From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17371 invoked by alias); 1 Dec 2004 08:07:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16365 invoked from network); 1 Dec 2004 08:06:10 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 1 Dec 2004 08:06:10 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id 2977F111F2D; Wed, 1 Dec 2004 00:06:01 -0800 (PST) Date: Wed, 01 Dec 2004 08:07:00 -0000 From: Randolph Chung To: gdb-patches@sources.redhat.com Subject: Re: [patch] relax test in gdb.base/commands.exp Message-ID: <20041201080600.GB6359@tausq.org> Reply-To: Randolph Chung References: <20041122232915.GG9148@tausq.org> <20041128174334.GB24639@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041128174334.GB24639@nevyn.them.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00013.txt.bz2 > Why do we get it in the epilogue? Is it because the debug information > claims the variable has gone out of scope, or is it because of > faulty unwind information for the epilogue causing GDB to think the > frame has changed? hmmm.. i just saw this comment in recurse.exp, which is the same as what i observed: # The former version expected the test to return to main(). # Now it expects the test to return to main or to stop in the # function's epilogue. # # The problem is that gdb needs to (but doesn't) understand # function epilogues in the same way as for prologues. # # If there is no hardware watchpoint (such as a x86 debug register), # then watchpoints are done "the hard way" by single-stepping the # target until the value of the watched variable changes. If you # are single-stepping, you will eventually step into an epilogue. # When you do that, the "top" stack frame may become partially # deconstructed (as when you pop the frame pointer, for instance), # and from that point on, GDB can no longer make sense of the stack. # # A test which stops in the epilogue is trying to determine when GDB # leaves the stack frame in which the watchpoint was created. It does # this basically by watching for the frame pointer to change. When # the frame pointer changes, the test expects to be back in main, but # instead it is still in the epilogue of the callee. in the code, i actually see some logic to handle this case: /* in_function_epilogue_p() returns a non-zero value if we're still in the function but the stack frame has already been invalidated. Since we can't rely on the values of local variables after the stack has been destroyed, we are treating the watchpoint in that state as `not changed' without further checking. vinschen/2003-09-04: The former implementation left out the case that the watchpoint frame couldn't be found by frame_find_by_id() because the current PC is currently in an epilogue. Calling gdbarch_in_function_epilogue_p() also when fr == NULL fixes that. */ if ((!within_current_scope || fr == get_current_frame ()) && gdbarch_in_function_epilogue_p (current_gdbarch, read_pc ())) return WP_VALUE_NOT_CHANGED; so possibly all i need is to define a function_epilogue_p predicate for the hppa target. does this mean that recurse.exp should change as well? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/