Re: Why does solib_open do what it does?

Michael Snyder
2003-06-18T18:45:23Z

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