Re: PROPOSAL: Restore location list for data member of structure/class

[brender at gemgrp dot zko dot dec dot com (Ron 603-884-2088)]

>0410.3 didn't change any definitions, it was editorial.  It proposed
>descriptions for previous uses of constant.  It doesn't offer any additional 
>ways to distinguish between these constants.  The definition of constant
>was not changed; merely the use of the constant was clarified.  Note that
>it did not restrict the meaning of constant to be less than it was before.

All true.


>Loclist is a description of a use of DW_FORM_data4 and DW_FORM_data8.  
>In current use, with DW_AT_data_member_location, a DW_FORM_data4/8 
>represents offsets from the beginning of the structure.  In your proposal,
>this would not be the case; they would point to a loclist.  This is an 
>incompatible change.

Actually, 302.1 made the incompatible change -- this proposal undoes that!

DWARF Version 2, Section 5.5.4, p41, states:

    [Tag DW_TAG_inheritance] also has a DW_AT_data_member_location
    attribute, whose value is a location description [emphasis added]
                                --------------------
    describing the location of that member relative to the base address
    of the [immediately enclosing] struct, union or class...

Now, recall, there are two kinds of location descriptions (in V2, prior to
410.3):

    . blocks, which represent DWARF expressions
    . constants, which are offsets into the .debug_loc section, which
      identifies an applicable location list.

302.1 changed the interpretation of constant to mean a simple offset from
the base of the object. The ability to identify an applicable location
list was lost as a result of that change.

This proposal, by allowing loclist as a class of value foe DW_AT_data_member_
location, restores that original ability!


>In your proposal, only DW_FORM_data1, data2, sdata, and udata could be used 
>to represent offsets.  

Correct -- that is the intent. But so what? There is no offset that cannot
be represented. Any constant offset that might have used DW_FORM_data4
or DW_FORM_data8, can instead be expressed using sdata or udata (probably
more compactly, too).

Note that these four cannot be used to represent offsets in the .debug_loc
section, even in DWARF V2. Since there is no way to predict how large the
.debug_loc section will end up due to the contributions of other compilation
units, a location list offset must necessarily be relocated by the linker.
There is no way to assume that DW_FORM_data1 and _data2 won't overflow
as a result of relocation, and similarly, there is no way to assure that
_sdata or _udata can be relocated and the result written back in the same
space. As a result, DWARF V2 simply *wastes* these four forms when it
assigns all froms of class constant to encode an offset into another section.

The combined effect of 302.1 and 410.3 is to put those four previously
wasted forms to very good use.


>It appears to me that your proposal has both loclist and constant as 
>permitted types.  Since loclist is a constant, it looks to be ambiguous.

410.3 includes the language that resolves the ambiguity. Specifically, it
says

    [For second paragraph of 7.5.4]:

	"DW_FORM_data4 and DW_FORM_data8 are members of class "constant",
	"lineptr", "loclist" and "macptr". They are members of class
	constant if used with an attribute that allows class constant
	but not class lineptr, loclist, or macptr. They are members of
	--------------------------------------------------------------
	class lineptr, loclist, or macptr, if used for the value of an
	--------------------------------------------------------------
	attribute that allows one of these classes." [Emphasis added.]
	------------------------------------------


    [In the description of constant]:

	"... Note that DW_FORM_data4 and DW_FORM_data8 are members of
	class constant only if the attribute in question does not allow
	one of "lineptr", "loclist" or "macptr".

	[This "note" is nothing more than a direct restatement of the
	rule quoted above.]

In this case, since DW_AT_data_member_location allows both constant and
loclist (in my proposal), the "ambiguity" is resolved -- loclist takes
precedence, if you will.


Bottom line:

  - this proposal is well defined
  - it removes an incompatibility (inability to have location list for
    data members) that we introduced earlier,
  - and does so without compromising the reason (smaller descriptions in
    the most common cases) that we thought this was a good tradeoff in the
    first place.

That is what I mean when I say we get to have it both ways!