This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] going back: reverse-execution vs. checkpoint/restart
- From: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 23 May 2005 12:15:34 -0700
- Subject: Re: [discuss] going back: reverse-execution vs. checkpoint/restart
- References: <42922617.3050805@redhat.com> <20050523190111.GA9003@nevyn.them.org>
Daniel Jacobowitz wrote:
On Mon, May 23, 2005 at 11:51:03AM -0700, Michael Snyder wrote:
And it's quite reasonable to suppose that there is an
evolutionary path from checkpoint/restart to reverse
execution. We've already discussed some of the ways
in which it could go, so I think it's virtually a given
that it is possible to get from A to B. For that matter,
it should be also possible to get from B to A: a target
that only supports the rs/bs primatives should be able
to implement checkpoint/restart in terms of them.
Not necessarily. Once you back up and manually make a state change it
may not be possible to get back to some other state previously reached.
OK -- but that just means that for any of these requests,
we must take into account the possibility that the request
may fail. EG. a target may support checkpoints, but a
request for a specific checkpoint may fail for reasons
that only the target may know (eg. you went back in time
and "killed your grandfather", so the future you remember
doesn't exist any more).
So, we export the simplest, most general and least
restrictive interface we can think of, make no assumptions
about the implementation details, and always check for
failure messages.