[llvm] [AArch64][v8.5A] Omit BTI for non-addr-taken static fns in ELF (PR #135043)
Simon Tatham via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 9 09:23:45 PDT 2025
https://github.com/statham-arm created https://github.com/llvm/llvm-project/pull/135043
This follows up commit 7af2b51e761f499, which removed the BTI at the start of functions with internal linkage (provided they weren't indirectly called inside the translation unit) for Linux targets.
Now we leave out the BTI for any ELF target, including bare-metal, because the AAELF64 document in the Arm ABI has been updated to make the same guarantee as SYSVABI64: if the linker wants to insert an indirect branch at link time (e.g. as part of a long branch thunk) it's responsible for making a BTI-equipped landing pad.
That was too difficult to test in the existing codegen test `patchable-function-entry-bti.ll`, because so much of LLVM's detailed asm output changes for non-ELF targets. So I've simplified that back to how it was before 7af2b51e761f499 (except that now it expects no BTI in the disputed function), and made a new test checking specifically the difference in BTI between the formats.
>From 1ad5f4dacda47578d4dcc124c480b6213fd8ad40 Mon Sep 17 00:00:00 2001
From: Simon Tatham <simon.tatham at arm.com>
Date: Wed, 9 Apr 2025 17:10:47 +0100
Subject: [PATCH] [AArch64][v8.5A] Omit BTI for non-addr-taken static fns in
ELF
This follows up commit 7af2b51e761f499, which removed the BTI at the
start of functions with internal linkage (provided they weren't
indirectly called inside the translation unit) for Linux targets.
Now we leave out the BTI for any ELF target, including bare-metal,
because the AAELF64 document in the Arm ABI has been updated to make
the same guarantee as SYSVABI64: if the linker wants to insert an
indirect branch at link time (e.g. as part of a long branch thunk)
it's responsible for making a BTI-equipped landing pad.
That was too difficult to test in the existing codegen test
`patchable-function-entry-bti.ll`, because so much of LLVM's detailed
asm output changes for non-ELF targets. So I've simplified that back
to how it was before 7af2b51e761f499 (except that now it expects no
BTI in the disputed function), and made a new test checking
specifically the difference in BTI between the formats.
---
.../Target/AArch64/AArch64BranchTargets.cpp | 13 +++--
.../CodeGen/AArch64/internal-linkage-bti.ll | 47 +++++++++++++++++++
.../AArch64/patchable-function-entry-bti.ll | 14 ++----
3 files changed, 56 insertions(+), 18 deletions(-)
create mode 100644 llvm/test/CodeGen/AArch64/internal-linkage-bti.ll
diff --git a/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp b/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp
index c60fbb63c73ab..2a96f15c20f6b 100644
--- a/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp
+++ b/llvm/lib/Target/AArch64/AArch64BranchTargets.cpp
@@ -86,15 +86,14 @@ bool AArch64BranchTargets::runOnMachineFunction(MachineFunction &MF) {
// non-guarded pages (which might be non-BTI-aware code) are allowed to
// branch to a "BTI c" using any register.
//
- // For SysV targets, this is enough, because SYSVABI64 says that if the
- // static linker later wants to use an indirect branch instruction in a
+ // For ELF targets, this is enough, because AAELF64 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.
+ // a BTI, and pointing the indirect branch at that. For non-ELF targets we
+ // can't rely on that, so we 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() ||
+ (!MF.getSubtarget<AArch64Subtarget>().isTargetELF() ||
(F.hasAddressTaken() || !F.hasLocalLinkage())))
CouldCall = true;
diff --git a/llvm/test/CodeGen/AArch64/internal-linkage-bti.ll b/llvm/test/CodeGen/AArch64/internal-linkage-bti.ll
new file mode 100644
index 0000000000000..59d59fce81fd7
--- /dev/null
+++ b/llvm/test/CodeGen/AArch64/internal-linkage-bti.ll
@@ -0,0 +1,47 @@
+; RUN: llc -mtriple=aarch64-linux-gnu %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI
+; RUN: llc -mtriple=aarch64-none-elf %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI
+; RUN: llc -mtriple=aarch64-none-macho %s -o - | FileCheck %s --check-prefixes=CHECK,BTI
+; RUN: llc -mtriple=aarch64-windows-msvc %s -o - | FileCheck %s --check-prefixes=CHECK,BTI
+
+;; This function has internal linkage, and nothing in this translation unit
+;; calls it indirectly. So it doesn't need a BTI at the start ... except that
+;; it might, if at link time if the linker inserts a long-branch thunk using a
+;; BLR instruction.
+;;
+;; For ELF targets, both Linux and bare-metal, we expect no BTI instruction at
+;; the start of the function, because AAELF64 specifies that it's not needed:
+;; if the linker wants to do that then it's responsible for making a 'landing
+;; pad' near the target function which _does_ have a BTI, and pointing the
+;; indirect call at that.
+;;
+;; But this is specified in AAELF64, so non-ELF targets can't rely on that
+;; guarantee, and we expect LLVM to insert the BTI anyway.
+define internal void @internal_linkage() "branch-target-enforcement" {
+; CHECK-LABEL: internal_linkage:
+; BTI: hint #34
+; NOBTI-NOT: hint #34
+; CHECK: ret
+entry:
+ ret void
+}
+
+;; This function has internal linkage but _is_ potentially called indirectly
+;; (its address escapes from the module via external_linkage() below), so it
+;; needs a BTI irrespective of target triple.
+define internal void @indirectly_called() "branch-target-enforcement" {
+; CHECK-LABEL: indirectly_called:
+; CHECK: hint #34
+; CHECK: ret
+entry:
+ ret void
+}
+
+;; This function has external linkage, so it needs a BTI in all circumstances.
+define ptr @external_linkage() "branch-target-enforcement" {
+; CHECK-LABEL: external_linkage:
+; CHECK: hint #34
+; CHECK: ret
+entry:
+ call void @internal_linkage()
+ ret ptr @indirectly_called
+}
diff --git a/llvm/test/CodeGen/AArch64/patchable-function-entry-bti.ll b/llvm/test/CodeGen/AArch64/patchable-function-entry-bti.ll
index 6d5dfc9d8fae4..7f9670c40b914 100644
--- a/llvm/test/CodeGen/AArch64/patchable-function-entry-bti.ll
+++ b/llvm/test/CodeGen/AArch64/patchable-function-entry-bti.ll
@@ -1,5 +1,4 @@
-; RUN: llc -mtriple=aarch64-linux-gnu -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s --check-prefixes=CHECK,SYSV
-; RUN: llc -mtriple=aarch64-none-elf -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s --check-prefixes=CHECK,NONSYSV
+; RUN: llc -mtriple=aarch64 -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s
define void @f0() "patchable-function-entry"="0" "branch-target-enforcement" {
; CHECK-LABEL: f0:
@@ -49,25 +48,18 @@ define void @f2_1() "patchable-function-entry"="1" "patchable-function-prefix"="
}
;; -fpatchable-function-entry=1 -mbranch-protection=bti
-;; For SysV compliant targets, we don't add BTI (or create the .Lpatch0 symbol)
-;; because the function has internal linkage and isn't address-taken. For
-;; non-SysV targets, we do add the BTI, because outside SYSVABI64 there's no
-;; spec preventing the static linker from using an indirect call instruction in
-;; a long-branch thunk inserted at link time.
+;; We don't add BTI c, because the function has internal linkage
define internal void @f1i(i64 %v) "patchable-function-entry"="1" "branch-target-enforcement" {
; CHECK-LABEL: f1i:
; CHECK-NEXT: .Lfunc_begin3:
; CHECK: // %bb.0:
-; NONSYSV-NEXT: hint #34
-; NONSYSV-NEXT: .Lpatch1:
; CHECK-NEXT: nop
;; Other basic blocks have BTI, but they don't affect our decision to not create .Lpatch0
; CHECK: .LBB{{.+}} // %sw.bb1
; CHECK-NEXT: hint #36
; CHECK: .section __patchable_function_entries,"awo", at progbits,f1i{{$}}
; CHECK-NEXT: .p2align 3
-; NONSYSV-NEXT: .xword .Lpatch1
-; SYSV-NEXT: .xword .Lfunc_begin3
+; CHECK-NEXT: .xword .Lfunc_begin3
entry:
switch i64 %v, label %sw.bb0 [
i64 1, label %sw.bb1
More information about the llvm-commits
mailing list