Re: [patch] [python] Implement stop_p for gdb.Breakpoint

[Tom Tromey <tromey@redhat.com>]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> - "consistency is good", so if we go with _p for stop_p we need to go
Doug> with _p for all predicates
Doug>   - are we prepared for that?
Doug>   - are there any existing predicates that don't have _p?
Doug>   - does python have an existing convention?
Doug>   [I used stop_p at the time for clarity's sake.  But I think these
Doug> questions need to be asked.]

I don't think we should use _p on predicates.  That is not a Python
convention.

I don't think Python actually does have a convention for this kind of
predicate.  I suggest we just pick a name that makes sense.

Doug> - I didn't see any tests for log-printf

I don't think log-printf is ready for submission.  It can either be a
separate patch later, or just not submitted.  I wrote it just to provide
a real-word test of one of the use cases for which this functionality is
intended.

Doug> - is the logic for deciding whether to stop correct?
Doug>   E.g. if stop_p says "don't stop" and a condition says "stop" will
Doug> execution continue?  It looks like it, but maybe I'm misunderstanding
Doug> something.

Phil> The case of the user having an old-style GDB condition, and an
Phil> implementation of a "stop_p" is an odd one. I was inclined to disallow
Phil> it, but eventually decided against it.  There will be conflict if stop_p
Phil> and condition disagree.  My first thoughts are "stop" should always
Phil> trump "don't stop". What do you think?

My view is that the conditions should be separate, and that if either
one indicates "stop", then the breakpoint should stop.

My reason is that the Python method is an implementation detail of some
kind of "stop point" provided by a Python script.  It is not readily
mutable by the user.  On the other hand, the condition is something
explicitly under the user's control.

If we really need to let the Python programmer prevent users from
setting a condition on one of these breakpoints, we can provide a
mechanism for doing that.

Doug> For things like this I like to start slow: "It's easier to relax
Doug> restrictions than it is to impose them after the fact."

Doug> So my vote would be to not support both in the first pass.  It
Doug> kinda makes intuitive sense too (to me anyway).  i.e. the default
Doug> implementation of "stop_p" uses the command-line condition, and if
Doug> overridden then uses the python-provided addition.

These two statements are contradictory.  Or, maybe I didn't understand
one of them.

If we unify stop_p and the user condition now, it will be hard to
separate them later -- because we will have documented that this is how
they work.

I think the most conservative approach is to make it an error for the
user to set a condition on a breakpoint that has a stop_p method, and
vice versa.  That preserves the ability to make a different decision
later.

Tom