1998-09-08 Jason Molenda (jsm@bugshack.cygnus.com)
authorJason Molenda <jmolenda@apple.com>
Wed, 9 Sep 1998 04:16:53 +0000 (04:16 +0000)
committerJason Molenda <jmolenda@apple.com>
Wed, 9 Sep 1998 04:16:53 +0000 (04:16 +0000)
commitfc4109089c227d1aaa33d4f7fe51be5d6f5fdf54
tree5f762f1f30311ab12e1c12d704df1dc8f2104ec3
parent1f926de145e7fd8211c58e4ae9d08916c16657e4
1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)

        * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
        current fp matches the bp->fp OR if the current fp is less than
        the bp->fp if we're looking at a bp_step_resume breakpoint.

PR 15992.

With a bp_step_resume type breakpoint, the frame pointer check exists in
case we recurse and execute the same text section--we want to not stop
there because it would confuse the user.  So gdb checks to see that the
frame pointer matches the one recorded in the breakpoint.

If the current frame pointer is less than the frame pointer recorded in
the breakpoint, then something odd is happened and we should declare that
we're at the breakpoint so that we clear it out.

This happens in Purify instrumented executables on PA systems, at least.
They insert some calls out to Purify code in the function epilogue and
it confuses GDB (which assumes that the frame pointer does not move
around through the entire execution of a function).
gdb/ChangeLog