From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by sourceware.org (Postfix) with ESMTPS id 65B6E3857809 for ; Mon, 25 Jul 2022 15:45:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65B6E3857809 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4Ls4BD5MNzz9sW5; Mon, 25 Jul 2022 17:45:24 +0200 (CEST) Date: Mon, 25 Jul 2022 17:45:23 +0200 (CEST) From: ibuclaw@gdcproject.org To: Jan Beulich Cc: Ian Lance Taylor , "gcc@gcc.gnu.org" Message-ID: <1574845149.11500.1658763923107@office.mailbox.org> In-Reply-To: <2c1ee0ba-0dd1-2c70-4bb7-697c551f113b@suse.com> References: <168911bd-ba44-e197-ffd7-c687a6d7eb06@suse.com> <1048129500.281965.1658750733793@office.mailbox.org> <2c1ee0ba-0dd1-2c70-4bb7-697c551f113b@suse.com> Subject: Re: libiberty D tuple demangling MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 15:45:30 -0000 > On 25/07/2022 14:13 CEST Jan Beulich wrote: > > > On 25.07.2022 14:05, ibuclaw@gdcproject.org wrote: > >> On 25/07/2022 08:45 CEST Jan Beulich wrote: > >> while commit 3f30a274913b ("libiberty: Update D symbol demangling > >> for latest ABI spec") mentions in its description that tuple encoding > >> has changed, there's no real adjustment to dlang_parse_tuple() there, > >> nor are there any new (or replaced) test cases for that. Was this > >> simply overlooked? > > > > Is there any specific example that fails to demangle, or are you just skimming? > > I'm merely looking at the code alongside the ABI spec. > > > From what I recall, there is a couple places in the dlang_demangle parser that handle ambiguities in a mangled symbol. The ABI change only added a terminating 'Z', which makes said code that handles ambiguity redundant - but of course kept around so we handle both old and new symbols. > > It's not just the addition of Z at the end but also the dropping of the > number of elements at the beginning, aiui. It's actually that aspect > which caught my attention, since the ABI doesn't talk about any number > there, but the code fetches one. > Went to have a look at docarchives, but it appears to be down (that's on me, I have been meaning to migrate the service to new servers). Yes, your right, the number was indeed dropped too from the ABI. https://web.archive.org/web/20170812061158/https://dlang.org/spec/abi.html#TypeTuple TypeTuple: B Number Parameters https://dlang.org/spec/abi.html#TypeTuple TypeTuple: B Parameters Z However, it gets worse the more I stare at it. Looks like it was not understood what 'Number' meant in the old ABI. I assumed it was the encoded number of tuple elements - same as static arrays - however what I see in the front-end is instead an encoded buffer length. https://github.com/gcc-mirror/gcc/blob/releases/gcc-10/gcc/d/dmd/dmangle.c#L312-L313 So the loop should instead be more like: --- unsigned long len; mangled = dlang_number (mangled, &len); if (mangled == NULL) return NULL; string_append (decl, "Tuple!("); const char *endp = mangled + len; int elements = 0; while (mangled != endp) { if (elements++) string_append (decl, ", "); mangled = dlang_type (decl, mangled, info); if (mangled == NULL || mangled > endp) return NULL; } string_append (decl, ")"); return mangled; --- On top of that, TypeTuple is a compile-time-only type - it never leaks to the code generator - so the grammar entry in the ABI is frivolous (although internally, that it gets a mangle at all would save some memory as duplicated types are merged). Iain.