https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #5 from Tom Tromey <tromey at gcc dot gnu.org> ---
> If the 64-bit value is
> negative, we emit DW_FORM_sdata, otherwise we emit whatever is smallest
> representation of the positive value (DW_FORM_data{1,2,4,8}, could perhaps
> use DW_FORM_udata).
I think I didn't properly understand this earlier.
If GCC emits "128" as "DW_FORM_data1 0x80", even for a could-be-signed
attribute, then that seems like a real problem.
I did find a spot where GCC does this:
if (bit_offset < 0)
add_AT_int (die, DW_AT_bit_offset, bit_offset);
else
add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT)
bit_offset);
I looked at all calls to add_AT_unsigned and also found this applies
to DW_AT_data_member_location, DW_AT_const_value.
There's also this comment in add_scalar_info:
/* If HOST_WIDE_INT is big enough then represent the bound as
a constant value. We need to choose a form based on
whether the type is signed or unsigned. We cannot just
call add_AT_unsigned if the value itself is positive
(add_AT_unsigned might add the unsigned value encoded as
DW_FORM_data[1248]). Some DWARF consumers will lookup the
bounds type and then sign extend any unsigned values found
for signed types. This is needed only for
DW_AT_{lower,upper}_bound, since for most other attributes,
consumers will treat DW_FORM_data[1248] as unsigned values,
regardless of the underlying type. */
... which to me is just confirmation that this whole area is a mess.
