We are planning to ask other tools to support SOURCE_PREFIX_MAP, in the same way that we have already done this for SOURCE_DATE_EPOCH. So, this will last for some time and have quite wide reach. Consequently, we believe it is better to split on the final '=', since it is much less likely to result in problems.
For example, with the previous behaviour (splitting on the first '=') it would not be possible to map paths like the following: C:\Documents and Settings\Betrand Russell\Proofs of 1+1=2\Automated Proofs\Source Code\ /srv/net/distributed-hash-table/address/VaIWP8YIWDChR2O76yiufXBsbw5g2skB_kp9VP-qVLvydovdGw==/projects/gcc-6/ These are contrived examples, but hopefully you can agree that they're not *so* unrealistic - future software or users might plausibly wish to run reproducible build processes underneath paths similar to these. On the other hand, I can think of much fewer cases where the new-prefix *must* include a '=' character. I can't think of any software project that includes it, and I'd imagine that any such (or future) projects that might exist would already have standardised "ASCII-only" versions of its name. ChangeLogs ---------- gcc/ChangeLog: 2016-11-01 Ximin Luo <infini...@pwned.gg> * final.c: (add_debug_prefix_map): Split on the last and not first '='. * doc/invoke.texi (Environment Variables): Update SOURCE_PREFIX_MAP to describe new parsing. Index: gcc-7-20161030/gcc/final.c =================================================================== --- gcc-7-20161030.orig/gcc/final.c +++ gcc-7-20161030/gcc/final.c @@ -1528,7 +1528,7 @@ add_debug_prefix_map (const char *arg) debug_prefix_map *map; const char *p; - p = strchr (arg, '='); + p = strrchr (arg, '='); if (!p) { error ("invalid value %qs for debug-prefix-map", arg); Index: gcc-7-20161030/gcc/doc/invoke.texi =================================================================== --- gcc-7-20161030.orig/gcc/doc/invoke.texi +++ gcc-7-20161030/gcc/doc/invoke.texi @@ -26233,8 +26233,8 @@ output by higher-level build processes. The form and behaviour is similar to @option{-fdebug-prefix-map}. That is, the value of @env{SOURCE_PREFIX_MAP} must be of the form -@samp{@var{old}=@var{new}}. The split occurs on the first @code{=} -character, so that @var{old} cannot itself contain a @code{=}. +@samp{@var{old}=@var{new}}. The split occurs on the last @code{=} +character, so that @var{new} cannot itself contain a @code{=}. Whenever an absolute source- or build-related filepath is to be emitted in a final end-result output, GCC will replace @var{old} with @var{new}