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

Reply via email to