[Dwarf-Discuss] DW_FORM_data1 and DW_AT_const_value

Roland McGrath roland at redhat.com
Mon Jul 26 14:59:15 PDT 2010


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.

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.
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.


Thanks,
Roland



More information about the Dwarf-Discuss mailing list