Created attachment 11364 [details] t.tar.gz Issue originally discovered in https://bugs.gentoo.org/667854 as a menacing warning on x86_64 and arm64: $ echo 'void f(void){}' > a.c $ clang -c a.c -o a.o.clang $ cp a.o.clang a.o $ strip a.o strip: stTEWJ8A: failed to find link section for section 5 strip: stTEWJ8A: failed to find link section for section 5 $ sha1sum a.o.clang a.o 34c07c978aeb3ef1fbe2083b5fbaf608c7fe63ec a.o.clang 2060df629d6b818cb1c56147dc9c89cfd5fbf5ad a.o The warning comes from .llvm_addrsig (SHT_LLVM_ADDRSIG) and attached strtab/symtab. strip strips unreferenced symbols but does not touch .llvm_addrsig rendering references invalid (I think). https://reviews.llvm.org/D47744 has SHT_LLVM_ADDRSIG description. I'm not sure what exactly binutils (or llvm) should do here. A few options: 1. avoid stripping binaries with unknown unhandled sections 2. Add support for SHT_LLVM_ADDRSIG handling 3. Come back to llvm and add some generic relocations(?) into .llvm_addrsig if possible so binutiols' strip would just work. Attaching t.tar.gz with a.c a.o a.o.clang Thanks!
Storing symbol indices in .llvm_addrsig means that any tool that modifies the symbol table must update .llvm_addrsig. It's not just strip/objcopy but also ld -r, where .llvm_addrsig contents currently will become invalid without any warning to the user. In my opinion, .llvm_addrsig is a poor design. Peter Collingbourne received multiple objections to the idea when it was proposed on the generic ABI list, but he went ahead anyway. (Well, maybe the code was accepted into llvm during the discussion.) He was even told how to implement the functionality correctly, by a toolchain expert. Quoting Cary: "A much simpler (and zero-cost, from an object file size point of view) solution would be to add FPTR relocations to the psABI, and use those for any references that would impose the address significance constraint." https://groups.google.com/d/msg/generic-abi/MPr8TVtnVn4/g5yBRRB5AAAJ H.J. Lu also agreed that new relocations could be added. So I'd say there is zero chance of SHT_LLVM_ADDRSIG being blessed by the generic ABI group, and also little chance that any of the binutils maintainers will treat this as a bug that needs fixing. (A proper fix is non-trivial, but if anyone wants to implement support for SHT_LLVM_ADDRSIG look at how SHT_GROUP signature symbols are handled.)
As per comment #1