1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
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
}
|
