From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15882 invoked by alias); 6 Aug 2008 17:10:11 -0000 Received: (qmail 15864 invoked by uid 22791); 6 Aug 2008 17:10:10 -0000 X-Spam-Check-By: sourceware.org Received: from us02smtp1.synopsys.com (HELO vaxjo.synopsys.com) (198.182.60.75) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Aug 2008 17:09:30 +0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by vaxjo.synopsys.com (Postfix) with ESMTP id 361E4DC1E; Wed, 6 Aug 2008 10:09:28 -0700 (PDT) Received: from venkatar-opt-lnx.internal.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA24390; Wed, 6 Aug 2008 10:09:27 -0700 (PDT) Received: from venkatar-opt-lnx.internal.synopsys.com (localhost.localdomain [127.0.0.1]) by venkatar-opt-lnx.internal.synopsys.com (8.13.1/8.12.3) with ESMTP id m76H9RtX003347; Wed, 6 Aug 2008 10:09:27 -0700 Received: (from jbuck@localhost) by venkatar-opt-lnx.internal.synopsys.com (8.13.1/8.13.1/Submit) id m76H9Dub003346; Wed, 6 Aug 2008 10:09:13 -0700 Date: Wed, 06 Aug 2008 17:10:00 -0000 From: Joe Buck To: Paul Koning Cc: mark.kettenis@xs4all.nl, drow@false.org, gcc@sources.redhat.com, sposelenov@emcraft.com, gdb@sources.redhat.com Subject: Re: Problem reading corefiles on ARM Message-ID: <20080806170912.GL18206@synopsys.com> References: <4899C0FE.4010008@emcraft.com> <20080806152736.GA31492@caradoc.them.org> <200808061542.m76FgmUv017348@brahms.sibelius.xs4all.nl> <18585.51522.726379.18666@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18585.51522.726379.18666@gargle.gargle.HOWL> User-Agent: Mutt/1.4.1i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00107.txt.bz2 On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote: > I think the space savings in "noreturn" come from not having to save > caller-saved registers in the calling function. That savings can add > up if the noreturn function is called from many places. > > Clearly the return address needs to be saved in the case of functions > like "abort". Come to think of it, probably all the usual registers > should be saved, so you can examine variables in the function that > called abort and not get nonsense. > > It sounds to me like the "noreturn" attribute should be removed from > "abort". I don't think that this is the right way to go. There are several effects from "noreturn". We would want some of these effects for "abort", but not others, to get debuggable code without degrading compile-time warnings. For the function #include int func(int arg) { switch (arg) { case 0: return 23; case 1: return 42; default: abort(); } } getting rid of the "noreturn" attribute on abort() would make -Wall give the warning foo.c: In function `func': foo.c:9: warning: control reaches end of non-void function So, to produce debuggable code, instead of getting rid of the attribute, we should instead keep the attribute, as well as enough information to debug. Some users will want the maximum optimization even if it impedes debugging. We already have -fomit-frame-pointer, which leaves out information on stack frames. Perhaps that flag could also enable (or in its absence, disable) the omission of information about calls to noreturn functions. An alternative would be a separate flag.