From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18328 invoked by alias); 14 Nov 2013 20:53:59 -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 18315 invoked by uid 89); 14 Nov 2013 20:53:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_20,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Nov 2013 20:53:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAEKrj04030476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 15:53:46 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAEKrioP022202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Nov 2013 15:53:44 -0500 From: Tom Tromey To: Doug Evans Cc: gdb-patches@sourceware.org, pmuldoon@redhat.com, palves@redhat.com, eliz@gnu.org Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint References: Date: Thu, 14 Nov 2013 20:54:00 -0000 In-Reply-To: (Doug Evans's message of "Thu, 14 Nov 2013 09:48:31 -0800") Message-ID: <87bo1mwvqg.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-11/txt/msg00389.txt.bz2 >>>>> "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. 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. Tom