This is the mail archive of the gdb@sources.redhat.com 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: Why does solib_open do what it does?


Kevin Buettner wrote:
On Jun 17, 9:54pm, Kris Warkentin wrote:


Michael, any comments?

I don't remember. ;-( I'll just remark that ld puts full paths in for some libs, and not for

others.


That's why there are two variables, SOLIB-SEARCH-PATH and
SOLIB-ABSOLUTE-PREFIX.  One is the prefix that goes before everything
(even rooted filespecs), and the other is the additional prefix that
goes before an un-rooted filespec.

Okay then, here's what I propose.


1) Change the order as Kevin suggested earlier.  This give the user plenty
of opportunity to tell gdb how to find the solibs before we thrash about
desperately in LD_LIBRARY_PATH, etc.


Definitely okay.


2) Take out the solib_search_path check in the if(found_file <0 &&
solib_search_path != NULL) parts of the last two desperation plays.  I don't
think there's any reason for them.


Wow. Good catch. I don't understand them either. But...


I have a feeling that we want to leave the last two searches in place simply
because native debugging is the most common and they probably catch a lot of
action.  Most people doing remote debugging are setting up their
solib-absolute-prefix and such properly anyway.


Given the fact that these tests are here, I don't think that the $PATH
and $LD_LIBRARY_PATH checks are ever actually used for native
debugging.

After all, who bothers to set solib_search_path when doing native
debugging?  And if you do set solib_search_path, doesn't it seem
strange that these additional checks suddenly become enabled?

So, at this point we have two choices: a) Do away with the $PATH and
$LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove
the ``solib_search_path != NULL'' check.

If we can actually convince ourselves that leaving in the $PATH and
$LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to
go.  At the moment, however, I'm strongly leaning towards option a.

You don't think that gdb should honor LD_LIBRARY_PATH in native debugging, if it is set? Won't the linker-loader honor it?

I'd be ready to agree that, if solib-search-path is set,
it should override LD_LIBRARY_PATH.  But if it isn't set...


In fact, for remote debugging, leaving these checks in is rather
dangerous.  If, for some reason, the shared lib is not found via
either solib-absolute-prefix or solib-search-path, we don't want
to search paths on the host file system which refer to the hosts
libraries.   If the file is found via one of these paths, it is
almost certainly wrong, and I've seen cases where this can cause
wildly unpredictable behavior.  (E.g, segfaults on the target, or
breakpoints being hit at strange places.)

Agreed. Indeed, I think LD_LIBRARY_PATH is required for native, and always wrong for cross. Is there any way we can use that distinction? Maybe with a configure variable?


I think I could be convinced to leave these checks in if we
were to replace that ``solib_search_path != NULL'' conjunct with
``solib_absolute_prefix == NULL'' instead.  That is, if you set
solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never
be considered.  (I guess there were actually three choices.  We'll
call this one option c.)

Opinions?

How about (d) a configure variable that enables the tests for native only.







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