Commit Graph

125 Commits

Author SHA1 Message Date
Sean Callanan 575a4545de Improved logging for the SBTarget's launching
and attaching APIs.

llvm-svn: 166356
2012-10-20 00:21:31 +00:00
Jason Molenda 4bd4e7e3ba Add support for debugging KASLR kernels via kdp (the kernel being
loaded at a random offset).

To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.

I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.

<rdar://problem/7714201>

llvm-svn: 164881
2012-09-29 04:02:01 +00:00
Greg Clayton b5f0feabae Wrapped up the work I am going to do for now for the "add-dsym" or "target symfile add" command.
We can now do:

Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>

Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib

Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>

Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame

llvm-svn: 164806
2012-09-27 22:26:11 +00:00
Greg Clayton 91e407ea07 If we are attached to a platform, then make sure that we can verify that a process exists when attaching by "pid" before we try and do a lengthy command that could take a while to timeout.
llvm-svn: 164738
2012-09-27 00:03:39 +00:00
Greg Clayton e2186ed6d9 Patch from Andrew Kaylor for linux:
The attached patch fixes a problem with performing an attach from the SBTarget API on Linux (and other systems that use ProcessPOSIX).
 
When Process::Attach was called from SBTarget, it resulted in a call to a form of the DoAttachWithID function that wasn't implemented in ProcessPOSIX, and so it fell back to the default implementation (which just returns an error).  It didn't seem necessary to use the attach_info parameter for this case, so I just implemented it as a call to the simpler version of the function.
 
In debugging this problem, I also found that SBTarget wasn't checking the return value from the Attach call, causing it to hang when the attach fails.

llvm-svn: 163399
2012-09-07 17:51:47 +00:00
Greg Clayton 1f7460716b <rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860
2012-08-29 21:13:06 +00:00
Jim Ingham cd16df9154 Add "vAttachOrWait" to debugserver, so you can implement "attach to the process if it exists OR wait for it" without race conditions. Use that in lldb.
llvm-svn: 160578
2012-07-20 21:37:13 +00:00
Greg Clayton 23f59509a8 Ran the static analyzer on the codebase and found a few things.
llvm-svn: 160338
2012-07-17 03:23:13 +00:00
Greg Clayton 7820bd1e52 <rdar://problem/11357711>
Fixed a crasher where the section load list was not thread safe.

llvm-svn: 159884
2012-07-07 01:24:12 +00:00
Johnny Chen b90827e66c rdar://problem/11584012
Refactorings of watchpoint creation APIs so that SBTarget::WatchAddress(), SBValue::Watch(), and SBValue::WatchPointee()
now take an additional 'SBError &error' parameter (at the end) to contain the reason if there is some failure in the
operation.  Update 'watchpoint set variable/expression' commands to take advantage of that.

Update existing test cases to reflect the API change and add test cases to verify that the SBError mechanism works for
SBTarget::WatchAddress() by passing an invalid watch_size.

llvm-svn: 157964
2012-06-04 23:19:54 +00:00
Johnny Chen 7385a5ae0b Thread-hardening the SB API calls related to watchpoint operations.
llvm-svn: 157776
2012-05-31 22:56:36 +00:00
Jim Ingham a8558b6289 Also push file & line breakpoints past the prologue. Also added a "-K" argument to the relevant
"break set" commands to set this per breakpoint.  Also, some CreateBreakpoint API's in the lldb_private
namespace had "internal" first and "skip_prologue" second.  "internal should always be last.  Fixed that.

rdar://problem/11484729

llvm-svn: 157225
2012-05-22 00:12:20 +00:00
Filipe Cabecinhas 721ba3ff77 Fixes the case where we created a dummy target, deleted it, and then tried to evaluate an expression with no target.
llvm-svn: 157110
2012-05-19 09:59:08 +00:00
Greg Clayton b210aec64d Added the ability to specify the symbol file for a module when adding it to a target.
llvm-svn: 155384
2012-04-23 20:23:39 +00:00
Greg Clayton 29399a24c6 In a prior commit, I changed the parameters around on a ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit.
llvm-svn: 154182
2012-04-06 17:41:13 +00:00
Greg Clayton d761d42707 Removed unused variable.
llvm-svn: 153625
2012-03-29 01:39:57 +00:00
Greg Clayton 741f3f9a55 lldb_private::Section objects have a boolean flag that can be set that
indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.

