Commit graph

4 commits

Author SHA1 Message Date
Doug Evans
f2e0d4b4eb Require numeric attributes to specify the form.
gdb/testsuite/ChangeLog:

	* lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value
	is given without an explicit form.
	* gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric
	attributes.
	* gdb.dwarf/corrupt.exp: Ditto.
	* gdb.dwarf2/enum-type.exp: Ditto.
	* gdb.trace/entry-values.exp: Ditto.
	* gdb.trace/unavailable-dwarf-piece.exp: Ditto.
2015-01-11 15:45:43 -08:00
Joel Brobecker
32d0add0a6 Update year range in copyright notice of all files owned by the GDB project.
gdb/ChangeLog:

        Update year range in copyright notice of all files.
2015-01-01 13:32:14 +04:00
Andreas Arnez
e0c0f156b4 Exploit 'prepare_for_testing' etc. for 'Dwarf::assemble'-generated files
Now that prepare_for_testing etc. can cope with absolute path names,
this can be exploited for test cases with generated source files.
This is just to simplify the code and shouldn't cause any functional
change.
2014-03-12 16:22:18 +01:00
Joel Brobecker
55426c9d52 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.
2014-02-26 10:39:25 -08:00