From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2O3BNiRuyGO6vxkAWB0awg (envelope-from ) for ; Wed, 18 Jan 2023 17:09:40 -0500 Received: by simark.ca (Postfix, from userid 112) id DE1811E128; Wed, 18 Jan 2023 17:09:40 -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=wdPKLL0L; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=unavailable 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 97A361E112 for ; Wed, 18 Jan 2023 17:09:40 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 48A23385843E for ; Wed, 18 Jan 2023 22:09:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48A23385843E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674079780; bh=4kmr4ndqEVIlPuHMIM1gtQxJS7UKgRVZp5RB3zEsv8g=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=wdPKLL0L0a60W0+X6fNsSfcWRphPLWu4Nq5SlS+lTh+yK17QvKzxgbBl3BHCIyRob xMqqcQhM0kRapf5j9RaPJuaemaFh/y2az4CpIv+eRpjTp7SZA3IOGETGT/bTS7ItIc aOwniDhfkUULXdr7E3eXIDRVnzG0nnnr+CUljysY= Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 6EC043858C52 for ; Wed, 18 Jan 2023 22:09:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6EC043858C52 Received: by mail-oi1-x233.google.com with SMTP id s124so224158oif.1 for ; Wed, 18 Jan 2023 14:09:07 -0800 (PST) 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=4kmr4ndqEVIlPuHMIM1gtQxJS7UKgRVZp5RB3zEsv8g=; b=UD9AncvbsGivuQzbwwk+mrdzHbDz2TuXZNp9XJ+IZOV5Db/rva4C1VaEInNSwz21Mw 6U0nRNpSI4Hby58zGDhLYGuOuh5BcZgw4V1WpmJvsbu376ldTYDFXw38sqGS9x7XmJrU JlPwCtzy4vx0n9tEyO+BJt1Yjm/BDLaWQRUq2/7EAakS7x4H3U+rEefGjOyCBpaPyFcz R0fQsiYIDDo8OCzzbrOibDGDf0tu68ep85gKWqJjWIAFSAlm512e1bedGExnJ0JC3LrP 8H6A4Hcbz1xxB5DteTvU06OhapD9WBlmDoZG+ZgN+MgwxCWfRAqrCiDF7RJM7WB7PYJz sNgg== X-Gm-Message-State: AFqh2kqOmp7GCnklimNeIeQHV7ZVRVZVcPiwYxaf7QsqPpbqVUKyrEB4 VV9F1zxfvAM8RcqcGePcu0hXzVehD/fllPoKspQ= X-Google-Smtp-Source: AMrXdXtAoxVBiMbfB1rBtif4AGTzIzNXGndLGlTzZzAi+GqfDJQe0r0wR4d0HR9PlFC7RhBgDkkYRRjP96gExNMeyCA= X-Received: by 2002:a05:6808:201f:b0:35b:3f80:32e8 with SMTP id q31-20020a056808201f00b0035b3f8032e8mr360808oiw.177.1674079746644; Wed, 18 Jan 2023 14:09:06 -0800 (PST) MIME-Version: 1.0 References: <525f9315-27f1-935a-4e5e-4a043b24eecf@simark.ca> <87pmbgq2s0.fsf@tromey.com> <4fd385ad-fa48-7fab-0131-d24ae2db45a9@simark.ca> In-Reply-To: <4fd385ad-fa48-7fab-0131-d24ae2db45a9@simark.ca> Date: Wed, 18 Jan 2023 14:08:55 -0800 Message-ID: Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name To: Simon Marchi Cc: Tom Tromey , Simon Marchi via 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" On Mon, Jan 16, 2023 at 1:18 PM Simon Marchi wrote: > > > 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. > > This is my understanding of what you are saying. Save the name without > the template part in the cooked index, but attach to it a data structure > that describes the template parameters. When the user types, let's say, > "b my_class::my_method", "my_class" gets translated to > the name "my_class" plus a description of the concrete arguments (the > type argument "int" and the value argument 2). Then, when checking if a > given CU should expanded, and we have a match for the "my_class" name, > we compare the data structures describing the parameters to the one > describing the arguments, see if it's really a match. Does that sound > right? That's more or less what we did in lldb - though we do do both lookups (try "t1" because that's what we have on hand (need to be able to create that from the DIEs to show something good to the user anyway) and if that doesn't find any results, try "t1" then filter out the results looking for the equivalent of "t1" based on the DIEs/some processed data structure from the DIEs). It'd be really good/important for us to all agree on what goes in the index so that .debug_names can be effectively portable. I think the goal should be that if the template has a simplified DW_AT_name, then the index entry should be similarly simplified (that's what Clang does for now, at least & what the DWARF spec says to do, I think/assume (even if it doesn't speak about template naming)). > I'm just a bit worried that it might be difficult to implement this "is > there a match function", given the complex rules of C++ template > deduction. But maybe it's not so bad, or we already have that logic > somewhere. Yeah, in lldb I think we're doing that based on the string we would use to show to a user - which in lldb's case is from Clang's AST generated from DWARF DIEs, but it doesn't matter too much how you do it, as you say, there's already some logic to do that in the debugger to show users a name string - so check that between instantiations to check they're the same entity.