Re: Simics & reverse execution

[Hui Zhu <teawater@gmail.com>]

This is really a big mail.  And looks like a AD.  :)

I think you mean is simics can support reverse with remote like vmware, right?

Hui

On Wed, Aug 19, 2009 at 15:33, Jakob Engblom <jakob@virtutech.com> wrote:
>
> 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
>