From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8688 invoked by alias); 21 May 2005 00:58:50 -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 8629 invoked from network); 21 May 2005 00:58:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 May 2005 00:58:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DZIKD-0004AN-85; Fri, 20 May 2005 20:58:45 -0400 Date: Sat, 21 May 2005 00:58:00 -0000 From: Daniel Jacobowitz To: Paul Schlie Cc: Dan Shearer , gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050521005845.GA15974@nevyn.them.org> Mail-Followup-To: Paul Schlie , Dan Shearer , gdb@sources.redhat.com References: <20050520220807.GA11445@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/msg00253.txt.bz2 On Fri, May 20, 2005 at 06:42:45PM -0400, Paul Schlie wrote: > - Which is fully your right to claim/believe; however noting the absence > of non-proprietary simulators with these capabilities (it's a little > unclear how one can presume that interfaces are likely most ideally > necessary or appropriate; and simply note that register and memory state > by definition is program state, which GDB already has direct access to). That is incorrect. There can be considerably more state. For instance, I understand from Dan's explanation that Simics will reply external interrupt sources - at the same clock cycles where they would otherwise have occurred. > As an aside and personal opinion, I happen believe it's not likely good > form to define "opaque" interfaces to non-FSF tools without at least > simultaneously implementing a non-opaque/proprietary solution (which is > I guess the same philosophical problem that I have with the sourcing of > any information, including potentially proprietary extended register/ISA > definitions through an "opaque" interface/wall). It's no more opaque than the continue command is opaque. -- Daniel Jacobowitz CodeSourcery, LLC