debuginfo: Generate DW_TAG_template_type_parameter DIEs for generic types

[michaelwoerister]

Section 5.5.8 Class Template Instantiations of the DWARF 4 standard says:

A class template instantiation is represented by a debugging information entry with the tag DW_TAG_class_type, DW_TAG_structure_type or DW_TAG_union_type. With five exceptions, such an entry will contain the same attributes and have the same types of child entries as would an entry for a class type defined explicitly using the instantiation types and values.

and later (two of the five mentioned exceptions):

Each formal parameterized type declaration appearing in the template definition is
represented by a debugging information entry with the tag DW_TAG_template_type_parameter. [...]

The class type entry and each of its child entries references a template type parameter entry in any circumstance where the source template definition references a formal parameterized type. [...]

These things are not done yet: For generic types we describe their monomorphized version, losing the information that they stem from a generic definition. In order to fix this issue, the following two things need to be done:

1. Create DW_TAG_template_type_parameter metadata entries for each generic parameter like already done for generic functions.
2. Reference these metadata entries where they are use in the type definition---instead of directly referencing the type they have been substituted by.

[flaper87]

Triage bump... Nothing has been done here yet.

[steveklabnik]

Triage: still no change

[steveklabnik]

Triage: no change

[Mark-Simulacrum]

I'm a little confused by this issue, since gdb seems to indicate the same output from both C++ code (g++ compiled). Perhaps someone could explain what specifically we expect to be different? I've provided C++ and Rust code below as well as gdb output (which is effectively identical). This issue is somewhat similar to #8641 in my opinion.

template<class T>
struct generic {
    T a;
};

struct normal {
    int a;
};

int main() {
    auto generic_t = generic<int> { 10 };
    auto normal_t = normal { 10 };
    return 0;
}

(gdb) info types generic
All types matching regular expression "generic":

File ./test.cpp:
generic<int>;
(gdb) info types normal
All types matching regular expression "normal":

File ./test.cpp:
normal;
(gdb)

pub struct Generic<T: Clone>(T);
pub struct Normal(i32);

fn main () {
    let generic = Generic(10);
    let normal = Normal(10);
    generic;
    normal;
}

(gdb) info types Generic
All types matching regular expression "Generic":

File /tmp/tmp.hAwRDXXf4B/test.rs:
struct Generic<i32>;
(gdb) info types Normal
All types matching regular expression "Normal":

File /tmp/tmp.hAwRDXXf4B/test.rs:
struct Normal;

[Mark-Simulacrum]

We generate DW_TAG_template_type_param today, and I'm not sure if we did before. GDB output remains the same.

 <5><12233>: Abbrev Number: 66 (DW_TAG_template_type_param)
    <12234>   DW_AT_type        : <0x1be6c>
    <12238>   DW_AT_name        : (indirect string, offset: 0x8df78): T

[tromey]

We generate DW_TAG_template_type_param today

Not always, for example in the test case given earlier, I don't see template tags. The DWARF for Generic<i32> is just:

 <2><81>: Abbrev Number: 6 (DW_TAG_structure_type)
    <82>   DW_AT_name        : (indirect string, offset: 0x6e): Generic<i32>
    <86>   DW_AT_byte_size   : 4
    <87>   Unknown AT value: 88: 4
 <3><88>: Abbrev Number: 7 (DW_TAG_member)
    <89>   DW_AT_name        : (indirect string, offset: 0x66): __0
    <8d>   DW_AT_type        : <0xa8>
    <91>   Unknown AT value: 88: 4
    <92>   DW_AT_data_member_location: 0
 <3><93>: Abbrev Number: 0

(Ignore that unknown AT value thing, that's an out-of-date objdump.)

[tromey]

BTW this does affect gdb, see https://sourceware.org/bugzilla/show_bug.cgi?id=21466

[michaelwoerister]

Yes, template parameter descriptions are only emitted for functions and methods. There is no reason why data types should not be supported. It just has never been urgent enough for someone to put time into it.

[tromey]

That was the wrong gdb bug btw, the correct one is https://sourceware.org/bugzilla/show_bug.cgi?id=21893