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