On Tue, Nov 01, 2022 at 01:46:20PM -0600, Jeff Law via Gcc-patches wrote:
> > This does cause a change of behaviour if users were previously relying upon
> > symlinks or absolute paths not being resolved.
>
> I'm not too worried about this scenario.

As mentioned in the PR, this patch breaks e.g. ccache testsuite.

I strongly doubt most of the users want such a behavior, because it
makes all filenames absolute when -f*-prefix-map= options remap one
absolute path to another one.
Say if I'm in /tmp and /tmp is the canonical path and there is
src/test.c file, with -fdebug-prefix-map=/tmp=/blah
previously there would be DW_AT_comp_dir "/blah" and it is still there,
but DW_AT_name which was previouly "src/test.c" (relative against
DW_AT_comp_dir) is now "/blah/src/test.c" instead.

Even worse, the canonicalization is only done on the remap_filename
argument, but not on the old_prefix side.  That is e.g. what breaks
ccache.  If there is
/tmp/foobar1 directory and
ln -sf foobar1 /tmp/foobar2
cd /tmp/foobar2
then -fdebug-prefix-map=`pwd`:/blah will just not work, while
src/test.c will be canonicalized to /tmp/foobar1/src/test.c,
old_prefix is still what the user provided which is /tmp/foobar2.
User would need to change their uses to use -fdebug-prefix-map=`realpath $(pwd)`=/blah

I've created 3 patches for this.

The first patch just reverts the patch (and its follow-up patch).

The second introduces a new option, -f{,no}-canon-prefix-map which affects
the behavior of -f{file,macro,debug,profile}-prefix-map=, if on it
canonicalizes the old path of the prefix map option and compares that
against the canonicalized filename for absolute paths but not relative.

And last is like the second, but does that also for relative paths except
for filenames with no / (or / or \ on DOS based fs).  So, the third patch
gets an optional behavior of what has been on the trunk lately with the
difference that the old_prefix is canonicalized by the compiler.

Initially I've thought I'd just add some magic syntax to the OLD=NEW
argument of those options (because there are 4 of them), but as noted
in the comments, = is valid char in OLD (just not new), so it would
be hard to figure out some syntax.  So instead a new option, which one
can turn on and off for different -f*-prefix-map= options if needed.

-fdebug-prefix-map=/path1=/mypath1 -fcanon-prefix-map \
-fdebug-prefix-map=/path2=/mypath2 -fno-canon-prefix-map \
-fdebug-prefix-map=/path3=/mypath3

will use the old behavior for the /path1 and /path3 handling and
the new one only for /path2 handling.

This commit is the third patch described above.

2023-03-10  Jakub Jelinek  <jakub@redhat.com>

	PR other/108464
	* common.opt (fcanon-prefix-map): New option.
	* opts.cc: Include file-prefix-map.h.
	(flag_canon_prefix_map): New variable.
	(common_handle_option): Handle OPT_fcanon_prefix_map.
	(gen_command_line_string): Ignore OPT_fcanon_prefix_map.
	* file-prefix-map.h (flag_canon_prefix_map): Declare.
	* file-prefix-map.cc (struct file_prefix_map): Add canonicalize
	member.
	(add_prefix_map): Initialize canonicalize member from
	flag_canon_prefix_map, and if true canonicalize it using lrealpath.
	(remap_filename): Revert 2022-11-01 and 2022-11-07 changes,
	use lrealpath result only for map->canonicalize map entries.
	* lto-opts.cc (lto_write_options): Ignore OPT_fcanon_prefix_map.
	* opts-global.cc (handle_common_deferred_options): Clear
	flag_canon_prefix_map at the start and handle OPT_fcanon_prefix_map.
	* doc/invoke.texi (-fcanon-prefix-map): Document.
	(-ffile-prefix-map, -fdebug-prefix-map, -fprofile-prefix-map): Add
	see also for -fcanon-prefix-map.
	* doc/cppopts.texi (-fmacro-prefix-map): Likewise.