From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4410 invoked by alias); 7 Mar 2011 20:48:55 -0000 Received: (qmail 4402 invoked by uid 22791); 7 Mar 2011 20:48:54 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Mar 2011 20:48:50 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p27Kml2G024337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2011 15:48:47 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p27Kmls7021442; Mon, 7 Mar 2011 15:48:47 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p27KmkH5020416; Mon, 7 Mar 2011 15:48:46 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 222D9378339; Mon, 7 Mar 2011 13:48:46 -0700 (MST) From: Tom Tromey To: Doug Evans Cc: pmuldoon@redhat.com, gdb-patches@sourceware.org Subject: Re: [patch] [python] Implement stop_p for gdb.Breakpoint References: Date: Mon, 07 Mar 2011 20:52:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 23 Feb 2011 21:29:05 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2011-03/txt/msg00504.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> - "consistency is good", so if we go with _p for stop_p we need to go Doug> with _p for all predicates Doug> - are we prepared for that? Doug> - are there any existing predicates that don't have _p? Doug> - does python have an existing convention? Doug> [I used stop_p at the time for clarity's sake. But I think these Doug> questions need to be asked.] I don't think we should use _p on predicates. That is not a Python convention. I don't think Python actually does have a convention for this kind of predicate. I suggest we just pick a name that makes sense. Doug> - I didn't see any tests for log-printf I don't think log-printf is ready for submission. It can either be a separate patch later, or just not submitted. I wrote it just to provide a real-word test of one of the use cases for which this functionality is intended. Doug> - is the logic for deciding whether to stop correct? Doug> E.g. if stop_p says "don't stop" and a condition says "stop" will Doug> execution continue? It looks like it, but maybe I'm misunderstanding Doug> something. Phil> The case of the user having an old-style GDB condition, and an Phil> implementation of a "stop_p" is an odd one. I was inclined to disallow Phil> it, but eventually decided against it. There will be conflict if stop_p Phil> and condition disagree. My first thoughts are "stop" should always Phil> trump "don't stop". What do you think? My view is that the conditions should be separate, and that if either one indicates "stop", then the breakpoint should stop. My reason is that the Python method is an implementation detail of some kind of "stop point" provided by a Python script. It is not readily mutable by the user. On the other hand, the condition is something explicitly under the user's control. If we really need to let the Python programmer prevent users from setting a condition on one of these breakpoints, we can provide a mechanism for doing that. Doug> For things like this I like to start slow: "It's easier to relax Doug> restrictions than it is to impose them after the fact." Doug> So my vote would be to not support both in the first pass. It Doug> kinda makes intuitive sense too (to me anyway). i.e. the default Doug> implementation of "stop_p" uses the command-line condition, and if Doug> overridden then uses the python-provided addition. These two statements are contradictory. Or, maybe I didn't understand one of them. If we unify stop_p and the user condition now, it will be hard to separate them later -- because we will have documented that this is how they work. I think the most conservative approach is to make it an error for the user to set a condition on a breakpoint that has a stop_p method, and vice versa. That preserves the ability to make a different decision later. Tom