From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlxkO-0005ZF-KE for qemu-devel@nongnu.org; Tue, 03 Jul 2012 03:42:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlxkM-0007Lw-Nl for qemu-devel@nongnu.org; Tue, 03 Jul 2012 03:42:08 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:60399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlxkM-0007Li-Hc for qemu-devel@nongnu.org; Tue, 03 Jul 2012 03:42:06 -0400 Received: by bkty12 with SMTP id y12so1556850bkt.4 for ; Tue, 03 Jul 2012 00:42:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 3 Jul 2012 08:42:03 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] target ARM PC increment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Munday Cc: qemu-devel@nongnu.org On 3 July 2012 01:53, David Munday wrote: > I'm developing with QEMU to run arm binaries. Right now I can't tell if the > Thumb32 vmul.f64 instruction encoded(ee25 7b07) is executing or not. I would > like to see where QEMU increments the PC so as to see if this instruction is > getting skipped or to trace it's behavior. > > I've looked extensively through cpu-exec.c and target-arm/cpu.h but have yet > to find where I can print the PC of each instruction executed. You can't, at least not easily. The PC is only updated: * at the end of a basic block * before certain operations that require register state to be correct * in the exception handling path for things like loads which aborted Having an explicit "add 4 to PC" after each instruction would be a lot of overhead in the common case, which is why we don't do it that way. The easiest way to check if the instruction is actually doing something is probably to use qemu's built in debug stub and connect an ARM gdb to it. Then you can single step in the gdb and look at register values before and after. If you want to check whether we're actually generating code of some kind for the instruction, then run QEMU under an x86 gdb and put a breakpoint on disas_thumb_insn(), conditional on s->pc being the location of the insn you're interested in. Then step through... Or use the '-d' options to trace incoming and outgoing assembly. (NB: I'm assuming you're using at least QEMU1.0 here. Older QEMU had a number of problems with the VFP and Neon emulation; using them is likely to be a waste of your time.) -- PMM