[lldb-dev] Increasing support for other gdbservers

[Aidan Dodds]

On 30/03/2015 14:13, Gary Benson wrote:
> Greg Clayton wrote:
>>> On Mar 27, 2015, at 4:33 AM, Aidan Dodds <aidan at codeplay.com> wrote:
>>> 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.
> Not true.  Any version of GDB can work with anything that implements
> the protocol.  Each side indicates to the other the features it
> supports, and both sides are abide by the limitations of the other.
>
>> 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.
> Any version of GDB can talk to anything that implements the protocol.
> You can run GDB on S/390 Linux and connect to a gdbserver running on
> Windows.  Or vice versa.  The remote side sends all these details to
> GDB on request.  Don't believe me?  Try a simple case with protocol
> debugging switched on and watch what goes over the wire:
>
>    bash$ gdb /bin/ls
>    (gdb) set debug remote 1
>    (gdb) target remote | gdbserver - /bin/ls
>    
> You'll see something like this:
>
>    Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;xmlRegisters=i386;qRelocInsn+#54
>    Packet received: PacketSize=3fff;QPassSignals+;QProgramSignals+;qXfer:libraries-svr4:read+;augmented-libraries-svr4-read+;qXfer:auxv:read+;qXfer:spu:read+;qXfer:spu:write+;qXfer:siginfo:read+;qXfer:siginfo:write+;qXfer:features:read+;QStartNoAckMode+;qXfer:osdata:read+;multiprocess+;QNonStop+;QDisableRandomization+;qXfer:threads:read+;ConditionalTracepoints+;TraceStateVariables+;TracepointSource+;DisconnectedTracing+;FastTracepoints+;StaticTracepoints+;InstallInTrace+;qXfer:statictrace:read+;qXfer:traceframe-info:read+;EnableDisableTracepoints+;QTBuffer:size+;tracenz+;ConditionalBreakpoints+;BreakpointCommands+;QAgent+;swbreak+;hwbreak+
>
> That's both sides informing the other what protocol features they
> support.  A little further down you'll see something like this:
>
>    Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2015 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!-- AMD64 with AVX - Includes Linux-only special "register".  -->\n\n<!DOCTYPE target SYSTEM "gdb-target.dtd">\n<target>\n  <architecture>i386:x86-64</architecture>\n  <osabi>GNU/Linux</osabi>\n  <xi:include href="64bit-core.xml"/>\n  <xi:include href="64bit-sse.xml"/>\n  <xi:include href="64bit-linux.xml"/>\n  <xi:include href="64bit-avx.xml"/>\n</target>\n
>    Sending packet: $qXfer:features:read:64bit-core.xml:0,fff#75...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2010-2015 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.i386.core">\n  <flags id="i386_eflags" size="4">\n    <field name="CF" start="0" end="0"/>\n    <field name="" start="1" end="1"/>\n    <field name="PF" start="2" end="2"/>\n    <field name="AF" start="4" end="4"/>\n    <field name="ZF" start="6" end="6"/>\n    <field name="SF" start="7" end="7"/>\n    <field name="TF" start="8" end="8"/>\n    <field name="IF" start="9" end="9"/>\n    <field name="DF" start="10" end="10"/>\n    <field name="OF" start="11" end="11"/>\n    <field name="NT" start="14" end="14"/>\n    <field name="RF" start="16" end="16"/>\n    <field name="VM" start="17" end="17"/>\n    <field name="AC" start="18" end="18"/>\n    <field name="VIF" start="19" end="19"/>\n    <field name="VIP" start="20" end="20"/>\n    <field name="ID" start="21" end="21"/>\n  </flags>\n\n  <reg name="rax" bitsize="64" type="int64"/>\n  <reg name="rbx" bitsize="64" type="int64"/>\n  <reg name="rcx" bitsize="64" type="int64"/>\n  <reg name="rdx" bitsize="64" type="int64"/>...
>
> Is something you are talking about not right there?

Yes I was going to point this out also.  A lot of information can be 
obtained through the $qXfer: packets, such as register mappings via 
$qXfer:features:read:target.xml and associated .xml's that LLDB
currently doesn't make use of.  Support for these types of features 
could bring gdbserver compatibility a long way, avoiding pre-canned 
compatibility scripts.

The reasons for originally asking is that we have had to add various 
degrees of gdbserver compatibility to lldb a number of times and it is 
something that really should be well supported upstream.  The problem is 
doing it in such a way that fits nicely alongside existing plugins.