From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25596 invoked by alias); 4 Jan 2006 08:27:05 -0000 Received: (qmail 25588 invoked by uid 22791); 4 Jan 2006 08:27:05 -0000 X-Spam-Check-By: sourceware.org Received: from 203.197.88.2.ILL-PUNE.static.vsnl.net.in (HELO marvin.codito.net) (203.197.88.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 08:27:02 +0000 Received: from zirakzigil.codito.co.in ([220.225.32.98]) (authenticated bits=0) by marvin.codito.net (8.13.5/8.13.5/Debian-3) with ESMTP id k048MXvU016942; Wed, 4 Jan 2006 13:52:35 +0530 Subject: Re: Fix for PR 1971 . From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@codito.com To: Jim Blandy Cc: gdb-patches@sources.redhat.com In-Reply-To: <8f2776cb0601032357q32754aaxef1ac495584c9ca4@mail.gmail.com> 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> <8f2776cb0601032357q32754aaxef1ac495584c9ca4@mail.gmail.com> Content-Type: text/plain Date: Wed, 04 Jan 2006 08:27:00 -0000 Message-Id: <1136362913.17597.79.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00036.txt.bz2 On Tue, 2006-01-03 at 23:57 -0800, Jim Blandy wrote: > 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. Thanks for all the review and the comments. Yes, that sounds right, I can't think of a situation where we should worry about this. Will wait a couple of days and if there are no objections I will go ahead and commit it. cheers Ramana > > It looks okay to me, then. Let's let it sit for a few days; if nobody > has futher comments, go ahead and commit. >