This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: solib-patch-2.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]