[clang] [llvm] Add support for template as type parameter (PR #127654)

via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 11 07:04:29 PDT 2025


ykhatav wrote:

> 0x00000042:   DW_TAG_structure_type
>                 DW_AT_calling_convention        (DW_CC_pass_by_value)
>                 DW_AT_name      ("other<int>")
>                 DW_AT_byte_size (0x08)
>                 DW_AT_decl_file ("")
>                 DW_AT_decl_line (6)
> 
> 0x00000048:     DW_TAG_template_type_parameter
>                   DW_AT_type    (0x0000003e "int")
>                   DW_AT_name    ("T")
> 
> 0x0000004e:     DW_TAG_member
>                   DW_AT_name    ("v1")
>                   DW_AT_type    (0x0000006d "trait<int>::type")
>                   DW_AT_decl_file       ("")
>                   DW_AT_decl_line       (7)
>                   DW_AT_data_member_location    (0x00)
> 
> 0x00000057:     DW_TAG_member
>                   DW_AT_name    ("v2")
>                   DW_AT_type    (0x00000048 "other<int>::T")
>                   DW_AT_decl_file       ("")
>                   DW_AT_decl_line       (8)
>                   DW_AT_data_member_location    (0x04)



> > > Mostly I worry it won't be terribly complete, because it can't work through situations, like this:
> > > ```
> > > template<typename T>
> > > struct trait {
> > >   using type = T;
> > > };
> > > template<typename T>
> > > struct other {
> > >   trait<T>::type v1;
> > >   T v2;
> > > };
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > In this case, v2 can be described as being of type "T" referencing the template_type_parameter, but v1 can't be - because it references trait::type, for instance.
> > 
> > 
> > I believe, in this case, the debug information of "v2" can still be improved and align with DWARF v5
> 
> Right - like I said, I get that "v2" gets better, but "v1" doesn't, right? And I imagine many/(most?) uses of type parameters in templates are more complicated - so I'm not sure how much this helps, and will feel awkwardly inconsistent for DWARF consumers/users?
> 
I am not sure that I understand your concern completely. Consider the following DWARF output based on my implementation. How would you say "v1" should be represented ideally?
`0x00000042:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("other<int>")
                DW_AT_byte_size (0x08)
                DW_AT_decl_file ("")
                DW_AT_decl_line (6)

0x00000048:     DW_TAG_template_type_parameter
                  DW_AT_type    (0x0000003e "int")
                  DW_AT_name    ("T")

0x0000004e:     DW_TAG_member
                  DW_AT_name    ("v1")
                  DW_AT_type    (0x0000006d "trait<int>::type")
                  DW_AT_decl_file       ("")
                  DW_AT_decl_line       (7)
                  DW_AT_data_member_location    (0x00)

0x00000057:     DW_TAG_member
                  DW_AT_name    ("v2")
                  DW_AT_type    (0x00000048 "other<int>::T")
                  DW_AT_decl_file       ("")
                  DW_AT_decl_line       (8)
                  DW_AT_data_member_location    (0x04)`
> > > Also, I'd worry that most debuggers/DWARF consumers aren't ready to handle type references to template_type_parameters? So best to test this with at least LLDB and GDB before we commit it.
> > 
> > 
> > While I acknowledge that current debuggers may not fully support this DWARF representation, I suggest that this implementation be controlled by a switch until downstream tools are updated to accommodate these changes.
> 
> Yeah - not sure it rises to the level of needing a flag (flags are a bit of an unfortunate maintenance burden - means more DWARF variety, harder to know everyone's doing the same thing, etc... ) - but some testing ahead of time would be good.

My main aim of keeping this implementation behind a flag is that the current implementation crashes lldb and gdb gives the following output. Mostly because they don't handle the template type parameter represented as type:
`$1 = {
val_ = <unknown type in /llvm-project/test.exe, CU 0x0, DIE 0x40>, val2_ = 3}`


https://github.com/llvm/llvm-project/pull/127654


More information about the cfe-commits mailing list