This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint
- From: Doug Evans <xdje42 at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org, pmuldoon at redhat dot com, eliz at gnu dot org
- Date: Thu, 14 Nov 2013 21:34:31 -0800
- Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint
- Authentication-results: sourceware.org; auth=none
- References: <m3siv0q29h dot fsf at seba dot sebabeach dot org> <m3k3gaq3gw dot fsf at seba dot sebabeach dot org> <87bo1mwvqg dot fsf at fleche dot redhat dot com> <52853D8A dot 5070908 at redhat dot 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.