Re: Problem reading corefiles on ARM

[Paul Koning <Paul_Koning@dell.com>]

>>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.COM> writes:

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

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

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

 Joe> After all, if we have

 Joe> int func1(int); void func2(int); void ordinary_function(void);

 Joe> void func(int arg) { int v1 = func1(arg); func2(v1);
 Joe> 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.

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.

    paul