compare object sizes before comparing them with value_contents_eq
authorJoel Brobecker <brobecker@adacore.com>
Thu, 30 Apr 2015 21:04:25 +0000 (23:04 +0200)
committerJoel Brobecker <brobecker@adacore.com>
Tue, 5 May 2015 17:51:38 +0000 (10:51 -0700)
commit2478d075da8f728137bbdaa68b049051c74f4254
tree037ada933b68b7d39aa59bce26ecc23d3d99f932
parent87b8eff03fa5cd49c4829656c3d36bb3386dd6be
compare object sizes before comparing them with value_contents_eq

This is an issue which I noticed while working on trying to print
an array of variant records. For instance, trying to print "A1",
an array of elements whose size is variable, defined as follow
(see gdb.ada/var_rec_arr testcase):

   subtype Small_Type is Integer range 0 .. 10;
   type Record_Type (I : Small_Type := 0) is record
      S : String (1 .. I);
   end record;
   function Ident (R : Record_Type) return Record_Type;

   type Array_Type is array (Integer range <>) of Record_Type;

   A1 : Array_Type := (1 => (I => 0, S => <>),
                       2 => (I => 1, S => "A"),
                       3 => (I => 2, S => "AB"));

The debugger sometimes prints the array as follow:

    (gdb) print A1
    $1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))

The problem happens inside the part of the loop printing the array's
elements, while trying to count the number of consecutive elements
that have the same value (in order to replace them by the "<repeats
nnn times>" message when the number exceeds a threshold). In particular,
in ada-valprint.c::val_print_packed_array_elements:

  elttype = TYPE_TARGET_TYPE (type);
  eltlen = TYPE_LENGTH (check_typedef (elttype));

  while (...)
    {
          if (!value_contents_eq (v0, value_embedded_offset (v0),
                                  v1, value_embedded_offset (v1),
                                  eltlen))
            break;

The value comparison is performed using value_contents_eq but makes
the assumption that elttype is not dynamic, which is not always true.
In particular, in the case above, elttype is dynamic and therefore
its TYPE_LENGTH changes from element to element.

As it happens in this case, the eltlen is zero, which causes the call
to value_contents_eq to return true, and therefore GDB thinks all
3 elements of the array are equal.

This patch fixes the issue by making sure that both v0 and v1, which
are values whose type we expect to be resolved, have identical lengths.
If not, then the two elements of the array cannot possibly have the
same value and we do not even need to do the binary comparison.

Unfortunately, this is still not enough to get GDB to print the correct
value for our array, because the assumption that v0 and v1 have a type
which has been resolved is actually not met. So, the second part of
the patch modifies the function that constructed the values to make
sure dynamic types do get resolved.

gdb/ChangeLog:

        * ada-valprint.c (val_print_packed_array_elements): Delete
        variable "len".  Add a type-length check when comparing two
        consecutive elements of the array.  Use the element's actual
        length in call to value_contents_eq.
        * ada-lang.c (ada_value_primitive_packed_val): Always return
        a value whose type has been resolved.
gdb/ChangeLog
gdb/ada-lang.c
gdb/ada-valprint.c