old-cross-binutils/gdb/testsuite/gdb.dwarf2/dynarr-ptr.exp

355 lines
8.8 KiB
Text
Raw Normal View History

# Copyright 2014-2016 Free Software Foundation, Inc.
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
load_lib dwarf.exp
# This test can only be run on targets which support DWARF-2 and use gas.
if {![dwarf2_support]} {
return 0
}
standard_testfile dynarr-ptr.c dynarr-ptr-dw.S
# We need to know the size of integer and address types in order
# to write some of the debugging info we'd like to generate.
#
# For that, we ask GDB by debugging our dynarr-ptr.c program.
# Any program would do, but since we already have dynarr-ptr.c
# specifically for this testcase, might as well use that.
if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
untested ${testfile}.exp
return -1
}
# Make some DWARF for the test.
set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
cu {} {
DW_TAG_compile_unit {
{DW_AT_language @DW_LANG_Ada95}
{DW_AT_name foo.adb}
{DW_AT_comp_dir /tmp}
} {
declare_labels integer_label array_label array_ptr_label \
array_typedef_label
set ptr_size [get_sizeof "void *" 96]
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
set int_size [get_sizeof "int" 4]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
integer_label: DW_TAG_base_type {
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
{DW_AT_byte_size $int_size DW_FORM_sdata}
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
{DW_AT_encoding @DW_ATE_signed}
{DW_AT_name integer}
}
array_label: DW_TAG_array_type {
{DW_AT_name foo__array_type}
{DW_AT_type :$integer_label}
{external 1 flag}
} {
DW_TAG_subrange_type {
{DW_AT_type :$integer_label}
{DW_AT_lower_bound {
DW_OP_push_object_address
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
DW_OP_const1u [expr {2 * $int_size}]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
DW_OP_minus
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
DW_OP_deref_size $int_size
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
{DW_AT_upper_bound {
DW_OP_push_object_address
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
DW_OP_const1u $int_size
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
DW_OP_minus
gdb.dwarf2: Don't hardcode certain constants in Dwarf::assemble constructs Two tests in gdb.dwarf2, data-loc.exp and dynarr-ptr.exp assume that sizeof(int) is 4. This patch looks up the integer size and uses this constant for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound. I discovered this problem while looking at test results for this msp430 multilib: msp430-sim/-msim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either It fixes the following set of failures: FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr_tdef'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef.all'first FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.five_ptr_tdef'first FAIL: gdb.dwarf2/data-loc.exp: print foo.three FAIL: gdb.dwarf2/data-loc.exp: print foo.three(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(1) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.three_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five FAIL: gdb.dwarf2/data-loc.exp: print foo.five(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five(6) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(2) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(3) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(4) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(5) FAIL: gdb.dwarf2/data-loc.exp: print foo.five_tdef(6) FAIL: gdb.dwarf2/data-loc.exp: print foo__three FAIL: gdb.dwarf2/data-loc.exp: print foo__three_tdef FAIL: gdb.dwarf2/data-loc.exp: print foo__five FAIL: gdb.dwarf2/data-loc.exp: print foo__five_tdef As I recall, there are still (other) problems with msp430 multilibs which don't use -mlarge. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Don't hardcode value associated with DW_AT_byte_size. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Don't hardcode constants for DW_AT_byte_size, DW_AT_lower_bound, and DW_AT_upper_bound.
2015-10-30 04:53:51 +00:00
DW_OP_deref_size $int_size
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
}
}
array_ptr_label: DW_TAG_pointer_type {
{DW_AT_byte_size $ptr_size DW_FORM_data1}
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
{DW_AT_type :$array_label}
}
array_typedef_label: DW_TAG_typedef {
{DW_AT_name "foo__array_ptr"}
{DW_AT_type :$array_ptr_label}
}
DW_TAG_variable {
{DW_AT_name foo__three_ptr}
{DW_AT_type :$array_ptr_label}
{DW_AT_location {
gdb.dwarf2: Define and use gdb_target_symbol for symbol prefixes Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to (minimal/linker) symbols created in the course of building a small test program. Some targets use a prefix such as underscore ("_") on these symbols. Many of the tests in gdb.dwarf2 do not take this into account. As a consequence, these tests fail to build, resulting either in failures or untested testcases. Here is an example from gdb.dwarf2/dw2-regno-invalid.exp: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc main DW_FORM_addr} {high_pc main+0x10000 DW_FORM_addr} } { ... } For targets which require an underscore prefix on linker symbols, the two occurrences of "main" would have to have a prepended underscore, i.e. _main instead of main. For the above case, a call to the new proc gdb_target_symbol is used prepend the correct prefix to the symbol. I.e. the above code is rewritten (as shown in the patch) as follows: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc [gdb_target_symbol main] DW_FORM_addr} {high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr} } { ... } I also found it necessary to make an adjustment to lib/dwarf.exp so that expressions of more than just one list element can be used in DW_TAG_... constructs. Both atomic-type.exp and dw2-bad-mips-linkage-name.exp require this new functionality. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix, gdb_target_symbol): New procs. * lib/dwarf.exp (_handle_DW_TAG): Handle attribute values, representing expressions, of more than one list element. * gdb.dwarf2/atomic-type.exp (Dwarf::assemble): Use gdb_target_symbol to prepend linker symbol prefix to f. * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Likewise, for table_1 and table_2. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp (Dwarf::assemble): Likewise, for f and g. * gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Likewise, for ptr. * gdb.dwarf2/dw2-regno-invalid.exp (Dwarf::assemble): Likewise, for main. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Likewise, for table_1_ptr and table_2_ptr.
2015-10-28 18:36:06 +00:00
DW_OP_addr [gdb_target_symbol table_1_ptr]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
{external 1 flag}
}
DW_TAG_variable {
{DW_AT_name foo__three_ptr_tdef}
{DW_AT_type :$array_typedef_label}
{DW_AT_location {
gdb.dwarf2: Define and use gdb_target_symbol for symbol prefixes Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to (minimal/linker) symbols created in the course of building a small test program. Some targets use a prefix such as underscore ("_") on these symbols. Many of the tests in gdb.dwarf2 do not take this into account. As a consequence, these tests fail to build, resulting either in failures or untested testcases. Here is an example from gdb.dwarf2/dw2-regno-invalid.exp: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc main DW_FORM_addr} {high_pc main+0x10000 DW_FORM_addr} } { ... } For targets which require an underscore prefix on linker symbols, the two occurrences of "main" would have to have a prepended underscore, i.e. _main instead of main. For the above case, a call to the new proc gdb_target_symbol is used prepend the correct prefix to the symbol. I.e. the above code is rewritten (as shown in the patch) as follows: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc [gdb_target_symbol main] DW_FORM_addr} {high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr} } { ... } I also found it necessary to make an adjustment to lib/dwarf.exp so that expressions of more than just one list element can be used in DW_TAG_... constructs. Both atomic-type.exp and dw2-bad-mips-linkage-name.exp require this new functionality. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix, gdb_target_symbol): New procs. * lib/dwarf.exp (_handle_DW_TAG): Handle attribute values, representing expressions, of more than one list element. * gdb.dwarf2/atomic-type.exp (Dwarf::assemble): Use gdb_target_symbol to prepend linker symbol prefix to f. * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Likewise, for table_1 and table_2. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp (Dwarf::assemble): Likewise, for f and g. * gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Likewise, for ptr. * gdb.dwarf2/dw2-regno-invalid.exp (Dwarf::assemble): Likewise, for main. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Likewise, for table_1_ptr and table_2_ptr.
2015-10-28 18:36:06 +00:00
DW_OP_addr [gdb_target_symbol table_1_ptr]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
{external 1 flag}
}
DW_TAG_variable {
{DW_AT_name foo__five_ptr}
{DW_AT_type :$array_ptr_label}
{DW_AT_location {
gdb.dwarf2: Define and use gdb_target_symbol for symbol prefixes Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to (minimal/linker) symbols created in the course of building a small test program. Some targets use a prefix such as underscore ("_") on these symbols. Many of the tests in gdb.dwarf2 do not take this into account. As a consequence, these tests fail to build, resulting either in failures or untested testcases. Here is an example from gdb.dwarf2/dw2-regno-invalid.exp: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc main DW_FORM_addr} {high_pc main+0x10000 DW_FORM_addr} } { ... } For targets which require an underscore prefix on linker symbols, the two occurrences of "main" would have to have a prepended underscore, i.e. _main instead of main. For the above case, a call to the new proc gdb_target_symbol is used prepend the correct prefix to the symbol. I.e. the above code is rewritten (as shown in the patch) as follows: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc [gdb_target_symbol main] DW_FORM_addr} {high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr} } { ... } I also found it necessary to make an adjustment to lib/dwarf.exp so that expressions of more than just one list element can be used in DW_TAG_... constructs. Both atomic-type.exp and dw2-bad-mips-linkage-name.exp require this new functionality. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix, gdb_target_symbol): New procs. * lib/dwarf.exp (_handle_DW_TAG): Handle attribute values, representing expressions, of more than one list element. * gdb.dwarf2/atomic-type.exp (Dwarf::assemble): Use gdb_target_symbol to prepend linker symbol prefix to f. * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Likewise, for table_1 and table_2. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp (Dwarf::assemble): Likewise, for f and g. * gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Likewise, for ptr. * gdb.dwarf2/dw2-regno-invalid.exp (Dwarf::assemble): Likewise, for main. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Likewise, for table_1_ptr and table_2_ptr.
2015-10-28 18:36:06 +00:00
DW_OP_addr [gdb_target_symbol table_2_ptr]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
{external 1 flag}
}
DW_TAG_variable {
{DW_AT_name foo__five_ptr_tdef}
{DW_AT_type :$array_typedef_label}
{DW_AT_location {
gdb.dwarf2: Define and use gdb_target_symbol for symbol prefixes Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to (minimal/linker) symbols created in the course of building a small test program. Some targets use a prefix such as underscore ("_") on these symbols. Many of the tests in gdb.dwarf2 do not take this into account. As a consequence, these tests fail to build, resulting either in failures or untested testcases. Here is an example from gdb.dwarf2/dw2-regno-invalid.exp: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc main DW_FORM_addr} {high_pc main+0x10000 DW_FORM_addr} } { ... } For targets which require an underscore prefix on linker symbols, the two occurrences of "main" would have to have a prepended underscore, i.e. _main instead of main. For the above case, a call to the new proc gdb_target_symbol is used prepend the correct prefix to the symbol. I.e. the above code is rewritten (as shown in the patch) as follows: Dwarf::assemble $asm_file { cu {} { compile_unit { {low_pc [gdb_target_symbol main] DW_FORM_addr} {high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr} } { ... } I also found it necessary to make an adjustment to lib/dwarf.exp so that expressions of more than just one list element can be used in DW_TAG_... constructs. Both atomic-type.exp and dw2-bad-mips-linkage-name.exp require this new functionality. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix, gdb_target_symbol): New procs. * lib/dwarf.exp (_handle_DW_TAG): Handle attribute values, representing expressions, of more than one list element. * gdb.dwarf2/atomic-type.exp (Dwarf::assemble): Use gdb_target_symbol to prepend linker symbol prefix to f. * gdb.dwarf2/data-loc.exp (Dwarf::assemble): Likewise, for table_1 and table_2. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp (Dwarf::assemble): Likewise, for f and g. * gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Likewise, for ptr. * gdb.dwarf2/dw2-regno-invalid.exp (Dwarf::assemble): Likewise, for main. * gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Likewise, for table_1_ptr and table_2_ptr.
2015-10-28 18:36:06 +00:00
DW_OP_addr [gdb_target_symbol table_2_ptr]
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
} SPECIAL_expr}
{external 1 flag}
}
}
}
}
# Now that we've generated the DWARF debugging info, rebuild our
# program using our debug info instead of the info generated by
# the compiler.
if { [prepare_for_testing ${testfile}.exp ${testfile} \
[list $srcfile $asm_file] {nodebug}] } {
return -1
}
if ![runto_main] {
return -1
}
gdb_test_no_output "set language ada"
# foo.three_ptr.all
gdb_test "print foo.three_ptr.all" \
" = \\(1, 2, 3\\)"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
gdb_test "print foo.three_ptr.all(1)" \
" = 1"
gdb_test "print foo.three_ptr.all(2)" \
" = 2"
gdb_test "print foo.three_ptr.all(3)" \
" = 3"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.three_ptr.all'first" \
" = 1"
gdb_test "print foo.three_ptr.all'last" \
" = 3"
gdb_test "print foo.three_ptr.all'length" \
" = 3"
gdb_test "ptype foo.three_ptr.all" \
" = array \\(<>\\) of integer"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
# foo.three_ptr
gdb_test "print foo.three_ptr(1)" \
" = 1"
gdb_test "print foo.three_ptr(2)" \
" = 2"
gdb_test "print foo.three_ptr(3)" \
" = 3"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.three_ptr'first" \
" = 1"
gdb_test "print foo.three_ptr'last" \
" = 3"
gdb_test "print foo.three_ptr'length" \
" = 3"
gdb_test "ptype foo.three_ptr" \
" = access array \\(<>\\) of integer"
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
# foo.three_ptr_tdef.all
gdb_test "print foo.three_ptr_tdef.all" \
" = \\(1, 2, 3\\)"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
gdb_test "print foo.three_ptr_tdef.all(1)" \
" = 1"
gdb_test "print foo.three_ptr_tdef.all(2)" \
" = 2"
gdb_test "print foo.three_ptr_tdef.all(3)" \
" = 3"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.three_ptr_tdef.all'first" \
" = 1"
gdb_test "print foo.three_ptr_tdef.all'last" \
" = 3"
gdb_test "print foo.three_ptr_tdef.all'length" \
" = 3"
gdb_test "ptype foo.three_ptr_tdef.all" \
" = array \\(<>\\) of integer"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
# foo.three_ptr_tdef
gdb_test "print foo.three_ptr_tdef(1)" \
" = 1"
gdb_test "print foo.three_ptr_tdef(2)" \
" = 2"
gdb_test "print foo.three_ptr_tdef(3)" \
" = 3"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.three_ptr_tdef'first" \
" = 1"
gdb_test "print foo.three_ptr_tdef'last" \
" = 3"
gdb_test "print foo.three_ptr_tdef'length" \
" = 3"
gdb_test "ptype foo.three_ptr_tdef" \
" = access array \\(<>\\) of integer"
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
# foo.five_ptr.all
gdb_test "print foo.five_ptr.all" \
" = \\(2 => 5, 8, 13, 21, 34\\)"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
gdb_test "print foo.five_ptr.all(2)" \
" = 5"
gdb_test "print foo.five_ptr.all(3)" \
" = 8"
gdb_test "print foo.five_ptr.all(4)" \
" = 13"
gdb_test "print foo.five_ptr.all(5)" \
" = 21"
gdb_test "print foo.five_ptr.all(6)" \
" = 34"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.five_ptr.all'first" \
" = 2"
gdb_test "print foo.five_ptr.all'last" \
" = 6"
gdb_test "print foo.five_ptr.all'length" \
" = 5"
gdb_test "ptype foo.five_ptr.all" \
" = array \\(<>\\) of integer"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
# foo.five_ptr
gdb_test "print foo.five_ptr(2)" \
" = 5"
gdb_test "print foo.five_ptr(3)" \
" = 8"
gdb_test "print foo.five_ptr(4)" \
" = 13"
gdb_test "print foo.five_ptr(5)" \
" = 21"
gdb_test "print foo.five_ptr(6)" \
" = 34"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.five_ptr'first" \
" = 2"
gdb_test "print foo.five_ptr'last" \
" = 6"
gdb_test "print foo.five_ptr'length" \
" = 5"
gdb_test "ptype foo.five_ptr" \
" = access array \\(<>\\) of integer"
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 15:50:13 +00:00
# foo.five_ptr_tdef.all
gdb_test "print foo.five_ptr_tdef.all" \
" = \\(2 => 5, 8, 13, 21, 34\\)"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
gdb_test "print foo.five_ptr_tdef.all(2)" \
" = 5"
gdb_test "print foo.five_ptr_tdef.all(3)" \
" = 8"
gdb_test "print foo.five_ptr_tdef.all(4)" \
" = 13"
gdb_test "print foo.five_ptr_tdef.all(5)" \
" = 21"
gdb_test "print foo.five_ptr_tdef.all(6)" \
" = 34"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.five_ptr_tdef.all'first" \
" = 2"
gdb_test "print foo.five_ptr_tdef.all'last" \
" = 6"
gdb_test "print foo.five_ptr_tdef.all'length" \
" = 5"
gdb_test "ptype foo.five_ptr_tdef.all" \
" = array \\(<>\\) of integer"
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 17:50:03 +00:00
# foo.five_ptr_tdef
gdb_test "print foo.five_ptr_tdef(2)" \
" = 5"
gdb_test "print foo.five_ptr_tdef(3)" \
" = 8"
gdb_test "print foo.five_ptr_tdef(4)" \
" = 13"
gdb_test "print foo.five_ptr_tdef(5)" \
" = 21"
gdb_test "print foo.five_ptr_tdef(6)" \
" = 34"
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 17:56:25 +00:00
gdb_test "print foo.five_ptr_tdef'first" \
" = 2"
gdb_test "print foo.five_ptr_tdef'last" \
" = 6"
gdb_test "print foo.five_ptr_tdef'length" \
" = 5"
gdb_test "ptype foo.five_ptr_tdef" \
" = access array \\(<>\\) of integer"