Using reverse execution

[Stan Shebs]

Michael Snyder wrote:

>
> 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.

I think we know these primitives work for forward execution
because we have 40+ years of experience that says they are
useful. Students learn those in school as part of their formative
experience with debugging, so there is also a bit of tautology -
"these are useful for debugging because these are what we use
for debugging". It's so ingrained that researchers in
algorithmic and specification-based debugging continually
have a hard time getting anybody interested in their approach.

>
> 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. 

This comes back to the "first impression" issue. App writers
on Mac OS X have a huge numbers of libraries (frameworks) that
they're suppposed to use, and at the bottom of those there are lots
and lots of system calls going on. If the reverse step button is
perpetually grayed out for every line more complicated than
"a = b + c", users are going to see reversing as a useless feature
and never get in the habit of using it to solve their problems.

Fortunately I don't think we have to give up that easily; an adroitly
designed mechanism could treat system call behavior as a black box
requiring a bit of footwork to reverse past, just as GDB does some
footwork with breakpoints to cover up how we're scribbling trap
instructions all over supposedly read-only memory. :-)

Stan