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

gdb and binutils branch master updated. 45e44d277a1b558bb77ea0a1962172a06be26594


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  45e44d277a1b558bb77ea0a1962172a06be26594 (commit)
      from  82dac402d2a0fa22abd9b355a7bd8383dce9527c (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=45e44d277a1b558bb77ea0a1962172a06be26594

commit 45e44d277a1b558bb77ea0a1962172a06be26594
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Thu Oct 2 15:17:49 2014 -0700

    Handling of empty Ada ranges with a negative upper bound.
    
    Consider the following variable declaration:
    
        type Array_Type is array (Integer range <>) of Integer;
        Var: Array_Type (0 .. -1);
    
    "ptype var" prints the wrong upper bound for that array:
    
        (gdb) ptype var
        type = array (0 .. 4294967295) of integer
    
    The debugging info for the type of variable "Var" is as follow:
    
      <2><cf>: Abbrev Number: 13 (DW_TAG_structure_type)
         <d0>   DW_AT_name        : foo__var___PAD
      <3><db>: Abbrev Number: 14 (DW_TAG_member)
         <dc>   DW_AT_name        : F
         <e0>   DW_AT_type        : <0xa5>
    
    This is just an artifact from code generation, which is just
    a wrapper that we should ignore. The real type is the type of
    field "F" in that PAD type, which is described as:
    
      <2><a5>: Abbrev Number: 10 (DW_TAG_array_type)
         <a6>   DW_AT_name        : foo__TvarS
      <3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type)
         <b7>   DW_AT_type        : <0xc1>
         <bb>   DW_AT_lower_bound : 0
         <bc>   DW_AT_upper_bound : 0xffffffff
    
    Trouble occurs because DW_AT_upper_bound is encoded using
    a DW_FORM_data4, which is ambiguous regarding signedness.
    In that case, dwarf2read.c::dwarf2_get_attr_constant_value
    reads the value as unsigned, which is not what we want
    in this case.
    
    As it happens, we already have code dealing with this situation
    in dwarf2read.c::read_subrange_type which checks whether
    the subrange's type is signed or not, and if it is, fixes
    the bound's value by sign-extending it:
    
      if (high.kind == PROP_CONST
          && !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask))
        high.data.const_val |= negative_mask;
    
    Unfortunately, what happens in our case is that the base type
    of the array's subrange type is marked as being unsigned, and
    so we never get to apply the sign extension. Following the DWARF
    trail, the range's base type is described as another subrange type...
    
      <2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type)
         <c7>   DW_AT_name        : foo__TTvarSP1___XDLU_0__1m
         <cb>   DW_AT_type        : <0x2d>
    
    ... whose base type is, (finally), a basic type (signed):
    
      <1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
         <2e>   DW_AT_byte_size   : 4
         <2f>   DW_AT_encoding    : 5        (signed)
         <30>   DW_AT_name        : integer
    
    The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m
    (the base type of the array's range type) is an unsigned type
    is found in gdbtypes.c::create_range_type.  We consider that
    a range type is unsigned iff its lower bound is >= 0:
    
      if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0)
        TYPE_UNSIGNED (result_type) = 1;
    
    That is normally sufficient, as one would expect the upper bound to
    always be greater or equal to the lower bound. But Ada actually
    allows the declaration of empty range types where the upper bound
    is less than the lower bound. In this case, the upper bound is
    negative, so we should not be marking the type as unsigned.
    
    This patch fixes the issue by simply checking the upper bound as well
    as the lower bound, and clears the range type's unsigned flag when
    it is found to be constant and negative.
    
    gdb/ChangeLog:
    
            * gdbtypes.c (create_range_type): Unset RESULT_TYPE's
            flag_unsigned if HIGH_BOUND is constant and negative.
    
    gdb/testsuite/ChangeLog:
    
            * gdb.ada/n_arr_bound: New testcase.
    
    Tested on x86_64-linux.

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

Summary of changes:
 gdb/ChangeLog                                      |    5 +++
 gdb/gdbtypes.c                                     |    7 ++++
 gdb/testsuite/ChangeLog                            |    4 ++
 gdb/testsuite/gdb.ada/n_arr_bound.exp              |   32 ++++++++++++++++++++
 gdb/testsuite/gdb.ada/n_arr_bound/foo.adb          |   23 ++++++++++++++
 .../gdb.ada/{arr_arr => n_arr_bound}/pck.adb       |    0
 .../gdb.ada/{arr_arr => n_arr_bound}/pck.ads       |    0
 7 files changed, 71 insertions(+), 0 deletions(-)
 create mode 100644 gdb/testsuite/gdb.ada/n_arr_bound.exp
 create mode 100644 gdb/testsuite/gdb.ada/n_arr_bound/foo.adb
 copy gdb/testsuite/gdb.ada/{arr_arr => n_arr_bound}/pck.adb (100%)
 copy gdb/testsuite/gdb.ada/{arr_arr => n_arr_bound}/pck.ads (100%)


hooks/post-receive
-- 
gdb and binutils


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