From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21376 invoked by alias); 3 Jan 2006 23:43:53 -0000 Received: (qmail 21367 invoked by uid 22791); 3 Jan 2006 23:43:52 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.200) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jan 2006 23:43:50 +0000 Received: by zproxy.gmail.com with SMTP id l1so2818832nzf for ; Tue, 03 Jan 2006 15:43:49 -0800 (PST) Received: by 10.36.2.19 with SMTP id 19mr4508267nzb; Tue, 03 Jan 2006 15:43:49 -0800 (PST) Received: by 10.37.2.42 with HTTP; Tue, 3 Jan 2006 15:43:48 -0800 (PST) Message-ID: <8f2776cb0601031543g4fc5a45bj9cf367c82d6793b0@mail.gmail.com> Date: Tue, 03 Jan 2006 23:43: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: <8f2776cb0601031534p23c54aadkdccb840296911560@mail.gmail.com> 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> 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/msg00019.txt.bz2 On 1/3/06, Jim Blandy wrote: > On 1/3/06, Ramana Radhakrishnan wrote: > > Attached is a fix for PR 1971. This inserts a breakpoint at the return > > address for a function that does not have a previous frame which is what > > you have in the case of main. This would however not stop after the > > return from main because the semantics of the next command would not > > stop the execution in any place where there is no debug information. > > > > Tested on native x86 with today's head as well as 6.4 branch with no > > extra regressions . > > Is this the behavior we actually want? Where the user hasn't "set > backtrace past-main on", isn't it the correct behavior for GDB to > allow the program to exit when doing a 'next' out of main? (I assume > that, if one does a 'set backtrace past-main on', then 'next' works as > you suggest it should.) Oh, wait. I might understand better now. The current behavior is a segfault, as get_prev_frame returns NULL. The code you patched is clearly wrong as it stands, since it doesn't account for that possibility. The behavior with your patch is that 'next' from main causes the program to run to completion when past-main is off, as I suggested it ought. Right? I see three uses of insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ())) in infrun.c; would it be reasonable to add a new function in the insert_step_resume_breakpoint_at_* family, insert_step_resume_breakpoint_at_caller (say), that sets the step-resume breakpoint at a sal built from the given frame's return address? I think you'd want to use frame_pc_unwind in that function, and not gdbarch_unwind_pc.