[lldb-dev] lldb-gdbserver (llgs) is here! Light FAQ.

[Todd Fiala]

Hi all,

Revision 212069 in the llvm.org lldb trunk brings in lldb-gdbserver to lldb
TOT.

Here is the abbreviated FAQ on lldb-gdbserver:

WHAT IS IT?

lldb-gdbserver is intended to be a drop-in replacement for debugserver on
platforms that support it.  It supports debugging an executable running on
a remote machine.  It is the portion that runs on the remote machine,
talking to an lldb client running on a local machine.

WHAT PLATFORMS DOES IT SUPPORT?

Currently it supports Linux x86_64 running llgs on the remote end, and has
only been tested officially when run from an lldb running on Linux x86_64.
 (This will change in the future, but we're taking it one step at a time).

WHY DIDN'T YOU JUST USE DEBUGSERVER?

After some discussion with Greg Clayton, we decided it would be easier to
create an lldb-gdbserver piece that runs off a new abstraction called
NativeProcessProtocol (with NativeThreadProtocol and
NativeRegisterContext).  The existing debugserver code was also heavily
dependent on MacOS/iOS-specific constructs, and we were looking to move
towards a more platform-neutral code base.

Native*Protocol classes allow us to move towards supporting an
OS/Architecture in one place (in the OS/Architecture-specific
Native*Protocol classes) and get remote/local debugging at the same time
without duplicating code.  We have follow-on steps that need to happen
before we can realize this goal - namely, we need to rework lldb's local
debugging to work in terms of the Native* classes.  For the short term,
we're looking to work the kinks out of those Native* classes using llgs.

DOES LLDB-PLATFORM SUPPORT LLDB-GDBSERVER?

Not yet.  Coming very soon.

HOW DO I USE IT?

You can fire up a lldb-gdbserver instance on a system similar to the
instructions for debugserver:

remote-system $ lldb-gdbserver host-system:5432

host-system $ lldb -- /bin/ls
(lldb) gdb-remote remote-system:5432
(lldb) run

You can also attach by process id (pid), or have lldb-gdbserver launch the
process.

IS IT READY FOR PRIMETIME?

It needs to pass the remote test suite at an acceptable level before it's
ready for heavy usage.  I'm going to get lldb-platform working next, a
pre-requisite for running the lldb test suite in remote mode.  I expect
this step will shake out a number of bugs we'll want to fix.  Any testing
you can give it and any bugs you file on incorrect behavior will be helpful.

WHAT WORKS?

I've been able to do the following:

   - Start/stop processes.
   - Use breakpoints.
   - Evaluate expressions.
   - Observe program exits, kill processes, etc.

There is likely to be a bunch of things that don't work - I'll fix them in
priority order as soon as we find them.  Please file any bugs you find
while using lldb-gdbserver when running on Linux x86_64 while using a Linux
x86_64 lldb as a client.

HOW DO I FILE A BUG?

File at llvm.org's bugzilla.  Tag them with the lldb project and include
"llgs" or "lldb-gdbserver" in the subject.

HOW ABOUT OTHER PLATFORMS?

Ed Maste is working on getting this running on FreeBSD.  Greg mentioned
Apple will look into moving over to lldb-gdbserver after we work the kinks
out of it and reach a reasonable level of compatibility with debugserver.

CAN WE CONNECT TO LLGS WITH OTHER LLDB PLATFORMS OR IDEs?

I've focused on Linux x86_64 llgs and lldb side.  I have started fixing
code that is broken when attempting to connect across OS/Architectures.
 Regarding IDEs and other debugger hosts for lldb, YMMV.  I am doing some
work there but nothing interesting to say yet.  We are definitely driving
to ensure an lldb on one architecture/OS can attach to an llgs of a
different architecture/OS.  Some of this work landed earlier last week.

WHAT'S NEXT?

   - lldb-platform support for Linux x86_64.
   - More Linux platforms.
   - Android support.
   - Bug fixes.

Thanks, all!

Sincerely,
Todd Fiala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140630/5f31a1ae/attachment.html>