Re: Problem reading corefiles on ARM

[Joe Buck <Joe dot Buck at synopsys dot COM>]

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 <stdlib.h>

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.