[Dwarf-Discuss] DW_FORM_data1 and DW_AT_const_value

[Michael Eager]

Roland McGrath wrote:
> Here's the way I've always thought about this.
> 
> The clearest way to get an exact target byte pattern in general is just
> to use DW_FORM_block*, which is unambiguous about both the size and the
> contents of the constant block.
> 
> For a quantity that is 64 bits or smaller, you can use constant forms
> instead.  I take any constant form to represent a bit pattern that is up
> to 64 bits wide.  I take DW_FORM_data[124] to be a bit pattern whose
> implicit high bits are all zero.  I take DW_FORM_sdata to be
> sign-extended by SLEB128 rules to 64 bits.  The resulting 64 bits is a
> target bit pattern to be interpreted according to the context of the
> attribute, such as the type indicated by a related DW_AT_type attribute.
> If the quantity of interest is smaller than 64 bits, then the extra high
> bits are ignored.  That bit pattern of the indicated width is then
> interpreted according to the associated DW_ATE_* and the target format
> rules it indicates (i.e. an FP format, an unsigned integer, a signed integer).
> 
> The italicized (and thus non-normative) paragraph that Tom quoted from
> the spec might suggest in a different direction, but it is quite
> ambiguous.  On its face it seems to suggest that the issue of any
> implied high bits (or lack thereof) in DW_FORM_data[124] is known to be
> fuzzy and not really specified.  It's clear to everyone what the meaning
> is for DW_FORM_[us]data, and it "strongly encourages" using only them.

There is a distinction between "ambiguous" and "unspecified".
The interpretation of the value of DW_FORM_data is unspecified.
I don't believe that there is any ambiguity.

> I think it's wise (and is manifest existing practice) to use
> DW_FORM_data[124] freely and be clear that they imply zero-extension.

That is not the interpretation described in the DWARF standard.

> The only reason we have a variety of forms to encode each class is to
> offer compact options for values with few significant bits.  Using
> data[124] can save a byte of encoding space for various ranges of values
> vs always using LEB128.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077