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

[Peter Maydell]

> 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 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.