From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3460 invoked by alias); 1 Dec 2005 18:27:10 -0000 Received: (qmail 3445 invoked by uid 22791); 1 Dec 2005 18:27:09 -0000 X-Spam-Check-By: sourceware.org Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Dec 2005 18:27:03 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB1IR1fk010179 for ; Thu, 1 Dec 2005 13:27:01 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB1IQRSI055258 for ; Thu, 1 Dec 2005 11:26:28 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jB1IQxYo030591 for ; Thu, 1 Dec 2005 11:27:00 -0700 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jB1IQxUn030550; Thu, 1 Dec 2005 11:26:59 -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: Thu, 01 Dec 2005 18:27:00 -0000 User-Agent: KMail/1.6.2 Cc: Jim Blandy , gdb-patches@sources.redhat.com References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0511302121k4b750269l4316b1e13a41debc@mail.gmail.com> In-Reply-To: <8f2776cb0511302121k4b750269l4316b1e13a41debc@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200512011057.59870.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/msg00023.txt.bz2 On Wednesday 30 November 2005 21:21, Jim Blandy wrote: > I'm not objecting to the patch, but following the links to the other > messages I didn't really see an explanation as to how incorrectly > recognizing the prologue causes the watchpoints to be deleted early. > I assume we're talking about a case like: > - we're in some function foo > - we set a watchpoint on one of its local variables > - we step through a call from foo to bar > - as we exit bar, the watchpoint gets deleted, even though it's in the > frame we're returning to, not the frame that is exiting. > > Is that right? How does correctly recognizing the prologue fix this? > > You have it, that's exactly what's going on. The reason the watchpoint gets deleted when exiting bar is that 'watchpoint_check' ("breakpoint.c":2480) thinks that the watched variable is out of scope. It thinks that because once the stack pointer has been diddled with in the functions epilogue, 'frame_find_by_id' ("./frame.c":394) is unable to find frame where the variable is active. It is unable to do so because when scanning through the frames, 'get_frame_id' ("./frame.c":333) returns a frame_id with the correct 'stack_addr' but with the wrong 'code_addr'. The 'code_addr' is for the function being exited instead of the function being returned to. When the frame where the variable is active can not be found, 'gdbarch_in_function_epilogue_p' is called to see if execution is in an epilogue. If it is 'watchpoint_check' just returns 'no change'. Once execution gets out of the epilogue by returning, 'get_frame_id' does the right thing again and everything is good. The default 'gdbarch_in_function_epilogue_p' always just says no. By defining 'rs6000_in_function_epilogue_p' and puting it's address into the arch. vector, the correct determination is made and the bug is fixed. -=# Paul #=- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3463 invoked by alias); 1 Dec 2005 18:27:10 -0000 Received: (qmail 3440 invoked by uid 22791); 1 Dec 2005 18:27:09 -0000 X-Spam-Check-By: sourceware.org Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Dec 2005 18:27:03 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB1IR1nc024491 for ; Thu, 1 Dec 2005 13:27:01 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB1IQSSI081006 for ; Thu, 1 Dec 2005 11:26:28 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jB1IQxYq030591 for ; Thu, 1 Dec 2005 11:27:00 -0700 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jB1IQxUn030550; Thu, 1 Dec 2005 11:26:59 -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: Thu, 01 Dec 2005 20:14:00 -0000 User-Agent: KMail/1.6.2 Cc: Jim Blandy , gdb-patches@sources.redhat.com References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0511302121k4b750269l4316b1e13a41debc@mail.gmail.com> In-Reply-To: <8f2776cb0511302121k4b750269l4316b1e13a41debc@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200512011057.59870.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/msg00024.txt.bz2 Message-ID: <20051201201400.V77hsMNevgW29QSyNCV7WsP6fVfs8didQMqd2r8Z6sM@z> On Wednesday 30 November 2005 21:21, Jim Blandy wrote: > I'm not objecting to the patch, but following the links to the other > messages I didn't really see an explanation as to how incorrectly > recognizing the prologue causes the watchpoints to be deleted early. > I assume we're talking about a case like: > - we're in some function foo > - we set a watchpoint on one of its local variables > - we step through a call from foo to bar > - as we exit bar, the watchpoint gets deleted, even though it's in the > frame we're returning to, not the frame that is exiting. > > Is that right? How does correctly recognizing the prologue fix this? > > You have it, that's exactly what's going on. The reason the watchpoint gets deleted when exiting bar is that 'watchpoint_check' ("breakpoint.c":2480) thinks that the watched variable is out of scope. It thinks that because once the stack pointer has been diddled with in the functions epilogue, 'frame_find_by_id' ("./frame.c":394) is unable to find frame where the variable is active. It is unable to do so because when scanning through the frames, 'get_frame_id' ("./frame.c":333) returns a frame_id with the correct 'stack_addr' but with the wrong 'code_addr'. The 'code_addr' is for the function being exited instead of the function being returned to. When the frame where the variable is active can not be found, 'gdbarch_in_function_epilogue_p' is called to see if execution is in an epilogue. If it is 'watchpoint_check' just returns 'no change'. Once execution gets out of the epilogue by returning, 'get_frame_id' does the right thing again and everything is good. The default 'gdbarch_in_function_epilogue_p' always just says no. By defining 'rs6000_in_function_epilogue_p' and puting it's address into the arch. vector, the correct determination is made and the bug is fixed. -=# Paul #=-