[PATCH v4 0/2] Handle unnamed template tags in GDB

[PATCH v4 0/2] Handle unnamed template tags in GDB

[Nils-Christian Kempke via Gdb-patches]

Hi,

please find attached v4 of this series.

v1:
https://sourceware.org/pipermail/gdb-patches/2022-July/190574.html
v2:
https://sourceware.org/pipermail/gdb-patches/2022-August/191210.html
v3:
https://sourceware.org/pipermail/gdb-patches/2022-August/191511.html

Changes since v3 incorporate Tom's comments here:
https://sourceware.org/pipermail/gdb-patches/2022-August/191516.html

Patch 1:
  * No changes
Patch 2:
  * Changed assert and removed nullptr check from while loop condition in
  unnamed_template_tag_name.
  * Use objfile::intern over obstack_strndup.

Thanks!

Nils

Nils-Christian Kempke (2):
  gdb, testsuite: adapt function_range expected name
  gdb, dwarf: create symbols for template tags without names

 gdb/dwarf2/read.c                             |  45 ++++-
 .../missing-type-name-for-templates.cc        |  58 ++++++
 .../missing-type-name-for-templates.exp       | 170 ++++++++++++++++++
 gdb/testsuite/lib/dwarf.exp                   |  12 +-
 4 files changed, 280 insertions(+), 5 deletions(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.cc
 create mode 100644 gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.exp

-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v4 1/2] gdb, testsuite: adapt function_range expected name

[Nils-Christian Kempke via Gdb-patches]

When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.

However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.

The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name.  This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.

An example might make this more clear.  Given the following code

  >> cat c.cpp
  int foo (int a, float b)
  {
    return 0;
  }

  int main (int argc, char **argv)
  {
    return 0;
  }

which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:

  >> clang --version
  clang version 10.0.0-4ubuntu1
  ...
  >> clang -O0 -g ./c.cpp
  >> gdb -q ./a.out -ex "start"
  ...
  (gdb) disassemble main
  Dump of assembler code for function main(int, char**):
     0x0000000000401120 <+0>:     push   %rbp
     0x0000000000401121 <+1>:     mov    %rsp,%rbp
  ...
     0x0000000000401135 <+21>:    ret
  End of assembler dump.
  (gdb) disassemble foo
  Dump of assembler code for function _Z3fooif:
     0x0000000000401110 <+0>:     push   %rbp
     0x0000000000401111 <+1>:     mov    %rsp,%rbp
  ...
     0x000000000040111f <+15>:    ret
  End of assembler dump.

Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:

  >> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
      <2b>   DW_AT_low_pc      : 0x401110
      <33>   DW_AT_high_pc     : 0x10
      <37>   DW_AT_frame_base  : 1 byte block: 56         (DW_OP_reg6 (rbp))
      <39>   DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
      <3d>   DW_AT_name        : (indirect string, offset: 0x42): foo
      <41>   DW_AT_decl_file   : 1
      <42>   DW_AT_decl_line   : 1
      <43>   DW_AT_type        : <0x9a>

Now, let's rename the C++ file and compile it as C:

  >> mv c.cpp c.c
  >> clang -O0 -g ./c.c
  >> gdb -q ./a.out -ex "start'
  ...
  (gdb) disassemble main
  Dump of assembler code for function main:
     0x0000000000401120 <+0>:     push   %rbp
     0x0000000000401121 <+1>:     mov    %rsp,%rbp
  ...
     0x0000000000401135 <+21>:    ret
  End of assembler dump.
  (gdb) disassemble foo
  Dump of assembler code for function foo:
     0x0000000000401110 <+0>:     push   %rbp
     0x0000000000401111 <+1>:     mov    %rsp,%rbp
  ...
     0x000000000040111f <+15>:    ret
  End of assembler dump.

Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:

  >> objdump --dwarf=info ./a.out | grep foo -A3 -B3
      <2b>   DW_AT_low_pc      : 0x401110
      <33>   DW_AT_high_pc     : 0x10
      <37>   DW_AT_frame_base  : 1 byte block: 56         (DW_OP_reg6 (rbp))
      <39>   DW_AT_name        : (indirect string, offset: 0x37): foo
      <3d>   DW_AT_decl_file   : 1
      <3e>   DW_AT_decl_line   : 1
      <3f>   DW_AT_prototyped  : 1

