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

[Jan Kratochvil <jan.kratochvil@redhat.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