From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: muller@cerbere.u-strasbg.fr Cc: kettenis@science.uva.nl, gdb-patches@sources.redhat.com Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets. Date: Fri, 30 Nov 2001 11:48:00 -0000 Message-id: <1858-Fri30Nov2001214802+0200-eliz@is.elta.co.il> References: <4.2.0.58.20011130161336.01698ae8@ics.u-strasbg.fr> <4.2.0.58.20011121124943.00a4a288@ics.u-strasbg.fr> <4.2.0.58.20011130165213.016940c0@ics.u-strasbg.fr> X-SW-Source: 2001-11/msg00627.html > 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. 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2914 invoked by alias); 30 Nov 2001 19:48:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2719 invoked from network); 30 Nov 2001 19:48:49 -0000 Received: from unknown (HELO odin.inter.net.il) (192.114.186.10) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 19:48:49 -0000 Received: from zaretsky ([192.116.55.139]) by odin.inter.net.il (Mirapoint) with ESMTP id ACJ93470; Fri, 30 Nov 2001 21:48:36 +0200 (IST) Date: Fri, 23 Nov 2001 06:39:00 -0000 From: "Eli Zaretskii" To: muller@cerbere.u-strasbg.fr Message-ID: <1858-Fri30Nov2001214802+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: kettenis@science.uva.nl, gdb-patches@sources.redhat.com In-reply-to: <4.2.0.58.20011130165213.016940c0@ics.u-strasbg.fr> (message from Pierre Muller on Fri, 30 Nov 2001 17:04:58 +0100) Subject: Re: [RFC] Possible bug with i386 watchpoints on several targets. Reply-to: Eli Zaretskii References: <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> X-SW-Source: 2001-11/txt/msg00412.txt.bz2 Message-ID: <20011123063900.pCwEggPXKJdSqqSm_5l3Nixb87bS-je1xVCDQyuUoHI@z> > 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. 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.