From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7422 invoked by alias); 12 Dec 2007 19:21:28 -0000 Received: (qmail 7414 invoked by uid 22791); 12 Dec 2007 19:21:27 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Dec 2007 19:21:20 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 478433BD7F; Wed, 12 Dec 2007 11:21:17 -0800 (PST) Subject: Re: RFA: Fix check for no-saved-pc From: Michael Snyder To: Mark Kettenis Cc: drow@false.org, gdb-patches@sourceware.org In-Reply-To: <1196809890.2501.287.camel@localhost.localdomain> References: <1196462431.2501.164.camel@localhost.localdomain> <20071130230045.GA24809@caradoc.them.org> <1196473044.2501.189.camel@localhost.localdomain> <200712041805.lB4I5KsC028209@brahms.sibelius.xs4all.nl> <1196809890.2501.287.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 12 Dec 2007 19:42:00 -0000 Message-Id: <1197486323.32169.94.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00167.txt.bz2 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 > > > 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. > > > >