Bugzilla – Bug 1195427
llvm13 varies from ASLR
Last modified: 2022-02-03 23:23:16 UTC
While working on reproducible builds for openSUSE, I noticed that our llvm13 package as well as various rust-built packages (fractal, gstreamer-plugins-rs, rage-encryption) vary unless ASLR is disabled during build. /usr/lib64/libc++.so.1.0 differs in assembler output --- old /usr/lib64/libc++.so.1.0 (disasm) +++ new /usr/lib64/libc++.so.1.0 (disasm) @@ -265,7 +265,7 @@ test %r12b,%r12b je <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_ + ofs> jmp <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_ + ofs> - lea -offset(%rip),%rax # <.str.45.llvm.16827896509114616097-0x569> + lea -offset(%rip),%rax # <.str.45.llvm.15443811693845109111-0x569> movslq (%rax,%rcx,4),%rcx Please work with upstream as appropriate.
I would recommend disabling ASLR for the package build. We do the same for gcc packages when built with PGO.
Are these just different symbol names or indeed different addresses? The offset seems to be the same, but that could be a coincidence. I get this locally with objdump -d: je 5ee18 <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_@@Base+0x18> jmp 5f309 <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_@@Base+0x509> lea -0x20848(%rip),%rax # 3e8a0 <_ZTSSt12bad_any_cast@@Base-0x1637> movslq (%rax,%rcx,4),%rcx In fact $ readelf -a --wide /usr/lib64/libc++.so.1.0 | grep '\.str\.[0-9]*\.llvm\..*' doesn't produce anything. So I guess it's just debuginfo?
(In reply to Aaron Puchert from comment #2) > So I guess it's just debuginfo? That seems so. After installing libc++1-debuginfo I get je 5ee18 <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_+0x18> jmp 5f309 <_ZNSt3__16__sortIRNS_6__lessIccEEPcEEvT0_S5_T_+0x509> lea -0x20848(%rip),%rax # 3e8a0 <.str.45.llvm.18274093503240611828-0x569> movslq (%rax,%rcx,4),%rcx Do we expect debuginfo to be reproducible? I guess there is a tradeoff between producing it faster and making it more reproducible, and the benefits of reproducibility might not be so pronounced there. Anyway, in my local build that symbol is 000000000003ee09 "/" So unsurprisingly, a string. I wonder why it isn't just hashing the contents of that string, especially since that large number looks an awful lot like a hash.