From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23822 invoked by alias); 6 Apr 2004 14:22:37 -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 23715 invoked from network); 6 Apr 2004 14:22:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Apr 2004 14:22:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1BArTA-0007iO-Hi; Tue, 06 Apr 2004 10:22:28 -0400 Date: Tue, 06 Apr 2004 14:22:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: eliz@gnu.org, gdb-patches@sources.redhat.com Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Message-ID: <20040406142228.GA29473@nevyn.them.org> Mail-Followup-To: Orjan Friberg , eliz@gnu.org, gdb-patches@sources.redhat.com References: <407282F4.2080602@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407282F4.2080602@axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-04/txt/msg00137.txt.bz2 On Tue, Apr 06, 2004 at 12:14:12PM +0200, Orjan Friberg wrote: > Eli Zaretskii wrote: > > > >Anyway, from your description, it is quite clear that if a target > >defines HAVE_NONSTEPPABLE_WATCHPOINT, GDB must call > >target_stopped_data_address before it disables the watchpoint and > >steps over it, or else the target end should store the necessary info > >somewhere and deliver it when target_stopped_data_address is called. > > > >In other words, it sounds like a bug. > > I had missed a previous thread on the subject, initiated by Paul Koning > (starting at > http://sources.redhat.com/ml/gdb-patches/2003-05/msg00506.html). Paul > sent me a patch for 5.3 which no longer applies cleanly, and with his > blessings I'm trying to update his patch to the current CVS. > > Doing that, I encountered a problem with read watchpoints (rwatch > command): in insert_breakpoints, before calling insert_bp_location, the > current value of the watched expression is read. Then in > bpstat_stop_status, when the watchpoint has hit, there's the following > code snippet: > > case WP_VALUE_CHANGED: > if (b->type == bp_read_watchpoint) > { > /* Don't stop: read watchpoints shouldn't fire if > the value has changed. This is for targets > which cannot set read-only watchpoints. */ > bs->print_it = print_it_noop; > bs->stop = 0; > continue; > } > ++(b->hit_count); > break; > > So, if we're "read watching" a variable that indeed has changed since we > read it before inserting it we decide not to stop. Here's another > example (foo is rwatched): > > volatile int foo = 0; > int a; > > a = foo; /* foo read; stops. */ > foo = 1; > a = foo; /* foo read; doesn't stop because value changed. */ > > > The "Don't stop" comment is consistent with the behaviour, so it seems > like this is intended. What am I missing here? Presumably, the relevant part of the comment is the second half: "this is for targets which cannot set read-only watchpoints". On the other hand, it does not sound like that code will work for targets which _can_ set read-only watchpoints. The patch was: 2000-03-21 Eli Zaretskii * breakpoint.c (bpstat_stop_status): Don't stop if a read watchpoint appears to break, but the watched value changed. And since Eli demonstrably knows more than I do about how watchpoints work, I'm going to defer further comments at this point :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer