(Ada) slightly incorrect bounds for type of array indexed by enum
authorJoel Brobecker <brobecker@adacore.com>
Sat, 8 Sep 2018 21:49:10 +0000 (16:49 -0500)
committerJoel Brobecker <brobecker@adacore.com>
Sat, 8 Sep 2018 21:49:10 +0000 (17:49 -0400)
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.

gdb/ChangeLog
gdb/ada-typeprint.c

index 7869bc192a29f55c521c80fb804084ce9bd06506..0f73a3ef8720b2b3fbcbced8e5e43c8133e59e13 100644 (file)
@@ -1,3 +1,8 @@
+2018-09-08  Joel Brobecker  <brobecker@adacore.com>
+
+       * ada-typeprint.c (print_range): Print the bounds using TYPE
+       rather than its TYPE_TARGET_TYPE.
+
 2018-09-08  Joel Brobecker  <brobecker@adacore.com>
 
        * ada-lang.c (ada_to_fixed_value): Minor reformatting in
index 47ce897d01616052398a1cb93782b4364b5c6d98..b78654d100f8677f5dd18732e161768c1c9257c7 100644 (file)
@@ -159,14 +159,9 @@ print_range (struct type *type, struct ui_file *stream,
     case TYPE_CODE_RANGE:
     case TYPE_CODE_ENUM:
       {
-       struct type *target_type;
        LONGEST lo = 0, hi = 0; /* init for gcc -Wall */
        int got_error = 0;
 
-       target_type = TYPE_TARGET_TYPE (type);
-       if (target_type == NULL)
-         target_type = type;
-
        TRY
          {
            lo = ada_discrete_type_low_bound (type);
@@ -186,9 +181,9 @@ print_range (struct type *type, struct ui_file *stream,
 
        if (!got_error)
          {
-           ada_print_scalar (target_type, lo, stream);
+           ada_print_scalar (type, lo, stream);
            fprintf_filtered (stream, " .. ");
-           ada_print_scalar (target_type, hi, stream);
+           ada_print_scalar (type, hi, stream);
          }
       }
       break;