This is the mail archive of the gdb-testers@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] compare object sizes before comparing them with value_contents_eq


*** TEST RESULTS FOR COMMIT 2478d075da8f728137bbdaa68b049051c74f4254 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: master
Commit: 2478d075da8f728137bbdaa68b049051c74f4254

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]