From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4983 invoked by alias); 6 Aug 2008 17:39:22 -0000 Received: (qmail 4965 invoked by uid 22791); 6 Aug 2008 17:39:22 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkpc120.us.dell.com (HELO aussmtpmrkpc120.us.dell.com) (143.166.82.159) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Aug 2008 17:38:42 +0000 X-IronPort-AV: E=Sophos;i="4.31,315,1215406800"; d="scan'208";a="353248741" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 06 Aug 2008 12:38:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18585.57711.850217.939413@gargle.gargle.HOWL> Date: Wed, 06 Aug 2008 17:39:00 -0000 From: Paul Koning To: Joe.Buck@synopsys.COM 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 References: <4899C0FE.4010008@emcraft.com> <20080806152736.GA31492@caradoc.them.org> <200808061542.m76FgmUv017348@brahms.sibelius.xs4all.nl> <18585.51522.726379.18666@gargle.gargle.HOWL> <20080806170912.GL18206@synopsys.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-IsSubscribed: yes 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/msg00109.txt.bz2 >>>>> "Joe" == Joe Buck writes: Joe> 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". Joe> I don't think that this is the right way to go. Joe> There are several effects from "noreturn". We would want some Joe> of these effects for "abort", but not others, to get debuggable Joe> code without degrading compile-time warnings. Good point. So the issue is that two unrelated features are currently combined in a single attribute: 1. This function doesn't return, do the right thing with warnings in the caller of this function. 2. Don't bother saving registers when calling this function because it won't return so the registers aren't needed afterwards. The issue is that #2 doesn't apply to "abort" because the registers ARE needed afterwards -- at debug time. One possibility is to have "noreturn" mean #1 only, and invent a new flag for #2. The alternative is to have "noreturn" mean both (as today) and invent a new flag to cancel #2. I'd suggest the former because that's the more likely case. It's hard to think of examples where #2 is needed (or at least, where it is important). paul