Testsuite recurse.exp: Leaving scope of watchpoint test fails

[Corinna Vinschen <vinschen at redhat dot com>]

Hi,

The test `recurse.exp' in testsuite/gdb.base checks in line 126ff.
if the watchpoint is correctly deleted after the scope of that
watchpoint is left:

        # Continue again.  We should have a watchpoint go out of scope now
        if [gdb_test "continue" \
            "Continuing.*\[Ww\]atchpoint.*deleted.*main \\(\\) .*" \
            "first instance watchpoint deleted when leaving scope"] then {
            gdb_suppress_tests;
        }

The test expects the testcase to be in function main() when
the scope of the watchpoint has been left.  That works wonderful
e.g. on a i686-pc-linux target:

    continue^M
    Continuing.^M
    ^M
    Watchpoint 2 deleted because the program has left the block in^M
    which its expression is valid.^M
    main () at /home/corinna/src/devo/gdb/testsuite/gdb.base/recurse.c:30^M
    30        return 0;^M
    (gdb) PASS: gdb.base/recurse.exp: first instance watchpoint deleted when leaving scope

but it doesn't work on some other systems (e.g., the target I'm just
working on):

    continue^M
    Continuing.^M
    ^M
    Watchpoint 2 deleted because the program has left the block in^M
    which its expression is valid.^M
    0x00008142 in recurse (a=-32676) at /home/corinna/src/devo/gdb/testsuite/gdb.base/recurse.c:21^M
    21      }^M
    (gdb) FAIL: gdb.base/recurse.exp: first instance watchpoint deleted when leaving scope

As you can see, the watchpoint has been correctly deleted but gdb
stops somewhere in the epilogue of the function instead of in main()
where the test expects gdb to be.

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.

The test that is failing 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, which you see
as the closing curly-brace.

What can we do in that situation?  As a short-term solution it
would make sense to change the test so that it passes when gdb
stops in the curly-brace line 21.

As long-term it would probably make more sense when gdb recognizes
that it's currently in the epilogue and steps further until the
function has been left.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com