That looks fine. On Jun 27, 2013, at 3:49 AM, Sebastien Metrot <[email protected]> wrote:
> Greg, > > I have updated the sources today to see if the remote launch has been fixed > but it still doesn't work here so I'm proposing the following change. > > Cheers, > > S. > > > Index: source/API/SBProcess.cpp > =================================================================== > --- source/API/SBProcess.cpp (revision 185064) > +++ source/API/SBProcess.cpp (working copy) > @@ -173,7 +173,7 @@ > launch_flags); > Module *exe_module = > process_sp->GetTarget().GetExecutableModulePointer(); > if (exe_module) > - launch_info.SetExecutableFile(exe_module->GetFileSpec(), > true); > + > launch_info.SetExecutableFile(exe_module->GetPlatformFileSpec(), true); > if (argv) > launch_info.GetArguments().AppendArguments (argv); > if (envp) > > > > On Jun 25, 2013, at 16:14 , Sebastien Metrot <[email protected]> wrote: > >> 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 > > > _______________________________________________ > 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
