Cool! Any chance to have this committed to svn? (Sorry to be a pain)

Thanks,

S.

On Jun 27, 2013, at 20:03 , Greg Clayton <[email protected]> wrote:

> 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

Reply via email to