From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8029 invoked by alias); 10 Nov 2005 10:53:45 -0000 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 Received: (qmail 8020 invoked by uid 22791); 10 Nov 2005 10:53:43 -0000 Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 10:53:43 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-01.spheriq.net with ESMTP id jAAArW5k010735 for ; Thu, 10 Nov 2005 10:53:32 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id jAAArVlW030136 for ; Thu, 10 Nov 2005 10:53: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 jAAArSiR002427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 10 Nov 2005 10:53: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 9B8FCDA45; Thu, 10 Nov 2005 10:53:21 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id AF7EF473BB; Thu, 10 Nov 2005 10:56:09 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4B2AF75999; Thu, 10 Nov 2005 10:56:09 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4EB32474E7; Thu, 10 Nov 2005 10:38:34 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGT00181 (AUTH "andrew stubbs"); Thu, 10 Nov 2005 10:35:36 GMT Message-ID: <437321EE.7010904@st.com> Date: Thu, 10 Nov 2005 13:36:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [SH][PATCH] Disable ABI frame sniffer References: <43722DEF.8060300@st.com> <20051110013122.GB11334@nevyn.them.org> In-Reply-To: <20051110013122.GB11334@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 X-SW-Source: 2005-11/txt/msg00129.txt.bz2 Daniel Jacobowitz wrote: > I had to look up what you meant by "ABI frame sniffer"; we normally > call this the prologue analyzer. One registers the analyser using frame_unwind_append_sniffer(). The currently configured analysers are called dwarf2_frame_sniffer() and sh_frame_sniffer(). I can't imagine where I got the name from ;-) >>With the ABI sniffer 'off' it is not possible to backtrace through code >>that does not have CFI. On sh-elf, at least, there is always CFI when >>there is debug info, so it is relatively rare that the ABI sniffer is >>actually required. >> >>I have not set the default to 'off' because that causes quite a number >>of FAILs in the testsuite. > > > That should be a hint... Naturally you can't unwind ASM or anything without CFI without the fallback unwinder. That's why it is there. That doesn't mean it isn't irritating when it trys to unwind frames that aren't there. Most of the time you just don't need it. > Obviously the SH maintainers have final say, but I strongly discourage > any patch along these lines. If you want to improve the fallback > unwinder, go ahead. If you want to add more generic tests to terminate > backtraces without annoying messages, we can discuss that. But turning > it off is not viable. It may be possible to improve the unwinder. However, it is dependent on the values in registers and in memory. It would be impossible to prevent it getting occasionally confused. I did, when I origininally encountered the problem, try to detect the problem to avoid the messages, but all I ended up doing was detecting if it would give an error and declaring there were no more frames, which seemed pointless - it would hide the message when it really did mean something. Besides which, the other problem I am trying to fix is that, before the error, the unwinder would typically produce at least one bogus frame. Even if the error has changed to a warning (as you say in the other message) this would still be an irritant. I much prefer the option to say 'My program has CFI, I know it does, I put it there, so stop trying to confuse yourself'. As to the SH maintainers, there are none listed in MAINTAINERS. Andrew Stubbs