On 28/06/2022 10:21, Andrea Corallo via Gcc-patches wrote:
Hi all,
second iteration of this patch enabling Branch Target Identification
Armv8.1-M Mechanism [1].
This is achieved by using the bti pass made common with Aarch64.
The pass iterates through the instructions and adds the necessary BTI
instructions at the beginning of every function and at every landing
pads targeted by indirect jumps.
Best Regards
Andrea
[1]
<https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension>
gcc/ChangeLog
2022-04-07 Andrea Corallo <andrea.cora...@arm.com>
* config.gcc (arm*-*-*): Add 'aarch-bti-insert.o' object.
* config/arm/arm-protos.h: Update.
* config/arm/arm.cc (aarch_bti_enabled, aarch_bti_j_insn_p)
(aarch_pac_insn_p, aarch_gen_bti_c, aarch_gen_bti_j): New
functions.
* config/arm/arm.md (bti_nop): New insn.
* config/arm/t-arm (PASSES_EXTRA): Add 'arm-passes.def'.
(aarch-bti-insert.o): New target.
* config/arm/unspecs.md (UNSPEC_BTI_NOP): New unspec.
* config/arm/aarch-bti-insert.cc (rest_of_insert_bti): Update
to verify arch compatibility.
gcc/testsuite/ChangeLog
2022-04-07 Andrea Corallo <andrea.cora...@arm.com>
* gcc.target/arm/bti-1.c: New testcase.
* gcc.target/arm/bti-2.c: Likewise.
@@ -104,6 +105,14 @@ rest_of_insert_bti (void)
rtx_insn *insn;
basic_block bb;
+#if defined (TARGET_32BIT) || defined (TARGET_THUMB1)
See the comment about errors in response to patch 10. I'd simply expect
the gate function to be disabled when we can't support PAC, so we should
never get here.
+ if (!arm_arch8)
+ {
+ error ("This architecture does not support branch protection
instructions");
+ goto exit;
+ }
+#endif
+
...
+
+rtx aarch_gen_bti_c (void)
+{
+ return gen_bti_nop ();
+}
+
+rtx aarch_gen_bti_j (void)
+{
+ return gen_bti_nop ();
+}
+
Function names should start a new line... Thus:
rtx
aarch_gen_bti_c (void)
etc.
+(define_insn "bti_nop"
+ [(unspec_volatile [(const_int 0)] UNSPEC_BTI_NOP)]
+ "TARGET_THUMB2"
This isn't quite right. We need v8-m.main as the baseline architecture
for the NOPs to behave as NOPs.
+ "bti"
+ [(set_attr "type" "mov_reg")])
+
How to deal with architectural NOPs is an interesting question. I think
really, for the scheduler we need to describe each newly defined NOP
separately, then in the scheduling descriptions we can handle all
unimplemented NOPs by grouping them together for that architecture,
whilst describing more accurately how to handle them on CPUs where they
acquire a defined behaviour.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2021bdf9d2f..004e1dfa8d8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -353,7 +353,7 @@ arc*-*-*)
;;
arm*-*-*)
cpu_type=arm
- extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o"
+ extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o
aarch-bti-insert.o"
--- a/gcc/config/arm/t-arm
+++ b/gcc/config/arm/t-arm
@@ -175,3 +175,13 @@ arm-d.o: $(srcdir)/config/arm/arm-d.cc
arm-common.o: arm-cpu-cdata.h
driver-arm.o: arm-native.h
+
+PASSES_EXTRA += $(srcdir)/config/arm/arm-passes.def
See comment on patch 11. Perhaps the right thing to do is to move the
hunk that adds arm-passes.def into this patch.
