From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27116 invoked by alias); 18 May 2006 18:09:38 -0000 Received: (qmail 27107 invoked by uid 22791); 18 May 2006 18:09:37 -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; Thu, 18 May 2006 18:09:35 +0000 Received: (qmail 10977 invoked from network); 18 May 2006 18:09:33 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 May 2006 18:09:33 -0000 To: pgilliam@us.ibm.com Cc: Andrew STUBBS , Joel Brobecker , Daniel Jacobowitz , Mark Kettenis , 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> From: Jim Blandy Date: Thu, 18 May 2006 20:04:00 -0000 In-Reply-To: <1147969938.3672.168.camel@dufur.beaverton.ibm.com> (PAUL GILLIAM's message of "Thu, 18 May 2006 09:32:18 -0700") 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/msg00402.txt.bz2 PAUL GILLIAM writes: > On Thu, 2006-05-18 at 09:53 -0700, Jim Blandy wrote: >> Andrew STUBBS writes: >> > Jim Blandy wrote: >> >> For the record, at the top of this thread I said I thought it was >> >> fine, too. I've run into these often enough due to deliberate >> >> attempts by runtimes to terminate the stack that I think it outweighs >> >> the (minor, to my mind) value of seeing a 0x00000000 frame that >> >> indicates an actual error. >> >> GDB should be honest with the user about what it finds, but I don't >> >> think we can be a multi-platform debugger and be that picky about >> >> confining each bit of logic to exactly the platforms that promise to >> >> uphold it. >> > >> > How about adding a command: >> > >> > set backtrace terminate-on-zero-pc on|off >> > >> > and let the user decide. Set it to 'on' by default on the principle >> > that, if they aren't aware of the possibility, users don't want to see >> > zero frames they don't understand. >> > >> > Just a thought. >> >> Well, that would lift the burden of the decision from our shoulders >> (that is, GDB developers', not restricted to the folks here) to the >> users'. I think we're probably in a better position to make it. > > No, that lifts the burden of deciding for *all* users from our > shoulders, allowing those users who understand the issues to override > our decision. > > On the other hand, it would add one more user tweek that most users > would not understand or care about. > > It's a hard call. > > I'd vote for the new command and classify it as obscure. Okay --- I should be less equivocal. It is a bad idea to add this command, obscure or otherwise. Engineers do this all the time when they're having difficulty settling on a solution: they figure, hey, let's let the users decide! It's presented as "giving the users more control". Nobody wants to argue with that: every day we run into something we wish we could tweak. Today I wished I could control the 'From' address vixie cron uses in its mail messages. But it's a mistake to treat this as an indication of the general desireability of more switches and knobs. And half the time the knobs are just workarounds for some other problem --- for example, I think the real problem with my cron is that outgoing mail on my machine is misconfigured. Nobody has written us saying they want to choose whether GDB treats a zero return address as indicating the end of the stack. Rather, many users have written us complaining that GDB displays extra frames at the end of well-formed, non-corrupt stacks. And over the course of the what seems like dozens of embedded GDB ports I've debugged since 1997, I've come across the same behavior many times myself. The only reason presented in this thread for displaying those frames at all is that it can be an indication of a bug in GDB. This is based on the (sound) general argument that GDB should be picky about the state it examines, and report anomalies. But that heuristic just doesn't make sense when the particular "anomaly" at hand is, in fact, a valid and deliberate end-of-stack indicator on many systems.