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
