[lldb-dev] lldb-gdbserver (Linux x86_64) is coming soon!
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
> 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>
>> 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
>>> - 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
>>> - 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.
>>> Todd Fiala
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev