Hi,<div><br></div><div>Thanks for your reply. It's nice to know that I was on the right path :-)</div><div><br></div><div>But I still have some questions:</div><div><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 15:32, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On Aug 24, 2011, at 6:11 PM, Filipe Cabecinhas wrote:<br>
<br>
> Hi,<br>
><br>
> I'm trying to do remote debugging with lldb, but I keep running into problems.<br>
><br>
> How should I do it?<br>
><br>
> I tried running "debugserver localhost:42000" and then, on the lldb client:<br>
><br>
> platform select (remote-macosx | remote-gdb-server?) + platform connect?<br>
> platform select … + process connect?<br>
<br>
</div>The platform stuff is still a work in progress which we hope to really perfect over the next year. If you are doing Mac to Mac debugging the best thing to do right now is:<br>
<br>
AFP mount the root drive on the other machine. For these examples lets suppose we have machine1 and machine2. So the flow would be:<br>
<br>
- machine1: start debugserver:<br>
machine1 % debugserver localhost:12345 /bin/ls<br>
<br>
- machine2: mount the root drive from machine2 and launch lldb:<br>
machine2 % ./lldb<br>
(lldb) platform select remote-macosx --sysroot /Volumes/machine1<br>
(lldb) process connect connect://machine1:12345<br>
<br>
This should do it. Currently the platforms don't do any file copying from one to the other, so you will need a copy of all executables and shared libraries to exist within the "Volumes/machine1" directory. So if you are running "/bin/ls" it should be available through your mount at: "/Volumes/machine1/bin/ls". Likewise for all shared libraries.<br>
<div><br></div></blockquote><div><br></div><div>Is the remote-macosx platform the one to choose in order to have more information about the program? Or could I also choose the remote-gdb-server platform (which seems more generic)? Is there some code that "isn't there yet" on the remote-gdb-server?</div>
<div><br></div><div>I managed to run the program with both, but where is the difference between them? Or is it the same because you've wired the macosx-host platform to just start a remote-gdb-server?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>><br>
> I would suppose you need the plugins for the combinations you want to use, but with the gdb-remote stuff, I'm getting confused.<br>
><br>
> In lldb_private::Initialize(), we initialize several plugins, depending on the operating system. I'm supposing the DynamicLoader and Process plugins (along with some others) are only needed when running as host, otherwise, we couldn't, on Linux, debug a FreeBSD or Mac OS X target (since their initialization gets ifdeffed out).<br>
><br>
<br>
</div>None of these should really be ifdefed out, they should be being compiled on all platforms, excluding any "native only" plug-ins.<br></blockquote><div><br></div><div>So, in the future, lldb.cpp will simply run all that code, except for some of the Platform (and Process?) plugins? I'm supposing it's most of them, since many depend on the debuggee, and not the platform where lldb is running (just the remote server).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> I saw that, on Mac OS X, lldb spawns a debugserver that runs the program and they communicate using the plugin ProcessGDBRemote (another question: Why is that plug-in only started on Mac OS X? It has to run on the host, but otherwise I didn't see much platform-specific stuff (I just skimmed the file)). Shouldn't that Process plugin be also used with a PlatformRemoteGDBServer?<br>
><br>
</div>The platform (currently on MacOSX built as the "lldb-platform" executable) can currently do the job of being launched on a remote host and it can spawn a new debugserver in order to debug a process on the host, list processes, attach to existing process and do much more. All the code that the "lldb-platform" uses if from the "lldb_private::Host" API layer, so it completely reuses the host code that can launch processes for debugging, and much more.<br>
<br>
The ideal platform looking forward would:<br>
- be a binary that runs natively on the remote machine that hopefully can be automatically launched when the remote host is contacted on a port. On MacOSX, we can add a launchd plist entry that would automatically launch "lldb-platform" (or any equivalent) when the remote host is contacted on a fixed port number.<br>
- upload and download files from the platform and cache them locally (currently we require all files to be there already in the "--sysroot" for the platform)<br>
- list and query info for existing processes (lldb-platform can already do this)<br>
- launch a process whose executable exists on the remote host (possibly just updloaded via the platform) with any args required. This would spawn the process under a debugserver and return the port needed to connect.<br>
- attach to an existing process (spawn a debugserver that will attach, an return the port number across the platform protocol)<br>
<br>
So much of this works right now. You can try out the "lldb-platform" binary with the current build and pretend to debug remotely:<br>
<br>
<br>
% ./lldb-platform --listen 1444<br>
Listening for a connection on 1444...<br>
<br>
<br>
<br>
Then launch lldb and connect:<br>
<br>
% ./lldb<br>
(lldb) platform select remote-macosx<br>
Platform: remote-macosx<br>
Connected: no<br>
(lldb) platform connect connect://localhost:1444<br>
Platform: remote-macosx<br>
Triple: x86_64-apple-darwin<br>
OS Version: 10.7.1<br>
Kernel: Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64<br>
Hostname: <a href="http://myhost.apple.com" target="_blank">myhost.apple.com</a><br>
Connected: yes<br>
(lldb) platform process list<br>
40 matching processes were found on "<a href="http://myhost.apple.com" target="_blank">myhost.apple.com</a>"<br>
PID PARENT USER ARCH NAME<br>
====== ====== ========== ======= ============================<br>
46384 46139 gclayton x86_64 lldb<br>
.....<br>
(lldb)<br>
<br>
<br>
There is much work to do, but there is a lot of support already in place to get remote debugging started.<br>
<br>
Let me know if you have any questions.<br>
<font color="#888888"><br>
Greg Clayton<br>
<br>
</font></blockquote></div><br></div><div>I'll check some stuff with Linux and gdbserver and may have some more questions afterwards. I managed to do some "remote" debugging with lldb, with your help, which is one step closer to what I wanted.</div>
<div><br></div><div>Thanks,</div><div><br></div><div> Filipe</div><div><br></div>