Please add code to pick up SOLIB_SEARCH_PATH env var.

Please add code to pick up SOLIB_SEARCH_PATH env var.

[Yoshinori Toshima]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

 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

[-- Attachment #2: solib-patch.diff --]
[-- Type: text/plain, Size: 1172 bytes --]

*** gdb.org/solib.c	2010-12-16 17:51:11.000000000 +0900
--- gdb/solib.c	2010-12-16 17:55:29.000000000 +0900
*************** solib_global_lookup (const struct objfil
*** 1448,1453 ****
--- 1448,1469 ----
    return NULL;
  }
  
+ void 
+ check_solib_search_path_env () 
+ {
+   char *envvar = getenv("SOLIB_SEARCH_PATH");
+   if (envvar != NULL) {
+     if (access(envvar, R_OK) == 0) {
+       solib_search_path = envvar;
+       fprintf_filtered (gdb_stdout, _("Picked up SOLIB_SEARCH_PATH %s.\n"),
+                     envvar);
+     } else {
+       warning (_("SOLIB_SEARCH_PATH %s is not accessible. "
+                "Ignored."), envvar);
+     }
+   }
+ }
+ 
  
  extern initialize_file_ftype _initialize_solib; /* -Wmissing-prototypes */
  
*************** For other (relative) files, you can add 
*** 1491,1496 ****
--- 1507,1514 ----
    add_alias_cmd ("solib-absolute-prefix", "sysroot", class_support, 0,
  		 &showlist);
  
+   check_solib_search_path_env();
+ 
    add_setshow_optional_filename_cmd ("solib-search-path", class_support,
  				     &solib_search_path, _("\
  Set the search path for loading non-absolute shared library symbol files."), _("\

Re: Please add code to pick up SOLIB_SEARCH_PATH env var.

[Pierre Muller]

   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
>

Re: Please add code to pick up SOLIB_SEARCH_PATH env var.

[Yoshinori Toshima]

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
>>
>
>
>
>

Re: Please add code to pick up SOLIB_SEARCH_PATH env var.

[Yoshinori Toshima]

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

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
>>>
>>
>>
>>
>>
>


[-- Attachment #2: solib-patch-2.diff --]
[-- Type: text/plain, Size: 1009 bytes --]

*** gdb.org/solib.c	2010-12-16 17:51:11.000000000 +0900
--- gdb/solib.c	2010-12-16 23:15:17.000000000 +0900
*************** solib_global_lookup (const struct objfil
*** 1448,1453 ****
--- 1448,1464 ----
    return NULL;
  }
  
+ void 
+ check_solib_search_path_env () 
+ {
+   char *envvar = getenv("SOLIB_SEARCH_PATH");
+   if (envvar != NULL) {
+       solib_search_path = envvar;
+       fprintf_filtered (gdb_stdout, _("Picked up SOLIB_SEARCH_PATH %s.\n"),
+                     envvar);
+   }
+ }
+ 
  
  extern initialize_file_ftype _initialize_solib; /* -Wmissing-prototypes */
  
*************** For other (relative) files, you can add 
*** 1491,1496 ****
--- 1502,1509 ----
    add_alias_cmd ("solib-absolute-prefix", "sysroot", class_support, 0,
  		 &showlist);
  
+   check_solib_search_path_env();
+ 
    add_setshow_optional_filename_cmd ("solib-search-path", class_support,
  				     &solib_search_path, _("\
  Set the search path for loading non-absolute shared library symbol files."), _("\

Re: Please add code to pick up SOLIB_SEARCH_PATH env var.

[Pedro Alves]

On Thursday 16 December 2010 09:26:11, Yoshinori Toshima wrote:
> 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.

Did you try 'gdb -ex "set solib-search-patch ..."' ?

-- 
Pedro Alves