(Ada) slightly incorrect bounds for type of array indexed by enum

Consider the following code:

   type Enumerated is (Enum_A, Enum_B, Enum_C, Enum_Last);
   type Table is array (Enumerated) of Integer;
   --  Declare a variable of type Table to make sure the compiler
   --  does emit the debugging information for that type.
   V : Table := (others => 1);

Trying to print the type description of type Table, or of variable V
yields:

    (gdb) ptype v
    type = array (0 .. 3) of integer
    (gdb) ptype example.table
    type = array (0 .. 3) of integer

The compiler generates an XA type for the bounds...

 <1><cf6>: Abbrev Number: 13 (DW_TAG_structure_type)
    <cf7>   DW_AT_name        : example__table___XA

... whose member is described as being as:

 <2><cfe>: Abbrev Number: 14 (DW_TAG_member)
    <cff>   DW_AT_name        : example__enumerated
    <d05>   DW_AT_type        : <0xc69>

This leads us to DIE 0xc69, which is our enumeration type:

 <2><c69>: Abbrev Number: 4 (DW_TAG_enumeration_type)
    <c6a>   DW_AT_name        : example__enumerated

Normally, for arrays, we expect a range type, rather than an enumerated
type. However, for a situation like this, where the range of the array
index is the full enumeration type, it seems like a waste to require
an extra range layer.

Instead, looking at print_range, we see that we print the bounds
of our range using the target type:

       target_type = TYPE_TARGET_TYPE (type);
       if (target_type == NULL)
         target_type = type;
       [...]
       ada_print_scalar (target_type, lo, stream);
       fprintf_filtered (stream, " .. ");
       ada_print_scalar (target_type, hi, stream);

In this case, this causes us to use the enumerated type's subtype,
which is a plain integer type, hence the output we get. However,
there is no reason for using the target type, even in the TYPE_CODE_RANGE
situation. So this patch fixes the issue by simply printing the bounds
using the type being given, instead of its target type.

gdb/ChangeLog:

        * ada-typeprint.c (print_range): Print the bounds using TYPE
        rather than its TYPE_TARGET_TYPE.

A new test for this isn't necessary, as existing tests will demonstrate
this issue once a change in the compiler triggering the generation of
this type of debugging info gets pushed.

0 files changed, 0 insertions, 0 deletions