[RFA/DWARF] Set enum type "flag_enum" and "unsigned" flags at type creation.

[Mark Wielaard]

On Mon, 2014-01-27 at 08:19 +0400, Joel Brobecker wrote:
> To understand why the range type's upper bound is read as a negative
> value, one needs to look at how it is determined, in read_subrange_type:
> 
>   orig_base_type = die_type (die, cu);
>   base_type = check_typedef (orig_base_type);
>   [... high is first correctly read as 128, but then ...]
>   if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
>     high |= negative_mask;
> 
> The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
> is not set. And the reason for that is because the base_type was only
> partially constructed during the call to die_type. While the enum
> is constructed on the fly by read_enumeration_type, its flag_unsigned
> flag is only set later on, while creating the symbols corresponding to
> the enum type's enumerators (see process_enumeration_scope), after
> we've already finished creating our range type - and therefore too
> late.

This looks suspicious. I think the explicit sign-extension is in general
wrong. It seems to assume that the DWARF producer encoded the
DW_AT_upper_bound wrongly (not as a signed value, but as an unsigned
value that needs to be sign-extended). Something like that might happen
in theory if the producer used DW_FORM_data[1248] because DWARF doesn't
define how to encode signed values in that case. But in practice this
seems to have been settled by interpreting these values as zero-extended
values (not sign-extended) and by the producer using either
DW_FORM_sdata or DW_FORM_udata to remove any ambiguity (like in your
testcase).

Does anything break if you just remove the sign-extension part?
If not, then you don't have to go through the whole
update_enumeration_type_from_children. Or do you need that for anything
else?

Cheers,

Mark