gas / binutils 2.27 generates invalid ELF files

[osresearch]

The Heads project is having problems building musl-cross on modern systems due to an incompatible change in libelf. https://github.com/osresearch/heads/pull/618#issuecomment-558813075

The problem is also described here: https://wiki.gentoo.org/wiki/Binutils_2.32_upgrade_notes/elfutils_0.175:unable_to_initialize_decompress_status_for_section.debug_info

Starting from dev-libs/elfutils-0.175 libelf writes compressed section alignment according to the ELF spec (see https://sourceware.org/PR23916). Unfortunately GNU assembler (gas from binutis-2.31.1 and older) writes non-conformant alignment. This means that libelf processing of such ELF files "corrupts" object files for binutils-2.31. binutils-2.32 now writes conformant ELF alignments (see https://sourceware.org/PR23919) but the result is not compatible to binutils-2.31.

The symptom that we encounter is that musl-cross-gas produces invalid ELF files for the Linux kernel's .S assembly programs, which are corrupted when they are processed by the ORC unwinder linked against the system's libelf:

/heads/build/../crossgcc/x86_64-linux-musl/bin/x86_64-linux-musl-objdump: arch/x86/lib/memmove_64.o: File format not recognized
/heads/build/../crossgcc/x86_64-linux-musl/bin/x86_64-linux-musl-objdump: arch/x86/lib/retpoline.o: unable to initialize decompress status for section .debug_line

I think moving musl-cross to binutils 2.32 (from the current 2.27) would fix this.

[rofl0r]

thanks for notifying us of this issue.

does this commit https://github.com/GregorR/musl-cross/commit/19529754abde58608d9b91ca2f80c6cdc058501d fix it for you ? (it is in branch binutils_chdr, not yet master in case that matters.)

I think moving musl-cross to binutils 2.32 (from the current 2.27) would fix this.

most likely, but there could be new regressions so for the time being i opted to backport the patch upstreamed in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=88739f776b733b0b84600b283417f862a010bb5d as it was straight-forward.

[rofl0r]

i'm adding @tlaurion to the CC list, as he seems to be working on this.

[tlaurion]

We then switched to musl-cross-make which resolved the issue. Project is staling though.

[rofl0r]

Project is staling though.

are you refering to musl-cross-make or another project? in case of mcm, i'm aware from IRC conversations that @richfelker is working on it and has a couple commits in the queue. it should hopefully get updated soon with fresh gcc versions and some patches for fdpic toolchains.