Re: [RFC] Python Finish Breakpoints

[Phil Muldoon <pmuldoon at redhat dot com>]

Phil Muldoon <pmuldoon@redhat.com> writes:

> Kevin Pouget <kevin.pouget@gmail.com> writes:
>
>> Any feedback ... ?


> Overall I like the idea, but I am unsure of the implementation.  I don't
> want to unnecessarily bike-shed something before the maintainer have a
> had a look at it.

I talked with Tom about this on IRC (really we should have done it on
the list, but there things happen).  I'm sure Tom will also comment.
But some things came up that Tom mentioned, and we expanded on, that is
important enough to mention now, before you do anymore work.

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