[lldb-dev] Remote debugging with lldb

[Greg Clayton]

On Sep 2, 2011, at 2:04 PM, Filipe Cabecinhas wrote:

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

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. 

> 

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

No, as above, we should create the target with the needed file, then connect. Eventually we need the platform to be able to allow us to request a remote file when we attach or launch, but that isn't there yet. 

Greg