From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JhQBv-0005MT-3i for qemu-devel@nongnu.org; Thu, 03 Apr 2008 10:13:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JhQBr-0005I4-Lb for qemu-devel@nongnu.org; Thu, 03 Apr 2008 10:13:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JhQBq-0005GN-PN for qemu-devel@nongnu.org; Thu, 03 Apr 2008 10:13:18 -0400 Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JhQBq-0003MQ-38 for qemu-devel@nongnu.org; Thu, 03 Apr 2008 10:13:18 -0400 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080403141603.ZIHJ28015.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Thu, 3 Apr 2008 15:16:03 +0100 Received: from miranda.arrow ([213.107.26.151]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080403141701.JVS219.aamtaout01-winn.ispmail.ntl.com@miranda.arrow> for ; Thu, 3 Apr 2008 15:17:01 +0100 Received: from sdb by miranda.arrow with local (Exim 4.63) (envelope-from ) id 1JhQBl-00047g-FC for qemu-devel@nongnu.org; Thu, 03 Apr 2008 15:13:13 +0100 Date: Thu, 3 Apr 2008 15:13:13 +0100 From: Stuart Brady Subject: Re: [Qemu-devel] Instruction trace for ARM target Message-ID: <20080403141313.GA15754@miranda.arrow> References: <1207164499.9736.32.camel@goffart-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1207164499.9736.32.camel@goffart-laptop> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Apr 02, 2008 at 09:28:19PM +0200, Klaus Goffart wrote: > But, I'm not sure if these are all pc values. I do not completely > understand the way the helper_dump_pc() method is called, but it seems > that it is triggered in the disas_insn() respectively the > disas_arm_insn() method. But isn't each instruction just disassembled > once and then cached for the next execution? Then the corresponding pc > values would be missing. That's why disas_insn() should call gen_op_dump_pc(), instead of calling helper_dump_pc() directly. Calling gen_op_dump_pc() adds the code needed to call helper_dump_pc() to the translation block that is currently being generated. Actually, with the code in SVN, you'd probably want something like: tcg_gen_helper_0_1(helper_dump_pc, tcg_const_ptr(s->pc)); You would then no longer need op_dump_pc(). The program counter isn't updated after each instruction is executed for performance reasons, so it's passed as a parameter during translation, whenever it is needed. On the other hand, when the program counter is finally updated (e.g. after a conditional branch) you often can't determine its new value at translation time -- but where the instruction fetch occurs, this isn't a problem! > To get the instructions being executed I call the ldl_code() method with > the actual pc value in the helper_dump_pc() method. It seems to work, > but it would be great if anybody could just point out if this is > correct. If by 'actualy pc value', you mean the PC in the CPUState ('env'), then I'm very surprised that this would appear to produce correct output. > My next step is to mark those instructions that are not executed due to > their condition codes and the memory accessed by executed instructions. > But I have no idea where this information is available. Can anybody give > me a clue? Well, you'd certainly have to generate extra ops to mark instructions as executed, as instruction fetches occur at translation time. For memory access, you could modify the memory accessors to perform the marking... probably by adding helper calls in tcg-op.h. Cheers, -- Stuart Brady