I think that's because It uses the GDB debugger protocol and so it should be possible to use it as a replacement for gdbserver.
That said, I don't know if that kind of configuration is supported yet or if it depends on the GDB protocol extensions introduced by LLDB. Le 26 juin 2014 à 06:03, Zachary Turner <[email protected]> a écrit : > 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 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 > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
