darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
old-cross-binutils/gdb/testsuite/gdb.dwarf2/data-loc.exp

292 lines
7.3 KiB
Text
Raw Normal View History

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 09:32:14 +00:00
# Copyright 2014-2015 Free Software Foundation, Inc.
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +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 data-loc.c data-loc-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 data-loc.c program.
# Any program would do, but since we already have data-loc.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}
} {
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
declare_labels integer_label array_label array_ptr_label
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
integer_label: DW_TAG_base_type {
{DW_AT_byte_size 4 DW_FORM_sdata}
{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}
{DW_AT_data_location {
DW_OP_push_object_address
DW_OP_deref
} SPECIAL_expr}
{external 1 flag}
} {
DW_TAG_subrange_type {
{DW_AT_type :$integer_label}
{DW_AT_lower_bound {
DW_OP_push_object_address
DW_OP_plus_uconst [get_sizeof "void *" 96]
DW_OP_deref
DW_OP_deref_size [get_sizeof "int" 4]
} SPECIAL_expr}
{DW_AT_upper_bound {
DW_OP_push_object_address
DW_OP_plus_uconst [get_sizeof "void *" 96]
DW_OP_deref
DW_OP_plus_uconst [get_sizeof "int" 4]
DW_OP_deref_size [get_sizeof "int" 4]
} SPECIAL_expr}
}
}
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
array_ptr_label: DW_TAG_typedef {
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
{DW_AT_name foo__array_type}
{DW_AT_type :$array_label}
}
DW_TAG_variable {
{DW_AT_name foo__three}
{DW_AT_type :$array_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]
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
} SPECIAL_expr}
{external 1 flag}
}
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
DW_TAG_variable {
{DW_AT_name foo__three_tdef}
{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]
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
} SPECIAL_expr}
{external 1 flag}
}
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
DW_TAG_variable {
{DW_AT_name foo__five}
{DW_AT_type :$array_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]
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
} SPECIAL_expr}
{external 1 flag}
}
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
DW_TAG_variable {
{DW_AT_name foo__five_tdef}
{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]
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
} SPECIAL_expr}
{external 1 flag}
}
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
}
}
}
# 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"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo.three
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "print foo.three" \
" = \\(1, 2, 3\\)"
gdb_test "ptype foo.three" \
"type = array \\(1 .. 3\\) of integer"
gdb_test "print foo.three(1)" \
" = 1"
gdb_test "print foo.three(2)" \
" = 2"
gdb_test "print foo.three(3)" \
" = 3"
gdb_test "print foo.three'first" \
" = 1"
gdb_test "print foo.three'last" \
" = 3"
gdb_test "print foo.three'length" \
" = 3"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo.three_tdef
gdb_test "print foo.three_tdef" \
" = \\(1, 2, 3\\)"
gdb_test "ptype foo.three_tdef" \
"type = array \\(1 .. 3\\) of integer"
gdb_test "print foo.three_tdef(1)" \
" = 1"
gdb_test "print foo.three_tdef(2)" \
" = 2"
gdb_test "print foo.three_tdef(3)" \
" = 3"
gdb_test "print foo.three_tdef'first" \
" = 1"
gdb_test "print foo.three_tdef'last" \
" = 3"
gdb_test "print foo.three_tdef'length" \
" = 3"
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "print foo.five" \
" = \\(2 => 5, 8, 13, 21, 34\\)"
gdb_test "ptype foo.five" \
"type = array \\(2 .. 6\\) of integer"
gdb_test "ptype foo.array_type" \
"type = array \\(<>\\) of integer"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo.five
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "print foo.five(2)" \
" = 5"
gdb_test "print foo.five(3)" \
" = 8"
gdb_test "print foo.five(4)" \
" = 13"
gdb_test "print foo.five(5)" \
" = 21"
gdb_test "print foo.five(6)" \
" = 34"
gdb_test "print foo.five'first" \
" = 2"
gdb_test "print foo.five'last" \
" = 6"
gdb_test "print foo.five'length" \
" = 5"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo.five_tdef
gdb_test "print foo.five_tdef" \
" = \\(2 => 5, 8, 13, 21, 34\\)"
gdb_test "ptype foo.five_tdef" \
"type = array \\(2 .. 6\\) of integer"
gdb_test "ptype foo.array_type" \
"type = array \\(<>\\) of integer"
gdb_test "print foo.five_tdef(2)" \
" = 5"
gdb_test "print foo.five_tdef(3)" \
" = 8"
gdb_test "print foo.five_tdef(4)" \
" = 13"
gdb_test "print foo.five_tdef(5)" \
" = 21"
gdb_test "print foo.five_tdef(6)" \
" = 34"
gdb_test "print foo.five_tdef'first" \
" = 2"
gdb_test "print foo.five_tdef'last" \
" = 6"
gdb_test "print foo.five_tdef'length" \
" = 5"
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test_no_output "set lang c"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo__three
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "print foo__three" \
" = \\{1, 2, 3\\}"
gdb_test "ptype foo__three" \
"type = integer \\\[3\\\]"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo__three_tdef
gdb_test "print foo__three_tdef" \
" = \\{1, 2, 3\\}"
gdb_test "ptype foo__three_tdef" \
"type = integer \\\[3\\\]"
# foo__five
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "print foo__five" \
" = \\{5, 8, 13, 21, 34\\}"
gdb_test "ptype foo__five" \
"type = integer \\\[5\\\]"
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 12:50:38 +00:00
# foo__five_tdef
gdb_test "print foo__five_tdef" \
" = \\{5, 8, 13, 21, 34\\}"
gdb_test "ptype foo__five_tdef" \
"type = integer \\\[5\\\]"
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-13 23:45:59 +00:00
gdb_test "ptype foo__array_type" \
"type = integer \\\[variable length\\\]"
Reference in a new issue Copy permalink