This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why does solib_open do what it does?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]