Why does solib_open do what it does?

Why does solib_open do what it does?

[Kris Warkentin]

I'm looking at solib.c:solib_open() and as I go down the list:

   Search order:
1   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
2   * If path is absolute or relative, look for it literally (unmodified).
3   * Look in SOLIB_SEARCH_PATH.
4   * If available, use target defined search function.
5   * Look in inferior's $PATH.
6   * Look in inferior's $LD_LIBRARY_PATH.

I'm puzzled.  Why are we testing for the existence of solib_search_path
before checking 5 and 6?

cheers,

Kris

Re: Why does solib_open do what it does?

[Daniel Jacobowitz]

On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote:
> I'm looking at solib.c:solib_open() and as I go down the list:
> 
>    Search order:
> 1   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
> 2   * If path is absolute or relative, look for it literally (unmodified).
> 3   * Look in SOLIB_SEARCH_PATH.
> 4   * If available, use target defined search function.
> 5   * Look in inferior's $PATH.
> 6   * Look in inferior's $LD_LIBRARY_PATH.
> 
> I'm puzzled.  Why are we testing for the existence of solib_search_path
> before checking 5 and 6?

You'll have to get Kevin's opinion, but it looks like a paste-o to me.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does solib_open do what it does?

[Kris Warkentin]

> On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote:
> > I'm looking at solib.c:solib_open() and as I go down the list:
> >
> >    Search order:
> > 1   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
> > 2   * If path is absolute or relative, look for it literally
(unmodified).
> > 3   * Look in SOLIB_SEARCH_PATH.
> > 4   * If available, use target defined search function.
> > 5   * Look in inferior's $PATH.
> > 6   * Look in inferior's $LD_LIBRARY_PATH.
> >
> > I'm puzzled.  Why are we testing for the existence of solib_search_path
> > before checking 5 and 6?
>
> You'll have to get Kevin's opinion, but it looks like a paste-o to me.

That's what I was thinking too.  A customer reported that when they don't
set solib-search-path, all of a sudden gdb isn't finding solibs that used to
be found in LD_LIBRARY_PATH.

You think it's okay for me to fix it?

cheers,

Kris

Re: Why does solib_open do what it does?

[Elena Zannoni]

Kris Warkentin writes:
 > > On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote:
 > > > I'm looking at solib.c:solib_open() and as I go down the list:
 > > >
 > > >    Search order:
 > > > 1   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
 > > > 2   * If path is absolute or relative, look for it literally
 > (unmodified).
 > > > 3   * Look in SOLIB_SEARCH_PATH.
 > > > 4   * If available, use target defined search function.
 > > > 5   * Look in inferior's $PATH.
 > > > 6   * Look in inferior's $LD_LIBRARY_PATH.
 > > >
 > > > I'm puzzled.  Why are we testing for the existence of solib_search_path
 > > > before checking 5 and 6?
 > >
 > > You'll have to get Kevin's opinion, but it looks like a paste-o to me.
 > 
 > That's what I was thinking too.  A customer reported that when they don't
 > set solib-search-path, all of a sudden gdb isn't finding solibs that used to
 > be found in LD_LIBRARY_PATH.
 > 
 > You think it's okay for me to fix it?
 > 
 > cheers,
 > 
 > Kris
 > 

can you do some cvs annotate/diffs ? maybe you'll see when that was
introduced, and find a changelog that explains things.

elena

Re: Why does solib_open do what it does?

[Kris Warkentin]

> can you do some cvs annotate/diffs ? maybe you'll see when that was
> introduced, and find a changelog that explains things.

It's from the first revision of solib_open from msnyder back in November of
2000.  No explanation in the logs.

cheers,

Kris

Re: Why does solib_open do what it does?

[Kevin Buettner]

On Jun 17,  3:14pm, Kris Warkentin wrote:
> Subject: Re: Why does solib_open do what it does?
> > On Tue, Jun 17, 2003 at 03:01:25PM -0400, Kris Warkentin wrote:
> > > I'm looking at solib.c:solib_open() and as I go down the list:
> > >
> > >    Search order:
> > > 1   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
> > > 2   * If path is absolute or relative, look for it literally
> (unmodified).
> > > 3   * Look in SOLIB_SEARCH_PATH.
> > > 4   * If available, use target defined search function.
> > > 5   * Look in inferior's $PATH.
> > > 6   * Look in inferior's $LD_LIBRARY_PATH.
> > >
> > > I'm puzzled.  Why are we testing for the existence of solib_search_path
> > > before checking 5 and 6?
> >
> > You'll have to get Kevin's opinion, but it looks like a paste-o to me.
> 
> That's what I was thinking too.  A customer reported that when they don't
> set solib-search-path, all of a sudden gdb isn't finding solibs that used to
> be found in LD_LIBRARY_PATH.

