Why GDB ignores relative RPATH to find shared libraries?

Why GDB ignores relative RPATH to find shared libraries?

[Ansis Atteka]

Hello,

This is actually a suggestion of how GDB might make easier coredump
analysis when RPATH with $ORIGIN is used to specify relative paths to
shared libraries.

Use case:
I have a program which runs on a different machine than it was built
on. It uses some system shared libraries (in "/lib" directory) and
also some of our own shared libraries (in "/opt/application/lib"
directory). The executable itself is in "/opt/application/bin". So
path to my libraries is relative with respect to executable (obviously
the path to my private libs will be "../lib" from
"/opt/application/bin").

The problem is that whenever I need to do remote coredump analysis on
development workstation I always have to make sure that GDB uses
correct shared libraries. So is there a reason why gdb ignores
relative $ORIGIN RPATH and does not automatically load my libs from
correct rpath whenever I do "gdb /path/to/executable
/path/to/coredump?

It seems that GDB favours the paths to shared libraries specified in
coredump file instead of those specified in executable and that is not
portable for remote analysis. The only case when GDB should favour
path to shared libraries from coredump is when executable itself
loaded shared library with dlopen().

Other solutions, which I do not like that much:
1. Use relative LD_LIBRARY_PATH=../lib. The problem with this approach
is that it sets relative path in respect to Current Working Directory
instead of respect to Executable. And of course LD_LIBRARY_PATH leads
to other problems...
2. Set *.so lib paths from GDB manually. Extra overhead of work which
might lead to other problems. I would prefer that I could simply copy
coredump to my build products and do analysis right away without
setting any paths explicitly.

Best regards,
Ansis Atteka

Re: Why GDB ignores relative RPATH to find shared libraries?

[Jan Kratochvil]

On Fri, 19 Nov 2010 02:31:11 +0100, Ansis Atteka wrote:
> It seems that GDB favours the paths to shared libraries specified in
> coredump file instead of those specified in executable

It does not favor them but it never reads them at all.  GDB uses only the
_r_debug inferior shared library list.

rm -rf xbin xlib core.*;mkdir xbin xlib;:|gcc -x c - -shared -fPIC -o xlib/libx.so -Wl,-soname,libx.so;echo 'main(){*(int*)0=0;}'|gcc -o xbin/bin -x c - -Lxlib -lx -Wl,-rpath,'$ORIGIN/../xlib';(ulimit -c unlimited;./xbin/bin);gdb -nx xbin/bin ./core.*

define sharedlist
        set var $sharedlist_iter=_r_debug.r_map
        while ($sharedlist_iter)
                print $sharedlist_iter->l_name
                set var $sharedlist_iter=$sharedlist_iter->l_next
        end
end

(gdb) sharedlist 
$5 = 0x35f0419a74 ""
$6 = 0x35f0419a74 ""
$7 = 0x7f56709fb7b0 "/home/jkratoch/t/libs/xbin/../xlib/libx.so"
$8 = 0x7f56709fbca0 "/lib64/libc.so.6"
$9 = 0x400200 "/lib64/ld-linux-x86-64.so.2"

There is no $ORIGIN present anywhere in the inferior's list of currently
loaded shared libraries.  (Not even in the glibc internal link_map structure.)


This is sometimes a problem you cannot put breakpoints (without just making
them `pending') into shared libraries before you `start' the program, as GDB
does not know which shared libraries may get loaded.
Filed http://sourceware.org/bugzilla/show_bug.cgi?id=12249 RFE for it.


> and that is not portable for remote analysis.

Currently even ld.so never suggests when it used $ORIGIN:

LD_DEBUG=all ./xbin/bin 2>&1 |grep libx|grep -v symbol=
     26462:	file=libx.so [0];  needed by ./xbin/bin [0]
     26462:	find library=libx.so [0]; searching
     26462:	  trying file=/home/jkratoch/t/libs/xbin/../xlib/tls/x86_64/libx.so
     26462:	  trying file=/home/jkratoch/t/libs/xbin/../xlib/tls/libx.so
     26462:	  trying file=/home/jkratoch/t/libs/xbin/../xlib/x86_64/libx.so
     26462:	  trying file=/home/jkratoch/t/libs/xbin/../xlib/libx.so
     26462:	file=libx.so [0];  generating link map
     26462:	checking for version `GLIBC_2.2.5' in file /lib64/libc.so.6 [0] required by file /home/jkratoch/t/libs/xbin/../xlib/libx.so [0]
     26462:	relocation processing: /home/jkratoch/t/libs/xbin/../xlib/libx.so (lazy)
     26462:	binding file /home/jkratoch/t/libs/xbin/../xlib/libx.so [0] to /lib64/libc.so.6 [0]: normal symbol `__cxa_finalize' [GLIBC_2.2.5]
     26462:	calling init: /home/jkratoch/t/libs/xbin/../xlib/libx.so

But GDB could it from DT_RPATH.

Filed http://sourceware.org/bugzilla/show_bug.cgi?id=12250 RFE for it.


Thanks,
Jan