Re: Problem reading corefiles on ARM

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

Paul Koning <Paul_Koning@dell.com> writes:
> > That's sufficient for live debugging but not for corefiles.  In that
> > case you do want caller-saved registers, because they may contain
> > local variable values that don't live in memory at the time of the
> > abort call.

On Wed, Aug 06, 2008 at 11:38:14PM +0200, Andreas Schwab wrote:
> In an optimized build you can't expect any local variable to survive,
> since it may just be dead before the call, or its value may be
> unavailable for any other reason.  The use of the noreturn attribute
> only adds little to this.

Agreed.  I think that the objective should be that if there is an abort
call, then from either a core dump or when gdb'ing a live process it
should be possible to determine the call site of the abort() call, even
with -O2/-Os.  But beyond that, the optimizer should be free, just as
in other cases, to discard values in registers that will never be used
again.

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();
}

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