[lldb-dev] Remote debugging with lldb

[Filipe Cabecinhas]

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/20110831/03f3e375/attachment.html>