Re: [PATCH] improve python finish breakpoint for exceptions/longjmp case.

["Andrew Burgess" <aburgess@broadcom.com>]

On 17/10/2012 5:27 PM, Jan Kratochvil wrote:

> On Mon, 15 Oct 2012 22:39:52 +0200, Andrew Burgess wrote:
>> @@ -295,11 +304,18 @@ bpfinishpy_init (PyObject *self, PyObject *args, PyObject *kwargs)
>>                           AUTO_BOOLEAN_TRUE,
>>                           &bkpt_breakpoint_ops,
>>                           0, 1, internal_bp, 0);
>> +      set_longjmp_breakpoint (inferior_thread (), null_frame_id);
> 
> I find too intrusive to call set_longjmp_breakpoint here.
> 
> A countercase - I did not try to reproduce it in real:
> 
>  * You have breakpoint installed at TRACEDFUNC and you automatically use
>    Python finish breakpoint to trace return values of TRACEDFUNC.
>  * User at CALLERFUNC will type in GDB CLI "finish".
>  * CALLERFUNC does a lot of processing and it also calls TRACEDFUNC.
>  * Now you overwide tp->INITIATING_FRAME of the user "finish" command by
>    null_frame_id which breaks the behavior in some way.

I don't think this is a problem, the first finish will be cancelled when
we stop for the second time in TRACEDFUNC. So, I think the chain of
events will be:

 - Stop in TRACEDFUNC, create a finish breakpoint setting
tp->INITIATING_FRAME to null_frame_id.
 - From the cli use "finish" command, change tp->INITIATING_FRAME.
 - User continues.
 - Recursively enter TRACEDFUNC, stopping.  The finish breakpoint is now
cancelled.  At this point the first finish breakpoint is also cancelled,
but this is a known bug at this point that I plan to work on later; and
is no worse than current behaviour.
 - User creates new finish breakpoint, setting tp->INITIATING_FRAME, but
that's fine as we have no "finish" in play at this point.

Let me know if I've got this wrong and you can see a problem, especially
if you think I've broken /other/ commands, that would be worse than just
leaving the finish breakpoint stuff with a few broken edge cases.

> You want to install the "longjmp breakpoint" there by
> set_longjmp_breakpoint_for_call_dummy.  You want to hook there
> check_longjmp_breakpoint_for_call_dummy to call bpfinishpy_detect_out_scope_cb
> in some way.  Currently you do it on stop but that is too late, breakpoint may
> may have been for example placed at stack trampoline function (code at the
> stack) and the breakpoint instruction now corrupts live stack data there.

Hmmm, I see the problem, I'll work on that one.


Thanks for your time,
Andrew