From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17312 invoked by alias); 29 Nov 2007 08:54:35 -0000 Received: (qmail 17298 invoked by uid 22791); 29 Nov 2007 08:54:34 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Nov 2007 08:54:25 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ixf9V-0004Q7-V5 for gdb-patches@sources.redhat.com; Thu, 29 Nov 2007 08:54:16 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 08:53:45 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 08:53:45 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [PATCH] Watchpoints + conditionals problem Date: Thu, 29 Nov 2007 08:54:00 -0000 Message-ID: References: <1196272755.15925.11.camel@gargoyle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 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/msg00539.txt.bz2 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