Sure thing:

Author: gclayton
Date: Fri Jun 28 19:10:32 2013
New Revision: 185245

URL: http://llvm.org/viewvc/llvm-project?rev=185245&view=rev
Log:
Fixed SBProcess::RemoteLaunch() to use the platform executable path. Patch from 
Sebastien Metrot.

Modified:
   lldb/trunk/source/API/SBProcess.cpp

Modified: lldb/trunk/source/API/SBProcess.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBProcess.cpp?rev=185245&r1=185244&r2=185245&view=diff
==============================================================================
--- lldb/trunk/source/API/SBProcess.cpp (original)
+++ lldb/trunk/source/API/SBProcess.cpp Fri Jun 28 19:10:32 2013
@@ -173,7 +173,7 @@ SBProcess::RemoteLaunch (char const **ar
                                           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 28, 2013, at 1:26 PM, Sebastien Metrot <[email protected]> wrote:

> 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

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

Reply via email to