From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20592 invoked by alias); 15 Nov 2013 11:39:27 -0000 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 Received: (qmail 20569 invoked by uid 89); 15 Nov 2013 11:39:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_05,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2013 11:38:03 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAFBbs18006185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Nov 2013 06:37:54 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAFBbpT7009444; Fri, 15 Nov 2013 06:37:52 -0500 Message-ID: <5286078F.8090700@redhat.com> Date: Fri, 15 Nov 2013 12:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Doug Evans CC: Tom Tromey , gdb-patches@sourceware.org, pmuldoon@redhat.com, eliz@gnu.org Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint References: <87bo1mwvqg.fsf@fleche.redhat.com> <52853D8A.5070908@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00408.txt.bz2 On 11/15/2013 05:34 AM, Doug Evans wrote: > On Thu, Nov 14, 2013 at 1:15 PM, Pedro Alves wrote: >> That does make sense. In that scenario, it then sounds like it's >> best to think of the "stop" method more like a ops->check_status >> implementation/extension, than a breakpoint condition. > > Need More Data. > In this scenario, when would one typically add a CLI condition to such > a Python interpreter breakpoint? Not exactly sure what you're asking, but say, you're debugging a C program that uses Python as extension language, like e.g., GDB, and you have something buggy in the extension support, only triggered on a particular path of this Python script, but of all the 2000000 calls to the script, you can tell that only those for a certain condition in the C side of the program not exposed to Python would be interesting, as they're the ones that seem to trigger the bug. You'd use the fictitious "python-interp-breakpoint" command to set a breakpoint in the Python script, and do: (gdb) python-interp-breakpoint some-other-cool-extention.py:30 (gdb) condition $bpnum global_in_the_C_code_of_the_program==0xf00 That is, please ignore all hits of the python breakpoint unless this particular condition in my program is true. I imagine that such a thing would be useful for debugging the Python interpreter itself too. > Plus if this is really a check_status thing then I wonder if > gdb.Breakpoint is going down the wrong path and we should be providing > a class where users can override breakpoint_ops. Yeah, I meant it only in the abstract. My view is that breakpoint_ops is messy at places, and exposing it in full directly at least in its current state would be a bad idea. >>> This particular example would be better with some other additions to the >>> gdb breakpoint API; and maybe those would obviate the need for this dual >>> purposing. But since we don't have those additions, it remains unclear >>> to me that "|" is better than "&&" here. >> >> Yeah, it does sound like && is more useful. To get "|", the user can >> set another breakpoint at the same address/whatever with a cli condition. > > That's a good point. -- Pedro Alves