Yes, you're right -- I hadn't noticed this wrinkle of the architecture. I'll put this on my todo list -- it should be straightforward.
Do you have a convenient test binary that I could use as a test case? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1768295 Title: VLLDM/VLSTM trigger UsageFault in the Secure Mode Status in QEMU: New Bug description: The VLLDM/VLSTM instructions trigger UsageFault when they are supposed to behave as NOP. Version: $ qemu-system-arm --version QEMU emulator version 2.11.93 VLLDM and VLSTM are instructions newly added to ARMv8-M Mainline Profile. Although they are FP instructions and the FP support of the M profile is not implemented by QEMU, the Armv8-M Architecture Reference Manual specifies that they should behave as NOP even in this case: C2.4.268 VLLDM: > If the Floating-point Extension is not implemented, this instruction is available in Secure state, but behaves as a NOP. C2.4.269 VLSTM: > If the Floating-point Extension is not implemented, this instruction is available in Secure state, but behaves as a NOP. VLLDM and VLSTM are generated automatically by the compiler to save and restore the floating point registers (in a lazy manner) during a Non-Secure function call. An example is shown below: 10000064 <__gnu_cmse_nonsecure_call>: 10000064: e92d 4fe0 stmdb sp!, {r5, r6, r7, r8, r9, sl, fp, lr} 10000068: 4627 mov r7, r4 1000006a: 46a0 mov r8, r4 1000006c: 46a1 mov r9, r4 1000006e: 46a2 mov sl, r4 10000070: 46a3 mov fp, r4 10000072: 46a4 mov ip, r4 10000074: b0a2 sub sp, #136 ; 0x88 10000076: ec2d 0a00 vlstm sp 1000007a: f384 8800 msr CPSR_f, r4 1000007e: 4625 mov r5, r4 10000080: 4626 mov r6, r4 10000082: 47a4 blxns r4 10000084: ec3d 0a00 vlldm sp 10000088: b022 add sp, #136 ; 0x88 1000008a: e8bd 8fe0 ldmia.w sp!, {r5, r6, r7, r8, r9, sl, fp, pc} To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1768295/+subscriptions
