From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31371 invoked by alias); 3 Dec 2005 04:20:52 -0000 Received: (qmail 31357 invoked by uid 22791); 3 Dec 2005 04:20:52 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.204) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 04:20:50 +0000 Received: by zproxy.gmail.com with SMTP id l1so761252nzf for ; Fri, 02 Dec 2005 20:20:48 -0800 (PST) Received: by 10.36.3.15 with SMTP id 15mr3344967nzc; Fri, 02 Dec 2005 20:20:48 -0800 (PST) Received: by 10.37.2.6 with HTTP; Fri, 2 Dec 2005 20:20:48 -0800 (PST) Message-ID: <8f2776cb0512022020i655a67c1td120a61ed5f4154e@mail.gmail.com> Date: Sun, 04 Dec 2005 20:48:00 -0000 From: Jim Blandy To: Jim Blandy , pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' In-Reply-To: <20051203030533.GA23195@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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> <20051203030533.GA23195@nevyn.them.org> 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/msg00081.txt.bz2 On 12/2/05, Daniel Jacobowitz wrote: > > 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... I've been loose with my words, so what I'm describing may not correspond exactly to what I've said before, or to what Paul has posted, so erase all that and read afresh. If you call rs6000-tdep.c skip_prologue to analyze a live frame, with 'pc' being the function's entry point and 'lim_pc' being the current PC within that function, then sometimes the analysis won't reach lim_pc; it'll hit some branch or unrecognized instruction. In that case, we just give up and hope that the information we've gathered so far would still be accurate if we had been able to analyze all the way to lim_pc. But we can do a bit better than that. If skip_prologue were sure that lim_pc represents a real PC value (its callers know), and scanning from the entry point wasn't able to reach lim_pc, and lim_pc points directly at a return instruction, then we *know* that the current SP is our CFA. And if you actually understand all the instructions between lim_pc and the return instruction, then you may again be able to derive the CFA. This information can be used in preference to that obtained with the from-entry-point scan. To put it another way, there are two cases where we can be pretty confident our machine code analysis has gotten us the straight dope: when we recognize everything from the entry point to lim_pc, and when we recognize everything from lim_pc to a return instruction. In the first case, we can run backwards from lim_pc to reconstruct the state when we were at the entry point; in the second case, we can run forwards from lim_pc to construct the state we'll be at when we return. Either one is equivalent, for our concept of unwinding. If we moved Paul's heuristic (actually, it's a bit loose for my tastes too, so maybe something tighter) into skip_prologue, we could solve the watchpoint problem, and also improve backtraces, which will also be broken in the midst of the epilogue (if they weren't then watchpoint_check wouldn't be unhappy). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31373 invoked by alias); 3 Dec 2005 04:20:53 -0000 Received: (qmail 31356 invoked by uid 22791); 3 Dec 2005 04:20:52 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.205) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 04:20:50 +0000 Received: by zproxy.gmail.com with SMTP id x3so317308nzd for ; Fri, 02 Dec 2005 20:20:48 -0800 (PST) Received: by 10.36.3.15 with SMTP id 15mr3344967nzc; Fri, 02 Dec 2005 20:20:48 -0800 (PST) Received: by 10.37.2.6 with HTTP; Fri, 2 Dec 2005 20:20:48 -0800 (PST) Message-ID: <8f2776cb0512022020i655a67c1td120a61ed5f4154e@mail.gmail.com> Date: Sun, 04 Dec 2005 21:12:00 -0000 From: Jim Blandy To: Jim Blandy , pgilliam@us.ibm.com, gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' In-Reply-To: <20051203030533.GA23195@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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> <20051203030533.GA23195@nevyn.them.org> 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/msg00082.txt.bz2 Message-ID: <20051204211200.GFb3Xw44EiUxZp5jpXylPkDuPgNJkqC3vbcy27aWQDA@z> On 12/2/05, Daniel Jacobowitz wrote: > > 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... I've been loose with my words, so what I'm describing may not correspond exactly to what I've said before, or to what Paul has posted, so erase all that and read afresh. If you call rs6000-tdep.c skip_prologue to analyze a live frame, with 'pc' being the function's entry point and 'lim_pc' being the current PC within that function, then sometimes the analysis won't reach lim_pc; it'll hit some branch or unrecognized instruction. In that case, we just give up and hope that the information we've gathered so far would still be accurate if we had been able to analyze all the way to lim_pc. But we can do a bit better than that. If skip_prologue were sure that lim_pc represents a real PC value (its callers know), and scanning from the entry point wasn't able to reach lim_pc, and lim_pc points directly at a return instruction, then we *know* that the current SP is our CFA. And if you actually understand all the instructions between lim_pc and the return instruction, then you may again be able to derive the CFA. This information can be used in preference to that obtained with the from-entry-point scan. To put it another way, there are two cases where we can be pretty confident our machine code analysis has gotten us the straight dope: when we recognize everything from the entry point to lim_pc, and when we recognize everything from lim_pc to a return instruction. In the first case, we can run backwards from lim_pc to reconstruct the state when we were at the entry point; in the second case, we can run forwards from lim_pc to construct the state we'll be at when we return. Either one is equivalent, for our concept of unwinding. If we moved Paul's heuristic (actually, it's a bit loose for my tastes too, so maybe something tighter) into skip_prologue, we could solve the watchpoint problem, and also improve backtraces, which will also be broken in the midst of the epilogue (if they weren't then watchpoint_check wouldn't be unhappy).