This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <> said:

> hey..
> I watched the following Google tech talk with much interest:
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]