dwblaikie wrote:
> 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")
> 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)
> ```
That's basically my point, sorry, that v1 must be represented as
"trait<int>::type" (because it has to be canonical) and so if many uses, like
this one, of a type in a template can't reference the
DW_TAG_template_type_parameter, because it's non-canonical - I'm not sure
there's a lot of value in making it work for the subset of cases where it is
workable.
> My primary reason for placing this implementation behind a flag is that it
> currently causes LLDB to crash and results in the following output from GDB.
> This is largely due to the fact that these debuggers do not yet support
> handling template type parameters represented as types: `$1 = { val_ =
> <unknown type in /llvm-project/test.exe, CU 0x0, DIE 0x40>, val2_ = 3}`
Ah, thanks for testing. Yeah, that makes me similarly less inclined to pursue
this direction.
I'd say unless there's some specifically valuable feature that hinges on this
representation change, I'm not super inclined to put this into Clang at the
moment. Other folks/reviewers might have other perspectives, though.
https://github.com/llvm/llvm-project/pull/127654
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits