set env affects host?

set env affects host?

[Graeme Peterson]

Hi, all.

In gdb, according to the help, typing "set env LD_LIBRARY_PATH=<some_path>"
should set the env var LD_LIBRARY_PATH for the inferior.

In gdb-5.2.1 (on QNX6), it seems that it also affects the host, in that
symbol information for shared objects is now searched for in that new
LD_LIBRARY_PATH.

So, on my host I have the libs in "/<target_cpu>/lib/test/".  On my target
they live in "/lib/test". 

In order for GDB to both load the symbols and allow the inferior to run, I
have to have both "/lib/test" and "/<target_cpu>/lib/test" in the set env
LD_LIBRARY_PATH command.

I do not have the ability to check this with "target remote" on a non-QNX
setup.

Can anyone verify if this is expected behavior?  It seems to me that the
new LD_LIBRARY_PATH should be passed to the inferior only, and that GDB's
environment (if solib-search-path is not set) should be used for loading
shared object symbols.

Thanks in advance.
GP

Re: set env affects host?

[Graeme Peterson]

Well, I think I have answered my own question by checking in the
source.  I found a comment in solib.c for solib_open that says that solib
symbols are found in the inferior's LD_LIBRARY_PATH, and never in the
host's.  So I guess that is that.  :-)

   Search order:
   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
   * If path is absolute or relative, look for it literally (unmodified).
   * Look in SOLIB_SEARCH_PATH.
   * Look in inferior's $PATH.
   * Look in inferior's $LD_LIBRARY_PATH.

Anyone care to comment on the rationale behind the behavior?  Clearly it
seemed reasonable to me to find the solibs for symbols in the host's
LD_LIBRARY_PATH, but that is wrong.

Thanks.
GP

On Wed, 13 Nov 2002, Graeme Peterson wrote:

> 
> Hi, all.
> 
> In gdb, according to the help, typing "set env LD_LIBRARY_PATH=<some_path>"
> should set the env var LD_LIBRARY_PATH for the inferior.
> 
> In gdb-5.2.1 (on QNX6), it seems that it also affects the host, in that
> symbol information for shared objects is now searched for in that new
> LD_LIBRARY_PATH.
> 
> So, on my host I have the libs in "/<target_cpu>/lib/test/".  On my target
> they live in "/lib/test". 
> 
> In order for GDB to both load the symbols and allow the inferior to run, I
> have to have both "/lib/test" and "/<target_cpu>/lib/test" in the set env
> LD_LIBRARY_PATH command.
> 
> I do not have the ability to check this with "target remote" on a non-QNX
> setup.
> 
> Can anyone verify if this is expected behavior?  It seems to me that the
> new LD_LIBRARY_PATH should be passed to the inferior only, and that GDB's
> environment (if solib-search-path is not set) should be used for loading
> shared object symbols.
> 
> Thanks in advance.
> GP
> 
> 

Re: set env affects host?

[Paul Koning]

>>>>> "Graeme" == Graeme Peterson <gp@qnx.com> writes:

 Graeme> Well, I think I have answered my own question by checking in
 Graeme> the source.  I found a comment in solib.c for solib_open that
 Graeme> says that solib symbols are found in the inferior's
 Graeme> LD_LIBRARY_PATH, and never in the host's.  So I guess that is
 Graeme> that.  :-)

 Graeme> Search order: * If path is absolute, look in
 Graeme> SOLIB_ABSOLUTE_PREFIX.  * If path is absolute or relative,
 Graeme> look for it literally (unmodified).  * Look in
 Graeme> SOLIB_SEARCH_PATH.  * Look in inferior's $PATH.  * Look in
 Graeme> inferior's $LD_LIBRARY_PATH.

 Graeme> Anyone care to comment on the rationale behind the behavior?
 Graeme> Clearly it seemed reasonable to me to find the solibs for
 Graeme> symbols in the host's LD_LIBRARY_PATH, but that is wrong.

Looking in the host LD_LIBRARY_PATH, or for that matter using absolute
names literally, is likely to be wrong for cross-debugging.
Fortunately the literal lookup is not the first thing tried, but as
far as I'm concerned it might as well go away entirely if host !=
target. 

	paul

