public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Blandy <jimb@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: Watchpoints with condition
Date: Mon, 03 Dec 2007 20:59:00 -0000	[thread overview]
Message-ID: <uodd7ze86.fsf@gnu.org> (raw)
In-Reply-To: <m3odd74qam.fsf@codesourcery.com> (message from Jim Blandy on 	Mon, 03 Dec 2007 09:54:41 -0800)

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 03 Dec 2007 09:54:41 -0800
> 
> Okay, so 'watch foo if foo == 1' has some interesting behavior:
> - if foo is 1 when the watchpoint is set, then the watchpoint doesn't
>   trigger until foo becomes != 1, and then becomes 1 again.
> - If foo is != 1 when the watchpoint is set, then the command is
>   equivalent to watch foo == 1.
> 
> The first case seems really obscure; I assumed that wasn't what Eli
> was using conditional watchpoints for "quite a lot".

Right.  You can "set foo = something that is not 1", before starting
to watch like that.  But that's normally not a problem in real life,
because this use case is for catching writes of _rare_ values, not
frequent ones.

> I think the only valuable use case for conditional watchpoints is the
> one you mentioned, where Y is something expensive, and X is some
> cheaper conservative approximation to the condition we really want.

Well, you are wrong (and Daniel explained one reason why).  Believe
me, this use case is very useful and important.  (Actually, it was one
of the main reasons I got involved with fixing x86 hardware
watchpoints at the time: I needed to set several watchpoints on the
same variable, each one watching a different value being written.)

  parent reply	other threads:[~2007-12-03 20:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-30 16:25 Vladimir Prus
2007-11-30 16:37 ` Daniel Jacobowitz
2007-11-30 21:16 ` Eli Zaretskii
2007-11-30 23:30   ` Jim Blandy
2007-11-30 23:49     ` Daniel Jacobowitz
2007-12-03 17:54       ` Jim Blandy
2007-12-03 18:11         ` Daniel Jacobowitz
2007-12-03 20:59         ` Eli Zaretskii [this message]
2007-12-03 23:07           ` Jim Blandy
2007-12-04  4:23             ` Eli Zaretskii
2007-12-04  5:11               ` Michael Snyder
2007-12-04 17:24                 ` Jim Blandy
2007-12-04 17:30                   ` Paul Koning
2007-12-04 21:07                   ` Eli Zaretskii
2007-12-04 23:17                   ` Michael Snyder
2007-12-05 21:37                     ` Jim Blandy
2007-12-01  1:10 ` Russell Shaw
2007-12-01  1:46   ` Michael Snyder
2007-12-01  9:16     ` Eli Zaretskii
2007-12-04  2:04 ` Michael Snyder
2007-12-04  7:25   ` Vladimir Prus
2007-12-04 10:48     ` Michael Snyder
2007-12-04 14:07       ` Daniel Jacobowitz
2007-12-04 21:08     ` Eli Zaretskii

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=uodd7ze86.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=jimb@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).