https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
Simon Marchi <simon.marchi at polymtl dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simon.marchi at polymtl dot ca
--- Comment #7 from Simon Marchi <simon.marchi at polymtl dot ca> ---
I volunteer to bring an issue to the DWARF committee to clarify this. I'd like
to gather feedback about how you think it should be fixed. There is already
the non-normative text:
If one of the DW_FORM_data<n>forms is used to represent a signed or
unsigned
integer, it can be hard for a consumer to discover the context necessary to
determine which interpretation is intended. Producers are therefore
strongly
encouraged to use DW_FORM_sdata or DW_FORM_udata for signed and
unsigned integers respectively, rather than DW_FORM_data<n>.
... so I am afraid that any attempt at addressing this problem will be met with
a "it's a quality of implementation issue", but I think it's worth trying. I
think it would be better if DWARF didn't allow being ambiguous.
So far my understanding is the problem is: you could have an attribute, let's
say DW_AT_const_value, with form DW_AT_data1, and value 0x80. As a consumer,
how do you know if that 0x80 means -1 or 128? You could have compiler-1 people
saying "it should obviously be interpreted as a signed constant" and compiler-2
people saying "it should obviously be interpreted as an unsigned constant".
And then, as a consumer, you are in a pickle.
Here are some ideas on how to fix it:
1. The easy way: remove the DW_FORM_data<n> forms from the constant class.
This only leaves DW_FORM_udata and DW_FORM_sdata, which are define the
signedness explicitly. The advantages: it's an easy change for everybody (in
the spec, in producers, in consumers). How many ways of describing a constant
does DWARF really need? The downside is obviously a possible increase in debug
info size. But would it be significant? I would like to prototype it an see
how many values in a real-world DWARF file would now take an extra byte because
of this.
2. A more complicated way: for each attribute that can be of the constant
class, define a default signedness (I imagine an extra column in Table 7.5:
Attribute encodings). If the form does not specify the signedness (i.e.
DW_FORM_data<n>), then the consumer would refer to that table to know if the
value should be treated as signed or unsigned.
Any other ideas?
