(And yes, it does make for a long exe name!)
On Thu, Jun 26, 2014 at 8:02 AM, Todd Fiala <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> > > > -- > -Todd > -- -Todd
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
