| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if no indexes are supplied. This can be handy to use as:
(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
|
|
|
|
|
|
| |
added options to allow showing source for all frames (--source-frames=NFRAMES) and for all threads (--source-all).
llvm-svn: 160175
|
|
|
|
|
|
|
|
| |
command with the "--source-context" (-C for short to match grep) option.
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
|
|
|
|
|
|
| |
and prints any available info.
llvm-svn: 159775
|
|
|
|
|
|
| |
work correctly when run inside LLDB. Before this fix the "cmd.Cmd" object was trying to read from stdin itself and it was competing without command interpreter for the bytes.
llvm-svn: 159688
|
|
|
|
|
|
|
|
| |
enabled, then dump full paths to source files and modules.
Changed much of the output that was coming out with "--verbose" over to use the new "--debug" flag.
llvm-svn: 159363
|
|
|
|
|
|
| |
allow you to dump your current process state out to a crash log file. This will dump all of the target module information with all load addresses, UUID values, and shared library paths, as well as all thread stacks and the crash log header. This will make it easy for us to save the current state of a process and then reload it later into LLDB.
llvm-svn: 159286
|
|
|
|
|
|
|
|
| |
when symbolicating after loading a crash log file.
Added colorization to the gdbremote.py output and also added the ability to symbolicate the addresses in registers.
llvm-svn: 157965
|
|
|
|
|
|
| |
This will make it easier to symbolicate the packet log output since we can use the lldb.utils.symbolication package module to symbolicate register values.
llvm-svn: 157835
|
|
|
|
|
|
| |
interactive mode.
llvm-svn: 157770
|
|
|
|
|
|
| |
frames when it isn't the zero'th frame.
llvm-svn: 156974
|
|
|
|
| |
llvm-svn: 156945
|
|
|
|
|
|
|
|
| |
object and made an accessor for getting a normalized UUID value out of the image object.
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
|
|
|
|
|
|
|
|
| |
from the crash log file.
rdar://problem/11428134
llvm-svn: 156581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
multiple crash logs at once and do some data mining. Added an interactive command prompt that allows you to do:
% 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
|
|
|
|
|
|
|
|
| |
session:
AttributeError: 'module' object has no attribute 'debugger'
llvm-svn: 156115
|
|
|
|
|
|
| |
rdar://problem/11374653
llvm-svn: 156088
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
work with all of the new module paths.
llvm-svn: 155528
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
of LLDB.framework.
llvm-svn: 154728
|
|
|
|
|
|
| |
--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: 153907
|
|
|
|
|
|
| |
itself to be disassembled.
llvm-svn: 153626
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and to print the total count & time in the header.
llvm-svn: 151823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sbvalue.value (<SBValue>)
sbvalue.variable (<SBValue>)
Initialize both with a lldb.SBValue
sbvalue.value() make all sorts of convenience properties. Type "help(sbvalue.value)"
in the embedded python interpreter to see what is available.
sbvalue.variable() wraps a lldb.SBValue and allows you to play with your variable just
as you would expect:
pt = sbvalue.variable (lldb.frame.FindVariable("pt"))
print pt.x
print py.y
argv = sbvalue.variable (lldb.frame.FindVariable("argv"))
print argv[0]
Member access and array acccess is all taken care of!
llvm-svn: 149260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
end_gdb_log.
When this is imported into your lldb using the "command script import /path/to/gdbremote.py"
these new commands are available within LLDB. 'start_gdb_log' will enable logging with
timestamps for GDB remote packets, and 'stop_gdb_log' will then dump the details and
also a lot of packet timing data. This allows us to accurately track what packets are
taking up the most time when debugging (when using the ProcessGDBRemote debugging plug-in).
Also udpated the comments at the top of the cmdtemplate.py to show how to correctly import
the module from within LLDB.
llvm-svn: 149030
|
|
|
|
| |
llvm-svn: 148768
|
|
|
|
|
|
|
| |
to breakpoints, creating new LLDB commands using python modules and also how
to run scripts from the command line.
llvm-svn: 148650
|
|
|
|
|
|
|
| |
PC to disassemble. Users can also specify the frame depth to disassemble to
and also if disassembly should happen for all threads.
llvm-svn: 148627
|
|
|
|
|
|
|
|
|
|
| |
python so that single and double quotes and other standard shell like argument
parsing happens as expected before passing stuff along to option parsing.
Also handle exceptions so that we don't accidentally exit lldb if an uncaught
exception occurs.
llvm-svn: 148623
|
|
|
|
|
|
|
|
|
|
|
|
| |
filled out the command help and removed unused options.
Updated the command to have a "--load-all" option that will cause the target
that gets created to locate and load all images specified in the Binary Images
section of the crash log to allow for complete program state to be matched
to that of the crash log, not just the images that were in the stack frames
(the default).
llvm-svn: 148605
|
|
|
|
|
|
|
|
| |
(lldb) script import crashlog
will automatically add the "crashlog" command to the command interpreter!
llvm-svn: 148598
|
|
|
|
|
|
| |
a reference to a class variable.
llvm-svn: 148562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
environment variable it set to include a path to lldb.py.
Also fixed the case where the executable can't be located and doesn't match
what is installed on the current system. It will still symbolicate the other
frames, and will just show what was originally in the crash log file.
Also removed the --crash-log option so the arguments to the "crashlog"
command are one or more paths to crash logs.
Fixed the script to "auto-install" itself when loaded from the embedded
script interpreter. Now you only need to import the module and the
command is ready for use.
llvm-svn: 148561
|
|
|
|
|
|
|
| |
system and also deal with dsymForUUID being available on the network, locally,
and not at all.
llvm-svn: 148534
|
|
|
|
|
|
|
|
|
|
| |
of the identifier name in the binary images section. Improved the regular
expression for the frames.
Added a new file "crashlog.lldb" which can be sourced with "command source"
that will import the module and set itself up to be used as a command.
llvm-svn: 148529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module (you can't import a module with a '-' in it) and also added a
Symbolcate(...) top level function so it can be imported and used as an
LLDB command.
Then you can import the module and map a "crashlog" command (for darwin
use only currently) to the python function "crashlog.Symbolicate":
(lldb) script import crashlog
(lldb) command script add -f crashlog.Symbolicate crashlog
Then use it to symbolicate:
(lldb) crashlog --crash-log /path/to/foo.crash
The crash log will then get symbolicated and inline frames will be added to
the crash log and the frames will be displayed. The crash log currently will
only try and fetch and setup the target images requires in order to do the
symbolication.
This will need to be iterated upon, but it is getting close to being useful
so I am going to check this in.
llvm-svn: 148528
|
|
|
|
| |
llvm-svn: 141340
|
|
|
|
|
|
| |
built-in iterators.
llvm-svn: 141326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbol context that represents an inlined function. This function has been
renamed internally to:
bool
SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc,
SymbolContext &next_frame_sc,
Address &next_frame_pc) const;
And externally to:
SBSymbolContext
SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc,
SBAddress &parent_frame_addr) const;
The correct blocks are now correctly calculated.
Switched the stack backtracing engine (in StackFrameList) and the address
context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...)
so all inlined callstacks will match exactly.
llvm-svn: 140910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
const char *
SBInstruction::GetMnemonic()
const char *
SBInstruction::GetOperands()
const char *
SBInstruction::GetComment()
Fixed the symbolicate example script and the internals.
llvm-svn: 140591
|