From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22631 invoked by alias); 2 Jan 2003 23:13:48 -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 22624 invoked from network); 2 Jan 2003 23:13:45 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 2 Jan 2003 23:13:45 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h02MkHB06694 for ; Thu, 2 Jan 2003 17:46:17 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h02NDVn00443; Thu, 2 Jan 2003 18:13:31 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h02NDVn27633; Thu, 2 Jan 2003 15:13:31 -0800 Message-ID: <3E14C79B.8A2FFD74@redhat.com> Date: Thu, 02 Jan 2003 23:13:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com, jimb@redhat.com Subject: Re: [RFA/breakpoint] Fix errors from disabled watchpoints References: <20021228180954.GA17387@nevyn.them.org> <3E149C3E.5EE135BB@redhat.com> <20030102212230.GA23599@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00039.txt.bz2 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.