This is the mail archive of the 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: GDB honouring RPATH in binaries.

On Thu, Feb 20, 2003 at 12:33:01PM -0700, Kevin Buettner wrote:
> On Feb 20,  2:15pm, Kris Warkentin wrote:
> > I've been having a debate with some coworkers about whether or not gdb
> > should use the rpath in an elf binary to find shared libs if it has been
> > set.  The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
> > that order and the proposal was that gdb should do the same thing.
> > 
> > The problem I have with this is in the remote case.  This might make perfect
> > sense on a self-hosted debugger but if targetting a remote machine, the
> > RPATH might not make any logical mapping onto the host machine's filesystem.
> > It might be possible to come up with some sort of heuristic using
> > solib-absolute-prefix as a base but I don't think there's any reliable way
> > to make use of this info if not self hosted.
> > 
> > Any thoughts?
> The other problem that I see is that the procedures used to resolve
> the location of a dynamic library will vary depending upon the runtime
> loader.  E.g, on Linux, I am pretty sure that RPATH supercedes
> It may make sense to have a osabi dependent method for doing this
> resolution.  Or maybe this machinery should be tied to the solib
> back end.  (That way if you had a qnx back end, it would get used
> automatically.)
> With regard to the remote case, I would have thought that simply
> prepending solib-absolute-prefix would give the correct results.

Question: when do we need to find shared libraries that we can't use a
full path + solib-absolute-prefix, where RPATH would be in the least
useful?  RPATH only matters when you have multiple places you could
find the library and are interested in which one you got; if there is a
mapping between target and host filesystems, it should be
solib-absolute-prefix only.

We generally get full pathnames of loaded modules from the dynamic
linker, and use that.  Is this a problem for QNX?

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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