In thinking about the new attributes which we're proposing
(DW_AT_Allocated, DW_AT_Associated) which can get their values from a
stack engine, it crossed my mind that maybe there's a more general
proposal lurking here which could subsume these and provide a way of
allowing different compilers and languages to extend the debug
information without requiring future DWARF extensions.

Suppose we were to add a new DIE, something like this

DW_TAG_attribute_definition

This takes as arguments
    DW_AT_name
    DW_AT_type
and a new attribute
    DW_AT_tag with some form suitable for encoding an attribute number.

The effect of this is to educate the debugger about a new DWARF
attribute which can then be used in later type definitions.

The "tag" gives the value of the DW_AT number which will be used to
encode this new attribute.

The name gives the name of the attribute which should be used when
displaying it to the user.

The type lets the debugger know how to display the value of this
attribute. (Use of enum types here may be particularly useful).

These DIEs would be owned by a compilation unit, as usual, and the new
attributes would only be valid inside the compilation unit. (You need
this to avoid name conflicts).

When such an attribute is _used_, it will use the same schemes which
we have already been discussing to generate a value, so either

1) It can have a constant value immediately present
or
2) It can have a stack engine immediately present which will generate the
   value of the attribute
or
3) It can have a reference to a stack engine elsewhere in the DWARF
   which will generate an address from which to fetch the attribute
   value.

What this new DIE allows is for compilers to educate debuggers about
attributes which can then be displayed to users in a meaningful way,
without the debugger having any understanding of the attribute at all.

Of course, we'd also need to reserve some space in the attribute
encoding for these "dynamic" attributes (this needs to be a different
space from the already reserved LO_user to HI_user space, of course).

This does not introduce any compatibility problems, since an old
debugger will simply see DIEs and attributes which it doesn't
understand, but knows how to skip, and that's what it is supposed to
do.

I see the benefits of this as

1) It allows compiler writers to produce more useful display of run
   time structures without requiring debugger changes.
2) It removes the need for new DWARF extensions where all that is
   required is the ability to display things to users.

I think the real question is whether we believe that there are many
attributes of objects which the user wants to see, but the debugger
need not understand ?

Although interesting, the committee did not feel that there was a compelling reason to adopt this proposal.