From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 813203858D20 for ; Thu, 12 Jan 2023 02:32:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 813203858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1A96A1E0D3; Wed, 11 Jan 2023 21:32:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1673490759; bh=aCztXvDudDxCQDT2NJhqLRDWvUHa3UDswGDOD8nR9c8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Xcl7i/oIJJio3q79eEz6I6HRu9R5szykuYlCfwBFO+Dztcu5tifxtacSAEiyvmOLf Y8FEFN+9+lBxWPn8+/E1rCnwIEovNjM3RXHBmJyvwJzW4WrgBDrqlHceC0horuiF1+ 8RitCct9QlKLyNzLFR/C2UlFFbHX3CFdqRw3b0jk= Message-ID: Date: Wed, 11 Jan 2023 21:32:38 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name Content-Language: en-US To: David Blaikie Cc: gdb References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,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: > 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. Simon