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

[Mark Wielaard <mjw@redhat.com>]

On Wed, 2014-02-26 at 10:31 -0800, Joel Brobecker wrote:
> I finally had some time to test this patch, and unfortunately,
> it does introduce some regression (in Ada). For instance in
> homonym.exp:

Sorry, I didn't have gcc-gnat installed and so missed this. I have it
installed now. BTW. Are there any overviews of what are expected
results? For make check RUNTESTFLAGS='--directory gdb.ada' I get:

		=== gdb Summary ===

# of expected passes            490
# of unexpected failures        29
# of unexpected successes       8
# of expected failures          2
# of known failures             1
# of unsupported tests          3

Is that reasonable? The amount of failures seems a bit high. The
testsuite is not supposed to be (near) zero-fail?

>    type Integer_Range is new Integer range -100 .. 100;
>    subtype Local_Type is Integer_Range;
> 
> This is what GDB would print afterwards:
> 
>     (gdb) ptype local_type
>     type = range 4294967196 .. 100
> 
> The lower bound should be -100. The debugging info is generated
> as follow:
> 
>  <2><80>: Abbrev Number: 2 (DW_TAG_subrange_type)
>     <81>   DW_AT_lower_bound : 0xffffff9c
>     <85>   DW_AT_upper_bound : 100
>     <86>   DW_AT_name        : (indirect string, offset: 0x76): homonym__get_value__local_type___XDLU_100m__100
>     <8a>   DW_AT_type        : <0x37>
> 
> And the corresponding abbrev gives the form:
> 
>    2      DW_TAG_subrange_type    [no children]
>     DW_AT_lower_bound  DW_FORM_data4
>     DW_AT_upper_bound  DW_FORM_data1
>     DW_AT_name         DW_FORM_strp
>     DW_AT_type         DW_FORM_ref4
>     DW_AT value: 0     DW_FORM value: 0
> 
> It's the dreaded DW_FORM_dataN form... And unfortunately, I get the same
> representation with pre-versions of GCC 4.9, so it looks like we're not
> going to be able to remove that bit anytime soon :-(.

Grrr and sigh. Why does GCC do that? Encoding the negative lower bound
like that actually takes up more space than simply using DW_FORM_sdata.
The comment in the GCC sources even says this is suboptimal:

        /* Otherwise represent the bound as an unsigned value with the
           precision of its type.  The precision and signedness of the
           type will be necessary to re-interpret it unambiguously.  */

Luckily it seems GCC only does this when adding bounds info. But it does
seem we are stuck with it for now :{

I'll see if I can fix GCC so one day day in the far, far, future this
hack won't be necessary.

Cheers,

Mark