On 09/26/14 00:43, Mark Wielaard wrote:
On Thu, 2014-09-25 at 11:04 -0700, Michael Eager wrote:
A DWARF producer is free to generate DWARF in any fashion which
accurately describes the source and compilation process. If you want
to adopt a 'const' before 'volatile' convention (alphabetical) you
are welcome to do so, but there is no requirement to do this.
Correct. That is indeed the problem.
No, this is a design goal of the DWARF standard, not a problem.
> DWARF only has an ordered
representation of the type qualifier concept. That forces producers to
make a choice of ordering even if that doesn't really make sense.
Indeed, the orderings do make sense. One common use is that they
reflect the source ordering.
What DWARF does not do is impose a design decision which works best for
one producer on all other producers.
On
itself this wouldn't be a problem of course, since the ordering in the
DWARF representation can normally be ignored.
In general, this is not true.
DW_TAG_const -> DW_TAG_pointer_type -> DW_TAG_base_type
is not the same as
DW_TAG_pointer_type -> DW_TAG_const -> DW_TAG_base_type
Alternately, GCC could have a set of pre-computed DIE type trees in
preferred order and use a matching equivalent when it generates DWARF.
Right, but that would not be optimal when you have multiple types with
multiple qualifiers. You'll end up with extra unused type DIE trees in
the compile unit because DWARF forces the producer to choose an ordered
representation. It might be the best we can do though given the current
situation, depending on what optimization you prefer.
Don't output the ones you don't use.
Optimization is a Quality of Implementation issue. I'm not advocating any
particular design for GCC or any other producer. If there are different
ways in which a producer can perform an optimization, then each producer
should be free to pick the one which they use.
Right. So with the current representation of ordered qualifiers we would
need a description whether the DWARF DIE type ordering matters per
language.
DWARF contains DW_AT_LANGUAGE which specifies the language. Any dependency
that the producer or consumer might have on the specific language should be
handled by interpreting this code.
2) The Type Signature Computation could be changed to understand that
type qualifier tags pointing to each other need to be sorted first. This
makes the algorithm a little trickier, but means less different type
trees in the compile units.
This would mean embedding an understanding of C/C++ type equivalence
into the type signature computation. DWARF is intended to be language-
neutral, and, in particular, avoid hidden language dependencies.
Indeed. I don't see how with the current DWARF representation of type
qualifier modifiers we can express the language type equivalence rules
in a way that would avoid having language specific dependencies like
this.
See above. DWARF does not specify language semantics, whether type
equivalence or any other feature.
DWARF only describes the transformation between source and object. Anything
which is defined elsewhere, such as language specification, machine description,
OS ABI, and so forth, are described in their respective standards, not in DWARF.
3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
tags and replace them with one DW_TAG_qualified_type tag with either
separate DW_AT_const|volatile|restrict|atomic flag attributes or a
DW_AT_qualifiers attribute that indicates the combined qualifiers
(const, volatile, restrict, atomic). That removes the whole ordering
issues, so it doesn't matter in which order the DIE chain is flattened.
The deadline for DWARF Version 5 proposals passed long ago.
Lets table the fix for DWARF.Next then. It is just an issue that came up
now. I don't think it is super urgent to be fixed right away. It has
been this way for years. But eventually it would be nice to make it
possible to express type qualifiers and type equivalence in DWARF in a
cleaner, more language independent way.
If there is an argument that DWARF needs to express a language feature,
such as type equivalence, which is internal to the producer and (as far
as I can see) irrelevant to the consumer, then indeed, a language-independent
approach would be appropriate. So far, you have said that you want
this change to address an internal design issue.
This is QoI issue, not one of DWARF functionality or descriptive ability.
If I can come up with different designs to address your QoI concern in the
time it takes to reply to an email, I can't see that this warrants a change
in the DWARF standard.
--
Michael Eager ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
