From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27032 invoked by alias); 2 Dec 2005 19:15:27 -0000 Received: (qmail 27015 invoked by uid 22791); 2 Dec 2005 19:15:26 -0000 X-Spam-Check-By: sourceware.org Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 19:15:24 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB2JFMDn027565 for ; Fri, 2 Dec 2005 14:15:22 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB2JGqb5095658 for ; Fri, 2 Dec 2005 12:16:52 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jB2JFLqZ009262 for ; Fri, 2 Dec 2005 12:15:21 -0700 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jB2JFLtV009249; Fri, 2 Dec 2005 12:15:21 -0700 From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: gdb-patches@sourceware.org Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' Date: Fri, 02 Dec 2005 20:17:00 -0000 User-Agent: KMail/1.6.2 Cc: Daniel Jacobowitz , Jim Blandy , gdb-patches@sources.redhat.com References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com> <20051202011703.GA27515@nevyn.them.org> In-Reply-To: <20051202011703.GA27515@nevyn.them.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200512021146.54036.pgilliam@us.ibm.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00064.txt.bz2 Message-ID: <20051202201700.des1PlyltELlD8iNsszv55QksK9xuoSeaDtvjUzO6_A@z> On Thursday 01 December 2005 17:17, Daniel Jacobowitz wrote: > On Thu, Dec 01, 2005 at 05:07:24PM -0800, Jim Blandy wrote: > > Paul wanted to fast-track this patch, in hopes it could get into the > > 6.4 release. Joel, what are your thoughts? > > I'm opposed. The patch is a serious hack - it assumes that the exit of > the function is near the end of the function - and I think we need to > think about the underlying issues a bit. It's also for a very minor > bug. > This patch does *not* assume that the exit of the function is near the end of the function. It's more/less of a hack than that! Here is the 'algorithm': 1) scan forward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. b) Stop scanning if you find a return instruction or reach the end of the function. 2) scan backward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. b) Stop scanning if you reach the beginning of the function. Some other points: * The PowerPC would not be the only architecture that uses 'gdbarch_in_function_epilogue_p()'. * Danial may characterize the inability to watch a local variable as a very minor bug, but if a user (we have one) is so desperate with a bug of their own that they see *software* watchpoints as a needed tool, I don't think they would characterize this is "very minor". 8-) * I know that this is a hack. It really is a fall-back-hack, as Jim Blandly aluded to in his posting: http://sourceware.org/ml/gdb-patches/2005-12/msg00028.html * If the 'underlying cause' Jim refers to gets fixed, the hack will no longer be executed and it could be removed, or it could stay. * I would prefer the 'right' fix and will presue it, but for right now, this patch 'fixes' a bug and all though it's a hack, it is isolated and easly addressed once the 'right' fix is found.