Greg,
I tried this solution but it didn't work because there may be a bug in
SBTarget.cpp line 176:
launch_info.SetExecutableFile(exe_module->GetFileSpec(), true);
Shouldn't this read GetPlatformFileSpec instead of GetFileSpec?
Cheers,
S.
On Jun 24, 2013, at 19:58 , 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
