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

[Doug Evans <dje at google dot com>]

On Mon, Dec 13, 2010 at 5:50 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> 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.

Hi.
My $0.02 cents.

Collecting data in the "evaluate" function feels too hacky for
something we explicitly tell users is the published way to do this
kind of thing.
And the name "evaluate" doesn't feel right either.  What does it mean
to evaluate a breakpoint? [One might think it means to evaluate the
location of the breakpoint, e.g., since gdb tries to re-evaluate the
location when the binary changes.]
I realize the _p convention mightn't be sufficiently common to use in
the Python API, but for example a better name might be stop_p.
And then one would have another method (I don't have a good name for
it ATM) to use to collect data.
Setting aside name choices, I like that API better.

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

Not that this has to be done now, or ever, but I wonder how useful it
would be to allow CLI breakpoints to have commands that are executed
prior to evaluating the condition.  "continue", etc. would not be
allowed here, so it may be too awkward to implement.