From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) by sourceware.org (Postfix) with ESMTPS id 364883858C52 for ; Wed, 18 Jan 2023 22:12:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 364883858C52 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-x31.google.com with SMTP id 586e51a60fabf-1433ef3b61fso510116fac.10 for ; Wed, 18 Jan 2023 14:12:31 -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=1c/FqLuY54g7sIjYuOUg8Aw6fCHerqQg6lfbctraHoo=; b=GSvpG7Bx0uO/zFnTq1KNQjggELBkY2vdSZR88ycQKXG1P9S+rBcDXf3NxXNE466Bgt IUF53k4sNBJpwKyUqQVHJieTJIT/++zBcEPvLVc5uLjFYfGVX6jQmrPt5skFedS3Q1Wf HKfTXmg2aq6N53qAx4eF3sw7XaIW+wPTfzkVyVMSD5AlYe4vayeYYsGjuo4arubGu50q 1SFp03RZEmAbcxmytFCymDapXVSfqsrIbdHu5wZFgVDVH08IBKAQO/5n8Z8mWFOOG4c+ avSlQKa+g7DN9gfQufJtO1Mpb6JEdLwkoGxcyxCrvgsz7c/qAh/slhCTXPlAdarWbpii PVpQ== 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=1c/FqLuY54g7sIjYuOUg8Aw6fCHerqQg6lfbctraHoo=; b=3rZiNPv6+7jL7JhW8Coh5tOGZKxJHM/SHvtTp2IFrDJF6X/B42XPvkSX3RmLPkymMg 9HL/lpTZNXYIcGIS9PXIMHbH8bE+dRtmfvFyG1bMHQJKyLyWKY1Jdk14+vA2bWaxNIvG BRj+bMBH9Vx46I0gKCKFic1Ihnx2F09i+aob55JoqukpsnReKbpDnM8p1MiXa9TzMm3D JvN4LA8mFbBl6p8rkNIPeIs+I9CL3qsgYsgI0Zxu8OTEsYE5lzGPi+WavyD/oX3MHBE/ +zgt4YrYnBQuU3ZoTdf/LnBc/5N7D2AmWhuDj2nQVrbAG8aAr/T0b9RTnT7L35xQ2CDe y/9Q== X-Gm-Message-State: AFqh2koiSelThSzgii27nU+CMG7m3uh8uQp5Wqnaq5zk1BrHjLyEZqYT 8gBuZATD5Kpw+gwJ4MwX7V2ncKdffrURRjx5DTE= X-Google-Smtp-Source: AMrXdXv7e/A+1b7gETOwSx6q6CSfYdDY8uafn4clsQjc7mJxQITCKWmfMaKAxsTA+Xe2a4aRuZ8J/qxwyrQ1yY9FRKI= X-Received: by 2002:a05:6870:80e:b0:15f:18de:58f with SMTP id fw14-20020a056870080e00b0015f18de058fmr631773oab.118.1674079950507; Wed, 18 Jan 2023 14:12:30 -0800 (PST) MIME-Version: 1.0 References: <525f9315-27f1-935a-4e5e-4a043b24eecf@simark.ca> <87pmbgq2s0.fsf@tromey.com> In-Reply-To: <87pmbgq2s0.fsf@tromey.com> From: David Blaikie Date: Wed, 18 Jan 2023 14:12:18 -0800 Message-ID: Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name To: Tom Tromey Cc: Simon Marchi via Gdb , Simon Marchi Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Sat, Jan 14, 2023 at 12:28 PM Tom Tromey wrote: > > >>>>> "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. Agreed. DWARF ends up being more like XML with a library of tags with suggestions at best, but certainly not "this means this and only this" & so debuggers/compilers end up with ad-hoc agreements about how certain features should be encoded. Mostly GCC and GDB get to set that pseudostandard and Clang/lldb for the most part follow suit, though some amount of Clang+LLDB do some things together, moreso on MacOS. I'm always happy to chat more about these things/help set direction on the Clang side, at least. > > 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