[Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types
David Blaikie
dblaikie@gmail.com
Fri Apr 10 23:44:11 GMT 2020
On Fri, Apr 10, 2020 at 4:20 PM Jay Kamat <jaygkamat at gmail.com> wrote:
> 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>]
>
m1 isn't of type T2 though, it's of type t1<T2> - so, mechanically/in more
literal detail, what would that look like in the DWARF?
I think it'd involve introducing a new concept - well, maybe we could use
alias templates as a proxy? but it'd be weird, right - the type DIE
describing t1<T2> has to be able to refer to T2, the template parameter,
but it should probably be scoped wherever t1 is scoped, I guess? it's going
to get pretty weird/unweildy, I'd think, say something like this:
DW_TAG_compile_unit
DW_TAG_structure_type // DIE X
DW_AT_name "t1<int>"
DW_TAG_template_parameter
DW_AT_name "T1"
DW_AT_type "int"
DW_TAG_structure_type
DW_AT_name "t2"
DW_TAG_template_parameter // DIE Y
DW_AT_name "T2"
DW_AT_type "int"
DW_AT_member
DW_AT_name "m1"
DW_AT_type // -> DIE Z
DW_TAG_structure_type // DIE Z
DW_AT_specification // -> DIE X
DW_AT_declaration true // maybe? Not sure
DW_AT_name t1<T2>
DW_TAG_template_parameter
DW_AT_type // -> DIE Y
That seems a bit unwieldy - and unclear /exactly/ how it'd work, so far as
I can tell.
> 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.
>
I think it's probably reasonable for an implementation to support this in
the ways that are simple/easy (when a template parameter isn't used as a
template argument - but just directly like for a member in your original
example) & probably not super hard to support? I could see how an
implementation might do that for a language that doesn't have the
complicated cases C++ does, maybe? Not sure.
> 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?
>
Seems reasonable - I don't know much about how the process of changing the
DWARF spec works. I'm a bit more of an implementor/spectator to the spec
process.
>
> 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 at 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 at lists.dwarfstd.org
> >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> >>
>
> > LocalWords: impelmentation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200410/d1524f6c/attachment-0001.html>
More information about the Dwarf-discuss
mailing list