- Add latency timings to GDB packet log summary if timestamps are on log
- Add the ability to plot the latencies for each packet type with --plot
- Don't crash the script when target xml register info is in wierd format
llvm-svn: 343243
Fixes include:
- fix all lint errors
- add code that will automatically register and LLDB command classes by detecting the classes and any classes that have a "register_lldb_command" function
- automatically fill in the correct module name when registering commands
- automatically fill in the class name when registering command
llvm-svn: 335401
This is a combination stand alone BSD archive tool that can dump BSD archives:
% bsd.py /path/to/foo.a
Search archives for an object file:
% bsd.py --object foo.o bar.a
Dump the symbol definitions found in the __.SYMDEF objects:
% bsd.py --symdef bar.a
Find symbols by name that are listed in the __.SYMDEF objects:
% bsd.py --symbol _Z123 bar.a
Extract objects from BSD archives:
% bsd.py --object foo.o bar.a --extract
% bsd.py --object foo.o bar.a --extract --outfile /tmp/foo.o
% bsd.py --object foo.o bar.a --extract --mtime 0x1234556
It also has installs a new LLDB command line command when imported into LLDB:
(lldb) command script import ~/Dropbox/bin/bsd.py
The "verify-debug-map-objects" command has been installed, type "help verify-debug-map-objects" for detailed help.
(lldb) verify-debug-map-objects a.out
This will iterate through all object files and verify the modification times match for any .o files, it will verify any .o files from BSD archives are found and have matching modification times and print out errors if any are found.
llvm-svn: 328990
This version relies on a newer and more convenient way
to use a class to implement a command. It has been in place
since early 2015, so it should be pretty safe to use.
llvm-svn: 317043
Sometimes you want to step along and print a local each time as you go.
You can do that with stop hooks, but that's a little heavy-weight. This
is a sketch of a command that steps and then does "frame variable" on all
its arguments.
llvm-svn: 314958
Sometimes you are debugging in source, but you really only want to see
the disassembly. That's easy to do but you have to set a few variables.
This command toggles between your old values, and a disassembly only mode.
llvm-svn: 300902
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
A few fixes:
- Check the process state to make sure it is stopped
- Grab the frame from the "exe_ctx" so this will work during breakpoint callbacks
- Print out the SBDeclaration objects of the variables that shadow each other so we can see the source locations of which variable declarations are shodowing each other.
llvm-svn: 273963
This shows how to grab individual blocks from stack frames and get only the variables from those blocks. It then will iterate over all of the parent blocks and look for shadowed variables.
llvm-svn: 273604
version of this script. We picked up a bug at some point in March
where scripts that fail to call SBDebugger::Destroy() will crash
in the Debugger C++ dtor. I want to track the change down which
introduced the change - but this script should be calling
SBDebugger::Destroy() in the first place, so do that.
llvm-svn: 233779
- tree items can define any number of key/value pairs
- creating a tree you specify which columns you want to display and it will pick out the right key/value pairs from the new tree item dictionaries
- added new "tk-target" command to explore the target's images, sections, symbols, compile units and line tables.
llvm-svn: 219219
If you "command script import" this file, then you will have two new commands:
(lldb) tk-variables
(lldb) tk-process
Not sure how this will work on all other systems, but on MacOSX, you will get a window with a tree view that allows you to inspect your local variables by expanding variables to see the child values.
The "tk-process" allows you to inspect the currently selected process by expanding the process to see the threads, the threads to see the frames, and the frames to see the variables. Very handy if you want to view variables for all frames simultaneously.
llvm-svn: 218279
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
This commit adds an example python file that can be used with 'target-definition-file' setting for Linux gdbserver.
This file has an extra key 'breakpoint-pc-offset' that LLDB uses to determine how much to change the PC
after hitting the breakpoint.
llvm-svn: 192962
- Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication
- Finished up the target definition python setting stuff.
- Added a new "slice" key/value pair that can specify that a register is part of another register:
{ 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' },
- Added a new "composite" key/value pair that can specify that a register is made up of two or more registers:
{ 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] },
- Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers:
{ 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']},
This now completes the feature that allows a GDB remote target to completely describe itself.
llvm-svn: 192858
When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the
registers on the remote server. When those packets aren't supported, LLDB doesn't
know what the registers look like. This checkin implements a setting that can be used
to specify a python file that contains the registers definitions. The setting is:
(lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py
Inside module there should be a function:
def get_dynamic_setting(target, setting_name):
This dynamic setting function is handed the "target" which is a SBTarget, and the
"setting_name", which is the name of the dynamic setting to retrieve. For the GDB
remote target definition the setting name is 'gdb-server-target-definition'. The
return value is a dictionary that follows the same format as the OperatingSystem
plugins follow. I have checked in an example file that implements the x86_64 GDB
register set for people to see:
examples/python/x86_64_target_definition.py
This allows LLDB to debug to any archticture that is support and allows users to
define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo)
are not supported by the remote GDB server.
A few benefits of doing this in Python:
1 - The dynamic register context was already supported in the OperatingSystem plug-in
2 - Register contexts can use all of the LLDB enumerations and definitions for things
like lldb::Format, lldb::Encoding, generic register numbers, invalid registers
numbers, etc.
3 - The code that generates the register context can use the program to calculate the
register context contents (like offsets, register numbers, and more)
4 - True dynamic detection could be used where variables and types could be read from
the target program itself in order to determine which registers are available since
the target is passed into the python function.
This is designed to be used instead of XML since it is more dynamic and code flow and
functions can be used to make the dictionary.
llvm-svn: 192646
Added "mach_o.py" which is a mach-o parser that can dump mach-o file contents and also extract sections. It uses the "file_extract" module and the "dict_utils" module.
llvm-svn: 189959
print five words of memory at the beginning of the stack frame so it's
easier to track where an incorrect saved-fp or saved-pc may have come from.
llvm-svn: 185903
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.
llvm-svn: 184364
Change the simple-minded stack walk to not depend on lldb to unwind
the first frame.
Collect a list of Modules and Addresses seen while backtracing (with
both methods), display the image list output for all of those modules,
plus disassemble and image show-unwind any additional frames that
the simple backtrace was able to unwind through instead of just the
lldb unwind algorithm frames.
Remove checks for older lldb's that didn't support -a for disassemble
or specifying the assembler syntax on x86 targets.
llvm-svn: 184280
This module uses Python's sys.settrace() mechanism so setup a hook that can log every significant operation
This is a first step in providing a good debugging experience of Python embedded in LLDB
This module comprises an OO infrastructure that wraps Python's tracing and inspecting mechanisms, plus a very simple logging tracer
Output from this tracer looks like:
call print_keyword_args from <module> @ 243 args are kwargs are {'first_name': 'John', 'last_name': 'Doe'}
running print_keyword_args @ 228 locals are {'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
first_name = John
running print_keyword_args @ 228 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
last_name = Doe
running print_keyword_args @ 228 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
return from print_keyword_args value is None locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
llvm-svn: 181343
finish-swig-Python-LLDB.sh to create a new lldb.diagnose subdirectory
in the LLDB framework; the first diagnostic command in this directory
is diagnose-unwind. There may be others added in the future.
Users can load these diagnostic tools into their session with
"script import lldb.diagnose".
llvm-svn: 180768
lldb-179 version numberings and the new lldb-300 version numberings.
Remove the pretense that someone might run this from the command
line; this is only used from within a live lldb debug session. Fix
the loading so it can be loaded via "script import lldb.macosx" or
the script can be loaded individually like "command script import
unwind_diagnose.py"
llvm-svn: 180085
unwind instructions for a function/symbol which contains that
address.
Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.
llvm-svn: 180079
It will be installed in the LLDB.framework and can be loaded with
(lldb) script import lldb.macosx
after which a "unwind-diagnose" command will be registered. Select
the thread which has a bad backtrace and run this command -- a lot
of information about the stack frames, and an alternate backtrace
algorithm, will be used. The information will often be sufficient
for a remote person to figure out why the backtrace failed.
<rdar://problem/13679300>
llvm-svn: 180077
crashlog.py was always subtracting 1 to point to the previous instruction when symbolicating ARM backtraces. Many times the backtraces will include bit zero set to 1 to indicate thumb, so we need to make sure we mask the address and then backup one for non frame zero frames.
llvm-svn: 178812
This is a very basic implementation of a library that easily allows to drive LLDB.framework to write test cases for performance
This is separate from the LLDB testsuite in test/ in that:
a) this uses C++ instead of Python to avoid measures being affected by SWIG
b) this is in very early development and needs lots of tweaking before it can be considered functionally complete
c) this is not meant to test correctness but to help catch performance regressions
There is a sample application built against the library (in darwin/sketch) that uses the famous sample app Sketch as an inferior to measure certain basic parameters of LLDB's behavior.
The resulting output is a PLIST much like the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>fetch-frames</key>
<real>0.13161715522222225</real>
</dict>
<dict>
<key>file-line-bkpt</key>
<real>0.029111678750000002</real>
</dict>
<dict>
<key>fetch-modules</key>
<real>0.00026376766666666668</real>
</dict>
<dict>
<key>fetch-vars</key>
<real>0.17820429311111111</real>
</dict>
<dict>
<key>run-expr</key>
<real>0.029676525769230768</real>
</dict>
</array>
</plist>
Areas for improvement:
- code cleanups (I will be out of the office for a couple days this coming week, but please keep ideas coming!)
- more metrics and test cases
- better error checking
This toolkit also comprises a simple event-loop-driven controller for LLDB, similar yet much simpler to what the Driver does to implement the lldb command-line tool.
llvm-svn: 176715
I used this to verify that the debug map line tables were the same as previous LLDB releases prior to my change in the DWARF in .o file linking.
llvm-svn: 176610
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
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
Greg Clayton