diff mbox series

[4/12] arm: Add testsuite library support for PACBTI target

Message ID gkr5ymtwnpk.fsf@arm.com
State Superseded
Headers
Series arm: Enables return address verification and branch target identification on Cortex-M |

Commit Message

Andrea Corallo April 28, 2022, 9:40 a.m. UTC 
  Add targeting-checking entities for PACBTI in testsuite
framework.

Pre-approved with the requested changes here
<https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html>.

gcc/testsuite/ChangeLog:

	* testsuite/lib/target-supports.exp:
	(check_effective_target_arm_pacbti_hw): New.
	* doc/sourcebuild.texi: Document arm_pacbti_hw.

Co-Authored-By: Tejas Belagod  <tbelagod@arm.com>

Comments

Richard Earnshaw July 1, 2022, 1:03 p.m. UTC | #1 
On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote:
> Add targeting-checking entities for PACBTI in testsuite
> framework.
> 
> Pre-approved with the requested changes here
> <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html>.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* testsuite/lib/target-supports.exp:
> 	(check_effective_target_arm_pacbti_hw): New.
> 	* doc/sourcebuild.texi: Document arm_pacbti_hw.
> 
> Co-Authored-By: Tejas Belagod  <tbelagod@arm.com>
> 
+proc check_effective_target_arm_pacbti_hw {} {
+    return [check_runtime arm_pacbti_hw_available {
+	__attribute__ ((naked)) int
+	main (void)
+	{
+	  asm ("pac r12, lr, sp");

So the armv8-m Arm ARM says that this instruction is in the NOP space 
and that it is undefined if we aren't armv8-m.main or higher.

+	  asm ("mov r0, #0");
+	  asm ("autg r12, lr, sp");

This isn't in the nop space, but the Arm ARM says it is unpredictable if 
the extension isn't present.  Unfortunately, that means this isn't a 
particularly reliable way of detecting that the PACBTI feature is present.

However, I can't think off hand of more reliable way of testing this 
since reading the feature register ID_ISAR5 is not possible when in 
unprivileged mode.

So I think we'll have to live with this.

+	  asm ("bx lr");
+	}
+    } ""]

OK.

R.
Richard Earnshaw July 1, 2022, 2:17 p.m. UTC | #2 
On 01/07/2022 14:03, Richard Earnshaw via Gcc-patches wrote:
> 
> 
> On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote:
>> Add targeting-checking entities for PACBTI in testsuite
>> framework.
>>
>> Pre-approved with the requested changes here
>> <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html>.
>>
>> gcc/testsuite/ChangeLog:
>>
>>     * testsuite/lib/target-supports.exp:
>>     (check_effective_target_arm_pacbti_hw): New.
>>     * doc/sourcebuild.texi: Document arm_pacbti_hw.
>>
>> Co-Authored-By: Tejas Belagod  <tbelagod@arm.com>
>>
> +proc check_effective_target_arm_pacbti_hw {} {
> +    return [check_runtime arm_pacbti_hw_available {
> +    __attribute__ ((naked)) int
> +    main (void)
> +    {
> +      asm ("pac r12, lr, sp");
> 
> So the armv8-m Arm ARM says that this instruction is in the NOP space 
> and that it is undefined if we aren't armv8-m.main or higher.
> 
> +      asm ("mov r0, #0");
> +      asm ("autg r12, lr, sp");
> 
> This isn't in the nop space, but the Arm ARM says it is unpredictable if 
> the extension isn't present.  Unfortunately, that means this isn't a 
> particularly reliable way of detecting that the PACBTI feature is present.
> 
> However, I can't think off hand of more reliable way of testing this 
> since reading the feature register ID_ISAR5 is not possible when in 
> unprivileged mode.
> 
> So I think we'll have to live with this.
> 
> +      asm ("bx lr");
> +    }
> +    } ""]
> 
> OK.
> 

Or perhaps not. The test does not try to add the right options to enable 
PAC/BTI if those aren't in the default selection for the current 
testsuite run.

Perhaps we also need some additional tests to work out what architecture 
options to add (if any) to ensure the test will at least assemble.

> R.
R.
Andrea Corallo July 4, 2022, 2:47 p.m. UTC | #3 
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:

> On 01/07/2022 14:03, Richard Earnshaw via Gcc-patches wrote:
>> On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote:
>>> Add targeting-checking entities for PACBTI in testsuite
>>> framework.
>>>
>>> Pre-approved with the requested changes here
>>> <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html>.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>     * testsuite/lib/target-supports.exp:
>>>     (check_effective_target_arm_pacbti_hw): New.
>>>     * doc/sourcebuild.texi: Document arm_pacbti_hw.
>>>
>>> Co-Authored-By: Tejas Belagod  <tbelagod@arm.com>
>>>
>> +proc check_effective_target_arm_pacbti_hw {} {
>> +    return [check_runtime arm_pacbti_hw_available {
>> +    __attribute__ ((naked)) int
>> +    main (void)
>> +    {
>> +      asm ("pac r12, lr, sp");
>> So the armv8-m Arm ARM says that this instruction is in the NOP
>> space and that it is undefined if we aren't armv8-m.main or higher.
>> +      asm ("mov r0, #0");
>> +      asm ("autg r12, lr, sp");
>> This isn't in the nop space, but the Arm ARM says it is
>> unpredictable if the extension isn't present.  Unfortunately, that
>> means this isn't a particularly reliable way of detecting that the
>> PACBTI feature is present.
>> However, I can't think off hand of more reliable way of testing this
>> since reading the feature register ID_ISAR5 is not possible when in
>> unprivileged mode.
>> So I think we'll have to live with this.
>> +      asm ("bx lr");
>> +    }
>> +    } ""]
>> OK.
>> 
>
> Or perhaps not. The test does not try to add the right options to
> enable PAC/BTI if those aren't in the default selection for the
> current testsuite run.
>
> Perhaps we also need some additional tests to work out what
> architecture options to add (if any) to ensure the test will at least
> assemble.

Hi Richard,
thanks for reviewing.

Wouldn't be sufficient for that to have this test compiled with
-march=armv8-m.main?

BR

  Andrea
Richard Earnshaw July 5, 2022, 10:05 a.m. UTC | #4 
On 04/07/2022 15:47, Andrea Corallo wrote:
> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:
> 
>> On 01/07/2022 14:03, Richard Earnshaw via Gcc-patches wrote:
>>> On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote:
>>>> Add targeting-checking entities for PACBTI in testsuite
>>>> framework.
>>>>
>>>> Pre-approved with the requested changes here
>>>> <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html 
> <https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586331.html>>.
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>>     * testsuite/lib/target-supports.exp:
>>>>     (check_effective_target_arm_pacbti_hw): New.
>>>>     * doc/sourcebuild.texi: Document arm_pacbti_hw.
>>>>
>>>> Co-Authored-By: Tejas Belagod  <tbelagod@arm.com>
>>>>
>>> +proc check_effective_target_arm_pacbti_hw {} {
>>> +    return [check_runtime arm_pacbti_hw_available {
>>> +    __attribute__ ((naked)) int
>>> +    main (void)
>>> +    {
>>> +      asm ("pac r12, lr, sp");
>>> So the armv8-m Arm ARM says that this instruction is in the NOP
>>> space and that it is undefined if we aren't armv8-m.main or higher.
>>> +      asm ("mov r0, #0");
>>> +      asm ("autg r12, lr, sp");
>>> This isn't in the nop space, but the Arm ARM says it is
>>> unpredictable if the extension isn't present.  Unfortunately, that
>>> means this isn't a particularly reliable way of detecting that the
>>> PACBTI feature is present.
>>> However, I can't think off hand of more reliable way of testing this
>>> since reading the feature register ID_ISAR5 is not possible when in
>>> unprivileged mode.
>>> So I think we'll have to live with this.
>>> +      asm ("bx lr");
>>> +    }
>>> +    } ""]
>>> OK.
>>> 
>>
>> Or perhaps not. The test does not try to add the right options to
>> enable PAC/BTI if those aren't in the default selection for the
>> current testsuite run.
>>
>> Perhaps we also need some additional tests to work out what
>> architecture options to add (if any) to ensure the test will at least
>> assemble.
> 
> Hi Richard,
> thanks for reviewing.
> 
> Wouldn't be sufficient for that to have this test compiled with
> -march=armv8-m.main?

Take a look at how, for example, check_effective_target_arm_mve_hw (and 
add_options_for_v8_1_m_mve_fp) is implemented.

R.

> 
> BR
> 
>    Andrea
diff mbox series

Patch

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 613ac29967b..e8cbd8e4aef 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2167,6 +2167,10 @@  ARM target supports options to generate instructions from ARMv8.1-M with
 the Custom Datapath Extension (CDE) and M-Profile Vector Extension (MVE).
 Some multilibs may be incompatible with these options.
 
+@item arm_pacbti_hw
+Test system supports executing Pointer Authentication and Branch Target
+Identification instructions.
+
 @item arm_prefer_ldrd_strd
 ARM target prefers @code{LDRD} and @code{STRD} instructions over
 @code{LDM} and @code{STM} instructions.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index ff8edbd3e17..df8ab037fb3 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5090,6 +5090,22 @@  proc check_effective_target_arm_cmse_clear_ok {} {
     } "-mcmse"];
 }
 
+# Return 1 if the target supports executing PACBTI instructions, 0
+# otherwise.
+
+proc check_effective_target_arm_pacbti_hw {} {
+    return [check_runtime arm_pacbti_hw_available {
+	__attribute__ ((naked)) int
+	main (void)
+	{
+	  asm ("pac r12, lr, sp");
+	  asm ("mov r0, #0");
+	  asm ("autg r12, lr, sp");
+	  asm ("bx lr");
+	}
+    } ""]
+}
+
 # Return 1 if this compilation turns on string_ops_prefer_neon on.
 
 proc check_effective_target_arm_tune_string_ops_prefer_neon { } {