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

[Michael Eager]

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	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077