From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32521 invoked by alias); 28 Nov 2007 17:59:45 -0000 Received: (qmail 32509 invoked by uid 22791); 28 Nov 2007 17:59:43 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Nov 2007 17:59:35 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 25CDC17F71F for ; Wed, 28 Nov 2007 15:55:30 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lASHxMuJ3473552 for ; Wed, 28 Nov 2007 15:59:26 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lASHxK8g007185 for ; Wed, 28 Nov 2007 15:59:20 -0200 Received: from [9.12.244.126] ([9.12.244.126]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lASHxFpY006996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Nov 2007 15:59:18 -0200 Subject: [PATCH] Watchpoints + conditionals problem From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary="=-0XzF6zj05FB/lkboVjg1" Date: Wed, 28 Nov 2007 17:59:00 -0000 Message-Id: <1196272755.15925.11.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00525.txt.bz2 --=-0XzF6zj05FB/lkboVjg1 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 944 Hi folks, There is an unexpected behavior when we use software watchpoints (also hardware in some cases) attached to conditional expressions, such as: "watch x if x == ", considering "x" a simple "int" type variable. When that watchpoint goes out of scope, it's marked for disposal at the next stop as obviously there's no way to evaluate the expression "x" anymore. But GDB is still trying to evaluate the conditional part of the watchpoint, even though "x" is out of scope already. Thus, GDB is failing to find correct frame information and ends up in an internal error. I've tracked down this issue and it seems we need to check for the disposition field of the watchpoint whenever we check for the return value of a conditional expression. Attached is a simple patch of what i have in mind to fix this issue. The testcase can be a simple "Hello world"-like binary with a few variables to watch. Any other ideas? Regards, Luis --=-0XzF6zj05FB/lkboVjg1 Content-Disposition: attachment; filename=watch_condition_fix.diff Content-Type: text/x-patch; name=watch_condition_fix.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 555 Index: gdb/breakpoint.c =================================================================== --- gdb.orig/breakpoint.c 2007-11-28 09:47:26.000000000 -0800 +++ gdb/breakpoint.c 2007-11-28 09:49:47.000000000 -0800 @@ -2969,7 +2969,7 @@ if (b->type == bp_watchpoint_scope) b->related_breakpoint->watchpoint_triggered = watch_triggered_yes; - if (bl->cond) + if (bl->cond && bl->owner->disposition != disp_del_at_next_stop) { /* Need to select the frame, with all that implies so that the conditions will have the right context. */ --=-0XzF6zj05FB/lkboVjg1--