Back to Reverse Execution

By Jakob Engblom 

Engblom_lgSimics reverse execution and reverse debugging is a unique and 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 execution, 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 videos.


For additional information from Wind River, visit us on Facebook