[lld] [LLD/AArch64] BTI link-time relaxation: NOP redundant `bti c` for internal functions (PR #187871)

[Junjie Peng via llvm-commits]

HacoK wrote:

> This idea to do this sort of transformation has come up before. I've not had a chance to look at the implementation in detail yet. Here's a few comments based on prior experience:
> 
> * For this to be safe, there would need to be an ABI rule that mandated relocations were used. I can remember a compiler (for Arm not AArch64) using and ADR (a psynonym for `add r0, pc, #immediate`, `bx r0`) which did not have a relocation. The source and destination happened to be in the same section, and the compiler/assembler knew that the definition was prevailing. It looks like clang and gcc will always use relocations as of today, but that's not a guarantee that they will in the future unless the ABI requires it.
> * There has been an attempt at this before, no patch, but a description of the problems in [endbr64 removal #74400](https://github.com/llvm/llvm-project/issues/74400) . There were a couple of corner cases that came up ([endbr64 removal #74400 (comment)](https://github.com/llvm/llvm-project/issues/74400#issuecomment-1925802289)) which I think are the same underlying problem. That is symbol aliasing, where instead of a relocation to the STT_FUNC symbol, there was a relocation to an alias, sometimes via the section symbol + addend. I don't think that this is an insurmountable problem, but it means doing something similar to the thunk code and converting all relocations to section symbol + offset.
> * I don't think this should be enabled by default, I'm not sure we can guarantee the safety yet and I would expect it to have some impact on link-time for a large program, the trade-off may not be worth it for some.
> * In theory BOLT may be able to a better job than LLD as it should be able to remove the BTI instructions completely.

Thanks, this is a very useful set of concerns.

I agree this should not be enabled by default in its current form. The present implementation is really only justified for object producers that faithfully express all relevant code-address uses via relocations, and without an ABI requirement that is not a property LLD can assume universally.

I also agree the #74400 aliasing / section-symbol+addend cases are the real missing piece here. I think the analysis needs to move from “which symbol was referenced” to a canonical `<section, offset>` view, similar to the thunk code, and then treat aliases at the same location as equivalent for address-taken purposes.

I’ll rework the patch in that direction and gate it behind an explicit option rather than the default relaxation path. BOLT may well do a better job for aggressive post-link cleanup; my intent here is only a conservative linker-side transform.


https://github.com/llvm/llvm-project/pull/187871