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

[Doug Evans <xdje42@gmail.com>]

On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <palves@redhat.com> wrote:
> On 11/14/2013 08:53 PM, Tom Tromey wrote:
>>>>>>> "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.
>
> That does make sense.  In that scenario, it then sounds like it's
> best to think of the "stop" method more like a ops->check_status
> implementation/extension, than a breakpoint condition.

Need More Data.
In this scenario, when would one typically add a CLI condition to such
a Python interpreter breakpoint?

Plus if this is really a check_status thing then I wonder if
gdb.Breakpoint is going down the wrong path and we should be providing
a class where users can override breakpoint_ops.

>> 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.
>
> Yeah, it does sound like && is more useful.  To get "|", the user can
> set another breakpoint at the same address/whatever with a cli condition.

That's a good point.