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? Thanks, Mark _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
