From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30303 invoked by alias); 18 May 2006 09:31:34 -0000 Received: (qmail 30292 invoked by uid 22791); 18 May 2006 09:31:33 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 May 2006 09:31:31 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-03.spheriq.net with ESMTP id k4I9VRt9023860 for ; Thu, 18 May 2006 09:31:27 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id k4I9VOlV012351 for ; Thu, 18 May 2006 09:31:26 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id k4I9VMni026286 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 18 May 2006 09:31:23 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3884FDA86; Thu, 18 May 2006 09:30:29 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9ABD847339; Thu, 18 May 2006 09:30:28 +0000 (GMT) Received: from [164.129.15.13] (bri1043.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHO01718 (AUTH stubbsa); Thu, 18 May 2006 10:30:27 +0100 (BST) Message-ID: <446C3EB3.1040606@st.com> Date: Thu, 18 May 2006 10:09:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jim Blandy Cc: Joel Brobecker , PAUL GILLIAM , 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00398.txt.bz2 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. Andrew