[discuss] going back: reverse-execution vs. checkpoint/restart

[Michael Snyder <msnyder at redhat dot com>]

Last week I was beginning to lean in the direction of
Paul's and Frank's viewpoint.  On reflection, I think
I can argue that the two are not mutually exclusive.

As Frank points out, the "rs/bs" and "rc/bc" primatives
are useful only for a really clever target -- one that
not only has a means of backing up to a previous state,
but can do it at single-instruction granularity, fast
and efficiently, and has worked out a lot of the 'kinks'
that a lot of us haven't even thought about yet.  And
as Paul points out, there is currently only one such
target that we know of.

The bookmark (or checkpoint/restart) model is a considerably
smaller and less daunting "chunk" for the target-side
implementer to take on at one go -- and is not necessarily
limited to simulators.  If gdb implemented an interface for
checkpoint/restart, there's a good chance that a number of
targets would soon take advantage of it.

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.

How much of that evolution needs to take place on the
gdb side, and how much on the target side, is a great
field for discussion -- I would only note that we do
not have to answer that question now.  If we convince
ourselves that both sets of primatives are useful for
some targets, and that one may evolve into the other,
then there is no reason not to implement them both.
Being able to do either one but not the other would
be better than not being able to do either.

Certainly users have been asking for checkpoint/restart
for years, if not decades.  It would be very cool if
we could give it to them, with an interface that lends
itself to porting to various target environments.

And certainly the idea of reverse execution has been
around for years too, and it would be cool to be able
to support that.

So why settle for one or the other?  The beauty of
gdb is that it doesn't need to know HOW the target
accomplishes a thing.  Details such as whether the
cached states are kept in a circular buffer are
for the target implementers to worry about.  We just
define our interface specification to be as general
as possible.  The less we assume about the target-side
implementation, the better.

That said -- it's still useful and fun to discuss how
these things may be accomplished, and should help us
to design a generally useful interface.