From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8626 invoked by alias); 29 Nov 2007 12:06:08 -0000 Received: (qmail 8612 invoked by uid 22791); 29 Nov 2007 12:06:07 -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; Thu, 29 Nov 2007 12:05:59 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id F247D17F50A for ; Thu, 29 Nov 2007 10:01:54 -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 lATC5tWI2273336 for ; Thu, 29 Nov 2007 10:05:55 -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 lATC5tRZ014788 for ; Thu, 29 Nov 2007 10:05:55 -0200 Received: from [9.18.238.21] ([9.18.238.21]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lATC5tc2014785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2007 10:05:55 -0200 Subject: Re: [PATCH] Watchpoints + conditionals problem From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Vladimir Prus Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <1196272755.15925.11.camel@gargoyle> Content-Type: text/plain Date: Thu, 29 Nov 2007 12:06:00 -0000 Message-Id: <1196337955.6139.1.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit 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/msg00544.txt.bz2 Thanks Vladimir, Either way is fine with me. The simple fix or the alternate one. Anybody has any comments? Regards, Luis On Thu, 2007-11-29 at 11:53 +0300, Vladimir Prus wrote: > Luis Machado wrote: > > > 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 run into same problem yesterday. > > > 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? > > I guess ideally we need to: > > 1. Don't check condition at all if bs->stop is already 0. > 2. Immediately delete watchpoint, don't bother with del_at_next_stop > > But for now, your approach is probably fine -- can anybody approve it? > > - Volodya >