ykhatav wrote:
> > For template classes with type parameters, the information of which member
> > variables are of a "templated type" is lost. The debugger cannot
> > differentiate between "templated" types and "hardcoded" types. This is
> > because both types have the same debug information, so there is no way that
> > gdb can distinguish between them. This patch adds support for templates as
> > type by representing the template type as a derived type.
>
> What features are you hoping to build on this debug info?
I would say it is more of an improvement in debug information. The current
implementation of Clang generates DWARF debug information that could be
improved for better compliance with DWARF v5 standards. Consider the example
D.11 from DWARF v5. Currently, Clang produces the following DWARF output:
```
0x0000003e: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)
0x00000042: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("wrapper<int>")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("")
DW_AT_decl_line (2)
0x00000048: DW_TAG_template_type_parameter
DW_AT_type (0x0000003e "int")
DW_AT_name ("T")
0x0000004e: DW_TAG_member
DW_AT_name ("comp")
DW_AT_type (0x0000003e "int")
DW_AT_decl_file ("")
DW_AT_decl_line (3)
DW_AT_data_member_location (0x00)
```
Note that the type of variable "comp" directly references "int" instead of
DW_TAG_template_type_parameter.
> 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, it could be represented using DW_TAG_template_type
instead of "int":
```
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.
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
