qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Bug 1428657] [NEW] qemu-system-arm does not ignore the


From: Peter Maydell
Subject: Re: [Qemu-devel] [Bug 1428657] [NEW] qemu-system-arm does not ignore the lowest bit of pc when returning from interrrupt
Date: Sun, 8 Mar 2015 19:43:22 +0900

On 5 March 2015 at 23:15, Anders Esbensen <address@hidden> wrote:
> Public bug reported:
>
> This was observed in qemu v2.1.3, running a sample app from
>
> FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo)
>
> In the sample code compiled with arm-none-eabi-gcc , version 4.8.2
> (4.8.2-14ubuntu1+6) .
>
> qemu seems to be executing the wrong instrunction after returning from
> the SVCHandler. The svc handler changes the PSP register and the new
> stack contains an add return address, which should be
> allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html).
> The lowest bit of the address should be ignored, but it seems that qemu
> executes garbage after returning from the interrupt.

So if I understand you correctly, the guest is executing
a return-from-exception (via a bx lr instruction where the
return address is one of the 0xffffffXX special cases), and
the PC value in the exception frame we're restoring has
its least significant bit set?

If so, then this is a guest bug. In an exception frame the
PC must be halfword aligned (ie must have the ls bit clear),
because the "is this Thumb or not?" information is stored in
the PSR field in the exception frame. If the LSB of the PC
is set then the behaviour is UNPREDICTABLE (see the PopStack
pseudocode in the ARMv7M ARM ARM). Real hardware seems to
ignore the LSbit, but QEMU's behaviour is architecturally
permitted and you should really fix your guest code.

(The ARM knowledgebase article you give a link to correctly
notes that the LSbit in vector table entries and normal
branch targets is significant, but says nothing about the
PC in exception frames.)

thanks
-- PMM



reply via email to

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