Re: RFA: Fix check for no-saved-pc

[Michael Snyder <msnyder@specifix.com>]

On Tue, 2007-12-04 at 19:05 +0100, Mark Kettenis wrote:
> > From: Michael Snyder <msnyder@specifix.com>
> > Date: Fri, 30 Nov 2007 17:37:24 -0800
> > 
> > On Fri, 2007-11-30 at 18:00 -0500, Daniel Jacobowitz wrote:
> > > On Fri, Nov 30, 2007 at 02:40:31PM -0800, Michael Snyder wrote:
> > > > There's a check in get_prev_frame to see if the next saved pc
> > > > is zero.  I think it has an off-by-one error, and is checking 
> > > > for the pc of the wrong frame.
> > > 
> > > Mark K. and I have had roughly a month's worth of discussion on this
> > > check over the last two years; it's where it is on purpose.  Here's
> > > the last conversation:
> > > 
> > >   http://sourceware.org/ml/gdb-patches/2006-05/msg00196.html
> > >   http://sourceware.org/ml/gdb-patches/2006-07/msg00296.html
> > 
> > All right.  Then let's leave that test alone, and add another
> > test, much later on, to detect and report this situation.
> > 
> > Here's my revised patch.  Testsuites un-affected.
> > 
> > As before, the effect of this change is to have gdb print
> > a more informative message instead of a meaningless zero-frame.
> 
> It's not meaningless; it's a very valuable hint that the stack has been
> corrupted. 

My poor choice of words.  What I meant was more like, one is a
"hint" and the other is an explicit statement.  A person does
not need to know what this hint means if gdb tells them
explicitly.


>  You'll get very similar output if youd chosen some random
> value instead of zero when you corrupted the stack.  Why is zero special?

A good question, and the only answer I can give is "it just is".
You are right, this is a special case -- but it seems, in practice,
to be one that comes up fairly frequently, eg. when a wild pointer
or out of bounds array writes zeroes over a region of stack.

Why zero and not some other value?  Just because it is fairly
common to write zeroes into something, I guess.  The real 
answer is because we or our users see it a lot.


> If your answer to that question is something like: "because on arm the
> outermost frame gets marked by a zero pc", 

No, that's not it at all.  This has nothing to do with any
particular architecture (although some may or may not be
more vulnerable to it than others).  This has nothing to 
do with any deliberate attempt to "mark" the outermost frame.

OTOH, one context in which it does come up is when there
has been no attempt at all to mark the outermost frame -- 
as eg. the first frame of a new thread -- and the frame's
memory comes up full of zeros (either because that's the
default value for un-initialized memory, or because the
thread library initializes it to zero).

GDB looks where the function prologue says the return address
should be stored, and finds zero.