>>>>> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Paul Koning <[EMAIL PROTECTED]> 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
