Re: Problem reading corefiles on ARM

[Joe Buck <Joe.Buck@synopsys.COM>]

I wrote:
>  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.

On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote:
> 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.

But not necessarily all of them (depending on platform).  That is,
the caller-saved registers don't have to be saved because the function
isn't returning, but there has to be enough of a stack frame so that
a debugger can set a breakpoint on the abort and determine who the
caller was.

> 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). 

Evidently there was a motivating application where #2 was an important
optimization.  Still, I think you're right that it would be better to
do it only if the optimization is asked for (via a new flag).