hanchenye-llvm-project/lldb
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
..
docs Remove added file for the test commit 2013-10-14 10:12:30 +00:00
examples <rdar://problem/14972424> 2013-10-15 00:14:28 +00:00
include <rdar://problem/14972424> 2013-10-15 00:14:28 +00:00
lib merge lldb-platform-work branch (and assorted fixes) into trunk 2013-08-26 23:57:52 +00:00
lldb.xcodeproj Removed the -t options from linking flags to avoid having the linker print out all .o files it was linking with. 2013-10-10 17:51:57 +00:00
lldb.xcworkspace Move the performance test cases into their own project. 2013-03-18 23:05:00 +00:00
resources Bump version number to 310.99.0. 2013-07-15 04:47:33 +00:00
scripts <rdar://problem/14972424> 2013-10-15 00:14:28 +00:00
source <rdar://problem/14972424> 2013-10-15 00:14:28 +00:00
test Expected FreeBSD failure due to pr 17430 2013-10-11 17:24:16 +00:00
tools Fix a few errors found when building lldb with newer versions of clang. 2013-10-05 02:52:22 +00:00
utils Add LLVM license headers to lldb ui frontend 2013-10-11 17:13:07 +00:00
www Tweak documentation for formats in categories 2013-10-08 21:07:22 +00:00
.arcconfig Adding .arcconfig file to LLDB to allow using Phabricator for reviews 2013-05-23 20:21:28 +00:00
.gitignore
CMakeLists.txt Convert to UNIX line endings. 2013-09-25 10:37:32 +00:00
INSTALL.txt Update INSTALL.txt to mention LLDB builds on Linux with GCC or Clang. 2013-02-21 22:37:18 +00:00
LICENSE.TXT
Makefile Respect SDKROOT in lldb Makefile 2013-09-18 16:32:28 +00:00