[lldb-dev] Remote debugging with lldb

[Filipe Cabecinhas]

Hi,


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

>
> On Sep 1, 2011, at 1:52 PM, Filipe Cabecinhas wrote:
>
> 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'.
>
>
> 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.
>

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.

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.
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 Process::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.

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)?

One more question (from the last email) about another way we could do this:

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?

Thanks for the help,

  Filipe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110902/fd5b7bbf/attachment.html>