[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #36989|0 |1 is obsolete|| --- Comment #1 from Daniel Kahn Gillmor --- Created attachment 37001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37001=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix) I'm attaching an updated patch that uses an "ENV:" prefix instead of a literal "$", because the "$" is messy to pass through a complex build chain without a lot of escaping. So the reproducible use case would be something like: export SOURCE_BUILD_DIR="$(pwd)" gcc -fdebug-prefix-map=ENV:SOURCE_BUILD_DIR=/usr/src
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37004|0 |1 is obsolete|| --- Comment #4 from Daniel Kahn Gillmor --- Created attachment 37005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37005=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix)
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37003|0 |1 is obsolete|| --- Comment #3 from Daniel Kahn Gillmor --- Created attachment 37004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37004=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix)
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 --- Comment #5 from Daniel Kahn Gillmor --- Created attachment 37007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37007=edit ignore -fdebug-prefix-map when generating DW_AT_producer Here is an alternate approach (suggested by Bernd Schmidt): just avoid writing -fdebug-prefix-map to the DW_AT_producer field entirely.
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37001|0 |1 is obsolete|| --- Comment #2 from Daniel Kahn Gillmor --- Created attachment 37003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37003=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix) the v3 patch fixes coding conventions (thanks, Bernd Schmidt!)
[Bug debug/68848] New: allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
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=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
[Bug lto/66305] -ffat-lto-objects create unreproducible objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305 Daniel Kahn Gillmor changed: What|Removed |Added CC||dkg at fifthhorseman dot net --- Comment #5 from Daniel Kahn Gillmor --- (In reply to lunar from comment #3) > Would using a hash over the section content work? In any cases, in the context > of Debian (this applies for FreeBSD as well), we have a canonical build path > so it would probably be fine to use it as the source of the hash. Please don't embed the full canonical build path into the solution for this. It seems possible to vary the build path successfully and produce the same output (see bug 68848 for a minor fix needed for debugging symbols), so it would be a shame to re-embed it here. > I guess one could already do this without further help by giving the > build path to `-frandom-seed=`. This only would need some Makefile trickery. using a cryptographic digest of the file contents would require roughly the same Makefile trickery without forcing a canonicalized build path.
