[lldb-dev] Remote debugging with lldb

[Filipe Cabecinhas]

Hi,

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.

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 ;-)).

Regards,

  Filipe


On Tue, Sep 6, 2011 at 13:43, Greg Clayton <gclayton at apple.com> wrote:

>
> On Sep 6, 2011, at 11:10 AM, Filipe Cabecinhas wrote:
>
> > Hi,
> >
> > On Fri, Sep 2, 2011 at 19:03, Greg Clayton <gclayton at apple.com> wrote:
> >
> > On Sep 2, 2011, at 2:04 PM, Filipe Cabecinhas wrote:
> >
> > > 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)?
> >
> > 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".
> >
> > You can start lldb, set the platform, set the file and attach:
> >
> > % lldb
> > (lldb) platform select ...
> > (lldb) target create /tmp/a.out
> > (lldb) process connect ....
> >
> > 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.
> >
> > 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.
> >
> >  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).
>
> I can currently do this just fine:
>
>
> (lldb) platform select remote-ios
>  Platform: remote-ios
>  Connected: no
>  SDK Path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2"
> (lldb) target create a.out
> Current executable set to 'a.out' (armv6).
> (lldb) image list
> [  0] /Volumes/work/gclayton/Documents/devb/attach/a.out
> [  1]
> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/dyld
> [  2]
> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libgcc_s.1.dylib
> [  3]
> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libSystem.B.dylib
> ...
>
> Is this just not working for remote-macosx?
>
>
> > 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.
>
> It is already working, no??
>
> > Regards,
> >
> >   Filipe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110906/0aadfdb6/attachment.html>