Re: Why does solib_open do what it does?

[Michael Snyder <msnyder at redhat dot com>]

Kris Warkentin wrote:
> > 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?
>
>
> Hmm...good point.  It's probably completely unexercised code.
>
>
> > 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.
>
>
> Well, we had some customers complain that LD_LIBRARY_PATH stopped working
> for them when they stopped setting solib-search-path.  They were using it
> for remote debugging (somewhat questionable I know) because they have a
> central build server that stores most of their libs and then developers
> systems have a mount.  The administrators set LD_LIBRARY_PATH specifically
> for gdb to find these libs when debugging remote targets.

Well, that's obviously a kludge, not what they should be doing.
We once discussed looking for an environment variable, eg.
GDB_SOLIB_SEARCH_PATH, but somebody was against it (maybe Ian
Lance Taylor?).  Should we revive that idea?


> They'll probably whine if I take it out. 

Too bad -- they're doing something wrong.

> Really though, the only places I
> can see this being useful is cases like this and when you've got a
> misbehaving linker which doesn't fill in the full path.

I don't think that is a sign of a misbehaving linker.
Some libraries don't have the full path -- that's why there are
two gdb variables rather than just one.


> > 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.)
>
>
> This was my major problem with checking LD_LIBRARY_PATH.

For cross-debugging, yes.  I think it would always be wrong.


> > 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.)
>
>
> Well, that wouldn't help my customers since we do set solib-absolute-prefix.
> On the other hand, there IS solib-search-path and .gdbinit files so I don't
> really have a problem with telling them that the LD_L... checking has gone
> away.  I'll leave the decision to you.  I'm just going to remove the
> solib_search_path != NULL checks from our shipping version and mark the
> behaviour as deprecated if necessary.
>
> cheers,
>
> Kris