From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15261 invoked by alias); 13 Dec 2010 21:02:17 -0000 Received: (qmail 15245 invoked by uid 22791); 13 Dec 2010 21:02:15 -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 21:02:07 +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 oBDL243d004294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 16:02:04 -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 oBDL230W013717; Mon, 13 Dec 2010 16:02:03 -0500 From: Phil Muldoon To: Doug Evans Cc: 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: Mon, 13 Dec 2010 21:02:00 -0000 In-Reply-To: (Doug Evans's message of "Mon, 13 Dec 2010 12:45:38 -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=utf-8 Content-Transfer-Encoding: quoted-printable 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/msg00201.txt.bz2 Doug Evans writes: > On Mon, Dec 13, 2010 at 5:50 AM, Phil Muldoon wrote: >> This patch allows Python breakpoints to be sub-classed and implements >> the "evaluate" function. =C2=A0If the user defines an "evaluate" functio= n 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. =C2=A0If the function returns True, GDB= will >> stop the inferior at the breakpoint; if the function returns False >> the inferior will continue. > > Hi. > My $0.02 cents. > > Collecting data in the "evaluate" function feels too hacky for > something we explicitly tell users is the published way to do this > kind of thing. It's nothing more than a hook for the user to accomplish some truth finding mission at breakpoint evaluation time. If the user wants to collect data, then I think they can do that -- that is we should not attempt to stop them. I probably worded my email hastily; FWIW I think this a place where we can write conditional breakpoints that can be written entirely in Python. > And the name "evaluate" doesn't feel right either. What does it mean > to evaluate a breakpoint? [One might think it means to evaluate the > location of the breakpoint, e.g., since gdb tries to re-evaluate the > location when the binary changes.] > I realize the _p convention mightn't be sufficiently common to use in > the Python API, but for example a better name might be stop_p. > And then one would have another method (I don't have a good name for > it ATM) to use to collect data. > Setting aside name choices, I like that API better. I'm happy with any name. Lets just call it what the majority are comfortable with. I used "evaluate" purely as a descriptive term to what we are doing. Whatever else fits will work with me. > OTOH, it seems like Python-based breakpoints have two conditions now > (or at least two kinds of conditions one has to think about). > One set with the "condition" command and one from the "evaluate" API func= tion. > IWBN to have only one, at least conceptually. Maybe you could rename > "evaluate" to "condition" (or some such, I realize there's already a > "condition"), and have the default be to use the CLI condition. This is something that is always a ponder-point for Python API hackers. There are lots of places where "things" have worked in CLI for many years, and we (well, I) do not want to deprecate existing CLI functionality while expanding other areas. I'm not sure what the path is from here. Overloading the condition API seems like a pain for the script-writer to figure out if it is a Python scripted condition, or a CLI scripted condition. That is why I ended up choosing a different name.=20=20 What do you think? Cheers, Phil