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

[Bruno Larsen]

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