[lldb-dev] Increasing support for other gdbservers

[Greg Clayton]

> On Mar 27, 2015, at 4:33 AM, Aidan Dodds <aidan at codeplay.com> wrote:
> 
> Hi Folks,
> 
> I would like to add better support for gdbserver from the gnu toolchain and similar legacy gdb stubs in lldb.
> The work going into lldb-gdbserver is great but it is not always a possible to change the remote gdb stub, and there are so many tools and devices with older gdb stubs in them.
> 
> It seems like process gdb-remote has moved hand in hand with lldb-gdbserver away from gnu gdbservers RSP protocol.
> 
> Does anyone have an suggestions when it comes to adding lldb support for traditional gdbservers?
> 
> There seems like two obvious approaches; extend gdb-remote or create a gdb-legacy plugin.
> To my mind the second approach may be cleaner, and a large amount of common code could be shared between the two.
> 
> Another approach would be to incorporate a plugin system into gdb-remote to ease the addition of new packets and handling routines.
> 
> I am interested to hear thoughts, suggestions and feedback on this topic.

The problem is with GDB remote, the GDB and the GDB server must be built together and for each other. A single version of GDB is mated to a GDB server and things can't change. LLDB supports all architectures and any target, not just one at a time. And we certainly don't expect our GDB server binaries to always be in perfect sync with our LLDB. To get around this we added many packets to the GDB remote protocol to allow getting host info for what we are attaching to (triple, OS, vendor, etc), process info (architecture, pointer size, endian etc), register info (define all registers so that LLDB can dynamically figure out what registers are available and how they map to debug info and runtime info (register numbering mappings), and more.

We support GDB servers that don't support all the added LLDB specific packets by allowing users to specify a "target definition" python file in the settings:

(lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/target/defnition/foo.py

There are examples checked in:

svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_qemu_target_definition.py
svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py

Then when we connect to a GDB server that doesn't support the extra packets or the register definitions, we can fall back onto the currently selected target definition file. 

Typically what you want to start with is doing a:

(gdb) maint print raw-registers

In the GDB that supports hooking up to your GDB remote so you can see exactly what the register context should look like. You can then use this information to fill out a target definition file that you can use. If you do end up making any target definition files, please check the "examples/python" directory to make sure one doesn't already exists, and check it in with a very descriptive name so others can then use this. Feel free to add as many comments and you can in the python file to let people know what GDB server that your stuff will work with.

Let me know if you have any other questions.

Greg