From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23997 invoked by alias); 9 May 2014 16:37:31 -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 23983 invoked by uid 89); 9 May 2014 16:37:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 ESMTP; Fri, 09 May 2014 16:37:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s49GbRTN016457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 May 2014 12:37:27 -0400 Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s49GbQAK025822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 May 2014 12:37:27 -0400 Message-ID: <536D0446.9060500@redhat.com> Date: Fri, 09 May 2014 16:37:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Matt Rice CC: "gdb-patches@sourceware.org ml" Subject: Re: [RFA 7/9] Explicit locations v2 - CLI for explicit locations References: <536BC707.4030300@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00117.txt.bz2 On 05/08/2014 05:48 PM, Matt Rice wrote: > Just curious if we need this quote handling in explicit linespec's Good question! I did this so long ago, I'm not 100% certain /why/ I chose to include quoting, but I can have a guess... UI consistency. It is allowed in linespecs, largely -- but not entirely -- to work around (old) parser problems. Users are, sadly, quite used to quoting things. In order to maintain some sort of parallelism, I *think* that I added the ability to quote stuff, but it is not necessary (see below). > I thought (though i'm not terribly familiar with c++ linespecs) > that the quotes were for operator+, clashing with foo+offset > and 'something::foo' clashing with file:line stuff, With the "new" linespec parser, I've tried to minimize the need to quote anything. Alas, as you point out, the need still arises. One of the tests that I have added for dprintfs seems to indicate that I had similar concerns about permissive quoting: (gdb) dprintf -func A::operator,,"hello\n" Believe it or not, that actually does do what it is supposed to do. [Ok, maybe I am the only one surprised to (re)discover that.] > where it isn't obvious to me the need for it arises when using > explicit locations. > I suppose break -source '/path with spaces/foo.c' -line +42 I tried this on my working copy: (gdb) b -source /dir with spaces/file with spaces.c -line 3 No source file named /dir with spaces/file with spaces.c. Make breakpoint pending on future shared library load? (y or [n]) n So it seems I already had something in mind to handle spaces in a relatively sane way. [Not that there aren't any lurking bugs -- I'll be the first to admit I am seldom capable of writing bug-free code with a patch this large.] > my main curiosity here is for languages which allow the ' character, > particularly the ML family's usage of type variables[1]. to > discriminate polymorphic functions of the variety break -function > foo('a) vs break -function foo(string). The parser seems to already permit this syntax, but again, I'm sure there are latent bugs in there somewhere: (gdb) b -func foo('a) Function "foo('a)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n So, in the end, it certainly seems that we could whack this quoting stuff altogether if it was so desired. Other than the parallelism `argument' that I think I used to justify this to myself when I originally wrote it, there isn't really a compelling reason to keep it. At least, not that I know of/remember right now. Keith