From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21779 invoked by alias); 22 May 2008 16:17:22 -0000 Received: (qmail 21764 invoked by uid 22791); 22 May 2008 16:17:22 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 May 2008 16:17:04 +0000 Received: by ti-out-0910.google.com with SMTP id d10so128986tib.12 for ; Thu, 22 May 2008 09:17:02 -0700 (PDT) Received: by 10.110.68.4 with SMTP id q4mr25061tia.41.1211473020488; Thu, 22 May 2008 09:17:00 -0700 (PDT) Received: by 10.110.109.4 with HTTP; Thu, 22 May 2008 09:17:00 -0700 (PDT) Message-ID: Date: Fri, 23 May 2008 02:54:00 -0000 From: Tea To: "Thiago Jung Bauermann" Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release Cc: "Daniel Jacobowitz" , "Michael Snyder" , gdb-patches@sourceware.org In-Reply-To: <1211402304.7957.76.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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> 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/msg00664.txt.bz2 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? teawatert On Thu, May 22, 2008 at 4:38 AM, Thiago Jung Bauermann wrote: > On Wed, 2008-05-21 at 14:45 -0400, Daniel Jacobowitz wrote: >> On Wed, May 21, 2008 at 03:35:16PM -0300, Thiago Jung Bauermann wrote: >> > Right. And that's very easy to implement right? Just throw away the >> > recorded entries "in the future". Or am I being to na=EFve? >> >> It depends... hey, weren't you at my talk about this last June? :-) > > Ahem. :-) > >> I don't remember if I went into this part but there's a section in the >> proceedings. > > IIRC, you did talk about the printf example and an event log. > >> Continuing forward from a modified point depends on >> being able to synchronize external and recorded state. Just >> destroying the recorded state would work if you could detect >> relevant modifications - it's made slightly tricky by memory >> breakpoints but you're right, it's not too hard. > > Yeah, I was ignoring the external world. Since the record patch also > ignores it, I guess it's okay for now... > > That would probably be the meat of GDB record Mark II or something. > -- > []'s > Thiago Jung Bauermann > Software Engineer > IBM Linux Technology Center > >