Re: Using reverse execution

[Michael Snyder <michsnyd@cisco.com>]

 > Depending on the answers, the project could be fatally flawed.
 > For instance, if the ability to undo system calls is critical
 > for usability, that pretty much relegates reversal to simulator
 > targets only - not interesting for my user base. That's why I
 > wanted to talk about usage patterns; if users don't need the
 > debugger to do the incredibly hard things, then we can get to
 > something useful sooner.

Here's the thing, though, Stan --

We can separate the debugger implementation questions from
the target-side implementation questions.  Whether I/O can
be "undone", whether system calls can be reversed over, even
whether the target can proceed forward again from a point
that it has reversed back to -- these are all things about
which gdb need not concern itself.  They're target-side
details.

Think about forward execution.  Does gdb know anything
about system calls?  In general, not.  Does it know anything
about I/O?  Definitely not, except in some special cases.
GDB knows about step, continue, and why-did-we-stop?
Those are its primatives.

If we make the CORE PART of gdb do nothing more than use
similar primatives for backward debugging, then it will
"just work".  I know this, 'cause I've done it.  We may
need to build some more intimate details into SOME gdb
back-ends, or implement a separate module that can do
certain things such as checkpoints for a target that
can't do them for itself -- but the core part of gdb
doesn't need to know about that, and those considerations
need not hold up the development of reverse execution
in the core part of gdb.

Separate the debugging of reverse-execution from the
question of how the reverse-execution is to be done.
I know, you need to consider both, and there's definitely
cross-over, but what I am saying is that we CAN
separate them, and that gdb will be better if we do.
The part of gdb that controls execution (infrun and
infcmd, for instance) SHOULD not know how the backend
or the target "works".

The target, on the other hand, may have lots of
capabilities, and it may not.  Maybe it can only
"back up" until the first system call, and then
it gives up.  Well, then gdb just needs to know
how to handle a target that can do some reverse
executing, but then can't do more.  That's general --
because another target may have a "buffer" of saved
state for reverse execution, and it may eventually
reach the beginning of that buffer.  Infrun doesn't
necessarily need to know WHY the target can't go
backward any more, just that it can't.  Although
of course we might encode some common reasons and
give some meaningful failure message, it isn't
essential to the implementation of reverse debugging.