https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
Bug ID: 101473
Summary: LTO makes debug info depend on toolchain path
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: tonyb at cybernetics dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When compiling with -flto -g, the resulting debug info varies depending on the
install path of the compiler toolchain. This is a problem for reproducible
builds (https://reproducible-builds.org/) when the compiler toolchain is
installed in the user home directory. For example, when compiling a file
lto_test.c with the same toolchain copied into two different paths, readelf -a
shows the following:
toolchain path 1:
23: 00000000000005f5 0 NOTYPE WEAK HIDDEN 28 lto_test.c.79b8ff9a
toolchain path 2:
42: 00000000000005f5 0 NOTYPE WEAK HIDDEN 28 lto_test.c.bba5e59b
The -frandom-seed flag does not help in this case. The output is deterministic
(same output across multiple runs).
With -flto disabled, the problem goes away. Non-LTO binaries are identical
regardless of the compiler toolchain path.
Stripping the debug info from the LTO binaries makes them identical, but using
"objcopy --add-gnu-debuglink" makes them different again because the embedded
checksum for the debug info is different.
I encountered this problem trying to make reproducible builds with -flto under
Yocto. Here is the Yocto bug report, including test code for Yocto:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481
Regarding the "LTO reproducible build test" attachment in the Yocto bug report:
Yocto sets up the compiler toolchain in a "recipe-sysroot-native" directory and
the system lib/, include/, and such in a "recipe-sysroot" directory, which are
prepared by running "bitbake lto-test". Then the run-lto-test script makes two
copies of the compiler toolchain under two differnet names using "cp -rl",
compiles the simple test program using both toolchains, and compares them.
Comment 6 on this bug may be related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305#c6