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

[Eli Zaretskii <eliz at gnu dot org>]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Date: Mon, 13 Dec 2010 13:50:36 +0000
> 
> 
> This patch allows Python breakpoints to be sub-classed and implements
> the "evaluate" function.  If the user defines an "evaluate" function in
> the Python breakpoint it will be called when GDB evaluates any
> conditions assigned to the breakpoint. This allows the user to write
> conditional breakpoints entirely in Python, and also allows the user to
> collect data at each breakpoint.  If the function returns True, GDB will
> stop the inferior at the breakpoint; if the function returns False
> the inferior will continue.

Thanks.

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

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

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

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