gdb and binutils branch master updated. 4a46959e7b897a74c0ee4a0b6ecbaacc1a9f243e

[brobecke at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  4a46959e7b897a74c0ee4a0b6ecbaacc1a9f243e (commit)
      from  2acf986b741bd27cc441d2972b248dd506f0415a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4a46959e7b897a74c0ee4a0b6ecbaacc1a9f243e

commit 4a46959e7b897a74c0ee4a0b6ecbaacc1a9f243e
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Thu Sep 11 18:38:04 2014 -0700

    varsize-limit error printing element of packed array...
    
    ... when that packed array is part of a discriminated record and
    one of the bounds is a discriminant.
    
    Consider the following code:
    
       type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
       type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
       pragma PACK (FUNNY_STR_T);
       type FUNNY_STRING_T (SIZE : NATURAL := 1) is
          record
             STR    : FUNNY_STR_T (1 .. SIZE) := (others => '0');
             LENGTH : NATURAL := 4;
          end record;
       TEST: FUNNY_STRING_T(100);
    
    GDB is able to print the value of variable "test" and "test.str".
    But not "test.str(1)":
    
        (gdb) p test
        $1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
        (gdb) p test.str
        $2 = (33 'A', nul <repeats 99 times>)
        (gdb) p test.str(1)
        object size is larger than varsize-limit
    
    The problem occurs during the phase where we are trying to resolve
    the expression subscript operation. On the one hand of the subscript
    operator, we have the result of the evaluation of "test.str", which
    is our packed array. We have the following code to handle packed
    arrays in particular:
    
          if (ada_is_constrained_packed_array_type
              (desc_base_type (value_type (argvec[0]))))
            argvec[0] = ada_coerce_to_simple_array (argvec[0]);
    
    This eventually leads to a call to constrained_packed_array_type
    to return the "simple array".  This function relies on a parallel
    ___XA type, when available, to determine the bounds.  In our case,
    we find type...
    
        failure__funny_string_t__T4b___XA"
    
    ... which has one field describing the bounds of our array as:
    
        failure__funny_string_t__T3b___XDLU_1__size
    
    The part that interests us is after the ___XD suffix or,
    in other words: "LU_1__size". What this means in GNAT encoding
    parlance is that the lower bound is 1, and that the upper bound
    is the value of "size". "size" is our discriminant in this case.
    
    Normally, we would access the record's discriminant in order to
    get the upper bound's value, but we do not have that information,
    here. We are in a mode where we are just trying to "fix" the type
    without an actual value. This is what the call to to_fixed_range_type
    is doing, and because the fix'ing fails, it ends up returning
    the ___XDLU type unmodified as our index type.
    
    This shouldn't be a problem, except that the later part of
    constrained_packed_array_type then uses that index_type to
    determine the array size, via a call to get_discrete_bounds.
    The problem is that the upper bound of the ___XDLU type is
    dynamic (in the DWARF sense) while get_discrete_bounds implicitly
    assumes that the bounds are static, and therefore accesses
    them using macros that assume the bounds values are constants:
    
        case TYPE_CODE_RANGE:
          *lowp = TYPE_LOW_BOUND (type);
          *highp = TYPE_HIGH_BOUND (type);
    
    This therefore returns a bogus value for the upper bound,
    leading to an unexpectedly large size for our array, which
    later triggers the varsize-limit guard we've seen above.
    
    This patch avoids the problem by adding special handling
    of dynamic range types. It also extends the documentation
    of the constrained_packed_array_type function to document
    what happens in this situation.
    
    gdb/ChangeLog:
    
            * ada-lang.c (constrained_packed_array_type): Set the length
            of the return array as if both bounds where zero if that
            returned array's index type is dynamic.
    
    gdb/testsuite/ChangeLog:
    
            * gdb.ada/pkd_arr_elem: New Testcase.
    
    Tested on x86_64-linux.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |    6 +++
 gdb/ada-lang.c                                     |   14 +++++-
 gdb/testsuite/ChangeLog                            |    4 ++
 gdb/testsuite/gdb.ada/pkd_arr_elem.exp             |   38 ++++++++++++++++
 gdb/testsuite/gdb.ada/pkd_arr_elem/failure.adb     |   45 ++++++++++++++++++++
 .../gdb.ada/{mi_interface => pkd_arr_elem}/pck.adb |    0
 gdb/testsuite/gdb.ada/pkd_arr_elem/pck.ads         |   19 ++++++++
 7 files changed, 124 insertions(+), 2 deletions(-)
 create mode 100644 gdb/testsuite/gdb.ada/pkd_arr_elem.exp
 create mode 100644 gdb/testsuite/gdb.ada/pkd_arr_elem/failure.adb
 copy gdb/testsuite/gdb.ada/{mi_interface => pkd_arr_elem}/pck.adb (100%)
 create mode 100644 gdb/testsuite/gdb.ada/pkd_arr_elem/pck.ads


hooks/post-receive
-- 
gdb and binutils