overlap in the SWIG integration which has now been fixed by introducing
callbacks for initializing SWIG for each language (python only right now).
There was also a breakpoint command callback that called into SWIG which has
been abtracted into a callback to avoid cross over as well.
Added a new binary: lldb-platform
This will be the start of the remote platform that will use as much of the
Host functionality to do its job so it should just work on all platforms.
It is pretty hollowed out for now, but soon it will implement a platform
using the GDB remote packets as the transport.
llvm-svn: 128053
command(s) right after starting up gdb. Update the README file to show an example of
using these to pass '-arch armv7' to gdb and to execute gdb command to set shared library
path substitutions before loading iOS4.3 sdk's /usr/lib/libSystem.B.dylib and disassembling
the 'printf' function.
llvm-svn: 128040
static archive that can be linked against. LLDB.framework/lldb.so
exports a very controlled API. Splitting the API into a static
library allows other tools (debugserver for now) to use the power
of the LLDB debugger core, yet not export it as its API is not
portable or maintainable. The Host layer and many of the other
internal only APIs can now be statically linked against.
Now LLDB.framework/lldb.so links against "liblldb-core.a" instead
of compiling the .o files only for the shared library. This fix
is only for compiling with Xcode as the Makefile based build already
does this.
The Xcode projecdt compiler has been changed to LLVM. Anyone using
Xcode 3 will need to manually change the compiler back to GCC 4.2,
or update to Xcode 4.
llvm-svn: 127963
platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)
When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can
do:
(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib
Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.
This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.
llvm-svn: 127934
ReadCoreReg (which 'does the right thing', adding to pc when needed);
fixed places in code where extra addition was being passed along.
Fix bug in insn tables.
llvm-svn: 127838
read the memory contents of the function, and then feed the bytes to the
'llvm-mc -disassemble' command.
It uses the pexpect module located under ToT/test/pexpect-2.4 directory to
automate the interaction with gdb. This is used initially to test the low
level ARM disassembler of llvm.
llvm-svn: 127785
for templatized types that could cause parts of a std::vector (and I am sure
other STL types) to be incorrectly uniqued to each other wreaking havoc on
variable display for types within the same executable module.
llvm-svn: 127662
types that have different contents. Currently LLDB is incorrectly uniquing,
on MacOSX, the std::vector _VectorImpl class from the two different vector
templates. The DWARF looks like:
0x0000008e: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<int,std::allocator<int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000103} )
0x00000098: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x000000a0: DW_TAG_inheritance [9]
DW_AT_type( {0x000006fa} ( allocator<int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
0x0000011b: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<short int,std::allocator<short int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000190} )
0x00000125: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x0000012d: DW_TAG_inheritance [9]
DW_AT_type( {0x00000f75} ( allocator<short int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
In this case it using DIE 0x00000098 for both 0x00000098 and 0x00000125.
This test will help detect this issue once I have a fix for it. I have a fix
that I am testing.
llvm-svn: 127660
We were dropping the expansion of -rpath=$(LibDir) on linux, which resulted in
the build not being able to resolve libLLVM.so. Bring in the definition before
expanding the values hanging off LD.Flags.
Thanks to Jason E. Aten for reporting this!
llvm-svn: 127570
This uses pexpect module to spawn a 'lldb' program and uses pseudo-TTY to talk to
the child application.
The test cases test setting breakpoints, adding a stop-hook with line range, and
verifies that when the inferior stops, the stop-hook will fire off when it is
within range and will not fire off when it is out of range.
llvm-svn: 127519
Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language.
llvm-svn: 127457
SBTarget.Launch() API, stop at a breakpoint, get the stopped thread, and verify that the
pid of the stopped thread's process is equal to the pid of the process returned by
SBTarget.Launch().
llvm-svn: 127444
correct order. Previously this was tacitly implemented but not
enforced, so it was possible to accidentally do things in the wrong
order and cause problems. This fixes that problem.
llvm-svn: 127430
Jim Ingham