Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Michael Elizabeth Chastain]

Andrew Cagney writes:

> ... so there may not necessarily be a frame change.

Right.

> However, if the frame has gone (or is being destroyed) the variable
> is out of scope.

The problem is with the recursive case, where there are several frames
which map to the same line numbers, and several instances of the variable.
gdb could have bugs where it creates a watchpoint for one of these frames,
but then deletes it when an inferior frame exits.  With this patch,
the test suite wouldn't detect such a bug.

Michael C

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Michael Snyder]

Michael Elizabeth Chastain wrote:
> 
> Andrew Cagney writes:
> 
> > ... so there may not necessarily be a frame change.
> 
> Right.
> 
> > However, if the frame has gone (or is being destroyed) the variable
> > is out of scope.
> 
> The problem is with the recursive case, where there are several frames
> which map to the same line numbers, and several instances of the variable.
> gdb could have bugs where it creates a watchpoint for one of these frames,
> but then deletes it when an inferior frame exits.  With this patch,
> the test suite wouldn't detect such a bug.

Right, I agree.

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Michael Elizabeth Chastain]

Michael Snyder writes:
> I think this is a good idea (hmm... didn't somebody else recently 
> submit this same change, with a different implementation?)
> I get bitten by this testsuite glitch all the time.
> My only concern is, can this cause us to miss an actual bug?
> Such as if this (watchpoint out of scope event) were to trigger
> in, say, the wrong frame of the recursive call?

Yes, I think it would cause the test to miss this kind of bug:

  main() calls foo()
  user sets watchpoint in foo()
  foo() calls foo()
  foo() returns
  gdb deletes watchpoint (which belonged to first foo)

gdb.texinfo says:

  @value{GDBN} automatically deletes watchpoints that watch local
  (automatic) variables, or expressions that involve such variables, when
  they go out of scope, that is, when the execution leaves the block in
  which these variables were defined.

I interpret "go out of scope" to be talking about stack frames,
but it's likely that gdb can have bugs where it's checking for scope
by looking at line numbers.

So actually I think that the right result for this use case is
UNRESOLVED, which means that a human has to look at it each time.

So I don't recommend this patch as is.

How about this: enhance watchpoint_command_test to be two tests,
one non-recursive, and one recursive.  Then the non-recursive one
will be simple non-controversial and it can PASS on either the last
line of the callee or the next line of the caller.  The recursive
one will be trickier, it will have to look at the value of some
recursion variable to make sure that it is in the correct scope.

Michael C

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Andrew Cagney]

> gdb.texinfo says:
> 
>   @value{GDBN} automatically deletes watchpoints that watch local
>   (automatic) variables, or expressions that involve such variables, when
>   they go out of scope, that is, when the execution leaves the block in
>   which these variables were defined.
> 
> I interpret "go out of scope" to be talking about stack frames,
> but it's likely that gdb can have bugs where it's checking for scope
> by looking at line numbers.

FYI,  out of scope includes:

foo ()
{
    int bar;

    ....
    {
       int bar;
       .... <watch bar>
    }

}

so there may not necessarily be a frame change.  However, if the frame 
has gone (or is being destroyed) the variable is out of scope.

> So actually I think that the right result for this use case is
> UNRESOLVED, which means that a human has to look at it each time.
> 
> So I don't recommend this patch as is.
> 
> How about this: enhance watchpoint_command_test to be two tests,
> one non-recursive, and one recursive.  Then the non-recursive one
> will be simple non-controversial and it can PASS on either the last
> line of the callee or the next line of the caller.  The recursive
> one will be trickier, it will have to look at the value of some
> recursion variable to make sure that it is in the correct scope.
> 
> Michael C

Andrew

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Eli Zaretskii]

On Thu, 2 May 2002, Michael Elizabeth Chastain wrote:

> gdb.texinfo says:
> 
>   @value{GDBN} automatically deletes watchpoints that watch local
>   (automatic) variables, or expressions that involve such variables, when
>   they go out of scope, that is, when the execution leaves the block in
>   which these variables were defined.

Btw, I think this is a misfeature: GDB should disable the watchpoints, 
but not delete them.

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Michael Snyder]

Eli Zaretskii wrote:
> 
> On Thu, 2 May 2002, Michael Elizabeth Chastain wrote:
> 
> > gdb.texinfo says:
> >
> >   @value{GDBN} automatically deletes watchpoints that watch local
> >   (automatic) variables, or expressions that involve such variables, when
> >   they go out of scope, that is, when the execution leaves the block in
> >   which these variables were defined.
> 
> Btw, I think this is a misfeature: GDB should disable the watchpoints,
> but not delete them.

Hmmm... I thought that was (effectively) what happened.
I know there's an invisible "out of scope" breakpoint sometimes, 
and I thought it was that breakpoint that was deleted, not the
watchpoint itself.  Was I wrong?

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Eli Zaretskii]

> Date: Thu, 02 May 2002 11:07:18 -0700
> From: Michael Snyder <msnyder@redhat.com>
> > 
> > Btw, I think this is a misfeature: GDB should disable the watchpoints,
> > but not delete them.
> 
> Hmmm... I thought that was (effectively) what happened.
> I know there's an invisible "out of scope" breakpoint sometimes, 
> and I thought it was that breakpoint that was deleted, not the
> watchpoint itself.  Was I wrong?

