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

[Doug Evans <dje@google.com>]

On Tue, Dec 14, 2010 at 9:28 AM, Tom Tromey <tromey@redhat.com> wrote:
> This patch addresses two bits of functionality we have needed in Python.
>
> First, we need a clean way to run some code at a given breakpoint
> location -- but with the caveats that the code always be run, regardless
> of other breakpoints, and that the code not interfere with stepping.
>
> By "clean" I just mean that we want it not to have user-visible effects
> other than the effects we intend.  Yes, we can do it using a python
> convenience function -- but the convenience function's name is visible
> and in a flat namespace.

The reference to convenience functions was *not* a serious attempt at
arguing against doing something.
It was just an off the cuff comment regarding hacky solutions.

> The use case for this is something like gdb-heap, where we want to
> install a breakpoint that collects some information but doesn't
> interfere with ordinary debugging.
>
>
> Second, we want a way to stop the inferior when such the data collection
> step decides.  Our use case here is a (to-be-written) mutex-tracking
> extension, that collects information about pthread locking and
> unlocking, and stops when a deadlock is detected.

Right.  These are the "existing needs" I was referring to.

> Doug> I realize the _p convention mightn't be sufficiently common to use in
> Doug> the Python API, but for example a better name might be stop_p.
> Doug> And then one would have another method (I don't have a good name for
> Doug> it ATM) to use to collect data.
> Doug> Setting aside name choices, I like that API better.
>
> Having two methods seems worse to me.  It is more complicated without
> any added benefits.

One thought I had was that maybe one might have a situation where it'd
be useful to run all the collect methods first, and then run all the
stop_p methods.
Plus I still like the API design of keeping data collection separate
from stop/don't-stop.

> First, both such methods will be called in the same place in gdb.  This
> is necessary to implement the needed features.  But then .. why call two
> methods when you can just call one?
>
> Second, consider the mutex-watching use case.  To implement this in the
> two-method case, you must have the data collector set a flag, which is
> then returned by the condition method.  Or ... just do all the work in
> the condition method -- which is where we are now.

Setting a flag seems hardly onerous.

But don't let my $0.02 cents get in the way ... btw ...
If you *really* want to go this route, go for it.

Btw, if some mutex-checker or whatever detected a condition that it
wanted to report to the user, IWBN to be able to throw an error that
some higher level construct could recognize and deal with.
Is a simple boolean result from stop_p (I'm only calling that for
clarity's sake) going to be sufficient?
[Heh.  And if one bkpt did throw an error in stop_p, one might have
wished one could have collected one's own data first. 1/2 :-)]