To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range.  This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.

Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
 gdb/testsuite/lib/dwarf.exp | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 3d833e5cd58..b5474ca6ce4 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -391,10 +391,14 @@ proc function_range { func src {options {debug}} } {
     }
 
     # Compute the size of the last instruction.
-    if { $func_length == 0 } then {
-	set func_pattern "$func"
-    } else {
-	set func_pattern "$func\\+$func_length"
+    # For C++, GDB appends arguments to the names of functions if they don't
+    # have a linkage name.  For example, asking gdb to disassemble a C++ main
+    # will print the function name as main() or main(int argc, char **argv).
+    # Take this into account by optionally allowing an argument list after
+    # the function name.
+    set func_pattern "$func\(\?\:\\(\.\*\\)\)?"
+    if { $func_length != 0 } {
+	set func_pattern "$func_pattern\\+$func_length"
     }
     set test "x/2i $func+$func_length"
     gdb_test_multiple $test $test {
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v4 2/2] gdb, dwarf: create symbols for template tags without names

[Nils-Christian Kempke via Gdb-patches]

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
'<unnamedNUMBER>' 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<typename A, typename B, typename C>
  class Foo {};

  template<typename, typename B, typename>
  class Foo;

  int main () {
    Foo<double, int, float> 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<double, int, float>
    <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
tag DIEs and thus lose knowledge about them.  Breaking at the return
statement and printing f's type would read

  (gdb) ptype f
  type = class Foo<double, int, float> [with B = int] {
      <no data fields>
  }

After this patch GDB does generate symbols from the DWARF (with their
artificial names:

  (gdb) ptype f
  type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
  <unnamed1> = float] {
      <no data fields>
  }

The same principle theoretically applies to template functions.  Also
here, GDB would not record unnamed template TAGs but I know of no visual
way to trigger and test this changed behavior.  Template functions do
not emit a '[with...]' list and their name generation also does not
suffer from template tags without names.  GDB does not check whether or
not a template tag has a name in 'dwarf2_compute_name' and thus, the
names of the template functions are created independently of whether or
not the template TAGs have a DW_TAT_name attribute.  A testcase has
been added in the gdb.dwarf2 for template classes and structs.

Bug:  https://sourceware.org/bugzilla/show_bug.cgi?id=28396
---
 gdb/dwarf2/read.c                             |  45 ++++-
 .../missing-type-name-for-templates.cc        |  58 ++++++
 .../missing-type-name-for-templates.exp       | 170 ++++++++++++++++++
 3 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.cc
 create mode 100644 gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.exp

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 84faeb45238..5fb9bfd2d97 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -21919,6 +21919,41 @@ typename_concat (struct obstack *obs, const char *prefix, const char *suffix,
     }
 }
 
+/* Return a generic name for a DW_TAG_template_type_param or
+   DW_TAG_template_value_param tag, missing a DW_AT_name attribute.  We do this
+   per parent, so each function/class/struct template will have their own set
+   of template parameters named <unnnamed0>, <unnamed1>, ... where the
+   enumeration starts at 0 and represents the position of the template tag in
+   the list of unnamed template tags for this parent, counting both, type and
+   value tags.  */
+
+static const char *
+unnamed_template_tag_name (die_info *die, dwarf2_cu *cu)
+{
+  if (die->parent == nullptr)
+    return nullptr;
+
+  /* Count the parent types unnamed template type and value children until, we
+     arrive at our entry.  */
+  size_t nth_unnamed = 0;
+
+  die_info *child = die->parent->child;
+  while (child != die)
+  {
+    gdb_assert (child != nullptr);
+    if (child->tag == DW_TAG_template_type_param
+	|| child->tag == DW_TAG_template_value_param)
+      {
+	if (dwarf2_attr (child, DW_AT_name, cu) == nullptr)
+	  ++nth_unnamed;
+      }
+    child = child->sibling;
+  }
+
+  const std::string name_str = "<unnamed" + std::to_string (nth_unnamed) + ">";
+  return cu->per_objfile->objfile->intern (name_str.c_str ());
+}
+
 /* Get name of a die, return NULL if not found.  */
 
 static const char *
@@ -21954,7 +21989,9 @@ dwarf2_name (struct die_info *die, struct dwarf2_cu *cu)
       && die->tag != DW_TAG_interface_type
       && die->tag != DW_TAG_structure_type
       && die->tag != DW_TAG_namelist
-      && die->tag != DW_TAG_union_type)
+      && die->tag != DW_TAG_union_type
+      && die->tag != DW_TAG_template_type_param
+      && die->tag != DW_TAG_template_value_param)
     return NULL;
 
   switch (die->tag)
