Watchpoints with condition

Watchpoints with condition

[Vladimir Prus]

GDB presently allow a watchpoint to have a condition, and I wonder
what are the use-cases for that.

If anybody has used watchpoint in condition in practice when debugging
real problem (as opposed to just playing with gdb, or making up
possible uses), can he share why it was needed?

- Volodya

Re: Watchpoints with condition

[Daniel Jacobowitz]

On Fri, Nov 30, 2007 at 07:25:19PM +0300, Vladimir Prus wrote:
> 
> GDB presently allow a watchpoint to have a condition, and I wonder
> what are the use-cases for that.
> 
> If anybody has used watchpoint in condition in practice when debugging
> real problem (as opposed to just playing with gdb, or making up
> possible uses), can he share why it was needed?

I haven't, but here's a use case: if the condition is something you
couldn't set a watchpoint on or would take too many hardware resources
to watch.  E.g.

  set $name = "my_function"
  watch global_variable if strcmp (cfun->name, $name) == 0

-- 
Daniel Jacobowitz
CodeSourcery

Re: Watchpoints with condition

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Fri, 30 Nov 2007 19:25:19 +0300
> 
> 
> GDB presently allow a watchpoint to have a condition, and I wonder
> what are the use-cases for that.
> 
> If anybody has used watchpoint in condition in practice when debugging
> real problem (as opposed to just playing with gdb, or making up
> possible uses), can he share why it was needed?

I use it quite a lot.  The simplest use case is like this:

  (gdb) watch foo if foo == 1

This stops at the watchpoint only if the value written to the variable
is 1.  Imagine that you need to find who writes a specific value into
a variable that is otherwise written into a lot by legitimate code.

Re: Watchpoints with condition

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:
>> From: Vladimir Prus <vladimir@codesourcery.com>
>> Date: Fri, 30 Nov 2007 19:25:19 +0300
>> 
>> 
>> GDB presently allow a watchpoint to have a condition, and I wonder
>> what are the use-cases for that.
>> 
>> If anybody has used watchpoint in condition in practice when debugging
>> real problem (as opposed to just playing with gdb, or making up
>> possible uses), can he share why it was needed?
>
> I use it quite a lot.  The simplest use case is like this:
>
>   (gdb) watch foo if foo == 1

Isn't that equivalent to 'watch foo == 1'?

Re: Watchpoints with condition

[Daniel Jacobowitz]

On Fri, Nov 30, 2007 at 03:30:21PM -0800, Jim Blandy wrote:
> Isn't that equivalent to 'watch foo == 1'?

Not quite.

  watch foo == 1

stops when foo becomes 1 or non-1.

  watch foo if foo == 1

stops only when foo becomes 1.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Watchpoints with condition

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Fri, Nov 30, 2007 at 03:30:21PM -0800, Jim Blandy wrote:
>> Isn't that equivalent to 'watch foo == 1'?
>
> Not quite.
>
>   watch foo == 1
>
> stops when foo becomes 1 or non-1.
>
>   watch foo if foo == 1
>
> stops only when foo becomes 1.

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".

I think any time you have 'watch X if Y', and X is a subexpression of
Y, and Y is initially false, it's equivalent to 'watch Y != 0' (or
simply 'watch Y' if Y is a boolean expression).  X gets watched
automatically because it appears in Y, and the only time the
expression changes value is when it becomes true.

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.

Re: Watchpoints with condition

[Daniel Jacobowitz]

On Mon, Dec 03, 2007 at 09:54:41AM -0800, Jim Blandy wrote:
> 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.

No.  When foo goes back to zero, "watch foo == 1" stops.  "watch foo
if foo == 1" does not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Watchpoints with condition

[Eli Zaretskii]

> 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.)

Re: Watchpoints with condition

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:
>> 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.)

I don't want to believe you; I want to understand it for myself.  :)

What I understand Daniel to be saying is that 'watch X if Y' allows
you to restrict yourself to transitions into a certain state, whereas
any 'watch Y' will always report both transitions to and from the
state.

In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
Y'; etc. have worked for you?  You would have gotten more hits than
you'd like, but only twice as many --- is that right?

