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: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches at sourceware dot org
- Date: Wed, 4 Sep 2013 21:13:06 +0200
- 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>
On Wed, 04 Sep 2013 12:48:41 +0200, Pedro Alves 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".
That is correct, you have specified different "file" parameter, therefore
those inferiors will be executed with different argv[0].
Just the name is displayed in absolute form (with CWD prepended) - argv[0]
will be supplied exactly as given by the user (relatively in your case).
The other possibility would be to really display argv[0]:
* 1 <null> ./gdb
+
* 1 <null> gdbserver/../gdb
But I think the current output above is preferred.
> I tried your new series at
> <https://sourceware.org/ml/gdb-patches/2013-08/msg00837.html>, and
> seems there's still some inconsistency:
I have found the series does not make much sense, going to rework it first.
When bfd->filename no longer contains the canonical form then we could use it
as its original filename, couldn't we? No, we can't because it can be shared
from cache so it may be original filename of an unrelated file.
As long as bfd's are shared (based on their canonical name) it does not make
sense to put to bfd->filename anything besides the canonical name.
But I think objfile->name can store the original (non-canonical) filename.
exec_bfd does not have its objfile - it has symfile_objfile which does not
have to be equal and argv[0] should IMO correspond rather to exec_bfd than to
correspond to symfile_objfile. But we have already exec_filename for exec_bfd
so that is no longer a problem.
Going to code new series how it will work, thanks for the feedback.
In reality xfullpath() (canonical directories, filename intact) was a perfect
match as it resolved all relative references to directories while it kept
argv[0] in original form (as inferiors generally care only about filename in
argv[0] and not about directories in argv[0]; except for GDB relocatability
although there it does not matter if the path is canonicalized or not).
Just so far I still do not think it is worth it reintroducing xfullpath.
Jan