Hi,<div><br></div><div>Yes, PlatformRemoteiOS overrides the ResolveExecutable method. My suggestion is to apply the following patch to PlatformDarwin or override that same method on PlatformMacOSX and check for that special case.</div>
<div><br></div><div>If this patch is applied, the PlatformRemoteiOS::ResolveExecutable override doesn't seem to make sense anymore (modulus error messages). Please check if that is still needed (I can't even test on iOS devices ;-)).</div>
<div><br></div><div>Regards,</div><div><br></div><div>  Filipe</div><div><br><br><div class="gmail_quote">On Tue, Sep 6, 2011 at 13:43, 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 Sep 6, 2011, at 11:10 AM, Filipe Cabecinhas wrote:<br>
<br>
> Hi,<br>
><br>
> On Fri, Sep 2, 2011 at 19:03, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
><br>
> On Sep 2, 2011, at 2:04 PM, Filipe Cabecinhas wrote:<br>
><br>
> > 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)?<br>

><br>
> Exactly! You should be able to specify the local copy of the file you have. We will always check the UUIDs of the executable files you have loaded when dyld comes along. For instance, locally you have a binary "/tmp/a.out". Remotely this file is in "/usr/local/bin/a.out".<br>

><br>
> You can start lldb, set the platform, set the file and attach:<br>
><br>
> % lldb<br>
> (lldb) platform select ...<br>
> (lldb) target create /tmp/a.out<br>
> (lldb) process connect ....<br>
><br>
> Now when the dynamic loader plug-in gets info about a remote binary, it will say the path is at "/usr/local/bin/a.out", but we will notice that the UUID in the binary matches, so we don't care what the local path is.<br>

><br>
> LLDB currently really needs to have local copies of the files in order to debug. The architecture you select when you create the target really helps to specify which sets of plug-ins get loaded.<br>
><br>
>  But you can't do that right now. As of now, if you didn't "platform connect", m_remote_platform_sp is NULL. That way, you'll just get an error when issuing the "target create" command, because you can't resolve the executable (see PlatformDarwin.cpp:83).<br>

<br>
</div>I can currently do this just fine:<br>
<br>
<br>
(lldb) platform select remote-ios<br>
  Platform: remote-ios<br>
 Connected: no<br>
  SDK Path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2"<br>
(lldb) target create a.out<br>
Current executable set to 'a.out' (armv6).<br>
(lldb) image list<br>
[  0] /Volumes/work/gclayton/Documents/devb/attach/a.out<br>
[  1] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/dyld<br>
[  2] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libgcc_s.1.dylib<br>
[  3] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libSystem.B.dylib<br>
...<br>
<br>
Is this just not working for remote-macosx?<br>
<div class="im"><br>
<br>
> I was thinking about adding the code to resolve the executable in relation to the platform's sysroot (I suppose I would just concatenate the directories and try to resolve the FileSpec). That way, we would be able to create a target before connecting.<br>

<br>
</div>It is already working, no??<br>
<br>
> Regards,<br>
><br>
>   Filipe<br>
<br>
</blockquote></div><br></div>