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

[Anup Patel <757702@bugs.launchpad.net>]

Also, in the test case hits 0x8 after encountering UNDEF instruction at
0x100058.
The test case is not broken it failed in initialization sequence itself.

PS: I had download most recent version of QEMU 0.14.0 and build it my
self.

On Tue, Apr 12, 2011 at 4:33 PM, Anup Patel
<anuppatelinvincible@gmail.com>wrote:

> 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 <peter.maydell@linaro.org>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.