From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8682 invoked by alias); 15 Nov 2013 15:54:41 -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 8671 invoked by uid 89); 15 Nov 2013 15:54:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_20,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-wg0-f49.google.com Received: from Unknown (HELO mail-wg0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 15:54:39 +0000 Received: by mail-wg0-f49.google.com with SMTP id x13so3621047wgg.28 for ; Fri, 15 Nov 2013 07:54:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.84.72 with SMTP id w8mr2027955wjy.55.1384530870561; Fri, 15 Nov 2013 07:54:30 -0800 (PST) Received: by 10.194.37.73 with HTTP; Fri, 15 Nov 2013 07:54:30 -0800 (PST) In-Reply-To: <5286078F.8090700@redhat.com> References: <87bo1mwvqg.fsf@fleche.redhat.com> <52853D8A.5070908@redhat.com> <5286078F.8090700@redhat.com> Date: Fri, 15 Nov 2013 16:30:00 -0000 Message-ID: Subject: Re: [PATCH, doc RFA] Allow CLI and Python conditions to be set on same breakpoint From: Doug Evans To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org, Phil Muldoon , eliz@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00418.txt.bz2 On Fri, Nov 15, 2013 at 3:37 AM, Pedro Alves wrote: > 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. That's really just the "It's more useful to combine them as &&" view (which I agree is a good point). Same thing can apply to other functionality implemented as a Python breakpoint with "stop". I can think of a couple of other ways to achieve it, but && makes it easy.