Trouble with 'target modules search-paths...'

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

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.

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

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.