From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25447 invoked by alias); 8 Nov 2011 16:36:47 -0000 Received: (qmail 25436 invoked by uid 22791); 8 Nov 2011 16:36:46 -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; Tue, 08 Nov 2011 16:36:31 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA8GaVAB022092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Nov 2011 11:36:31 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA8GaUaD023680; Tue, 8 Nov 2011 11:36:31 -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 pA8GaTQU029210; Tue, 8 Nov 2011 11:36:30 -0500 From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: RFA: implement ambiguous linespec proposal References: <20111028221459.GA28467@host1.jankratochvil.net> <20111104074543.GA13839@host1.jankratochvil.net> Date: Tue, 08 Nov 2011 16:36:00 -0000 In-Reply-To: <20111104074543.GA13839@host1.jankratochvil.net> (Jan Kratochvil's message of "Fri, 4 Nov 2011 08:45:43 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/msg00195.txt.bz2 >>>>> "Jan" =3D=3D Jan Kratochvil writes: Jan> Compiler says: Jan> .C:13:6: error: call of overloaded =E2=80=98m()=E2=80=99 is ambiguous Jan> .C:13:6: note: candidates are: Jan> .C:6:7: note: int N2::m() Jan> .C:2:7: note: int N1::m() Jan> and I think GDB should also say the same output as error. I agree for expressions. I think linespecs are different. For example, with ADL, a plain name like "function" may be looked up in the namespaces of the arguments. I don't see how linespec will ever handle this sanely. GDB is already inconsistent here, BTW. For example, "break k::m" will search superclasses of "k", but "break m" will not search superclasses of the class of *this. I have been thinking about this, though, and I think there is another approach that could work. Jan> One can store the available namespaces as strings with the Jan> breakpoint (instead of storing pointer to the block - where the Jan> block may disappear). Yeah. I would like to store as little context as possible, though. Or, rather, I would like all the context to appear in the linespec's canonical form. The way we could make this work is that we could have decode_line_full return sets of SALs, where each set is distinguished by its canonical name. So, in this case, we would return two sets, one "N1::m" and one "N2::m". Then, this would create two separate breakpoints -- one per set. This is more complicated than just rejecting this case, but it would let us preserve namespace searches. I think it would also make some Ada cases work more sanely, though I don't know enough to say with certainty. I'm thinking here about how ada_lookup_symbol_list returns a list but then the linespec code only uses the first one (via some call through ada_lookup_encoded_symbol, I don't remember the details). My problem with this is that it adds more complexity to the user interface: some linespecs will create a single breakpoint with multiple locations, some will create multiple breakpoints once again, depending on the context. So, I am still against it, but I will take a stab at it if you think it is important. Tom