On Mon, 18 May 2026 at 17:16, Torbjörn SVENSSON <[email protected]> wrote: > > Testing an arm-none-eabi GCC toolchain using QEMU gives unpredictable > test results for some test cases. In the GCC testsuite function > check_effective_target_arm_pacbti_hw, the testsuite tries to identify > if the target supports PACBTI instructions. The test consists of: > > __attribute__ ((naked)) int > main (void) > { > asm ("pac r12, lr, sp"); > asm ("mov r0, #0"); > asm ("autg r12, lr, sp"); > asm ("bx lr"); > } > > Running the above code in QEMU will cause LR to get corrupted. > The reson for the corruption is that AUTG overlaps with the SMMLA > instruction, and SMMLA will write the result to Rn, that for > `AUTG R12, LR, SP` happens to match `LR`.
If the test case is expecting to be able to run on any M-profile CPU, this is a bug in the test case. The AUTG instruction is specified as being UNPREDICTABLE if the DSP extension is implemented and the PACBTI extension is not (and to UNDEF if neither extension is implemented). (We could consider making the QEMU behaviour for these UNPREDICTABLE cases in SMMLA etc be "UNDEF" rather than "write to the PC/LR"; we choose to handle this kind of UNPREDICTABLE decode that way for other insns already.) > The solution to the above problem is to define the following new > Cortex-M instructions in QEMU: > > * AUT > * AUTG > * BXAUT > * PAC > * PACBTI > * PACG > > This patch series only implements the pointer authentication code part > of PACBTI. The branch target identification part is not implemented. I think that overall we need the full PACBTI implemented -- we can't advertise it in the CPU ID registers but only implement part of it, or only implement it for user-mode and not for system mode. thanks -- PMM
