From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14570 invoked by alias); 15 May 2006 10:19:49 -0000 Received: (qmail 14558 invoked by uid 22791); 15 May 2006 10:19:48 -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; Mon, 15 May 2006 10:19:45 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-03.spheriq.net with ESMTP id k4FAJWR8030564 for ; Mon, 15 May 2006 10:19:33 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id k4FAJVmP020444 for ; Mon, 15 May 2006 10:19:31 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id k4FAJSCn028798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 15 May 2006 10:19:30 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 008E6DA47; Mon, 15 May 2006 10:19:27 +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 7FA1147434; Mon, 15 May 2006 10:19:27 +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 CHN23701 (AUTH stubbsa); Mon, 15 May 2006 11:18:34 +0100 (BST) Message-ID: <4468557A.3070204@st.com> Date: Mon, 15 May 2006 13:57:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Kettenis Cc: drow@false.org, 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> In-Reply-To: <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> 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/msg00325.txt.bz2 Mark Kettenis wrote: > And this is exactly the reason why things are done the way they are > done. People should accept that the unwinder can fail, and we should > provide a way to indicate this. There are many ways in which an > unwinder can fail and they're not always detectable. One very > important scemario is where your program is thrashing the stack, > overwriting the return address. We absulutely need to provide the > user some indication that something is wrong. Currently this is the > extra frame we're printing. Except that I get this when there is nothing wrong. I.e. It is crying wolf. The problem I have seems to be that the function that launches a thread has dwarf debug information and GDB can't accept that the first function on the stack can have this. It unwinds all through the stack till it reaches the end of the dwarf functions and then tries the machine specific unwinder. This MUST return at least one frame, even though it knows there isn't one. If it returns NULL, like the dwarf unwinder does, then you get an internal error message, so it returns a null frame ID and causes a null frame in the display. Daniel's patch fixes my problem. > 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 :(. It shouldn't be saying there are problems where there are none. Andrew