[llvm] [BOLT][AArch64] Add support for long absolute LLD thunks/veneers (PR #113408)

[Peter Smith via llvm-commits]

https://github.com/smithp35 commented:

I can't see anything wrong with the patch. I expect the `__AArch64ADRPThunk_` to be more common, as these will be used when the code is build position independent.

It is a bit of a pity that BOLT has to detect veneers, as there are many possible code-sequences across all static linkers. While it is too late to do anything now, I'm wondering if there could be some extra hints that could be generated by static linkers to make it easier for binary analysis tools to handle veneers. Possibly written up in the AArch64 sysvabi so that other linker's could choose to adopt them.

One possible case that you may need to handle in the veneer to a veneer case is the newly added `__AArch64BTIThunk_`. These are needed when LLD inserts a veneer with an indirect branch to a destination that doesn't have a BTI at the destination. In this case the linker adds a "landing pad" veneer with a BTI which then transfers control to the destination, either by falling through or with a direct branch.

For example:
```
bl __AArch64AbsLongThunkFoo

__AArch64AbsLongThunk_Foo
...
br x16
...
__AArch64BTIThunk_Foo
bti c
b Foo // This can be elided if Foo follows after the veneer.
...
Foo:
// some instruction other than one of the BTI (or compatible instructions)
```

I don't think it is critical that these are detected as these veneers are alternative entry points for a function, but BOLT may have been able to rearrange the code such that an indirect branch to Foo (which requires a BTI at the destination) is no longer necessary.

I wouldn't expect BOLT to encounter these for a while as clang currently outputs BTI instructions for all functions, but this may change in the future.

As an aside, a possible optimisation for BOLT, assuming it can detect all indirect branch targets is to remove `BTI c` instructions that aren't needed.

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