From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31898 invoked by alias); 22 May 2006 23:11:07 -0000 Received: (qmail 31890 invoked by uid 22791); 22 May 2006 23:11:06 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 22 May 2006 23:11:04 +0000 Received: (qmail 943 invoked from network); 22 May 2006 23:11:03 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 May 2006 23:11:03 -0000 To: Eli Zaretskii Cc: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier References: <20060510180312.GA12606@nevyn.them.org> <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> <20060513151338.GB3721@nevyn.them.org> <200605131642.k4DGgiqa018273@elgar.sibelius.xs4all.nl> <20060516204503.GC13210@nevyn.them.org> <200605162137.k4GLbZiS014187@elgar.sibelius.xs4all.nl> <20060516221837.GA15617@nevyn.them.org> <1147815745.3672.163.camel@dufur.beaverton.ibm.com> <20060517155729.GF27234@adacore.com> <446C3EB3.1040606@st.com> <1147969938.3672.168.camel@dufur.beaverton.ibm.com> <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> From: Jim Blandy Date: Mon, 22 May 2006 23:15:00 -0000 In-Reply-To: (Eli Zaretskii's message of "Fri, 19 May 2006 21:12:24 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00444.txt.bz2 Eli Zaretskii writes: >> Cc: Mark Kettenis , gdb-patches@sourceware.org >> From: Jim Blandy >> Date: Fri, 19 May 2006 10:38:36 -0700 >> >> > I think it was already suggested in this lengthy thread to display >> > some kind of message to alert the user. For example: >> > >> > (Backtrace terminated due to zero return address.) >> > >> > Would this make everybody fairly happy to zero in on a solution? >> >> (UNFAIR UNHAPPINESS ABOUT NON-ZERO SOLUTIONS FOR EVERYBODY!!!) >> >> Well, no: the stacks we'd like to display are healthy and well-formed, >> according to the conventions of the system; there's nothing >> non-standard about them at all. So they ought to display as normal >> stacks --- on those systems. > > Sorry, I'm too dumb today to see what's humor here and what's for > real. It sounds like you want to see no message at all, and OTOH, you > also objected to having a user option for turning the message on and > off. That leaves us at an impasse. The first sentence was meant to be funny. The following paragraph was completely serious. I don't think we're at an impasse. Right now, on systems that terminate their stacks with zero return addresses, GDB displays well-formed stacks incorrectly, showing an extra frame after the oldest real frame. Everyone agrees, including Mark, that this behavior is wrong, and should be fixed. Daniel's original proposal, which Joel and I think is fine, was to make GDB treat a null return address as a proper end-of-stack on all systems. This would be a simple, localized change. It would fix the bug observed on zero-return-addr-stack-end systems. The drawback Mark pointed out is that, on a system that does not use a zero return address to indicate the end of the stack, if a stack has been corrupted by having some return address overwritten with a zero, GDB will display that stack as ending normally. That is, because Daniel's proposed change would affect all systems, not just systems which intentionally use zero return addresses, it could make certain kinds of corruption somewhat less apparent: instead of ending with a weird frame with a 0x00000000 PC, the backtrace will simply end at the prior frame. You'll still have a stack that ends before you'd expect, but it won't end in a mess. The compromise is to do something which makes the interpretation of zero return addresses specific to those ABI's that use it. Daniel suggested a gdbarch flag, but Mark wants to pursue having the unwinders on such ABI's make the decision.