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

[Randolph Chung <randolph at tausq dot org>]

> 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/