[commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415)
Doug Evans
dje@google.com
Wed Sep 4 16:31:00 GMT 2013
On Wed, Sep 4, 2013 at 3:48 AM, Pedro Alves <palves@redhat.com> wrote:
> It seems this patch introduces some output inconsistency
> (only tried mainline):
>
> $ ./gdb
> ...
> (gdb) file ./gdb
> Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done.
> Setting up the environment for debugging gdb.
> (top-gdb) info inferiors
> Num Description Executable
> * 1 <null> /home/pedro/gdb/mygit/build/gdb/./gdb
> (top-gdb)
>
> Note "gdb/gdb" vs "gdb/./gdb".
>
> (top-gdb) file gdbserver/../gdb
> Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/gdb"? (y or n) y
> Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done.
> (top-gdb) info inferiors
> Num Description Executable
> * 1 <null> /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb
> (top-gdb)
>
> Note ".../gdb/gdb" vs ".../gdb/gdbserver/../gdb".
>
> I tried your new series at
> <https://sourceware.org/ml/gdb-patches/2013-08/msg00837.html>, and
> seems there's still some inconsistency:
>
> (gdb) file ./gdb
> Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done.
> Setting up the environment for debugging gdb.
> (top-gdb) info inferiors
> Num Description Executable
> * 1 <null> /home/pedro/gdb/mygit/build/gdb/./gdb
> (top-gdb) info files
> Symbols from "/home/pedro/gdb/mygit/build/gdb/./gdb".
> Local exec file:
> `/home/pedro/gdb/mygit/build/gdb/./gdb', file type elf64-x86-64.
>
> This one's consistent now, but then this one's odd:
>
> (top-gdb) file gdbserver/../gdb
> Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/./gdb"? (y or n) y
> Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done.
>
> (top-gdb) info inferiors
> Num Description Executable
> * 1 <null> /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb
> (top-gdb)
>
> Hmm. It seems to only happen after having loaded "./gdb" first. This
> sounds like related to the filename handling in the gdb/bfd cache? GDB
> finds reuses the same bfd (as gdbserver/../gdb is the same file as
> the previous ./gdb), and then we printing the filename that had
> been associated with the bfd before, instead of the one that was
> specified in the second "file" ?
Hi. Some random thoughts.
If the user wants to debug foo/bar/../baz, I don't mind gdb printing
it as foo/bar/../baz.
Other's might of course.
Removing ./ from paths is easy and reasonable enough.
If gdb is debugging a new file I would have expected the old file to
be gone from bfd's cache.
[The problem may be in the sequencing.]
We do need to be consistent with which flavor of a path we use.
More information about the Gdb-patches
mailing list