From: Rob Landley <rob@landley.net>
To: Mark Burton <mark.burton@greensocs.com>
Cc: "Blue Swirl" <blauwirbel@gmail.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"KONRAD Frédéric" <fred.konrad@greensocs.com>
Subject: Re: [Qemu-devel] [RFC] reverse execution.
Date: Sun, 19 May 2013 16:39:57 -0500 [thread overview]
Message-ID: <1368999597.2776.0@driftwood> (raw)
In-Reply-To: <019C9E6F-6C2C-4D59-BB88-974F498337EB@greensocs.com> (from mark.burton@greensocs.com on Sun May 19 15:09:14 2013)
On 05/19/2013 03:09:14 PM, Mark Burton wrote:
> Spot on Peter,
> The (simplistic) plan is simply to take a snapshot at regular
> intervals,
> when you want to step backwards, you return to a snapshot, and then
> re-run
> forwards to 'just before you started'.
You'd have to snapshot all of memory because any of it could be used
for branching decisions. You'd have to snapshot the state of I/O
devices for the same reason. This includes serial ports and keyboards
and your hardware random number generator and the timer interrupt and
disk interrupts, all of which you have to log and replay the input
from, and get the timing exactly right for the interrupts they
generate. (It has to happen at the right spot because it's used to
update the random number pool, it can affect scheduling decisions...)
Good luck with that.
A horrid thing you might do is log the instruction pointer every time
it changes into a (giant) ring buffer. Possibly instrument tcg to write
up that register every time it has to actually know it (jumps and when
interrupts happen). (You don't have to know "advanced to next
instruction". You do have to know "advanced to something other than
next instruction".) It'll be slow and painful, but might be possible.
Then again to make it work you'd have to log not just where you went
but where you came _from_ so you could see that you got there and it's
time to jump again (interrupts again, doesn't mean it's a normal
departure point, could be a signal). And the problem is do you record
the target's idea of "from" or the translated host idea of "from"...
Rob
next prev parent reply other threads:[~2013-05-19 21:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 18:27 [Qemu-devel] [RFC] reverse execution KONRAD Frédéric
2013-05-09 17:54 ` Blue Swirl
2013-05-17 17:23 ` KONRAD Frédéric
2013-05-17 17:54 ` Peter Maydell
2013-05-17 19:16 ` Mark Burton
2013-05-23 1:57 ` Edgar E. Iglesias
2013-05-18 18:52 ` Blue Swirl
2013-05-22 16:14 ` KONRAD Frédéric
2013-05-19 4:37 ` Rob Landley
2013-05-19 7:21 ` Peter Maydell
2013-05-19 20:09 ` Mark Burton
2013-05-19 21:20 ` Peter Maydell
[not found] ` <CAD2=zRDphd7N5gCQeX6oVQP=HEbRRMpcwPKEVDj46DHKhgkKMw@mail.gmail.com>
2013-05-19 21:47 ` Brendan Dolan-Gavitt
2013-05-20 5:28 ` Mark Burton
2013-05-19 21:39 ` Rob Landley [this message]
2013-05-20 5:34 ` Mark Burton
2013-05-29 12:37 ` Pavel Dovgaluk
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=1368999597.2776.0@driftwood \
--to=rob@landley.net \
--cc=blauwirbel@gmail.com \
--cc=fred.konrad@greensocs.com \
--cc=mark.burton@greensocs.com \
--cc=peter.maydell@linaro.org \
--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).