Re: [Qemu-devel] [Bug 757702] Re: Undefined instruction exception starts at offset 0x8 instead of 0x4

[Anup Patel]

I think you are right. This seems to be more of a GDB issue.

Any ways thanks for your support.

--Anup

On Wed, Apr 13, 2011 at 5:24 PM, Peter Maydell
<address@hidden>wrote:

> > Were you able to replicate the problem with the steps that I had
> mentioned ?
> > The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow
> > the execution flow using "si" command of GDB.
> > You will definitely hit the problem.
>
> Ah, I had to find a different gdb to reproduce this with (arm-none-eabi-
> gdb from the 2010.09 codesourcery toolchain). That gdb does single-step-
> insn by asking the target to single step, and you get the behaviour
> above. The gdb I was using does single-step-insn by setting breakpoints
> at where it thinks the next insn will be, which means that "si" on the
> UNDEF never returns because gdb has set a bp at 0x10005c which we of
> course never hit. With the codesourcery gdb I see 'si' having the
> behaviour you describe above.
>
> However:
>
> (gdb) target remote :1234
> Remote debugging using :1234
> 0x00100000 in ?? ()
> (gdb) break *0x4
> Breakpoint 1 at 0x4
> (gdb) si
> 0x00100054 in ?? ()
> (gdb) si
> 0x00100058 in ?? ()
> (gdb) si
>
> Breakpoint 1, 0x00000004 in ?? ()
>
> ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's
> just that the singlestep doesn't do what you expect: instead of stopping
> before we execute the instruction at the UNDEF vector, we first execute
> it and then stop afterwards [this sort of makes a twisted kind of sense
> if you think about it -- we never actually executed the UNDEF insn
> because we took the exception first, so single-step executes exactly one
> instruction which is the one at 0x4. However it's hopelessly confusing
> for the user so I'd consider it a bug.]
>
> Can you confirm that if you set the breakpoint as I do in the transcript
> above you see the same output?
>
> So I think that what is happening here is that misbehaviour by qemu's
> gdb interface is confusing you, rather than the actual qemu ARM
> implementation being wrong.
>
> If you revise your test program so that it installs some actual code
> into the vectors rather than leaving them all as NOPs I think this will
> be more obvious.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/757702
>
> Title:
>  Undefined instruction exception starts at offset 0x8 instead of 0x4
>
> Status in QEMU:
>  New
>
> Bug description:
>  ARMv7a has lot of undefined instruction from its instruction opcode
>  space. This undefined instructions are very useful for replacing
>  sensitive non-priviledged instructions of guest operating systems
>  (virtualization). The undefined instruction exception executes at
>  <exception_base> + 0x4, where <exception_base> can be 0x0 or
>  0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at
>  0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0,
>  seems like this is a new bug. As as example, if we try to execute
>  value "0xec019800" in qemu 0.14.0 then it should cause undefined
>  exception at <exception_base>+0x4 since "0xec019800" is an undefined
>  instruction.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/757702

Title:
  Undefined instruction exception starts at offset 0x8 instead of 0x4

Status in QEMU:
  New

Bug description:
  ARMv7a has lot of undefined instruction from its instruction opcode
  space. This undefined instructions are very useful for replacing
  sensitive non-priviledged instructions of guest operating systems
  (virtualization). The undefined instruction exception executes at
  <exception_base> + 0x4, where <exception_base> can be 0x0 or
  0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at
  0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0,
  seems like this is a new bug. As as example, if we try to execute
  value "0xec019800" in qemu 0.14.0 then it should cause undefined
  exception at <exception_base>+0x4 since "0xec019800" is an undefined
  instruction.