[Dwarf-Discuss] type qualifiers (Was: Proposal to add DW_AT_alignment)

[Mark Wielaard]

On Thu, 2014-07-10 at 12:48 +0000, Robinson, Paul wrote:
> > There are I think two ways to solve this if we want to make DWARF5 more
> > "future proof" (by which I mean, make it easier for producers to add
> > vendor qualified type extensions and for consumers to easily ignore a
> > type TAG that is a qualifier that may be ignored if not recognized).
> > 
> > 1) We could introduce a DW_TAG_qualified_type tag. The attributes on
> > this tag would express which qualifiers apply to the underlying type
> > referenced by the DW_AT_type attribute.
> > 
> > 2) We could introduce a DW_AT_qualifies_type attribute. Any tag that has
> > that attribute would be a qualified type tag that could be
> > skipped/replaced by the underlying type if not recognized.
> > 
> > Do those proposals make sense? Which one seems easier for
> > producers/consumers to handle?
> 
> I like the idea of future-proofing qualifiers.  A DW_AT_qualifies_type
> flag feels more backward compatible, as it can be easily added to existing
> qualifier tags with essentially no size cost (FORM_flag_present) and should
> be just ignored by older consumers.  And once consumers learn to check for
> the flag, all new future qualifiers can be handled smoothly as well.

O, I hadn't thought about retrofitting existing type qualifier tags,
nice idea. I was mainly concerned about making sure vendor extensions
could add new type qualifiers that consumers that didn't know about them
could easily ignore. I had assumed that consumers would have to use a
hard coded table anyway to support DWARF < 5. And that you would use
DW_AT_qualifies_type instead of DW_AT_type as a DIE ref instead. But for
new Dwarfv5+ consumers it would be nice to have DW_AT_qualifies_type as
flag, plus a "normal" DW_AT_type for all such qualifier tags.

> While DW_TAG_qualified_type might be more generic, it does have a slight
> size cost in that we'd need some sort of qualifier enumeration which in
> turn means each instance of the tag occupies an extra byte. Because many
> qualifiers are sensitive to order, there's probably little to gain by
> inventing a way to represent multiple qualifiers in a single tag (we'd
> still need chains of tags).  So I'm inclined to go with the flag idea.

I think in general qualifiers are not sensitive to order. const volatile
restrict atomic can come in any order and would mean the same. And if
you see typedef as a special "name" qualifier, then I think you can
combine some into one tag. But you'll have to introduce new attributes
for each. So I do agree the flag attribute is the best approach.

I can write up formal proposal for this, but don't know what the best
way to do that is. It would slightly tweak some of the already existing
proposals. Should I just write the proposal as a change as if the
existing new qualifier proposals are already accepted? Or is it better
to take the existing proposals and submit updated variants of them?

Thanks,

Mark