From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60666 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PM5vQ-0003Pb-VM
	for qemu-devel@nongnu.org; Fri, 26 Nov 2010 16:33:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PM5vP-0002Vm-Ig
	for qemu-devel@nongnu.org; Fri, 26 Nov 2010 16:33:48 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:44386)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PM5vP-0002Vb-66
	for qemu-devel@nongnu.org; Fri, 26 Nov 2010 16:33:47 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing)
Date: Fri, 26 Nov 2010 21:33:33 +0000
References: <86ocdj74qd.wl%lluis@ginnungagap.pc.ac.upc.edu>
	<201011261906.32380.paul@codesourcery.com>
	<87lj4f4z2t.fsf@ginnungagap.bsc.es>
In-Reply-To: <87lj4f4z2t.fsf@ginnungagap.bsc.es>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201011262133.33637.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?iso-8859-15?q?Llu=EDs?= <xscript@gmx.net>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, Yufei Chen <cyfdecyf@gmail.com>, qemu-devel@nongnu.org, Eduardo Cruz <eduardohmdacruz@gmail.com>, Jun Koi <junkoi2004@gmail.com>

> > Likewise requiring separate tracing hooks be added to the existing
> > decoders is extremely unlikely to be a feasible long-term
> > solution.
> 
> You mean having to modify each "translate.c"? The worst event to handle
> is instruction fetch on x86.

Instruction fetches are trivial, you just intercept calls to ld*_code.

> > I'd also posit that instrumenting changes in sate is of very limited use
> > if you don't know what the new value is.
> 
> I don't understand what you mean here.

Your proposed FETCH macro instrumented which registers are modified by an 
insn, but did not the actual values about to be written to those registers.
 
> > You almost certainly want to do this using the equivalent of a memory
> > watchpoint on the CPUState structure.
> 
> Sorry, do what?

All guest register values are held in the CPUState structure. So to instrument 
accesses to guest state you just need to intercept TCG accesses to this 
structure, either via explicit ld/st ops, or via a global_mem. To a first 
approximation you can probably get away with just the latter.

Paul