From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20979 invoked by alias); 4 Jan 2006 07:57:35 -0000 Received: (qmail 20968 invoked by uid 22791); 4 Jan 2006 07:57:34 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.196) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 07:57:32 +0000 Received: by zproxy.gmail.com with SMTP id l1so2908673nzf for ; Tue, 03 Jan 2006 23:57:30 -0800 (PST) Received: by 10.36.227.5 with SMTP id z5mr4997506nzg; Tue, 03 Jan 2006 23:57:30 -0800 (PST) Received: by 10.37.2.42 with HTTP; Tue, 3 Jan 2006 23:57:30 -0800 (PST) Message-ID: <8f2776cb0601032357q32754aaxef1ac495584c9ca4@mail.gmail.com> Date: Wed, 04 Jan 2006 07:57:00 -0000 From: Jim Blandy To: ramana.radhakrishnan@codito.com Subject: Re: Fix for PR 1971 . Cc: gdb-patches@sources.redhat.com In-Reply-To: <1136356104.17597.47.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1136312069.8808.24.camel@localhost.localdomain> <8f2776cb0601031534p23c54aadkdccb840296911560@mail.gmail.com> <8f2776cb0601031543g4fc5a45bj9cf367c82d6793b0@mail.gmail.com> <1136350956.8215.14.camel@localhost.localdomain> <8f2776cb0601032155q10fa5597naf26a180c753e2a3@mail.gmail.com> <1136356104.17597.47.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00033.txt.bz2 On 1/3/06, Ramana Radhakrishnan wrote: > I am not sure about removing the get_prev_frame. We need it for the > correct frame id . In case you were stepping over a recursive call and > deep inside after main had executed you would need the correct frame id > of the return frame and in the other case a null_frame_id. Okay, I see. Hmm. If I'm reading breakpoint.c right, null_frame_id acts as a wildcard, saying, treat the breakpoint as applying to any frame. So we're assuming that, whoever the caller of the "oldest" frame is, it's not going to be called recursively (or else the step-resume breakpoint would trigger in one of the inner frames). I don't know if that case is worth worrying about. It looks okay to me, then. Let's let it sit for a few days; if nobody has futher comments, go ahead and commit.