From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17314 invoked by alias); 3 Dec 2001 09:33: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 17255 invoked from network); 3 Dec 2001 09:33:34 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 3 Dec 2001 09:33:34 -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 KAA19530; Mon, 3 Dec 2001 10:27:15 +0100 Message-Id: <4.2.0.58.20011203101333.00acd588@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 03 Dec 2001 01:33: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: <1858-Fri30Nov2001214802+0200-eliz@is.elta.co.il> References: <4.2.0.58.20011130165213.016940c0@ics.u-strasbg.fr> <4.2.0.58.20011130161336.01698ae8@ics.u-strasbg.fr> <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr> <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr> <4.2.0.58.20011130161336.01698ae8@ics.u-strasbg.fr> <4.2.0.58.20011130165213.016940c0@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/msg00030.txt.bz2 At 20:48 30/11/2001 , Eli Zaretskii a écrit: > > Date: Fri, 30 Nov 2001 17:04:58 +0100 > > From: Pierre Muller > > > > use the following command > > (top-gdb) watch gdb_stdout > > (top-gdb) r > > Here you should get a stop due to the setting of gdb_stdout value. > > (top-gdb) cont > > you should now reach the debuggee command prompt, > > simply quit. > > (gdb) quit > > and rerun the same executable without any watchpoint modification. > > (top-gdb) run > > if the bug that I found on both win32 (without i386_cleanup_deregs call) > > and on current (a few days old) CVS for linux. > > You won't get any stop on the second run. > >This has nothing to do with i386_cleanup_dregs or, indeed, the x86 >watchpoint support. Type "maintenance show-debug-regs", and you will >see that the watchpoint does trigger on the second run, but GDB >ignores it. It ignores the watchpoint because the old and the new >values compare equal on the second run, so GDB thinks it's a false >alarm. No, sorry, but I don't agree here: I retested with today CVS compiled for i386 linux . 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. The reason is that on the second run i386_linux_drset is not called again on the second run. And its not called again because in i386_insert_aligned_watchpoint the macros I386_DR_LOW_SET_ADDR (i, addr); I386_DR_LOW_SET_CONTROL (dr_control_mirror); are only called if the the debug register is used for the first time. 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. Thus the enabling of the hardware watchpoint only does increment dr_ref_count[0] (line 334) and no linux specifc functions are called. This is exactly the same behaviour as what I got before calling i386_cleanup_dregs for the cygwin target. >The reason that hardware watchpoints are only considered to fire when >the watched value changes is that hardware watchpoints are treated teh >same as software watchpoints, and software watchpoints obviously >cannot fire unless the watched value changes. > >I think it is fundamentally wrong to treat hardware and software >watchpoints in a similar way. I think hardware watchpoints should be >treated like read and access watchpoints, not like software >watchpoints. If others (mainly Michael Snyder) agree, I will submit a >patch that will make that change, and will also solve this particular >problem raised by Pierre. There may be different solutions to the problem above, but I think that in any case, we need to reset dr_mirror and dr_ref_count array at each new start. I believe that this would be enough to solve all current troubles. PS: A propos unwanted output of the cygwin target using debug registers, I find the same sort of unwanted output for the linux target, probably due to the removal/reinsertion of hardware watchpoints when loading dynamic libraries. 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