binutils-gdb/gdb/testsuite/gdb.dwarf2/nonvar-access.exp

233 lines
5.9 KiB
Plaintext
Raw Normal View History

# Copyright 2016-2017 Free Software Foundation, Inc.
# 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/>.
# Test accessing "non-variable" variables, i.e., variables which are
# optimized to a constant DWARF location expression and/or
# partially/fully optimized out.
load_lib dwarf.exp
if {![dwarf2_support]} { return 0 }
standard_testfile main.c nonvar-access-dw.S
# Make some DWARF for the test.
set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
cu {} {
compile_unit {
{DW_AT_name main.c}
} {
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
declare_labels int_type_label char_type_label \
struct_s_label struct_t_label array_a9_label \
Big-endian targets: Don't ignore offset into DW_OP_stack_value Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero offset into a DW_OP_implicit_value to be handled incorrectly on big-endian targets. GDB ignored the offset and copied the wrong bytes: https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html But there is still a similar issue when a DW_OP_implicit_pointer points into a DW_OP_stack_value instead; and again, the offset is ignored. There is an important difference, though: While implicit values are treated like blocks of data and anchored at the lowest-addressed byte, stack values traditionally contain integer numbers and are anchored at the *least significant* byte. Also, stack values do not come in varying sizes, but are cut down appropriately when used. Thus, on big-endian targets the scenario looks like this (higher addresses shown right): |<- - - - - Stack value - - - - - - ->| | | |<- original object ->| | | offset ->|####| ^^^^ de-referenced implicit pointer (Note how the original object's size influences the position of the de-referenced implicit pointer within the stack value. This is not the case for little-endian targets, where the original object starts at offset zero within the stack value.) This patch implements the logic indicated in the above diagram and adds an appropriate test case. A new function dwarf2_fetch_die_type_sect_off is added; it is used for retrieving the original object's type, so its size can be determined. That type is passed to dwarf2_evaluate_loc_desc_full via a new parameter. gdb/ChangeLog: * dwarf2loc.c (indirect_synthetic_pointer): Get data type of pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full. (dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename byte_offset to subobj_byte_offset. Fix the handling of DWARF_VALUE_STACK on big-endian targets when coming via an implicit pointer. (dwarf2_evaluate_loc_desc): Adjust call to dwarf2_evaluate_loc_desc_full. * dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration. * dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function. gdb/testsuite/ChangeLog: * lib/dwarf.exp: Add support for DW_OP_implicit_pointer. * gdb.dwarf2/nonvar-access.exp: Add test for stack value location and implicit pointer into such a location.
2017-03-17 02:50:24 +08:00
char_ptr_label implicit_a_label stack_b_label
int_type_label: base_type {
{name "int"}
{encoding @DW_ATE_signed}
{byte_size 4 DW_FORM_sdata}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
char_type_label: base_type {
{name "char"}
{encoding @DW_ATE_unsigned}
{byte_size 1 DW_FORM_sdata}
}
char_ptr_label: pointer_type {
{type :$char_type_label}
}
struct_s_label: structure_type {
{name s}
{byte_size 4 DW_FORM_sdata}
} {
member {
{name a}
{type :$int_type_label}
{data_member_location 0 DW_FORM_udata}
{bit_size 8 DW_FORM_udata}
}
member {
{name b}
{type :$int_type_label}
{data_bit_offset 8 DW_FORM_udata}
{bit_size 24 DW_FORM_udata}
}
}
struct_t_label: structure_type {
{name t}
{byte_size 4 DW_FORM_sdata}
} {
member {
{name a}
{type :$int_type_label}
{data_member_location 0 DW_FORM_udata}
{bit_size 9 DW_FORM_udata}
}
member {
{name b}
{type :$int_type_label}
{data_bit_offset 9 DW_FORM_udata}
{bit_size 23 DW_FORM_udata}
}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
array_a9_label: array_type {
{type :$char_type_label}
} {
subrange_type {
{type :$int_type_label}
{upper_bound 8 DW_FORM_udata}
}
}
DW_TAG_subprogram {
{name main}
{DW_AT_external 1 flag}
{low_pc [gdb_target_symbol main] DW_FORM_addr}
{high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr}
} {
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Simple variable without location.
DW_TAG_variable {
{name undef_int}
{type :$int_type_label}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Struct variable without location.
DW_TAG_variable {
{name undef_s}
{type :$struct_s_label}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Composite location: byte-aligned pieces.
DW_TAG_variable {
{name def_s}
{type :$struct_s_label}
{location {
const1u 0
stack_value
bit_piece 8 0
const1s -1
stack_value
bit_piece 24 0
} SPECIAL_expr}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Composite location: non-byte-aligned pieces.
DW_TAG_variable {
{name def_t}
{type :$struct_t_label}
{location {
const1u 0
stack_value
bit_piece 9 0
const1s -1
stack_value
bit_piece 23 0
} SPECIAL_expr}
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Implicit location: immediate value.
DW_TAG_variable {
{name def_implicit_s}
{type :$struct_s_label}
{location {
implicit_value 0x12 0x34 0x56 0x78
} SPECIAL_expr}
}
# Implicit location: immediate value for whole array, with
# excess bytes.
implicit_a_label: DW_TAG_variable {
{name def_implicit_a}
{type :$array_a9_label}
{location {
implicit_value 0x1 0x12 0x23 0x34 0x45 \
0x56 0x67 0x78 0x89 0x9a 0xab
} SPECIAL_expr}
}
# Implicit pointer into immediate value.
DW_TAG_variable {
{name implicit_a_ptr}
{type :$char_ptr_label}
{location {
Big-endian targets: Don't ignore offset into DW_OP_stack_value Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero offset into a DW_OP_implicit_value to be handled incorrectly on big-endian targets. GDB ignored the offset and copied the wrong bytes: https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html But there is still a similar issue when a DW_OP_implicit_pointer points into a DW_OP_stack_value instead; and again, the offset is ignored. There is an important difference, though: While implicit values are treated like blocks of data and anchored at the lowest-addressed byte, stack values traditionally contain integer numbers and are anchored at the *least significant* byte. Also, stack values do not come in varying sizes, but are cut down appropriately when used. Thus, on big-endian targets the scenario looks like this (higher addresses shown right): |<- - - - - Stack value - - - - - - ->| | | |<- original object ->| | | offset ->|####| ^^^^ de-referenced implicit pointer (Note how the original object's size influences the position of the de-referenced implicit pointer within the stack value. This is not the case for little-endian targets, where the original object starts at offset zero within the stack value.) This patch implements the logic indicated in the above diagram and adds an appropriate test case. A new function dwarf2_fetch_die_type_sect_off is added; it is used for retrieving the original object's type, so its size can be determined. That type is passed to dwarf2_evaluate_loc_desc_full via a new parameter. gdb/ChangeLog: * dwarf2loc.c (indirect_synthetic_pointer): Get data type of pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full. (dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename byte_offset to subobj_byte_offset. Fix the handling of DWARF_VALUE_STACK on big-endian targets when coming via an implicit pointer. (dwarf2_evaluate_loc_desc): Adjust call to dwarf2_evaluate_loc_desc_full. * dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration. * dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function. gdb/testsuite/ChangeLog: * lib/dwarf.exp: Add support for DW_OP_implicit_pointer. * gdb.dwarf2/nonvar-access.exp: Add test for stack value location and implicit pointer into such a location.
2017-03-17 02:50:24 +08:00
implicit_pointer $implicit_a_label 5
} SPECIAL_expr}
}
# Stack-value location.
stack_b_label: DW_TAG_variable {
{name def_stack_b}
{type :$struct_t_label}
{location {
const4u 0x1a2b3c4d
stack_value
} SPECIAL_expr}
}
# Implicit pointer into stack value.
DW_TAG_variable {
{name implicit_b_ptr}
{type :$char_ptr_label}
{location {
implicit_pointer $stack_b_label 1
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
} SPECIAL_expr}
}
}
}
}
}
Fix more cases of improper test names I noticed more occurrences of improper test names. The rather mechanical, tedious and large patch below addresses, hopefully, most of the leftover cases. As usual, another pair of eyes is welcome to check if missed something or did an invalid substitution. This patch also fixes the prepare_for_testing calls to pass proper test names. gdb/testsuite/ChangeLog: 2016-12-23 Luis Machado <lgustavo@codesourcery.com> Fix test names for the following files: * gdb.ada/exec_changed.exp * gdb.ada/info_types.exp * gdb.arch/aarch64-atomic-inst.exp * gdb.arch/aarch64-fp.exp * gdb.arch/altivec-abi.exp * gdb.arch/altivec-regs.exp * gdb.arch/amd64-byte.exp * gdb.arch/amd64-disp-step.exp * gdb.arch/amd64-dword.exp * gdb.arch/amd64-entry-value-inline.exp * gdb.arch/amd64-entry-value-param.exp * gdb.arch/amd64-entry-value-paramref.exp * gdb.arch/amd64-entry-value.exp * gdb.arch/amd64-i386-address.exp * gdb.arch/amd64-invalid-stack-middle.exp * gdb.arch/amd64-invalid-stack-top.exp * gdb.arch/amd64-optimout-repeat.exp * gdb.arch/amd64-prologue-skip.exp * gdb.arch/amd64-prologue-xmm.exp * gdb.arch/amd64-stap-special-operands.exp * gdb.arch/amd64-stap-wrong-subexp.exp * gdb.arch/amd64-tailcall-cxx.exp * gdb.arch/amd64-tailcall-noret.exp * gdb.arch/amd64-tailcall-ret.exp * gdb.arch/amd64-tailcall-self.exp * gdb.arch/amd64-word.exp * gdb.arch/arm-bl-branch-dest.exp * gdb.arch/arm-disp-step.exp * gdb.arch/arm-neon.exp * gdb.arch/arm-single-step-kernel-helper.exp * gdb.arch/avr-flash-qualifier.exp * gdb.arch/disp-step-insn-reloc.exp * gdb.arch/e500-abi.exp * gdb.arch/e500-regs.exp * gdb.arch/ftrace-insn-reloc.exp * gdb.arch/i386-avx512.exp * gdb.arch/i386-bp_permanent.exp * gdb.arch/i386-byte.exp * gdb.arch/i386-cfi-notcurrent.exp * gdb.arch/i386-disp-step.exp * gdb.arch/i386-dr3-watch.exp * gdb.arch/i386-float.exp * gdb.arch/i386-gnu-cfi.exp * gdb.arch/i386-mpx-map.exp * gdb.arch/i386-mpx-sigsegv.exp * gdb.arch/i386-mpx-simple_segv.exp * gdb.arch/i386-mpx.exp * gdb.arch/i386-permbkpt.exp * gdb.arch/i386-prologue.exp * gdb.arch/i386-signal.exp * gdb.arch/i386-size-overlap.exp * gdb.arch/i386-unwind.exp * gdb.arch/i386-word.exp * gdb.arch/mips-fcr.exp * gdb.arch/powerpc-d128-regs.exp * gdb.arch/powerpc-stackless.exp * gdb.arch/ppc64-atomic-inst.exp * gdb.arch/s390-stackless.exp * gdb.arch/s390-tdbregs.exp * gdb.arch/s390-vregs.exp * gdb.arch/sparc-sysstep.exp * gdb.arch/thumb-bx-pc.exp * gdb.arch/thumb-singlestep.exp * gdb.arch/thumb2-it.exp * gdb.arch/vsx-regs.exp * gdb.asm/asm-source.exp * gdb.base/a2-run.exp * gdb.base/advance.exp * gdb.base/all-bin.exp * gdb.base/anon.exp * gdb.base/args.exp * gdb.base/arithmet.exp * gdb.base/async-shell.exp * gdb.base/async.exp * gdb.base/attach-pie-noexec.exp * gdb.base/attach-twice.exp * gdb.base/auto-load.exp * gdb.base/bang.exp * gdb.base/bitfields.exp * gdb.base/break-always.exp * gdb.base/break-caller-line.exp * gdb.base/break-entry.exp * gdb.base/break-inline.exp * gdb.base/break-on-linker-gcd-function.exp * gdb.base/break-probes.exp * gdb.base/break.exp * gdb.base/breakpoint-shadow.exp * gdb.base/call-ar-st.exp * gdb.base/call-sc.exp * gdb.base/call-signal-resume.exp * gdb.base/call-strs.exp * gdb.base/callfuncs.exp * gdb.base/catch-fork-static.exp * gdb.base/catch-gdb-caused-signals.exp * gdb.base/catch-load.exp * gdb.base/catch-signal-fork.exp * gdb.base/catch-signal.exp * gdb.base/catch-syscall.exp * gdb.base/charset.exp * gdb.base/checkpoint.exp * gdb.base/chng-syms.exp * gdb.base/code-expr.exp * gdb.base/code_elim.exp * gdb.base/commands.exp * gdb.base/completion.exp * gdb.base/complex.exp * gdb.base/cond-expr.exp * gdb.base/condbreak.exp * gdb.base/consecutive.exp * gdb.base/continue-all-already-running.exp * gdb.base/coredump-filter.exp * gdb.base/corefile.exp * gdb.base/dbx.exp * gdb.base/debug-expr.exp * gdb.base/define.exp * gdb.base/del.exp * gdb.base/disabled-location.exp * gdb.base/disasm-end-cu.exp * gdb.base/disasm-optim.exp * gdb.base/display.exp * gdb.base/duplicate-bp.exp * gdb.base/ena-dis-br.exp * gdb.base/ending-run.exp * gdb.base/enumval.exp * gdb.base/environ.exp * gdb.base/eu-strip-infcall.exp * gdb.base/eval-avoid-side-effects.exp * gdb.base/eval-skip.exp * gdb.base/exitsignal.exp * gdb.base/expand-psymtabs.exp * gdb.base/filesym.exp * gdb.base/find-unmapped.exp * gdb.base/finish.exp * gdb.base/float.exp * gdb.base/foll-exec-mode.exp * gdb.base/foll-exec.exp * gdb.base/foll-fork.exp * gdb.base/fortran-sym-case.exp * gdb.base/freebpcmd.exp * gdb.base/func-ptr.exp * gdb.base/func-ptrs.exp * gdb.base/funcargs.exp * gdb.base/gcore-buffer-overflow.exp * gdb.base/gcore-relro-pie.exp * gdb.base/gcore-relro.exp * gdb.base/gcore.exp * gdb.base/gdb1090.exp * gdb.base/gdb11530.exp * gdb.base/gdb11531.exp * gdb.base/gdb1821.exp * gdb.base/gdbindex-stabs.exp * gdb.base/gdbvars.exp * gdb.base/hbreak.exp * gdb.base/hbreak2.exp * gdb.base/included.exp * gdb.base/infcall-input.exp * gdb.base/inferior-died.exp * gdb.base/infnan.exp * gdb.base/info-macros.exp * gdb.base/info-os.exp * gdb.base/info-proc.exp * gdb.base/info-shared.exp * gdb.base/info-target.exp * gdb.base/infoline.exp * gdb.base/interp.exp * gdb.base/interrupt.exp * gdb.base/jit-reader.exp * gdb.base/jit-simple.exp * gdb.base/kill-after-signal.exp * gdb.base/kill-detach-inferiors-cmd.exp * gdb.base/label.exp * gdb.base/langs.exp * gdb.base/ldbl_e308.exp * gdb.base/line-symtabs.exp * gdb.base/linespecs.exp * gdb.base/list.exp * gdb.base/long_long.exp * gdb.base/longest-types.exp * gdb.base/maint.exp * gdb.base/max-value-size.exp * gdb.base/memattr.exp * gdb.base/mips_pro.exp * gdb.base/morestack.exp * gdb.base/moribund-step.exp * gdb.base/multi-forks.exp * gdb.base/nested-addr.exp * gdb.base/nextoverexit.exp * gdb.base/noreturn-finish.exp * gdb.base/noreturn-return.exp * gdb.base/nostdlib.exp * gdb.base/offsets.exp * gdb.base/opaque.exp * gdb.base/pc-fp.exp * gdb.base/permissions.exp * gdb.base/print-symbol-loading.exp * gdb.base/prologue-include.exp * gdb.base/psymtab.exp * gdb.base/ptype.exp * gdb.base/random-signal.exp * gdb.base/randomize.exp * gdb.base/range-stepping.exp * gdb.base/readline-ask.exp * gdb.base/recpar.exp * gdb.base/recurse.exp * gdb.base/relational.exp * gdb.base/restore.exp * gdb.base/return-nodebug.exp * gdb.base/return.exp * gdb.base/run-after-attach.exp * gdb.base/save-bp.exp * gdb.base/scope.exp * gdb.base/sect-cmd.exp * gdb.base/set-lang-auto.exp * gdb.base/set-noassign.exp * gdb.base/setvar.exp * gdb.base/sigall.exp * gdb.base/sigbpt.exp * gdb.base/siginfo-addr.exp * gdb.base/siginfo-infcall.exp * gdb.base/siginfo-obj.exp * gdb.base/siginfo.exp * gdb.base/signals-state-child.exp * gdb.base/signest.exp * gdb.base/sigstep.exp * gdb.base/sizeof.exp * gdb.base/skip.exp * gdb.base/solib-corrupted.exp * gdb.base/solib-nodir.exp * gdb.base/solib-search.exp * gdb.base/stack-checking.exp * gdb.base/stale-infcall.exp * gdb.base/stap-probe.exp * gdb.base/start.exp * gdb.base/step-break.exp * gdb.base/step-bt.exp * gdb.base/step-line.exp * gdb.base/step-over-exit.exp * gdb.base/step-over-syscall.exp * gdb.base/step-resume-infcall.exp * gdb.base/step-test.exp * gdb.base/store.exp * gdb.base/structs3.exp * gdb.base/sym-file.exp * gdb.base/symbol-without-target_section.exp * gdb.base/term.exp * gdb.base/testenv.exp * gdb.base/ui-redirect.exp * gdb.base/until.exp * gdb.base/unwindonsignal.exp * gdb.base/value-double-free.exp * gdb.base/vla-datatypes.exp * gdb.base/vla-ptr.exp * gdb.base/vla-sideeffect.exp * gdb.base/volatile.exp * gdb.base/watch-cond-infcall.exp * gdb.base/watch-cond.exp * gdb.base/watch-non-mem.exp * gdb.base/watch-read.exp * gdb.base/watch-vfork.exp * gdb.base/watchpoint-cond-gone.exp * gdb.base/watchpoint-delete.exp * gdb.base/watchpoint-hw-hit-once.exp * gdb.base/watchpoint-hw.exp * gdb.base/watchpoint-stops-at-right-insn.exp * gdb.base/watchpoints.exp * gdb.base/wchar.exp * gdb.base/whatis-exp.exp * gdb.btrace/buffer-size.exp * gdb.btrace/data.exp * gdb.btrace/delta.exp * gdb.btrace/dlopen.exp * gdb.btrace/enable.exp * gdb.btrace/exception.exp * gdb.btrace/function_call_history.exp * gdb.btrace/gcore.exp * gdb.btrace/instruction_history.exp * gdb.btrace/nohist.exp * gdb.btrace/reconnect.exp * gdb.btrace/record_goto-step.exp * gdb.btrace/record_goto.exp * gdb.btrace/rn-dl-bind.exp * gdb.btrace/segv.exp * gdb.btrace/step.exp * gdb.btrace/stepi.exp * gdb.btrace/tailcall-only.exp * gdb.btrace/tailcall.exp * gdb.btrace/tsx.exp * gdb.btrace/unknown_functions.exp * gdb.btrace/vdso.exp * gdb.compile/compile-ifunc.exp * gdb.compile/compile-ops.exp * gdb.compile/compile-print.exp * gdb.compile/compile-setjmp.exp * gdb.cp/abstract-origin.exp * gdb.cp/ambiguous.exp * gdb.cp/annota2.exp * gdb.cp/annota3.exp * gdb.cp/anon-ns.exp * gdb.cp/anon-struct.exp * gdb.cp/anon-union.exp * gdb.cp/arg-reference.exp * gdb.cp/baseenum.exp * gdb.cp/bool.exp * gdb.cp/breakpoint.exp * gdb.cp/bs15503.exp * gdb.cp/call-c.exp * gdb.cp/casts.exp * gdb.cp/chained-calls.exp * gdb.cp/class2.exp * gdb.cp/classes.exp * gdb.cp/cmpd-minsyms.exp * gdb.cp/converts.exp * gdb.cp/cp-relocate.exp * gdb.cp/cpcompletion.exp * gdb.cp/cpexprs.exp * gdb.cp/cplabel.exp * gdb.cp/cplusfuncs.exp * gdb.cp/cpsizeof.exp * gdb.cp/ctti.exp * gdb.cp/derivation.exp * gdb.cp/destrprint.exp * gdb.cp/dispcxx.exp * gdb.cp/enum-class.exp * gdb.cp/exception.exp * gdb.cp/exceptprint.exp * gdb.cp/expand-psymtabs-cxx.exp * gdb.cp/expand-sals.exp * gdb.cp/extern-c.exp * gdb.cp/filename.exp * gdb.cp/formatted-ref.exp * gdb.cp/fpointer.exp * gdb.cp/gdb1355.exp * gdb.cp/gdb2495.exp * gdb.cp/hang.exp * gdb.cp/impl-this.exp * gdb.cp/infcall-dlopen.exp * gdb.cp/inherit.exp * gdb.cp/iostream.exp * gdb.cp/koenig.exp * gdb.cp/local.exp * gdb.cp/m-data.exp * gdb.cp/m-static.exp * gdb.cp/mb-ctor.exp * gdb.cp/mb-inline.exp * gdb.cp/mb-templates.exp * gdb.cp/member-name.exp * gdb.cp/member-ptr.exp * gdb.cp/meth-typedefs.exp * gdb.cp/method.exp * gdb.cp/method2.exp * gdb.cp/minsym-fallback.exp * gdb.cp/misc.exp * gdb.cp/namelessclass.exp * gdb.cp/namespace-enum.exp * gdb.cp/namespace-nested-import.exp * gdb.cp/namespace.exp * gdb.cp/nextoverthrow.exp * gdb.cp/no-dmgl-verbose.exp * gdb.cp/non-trivial-retval.exp * gdb.cp/noparam.exp * gdb.cp/nsdecl.exp * gdb.cp/nsimport.exp * gdb.cp/nsnested.exp * gdb.cp/nsnoimports.exp * gdb.cp/nsrecurs.exp * gdb.cp/nsstress.exp * gdb.cp/nsusing.exp * gdb.cp/operator.exp * gdb.cp/oranking.exp * gdb.cp/overload-const.exp * gdb.cp/overload.exp * gdb.cp/ovldbreak.exp * gdb.cp/ovsrch.exp * gdb.cp/paren-type.exp * gdb.cp/parse-lang.exp * gdb.cp/pass-by-ref.exp * gdb.cp/pr-1023.exp * gdb.cp/pr-1210.exp * gdb.cp/pr-574.exp * gdb.cp/pr10687.exp * gdb.cp/pr12028.exp * gdb.cp/pr17132.exp * gdb.cp/pr17494.exp * gdb.cp/pr9067.exp * gdb.cp/pr9167.exp * gdb.cp/pr9631.exp * gdb.cp/printmethod.exp * gdb.cp/psmang.exp * gdb.cp/psymtab-parameter.exp * gdb.cp/ptype-cv-cp.exp * gdb.cp/ptype-flags.exp * gdb.cp/re-set-overloaded.exp * gdb.cp/ref-types.exp * gdb.cp/rtti.exp * gdb.cp/scope-err.exp * gdb.cp/shadow.exp * gdb.cp/smartp.exp * gdb.cp/static-method.exp * gdb.cp/static-print-quit.exp * gdb.cp/temargs.exp * gdb.cp/templates.exp * gdb.cp/try_catch.exp * gdb.cp/typedef-operator.exp * gdb.cp/typeid.exp * gdb.cp/userdef.exp * gdb.cp/using-crash.exp * gdb.cp/var-tag.exp * gdb.cp/virtbase.exp * gdb.cp/virtfunc.exp * gdb.cp/virtfunc2.exp * gdb.cp/vla-cxx.exp * gdb.disasm/t01_mov.exp * gdb.disasm/t02_mova.exp * gdb.disasm/t03_add.exp * gdb.disasm/t04_sub.exp * gdb.disasm/t05_cmp.exp * gdb.disasm/t06_ari2.exp * gdb.disasm/t07_ari3.exp * gdb.disasm/t08_or.exp * gdb.disasm/t09_xor.exp * gdb.disasm/t10_and.exp * gdb.disasm/t11_logs.exp * gdb.disasm/t12_bit.exp * gdb.disasm/t13_otr.exp * gdb.dlang/circular.exp * gdb.dwarf2/arr-stride.exp * gdb.dwarf2/arr-subrange.exp * gdb.dwarf2/atomic-type.exp * gdb.dwarf2/bad-regnum.exp * gdb.dwarf2/bitfield-parent-optimized-out.exp * gdb.dwarf2/callframecfa.exp * gdb.dwarf2/clztest.exp * gdb.dwarf2/corrupt.exp * gdb.dwarf2/data-loc.exp * gdb.dwarf2/dup-psym.exp * gdb.dwarf2/dw2-anon-mptr.exp * gdb.dwarf2/dw2-anonymous-func.exp * gdb.dwarf2/dw2-bad-mips-linkage-name.exp * gdb.dwarf2/dw2-bad-unresolved.exp * gdb.dwarf2/dw2-basic.exp * gdb.dwarf2/dw2-canonicalize-type.exp * gdb.dwarf2/dw2-case-insensitive.exp * gdb.dwarf2/dw2-common-block.exp * gdb.dwarf2/dw2-compdir-oldgcc.exp * gdb.dwarf2/dw2-compressed.exp * gdb.dwarf2/dw2-const.exp * gdb.dwarf2/dw2-cp-infcall-ref-static.exp * gdb.dwarf2/dw2-cu-size.exp * gdb.dwarf2/dw2-dup-frame.exp * gdb.dwarf2/dw2-entry-value.exp * gdb.dwarf2/dw2-icycle.exp * gdb.dwarf2/dw2-ifort-parameter.exp * gdb.dwarf2/dw2-inline-break.exp * gdb.dwarf2/dw2-inline-param.exp * gdb.dwarf2/dw2-intercu.exp * gdb.dwarf2/dw2-intermix.exp * gdb.dwarf2/dw2-lexical-block-bare.exp * gdb.dwarf2/dw2-linkage-name-trust.exp * gdb.dwarf2/dw2-minsym-in-cu.exp * gdb.dwarf2/dw2-noloc.exp * gdb.dwarf2/dw2-op-call.exp * gdb.dwarf2/dw2-op-out-param.exp * gdb.dwarf2/dw2-opt-structptr.exp * gdb.dwarf2/dw2-param-error.exp * gdb.dwarf2/dw2-producer.exp * gdb.dwarf2/dw2-ranges-base.exp * gdb.dwarf2/dw2-ref-missing-frame.exp * gdb.dwarf2/dw2-reg-undefined.exp * gdb.dwarf2/dw2-regno-invalid.exp * gdb.dwarf2/dw2-restore.exp * gdb.dwarf2/dw2-restrict.exp * gdb.dwarf2/dw2-single-line-discriminators.exp * gdb.dwarf2/dw2-strp.exp * gdb.dwarf2/dw2-undefined-ret-addr.exp * gdb.dwarf2/dw2-unresolved.exp * gdb.dwarf2/dw2-var-zero-addr.exp * gdb.dwarf2/dw4-sig-types.exp * gdb.dwarf2/dwz.exp * gdb.dwarf2/dynarr-ptr.exp * gdb.dwarf2/enum-type.exp * gdb.dwarf2/gdb-index.exp * gdb.dwarf2/implptr-64bit.exp * gdb.dwarf2/implptr-optimized-out.exp * gdb.dwarf2/implptr.exp * gdb.dwarf2/implref-array.exp * gdb.dwarf2/implref-const.exp * gdb.dwarf2/implref-global.exp * gdb.dwarf2/implref-struct.exp * gdb.dwarf2/mac-fileno.exp * gdb.dwarf2/main-subprogram.exp * gdb.dwarf2/member-ptr-forwardref.exp * gdb.dwarf2/method-ptr.exp * gdb.dwarf2/missing-sig-type.exp * gdb.dwarf2/nonvar-access.exp * gdb.dwarf2/opaque-type-lookup.exp * gdb.dwarf2/pieces-optimized-out.exp * gdb.dwarf2/pieces.exp * gdb.dwarf2/pr10770.exp * gdb.dwarf2/pr13961.exp * gdb.dwarf2/staticvirtual.exp * gdb.dwarf2/subrange.exp * gdb.dwarf2/symtab-producer.exp * gdb.dwarf2/trace-crash.exp * gdb.dwarf2/typeddwarf.exp * gdb.dwarf2/valop.exp * gdb.dwarf2/watch-notconst.exp * gdb.fortran/array-element.exp * gdb.fortran/charset.exp * gdb.fortran/common-block.exp * gdb.fortran/complex.exp * gdb.fortran/derived-type-function.exp * gdb.fortran/derived-type.exp * gdb.fortran/logical.exp * gdb.fortran/module.exp * gdb.fortran/multi-dim.exp * gdb.fortran/nested-funcs.exp * gdb.fortran/print-formatted.exp * gdb.fortran/subarray.exp * gdb.fortran/vla-alloc-assoc.exp * gdb.fortran/vla-datatypes.exp * gdb.fortran/vla-history.exp * gdb.fortran/vla-ptr-info.exp * gdb.fortran/vla-ptype-sub.exp * gdb.fortran/vla-ptype.exp * gdb.fortran/vla-sizeof.exp * gdb.fortran/vla-type.exp * gdb.fortran/vla-value-sub-arbitrary.exp * gdb.fortran/vla-value-sub-finish.exp * gdb.fortran/vla-value-sub.exp * gdb.fortran/vla-value.exp * gdb.fortran/whatis_type.exp * gdb.go/chan.exp * gdb.go/handcall.exp * gdb.go/hello.exp * gdb.go/integers.exp * gdb.go/methods.exp * gdb.go/package.exp * gdb.go/strings.exp * gdb.go/types.exp * gdb.go/unsafe.exp * gdb.guile/scm-arch.exp * gdb.guile/scm-block.exp * gdb.guile/scm-breakpoint.exp * gdb.guile/scm-cmd.exp * gdb.guile/scm-disasm.exp * gdb.guile/scm-equal.exp * gdb.guile/scm-frame-args.exp * gdb.guile/scm-frame-inline.exp * gdb.guile/scm-frame.exp * gdb.guile/scm-iterator.exp * gdb.guile/scm-math.exp * gdb.guile/scm-objfile.exp * gdb.guile/scm-ports.exp * gdb.guile/scm-symbol.exp * gdb.guile/scm-symtab.exp * gdb.guile/scm-value-cc.exp * gdb.guile/types-module.exp * gdb.linespec/break-ask.exp * gdb.linespec/cpexplicit.exp * gdb.linespec/explicit.exp * gdb.linespec/keywords.exp * gdb.linespec/linespec.exp * gdb.linespec/ls-dollar.exp * gdb.linespec/ls-errs.exp * gdb.linespec/skip-two.exp * gdb.linespec/thread.exp * gdb.mi/mi-async.exp * gdb.mi/mi-basics.exp * gdb.mi/mi-break.exp * gdb.mi/mi-catch-load.exp * gdb.mi/mi-cli.exp * gdb.mi/mi-cmd-param-changed.exp * gdb.mi/mi-console.exp * gdb.mi/mi-detach.exp * gdb.mi/mi-disassemble.exp * gdb.mi/mi-eval.exp * gdb.mi/mi-file-transfer.exp * gdb.mi/mi-file.exp * gdb.mi/mi-fill-memory.exp * gdb.mi/mi-inheritance-syntax-error.exp * gdb.mi/mi-linespec-err-cp.exp * gdb.mi/mi-logging.exp * gdb.mi/mi-memory-changed.exp * gdb.mi/mi-read-memory.exp * gdb.mi/mi-record-changed.exp * gdb.mi/mi-reg-undefined.exp * gdb.mi/mi-regs.exp * gdb.mi/mi-return.exp * gdb.mi/mi-reverse.exp * gdb.mi/mi-simplerun.exp * gdb.mi/mi-solib.exp * gdb.mi/mi-stack.exp * gdb.mi/mi-stepi.exp * gdb.mi/mi-syn-frame.exp * gdb.mi/mi-until.exp * gdb.mi/mi-var-block.exp * gdb.mi/mi-var-child.exp * gdb.mi/mi-var-cmd.exp * gdb.mi/mi-var-cp.exp * gdb.mi/mi-var-display.exp * gdb.mi/mi-var-invalidate.exp * gdb.mi/mi-var-list-children-invalid-grandchild.exp * gdb.mi/mi-vla-fortran.exp * gdb.mi/mi-watch.exp * gdb.mi/mi2-var-child.exp * gdb.mi/user-selected-context-sync.exp * gdb.modula2/unbounded-array.exp * gdb.multi/dummy-frame-restore.exp * gdb.multi/multi-arch-exec.exp * gdb.multi/multi-arch.exp * gdb.multi/tids.exp * gdb.multi/watchpoint-multi.exp * gdb.opencl/callfuncs.exp * gdb.opencl/convs_casts.exp * gdb.opencl/datatypes.exp * gdb.opencl/operators.exp * gdb.opencl/vec_comps.exp * gdb.opt/clobbered-registers-O2.exp * gdb.opt/inline-break.exp * gdb.opt/inline-bt.exp * gdb.opt/inline-cmds.exp * gdb.opt/inline-locals.exp * gdb.pascal/case-insensitive-symbols.exp * gdb.pascal/floats.exp * gdb.pascal/gdb11492.exp * gdb.python/lib-types.exp * gdb.python/py-arch.exp * gdb.python/py-as-string.exp * gdb.python/py-bad-printers.exp * gdb.python/py-block.exp * gdb.python/py-breakpoint-create-fail.exp * gdb.python/py-breakpoint.exp * gdb.python/py-caller-is.exp * gdb.python/py-cmd.exp * gdb.python/py-explore-cc.exp * gdb.python/py-explore.exp * gdb.python/py-finish-breakpoint.exp * gdb.python/py-finish-breakpoint2.exp * gdb.python/py-frame-args.exp * gdb.python/py-frame-inline.exp * gdb.python/py-frame.exp * gdb.python/py-framefilter-mi.exp * gdb.python/py-infthread.exp * gdb.python/py-lazy-string.exp * gdb.python/py-linetable.exp * gdb.python/py-mi-events.exp * gdb.python/py-mi-objfile.exp * gdb.python/py-mi.exp * gdb.python/py-objfile.exp * gdb.python/py-pp-integral.exp * gdb.python/py-pp-maint.exp * gdb.python/py-pp-re-notag.exp * gdb.python/py-pp-registration.exp * gdb.python/py-recurse-unwind.exp * gdb.python/py-strfns.exp * gdb.python/py-symbol.exp * gdb.python/py-symtab.exp * gdb.python/py-sync-interp.exp * gdb.python/py-typeprint.exp * gdb.python/py-unwind-maint.exp * gdb.python/py-unwind.exp * gdb.python/py-value-cc.exp * gdb.python/py-xmethods.exp * gdb.reverse/amd64-tailcall-reverse.exp * gdb.reverse/break-precsave.exp * gdb.reverse/break-reverse.exp * gdb.reverse/consecutive-precsave.exp * gdb.reverse/consecutive-reverse.exp * gdb.reverse/finish-precsave.exp * gdb.reverse/finish-reverse-bkpt.exp * gdb.reverse/finish-reverse.exp * gdb.reverse/fstatat-reverse.exp * gdb.reverse/getresuid-reverse.exp * gdb.reverse/i386-precsave.exp * gdb.reverse/i386-reverse.exp * gdb.reverse/i386-sse-reverse.exp * gdb.reverse/i387-env-reverse.exp * gdb.reverse/i387-stack-reverse.exp * gdb.reverse/insn-reverse.exp * gdb.reverse/machinestate-precsave.exp * gdb.reverse/machinestate.exp * gdb.reverse/next-reverse-bkpt-over-sr.exp * gdb.reverse/pipe-reverse.exp * gdb.reverse/readv-reverse.exp * gdb.reverse/recvmsg-reverse.exp * gdb.reverse/rerun-prec.exp * gdb.reverse/s390-mvcle.exp * gdb.reverse/step-precsave.exp * gdb.reverse/step-reverse.exp * gdb.reverse/time-reverse.exp * gdb.reverse/until-precsave.exp * gdb.reverse/until-reverse.exp * gdb.reverse/waitpid-reverse.exp * gdb.reverse/watch-precsave.exp * gdb.reverse/watch-reverse.exp * gdb.rust/generics.exp * gdb.rust/methods.exp * gdb.rust/modules.exp * gdb.rust/simple.exp * gdb.server/connect-with-no-symbol-file.exp * gdb.server/ext-attach.exp * gdb.server/ext-restart.exp * gdb.server/ext-wrapper.exp * gdb.server/file-transfer.exp * gdb.server/server-exec-info.exp * gdb.server/server-kill.exp * gdb.server/server-mon.exp * gdb.server/wrapper.exp * gdb.stabs/exclfwd.exp * gdb.stabs/gdb11479.exp * gdb.threads/clone-new-thread-event.exp * gdb.threads/corethreads.exp * gdb.threads/current-lwp-dead.exp * gdb.threads/dlopen-libpthread.exp * gdb.threads/gcore-thread.exp * gdb.threads/sigstep-threads.exp * gdb.threads/watchpoint-fork.exp * gdb.trace/actions-changed.exp * gdb.trace/backtrace.exp * gdb.trace/change-loc.exp * gdb.trace/circ.exp * gdb.trace/collection.exp * gdb.trace/disconnected-tracing.exp * gdb.trace/ftrace.exp * gdb.trace/mi-trace-frame-collected.exp * gdb.trace/mi-trace-unavailable.exp * gdb.trace/mi-traceframe-changed.exp * gdb.trace/mi-tsv-changed.exp * gdb.trace/no-attach-trace.exp * gdb.trace/passc-dyn.exp * gdb.trace/qtro.exp * gdb.trace/range-stepping.exp * gdb.trace/read-memory.exp * gdb.trace/save-trace.exp * gdb.trace/signal.exp * gdb.trace/status-stop.exp * gdb.trace/tfile.exp * gdb.trace/trace-break.exp * gdb.trace/trace-buffer-size.exp * gdb.trace/trace-condition.exp * gdb.trace/tracefile-pseudo-reg.exp * gdb.trace/tstatus.exp * gdb.trace/unavailable.exp * gdb.trace/while-dyn.exp * gdb.trace/while-stepping.exp
2016-12-24 00:52:18 +08:00
if { [prepare_for_testing "failed to prepare" ${testfile} \
[list $srcfile $asm_file] {nodebug}] } {
return -1
}
if ![runto_main] {
return -1
}
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Determine endianness.
set endian "little"
gdb_test_multiple "show endian" "determine endianness" {
-re ".* (big|little) endian.*$gdb_prompt $" {
set endian $expect_out(1,string)
pass "endianness: $endian"
}
}
# Byte-aligned objects with simple location descriptions.
switch $endian { big {set val 0x345678} little {set val 0x785634} }
gdb_test "print/x def_implicit_s" " = \\{a = 0x12, b = $val\\}"
gdb_test "print/x def_implicit_s.b" " = $val"
gdb_test "print/x def_implicit_a" \
" = \\{0x1, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0x78, 0x89\\}"
gdb_test "print/x def_implicit_a\[5\]" " = 0x56"
gdb_test "print/x *(char (*)\[5\]) implicit_a_ptr" \
" = \\{0x56, 0x67, 0x78, 0x89, 0x9a\\}"
Big-endian targets: Don't ignore offset into DW_OP_stack_value Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero offset into a DW_OP_implicit_value to be handled incorrectly on big-endian targets. GDB ignored the offset and copied the wrong bytes: https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html But there is still a similar issue when a DW_OP_implicit_pointer points into a DW_OP_stack_value instead; and again, the offset is ignored. There is an important difference, though: While implicit values are treated like blocks of data and anchored at the lowest-addressed byte, stack values traditionally contain integer numbers and are anchored at the *least significant* byte. Also, stack values do not come in varying sizes, but are cut down appropriately when used. Thus, on big-endian targets the scenario looks like this (higher addresses shown right): |<- - - - - Stack value - - - - - - ->| | | |<- original object ->| | | offset ->|####| ^^^^ de-referenced implicit pointer (Note how the original object's size influences the position of the de-referenced implicit pointer within the stack value. This is not the case for little-endian targets, where the original object starts at offset zero within the stack value.) This patch implements the logic indicated in the above diagram and adds an appropriate test case. A new function dwarf2_fetch_die_type_sect_off is added; it is used for retrieving the original object's type, so its size can be determined. That type is passed to dwarf2_evaluate_loc_desc_full via a new parameter. gdb/ChangeLog: * dwarf2loc.c (indirect_synthetic_pointer): Get data type of pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full. (dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename byte_offset to subobj_byte_offset. Fix the handling of DWARF_VALUE_STACK on big-endian targets when coming via an implicit pointer. (dwarf2_evaluate_loc_desc): Adjust call to dwarf2_evaluate_loc_desc_full. * dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration. * dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function. gdb/testsuite/ChangeLog: * lib/dwarf.exp: Add support for DW_OP_implicit_pointer. * gdb.dwarf2/nonvar-access.exp: Add test for stack value location and implicit pointer into such a location.
2017-03-17 02:50:24 +08:00
switch $endian {
big {set val "a = 52, b = 2833485"}
little {set val "a = 77, b = 857502"}
}
gdb_test "print def_stack_b" " = \\{$val\\}"
switch $endian {big {set val 0x2b} little {set val 0x3c}}
gdb_test "print/x *implicit_b_ptr" " = $val"
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Byte-aligned fields, pieced together from DWARF stack values.
gdb_test "print def_s" " = \\{a = 0, b = -1\\}"
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Non-byte-aligned fields, pieced together from DWARF stack values.
gdb_test "print def_t" " = \\{a = 0, b = -1\\}"
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Simple variable without location.
gdb_test "print undef_int" " = <optimized out>"
Big-endian targets: Don't ignore offset into DW_OP_implicit_value When a variable's location is expressed as DW_OP_implicit_value, but the given value is longer than needed, which bytes should be used? GDB's current logic was introduced with a patch from 2011 and uses the "least significant" bytes: https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html Now consider a sub-value from such a location at a given offset, accessed through DW_OP_implicit_pointer. Which bytes should be used for that? The patch above *always* uses the last bytes on big-endian targets, ignoring the offset. E.g., given the code snippet const char foo[] = "Hello, world!"; const char *a = &foo[0]; const char *b = &foo[7]; assume that `foo' is described as DW_OP_implicit_value and `a' and `b' each as DW_OP_implicit_pointer into that value. Then with current GDB `*a' and `*b' yield the same result -- the string's zero terminator. This patch basically reverts the portion of the patch above that deals with DW_OP_implicit_value. This fixes the offset handling and also goes back to dropping the last instead of the first bytes on big-endian targets if the implicit value is longer than needed. The latter aspect of the change probably doesn't matter for actual programs, but simplifies the logic. The patch also cleans up the original code a bit and adds appropriate test cases. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of taking a 2-byte value out of a 4-byte DWARF implicit value on big-endian targets. * gdb.dwarf2/nonvar-access.exp: Add more comments to existing logic. Add test cases for DW_OP_implicit. gdb/ChangeLog: * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian targets. And if the implicit value is longer than needed, extract the first bytes instead of the "least significant" ones.
2017-02-01 23:59:00 +08:00
# Member of a structure without location.
gdb_test "print undef_s.a" " = <optimized out>"