[lldb-dev] Trouble with 'target modules search-paths...'

[Aidan Dodds]

Hi Greg,

Thanks for the reply.
That was my impression also, that it was there to try to resolve missing 
images.


I have started to unravel the problem that I am seeing, but my knowledge 
is still patchy with regards to some of the workings of Target.

When I attach to my process, the DynamicLoaders DidAttach() method 
fires.  This enumerates the target module and calls 
Target::SetSectionLoadAddress() for
each section found.  Thus it seems the Target::m_section_load_history 
member is populated by the dynamic loader.

Next, I set the search path, which fires the 
Target::ImageSearchPathsChanged() callback.  Part of this process is to 
call Target::ClearModules(), which
runs m_section_load_history.Clear();  Clearing all of the information on 
the loaded sections.

After this process, the dynamic loader never gets the chance to rebuild 
Target::m_section_load_history.
Thus things like Target::ResolveLoadAddress() will fail.


Do you have any suggestions for a clean way to fix this problem?

It seems to me one way would be to add a new method to Target, which 
would resolve any currently unloaded modules, without unloading 
everything that is already loaded.
This could then be called instead from 
Target::ImageSearchPathsChanged(), instead of unloading and reloading 
the executable to get the same effect.

Does that sound right?

Thanks,
Aidan


On 26/03/2014 18:14, Greg Clayton wrote:
> I believe it is assuming that by loading the module again, any shared libraries that weren't found could now be located. Lets say you loaded some file:
>
> (lldb) file a.out
> (lldb) image list
> a.out
>
> Only 1 file was found, even though a.out said it depended on /usr/lib/libfoo.so and /usr/lib/libbar.so...
>
> Then you modify the search paths, and then
>
> (lldb) file a.out
> (lldb) target modules search-paths add . d:/foo
> (lldb) image list
> a.out
> d:/libfoo.so
> d:/libbar.so
>
> This is probably what the intent was. So try doing a "image list" before and after and see what differs.
>
> On Mar 25, 2014, at 9:44 AM, Aidan Dodds <aidan at codeplay.com> wrote:
>
>> Hi All,
>>
>> I have been experiencing some problems when using the following command:
>>
>> (lldb) target modules search-paths add . d:/foo
>>
>> My intent is to set the folder for LLDB to locate any shared object files that the gdbremote target may load via dlopen().
>> After issuing the above command all of the loaded sections in the target executable seems to be missing, and I am unable to
>> find a LoadAddresses for any symbols etc.
>>
>> I have come across the code below, from "source/Target/Target.cpp at line:1748"
>>
>> void
>> Target::ImageSearchPathsChanged
>> (
>>     const PathMappingList &path_list,
>>     void *baton
>> )
>> {
>>     Target *target = (Target *)baton;
>>     ModuleSP exe_module_sp (target->GetExecutableModule());
>>     if (exe_module_sp)
>>         target->SetExecutableModule (exe_module_sp, true);
>> }
>>
>> When I disable this code then everything works as expected for me.
>>
>> I am wondering what the intent of this code is?
>> or does anyone have any ideas why I would be seeing such problems?
>>
>> Thanks,
>> Aidan
>>
>> -- 
>> Aidan Dodds
>> Codeplay Software Ltd
>> 45 York Place, Edinburgh, EH1 3HP
>> Tel: 0131 466 0503
>> Fax: 0131 557 6600
>> Website: http://www.codeplay.com
>> Twitter: https://twitter.com/codeplaysoft
>>
>> This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
>> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
>> Company registered in England and Wales, number: 04567874
>> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev