This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: reverse trace [was: vmware's replay framework and gdb]
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: ebo at sandien dot com
- Cc: Edward Peschko <horos11 at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 06 Nov 2008 02:43:54 -0200
- Subject: Re: reverse trace [was: vmware's replay framework and gdb]
- References: <twig.1225933292.67320@swcp.com>
El miÃ, 05-11-2008 a las 18:01 -0700, EBo escribiÃ:
> 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.
<snip>
> 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.
Since we're just brainstorming:
Have you seen Chronicle and Chronomancer? I didn't try them, but from
what I read they seem to go in the direction that you suggest here:
http://code.google.com/p/chronicle-recorder/
http://code.google.com/p/chronomancer/
http://weblogs.mozillazine.org/roc/archives/2007/08/announcing_chro.html
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center