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

Phil Muldoon
2010-12-14T19:51:22Z

Tom Tromey <tromey@redhat.com> writes:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:

>
> Doug> And the name "evaluate" doesn't feel right either.
>
> I agree.

It's no problem to allow the implemented function to be called
"condition" or anything else.

> Doug> OTOH, it seems like Python-based breakpoints have two conditions
> Doug> now (or at least two kinds of conditions one has to think about).
> Doug> One set with the "condition" command and one from the "evaluate"
> Doug> API function. IWBN to have only one, at least conceptually.
> Doug> Maybe you could rename "evaluate" to "condition" (or some such, I
> Doug> realize there's already a "condition"), and have the default be to
> Doug> use the CLI condition.
>
> This would be fine with me as long as it meets all the goals above.

So let me be sure I understand correctly:

class MyBreakpoint (gdb.Breakpoint):
def condition (self):
inf_val = gdb.parse_and_eval("i")
if inf_val == 3:
return True
return False

foo = MyBreakpoint ("myfile.c:42")

Would be how we work with the new Python evaluation breakpoints.

And

bar = gdb.Breakpoint("myfile.c:42)

bar.condition = "i == 2"

Would be the old style. In this case "foo" would have had the "condition"
method executed three times (up until i == 2), always returning "False"
(IE, don't stop) before the "bar" condition of the other breakpoint
stopped the inferior with its condition.

In the case of a new style breakpoint having both a CLI .condition() AND
an implemented method (though I could never see why you would want to do
this), whichever of those methods told GDB not to stop would trump the
other. (GDB assumes in bpstat_stop_status that the breakpoint will stop
the inferior (other than special cases like moribund breakpoints) and it
is up to the breakpoint evaluation to say, "hey don't stop". So the
stop-bit is never set by the conditional stuff, just unset).

How does this sound?

Cheers

Phil