From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27417 invoked by alias); 17 Dec 2007 18:35:01 -0000 Received: (qmail 27401 invoked by uid 22791); 17 Dec 2007 18:35:00 -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; Mon, 17 Dec 2007 18:34:56 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 51F093C2BE; Mon, 17 Dec 2007 10:34:51 -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: <200712162006.lBGK6AXD018398@brahms.sibelius.xs4all.nl> 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> <1197486323.32169.94.camel@localhost.localdomain> <200712162006.lBGK6AXD018398@brahms.sibelius.xs4all.nl> Content-Type: text/plain Date: Mon, 17 Dec 2007 18:43:00 -0000 Message-Id: <1197916490.20496.42.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/msg00279.txt.bz2 On Sun, 2007-12-16 at 21:06 +0100, Mark Kettenis wrote: > > From: Michael Snyder > > Date: Wed, 12 Dec 2007 11:05:23 -0800 > > > > Ping? > > Bleah, I tried to find a window of a bit more than 15 minutes to think > about a reply for a week and a half and failed :(. > > > > > 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. > > It doesn't really add much more information: > > ? 0x00000000 foo > > isn't really less explicit than > > Saved pc is zero Well sure it is -- if you're a naive user. > Yes, if you fall off the stack, I can imagine you hit zeroes much more > often. I've repeatedly stated that people should fix their threading > libraries to explicitly mark the end of the stack such that this > doesn't happen, or that we should change GDB such that we terminate > the stack at the thread entry point, much like we do for main(). I > really don't want to cripple GDB because people think that's too > difficult. We don't have control over those thread libraries, so all we can do is (1) ask them, and (2) try to put work arounds to prevent bogus behavior in gdb. I don't think it's wrong to do that. Cripple gdb? It's only crippling gdb if you think that a saved PC of zero is a legitimate possibility. I think that possibility is remote beyond being worthy of consideration. > Yes, I think your diff cripple GDB. The zero-pc frame might have > useful information that could help me track down the memory > corruption. Well, then it's really a conflict of interests between the naive user, and the user who is sophisticated enough to (a) know what a stack frame of 0x00000000 implies, and (b) know how to extract info from a blown stack frame. I think the naive users outnumber the ones with that level of sophistication by at least 100's to one, if not 1000's to one. We really need to weigh their interests a little more heavily.