From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26104 invoked by alias); 6 Nov 2008 10:22:52 -0000 Received: (qmail 26059 invoked by uid 22791); 6 Nov 2008 10:22:51 -0000 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 10:22:08 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id D7C2726EF6C; Thu, 6 Nov 2008 11:22:04 +0100 (CET) Received: from polhem (c83-253-20-211.bredband.comhem.se [83.253.20.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 9830F26EF64; Thu, 6 Nov 2008 11:22:04 +0100 (CET) From: "Jakob Engblom" To: , "'Edward Peschko'" , References: <5cfa99000811051104v3e6ab5e6m50faddb64de050fe@mail.gmail.com> In-Reply-To: Subject: RE: reverse trace [was: vmware's replay framework and gdb] Date: Thu, 06 Nov 2008 10:22:00 -0000 Message-ID: <005f01c93ff9$83b31cd0$8b195670$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: sv 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/msg00049.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. 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