lldb_private::Section now has:

bool
Section::IsThreadSpecific () const
{
    return m_thread_specific;
}

void
Section::SetIsThreadSpecific (bool b)
{
    m_thread_specific = b;
}

The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"
sections.

Eventually we need to have each lldb_private::Thread subclass be able to 
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.

llvm-svn: 153537
2012-03-27 21:10:07 +00:00
Greg Clayton 84db9105d2 <rdar://problem/11113279>
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482
2012-03-26 23:03:23 +00:00
Greg Clayton ecc7c0d817 Moved inline functions into SBTarget.cpp and made destructors for SBLaunchInfo and SBAttachInfo to avoid link warnings.
llvm-svn: 152267
2012-03-07 23:52:51 +00:00
Greg Clayton 9c76611055 Added the ability to disassembly "count" instructions given a SBAddress.
This was done in SBTarget:

lldb::SBInstructionList
lldb::SBTarget::ReadInstructions (lldb::SBAddress base_addr, uint32_t count);

Also cleaned up a few files in the LLDB.framework settings.

llvm-svn: 152152
2012-03-06 22:24:44 +00:00
Jim Ingham fab10e89ce Add a command and an SB API to create exception breakpoints. Make the break output prettier for Exception breakpoints.
llvm-svn: 152081
2012-03-06 00:37:27 +00:00
Han Ming Ong 04cf1bad35 <rdar://problem/10967188>
When using launch_info for launching with a target already set, we should just prepend the target's path as the first argument.

llvm-svn: 151867
2012-03-02 01:02:04 +00:00
Han Ming Ong bee9839770 <rdar://10949461>
Only set the ProcessSP when the attach is successful.

llvm-svn: 151741
2012-02-29 19:16:40 +00:00
Han Ming Ong cec8c90a2e <rdar://10950312>
Need to GetProcess() to set the uid of the process to attach.

llvm-svn: 151679
2012-02-29 00:12:56 +00:00
Greg Clayton b9a01b3990 Made a ModuleSpec class in Module.h which can specify a module using one or
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself. 

I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong  symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.

llvm-svn: 151476
2012-02-26 05:51:37 +00:00
Han Ming Ong 846470482c <rdar://problem/3535148>
Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only.

llvm-svn: 151419
2012-02-25 01:07:38 +00:00
Greg Clayton 41bd8ac206 Added some missing accessors to the SBAttachInfo for user and group ID
getting, setting, and checking.

llvm-svn: 151408
2012-02-24 23:56:06 +00:00
Greg Clayton 38d1f05167 Fixed the launching code when using the new SBLaunchInfo.
llvm-svn: 151392
2012-02-24 20:59:25 +00:00
Greg Clayton 0e615684bb Added the new way we will eventually do all attaches and launches. First clients
will fill out either a SBLaunchInfo or SBAttachInfo class, then call:

SBProcess SBTarget::Launch (SBLaunchInfo &, SBError &);
SBProcess SBTarget::Attach (SBAttachInfo &, SBError &);

The attach is working right now and allows the ability to set many filters such
as the parent process ID, the user/group ID, the effective user/group ID, and much
more.

The launch is not yet working, but I will get this working soon. By changing our
launch and attach calls to take an object, it allows us to add more capabilities to
launching and attaching without having to have launch and attach functions that
take more and more arguments. 

Once this is all working we will deprecated the older launch and attach fucntions
and eventually remove them.

llvm-svn: 151344
2012-02-24 05:03:03 +00:00
Greg Clayton e72dfb321c <rdar://problem/10103468>
I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had 
lldb_private::Section pointers into modules that had been removed or 
replaced. This also let to grabbing stale modules from those sections. 
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *. 

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed. 

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.

llvm-svn: 151336
2012-02-24 01:59:29 +00:00
Jim Ingham 4bddaeb5ab Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set.
Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/10619974>

llvm-svn: 150665
2012-02-16 06:50:00 +00:00
Sean Callanan 9df05fbb7f Extended function lookup to allow the user to
indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.

llvm-svn: 150279
2012-02-10 22:52:19 +00:00
Greg Clayton c3776bf288 First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory. 

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many 
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the 
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for 
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.

