From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 7kBXNY9cuGNDEREAWB0awg (envelope-from ) for ; Fri, 06 Jan 2023 12:38:23 -0500 Received: by simark.ca (Postfix, from userid 112) id C903D1E222; Fri, 6 Jan 2023 12:38:23 -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=yBvaMT47; 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=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 07C661E112 for ; Fri, 6 Jan 2023 12:38:23 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0C2553858416 for ; Fri, 6 Jan 2023 17:38:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C2553858416 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673026702; bh=dldI4Q117+21fARb4n90nFu2OleeFYR2ICm1i4GRd4M=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=yBvaMT47MNOf+htpP7aeKJ027wJ1CSQWhXJd/JD98tQnTw2NdAr0ly/DJKBiC51+D 17lDrLapmWQRFw7d/j1Rnujtm6hBQacMvhxis/gvHQncnffwkdTa5fCOkqcVsi3k/D NHIOU+vsBrz5pkYJMg0wOA4Q0ZN+cXO8ROfGN5l8= Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 5DF943858D33 for ; Fri, 6 Jan 2023 17:37:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5DF943858D33 Received: by mail-oi1-x22f.google.com with SMTP id i127so1610532oif.8 for ; Fri, 06 Jan 2023 09:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dldI4Q117+21fARb4n90nFu2OleeFYR2ICm1i4GRd4M=; b=tzlY19PVNEbFhW/SXu2sATyQKGLqyfjONawzFEAOh+U8Pdg8HcUvxj1bPlit3UV6tM 4zMXTtQN5om1Crm5JeqWD9a7ew1k6/t8CR+PdoE7iKmLl6qhkotCNnYs96JOZz/Lca9h i6n/1Y3jq/6H/rN3hpEI4q+cWk3PiLyN1U3JZQUDy8FJcko2kmGxA/Qjl+yp00FGPEZr e9tY8fyIi63Xuq88DOEgqTASPnjHNc0xxaVTb9nSQcXREhGotD5l4y8CGPRBjg+oqRco zwa/8KMpgRdFEOslwLhAfQfDNkUC5GwbnoM0VWBsSmJ04igFNFfE8WM/HLjJlEoYQoFF K17Q== X-Gm-Message-State: AFqh2krN15ykwe5knYM3Xxj7GW8CV01aJ+OVIWcpJGdFGhqDvCKtteat dqi2TprAxy+kF1cOEpRhthQZW79Psv/ujPJsTpNV4lMO X-Google-Smtp-Source: AMrXdXv2UPNSGfM88NphZ44P1LRXmurWtCjkwwOlHmgy1ikAoTOHDPa9Y8ASRoHD6esJzDrfMbxSxZrG4Ux5mfuzwJQ= X-Received: by 2002:a05:6808:1385:b0:363:b8c3:a76b with SMTP id c5-20020a056808138500b00363b8c3a76bmr1147705oiw.118.1673026673380; Fri, 06 Jan 2023 09:37:53 -0800 (PST) MIME-Version: 1.0 Date: Fri, 6 Jan 2023 09:37:41 -0800 Message-ID: Subject: Decl/def matching with templates without template parameters in the DW_AT_name To: gdb Content-Type: text/plain; charset="UTF-8" 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: David Blaikie via Gdb Reply-To: David Blaikie Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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>") when the DW_TAG_template_*_parameters contain sufficient information to reconstruct the original name. 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. 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?