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

[Pedro Alves <palves@redhat.com>]

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.

> 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.

-- 
Pedro Alves