RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files)
Magnus Ihse Bursie
ihse at openjdk.org
Wed Aug 7 15:10:32 UTC 2024
On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
> Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details.
Thank you Jiangli for the additional links. While the lack of formal documentation is somewhat dissatisfying, I agree that the code analysis from the mailing list is good enough indication that a lack of `.llvm_addrsig` means all addresses are considered significant.
Also, this whole situation seem like a clusterf**k of bad tooling and tooling cooperation. :-( Are you saying that even using strip can cause lld malfunction? Is there any chance we risk running into problems that way?
The opinions on the bug report you posted indicate that people are not happy with this design:
> "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. [...] 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.
I agree with this assessment. Adding a new section that causes failure if it is not kept updated by other tools (and possibly even their own `ld -r`!) is just bad behavior on their part. Nevertheless, we have had to deal with broken tools before, so if we can force it to behave more properly by removing the `.llvm_addrsig` section, then I guess that this is the workaround we need to use anyway.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2273700966
More information about the build-dev
mailing list