From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10068 invoked by alias); 3 Dec 2001 11:10:41 -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 10001 invoked from network); 3 Dec 2001 11:10:38 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by sources.redhat.com with SMTP; 3 Dec 2001 11:10:38 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id NAA16767; Mon, 3 Dec 2001 13:09:50 +0200 (IST) Date: Mon, 03 Dec 2001 03:10:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Pierre Muller cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets. In-Reply-To: <4.2.0.58.20011203101333.00acd588@ics.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg00033.txt.bz2 On Mon, 3 Dec 2001, Pierre Muller wrote: > Of course i386_stopped_data_address gets called, but if you > set a breakpoint on the end of this function and add the condition > ' cond X ret != 0' > Then you will clearly see that the behavior is wrong: > only on the first run after setting a hardware watchpoint you will get > a non zero return value for this watchpoint. i386_stopped_data_address has no role when a write-data hardware watchpoint is hit, only when read or access watchpoints are hit. At least that's my reading of the code and what I see tracing through execution. See breakpoint.c:bpstat_stop_status, you will see there that hardware watchpoints and rwatch/awatch watchpoints are treated differently, and i386_stopped_data_address (called via the target_stopped_data_address macro) is only called for awatch/rwatch. The important function for hardware watchpoints is watchpoint_check, not i386_stopped_data_address. > As the i386_cleanup_dregs is never called for linux target, > the internal state of the dr_mirror and dr_ref_count > is wrong on the second start. > dr_mirror[0] still contains the hardware watchpoint address > and dr_ref_count contains one. Then please explain why does the DJGPP port exhibits the same behavior as the Linux port with the test program you posted. go32-nat.c _does_ call i386_cleanup_dregs, but the watchpoint doesn't trigger on the second run.