From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26341 invoked by alias); 13 Dec 2010 14:47:43 -0000 Received: (qmail 26333 invoked by uid 22791); 13 Dec 2010 14:47:42 -0000 X-SWARE-Spam-Status: No, hits=-5.8 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, 13 Dec 2010 14:47:38 +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.13.8/8.13.8) with ESMTP id oBDElYTI021818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 09:47:34 -0500 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBDElXh1003433; Mon, 13 Dec 2010 09:47:33 -0500 From: Phil Muldoon To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. References: <8362uxiwmc.fsf@gnu.org> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 13 Dec 2010 14:47:00 -0000 In-Reply-To: <8362uxiwmc.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Dec 2010 16:19:07 +0200") 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/msg00183.txt.bz2 Eli Zaretskii writes: >> From: Phil Muldoon >> Date: Mon, 13 Dec 2010 13:50:36 +0000 >> +class. The @code{gdb.Breakpoint} class can be sub-classed and, in >> +particular, you may choose to implement the @code{evaluate} function. >> +If this function is defined it will be called when the inferior reaches >> +that breakpoint. > > Which "that breakpoint" are you talking about here? Perhaps you meant > this: > > If this function is defined for a breakpoint, it will be called when > the inferior reaches that breakpoint. > > ? If so, the text is clear, but then this interpretation doesn't seem > to be consistent with the example you give. I'm not sure what you mean here. Given the example in the patch, you can instantiate any number of those breakpoints. So +class MyBreakpoint (gdb.Breakpoint): + def evaluate (self): + inf_val = gdb.parse_and_eval("foo") + if inf_val == 3: + return True + return False There are two scenarios where the breakpoints would be executed. The first is where you would end up instantiating two instances of the above breakpoint at the same location: python bp1 = MyBreakPoint("myfile.c:42") python bp2 = MyBreakpoint("myfile.c:42", internal=True) And the other where you would have two dissimilar breakpoints at the same location: e.g, +class MyBreakpoint2 (gdb.Breakpoint): + def evaluate (self): + inf_val = gdb.parse_and_eval("bar") + if inf_val == 5: + return True + return False python bp1 = MyBreakPoint("myfile.c:42") python bp2 = MyBreakpoint2("myfile.c:42") Does that help explain? I'm opening to wording it however makes the most sense. >> +@code{True}, the inferior will be stopped at the location of the >> +breakpoint. Otherwise if the function returns @code{False} the >> +inferior will continue. > > Either "otherwise", or "if it returns False"; using both is redundant. Ok, thanks. >> + The @code{evaluate} function should not >> +attempt to influence the state of the inferior (e.g., step) or >> +otherwise alter its data. > > Sounds like a non-trivial limitation; is it really necessary? I mentioned it as it was a non-trivial limitation? It is something the user should not do in the evaluate function. The most pressing reason is that there may be other breakpoints to be checked at that location so the state of the inferior should remain. The other is it is just bad business influencing the inferior position (i.e., stepping) when breakpoint evaluation is being performed. At least to me. This is all well and good, but we cannot prevent the user from doing it; just tell them it is very bad idea. ;) >> +If there are multiple breakpoints at the same location with an >> +@code{evaluate} function, each one will be called regardless of the >> +return status of the previous. > > Do we have anything to say regarding the order of the calls? I'm not sure, as there is no mention I could find in the manual regarding the conditional evaluation order of breakpoints. I believe they are called in the order of creation. Maybe Pedro knows. But as breakpoint ordering is not mentioned anywhere else, and as all the evaluation functions at that location will be called regardless, I decided not to mention it. Cheers, Phil