Re: [RFC] Python Finish Breakpoints

Tom Tromey
2011-10-20T20:00:19Z

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> I would like to come back on this patch discussion, I know it has been
Kevin> a while since the last post (May 30th), but I was waiting for my
Kevin> copyright assignment to be ready, and then had to empty the patches
Kevin> already in the pipe.

Thanks for reopening this.
I'd like this functionality, in some form :), to go in.

Kevin> it appeared that the most stormy part was related to the
Kevin> FinishBreakpoint.out_of_scope() callback:

>> @defop Operation {gdb.Breakpoint} out_of_scope (self)
>> In some circonstances (eg, @code{longjmp}, C++ exceptions, @value{GDBN}
>> @code{return} command, ...), a function may not properly terminate, and thus
>> never hit a @{code} FinishBreakpoint. When @value{GDBN} notices such a
>> situation, the @code{out_of_scope} function will be triggered.

Kevin> I'll try a last time to convince you about its necessity, then I'll
Kevin> consider dropping it off !

Kevin> The main rational behind this callback is housekeeping: I'm building
Kevin> new functionalities on top of the Python interface, and I would like
Kevin> it to be invisible to the user (eg, when GDB performs a 'next/finish',
Kevin> you don't want to let the internal breakpoints in the inferior when
Kevin> the commands returns, in any situation.

Kevin> In the case of FinishBreakpoints, I would like to easily know if when
Kevin> the BP became meaningless (that is, the exec ran out of the scope
Kevin> where the FBP can be trigged) and time has come to remove it.
Kevin> Does it make sense?

I think a callback like this does make sense for finish breakpoints.
From looking back at the old thread, the problem I had was that I did
not understand the way that the callback was used, or the purpose of the
"out_of_scope_notif" attribute.

I'll send some notes on the latest version of the patch in a bit.

Tom