From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QA2a5-0006ab-Ug for qemu-devel@nongnu.org; Wed, 13 Apr 2011 12:06:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QA2Zv-0001pA-Pv for qemu-devel@nongnu.org; Wed, 13 Apr 2011 12:06:13 -0400 Received: from adelie.canonical.com ([91.189.90.139]:52270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QA2Zv-0001ot-JK for qemu-devel@nongnu.org; Wed, 13 Apr 2011 12:06:03 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1QA2Zr-0004o1-BA for ; Wed, 13 Apr 2011 16:05:59 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 097952E89A9 for ; Wed, 13 Apr 2011 16:05:54 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 15:57:51 -0000 From: Anup Patel <757702@bugs.launchpad.net> Sender: bounces@canonical.com References: <20110411161233.16764.21820.malonedeb@soybean.canonical.com> <20110413115426.23682.17659.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 I think you are right. This seems to be more of a GDB issue. Any ways thanks for your support. --Anup On Wed, Apr 13, 2011 at 5:24 PM, Peter Maydell wrote: > > Were you able to replicate the problem with the steps that I had > mentioned ? > > The key thing is is if you don't set breakpoint at 0x4 or 0x8 just foll= ow > > the execution flow using "si" command of GDB. > > You will definitely hit the problem. > > Ah, I had to find a different gdb to reproduce this with (arm-none-eabi- > gdb from the 2010.09 codesourcery toolchain). That gdb does single-step- > insn by asking the target to single step, and you get the behaviour > above. The gdb I was using does single-step-insn by setting breakpoints > at where it thinks the next insn will be, which means that "si" on the > UNDEF never returns because gdb has set a bp at 0x10005c which we of > course never hit. With the codesourcery gdb I see 'si' having the > behaviour you describe above. > > However: > > (gdb) target remote :1234 > Remote debugging using :1234 > 0x00100000 in ?? () > (gdb) break *0x4 > Breakpoint 1 at 0x4 > (gdb) si > 0x00100054 in ?? () > (gdb) si > 0x00100058 in ?? () > (gdb) si > > Breakpoint 1, 0x00000004 in ?? () > > ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's > just that the singlestep doesn't do what you expect: instead of stopping > before we execute the instruction at the UNDEF vector, we first execute > it and then stop afterwards [this sort of makes a twisted kind of sense > if you think about it -- we never actually executed the UNDEF insn > because we took the exception first, so single-step executes exactly one > instruction which is the one at 0x4. However it's hopelessly confusing > for the user so I'd consider it a bug.] > > Can you confirm that if you set the breakpoint as I do in the transcript > above you see the same output? > > So I think that what is happening here is that misbehaviour by qemu's > gdb interface is confusing you, rather than the actual qemu ARM > implementation being wrong. > > If you revise your test program so that it installs some actual code > into the vectors rather than leaving them all as NOPs I think this will > be more obvious. > > -- > 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.