<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/4/26 6:00 PM, Cary Coutant via
Dwarf-discuss wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJimCsGt6uQW+E0NRZKveWLnZNn6tsZc-9+P4AEwg7uDLJ07Sw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">template<typename
T> struct t1 {<br>
T n1;<br>
};<br>
<br>
template<typename T> struct t2 {<br>
T m1;<br>
t1<T> m2;<br>
};<br>
<br>
int main()<br>
{<br>
t2<int> v1;<br>
return 0;<br>
}<br>
<br>
Based on the current specification, the type of m1 should
reference<br>
a template parameter entry. This is a bug in gcc which has
already<br>
been described [1]. llvm/clang attempted to fix this in PR
[2].<br>
<br>
Also for m2 we can see that there is no information that its
type was<br>
originally described by a template type parameter of t2.
However,<br>
there is no specification addressing this specific case in
the DWARF<br>
Standard.<br>
</blockquote>
<div><br>
</div>
<div>Like Ben, I'm not sure I see why this isn't possible
given the current spec. The type attribute for v1 should
point to a type DIE for t2<int>, which will have a
template type parameter and two data members, m1 and m2.
Briefly:</div>
<div><br>
</div>
<div><font face="monospace">L1: DW_TAG_structure_type (name:
t2<int>)</font></div>
<div><font face="monospace">L2:
DW_TAG_template_type_parameter (name: T, type: ref to
type int)</font></div>
<div><font face="monospace">L3: DW_TAG_member (name: m1,
type: ref to L2) [NOTE 1]</font></div>
<div><font face="monospace">L4: DW_TAG_member (name: m2,
type: ref to type t1<T>) [NOTE 2]</font></div>
<div><br>
</div>
<div>NOTE 1: This is the bug you point out where gcc and clang
don't do what the spec says, and put a ref to type int
instead of to the template type parameter entry.</div>
<div><br>
</div>
<div>NOTE 2: This is the part that may not be so obvious. We
want a ref to a DIE that represents the type t1<T>
rather than t1<int>. I think we can have that, but
that new type entry will need to be a child of the
t2<int> type. Otherwise, it won't be able to reference
the template type parameter entry (technically, it *could*,
but pointing from one type DIE into the interior of another
is ugly, and could conceivably cause problems down the
road).</div>
<div><br>
</div>
<div>
<div><font face="monospace">L1: DW_TAG_structure_type (name:
t2<int>)</font></div>
<div><font face="monospace">L2:
DW_TAG_template_type_parameter (name: T, type: ref to
type int)</font></div>
<div><font face="monospace">L3: DW_TAG_member (name: m1,
type: ref to L2)</font></div>
<div><font face="monospace">L4: DW_TAG_member (name: m2,
type: ref to L5)</font></div>
<div><font face="monospace">L5: DW_TAG_structure_type
(name: t1<T>)</font></div>
<div><font face="monospace">L6:
DW_TAG_template_type_parameter (name: T, type: ref to
type int)</font></div>
<div><font face="monospace">L7: DW_TAG_member (name: n1,
type: ref to L6)</font></div>
</div>
</div>
</div>
</blockquote>
<p>This is a more compact version of what I came up with. I kept on
getting things jumbled up until I changed one of the names of the
template parameters so that I could keep them straight.</p>
<p>There were two twists that I played with as well. These are
probably obvious to other people:</p>
<p>Say there was also a variable with a t1<int> instance
outside of the t2 template. I puzzled for a few minutes about that
and thought is that the same as the t1<T> inside of t2's
instantiation. The other one was I made t3 which also had a
t1<T> inside of it.<br>
</p>
<p>It took me a few minutes but I eventually realized that they were
different types even though they resolved to the same thing
t1<int>. However, m2 was like t2::t1<int> while my
other m2 was really t3::t1<int></p>
<p>From an ABI (libabigail) perspective they were different but
potentially compatible types.</p>
<p>So if there was a function that took t1<int> and somehow
was changed to t2::t1<int> then I at least should warn about
it. However, since the bit representation was the same it should
still work.</p>
<p>I didn't check to see if any current compilers do this but I
could imagine where a compiler could choose to use the same text
region for both:</p>
<p>void foo( t1<int> v);<br>
void foo( t2::t1<int> v);</p>
<p>and I considered how that may affect consumers.</p>
<blockquote type="cite"
cite="mid:CAJimCsGt6uQW+E0NRZKveWLnZNn6tsZc-9+P4AEwg7uDLJ07Sw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>
<div> </div>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Besides missing consumer support (e.g. GDB or LLDB), missing
support for<br>
nested templates was one further reason why the llvm PR [2]
was rejected<br>
by David Blaikie. I discussed this topic with him since I
am working on<br>
the enablement in GDB and submitted a patch series [3] to
support template<br>
type resolution based on the current DWARF specification.
David Blaikie<br>
asked me to submit a DWARF issue for this, since we could
not come up with<br>
a useful specification for the nested case (type of m2 in
the example<br>
above).<br>
</blockquote>
<div><br>
</div>
<div>In the PR, David noted:</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That's
basically my point, sorry, that v1 must be represented as
"trait::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.</blockquote>
<div><br>
</div>
<div>I guess I don't understand the part about "it has to be
canonical". David, can you explain why the approach I used
above wouldn't work for the PR's example with trait::type?</div>
<div><br>
</div>
<div>If we need something canonical (and if I understand what
that means), could we also have a canonical instantiation of
the type for t1<int> at the outermost scope, and add
an attribute to the entry for t1<T> at L5 that points
to that canonical instantiation — maybe call it
DW_AT_canonical_type?</div>
<div><br>
</div>
<div>There's also the concern that the compilers currently
don't generate what the DWARF spec says they should, and if
they did, the debuggers wouldn't be able to handle it. </div>
</div>
</div>
</blockquote>
<p>I'd just say, we file bugs and if they have a compelling reason
we assimilate that into our understanding and THEN if necessary
make changes to DWARF based upon that information.</p>
<p>-ben</p>
<blockquote type="cite"
cite="mid:CAJimCsGt6uQW+E0NRZKveWLnZNn6tsZc-9+P4AEwg7uDLJ07Sw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>And if David's point above is right that we can represent
the simple case, but not the more complex ones, is it worth
doing it even for the simple cases? If the spec is calling
for something that can't be done in the general case, should
we remove it from the spec?</div>
<div><br>
</div>
<div>-cary</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>