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

[Todd Fiala]

First rev of build fixes in for Windows.  Thanks to Zachary Turner for help.

tfiala-macbookpro:lldb tfiala$ svn commit
Sending        lldb.xcodeproj/project.pbxproj
Sending        source/Plugins/Process/Linux/CMakeLists.txt
Adding
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
Adding
source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
Sending        source/Plugins/Process/Linux/NativeThreadLinux.cpp
Sending        source/Plugins/Process/Utility/CMakeLists.txt
Sending        source/Plugins/Process/Utility/LinuxSignals.cpp
Deleting
source/Plugins/Process/Utility/NativeRegisterContextLinux_x86_64.cpp
Deleting
source/Plugins/Process/Utility/NativeRegisterContextLinux_x86_64.h
Sending
 source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
Sending        source/Target/ProcessLaunchInfo.cpp
Transmitting file data .......
Committed revision 212074.


On Mon, Jun 30, 2014 at 4:56 PM, Todd Fiala <todd.fiala at gmail.com> wrote:

> Changes coming in shortly...
>
>
> On Mon, Jun 30, 2014 at 4:13 PM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Looks like this introduced a build break on Windows. We're working to fix
>> that up now.
>>
>> -Todd
>>
>> On Jun 30, 2014, at 3:03 PM, Todd Fiala <todd.fiala at gmail.com> wrote:
>>
>> 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
>>
>>
>
>
> --
> -Todd
>



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