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

[Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org>]

On 04/08/2022 15:03, 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
> 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

Hi Nils,

Thanks for working on this. This version looks OK to me, and is no 
longer failing. I can't approve patches, but it gets a +1 from me

-- 
Cheers,
Bruno