Hello Pierre,

I removed access check from the patch and specified colon separated paths
including non-existing directory and a regular path.  gdb picked up
the libraries in the path list specified by the environment variable.
Invalid elements are simply ignored.  I've not checked all the details,
but these multiple path elements are handled properly when interpreting
solib variable solib_search_path.  Maybe access() check is redundant.

 > Did you try 'gdb -ex "set solib-search-patch ..."' ?
It worked.  It worked with colon separated multiple paths too.
I didn't see the option in man page, though.

It is good to have alternative methods, so suggested SOLIB_SEARCH_PATH
method still has value, I think.  One advantage is that it does not
require changing program which has a hard coded gdb invocation.

Regards,
Yoshinori

(2010/12/16 22:22), Yoshinori Toshima wrote:
> Hello Pierre,
>
> Thank you for your comment.
>
> Currently, single path element works.  It is rare to have same 
> libraries with
> same name in different directories.
>
> To support multiple path elements, we need to check solib_search_path
> variable use in solib.c again.  If it can have comma separated path 
> elements,
> then we can check each environment variable and join valid elements with
> colon and set it to solib_search_path.
>
> > Did you try 'gdb -ex "set solib-search-patch ..."' ?
> No I haven't.  I'll check it.
>
> Regards,
> Yoshinori
>
> (10/12/16 19:26), Pierre Muller wrote:
>>   I was wondering if your patch
>> would work if the environment variable had
>> several entries, like;
>> SOLIB_SEARCH_PATH=/myprefix/lib:/myprefix/lib64
>>
>>   Does access return 0 if you
>> give it the whole evironment variable, or should
>> you test the coponents one by one?
>>
>> Pierre Muller
>>
>>> Yoshinori Toshima <yoshinori.toshima@oracle.com> a écrit :
>>>
>>>  Hello,
>>>
>>> I have a small enhancement request for GDB to make it easier to
>>> use when debugging core file from other systems which have
>>> different libraries.
>>>
>>> Description:
>>> When debugging a core file from released product, it is convenient
>>> to have gdb use shared libraries in a directory which contains the
>>> libraries and executable taken from the system which caused the
>>> crash. It is possible to perform this by gdb command "set
>>> solib-search-path <path>". This means some commands are required
>>> after starting gdb. If we can set solib-search-path at gdb startup,
>>> it is easier to use. This is useful when we use GDB programmatically.
>>>
>>> HP-UX port of GDB has this feature via env var GDB_SHLIB_PATH.
>>> GDB does not have the feature yet, though it mentions SOLIB_SEARCH_PATH
>>> in solib.c.
>>>
>>> I changed solib.c to pick up SOLIB_SEARCH_PATH at startup and set
>>> it to solib_search_path in solib.c initialization. It worked as
>>> expected.
>>>
>>> Attached solib-patch.diff is based on solib.c in gdb 7.2.
>>>
>>> ChangeLog entry:
>>> 2010-12-16 Yoshinori Toshima <yoshinori.toshima@oracle.com>
>>>
>>> * solib.c: Pick up SOLIB_SEARCH_PATH env var to set 
>>> solib-search-path at
>>> startup.
>>>
>>> Regards,
>>> Yoshinori Toshima
>>>
>>
>>
>>
>>
>