Re: [PATCH 1/2] Change gdb_load_shlibs to gdb_load_shlib

[Pedro Alves <palves at redhat dot com>]

On 04/13/2016 10:05 PM, Simon Marchi wrote:
> On 16-04-13 02:18 PM, Pedro Alves wrote:

>> We'll now only end up with $libobj2's dirname in the solib-search-path.
>> This usually won't be a problem since the dirnames will be the same,
>> though I guess some test might be doing something with subdirs.
>> Grepping a bit I found solib-search.exp, though it's currently disabled
>> on remote testing.
> 
> Ah that's true. For some reason I thought it appended to the list in GDB.
> 
> In the original implementation, it only used the dirname of the first passed
> shared library, didn't it?  

You're right.  I only realized that after hitting send.

> So the behavior will change (we will keep the
> directory of the last one, where we used to keep the directory of the first
> one), but is the situation worse than it was?

Probably not.

> 
>> Do we need to maintain a list of dirnames, and clear it somewhere?
> 
> If a test case needs to have multiple different values in solib-search-path,
> we have multiple options.
> 
> Option #1
> 
> Maintain a list somewhere in the TCL code.  It's not my favorite, because
> we already have a ton of global stuff hard to keep track of.

Indeed.

> 
> Option #2
> 
> Get the current value using "show solib-search-path" and append the new value
> to it.

Interesting idea.

> 
> Option #3
> 
> Initially I thought of a lazy way to achieve what I want.  I thought to
> make gdb_load_shlibs return a list of the destination paths (one for each
> passed solib).  This way I wouldn't have had to modify all the callers.  If
> we used this approach, we could build the list of all the directories and pass
> that to set solib-search-path.
> 

Right.  Several tests call gdb_load_shlibs once for each lib, and we'd
need to merge those, for correct solib-search-path.

> Options #4
> 
> Maybe it's not a big deal, tests that do some special solib path stuff can
> just override solib-search-path as they see fit.

If testing something that needs to exercise something related to debugging a
set of libraries laid out in different directories like, e.g. having:

 plugin.so
 dir_1/plugin.so
 dir_1/dir_2/plugin.so
 dir_2/plugin.so
 dir_2/dir_1/plugin.so
 dir_2/dir_2/plugin.so

and exercising symbol the search code in solib.c:solib_find (e.g.,
mess with PATH/LD_LIBRARY_PATH), you still shouldn't need solib-search-path
when testing locally, and the testcase shouldn't need to explicitly
set solib-search-path.

It's just theoretical at this point though, given that as you found,
we already have the issue.

> The setting of
> solib-search-path in gdb_load_shlib[s] is only for convenience in the
> general case.

Since this turns out to be a pre-existing issue, I'm fine with ignoring 
it for now.

Thanks,
Pedro Alves