Hi,<div><br><br><div class="gmail_quote">On Thu, Sep 1, 2011 at 14:17, 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 style="word-wrap:break-word"><br><div><div><div>On Sep 1, 2011, at 1:52 PM, Filipe Cabecinhas wrote:</div><br><blockquote type="cite">Hi,<br><br><div class="gmail_quote">On Thu, Sep 1, 2011 at 12:21, 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">
PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.<br>
<div><div></div><div><br></div></div></blockquote><div><br></div><div>Yes, but the other two platforms never assign to m_remote_platform_sp. Only PlatformDarwin::ConnectRemote() does. And this won't get called when issuing a 'platform select' + 'process connect'.</div>

</div></blockquote><div><br></div></div>Correct. "process connect" connects you to a debugserver that is already debugging, or will debug a single process. The "platform connect" connects you to a platform which can then spawn new debugserver instances and let you connect to them.</div>

</div></blockquote><div><br></div><div>Ok, I managed to do that and connect to a platform that spawns debugservers. That way, if I'm just in lldb-land and use the platform, everything is ok.</div><div><br></div><div>
The problem is: imagine I have a gdbserver (let's use debugserver as an example, which implements that part of the communication), but not an lldb-platform.</div>
<div>I should be able to select a platform and 'process connect' to that debugserver. The problem is that the executable modules won't get set (and I can't find a way to set them). That way, the DYLD plugin won't get loaded (in <span class="s1">Process</span>::CompleteAttach), and I won't be able to see any symbols nor set breakpoints symbolically. In short, I would be debugging assembly with no symbols (fun :-) ). 'image add' won't help either (it will say it can break on some symbols, but won't stop when it gets there.</div>








<div><br></div><div>One way to fix this is to allow 'target create' (or another command) to tell the debugger which executable file we're using. That way, we could make it the executable image and then call CompleteAttach (or redo some of the steps) in order to get everything working (including the DYLD plugin). Is this a good way to do that? Or do you prefer to just have lldb talk to itself (and lldb-platform)?</div>
<div><br></div><div>One more question (from the last email) about another way we could do this:</div><div><br></div><div><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">On Thu, Aug 25, 2011 at 15:32, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank" style="color: rgb(17, 85, 204); ">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div><div class="im" style="color: rgb(80, 0, 80); "><br>On Aug 24, 2011, at 6:11 PM, Filipe Cabecinhas wrote:<br><br>> Hi,<br>><br></div><div class="im" style="color: rgb(80, 0, 80); ">> 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></div><div class="im" style="color: rgb(80, 0, 80); ">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></div></blockquote><div><br></div><div>The problem is: what can you do? In my testing I couldn't (with platform remote-macosx and sysroot=/) find out anything about the program. I could only do a process continue, and not much more. I couldn't set breakpoints, I couldn't see the source, etc. Is this simply not in place?</div>
<div><br></div><div>My problem with adding this is that AFAICT, I can't know the remote system path for the file currently being debugged, using the gdb remote protocol (if I could, the process could set the correct target when connecting to the debugserver). target create also doesn't allow me to say which program is being debugged because it wants a connected platform. target modules add will load information about the module, but not allow me to set breakpoints. Since we don't have a target, the MacOSX DYLD plugin won't get called when additional modules are loaded.</div>
<div><br></div><div>Since MacOSX is using the remote plugin for all debugging purposes it seems we only need to allow the MacOSX plugins to be used when using platform remote-macosx, as well as resolving the remote paths whenever asked. Is this right?</div>
<div><br></div><div>So, should we somehow get the path to the executable from the debugserver? Should we allow the user to do a target create … and use that file? Should 'process connect' receive an additional argument for the executable?</div>
</span></div><div><br></div><div>Thanks for the help,</div><div><br></div><div>  Filipe</div><div><br></div></div></div>