[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599

["richard.purdie at linuxfoundation dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464

--- Comment #3 from Richard Purdie <richard.purdie at linuxfoundation dot org> ---
(In reply to Jakub Jelinek from comment #2)
> Dunno about other uses of remap_filename, but for remap_debug_filename what
> that commit changed doesn't seem to be ever appropriate.

I think it depends on your use case. For example if via debug-prefix-map you
say you want:

/somepath/somesources translated to /somewhere

and then some code references ../somesources and ../../somesources from it's
build tree, would you want the user to have to add mappings for those and any
other combination some build system might end up generating due to it's source
layout?

>  Users pass often
> pass what they get from pwd to -fdebug-prefix-map=, and that is usually not
> the canonicalized path.  And DW_AT_comp_dir was that same path as well and
> IMHO it would be a very bad idea to change that.  Debug info contains
> relative paths in many cases, that also shouldn't be canonicalized, should
> be whatever user used in -I etc. options or #include paths etc.
> If one is mixing absolute paths and some are canonical and others aren't,
> one can use multiple -fdebug-prefix-map= options.  But ignoring what user
> asked for is just wrong.

It can be argued that if you ask for my above example and it doesn't remap the
relative accesses, it is also just wrong.

I can say that with all the cross compiling we do (in Yocto Project), making
this handle the corner cases improved our binary reproducibility quite
significantly. gcc can revert the change but we'd just have to patch something
in to handle this.

Another possible option is to resolve both sides of the equation before
deciding to remap or not (i.e. the directory in debug-prefix-map and the
potential target)?