Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yoshinori Toshima <yoshinori.toshima@oracle.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb-patches@sourceware.org, yoshinori.toshima@oracle.com
Subject: Re: Please add code to pick up SOLIB_SEARCH_PATH env var.
Date: Thu, 16 Dec 2010 14:23:00 -0000	[thread overview]
Message-ID: <4D0A20D6.4040009@oracle.com> (raw)
In-Reply-To: <4D0A128D.40201@oracle.com>

[-- 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."), _("\

  reply	other threads:[~2010-12-16 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  9:29 Yoshinori Toshima
2010-12-16 10:26 ` Pierre Muller
2010-12-16 13:23   ` Yoshinori Toshima
2010-12-16 14:23     ` Yoshinori Toshima [this message]
2010-12-16 13:07 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D0A20D6.4040009@oracle.com \
    --to=yoshinori.toshima@oracle.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox