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

Mark Wielaard mjw at redhat.com
Thu Jul 17 14:33:59 PDT 2014


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



More information about the Dwarf-Discuss mailing list