From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kXqnB/H+vmPBYxQAWB0awg (envelope-from ) for ; Wed, 11 Jan 2023 13:24:49 -0500 Received: by simark.ca (Postfix, from userid 112) id 1198F1E128; Wed, 11 Jan 2023 13:24:49 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Nuh4aINR; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AEFC31E110 for ; Wed, 11 Jan 2023 13:24:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 52CDF3857400 for ; Wed, 11 Jan 2023 18:24:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 52CDF3857400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673461488; bh=EUFUZmeFWcGGEM0GcKegzsXoCtR8taDlJB1pJ9GcdQA=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Nuh4aINR0S9ZWyfX23UxeCdJAX2S3uwWyIZ6vJAZACkPXcqePGQQePSjxQHJqykXY hfPFVu6yJCPwOztqmr9DSdWeWZx2pPmgy29XdZ/6/tStIZbTutMNe5iTxVAgrrIjsz 55U7EZMg5TCD3YhtYzDnGpN0riby9oSX2aqUcoHw= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 7EE793858C83 for ; Wed, 11 Jan 2023 18:24:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EE793858C83 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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C79B41E110; Wed, 11 Jan 2023 13:24:18 -0500 (EST) Message-ID: Date: Wed, 11 Jan 2023 13:24:18 -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 To: David Blaikie , gdb References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 1/6/23 12:37, David Blaikie via Gdb wrote: > I've been working on reducing debug info size, especially for > expression-template heavy code like in Tensorflow and Eigen. > > To that end, I've implemented the flag -gsimple-template-names in > Clang that simplifies the DW_AT_name for templates by omitting > template parameters (eg: "vector" instead of "vector std::allocator>") when the DW_TAG_template_*_parameters contain > sufficient information to reconstruct the original name. This reduces the length of strings, and more importantly it allows more sharing, is that it? It doesn't change the layout of the DIE tree? > This generally seems to work in GDB - that looks intentional (perhaps > because someone else implemented this feature elsewhere, or just for > canonicalization reasons (the full string with template parameters > might have different whitespace, parentheses, other formatting)), it > seems unlikely that GDB would accidentally be able to connect two > "vector" declarations up to the right "vector" definitions based on > the template parameters without intentional code to support this > scenario. Probably this code: https://gitlab.com/gnutools/binutils-gdb/-/blob/1b9af5b949bff0c750ededb459400c1857fec416/gdb/dwarf2/read.c#L9002 > But one place I found a problem was in pretty printers. I have > situations where a type declaration isn't resolved to a definition > when working within a pretty printer (resulting in the pretty printer > being unable to find member variables in the object/of that type) - > but if I print out the variable/member it works correctly - or if I > "list" the source of the file where the definition of the type is, > then the pretty printer works correctly. > > Does this ring a bell for anyone/sound like something sufficient to > file a bug, or would I need to dig in further to create an isolated > reproduction to help communicate the issue I'm seeing? I have no idea about what happens without digging into the code. I just remember some bug where GDB would generate the templated name with let's say "<5u>" for an integer value template parameter, so if you entered "<5>", it didn't match textually. Maybe something like that is happening. I also found: https://sourceware.org/bugzilla/show_bug.cgi?id=17762 There's the possibility that the "partial symbol" and "expanded symbol" don't have the same name. So you could see a difference in behavior depending on whether the CU has been expanded by GDB or not (I'm just speculating). 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. If so, I think we can consider it a GDB bug if it doesn't process the "without" version correctly. Feel free to file a bug with the relevant background information. It would be useful to include some binaries, one compiled with -gsimple-tempalte-names and one without, so it's easy to compare the two. Simon