From: "Jakob Engblom" <jakob@virtutech.com>
To: "'Michael Snyder'" <msnyder@vmware.com>,
"'teawater'" <teawater@gmail.com>
Cc: "'Daniel Jacobowitz'" <drow@false.org>, <gdb@sourceware.org>
Subject: RE: [discuss] semantics, "replay debugging" vs. "reverse debugging"
Date: Wed, 22 Oct 2008 19:38:00 -0000 [thread overview]
Message-ID: <011401c9347d$aa97a0f0$ffc6e2d0$@com> (raw)
In-Reply-To: <48FF6C46.1020402@vmware.com>
> > Sorry I am wrong.
> > In ARM, Just adds set cpsr reg. So:
> > add r0,r0,#10
> > Can reverse without record too.
>
> OK, well, I was really speaking in the abstract.
> I only meant "it's possible to imagine a target or
> architecture in which reverse execution can be done
> by some means other than record/replay".
>
> Didn't necessarily mean that it could be done on any
> real, existing architecture.
Just to add some more to this:
1. Simics is such a target, as is really any deterministic simulator that is
running without any asynchronous (from the perspective of the simulator program)
inputs. Typical cases involve booting a machine, which tends to be
non-interactive. Or running a program that has all its input data compiled into
it or read from some place that is already on the target. And you could say
that this is a degenerate form of record, since you DO have to "record" the
initial state in some way, even if the initial state is something that you write
yourself as a simulator configuration. It is recorded in a form that can be
brought back identically.
2. There are some odd-ball ideas in computer architecture close to the thinking
behing transactional memory where you do checkpoint and restore and reexecute
inside an actual physical CPU core. These might also for limited scopes support
reversing without replay.
But in general, the only way to get back to an earlier state is to record how to
get there, usually from some even earlier point. Alternatively, use a
tape-recorder analogy and just have a limited buffer with interesting data.
Best regards,
/jakob
_______________________________________________________
Jakob Engblom, PhD, Technical Marketing Manager
Virtutech Direct: +46 8 690 07 47
Drottningholmsvägen 14 Mobile: +46 709 242 646
11243 Stockholm Web: www.virtutech.com
Sweden
________________________________________________________
next prev parent reply other threads:[~2008-10-22 19:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-20 1:14 Michael Snyder
2008-10-20 8:11 ` Frederic Riss
2008-10-20 16:08 ` teawater
2008-10-21 7:29 ` Jakob Engblom
2008-10-22 3:26 ` teawater
2008-10-22 13:37 ` Daniel Jacobowitz
2008-10-22 16:19 ` teawater
2008-10-22 16:43 ` teawater
2008-10-22 16:48 ` teawater
2008-10-22 17:09 ` Dave Korn
2008-10-22 17:19 ` teawater
2008-10-22 18:14 ` Michael Snyder
2008-10-22 19:38 ` Jakob Engblom [this message]
2008-10-23 3:46 ` teawater
2008-10-23 8:35 ` Jeremy Bennett
2008-10-23 10:43 ` Jakob Engblom
2008-10-23 3:39 ` teawater
2008-10-21 7:27 ` Jakob Engblom
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='011401c9347d$aa97a0f0$ffc6e2d0$@com' \
--to=jakob@virtutech.com \
--cc=drow@false.org \
--cc=gdb@sourceware.org \
--cc=msnyder@vmware.com \
--cc=teawater@gmail.com \
/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