Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415)

[Doug Evans <dje@google.com>]

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.