This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves <> wrote:
> On 11/14/2013 08:53 PM, Tom Tromey wrote:
>>>>>>> "Doug" == Doug Evans <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]