From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34518 invoked by alias); 27 Jan 2016 01:11:50 -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 34504 invoked by uid 89); 27 Jan 2016 01:11:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Ease, Answer, easy!, Separation X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 27 Jan 2016 01:11:48 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 43313C0A9CD2; Wed, 27 Jan 2016 01:11:47 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0R1BkBX002326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2016 20:11:46 -0500 Subject: Re: [PATCH] python/19506 -- gdb.Breakpoint address location regression To: Joel Brobecker References: <1453413926-24995-1-git-send-email-keiths@redhat.com> <20160126122256.GH5146@adacore.com> Cc: gdb-patches@sourceware.org From: Keith Seitz X-Enigmail-Draft-Status: N1110 Message-ID: <56A81951.2030105@redhat.com> Date: Wed, 27 Jan 2016 01:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20160126122256.GH5146@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00666.txt.bz2 On 01/26/2016 04:22 AM, Joel Brobecker wrote: > Silly question, but does this work with " *main" (extra leading > space)? A very valid question, in fact. Answer: It works *now*! ;-) > It's too bad you have to explicitly check for '*' in the string. > Perhaps we should delegate that part to the linespec module? > Perhaps other areas might want to have the same (eg. the guile > breakpoint module). [Apologies for waxing a little philosophical here...] Here we are again with the same question as last time: should address locations be considered during linespec parsing? To be honest, I keep bouncing back and forth on this (a bit). IMO we have two opposing "forces" involved in this decision: 1) Ease of use 2) Separation of APIs For me, #1 really boils down to UI writers "passing the buck" down to gdb's internals (via CLI generalisms). With the location API work, I tried to make this layer a little more distinct/separate. UIs are responsible for implementing their own representations of locations in a way most consistent with their implementation specifics. [Example: using 'gdb.Breakpoint("-source foo.c -line 3")' seems downright wrong to me.] The CLI representation is well known, and since we already had a "parser" for it, MI, Python, and Guile just followed suit, reusing the syntax. Hey, it was easy! [And there is *nothing* wrong with that decision.] #2 is really just a theoretical concept. It isn't strictly necessary, but it sure would be nice to have [YMMV]. While I like encapsulating small(er) bits of separate functionality into separate APIs, it sometimes seems more work than it is worth. However, I think there is a trade-off here that can maintain (much of) both of these desirable traits. I missed that when I implemented the locations patches. I failed to acknowledge that we have this legacy "re-using" of CLI idioms like linespecs, and I should have made concessions to facilitate re-using this "legacy" syntax. [I say "legacy" to mean pre-locations linespecs compared to today's linespec location. An unfortunately subtle choice of words, I know.] In light of this, I am suggesting that instead of requiring python/mi/guile/whatever to implement their own string_to_event_location functions, that the current string_to_event_location be split into a "legacy" portion (that deals with address, probe, and linespec locations) and a newer (and separate) explicit-handling form (for the CLI only). This leaves python/guile to implement an explicit location specification in a manner more consistent with those interpreters, e.g., python could use named arguments to gdb.Breakpoint: gdb.Breakpoint(source="foo.c", line="3") This way we wouldn't "force" these languages to use the CLI's argument/value paradigm. I've already done something similar for MI. [MI is currently using string_to_event_location, which means it will erroneously support the CLI's explicit syntax in addition to its own! Bug! My bad! Have patch.] In short: 1) Remove explicit locations from string_to_event_location. Use this "new" function /everywhere/ legacy linespec support is desired. In my working tree, I call this string_to_event_location_basic. 2) string_to_event_locations can now be refactored to do two things: check for an explicit location OR call the _basic version to deal with linespec, address, and probe locations. WDYT? [I can send a small patch series to address/clean up all of these, if you think this is a reasonable resolution.] Keith