[Lldb-commits] [Patch][Please Review] Detect inferior changed

[Kopec, Matt]

As long as we're aware then I don't see any uses that warrant updating the module. Thanks for the review.

Matt

On 2013-03-04, at 8:04 PM, Greg Clayton <gclayton at apple.com> wrote:

> I am not too worried about the side effects of starting with a module that might be out of date unless something in the launch or attach would require data from the file itself.
> 
> Typically launching involves providing a path to posix_spawn or fork/exec and the correct program will launch. The dynamic loaders will detect the change when the shared library loaded notification is received, so this normally fixes things up. We also memory map the entire shared library contents so even if they do change on disk we have our own immutable copy (barring the file being on a network file system and being unmounted).
> 
> If you find any reason we should do more checking to ensure the file is up to date prior to launching, please let me know.
> 
> Otherwise, the patch looks good.
> 
> Greg
> 
> On Mar 4, 2013, at 4:30 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:
> 
>> This patch resolves an issue on Linux where if you are debugging an inferior, change the inferior in some way (source change then recompile) and do a run/process launch, lldb asserts on Linux. The problem comes down to lldb not checking for a changed module/objectfile. The test TestInferiorChanged.py tests for this exact behaviour.
>> 
>> I noticed the class DynamicLoaderMacOSXDYLD handles the changed inferior correctly for Mac and I have prepared a patch that does something similar in POSIX as part of DidLaunch/DidAttach, which I have attached. I was initially tempted to check this in without feedback from the list, however, I am now hesitant that DynamicLoader is the correct place to do this in general.
>> 
>> With the run/process launch command there are uses of the target executable module (ie. CommandObjectLaunch, Process::Launch) before reaching any DynamicLoader use, which, if the file/module has changed, parts of the executable module would be invalid. The directory/file would be the same but other parts such as the objectfile would be invalid. The earliest location to set the target executable correctly would probably be part of CommandObjectLaunch::DoExecute.
>> 
>> Is this a concern? Is there problems with setting the executable module this way or should it just be done as in the patch?
>> 
>> Thanks,
>> Matt<inferiorchanged.patch>_______________________________________________
>> lldb-commits mailing list
>> lldb-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>