From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29152 invoked by alias); 6 Nov 2008 01:02:42 -0000 Received: (qmail 29050 invoked by uid 22791); 6 Nov 2008 01:02:41 -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 01:01:39 +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 mA611Zch001631; Wed, 5 Nov 2008 18:01: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 mA611WcZ017892; Wed, 5 Nov 2008 18:01:33 -0700 (MST) (envelope-from ebo@sandien.com) Date: Thu, 06 Nov 2008 01:02:00 -0000 To: "Edward Peschko" , "gdb@sourceware.org" Subject: reverse trace [was: vmware's replay framework and gdb] From: "EBo" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: <5cfa99000811051104v3e6ab5e6m50faddb64de050fe@mail.gmail.com> X-Client-IP: 216.184.15.167 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 18:01: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/msg00040.txt.bz2 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: > > http://www.youtube.com/watch?v=RvMlihjqlhY > > 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 > --