Hi,<div><br></div><div>Some more questions. When does the 'm_remote_platform_sp' member in PlatformDarwin get assigned? It seems to me that the SP's contents will always be NULL and the remote-macosx platform will never resolve an executable (in <span class="s1">PlatformDarwin</span>::ResolveExecutable). Shouldn't the remote part of the platform, when m_remote_platform_sp is NULL, resolve the executable using the --sysroot option?</div>
<div><br></div><div>Regards,</div><div><br></div><div>  Filipe</div>







<div><br></div><div><br>










<br><div class="gmail_quote">On Thu, Aug 25, 2011 at 18:25, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com">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 class="im"><br>
On Aug 25, 2011, at 5:52 PM, Filipe Cabecinhas wrote:<br>
<br>
> 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?<br>

<br>
</div>If you are debugging a remote macosx machine, then use "remote-macosx". If it is anything else, then select "remote-gdb-server". Why? Becuase the platform for "remote-macosx" does know how to do "MacOSX" type things like how to resolve a bundle executable in case you say:<br>

<br>
(lldb) file /Volumes/machine1/Applications/TextEdit.app<br>
<br>
If you use the "remote-gdb-server" it won't know any of the macosx specifics.<br>
<div class="im"><br>
><br>
> I managed to run the program with both, but where is the difference between them?<br>
<br>
</div>See above and go look at the functions that are available in the Platform.h file to see what the platform does different for MacOSX.<br>
<div class="im"><br>
<br>
> Or is it the same because you've wired the macosx-host platform to just start a remote-gdb-server?<br>
<br>
</div>"remote-macosx" uses the GDB server platform since that is how we chose to implement it, though if a remote platform decided to implement all of the new LLDB platform GDB server packets, the debug session could do something totally different depending on what you attached to.<br>

<div class="im"><br>
> ><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>
> None of these should really be ifdefed out, they should be being compiled on all platforms, excluding any "native only" plug-ins.<br>
><br>
> So, in the future, lldb.cpp will simply run all that code, except for some of the Platform (and Process?) plugins?<br>
<br>
</div>Only the ones that do native debugging like the linux plug-in. So now linux debugging will behave very differently if it is locally debugged, versus remotely since LLDB has a native linux plug-in that will only compile and run on linux. On MacOSX, we always use debugserver, so this decouples us from having this issue.<br>

<div class="im"><br>
> 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).<br>
<br>
</div>Any plug-in that can support remote debugging should be compiled in, and should try to not include native header files that are only on the remote system.<br>
<div class="im"><br>
><br>
> 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.<br>

<br>
</div>If you launch a GDB on linux and type:<br>
<br>
(gdb) maintenance print raw-registers<br>
<br>
It will give you a good idea of what registers are expected and you could make LLDB have a hard coded set of registers for "i386-pc-linux" (or whatever the linux target triple is) and then just run the native Linux GDB server. Or write a new GDB server on linux that uses the code from the ProcessLinux.cpp.<br>

<font color="#888888"><br>
Greg<br>
<br>
</font></blockquote></div><br></div>