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

[Robinson, Paul]

> On Mon, 2014-06-02 at 14:07 +0200, Mark Wielaard wrote:
> > I'll try to prototype an implementation for GCC this week and see what
> > it looks like in practice so we can discuss things a bit more
> > concretely.
> 
> s/this week/next month/ :) I finally did some prototypes for some of the
> DWARF5 proposals (atomic and alignment type qualifiers) for GCC and GDB.
> I only looked at C for now, so please take a look if they also seem
> useful for other languages like Ada.
> 
> One issue I did find is that DWARF type qualifiers need even more
> coordination between producers and consumers than normally. You also
> cannot easily add them as vendor extensions because consumers cannot
> really ignore them like they could with unknown attributes.
> 
> I also added support for producing DW_TAG_restrict_type for example
> (which already was in DWARFv3). And although GDB did recognize it
> already, I had to adjust three other DWARF consumers to recognize the
> types (valgrind, systemtap and libabigail) or they would be unable to
> recognize the underlying pointer types.
> 
> That is because DWARF type qualifiers are expressed as "wrapper TAGs".
> Which is understandable, because they add "qualifications" to an
> underlying type. The underlying types are compatible in other respects.
> But you cannot easily introduce new qualifier type TAGs because the
> "obscure" the underlying type for the consumer. The consumer has no way
> to recognize which TAGs are qualifiers, except by just looking at the
> "hard coded" list of TAGs given in Figure 15. The consumer cannot easily
> look at the attributes either, because although all qualified type TAGs
> have a DW_AT_type attribute, so do other TAGs, which aren't qualifiers.
> 
> 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.

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

> 
> Thanks,
> 
> Mark
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org