From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5480 invoked by alias); 14 Dec 2010 19:51:22 -0000 Received: (qmail 5459 invoked by uid 22791); 14 Dec 2010 19:51:19 -0000 X-SWARE-Spam-Status: No, hits=-5.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; Tue, 14 Dec 2010 19:51:13 +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.13.8/8.13.8) with ESMTP id oBEJp97C005960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 14:51:09 -0500 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBEJp75C003004; Tue, 14 Dec 2010 14:51:08 -0500 From: Phil Muldoon To: Tom Tromey Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Tue, 14 Dec 2010 19:51:00 -0000 In-Reply-To: (Tom Tromey's message of "Tue, 14 Dec 2010 10:28:38 -0700") 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 X-IsSubscribed: yes 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: 2010-12/txt/msg00260.txt.bz2 Tom Tromey writes: >>>>>> "Doug" == Doug Evans writes: > > Doug> And the name "evaluate" doesn't feel right either. > > I agree. It's no problem to allow the implemented function to be called "condition" or anything else. > Doug> OTOH, it seems like Python-based breakpoints have two conditions > Doug> now (or at least two kinds of conditions one has to think about). > Doug> One set with the "condition" command and one from the "evaluate" > Doug> API function. IWBN to have only one, at least conceptually. > Doug> Maybe you could rename "evaluate" to "condition" (or some such, I > Doug> realize there's already a "condition"), and have the default be to > Doug> use the CLI condition. > > This would be fine with me as long as it meets all the goals above. So let me be sure I understand correctly: class MyBreakpoint (gdb.Breakpoint): def condition (self): inf_val = gdb.parse_and_eval("i") if inf_val == 3: return True return False foo = MyBreakpoint ("myfile.c:42") Would be how we work with the new Python evaluation breakpoints. And bar = gdb.Breakpoint("myfile.c:42) bar.condition = "i == 2" Would be the old style. In this case "foo" would have had the "condition" method executed three times (up until i == 2), always returning "False" (IE, don't stop) before the "bar" condition of the other breakpoint stopped the inferior with its condition. In the case of a new style breakpoint having both a CLI .condition() AND an implemented method (though I could never see why you would want to do this), whichever of those methods told GDB not to stop would trump the other. (GDB assumes in bpstat_stop_status that the breakpoint will stop the inferior (other than special cases like moribund breakpoints) and it is up to the breakpoint evaluation to say, "hey don't stop". So the stop-bit is never set by the conditional stuff, just unset). How does this sound? Cheers Phil