This is the mail archive of the 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]

gdb and binutils branch master updated. 8908fca5772fcff9f7766158ba2aa59f5a2b1f68

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  8908fca5772fcff9f7766158ba2aa59f5a2b1f68 (commit)
      from  4a46959e7b897a74c0ee4a0b6ecbaacc1a9f243e (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 -----------------------------------------------------------------;h=8908fca5772fcff9f7766158ba2aa59f5a2b1f68

commit 8908fca5772fcff9f7766158ba2aa59f5a2b1f68
Author: Joel Brobecker <>
Date:   Sat Sep 27 09:09:34 2014 -0700

    [Ada] Ignore __XA types when redundant.
    Consider the following code which declares a variable A2 which
    is an array of arrays of integers.
       type Array2_First is array (24 .. 26) of Integer;
       type Array2_Second is array (1 .. 2) of Array2_First;
       A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));
    Trying to print the type of that variable currently yields:
        (gdb) ptype A2
        type = array (1 .. 2, 24 .. 26) of integer
    This is not correct, as this is the description of a two-dimension
    array, which is different from an array of arrays. The expected
    output is:
        (gdb) ptype a2
        type = array (1 .. 2) of foo_n926_029.array2_first
    GDB's struct type currently handles multi-dimension arrays the same
    way arrays of arrays, where each dimension is stored as a sub-array.
    The ada-valprint module considers that consecutive array layers
    are in fact multi-dimension arrays. For array of arrays, a typedef
    layer is introduced between the two arrays, creating a break between
    each array type.
    In our situation, A2 is a described as a typedef of an array type...
            .uleb128 0x8    # (DIE (0x125) DW_TAG_variable)
            .ascii "a2\0"   # DW_AT_name
            .long   0xfc    # DW_AT_type
            .uleb128 0x4    # (DIE (0xfc) DW_TAG_typedef)
            .long   .LASF5  # DW_AT_name: "foo__array2_second"
            .long   0x107   # DW_AT_type
            .uleb128 0x5    # (DIE (0x107) DW_TAG_array_type)
            .long   .LASF5  # DW_AT_name: "foo__array2_second"
            .long   0xb4    # DW_AT_type
            .uleb128 0x6    # (DIE (0x114) DW_TAG_subrange_type)
            .long   0x11b   # DW_AT_type
            .byte   0x2     # DW_AT_upper_bound
            .byte   0       # end of children of DIE 0x107
    ... whose element type is, as expected, a typedef to the sub-array
            .uleb128 0x4    # (DIE (0xb4) DW_TAG_typedef)
            .long   .LASF4  # DW_AT_name: "foo__array2_first"
            .long   0xbf    # DW_AT_type
            .uleb128 0x9    # (DIE (0xbf) DW_TAG_array_type)
            .long   .LASF4  # DW_AT_name: "foo__array2_first"
            .long   0xd8    # DW_AT_GNAT_descriptive_type
            .long   0x1c5   # DW_AT_type
            .uleb128 0xa    # (DIE (0xd0) DW_TAG_subrange_type)
            .long   0xf0    # DW_AT_type
            .byte   0x18    # DW_AT_lower_bound
            .byte   0x1a    # DW_AT_upper_bound
            .byte   0       # end of children of DIE 0xbf
    The reason why things fails is that, during expression evaluation,
    GDB tries to "fix" A1's type. Because the sub-array has a parallel
    (descriptive) type (DIE 0xd8), GDB thinks that our array's index
    type must be dynamic and therefore needs to be fixed. This in turn
    causes the sub-array to be "fixed", which itself results in the
    typedef layer to be stripped.
    However, looking closer at the parallel type, we see...
            .uleb128 0xb    # (DIE (0xd8) DW_TAG_structure_type)
            .long   .LASF8  # DW_AT_name: "foo__array2_first___XA"
            .uleb128 0xc    # (DIE (0xe4) DW_TAG_member)
            .long   .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"
    ... that all it tells us is that the array bounds are 24 and 26,
    which is already correctly provided by the array's DW_TAG_subrange_type
    bounds, meaning that this parallel type is just redundant.
    Parallel types in general are slowly being removed in favor of
    standard DWARF constructs. But in the meantime, this patch kills
    two birds with one stone:
      1. It recognizes this situation where the XA type is useless,
         and saves an unnecessary range-type fixing;
      2. It fixes the issue at hand because ignoring the XA type results
         in no type fixing being required, which allows the typedef layer
         to be preserved.
            * ada-lang.c (ada_is_redundant_range_encoding): New function.
            (ada_is_redundant_index_type_desc): New function.
            (to_fixed_array_type): Ignore parallel XA type if redundant.
            * gdb.ada/arr_arr: New testcase.
    Tested on x86_64-linux.


Summary of changes:
 gdb/ChangeLog                                      |    6 ++
 gdb/ada-lang.c                                     |   73 ++++++++++++++++++++
 gdb/testsuite/ChangeLog                            |    4 +
 gdb/testsuite/gdb.ada/arr_arr.exp                  |   33 +++++++++
 gdb/testsuite/gdb.ada/arr_arr/foo.adb              |   25 +++++++
 .../gdb.ada/{mi_interface => arr_arr}/pck.adb      |    0
 .../gdb.ada/{pkd_arr_elem => arr_arr}/      |    0
 7 files changed, 141 insertions(+), 0 deletions(-)
 create mode 100644 gdb/testsuite/gdb.ada/arr_arr.exp
 create mode 100644 gdb/testsuite/gdb.ada/arr_arr/foo.adb
 copy gdb/testsuite/gdb.ada/{mi_interface => arr_arr}/pck.adb (100%)
 copy gdb/testsuite/gdb.ada/{pkd_arr_elem => arr_arr}/ (100%)

gdb and binutils

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