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

EBo
2008-11-06T01:02:42Z

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
>

--