It sounds to me like the solibs in question were actually being found via
solib-search-path, not LD_LIBRARY_PATH.

I think the problem with using LD_LIBRARY_PATH is that the paths
won't be correct without some sort of adjustment.  I.e, the paths
provided by LD_LIBRARY_PATH are target filesystem paths, not host
paths.

> You think it's okay for me to fix it?

Not yet.  I want to study the code some more first.

...

Actually, the one that bothers me is (2).  I think we ought to be doing
(2) after (3).

Kevin

Re: Why does solib_open do what it does?

[Kris Warkentin]

> > That's what I was thinking too.  A customer reported that when they
don't
> > set solib-search-path, all of a sudden gdb isn't finding solibs that
used to
> > be found in LD_LIBRARY_PATH.
>
> It sounds to me like the solibs in question were actually being found via
> solib-search-path, not LD_LIBRARY_PATH.
>
> I think the problem with using LD_LIBRARY_PATH is that the paths
> won't be correct without some sort of adjustment.  I.e, the paths
> provided by LD_LIBRARY_PATH are target filesystem paths, not host
> paths.

Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong
since the only util that should be concerned with that is the runtime
loader.  Ideally, ld should be filling in the path where it found the lib
which can then be used with solib-absolute-prefix or some such.

> > You think it's okay for me to fix it?
>
> Not yet.  I want to study the code some more first.
>
> Actually, the one that bothers me is (2).  I think we ought to be doing
> (2) after (3).

You may be right there.  I suppose we want to give the user every
opportunity to override things.  I specifically put the target-defined
search function AFTER the solib-search-path lookup for just that reason.  If
you're going to move 2, I would say it should be after the target defined
one so that both users and targets get a say before gdb starts looking in
places that could potentially have conflicting solibs.

cheers,

Kris

Re: Why does solib_open do what it does?

[Kevin Buettner]

On Jun 17,  4:15pm, Kris Warkentin wrote:

> > > That's what I was thinking too.  A customer reported that when they
> don't
> > > set solib-search-path, all of a sudden gdb isn't finding solibs that
> used to
> > > be found in LD_LIBRARY_PATH.
> >
> > It sounds to me like the solibs in question were actually being found via
> > solib-search-path, not LD_LIBRARY_PATH.
> >
> > I think the problem with using LD_LIBRARY_PATH is that the paths
> > won't be correct without some sort of adjustment.  I.e, the paths
> > provided by LD_LIBRARY_PATH are target filesystem paths, not host
> > paths.
> 
> Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong
> since the only util that should be concerned with that is the runtime
> loader.  Ideally, ld should be filling in the path where it found the lib
> which can then be used with solib-absolute-prefix or some such.

Right.

I think Michael added the searches on $PATH and $LD_LIBRARY_PATH for
native ports, but it's not clear to me that these searches are actually
needed.

Michael, any comments?

> > > You think it's okay for me to fix it?
> >
> > Not yet.  I want to study the code some more first.
> >
> > Actually, the one that bothers me is (2).  I think we ought to be doing
> > (2) after (3).
> 
> You may be right there.  I suppose we want to give the user every
> opportunity to override things.  I specifically put the target-defined
> search function AFTER the solib-search-path lookup for just that reason.  If
> you're going to move 2, I would say it should be after the target defined
> one so that both users and targets get a say before gdb starts looking in
> places that could potentially have conflicting solibs.

Sure.  That sounds right to me.  If you want to submit a patch for doing
this, that'd be very much appreciated.

Thanks,

Kevin

Re: Why does solib_open do what it does?

[Michael Snyder]

