From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25938 invoked by alias); 9 Nov 2011 18:19:32 -0000 Received: (qmail 25929 invoked by uid 22791); 9 Nov 2011 18:19:31 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 18:19:16 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA9IJ3Hk022250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2011 13:19:03 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA9IJ3uh026776; Wed, 9 Nov 2011 13:19:03 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pA9IJ1Od018659; Wed, 9 Nov 2011 13:19:02 -0500 From: Tom Tromey To: Joel Brobecker Cc: Jerome Guitton , Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: RFA: implement ambiguous linespec proposal References: <20111028221459.GA28467@host1.jankratochvil.net> <20111104074543.GA13839@host1.jankratochvil.net> <20111109160529.GO14508@adacore.com> <20111109175623.GP14508@adacore.com> Date: Wed, 09 Nov 2011 18:19:00 -0000 In-Reply-To: <20111109175623.GP14508@adacore.com> (Joel Brobecker's message of "Wed, 9 Nov 2011 09:56:23 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2011-11/txt/msg00244.txt.bz2 Joel> It is needed, and that's what we do at AdaCore. That's the new Joel> canonical form that I was mentioning in the previous messages. Joel> I don't think it is 100% unique, but it's pretty close, and I think Joel> it's the best we can do (we've never heard reports of problems Joel> with that form in the 10+ years we've been using it). Joel> The canonical form for Ada is: FILE:FUNCTION_NAME:LINE_NO. Once Joel> written in that form, the linespec parser should always re-evaluate Joel> it into one single logical breakpoint (with potentially multiple Joel> locations). Oh, ok. I forgot all the discussions we've had on this, maybe since I was fixated on ada_lookup_symbol_list, or maybe because of sleep deprivation :) I think FILE:FUNCTION:LINE is a good form to provide to users, but it seems to me that it is incorrect to rewrite a user's "FUNCTION" linespec into this form. My reason is that it seems like it would do the wrong thing if the line number changes -- the linespec would stop working, rather than re-evaluate correctly. How do you deal with this problem? My patch doesn't provide FILE:FUNCTION:LINE; but Keith is working on some parsing changes for linespec that should make it simpler to add things like this in the future. Joel> The question is, can we use that same form for everyone? I thought Joel> you were going to do unconditional rewriting of the location string, Joel> but now I'm not so sure anymore... With my patch, only relative forms require rewriting. I think those are just "break LINE" and "break LABEL". The former is rewritten to FILE:LINE, and the latter to FUNCTION:LABEL. With multiple-symbols=ask, we also do filtering based on the "canonical form", which is different from the string used to re-evaluate. E.g., suppose you do "break something::method" and there are 5 methods. Suppose you have multiple-symbols=ask and you pick something::method(int). Then, we will have a breakpoint whose linespec is "something::method" but whose filter is "something::method(int)". I chose this somewhat odd design over the more straightforward rewriting of the linespec because there are canonical forms which are not yet suitable as input to linespec. I could add these to linespec, but I wanted to keep the patch smaller -- my plan is to update this once Keith's changes are ready. Tom