From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [Qemu-devel] Re: [4799] Add instruction counter.
Date: Sun, 29 Jun 2008 15:31:27 +0100 [thread overview]
Message-ID: <200806291531.27662.paul@codesourcery.com> (raw)
In-Reply-To: <4867942C.205@web.de>
On Sunday 29 June 2008, Jan Kiszka wrote:
> Paul Brook wrote:
> >> 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.
> >
> > I'm fairly sure limiting the length of the TB and actual instruction
> > counting are largely independent. IIUC you only need the former.
>
> But to calculate the former, you need the latter again.
Not really. You only need to know how far through the TB you got before the
trap occurred.
> I wonder if it
> wouldn't be more efficient and flexible to specify a terminating PC
> instead of an instruction count. Wouldn't that make cpu_io_recompile
> independent of icount_decr and, thus, use_icount?
Ah, I see what you're getting at. cpu_restore_state modifies icount_decr to
indicate how far through the TB we got. That's can be independent of
use_icount.
A terminating PC is much less useful. In general the only instruction you
really know the location of is the one you're currently at.
Paul
next prev parent reply other threads:[~2008-06-29 14:31 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 ` [Qemu-devel] " Jan Kiszka
2008-06-29 13:16 ` Paul Brook
2008-06-29 13:54 ` Jan Kiszka
2008-06-29 14:31 ` Paul Brook [this message]
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=200806291531.27662.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=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.