From: Paul Brook <paul@codesourcery.com>
To: Lluís <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>
Subject: Re: [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing)
Date: Fri, 26 Nov 2010 21:33:33 +0000 [thread overview]
Message-ID: <201011262133.33637.paul@codesourcery.com> (raw)
In-Reply-To: <87lj4f4z2t.fsf@ginnungagap.bsc.es>
> > 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
next prev parent reply other threads:[~2010-11-26 21:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 21:42 [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing) Lluís
2010-11-26 19:06 ` Paul Brook
2010-11-26 20:19 ` Lluís
2010-11-26 21:33 ` Paul Brook [this message]
2010-11-29 15:04 ` Lluís
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011262133.33637.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=cyfdecyf@gmail.com \
--cc=eduardohmdacruz@gmail.com \
--cc=junkoi2004@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=xscript@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).