From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9427 invoked by alias); 6 Nov 2008 04:45:00 -0000 Received: (qmail 9355 invoked by uid 22791); 6 Nov 2008 04:44:59 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 04:44:04 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 89D85390044 for ; Thu, 6 Nov 2008 02:42:27 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mA64hexj4358352 for ; Thu, 6 Nov 2008 01:43:40 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mA64i1rM013654 for ; Thu, 6 Nov 2008 02:44:01 -0200 Received: from [9.8.11.66] ([9.8.11.66]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mA64hxkQ013642; Thu, 6 Nov 2008 02:44:00 -0200 Subject: Re: reverse trace [was: vmware's replay framework and gdb] From: Thiago Jung Bauermann To: ebo@sandien.com Cc: Edward Peschko , "gdb@sourceware.org" In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Thu, 06 Nov 2008 04:45:00 -0000 Message-Id: <1225946634.20764.74.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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/msg00043.txt.bz2 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