Simics & reverse execution

["Jakob Engblom" <jakob at virtutech dot com>]

In a thread about testing gdb reverse, Michael Snyder asked this question about
reverse debug and Simics:

> I think with your setup, you can make the recording first,
> before you ever start gdb, am I right?
> 
> I don't know whether you also have an option to start making
> the recording after you start debugging?  If so, you might want
> to test it in the same context?

I think it helps to explain how Simics does reverse execution (and which is
fairly similar if more nimble than the VMWare implementation currently). 

Essentially, reverse execution is implemented on the hardware level. Simics
simulates an entire system: core processors, their surrounding devices on a
typical system-on-chip, memories, disks, networks, PCI, RapidIO, etc.  In
extreme cases, we are talking about entire virtual networks and virtual SMP
servers with 10s, 100s, or 1000s of processors. 

The key level that Simics observes is the software interface to the hardware.
Simics does not need to know anything about the software to run it, it just
simulates the hardware. 

To reverse execution in Simics, you use a combination of record and reexecution
techniques. Simics itself is 100% repeatable in its execution, and it can record
any asynchronous user input to a system like network packets and users typing on
keyboards attached to virtual systems.  To reverse the execution, you jump back
to a checkpoint fo the system state and then you reexecute forward, to a place
before your current position in time.  There is a good illustration of this in
the white paper at
http://www.virtutech.com/whitepapers/simics_checkpointing.html . 

Doing reverse breakpoints basically involves successively jumping back and
executing forward until breakpoints trigger. I think process record does
something very similar, based on the recording, right?  

>From the outside, the semantics are identical to process record -- except that
there is no recording. But you have a limited window in both cases to which you
can go back (you start reverse execution at some point in time, which could be
system boot, or some later point).  

When we mix in gdb reverse with this, it is just an interface to the Simics core
engine.  Gdb reverse can be attached at any point during a run. Often, the way
you do things is to boot a machine to prompt (or open the booted state from a
checkpoint stored on disk), load target software in some way, and turn on
reverse execution when things get interesting: such as setting up the
configuration for the software to run, starting dependent services, connecting
to network servers, etc. 

Once the program you want to debug runs, you open a gdb remote connection and
attach gdb. Note that Simics by default lets gdb remote control one processor at
the hardware level, which is useful for bare-hardware or kernel-level debug.  We
can also use OS awarenesss to have a remote gdb only debug a certain process
when it is running.   Note that the Simics reverse affects the entire software
stack, including any writes to memory, disk, network packets sent, and kernel
process schedulings and interrupts from hardware.  In many ways, this makes
implementing reverse execution easier: there is a single interface level to
attack, no need to udnerstand the operating system on the target. 

As far as gdb remote is concerned, you can conceptually reverse into a time
prior to when gdb remote was attached. The underlying "recording" has no
relation to the actions of gdb remote.  

In simics, there are additional controls than regular debugging, such as turning
off reverse execution during a simulation. And "clearing the recording",
essentially making the current point in time the start of an unknown future
where asynchronous input from the user and environment is allowed, and the
system will take a different path than it took previously.  This does not
necessarily need to be addressed over gdb-remote.  But it might map to some of
the process record commands quite naturally.

What this means for Simics and gdb remote is that it would be nice to be able to
deal with points in time: in Simics, you are moving the target system clock
around in time arbitrarily.  In the Simics reverse interface, you can go to a
certain point in time, and also set execution bookmarks. 

But from a gdb perspective, all of this is hidden in a remote black box that
talks gdb remote. 

/jakob