Kevin Buettner wrote:
> On Jun 17,  4:15pm, Kris Warkentin wrote:
> 
> 
>>>>That's what I was thinking too.  A customer reported that when they
>>>
>>don't
>>
>>>>set solib-search-path, all of a sudden gdb isn't finding solibs that
>>>
>>used to
>>
>>>>be found in LD_LIBRARY_PATH.
>>>
>>>It sounds to me like the solibs in question were actually being found via
>>>solib-search-path, not LD_LIBRARY_PATH.
>>>
>>>I think the problem with using LD_LIBRARY_PATH is that the paths
>>>won't be correct without some sort of adjustment.  I.e, the paths
>>>provided by LD_LIBRARY_PATH are target filesystem paths, not host
>>>paths.
>>
>>Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong
>>since the only util that should be concerned with that is the runtime
>>loader.  Ideally, ld should be filling in the path where it found the lib
>>which can then be used with solib-absolute-prefix or some such.
> 
> 
> Right.
> 
> I think Michael added the searches on $PATH and $LD_LIBRARY_PATH for
> native ports, but it's not clear to me that these searches are actually
> needed.
> 
> 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.

Re: Why does solib_open do what it does?

[Kris Warkentin]

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

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.

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.

Sound reasonable?

cheers,

Kris

Re: Why does solib_open do what it does?

[Kevin Buettner]

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

Re: Why does solib_open do what it does?

[Kris Warkentin]

> 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

Re: Why does solib_open do what it does?

[Kris Warkentin]

I believe the comment does not accurately reflect the code.  Here is my
proposal for the new comment using the search algorithm rather than search
order:

   Search algorithm:
   * If there is a solib_absolute_prefix and path is absolute:
   *   Search for solib_absolute_prefix/path.
   * else
   *   Look for it literally (unmodified).
   * Look in SOLIB_SEARCH_PATH.
   * If available, use target defined search function.
   * Look in inferior's $PATH.
   * Look in inferior's $LD_LIBRARY_PATH.

The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more
literal.  It's only used if the path is absolute.  Then the question is, do
we think this is correct?  Should we be searching literally at this point or
defer that until later?

cheers,

Kris

Re: Why does solib_open do what it does?

[Michael Snyder]

Kevin Buettner wrote:
> 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.

You don't think that gdb should honor LD_LIBRARY_PATH in native
debugging, if it is set?  Won't the linker-loader honor it?

I'd be ready to agree that, if solib-search-path is set,
it should override LD_LIBRARY_PATH.  But if it isn't set...


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

Agreed.  Indeed, I think LD_LIBRARY_PATH is required for native,
and always wrong for cross.  Is there any way we can use that
distinction?  Maybe with a configure variable?


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

How about (d) a configure variable that enables the tests for native only.

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

Re: Why does solib_open do what it does?

[Michael Snyder]

Kris Warkentin wrote:
> I believe the comment does not accurately reflect the code.  Here is my
> proposal for the new comment using the search algorithm rather than search
> order:
> 
>    Search algorithm:
>    * If there is a solib_absolute_prefix and path is absolute:
>    *   Search for solib_absolute_prefix/path.
>    * else
>    *   Look for it literally (unmodified).
>    * Look in SOLIB_SEARCH_PATH.

I'm not sure -- but do you think it should be
/SOLIB_ABSOLUTE_PREFIX/SOLIB_SEARCH_PATH?
Or maybe both?

>    * If available, use target defined search function.
>    * Look in inferior's $PATH.
>    * Look in inferior's $LD_LIBRARY_PATH.

I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
But come to think of it, do remote targets even have environment variables?
And if so -- do they inherit them from gdb / the host?  If there's a
gdbserver-type situation, and if the server is able to provide the true
environment variables from the target, then yes, we should use these.
But I don't recall any gdbserver ever offering that functionality.


> The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat more
> literal. 

I think it's supposed to be literal.

> It's only used if the path is absolute.  Then the question is, do
> we think this is correct?  Should we be searching literally at this point or
> defer that until later?
> 
> cheers,
> 
> Kris
> 
> 
> 

Re: Why does solib_open do what it does?

[Kris Warkentin]

> Kris Warkentin wrote:
> > I believe the comment does not accurately reflect the code.  Here is my
> > proposal for the new comment using the search algorithm rather than
search
> > order:
> >
> >    Search algorithm:
> >    * If there is a solib_absolute_prefix and path is absolute:
> >    *   Search for solib_absolute_prefix/path.
> >    * else
> >    *   Look for it literally (unmodified).
> >    * Look in SOLIB_SEARCH_PATH.
>
> I'm not sure -- but do you think it should be
> /SOLIB_ABSOLUTE_PREFIX/SOLIB_SEARCH_PATH?
> Or maybe both?

