[lldb-dev] Starting remote process

Andrey Zaytsev andrey.zaytsev at jetbrains.com
Mon Jun 24 11:55:55 PDT 2013


Hello everyone,

By the way I have one related question: how to attach to already running remote process?


On Jun 24, 2013, at 9:58 PM, Greg Clayton <gclayton at apple.com> wrote:

> 
> after you create the target, you need to grab the executable module from the SBTarget and call "SBModule::SetPlatformFileSpec(SBFileSpec)" on it.
> 
> // First create debugger
> SBError error;
> SBTarget target = debugger.CreateTarget("/local/path/a.out", "x86_64-apple-macosx", "remote-macosx", false, error);
> 
> SBModule exe_module = target.FindModule(target.GetExecutable());
> 
> Then set the platform path:
> 
> if (exe_module.IsValid())
> {
>    SBFileSpec remote_path ("/remote/path/a.out", false);
>    exe_module.SetPlatformFileSpec (remote_path);
> 	
>    process = target.ConnectRemote(...)
> 
>    process.RemoteLaunch(...)
> 
> }
> 
> This will only work if you are connecting to a debugserver that is not running a process yet. There are two ways to start debugserver:
> 1 - with no process
> 2 - have it launch a process and wait to attach
> 
> We will assume we have two hosts here: local.foo.com (where you want to debug from), remote.foo.com (the remote host which will run the process).
> 
> When you launch with no process, you start debugserver with no process specified:
> 
> remote.foo.com% debugserver remote.foo.com:1234
> 
> Then you would follow the exact steps from above.
> 
> If you launch debugserver and give it a process already:
> 
> remote.foo.com% debugserver remote.foo.com:1234 -- /remote/path/a.out --arg --foo --bar
> 
> Then after you call ConnectRemote() you should have a live process and you won't require a remote launch. LLDB will be able to match up the remote path coming in ("/remote/path/a.out") with your local path by matching the UUID values as long as you created your target with the correct local copy of your binary ("/local/path/a.out"), with no need to call "SetPlatformFileSpec()".
> 
> Likewise if you have 4 shared libraries that you built locally and are somehow loading moving them over to the remote system so they get used while debugging and these files are not part of your normal sysroot that you mounted, you can tell the target about the local copies:
> 
> SBModule shlib_module1 = target.AddModule ("/local/path/libfoo.dylib", "x86_64-apple-macosx", NULL);
> SBModule shlib_module2 = target.AddModule ("/local/path/libbar.dylib", "x86_64-apple-macosx", NULL);
> SBModule shlib_module3 = target.AddModule ("/local/path/libbaz.dylib", "x86_64-apple-macosx", NULL);
> 
> You do this right after creating your target. Then LLDB knows about these shared libraries in its global module cache and can find them when we connect to your process even if the paths are totally different and even if you don't cal SetPlatformFileSpec on each module.
> 
> Greg Clayton
> 
> 
> On Jun 23, 2013, at 7:04 AM, Sebastien Metrot <meeloo at gmail.com> wrote:
> 
>> Hello,
>> 
>> I'm now investigating how to start a remote debugging session. 
>> I create a debugger, then a target (with the local path of the executable), and then a process with SBTarget::ConnectRemote. When I get the status changed event that tells me the debugger is connected I try to launch the remote application with SBProcess::RemoteLaunch but I get an error: "Remote Launch result: No such file or directory (path to my local executable)" and that's because the remote executable is not stored in the same path than the local one, but I haven't found a way to give that information to SBTarget or SBProcess. I have tried to pass it as the first argument of SBProcess::RemoteLaunch but it doesn't work as the first thing this method does is to insert the local target path in the argument list. 
>> If I comment the lines 175 and 176 in SBProcess.cpp that does the insertion:
>> //            if (exe_module)
>> //                launch_info.SetExecutableFile(exe_module->GetFileSpec(), true);
>> It then works beautifully.
>> 
>> What is the correct way or achieving what I'm trying to do? Is there a need for a new API or did I once again overlooked something?
>> 
>> Thanks!
>> 
>> S.
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev





More information about the lldb-dev mailing list