Re: Watchpoints with condition

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 03 Dec 2007 15:07:19 -0800
> 
> In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
> Y'; etc. have worked for you?  You would have gotten more hits than
> you'd like, but only twice as many --- is that right?

It would have shown me hits I don't want to see, yes.  And it is more
natural to write "watch X if X == 1" than what you suggest.

Re: Watchpoints with condition

[Michael Snyder]

On Tue, 2007-12-04 at 06:23 +0200, Eli Zaretskii wrote:
> > Cc: gdb@sourceware.org
> > From: Jim Blandy <jimb@codesourcery.com>
> > Date: Mon, 03 Dec 2007 15:07:19 -0800
> > 
> > In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
> > Y'; etc. have worked for you?  You would have gotten more hits than
> > you'd like, but only twice as many --- is that right?
> 
> It would have shown me hits I don't want to see, yes.  And it is more
> natural to write "watch X if X == 1" than what you suggest.

I have to agree -- typing "watch X == 1" is intuitive to you and me
(because we're gdb hackers), but it would not be intuitive to most
users.  Besides, as Eli says, it gives you unwanted hits.  Why would
we want to explain all of that (including the unwanted hits) to a
naive user?

Re: Watchpoints with condition

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> On Tue, 2007-12-04 at 06:23 +0200, Eli Zaretskii wrote:
>> > Cc: gdb@sourceware.org
>> > From: Jim Blandy <jimb@codesourcery.com>
>> > Date: Mon, 03 Dec 2007 15:07:19 -0800
>> > 
>> > In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
>> > Y'; etc. have worked for you?  You would have gotten more hits than
>> > you'd like, but only twice as many --- is that right?
>> 
>> It would have shown me hits I don't want to see, yes.  And it is more
>> natural to write "watch X if X == 1" than what you suggest.
>
> I have to agree -- typing "watch X == 1" is intuitive to you and me
> (because we're gdb hackers), but it would not be intuitive to most
> users.  Besides, as Eli says, it gives you unwanted hits.  Why would
> we want to explain all of that (including the unwanted hits) to a
> naive user?

I guess I don't see why 'GDB stops your program whenever the value of
this expression changes' is hard to understand.  Explaining
conditional watchpoints is a superset of explaining watchpoints, so I
don't see how it could be simpler.

*shrug*

Re: Watchpoints with condition

[Paul Koning]

>>>>> "Jim" == Jim Blandy <jimb@codesourcery.com> writes:

 Jim> Michael Snyder <msnyder at specifix.com> writes:
 >> On Tue, 2007-12-04 at 06:23 +0200, Eli Zaretskii wrote:
 >>> > Cc: gdb@sourceware.org > From: Jim Blandy
 >>> <jimb@codesourcery.com> > Date: Mon, 03 Dec 2007 15:07:19 -0800
 >>> > 
 >>> > In the use case you mention, why wouldn't 'watch v == X';
 >>> 'watch v == > Y'; etc. have worked for you?  You would have
 >>> gotten more hits than > you'd like, but only twice as many --- is
 >>> that right?
 >>> 
 >>> It would have shown me hits I don't want to see, yes.  And it is
 >>> more natural to write "watch X if X == 1" than what you suggest.
 >>  I have to agree -- typing "watch X == 1" is intuitive to you and
 >> me (because we're gdb hackers), but it would not be intuitive to
 >> most users.  Besides, as Eli says, it gives you unwanted hits.
 >> Why would we want to explain all of that (including the unwanted
 >> hits) to a naive user?

 Jim> I guess I don't see why 'GDB stops your program whenever the
 Jim> value of this expression changes' is hard to understand.
 Jim> Explaining conditional watchpoints is a superset of explaining
 Jim> watchpoints, so I don't see how it could be simpler.

The problem is that "watch xxx" stops whenever xxx is true" is an
obvious -- but wrong -- intuition of what the command does.

	paul

Re: Watchpoints with condition

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 04 Dec 2007 09:23:52 -0800
> 
> I guess I don't see why 'GDB stops your program whenever the value of
> this expression changes' is hard to understand.

Two reasons: (1) most people think watchpoints watch variables, not
expressions; and (2) the notion of "foo == 1" being an expression
whose value is either 1 or zero is natural only to C hackers.

> Explaining conditional watchpoints is a superset of explaining
> watchpoints, so I don't see how it could be simpler.

It is simpler because you still watch a simple variable, and the
condition is kept separately.  It is similar to

   x = y + (foo == 1);

vs

   if (foo == 1)
     x = y + 1;
   else
     x = y;

The latter shows what the code does more clearly (and in fact some
coding standards advise against the former style).

Re: Watchpoints with condition

[Michael Snyder]

On Tue, 2007-12-04 at 09:23 -0800, Jim Blandy wrote:
> Michael Snyder <msnyder at specifix.com> writes:
> > On Tue, 2007-12-04 at 06:23 +0200, Eli Zaretskii wrote:
> >> > Cc: gdb@sourceware.org
> >> > From: Jim Blandy <jimb@codesourcery.com>
> >> > Date: Mon, 03 Dec 2007 15:07:19 -0800
> >> > 
> >> > In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
> >> > Y'; etc. have worked for you?  You would have gotten more hits than
> >> > you'd like, but only twice as many --- is that right?
> >> 
> >> It would have shown me hits I don't want to see, yes.  And it is more
> >> natural to write "watch X if X == 1" than what you suggest.
> >
> > I have to agree -- typing "watch X == 1" is intuitive to you and me
> > (because we're gdb hackers), but it would not be intuitive to most
> > users.  Besides, as Eli says, it gives you unwanted hits.  Why would
> > we want to explain all of that (including the unwanted hits) to a
> > naive user?
> 
> I guess I don't see why 'GDB stops your program whenever the value of
> this expression changes' is hard to understand.  Explaining
> conditional watchpoints is a superset of explaining watchpoints, so I
> don't see how it could be simpler.

Well, since eliminating conditional watchpoints is not on the table, 
I guess it's a moot point, eh?

Re: Watchpoints with condition

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> On Tue, 2007-12-04 at 09:23 -0800, Jim Blandy wrote:
>> Michael Snyder <msnyder at specifix.com> writes:
>> > On Tue, 2007-12-04 at 06:23 +0200, Eli Zaretskii wrote:
>> >> > Cc: gdb@sourceware.org
>> >> > From: Jim Blandy <jimb@codesourcery.com>
>> >> > Date: Mon, 03 Dec 2007 15:07:19 -0800
>> >> > 
>> >> > In the use case you mention, why wouldn't 'watch v == X'; 'watch v ==
>> >> > Y'; etc. have worked for you?  You would have gotten more hits than
>> >> > you'd like, but only twice as many --- is that right?
>> >> 
>> >> It would have shown me hits I don't want to see, yes.  And it is more
>> >> natural to write "watch X if X == 1" than what you suggest.
>> >
>> > I have to agree -- typing "watch X == 1" is intuitive to you and me
>> > (because we're gdb hackers), but it would not be intuitive to most
>> > users.  Besides, as Eli says, it gives you unwanted hits.  Why would
>> > we want to explain all of that (including the unwanted hits) to a
>> > naive user?
>> 
>> I guess I don't see why 'GDB stops your program whenever the value of
>> this expression changes' is hard to understand.  Explaining
>> conditional watchpoints is a superset of explaining watchpoints, so I
>> don't see how it could be simpler.
>
> Well, since eliminating conditional watchpoints is not on the table, 
> I guess it's a moot point, eh?

Hey, I did shrug.  :)

Re: Watchpoints with condition

[Russell Shaw]

Vladimir Prus wrote:
> GDB presently allow a watchpoint to have a condition, and I wonder
> what are the use-cases for that.
> 
> If anybody has used watchpoint in condition in practice when debugging
> real problem (as opposed to just playing with gdb, or making up
> possible uses), can he share why it was needed?

I frequently need to enable or set a breakpoint only if another
previous point in the program has been passed. How do i do that?

Re: Watchpoints with condition

[Michael Snyder]

On Sat, 2007-12-01 at 12:10 +1100, Russell Shaw wrote:
> Vladimir Prus wrote:
> > GDB presently allow a watchpoint to have a condition, and I wonder
> > what are the use-cases for that.
> > 
> > If anybody has used watchpoint in condition in practice when debugging
> > real problem (as opposed to just playing with gdb, or making up
> > possible uses), can he share why it was needed?
> 
> I frequently need to enable or set a breakpoint only if another
> previous point in the program has been passed. How do i do that?


set $passed_milestone = 0
break milestone_func
commands
  silent
  set $passed_milestone = 1
end
break conditional_func if ($passed_milestone)

Re: Watchpoints with condition

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Cc: gdb@sources.redhat.com
> Date: Fri, 30 Nov 2007 17:32:51 -0800
> 
> > I frequently need to enable or set a breakpoint only if another
> > previous point in the program has been passed. How do i do that?
> 
> 
> set $passed_milestone = 0
> break milestone_func
> commands
>   silent
>   set $passed_milestone = 1
> end
> break conditional_func if ($passed_milestone)

Or just

  tbreak milestone_func
  commands
     silent
     break conditional_func
     continue
  end

Re: Watchpoints with condition

[Michael Snyder]

On Fri, 2007-11-30 at 19:25 +0300, Vladimir Prus wrote:
> GDB presently allow a watchpoint to have a condition, and I wonder
> what are the use-cases for that.
> 
> If anybody has used watchpoint in condition in practice when debugging
> real problem (as opposed to just playing with gdb, or making up
> possible uses), can he share why it was needed?


May I ask, what prompts the question?
Were you thinking of getting rid of it?

Re: Watchpoints with condition

[Vladimir Prus]

On Tuesday 04 December 2007 04:50:50 Michael Snyder wrote:
> On Fri, 2007-11-30 at 19:25 +0300, Vladimir Prus wrote:
> > GDB presently allow a watchpoint to have a condition, and I wonder
> > what are the use-cases for that.
> > 
> > If anybody has used watchpoint in condition in practice when debugging
> > real problem (as opposed to just playing with gdb, or making up
> > possible uses), can he share why it was needed?
> 
> 
> May I ask, what prompts the question?
> Were you thinking of getting rid of it?

I'm merely trying to understand the use cases. One of the specific
concern is what happens if a watchpoint's condition refers to a global
variable in a library that is unloaded and if that scenario is of
interest to anybody.

- Volodya

Re: Watchpoints with condition

[Michael Snyder]

On Tue, 2007-12-04 at 10:25 +0300, Vladimir Prus wrote:
> On Tuesday 04 December 2007 04:50:50 Michael Snyder wrote:
> > On Fri, 2007-11-30 at 19:25 +0300, Vladimir Prus wrote:
> > > GDB presently allow a watchpoint to have a condition, and I wonder
> > > what are the use-cases for that.
> > > 
> > > If anybody has used watchpoint in condition in practice when debugging
> > > real problem (as opposed to just playing with gdb, or making up
> > > possible uses), can he share why it was needed?
> > 
> > 
> > May I ask, what prompts the question?
> > Were you thinking of getting rid of it?
> 
> I'm merely trying to understand the use cases. One of the specific
> concern is what happens if a watchpoint's condition refers to a global
> variable in a library that is unloaded and if that scenario is of
> interest to anybody.

I see.  Thanks.

In terms of the specific scenario you describe, is that any
different from a conditional breakpoint that refers to a global
from an unloaded library?

My understanding (and I may be wrong) is that the conditional
is not evaluated until the breakpoint is hit.  Is it different
for a watchpoint?   Ah, wait, I think I see -- it's different
for a SOFTWARE watchpoint, isn't it?

Re: Watchpoints with condition

[Daniel Jacobowitz]

On Tue, Dec 04, 2007 at 02:34:28AM -0800, Michael Snyder wrote:
> My understanding (and I may be wrong) is that the conditional
> is not evaluated until the breakpoint is hit.  Is it different
> for a watchpoint?   Ah, wait, I think I see -- it's different
> for a SOFTWARE watchpoint, isn't it?

Shouldn't be, I don't think.  The watched value will be evaluated
every time, but the condition shouldn't be unless the watched value
changes.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Watchpoints with condition

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Tue, 4 Dec 2007 10:25:15 +0300
> Cc: gdb@sources.redhat.com
> 
> One of the specific concern is what happens if a watchpoint's
> condition refers to a global variable in a library that is unloaded
> and if that scenario is of interest to anybody.

That scenario is of interest, as it isn't different from a global
variable in `main'.  How code is divided between the main body and
shared libraries is immaterial.