Re: Undocumented behavior with CPSR_c mode

[Peter Maydell]

On Tue, 27 Feb 2024 at 13:15, Kirill Zhumarin <kirill.zhumarin@gmail.com> wrote:
> My environment:
> Real hardware: Infineon PMB8876 + Infineon PMB8875 (ARM926EJ-S core)
> QEMU: from master, arm926ej-s
>
> I found that the M4 bit in CPSR_c is optional when setting CPU mode.
> On real hardware, modes 00010 and 10010 are actually equal.

> And I get different results on qemu and real CPU:
>
> --------------------------------
> qemu
> CPSR: 60000113
> MODE: 10011
> --------------------------------
> pmb8876 or pmb8875
> CPSR: 60000012
> MODE: 10010
> --------------------------------
>
> QEMU just ignores setting invalid mode.
>
> Of course, I understand, this is an invalid code - according to the
> ARM documentation, "00010" mode does not exist.

Yes. The Arm Architecture Reference Manual says that
setting the M field to a reserved value is UNPREDICTABLE.
That means that the implementation is allowed to do (almost)
anything. It happens that QEMU's implementation makes a different
choice from what the hardware ARM926EJ-S does. QEMU does not
attempt to follow the exact behaviour (either UNPREDICTABLE
or IMPDEF) of individual CPU types.

> But this is not a synthetic code. I found it in an existing bootloader
> for pmb8876, and it works on a real device.

This code is broken; it just happens to do what the
author intended on the specific hardware it was tested on.

> That code looks like this:
> ```
> msr        cpsr_c,#0xc2 ; go to the IRQ mode
> ldr        sp,[DAT_00082e28] ; set IRQ mode stack
> ...
> msr        cpsr_c,#0xc3 ; back to the Supervisor mode
> ldr        sp,[DAT_00082e2c] ; set Supervisor mode stack
> ```
>
> Unfortunately, I do not have other ARM926EJ-S processors to test the
> behavior on them.
> Should QEMU repeat this undocumented behavior?

No, we don't follow device specifics to that level.

thanks
-- PMM