hanchenye-llvm-project/lldb/scripts
Greg Clayton ef8180a3f6 <rdar://problem/14972424>
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
2013-10-15 00:14:28 +00:00
..
Python <rdar://problem/14972424> 2013-10-15 00:14:28 +00:00
CMakeLists.txt Remove the windows CR 2013-06-13 16:05:41 +00:00
build-lldb-llvm-clang <rdar://problem/10507811> 2012-01-04 22:56:43 +00:00
build-llvm.pl Changed LLVM configure options to reflect the new 2013-08-13 18:11:20 +00:00
build-swig-wrapper-classes.sh Linux buildbot fix: detect swig tool from PATH in shell script (before searching hardcoded directories) 2012-11-28 23:49:11 +00:00
buildbot.py Added a buildbot script that automatically checks 2011-10-14 21:43:51 +00:00
checkpoint-llvm.pl Updated LLVM/Clang to pick up a fix for imports of 2011-11-04 22:46:46 +00:00
disasm-gdb-remote.pl Fixed register dumping for contained-regs. 2013-02-01 00:45:52 +00:00
finish-swig-wrapper-classes.sh Makefile patches from Charles Davis and Daniel Malea (+ one or two tweaks). 2012-11-01 18:55:16 +00:00
generate-vers.pl Updated Apple LLDB version to lldb-300.99.0. Also 2013-03-07 22:29:06 +00:00
install-lldb.sh
lldb.swig Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files). 2013-07-08 22:22:41 +00:00
lldb_python_module.cmake Fix CMake install target 2013-05-17 20:55:19 +00:00
sed-sources
verify_api.py Added the ability to verify the LLDB API on MacOSX using a script. Usage is: 2012-08-30 21:21:24 +00:00