From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21265 invoked by alias); 19 Oct 2007 11:49:09 -0000 Received: (qmail 21255 invoked by uid 22791); 19 Oct 2007 11:49:08 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Oct 2007 11:49:04 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 7ABD8982CA for ; Fri, 19 Oct 2007 11:49:03 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 5634D980A7 for ; Fri, 19 Oct 2007 11:49:03 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1IiqLe-0007L3-Dl for gdb@sourceware.org; Fri, 19 Oct 2007 07:49:02 -0400 Date: Fri, 19 Oct 2007 11:49:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: [RFC] Using values to handle unwinding Message-ID: <20071019114902.GB27622@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: <20071017220943.GA24607@caradoc.them.org> <200710191141.l9JBfok4014965@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710191141.l9JBfok4014965@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00167.txt.bz2 On Fri, Oct 19, 2007 at 01:41:50PM +0200, Ulrich Weigand wrote: > > if (get_frame_type (next_frame) == NORMAL_FRAME) > > return 0; > Well, we can always just use "get_next_frame (this_frame)" instead > of next_frame. Getting the next frame is always well-defined. Right. get_next_frame fails when the next frame is the sentinel frame, so it is not always useful if you need a frame that you can pass to a frame_unwind_* routine. But it never fails if frame->next->type would be NORMAL_FRAME. > > I noticed this while looking at m68k-elf backtraces. It would be nice > > to add a check like the above, either there or somewhere more generic, > > because otherwise a garbage stack pointer leads to a near-infinite > > backtrace. Any time that the current frame's PC points to somewhere > > GDB has no symbol info, GDB will conclude that there is a frameless > > function which only stored its return address on the stack at the > > call. So each word of the stack is popped in turn and becomes a new > > PC. Not very useful! > > Yes, situations similar to that were what prompted my addition of the > above sanity check (Andrew's comment nonwithstanding :-/). The m68k check turns out to be particularly thorny; this is a problem with architectures where call pushes onto the stack. You can't distinguish that from any other stack push, so all frames are assumed to have a valid return address as long as the stack is readable. I'm speculating about a "set backtrace max-uncertainty" and frame_is_uncertain ()... or "set backtrace aggressive off"... We shouldn't give up when we have no symbol information if the architecture claims to know how to handle that case. This happens when crashing in a stripped shared library, for instance, and on i386 GNU/Linux GDB generally manages a useful backtrace anyway. Anyway, that's unrelated to this patch. I'll save it for another day :-) -- Daniel Jacobowitz CodeSourcery