info for us to attach by pid, or by name and will also allow us to eventually
do a lot more powerful attaches. If you look at the options for the "platform
process list" command, there are many options which we should be able to
specify. This will allow us to do things like "attach to a process named 'tcsh'
that has a parent process ID of 123", or "attach to a process named 'x' which
has an effective user ID of 345".
I finished up the --shell implementation so that it can be used without the
--tty option in "process launch". The "--shell" option now can take an
optional argument which is the path to the shell to use (or a partial name
like "sh" which we will find using the current PATH environment variable).
Modified the Process::Attach to use the new ProcessAttachInfo as the sole
argument and centralized a lot of code that was in the "process attach"
Execute function so that everyone can take advantage of the powerful new
attach functionality.
llvm-svn: 144615
of problems with Objective-C object completion. To go
along with the LLVM/Clang-side fixes, we have a variety
of Objective-C improvements.
Fixes include:
- It is now possible to run expressions when stopped in
an Objective-C class method and have "self" act just
like "self" would act in the class method itself (i.e.,
[self classMethod] works without casting the return
type if debug info is present). To accomplish this,
the expression masquerades as a class method added by
a category.
- Objective-C objects can now provide methods and
properties and methods to Clang on demand (i.e., the
ASTImporter sets hasExternalVisibleDecls on Objective-C
interface objects).
- Objective-C built-in types, which had long been a bone
of contention (should we be using "id"? "id*"?), are
now fetched correctly using accessor functions on
ClangASTContext. We inhibit searches for them in the
debug information.
There are also a variety of logging fixes, and I made two
changes to the test suite:
- Enabled a test case for Objective-C properties in the
current translation unit.
- Added a test case for calling Objective-C class methods
when stopped in a class method.
llvm-svn: 144607
Fixed an issues with the SBType and SBTypeMember classes:
- Fixed SBType to be able to dump itself from python
- Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces
- Fixed SBTypeMember to be able to dump itself from python
- Fixed the SBTypeMember ability to get a field offset in bytes (the value
being returned was wrong)
- Added the SBTypeMember ability to get a field offset in bits
Cleaned up a lot of the Stream usage in the SB API files.
llvm-svn: 144493
This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.
The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.
While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
llvm-svn: 144489
the --tty option. So you can now get shell expansion and file redirection:
(lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt
Again, the "--tty" is mandatory for now until we hook this up to other
functions. The shell is also currently hard coded to "/bin/bash" and not the
"SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into.
llvm-svn: 144443
interfaces. This allows us to pull in Objective-C
method types on demand, which is also now implemented.
Also added a minor fix to prevent multiple-definition
errors for "Class" and "id".
llvm-svn: 144405
problem is that we had a bitfield that kept
track of what had been found so far, and inhibited
searches when the local variable bit was set.
This bitfield was not being initialized correctly.
llvm-svn: 144400
the argument description in the command name could cause a command
alias to crash, e.g.
command alias zzz target stop-hook delete 1
because the "name" is used to re-fetch the exact CommandObject when
adding the final arg.
<rdar://problem/10423753>
llvm-svn: 144330
string to avoid possible later crashes.
Modified the locations that do set the crash description to NULL out the
string when they are done doing their tasks.
llvm-svn: 144297
Fixed an issue where if you had an initialized global variable, we would not
link it up correctly in the debug info if the .o file had the symbols as
UNDF + EXT (undefined external). We now properly link the globals.
llvm-svn: 144259
lookups for Objective-C methods by selector.
Right now all it does is print log information.
Also improved the logging for imported TagDecls
to indicate whether or not the definition for
the imported TagDecl is complete.
llvm-svn: 144203
Add a more general purpose qMemoryRegionInfo packet which can
describe various attributes about a memory region. Currently it
will return the start address, size, and permissions (read, write,
executable) for the memory region. It may be possible to add
additional attributes in the future such as whether the region is
designated as stack memory or jitted code a la vmmap.
I still haven't implemented the lldb side of the code to use this
packet yet so there may be unexpected behavior - but the basic implementation looks
about right. I'll hook it up to lldb soon and fix any problems that crop up.
llvm-svn: 144175
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.
I want to have this feature available for the unwinder code. When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --
is the current pc value in an executable region (e.g. did they
jump to unallocated/unexecutable memory? we know how to unwind
from here if so.)
Is the stack pointer or the frame pointer the correct register
to use to find the caller's saved pc value?
Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.
llvm-svn: 144074
doesn't handle bitfields in eFormatChar's correctly, only eFormatUnsigned.
Fix DataExtractor::Dump to dump the bitfield eFormatChars correctly.
llvm-svn: 144069
be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.
llvm-svn: 144061
which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++. This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.
llvm-svn: 144042
dated 2010-21-15. The test started failure recently probably due to work done on the command parsing.
Anyway, the specific test sequence is invalid and is fixed now.
llvm-svn: 144039
a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled)
b) clears up several error messages
c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before
d) allows filename completion for "command script import" (much like what happens for "target create")
e) prevents "command script add" from replacing built-in commands with scripted commands
f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons)
plus, it fixes an issue in "type summary add" command handling which caused several test suite errors
llvm-svn: 144035
Greg Clayton