From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26280 invoked by alias); 4 Jan 2006 06:52:26 -0000 Received: (qmail 26273 invoked by uid 22791); 4 Jan 2006 06:52:25 -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 06:52:24 +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 k046T4kg012805; Wed, 4 Jan 2006 11:59:06 +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: <8f2776cb0601032155q10fa5597naf26a180c753e2a3@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> Content-Type: text/plain Date: Wed, 04 Jan 2006 06:52:00 -0000 Message-Id: <1136356104.17597.47.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/msg00031.txt.bz2 Hi Jim 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. Changing over breaks the behaviour of the backtrace over a recursive call. Gives me extra failures inside break.exp . cheers Ramana On Tue, 2006-01-03 at 21:55 -0800, Jim Blandy wrote: > Hi --- thanks for revising the patch. > > +/* Insert a step resume breakpoint at the return address of the > + caller. This is to ensure that on doing a next from before main completes > + execution of the program without GDB dumping core. Look at PR 1971 > + for more details. */ > > I don't think this is quite what you mean to say. The comment for a > function should describe its behavior in terms of its arguments; > "caller" is vague. Second, this isn't always used for "next"; it can > get used when you "step" into a function with no debug info (if I'm > reading right). Third, a more self-contained explanation of why the > get_prev_frame-based approach isn't sufficient would be better. > > How about: > > /* Insert a step-resume breakpoint at the address to which > RETURN_FRAME will return. > > Unlike insert_step_resume_breakpoint_at_frame (get_prev_frame (F)), > this works even when F is the oldest frame. (Consider next-ing out > of main when 'show backtrace past-main' is off.) */ > > Finally --- could insert_step_resume_breakpoint_at_caller simply > *always* use the frame_pc_unwind approach, and drop the check for > get_prev_frame altogether? I understand that trying get_prev_frame > first is guaranteed to give the least disturbance to the existing > behavior, but I don't like leaving stuff like that in there unless we > can explain why it's actually needed. -- Ramana Radhakrishnan GNU Tools codito ergo sum (www.codito.com) Ph: +91-20-26051367 (office) +91-9890040009 (mobile)