Re: [patch] Add an evaluation function hook to Python breakpoints.

[Phil Muldoon <pmuldoon@redhat.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Phil Muldoon <pmuldoon@redhat.com>
>> Cc: gdb-patches@sourceware.org
>> Date: Mon, 13 Dec 2010 14:47:33 +0000
>> 
>> +class MyBreakpoint (gdb.Breakpoint):
>> +      def evaluate (self):
>> +        inf_val = gdb.parse_and_eval("foo")
>> +        if inf_val == 3:
>> +          return True
>> +        return False
>> 
>> There are two scenarios where the breakpoints would be executed.  The first
>> is where you would end up instantiating two instances of the above
>> breakpoint at the same location:
>> 
>> python bp1 = MyBreakPoint("myfile.c:42")
>> python bp2 = MyBreakpoint("myfile.c:42", internal=True)
>
> So I would rephrase the text in question like this:
>
>   If this function is defined in a sub-class of @code{gdb.Breakpoint},
>   it will be called when the inferior reaches any breakpoint which
>   instantiates that sub-class.

But only if the inferior has stopped at the location of that
breakpoint.  So given this case:

python bp1 = MyBreakPoint("myfile.c:42")
python bp2 = MyBreakpoint("myfile.c:45")

Those two are using the same sub-classed breakpoint but are at different
locations.  So if the inferior reached line 42, then only the evaluate
function of bp1 would be called.  The above scenario would happen, for
example, if the user was checking the state of a global variable.

In the previous example:

python bp1 = MyBreakPoint("myfile.c:42")
python bp2 = MyBreakpoint("myfile.c:42", internal=True)

The evaluate function would be called for both bp1 an bp2 as they are
both at the same location, and they both have evaluate functions
defined.  

Make sense?


>> > Sounds like a non-trivial limitation; is it really necessary?
>> 
>> I mentioned it as it was a non-trivial limitation? It is something the user
>> should not do in the evaluate function.  The most pressing reason is
>> that there may be other breakpoints to be checked at that location so
>> the state of the inferior should remain.  The other is it is just bad
>> business influencing the inferior position (i.e., stepping) when
>> breakpoint evaluation is being performed.
>
> We allow that from the CLI, FWIW.


>> This is all well and good, but we cannot prevent the user from doing
>> it; just tell them it is very bad idea. ;)
>
> But if there's only one breakpoint at that location, there doesn't
> seem to be any reasons to disallow this, right?

Aha, I did not know about the CLI version, (or more specifically the
fact that we do not make a mention that it may be unwise to start
tinkering with the state of the inferior.)  In retrospect I think you
are right; adding this text would confuse matters.  I have removed it
from the patch.

Cheers

Phil