From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32627 invoked by alias); 4 Jan 2006 05:55:31 -0000 Received: (qmail 32619 invoked by uid 22791); 4 Jan 2006 05:55:30 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 05:55:28 +0000 Received: by zproxy.gmail.com with SMTP id l1so2886244nzf for ; Tue, 03 Jan 2006 21:55:26 -0800 (PST) Received: by 10.36.227.48 with SMTP id z48mr4851760nzg; Tue, 03 Jan 2006 21:55:26 -0800 (PST) Received: by 10.37.2.42 with HTTP; Tue, 3 Jan 2006 21:55:26 -0800 (PST) Message-ID: <8f2776cb0601032155q10fa5597naf26a180c753e2a3@mail.gmail.com> Date: Wed, 04 Jan 2006 05:55: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: <1136350956.8215.14.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> 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/msg00029.txt.bz2 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 complet= es + 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.