[lldb-dev] Remote debugging with lldb

[Filipe Cabecinhas]

Hi,

On Thu, Sep 1, 2011 at 12:21, Greg Clayton <gclayton at apple.com> wrote:

> PlatformDarwin is a base class and cant be instantiated on its own.
> PlatformMacOSX and PlatformRemoteiOS inherit from this base class and
> customize it.
>
>
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'.

On Thu, Aug 25, 2011 at 15:32, Greg Clayton <gclayton at apple.com> wrote:

>
> On Aug 24, 2011, at 6:11 PM, Filipe Cabecinhas wrote:
>
> > Hi,
> >
> > I'm trying to do remote debugging with lldb, but I keep running into
> problems.
> >
> > How should I do it?
> >
> > I tried running "debugserver localhost:42000" and then, on the lldb
> client:
> >
> > platform select (remote-macosx | remote-gdb-server?) + platform connect?
> > platform select … + process connect?
>
> 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:
>
> AFP mount the root drive on the other machine. For these examples lets
> suppose we have machine1 and machine2. So the flow would be:
>
> - machine1: start debugserver:
> machine1 % debugserver localhost:12345 /bin/ls
>
> - machine2: mount the root drive from machine2 and launch lldb:
> machine2 % ./lldb
> (lldb) platform select remote-macosx --sysroot /Volumes/machine1
> (lldb) process connect connect://machine1:12345
>
> 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.
>
>
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?

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.

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?

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?

Regards,

  Filipe


> On Aug 31, 2011, at 1:05 PM, Filipe Cabecinhas wrote:
>
> > Hi,
> >
> > 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 PlatformDarwin::ResolveExecutable). Shouldn't the remote part
> of the platform, when m_remote_platform_sp is NULL, resolve the executable
> using the --sysroot option?
> >
> > Regards,
> >
> >   Filipe
> >
> >
> >
> > On Thu, Aug 25, 2011 at 18:25, Greg Clayton <gclayton at apple.com> wrote:
> >
> > On Aug 25, 2011, at 5:52 PM, Filipe Cabecinhas wrote:
> >
> > > 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?
> >
> > 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:
> >
> > (lldb) file /Volumes/machine1/Applications/TextEdit.app
> >
> > If you use the "remote-gdb-server" it won't know any of the macosx
> specifics.
> >
> > >
> > > I managed to run the program with both, but where is the difference
> between them?
> >
> > 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.
> >
> >
> > > Or is it the same because you've wired the macosx-host platform to just
> start a remote-gdb-server?
> >
> > "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.
> >
> > > >
> > > > I would suppose you need the plugins for the combinations you want to
> use, but with the gdb-remote stuff, I'm getting confused.
> > > >
> > > > 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).
> > > >
> > >
> > > None of these should really be ifdefed out, they should be being
> compiled on all platforms, excluding any "native only" plug-ins.
> > >
> > > So, in the future, lldb.cpp will simply run all that code, except for
> some of the Platform (and Process?) plugins?
> >
> > 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.
> >
> > > 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).
> >
> > 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.
> >
> > >
> > > 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.
> >
> > If you launch a GDB on linux and type:
> >
> > (gdb) maintenance print raw-registers
> >
> > 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.
> >
> > Greg
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110901/07cbeb46/attachment.html>