From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13515 invoked by alias); 10 Nov 2005 14:35:42 -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 13460 invoked by uid 22791); 10 Nov 2005 14:35:37 -0000 Received: from fra-del-01.spheriq.net (HELO fra-del-01.spheriq.net) (195.46.51.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 14:35:37 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-01.spheriq.net with ESMTP id jAAEZT01002201 for ; Thu, 10 Nov 2005 14:35:29 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-03.spheriq.net with ESMTP id jAAEZSBm002406 for ; Thu, 10 Nov 2005 14:35:28 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id jAAEZQBd031948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 10 Nov 2005 14:35:27 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 4E6EBDA46; Thu, 10 Nov 2005 14:35:22 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 4910B471D9; Thu, 10 Nov 2005 14:38:18 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0ABC675999; Thu, 10 Nov 2005 14:38:17 +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 8F327471CE; Thu, 10 Nov 2005 14:38:17 +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 CGU02197 (AUTH "andrew stubbs"); Thu, 10 Nov 2005 14:35:20 GMT Message-ID: <43735A1D.6010406@st.com> Date: Thu, 10 Nov 2005 23:09: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> <437321EE.7010904@st.com> <20051110133905.GB21420@nevyn.them.org> In-Reply-To: <20051110133905.GB21420@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/msg00137.txt.bz2 Daniel Jacobowitz wrote: > I was complaning about the "ABI" part. If you want to talk about what > kind of object it is, it's an unwinder, not a sniffer; sniffers are > used to select unwinders. Hmm, confusing. Well, I can change the name easily enough. It is the unwinder based on the ABI though. How come the unwind function is called sniffer? >>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. > > > Quite on the contrary, my experience is that in most programs you'll > need it at least a couple of times, e.g. to get out of bits of libc or > linker-generated code. Bare-machine (or OS21) sh-elf doesn't use glibc with all its complications. We use newlib and we always compile it with debug info and CFI so there is it should never need to fall back. >>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. > > > Just like the rest of GDB on both counts. Maybe other bits of GDB need an option to switch them off when they turn problematic. Maybe they already do. In fact, maybe I should make this feature more generic and change the error message so that it says 'if this isn't a real problem try switching ... off'. >>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'. > > > For any frame with CFI, the CFI is used in preference. If you don't > want the fallback unwinder to come into play, if as you claim you > really don't need it, then find out why it's being triggered in the > first place. The problem only occurs in threads (unless 'set backtrace pastmain' is set, in which case it happens in any program) when the backtrace falls off the end of the program. There are no more frames because there's no more stack, but there's no way to know that unless you assume the CFI and program run out at the same time. >>As to the SH maintainers, there are none listed in MAINTAINERS. > > > Yes, my mistake; there used to be. BTW, were you (and others) waiting for them to do something about the SH specific patches I have been sending? I ask because I have had no response on a few. I'm currently in the process of trying to patch GDB HEAD sufficiently to run OS21 threaded programs on ST targets like I do with our 6.3 based tools. When I've got that done I'll have a better idea whether anything needs to be done any more. I suspect we will still _like_ to. Thanks Andrew Stubbs