From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26934 invoked by alias); 29 Nov 2001 08:26:19 -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 26899 invoked from network); 29 Nov 2001 08:26:17 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 08:26:17 -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 JAA16356; Thu, 29 Nov 2001 09:26:07 +0100 Message-ID: <4.2.0.58.20011129091702.00a40cc8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Nov 2001 11:30:00 -0000 To: Eli Zaretskii From: Pierre Muller Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target. Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <20011128193011.GA6502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2001-11/txt/msg00338.txt.bz2 Message-ID: <20011119113000.P3RwvX3MJsHgY0J5JpxCaTFcUITFvs2rw1hbDHEM9w8@z> At 09:12 29/11/2001 , Eli Zaretskii a écrit: >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. I think that I was not clear enough: Setting a watchpoint on cygwin target with my patch does NOT generate any unwanted stop. But it does generate unwanted output. This ouptut is generated by DLL_LOAD events. The problem that this load event does call new_symfile_objfile function, that does call breakpoint_re_set that finally calls breakpoint_re_set_one for each enabled break or watch point. But breakpoint_re_set_one systematically calls mention which in turn generates the unwanted uotput. >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. As I said above, my first conclusions were wrong, debug register generates exceptions only for write instructions if a "normal" watchpoint is set. I was just misled by the fact that I saw several Hardware watchpoint: string_of_the_expression_that_I_was_watching that appeared at the loading of the executable. There are no false debug stops, there are only unwanted gdb output generated by DDL LOAD events. 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