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

[Rd Cheung]

>  Odd. In that case what should happen is that the call to
>  xpsr_write() should cause env->thumb to be set, which is
>  the QEMU internal state that tracks whether we are in Arm
>  or Thumb mode.
> 
>  I would recommend adding also int,exec,cpu,unimp to your tracing
>  options. That will allow you to confirm exactly what the CPU
>  state on return from the exception is, because it will print
>  a register state dump to the log. (the 'cpu' and 'exec' logs
>  do slow down the emulation a lot, but hopefully this bug
>  happens early in execution.)

I have turned on the log options and I find out the execution will go

into the same interrupt service routine for multiple times as soon as

it exits from execption handler, before it hits its expected return address. 

So I look into the NVIC registers in cortex M3. I find out the ISPR 

register (interrupt set pending registers) in NVIC is not function normally. 

I made a breakpoint just before the code exit the exception handler. 

And I use 'x /20xw 0xe000e200' to check the ISPR register. At this point, the

value is 0x0, and then I type 'si' to gdb, and the code go to the expected return

 address. Then I 'x /20xw 0xe000e200' again, but this time, the value is 0x10, 

which indicates an interrupt is pending. If I type 'c' in gdb, the code will go to the 

interrupt service routine again.

Do you have any idea in mind?

Thanks a lot! I am looking forward to your reply.

Ruide Zhang

On Wed, Feb 21, 2018 at 10:09 AM, Peter Maydell <address@hidden> wrote:

On 21 February 2018 at 14:25, Rd Cheung <address@hidden> wrote:
> Yes, this looks like misusing ARM mode instead of Thumb mode to me.
> I just checked the local variable xpsr in function do_v7m_exception_exit()
> by adding a qemu_log_mask line at the end of the function. I turn on log by
> -d in_asm,guest_errors. And the xpsr = 0x1000000, which has its bit 24 set
> to 1.
> And bit 24 is the indicator of Thumb state according to ARM info center. So
> it
> should be correct, or am I getting something wrong?

Odd. In that case what should happen is that the call to
xpsr_write() should cause env->thumb to be set, which is
the QEMU internal state that tracks whether we are in Arm
or Thumb mode.

I would recommend adding also int,exec,cpu,unimp to your tracing
options. That will allow you to confirm exactly what the CPU
state on return from the exception is, because it will print
a register state dump to the log. (the 'cpu' and 'exec' logs
do slow down the emulation a lot, but hopefully this bug
happens early in execution.)

thanks
-- PMM