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

[Eli Zaretskii <eliz@gnu.org>]

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