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