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

[Michael Snyder <msnyder at specifix dot com>]

Ping?

On Tue, 2007-12-04 at 15:11 -0800, Michael Snyder wrote:
> 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.
> 
> 
> 
>