Bug 23817 - strip and ld -r corrupt SHT_LLVM_ADDRSIG section (files built with clang-7)
Summary: strip and ld -r corrupt SHT_LLVM_ADDRSIG section (files built with clang-7)
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.31
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2018-10-24 22:04 UTC by Sergei Trofimovich
Modified: 2018-10-25 00:37 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

t.tar.gz (624 bytes, application/gzip)
2018-10-24 22:04 UTC, Sergei Trofimovich

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich 2018-10-24 22:04:09 UTC
Created attachment 11364 [details]

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

Comment 1 Alan Modra 2018-10-25 00:37:57 UTC
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.)