@@ -21974,6 +22011,12 @@ dwarf2_name (struct die_info *die, struct dwarf2_cu *cu)
 	return attr_name;
       return CP_ANONYMOUS_NAMESPACE_STR;
 
+    /* DWARF does not actually require template tags to have a name.  */
+    case DW_TAG_template_type_param:
+    case DW_TAG_template_value_param:
+      if (attr_name == nullptr)
+	return unnamed_template_tag_name (die, cu);
+      /* FALLTHROUGH.  */
     case DW_TAG_class_type:
     case DW_TAG_interface_type:
     case DW_TAG_structure_type:
diff --git a/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.cc b/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.cc
new file mode 100644
index 00000000000..06746b533fd
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.cc
@@ -0,0 +1,58 @@
+/* Copyright (C) 2022 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+template<typename first, typename second>
+class template_var1
+{
+  first me;
+  second me2;
+};
+
+template<typename first, typename second>
+class template_var2
+{
+  first me;
+  second me2;
+};
+
+template<int val1, typename first, int val2, typename second>
+class template_var3
+{
+  first me;
+  second me2;
+};
+
+template<typename, typename second>
+class template_var1;
+
+template<typename, typename>
+class template_var2;
+
+template<int, typename, int, typename>
+class template_var3;
+
+int
+main (int argc, char **argv)
+{
+  asm ("main_label: .globl main_label");
+
+  template_var1<int, float> var1;
+  template_var2<int, float> var2;
+  template_var3<0, int, 11, float> var3;
+
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.exp b/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.exp
new file mode 100644
index 00000000000..14339c86ded
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/missing-type-name-for-templates.exp
@@ -0,0 +1,170 @@
+# Copyright 2022 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This tests GDB's handling of DW_TAG_template_type_parameter and
+# DW_TAG_template_value_parameter tags that do not have a DW_AT_name attribute.
+# The attribute is optional for the tags and a bug about GDB not recording
+# the respective symbols (because of the missing name) was reported in PR
+# gdb/28396.
+
+load_lib dwarf.exp
+
+if {![dwarf2_support]} {
+    return 0
+}
+
+standard_testfile .cc .S
+
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+    cu {} {
+	DW_TAG_compile_unit {
+	    {DW_AT_language @DW_LANG_C_plus_plus}
+	} {
+	    declare_labels int float template_var1 template_var2 template_var3
+
+	    int: DW_TAG_base_type {
+		{DW_AT_name "int"}
+		{DW_AT_byte_size 4 DW_FORM_data1}
+		{DW_AT_encoding @DW_ATE_signed}
+	    }
+
+	    float: base_type {
+		{DW_AT_name float}
+		{DW_AT_byte_size 4 DW_FORM_sdata}
+		{DW_AT_encoding @DW_ATE_float}
+	    }
+
+	    DW_TAG_subprogram {
+		{DW_AT_name "main"}
+		{MACRO_AT_range "main"}
+		{DW_AT_type :$int}
+		{DW_AT_external 1 DW_FORM_flag}
+	    } {
+		DW_TAG_variable {
+		    {DW_AT_name "var1"}
+		    {DW_AT_type :$template_var1}
+		}
+		DW_TAG_variable {
+		    {DW_AT_name "var2"}
+		    {DW_AT_type :$template_var2}
+		}
+		DW_TAG_variable {
+		    {DW_AT_name "var3"}
+		    {DW_AT_type :$template_var3}
+		}
+	    }
+
+	    # A variable whose type is a template instantiation with two
+	    # template parameters, one unnamed.
+	    template_var1: DW_TAG_structure_type {
+		{DW_AT_name "template_var1<int, float>"}
+	    } {
+		DW_TAG_member {
+		    {DW_AT_name "me"}
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_member {
+		    {DW_AT_name "me2"}
+		    {DW_AT_type :$float}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_name "second"}
+		    {DW_AT_type :$float}
+		}
+	    }
+
+	    # A variable whose type is a template instantiation with two
+	    # template parameters, both unnamed.
+	    template_var2: DW_TAG_class_type {
+		{DW_AT_name "template_var2<int, float>"}
+	    } {
+		DW_TAG_member {
+		    {DW_AT_name "me"}
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_member {
+		    {DW_AT_name "me2"}
+		    {DW_AT_type :$float}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_type :$float}
+		}
+	    }
+
+	    # A variable whose type is a template instantiation with four
+	    # template arguments, two types, two values, all unnamed.
+	    template_var3: DW_TAG_structure_type {
+		{DW_AT_name "template_var3<0, int, 11, float>"}
+	    } {
+		DW_TAG_member {
+		    {DW_AT_name "me"}
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_member {
+		    {DW_AT_name "me2"}
+		    {DW_AT_type :$float}
+		}
+		DW_TAG_template_value_param {
+		    {DW_AT_type :$int}
+		    {DW_AT_const_value 0 DW_FORM_sdata}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_type :$int}
+		}
+		DW_TAG_template_value_param {
+		    {DW_AT_type :$int}
+		    {DW_AT_const_value 11 DW_FORM_sdata}
+		}
+		DW_TAG_template_type_param {
+		    {DW_AT_type :$float}
+		}
+	    }
+	}
+    }
+}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+	[list $srcfile $asm_file] {nodebug c++}] } {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+gdb_test "ptype var1" [multi_line \
+    "type = struct template_var1<int, float> \\\[with <unnamed0> = int, second = float\\\] {" \
+    "    <unnamed0> me;" \
+    "    second me2;" \
+    "}"]
+
+gdb_test "ptype var2" [multi_line \
+    "type = class template_var2<int, float> \\\[with <unnamed0> = int, <unnamed1> = float\\\] {" \
+    "    <unnamed0> me;" \
+    "    <unnamed1> me2;" \
+    "}"]
+
+gdb_test "ptype var3" [multi_line \
+    "type = struct template_var3<0, int, 11, float> \\\[with <unnamed1> = int, <unnamed3> = float\\\] {" \
+    "    <unnamed1> me;" \
+    "    <unnamed3> me2;" \
+    "}"]
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v4 2/2] gdb, dwarf: create symbols for template tags without names

[Bruno Larsen via 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
> '<unnamedNUMBER>' 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<typename A, typename B, typename C>
>    class Foo {};
>
>    template<typename, typename B, typename>
>    class Foo;
>
>    int main () {
>      Foo<double, int, float> 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<double, int, float>
>      <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

RE: [PATCH v4 2/2] gdb, dwarf: create symbols for template tags without names

[Kempke, Nils-Christian via Gdb-patches]

> -----Original Message-----
> From: Bruno Larsen <blarsen@redhat.com>
> Sent: Thursday, August 25, 2022 4:05 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: tom@tromey.com
> Subject: Re: [PATCH v4 2/2] gdb, dwarf: create symbols for template tags
> without names
> 
> 
> 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
> > '<unnamedNUMBER>' 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<typename A, typename B, typename C>
> >    class Foo {};
> >
> >    template<typename, typename B, typename>
> >    class Foo;
> >
> >    int main () {
> >      Foo<double, int, float> 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<double, int,
> float>
> >      <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

Hi Bruno,

Thanks, yes.. I fixed it locally now.

Cheers,
Nils
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v4 0/2] Handle unnamed template tags in GDB

[Tom Tromey]

>>>>> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> writes:

> Hi,
> please find attached v4 of this series.

Thank you.  This looks good to me.

Tom

RE: [PATCH v4 0/2] Handle unnamed template tags in GDB

[Kempke, Nils-Christian via Gdb-patches]

Hi Tom,

Thanks for the review, I'm checking this in now.

Cheers,
Nils

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Tuesday, August 30, 2022 7:53 PM
> To: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>;
> tom@tromey.com
> Subject: Re: [PATCH v4 0/2] Handle unnamed template tags in GDB
> 
> >>>>> Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org> writes:
> 
> > Hi,
> > please find attached v4 of this series.
> 
> Thank you.  This looks good to me.
> 
> Tom
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928