From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21273 invoked by alias); 21 May 2005 01:53:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21180 invoked from network); 21 May 2005 01:52:59 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 May 2005 01:52:59 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DZJAT-0004am-6T; Fri, 20 May 2005 21:52:45 -0400 Date: Sat, 21 May 2005 01:53:00 -0000 From: Daniel Jacobowitz To: Paul Schlie Cc: Dan Shearer , gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050521015245.GA17463@nevyn.them.org> Mail-Followup-To: Paul Schlie , Dan Shearer , gdb@sources.redhat.com References: <20050521005845.GA15974@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00255.txt.bz2 On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote: > - Supporting HW co-simulation is certainly interesting, but fundamentally > no different; it only extends the definition of "state" typically by > literally exposing some of the logical CPU/I/O/Peripheral/outside-world > state in various levels of details depending on the goals of the model, > and/or simulation itself. (but would guess likely beyond the near term > goals of attempting to enable GDB support for basic reversible execution?) Why should it be? This is another reason that I consider the simulator a perfectly reasonable place to have the logic. Frank has contributed that sid would more readily support the sort of snapshot-based reconstruction that you're talking about (thanks Frank). I think that allowing the target to provide infrun with a view in which "single step backwards" is possible and then implementing that under the covers in the target stack would still be the way to go - but I don't think that's a legitimate objection to supporting a smart simulator which does it internally. When someone implements reversible debugging in a free simulator and wants to integrate that with GDB, they'll have the choice of doing the remaining steps in their simulator or in GDB. > [And suspect you'll find that most HW savvy simulation environments have > very limited if any support for "reversible" simulation, beyond > checkpoint-restart. As on a cycle by cycle basis, tracking and recording > incremental state changes would typically cripple the simulation, and > potentially even exhaust disk storage for complex models, but limited > forms do exist, and are useful.] You might want to read the papers on the specific simulator we're discussing using as a starting point; you can find the white paper on Virtutech's web site. Under the covers, of course, it's probably checkpoint based. But it's efficient, automatic checkpointing such that it can provide a reversible view over useful periods of time. Complete with "HW savvy" details. -- Daniel Jacobowitz CodeSourcery, LLC