This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Do not unwind frames past NULL PC
On Fri, 22 Feb 2008, Maciej W. Rozycki wrote:
> Hmm, it looks it has been discussed deeply and fiercely enough for me not
> to dare question the outcome (or the lack of), but given the situation
> wouldn't it be reasonable to place a comment within the code of this
> function stating that outermost frame determination has been deliberately
> omitted so that cases like stack corruption are easier for people to
> debug?
OK, here is the patch. I hope I have gathered the intent from the
discussions correctly and expressed it clearly enough.
Personally I think for MIPS there is no gain from printing a frame with a
zero PC. As for MIPS the frame is associated with the PC, there will
never be further backtrace past a zero PC, because there will never be a
frame described for the code address of zero. So whether the dangling
"frame" is displayed or not makes no difference -- unless there is an
error reported with a backtrace, the null PC will always be there. I
recognise that other architectures may have a different view on the frames
though.
2008-02-25 Maciej W. Rozycki <macro@mips.com>
* frame.c (get_prev_frame_1): Add a note about unwillingness to
check for the outermost frame.
OK to apply?
Maciej
gdb-get_prev_frame.diff
Index: binutils-quilt/src/gdb/frame.c
===================================================================
--- binutils-quilt.orig/src/gdb/frame.c 2008-02-25 10:42:37.000000000 +0000
+++ binutils-quilt/src/gdb/frame.c 2008-02-25 11:48:56.000000000 +0000
@@ -1250,6 +1250,14 @@
}
}
+ /* This is the place where a check for the ABI-specific condition
+ denoting the outermost frame could be done. We do not do this
+ though, quite deliberately, because we have no means to verify
+ whether this condition would be intentional or a result of a
+ possible stack corruption. If the latter was the case we would
+ remove information from output which for some ABIs could
+ provide a hint that a stack corruption actually happened. */
+
/* Allocate the new frame but do not wire it in to the frame chain.
Some (bad) code in INIT_FRAME_EXTRA_INFO tries to look along
frame->next to pull some fancy tricks (of course such code is, by