https://sourceware.org/bugzilla/show_bug.cgi?id=23817
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
Summary|strip corrupts |strip and ld -r corrupt
|SHT_LLVM_ADDRSIG section |SHT_LLVM_ADDRSIG section
|(files built with clang-7) |(files built with clang-7)
Severity|normal |enhancement
--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
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.)
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
