From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11216 invoked by alias); 4 Dec 2007 18:05:40 -0000 Received: (qmail 11170 invoked by uid 22791); 4 Dec 2007 18:05:40 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 18:05:29 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id lB4I5LS7024654; Tue, 4 Dec 2007 19:05:21 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id lB4I5KsC028209; Tue, 4 Dec 2007 19:05:20 +0100 (CET) Date: Tue, 04 Dec 2007 18:05:00 -0000 Message-Id: <200712041805.lB4I5KsC028209@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@specifix.com CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <1196473044.2501.189.camel@localhost.localdomain> (message from Michael Snyder on Fri, 30 Nov 2007 17:37:24 -0800) Subject: Re: RFA: Fix check for no-saved-pc References: <1196462431.2501.164.camel@localhost.localdomain> <20071130230045.GA24809@caradoc.them.org> <1196473044.2501.189.camel@localhost.localdomain> 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/msg00056.txt.bz2 > From: Michael Snyder > Date: Fri, 30 Nov 2007 17:37:24 -0800 > > 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. It's not meaningless; it's a very valuabl hint that the stack has been corrupted. You'll get very similar output if youd chosen some random value instead of zero when you corrupted the stack. Why is zero special? If your answer to that question is something like: "because on arm the outermost frame gets marked by a zero pc", then please implement proper backtrace termination for that case in the arm unwinder. Mark