From: teawater <teawater@gmail.com>
To: "Jakob Engblom" <jakob@virtutech.com>
Cc: "Michael Snyder" <msnyder@vmware.com>, gdb@sourceware.org
Subject: Re: [discuss] semantics, "replay debugging" vs. "reverse debugging"
Date: Wed, 22 Oct 2008 03:26:00 -0000 [thread overview]
Message-ID: <daef60380810212025w3a49208am47d0b851830fd7c4@mail.gmail.com> (raw)
In-Reply-To: <007e01c9334e$aad56ff0$00804fd0$@com>
I think your not clear my idea.
> I think maybe some instruction can do it.
> Such as add instruction. When it forward execute, it add some number
> to a value of register. When it reverse, it can sub this number from
> the value of register. It can reverse without record.
Maybe you can read this part again.
And what is the status of program? Most of time, it's just the values
of registers and memory. Do not think anything that complex.
On Tue, Oct 21, 2008 at 15:28, Jakob Engblom <jakob@virtutech.com> wrote:
>
>> > One could have reverse without record/replay if,
>> > for instance, one had a machine architecture where
>> > all instructions were reversable, ie. the machine
>> > itself could reverse-execute an instruction.
>>
>> I think maybe some instruction can do it.
>> Such as add instruction. When it forward execute, it add some number
>> to a value of register. When it reverse, it can sub this number from
>> the value of register. It can reverse without record.
>>
>> In P record, I make a interface to use it in record_t need_dasm. But I
>> still not use it. Maybe I can use it in the future.
>
> When thinking about overflow semantics, etc., it is clear that this can never
> work in general.
>
> The easiest way to create a reversible system is to
>
> 1. Impose determinisim
>
> 2. Make sure you can get back to a previous state
>
> And then you simply jump back and reexecute until some chosen point in time.
> Works like a charm, and is very general.
>
> /jakob
>
>
next prev parent reply other threads:[~2008-10-22 3:26 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 [this message]
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
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=daef60380810212025w3a49208am47d0b851830fd7c4@mail.gmail.com \
--to=teawater@gmail.com \
--cc=gdb@sourceware.org \
--cc=jakob@virtutech.com \
--cc=msnyder@vmware.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