Re: Why does solib_open do what it does?

[Kevin Buettner <kevinb at redhat dot com>]

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.

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.)

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?

Kevin