From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6761 invoked by alias); 23 May 2008 03:05:15 -0000 Received: (qmail 6753 invoked by uid 22791); 23 May 2008 03:05:14 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 May 2008 03:04:56 +0000 Received: by ti-out-0910.google.com with SMTP id d10so397646tib.12 for ; Thu, 22 May 2008 20:04:53 -0700 (PDT) Received: by 10.110.40.8 with SMTP id n8mr99067tin.7.1211511893634; Thu, 22 May 2008 20:04:53 -0700 (PDT) Received: by 10.110.109.4 with HTTP; Thu, 22 May 2008 20:04:53 -0700 (PDT) Message-ID: Date: Fri, 23 May 2008 14:33:00 -0000 From: Tea To: "Michael Snyder" Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release Cc: gdb-patches@sourceware.org In-Reply-To: <1211480158.3601.88.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1211231955.32587.23.camel@localhost.localdomain> <1211393440.3601.80.camel@localhost.localdomain> <1211394916.7957.47.camel@localhost.localdomain> <20080521184542.GA31895@caradoc.them.org> <1211402304.7957.76.camel@localhost.localdomain> <1211480158.3601.88.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00674.txt.bz2 Hi Michael, How do you think about "query". I always forget the name of variable that can set by user. So I more like query than it. :) Thanks, teawater On Fri, May 23, 2008 at 2:15 AM, Michael Snyder wrote: > On Fri, 2008-05-23 at 00:17 +0800, Tea wrote: >> I think the good way is let user choice. When the user goes back a few >> insns and he want to change the values of memory or register. The GDB >> willtalk clear what will happen such as the future record will >> destory, and ask user if he want to continue or not. >> Then user can choice with himself. >> >> How do you think? > > I tend to agree about the user choice. > Perhaps we could have it as a user-settable mode. > > Default might be "the past is read-only", ie. you > can't change the state. But you could set a mode > in which you can change the past (at the cost of > destroying the future) -- and if you try to do it > when the past is read-only, gdb could ask you if > you want to change the mode. > > Is that clear? Or am I being too metaphorical? > > Michael > > >