Re: Problem reading corefiles on ARM

Joe Buck
2008-08-06T17:52:14Z

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