[lldb-dev] Increasing support for other gdbservers

[Greg Clayton]

So GDB now supports all architectures and all OS variants in a single binary? ARM + x86_64 + i386 + MIPs + PPC for linux, darwin, Windows etc? The last time I worked with GDB, which was pre GPLv3, each GDB was compiled for a specific architecture (or closely related architectures) and a single OS. This is what I meant about LLDB handling all architectures and OS variants from the same LLDB. If GDB has changed that much since I have last looked at it I am very happy to hear that.

I know about the register numbering stuff and I would love to see support for the "$qXfer:features:" added to LLDB. The one thing this data doesn't contain is the register numbers for the ABI (DWARF register numbers (for debug info), compiler register numbers (for like .eh_frame)), but that info could be inferred from an ABI plugin that we could infer from the "osabi" of "GNU/Linux" in the target.xml:

<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
  <architecture>i386:x86-64</architecture>
  <osabi>GNU/Linux</osabi>
  <xi:include href="64bit-core.xml"/>
  <xi:include href="64bit-sse.xml"/>
  <xi:include href="64bit-linux.xml"/>
  <xi:include href="64bit-avx.xml"/>
</target>

So please do submit patches that implement this and we will be happy to approve them.


> On Mar 30, 2015, at 6:13 AM, Gary Benson <gbenson at redhat.com> 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?
> 
> Cheers,
> Gary
> 
> -- 
> http://gbenson.net/