If you try to access any child > 0 without having touched child 0, LLDB won't be able to reconstruct type information from the debug info.
Previously, we would fail.
Now, we simply go fetch child 0 and then come back.
llvm-svn: 174795
C++11 lambdas that don't capture anything can be used as static callback functions!
Heavily modified this python module to be able to not require a dylib in order to traverse the heap allocations.
Re-implemented the ptr_refs, objc_refs, malloc_info and cstr_refs to use complex expressions that use lambdas to do all static callback function work.
llvm-svn: 173989
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
The Python data formatters use a per-process cache that was previously keying off the PID. Moving that to be based on this new notion of unique ID.
llvm-svn: 172633
Making MightHaveChildren() always return true regardless for our own data formatters
This is meant to optimize performance for common most-often-not-empty container classes
llvm-svn: 169759
Change the wording of NSNumber summary from absurd value to unexpected value when a tagged pointer shows up that does not match our knowledge of the internals
llvm-svn: 169751
Adding the new has_children (or MightHaveChildren() in C++) for the existing synthetic children providers
In a few cases, the new call is going to be much more efficient than the previous num_children > 0 check
When the optimization was marginal (e.g. std::vector<>), the choice was to use num_children in order to keep
implementation details in one function instead of duplicating code
Next step is to provide test cases
llvm-svn: 166506
Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:
settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py
Then run your program and see the extra threads.
llvm-svn: 166244
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.
Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
Currently, the new API objects and features are not exposed via Python.
The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own
llvm-svn: 164865
Fixed an issue where not all text would always be seen when running any of the functions in heap.py in Xcode. Now we put the text directly into the command result object and skip STDIO since we have issues with STDIO right now in python scripts.
Also fixed an issue with the "--stack-history" option where MallocStackLoggingNoCompact was assumed to have to be enabled... It doesn't, just MallocStackLogging.
llvm-svn: 163042
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
Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing.
llvm-svn: 162530
into individually named log destinations. In the simple usage-lldb-loggings example, we ran two cases which resulted
in two lldb_log files.
llvm-svn: 162378
(lldb) script import lldb.macosx.crashlog
(lldb) crashlog -i /tmp/*.crash
% symbolicate --crashed-only
This will symbolicate all of the crash logs only for the crashed thread.
Also print out the crash log index number in the output of the interactive "image" command:
(lldb) script import lldb.macosx.crashlog
(lldb) crashlog -i /tmp/*.crash
% image LLDB.framework
...
This then allows you to symbolicate a crash log by index accurately when you looked for an image of a specific version
llvm-svn: 160316
Also made the symbolication of the crash logs more efficient when using the "--crashed-only" ("-c") option where only the crashed thread is symbolicated. We now only download the images for the frames in the crashed thread.
llvm-svn: 160160
Modified the heap.py to be able to correctly indentify the exact ivar for the "ptr_refs" command no matter how deep the ivar is in a class hierarchy. Also fixed the ability for the heap command to symbolicate the stack backtrace when MallocStackLogging is set in the environment and the "--stack" option was specified.
llvm-svn: 159883
Modified the crashlog darwin module to always create a uuid.UUID object when making the symbolication.Image objects. Also modified it to handle some more types of crash log files and improved the register reading for thread registers of crashed threads.
llvm-svn: 156596
% PYTHONPATH=./build/Debug/LLDB.framework/Resources/Python ; ./build/Debug//LLDB.framework/Resources/Python/lldb/macosx/crashlog.py -i ~/Downloads/crashes2/*.crash )
then you get an interactive prompt where you can search for data within all crash logs. For example you can do:
% list
which will list all crash logs
And you can search for all images given an image basename, or full path:
% image LLDB
% image /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB
% image LLDB.framework
Which would all produce an output listing like:
40CD4430-7D27-3248-BE4C-71B1F36FC5D0 (1.132 - 132) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000011f8bc000 - 0x0000000120d3efbf)
B727A528-FF1F-3B20-9E4F-BBE96C7D922D (1.136 - 136) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000011e7f7000 - 0x000000011fc7ff87)
4D6F8DC2-5757-39C7-96B0-1A5B5171DC6B (1.137 - 137) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000012bd7f000 - 0x000000012d1fcfef)
FBF8786F-92B9-31E3-8BCD-A82148338966 (1.137 - 137) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000122d78000 - 0x00000001241f5fd7)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000119b8d000 - 0x000000011b02ef5f)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000111497000 - 0x0000000112938f5f)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000116680000 - 0x0000000117b21f5f)
llvm-svn: 156201
Cleaned up the lldb.utils.symbolication, lldb.macosx.heap and lldb.macosx.crashlog. The lldb.macosx.heap can now build a dylib for the current triple into a temp directory and use it from there.
llvm-svn: 155577
the pre-flight code gets executed during setUp() after the debugger instance is available
and the post-flight code gets executed during tearDown() after the debugger instance has
done killing the inferior and deleting all the target programs.
Example:
[11:32:48] johnny:/Volumes/data/lldb/svn/ToT/test $ ./dotest.py -A x86_64 -v -c ../examples/test/.lldb-pre-post-flight functionalities/watchpoint/hello_watchpoint
config: {'pre_flight': <function pre_flight at 0x1098541b8>, 'post_flight': <function post_flight at 0x109854230>}
LLDB build dir: /Volumes/data/lldb/svn/ToT/build/Debug
LLDB-139
Path: /Volumes/data/lldb/svn/ToT
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 154753
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 154730
Last Changed Date: 2012-04-13 18:42:46 -0700 (Fri, 13 Apr 2012)
lldb.pre_flight: def pre_flight(test):
__import__("lldb")
__import__("lldbtest")
print "\nRunning pre-flight function:"
print "for test case:", test
lldb.post_flight: def post_flight(test):
__import__("lldb")
__import__("lldbtest")
print "\nRunning post-flight function:"
print "for test case:", test
Session logs for test failures/errors/unexpected successes will go into directory '2012-04-16-11_34_08'
Command invoked: python ./dotest.py -A x86_64 -v -c ../examples/test/.lldb-pre-post-flight functionalities/watchpoint/hello_watchpoint
compilers=['clang']
Configuration: arch=x86_64 compiler=clang
----------------------------------------------------------------------
Collected 2 tests
1: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Test a simple sequence of watchpoint creation and watchpoint hit. ...
Running pre-flight function:
for test case: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Running post-flight function:
for test case: test_hello_watchpoint_with_dsym_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
ok
2: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Test a simple sequence of watchpoint creation and watchpoint hit. ...
Running pre-flight function:
for test case: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
Running post-flight function:
for test case: test_hello_watchpoint_with_dwarf_using_watchpoint_set (TestMyFirstWatchpoint.HelloWatchpointTestCase)
ok
----------------------------------------------------------------------
Ran 2 tests in 1.584s
OK
llvm-svn: 154847
(lldb) command script import heap.py
Find all malloc blocks that contains a pointer value of 0x1234000:
(lldb) ptr_refs 0x1234000
Find all malloc blocks that contain a C string:
(lldb) cstr_refs "hello"
Get info on a malloc block that starts at or contains 0x12340000
(lldb) malloc_info 0x12340000
llvm-svn: 154602
First we can load the module:
(lldb) command script import /Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/heap.py
Loading "/Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/libheap.dylib"...ok
Image 0 loaded.
"heap_ptr_refs" and "heap_cstr_refs" commands have been installed, use the "--help" options on these commands for detailed help.
Lets take a look at the variable "my":
(lldb) fr var *my
(MyString) *my = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
We can see that this contains an ivar "str" which has a pointer value of "0x0000000100301a60". Lets search the heap for this pointer and see what we find:
(lldb) heap_ptr_refs 0x0000000100301a60
found pointer 0x0000000100301a60: block = 0x103800270, size = 384, offset = 168, type = 'void *'
found pointer 0x0000000100301a60: block = 0x100301cf0, size = 48, offset = 16, type = 'MyString *', ivar = 'str'
(MyString) *addr = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 96, type = (autorelease object pool)
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 104, type = (autorelease object pool)
Note that it used dynamic type info to find that it was in "MyString" at offset 16 and it also found the ivar "str"!
We can also look for C string values on the heap. Lets look for "a.out":
(lldb) heap_cstr_refs "a.out"
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
We see we have some objective C classes that contain this, so lets "po" all of the results by adding the --po option:
(lldb) heap_cstr_refs a.out --po
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x10010ce00 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x100114490 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100114530 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114e40 a.out.dSYM
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114fa0 a.out
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
(__NSCFData *) 0x100300780 <48656c6c 6f206672 6f6d2027 2f566f6c 756d6573 2f776f72 6b2f6763 6c617974 6f6e2f44 6f63756d 656e7473 2f737263 2f6c6c64 622f7465 73742f6c 616e672f 6f626a63 2f666f75 6e646174 696f6e2f 612e6f75 742700>
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100301a60 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
llvm-svn: 154519
new features:
(1) it outputs the instruction currently being
tested to a log file, if a path is provided
(2) if instructed, it prints the time remaining
in the exhaustive test
llvm-svn: 154205
Right now it only works on Mac OS X, but other
platforms would just need to add their own
implementation of AddLLDBToSysPathOn*().
The stress-tester has two modes:
Used with --bytes N --random, the stress-tester
generates random instructions of length N and
runs them through the disassembler. This is
suitable for architectures like Intel where it
is combinatorially infeasible to run through the
entire space of possible instructions.
Used with --bytes N and no arguments (or --start
S --stride T), the stress-tester tests the
disassembler with a monotonically increasing
sequence of instructions.
The --start and --stride arguments are intended
for use in multiprocessing environments. Give
each core an ID from 0 .. T-1, pass the ID in as
the --start, and use T as the stride, and you
can launch one copy of the stress-tester on each
core you have available.
llvm-svn: 154143
We are introducing a new Logger class on the Python side. This has the same purpose, but is unrelated, to the C++ logging facility
The Pythonic logging can be enabled by using the following scripting commands:
(lldb) script Logger._lldb_formatters_debug_level = {0,1,2,...}
0 = no logging
1 = do log
2 = flush after logging each line - slower but safer
3 or more = each time a Logger is constructed, log the function that has created it
more log levels may be added, each one being more log-active than the previous
by default, the log output will come out on your screen, to direct it to a file:
(lldb) script Logger._lldb_formatters_debug_filename = 'filename'
that will make the output go to the file - set to None to disable the file output and get screen logging back
Logging has been enabled for the C++ STL formatters and for Cocoa class NSData - more logging will follow
synthetic children providers for classes list and map (both libstdcpp and libcxx) now have internal capping for safety reasons
this will fix crashers where a malformed list or map would not ever meet our termination conditions
to set the cap to a different value:
(lldb) script {gnu_libstdcpp|libcxx}.{map|list}_capping_size = new_cap (by default, it is 255)
you can optionally disable the loop detection algorithm for lists
(lldb) script {gnu_libstdcpp|libcxx}.list_uses_loop_detector = False
llvm-svn: 153676
A new setting enable-synthetic-value is provided on the target to disable this behavior.
There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic.
The test suite has been changed accordingly.
Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang
Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching
llvm-svn: 153495
parse the output from "log enable --timestamp ...." and converts it to be relative
to the first timestamp and shows the time deltas between log lines. This can also
be used as a stand along script outside of lldb:
./delta.py log.txt
llvm-svn: 153288
(lldb) file /path/to/file.so
(lldb) crashlog crash.log
....
Then if the file.so has already been loaded it will use the one that is already in LLDB without trying to match up the paths.
llvm-svn: 153075
Changes to synthetic children:
- the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points
this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed
- making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly)
claim to itself be synthetic
- cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible
- major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself
- removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place)
Some clean ups to the summary generation code
Centralized the code that clears out user-visible strings and data in ValueObject
More efficient summaries for libc++ containers
llvm-svn: 153061
This has been done for those summaries where the difference is only cosmetic (e.g. naming things as items instead of values, ...)
The LLDB output style has been preserved when it provides more information (e.g. telling the type as well as the value of an NSNumber)
Test cases have been updated to reflect the updated output style where necessary
llvm-svn: 152592
std::string has a summary provider
std::vector std::list and std::map have both a summary and a synthetic children provider
Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two
The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic)
The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because
(a) we need different compiler flags for libc++ than for libstdcpp
(b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference
llvm-svn: 152570
Enrico Granata