RE: reverse trace [was: vmware's replay framework and gdb]

["EBo" <ebo@sandien.com>]

One of the reasons I was thinking of relational databases was that they can
deal with the volume and put whatever the decide to cache into dis instead of
memory (but maybe you were thinking disk space when you said memory anyway).  

Besides compression of data stream there is also the possibility of only
caching at certain sync points and tracing between sync points you have to
regenerate the temp variables, etc.  Like I said, I was just brain storming
here.  I had no idea how far things had gotten along the lines of
Chronomancer/Chronicle.

Regardless of how it eventually ends up working, it is going to either use a
LOT of space, or a lot of CPU power to recreate.  

Cheers,

  EBo --

Jakob Engblom <jakob@virtutech.com> said:

> Well, the amonut of data we are talking about is very very large.  Recording a
> complete execution trace very quickly eats up memory.  
>
> If you look at what Lauterbach and GreenHills have in their hardware-based
> reverse debuggers, it is essentialy that: a recording of execution step by step.
> Using some very clever compression techniques, they can put a few hundred
> million clock cycles of instructions into a gigabyte-level memory in their trace
> boxes.  You need to consider a data need for well over 32 bits per instruction.
> 
> Even quite trivial workloads quickly build up tens of gigabytes of data if you
> trace all, and that means that you are basically doing something that is more
> expensive than high-def video in terms of data rates.
> 
> Pushing that into a database is not really feasible for any real world scenario
> involving multiple gigahertz-level processors crunching real code and not
> idling. 
> 
> That's why the solutions to reversing from VmWare and Virtutech both hinge on
> deterministic replay rather than complete recording -- it is far cheaper to go
> back and reconstruct the state at some point in time than trying to store it. 
> 
> If you also include fnu things like memory state, I/O system state changes,
> graphics memory, etc. it is clear why this is the only sensible thing to do.
>  
> > So, if you are willing to do a little brainstorming along these lines the
> > following questions arise:
> > 
> > *) is there some easy way to get the symbol table and integrate that info back
> > into gdb and associate the variables/memory blocks with each line of code?
> > 
> > *) is there some computationally inexpensive way to trap memory changes and
> > associate the timing with source lines and execution times?
> > 
> > Once all this information is funneled through a relational database, you can
> > then either grab the current state of each variable or reconstruct it on the
> fly.
> > 
> > Just an idea, and I hope this kind of speculative response is considered
> > acceptable to the group.
> 
> Have been thinking along he same lines, but the volume really is a killer here.
> 
> 
> /jakob
>  
> 
> 
> 



--