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

[Zachary Turner]

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/20140625/f547057a/attachment.html>