From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from progateway7-pub.mail.pro1.eigbox.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by sourceware.org (Postfix) with ESMTPS id D9D113858D1E for ; Sat, 14 Jan 2023 20:28:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9D113858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw15.mail.unifiedlayer.com (unknown [10.0.90.130]) by progateway7.mail.pro1.eigbox.com (Postfix) with ESMTP id 299DB10042FAA for ; Sat, 14 Jan 2023 20:28:35 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id Gn8lpIrrPxrINGn8lpwMVY; Sat, 14 Jan 2023 20:28:35 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=MrOXV0We c=1 sm=1 tr=0 ts=63c31073 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=lzDhS8hmAAAA:8 a=p4yhxsxNAAAA:8 a=seAiKihsBqBN1cAOXB8A:9 a=skilWyurgcAA:10:demote_hacked_domain_2 a=ul9cdbp4aOFLsgKbc677:22 a=rigQk1bY_8VmChEzA3fK:22 a=4AvGVvso5qoc5vnZhopw:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=b8GcXw718+JraxSlU1xIGRYs3g1UEkprNhW9b/MpV1o=; b=XCDBZwhac53RseRu86nVY6Zqas a6GwmwJChcXy7qcljnyKkAZ2RvDCYQbuZGD9fX+XkLE4nx+CU+6oChyRN+U8IufJkC5nLdyf7bf5r Si9i+X+T8g/c0o6Ad2ldTaWzs; Received: from 97-122-76-186.hlrn.qwest.net ([97.122.76.186]:37636 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pGn8k-0044l8-On; Sat, 14 Jan 2023 13:28:34 -0700 From: Tom Tromey To: Simon Marchi via Gdb Cc: David Blaikie , Simon Marchi Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name References: <525f9315-27f1-935a-4e5e-4a043b24eecf@simark.ca> X-Attribution: Tom Date: Sat, 14 Jan 2023 13:28:31 -0700 In-Reply-To: <525f9315-27f1-935a-4e5e-4a043b24eecf@simark.ca> (Simon Marchi via Gdb's message of "Wed, 11 Jan 2023 20:46:32 -0500") Message-ID: <87pmbgq2s0.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.76.186 X-Source-L: No X-Exim-ID: 1pGn8k-0044l8-On X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-76-186.hlrn.qwest.net (prentzel) [97.122.76.186]:37636 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3021.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Simon" == Simon Marchi via Gdb writes: Simon> Digging in the history leads me to: Simon> https://inbox.sourceware.org/gdb-patches/201007302017.41074.pedro@codesourcery.com/ Simon> So RVCT, the RealView compiler. I don't have access to that, Simon> unfortunately. It seems obsolete, also. I don't like that code. It calls into type_print from the reader, which seems very weird. An approach based on purely traversing the DIE tree seems preferable to me. Anyway, making it work again seems possible. And this time it could have tests. The main thing I would want to avoid here is trying to put this extra name-construction into the indexer. That will just slow it down -- but this is normally the most user-visible slow thing in gdb, and most CUs are of no interest anyway. The downside of this decision is that expansion may expand too many CUs. So for example if there are a million instantiation of template X and the user types "break X::method", gdb might expand every CU referencing X and then still only set one breakpoint. However if this is an issue I think the solution could be to be more selective at expansion time. That is, let the user input "X" match X, but then actually examine the DIE tree to decide if this match should result in an expansion. >>> Is it valid DWARF (5) for DW_AT_name of a templated struct instantiation >>> to omit the template parameters? I don't see DWARF mandating one or the >>> other, so I assume that both including them or not are valid. >> 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" Simon> Typical "DWARF is a permissive standard, not a prescriptive one" thing. For Rust, my view was that a language ought to also have a "binding" to DWARF, to write down how DWARF features are in fact used by the language. DWARF does not really take this view, though, which is why there are a tags with different names but vaguely similar meanings... just one of the many ways that DWARF is bad. Simon> I just found this: Simon> http://wiki.dwarfstd.org/index.php?title=Best_Practices#Names_of_Program_Entities This says it "should have a canonical representation" but neglects to say what that representation should be, so IMO it can't really be relied upon by debuggers. It would be a real improvement to debug reading if the canonical form were in fact reliable across environments -- i.e., proscribed. gdb could avoid all name canonicalization during debug reading, which is a major point of serialization. This affects other languages as well, for example if Fortran and Ada specified a canonical case folding... while this would make gdb output slightly inconsistent with the source, it would also mean we could perhaps sanely handle some situations that are messy today -- see the recent discussion of strcasecmp and Unicode. Though note that DWARF also neglects to specify a Unicode normalization. Tom