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

[Anup Patel]

Actually, the undefined instruction that I have used is documented as
undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a
reference manual:
1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions"
2. Refer "A8.6.188 STC, STC2"

So you see one can easily get confused that this instruction belongs to STC
space. Actually speaking this UNDEF instruction spans not only in STC space
but also in LDC space.

--Anup

On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell
<address@hidden>wrote:

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