This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] improve python finish breakpoint for exceptions/longjmp case.
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)
>> 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,