From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21869 invoked by alias); 3 Dec 2005 03:05:46 -0000 Received: (qmail 21845 invoked by uid 22791); 3 Dec 2005 03:05:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 03 Dec 2005 03:05:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EiNiP-00063I-9V; Fri, 02 Dec 2005 22:05:33 -0500 Date: Sun, 04 Dec 2005 20:19:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' Message-ID: <20051203030533.GA23195@nevyn.them.org> Mail-Followup-To: Jim Blandy , pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com> <20051202011703.GA27515@nevyn.them.org> <200512021146.54036.pgilliam@us.ibm.com> <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> User-Agent: Mutt/1.5.8i 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/msg00080.txt.bz2 On Fri, Dec 02, 2005 at 02:19:07PM -0800, Jim Blandy wrote: > On 12/2/05, Paul Gilliam wrote: > > 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. > (That text belongs in a comment, else Daniel wouldn't have got it wrong!) For all sorts of reasons, this isn't a safe algorithm; just a guess. - A forward scan really has to stop at any control flow instruction. - A backward scan, in general, is just not possible. GCC does agressive basic block reordering and tail merging, and will do more so in the future; who knows where you came from... It may be a useful guess though. > You know, there's no reason this logic wouldn't be equally useful in > the skip_prologue function. If the prologue scan doesn't make it to > the PC, then we could do the above, and use it to provide an accurate > frame ID. That would fix the bug, and backtraces too. I don't think I follow... Anyway, there is exactly this one user of the method. It occured to me that there may be a better way to figure out what we _really_ want to check there. We want to know "is this watchpoint in a stack frame that isn't there any more". A gdbarch method that knows whether we're above or below the stack pointer... But this all gets tangled up in what we're _really_ watching. We want to watch the local variable, which may move around - we get the "multiple locations" (loclist) case completely wrong today. -- Daniel Jacobowitz CodeSourcery, LLC From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21860 invoked by alias); 3 Dec 2005 03:05:44 -0000 Received: (qmail 21844 invoked by uid 22791); 3 Dec 2005 03:05:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 03 Dec 2005 03:05:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EiNiP-00063I-9V; Fri, 02 Dec 2005 22:05:33 -0500 Date: Sun, 04 Dec 2005 18:59:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' Message-ID: <20051203030533.GA23195@nevyn.them.org> Mail-Followup-To: Jim Blandy , pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com> <20051202011703.GA27515@nevyn.them.org> <200512021146.54036.pgilliam@us.ibm.com> <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> User-Agent: Mutt/1.5.8i 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/msg00079.txt.bz2 Message-ID: <20051204185900.4HFRrucp3Z7BnPBr30b4QHu-2_-Pp2y7E0CLL8lMxwQ@z> On Fri, Dec 02, 2005 at 02:19:07PM -0800, Jim Blandy wrote: > On 12/2/05, Paul Gilliam wrote: > > 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. > (That text belongs in a comment, else Daniel wouldn't have got it wrong!) For all sorts of reasons, this isn't a safe algorithm; just a guess. - A forward scan really has to stop at any control flow instruction. - A backward scan, in general, is just not possible. GCC does agressive basic block reordering and tail merging, and will do more so in the future; who knows where you came from... It may be a useful guess though. > You know, there's no reason this logic wouldn't be equally useful in > the skip_prologue function. If the prologue scan doesn't make it to > the PC, then we could do the above, and use it to provide an accurate > frame ID. That would fix the bug, and backtraces too. I don't think I follow... Anyway, there is exactly this one user of the method. It occured to me that there may be a better way to figure out what we _really_ want to check there. We want to know "is this watchpoint in a stack frame that isn't there any more". A gdbarch method that knows whether we're above or below the stack pointer... But this all gets tangled up in what we're _really_ watching. We want to watch the local variable, which may move around - we get the "multiple locations" (loclist) case completely wrong today. -- Daniel Jacobowitz CodeSourcery, LLC