On Mar 27, 2014, at 5:15 AM, Aidan Dodds <[email protected]> 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. > > 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 <[email protected]> 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@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 >>> [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
