From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59701 invoked by alias); 16 Oct 2017 20:24:33 -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 52107 invoked by uid 89); 16 Oct 2017 20:24:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=converter X-HELO: mail-wr0-f181.google.com Received: from mail-wr0-f181.google.com (HELO mail-wr0-f181.google.com) (209.85.128.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Oct 2017 20:24:14 +0000 Received: by mail-wr0-f181.google.com with SMTP id y44so4146961wry.10 for ; Mon, 16 Oct 2017 13:24:04 -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=GO8EeD5AY3BmqFA+OmSOZMWKcQ5wtmAUM4UzD4PKuvE=; b=gziizT2hv3n/Cr+pn5/elXDwxjLAQaRcqpO487aMcVM9yJ/jzXiKmwuo7x2Goujr+b 5/GEXodOA9z8f7GidgAM28jxXpQoM/eqfGecN86mLqx+dEXH3WK+XT8U7Za1l3ZuYEuF myqbYE9yjz7O9wqaPiqADtnU/wIFHlC0mOOXTWcNM+G85xemY+jAEIJXHiZw7/rVrIVS jjkXJBbcX+0jdD0ZBJVmNcStVbOyTRaTEJ3vIV3fWMYsjWoG2UsgsXVzxdkZw7XPuH3B Jiadol5wO+Bxg7ZAMvAAbfKrYvCwVUT5xSHBhsDOWjl7cDL2Kiqwpb/VOI7zcDLU3BMp GzVQ== X-Gm-Message-State: AMCzsaWyuFLJXF0q/jiQwXGofqONPpILaA7Y3/TQzz+53s5CZEo0DpCM rfb1QrqGZPd4EaVUdnlBJz5CZGxctEk= X-Google-Smtp-Source: ABhQp+TSCa+EA0sMGtAN1/gjimNaWYvBuiZ/mfvjVByRJdOOhdzgPEDupnS44SpwkpoWskxbIz2uPQ== X-Received: by 10.223.164.206 with SMTP id h14mr1458631wrb.25.1508185441935; Mon, 16 Oct 2017 13:24:01 -0700 (PDT) Received: from ?IPv6:2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4? ([2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4]) by smtp.gmail.com with ESMTPSA id 76sm10098082wmj.37.2017.10.16.13.24.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 13:24:00 -0700 (PDT) Subject: Re: [python] Allow explicit locations in breakpoints. To: Simon Marchi , Keith Seitz , "gdb-patches@sourceware.org" References: <04ccc2c4-7827-eedc-d8db-a83a0167acb6@redhat.com> <58311250-9ab1-39d1-99b6-07478bc8c2ab@redhat.com> <4768c7ad-cc3d-5702-fa93-40e9760d4ee8@ericsson.com> From: Phil Muldoon Message-ID: Date: Mon, 16 Oct 2017 20:24:00 -0000 MIME-Version: 1.0 In-Reply-To: <4768c7ad-cc3d-5702-fa93-40e9760d4ee8@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00466.txt.bz2 On 16/10/17 19:23, Simon Marchi wrote: > On 2017-08-23 02:30 PM, Phil Muldoon wrote: >> On 23/08/17 18:51, Keith Seitz wrote: >>> On 08/23/2017 06:58 AM, Phil Muldoon wrote: > I think for Python it would make sense to support the two paradigms. If you > are writing a Python command that ends up installing a breakpoint, it would > be nice if you could directly pass what you received to the gdb.Breakpoint > constructor and have it parse it (including explicit locations). For example, > > (gdb) special-break -file foo.c -line 17 > > But it would also be nice to have a keywords based API, for when the line/file/function > information is already split. It would avoid having to build an explicit linespec > string just to have GDB parse it after. > > In terms of API, I think the "spec" argument could be mutually exclusive with > the function/file/line/etc keywork arguments, which would be added. An error > would be thrown if you try to use both ways at the same time. > > About the line="+3" issue, because this is Python, the line keyword could > probably accept integers and strings. And if it's a string, there could > be some validation on the format. > Simon, Thanks for the review. For the record I have no objection to the keywords API in addition to the spec line. But I'm not sure what you mean about the line argument taking an integer or a string. So line is a problem; it can be: - line=3 (at line three in the source code) - line=+3 (plus three lines from current source location) - line=-3 (minus three lines from current source location) I'm not sure how I could write a ParseTupleAndKeyword to accept that in any form other than a string? The -3 will be a minus three, the +3 will just be a 3, and the =3 will be a 3 too. The problem is the relative "+" information gets lost. Did you have something else in mind? I guess I could use the O& in the format string to invoke a converter function? I'm not quite sure what you intend though? For now, though, I'll add the keywords (as strings) in. This really prompts me to think we should rewrite the gdb.Breakpoint constructor to not use create_breakpoint and be more MI-like in the creation of breakpoints. Cheers Phil