From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63606 invoked by alias); 23 Aug 2017 18:31:07 -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 63228 invoked by uid 89); 23 Aug 2017 18:30:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 18:30:51 +0000 Received: by mail-wr0-f180.google.com with SMTP id a47so3118359wra.0 for ; Wed, 23 Aug 2017 11:30:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fqXX+TX+BIMQmCKGjeVbyqm6sH7pGCMpovOdBcVyNI0=; b=SMz8MUw6PH/fWvq0wN2lCJPxnG/F+93ki7PHGmOXvqP15HsKXYK6T65a+x7bh5+WD6 ubxu7Uu/kKocNLUmXiUyQqTxSszEbC8jwLdTpObaddDmSYxB6TFHpyZ18cO9yFcFqcAG gwdC1eqVwubdJazDCUhSrk25/rJMZg8om8RrNV6jiVteUx9GLtDuR/ukw/RI4kNUSAzz vrGaFYIBBABQRQbPn71DBoNZVBH3fsD43FIKjbg0zVRKS4lj0Hv5mboyqTbPLiOA4Xc0 bzoTuQeGlvQNVw+2bmzrdOt0z3Pd3wLYMDduVmFjE6RPMRa5Fu+6wmlpXPnaNaZj1hgf xvhw== X-Gm-Message-State: AHYfb5j+f+rL/93EucKR6nm6I+6P15EBPGUMDOIi3uQK8Xm3khA4a+3r k0zMPZ5wXjpPYVtSACHaZw== X-Received: by 10.223.163.18 with SMTP id c18mr2029560wrb.164.1503513049120; Wed, 23 Aug 2017 11:30:49 -0700 (PDT) Received: from ?IPv6:2a02:c7f:ae15:7800:4685:ff:fe66:9f4? ([2a02:c7f:ae15:7800:4685:ff:fe66:9f4]) by smtp.gmail.com with ESMTPSA id g51sm4198929wrg.92.2017.08.23.11.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 11:30:48 -0700 (PDT) Subject: Re: [python] Allow explicit locations in breakpoints. To: Keith Seitz , "gdb-patches@sourceware.org" References: <04ccc2c4-7827-eedc-d8db-a83a0167acb6@redhat.com> From: Phil Muldoon Message-ID: <58311250-9ab1-39d1-99b6-07478bc8c2ab@redhat.com> Date: Wed, 23 Aug 2017 18:31:00 -0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00453.txt.bz2 On 23/08/17 18:51, Keith Seitz wrote: > On 08/23/2017 06:58 AM, Phil Muldoon wrote: > >> diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c >> index 6156eb6179..8431bed939 100644 >> --- a/gdb/python/py-breakpoint.c >> +++ b/gdb/python/py-breakpoint.c >> @@ -681,7 +681,7 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs) >> case bp_breakpoint: >> { >> event_location_up location >> - = string_to_event_location_basic (©, current_language); >> + = string_to_event_location (©, current_language); >> create_breakpoint (python_gdbarch, >> location.get (), NULL, -1, NULL, >> 0, > > This binds python interfaces to the CLI, and I don't think we want > that. I would have expected (perhaps naively) to see explicit > locations supported using a more natural python convention, such as > using PyArg_ParseTupleAndKeywords. My original implementation was that. I had function="foo" etc as parameters to the constructor. The problem is with the -line parameters and relative parameters. So line=+3 won't work in the Python parameter sense. So it would have to be line="+3" in the constructor. If keywords are all strings, I'm not sure I see the point of parsing them as keywords when you can just specify the whole string (i.e. gdb.Breakpoint("-source=foo.c -line=28"). This is what we do, more less, with the current constructor: IE foo = gdb.Breakpoint("bar.c:23") or foo = gdb.Breakpoint("functionName"). So this patch allows the addition of explicit location parsing in much the same vein as we handle regular breakpoints. (That is, with a CLI-like interface). The gdb.Breakpoint class, for better or for worse, is based pretty much on the interface to create_breakpoint. I'm not adverse to implementing keywords; it's a little extra string wrangling, but I'm not clear on the benefit? The gdb.Breakpoint class has always handed over the interpretation of breakpoints to GDB using the CLI like syntax. I can see why MI separates it out, and I take your point well, in a machine context. Cheers Phil