It looks like that.  Try this:

  - write a simple program whose `main' assigns a value to a variable;

  - run the program to the entry to `main', then set a hardware
    watchpoint to watch that variable;

  - continue the program, and when the watchpoint is hit, continue it
    again;

  - when `main' is exited, GDB says the watchpoint was deleted;

  - try "info watchpoints" -- you won't see the watchpoint;

  - try rerunning the program -- the watchpoint won't be hit.

So my conclusion is that the watchpoint is really deleted, not just
disabled and/or made invisible.  For watchpoints which are hard to
set up (perhaps for some complicated expression or with complex
conditions), that is a nuisance.

[RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Fred Fish]

This patch fixes the following problem.

  57c57
  < FAIL: gdb.base/commands.exp: continue with watch
  ---
  > PASS: gdb.base/commands.exp: continue with watch

-Fred


2002-05-01  Fred Fish  <fnf@redhat.com>

	* gdb.base/commands.exp (watchpoint_command_test): Allow the
	watchpoint to go out of scope on either the last line of the
	factorial function or the location returned to in the caller.
	Add comment describing rationale for this change.

Index: gdb.base/commands.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/commands.exp,v
retrieving revision 1.10
diff -c -p -r1.10 commands.exp
*** gdb.base/commands.exp	13 Dec 2001 22:42:23 -0000	1.10
--- gdb.base/commands.exp	1 May 2002 23:43:56 -0000
*************** proc watchpoint_command_test {} {
*** 330,337 ****
  	timeout               {fail "(timeout) end commands on watch"}
      }
      send_gdb "continue\n"
      gdb_expect {
! 	-re "Continuing.*\[Ww\]atchpoint $wp_id deleted because the program has left the block in.*which its expression is valid.*run.c:57.*$gdb_prompt $" {
  	    pass "continue with watch"
  	}
  	-re "$gdb_prompt $"   {fail "continue with watch"}
--- 330,345 ----
  	timeout               {fail "(timeout) end commands on watch"}
      }
      send_gdb "continue\n"
+     # Note that when watchpoints are implemented by software single
+     # stepping the inferior and evaluating the watchpoint at each
+     # step, local_var can go out of scope while we are in the function
+     # epilogue, such as when executing an instruction that restores the
+     # frame pointer to the callee value when local_var is accessed
+     # relative to the frame pointer.  Thus the watchpoint may be
+     # deleted while we are still in the block for factorial, in the
+     # code corresponding to the closing brace.
      gdb_expect {
! 	-re "Continuing.*\[Ww\]atchpoint $wp_id deleted because the program has left the block in.*which its expression is valid.*run.c:(57|82).*$gdb_prompt $" {
  	    pass "continue with watch"
  	}
  	-re "$gdb_prompt $"   {fail "continue with watch"}

Re: [RFA] Fix problem with watchpoint test in gdb.base/commands.exp

[Michael Snyder]

Fred Fish wrote:
> 
> This patch fixes the following problem.
> 
>   57c57
>   < FAIL: gdb.base/commands.exp: continue with watch
>   ---
>   > PASS: gdb.base/commands.exp: continue with watch
> 
> -Fred

I think this is a good idea (hmm... didn't somebody else recently 
submit this same change, with a different implementation?)
I get bitten by this testsuite glitch all the time.
My only concern is, can this cause us to miss an actual bug?
Such as if this (watchpoint out of scope event) were to trigger
in, say, the wrong frame of the recursive call?


> 2002-05-01  Fred Fish  <fnf@redhat.com>
> 
>         * gdb.base/commands.exp (watchpoint_command_test): Allow the
>         watchpoint to go out of scope on either the last line of the
>         factorial function or the location returned to in the caller.
>         Add comment describing rationale for this change.
> 
> Index: gdb.base/commands.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/commands.exp,v
> retrieving revision 1.10
> diff -c -p -r1.10 commands.exp
> *** gdb.base/commands.exp       13 Dec 2001 22:42:23 -0000      1.10
> --- gdb.base/commands.exp       1 May 2002 23:43:56 -0000
> *************** proc watchpoint_command_test {} {
> *** 330,337 ****
>         timeout               {fail "(timeout) end commands on watch"}
>       }
>       send_gdb "continue\n"
>       gdb_expect {
> !       -re "Continuing.*\[Ww\]atchpoint $wp_id deleted because the program has left the block in.*which its expression is valid.*run.c:57.*$gdb_prompt $" {
>             pass "continue with watch"
>         }
>         -re "$gdb_prompt $"   {fail "continue with watch"}
> --- 330,345 ----
>         timeout               {fail "(timeout) end commands on watch"}
>       }
>       send_gdb "continue\n"
> +     # Note that when watchpoints are implemented by software single
> +     # stepping the inferior and evaluating the watchpoint at each
> +     # step, local_var can go out of scope while we are in the function
> +     # epilogue, such as when executing an instruction that restores the
> +     # frame pointer to the callee value when local_var is accessed
> +     # relative to the frame pointer.  Thus the watchpoint may be
> +     # deleted while we are still in the block for factorial, in the
> +     # code corresponding to the closing brace.
>       gdb_expect {
> !       -re "Continuing.*\[Ww\]atchpoint $wp_id deleted because the program has left the block in.*which its expression is valid.*run.c:(57|82).*$gdb_prompt $" {
>             pass "continue with watch"
>         }
>         -re "$gdb_prompt $"   {fail "continue with watch"}