From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCxwD-0007vj-Ax for qemu-devel@nongnu.org; Sun, 29 Jun 2008 10:31:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCxwB-0007vV-Rp for qemu-devel@nongnu.org; Sun, 29 Jun 2008 10:31:32 -0400 Received: from [199.232.76.173] (port=51050 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCxwB-0007vS-Lw for qemu-devel@nongnu.org; Sun, 29 Jun 2008 10:31:31 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:46586) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KCxwB-0006HZ-6z for qemu-devel@nongnu.org; Sun, 29 Jun 2008 10:31:31 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [4799] Add instruction counter. Date: Sun, 29 Jun 2008 15:31:27 +0100 References: <200806291416.06603.paul@codesourcery.com> <4867942C.205@web.de> In-Reply-To: <4867942C.205@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806291531.27662.paul@codesourcery.com> 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 Cc: Jan Kiszka On Sunday 29 June 2008, Jan Kiszka wrote: > Paul Brook wrote: > >> On the first glance this function looked like it could serve as an > >> alternative to SSTEP_INTERNAL and provide the required roll-back on > >> watchpoint hit. But looking closer I realized that icount_decr is only > >> maintained if use_icount is set. > > > > I'm fairly sure limiting the length of the TB and actual instruction > > counting are largely independent. IIUC you only need the former. > > But to calculate the former, you need the latter again. Not really. You only need to know how far through the TB you got before the trap occurred. > I wonder if it > wouldn't be more efficient and flexible to specify a terminating PC > instead of an instruction count. Wouldn't that make cpu_io_recompile > independent of icount_decr and, thus, use_icount? Ah, I see what you're getting at. cpu_restore_state modifies icount_decr to indicate how far through the TB we got. That's can be independent of use_icount. A terminating PC is much less useful. In general the only instruction you really know the location of is the one you're currently at. Paul