Re: Do not unwind frames past NULL PC

["Maciej W. Rozycki" <macro@mips.com>]

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