From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9548 invoked by alias); 9 Nov 2011 17:12:20 -0000 Received: (qmail 9539 invoked by uid 22791); 9 Nov 2011 17:12:19 -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 17:11:45 +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 pA9HBX2G013783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2011 12:11:33 -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 pA9HBWrQ003396; Wed, 9 Nov 2011 12:11:32 -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 pA9HBUrD008022; Wed, 9 Nov 2011 12:11:31 -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> Date: Wed, 09 Nov 2011 17:12:00 -0000 In-Reply-To: <20111109160529.GO14508@adacore.com> (Joel Brobecker's message of "Wed, 9 Nov 2011 08:05:29 -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/msg00238.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> We have a similar issue: When the user inserts a breakpoint, and there Joel> are multiple possible choices, we have two scnearios: Joel> 1. He selects `all' -> In that case, we actually create one breakpoint Joel> with multiple locations; Joel> 2. He selects a subset -> In that situation, we create one breakpoint Joel> per location. Joel> I think this can be pretty confusing. This happens with the new code too, though it depends on the 'multiple-symbols' setting. For 'all', there is no menu, just a breakpoint with all the locations. The code is based around the idea that a linespec has a canonical form. Re-setting is done based by re-parsing the original linespec (though there are exceptions to this rule -- linespec is pretty complicated); but filtering is done based on the canonical form. The exception to the re-parsing rule is for linespecs where the original text is context-relative. For example, "break 57" -- it would not make sense to try to re-parse "57", instead linespec returns a form of "file.c:57". So, I misspoke a little upthread. The problem with the searching namespace using declarations for C++ is that the linespec is context-relative, but there is no unique non-relative form we can rewrite. That is, in the example, the rewritten form for re-parsing would have to be both "N1::m" and "N2::m". Joel> [1]: We tried contributing it, but it was too hacky to really be part Joel> of the FSF sources. The main complaint at the time was the fact Joel> that it introduced a canonical form that was specific to Ada. I was Joel> planning on looking at generalizing it to all languages, but never Joel> got around to doing it. Do you have a URL? This would be a good time to resurrect it. I would like to take a look... I don't know Ada, though, so I'm going to guess that I probably won't be able to fix it up. In terms of the proposed patch, the key question is whether rewriting is needed for Ada, and if so, whether it can be done uniquely. Or, if using the simple name is always enough... in this case the solution is very easy. Tom