From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22926 invoked by alias); 14 Nov 2011 21:04:06 -0000 Received: (qmail 22916 invoked by uid 22791); 14 Nov 2011 21:04:04 -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; Mon, 14 Nov 2011 21:03:38 +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 pAEL3Fkj012296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2011 16:03:15 -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 pAEL3EkK024940; Mon, 14 Nov 2011 16:03:15 -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 pAEL3D7n004607; Mon, 14 Nov 2011 16:03:13 -0500 From: Tom Tromey To: Joel Brobecker Cc: Jerome Guitton , Jan Kratochvil , gdb-patches@sourceware.org, Paul Hilfinger 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> <20111109185935.GQ14508@adacore.com> Date: Mon, 14 Nov 2011 21:04:00 -0000 In-Reply-To: <20111109185935.GQ14508@adacore.com> (Joel Brobecker's message of "Wed, 9 Nov 2011 10:59:35 -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/msg00365.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Tom> E.g., suppose you do "break something::method" and there are 5 methods. Tom> Suppose you have multiple-symbols=ask and you pick something::method(int). Tom> Then, we will have a breakpoint whose linespec is "something::method" Tom> but whose filter is "something::method(int)". Joel> I wonder if we could start filtering based on function fully qualified Joel> name, and profile (argument types) as well. In other words, if the user Joel> does: Joel> (gdb) break foo Joel> and there are several functions named foo, then we'd have a filter Joel> that says: Joel> package1.foo(integer) Joel> package2.instantiation.foo(float) Yeah, this is actually what happens in multiple-symbols=ask mode: we present the canonical forms to the user, and record as the filter the one that he chooses. An implication of this is that we don't discriminate more finely than what can be encoded in the canonical form. So, for example, one cannot set a symbolic (as opposed to by-address) breakpoint at a single point of inlining -- because the canonical form for the inlined function will be identical across inlined instances. I don't know if that description makes any sense outside my head :) Joel> The only road-block I can foresee is the fact that I am unclear on Joel> the resolution rules in Ada. I think they can get quite tricky, and Joel> reproducing that in GDB might be a fair amount of work (if possible Joel> at all). On the other hand, it would be nice to have that, because Joel> we somewhat have something like that already for resolving inferior Joel> function calls from GDB, but it's fairly primitive, and I think we Joel> can call the wrong function sometimes (I just forgot the details). Yeah, the issue in this sub-thread is whether or not to perform name lookup. My view is that if the name lookup is context-dependent, then we should not do it. E.g., in the C++ example, having "break m" search namespaces would either require us to (1) rewrite the linespec from "m" to something else for purposes of re-evaluation, or (2) store the context. I tend to think neither one is very good and that we slipped into doing this in the first place by accident, not design. Joel> Just curious: Are we planning on emitting a warning if re-evaluating Joel> a breakpoint for which we no longer have a match for one of the entries Joel> in the filter? This would happen if the user selected a function which, Joel> after rebuilding the executable, no longer exists... It just silently stays around. I believe "info break" will show it as pending. Joel> I actually like this design better. In fact, we don't even need the Joel> filter to consist of strings. It could very well be something more Joel> elaborate... Yeah; we discussed that at some point, but I didn't seem to need it. It is still available as a future change though. Tom