qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 22/24] bsd-user/arm/target_arch_signal.h: arm set_mcontext


From: Richard Henderson
Subject: Re: [PATCH 22/24] bsd-user/arm/target_arch_signal.h: arm set_mcontext
Date: Thu, 28 Oct 2021 10:53:39 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]