From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9beL-0002BK-Cx for qemu-devel@nongnu.org; Tue, 12 Apr 2011 07:20:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9beJ-0001on-80 for qemu-devel@nongnu.org; Tue, 12 Apr 2011 07:20:49 -0400 Received: from adelie.canonical.com ([91.189.90.139]:36033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9beI-0001oK-Pt for qemu-devel@nongnu.org; Tue, 12 Apr 2011 07:20:47 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1Q9beF-000600-T0 for ; Tue, 12 Apr 2011 11:20:44 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id B157F2E8979 for ; Tue, 12 Apr 2011 11:20:40 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 11:10:40 -0000 From: Anup Patel <757702@bugs.launchpad.net> Sender: bounces@canonical.com References: <20110411161233.16764.21820.malonedeb@soybean.canonical.com> <20110412104919.23935.45193.malone@wampee.canonical.com> Message-Id: Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 757702] Re: Undefined instruction exception starts at offset 0x8 instead of 0x4 Reply-To: Bug 757702 <757702@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 wrote: > Actually, the undefined instruction that I have used is documented as > undefined at two places in "ARM Instruction Set Encoding" section of ARMv= 7a > 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 S= TC > space. Actually speaking this UNDEF instruction spans not only in STC spa= ce > but also in LDC space. > > --Anup > > On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell = 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=3D0 U=3D0 D=3D0 W=3D0 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 >> + 0x4, where 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 +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 + 0x4, where 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 +0x4 since "0xec019800" is an undefined instruction.