qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] ARM cortex-m3 instruction fetch misbehaves during do_v7m_


From: Peter Maydell
Subject: Re: [Qemu-arm] ARM cortex-m3 instruction fetch misbehaves during do_v7m_exception_exit
Date: Wed, 21 Feb 2018 13:41:46 +0000

On 21 February 2018 at 03:52, Rd Cheung <address@hidden> wrote:
> I am emulating TI RTOS(Texas Instrument real time operating system) on a
> cortex-M3 device. I have made boot up code work, but I am currently stuck at
> exception handler.
>
> when the code return from exception handler it goes to:
> 0x1001c90e:  b401b402  strlt    fp, [r1], #-0x402
>
> while it should be:
> 1001c90e:   B402                push       {r1}
> 1001c910:   B401                push       {r0}

That looks like the guest has returned with an incorrect
XPSR bit that specifies Arm mode, rather than Thumb mode
(and the guest will take an immediate UsageFault trying to
execute the next instruction, since M profile CPUs don't
implement Arm mode).

> I notice the TI RTOS return from an exception with PC with bit 0 set. But it
> should not be an issue of current qemu.

Which version of QEMU are you using? For v7M doing an exception
return to a PC with bit 0 set is UNPREDICTABLE and this is
always a bug in your guest code. QEMU will (in more recent
versions) ignore the set bit, as M3 hardware does. It will
also print a warning if you pass QEMU the option "-d guest_errors".
Older QEMU versions would attempt to start execution at the
odd address, but we can see from the disassembly that that
hasn't happened in your case.

However, the PC value doesn't affect whether we think the code
is in Arm or Thumb mode -- that is determined by the XPSR
value we pop off the stack, and specifically the XPSR.T bit.
You should look at what your guest code has set up as the
XPSR value.

thanks
-- PMM



reply via email to

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