From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6951 invoked by alias); 13 Dec 2010 20:45:49 -0000 Received: (qmail 6942 invoked by uid 22791); 13 Dec 2010 20:45:47 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Dec 2010 20:45:42 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id oBDKjesN021884 for ; Mon, 13 Dec 2010 12:45:40 -0800 Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by wpaz21.hot.corp.google.com with ESMTP id oBDKgAS5009701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 13 Dec 2010 12:45:39 -0800 Received: by qyk34 with SMTP id 34so3736461qyk.3 for ; Mon, 13 Dec 2010 12:45:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.91.13 with SMTP id k13mr4080631qcm.299.1292273138996; Mon, 13 Dec 2010 12:45:38 -0800 (PST) Received: by 10.220.210.12 with HTTP; Mon, 13 Dec 2010 12:45:38 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Dec 2010 20:45:00 -0000 Message-ID: Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. From: Doug Evans To: pmuldoon@redhat.com Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00200.txt.bz2 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. =A0If 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. =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. 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. 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 functi= on. 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. Not that this has to be done now, or ever, but I wonder how useful it would be to allow CLI breakpoints to have commands that are executed prior to evaluating the condition. "continue", etc. would not be allowed here, so it may be too awkward to implement.