Comment 9 for bug 757702

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
<email address hidden>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 <email 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
>>
>
>