This is the mail archive of the
mailing list for the GDB project.
Re: [RFC/RFA] Add hardware watchpoint support for cygwin target.
- From: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- To: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 29 Nov 2001 09:26:23 +0100
- Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target.
- References: <20011128193011.GA6502@redhat.com>
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
>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
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.
Institut Charles Sadron
F 67083 STRASBOURG CEDEX (France)
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99