From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oIqVDb6BB2NAHC0AWB0awg (envelope-from ) for ; Thu, 25 Aug 2022 10:05:50 -0400 Received: by simark.ca (Postfix, from userid 112) id 2B5901E4A7; Thu, 25 Aug 2022 10:05:50 -0400 (EDT) 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=lOvOz9ck; 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=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,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 BAE281E222 for ; Thu, 25 Aug 2022 10:05:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 428BA385482A for ; Thu, 25 Aug 2022 14:05:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 428BA385482A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1661436349; bh=ElSOz+mqEqGSwnW8eqQYAuJPngBCL5RXjIyZ6C1Q6HU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lOvOz9ckrvVl6GISubfW1Fpp0SB1Dws5M1NRjnetktSK8cHGeeXqHZSxOeZCla/Hc 7EkFec6aIFcfFQt/lEJ3+VwppL70Z0/k21EYOmM2gZOETsiEJ+KcAae8Tgvn3yJq+B glZiAT2jyDsAtEvHn7YLDxihw20kg3tqmxT4SrwM= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9C15B3858C2F for ; Thu, 25 Aug 2022 14:05:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C15B3858C2F Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-281-EL8-DkQRM_eGH7YtR-xr3Q-1; Thu, 25 Aug 2022 10:05:21 -0400 X-MC-Unique: EL8-DkQRM_eGH7YtR-xr3Q-1 Received: by mail-ed1-f72.google.com with SMTP id z6-20020a05640240c600b0043e1d52fd98so13156833edb.22 for ; Thu, 25 Aug 2022 07:05:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=ElSOz+mqEqGSwnW8eqQYAuJPngBCL5RXjIyZ6C1Q6HU=; b=woewPpK8Haf38+P7h6/9J+yKfk/QqHmiZ4WTt+qs7LwUQdgC0816sPHqlVK6ltwyhM 1rKwUF2LQtJDtLCupg3LZRE9tWPkX9hl4GJk9kBM/ErQOedE7+E8DC3f53hbCCDs/y2a +UDVvP2YA09vVJAjdFB3TVWnGfdlYjSth46Xb3cis33BeKnFEhw7fmd9C3I1J1HIEMAo MrYoNsKDt5qVw1NrBGjkZLfStyRbB7KAwiN5wwncbWQiDgMO1jVPUWiaRbS4xTn+vx/9 RqqejGQ9V5/tHnl4Y14aI6gaIVwrKXTc5Cb3n+oulKKeDIFn2xwH4C6uWiyRxwf00GA9 zPsA== X-Gm-Message-State: ACgBeo25Nn4BRdwRdbw1FFHtgr2ceV3FCgiZtq5JRABY3K6lv7bn/rjr hER69yxtaMiuBg9JQTnZoNxm3lnNdNdwQTOi5rEGB1F7DMJke3Dr3OuJSUh7uPzwhxgBJcxZVA1 NH/WtcXS1OZmR0cvvcmeqgA== X-Received: by 2002:a17:907:6e14:b0:730:a229:f747 with SMTP id sd20-20020a1709076e1400b00730a229f747mr2757337ejc.202.1661436320157; Thu, 25 Aug 2022 07:05:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR5QFKEiAcCkm9M+WZGfCDn/I3zhrL3XLpSYOQF8yvimZjX9gUy14ZTdz2UYdKt0GVMSI3aT+g== X-Received: by 2002:a17:907:6e14:b0:730:a229:f747 with SMTP id sd20-20020a1709076e1400b00730a229f747mr2757309ejc.202.1661436319873; Thu, 25 Aug 2022 07:05:19 -0700 (PDT) Received: from [10.43.2.105] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id i12-20020a170906698c00b0073c23616cb1sm2589867ejr.12.2022.08.25.07.05.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Aug 2022 07:05:16 -0700 (PDT) Message-ID: <75af27cf-67b5-62cc-1d2d-d3391334e072@redhat.com> Date: Thu, 25 Aug 2022 16:05:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v4 2/2] gdb, dwarf: create symbols for template tags without names To: Nils-Christian Kempke , gdb-patches@sourceware.org References: <20220824091858.1255517-1-nils-christian.kempke@intel.com> <20220824091858.1255517-3-nils-christian.kempke@intel.com> In-Reply-To: <20220824091858.1255517-3-nils-christian.kempke@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Cc: tom@tromey.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 24/08/2022 11:18, Nils-Christian Kempke wrote: > The following GDB behavior was also reported as a GDB bug in > > https://sourceware.org/bugzilla/show_bug.cgi?id=28396 > > I will reiterate the problem a bit and give some more information here. > This patch closes the above mentioned bug. > > The DWARF 5 standard 2.23 'Template Parameters' reads: > > A template type parameter is represented by a debugging information > entry with the tag DW_TAG_template_type_parameter. A template value > parameter is represented by a debugging information entry with the tag > DW_TAG_template_value_parameter. The actual template parameter entries > appear in the same order as the corresponding template formal > parameter declarations in the source progam. > > A type or value parameter entry may have a DW_AT_name attribute, whose > value is a null-terminated string containing the name of the > corresponding formal parameter. > > So the DW_AT_name attribute for DW_TAG_template_type_parameter and > DW_TAG_template_value_parameter is optional. > > Within GDB, creating a new symbol from some read DIE usually requires the > presence of a DW_AT_name for the DIE (an exception here is the case of > unnamed namespaces or the existence of a linkage name). > > This patch makes the presence of the DW_AT_name for template value/type > tags optional, similar to the unnamed namespaces. > > For unnamed namespaces dwarf2_name simply returns the constant string > CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a > case was added to the switch statement calling the > unnamed_template_tag_name helper. Within the scope of parent which > the template parameter is a child of, the helper counts the position > of the template tag within the unnamed template tags and returns > '' where NUMBER is its position. This way we end up with > unique names within the respective scope of the function/class/struct > (these are the only currenltly supported template kinds within GDB and > usually the compilers) where we discovered the template tags in. > > While I do not know of a way to bring GCC to emit template tags without > names there is one for clang/icpx. Consider the following example > > template > class Foo {}; > > template > class Foo; > > int main () { > Foo f; > return 0; > } > > The forward declaration for 'Foo' with the missing template type names > 'A' and 'C' makes clang emit a bunch of template tags without names: > > ... > <2><43>: Abbrev Number: 3 (DW_TAG_variable) > <44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8) > <47> DW_AT_name : (indirect string, offset: 0x63): f > <4b> DW_AT_decl_file : 1 > <4c> DW_AT_decl_line : 8 > <4d> DW_AT_type : <0x59> > ... > <1><59>: Abbrev Number: 5 (DW_TAG_class_type) > <5a> DW_AT_calling_convention: 5 (pass by value) > <5b> DW_AT_name : (indirect string, offset: 0x74): Foo > <5f> DW_AT_byte_size : 1 > <60> DW_AT_decl_file : 1 > <61> DW_AT_decl_line : 2 > <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param) > <63> DW_AT_type : <0x76> > <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param) > <68> DW_AT_type : <0x52> > <6c> DW_AT_name : (indirect string, offset: 0x6c): B > <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param) > <71> DW_AT_type : <0x7d> > ... > > Befor this patch, GDB would not create any symbols for the read template Hi Nils, Thanks for working on this. There is a small typo at the start of this sentence, but other than this, this patch, and the previous one, looks ready to go for me. Let's see if Tromey agrees and approves it. -- Cheers, Bruno