The problem is that you don't have the freedom to define an arbitrary path
if you always prepend solib-abs-pref to it. You can always put the full path
in your solib-search-path if you need to.

> >    * If available, use target defined search function.
> >    * Look in inferior's $PATH.
> >    * Look in inferior's $LD_LIBRARY_PATH.
>
> I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
> But come to think of it, do remote targets even have environment
variables?
> And if so -- do they inherit them from gdb / the host?  If there's a
> gdbserver-type situation, and if the server is able to provide the true
> environment variables from the target, then yes, we should use these.
> But I don't recall any gdbserver ever offering that functionality.

Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'.
This determines whether gdb will send it's environment to the target or
whether the target will inherit from the pdebug server.

> > The code seems to make the meaning of solib_ABSOLUTE_prefix somewhat
more
> > literal.
>
> I think it's supposed to be literal.

True.  Just never thought of it that way.

cheers,

Kris

Re: Why does solib_open do what it does?

[Daniel Jacobowitz]

On Wed, Jun 18, 2003 at 11:50:45AM -0700, Michael Snyder wrote:
> >   * If available, use target defined search function.
> >   * Look in inferior's $PATH.
> >   * Look in inferior's $LD_LIBRARY_PATH.
> 
> I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
> But come to think of it, do remote targets even have environment variables?
> And if so -- do they inherit them from gdb / the host?  If there's a
> gdbserver-type situation, and if the server is able to provide the true
> environment variables from the target, then yes, we should use these.
> But I don't recall any gdbserver ever offering that functionality.

None of the in-tree supported remote targets do.  It's not in the
current remote protocol as far as I know.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does solib_open do what it does?

[Daniel Jacobowitz]

On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote:
> You don't think that gdb should honor LD_LIBRARY_PATH in native
> debugging, if it is set?  Won't the linker-loader honor it?
> 
> I'd be ready to agree that, if solib-search-path is set,
> it should override LD_LIBRARY_PATH.  But if it isn't set...

As far as I'm concerned, the linker should always set the absolute
pathname, and we shouldn't be doing any of this junk.  I had to
reimplement ELF search order a few months ago.  It's considerably more
complex then what we do here - DT_RPATH for example.

> >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.)
> 
> Agreed.  Indeed, I think LD_LIBRARY_PATH is required for native,
> and always wrong for cross.  Is there any way we can use that
> distinction?  Maybe with a configure variable?

No.  Please take a look at PR gdb/633 and the discussion there.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does solib_open do what it does?

[Andrew Cagney]

>    * If available, use target defined search function.
>> >    * Look in inferior's $PATH.
>> >    * Look in inferior's $LD_LIBRARY_PATH.
> 
>>
>> I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
>> But come to think of it, do remote targets even have environment
> 
> variables?
> 
>> And if so -- do they inherit them from gdb / the host?  If there's a
>> gdbserver-type situation, and if the server is able to provide the true
>> environment variables from the target, then yes, we should use these.
>> But I don't recall any gdbserver ever offering that functionality.
> 
> 
> Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'.
> This determines whether gdb will send it's environment to the target or
> whether the target will inherit from the pdebug server.

This is a long standing design bug.

When it comes to the environment, GDB should be strictly using target 
vector methods.  The native target could then look in the hosts 
environment, the remote target query the remote end.

Andrew

Re: Why does solib_open do what it does?

[Michael Snyder]

Kris Warkentin wrote:
 >msnyder:
>>Kris Warkentin wrote:

>>I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
>>But come to think of it, do remote targets even have environment
>>variables?
> 
>>And if so -- do they inherit them from gdb / the host?  If there's a
>>gdbserver-type situation, and if the server is able to provide the true
>>environment variables from the target, then yes, we should use these.
>>But I don't recall any gdbserver ever offering that functionality.
> 
> Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'.
> This determines whether gdb will send it's environment to the target or
> whether the target will inherit from the pdebug server.

Cool, and I presume you can then read them back.
In that case, (assuming the child inherits from the target side server),
wouldn't you want LD_LIBRARY_PATH to be searched?  If the linker-loader
picks up libc from one place, but gdb picks it up from someplace else,
you're hosed.

Re: Why does solib_open do what it does?

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote:
> 
>>You don't think that gdb should honor LD_LIBRARY_PATH in native
>>debugging, if it is set?  Won't the linker-loader honor it?
>>
>>I'd be ready to agree that, if solib-search-path is set,
>>it should override LD_LIBRARY_PATH.  But if it isn't set...
> 
> 
> As far as I'm concerned, the linker should always set the absolute
> pathname, and we shouldn't be doing any of this junk. 

