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

Mark Wielaard mjw at redhat.com
Thu Jul 10 04:03:26 PDT 2014


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



More information about the Dwarf-Discuss mailing list