On 04/07/2022 15:47, Andrea Corallo wrote:
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
<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?
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
