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

["anssi.hannula at bitwise dot fi" <sourceware-bugzilla at sourceware dot org>]

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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.