On 10/19/21 9:44 AM, Warner Losh wrote:
+ regs->regs[15] = tswap32(gr[TARGET_REG_PC]);
+ cpsr = tswap32(gr[TARGET_REG_CPSR]);
+ cpsr_write(regs, cpsr, CPSR_USER | CPSR_EXEC, CPSRWriteByInstr);
Hmm. What's the expected behaviour if the saved CPSR state does not match the PC state
wrt thumb?
I'm ok if this should fail in spectacular ways, I just wanna know.
I *think* what will happen at the moment is that qemu will go into a whacky state in which
the translator will read and interpret unaligned data.
I have a pending patch set for arm to raise unaligned exceptions for mis-aligned pc. For
arm32 mode, this is fine, and we'll raise the exception. But for thumb mode, this is
architecturally impossible, and the translator will assert.
The assert is going to be a problem. There are a couple of options:
(1) TARGET_REG_PC wins: unset PC[0] and adjust CPSR[T] to match.
(2) CPSR_T wins: unset pc[0] if CPSR[T] is set, unchanged otherwise. (In the Arm ARM
psueodcode, pc[0] is hardwired to 0 in thumb mode.)
(3) Don't worry about matching PC[0] and CPSR[T], but do prevent an impossible situation
and unset PC[0] always. If PC[1] is set, and CPSR[T] is unset, then we'll raise unaligned
when the cpu restarts.
And, finally, you're missing the mc_vfp_* handling.
r~
