Hi, You are right, I have deliberately used an instruction from a "permanently UNDEF" space. I have used this instruction because thats this are the only UNDEF instructions with maximum payload of 20 bits.
Also, the instruction "0xec019800" does not belong to STC instruction space. GNU object dump does not display it as undefined instruction due to internal bug, but it is definitely an undefined instruction. May be the undefined instructions from "permanently UNDEF" space are only executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU 0.13.0. PFA, my test elf file. The UNDEF instruction that i have reported is at location 0x100058 in this elf file. The execution of elf file starts from 0x100000. I have launched qemu with command: ./qemu-system-arm -s -S -M realview-pb-a8 -serial stdio -kernel ../../../xvisor/tests/armv7/pb-a8/arm_test.elf I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf --eval-command="target remote localhost:1234" Please let me know if you are not able to reproduce the bug. --Anup On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <peter.mayd...@linaro.org>wrote: > > 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). > > PS: please don't use arbitrary UNDEF instruction patterns for this (the one > you quoted is in the STC instruction space for example). There's an > officially-defined "permanently UNDEF" space: > cond 0111 1111 xxxx xxxx xxxx 1111 xxxx > available for this purpose, which will mean you don't have to worry about > newer versions of the architecture allocating the UNDEF patterns you were > using. > > -- > 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 > ** Attachment added: "arm_test.elf" https://bugs.launchpad.net/bugs/757702/+attachment/2023365/+files/arm_test.elf -- 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.