Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> +A breakpoint may have both a normal breakpoint condition
Doug> +(@pxref{Conditions, ,Break Conditions}) and a Python
Doug> +@code{gdb.Breakpoint.stop} condition.
Doug> +Both will be evaluated and if either return @code{True} then the
Doug> +inferior will be stopped, otherwise the inferior will continue.

I'm not certain that these are the best semantics.

A motivating case for the Python "stop" method was to be able to let
Python authors write new kinds of breakpoints.

Say, for example, one wanted a breakpoint that triggered based on a
Python source file and line.  One could implement this by putting a
breakpoint in the Python interpreter with a suitable "stop" method.

In order for this to make sense, all the non-matching calls in the
interpreter must be discarded.  That is, stop returns false.

In this scenario, your proposed patch would go on to evaluate the
condition and perhaps break anyway.  But this violates the whole idea of
the new breakpoint.  Here, the CLI condition would most usefully be an
additional condition -- not a parallel one.


This particular example would be better with some other additions to the
gdb breakpoint API; and maybe those would obviate the need for this dual
purposing.  But since we don't have those additions, it remains unclear
to me that "|" is better than "&&" here.

Tom