From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52961 invoked by alias); 10 Mar 2017 19:24:01 -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 52945 invoked by uid 89); 10 Mar 2017 19:24:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=redesign, H*MI:sk:58C2F18, H*i:sk:58C2F18, H*f:sk:58C2F18 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, 10 Mar 2017 19:23:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 544E761B92 for ; Fri, 10 Mar 2017 19:24:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2AJNx6f029253; Fri, 10 Mar 2017 14:23:59 -0500 Subject: Re: [PATCH] c++/8218: Destructors w/arguments. To: Keith Seitz , gdb-patches@sourceware.org References: <1489010611-28451-1-git-send-email-keiths@redhat.com> <2ca278e9-a52a-c082-77f5-5ed60e39091e@redhat.com> <58C0B6B6.9040008@redhat.com> <58C2F189.6060105@redhat.com> From: Pedro Alves Message-ID: <8afc1123-39b5-bc7b-f30e-4028cd1f8934@redhat.com> Date: Fri, 10 Mar 2017 19:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <58C2F189.6060105@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00146.txt.bz2 On 03/10/2017 06:33 PM, Keith Seitz wrote: >> Eh, "mangled_name" is fetched from "TYPE_FN_FIELD_PHYSNAME (f, j)" >> just above. And PHYSNAME is the demangled name in DWARF/C++... >> >> I never quite got why that is (why PHYSNAME is the demangled >> name in C++), and there are still comments all over the place that >> suggest that PHYSNAME is the mangled name. Plus the variables names >> suggest that too. It's ... confusing. > > Long story short: the symbol tables only stored linkage names. That > means every time we attempt to match a name to a symbol (every time we > call strcmp_iw essentially), we need to demangle. Or mangle the lookup name and compare that. But it wouldn't work for my WIP linespec/completion branch, so I'm not proposing that. :-) > Every time we print > out a symbol, we demangle. Every time we do anything with any symbol, we > demangle it. I originally had a working code base to do this. As you can > imagine, it was terribly slow. Yeah, understood, thanks. Ada still does something like that, by using "encoded names" as symbol search names. Regardless, I think a global demangled<->mangled map/hash to avoid doing the work twice would help. I've been pondering that on and off. I think there's a PR open about how we end up demangling the same symbols more than once, due to minsyms vs symbols. > Users don't typically type "b _ZN1AD0Ev". They type "b A::~A". If we > could convince users to use only linkage names, we'd be in great shape. > > If we didn't care about memory footprint, we'd be in great shape. > > If we had access to the same mangler the compiler uses, we'd be in great > shape. > > But we have none of those things. Understood, thanks. > Do maintainers want to reassess this? No, no, no. I was honestly confused by this, not calling for a redesign. I think the main problem is one of nomenclature (what exactly is a physical name), of old stale comments and old variable names. E.g., comments in gdbtypes.h about physname things only talk about mangled names. > Yeah, I figure the way forward would really be to offer all-or-nothing. > Hide all artificial members or hide none. We now do a mish-mash of both, > confusing nearly everybody. /me notes future cleanup/feature Yeah. We could have a "show me artificial things" / "give me the ABI view" switches or format parameter to print/ptype, or some such. Thanks, Pedro Alves