llvm-svn: 150154
2012-02-09 06:16:32 +00:00
Greg Clayton 5569e64ea7 Removed all of the "#ifndef SWIG" from the SB header files since we are using
interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853
2012-02-06 01:44:54 +00:00
Greg Clayton 81e871ed76 Convert all python objects in our API to use overload the __str__ method
instead of the __repr__. __repr__ is a function that should return an
expression that can be used to recreate an python object and we were using
it to just return a human readable string.

Fixed a crasher when using the new implementation of SBValue::Cast(SBType).

Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general
improvements to the API.

Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't
correctly handle not having a target.

llvm-svn: 149743
2012-02-04 02:27:34 +00:00
Greg Clayton acdbe81637 lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still
contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.

Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.

For any code the public API files, we should always be grabbing shared 
pointers to any objects for the current class, and any other classes prior
to running code with them.

llvm-svn: 149238
2012-01-30 09:04:36 +00:00
Greg Clayton b9556acc9e SBFrame is now threadsafe using some extra tricks. One issue is that stack
frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life 
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until 
the thread goes away or the StackID no longer exists in the stack for the 
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:

1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
    still around inside a shared pointer, yet, not part of the current 
    thread (a new stack frame object had appeared with the same stack ID and
    depth). 
    
We now avoid all such issues and properly keep up to date, or we start 
returning errors when the frame doesn't exist and always responds with
invalid answers.

Also fixed the UserSettingsController  (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer 
needed.

llvm-svn: 149231
2012-01-30 07:41:31 +00:00
Greg Clayton e1cd1be6d6 Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
pointer from just a pointer, which is also easily solved using the 
std::tr1::enable_shared_from_this class. 

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).

llvm-svn: 149207
2012-01-29 20:56:30 +00:00
Greg Clayton 13d1950ae6 Added the ability to get the target triple, byte order and address byte size
from the SBTarget and SBModule interfaces. Also added many python properties
for easier access to many things from many SB objects.

llvm-svn: 149191
2012-01-29 06:07:39 +00:00
Johnny Chen 3ac503e042 Work in progress for:
rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.

llvm-svn: 146948
2011-12-20 01:22:03 +00:00
Johnny Chen 9530770bd6 Remove dead code found.
llvm-svn: 146936
2011-12-20 00:58:20 +00:00
Sean Callanan 50952e9571 I have added a function to SBTarget that allows
clients to disassemble a series of raw bytes as
demonstrated by a new testcase.

In the future, this API will also allow clients
to provide a callback that adds comments for
addresses in the disassembly.

I also modified the SWIG harness to ensure that
Python ByteArrays work as well as strings as
sources of raw data.

llvm-svn: 146611
2011-12-14 23:49:37 +00:00
Johnny Chen c6770763e6 http://llvm.org/bugs/show_bug.cgi?id=11560 lldb::SBTarget::FindFirstType crashes when passed None
Add null checks to several functions.  Plus add test scenario for passing None to SBTarget.FindFirstType(None) and friends.

llvm-svn: 146540
2011-12-14 01:43:31 +00:00
Greg Clayton 1ba6cfd1e6 After moving lldb::pid_t to 64 bits, keep a deprecated version around for
previous binaries that link against this for a few builds to make sure we
can continue to run against previous binaries.

llvm-svn: 145668
2011-12-02 02:10:57 +00:00
Greg Clayton ad9e828c89 <rdar://problem/10429064>
Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.

llvm-svn: 145371
2011-11-29 04:03:30 +00:00
Greg Clayton 144f3a9c90 Added a new class to Process.h: ProcessAttachInfo. This class contains enough
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
2011-11-15 03:53:30 +00:00
Greg Clayton da7bc7d000 <rdar://problem/10126482>
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
2011-11-13 06:57:31 +00:00
Greg Clayton c9ed478a39 Added the ability to run a process in a shell on MacOSX currently when using
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
2011-11-12 02:10:56 +00:00
Greg Clayton 982c9762a2 Modified all Process::Launch() calls to use a ProcessLaunchInfo structure
on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. Also all of the argument,
envronment and stdio things are now handled in a much more centralized fashion.

llvm-svn: 143656
2011-11-03 21:22:33 +00:00
Johnny Chen f5be9e3759 Add a test case to exercise the newly added SB API:
lldb::SBWatchpoint
SBTarget::WatchAddress (lldb::addr_t addr, size_t size, bool read, bool write)

llvm-svn: 141931
2011-10-14 01:16:39 +00:00