From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23472 invoked by alias); 13 Dec 2010 14:19:40 -0000 Received: (qmail 23458 invoked by uid 22791); 13 Dec 2010 14:19:39 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Dec 2010 14:19:32 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LDD00A00EFGM500@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Mon, 13 Dec 2010 16:19:09 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDD00A3REFVDL40@a-mtaout20.012.net.il>; Mon, 13 Dec 2010 16:19:08 +0200 (IST) Date: Mon, 13 Dec 2010 14:19:00 -0000 From: Eli Zaretskii Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. In-reply-to: To: pmuldoon@redhat.com Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <8362uxiwmc.fsf@gnu.org> References: 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/msg00181.txt.bz2 > From: Phil Muldoon > Date: Mon, 13 Dec 2010 13:50:36 +0000 > > > This patch allows Python breakpoints to be sub-classed and implements > the "evaluate" function. If the user defines an "evaluate" function in > the Python breakpoint it will be called when GDB evaluates any > conditions assigned to the breakpoint. This allows the user to write > conditional breakpoints entirely in Python, and also allows the user to > collect data at each breakpoint. If the function returns True, GDB will > stop the inferior at the breakpoint; if the function returns False > the inferior will continue. Thanks. > +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. > +@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. > + 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? > +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?