This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Fix check for no-saved-pc
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.
>
>
>
>