This is the mail archive of the
mailing list for the GDB project.
reverse trace [was: vmware's replay framework and gdb]
- From: "EBo" <ebo at sandien dot com>
- To: "Edward Peschko" <horos11 at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 5 Nov 2008 18:01:32 MST
- Subject: reverse trace [was: vmware's replay framework and gdb]
- Reply-to: 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.
Edward Peschko <firstname.lastname@example.org> said:
> 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,