From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13684 invoked by alias); 13 May 2006 15:13:44 -0000 Received: (qmail 13674 invoked by uid 22791); 13 May 2006 15:13:43 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 13 May 2006 15:13:41 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FevoJ-00015m-07; Sat, 13 May 2006 11:13:39 -0400 Date: Sat, 13 May 2006 15:17:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier Message-ID: <20060513151338.GB3721@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060510180312.GA12606@nevyn.them.org> <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i 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-05/txt/msg00294.txt.bz2 On Sat, May 13, 2006 at 11:46:35AM +0200, Mark Kettenis wrote: > > Tested on x86_64-pc-linux-gnu, and by hand against SymbianOS, where it gives > > much nicer looking backtraces. > > Our goal shouldn't be nicer looking backtraces. It should be > providing the user with all information needed to fix bugs in their > programs. Your patch is removing such a bit of information, and > therefore unacceptable to me. Sorry :(. Sorry, Mark, I completely disagree with you on this issue. Let's at least discuss it, please? You said that removing the 0x00000000 frame removed information. I disagree. It's not a valid frame, "up"'ing into it isn't going to give you anything sensible for saved registers unless the return address was the only thing on the stack that got clobbered (fairly rare). Instead, with the patch, the backtrace will appear to just suddenly stop. If the function at the bottom of the backtrace isn't an entry point, the fact that the backtrace has just suddenly stopped is a pretty big clue that the stack is horked. Explanatory output ("why did that backtrace stop?") is available in "set debug frame 1". If you think it's routinely useful, then we can make it available in some prettier form, perhaps in "info frame" for the outermost frame. Also, I don't think that "gdb is confused" errors are as desirable as you think they are. This extra frame has been reported to me as a bug at least three times that I can think of (twice for RTOSes and once for Linux KGDB). Such messages upset users when their stack is _not_ horked. For example, when GDB's prologue unwinder can't handle a prologue for a non-leaf function on the stack, often you'll get this "friendly" message: error (_("Previous frame identical to this frame (corrupt stack?)")); I've had users come up to me and say that they wasted hours looking for the stack corruption GDB was complaining about and in fact it was just a weakness in the unwinder. And Joel recently reported that Ada tasking generates this message on at least one platform, and users are unhappy about that, too. I think that determining the end of stack cleanly is one of the more important things for GDB to get right. And when we've run out of useful information, the stack appears to end, and we're quite justified in reporting that the stack ended. It's quite complex enough already without reporting "but the end of the stack looks a little funny to me...". -- Daniel Jacobowitz CodeSourcery