From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCwA4-0004E7-Do for qemu-devel@nongnu.org; Sun, 29 Jun 2008 08:37:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCwA3-0004Cy-3n for qemu-devel@nongnu.org; Sun, 29 Jun 2008 08:37:43 -0400 Received: from [199.232.76.173] (port=49612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCwA2-0004Ck-Ka for qemu-devel@nongnu.org; Sun, 29 Jun 2008 08:37:42 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:50039) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCwA2-0005ky-An for qemu-devel@nongnu.org; Sun, 29 Jun 2008 08:37:42 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 26FF4E39A20D for ; Sun, 29 Jun 2008 14:37:40 +0200 (CEST) Received: from [88.64.4.12] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KCwA0-000703-00 for qemu-devel@nongnu.org; Sun, 29 Jun 2008 14:37:40 +0200 Message-ID: <4867820F.8070002@web.de> Date: Sun, 29 Jun 2008 14:37:35 +0200 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF8F25891A9DFEFAE9D7B47F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [4799] Add instruction counter. 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF8F25891A9DFEFAE9D7B47F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: > Revision: 4799 > http://svn.sv.gnu.org/viewvc/?view=3Drev&root=3Dqemu&revision= =3D4799 > Author: pbrook > Date: 2008-06-29 01:03:05 +0000 (Sun, 29 Jun 2008) >=20 > Log Message: > ----------- > Add instruction counter. =2E.. > +/* in deterministic execution mode, instructions doing device I/Os > + must be at the end of the TB */ > +void cpu_io_recompile(CPUState *env, void *retaddr) > +{ > + TranslationBlock *tb; > + uint32_t n, cflags; > + target_ulong pc, cs_base; > + uint64_t flags; > + > + tb =3D tb_find_pc((unsigned long)retaddr); > + if (!tb) { > + cpu_abort(env, "cpu_io_recompile: could not find TB for pc=3D%= p",=20 > + retaddr); > + } > + n =3D env->icount_decr.u16.low + tb->icount; > + cpu_restore_state(tb, env, (unsigned long)retaddr, NULL); > + /* Calculate how many instructions had been executed before the fa= ult > + occured. */ > + n =3D n - env->icount_decr.u16.low; > + /* Generate a new TB ending on the I/O insn. */ > + n++; 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. But that appears to be optional and default off. Now I'm wondering if I should simply rebase my roll-back approach or if I should try to generalize yours in order to get the debugging series work again. I do not yet get why you were forced to go a different path for cpu_io_recompile, ie. rebuilding and (re-executing?) the whole TB up to the instruction that caused the IO access instead of just regenerating a single-insn TB for that purpose. Is it more efficient? But if use_icount is off by default, I guess this doesn't come for free either... Jan --------------enigAF8F25891A9DFEFAE9D7B47F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhnghMACgkQniDOoMHTA+l5bACdFwgJUCXvd7y8Ma5xSAFnZ52O fFoAmwYI5XBc+5C1K0IPwnn9hEWVHewh =1P6N -----END PGP SIGNATURE----- --------------enigAF8F25891A9DFEFAE9D7B47F--