Re: Why does solib_open do what it does?

[Michael Snyder <msnyder@redhat.com>]

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.