From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BD3173850402; Fri, 16 Jul 2021 14:11:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD3173850402 From: "tonyb at cybernetics dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/101473] New: LTO makes debug info depend on toolchain path Date: Fri, 16 Jul 2021 14:11:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 10.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tonyb at cybernetics dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:11:59 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101473 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 determini= stic (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 us= ing "objcopy --add-gnu-debuglink" makes them different again because the embedd= ed checksum for the debug info is different. I encountered this problem trying to make reproducible builds with -flto un= der Yocto. Here is the Yocto bug report, including test code for Yocto: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3D14481 Regarding the "LTO reproducible build test" attachment in the Yocto bug rep= ort: 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=3D66305#c6=