RE: Simics & reverse execution

["Jakob Engblom" <jakob at virtutech dot 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?

I think the answer is that method used seems mostly the same.  

The key thing for me was to explain that the time scope of the reversible run is
potentially larger than what any particular gdb-remote connection sees: i.e., it
is nice if gdb would accept backing into "before it was attached" logically, and
not assume too much control over the reversing in itself. 

And that a probe for reversibility in gbd-remote would be a worthwhile addition
to the protocol. 

/jakob
 
> 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
> >