From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17341 invoked by alias); 6 Nov 2008 17:01:46 -0000 Received: (qmail 17244 invoked by uid 22791); 6 Nov 2008 17:01:45 -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 17:01:00 +0000 Received: from ame8.swcp.com (ame8.swcp.com [216.184.2.163]) by mx1a.swcp.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id mA6H0suk003397; Thu, 6 Nov 2008 10:00:54 -0700 Received: from swcp.com (nousagi.swcp.com [216.184.2.107] (may be forged)) by ame8.swcp.com (8.14.2/8.13.6) with SMTP id mA6H0nJS089977; Thu, 6 Nov 2008 10:00:52 -0700 (MST) (envelope-from ebo@sandien.com) Date: Thu, 06 Nov 2008 17:01:00 -0000 To: "Jakob Engblom" , , "'Edward Peschko'" , Subject: RE: reverse trace [was: vmware's replay framework and gdb] From: "EBo" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: <005f01c93ff9$83b31cd0$8b195670$@com> References: <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 (ame8.swcp.com [216.184.2.128]); Thu, 06 Nov 2008 10:00:53 -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/msg00056.txt.bz2 One of the reasons I was thinking of relational databases was that they can deal with the volume and put whatever the decide to cache into dis instead of memory (but maybe you were thinking disk space when you said memory anyway). Besides compression of data stream there is also the possibility of only caching at certain sync points and tracing between sync points you have to regenerate the temp variables, etc. Like I said, I was just brain storming here. I had no idea how far things had gotten along the lines of Chronomancer/Chronicle. Regardless of how it eventually ends up working, it is going to either use a LOT of space, or a lot of CPU power to recreate. Cheers, EBo -- Jakob Engblom said: > Well, the amonut of data we are talking about is very very large. Recording a > complete execution trace very quickly eats up memory. > > If you look at what Lauterbach and GreenHills have in their hardware-based > reverse debuggers, it is essentialy that: a recording of execution step by step. > Using some very clever compression techniques, they can put a few hundred > million clock cycles of instructions into a gigabyte-level memory in their trace > boxes. You need to consider a data need for well over 32 bits per instruction. > > Even quite trivial workloads quickly build up tens of gigabytes of data if you > trace all, and that means that you are basically doing something that is more > expensive than high-def video in terms of data rates. > > Pushing that into a database is not really feasible for any real world scenario > involving multiple gigahertz-level processors crunching real code and not > idling. > > That's why the solutions to reversing from VmWare and Virtutech both hinge on > deterministic replay rather than complete recording -- it is far cheaper to go > back and reconstruct the state at some point in time than trying to store it. > > If you also include fnu things like memory state, I/O system state changes, > graphics memory, etc. it is clear why this is the only sensible thing to do. > > > 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. > > Have been thinking along he same lines, but the volume really is a killer here. > > > /jakob > > > > --