Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415) https://sourceware.org/ml/gdb-patches/2013-09/msg00138.html Message-ID: <52276600.7010706@redhat.com> 3 <null> /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb 2 <null> /home/pedro/gdb/mygit/build/gdb/./gdb Problem #1: ./ could be removed/simplified. Problem #2: gdbserver/../ could be also removed/simplified But argv[0] should be kept possibly unchanged from the user input. This also means argv[0] should be kept in relative (not absolute pathname) form; but GDB should better display absolute pathnames to user, which will not match argv[0] much. Going to use gdb_realpath_keepfile() (former xfullpath()) so the directories get lost even for inferior argv[0]. Inferiors care only about exact basename in argv[0] anyway. The goal of this PR fix would be to pass argv[0] unchanged to inferior while still displaying it to user in both convenient (canonical absolute form) but also the exact argv[0] form (original form, even if relative).
I have a somewhat similar problem. Suppose the user does 'file zzz', where zzz is a symlink. Then, after running, the user resets the symlink to point to some other file. In this case, gdb won't change -- because the realpath'ing in the objfile creation path will wind up resolving the symlink, and so reread_symbols will think nothing has changed. Locally this is complicated by the fact that we have a workaround for the Windows gnulib/BFD stat mismatch bug in place. I think my partial solution will be to remove OPF_RETURN_REALPATH from symfile_bfd_open. A full solution for this bug would probably involve storing the user-specified name in the objfile and then changing various spots in gdb to use that. That is, the objfile would need one name and the BFD would get another.
I suppose only the executable would need any special treatment. But for that, I wonder how it would work in the startup-with-shell case. Without a shell, gdb can easily control argv[0]. With a shell, it seems harder, particularly if the executable was specified relative to one working directory, but then the cwd was changed in the gdb session.
See also bug #24143. I have a patch that fixes that one (basically what I wrote here in comment #1) and so gets this one a little closer.