<div dir="ltr">Hi all,<div><br></div><div>Revision 212069 in the <a href="http://llvm.org">llvm.org</a> lldb trunk brings in lldb-gdbserver to lldb TOT.</div><div><br></div><div>Here is the abbreviated FAQ on lldb-gdbserver:</div>
<div><br></div><div>WHAT IS IT?</div><div><br></div><div>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.</div>
<div><br></div><div>WHAT PLATFORMS DOES IT SUPPORT?</div><div><br></div><div>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).</div>
<div><br></div><div>WHY DIDN'T YOU JUST USE DEBUGSERVER?</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>DOES LLDB-PLATFORM SUPPORT LLDB-GDBSERVER?</div><div><br></div><div>Not yet.  Coming very soon.</div><div><br></div><div>HOW DO I USE IT?</div><div><br></div><div>You can fire up a lldb-gdbserver instance on a system similar to the instructions for debugserver:</div>
<div><br></div><div>remote-system $ lldb-gdbserver host-system:5432</div><div><br></div><div>host-system $ lldb -- /bin/ls</div><div>(lldb) gdb-remote remote-system:5432</div><div>(lldb) run</div><div><br></div><div>You can also attach by process id (pid), or have lldb-gdbserver launch the process.</div>
<div><br></div><div>IS IT READY FOR PRIMETIME?</div><div><br></div><div>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.</div>
<div><br></div><div>WHAT WORKS?</div><div><br></div><div>I've been able to do the following:</div><div><ul><li>Start/stop processes.</li><li>Use breakpoints.</li><li>Evaluate expressions.</li><li>Observe program exits, kill processes, etc.</li>
</ul><div>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.</div>
<div><br></div><div>HOW DO I FILE A BUG?</div><div><br></div><div>File at <a href="http://llvm.org">llvm.org</a>'s bugzilla.  Tag them with the lldb project and include "llgs" or "lldb-gdbserver" in the subject.</div>
</div><div><br></div><div>HOW ABOUT OTHER PLATFORMS?</div><div><br></div><div>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.</div>
<div><br></div><div>CAN WE CONNECT TO LLGS WITH OTHER LLDB PLATFORMS OR IDEs?</div><div><br></div><div>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.</div>
<div><br></div><div>WHAT'S NEXT?</div><div><ul><li>lldb-platform support for Linux x86_64.</li><li>More Linux platforms.</li><li>Android support.</li><li>Bug fixes.</li></ul><div>Thanks, all!</div></div><div><br></div>
<div>Sincerely,</div><div>Todd Fiala</div><div><div><br></div>
</div></div>