[patch] relax test in gdb.base/commands.exp

[patch] relax test in gdb.base/commands.exp

[Randolph Chung]

The regexp below checked for a specific line number in the caller when
the watchpoint goes out of scope. On a target that emulates watchpoints
with single stepping i've seen that we get the "watchpoint deleted"
message when we're in the epilogue of a function. in this case the
current line number may still be in the called function. This patch
relaxes the line number checking a bit so we allow both cases (but not
any random line). Tested on hppa-linux. ok?

randolph



2004-11-22  Randolph Chung  <tausq@debian.org>

testsuite/
	* gdb.base/commands.exp (watchpoint_command_test): Relax line number 
	check to allow line number inside the called function.

Index: testsuite/gdb.base/commands.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/commands.exp,v
retrieving revision 1.13
diff -u -p -r1.13 commands.exp
--- testsuite/gdb.base/commands.exp	29 Sep 2003 15:08:52 -0000	1.13
+++ testsuite/gdb.base/commands.exp	22 Nov 2004 23:18:02 -0000
@@ -331,7 +331,7 @@ proc watchpoint_command_test {} {
     }
     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 $" {
+	-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"}
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch] relax test in gdb.base/commands.exp

[Daniel Jacobowitz]

On Mon, Nov 22, 2004 at 03:29:15PM -0800, Randolph Chung wrote:
> The regexp below checked for a specific line number in the caller when
> the watchpoint goes out of scope. On a target that emulates watchpoints
> with single stepping i've seen that we get the "watchpoint deleted"
> message when we're in the epilogue of a function. in this case the
> current line number may still be in the called function. This patch
> relaxes the line number checking a bit so we allow both cases (but not
> any random line). Tested on hppa-linux. ok?

Why do we get it in the epilogue?  Is it because the debug information
claims the variable has gone out of scope, or is it because of
faulty unwind information for the epilogue causing GDB to think the
frame has changed?

I know that GCC's epilogue unwind info is broken for all targets
(except maybe ia64).

If the former, then maybe your patch is correct.  If the latter, it
should probably be an XFAIL.

-- 
Daniel Jacobowitz

Re: [patch] relax test in gdb.base/commands.exp

[Randolph Chung]

> Why do we get it in the epilogue?  Is it because the debug information
> claims the variable has gone out of scope, or is it because of
> faulty unwind information for the epilogue causing GDB to think the
> frame has changed?

oh, probably the latter.....

inside the function, the backtrace shows:

(gdb) bt
#0  factorial (value=1) at ../../../gdb-cvs/gdb/testsuite/gdb.base/run.c:77
#1  0x00010584 in main (argc=1, argv=0xbff00220, envp=0xbff00228)
    at ../../../gdb-cvs/gdb/testsuite/gdb.base/run.c:57

but in the epilogue:
(gdb) bt
#0  0x00010624 in factorial (value=1)
    at ../../../gdb-cvs/gdb/testsuite/gdb.base/run.c:82
#1  0x403a146c in __libc_start_main () from /lib/libc.so.6
#2  0x00010480 in _start () at ../sysdeps/hppa/elf/start.S:67

> If the former, then maybe your patch is correct.  If the latter, it
> should probably be an XFAIL.

ok, i'll look into this some more.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch] relax test in gdb.base/commands.exp

[Randolph Chung]

> Why do we get it in the epilogue?  Is it because the debug information
> claims the variable has gone out of scope, or is it because of
> faulty unwind information for the epilogue causing GDB to think the
> frame has changed?

hmmm.. i just saw this comment in recurse.exp, which is the same as what
i observed:

        # The former version expected the test to return to main().
        # Now it expects the test to return to main or to stop in the
        # function's epilogue.
        #
        # The problem is that gdb needs to (but doesn't) understand
        # function epilogues in the same way as for prologues.
        #
        # If there is no hardware watchpoint (such as a x86 debug register),
        # then watchpoints are done "the hard way" by single-stepping the
        # target until the value of the watched variable changes.  If you
        # are single-stepping, you will eventually step into an epilogue.
        # When you do that, the "top" stack frame may become partially
        # deconstructed (as when you pop the frame pointer, for instance),
        # and from that point on, GDB can no longer make sense of the stack.
        #
        # A test which stops in the epilogue is trying to determine when GDB
        # leaves the stack frame in which the watchpoint was created.  It does
        # this basically by watching for the frame pointer to change.  When
        # the frame pointer changes, the test expects to be back in main, but
        # instead it is still in the epilogue of the callee.


in the code, i actually see some logic to handle this case:

      /* in_function_epilogue_p() returns a non-zero value if we're still
         in the function but the stack frame has already been invalidated.
         Since we can't rely on the values of local variables after the
         stack has been destroyed, we are treating the watchpoint in that
         state as `not changed' without further checking.

         vinschen/2003-09-04: The former implementation left out the case
         that the watchpoint frame couldn't be found by frame_find_by_id()
         because the current PC is currently in an epilogue.  Calling
         gdbarch_in_function_epilogue_p() also when fr == NULL fixes that. */
      if ((!within_current_scope || fr == get_current_frame ())
          && gdbarch_in_function_epilogue_p (current_gdbarch, read_pc ()))
        return WP_VALUE_NOT_CHANGED;

so possibly all i need is to define a function_epilogue_p predicate for
the hppa target. does this mean that recurse.exp should change as well?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/