This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem reading corefiles on ARM

Paul Koning <> 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

After all, if we have

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

void func(int arg) {
   int v1 = func1(arg);

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]