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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
