Re: [RFC] Python Finish Breakpoints

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> The problem is that the finish-breakpoint mechanism sets a breakpoint on
Ulrich> the regular return address of the current frame, i.e. the instruction
Ulrich> where the "call" instruction would return normally.  However, when an
Ulrich> exception is thrown and then caught, execution continues at a different
Ulrich> call site (in the catch block).  There's now two possibilities:
[...]

I think the test is actually incorrect, and that if it passes, it is
only by accident.

The test assumes that the "finish" will cause the
ExceptionFinishBreakpoint to fire.  However, I don't think this
makes sense.  A Python "finish" breakpoint will only fire if the
"finish" returns normally; it might fire "accidentally" if the
exception lands at exactly the same spot.

So, I think either result -- a call to the stop method or a call to the
out_of_scope method -- is ok in this situation.

Ulrich> Am I missing some piece of GDB code that attempts to handle this, and
Ulrich> is just malfunctioning?  It would certainly be good to properly support
Ulrich> this feature, but until we do, I'd suggest this test case should be
Ulrich> disabled ...

We have support for "finish", and other operations in the presence of
exceptions.  Search for _Unwind_DebugHook (in breakpoint.c and infrun.c).
This code only works if you are using a new-enough version of GCC and
have debuginfo for libgcc (but once the stap probe patches are in, you
will no longer need debuginfo).

We could probably augment Python "finish" breakpoints to add a new
method that is called in the exception case.

Tom