<div dir="ltr"><div>First rev of build fixes in for Windows. Thanks to Zachary Turner for help.</div><div><br></div><div>tfiala-macbookpro:lldb tfiala$ svn commit</div><div>Sending lldb.xcodeproj/project.pbxproj<br>
</div><div>Sending source/Plugins/Process/Linux/CMakeLists.txt</div><div>Adding source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp</div>
<div>Adding source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h</div><div>Sending source/Plugins/Process/Linux/NativeThreadLinux.cpp</div><div>Sending source/Plugins/Process/Utility/CMakeLists.txt</div>
<div>Sending source/Plugins/Process/Utility/LinuxSignals.cpp</div><div>Deleting source/Plugins/Process/Utility/NativeRegisterContextLinux_x86_64.cpp</div><div>Deleting source/Plugins/Process/Utility/NativeRegisterContextLinux_x86_64.h</div>
<div>Sending source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp</div><div>Sending source/Target/ProcessLaunchInfo.cpp</div><div>Transmitting file data .......</div><div>Committed revision 212074.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 30, 2014 at 4:56 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Changes coming in shortly...</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On Mon, Jun 30, 2014 at 4:13 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Looks like this introduced a build break on Windows. We're working to fix that up now.<span><font color="#888888"><br>
<br>-Todd</font></span></div><div><div><div><br>On Jun 30, 2014, at 3:03 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<br><br></div><blockquote type="cite">
<div><div dir="ltr">Hi all,<div><br></div><div>Revision 212069 in the <a href="http://llvm.org" target="_blank">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" target="_blank">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>
</div></blockquote></div></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr">-Todd</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>