From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22351 invoked by alias); 8 Oct 2008 00:31:46 -0000 Received: (qmail 22327 invoked by uid 22791); 8 Oct 2008 00:31:37 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Oct 2008 00:31:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 25AF22A95F3; Tue, 7 Oct 2008 20:31:00 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KwYzXoCkYZ66; Tue, 7 Oct 2008 20:31:00 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 747D32A9627; Tue, 7 Oct 2008 20:30:59 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D2F11E7ACD; Tue, 7 Oct 2008 20:30:58 -0400 (EDT) Date: Wed, 08 Oct 2008 00:31:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: "gdb-patches@sourceware.org" , Daniel Jacobowitz , Pedro Alves , teawater Subject: Re: [RFA] Reverse Debugging, 3/5 Message-ID: <20081008003058.GB3810@adacore.com> References: <48E3CD0B.8020003@vmware.com> <20081006212132.GB21853@adacore.com> <48EA83AD.9040004@vmware.com> <20081006214317.GD21853@adacore.com> <48EAA2C6.2020502@vmware.com> <20081007040703.GF28138@adacore.com> <48EBADE0.4010405@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EBADE0.4010405@vmware.com> User-Agent: Mutt/1.4.2.2i 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-10/txt/msg00230.txt.bz2 HaaaAAAAA, thank you so much for the example, it makes complete sense now. If you don't mind, and that's only a suggestion, perhaps I would suggest handle_stepped_backward_into_function for the function name. > Hmmm. Well, the question is, do we need to update stop_func_start. > We don't use it locally, so perhaps we don't need to do it. But > I don't really know if we're doing it because someone else will > maybe need it later. > > It might be an artifact. But it's not "incorrect", in that > skipping the prologue is the right thing to do IF you want > the function start location. Hmm, you might be right. I'm young and foolish, so I tend to delete code I'm not sure I need, and only put it back when things do actually break. I looked at the "handle_inferior_event" code, and it looks like this field is not used before being recomputed, but it's hard to say for sure, as you have to also visit the functions being called from there... Anyway, I was just wondering... -- Joel