[lldb-dev] 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: /tmp/date (lldb) gdb-remote localhost: Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGTRAP frame #0: 0x (lldb) c Process 6593 resuming Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGTRAP frame #0: 0x (lldb) c Process 6593 resuming Process 6593 stopped * thread #1: tid = 6593, stop reason = signal SIGSEGV frame #0: 0x (lldb) c Process 6593 resuming Process 6593 exited with status = 11 (0x000b) Thanks, David Manouchehri ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
Thanks, that did the trick! Should I add this information to https://llvm.org/viewvc/llvm-project/lldb/trunk/www/ 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 plugin.process.gdb-remote.target-definition-file ./x86_64_linux_target_definition.py (lldb) gdb-remote localhost: (lldb) Process 5221 stopped * thread #1, stop reason = signal SIGTRAP frame #0: 0x2aaabc30 -> 0x2aaabc30: movq %rsp, %rdi 0x2aaabc33: callq 0x2aaac9b0 0x2aaabc38: movq %rax, %r12 0x2aaabc3b: 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 - http://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add - sudo apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-5.0 main" sudo apt-get update sudo apt-get -y install lldb-5.0 gdbserver wget https://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py # In another terminal run: gdbserver localhost: /bin/date lldb-5.0 /bin/date settings set plugin.process.gdb-remote.target-definition-file ./x86_64_linux_target_definition.py gdb-remote localhost: ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
I was/am running gdbserver 7.11.1 (Ubuntu 7.11.1-0ubuntu1~16.5). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
Is there a user accessible setting to force on XML target descriptions in new-gdbsever? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
Does ds2 have the same behavior? Took a glance and didn't see it. On Dec 6, 2017 7:47 AM, "Pavel Labath" wrote: > On 6 December 2017 at 12:40, Pedro Alves via lldb-dev > wrote: > > On 12/05/2017 11:17 PM, David Manouchehri wrote: > >> Is there a user accessible setting to force on XML target descriptions > >> in new-gdbsever? > > > > 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? > > > > 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. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