Re: set env affects host?

[Daniel Jacobowitz]

On Wed, Nov 13, 2002 at 05:47:56PM -0500, Paul Koning wrote:
> >>>>> "Graeme" == Graeme Peterson <gp@qnx.com> writes:
> 
>  Graeme> Well, I think I have answered my own question by checking in
>  Graeme> the source.  I found a comment in solib.c for solib_open that
>  Graeme> says that solib symbols are found in the inferior's
>  Graeme> LD_LIBRARY_PATH, and never in the host's.  So I guess that is
>  Graeme> that.  :-)
> 
>  Graeme> Search order: * If path is absolute, look in
>  Graeme> SOLIB_ABSOLUTE_PREFIX.  * If path is absolute or relative,
>  Graeme> look for it literally (unmodified).  * Look in
>  Graeme> SOLIB_SEARCH_PATH.  * Look in inferior's $PATH.  * Look in
>  Graeme> inferior's $LD_LIBRARY_PATH.
> 
>  Graeme> Anyone care to comment on the rationale behind the behavior?
>  Graeme> Clearly it seemed reasonable to me to find the solibs for
>  Graeme> symbols in the host's LD_LIBRARY_PATH, but that is wrong.
> 
> Looking in the host LD_LIBRARY_PATH, or for that matter using absolute
> names literally, is likely to be wrong for cross-debugging.
> Fortunately the literal lookup is not the first thing tried, but as
> far as I'm concerned it might as well go away entirely if host !=
> target. 

I think that was the consensus the last time this came up: cross
debuggers should only do some of those.  Check the large discussion
resulting from gdb/633.

Either local/remote or native/cross should control this; someone just
needs to decide the exact behavior and implement it :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: set env affects host?

[gp]

Thanks Paul, Daniel.

Knowing how it works (on my part) helps!  ;-)  The more I think about it, it 
seems right that LD_LIBRARY_PATH be used only for loading solibs at runtime 
(whether on the host or the target) and that a different env-var/mechanism be 
used for the symbol file search path.

I (obviously) could see it the other way, too, but this does make sense, and 
has the benefit of being how it actually works...  ;-)

Thanks again.  I will check thread 633 on this.

Regards,
GP

Daniel Jacobowitz <drow@mvista.com> said:

> On Wed, Nov 13, 2002 at 05:47:56PM -0500, Paul Koning wrote:
> > >>>>> "Graeme" == Graeme Peterson <gp@qnx.com> writes:
> > 
> >  Graeme> Well, I think I have answered my own question by checking in
> >  Graeme> the source.  I found a comment in solib.c for solib_open that
> >  Graeme> says that solib symbols are found in the inferior's
> >  Graeme> LD_LIBRARY_PATH, and never in the host's.  So I guess that is
> >  Graeme> that.  :-)
> > 
> >  Graeme> Search order: 
> >  Graeme> * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.  
> >  Graeme> * If path is absolute or relative, look for it literally
> >  Graeme>   (unmodified).  
> >  Graeme> * Look in SOLIB_SEARCH_PATH.  
> >  Graeme> * Look in inferior's $PATH.  
> >  Graeme> * Look in inferior's $LD_LIBRARY_PATH.
> > 
> >  Graeme> Anyone care to comment on the rationale behind the behavior?
> >  Graeme> Clearly it seemed reasonable to me to find the solibs for
> >  Graeme> symbols in the host's LD_LIBRARY_PATH, but that is wrong.
> > 
> > Looking in the host LD_LIBRARY_PATH, or for that matter using absolute
> > names literally, is likely to be wrong for cross-debugging.
> > Fortunately the literal lookup is not the first thing tried, but as
> > far as I'm concerned it might as well go away entirely if host !=
> > target. 
> 
> I think that was the consensus the last time this came up: cross
> debuggers should only do some of those.  Check the large discussion
> resulting from gdb/633.
> 
> Either local/remote or native/cross should control this; someone just
> needs to decide the exact behavior and implement it :)
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 



--