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