Re: [Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types
On Fri, Apr 10, 2020 at 4:20 PM Jay Kamat 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::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]
> m1 -> T2 -> [struct t1]
>
m1 isn't of type T2 though, it's of type t1 - 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 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"
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
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 struct t1 { };
> > template struct t2 { t1 m1; };
> > t1 v1;
> > t2 v2;
> >
> > The DW_AT_type of v1 and the DW_AT_type of t2::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)
> 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
> >> struct wrapper {
> >> T comp;
> >> };
> >> wrapper 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
Re: [Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types
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::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]
m1 -> T2 -> [struct t1]
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 struct t1 { };
template struct t2 { t1 m1; };
t1 v1;
t2 v2;
The DW_AT_type of v1 and the DW_AT_type of t2::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) 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
struct wrapper {
T comp;
};
wrapper 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:
0x085e: DW_TAG_structure_type
DW_AT_name ("wrapper")
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 (0x0880)
0x086b: 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(0x0057 "int")
DW_AT_data_member_location(0x00)
0x0878: DW_TAG_template_type_parameter
DW_AT_name("T")
DW_AT_type(0x0057 "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
Re: [Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types
"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 struct t1 { };
template struct t2 { t1 m1; };
t1 v1;
t2 v2;
The DW_AT_type of v1 and the DW_AT_type of t2::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) 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
> struct wrapper {
> T comp;
> };
> wrapper 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:
>
> 0x085e: DW_TAG_structure_type
>DW_AT_name ("wrapper")
>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 (0x0880)
>
> 0x086b: 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(0x0057 "int")
> DW_AT_data_member_location(0x00)
>
> 0x0878: DW_TAG_template_type_parameter
> DW_AT_name("T")
> DW_AT_type(0x0057 "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
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-Discuss] Discrepancy Between Implementation and Spec in Template Types
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
struct wrapper {
T comp;
};
wrapper 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:
0x085e: DW_TAG_structure_type
DW_AT_name ("wrapper")
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 (0x0880)
0x086b: 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(0x0057 "int")
DW_AT_data_member_location(0x00)
0x0878: DW_TAG_template_type_parameter
DW_AT_name("T")
DW_AT_type(0x0057 "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
