[Bug lto/66305] New: -ffat-lto-objects create unreproducible objects

[lunar at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305

Bug ID: 66305
   Summary: -ffat-lto-objects create unreproducible objects
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lunar at debian dot org
  Target Milestone: ---

Hi!

We are working in Debian—and I know other free software projects
care—in providing our users with a way to reproduce bit-for-bit
identical binary packages from the source and build enviroment.
See https://wiki.debian.org/ReproducibleBuilds for more information.

Python packages in Debian are built with `-flto -ffat-lto-objects`
on architectures that support it. Sadly, this makes the resulting
binary unreproducible.

For a trivial test case:

$ cat a.c
int a(void) {
return 42;
}
$ gcc -flto -ffat-lto-objects -c a.c
$ strings a.o | grep lto_
.gnu.lto_.inline.4980dca9e6ae4d45
.gnu.lto_a.4980dca9e6ae4d45
.gnu.lto_.symbol_nodes.4980dca9e6ae4d45
.gnu.lto_.refs.4980dca9e6ae4d45
.gnu.lto_.decls.4980dca9e6ae4d45
.gnu.lto_.symtab.4980dca9e6ae4d45
.gnu.lto_.opts
__gnu_lto_v1
$ gcc -flto -ffat-lto-objects -c a.c
$ strings a.o | grep lto_
.gnu.lto_.inline.24c30dabb443e726
.gnu.lto_a.24c30dabb443e726
.gnu.lto_.symbol_nodes.24c30dabb443e726
.gnu.lto_.refs.24c30dabb443e726
.gnu.lto_.decls.24c30dabb443e726
.gnu.lto_.symtab.24c30dabb443e726
.gnu.lto_.opts
__gnu_lto_v1

Would it be possible to make the section names deterministic?

[Bug lto/66305] -ffat-lto-objects create unreproducible objects

[lunar at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305

--- Comment #3 from lunar at debian dot org ---
Richard Biener:
 I think they become deterministic with -frandom-seed=0 for example.
 They are not deterministic to support partial linking of LTO objects as far
 as I know.

They are indeed reproducible with `-frandom-seed=0`. But I guess there's a
downside to that, right?

Andi:
 In theory it would be possible to use the hash of the full output path name or
 similar, which would be a bit more deterministic, but there are still
 ways this could break (e.g. if someone copies object files around)

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.

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.

 How about your deterministic build tools just learn to ignore that
 suffix?

I am not sure I understand what you are talking about. We want to get
byte-for-byte identical packages on each build (provided the same software
versions are used), so we need a given version of GCC to always produce the
same output.