-faddrsig vs systems using GNU binutils

Clang Frontend
1

Hello,

Clang currently defaults to emitting address significance table
(-faddrsig) on majority of the systems. Of those systems, at least
Gentoo still defaults to using GNU binutils most of the time.
As a result, strip(1) now outputs verbose errors on clang-created
executables, e.g.:

armv7a-unknown-linux-gnueabihf-strip: st5EpxDK: failed to find link
section for section 6
armv7a-unknown-linux-gnueabihf-strip: st5EpxDK: failed to find link
section for section 6

We (Gentoo) have received user reports about this [1]. We have passed
this on to GNU binutils [2] but it seems that they not only aren't
interested in providing any support for this section but actively
indicate that the proposed standard is unlikely to be accepted into
generic-abi.

Could you advise on how to proceed? I'm thinking of disabling it
by default but I would prefer not to add unnecessary distro
customization if possible.

[1]:667854 – /usr/bin/armv7a-unknown-linux-gnueabihf-strip fails to find various link sections while striping statically linked files during src_install (affected packages: libcxx-7.0.1, libcxxabi-7.0.1, compiler-rt-7.0.1, compiler-rt-plugins-7.0.1)
[2]:23817 – strip and ld -r corrupt SHT_LLVM_ADDRSIG section (files built with clang-7)

2

HI Michal,

Note that these messages are coming from attempts to strip object files, not executables. As far as I know, they aren’t actually errors; the object files still get stripped (and sh_link on the addrsig section gets reset to 0, which the linker treats as an indication to not try to read the section, which means that a stripped object file with this section won’t cause any problems in practice). If the messages are a problem for you, you will most likely want to change Gentoo’s packaging scripts to pass -fno-addrsig to the compiler.

Peter