[Dwarf-Discuss] qualifier modifier type tags vs type signatures

[Mark Wielaard]

On Thu, 2014-09-25 at 11:04 -0700, Michael Eager wrote:
> On 09/25/14 08:18, Mark Wielaard wrote:
> > This came up on the gcc list when extending the number of DWARF type
> > qualifier modifiers that are handled. But the issue can be shown with
> > just const and volatile.
> >
> > The issue is that there is no ordering constraint on the type qualifier
> > modifier tags (they can appear in any order), but the type signature
> > computation for type units depends on an flattened ordered DIE tree to
> > get the same signature for the same type from different compile units.
> 
> The C/C++ languages do not place any ordering restrictions on these
> qualifiers (or on a number of other qualifiers).
> 
> 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. 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. On
itself this wouldn't be a problem of course, since the ordering in the
DWARF representation can normally be ignored. But since the order in
representation does matter to other things. Like for the DWARF type
signatures or for tools (like dwz) that work on the language independent
DIE tree representations, the forced ordering cannot really be ignored.

> > I think what GCC does when constructing the DIE type trees is correct.
> > It creates the most efficient type tree in both compile units. To create
> > type trees that look the same in flattened form in both compile units it
> > would have to add extra type trees (a volatile -> int in one or a const
> > -> int in the other) that aren't used otherwise. And it cannot really
> > know which ordering is preferred across all compilation units up front.
> 
> 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.

> > 1) DWARF could prescribe an ordering to use when multiple qualifiers
> > type tags are in used. This might cause producers to create some extra
> > type trees if different subsets of type qualifiers are used, but if type
> > units are used, it might lead to a couple more types to share the same
> > signature.
> 
> DWARF is descriptive, not prescriptive.
> 
> Both DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type and
> DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type are valid
> descriptions.
> 
> That these both describe the same type in C/C++ is a language issue.
> Conceivably there might be a language which does not have this same type
> equivalence.

Right. So with the current representation of ordered qualifiers we would
need a description whether the DWARF DIE type ordering matters per
language.

> > 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.

> > 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.

Cheers,

Mark