Click above to get retro games delivered to your door ever month!

The debugger keeps an execution history as you debug your program.  This
history is accessible using the Undo menu.  The effect of program statements
as you single step through your program are recorded.  All interactions that
allow you to modify the state of your program including modifying variable
values, changing memory and registers are also recorded.  Undo and Redo let
you browse backward and forward through this execution history.  As you use
these menu items, all recorded effects are undone or redone, and each of the
debugger's windows are updated accordingly.

You can resume program execution at any previous point in the history.  The
program history has no size restrictions aside from the amount of memory
available to the debugger, so theoretically you could single step through
your entire program and then execute it in reverse.  There are several
practical problems that get in the way of this.  When you single step over a
call or interrupt instruction, or let the program run normally, the debugger
has no way of knowing what kind of side effects occurred.  No attempt is
made to discover and record these side effects, but the fact that you did
step over a call is recorded.  If you try to resume program execution from a
point prior to a side effect, the debugger will give you a the option to
continue or back out of the operation.  Use caution if you choose to
continue.  If an important side effect is duplicated, you program could
crash.  Of course reversing execution over functions with no side effects is
harmless, and can be a useful debugging technique.  If you have accidentally
stepped over a call that does have a side effect, you can use Replay to
restore your program state.

Unwind and Rewind move the debugger's state up and down the call stack.
 Like Undo, all windows are updated as you browse up and down the stack, and
you can resume execution from a point up the call stack.  A warning will be
issued if you try resuming from a point up the call stack since the debugger
cannot completely undo the effects of the call.

Unwind is particularly useful when your program crashes in a routine that
does not contain debugging information.  strcpy() is a good example of this.
 You can use Unwind to find the call site and inspect the parameters that
caused the problem.

The runtime library detects certain classes of errors and diagnoses them as
fatal runtime errors.  If this occurs when you are debugging, the debugger
will be activated and the error message will be displayed.  For example,
throwing an exception in C++ without having a catch in place is a fatal
runtime error.  In C, the abort() and assert() functions are fatal errors.
 When this happens, you will be positioned in an internal C library call.
 You can use Unwind to find the point in your source code that initiated the
error condition.

When Unwind and Undo are used in conjunction, Undo is the primary operation
and Unwind is secondary.  You can Undo to a previous point in the history
and then Unwind the stack.  If you Unwind the stack first and then use Undo,
the Unwind has no effect.

If you modify the machine state in any way when you are browsing backward
through the execution history, all forward information from that point is
discarded.  If you have browsed backward over a side effect the debugger
will give you the option of canceling any such operation.

The Undo menu contains the following items.


Undo
    Browse backwards through the program execution history.

Redo
    Browse forward through the program execution history.

Unwind Stack
    Move up the call stack one level.

Rewind Stack
    Move down the call stack one level.

Home
    Return to the currently executing location, reversing the effects of all
    Undo and Unwind operations.