From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25947 invoked by alias); 28 Nov 2004 17:43:39 -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 25914 invoked from network); 28 Nov 2004 17:43:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 28 Nov 2004 17:43:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CYT5C-0006Sx-N6; Sun, 28 Nov 2004 12:43:34 -0500 Date: Sun, 28 Nov 2004 17:43:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] relax test in gdb.base/commands.exp Message-ID: <20041128174334.GB24639@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb-patches@sources.redhat.com References: <20041122232915.GG9148@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041122232915.GG9148@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00489.txt.bz2 On Mon, Nov 22, 2004 at 03:29:15PM -0800, Randolph Chung wrote: > The regexp below checked for a specific line number in the caller when > the watchpoint goes out of scope. On a target that emulates watchpoints > with single stepping i've seen that we get the "watchpoint deleted" > message when we're in the epilogue of a function. in this case the > current line number may still be in the called function. This patch > relaxes the line number checking a bit so we allow both cases (but not > any random line). Tested on hppa-linux. ok? 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? I know that GCC's epilogue unwind info is broken for all targets (except maybe ia64). If the former, then maybe your patch is correct. If the latter, it should probably be an XFAIL. -- Daniel Jacobowitz