aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2
AgeCommit message (Collapse)AuthorFilesLines
2021-02-09[gdb/symtab] Fix element type modification in read_array_typeTom de Vries1-0/+10
When running test-case gdb.fortran/function-calls.exp with target board unix/gdb:debug_flags=-gdwarf-5, I run into: ... (gdb) PASS: gdb.fortran/function-calls.exp: \ p derived_types_and_module_calls::pass_cart(c) p derived_types_and_module_calls::pass_cart_nd(c_nd)^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \ (c=<error reading variable: Cannot access memory at address 0xc>) at \ function-calls.f90:130^M 130 pass_cart_nd = ubound(c%d,1,4)^M The program being debugged was signaled while in a function called from GDB.^M GDB has restored the context to what it was before the call.^M To change this behavior use "set unwindonsignal off".^M Evaluation of the expression containing the function^M (derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M (gdb) FAIL: gdb.fortran/function-calls.exp: p ... The problem originates in read_array_type, when reading a DW_TAG_array_type with a dwarf-5 DW_TAG_generic_subrange child. This is not supported, and the fallout of this is that rather than constructing a new array type, the code proceeds to modify the element type. Fix this conservatively by issuing a complaint and bailing out in read_array_type when not being able to construct an array type, such that we have: ... (gdb) maint expand-symtabs function-calls.f90^M During symbol reading: unable to find array range \ - DIE at 0xe1e [in module function-calls]^M During symbol reading: unable to find array range \ - DIE at 0xe1e [in module function-calls]^M (gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \ (PRMS: symtab/27388) ... Tested on x86_64-linux. gdb/ChangeLog: 2021-02-09 Tom de Vries <tdevries@suse.de> PR symtab/27341 * dwarf2/read.c (read_array_type): Return NULL when not being able to construct an array type. Add assert to ensure that element_type is not being modified. gdb/testsuite/ChangeLog: 2021-02-09 Tom de Vries <tdevries@suse.de> PR symtab/27341 * lib/gdb.exp (with_complaints): New proc, factored out of ... (gdb_load_no_complaints): ... here. * gdb.fortran/function-calls.exp: Add test-case.
2021-02-05[gdb/symtab] Handle DW_TAG_type_unit in process_psymtab_comp_unitTom de Vries1-0/+3
When running test-case gdb.cp/cpexprs-debug-types.exp with target board unix/gdb:debug_flags=-gdwarf-5, I run into: ... (gdb) file cpexprs-debug-types^M Reading symbols from cpexprs-debug-types...^M ERROR: Couldn't load cpexprs-debug-types into GDB (eof). ERROR: Couldn't send delete breakpoints to GDB. ERROR: GDB process no longer exists GDB process exited with wait status 23054 exp9 0 0 CHILDKILLED SIGABRT SIGABRT ... We're running into this abort in process_psymtab_comp_unit: ... switch (reader.comp_unit_die->tag) { case DW_TAG_compile_unit: this_cu->unit_type = DW_UT_compile; break; case DW_TAG_partial_unit: this_cu->unit_type = DW_UT_partial; break; default: abort (); } ... because reader.comp_unit_die->tag == DW_TAG_type_unit. Fix this by adding a DW_TAG_type_unit case. Tested on x86_64-linux. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR symtab/27333 * dwarf2/read.c (process_psymtab_comp_unit): Handle DW_TAG_type_unit.
2021-02-05[gdb/symtab] Fix duplicate CUs in create_cus_from_debug_names_listTom de Vries1-0/+1
When running test-case gdb.dwarf2/clang-debug-names.exp, I run into the following warning: ... (gdb) file clang-debug-names^M Reading symbols from clang-debug-names...^M warning: Section .debug_aranges in clang-debug-names has duplicate \ debug_info_offset 0xc7, ignoring .debug_aranges.^M ... This is caused by a missing return in commit 3ee6bb113af "[gdb/symtab] Fix incomplete CU list assert in .debug_names". Fix this by adding the missing return, such that we have instead this warning: ... (gdb) file clang-debug-names^M Reading symbols from clang-debug-names...^M warning: Section .debug_aranges in clang-debug-names \ entry at offset 0 debug_info_offset 0 does not exists, \ ignoring .debug_aranges.^M ... which is a known problem filed as PR25969 - "Ignoring .debug_aranges with clang .debug_names". Tested on x86_64-linux. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR symtab/27307 * dwarf2/read.c (create_cus_from_debug_names_list): Add missing return. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> PR symtab/27307 * gdb.dwarf2/clang-debug-names.exp: Check file command warnings.
2021-02-05[gdb/symtab] Fix indentation in create_cus_from_debug_names_listTom de Vries1-15/+17
Fix indentation in !map.augmentation_is_gdb part of create_cus_from_debug_names_list. gdb/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (create_cus_from_debug_names_list): Fix indentation.
2021-02-02gdb/dwarf: make read_{loc,rng}list_index return sect_offsetSimon Marchi1-10/+12
I think it's wrong that read_loclist_index and read_rnglist_index return a CORE_ADDR. A CORE_ADDR is an address in the program. These functions return offset in sections (.debug_loclists and .debug_rnglists). I think sect_offset is more appropriate. I'm wondering if struct attribute should have a "set_sect_offset" method, that takes a sect_offset parameter, or if it's better to be left as a simple "unsigned". gdb/ChangeLog: * dwarf2/read.c (read_loclist_index, read_rnglist_index): Return a sect_offset. (read_attribute_reprocess): Adjust. Change-Id: I0e22e0864130fb490072b41ae099762918b8ad4d
2021-02-02gdb/dwarf: split dwarf2_cu::ranges_base in twoSimon Marchi2-76/+102
Consider the test case added in this patch. It defines a compilation unit with a DW_AT_rnglists_base attribute (used for attributes of form DW_FORM_rnglistx), but also uses DW_AT_ranges of form DW_FORM_sec_offset: 0x00000027: DW_TAG_compile_unit DW_AT_ranges [DW_FORM_sec_offset] (0x0000004c [0x0000000000005000, 0x0000000000006000)) DW_AT_rnglists_base [DW_FORM_sec_offset] (0x00000044) The DW_AT_rnglists_base does not play a role in reading the DW_AT_ranges of form DW_FORM_sec_offset, but it should also not do any harm. This case is currently not handled correctly by GDB. This is not something that a compiler is likely to emit, but in my opinion there's no reason why GDB should fail reading it. The problem is that in partial_die_info::read and a few other places where the same logic is replicated, the cu->ranges_base value, containing the DW_AT_rnglists_base value, is wrongfully added to the DW_AT_ranges value. It is quite messy how to decide whether cu->ranges_base should be added to the attribute's value or not. But to summarize, the only time we want to add it is when the attribute comes from a pre-DWARF 5 split unit file (a .dwo) [1]. In this case, the DW_AT_ranges attribute from the split unit file will have form DW_FORM_sec_offset, pointing somewhere in the linked file's .debug_ranges section. *But* it's not a "true" DW_FORM_sec_offset, in that it's an offset relative to the beginning of that CU's contribution in the section, not relative to the beginning of the section. So in that case, and only that case, do we want to add the ranges base value, which we found from the DW_AT_GNU_ranges_base attribute on the skeleton unit. Almost all instances of the DW_AT_ranges attribute will be found in the split unit (on DW_TAG_subprogram, for example), and therefore need to have the ranges base added. However, the DW_TAG_compile_unit DIE in the skeleton may also have a DW_AT_ranges attribute. For that one, the ranges base must not be added. Once the DIEs have been loaded in GDB, however, the distinction between what's coming from the skeleton and what's coming from the split unit is not clear. It is all merged in one big happy tree. So how do we know if a given attribute comes from the split unit or not? We use the fact that in pre-DWARF 5 split DWARF, DW_AT_ranges is found on the skeleton's DW_TAG_compile_unit (in the linked file) and never in the split unit's DW_TAG_compile_unit. This is why you have this in partial_die_info::read: int need_ranges_base = (tag != DW_TAG_compile_unit && attr.form != DW_FORM_rnglistx); However, with the corner case described above (where we have a DW_AT_rnglists_base attribute and a DW_AT_ranges attribute of form DW_FORM_sec_offset) the condition gets it wrong when it encounters an attribute like DW_TAG_subprogram with a DW_AT_ranges attribute of DW_FORM_sec_offset form: it thinks that it is necessary to add the base, when it reality it is not. The problem boils down to failing to differentiate these cases: - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a pre-DWARF 5 split unit (in which case we need to add the base) - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a DWARF 5 non-split unit (in which case we must not add the base) What makes it unnecessarily complex is that the cu->ranges_base field is overloaded, used to hold the pre-DWARF 5, non-standard DW_AT_GNU_ranges_base and the DWARF 5 DW_AT_rnglists_base. In reality, these two are called "bases" but are not the same thing. The result is that we need twisted conditions to try to determine whether or not we should add the base to the attribute's value. To fix it, split the field in two distinct fields. I renamed everything related to the "old" ranges base to "gnu_ranges_base", to make it clear that it's about the non-standard, pre-DWARF 5 thing. And everything related to the DWARF 5 thing gets renamed "rnglists". I think it becomes much easier to reason this way. The issue described above gets fixed by the fact that the DW_AT_rnglists_base value does not end up in cu->gnu_ranges_base, so cu->gnu_ranges_base stays 0. The condition to determine whether gnu_ranges_base should be added can therefore be simplified back to: tag != DW_TAG_compile_unit ... as it was before rnglistx support was added. Extend the gdb.dwarf2/rnglists-sec-offset.exp to cover this case. I also extended the test case for loclists similarly, just to see if there would be some similar problem. There wasn't, but I think it's not a bad idea to test that case for loclists as well, so I left it in the patch. [1] https://gcc.gnu.org/wiki/DebugFission gdb/ChangeLog: * dwarf2/die.h (struct die_info) <ranges_base>: Split in... <gnu_ranges_base>: ... this... <rnglists_base>: ... and this. * dwarf2/read.c (struct dwarf2_cu) <ranges_base>: Split in... <gnu_ranges_base>: ... this... <rnglists_base>: ... and this. (read_cutu_die_from_dwo): Adjust (dwarf2_get_pc_bounds): Adjust (dwarf2_record_block_ranges): Adjust. (read_full_die_1): Adjust (partial_die_info::read): Adjust. (read_rnglist_index): Adjust. gdb/testsuite/ChangeLog: * gdb.dwarf2/rnglists-sec-offset.exp: Add test for DW_AT_ranges of DW_FORM_sec_offset form plus DW_AT_rnglists_base attribute. * gdb.dwarf2/loclists-sec-offset.exp: Add test for DW_AT_location of DW_FORM_sec_offset plus DW_AT_loclists_base attribute Change-Id: Icd109038634b75d0e6e9d7d1dcb62fb9eb951d83
2021-02-02gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_indexSimon Marchi1-6/+38
When loading the binary from PR 26813 in GDB, we get: DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse] ... and the symbols fail to load. In read_rnglist_index and read_loclist_index, we read the header (documented in sections 7.28 and 7.29 of DWARF 5) of the CU's contribution to the .debug_rnglists / .debug_loclists sections to validate that the index we want to read makes sense. However, we always read the header at the beginning of the section, rather than the header for the contribution from which we want to read the index. To illustrate, here's what the binary from PR 26813 contains. There are two compile units: 0x0000000c: DW_TAG_compile_unit 1 DW_AT_ranges [DW_FORM_rnglistx]: 0x0 DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC 0x00003ec9: DW_TAG_compile_unit 2 DW_AT_ranges [DW_FORM_rnglistx]: 0xB DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85 The layout of the .debug_rnglists is the following: [0x00, 0x0B]: header for CU 1's contribution [0x0C, 0x0F]: list of offsets for CU 1 (1 element) [0x10, 0x78]: range lists data for CU 1 [0x79, 0x84]: header for CU 2's contribution [0x85, 0xB4]: list of offsets for CU 2 (12 elements) [0xB5, 0xBD7]: range lists data for CU 2 The DW_AT_rnglists_base attrbute points to the beginning of the list of offsets for that CU, relative to the start of the .debug_rnglists section. That's right after the header for that contribution. When we try to read the DW_AT_ranges attribute for CU 2, read_rnglist_index reads the header for CU 1 instead of the one for CU 2. Since there's only one element in CU 1's offset list, it believes (wrongfully) that the index 0xB is out of range. Fix it by reading the header just before where DW_AT_rnglists_base points to. With this patch, I am able to load GDB built with clang-11 and -gdwarf-5 in itself, with and without -readnow. gdb/ChangeLog: PR gdb/26813 * dwarf2/read.c (read_loclists_rnglists_header): Add header_offset parameter and use it. (read_loclist_index): Read header of the current contribution, not the one at the beginning of the section. (read_rnglist_index): Likewise. Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d
2021-02-02gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listxSimon Marchi3-4/+18
We hit an assertion when loading the binary from PR 26813. When fixing it, execution goes a up bit further but then hits another assert, and another, and another. With these fours fixes, I am able to load the binary and get to the prompt. An error is shown (index pointing outside of the section), because the DW_FORM_rnglistx attribute is not read correctly, but that one is taken care of by the next patch. The four fixes are: - attribute::form_requires_reprocessing needs to handle forms DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess is called for them in read_attribute_value. - read_attribute_reprocess must call set_unsigned for them, not set_address. The parameter of set_address is a CORE_ADDR, meaning it's for program addresses. Post-reprocess, DW_FORM_rnglistx and DW_FORM_loclistx are offsets into their respective sections (.debug_rnglists and .debug_loclists). set_unsigned is the current attribute value setter that fits the best. But perhaps we should have a setter that takes a sect_offset? - read_attribute_process must call as_unsigned_reprocess instead of as_unsigned to get the pre-reprocess value, otherwise we hit the assert inside as_unsigned that makes sure the attribute doesn't need reprocessing. - attribute::set_unsigned needs to clear the requires_reprocessing flag, otherwise it stays set when reprocessing DW_FORM_rnglistx and DW_FORM_loclistx attributes. There's another assert that we hit once the next patch is applied, but since it's in the same vein as the changes in this patch, I included it in this patch: - attribute::form_is_unsigned must handle form DW_FORM_loclistx, otherwise we hit the assert when trying to call set_unsigned for an attribute of this form. DW_FORM_rnglistx is already handled. gdb/ChangeLog: PR gdb/26813 * dwarf2/attribute.h (struct attribute) <set_unsigned>: Clear requires_reprocessing flag. * dwarf2/attribute.c (attribute::form_is_unsigned): Handle DW_FORM_loclistx. (attribute::form_requires_reprocessing): Handle DW_FORM_rnglistx and DW_FORM_loclistx. * dwarf2/read.c (read_attribute_reprocess): Use set_unsigned instead of set_address for DW_FORM_loclistx and DW_FORM_rnglistx. Change-Id: I06c156fa3913ca98e4e39085f4ef171645b4bc1e
2021-02-02gdb/dwarf: remove unnecessary check in read_{rng,loc}list_indexSimon Marchi1-11/+0
In read_rnglist_index and read_loclist_index, we check that both the start and end of the offset that we read from the offset table are within the section. I think it's unecessary to do both: if the end of the offset is within the section, then surely the start of the offset is within it. Remove the check for the start of the offset in both functions. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Remove bound check for start of offset. (read_rnglist_index): Likewise. Change-Id: I7b57ddf4f8a8a28971738f0e3f3af62108f9e19a
2021-02-02gdb/dwarf: add missing bound check to read_loclist_indexSimon Marchi1-4/+13
read_rnglist_index has a bound check to make sure that we don't go past the end of the section while reading the offset, but read_loclist_index doesn't. Add it to read_loclist_index. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Add bound check for the end of the offset. Change-Id: Ic4b55c88860fdc3e007740949c78ec84cdb4da60
2021-02-02gdb/dwarf: fix bound check in read_rnglist_indexSimon Marchi1-1/+3
I think this check in read_rnglist_index is wrong: /* Validate that reading won't go beyond the end of the section. */ if (start_offset + cu->header.offset_size > rnglist_base + section->size) error (_("Reading DW_FORM_rnglistx index beyond end of" ".debug_rnglists section [in module %s]"), objfile_name (objfile)); The addition `rnglist_base + section->size` doesn't make sense. rnglist_base is an offset into `section`, so it doesn't make sense to add it to `section`'s size. `start_offset` also is an offset into `section`, so we should just compare it to just `section->size`. gdb/ChangeLog: * dwarf2/read.c (read_rnglist_index): Fix bound check. Change-Id: If0ff7c73f4f80f79aac447518f4e8f131f2db8f2
2021-02-02gdb/dwarf: change read_loclist_index complaints into errorsSimon Marchi1-8/+11
Unlike read_rnglists_index, read_loclist_index uses complaints when it detects an inconsistency (a DW_FORM_loclistx value without a .debug_loclists section or an offset outside of the section). I really think they should be errors, since there's no point in continuing if this situation happens, we will likely segfault or read garbage. gdb/ChangeLog: * dwarf2/read.c (read_loclist_index): Change complaints into errors. Change-Id: Ic3a1cf6e682d47cb6e739dd76fd7ca5be2637e10
2021-02-02[gdb/symtab] Fix assert in write_one_signatured_typeTom de Vries1-0/+8
When running test-case gdb.dwarf2/fission-reread.exp with target board cc-with-gdb-index, we run into an abort during the generation of the gdb-index by cc-with-tweaks.sh: ... build/gdb/testsuite/cache/gdb.sh: line 1: 27275 Aborted (core dumped) ... This can be reproduced on the command line like this: ... $ gdb -batch ./outputs/gdb.dwarf2/fission-reread/fission-reread \ -ex 'save gdb-index ./outputs/gdb.dwarf2/fission-reread' warning: Could not find DWO TU fission-reread.dwo(0x9022f1ceac7e8b19) \ referenced by TU at offset 0x0 [in module fission-reread] warning: Could not find DWO CU fission-reread.dwo(0x807060504030201) \ referenced by CU at offset 0x561 [in module fission-reread] Aborted (core dumped) ... The abort is a segfault due to a using a nullptr psymtab in write_one_signatured_type. The problem is that we're trying to write index entries for the type unit with signature: ... (gdb) p /x entry->signature $2 = 0x9022f1ceac7e8b19 ... which is a skeleton type unit: ... Contents of the .debug_types section: Compilation Unit @ offset 0x0: Length: 0x4a (32-bit) Version: 4 Abbrev Offset: 0x165 Pointer Size: 4 Signature: 0x9022f1ceac7e8b19 Type Offset: 0x0 <0><17>: Abbrev Number: 2 (DW_TAG_type_unit) <18> DW_AT_comp_dir : /tmp/src/gdb/testsuite <2f> DW_AT_GNU_dwo_name: fission-reread.dwo <42> DW_AT_GNU_pubnames: 0x0 <46> DW_AT_GNU_pubtypes: 0x0 <4a> DW_AT_GNU_addr_base: 0x0 ... referring to a .dwo file, but as the warnings show, the .dwo file is not found. Fix this by skipping the type unit in write_one_signatured_type if psymtab == nullptr. Tested on x86_64-linux. gdb/ChangeLog: 2021-02-02 Tom de Vries <tdevries@suse.de> PR symtab/24620 * dwarf2/index-write.c (write_one_signatured_type): Skip if psymtab == nullptr. gdb/testsuite/ChangeLog: 2021-02-02 Tom de Vries <tdevries@suse.de> PR symtab/24620 * gdb.dwarf2/fission-reread.exp: Add test-case.
2021-01-25[gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIETom de Vries1-1/+1
While looking into a failure in gdb.go/package.exp with gcc-11, I noticed that gdb shows some complaints when loading the executable (also with gcc-10, where the test-case passes): ... $ gdb -batch -iex "set complaints 100" package.10 -ex start During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) Temporary breakpoint 1 at 0x402ae6: file gdb.go/package1.go, line 8. During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) During symbol reading: Invalid .debug_rnglists data (no base address) ... Fix this by using as_unsigned () to read DW_AT_ranges in the partial DIE reader, similar to how that is done in dwarf2_get_pc_bounds. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-25 Bernd Edlinger <bernd.edlinger@hotmail.de> Simon Marchi <simon.marchi@polymtl.ca> Tom de Vries <tdevries@suse.de> * dwarf2/read.c (partial_die_info::read): Use as_unsigned () for DW_AT_ranges. gdb/testsuite/ChangeLog: 2021-01-25 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-psym.exp (gdb_load_no_complaints): New proc. * lib/gdb.exp: Use gdb_load_no_complaints.
2021-01-25Fix fixed-point regression with recent GCCTom Tromey1-19/+42
A recent version of GCC changed how fixed-point types are described. For example, a denominator in one test case now looks like: GNU_denominator (exprloc) [ 0] implicit_value: 16 byte block: 00 00 b8 9d 0d 69 55 a0 01 00 00 00 00 00 00 00 ... the difference being that this now uses exprloc and emits a DW_OP_implicit_value for the 16-byte block. (DWARF 5 still uses DW_FORM_data16.) This change was made here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560897.html This patch updates gdb to handle this situation. Note that, before GCC 11, this test would not give the same answer. Earlier versions of GCC fell back to GNAT encodings for this case. gdb/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (get_mpz): New function. (get_dwarf2_rational_constant): Use it. gdb/testsuite/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points.exp: Add regression test. * gdb.ada/fixed_points/fixed_points.adb (FP5_Var): New variable. * gdb.ada/fixed_points/pck.adb (Delta5, FP5_Type): New.
2021-01-23Use std::vector for "registers_used" in compile featureTom Tromey2-4/+4
This changes the GDB compile code to use std::vector<bool> when computing which registers are used. This is a bit more idiomatic, but the main benefit is that it also adds some checking when the libstd++ debug mode is enabled. 2021-01-23 Tom Tromey <tom@tromey.com> * symtab.h (struct symbol_computed_ops) <generate_c_location>: Change type of "registers_used". * dwarf2/loc.h (dwarf2_compile_property_to_c): Update. * dwarf2/loc.c (dwarf2_compile_property_to_c) (locexpr_generate_c_location, loclist_generate_c_location): Change type of "registers_used". * compile/compile.h (compile_dwarf_expr_to_c) (compile_dwarf_bounds_to_c): Update. * compile/compile-loc2c.c (pushf_register_address) (pushf_register, do_compile_dwarf_expr_to_c) (compile_dwarf_expr_to_c, compile_dwarf_bounds_to_c): Change type of "registers_used". * compile/compile-c.h (generate_c_for_variable_locations): Update. * compile/compile-c-symbols.c (generate_vla_size) (generate_c_for_for_one_variable): Change type of "registers_used". (generate_c_for_variable_locations): Return std::vector. * compile/compile-c-support.c (generate_register_struct): Change type of "registers_used". (compute): Update.
2021-01-20gdb/dwarf: add assertion in maybe_queue_comp_unitSimon Marchi1-1/+6
The symptom that leads to this is the crash described in PR 26828: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error: member access within null pointer of type 'struct dwarf2_cu' The line of the crash is the following, in follow_die_offset: if (target_cu != cu) target_cu->ancestor = cu; <--- HERE The line that assign nullptr to `target_cu` is the `per_objfile->get_cu` call after having called maybe_queue_comp_unit: /* If necessary, add it to the queue and load its DIEs. */ if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language)) load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu), false, cu->language); target_cu = per_objfile->get_cu (per_cu); <--- HERE Some background: there is an invariant, documented in maybe_queue_comp_unit's doc, that if a CU is queued for expansion (present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory. "its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu object exists for this CU. Yet another way to say it is that `per_objfile->get_cu (per_cu)` returns something not nullptr for that CU. The crash documented in PR 26828 triggers some hard-to-reproduce sequence that ends up violating the invariant: - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A - The DIE in CU A requires some DIE in CU B - follow_die_offset calls maybe_queue_comp_unit. maybe_queue_comp_unit sees CU B is not queued and its DIEs are not loaded, so it enqueues it and returns 1 to its caller - meaning "the DIEs are not loaded, you should load them" - prompting follow_die_offset to load the DIEs by calling load_full_comp_unit - Note that CU B is enqueued by maybe_queue_comp_unit even if it has already been expanded. It's a bit useless (and causes trouble, see next patch), but that's how it works right now. - Since we entered the dwarf2/read code through dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we exit the dwarf2/read code with CU B still lingering in the queue. - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - This time, maybe_queue_comp_unit sees that CU B is in the queue. Because of the invariant that if a CU is in the queue, its DIEs are loaded in the memory, it returns 0 to its caller, meaning "you don't need to load the DIEs!". - That happens to be true, so everything is fine for now. - Time passes, some things call dwarf2_per_objfile::age_comp_units enough so that CU B's age becomes past the dwarf_max_cache_age threshold. age_comp_units proceeds to free CU B's DIEs. Remember that CU B is still lingering in the queue (oops, the invariant just got violated). - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - maybe_queue_comp_unit sees that CU B is in the queue, so returns to its caller "you don't need to load the DIEs!". However, we know at this point this is false. - follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for CU B: target_cu = per_objfile->get_cu (per_cu); But since they are not loaded, target_cu is nullptr, and we get the crash mentioned above a few lines after that. This patch adds an assertions in maybe_queue_comp_unit to verify the invariant, to make sure it doesn't return a falsehood to its caller. The current patch doesn't fix the issue (the next patch does), but it makes it so we catch the problem earlier and get this assertion failure instead of a segmentation fault: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error: int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*, dwarf2_per_objfile*, language): Assertion `per_objfile->get_cu (per_cu) != nullptr' failed. gdb/ChangeLog: PR gdb/26828 * dwarf2/read.c (maybe_queue_comp_unit): Add assertion. Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe
2021-01-20gdb/dwarf: add some logging in dwarf2/read.cSimon Marchi1-0/+15
This patch adds some logging that helped me diagnose the problems fixed later in this series. I'm thinking that if it helped me now, it could help somebody else (or myself) in the future, so I might as well add them for real. They can happen quite frequently and be noisy, so I used dwarf_read_debug_printf_v for them, which means they'll only print if `set debug dwarf-read` is >= 2. gdb/ChangeLog: * dwarf2/read.c (follow_die_offset): Add logging. (dwarf2_per_objfile::age_comp_units): Add logging. Change-Id: I7483c0b05c37bc9710b9b5d40e272935bc010863
2021-01-19Convert some frame functions to use gdb::array_view.Luis Machado1-3/+3
This patch converts the most obvious functions from gdb/frame.h to use the gdb::array_view abstraction. I've converted the ones that used buffer + length. There are others using only the buffer, with an implicit size. I did not touch those for now. But it would be nice to pass the size for safety. Tested with --enable-targets=all on Ubuntu 18.04/20.04 aarch64-linux. gdb/ChangeLog 2021-01-19 Luis Machado <luis.machado@linaro.org> * frame.h (get_frame_register_bytes): Pass a gdb::array_view instead of buffer + length. (put_frame_register_bytes): Likewise. Adjust documentation. (get_frame_memory): Pass a gdb::array_view instead of buffer + length. (safe_frame_unwind_memory): Likewise. * frame.c (get_frame_register_bytes, put_frame_register_bytes) (get_frame_memory, safe_frame_unwind_memory): Adjust to use gdb::array_view. * amd64-fbsd-tdep.c (amd64fbsd_sigtramp_p): Likewise. * amd64-linux-tdep.c (amd64_linux_sigtramp_start): Likewise. * amd64-obsd-tdep.c (amd64obsd_sigtramp_p): Likewise. * arc-linux-tdep.c (arc_linux_is_sigtramp): Likewise. * cris-tdep.c (cris_sigtramp_start, cris_rt_sigtramp_start): Likewise. * dwarf2/loc.c (rw_pieced_value): Likewise. * hppa-tdep.c (hppa_frame_cache): Likewise. * i386-fbsd-tdep.c (i386fbsd_sigtramp_p): Likewise. * i386-gnu-tdep.c (i386_gnu_sigtramp_start): Likewise. * i386-linux-tdep.c (i386_linux_sigtramp_start) (i386_linux_rt_sigtramp_start): Likewise. * i386-obsd-tdep.c (i386obsd_sigtramp_p): Likewise. * i386-tdep.c (i386_register_to_value): Likewise. * i387-tdep.c (i387_register_to_value): Likewise. * ia64-tdep.c (ia64_register_to_value): Likewise. * m32r-linux-tdep.c (m32r_linux_sigtramp_start) (m32r_linux_rt_sigtramp_start): Likewise. * m68k-linux-tdep.c (m68k_linux_pc_in_sigtramp): Likewise. * m68k-tdep.c (m68k_register_to_value): Likewise. * mips-tdep.c (mips_register_to_value) (mips_value_to_register): Likewise. * ppc-fbsd-tdep.c (ppcfbsd_sigtramp_frame_sniffer) (ppcfbsd_sigtramp_frame_cache): Likewise. * ppc-obsd-tdep.c (ppcobsd_sigtramp_frame_sniffer) (ppcobsd_sigtramp_frame_cache): Likewise. * rs6000-tdep.c (rs6000_in_function_epilogue_frame_p) (rs6000_register_to_value): Likewise. * tilegx-tdep.c (tilegx_analyze_prologue): Likewise. * tramp-frame.c (tramp_frame_start): Likewise. * valops.c (value_assign): Likewise.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker35-35/+35
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-12-23gdb: avoid accessing global C++ language implementation functionsAndrew Burgess1-3/+4
The function c_printchar is called from two places; it provides the implementation of language_defn::printchar and it is called from dwarf2_compute_name. It would be nice to rename c_printchar as language_defn::printchar and so avoid the trampoline. To achieve this, instead of calling c_printchar directly from the DWARF code, I lookup the C++ language object and call the printchar member function. In a later commit I can then rename c_printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (dwarf2_compute_name): Call methods on C++ language object instead of calling global functions directly.
2020-12-14Be more careful when rewriting thick pointer array typeTom Tromey1-13/+58
To handle thick pointers with -fgnat-encodings=minimal, gdb will rewrite the underlying array type to remove the bounds. However, if the same DWARF type is used both for a thick pointer and for an ordinary array, this will have the side effect of removing the bounds from the array. This breaks the printing of objects of this type. This patch fixes the problem by copying the array type, its range, and its bounds. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (rewrite_array_type): New function. (quirk_ada_thick_pointer_struct): Use rewrite_array_type. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/ada-thick-pointer.exp: New file.
2020-12-11gdb: factor out debug_prefixed_printf_condSimon Marchi1-12/+4
The same pattern happens often to define a "debug_printf" macro: #define displaced_debug_printf(fmt, ...) \ do \ { \ if (debug_displaced) \ debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \ } \ while (0) Move this pattern behind a helper macro, debug_prefixed_printf_cond and update the existing macros to use it. gdb/ChangeLog: * displaced-stepping.h (displaced_debug_printf): Use debug_prefixed_printf_cond. * dwarf2/read.c (dwarf_read_debug_printf): Likewise. (dwarf_read_debug_printf_v): Likewise. * infrun.h (infrun_debug_printf): Likewise. * linux-nat.c (linux_nat_debug_printf): Likewise. gdbsupport/ChangeLog: * common-debug.h (debug_prefixed_printf_cond): New. * event-loop.h (event_loop_debug_printf): Use debug_prefixed_printf_cond. Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99
2020-12-09Handle 128-bit constants for fixed pointTom Tromey1-34/+48
In some cases, GNAT can emit 128-bit constants for fixed-point types. This patch changes gdb to handle this scenario, by changing the low-level rational-reading functions in dwarf2/read.c to work directly with gdb_mpz values. (I'm not sure offhand if these 128-bit patches have gone into upstream GCC yet -- but they will eventually, and meanwhile I think it should be clear that this patch is otherwise harmless.) gdb/ChangeLog 2020-12-09 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (get_dwarf2_rational_constant): Change "numerator" and "denominator" to gdb_mpz. Handle block forms. (get_dwarf2_unsigned_rational_constant): Change "numerator" and "denominator" to gdb_mpz. (finish_fixed_point_type): Update. (has_zero_over_zero_small_attribute): Update.
2020-12-03gdb: fix logic of find_comp_unit and set_comp_unitSimon Marchi1-4/+6
The logic in find_comp_unit and set_comp_unit is reversed. When the BFD requires relocation, we want to put the comp_unit structure in the map where the comp_unit objects are not shared, that is the one indexed by objfile. If the BFD does not require relocation, then, we can share a single comp_unit structure for all users of that BFD, so we want to put it in the BFD-indexed map. The comments on top of dwarf2_frame_bfd_data and dwarf2_frame_objfile_data make that clear. Fix it by swapping the two in find_comp_unit and set_comp_unit. I don't have a test for this, because I don't see how to write one in a reasonable amount of time. gdb/ChangeLog: PR gdb/26876 * dwarf2/frame.c (find_comp_unit, set_comp_unit): Reverse use of dwarf2_frame_bfd_data and dwarf2_frame_objfile_data. Change-Id: I80c1ee7ad8425fa4947de65b170973d05f5a52ec
2020-12-01Search for DWZ files in debug-file-directories as wellSergio Durigan Junior1-7/+100
When Debian (and Ubuntu) builds its binaries, it (still) doesn't use dwz's "--relative" option. This causes their debuginfo files to carry a .gnu_debugaltlink section containing a full pathname to the DWZ alt debug file, like this: $ readelf -wk /usr/bin/cat Contents of the .gnu_debugaltlink section: Separate debug info file: /usr/lib/debug/.dwz/x86_64-linux-gnu/coreutils.debug Build-ID (0x14 bytes): ee 76 5d 71 97 37 ce 46 99 44 32 bb e8 a9 1a ef 99 96 88 db Contents of the .gnu_debuglink section: Separate debug info file: 06d3bee37b8c7e67b31cb2689cb351102ae73b.debug CRC value: 0x53267655 This usually works OK, because most of the debuginfo files installed via apt will be present in /usr/lib/debug anyway. However, imagine the following scenario: - You are using /usr/bin/cat, it crashes on you and generates a corefile. - You don't want/need to "apt install" the debuginfo file for coreutils from the repositories. Instead, you already have the debuginfo files in a separate directory (e.g., $HOME/dbgsym). - You start GDB and "set debug-file-directory $HOME/dbgsym/usr/lib/debug". You then get the following message: $ gdb -ex 'set debug-file-directory ./dbgsym/usr/lib/debug' -ex 'file /bin/cat' -ex 'core-file ./cat.core' GNU gdb (Ubuntu 10.1-0ubuntu1) 10.1 ... Reading symbols from /bin/cat... Reading symbols from /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug... could not find '.gnu_debugaltlink' file for /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug This error happens because GDB is trying to locate the build-id link (inside /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id) for the DWZ alt debug file, which doesn't exist. Arguably, this is a problem with how dh_dwz works in Debian, and it's something I'm also planning to tackle. But, back at the problem at hand. Besides not being able to find the build-id link in the directory mentioned above, GDB also tried to open the DWZ alt file using its filename. The problem here is that, since we don't have the distro's debuginfo installed, it can't find anything under /usr/lib/debug that satisfies it. It occurred to me that a good way to workaround this problem is to actually try to locate the DWZ alt debug file inside the debug-file-directories (that were likely provided by the user). So this is what the proposed patch does. The idea here is simple: get the filename extracted from the .gnu_debugaltlink section, and manipulate it in order to replace the initial part of the path (everything before "/.dwz/") by whatever debug-file-directories the user might have provided. I talked with Mark Wielaard and he agrees this is a sensible approach. In fact, apparently this is something that eu-readelf also does. I regtested this code, and no regressions were found. 2020-12-01 Sergio Durigan Junior <sergiodj@sergiodj.net> * dwarf2/read.c (dwz_search_other_debugdirs): New function. (dwarf2_get_dwz_file): Convert 'filename' to a std::string. Use dwz_search_other_debugdirs to search for DWZ files in the debug-file-directories provided by the user as well.
2020-11-30[gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clangTom de Vries1-4/+9
Consider test-case gdb.base/vla-optimized-out.exp, compiled using clang-10. GDB fails to get the size of the vla a: ... (gdb) p sizeof (a)^M Cannot access memory at address 0x6^M (gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of \ optimized out vla ... The relevant DWARF looks like this: the variable a: ... <2><12b>: Abbrev Number: 5 (DW_TAG_variable) <12c> DW_AT_name : a <132> DW_AT_type : <0x189> ... has type: ... <1><189>: Abbrev Number: 10 (DW_TAG_array_type) <18a> DW_AT_type : <0x198> <2><18e>: Abbrev Number: 11 (DW_TAG_subrange_type) <18f> DW_AT_type : <0x19f> <193> DW_AT_count : <0x117> ... with the count attribute equated to the value of this artificial variable: ... <2><117>: Abbrev Number: 4 (DW_TAG_variable) <118> DW_AT_location : 10 byte block: 75 1 10 ff ff ff ff f 1a 9f \ (DW_OP_breg5 (rdi): 1; DW_OP_constu: 4294967295; DW_OP_and; DW_OP_stack_value) <123> DW_AT_name : __vla_expr0 <127> DW_AT_type : <0x182> <12b> DW_AT_artificial : 1 ... The location description of the variable is terminated with DW_OP_stack_value, which according to the DWARF spec means that "the DWARF expression represents the actual value of the object, rather than its location". However, in attr_to_dynamic_prop, we set is_reference to true: ... baton->locexpr.is_reference = true; ... and use it in dwarf2_evaluate_property to dereference the value of the DWARF expression, which causes the access to memory at address 0x6. Fix this by ignoring the baton->locexpr.is_reference == true setting if the expression evaluation has ctx.location == DWARF_VALUE_STACK, such that we get: ... (gdb) p sizeof (a)^M $2 = 6^M (gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed size of \ optimized out vla ... Tested on x86_64-linux, with gcc. Tested the following test-cases (the ones mentioned in PR26905) on x86_64-linux with clang-10: - gdb.base/vla-optimized-out.exp - gdb.base/vla-ptr.exp - gdb.mi/mi-vla-c99 gdb/ChangeLog: 2020-11-30 Tom de Vries <tdevries@suse.de> PR symtab/26905 * dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add and handle is_reference parameter. (dwarf2_evaluate_property): Update dwarf2_locexpr_baton_eval call. gdb/testsuite/ChangeLog: 2020-11-30 Tom de Vries <tdevries@suse.de> PR symtab/26905 * gdb.dwarf2/count.exp: Remove kfails.
2020-11-23gdbtypes.h: Get rid of the TYPE_FIXED_POINT_INFO macroJoel Brobecker1-2/+2
This is one step further towards the removal of all these macros. gdb/ChangeLog: * gdbtypes.h (struct type) <fixed_point_info, set_fixed_point_info>: New methods. (INIT_FIXED_POINT_SPECIFIC): Adjust. (TYPE_FIXED_POINT_INFO): Delete macro. (allocate_fixed_point_type_info): Change return type to void. * gdbtypes.c (copy_type_recursive): Replace the use of TYPE_FIXED_POINT_INFO by a call to the fixed_point_info method. (fixed_point_scaling_factor): Likewise. (allocate_fixed_point_type_info): Change return type to void. Adjust implementation accordingly. * dwarf2/read.c (finish_fixed_point_type): Replace the use of TYPE_FIXED_POINT_INFO by a call to the fixed_point_info method.
2020-11-20gdb: fix dwarf2/read.c build on solarisSimon Marchi1-2/+2
When building on solaris (gcc farm machine gcc211), I get: CXX dwarf2/read.o /export/home/simark/src/binutils-gdb/gdb/dwarf2/read.c: In function 'void finish_fixed_point_type(type*, die_info*, dwarf2_cu*)': /export/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18204:42: error: call of overloaded 'abs(LONGEST&)' is ambiguous *num_or_denom = 1 << abs (scale_exp); ^ In file included from /usr/include/stdlib.h:11:0, from ../gnulib/import/stdlib.h:36, from /opt/csw/include/c++/5.5.0/cstdlib:72, from /export/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:90, from /export/home/simark/src/binutils-gdb/gdb/defs.h:28, from /export/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:31: /opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/iso/stdlib_iso.h:163:16: note: candidate: long int std::abs(long int) inline long abs(long _l) { return labs(_l); } ^ /opt/csw/lib/gcc/sparc-sun-solaris2.10/5.5.0/include-fixed/iso/stdlib_iso.h:117:12: note: candidate: int std::abs(int) extern int abs(int); ^ I don't know why, but using std::abs instead of just abs fixes it. gdb/ChangeLog: * dwarf2/read.c (finish_fixed_point_type): Use std::abs instead of abs. Change-Id: I57b9098351f2a8b2d2f61e848b97f7b2dfe55908
2020-11-15Add support for printing value of DWARF-based fixed-point type objectsJoel Brobecker1-0/+211
This commit introduces a new kind of type, meant to describe fixed-point types, using a new code added specifically for this purpose (TYPE_CODE_FIXED_POINT). It then adds handling of fixed-point base types in the DWARF reader. And finally, as a first step, this commit adds support for printing the value of fixed-point type objects. Note that this commit has a known issue: Trying to print the value of a fixed-point object with a format letter (e.g. "print /x NAME") causes the wrong value to be printed because the scaling factor is not applied. Since the fix for this issue is isolated, and this is not a regression, the fix will be made in a pach of its own. This is meant to simplify review and archeology. Also, other functionalities related to fixed-point type handling (ptype, arithmetics, etc), will be added piecemeal as well, for the same reasons (faciliate reviews and archeology). Related to this, the testcase gdb.ada/fixed_cmp.exp is adjusted to compile the test program with -fgnat-encodings=all, so as to force the use of GNAT encodings, rather than rely on the compiler's default to use them. The intent is to enhance this testcase to also test the pure DWARF approach using -fgnat-encodings=minimal as soon as the corresponding suport gets added in. Thus, the modification to the testcase is made in a way that it prepares this testcase to be tested in both modes. gdb/ChangeLog: * ada-valprint.c (ada_value_print_1): Add fixed-point type handling. * dwarf2/read.c (get_dwarf2_rational_constant) (get_dwarf2_unsigned_rational_constant, finish_fixed_point_type) (has_zero_over_zero_small_attribute): New functions. read_base_type, set_die_type): Add fixed-point type handling. * gdb-gdb.py.in: Add fixed-point type handling. * gdbtypes.c: #include "gmp-utils.h". (create_range_type, set_type_code): Add fixed-point type handling. (init_fixed_point_type): New function. (is_integral_type, is_scalar_type): Add fixed-point type handling. (print_fixed_point_type_info): New function. (recursive_dump_type, copy_type_recursive): Add fixed-point type handling. (fixed_point_type_storage): New typedef. (fixed_point_objfile_key): New static global. (allocate_fixed_point_type_info, is_fixed_point_type): New functions. (fixed_point_type_base_type, fixed_point_scaling_factor): New functions. * gdbtypes.h: #include "gmp-utils.h". (enum type_code) <TYPE_SPECIFIC_FIXED_POINT>: New enum. (union type_specific) <fixed_point_info>: New field. (struct fixed_point_type_info): New struct. (INIT_FIXED_POINT_SPECIFIC, TYPE_FIXED_POINT_INFO): New macros. (init_fixed_point_type, is_fixed_point_type) (fixed_point_type_base_type, fixed_point_scaling_factor) (allocate_fixed_point_type_info): Add declarations. * valprint.c (generic_val_print_fixed_point): New function. (generic_value_print): Add fixed-point type handling. * value.c (value_as_address, unpack_long): Add fixed-point type handling. gdb/testsuite/ChangeLog: * gdb.ada/fixed_cmp.exp: Force compilation to use -fgnat-encodings=all. * gdb.ada/fixed_points.exp: Add fixed-point variables printing tests. * gdb.ada/fixed_points/pck.ads, gdb.ada/fixed_points/pck.adb: New files. * gdb.ada/fixed_points/fixed_points.adb: Add use of package Pck. * gdb.dwarf2/dw2-fixed-point.c, gdb.dwarf2/dw2-fixed-point.exp: New files.
2020-11-12gdb/dwarf: fix call to dwarf2_queue_guard in dw2_do_instantiate_symtabSimon Marchi1-1/+1
It took me a while to understand why that would even compile: it looks like we pass a type name as a pointer, that makes no sense. By looking at the DWARF, I understood that the compiler actually interprets it as a function declaration. So the statement was doing nothing, no dwarf2_queue_guard was instantiated. Fix it by passing the right variable name. gdb/ChangeLog: * dwarf2/read.c (dw2_do_instantiate_symtab): Fix call to dwarf2_queue_guard. Change-Id: I3a7bdead9e8c39f8342a471f10181b85b8f0d801
2020-11-12gdb/dwarf: fix typo in dwarf2/read.cSimon Marchi1-1/+1
gdb/ChangeLog: * dwarf2/read.c (dw2_do_instantiate_symtab): Fix typo in comment. Change-Id: I6cb98768c04a537cf3d427648bddc57c631518e5
2020-11-12gdb: convert "set debug dwarf-read" to new styleSimon Marchi1-152/+114
Add dwarf_read_debug_printf and dwarf_read_debug_printf_v macros and use them throughout dwarf2/read.c. The second one is used for "verbose" prints, when the value of "set debug dwarf-read" is >= 2. gdb/ChangeLog: * dwarf2/read.c (dwarf_read_debug_printf, dwarf_read_debug_printf_v): New macros, use throughout the file. Change-Id: I694da69da2e1f2caa4c27a421a975790636411e2
2020-11-05Remove objfile parameter from abbrev_table::readTom Tromey3-13/+16
In a longer series that I am working on, I needed to remove the objfile parameter from abbrev_table::read. It seemed to me that this was a simple and relatively harmless patch, so I'm sending it now. gdb/ChangeLog 2020-11-05 Tom Tromey <tom@tromey.com> * dwarf2/read.c (read_cutu_die_from_dwo) (cutu_reader::cutu_reader, cutu_reader::cutu_reader) (build_type_psymtabs_1): Update. * dwarf2/abbrev.h (struct abbrev_table): Remove objfile parameter. * dwarf2/abbrev.c (abbrev_table::read): Remove objfile parameter. Don't read section. Add assert.
2020-11-04Recognize names of array typesTom Tromey1-5/+21
With -fgnat-encodings=minimal, Gnat will emit DW_TAG_array_type that has a name -- and this is the only time the name is emitted for the type. (For comparison, in C a typedef would be emitted in this situation.) This patch changes gdb to recognize the name of an array type. This is limited to Ada, to avoid any potential problems if some rogue DWARF happens to name an array type in some other language, and to avoid loading unnecessary partial DIEs. gdb/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (add_partial_symbol, process_die): Handle DW_TAG_array_type. (is_type_tag_for_partial): Add "lang" parameter. (load_partial_dies, new_symbol): Handle DW_TAG_array_type. gdb/testsuite/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * gdb.ada/tick_length_array_enum_idx.exp: Add ptype test. * gdb.ada/tick_length_array_enum_idx/foo_n207_004.adb (PT_Full): New variable. * gdb.ada/tick_length_array_enum_idx/pck.adb (Full_PT): New type.
2020-11-04Only use stride for final element typeTom Tromey1-4/+12
A DWARF array type may specify a stride. Currently, the DWARF reader applies this stride to every dimension of an array. However, this seems incorrect to me -- only the innermost array ought to use the stride, while outer arrays should compute a stride based on the size of the inner arrays. This patch arranges to apply the stride only to the innermost array type. This fixes a bug noticed when running some Ada tests with -fgnat-encodings=minimal. gdb/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (read_array_type): Only apply stride to innermost array. gdb/testsuite/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * gdb.ada/enum_idx_packed.exp: Add test. * gdb.ada/enum_idx_packed/foo.adb (Multi_Access): New variable. * gdb.ada/enum_idx_packed/pck.ads (Short) (Multi_Dimension, Multi_Dimension_Access): New types.
2020-11-04Synthesize array descriptors with -fgnat-encodings=minimalTom Tromey1-6/+322
When -fgnat-encodings=minimal, the compiler will avoid the special GNAT-specific "encodings" format, and instead emit ordinary DWARF as much as possible. When emitting DWARF for thick pointers to arrays, the compiler emits something like: <1><11db>: Abbrev Number: 7 (DW_TAG_array_type) <11dc> DW_AT_name : (indirect string, offset: 0x1bb8): string <11e0> DW_AT_data_location: 2 byte block: 97 6 (DW_OP_push_object_address; DW_OP_deref) <11e3> DW_AT_type : <0x1173> <11e7> DW_AT_sibling : <0x1201> <2><11eb>: Abbrev Number: 8 (DW_TAG_subrange_type) <11ec> DW_AT_type : <0x1206> <11f0> DW_AT_lower_bound : 6 byte block: 97 23 8 6 94 4 (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref; DW_OP_deref_size: 4) <11f7> DW_AT_upper_bound : 8 byte block: 97 23 8 6 23 4 94 4 (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref; DW_OP_plus_uconst: 4; DW_OP_deref_size: 4) If you read between the lines, the "array" is actually a structure with two elements. One element is a pointer to the array data, and the other structure describes the bounds of the array. However, the compiler doesn't emit this explicitly, but instead hides it behind these location expressions. gdb can print such objects, but currently there is no way to construct one. So, this patch adds some code to the DWARF reader to recognize this construct, and then synthesize an array descriptor. This descriptor is then handled by the existing Ada code. Internally, we've modified GCC to emit the structure type explicitly (we will of course be sending this upstream). In this case, the array still has the DW_AT_data_location, though. This patch also modifies gdb to ignore the data location in this case -- this is preferred because the location only serves to confuse the Ada code that already knows where to find the data. In the future I hope to move some of this handling to the gdb core, so that Ada-specific hacks are not needed; however I have not yet done this. Because parallel types are not emitted with -fgnat-encodings=minimal, some changes to the Ada code were also required. The change ina ada-valprint.c was needed to avoid infinite recursion when trying to print a constrained packed array. And, there didn't seem to be any need for a recursive call here -- the value could simply be returned instead. Finally, gdb.ada/frame_arg_lang.exp no longer works in C mode, because we drop back to the structure approach now. As mentioned earlier, future work should probably fix this again; meanwhile, this doesn't seem to be a big problem, because it is what is currently done (users as a rule don't use -fgnat-encodings=minimal -- which is what I am ultimately trying to fix). Note that a couple of tests have an added KFAIL. Some -fgnat-encodings=minimal changes have landed in GNAT, and you need something very recent to pass all the tests. I'm using git gcc to accomplish this. gdb/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (recognize_bound_expression) (quirk_ada_thick_pointer): New functions. (read_array_type): Call quirk_ada_thick_pointer. (set_die_type): Add "skip_data_location" parameter. (quirk_ada_thick_pointer): New function. (process_structure_scope): Call quirk_ada_thick_pointer. * ada-lang.c (ada_is_unconstrained_packed_array_type) (decode_packed_array_bitsize): Handle thick pointers without parallel types. (ada_is_gnat_encoded_packed_array_type): Rename from ada_is_packed_array_type. (ada_is_constrained_packed_array_type): Update. * ada-valprint.c (ada_val_print_gnat_array): Remove. (ada_value_print_1): Use ada_get_decoded_value. gdb/testsuite/ChangeLog 2020-11-04 Tom Tromey <tromey@adacore.com> * gdb.ada/O2_float_param.exp: Test different -fgnat-encodings values. * gdb.ada/access_to_unbounded_array.exp: Test different -fgnat-encodings values. * gdb.ada/big_packed_array.exp: Test different -fgnat-encodings values. * gdb.ada/arr_enum_idx_w_gap.exp: Test different -fgnat-encodings values. * gdb.ada/array_ptr_renaming.exp: Test different -fgnat-encodings values. * gdb.ada/array_of_variable_length.exp: Test different -fgnat-encodings values. * gdb.ada/arrayparam.exp: Test different -fgnat-encodings values. * gdb.ada/arrayptr.exp: Test different -fgnat-encodings values. * gdb.ada/frame_arg_lang.exp: Revert -fgnat-encodings=minimal change. * gdb.ada/mi_string_access.exp: Test different -fgnat-encodings values. * gdb.ada/mod_from_name.exp: Test different -fgnat-encodings values. * gdb.ada/out_of_line_in_inlined.exp: Test different -fgnat-encodings values. * gdb.ada/packed_array.exp: Test different -fgnat-encodings values. * gdb.ada/pckd_arr_ren.exp: Test different -fgnat-encodings values. * gdb.ada/unc_arr_ptr_in_var_rec.exp: Test different -fgnat-encodings values. * gdb.ada/variant_record_packed_array.exp: Test different -fgnat-encodings values.
2020-11-04Rewrite leb.h:read_3_bytesTom Tromey1-8/+1
read_3_bytes assumes little-endian data, but in fact it depends on the BFD. This patch rewrites this function to use bfd_get_24 instead. 2020-11-04 Tom Tromey <tromey@adacore.com> * dwarf2/leb.h (read_3_bytes): Use bfd_get_24.
2020-11-02gdb, gdbserver, gdbsupport: fix leading space vs tabs issuesSimon Marchi11-558/+558
Many spots incorrectly use only spaces for indentation (for example, there are a lot of spots in ada-lang.c). I've always found it awkward when I needed to edit one of these spots: do I keep the original wrong indentation, or do I fix it? What if the lines around it are also wrong, do I fix them too? I probably don't want to fix them in the same patch, to avoid adding noise to my patch. So I propose to fix as much as possible once and for all (hopefully). One typical counter argument for this is that it makes code archeology more difficult, because git-blame will show this commit as the last change for these lines. My counter counter argument is: when git-blaming, you often need to do "blame the file at the parent commit" anyway, to go past some other refactor that touched the line you are interested in, but is not the change you are looking for. So you already need a somewhat efficient way to do this. Using some interactive tool, rather than plain git-blame, makes this trivial. For example, I use "tig blame <file>", where going back past the commit that changed the currently selected line is one keystroke. It looks like Magit in Emacs does it too (though I've never used it). Web viewers of Github and Gitlab do it too. My point is that it won't really make archeology more difficult. The other typical counter argument is that it will cause conflicts with existing patches. That's true... but it's a one time cost, and those are not conflicts that are difficult to resolve. I have also tried "git rebase --ignore-whitespace", it seems to work well. Although that will re-introduce the faulty indentation, so one needs to take care of fixing the indentation in the patch after that (which is easy). gdb/ChangeLog: * aarch64-linux-tdep.c: Fix indentation. * aarch64-ravenscar-thread.c: Fix indentation. * aarch64-tdep.c: Fix indentation. * aarch64-tdep.h: Fix indentation. * ada-lang.c: Fix indentation. * ada-lang.h: Fix indentation. * ada-tasks.c: Fix indentation. * ada-typeprint.c: Fix indentation. * ada-valprint.c: Fix indentation. * ada-varobj.c: Fix indentation. * addrmap.c: Fix indentation. * addrmap.h: Fix indentation. * agent.c: Fix indentation. * aix-thread.c: Fix indentation. * alpha-bsd-nat.c: Fix indentation. * alpha-linux-tdep.c: Fix indentation. * alpha-mdebug-tdep.c: Fix indentation. * alpha-nbsd-tdep.c: Fix indentation. * alpha-obsd-tdep.c: Fix indentation. * alpha-tdep.c: Fix indentation. * amd64-bsd-nat.c: Fix indentation. * amd64-darwin-tdep.c: Fix indentation. * amd64-linux-nat.c: Fix indentation. * amd64-linux-tdep.c: Fix indentation. * amd64-nat.c: Fix indentation. * amd64-obsd-tdep.c: Fix indentation. * amd64-tdep.c: Fix indentation. * amd64-windows-tdep.c: Fix indentation. * annotate.c: Fix indentation. * arc-tdep.c: Fix indentation. * arch-utils.c: Fix indentation. * arch/arm-get-next-pcs.c: Fix indentation. * arch/arm.c: Fix indentation. * arm-linux-nat.c: Fix indentation. * arm-linux-tdep.c: Fix indentation. * arm-nbsd-tdep.c: Fix indentation. * arm-pikeos-tdep.c: Fix indentation. * arm-tdep.c: Fix indentation. * arm-tdep.h: Fix indentation. * arm-wince-tdep.c: Fix indentation. * auto-load.c: Fix indentation. * auxv.c: Fix indentation. * avr-tdep.c: Fix indentation. * ax-gdb.c: Fix indentation. * ax-general.c: Fix indentation. * bfin-linux-tdep.c: Fix indentation. * block.c: Fix indentation. * block.h: Fix indentation. * blockframe.c: Fix indentation. * bpf-tdep.c: Fix indentation. * break-catch-sig.c: Fix indentation. * break-catch-syscall.c: Fix indentation. * break-catch-throw.c: Fix indentation. * breakpoint.c: Fix indentation. * breakpoint.h: Fix indentation. * bsd-uthread.c: Fix indentation. * btrace.c: Fix indentation. * build-id.c: Fix indentation. * buildsym-legacy.h: Fix indentation. * buildsym.c: Fix indentation. * c-typeprint.c: Fix indentation. * c-valprint.c: Fix indentation. * c-varobj.c: Fix indentation. * charset.c: Fix indentation. * cli/cli-cmds.c: Fix indentation. * cli/cli-decode.c: Fix indentation. * cli/cli-decode.h: Fix indentation. * cli/cli-script.c: Fix indentation. * cli/cli-setshow.c: Fix indentation. * coff-pe-read.c: Fix indentation. * coffread.c: Fix indentation. * compile/compile-cplus-types.c: Fix indentation. * compile/compile-object-load.c: Fix indentation. * compile/compile-object-run.c: Fix indentation. * completer.c: Fix indentation. * corefile.c: Fix indentation. * corelow.c: Fix indentation. * cp-abi.h: Fix indentation. * cp-namespace.c: Fix indentation. * cp-support.c: Fix indentation. * cp-valprint.c: Fix indentation. * cris-linux-tdep.c: Fix indentation. * cris-tdep.c: Fix indentation. * darwin-nat-info.c: Fix indentation. * darwin-nat.c: Fix indentation. * darwin-nat.h: Fix indentation. * dbxread.c: Fix indentation. * dcache.c: Fix indentation. * disasm.c: Fix indentation. * dtrace-probe.c: Fix indentation. * dwarf2/abbrev.c: Fix indentation. * dwarf2/attribute.c: Fix indentation. * dwarf2/expr.c: Fix indentation. * dwarf2/frame.c: Fix indentation. * dwarf2/index-cache.c: Fix indentation. * dwarf2/index-write.c: Fix indentation. * dwarf2/line-header.c: Fix indentation. * dwarf2/loc.c: Fix indentation. * dwarf2/macro.c: Fix indentation. * dwarf2/read.c: Fix indentation. * dwarf2/read.h: Fix indentation. * elfread.c: Fix indentation. * eval.c: Fix indentation. * event-top.c: Fix indentation. * exec.c: Fix indentation. * exec.h: Fix indentation. * expprint.c: Fix indentation. * f-lang.c: Fix indentation. * f-typeprint.c: Fix indentation. * f-valprint.c: Fix indentation. * fbsd-nat.c: Fix indentation. * fbsd-tdep.c: Fix indentation. * findvar.c: Fix indentation. * fork-child.c: Fix indentation. * frame-unwind.c: Fix indentation. * frame-unwind.h: Fix indentation. * frame.c: Fix indentation. * frv-linux-tdep.c: Fix indentation. * frv-tdep.c: Fix indentation. * frv-tdep.h: Fix indentation. * ft32-tdep.c: Fix indentation. * gcore.c: Fix indentation. * gdb_bfd.c: Fix indentation. * gdbarch.sh: Fix indentation. * gdbarch.c: Re-generate * gdbarch.h: Re-generate. * gdbcore.h: Fix indentation. * gdbthread.h: Fix indentation. * gdbtypes.c: Fix indentation. * gdbtypes.h: Fix indentation. * glibc-tdep.c: Fix indentation. * gnu-nat.c: Fix indentation. * gnu-nat.h: Fix indentation. * gnu-v2-abi.c: Fix indentation. * gnu-v3-abi.c: Fix indentation. * go32-nat.c: Fix indentation. * guile/guile-internal.h: Fix indentation. * guile/scm-cmd.c: Fix indentation. * guile/scm-frame.c: Fix indentation. * guile/scm-iterator.c: Fix indentation. * guile/scm-math.c: Fix indentation. * guile/scm-ports.c: Fix indentation. * guile/scm-pretty-print.c: Fix indentation. * guile/scm-value.c: Fix indentation. * h8300-tdep.c: Fix indentation. * hppa-linux-nat.c: Fix indentation. * hppa-linux-tdep.c: Fix indentation. * hppa-nbsd-nat.c: Fix indentation. * hppa-nbsd-tdep.c: Fix indentation. * hppa-obsd-nat.c: Fix indentation. * hppa-tdep.c: Fix indentation. * hppa-tdep.h: Fix indentation. * i386-bsd-nat.c: Fix indentation. * i386-darwin-nat.c: Fix indentation. * i386-darwin-tdep.c: Fix indentation. * i386-dicos-tdep.c: Fix indentation. * i386-gnu-nat.c: Fix indentation. * i386-linux-nat.c: Fix indentation. * i386-linux-tdep.c: Fix indentation. * i386-nto-tdep.c: Fix indentation. * i386-obsd-tdep.c: Fix indentation. * i386-sol2-nat.c: Fix indentation. * i386-tdep.c: Fix indentation. * i386-tdep.h: Fix indentation. * i386-windows-tdep.c: Fix indentation. * i387-tdep.c: Fix indentation. * i387-tdep.h: Fix indentation. * ia64-libunwind-tdep.c: Fix indentation. * ia64-libunwind-tdep.h: Fix indentation. * ia64-linux-nat.c: Fix indentation. * ia64-linux-tdep.c: Fix indentation. * ia64-tdep.c: Fix indentation. * ia64-tdep.h: Fix indentation. * ia64-vms-tdep.c: Fix indentation. * infcall.c: Fix indentation. * infcmd.c: Fix indentation. * inferior.c: Fix indentation. * infrun.c: Fix indentation. * iq2000-tdep.c: Fix indentation. * language.c: Fix indentation. * linespec.c: Fix indentation. * linux-fork.c: Fix indentation. * linux-nat.c: Fix indentation. * linux-tdep.c: Fix indentation. * linux-thread-db.c: Fix indentation. * lm32-tdep.c: Fix indentation. * m2-lang.c: Fix indentation. * m2-typeprint.c: Fix indentation. * m2-valprint.c: Fix indentation. * m32c-tdep.c: Fix indentation. * m32r-linux-tdep.c: Fix indentation. * m32r-tdep.c: Fix indentation. * m68hc11-tdep.c: Fix indentation. * m68k-bsd-nat.c: Fix indentation. * m68k-linux-nat.c: Fix indentation. * m68k-linux-tdep.c: Fix indentation. * m68k-tdep.c: Fix indentation. * machoread.c: Fix indentation. * macrocmd.c: Fix indentation. * macroexp.c: Fix indentation. * macroscope.c: Fix indentation. * macrotab.c: Fix indentation. * macrotab.h: Fix indentation. * main.c: Fix indentation. * mdebugread.c: Fix indentation. * mep-tdep.c: Fix indentation. * mi/mi-cmd-catch.c: Fix indentation. * mi/mi-cmd-disas.c: Fix indentation. * mi/mi-cmd-env.c: Fix indentation. * mi/mi-cmd-stack.c: Fix indentation. * mi/mi-cmd-var.c: Fix indentation. * mi/mi-cmds.c: Fix indentation. * mi/mi-main.c: Fix indentation. * mi/mi-parse.c: Fix indentation. * microblaze-tdep.c: Fix indentation. * minidebug.c: Fix indentation. * minsyms.c: Fix indentation. * mips-linux-nat.c: Fix indentation. * mips-linux-tdep.c: Fix indentation. * mips-nbsd-tdep.c: Fix indentation. * mips-tdep.c: Fix indentation. * mn10300-linux-tdep.c: Fix indentation. * mn10300-tdep.c: Fix indentation. * moxie-tdep.c: Fix indentation. * msp430-tdep.c: Fix indentation. * namespace.h: Fix indentation. * nat/fork-inferior.c: Fix indentation. * nat/gdb_ptrace.h: Fix indentation. * nat/linux-namespaces.c: Fix indentation. * nat/linux-osdata.c: Fix indentation. * nat/netbsd-nat.c: Fix indentation. * nat/x86-dregs.c: Fix indentation. * nbsd-nat.c: Fix indentation. * nbsd-tdep.c: Fix indentation. * nios2-linux-tdep.c: Fix indentation. * nios2-tdep.c: Fix indentation. * nto-procfs.c: Fix indentation. * nto-tdep.c: Fix indentation. * objfiles.c: Fix indentation. * objfiles.h: Fix indentation. * opencl-lang.c: Fix indentation. * or1k-tdep.c: Fix indentation. * osabi.c: Fix indentation. * osabi.h: Fix indentation. * osdata.c: Fix indentation. * p-lang.c: Fix indentation. * p-typeprint.c: Fix indentation. * p-valprint.c: Fix indentation. * parse.c: Fix indentation. * ppc-linux-nat.c: Fix indentation. * ppc-linux-tdep.c: Fix indentation. * ppc-nbsd-nat.c: Fix indentation. * ppc-nbsd-tdep.c: Fix indentation. * ppc-obsd-nat.c: Fix indentation. * ppc-ravenscar-thread.c: Fix indentation. * ppc-sysv-tdep.c: Fix indentation. * ppc64-tdep.c: Fix indentation. * printcmd.c: Fix indentation. * proc-api.c: Fix indentation. * producer.c: Fix indentation. * producer.h: Fix indentation. * prologue-value.c: Fix indentation. * prologue-value.h: Fix indentation. * psymtab.c: Fix indentation. * python/py-arch.c: Fix indentation. * python/py-bpevent.c: Fix indentation. * python/py-event.c: Fix indentation. * python/py-event.h: Fix indentation. * python/py-finishbreakpoint.c: Fix indentation. * python/py-frame.c: Fix indentation. * python/py-framefilter.c: Fix indentation. * python/py-inferior.c: Fix indentation. * python/py-infthread.c: Fix indentation. * python/py-objfile.c: Fix indentation. * python/py-prettyprint.c: Fix indentation. * python/py-registers.c: Fix indentation. * python/py-signalevent.c: Fix indentation. * python/py-stopevent.c: Fix indentation. * python/py-stopevent.h: Fix indentation. * python/py-threadevent.c: Fix indentation. * python/py-tui.c: Fix indentation. * python/py-unwind.c: Fix indentation. * python/py-value.c: Fix indentation. * python/py-xmethods.c: Fix indentation. * python/python-internal.h: Fix indentation. * python/python.c: Fix indentation. * ravenscar-thread.c: Fix indentation. * record-btrace.c: Fix indentation. * record-full.c: Fix indentation. * record.c: Fix indentation. * reggroups.c: Fix indentation. * regset.h: Fix indentation. * remote-fileio.c: Fix indentation. * remote.c: Fix indentation. * reverse.c: Fix indentation. * riscv-linux-tdep.c: Fix indentation. * riscv-ravenscar-thread.c: Fix indentation. * riscv-tdep.c: Fix indentation. * rl78-tdep.c: Fix indentation. * rs6000-aix-tdep.c: Fix indentation. * rs6000-lynx178-tdep.c: Fix indentation. * rs6000-nat.c: Fix indentation. * rs6000-tdep.c: Fix indentation. * rust-lang.c: Fix indentation. * rx-tdep.c: Fix indentation. * s12z-tdep.c: Fix indentation. * s390-linux-tdep.c: Fix indentation. * score-tdep.c: Fix indentation. * ser-base.c: Fix indentation. * ser-mingw.c: Fix indentation. * ser-uds.c: Fix indentation. * ser-unix.c: Fix indentation. * serial.c: Fix indentation. * sh-linux-tdep.c: Fix indentation. * sh-nbsd-tdep.c: Fix indentation. * sh-tdep.c: Fix indentation. * skip.c: Fix indentation. * sol-thread.c: Fix indentation. * solib-aix.c: Fix indentation. * solib-darwin.c: Fix indentation. * solib-frv.c: Fix indentation. * solib-svr4.c: Fix indentation. * solib.c: Fix indentation. * source.c: Fix indentation. * sparc-linux-tdep.c: Fix indentation. * sparc-nbsd-tdep.c: Fix indentation. * sparc-obsd-tdep.c: Fix indentation. * sparc-ravenscar-thread.c: Fix indentation. * sparc-tdep.c: Fix indentation. * sparc64-linux-tdep.c: Fix indentation. * sparc64-nbsd-tdep.c: Fix indentation. * sparc64-obsd-tdep.c: Fix indentation. * sparc64-tdep.c: Fix indentation. * stabsread.c: Fix indentation. * stack.c: Fix indentation. * stap-probe.c: Fix indentation. * stubs/ia64vms-stub.c: Fix indentation. * stubs/m32r-stub.c: Fix indentation. * stubs/m68k-stub.c: Fix indentation. * stubs/sh-stub.c: Fix indentation. * stubs/sparc-stub.c: Fix indentation. * symfile-mem.c: Fix indentation. * symfile.c: Fix indentation. * symfile.h: Fix indentation. * symmisc.c: Fix indentation. * symtab.c: Fix indentation. * symtab.h: Fix indentation. * target-float.c: Fix indentation. * target.c: Fix indentation. * target.h: Fix indentation. * tic6x-tdep.c: Fix indentation. * tilegx-linux-tdep.c: Fix indentation. * tilegx-tdep.c: Fix indentation. * top.c: Fix indentation. * tracefile-tfile.c: Fix indentation. * tracepoint.c: Fix indentation. * tui/tui-disasm.c: Fix indentation. * tui/tui-io.c: Fix indentation. * tui/tui-regs.c: Fix indentation. * tui/tui-stack.c: Fix indentation. * tui/tui-win.c: Fix indentation. * tui/tui-winsource.c: Fix indentation. * tui/tui.c: Fix indentation. * typeprint.c: Fix indentation. * ui-out.h: Fix indentation. * unittests/copy_bitwise-selftests.c: Fix indentation. * unittests/memory-map-selftests.c: Fix indentation. * utils.c: Fix indentation. * v850-tdep.c: Fix indentation. * valarith.c: Fix indentation. * valops.c: Fix indentation. * valprint.c: Fix indentation. * valprint.h: Fix indentation. * value.c: Fix indentation. * value.h: Fix indentation. * varobj.c: Fix indentation. * vax-tdep.c: Fix indentation. * windows-nat.c: Fix indentation. * windows-tdep.c: Fix indentation. * xcoffread.c: Fix indentation. * xml-syscall.c: Fix indentation. * xml-tdesc.c: Fix indentation. * xstormy16-tdep.c: Fix indentation. * xtensa-config.c: Fix indentation. * xtensa-linux-nat.c: Fix indentation. * xtensa-linux-tdep.c: Fix indentation. * xtensa-tdep.c: Fix indentation. gdbserver/ChangeLog: * ax.cc: Fix indentation. * dll.cc: Fix indentation. * inferiors.h: Fix indentation. * linux-low.cc: Fix indentation. * linux-nios2-low.cc: Fix indentation. * linux-ppc-ipa.cc: Fix indentation. * linux-ppc-low.cc: Fix indentation. * linux-x86-low.cc: Fix indentation. * linux-xtensa-low.cc: Fix indentation. * regcache.cc: Fix indentation. * server.cc: Fix indentation. * tracepoint.cc: Fix indentation. gdbsupport/ChangeLog: * common-exceptions.h: Fix indentation. * event-loop.cc: Fix indentation. * fileio.cc: Fix indentation. * filestuff.cc: Fix indentation. * gdb-dlfcn.cc: Fix indentation. * gdb_string_view.h: Fix indentation. * job-control.cc: Fix indentation. * signals.cc: Fix indentation. Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-11-01Change end_psymtab_common to a methodTom Tromey1-2/+2
This changes end_psymtab_common to be a method on partial_symtab. This seems a little cleaner to me. gdb/ChangeLog 2020-11-01 Tom Tromey <tom@tromey.com> * dbxread.c (dbx_end_psymtab): Update. * dwarf2/read.c (process_psymtab_comp_unit_reader) (build_type_psymtabs_reader): Update. * xcoffread.c (xcoff_end_psymtab): Update. * ctfread.c (scan_partial_symbols): Update. * psymtab.c (sort_pst_symbols): Remove. (partial_symtab::end): Rename from end_psymtab_common. Inline sort_pst_symbols. * psympriv.h (struct partial_symtab) <end>: New method. (end_psymtab_common): Don't declare.
2020-11-01Remove parameter from end_psymtab_commonTom Tromey1-3/+2
The objfile parameter to end_psymtab_common is no longer needed, so this removes it. gdb/ChangeLog 2020-11-01 Tom Tromey <tom@tromey.com> * dbxread.c (dbx_end_psymtab): Update. * dwarf2/read.c (process_psymtab_comp_unit_reader): Update. (build_type_psymtabs_reader): Update. * xcoffread.c (xcoff_end_psymtab): Update. * ctfread.c (scan_partial_symbols): Update. * psympriv.h (end_psymtab_common): Update. * psymtab.c (end_psymtab_common): Remove objfile parameter. (sort_pst_symbols): Likewise.
2020-11-01Remove init_psymbol_listTom Tromey1-2/+0
init_psymbol_list is now empty, and so this removes it. gdb/ChangeLog 2020-11-01 Tom Tromey <tom@tromey.com> * dbxread.c (dbx_symfile_read): Update. * dwarf2/read.c (dwarf2_build_psymtabs): Update. * xcoffread.c (xcoff_initial_scan): Update. * psympriv.h (init_psymbol_list): Don't declare. * psymtab.c (init_psymbol_list): Remove.
2020-10-26[gdb/symtab] Read CU base address for enqueued CUTom de Vries1-0/+2
Consider the test-case contained in this patch. It consists of two CUs: - cu1, containing a DW_TAG_variable DIE foo - cu2, containing a DW_TAG_base_type DIE int where the variable foo has type int, in other words, there's an inter-CU reference. When expanding the symtab for cu1, expansion of the symtab for cu2 is enqueued, and later processed by process_full_comp_unit. However, processing of .debug_ranges fails because the range is specified relative to a base address which is considered not to be present because !cu->base_address.has_value (), and we run into this case in dwarf2_ranges_process: ... if (!base.has_value ()) { /* We have no valid base address for the ranges data. */ complaint (_("Invalid .debug_ranges data (no base address)")); return 0; } ... Fix this in process_full_comp_unit by setting cu->base_address. Tested on x86_64-linux. gdb/ChangeLog: 2020-10-26 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (process_full_comp_unit): Call dwarf2_find_base_address. gdb/testsuite/ChangeLog: 2020-10-26 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/enqueued-cu-base-addr.exp: New file.
2020-10-22gdb/dwarf: fix reading subprogram with DW_AT_specification (PR gdb/26693)Simon Marchi1-6/+16
Fix a regression introduced by commit 7188ed02d2a7 ("Replace dwarf2_per_cu_data::cu backlink with per-objfile map"). This patch targets both master and gdb-10-branch, since this is a regression from GDB 9. Analysis -------- The DWARF generated by the included test case looks like: 0x0000000b: DW_TAG_compile_unit DW_AT_language [DW_FORM_sdata] (4) 0x0000000d: DW_TAG_base_type DW_AT_name [DW_FORM_string] ("int") DW_AT_byte_size [DW_FORM_data1] (0x04) DW_AT_encoding [DW_FORM_sdata] (5) 0x00000014: DW_TAG_subprogram DW_AT_name [DW_FORM_string] ("apply") 0x0000001b: DW_TAG_subprogram DW_AT_specification [DW_FORM_ref4] (0x00000014 "apply") DW_AT_low_pc [DW_FORM_addr] (0x0000000000001234) DW_AT_high_pc [DW_FORM_data8] (0x0000000000000020) 0x00000030: DW_TAG_template_type_parameter DW_AT_name [DW_FORM_string] ("T") DW_AT_type [DW_FORM_ref4] (0x0000000d "int") 0x00000037: NULL 0x00000038: NULL Simply loading the file in GDB makes it crash: $ ./gdb -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/pr26693/pr26693 [1] 15188 abort (core dumped) ./gdb -nx --data-directory=data-directory The crash happens here, where htab (a dwarf2_cu::die_hash field) is unexpectedly NULL while generating partial symbols: #0 0x000055555fa28188 in htab_find_with_hash (htab=0x0, element=0x7fffffffbfa0, hash=27) at /home/simark/src/binutils-gdb/libiberty/hashtab.c:591 #1 0x000055555cb4eb2e in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22951 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 The special thing about this DWARF is that the subprogram at 0x1b is a template specialization described with DW_AT_specification, and has no DW_AT_name in itself. To compute the name of this subprogram, partial_die_full_name needs to load the full DIE for this partial DIE. The name is generated from the templated function name and the actual tempalate parameter values of the specialization. To load the full DIE, partial_die_full_name creates a dummy DWARF attribute of form DW_FORM_ref_addr that points to our subprogram's DIE, and calls follow_die_ref on it. This eventually causes load_full_comp_unit to be called for the exact same CU we are currently making partial symbols for: #0 load_full_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, skip_partial=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9238 #1 0x000055555cb4e943 in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22942 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 load_full_comp_unit creates a cutu_reader for the CU. Since a dwarf2_cu object already exists for the CU, load_full_comp_unit is expected to find it and pass it to cutu_reader, so that cutu_reader doesn't create a new dwarf2_cu for the CU. And this is the difference between before and after the regression. Before commit 7188ed02d2a7, the dwarf2_per_cu_data -> dwarf2_cu link was a simple pointer in dwarf2_per_cu_data. This pointer was set up when starting the read the partial symbols. So it was already available at that point where load_full_comp_unit gets called. Post-7188ed02d2a7, this link is per-objfile, kept in the dwarf2_per_objfile::m_dwarf2_cus hash map. The entry is only put in the hash map once the partial symbols have been successfully read, when cutu_reader::keep is called. Therefore, it is _not_ set at the point load_full_comp_unit is called. As a consequence, a new dwarf2_cu object gets created and initialized by load_full_comp_unit (including initializing that dwarf2_cu::die_hash field). Meanwhile, the dwarf2_cu object created and used by the callers up the stack does not get initialized for full symbol reading, and the dwarf2_cu::die_hash field stays unexpectedly NULL. Solution -------- Since the caller of load_full_comp_unit knows about the existing dwarf2_cu object for the CU we are reading (the one load_full_comp_unit is expected to find), we can simply make it pass it down, instead of having load_full_comp_unit look up the per-objfile map. load_full_comp_unit therefore gets a new `existing_cu` parameter. All other callers get updated to pass `per_objfile->get_cu (per_cu)`, so the behavior shouldn't change for them, compared to the current HEAD. A test is added, which is the bare minimum to reproduce the issue. Notes ----- The original problem was reproduced by downloading https://github.com/oneapi-src/oneTBB/releases/download/v2020.3/tbb-2020.3-lin.tgz and loading libtbb.so in GDB. This code was compiled with the Intel C/C++ compiler. I was not able to reproduce the issue using GCC, I think because GCC puts a DW_AT_name in the specialized subprogram, so there's no need for partial_die_full_name to load the full DIE of the subprogram, and the faulty code doesn't execute. gdb/ChangeLog: PR gdb/26693 * dwarf2/read.c (load_full_comp_unit): Add existing_cu parameter. (load_cu): Pass existing CU. (process_imported_unit_die): Likewise. (follow_die_offset): Likewise. gdb/testsuite/ChangeLog: PR gdb/26693 * gdb.dwarf2/template-specification-full-name.exp: New test. Change-Id: I57c8042f96c45f15797a3848e4d384181c56bb44
2020-10-17Have partial symbol tables own psymbol vectorsTom Tromey2-51/+26
Currently pointers to all partial symbols are stored in two vectors; and then indices into these vectors are stored in each partial_symtab. This patch changes this so that each partial symtab instead has vectors of symbols. add_psymbol_to_list can now be changed into a method on partial_symtab as well. My main motivation for doing this is that I am looking into calling sort_pst_symbols in the background. However, I haven't actually implemented this yet. (Also this may make it more feasible to also sort the static psymbols, though I haven't tried that either.) Also, though, this lets us remove the "current_global_psymbols" vector, because now the callers can simply refer directly to the psymtab that they are modifying (formerly this was implicit). The main drawback of this patch is that it increases the size of partial symtab. gdb/ChangeLog 2020-10-17 Tom Tromey <tom@tromey.com> * xcoffread.c (xcoff_end_psymtab): Use partial_symtab::empty. (scan_xcoff_symtab): Update. * psymtab.h (class psymtab_storage) <global_psymbols, static_psymbols, current_global_psymbols, current_static_psymbols>: Remove. * psymtab.c (require_partial_symbols, find_pc_sect_psymbol) (match_partial_symbol, lookup_partial_symbol): Update. (print_partial_symbols): Change parameters. (dump_psymtab, recursively_search_psymtabs) (psym_fill_psymbol_map, psym_find_compunit_symtab_by_address) (sort_pst_symbols, partial_symtab::partial_symtab): Update. (concat): Remove. (end_psymtab_common): Simplify. (append_psymbol_to_list): Change parameters. (partial_symtabs::add_psymbol): Rename from add_psymbol_to_list. (init_psymbol_list): Simplify. (maintenance_info_psymtabs, maintenance_check_psymtabs): Update. * psympriv.h (struct partial_symtab) <empty>: New method. <globals_offset, n_global_syms, statics_offset, n_static_syms>: Remove. <global_psymbols, static_psymbols>: New members. <add_psymbol>: New methods. (add_psymbol_to_list): Don't declare. (psymbol_placement): Move earlier. * mdebugread.c (parse_partial_symbols): Update. (handle_psymbol_enumerators): Change parameters. (mdebug_expand_psymtab): Update. * dwarf2/read.c (process_psymtab_comp_unit_reader) (add_partial_symbol): Update. * dwarf2/index-write.c (write_psymbols): Change parameters. (write_one_signatured_type): Update. (recursively_count_psymbols): Update. (recursively_write_psymbols): Update. (class debug_names) <recursively_write_psymbols>: Update. <write_psymbols>: Change parameters. <write_one_signatured_type>: Update. * dbxread.c (read_dbx_symtab): Update. (dbx_end_psymtab): Use partial_symtab::empty. * ctfread.c (struct ctf_context) <pst>: New member. (create_partial_symtab): Set it. (ctf_psymtab_type_cb, ctf_psymtab_var_cb): Update. (scan_partial_symbols): Use the psymtab's context. Update.
2020-10-09Fix bit offset regressionTom Tromey1-5/+5
The type-safe attribute patch introduced a regression that can occur when the DW_AT_bit_offset value is negative. This can happen with some Ada programs. This patch fixes the problem. It also fixes a minor oddity in the existing scalar storage test -- this test was intended to assign a smaller number of bits to the field. 2020-10-09 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (dwarf2_add_field): Handle signed offsets. gdb/testsuite/ChangeLog 2020-10-09 Tom Tromey <tromey@adacore.com> * gdb.ada/scalar_storage/storage.adb (Another_Range): New type. (Rec): Add field. Fix range. * gdb.ada/scalar_storage.exp: Update.
2020-10-02DWARFv5: Handle DW_MACRO_define_strx and DW_MACRO_undef_strx macro entries.nitachra3-4/+91
GDB complaints "During symbol reading: unrecognized DW_MACFINO opcode 0xb" with the testcase given below. Clang is emitting DW_MACRO_define_strx and DW_MACRO_undef_strx entries in .debug_macro section which are not supported in GDB. This patch handles them. DW_MACRO_define_strx and DW_MACRO_undef_strx are added in DWARFv5. They have two operands. The first operand encodes the line number of the #define or #undef macro directive. The second operand identifies a string; it is represented using an unsigned LEB128 encoded value, which is interpreted as a zero-based index into an array of offsets in the .debug_str_offsets section. This is as per the section 6.3.2.1 of Dwarf Debugging Information Format Version 5. Test case used: #define MAX_SIZE 10 int main(void) { int size = 0; size = size + MAX_SIZE; printf("\n The value of size is [%d]\n",size); return 0; } clang -gdwarf-5 -fdebug-macro macro.c -o macro.out Before the patch: gdb/new_gdb/binutils-gdb/build/bin/gdb -q macro.out -ex "set complaints 1" -ex "start" Reading symbols from macro.out... During symbol reading: unrecognized DW_MACFINO opcode 0xb Temporary breakpoint 1 at 0x4004df: file macro.c, line 7. Starting program: /home/nitika/workspace/macro.out Temporary breakpoint 1, main () at macro.c:7 7 int size = 0; (gdb) Tested by running the testsuite before and after the patch with -gdwarf-5 and there is no increase in the number of test cases that fails. Used clang 11.0.0. gdb/ChangeLog: * dwarf2/macro.c (dwarf_decode_macro_bytes): Handle DW_MACRO_define_strx and DW_MACRO_undef_strx. (dwarf_decode_macros): Likewise * dwarf2/read.c (dwarf_decode_macros): Pass str_offsets_base in the parameters which is the value of DW_AT_str_offsets_base. * dwarf2/macro.h (dwarf_decode_macros): Modify the definition to include str_offsets_base.
2020-09-30[gdb] Fix regression in dwarf2_nameTom de Vries1-0/+2
Since commit 2c830f5475 "Change some uses of DW_STRING to string method" we have these regressions: ... FAIL: gdb.base/info-types-c++.exp: info types FAIL: gdb.cp/anon-struct.exp: print type of t::t FAIL: gdb.cp/anon-struct.exp: print type of X::t2 FAIL: gdb.cp/anon-struct.exp: print type of X::t2::t2 FAIL: gdb.cp/anon-struct.exp: print type of t3::~t3 ... Fix these in dwarf2_name by updating attr_name each time attr is updated. Tested on x86_64-linux. gdb/ChangeLog: 2020-09-30 Tom de Vries <tdevries@suse.de> PR symtab/26683 * dwarf2/read.c (dwarf2_name): Update attr_name after attr is updated.
2020-09-30Fix regression in variant part handlingTom Tromey1-2/+2
My series to change DWARF attribute handling to be type-safe introduced a regression in gdb.ada/variant.exp. handle_variant was using as_unsigned on an attribute with DW_FORM_sdata. This patch changes it to use constant_value instead. 2020-09-30 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (handle_variant): Use constant_value.
2020-09-29Remove DW_UNSNDTom Tromey2-89/+86
This removes DW_UNSND, replacing uses with either as_unsigned or constant_value, depending primarily on whether or not the form is already known to be appropriate. gdb/ChangeLog 2020-09-29 Tom Tromey <tom@tromey.com> * dwarf2/read.c (lookup_dwo_id, get_type_unit_group) (read_file_scope, dwarf2_get_pc_bounds) (dwarf2_record_block_ranges, dwarf2_add_field, get_alignment) (read_structure_type, handle_struct_member_die) (read_enumeration_type, read_array_type, read_set_type) (read_tag_pointer_type, read_tag_reference_type) (read_subroutine_type, read_base_type, read_subrange_type) (read_full_die_1, partial_die_info::read) (partial_die_info::read, by, new_symbol) (dwarf2_const_value_data, dwarf2_const_value_attr) (dump_die_shallow, dwarf2_fetch_constant_bytes) (prepare_one_comp_unit): Update. * dwarf2/attribute.h (DW_UNSND): Remove.