gdb-remote incompatibility with gdbserver?

My apologizes if this is mentioned somewhere already, couldn't find
anything on the subject; it seems that gdb-remote doesn't work very
well (or at all in my tests) with gdbserver.

Tim Hammerquist was also able to reproduce issues when attempting to
use gdb-remote with gdbserver. (Test with freebsd/gdbserver,
freebsd/lldb38, freebsd/gdbserver, and macos/lldb-900.0.57.)

Could we document this somewhere? It's not a large issue since there's
alternatives like lldb-server and Facebook's ds2, but it's a bit
confusing to new users who fairly expect a command called "gdb-remote"
to work with gdbserver.

root@17e840390f4d:~# lldb-3.8 date
(lldb) target create "date"
Current executable set to 'date' (x86_64).
(lldb) # In another terminal: gdbserver localhost:4444 /tmp/date
(lldb) gdb-remote localhost:4444
Process 6593 stopped
* thread #1: tid = 6593, stop reason = signal SIGTRAP
    frame #0: 0xffffffffffffffff
(lldb) c
Process 6593 resuming
Process 6593 stopped
* thread #1: tid = 6593, stop reason = signal SIGTRAP
    frame #0: 0xffffffffffffffff
(lldb) c
Process 6593 resuming
Process 6593 stopped
* thread #1: tid = 6593, stop reason = signal SIGSEGV
    frame #0: 0xffffffffffffffff
(lldb) c
Process 6593 resuming
Process 6593 exited with status = 11 (0x0000000b)


David Manouchehri

lldb doesn't know what register set exists - if you do 'register read' you'll see that there are no registers. Maybe gdbserver doesn't implement the target.xml request (it's their packet definition! c'mon!)

Download the x86_64 target def file from

and load it in your .lldbinit file or on the cmd line

lldb -O 'settings set /path/to/'

Thanks, that did the trick! Should I add this information to and submit a
review on Phabricator?

root@13bfa9bdf1e7:/# lldb-5.0 /bin/date
(lldb) target create "/bin/date"
Current executable set to '/bin/date' (x86_64).
(lldb) settings set
(lldb) gdb-remote localhost:4444
(lldb) Process 5221 stopped
* thread #1, stop reason = signal SIGTRAP
    frame #0: 0x00002aaaaaaabc30
-> 0x2aaaaaaabc30: movq %rsp, %rdi
    0x2aaaaaaabc33: callq 0x2aaaaaaac9b0
    0x2aaaaaaabc38: movq %rax, %r12
    0x2aaaaaaabc3b: movl 0x225037(%rip), %eax

For those who run into this message in the future, here's the exact
commands I ran to get gdbserver working:

wget -O - | sudo apt-key add -
sudo apt-add-repository "deb Index of /xenial/
llvm-toolchain-xenial-5.0 main"
sudo apt-get update
sudo apt-get -y install lldb-5.0 gdbserver
# In another terminal run: gdbserver localhost:4444 /bin/date
lldb-5.0 /bin/date
settings set
gdb-remote localhost:4444

LLDB should be changed to error out if we don't get any register information from the remote GDB server and have the error message tell us that we need to add register definition file. Then this would be clear. Maybe a message like:

error: GDB server doesn't vend register information. You must specify a register definition file with "settings set /path/to/"

Though it does seem to be a bug that the "gdbserver" you were using doesn't support the Target XML packets that the GDB remote protocol defines? Is this some old version of GDB remote from many many years ago? Seems any recent gdbserver should have this feature?


I was/am running gdbserver 7.11.1 (Ubuntu 7.11.1-0ubuntu1~16.5).

Interesting! So would we add xmlRegisters=i386 to qSupported for i386 and xmlRegisters=x86_64 for x86_64? We should have LLDB send this down to the server then and everything would just work?


Is there a user accessible setting to force on XML target descriptions
in new-gdbsever?

It's "xmlRegisters=i386" for both 32-bit/64-bit.

I don't know whether that's all you're missing.

I should qualify "doesn't send back" better. To be more accurate,
without "xmlRegisters=i386" gdbserver still reports back a XML description in
response to "qXfer:features:read:target.xml". But, that description matches the
register file/layout that predated x86 XML target descriptions. GDB still connects
and debugs fine in that case (just tried it on x86_64), but the problem will be
that that description (and the resulting g/G packet layout) doesn't include all
the new registers that have been added over the years (SSE, etc.).

So sounds like there may be more to it.

Pedro Alves

In gdbserver? Nope.

There's a setting in GDB to force it to not fetch descriptions,
which I found out today didn't actually work. Fixed now in master [1].
GDB works fine against gdbserver with XML force-disabled, so

I suspect something else is going on.

Maybe a disagreement about who adjusts the PC after a breakpoint trap
between lldb and gdbserver? (given the spurious SIGTRAPs and SIGSEGVs)
gdb and gdbserver negotiate that via qSupported. If both agree on
the "swbreak+" feature, then gdbserver handles it (and reports a "T05 swbreak"
for int3 traps). Otherwise gdbserver assumes that the client (gdb/lldb) will,
so doesn't do it itself. I did a quick grep on a lldb checkout I had
around here and didn't find any "swbreak" hit, but maybe lldb assumes
the server does it?

Really just guessing though.

[1] Pedro Alves - [pushed] remote: Make qXfer packets respect corresponding "set remote fo

Pedro Alves

I think that could be (a part of) the problem. lldb-server always
adjusts the PC (see NativeProcessLinux::FixupBreakpointPCsAsNeeded). I
am unsure whether there is any additional fixup logic in the client.

Does ds2 have the same behavior? Took a glance and didn’t see it.