Well, but that is not in fact the case.  For sure not on linux,
and I don't think it is on solaris either.

Re: Why does solib_open do what it does?

[Kris Warkentin]

> >>I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
> >>But come to think of it, do remote targets even have environment
> >>variables?
> >
> >>And if so -- do they inherit them from gdb / the host?  If there's a
> >>gdbserver-type situation, and if the server is able to provide the true
> >>environment variables from the target, then yes, we should use these.
> >>But I don't recall any gdbserver ever offering that functionality.
> >
> > Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'.
> > This determines whether gdb will send it's environment to the target or
> > whether the target will inherit from the pdebug server.
>
> Cool, and I presume you can then read them back.
> In that case, (assuming the child inherits from the target side server),
> wouldn't you want LD_LIBRARY_PATH to be searched?  If the linker-loader
> picks up libc from one place, but gdb picks it up from someplace else,
> you're hosed.

Nope.  Say I've got a windows host.  My libs are in $QNX_TARGET/$CPU/usr/lib
(ie. c:\QNXsdk\target\qnx6\ppcbe\usr\lib).  On my target, LD_LIBRARY_PATH is
relative to the root, on my host, they're relative to $QNX_TARGET/$CPU.
This is where the target defined search function comes in.  We construct a
search path using $QNX_TARGET/$CPU as a base and search from there.
Actually, we set solib-absolute-prefix to $QNX_TARGET/$CPU as well so in
many cases it gets found by the very first check.

cheers,

Kris

Re: Why does solib_open do what it does?

[Kris Warkentin]

> Daniel Jacobowitz wrote:
> > On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote:
> >
> >>You don't think that gdb should honor LD_LIBRARY_PATH in native
> >>debugging, if it is set?  Won't the linker-loader honor it?
> >>
> >>I'd be ready to agree that, if solib-search-path is set,
> >>it should override LD_LIBRARY_PATH.  But if it isn't set...
> >
> >
> > As far as I'm concerned, the linker should always set the absolute
> > pathname, and we shouldn't be doing any of this junk.
>
> Well, but that is not in fact the case.  For sure not on linux,
> and I don't think it is on solaris either.

Linkers can be funny that way.  Things like the loader (in our case
ldqnx.so) don't have the full path but other libs do.

cheers,

Kris

Re: Why does solib_open do what it does?

[Daniel Jacobowitz]

On Wed, Jun 18, 2003 at 01:11:38PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote:
> >
> >>You don't think that gdb should honor LD_LIBRARY_PATH in native
> >>debugging, if it is set?  Won't the linker-loader honor it?
> >>
> >>I'd be ready to agree that, if solib-search-path is set,
> >>it should override LD_LIBRARY_PATH.  But if it isn't set...
> >
> >
> >As far as I'm concerned, the linker should always set the absolute
> >pathname, and we shouldn't be doing any of this junk. 
> 
> Well, but that is not in fact the case.  For sure not on linux,
> and I don't think it is on solaris either.

In Linux it's the case for all searched-for objects, as far as I know -
anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH,
etc. will either be an absolute path or else contain slashes and be
relative to the current directory.  If it's not true for dlopen'd
objects, well, there's no way to know where the app had chdir'd to when
it loaded them.

Do you know offhand when it's not true for GNU/Linux?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does solib_open do what it does?

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Jun 18, 2003 at 01:11:38PM -0700, Michael Snyder wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>>On Wed, Jun 18, 2003 at 11:41:02AM -0700, Michael Snyder wrote:
>>>
>>>
>>>>You don't think that gdb should honor LD_LIBRARY_PATH in native
>>>>debugging, if it is set?  Won't the linker-loader honor it?
>>>>
>>>>I'd be ready to agree that, if solib-search-path is set,
>>>>it should override LD_LIBRARY_PATH.  But if it isn't set...
>>>
>>>
>>>As far as I'm concerned, the linker should always set the absolute
>>>pathname, and we shouldn't be doing any of this junk. 
>>
>>Well, but that is not in fact the case.  For sure not on linux,
>>and I don't think it is on solaris either.
> 
> 
> In Linux it's the case for all searched-for objects, as far as I know -
> anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH,
> etc. will either be an absolute path or else contain slashes and be
> relative to the current directory.  If it's not true for dlopen'd
> objects, well, there's no way to know where the app had chdir'd to when
> it loaded them.
> 
> Do you know offhand when it's not true for GNU/Linux?

