From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20111 invoked by alias); 28 Dec 2010 05:08:40 -0000 Received: (qmail 20100 invoked by uid 22791); 28 Dec 2010 05:08:39 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_50,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) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Dec 2010 05:08:34 +0000 Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oBS58V4i002014 for ; Mon, 27 Dec 2010 21:08:31 -0800 Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by wpaz9.hot.corp.google.com with ESMTP id oBS58TAl031509 for ; Mon, 27 Dec 2010 21:08:29 -0800 Received: by qwj9 with SMTP id 9so9588980qwj.22 for ; Mon, 27 Dec 2010 21:08:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.74.8 with SMTP id s8mr12442297qaj.204.1293512909404; Mon, 27 Dec 2010 21:08:29 -0800 (PST) Received: by 10.220.60.10 with HTTP; Mon, 27 Dec 2010 21:08:29 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Dec 2010 05:53:00 -0000 Message-ID: Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. From: Doug Evans To: Tom Tromey Cc: pmuldoon@redhat.com, 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/msg00490.txt.bz2 On Wed, Dec 22, 2010 at 8:19 AM, Tom Tromey wrote: >>>>>> "Doug" =3D=3D Doug Evans writes: > >>> The method in question is attached to a particular breakpoint. =A0So, if >>> it requests a stop, it will be reported as coming from that breakpoint. > > Doug> That feels a bit subtle (and easy for the user to confuse with a > Doug> normal breakpoint). > > But it will actually be a normal breakpoint. Right, that's my point. The user will see the normal breakpoint output, and then be expected to know that the breakpoint is special (e.g., a rule was violated and that s/he needs to pay attention to what the rule was). Is there a plan to have something more? [Or am I missing something?] > Doug> Plus will it also breakdown if a developer sets his/her own breakpo= int > Doug> at that location? > > No, it will continue to do the right thing. =A0In fact that is one of the > major points of this patch, see the requirements upthread. Sorry, maybe I was too subtle. If one is using this facility to implement a rule checker that stops when the rule is violated, and one sets another breakpoint at the same location, when the program stops how does one know whether the rule was violated or not? [Especially if all that is reported is the normal breakpoint output.]