From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 9C45A3858010 for ; Thu, 2 Dec 2021 22:07:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C45A3858010 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0b.wildebeest.org [172.31.17.141]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 20C8E301B4B1; Thu, 2 Dec 2021 23:07:02 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 29E052E8152B; Thu, 2 Dec 2021 23:07:02 +0100 (CET) Date: Thu, 2 Dec 2021 23:07:02 +0100 From: Mark Wielaard To: Eduard-Mihai Burtescu Cc: gcc-patches@gcc.gnu.org, Nick Nethercote Subject: Re: [PATCH] libiberty rust-demangle, ignore .suffix Message-ID: References: <20211202171713.15454-1-mark@klomp.org> <003e2dd7-5efa-4e81-a578-1d031ab5eee5@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003e2dd7-5efa-4e81-a578-1d031ab5eee5@www.fastmail.com> X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 22:07:07 -0000 Hi Eddy, On Thu, Dec 02, 2021 at 07:35:17PM +0200, Eduard-Mihai Burtescu wrote: > On Thu, Dec 2, 2021, at 19:17, Mark Wielaard wrote: > > Rust v0 symbols can have a .suffix because if compiler transformations. > > For some context, the suffix comes from LLVM (I believe as part of > its LTO). If this were a semantic part of a Rust symbol, it would > have an encoding within v0 (as we already do for e.g. shims). The same is true for gccrs or the libgccjit backend, gcc might clone the symbol name and make it unique by appending some .suffix name. > That also means that for consistency, suffixes like these should be > handled uniformly for both v0 and legacy (as rustc-demangle does), > since LLVM doesn't distinguish. The problem with the legacy mangling is that dot '.' is a valid character. That is why the patch only handles the v0 mangling case (where dot '.' isn't valid). > You may even be able to get Clang to generate C++ mangled symbols > with ".llvm." suffixes, with enough application of LTO. This is not > unlike GCC ".clone" suffixes, AFAIK. Sadly I don't think there's a > way to handle both as "outside the symbol", without hardcoding > ".llvm." in the implementation. We could use the scheme used by c++ where the .suffix is added as " [clone .suffix]", it even handles multiple dots, where something like _Z3fooi.part.9.165493.constprop.775.31805 demangles to foo(int) [clone .part.9.165493] [clone .constprop.775.31805] I just don't think that is very useful and a little confusing. > I don't recall the libiberty demangling API having any provisions > for the demangler deciding that a mangled symbol "stops early", > which would maybe allow for a more general solution. No, there indeed is no interface. We might introduce a new option flag for treating '.' as end of symbol. But do we really need that flexibility? > Despite all that, if it helps in practice, I would still not mind > this patch landing in its current form, I just wanted to share my > perspective on the larger issue. Thanks for that. Do you happen to know what other rust demanglers do? Cheers, Mark