No, I just recall that, several years ago when I worked on this code,
it was not always true.

Re: Why does solib_open do what it does?

[Kris Warkentin]

> > In Linux it's the case for all searched-for objects, as far as I know -
> > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH,
> > etc. will either be an absolute path or else contain slashes and be
> > relative to the current directory.  If it's not true for dlopen'd
> > objects, well, there's no way to know where the app had chdir'd to when
> > it loaded them.
> >
> > Do you know offhand when it's not true for GNU/Linux?
>
> No, I just recall that, several years ago when I worked on this code,
> it was not always true.

Okay gentlemen, all kidding aside, what do we do?  At the bare minimum I
believe the test

  /* If not found, next search the inferior's $PATH environment variable. */
  if (found_file < 0 && solib_search_path != NULL)

should be just:

if (found_file < 0).

We can always make a decision about removing the PATH and LD_LIBRARY_PATH
checks later.

cheers,

Kris

Re: Why does solib_open do what it does?

[Kevin Buettner]

On Jun 19,  8:24am, Kris Warkentin wrote:

> > > In Linux it's the case for all searched-for objects, as far as I know -
> > > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH,
> > > etc. will either be an absolute path or else contain slashes and be
> > > relative to the current directory.  If it's not true for dlopen'd
> > > objects, well, there's no way to know where the app had chdir'd to when
> > > it loaded them.
> > >
> > > Do you know offhand when it's not true for GNU/Linux?
> >
> > No, I just recall that, several years ago when I worked on this code,
> > it was not always true.
> 
> Okay gentlemen, all kidding aside, what do we do?  At the bare minimum I
> believe the test
> 
>   /* If not found, next search the inferior's $PATH environment variable. */
>   if (found_file < 0 && solib_search_path != NULL)
> 
> should be just:
> 
> if (found_file < 0).
> 
> We can always make a decision about removing the PATH and LD_LIBRARY_PATH
> checks later.

Okay, I've come to a decision.

It's still not clear to me if the PATH and LD_LIBRARY_PATH searches
are needed for natives.  Either they're not needed or nobody's noticed
that some previously available functionality (prior to Nov 21, 2000)
is now missing.  I do know, however, that we definitely don't want to
do these searches for (most) remote targets.  In light of Michael's
remarks, I'm now inclined to be more cautious about removing these
searches than I was originally.

Further, if you're debugging a remote target, you'd better have
solib-absolute-prefix set, or things will almost certainly go wrong. 
To the best of my knowledge, when you're debugging a native target,
you never set solib-absolute-prefix, so the fact that this is set or
not gives us a cheap, but effective way to determine whether the
intent is to run on a native target or not.

Actually, it's better than that.  Something that I occassionally do is
to run against a "native" rda or gdb server where I don't set
solib-absolute-prefix.  Doing things in this fashion will make search
algorithm for this kind of "remote" (which is really a native
disguised as a remote) target identical to running a native and that
is precisely what's desired.

So...  I'd like to see the checks preceding the PATH and LD_LIBRARY_PATH
searches changed from:

  if (found_file < 0 && solib_search_path != NULL)

to:

  if (found_file < 0 && solib_absolute_prefix == NULL)

Kris, I believe you volunteered to make the necessary changes.  Would
you like to do the honors?  BTW, your proposed comment changes look
good too.  Consider these changes preapproved, but do make sure you
post the patch that you end up committing.

Thanks,

Kevin

Re: Why does solib_open do what it does?

[Kevin Buettner]

On Jun 19,  4:16pm, Kevin Buettner wrote:

> It's still not clear to me if the PATH and LD_LIBRARY_PATH searches
> are needed for natives.  Either they're not needed or nobody's noticed
> that some previously available functionality (prior to Nov 21, 2000)
> is now missing.  I do know, however, that we definitely don't want to
> do these searches for (most) remote targets.  In light of Michael's
> remarks, I'm now inclined to be more cautious about removing these
> searches than I was originally.
> 
> Further, if you're debugging a remote target, you'd better have
> solib-absolute-prefix set, or things will almost certainly go wrong. 
> To the best of my knowledge, when you're debugging a native target,
> you never set solib-absolute-prefix, so the fact that this is set or
> not gives us a cheap, but effective way to determine whether the
> intent is to run on a native target or not.
> 
> Actually, it's better than that.  Something that I occassionally do is
> to run against a "native" rda or gdb server where I don't set
> solib-absolute-prefix.  Doing things in this fashion will make search
> algorithm for this kind of "remote" (which is really a native
> disguised as a remote) target identical to running a native and that
> is precisely what's desired.

