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

[Peter Maydell]

> Also, the instruction "0xec019800" does not belong to STC instruction
space.

Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 imm:8
For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in STC 
space. This is not "permanently UNDEF", it might be allocated to do something 
in future.

> PFA, my test elf file.

Thanks. Your test case appears to be broken in that it doesn't actually set up 
the vector table at address 0:
cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble ~/Desktop/arm_test.elf 
|less

[...]
Disassembly of section .text:

00100000 <_start_vect>:
  100000:       e59ff018        ldr     pc, [pc, #24]   ; 100020 <__reset>
  100004:       e59ff018        ldr     pc, [pc, #24]   ; 100024 
<__undefined_instruction>
  100008:       e59ff018        ldr     pc, [pc, #24]   ; 100028 
<__software_interrupt>
  10000c:       e59ff018        ldr     pc, [pc, #24]   ; 10002c 
<__prefetch_abort>
  100010:       e59ff018        ldr     pc, [pc, #24]   ; 100030 <__data_abort>
  100014:       e59ff018        ldr     pc, [pc, #24]   ; 100034 <__not_used>
  100018:       e59ff018        ldr     pc, [pc, #24]   ; 100038 <__irq>
  10001c:       e59ff018        ldr     pc, [pc, #24]   ; 10003c <__fiq>

So what happens is:
0x00100000:  e59ff018      ldr  pc, [pc, #24]   # qemu starts us at the ELF 
entry point
0x00100054:  e3a08000      mov  r8, #0  ; 0x0 
0x00100054:  e3a08000      mov  r8, #0  ; 0x0
0x00100058:  ec019800      stc  8, cr9, [r1], {0}   # here's our UNDEF
0x00000004:  00000000      andeq        r0, r0, r0   # jump to UNDEF vector at 
0x4 as expected
...but since nothing was loaded at address 0 the code is all NOPs and we just 
execute through it...
0x00000008:  00000000      andeq        r0, r0, r0
0x0000000c:  00000000      andeq        r0, r0, r0
0x00000010:  00000000      andeq        r0, r0, r0
...etc...

and eventually we fall into the actual image start at 0x100000, and we
go round in a big loop.

You can tell we're going to the correct vector if you ask gdb to put a
breakpoint there with "break *0x4" -- we hit it after executing the
undef.

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