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

Eli Zaretskii
2010-12-13T15:07:51Z

> 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.

Does this describe correctly what will happen?

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

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?

Anyway, this is not really related to the manual; if the modified text
above is okay with you, the patch for the manual is approved.

Thanks.