I've just thought of another way to look at this which has nothing to
do with inferences about which settings imply remote targets vs. 
which imply native targets.

When you set solib-absolute-prefix, you want all absolute paths (aside
from those constructed from solib-search-path) to be searched for
using the given prefix.  Our present search code using PATH and
LD_LIBRARY_PATH does not honor solib-absolute-prefix for absolute
paths, so it makes (some) sense to disable these searches when
solib-absolute-prefix is set.

It would probably make more sense to force the PATH and LD_LIBRARY_PATH
searches to honor solib-absolute-prefix, but before we go down that
road, I'd like to reach some definite conclusion regarding whether
these searches are really necessary.

Kevin

Re: Why does solib_open do what it does?

[Kris Warkentin]

Doh....I read the first email, made the changes and submitted the patch
before I saw this one.  Oh well, it won't hurt to have that in there for now
until we decide whether or not to prepend solib-absolute-prefix to paths.

I'm personnally of the opinion that there is MORE than enough search
capability there now.  If someone can't find a lib between what the loader
fills in, solib-search-path, solib-absolute-prefix AND target defined
searches.... I mean, how much hand-holding do we want to do?  The more you
broaden your seach, the more likely you are to get something you don't want.

cheers,

Kris

----- Original Message ----- 
From: "Kevin Buettner" <kevinb@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: "Daniel Jacobowitz" <drow@mvista.com>; "Gdb@Sources.Redhat.Com"
<gdb@sources.redhat.com>; "Michael Snyder" <msnyder@redhat.com>
Sent: Thursday, June 19, 2003 7:42 PM
Subject: Re: Why does solib_open do what it does?


> On Jun 19,  4:16pm, Kevin Buettner wrote:
>
> > It's still not clear to me if the PATH and LD_LIBRARY_PATH searches
> > are needed for natives.  Either they're not needed or nobody's noticed
> > that some previously available functionality (prior to Nov 21, 2000)
> > is now missing.  I do know, however, that we definitely don't want to
> > do these searches for (most) remote targets.  In light of Michael's
> > remarks, I'm now inclined to be more cautious about removing these
> > searches than I was originally.
> >
> > Further, if you're debugging a remote target, you'd better have
> > solib-absolute-prefix set, or things will almost certainly go wrong.
> > To the best of my knowledge, when you're debugging a native target,
> > you never set solib-absolute-prefix, so the fact that this is set or
> > not gives us a cheap, but effective way to determine whether the
> > intent is to run on a native target or not.
> >
> > Actually, it's better than that.  Something that I occassionally do is
> > to run against a "native" rda or gdb server where I don't set
> > solib-absolute-prefix.  Doing things in this fashion will make search
> > algorithm for this kind of "remote" (which is really a native
> > disguised as a remote) target identical to running a native and that
> > is precisely what's desired.
>
> I've just thought of another way to look at this which has nothing to
> do with inferences about which settings imply remote targets vs.
> which imply native targets.
>
> When you set solib-absolute-prefix, you want all absolute paths (aside
> from those constructed from solib-search-path) to be searched for
> using the given prefix.  Our present search code using PATH and
> LD_LIBRARY_PATH does not honor solib-absolute-prefix for absolute
> paths, so it makes (some) sense to disable these searches when
> solib-absolute-prefix is set.
>
> It would probably make more sense to force the PATH and LD_LIBRARY_PATH
> searches to honor solib-absolute-prefix, but before we go down that
> road, I'd like to reach some definite conclusion regarding whether
> these searches are really necessary.
>
> Kevin
>

Re: Why does solib_open do what it does?

[Kevin Buettner]

On Jun 20,  8:28am, Kris Warkentin wrote:

> Doh....I read the first email, made the changes and submitted the patch
> before I saw this one.  Oh well, it won't hurt to have that in there for now
> until we decide whether or not to prepend solib-absolute-prefix to paths.

Actually, you did the right thing.  The fix that you committed will hold
us until we figure out whether or not to retain the PATH / LD_LIBRARY_PATH
searches.

Kevin