Ah, I see, that makes a lot of sense. However, I have a couple questions:
The DW_AT_type of v1 and the DW_AT_type of t2<int>::m1 would need to point
to the same DIE, otherwise there would be much confusion about these being
different types, but being the same type in the DWARF
Would a level of indirection here cause that much confusion? Consumers could
effectively treat it like a typedef, if they wanted to get the concrete type
they could just follow the template type. I'm guessing this probably conflicts
with a lot of existing software and style though.
So in this example:
v1 -> [struct t1<int>]
m1 -> T2 -> [struct t1<int>]
For software consuming dwarf right now, can we assume that the type referenced
is always the concrete type, or should we account for the indirection that is
described in the spec? Ideally consumers should be able to handle both, but
not having an impelmentation makes things a little more difficult.
Lastly, would it be possible to modify the example in future versions of the
spec to limit confusion, or at least add a note saying that that behavior is
optional?
Thanks,
-Jay
David Blaikie writes:
"quality of implementation" thing - but in general, even if a few bugs were
fixed/improvements were made to both Clang and GCC, it's going to be
hard/impossible to track certain things through templates in DWARF - for
similar reasons that it's hard to provide diagnostic messages that describe
types in the way the user wrote them (not impossible in a few cases - Clang
and GCC are getting better at saying "std::string" often instead of
"std::basic_string<...>" for instance)
For instance - if you had a member that was an instantiation of another
template:
template<typename T1> struct t1 { };
template<typename T2> struct t2 { t1<T2> m1; };
t1<int> v1;
t2<int> v2;
The DW_AT_type of v1 and the DW_AT_type of t2<int>::m1 would need to point
to the same DIE, otherwise there would be much confusion about these being
different types, but being the same type in the DWARF - so that type
description can't mention T2 (because T2 has nothing to do with t1<int>) so
there's no way to describe that use of T2, for instance.
Basically: Due to necessary canonicalization, this isn't doable in general,
so compilers don't bother doing it at all - roughly?
On Thu, Apr 9, 2020 at 10:37 AM Jay Kamat via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
I wasn't on the list when I originally sent this message, and it didn't
show
up in the archive, so I'm sending it again. Sorry if there's duplication:
Hi!
I'm currently working on a debugger which consumes dwarf information
and I noticed a possible discrepancy between output from popular
compilers (gcc, clang) and the DWARF 5 and 4 spec.
In section 'D.11 Template Example' for the given source:
template<class T>
struct wrapper {
T comp;
};
wrapper<int> obj;
It says:
The actual type of the component comp is int, but in the DWARF the
type references the DW_TAG_template_type_parameter for T, which in
turn references int. This implies that in the original template comp
was of type T and that was replaced with int in the instance.
And this is reflected in the example output:
11$: DW_TAG_structure_type
DW_AT_name("wrapper")
12$: DW_TAG_template_type_parameter
DW_AT_name("T")
DW_AT_type(reference to "int")
13$: DW_TAG_member
DW_AT_name("comp")
DW_AT_type(reference to 12$)
Where the 'comp' DW_TAG_member has a type referencing to the
DW_TAG_template_type_parameter. However, upon compiling the given
example and dumping the dwarf (gcc 8.3.0, clang 7.0.1), I get:
0x0000085e: DW_TAG_structure_type
DW_AT_name ("wrapper<int>")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("/home/jay/Code/tmp/test/test.cpp")
DW_AT_decl_line (6)
DW_AT_decl_column (0x08)
DW_AT_sibling (0x00000880)
0x0000086b: DW_TAG_member
DW_AT_name ("comp")
DW_AT_decl_file ("/home/jay/Code/tmp/test/test.cpp")
DW_AT_decl_line (7)
DW_AT_decl_column (0x04)
DW_AT_type (0x00000057 "int")
DW_AT_data_member_location (0x00)
0x00000878: DW_TAG_template_type_parameter
DW_AT_name ("T")
DW_AT_type (0x00000057 "int")
Where the 'comp' DW_TAG_member points directly to the "int" type, and
nothing points to 0x878.
The information provided by the indirection mentioned in the spec is
useful, as it lets us determine which members are template parameters
(and could let us reconstruct the original templated type). As is, we
can only tell that there is a template parameter, and that it was
filled with type "int" in this case.
Is there a reason for this discrepancy, and is there anything that can
be done to resolve it? If I'm overlooking something simple, sorry!
Thanks in advance,
-Jay
PS: Sorry if this has already been discussed, but the search function
on the archive seems to be throwing an error:
Unable to read word database file
'/dh/mailman/rank/archives/private/
dwarf-discuss-dwarfstd.org/htdig/db.words.db'
Did you run htdig?
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
LocalWords: impelmentation
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
