From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27861 invoked by alias); 6 Nov 2008 05:10:48 -0000 Received: (qmail 27749 invoked by uid 22791); 6 Nov 2008 05:10:46 -0000 X-Spam-Check-By: sourceware.org Received: from mx1a.swcp.com (HELO mx1a.swcp.com) (216.184.2.64) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 05:09:42 +0000 Received: from ame7.swcp.com (ame7.swcp.com [216.184.2.70]) by mx1a.swcp.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id mA659ZDW031189; Wed, 5 Nov 2008 22:09:35 -0700 Received: from swcp.com (nousagi.swcp.com [216.184.2.107] (may be forged)) by ame7.swcp.com (8.14.2/8.13.6) with SMTP id mA659VBq069686; Wed, 5 Nov 2008 22:09:32 -0700 (MST) (envelope-from ebo@sandien.com) Date: Thu, 06 Nov 2008 05:10:00 -0000 To: "Thiago Jung Bauermann" , Subject: Re: reverse trace [was: vmware's replay framework and gdb] From: "EBo" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: <1225946634.20764.74.camel@localhost.localdomain> References: , X-Client-IP: 216.184.15.167 Cc: "Edward Peschko" , "gdb@sourceware.org" Reply-To: ebo@sandien.com X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (ame7.swcp.com [216.184.2.128]); Wed, 05 Nov 2008 22:09:33 -0700 (MST) X-Virus-Status: Clean Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00044.txt.bz2 Thanks Thiago, That is so wicked cool! If this project was really ongoing I would be interested, but as it is it looks orphaned... Who's to know though. Basically what I was thinking would be behind the scenes with gdb: * turn reversable tracing on * step forward * step back .. EBo -- Thiago Jung Bauermann said: > 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. > > > 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 > > --