[lldb-dev] lldb-gdbserver (Linux x86_64) is coming soon!

Todd Fiala todd.fiala at gmail.com
Thu Jun 26 08:02:53 PDT 2014

Hi Zachary,

Great question.  Way back in December when Greg Clayton and I talked about
it (this very thing, in fact), we decided it was proper to pay homage to
gdbserver since:
1. It is using the gdb-remote protocol as initially spec'd out by gdb, and
2. It is lldb's internal version of a server running the gdb-remote
protocol, and thus is a gdbserver of sorts.

It does run on the gdb-remote protocol.  It does support many of the
debugserver extensions, and will eventually support them all.  Greg intends
to move Apple over from debugserver to lldb-gdbserver when the timing is

I have not tried to ensure that lldb-gdbserver can drop in for gdbserver
with other clients (e.g. gdb).  However, I have been testing lldb-gdbserver
(we're calling it llgs for short) at the protocol level along with
debugserver, and I have fixed up a couple places where we were not obeying
the gdb-remote protocol spec.  Also, I have been fixing up lldb where it
fails to work with llgs when llgs was implementing the spec but didn't have
every single feature of debugserver.  So it is likely we're also improving
our compliance with the gdb-remote spec, FWIW.

Hope that helps!


On Wed, Jun 25, 2014 at 9:03 PM, Zachary Turner <zturner at google.com> wrote:

> Forgive the potentially noobish question, as I have little to no
> experience with GDB, but why is this called lldb-gdbserver?  Why isn't it
> just called lldb-server?  The name makes it sounds like lldb-gdbserver
> doesn't apply to you if you have no interest in interfacing with GDB.  Is
> that accurate or inaccurate?
> On Wed, Jun 25, 2014 at 1:41 PM, Todd Fiala <todd.fiala at gmail.com> wrote:
>> Hi all,
>> I'm targeting getting the lldb-gdbserver (llgs) branch upstreamed into
>> the lldb svn trunk by June 30th 2014 (next Monday).
>> The current state of the branch:
>>    - lldb-gdbserver is essentially working for Linux x86_64 targets.
>>    - Breakpoints, code correlation, backtraces, expression execution in
>>    inferior memory all work in simple test scenarios.
>>    - It touches minimal code from the existing branch, although it does
>>    share a fair amount of code with lldb-platform, particularly in
>>    GDBRemoteCommunicationServer.
>>    - lldb-platform for linux x86_64 is not yet implemented.  I'll be
>>    doing that shortly after upstreaming so we can run the remote test suite
>>    against lldb and llgs running remotely.
>>    - I've done some work to support loading elf files for other
>>    platforms on a given host.  (e.g. command-line MacOSX lldb connecting to
>>    Linux x86_64 llgs somewhat works, as should FreeBSD lldb over to Linux
>>    x86_64.)  I added off-host elf support for Linux, FreeBSD and NetBSD elf
>>    files if they have known elf note sections to identify or use the OSABI
>>    byte in the elf header and are loaded on a system different than the target
>>    ABI system.
>>    - I've added a host of gdb-remote-protocol tests to
>>    test/tools/lldb-gdbserver.  These run tests against debugserver and llgs.
>>     I used them to ensure that llgs was behaving identically at the gdb-remote
>>    protocol level to debugserver.  I upstreamed the vast majority of these
>>    already - they're marked XFAIL for llgs.  Those are all implemented in the
>>    llgs branch and passing.
>> I'm doing a minimal set of tasks to complete the branch to the point of
>> upstreaming:
>>    - Removing dead code.  I did borrow a fair amount of code from
>>    RegisterContext* and the Linux ProcessMonitor, but in some cases there is
>>    more code there than needed.
>>    - Run through the FIXME comments to see if anything super egregious
>>    should be fixed before upstreaming.
>> If you are interested in testing llgs on a linux_x86_64 host and target,
>> please have at it.  The llgs branch is located here
>> <https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64> on
>> github. File any issues you hit on the llvm.org bugzilla.  At this point
>> I'm looking to get it in sooner than later, since more recent activity in
>> lldb has been causing merging pains and the vast majority of the llgs code
>> paths don't intersect with local debugging paths (yet).
>>  I appreciate any and all feedback on it.  After the Linux x86_64 support
>> is ironed out, I plan to get a few other Linux architectures working, and
>> (ultimately) getting the Android llgs working so we can debug Android
>> devices with LLDB.
>> Thanks!
>> Sincerely,
>> Todd Fiala
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140626/9f5bcadd/attachment.html>

More information about the lldb-dev mailing list