[lldb-dev] Trouble with 'target modules search-paths...'
gclayton at apple.com
Thu Mar 27 10:01:10 PDT 2014
On Mar 27, 2014, at 5:15 AM, Aidan Dodds <aidan at codeplay.com> wrote:
> 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?
Set your search paths prior to running and creating your target.
> 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?
Yes it does.
> 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
>> 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
>> 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"
>>> 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?
>>> 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
More information about the lldb-dev