From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13562 invoked by alias); 4 Dec 2001 12:09:33 -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 13517 invoked from network); 4 Dec 2001 12:09:29 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 4 Dec 2001 12:09:29 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id NAA08645; Tue, 4 Dec 2001 13:09:18 +0100 Message-Id: <4.2.0.58.20011204130817.01979d70@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 04 Dec 2001 04:09:00 -0000 To: Eli Zaretskii From: Pierre Muller Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets. Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <4.2.0.58.20011203101333.00acd588@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2001-12/txt/msg00089.txt.bz2 At 12:09 03/12/2001 , Eli Zaretskii a écrit: >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. That is not totally true, because i386_stopped_by_data_address is also used in STOPPED_BY_WATCHPOINT macro, which explains why I see that the code uses that function for normal watchpoints. But I agree that its called but not really used. >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. I now also managed to compile gdb for djgpp and understood why I do get different results for cygwin and djgpp targets: do to DLL loadings, the watchpoints are removed and reinserted at program startup (same goes for linux programs that use shared libs) and thus the correct starting state of the watchpoints are loaded again. On the contrary, this does never occur in djgpp target, so that this target keeps the wrong value of the end of the previous run. So I finally agree with Eli to say that there a two problems here. One relative to the fact that the watchpoint values are not correctly resetted when the program restarts. But also a second problem if i386_cleanup_dregs is not called, because the target is not supposed to reuse the debug register values of the previous run, and with the current implementation not calling the i386_cleanup_dregs will result in not explicitly setting the values of the debug registers in the next run... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99