All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [4799] Add instruction counter.
Date: Sun, 29 Jun 2008 14:37:35 +0200	[thread overview]
Message-ID: <4867820F.8070002@web.de> (raw)
In-Reply-To: <E1KClJp-0000HC-Rt@cvs.savannah.gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Paul Brook wrote:
> Revision: 4799
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4799
> Author:   pbrook
> Date:     2008-06-29 01:03:05 +0000 (Sun, 29 Jun 2008)
> 
> Log Message:
> -----------
> Add instruction counter.

...

> +/* 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 = tb_find_pc((unsigned long)retaddr);
> +    if (!tb) {
> +        cpu_abort(env, "cpu_io_recompile: could not find TB for pc=%p", 
> +                  retaddr);
> +    }
> +    n = 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 fault
> +       occured.  */
> +    n = 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  parent reply	other threads:[~2008-06-29 12:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-29  1:03 [Qemu-devel] [4799] Add instruction counter Paul Brook
2008-06-29  4:44 ` C.W. Betts
2008-06-29  4:44   ` C.W. Betts
2008-06-29  9:58 ` Laurent Desnogues
2008-06-29 11:57   ` J. Mayer
2008-06-29 12:28     ` Paul Brook
2008-06-29 13:12       ` J. Mayer
2008-06-29 18:44   ` Stuart Brady
2008-06-29 12:37 ` Jan Kiszka [this message]
2008-06-29 13:16   ` [Qemu-devel] " Paul Brook
2008-06-29 13:54     ` Jan Kiszka
2008-06-29 14:31       ` Paul Brook
2008-07-10 23:04 ` [Qemu-devel] " Robert Reif
2008-07-11 16:42   ` Blue Swirl
2008-07-11 16:59   ` Julian Seward

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=4867820F.8070002@web.de \
    --to=jan.kiszka@web.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.