Re: [RFC] Python Finish Breakpoints

[Kevin Pouget <kevin.pouget@gmail.com>]

thanks for these useful feedbacks,
I will try to better understand what can be wrong/unusual with the
situations you described and prepare some tests to catch it.

But globally, my thoughts when I prepared this interface were that it
shouldn't be much different from a classic breakpoint. I'm not really
familiar with C++ mechanisms, but I can't see (right now, but I'll
investigate it) how it differs from setting a BP on the frame above,
checking for recursion upon BP hit and checking for the scope every
once in a while.

for instance, to talk about what I know
> What happens if a longjmp occurs?

nothing! obj->out_of_scope() will be triggered by
`observer_notify_stop' and the script will have the ability to
obj->delete() the breakpoint if it thinks it won't be useful anymore

> An exec?
nothing/the same as above, out_of_scope() will be triggered at the
next stop, I don't know off the top of my head what GDB does with BPs
on exec(), but the same would happen with FinishBreakpoint



I'll prepare the tests for all these situations and I'll see if it is
'at easy' as I thought

thanks,

Kevin

--

> There are questions arising on how these breakpoints cope when the
> inferior jumps unexpectedly.  I can think of two examples of this
> behavior during inferior function calls.
>
> * What happens with your breakpoint when you perform an inferior function
>  call on a C++ function, and that function raises an exception that is
>  normally and legally processed by an out-of-frame exception handler?
>  This question arises as it triggers special behavior in GDB.  The
>  problem originates from the dummy-frame created by GDB.  It insulates the
>  out-of-frame exception handler from the exception raising code, and
>  the default C++ handler terminates the inferior.  GDB detects this at
>  present, and rewinds the stack back to the original location before the
>  function call.  What happens, as in your example, if the breakpoint is
>  in this inferior function call?  This unwinding behavior related to a
>  C++ inferior is 'on' by default in GDB.
>
> * The other related example is what happens when a signal is delivered
>  to the inferior during the inferior function call?  Presently GDB will
>  stop with an error message.  However the user can turn unwinding 'on'
>  in this scenario too.  This signal handling unwinding is 'off' by
>  default.
>
> There are other scenarios and state changes to consider.  What happens if
> a longjmp occurs? An exec?
>
> So the behavior is subtle when dealing with inferior changes.  So to
> prove this new breakpoint type is robust, you would need to provide
> test-cases of this kind of proven behavior in your patch.
>
> Apologies to Tom is I misquoted or mis-phrased our conversation. ;)
>
> Cheers,
>
> Phil
>