Re: Why does solib_open do what it does?

Michael Snyder
2003-06-18T18:41:07Z

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.