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
The previous implementation only read out the first element of the
underlying storage array. Because of it only the first 32 (on x86) or
the first 64 (on x86_64) element was displayed.
Differential revision: http://reviews.llvm.org/D8585
llvm-svn: 233179
Summary:
GCC does not emit some DWARF required for the simplified formatter
to work. A workaround for it has been incorporated in the formatter.
The corresponding test TestDataFormatterStdMap has also been enabled
for GCC.
Test Plan: dotest.py -C <clang|gcc> -p TestDataFormatterStdMap
Reviewers: clayborg, vharron, granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8424
llvm-svn: 232678
Summary:
The existing formatter in C++ has been removed as it was not being used.
The associated test TestDataFormatterStdVBool.py has been enabled for
both Clang and GCC on Linux.
Test Plan: dotest.py -p TestDataFormatterStdVBool
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8390
llvm-svn: 232548
- 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
- If there is only 1 frame ptr_refs now works (fixed issue with stack detection)
- Fixed test for result now that it isn't a pointer anymore
llvm-svn: 198712
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
- specify the architecture
- specify the platform
- specify if only external symbols should be dumped
- specify if types in the function signatures should be canonicalized
llvm-svn: 183961
Improved the makefile "clean" to include deleting all ".d.[0-9]+" files.
Added options to the "lldb/examples/lookup" example and made it build using the LLDB_BUILD_DIR. If this is not set, it will default to "/Applications/Xcode.app/Contents/SharedFrameworks" on Darwin.
Added options to the "lldb/examples/function" example and made it build using the LLDB_BUILD_DIR.
llvm-svn: 183949
This example shows someone could iterate over all functions and do something intelligent with them, like create function signatures. Then two different builds could be compared to verify the API hasn't changed.
llvm-svn: 183923
Jason Molenda