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.
NativeProtocol classes allow us to move towards supporting an OS/Architecture in one place (in the OS/Architecture-specific NativeProtocol 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