From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25513 invoked by alias); 21 May 2008 20:38:51 -0000 Received: (qmail 25502 invoked by uid 22791); 21 May 2008 20:38:49 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 May 2008 20:38:27 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 3011117F5BC for ; Wed, 21 May 2008 17:27:34 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4LKcQWK614652 for ; Wed, 21 May 2008 17:38:26 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4LKcMcA013701 for ; Wed, 21 May 2008 17:38:23 -0300 Received: from [9.18.202.120] ([9.18.202.120]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4LKcMtQ013695; Wed, 21 May 2008 17:38:22 -0300 Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: Michael Snyder , Tea , gdb-patches@sourceware.org In-Reply-To: <20080521184542.GA31895@caradoc.them.org> References: <1211231955.32587.23.camel@localhost.localdomain> <1211393440.3601.80.camel@localhost.localdomain> <1211394916.7957.47.camel@localhost.localdomain> <20080521184542.GA31895@caradoc.them.org> Content-Type: text/plain; charset=utf-8 Date: Thu, 22 May 2008 15:08:00 -0000 Message-Id: <1211402304.7957.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 8bit 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/msg00651.txt.bz2 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ïve? > > 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