From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22549 invoked by alias); 29 Nov 2001 08:12:46 -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 22528 invoked from network); 29 Nov 2001 08:12:44 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 08:12:44 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id KAA11159; Thu, 29 Nov 2001 10:12:03 +0200 (IST) Date: Mon, 19 Nov 2001 08:29:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Christopher Faylor cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target. In-Reply-To: <20011128193011.GA6502@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00336.txt.bz2 On Wed, 28 Nov 2001, Christopher Faylor wrote: > It seems like the described behavior would be annoying indeed. It > would be nice to fix this. I second that. In my experience, having watchpoints fire when they shouldn't renders them almost unusable. A watchpoint is a kind of a ``silver bullet'': it is supposed to reveal bugs that cannot be reasonably caught by any other means, mainly when some code overwrites locations it shouldn't. They are also very useful when studying complex programs, when you want to find out which code modifies some variable. In both of these situations, if a watchpoint triggers when the variable isn't written, you cannot trust such a watchpoint, because you have no way of verifying independently whether the watchpoint should have triggered or not. (Comparing the old and new values is not a reliable way to find out whether the address was or wasn't written to.) So I'd suggest some more R&D here. For example, can anyone see if the debugger which comes with the Visual Studio does TRT with watchpoints? If it does, it means there is a way, albeit undocumented (so what else is new in Redmond-land?) to set a watchpoint and have it break on writes only. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Christopher Faylor Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target. Date: Thu, 29 Nov 2001 00:12:00 -0000 Message-ID: References: <20011128193011.GA6502@redhat.com> X-SW-Source: 2001-11/msg00551.html Message-ID: <20011129001200.Sxl1p4__vLukdH629L9_LbFs0O0Qbc_ogz6rcVlU9D4@z> On Wed, 28 Nov 2001, Christopher Faylor wrote: > It seems like the described behavior would be annoying indeed. It > would be nice to fix this. I second that. In my experience, having watchpoints fire when they shouldn't renders them almost unusable. A watchpoint is a kind of a ``silver bullet'': it is supposed to reveal bugs that cannot be reasonably caught by any other means, mainly when some code overwrites locations it shouldn't. They are also very useful when studying complex programs, when you want to find out which code modifies some variable. In both of these situations, if a watchpoint triggers when the variable isn't written, you cannot trust such a watchpoint, because you have no way of verifying independently whether the watchpoint should have triggered or not. (Comparing the old and new values is not a reliable way to find out whether the address was or wasn't written to.) So I'd suggest some more R&D here. For example, can anyone see if the debugger which comes with the Visual Studio does TRT with watchpoints? If it does, it means there is a way, albeit undocumented (so what else is new in Redmond-land?) to set a watchpoint and have it break on writes only.