https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848
Bug ID: 68848
Summary: allow -fdebug-prefix-map to read OLD prefix from
environment (improve reproducibility)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dkg at fifthhorseman dot net
Target Milestone: ---
Created attachment 36989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36989&action=edit
allow reading OLD argument to -fdebug-prefix-map from environment
Work on the reproducible-builds project [0] has identified that build
paths are one cause of output variation between builds. This
changeset allows users to avoid this variation when building C objects
with debug symbols, while leaving the default behavior unchanged.
Background
----------
gcc includes the build path in any generated DWARF debugging symbols,
specifically in DW_AT_comp_dir, but allows the embedded path to be
changed via -fdebug-prefix-map.
When -fdebug-prefix-map is used with the current build path, it
removes the build path from DW_AT_comp_dir but places it instead in
DW_AT_producer, so the reproducibility problem isn't resolved.
When building software for binary redistribution, the actual build
path on the build machine is irrelevant, and doesn't need to be
exposed in the debug symbols.
Resolution
----------
This patch extends the first argument to -fdebug-prefix-map ("old") to
be able to read from the environment, which allows a packager to avoid
embedded build paths in the debugging symbols with something like:
export SOURCE_BUILD_DIR="$(pwd)"
gcc -fdebug-prefix-map=\$SOURCE_BUILD_DIR=/usr/src
Details
-------
Specifically, if the first character of the "old" argument is a
literal $, then gcc will treat it as an environment variable name, and
use the value of the env var for prefix mapping.
As a result, DW_AT_producer contains the literal envvar name,
DW_AT_comp_dir contains the transformed build path, and the actual
build path is not at all present in the generated object file.
This has been tested successfully on amd64 machines, and i see no
reason why it would be platform-specific.
More discussion of alternate approaches considered and discarded in
the development of this change can be found at [1] for those
interested.
Feedback welcome!
[0] https://reproducible-builds.org
[1]
https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20151130/004051.html
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01168.html
