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 <gben...@redhat.com> wrote:
> 
> Greg Clayton wrote:
>>> On Mar 27, 2015, at 4:33 AM, Aidan Dodds <ai...@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" e!
 nd="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/


_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to