[Bug gdb/23764] New: Python Objfile.filename documentation does not match behavior (symlinks)

[anssi.hannula at bitwise dot fi]

https://sourceware.org/bugzilla/show_bug.cgi?id=23764

Bug ID: 23764
Summary: Python Objfile.filename documentation does not match
behavior (symlinks)
Product: gdb
Version: HEAD
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: anssi.hannula at bitwise dot fi
Target Milestone: ---

Created attachment 11319
--> https://sourceware.org/bugzilla/attachment.cgi?id=11319&action=edit
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).