qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Laurent Desnogues" <laurent.desnogues@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [RFD] Translation block instrumentation and multiple TCG code buffers
Date: Wed, 23 Jul 2008 16:55:33 +0200	[thread overview]
Message-ID: <761ea48b0807230755k25f8a580k69597eedb6c73c15@mail.gmail.com> (raw)

Hello,

some people are interested in instrumenting translated blocks for
various reasons.  For instance, Paul Brook added instruction counting;
another use includes instruction profiling.

Both these examples require the full basic block to have been
translated, while the counters updates should be at the beginning of
the translated block.

To achieve that, Paul did what he calls a "horrid hack": generate a tcg
subi which is patched with the correct count once the BB has been
translated.

When there is a single instruction to patch one can live with that
hack, but when one wants more, something cleaner is definitely needed.

One possible solution would be to have two tcg code buffers.
Instrumentation tcg ops would go into the second buffer;  that second
buffer would generate code before generating code for the translated
block.

I think the cleanest way to do that would be to move gen_opc_ptr and
gen_opparam_ptr to the tcg context (BTW this is already hinted in
tcg.c) and have a mechanism to change between the first and second
buffer when needed.  (Note I am not sure using multiple tcg contexts is
really the way to go at the moment given the way some of the code
assumes a single context exists [for instance the profiler].)

One could be more ambitious and have more than two buffers (for
instance, Paul's counter has to generate code that goes after the BB
has been translated), but that could come later.

What do people think?

Cheers,

                        Laurent

                 reply	other threads:[~2008-07-23 14:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=761ea48b0807230755k25f8a580k69597eedb6c73c15@mail.gmail.com \
    --to=laurent.desnogues@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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).