From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5546 invoked by alias); 4 Jan 2003 23:08:00 -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 5534 invoked from network); 4 Jan 2003 23:07:59 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 4 Jan 2003 23:07:59 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UzH6-0005DP-00 for ; Sat, 04 Jan 2003 19:08:24 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UxOa-00038Q-00 for ; Sat, 04 Jan 2003 18:08:00 -0500 Date: Sat, 04 Jan 2003 23:08:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA/breakpoint] Fix errors from disabled watchpoints Message-ID: <20030104230800.GE28756@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20021228180954.GA17387@nevyn.them.org> <3E149C3E.5EE135BB@redhat.com> <20030102212230.GA23599@nevyn.them.org> <3E14C79B.8A2FFD74@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E14C79B.8A2FFD74@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00160.txt.bz2 On Thu, Jan 02, 2003 at 03:13:31PM -0800, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > > > On Thu, Jan 02, 2003 at 12:08:30PM -0800, Michael Snyder wrote: > > > Daniel Jacobowitz wrote: > > > > > > > > Right now, if you set and then disable a watchpoint, you'll still memory > > > > errors from it in two places. One is fatal, and comes from > > > > insert_breakpoints (); the other is just noisy, and comes from > > > > breakpoint_re_set_one (). Neither really serves any purpose. If a > > > > watchpoint is disabled, we don't need to check what its value is; we'll > > > > check when we insert it. > > > > > > > > It would be nice to do the equivalet of a bp_shlib_disabled for watchpoints > > > > on memory that isn't currently accessible but that's not really practical on > > > > any OS I know of, so the user still has to hand-disable and hand-enable the > > > > watchpoints. But at least they don't have to _delete_ the watchpoints now. > > > > > > > > Is this OK? No surprises in the testsuite on i386-linux. > > > > > > I'm not surprised that watchpoints were broken in this way, > > > but after looking at your changes, I am surprised that the > > > problem didn't show up in any other context. > > > > > > My only concern with your change is that you've changed > > > the code from explicitly listing the excluded states, to > > > assuming that they are all excluded except for one. The > > > problem that concerns me with that is, what if future states > > > are added? > > > > We were already being pretty inconsistent about which we checked; see > > how half the checks I deleted were inclusive and the other half were > > exclusive? > > > > If we start adding states I suspect we'll need BREAKPOINT_ENABLED > > (bp->state), or something along those lines. > > Or BREAKPOINT_INSERTABLE, or something. OK, I'll approve it. Thanks, committed. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer