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

["EBo" <ebo at sandien dot com>]

I Cannot comment on VMWares effort, but reading this I had an idea and thought
I would share...

The overall problem with reverse tracing as I see it is one of caching the old
values basically as they change.  One way to get at this is to integrate a SQL
database with transaction support into the trace subsystem.  The you can view
the entire history back and forth.  

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.

  EBo --

Edward Peschko <horos11@gmail.com> said:

> hey..
> 
> I watched the following Google tech talk with much interest:
> 
> http://www.youtube.com/watch?v=RvMlihjqlhY
> 
> It describes a very generic, scalable, environment-agnostic way of
> recording programs' execution via vmware's virtualization, and doing
> reverse tracing (which is one of the reasons I'd like to record
> programs in the first place). I heard gdb mentioned in the video in
> passing, so I'm assuming someone in the list is familiar with vmware's
> effort, but how far along is gdb in supporting this framework?
> 
> Thanks much,
> 
> Ed
> 



--