On 30/03/2015 14:13, Gary Benson 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"!
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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
