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

Todd Fiala todd.fiala at gmail.com
Thu Jun 26 08:04:05 PDT 2014


(And yes, it does make for a long exe name!)


On Thu, Jun 26, 2014 at 8:02 AM, Todd Fiala <todd.fiala at gmail.com> wrote:

> 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
> right.
>
> 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!
>
> -Todd
>
>
> 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
>>>
>>>
>>
>
>
> --
> -Todd
>



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


More information about the lldb-dev mailing list