From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20771 invoked by alias); 4 Dec 2007 02:06:40 -0000 Received: (qmail 20690 invoked by uid 22791); 4 Dec 2007 02:06:39 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 02:06:33 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 4462A3BF96; Mon, 3 Dec 2007 18:06:31 -0800 (PST) Subject: Re: RFA: Fix check for no-saved-pc From: Michael Snyder To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org, Mark Kettenis In-Reply-To: <1196473044.2501.189.camel@localhost.localdomain> References: <1196462431.2501.164.camel@localhost.localdomain> <20071130230045.GA24809@caradoc.them.org> <1196473044.2501.189.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 04 Dec 2007 02:06:00 -0000 Message-Id: <1196733157.2501.202.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00050.txt.bz2 Mark, is the 2nd form of the patch acceptable to you? On Fri, 2007-11-30 at 17:37 -0800, Michael Snyder wrote: > On Fri, 2007-11-30 at 18:00 -0500, Daniel Jacobowitz wrote: > > On Fri, Nov 30, 2007 at 02:40:31PM -0800, Michael Snyder wrote: > > > There's a check in get_prev_frame to see if the next saved pc > > > is zero. I think it has an off-by-one error, and is checking > > > for the pc of the wrong frame. > > > > Mark K. and I have had roughly a month's worth of discussion on this > > check over the last two years; it's where it is on purpose. Here's > > the last conversation: > > > > http://sourceware.org/ml/gdb-patches/2006-05/msg00196.html > > http://sourceware.org/ml/gdb-patches/2006-07/msg00296.html > > All right. Then let's leave that test alone, and add another > test, much later on, to detect and report this situation. > > Here's my revised patch. Testsuites un-affected. > > As before, the effect of this change is to have gdb print > a more informative message instead of a meaningless zero-frame. > > 2007-11-30 Michael Snyder > > * frame.c (get_prev_frame): Remove unused local variable. > (get_prev_frame_1): Check for null saved pc in the calling > frame. Set up stop_reason conditions for printing stop reason. > > Index: frame.c > =================================================================== > RCS file: /cvs/src/src/gdb/frame.c,v > retrieving revision 1.235 > diff -u -p -r1.235 frame.c > --- frame.c 2 Nov 2007 14:47:27 -0000 1.235 > +++ frame.c 1 Dec 2007 01:30:01 -0000 > @@ -1248,6 +1248,16 @@ get_prev_frame_1 (struct frame_info *thi > this_frame->prev = NULL; > return NULL; > } > + /* Also check for a null saved_pc. At this point it can > + only be a bad thing. */ > + if (frame_pc_unwind (this_frame) == 0) > + { > + frame_debug_got_null_frame (gdb_stdlog, this_frame, > + "zero PC"); > + this_frame->stop_reason = UNWIND_NO_SAVED_PC; > + this_frame->prev = NULL; > + return NULL; > + } > } > > /* Allocate the new frame but do not wire it in to the frame chain. > @@ -1355,8 +1365,6 @@ inside_entry_func (struct frame_info *th > struct frame_info * > get_prev_frame (struct frame_info *this_frame) > { > - struct frame_info *prev_frame; > - > /* Return the inner-most frame, when the caller passes in NULL. */ > /* NOTE: cagney/2002-11-09: Not sure how this would happen. The > caller should have previously obtained a valid frame using > >