[llvm] [AArch64][v8.5A] Omit BTI for non-addr-taken static fns on Linux (PR #134669)
Simon Tatham via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 8 03:44:25 PDT 2025
================
@@ -78,16 +79,23 @@ bool AArch64BranchTargets::runOnMachineFunction(MachineFunction &MF) {
bool HasWinCFI = MF.hasWinCFI();
for (MachineBasicBlock &MBB : MF) {
bool CouldCall = false, CouldJump = false;
- // Even in cases where a function has internal linkage and is only called
- // directly in its translation unit, it can still be called indirectly if
- // the linker decides to add a thunk to it for whatever reason (say, for
- // example, if it is finally placed far from its call site and a BL is not
- // long-range enough). PLT entries and tail-calls use BR, but when they are
+ // If the function is address-taken or externally-visible, it could be
+ // indirectly called. PLT entries and tail-calls use BR, but when they are
// are in guarded pages should all use x16 or x17 to hold the called
// address, so we don't need to set CouldJump here. BR instructions in
// non-guarded pages (which might be non-BTI-aware code) are allowed to
// branch to a "BTI c" using any register.
- if (&MBB == &*MF.begin())
+ //
+ // For SysV targets, this is enough, because SYSVABI64 says that if the
+ // static linker later wants to use an indirect branch instruction in a
+ // long-branch thunk, it's also responsible for adding a 'landing pad' with
+ // a BTI, and pointing the indirect branch at that. However, at present
+ // this guarantee only holds for targets complying with SYSVABI64, so for
+ // other targets we must assume that `CouldCall` is _always_ true due to
+ // the risk of long-branch thunks at link time.
+ if (&MBB == &*MF.begin() &&
+ (!MF.getSubtarget<AArch64Subtarget>().isTargetLinux() ||
----------------
statham-arm wrote:
I'm concerned about that because there's no ABI guarantee that it will work for _all_ ELF platforms -- just because lld behaves in the right way, doesn't mean it's specified to work that way for all linkers.
So I've landed the patch as it is for the moment, which at least improves things in _some_ situations. I'm happy to come back and make that generalisation if https://github.com/ARM-software/abi-aa/issues/321 is fixed, though.
https://github.com/llvm/llvm-project/pull/134669
More information about the llvm-commits
mailing list