Created attachment 11319 [details]
Simple shell script to reproduce the issue

The Python API documentation ( https://sourceware.org/gdb/onlinedocs/gdb/Objfiles-In-Python.html ) says:

Variable: Objfile.filename

    The file name of the objfile as a string, with symbolic links resolved. 


But symbolic links do not actually seem resolved.


Simple testcase attached, output when run on gdb HEAD as of 2018-10-12:

$ GDB=./gdb sh test.sh
++ readlink -f ./gdb
+ GDB=/home/anssiha/sec/git/gdb-inst/bin/gdb
++ mktemp -d
+ TDIR=/tmp/tmp.fPvjnaCmLN
+ cd /tmp/tmp.fPvjnaCmLN
+ mkdir -p testdir
+ gcc -shared -o testdir/libtest.so -x c /dev/null
+ cat
+ ln -s testdir testdir2
+ ln -sf libtest.so testdir/libtest2.so
+ echo 'int main() {}'
+ gcc -x c -o testdir/foo - -Ltestdir2 -ltest2
+ LD_LIBRARY_PATH=/tmp/tmp.fPvjnaCmLN/testdir2
+ /home/anssiha/sec/git/gdb-inst/bin/gdb --batch -ex 'set auto-load safe-path /tmp/tmp.fPvjnaCmLN' -ex run testdir/foo
objfile.filename /tmp/tmp.fPvjnaCmLN/testdir2/libtest2.so
[Inferior 1 (process 10048) exited normally]

So neither the file symlink (libtest2.so => libtest.so) nor the path component symlink (testdir2 => testdir) was actually resolved.

GDB has internally resolved the symlinks, though, as it loads the autoload file using the resolved path (testdir/libtest.so-gdb.py instead of testdir2/libtest2.so-gdb.py).


I observed similar behavior with v8.1.

For the record, I noticed this when debugging GCC libstdc++.so.*-gdb.py not being able to find its python modules. It does that using the Objfile.filename directory as a starting point, but that directory can vary if the library is loaded from a different directory via a symlink (in my case, /lib vs /usr/lib).