gdb and binutils branch master updated. 55426c9d52fdba13df81fcce1b18469cc0362e50

[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  55426c9d52fdba13df81fcce1b18469cc0362e50 (commit)
      from  0dcb32c3ae07166fc3b04eb4a86ae93ecd87bfb8 (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=55426c9d52fdba13df81fcce1b18469cc0362e50

commit 55426c9d52fdba13df81fcce1b18469cc0362e50
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Wed Jan 22 18:40:20 2014 +0400

    DWARF: Set enum type "flag_enum" and "unsigned" flags at type creation.
    
    Consider the following Ada code:
    
       --  An array whose index is an enumeration type with 128 enumerators.
       type Enum_T is (Enum_000, Enum_001, [...], Enum_128);
       type Table is array (Enum_T) of Boolean;
    
    When the compiler is configured to generate pure DWARF debugging info,
    trying to print type Table's description yields:
    
        ptype pck.table
        type = array (enum_000 .. -128) of boolean
    
    The expected output was:
    
        ptype pck.table
        type = array (enum_000 .. enum_128) of boolean
    
    The DWARF debugging info for our array looks like this:
    
        <1><44>: Abbrev Number: 5 (DW_TAG_array_type)
           <45>   DW_AT_name        : pck__table
           <50>   DW_AT_type        : <0x28>
        <2><54>: Abbrev Number: 6 (DW_TAG_subrange_type)
           <55>   DW_AT_type        : <0x5c>
           <59>   DW_AT_lower_bound : 0
           <5a>   DW_AT_upper_bound : 128
    
    The array index type is, by construction with the DWARF standard,
    a subrange of our enumeration type, defined as follow:
    
        <2><5b>: Abbrev Number: 0
        <1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type)
           <5d>   DW_AT_name        : pck__enum_t
           <69>   DW_AT_byte_size   : 1
        <2><6b>: Abbrev Number: 8 (DW_TAG_enumerator)
           <6c>   DW_AT_name        : pck__enum_000
           <7a>   DW_AT_const_value : 0
        [etc]
    
    Therefore, while processing these DIEs, the array index type ends
    up being a TYPE_CODE_RANGE whose target type is our enumeration type.
    But the problem is that we read the upper bound as a negative value
    (-128), which is then used as is by the type printer to print the
    array upper bound. This negative value explains the "-128" in the
    output.
    
    To understand why the range type's upper bound is read as a negative
    value, one needs to look at how it is determined, in read_subrange_type:
    
      orig_base_type = die_type (die, cu);
      base_type = check_typedef (orig_base_type);
      [... high is first correctly read as 128, but then ...]
      if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
        high |= negative_mask;
    
    The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
    is not set. And the reason for that is because the base_type was only
    partially constructed during the call to die_type. While the enum
    is constructed on the fly by read_enumeration_type, its flag_unsigned
    flag is only set later on, while creating the symbols corresponding to
    the enum type's enumerators (see process_enumeration_scope), after
    we've already finished creating our range type - and therefore too
    late.
    
    My first naive attempt at fixing this problem consisted in extracting
    the part in process_enumeration_scope which processes all enumerators,
    to generate the associated symbols, but more importantly set the type's
    various flags when necessary. However, this does not always work well,
    because we're still in the subrange_type's scope, and it might be
    different from the scope where the enumeration type is defined.
    
    So, instead, what this patch does to fix the issue is to extract
    from process_enumeration_scope the part that determines whether
    the enumeration type should have the flag_unsigned and/or the
    flag_flag_enum flags set. It turns out that, aside from the code
    implementing the loop, this part is fairly independent of the symbol
    creation. With that part extracted, we can then use it at the end
    of our enumeration type creation, to produce a type which should now
    no longer need any adjustment.
    
    Once the enumeration type produced is correctly marked as unsigned,
    the subrange type's upper bound is then correctly read as an unsigned
    value, therefore giving us an upper bound of 128 instead of -128.
    
    gdb/ChangeLog:
    
            * dwarf2read.c (update_enumeration_type_from_children): New
            function, mostly extracted from process_structure_scope.
            (read_enumeration_type): Call update_enumeration_type_from_children.
            (process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned
            and flag_flag_enum fields.
    
    gdb/testsuite/ChangeLog:
    
            * gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.

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

Summary of changes:
 gdb/ChangeLog                                      |    8 ++
 gdb/dwarf2read.c                                   |   82 ++++++++++++++++----
 gdb/testsuite/ChangeLog                            |    4 +
 .../gdb.dwarf2/{arr-stride.c => arr-subrange.c}    |    0
 .../{arr-stride.exp => arr-subrange.exp}           |   73 ++++++++----------
 5 files changed, 110 insertions(+), 57 deletions(-)
 copy gdb/testsuite/gdb.dwarf2/{arr-stride.c => arr-subrange.c} (100%)
 copy gdb/testsuite/gdb.dwarf2/{arr-stride.exp => arr-subrange.exp} (53%)


hooks/post-receive
-- 
gdb and binutils