Re: Why does solib_open do what it does?

["Kris Warkentin" <kewarken at qnx dot com>]

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

They'll probably whine if I take it out.  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.

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

> 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