Back to Reverse Execution

Simics reverse execution and reverse debugging is a very
powerful feature of the simulator. In this blog post and accompanying video, we
will look at what exactly it is you can do with reverse execution in Simics. It
is not just a matter of running backwards to a breakpoint or stepping
instructions (pick up my 2012 S4D article for more on reverse debugging). Reverse execution fundamentally is about undoing
arbitrary operations on the target and going back to a prior state from a previous point in time. Furthermore, with
Simics, you can go back in time and choose to do something different than
you did in the original execution. In this blog post, we will take a look at just what you can do with reverse.

The basic operation of reverse execution is to stop at some
point in a system execution, go backwards to visit the past and see what
happens, and then go forward again. Reverse execution lets you go back and
forth over the execution to investigate a particular execution path in detail.


It is worth noting that with Simics, the entire system is
being reversed. Hardware device state, operating system, disk contents,
hypervisors, user applications, all user threads and kernel threads, network
traffic within the simulated network, and all the boards that form part of the
system. It is not a solution limited to a particular user-space process like
gdb reverse debugging, or a particular language virtual machine like the Microsoft
.net solutions. It is the entire system, as always with Simics.

In addition to just reversing back sequentially, you can
jump to a particular point in time. This integrates nicely with the new session
comments found in Simics 4.8
, since you can jump to a comment to see what the state was at the
point in time that someone made a comment on the system execution. The reverse execution bookmarks that we have always had are still around, obviously,  but they are intended for a different use case. They do not follow the system setup
around as it is checkpointed and communicated, but are rather supposed to be used within a debug session as quick throw-away notes.


Simics also lets you go back in time and change the path of
the system, thanks to the lightweight implementation of saving the reverse
execution history. Essentially, only the outside interaction with the simulator
is saved. The simulator’s internal behavior is deterministic,
and can thus be left out. This makes the path of the execution easy to save and
easy to modify. If we just remove the recorded input history, the path of the
system opens up to infinite possibilities.

With Simics, we can reverse the system state to the state at
some past point in time, discard the recorded input history, and choose a new
path for our system.


All those ways of using reverse execution are demonstrated in the video about reverse
, that is found on the Wind River Youtube channel.

For more examples of reverse debugging and reverse
execution, please read some of my old blog posts and visit their associated