aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dwarf2/dw2-bad-mips-linkage-name.c
AgeCommit message (Collapse)AuthorFilesLines
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-07-13[ppc64] Fix for function descriptorsJan Kratochvil1-2/+2
Marin Cermak has found various testcases (or one of them) of GDB FAIL on ppc64. https://sourceware.org/bugzilla/show_bug.cgi?id=20328 .o contained only the function descriptor address. The DWARF as produced by Tcl Dwarf::assemble: <1><27>: Abbrev Number: 4 (DW_TAG_subprogram) <28> DW_AT_name : main <2d> DW_AT_external : 1 <2e> DW_AT_low_pc : 0x1001ff98 <36> DW_AT_high_pc : 0x1002ff98 <2><3e>: Abbrev Number: 5 (DW_TAG_lexical_block) Runtime info: $2 = {<text variable, no debug info>} 0x10000674 <.main> $3 = {void ()} 0x1001ff98 <main> On Tue, 12 Jul 2016 15:22:49 +0200, Ulrich Weigand wrote: Well, most of the gdb.dwarf2 test cases simply use explicitly placed labels for the DW_AT_low_pc / DW_AT_high_pc attributes. See e.g. dw2-unresolved-main.c: asm (".globl cu_text_start"); asm ("cu_text_start:"); On Wed, 13 Jul 2016 10:54:00 +0200, Jan Kratochvil wrote: Now I see I should not do that because: lib/dwarf.exp: proc function_range { func src } { So I am providing this patch. gdb/testsuite/ChangeLog 2016-07-13 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.dwarf2/atomic-type.exp: Use function_range for low_pc and high_pc. * gdb.dwarf2/atomic.c (f): Rename f_end_lbl to f_label. * gdb.dwarf2/dw2-bad-mips-linkage-name.c (f): Rename f_end_lbl to f_label. (g): Rename g_end_lbl to g_label. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Use function_range for low_pc and high_pc. * gdb.dwarf2/dw2-lexical-block-bare.exp: Likewise.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-08-19dwarf2read.c: Check type of string valued attributes prior to decoding.Kevin Buettner1-0/+41
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.