Why does solib_open do what it does?

[Michael Snyder]

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