From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22830 invoked by alias); 9 Oct 2003 06:04:49 -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 22822 invoked from network); 9 Oct 2003 06:04:48 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 9 Oct 2003 06:04:48 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1A7Tuf-0006sD-N8; Thu, 09 Oct 2003 02:04:37 -0400 Date: Thu, 09 Oct 2003 06:04:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com In-reply-to: <20031008191156.GD13579@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 8 Oct 2003 15:11:56 -0400) Subject: Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint Reply-to: Eli Zaretskii References: <20031008170233.GA9013@nevyn.them.org> <3099-Wed08Oct2003195835+0200-eliz@elta.co.il> <20031008191156.GD13579@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00291.txt.bz2 > Date: Wed, 8 Oct 2003 15:11:56 -0400 > From: Daniel Jacobowitz > > > > Why did you decide to leave the subclasses of hardware watchpoints > > (read, access, and write) in the parent structure, instead of moving > > that distinction here? That seems like you are spreading related > > information between several places instead of having it in a single > > place. > > I'm actually planning to move it to the impl_breakpoint. Ah, okay then. > For instance, according to my interpretation, rwatch **foo should be: > a read watchpoint on the address *foo > a write watchpoint on the address foo, in case it is moved. > I don't know if that matches GDB's current interpreation of such > expressions, though - I haven't looked yet. GDB already does something similar, of course: that's why you see the value chain being chased each time GDB inserts or removes watchpoints. In this case, the value chain of **foo will include &foo as well. Similar things happen with watching arrays and structs; the comments in breakpoint.c should shed more light on this. One other thing to keep in mind wrt watchpoints is that the bp_hardware_watchpoint kind is handled differently from bp_read_watchpoint and bp_access_watchpoint. I believe the reasons are histerical, but I think you will need to know this while hacking that part of the code, especially if you decide to change it so that all 3 kinds are handled the same way, as I think they should.