Richard Earnshaw <richard.earns...@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 <tbela...@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
