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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

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