From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31366 invoked by alias); 15 Nov 2013 05:35:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31350 invoked by uid 89); 15 Nov 2013 05:35:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-wi0-f171.google.com Received: from Unknown (HELO mail-wi0-f171.google.com) (209.85.212.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 05:34:40 +0000 Received: by mail-wi0-f171.google.com with SMTP id hn6so506388wib.4 for ; Thu, 14 Nov 2013 21:34:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.187.232 with SMTP id fv8mr430627wjc.56.1384493671648; Thu, 14 Nov 2013 21:34:31 -0800 (PST) Received: by 10.194.37.73 with HTTP; Thu, 14 Nov 2013 21:34:31 -0800 (PST) In-Reply-To: <52853D8A.5070908@redhat.com> References: <87bo1mwvqg.fsf@fleche.redhat.com> <52853D8A.5070908@redhat.com> Date: Fri, 15 Nov 2013 06:39:00 -0000 Message-ID: Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint From: Doug Evans To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org, pmuldoon@redhat.com, eliz@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00400.txt.bz2 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.