From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by sourceware.org (Postfix) with ESMTPS id 4815D3858C52 for ; Wed, 18 Jan 2023 22:04:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4815D3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-142b72a728fso494437fac.9 for ; Wed, 18 Jan 2023 14:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vV5mrkB+0SNopBAl5xoqVlRdyRA5+/xJpxo94dO4wHg=; b=qmg5RaEbxzHp1dvVDEvCNO8zn92hFXoCpMG5yYAz8DZJXhlX6DMfSaEAjBb/cMR0cT at7zAyU5iJP6dk/8vvPZyblLCs41M/uP/BVdv1DcKKukJFAb4uTBMCHlBsa95ZLdlbGc 3xBpxjC4SED6wH97klqCF/dJhN+AOPaF2gpX39VfBWnOvyNw2CC+OgbKoQf0iGbfCY+G eUBTJNFGtqZaQEF/SNXx/YJR7LMbkzdTGX7izSpajFyqnkAjGXt8mWan1daQI3yVc64+ +yrYlz1R3mlik8Bsmvbk85kWRiqM+QzWfWB1BF1LdK2gprrrODfJGtZhURiwVlnT3jIM 2Rtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vV5mrkB+0SNopBAl5xoqVlRdyRA5+/xJpxo94dO4wHg=; b=FBI3AIrS1WtdoeWDkrnRKhuwxHr+M2VZl6NLkDaUpu+mO/n0hENHwlyw9estnzNOsj RIaXOrxlkFIVRc9az7LUACDrgLGzPGqORmFhVZ59rCcLvVa77INa0biJjdzTbwIgoeqH 16uASff7dYXWZ4eSLCoEBoY4zVyQku5cW1Y9IxMGHUmzcOI+LZVpxkhmgHpUaNi+DX0R J+ATQcXFJUkBjP05Eb2HwFV8uw+7ijAn6MbhUNOgiOIrUfj594WXG1EvQ8oa2nGD3syU qHrXENJsDaQC3bUWztOh1U2AmThuHscV4bjICg+ZZlQ+ifbZIGPQpW8den9RoZr0toaM PlSw== X-Gm-Message-State: AFqh2kpcU3ys9QsLYSH44sKNJJrTqYQboTHs75OSRc+H9beK0tAdENgp KF80OfZeiDBl/NP5VGCDDvO200EdAgYwSbA6TQYGh0Em X-Google-Smtp-Source: AMrXdXuZa/M2PqUoFqFDOF3I2GeZLK3HRYYzWFRUZ73+oNEwBwfKx+Jr8SpTX2jESJ1QkYXPRoIVPW3IPBQivV4oAfw= X-Received: by 2002:a05:6871:6a96:b0:150:2665:677a with SMTP id zf22-20020a0568716a9600b001502665677amr461292oab.177.1674079481660; Wed, 18 Jan 2023 14:04:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Blaikie Date: Wed, 18 Jan 2023 14:04:30 -0800 Message-ID: Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name To: Simon Marchi Cc: gdb Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 List-Id: On Wed, Jan 11, 2023 at 6:32 PM Simon Marchi wrote: > > > Yeah, this is a case where DWARF is like "here are some tools you > > could use to express some language features, have at!" and doesn't say > > "to describe this particular language feature you must use DWARF in > > this particular way" > I just found this: > > http://wiki.dwarfstd.org/index.php?title=Best_Practices#Names_of_Program_Entities > > For template instantiations, the DW_AT_name attribute should contain > both the source language name of the object and the template > parameters that distinguish one instantiation from another. The > resulting string should be in the natural form for the language, and > should have a canonical representation (i.e., different producers > should generate the same representation). For C++, the string should > match that produced by the target platform's canonical demangler; > spaces should only be inserted where syntactically required by the > compiler. > > Of course, it's not normative. According to the wiki history, this > particular bit was added by Cary Coutant, in case you want to ask him > why it is considered best practice. > > I Googled bits of the previous quote, and found this bug about template > string canonicalization, and not including template parameters in the > string: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845#c8 > > And this one, that sounds like the 2 vs 2u thing I talked about earler: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 > > Ah, and the thread that was on the GDB list about that: > > https://inbox.sourceware.org/gdb/CAATAM3ED7B3wEJFmaZA_MaOtN5EGKSGFmusAf-Mg5hX35D2r6A@mail.gmail.com/ > > And the corresponding one on llvm-dev, to which you participated: > > https://lists.llvm.org/pipermail/llvm-dev/2018-March/121541.html > > It's not all relevant, but I re-read those to remember what the trouble > with the name strings with template parameters was. > > My thought on all this is that if the name strings with template > parameters are not reliable and take a lot of space, and the same > information is described in a more structured way (as DIEs), then it > makes sense to drop the parameters from the string. Yeah, though I'll be the first to admit that the DIEs aren't perfect either - there's a bunch of cases I opted out of the name simplification (keeping their full name) because the DIEs weren't adequate to reproduce the original name (in an effort to be conservatively correct - in some cases it's the original name that's the problem (some of those I fixed, some were too complex for me to fix immediately, so I punted on them and kept the unsimplified name) - lambdas, operator overloads come to mind, but there were some others). It'd be good to get those DIE issues fixed, imho & then be able to rely on simplified names uniformly. (also as I mentioned in the bug I filed about the simplified names + index, there's a bunch of inconsistencies here with both Clang and GCC about alias templates and variable templates, as to whether they get simplified or unsimplified names and whether they get DIEs or not... :/ )