This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Move the frame zero PC check earlier


On Sat, May 13, 2006 at 11:46:35AM +0200, Mark Kettenis wrote:
> > Tested on x86_64-pc-linux-gnu, and by hand against SymbianOS, where it gives
> > much nicer looking backtraces.
> 
> Our goal shouldn't be nicer looking backtraces.  It should be
> providing the user with all information needed to fix bugs in their
> programs.  Your patch is removing such a bit of information, and
> therefore unacceptable to me.  Sorry :(.

Sorry, Mark, I completely disagree with you on this issue.  Let's at
least discuss it, please?

You said that removing the 0x00000000 frame removed information.  I
disagree.  It's not a valid frame, "up"'ing into it isn't going to give
you anything sensible for saved registers unless the return address was
the only thing on the stack that got clobbered (fairly rare).  Instead,
with the patch, the backtrace will appear to just suddenly stop.  If
the function at the bottom of the backtrace isn't an entry point, the
fact that the backtrace has just suddenly stopped is a pretty big clue
that the stack is horked.

Explanatory output ("why did that backtrace stop?") is available in
"set debug frame 1".  If you think it's routinely useful, then we can
make it available in some prettier form, perhaps in "info frame" for
the outermost frame.

Also, I don't think that "gdb is confused" errors are as desirable as
you think they are.  This extra frame has been reported to me as a bug
at least three times that I can think of (twice for RTOSes and once for
Linux KGDB).

Such messages upset users when their stack is _not_ horked.  For
example, when GDB's prologue unwinder can't handle a prologue for a
non-leaf function on the stack, often you'll get this "friendly"
message:

  error (_("Previous frame identical to this frame (corrupt stack?)"));

I've had users come up to me and say that they wasted hours looking for
the stack corruption GDB was complaining about and in fact it was just
a weakness in the unwinder.  And Joel recently reported that Ada
tasking generates this message on at least one platform, and users are
unhappy about that, too.

I think that determining the end of stack cleanly is one of the more
important things for GDB to get right.  And when we've run out of
useful information, the stack appears to end, and we're quite justified
in reporting that the stack ended.  It's quite complex enough already
without reporting "but the end of the stack looks a little funny to
me...".

-- 
Daniel Jacobowitz
CodeSourcery


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