Re: Problem reading corefiles on ARM

[Paul Koning <Paul_Koning@dell.com>]

>>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.COM> 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