This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415)
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 04 Sep 2013 17:55:28 +0100
- Subject: Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415)
- Authentication-results: sourceware.org; auth=none
- References: <20130826182111 dot GA19509 at host2 dot jankratochvil dot net> <21019 dot 47767 dot 404597 dot 352962 at ruffy dot mtv dot corp dot google dot com> <20130827140915 dot GA17861 at host2 dot jankratochvil dot net> <21022 dot 10862 dot 436924 dot 879667 at ruffy dot mtv dot corp dot google dot com> <20130828180359 dot GB4770 at host2 dot jankratochvil dot net> <52271009 dot 50805 at redhat dot com> <CADPb22QtWqOhAm2g6yF42arodf2Xp9frUc=YTVw=myJK-0=FPg at mail dot gmail dot com>
On 09/04/2013 05:31 PM, Doug Evans wrote:
> 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.
I don't mind either. Opening foo/bar/../baz is not the
same as opening foo/baz, if bar is a symlink. That's not usually
true when talking about "cd", though.
Maybe what we'll find out we need in the future is a knob users
can turn on to say "also print me the realpath in addition if it
differs from what I specified".
>
> Removing ./ from paths is easy and reasonable enough.
Yeah, I think we should.
>
> If gdb is debugging a new file I would have expected the old file to
> be gone from bfd's cache.
Well, or not, a valid caching policy may be to monitor memory/resource
usage, and as long as resources are available, assume the same file
will be reopened soon. I don't really know the policy here though,
it may just be the original file is only closed after the new one
is opened.
But, the issue should trigger even if not closing the old file.
Let me check...
(gdb) add-inferior -exec ./gdbserver/../gdb
Added inferior 2
Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb...done.
Setting up the environment for debugging gdb.
(top-gdb) add-inferior -exec ./gdb
Added inferior 3
Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb...done.
(top-gdb) info inferiors
Num Description Executable
3 <null> /home/pedro/gdb/mygit/build/gdb/./gdb
2 <null> /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb
* 1 <null>
Note it shows "gdbserver/../gdb" for inferior 3 too.
vs (new run from scratch):
(gdb) add-inferior -exec ./gdb
Added inferior 2
Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done.
Setting up the environment for debugging gdb.
(top-gdb) add-inferior -exec ./gdbserver/../gdb
Added inferior 3
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
3 <null> /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb
2 <null> /home/pedro/gdb/mygit/build/gdb/./gdb
* 1 <null>
Note it shows "./gdb" for inferior 2 too.
> [The problem may be in the sequencing.]
Yep, whatever is used first is reused.
> We do need to be consistent with which flavor of a path we use.
--
Pedro Alves