Re: Problem reading corefiles on ARM

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

Joe> After all, if we have

int func1(int);
void func2(int);
void ordinary_function(void);
 
void func(int arg) {
      int v1 = func1(arg);
      func2(v1);
      ordinary_function();
}

>  Joe> and there's a segfault in ordinary_function, in general v1 isn't
>  Joe> going to be kept around for inspection in the core dump.  So why
>  Joe> should we impose a stricter requirement if ordinary_function is
>  Joe> replaced by abort() ?  It seems Paul thinks we should be
>  Joe> required to save v1 if there's an abort call, unless I'm
>  Joe> misunderstanding.

On Thu, Aug 07, 2008 at 09:28:30AM -0400, Paul Koning wrote:
> My view is that abort() should be like other (returning) functions --
> no special treatment for variable liveness.  Yes, that means in the
> optimized case you may lose, some of the time.  People chose -O
> settings with that issue in mind.  I'm not asking for more to be saved
> for abort() than for regular functions -- but also no less.

I'm not sure if anyone besides Paul and me care any more, but I'll just
do one more.

OK, consider this case:

int func1(int);
void func2(int);
bool test(void);
void func3(int);

void func(int arg) {
      int v1 = func1(arg);
      func2(v1);
      if (test()) {
          func3(v1);
      }
}

Here if we put v1 in a register, we obviously have to save it across
the call to test(), unless we know that test() will never return true,
in which case we don't need to save v1.

But what about replacing the "if" by

      if (!test())
          abort();
      func3(v1);

Now, if I read you right, we'd have so save v1 even if we know that
test() returns false.