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>
>> Date: Mon, 13 Dec 2010 13:50:36 +0000

>> +class.  The @code{gdb.Breakpoint} class can be sub-classed and, in
>> +particular, you may choose to implement the @code{evaluate} function.
>> +If this function is defined it will be called when the inferior reaches
>> +that breakpoint.
>
> Which "that breakpoint" are you talking about here?  Perhaps you meant
> this:
>
>   If this function is defined for a breakpoint, it will be called when
>   the inferior reaches that breakpoint.
>
> ?  If so, the text is clear, but then this interpretation doesn't seem
> to be consistent with the example you give.


I'm not sure what you mean here.  Given the example in the patch, you
can instantiate any number of those breakpoints.

So

+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)

And the other where you would have two dissimilar breakpoints at the same
location:

e.g,

+class MyBreakpoint2 (gdb.Breakpoint):
+      def evaluate (self):
+        inf_val = gdb.parse_and_eval("bar")
+        if inf_val == 5:
+          return True
+        return False

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

Does that help explain? I'm opening to wording it however makes the most
sense.


>> +@code{True}, the inferior will be stopped at the location of the
>> +breakpoint.  Otherwise if the function returns @code{False} the
>> +inferior will continue.
>
> Either "otherwise", or "if it returns False"; using both is redundant.

Ok, thanks.

>> +                         The @code{evaluate} function should not
>> +attempt to influence the state of the inferior (e.g., step) or
>> +otherwise alter its data.  
>
> 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.  At least to me.  This is all
well and good, but we cannot prevent the user from doing it; just tell
them it is very bad idea. ;)

>> +If there are multiple breakpoints at the same location with an
>> +@code{evaluate} function, each one will be called regardless of the
>> +return status of the previous.
>
> Do we have anything to say regarding the order of the calls?

I'm not sure, as there is no mention I could find in the manual
regarding the conditional evaluation order of breakpoints.  I believe
they are called in the order of creation.  Maybe Pedro knows.  But as
breakpoint ordering is not mentioned anywhere else, and as all the
evaluation functions at that location will be called regardless, I
decided not to mention it.

Cheers,

Phil