From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7345 invoked by alias); 15 Sep 2004 23:10:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7334 invoked from network); 15 Sep 2004 23:10:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 15 Sep 2004 23:10:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1C7iur-0007qg-6n; Wed, 15 Sep 2004 19:10:21 -0400 Date: Wed, 15 Sep 2004 23:10:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Abort backtrace when consecutive zero PCs? Message-ID: <20040915231021.GA30025@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <41487D1D.7040504@gnu.org> <20040915221329.GA28732@nevyn.them.org> <4148C5A4.5000104@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4148C5A4.5000104@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-09/txt/msg00134.txt.bz2 On Wed, Sep 15, 2004 at 06:43:48PM -0400, Andrew Cagney wrote: > >On Wed, Sep 15, 2004 at 01:34:21PM -0400, Andrew Cagney wrote: > > > >>>Hello, > >>> > >>>One backtrace infinite loop case I've noticed (especially on ia64) is > >>>where successive frames all have a zero PC. > >>> > >>>While we definitly need to allow a backtrace through a single zero PC > >>>(for a NULL pointer call - signull.exp) should we make GDB abort when > >>>two or more consecutive frames have a zero PC? > >>> > >>>(mumble something about a runtime option) > >>> > >>>thoughts? > > > > > >I still think that you > > me or we? Do you have a pointer to the thread? I think that I want it; it was a form of speech indicating it would address this problem. I swear it's in the archives but I can't find the right thing to search for. > > want to reject zero PC followed by a normal > >(non-signal/dummy) frame, for exactly this reason... > > That sounds like a NULL pointer function call, which is what signull.exp > is all about. "followed" in the other direction. If we unwind a normal frame, and the next outer frame has a PC of zero, stop unwinding. We briefly had this check for "if the next frame is not the innermost frame" and that broke the equivalent of signull.exp; I think I proposed this in follow discussion to that. -- Daniel Jacobowitz