Why GDB ignores relative RPATH to find shared libraries?

[Ansis Atteka <ansisatteka dot dev at gmail dot com>]

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