Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] Add hardware watchpoint support for cygwin target.
Date: Mon, 19 Nov 2001 08:29:00 -0000	[thread overview]
Message-ID: <Pine.SUN.3.91.1011129101134.10998E-100000@is> (raw)
In-Reply-To: <20011128193011.GA6502@redhat.com>


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.


WARNING: multiple messages have this Message-ID
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Christopher Faylor <cgf@redhat.com>
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	[thread overview]
Message-ID: <Pine.SUN.3.91.1011129101134.10998E-100000@is> (raw)
Message-ID: <20011129001200.Sxl1p4__vLukdH629L9_LbFs0O0Qbc_ogz6rcVlU9D4@z> (raw)
In-Reply-To: <20011128193011.GA6502@redhat.com>

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.


  parent reply	other threads:[~2001-11-29  8:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-17 10:47 Pierre Muller
2001-11-28  9:44 ` Pierre Muller
2001-11-28 10:13 ` Eli Zaretskii
2001-11-17 16:07   ` Eli Zaretskii
2001-11-17 20:21   ` Christopher Faylor
2001-11-17 22:30     ` muller
2001-11-17 23:01       ` Christopher Faylor
2001-11-28 17:27         ` Christopher Faylor
2001-11-28 14:31       ` muller
2001-11-19  8:29     ` Eli Zaretskii [this message]
2001-11-21 15:15       ` Pierre Muller
2001-11-21 23:08         ` Christopher Faylor
2001-11-30  9:04           ` Christopher Faylor
2001-11-30  7:11         ` Pierre Muller
2001-11-29  0:12       ` Eli Zaretskii
2001-11-29  0:26       ` Pierre Muller
2001-11-19 11:30         ` Pierre Muller
2001-11-28 11:30     ` Christopher Faylor
2001-12-06  0:37     ` Pierre Muller
2001-12-06 13:30       ` Andrew Cagney
2001-12-07 16:59       ` Christopher Faylor
2001-12-10  2:23         ` Pierre Muller
2001-12-10 11:33           ` Christopher Faylor
2001-12-11  0:15             ` Eli Zaretskii
2001-12-11  1:04               ` Pierre Muller
2001-11-28 13:55   ` muller
2001-11-17 21:08     ` muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SUN.3.91.1011129101134.10998E-100000@is \
    --to=eliz@is.elta.co.il \
    --cc=cgf@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox