| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 155586
|
|
|
|
|
|
|
|
| |
doesn't print out all of the commands when executing the shell script.
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
|
|
|
|
|
|
| |
an issue that was preventing Python oneliners from executing
llvm-svn: 155563
|
|
|
|
| |
llvm-svn: 155556
|
|
|
|
|
|
| |
import and reference the Logger
llvm-svn: 155555
|
|
|
|
|
|
| |
work with all of the new module paths.
llvm-svn: 155528
|
|
|
|
|
|
| |
resources - This is one of the steps towards making the data formatters work again
llvm-svn: 155526
|
|
|
|
| |
llvm-svn: 155524
|
|
|
|
| |
llvm-svn: 155523
|
|
|
|
| |
llvm-svn: 155520
|
|
|
|
|
|
|
|
| |
global namespace.
Enrico will follow this up with fixing the data formatter test cases that are failing.
llvm-svn: 155514
|
|
|
|
|
|
| |
or malloc_info are called. If MallocStackLogging is enabled, then you can now use --stack to dump the backtrace of the code that allocated each malloc block.
llvm-svn: 155262
|
|
|
|
|
|
| |
symbolication.add_module() to not use the resolved_path before we have tried to locate it. Fixed crashlog.locate_module_and_debug_symbols() to return true and false correctly.
llvm-svn: 155255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
suite such that
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
|
|
|
|
|
|
| |
of LLDB.framework.
llvm-svn: 154728
|
|
|
|
|
|
| |
with a default format that makes sense, or that format can be overridden with the --format option.
llvm-svn: 154671
|
|
|
|
| |
llvm-svn: 154615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block. Using this on the lldb/test/lang/objc/foundation test we can see this in action:
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
|
|
|
|
| |
llvm-svn: 154506
|
|
|
|
|
|
| |
find values on the heap and print out the dynamic type of the malloc block that contains the data. I will be modifying this a bit more to tweak the output and make the output more useful.
llvm-svn: 154504
|
|
|
|
|
|
| |
results that are found by the function calls to find_pointer_in_heap().
llvm-svn: 154435
|
|
|
|
| |
llvm-svn: 154419
|
|
|
|
|
|
| |
diagnostic output from the synthetic children providers - this time the fix should work
llvm-svn: 154361
|
|
|
|
|
|
| |
--start argument. Fixed that.
llvm-svn: 154221
|
|
|
|
|
|
| |
the stress test by a LOT.
llvm-svn: 154208
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
any targets. Then modified the darwin "crashlog.py" to use this agnostic info and the new functionality and classes.
llvm-svn: 153969
|
|
|
|
| |
llvm-svn: 153911
|
|
|
|
| |
llvm-svn: 153910
|
|
|
|
| |
llvm-svn: 153907
|
|
|
|
| |
llvm-svn: 153899
|
|
|
|
| |
llvm-svn: 153878
|
|
|
|
|
|
| |
prevent errors about count being undefined from showing up
llvm-svn: 153791
|
|
|
|
|
|
| |
catch problems; more logging might/will be added as needed
llvm-svn: 153750
|
|
|
|
|
|
| |
formatters eating up all the stack when an unknown class has to be summarized ; this should make the whole Objective-C summaries more stable
llvm-svn: 153712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of bug fixing for data formatter issues.
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
|
|
|
|
|
|
| |
itself to be disassembled.
llvm-svn: 153626
|
|
|
|
|
|
| |
escape sequences by the summary provider shipping with LLDB - Added relevant test case code. Bonus points for identifying the source of the quotes :-)
llvm-svn: 153624
|
|
|
|
| |
llvm-svn: 153559
|
|
|
|
| |
llvm-svn: 153541
|
|
|
|
|
|
|
|
|
|
|
|
| |
SBValue is set up to always wrap a synthetic value when one is available.
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
|
|
|
|
|
|
| |
from the command line which was causing this script to dump the script itself.
llvm-svn: 153294
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
binary from any location and _then_ do the symbolication. Something like:
(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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following the naming pattern
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
|
|
|
|
| |
llvm-svn: 152970
|
|
|
|
|
|
| |
an example
llvm-svn: 152890
|
|
|
|
| |
llvm-svn: 152888
|