From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16455 invoked by alias); 8 Oct 2003 10:26:31 -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 16448 invoked from network); 8 Oct 2003 10:26:30 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 8 Oct 2003 10:26:30 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1A7BVt-0001Vl-Rl; Wed, 08 Oct 2003 06:25:50 -0400 Date: Wed, 08 Oct 2003 10:26:00 -0000 Message-Id: From: Eli Zaretskii To: Orjan Friberg CC: gdb-patches@sources.redhat.com In-reply-to: <3F83CFD1.8010002@axis.com> (message from Orjan Friberg on Wed, 08 Oct 2003 10:50:25 +0200) Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT Reply-to: Eli Zaretskii References: <3F83CFD1.8010002@axis.com> X-SW-Source: 2003-10/txt/msg00202.txt.bz2 > Date: Wed, 08 Oct 2003 10:50:25 +0200 > From: Orjan Friberg > > The problem seems to be that target_stopped_data_address () is called in > bp_stop_status () *after* the single-step over the disabled breakpoint > has been carried out, at which point the target is no longer stopped due > to a hardware watchpoint (but due to the single-step). Consequently, > target_stopped_data_address () returns 0, and gdb thinks that the > watchpoint didn't hit. I can't see that any other targets keep the last > "stopped data address" until the next hardware watchpoint is hit (which > would make the address still available after the single-step). Perhaps none of the targets that support hardware read and access watchpoints define HAVE_NONSTEPPABLE_WATCHPOINT? 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.