binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-linkage-name.exp

73 lines
2.2 KiB
Plaintext
Raw Normal View History

# Copyright 2015-2016 Free Software Foundation, Inc.
dwarf2read.c: Check type of string valued attributes prior to decoding. This change introduces a new function, dwarf2_string_attr(), which is a wrapper for dwarf2_attr(). dwarf2read.c has been updated to call dwarf2_string_attr in most instances where a string-valued attribute is decoded to produce a string value. In most cases, it simplifies the code; in some instances, the complexity of the code remains unchanged. I performed this change by looking for instances where the result of DW_STRING was used in an assignment. Many of these had a pattern which (roughly) looks something like this: struct attribute *attr = NULL; attr = dwarf2_attr (die, name, cu); if (attr != NULL && DW_STRING (attr)) { const char *str; ... str = DW_STRING (attr); ... /* Use str in some fashion. */ } Code of this form is transformed to look like this instead: const char *str; str = dwarf2_string_attr (die, name, cu) if (str != NULL) { ... /* Use str in some fashion. */ ... } In addition to invoking dwarf2_attr() and DW_STRING(), dwarf2_string_attr() checks to make sure that the attribute's `form' field matches one of DW_FORM_strp, DW_FORM_string, or DW_FORM_GNU_strp_alt. If it does not match one of these forms, it will return a NULL value in addition to calling complaint(). An earlier version of this patch did this type checking for one particular instance where a string attribute was being decoded. The situation that I was attempting to handle in that earlier patch is this: The Texas Instruments compiler uses the encoding for DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding, 0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name, does not have a string-typed value. In this instance, GDB was attempting to use an integer value as a string pointer, with predictable results. (GDB would die with a segmentation fault.) I've added a test which reproduces the problem that I was orignally wanting to fix. It uses DW_AT_MIPS_linkage name with an associate value which is a string, and again, where the value is a small integer. My test case causes GDB to segfault in an unpatched GDB. There will be two PASSes in a patched GDB. Unpatched GDB: (gdb) ptype f ERROR: Process no longer exists UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ERROR: Couldn't send ptype g to GDB. UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g Patched GDB: (gdb) ptype f type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ptype g type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g I see no regressions on an x86_64 native target. gdb/ChangeLog: * dwarf2read.c (dwarf2_string_attr): New function. (lookup_dwo_unit, process_psymtab_comp_unit_reader) (dwarf2_compute_name, dwarf2_physname, find_file_and_directory) (read_call_site_scope, namespace_name, guess_full_die_structure_name) (anonymous_struct_prefix, prepare_one_comp_unit): Use dwarf2_string_attr in place of dwarf2_attr and DW_STRING. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
2015-08-03 23:17:17 +02: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 dw2-bad-mips-linkage-name.c dw2-bad-mips-linkage-name.S
# Set up the 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_C}
{DW_AT_name dw2-bad-mips-linkage-name.c}
{DW_AT_comp_dir /tmp}
} {
declare_labels b_l
b_l: DW_TAG_base_type {
{DW_AT_byte_size 1 DW_FORM_sdata}
{DW_AT_encoding @DW_ATE_signed}
{DW_AT_name bool}
}
DW_TAG_subprogram {
{name f}
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 19:36:06 +01:00
{low_pc [gdb_target_symbol f] addr}
dwarf2read.c: Check type of string valued attributes prior to decoding. This change introduces a new function, dwarf2_string_attr(), which is a wrapper for dwarf2_attr(). dwarf2read.c has been updated to call dwarf2_string_attr in most instances where a string-valued attribute is decoded to produce a string value. In most cases, it simplifies the code; in some instances, the complexity of the code remains unchanged. I performed this change by looking for instances where the result of DW_STRING was used in an assignment. Many of these had a pattern which (roughly) looks something like this: struct attribute *attr = NULL; attr = dwarf2_attr (die, name, cu); if (attr != NULL && DW_STRING (attr)) { const char *str; ... str = DW_STRING (attr); ... /* Use str in some fashion. */ } Code of this form is transformed to look like this instead: const char *str; str = dwarf2_string_attr (die, name, cu) if (str != NULL) { ... /* Use str in some fashion. */ ... } In addition to invoking dwarf2_attr() and DW_STRING(), dwarf2_string_attr() checks to make sure that the attribute's `form' field matches one of DW_FORM_strp, DW_FORM_string, or DW_FORM_GNU_strp_alt. If it does not match one of these forms, it will return a NULL value in addition to calling complaint(). An earlier version of this patch did this type checking for one particular instance where a string attribute was being decoded. The situation that I was attempting to handle in that earlier patch is this: The Texas Instruments compiler uses the encoding for DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding, 0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name, does not have a string-typed value. In this instance, GDB was attempting to use an integer value as a string pointer, with predictable results. (GDB would die with a segmentation fault.) I've added a test which reproduces the problem that I was orignally wanting to fix. It uses DW_AT_MIPS_linkage name with an associate value which is a string, and again, where the value is a small integer. My test case causes GDB to segfault in an unpatched GDB. There will be two PASSes in a patched GDB. Unpatched GDB: (gdb) ptype f ERROR: Process no longer exists UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ERROR: Couldn't send ptype g to GDB. UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g Patched GDB: (gdb) ptype f type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ptype g type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g I see no regressions on an x86_64 native target. gdb/ChangeLog: * dwarf2read.c (dwarf2_string_attr): New function. (lookup_dwo_unit, process_psymtab_comp_unit_reader) (dwarf2_compute_name, dwarf2_physname, find_file_and_directory) (read_call_site_scope, namespace_name, guess_full_die_structure_name) (anonymous_struct_prefix, prepare_one_comp_unit): Use dwarf2_string_attr in place of dwarf2_attr and DW_STRING. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
2015-08-03 23:17:17 +02:00
{high_pc f_end_lbl addr}
{type :$b_l}
{DW_AT_MIPS_linkage_name _Z1fv}
}
DW_TAG_subprogram {
{name g}
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 19:36:06 +01:00
{low_pc [gdb_target_symbol g] addr}
dwarf2read.c: Check type of string valued attributes prior to decoding. This change introduces a new function, dwarf2_string_attr(), which is a wrapper for dwarf2_attr(). dwarf2read.c has been updated to call dwarf2_string_attr in most instances where a string-valued attribute is decoded to produce a string value. In most cases, it simplifies the code; in some instances, the complexity of the code remains unchanged. I performed this change by looking for instances where the result of DW_STRING was used in an assignment. Many of these had a pattern which (roughly) looks something like this: struct attribute *attr = NULL; attr = dwarf2_attr (die, name, cu); if (attr != NULL && DW_STRING (attr)) { const char *str; ... str = DW_STRING (attr); ... /* Use str in some fashion. */ } Code of this form is transformed to look like this instead: const char *str; str = dwarf2_string_attr (die, name, cu) if (str != NULL) { ... /* Use str in some fashion. */ ... } In addition to invoking dwarf2_attr() and DW_STRING(), dwarf2_string_attr() checks to make sure that the attribute's `form' field matches one of DW_FORM_strp, DW_FORM_string, or DW_FORM_GNU_strp_alt. If it does not match one of these forms, it will return a NULL value in addition to calling complaint(). An earlier version of this patch did this type checking for one particular instance where a string attribute was being decoded. The situation that I was attempting to handle in that earlier patch is this: The Texas Instruments compiler uses the encoding for DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding, 0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name, does not have a string-typed value. In this instance, GDB was attempting to use an integer value as a string pointer, with predictable results. (GDB would die with a segmentation fault.) I've added a test which reproduces the problem that I was orignally wanting to fix. It uses DW_AT_MIPS_linkage name with an associate value which is a string, and again, where the value is a small integer. My test case causes GDB to segfault in an unpatched GDB. There will be two PASSes in a patched GDB. Unpatched GDB: (gdb) ptype f ERROR: Process no longer exists UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ERROR: Couldn't send ptype g to GDB. UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g Patched GDB: (gdb) ptype f type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f ptype g type = bool () (gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g I see no regressions on an x86_64 native target. gdb/ChangeLog: * dwarf2read.c (dwarf2_string_attr): New function. (lookup_dwo_unit, process_psymtab_comp_unit_reader) (dwarf2_compute_name, dwarf2_physname, find_file_and_directory) (read_call_site_scope, namespace_name, guess_full_die_structure_name) (anonymous_struct_prefix, prepare_one_comp_unit): Use dwarf2_string_attr in place of dwarf2_attr and DW_STRING. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
2015-08-03 23:17:17 +02:00
{high_pc g_end_lbl addr}
{type :$b_l}
{DW_AT_MIPS_linkage_name 42 DW_FORM_data1}
}
}
}
}
if { [prepare_for_testing ${testfile}.exp ${testfile} \
[list $srcfile $asm_file] {nodebug}] } {
return -1
}
# A successful run will have two PASSes. A GDB that's lacking
# attribute type checking will segfault at some point. It doesn't
# much matter what we test here, so long as we do something to make
# sure that the DWARF is read.
gdb_test "ptype f" " = bool \\(\\)"
gdb_test "ptype g" " = bool \\(\\)"