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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to