From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10121 invoked by alias); 17 Apr 2004 08:27:04 -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 10114 invoked from network); 17 Apr 2004 08:27:03 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sources.redhat.com with SMTP; 17 Apr 2004 08:27:03 -0000 Received: from zaretski ([80.230.152.225]) by legolas.inter.net.il (MOS 3.4.5-GR) with ESMTP id BOV27671; Sat, 17 Apr 2004 11:26:07 +0300 (IDT) Date: Sat, 17 Apr 2004 08:27:00 -0000 From: "Eli Zaretskii" To: Orjan Friberg Message-Id: <1438-Sat17Apr2004112204+0300-eliz@gnu.org> CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <407FC69A.1000701@axis.com> (message from Orjan Friberg on Fri, 16 Apr 2004 13:42:18 +0200) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Reply-to: Eli Zaretskii References: <407282F4.2080602@axis.com> <20040406142228.GA29473@nevyn.them.org> <6654-Thu15Apr2004111217+0300-eliz@gnu.org> <407E8CEF.2050007@axis.com> <407FC69A.1000701@axis.com> X-SW-Source: 2004-04/txt/msg00387.txt.bz2 > Date: Fri, 16 Apr 2004 13:42:18 +0200 > From: Orjan Friberg > > Orjan Friberg wrote: > > > > 1. Add a check if the target cannot set "pure" read watchpoints to the > > b->type == bp_read_watchpoint check at WP_VALUE_CHANGED (my > > interpretation of Eli's suggestion). > > On second thought, this actually is no good for a target which *can* set > pure read watchpoints. If there's both a watch and an rwatch on a > variable that is written, we'll get a false read watchpoint hit. How about if such targets would set a read/write (i.e. access) watchpoint, and then use the same logic as i386: if the value didn't change, don't announce the rwatch hit? In effect, you would be emulating i386 behavior. That's a band-aid, I know. But to get rid of this mess altogether, the GDB's watchpoint processing will need to be thoroughly revamped. In particular, instead of walking all the watchpoints armed only with the address that caused the inferior to stop, we would need to have the target to tell us exactly what watchpoint triggered, and why. That would mean pushing most of the related logic in bpstat_stop_status into the target/architecture vectors, leaving the GDB's application level with only the higher-level API that communicates with the lower-level layers via watchpoint handles of some kind. By contrast, the current GDB code for hardware-assisted watchpoints grew up from the software watchpoints, whereby GDB would single-step the program and after each step check whether the value of any of the watched expressions changed. This legacy clearly shows for quite some time.