aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2
AgeCommit message (Collapse)AuthorFilesLines
2020-09-17Use htab_up in dwarf2/read.cTom Tromey1-11/+9
This changes dwarf2/read.c to use htab_up rather than explicit calls to htab_delete. gdb/ChangeLog 2020-09-17 Tom Tromey <tom@tromey.com> * dwarf2/read.c (compute_compunit_symtab_includes): Use htab_up.
2020-09-16gdb: Convert language_data::la_array_ordering to a methodAndrew Burgess1-1/+1
Convert language_data::la_array_ordering member variable to a virtual method language_defn::array_ordering. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-lang.c (ada_language_data): Remove la_array_ordering initializer. * c-lang.c (c_language_data): Likewise. (cplus_language_data): Likewise. (asm_language_data): Likewise. (minimal_language_data): Likewise. * d-lang.c (d_language_data): Likewise. * dwarf2/read.c (read_array_order): Update for call to array_ordering. * f-lang.c (f_language_data): Remove la_array_ordering initializer. (f_language::array_ordering): New member function. * go-lang.c (go_language_data): Remove la_array_ordering initializer. * language.c (unknown_language_data): Likewise. (auto_language_data): Likewise. * language.h (language_data): Delete la_array_ordering field. (language_defn::array_ordering): New member function. * m2-lang.c (m2_language_data): Remove la_array_ordering initializer. * objc-lang.c (objc_language_data): Likewise. * opencl-lang.c (opencl_language_data): Likewise. * p-lang.c (pascal_language_data): Likewise. * rust-lang.c (rust_language_data): Likewise.
2020-09-16gdb: Override store_sym_names_in_linkage_form_p for Go languageAndrew Burgess1-6/+0
When store_sym_names_in_linkage_form_p was introduced in this commit: commit 59cc4834e53565da1de4a7b615ed8890ed55c7da Date: Tue Mar 27 08:57:16 2018 -0500 problem looking up some symbols when they have a linkage name A special case was left behind for Go, however, this special case was not really needed anymore, it could be handled by having store_sym_names_in_linkage_form_p return the true for go, instead of false. This commit overrides store_sym_names_in_linkage_form_p for Go, and then removes the special case. As store_sym_names_in_linkage_form_p is only called once throughout GDB this should be perfectly safe. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (dwarf2_physname): Remove special case for language_go. * go-lang.c (go_language::store_sym_names_in_linkage_form_p): New member function.
2020-09-16gdb: Convert la_store_sym_names_in_linkage_form_p to a methodAndrew Burgess1-1/+1
Convert language_data::la_store_sym_names_in_linkage_form_p member variable to language_defn::store_sym_names_in_linkage_form_p virtual function. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-lang.c (ada_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (ada_language::store_sym_names_in_linkage_form_p): New member function. * c-lang.c (c_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (c_language::store_sym_names_in_linkage_form_p): New member function. (cplus_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (asm_language_data): Likewise. (asm_language::store_sym_names_in_linkage_form_p): New member function. (minimal_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (minimal_language::store_sym_names_in_linkage_form_p): New member function. * d-lang.c (d_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. * dwarf2/read.c (dwarf2_physname): Update call to store_sym_names_in_linkage_form_p. * f-lang.c (f_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. * go-lang.c (go_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. * language.c (unknown_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (unknown_language::store_sym_names_in_linkage_form_p): New member function. (auto_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. (auto_language::store_sym_names_in_linkage_form_p): New member function. * language.h (language_data): Remove la_store_sym_names_in_linkage_form_p member variable. (language_defn::store_sym_names_in_linkage_form_p): New member function. * m2-lang.c (m2_language_data): Remove la_store_sym_names_in_linkage_form_p initializer. * objc-lang.c (objc_language_data): Likewise. * opencl-lang.c (opencl_language_data): Likewise. * p-lang.c (pascal_language_data): Likewise. * rust-lang.c (rust_language_data): Likewise.
2020-09-14Use type_instance_flags more throughoutPedro Alves1-4/+3
A later patch in this series will rewrite enum_flags fixing some API holes. That would cause build failures around code using type_instance_flags. Or rather, that should be using it, but wasn't. This patch fixes it by using type_instance_flags throughout instead of plain integers. Note that we can't make the seemingly obvious change to struct type::instance_flags: - unsigned instance_flags : 9; + ENUM_BITFIELD (type_instance_flag_value) instance_flags : 9; Because G++ complains then that 9 bits isn't sufficient for holding all values of type_instance_flag_value. So the patch adds an type::instance_flags() method, which takes care of casting appropriately, and adds a separate type::set_instance_flags method, following the pattern of the ongoing TYPE_XXX macro elimination. This converts uses of TYPE_INSTANCE_FLAGS to type::instance_flags() in the places where the code was already being touched, but there are still many references to the TYPE_INSTANCE_FLAGS macro left behind. Those could/should be fully replaced at some point. gdb/ChangeLog: * avr-tdep.c (avr_address_class_type_flags): Return type_instance_flags. (avr_address_class_type_flags_to_name): Take a type_instance_flags. (avr_address_class_name_to_type_flags): Return bool and take a type_instance_flags. * d-lang.c (build_d_types): Use type::set_instance_flags. * ft32-tdep.c (ft32_address_class_type_flags): Return type_instance_flags. (ft32_address_class_type_flags_to_name): Take a type_instance_flags. (ft32_address_class_name_to_type_flags): Return bool and take a type_instance_flags. (ft32_gdbarch_init): Use type::set_instance_flags. * eval.c (fake_method::fake_method): Use type::set_instance_flags. * gdbarch.h, gdbarch.c: Regenerate. * gdbarch.sh (address_class_type_flags): Use type_instance_flags. (address_class_name_to_type_flags): Use type_instance_flags and bool. * gdbtypes.c (address_space_name_to_int) (address_space_int_to_name, make_qualified_type): Use type_instance_flags. (make_qualified_type): Use type_instance_flags and type::set_instance_flags. (make_type_with_address_space, make_cv_type, make_vector_type) (check_typedef): Use type_instance_flags. (recursive_dump_type): Cast type_instance_flags to unsigned for printing. (copy_type_recursive): Use type::set_instance_flags. (gdbtypes_post_init): Use type::set_instance_flags. * gdbtypes.h (struct type) <instance_flags>: Rename to ... <m_instance_flags>: ... this. <instance_flags, set_instance_flags>: New methods. (TYPE_INSTANCE_FLAGS): Use the instance_flags method. (SET_TYPE_INSTANCE_FLAGS): New. (address_space_name_to_int, address_space_int_to_name) (make_type_with_address_space): Pass flags using type_instance_flags instead of int. * stabsread.c (cleanup_undefined_types_noname): Use type::set_instance_flags. * s390-tdep.c (s390_address_class_type_flags): Return type_instance_flags. (s390_address_class_type_flags_to_name): Take a type_instance_flags. (s390_address_class_name_to_type_flags): Return bool and take a type_instance_flags. * type-stack.c (type_stack::follow_types): Use type_instance_flags. * dwarf2/read.c (read_tag_pointer_type): Use type_instance_flags.
2020-09-14gdb: add type::endianity_is_not_default / type::set_endianity_is_not_defaultSimon Marchi1-1/+1
Add the `endianity_is_not_default` and `set_endianity_is_not_default` methods on `struct type`, in order to remove the `TYPE_ENDIANITY_NOT_DEFAULT` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <endianity_is_not_default, set_endianity_is_not_default>: New methods. (TYPE_ENDIANITY_NOT_DEFAULT): Use type::endianity_is_not_default, change all write call sites to use type::set_endianity_is_not_default. Change-Id: I67acd68fcdae424d7e4a601afda78612ad5d92db
2020-09-14gdb: add type::stub_is_supported / type::set_stub_is_supportedSimon Marchi1-1/+1
Add the `stub_is_supported` and `set_stub_is_supported` methods on `struct type`, in order to remove the `TYPE_STUB_SUPPORTED` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <stub_is_supported, set_stub_is_supported>: New methods. (TYPE_STUB_SUPPORTED): Use type::stub_is_supported, change all write call sites to use type::set_stub_is_supported. Change-Id: I4dfecf2b5df9c2b7bb8db1e9252082140adf3028
2020-09-14gdb: remove TYPE_VARARGSSimon Marchi1-3/+3
gdb/ChangeLog: * gdbtypes.h (TYPE_VARARGS): Remove, replace all uses with type::has_varargs. Change-Id: Ieea4a64b4bfa4b8be643e68cb403081881133740
2020-09-14gdb: add type::has_varargs / type::set_has_varargsSimon Marchi1-1/+2
Add the `has_varargs` and `set_has_varargs` methods on `struct type`, in order to remove the `TYPE_VARARGS` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <has_varargs, set_has_varargs>: New methods. (TYPE_VARARGS): Use type::has_varargs, change all write call sites to use type::set_has_varargs. Change-Id: I898a1093ae40808b37a7c6fced7f6fa2aae604de
2020-09-14gdb: add type::is_prototyped / type::set_is_prototypedSimon Marchi1-1/+1
Add the `is_prototyped` and `set_is_prototyped` methods on `struct type`, in order to remove the `TYPE_PROTOTYPED` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <is_prototyped, set_is_prototyped>: New methods. (TYPE_PROTOTYPED): Use type::is_prototyped, change all write call sites to use type::set_is_prototyped. Change-Id: I6ba285250fae413f7c1bf2ffcb5a2cedc8e743da
2020-09-14gdb: add type::target_is_stub / type::set_target_is_stubSimon Marchi1-1/+1
Add the `target_is_stub` and `set_target_is_stub` methods on `struct type`, in order to remove the `TYPE_TARGET_STUB` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <target_is_stub, set_target_is_stub>: New methods. (TYPE_TARGET_STUB): Use type::is_stub, change all write call sites to use type::set_target_is_stub. Change-Id: I9c71a89adc7ae8d018db9ee156f41c623be0484a
2020-09-14gdb: remove TYPE_STUBSimon Marchi1-1/+1
gdb/ChangeLog: * gdbtypes.h (TYPE_STUB): Remove, replace all uses with type::is_stub. Change-Id: Iec25b50449a0d10a38f815209e478c343e98632c
2020-09-14gdb: add type::is_stub / type::set_is_stubSimon Marchi1-5/+5
Add the `is_stub` and `set_is_stub` methods on `struct type`, in order to remove the `TYPE_STUB` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <is_stub, set_is_stub>: New methods. (TYPE_STUB): Use type::is_stub, change all write call sites to use type::set_is_stub. Change-Id: Ie935e8fe72c908afd8718411e83f4ff00c386bf3
2020-09-14gdb: remove TYPE_NOSIGNSimon Marchi1-1/+1
gdb/ChangeLog: * gdbtypes.h (TYPE_NOSIGN): Remove, replace all uses with type::has_no_signedness. Change-Id: Iaf8d1cedad195d03a4358e90f6ada77290d03bf2
2020-09-14gdb: add type::has_no_signedness / type::set_has_no_signednessSimon Marchi1-1/+1
Add the `has_no_signedness` and `set_has_no_signednes` methods on `struct type`, in order to remove the `TYPE_NOSIGN` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <has_no_signedness, set_has_no_signedness>: New methods. (TYPE_NOSIGN): Use type::has_no_signedness, change all write call sites to use type::set_has_no_signedness. Change-Id: I80d8e774316d146fbd814b2928ad5392bada39d5
2020-09-14gdb: remove TYPE_UNSIGNEDSimon Marchi3-9/+9
gdb/ChangeLog: * gdbtypes.h (TYPE_UNSIGNED): Remove, replace all uses with type::is_unsigned. Change-Id: I84f76f5cd44ff7294e421d317376a9e476bc8666
2020-09-14gdb: add type::is_unsigned / type::set_is_unsignedSimon Marchi1-2/+6
Add the `is_unsigned` and `set_is_unsigned` methods on `struct type`, in order to remove the `TYPE_UNSIGNED` macro. In this patch, the `TYPE_UNSIGNED` macro is changed to use `type::is_unsigned`, so all the call sites that are used to set this property on a type are changed to use the new method. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <is_unsigned, set_is_unsigned>: New methods. (TYPE_UNSIGNED): Use type::is_unsigned. Change all write call sites to use type::set_is_unsigned. Change-Id: Ib09ddce84eda160a801a8f288cccf61c8ef136bc
2020-09-03[gdb/breakpoint, PIE] Handle setting breakpoint on label without addressTom de Vries1-1/+3
When adding: ... if ![runto_main] then { fail "can't run to main" return 0 } ... to test-case gdb.base/label-without-address.exp and running it with target board unix/-fPIE/-pie, we run into: ... (gdb) break main:L1^M Breakpoint 2 at 0x555555554000: file label-without-address.c, line 22.^M ... That is, for a label with optimized-out address, we set a breakpoint at the relocation base. The root cause is that the dwarf reader, despite finding that attribute DW_AT_low_pc is missing, still tags the L1 symbol as having LOC_LABEL, which means it has a valid address, which defaults to 0. Fix this by instead tagging the L1 symbol with LOC_OPTIMIZED_OUT. Tested on x86_64-linux. gdb/ChangeLog: 2020-09-03 Tom de Vries <tdevries@suse.de> PR breakpoint/26546 * dwarf2/read.c (new_symbol): Tag label symbol without DW_AT_low_pc as LOC_OPTIMIZED_OUT instead of LOC_LABEL. gdb/testsuite/ChangeLog: 2020-09-03 Tom de Vries <tdevries@suse.de> PR breakpoint/26546 * gdb.base/label-without-address.exp: Runto main first.
2020-08-31gdb: change type of field_info::non_public_fields to boolSimon Marchi1-3/+3
gdb/ChangeLog: * dwarf2/read.c (struct field_info) <non_public_fields>: Change type to bool. (dwarf2_add_field): Use true instead of 1. Change-Id: I7e9c86429402c28d4f15861d17976b9c50049f94
2020-08-31gdb: fix indentation of struct field_infoSimon Marchi1-28/+28
The indentation is off, fix it before doing other changes. gdb/ChangeLog: * dwarf2/read.c (struct field_info): Fix indentation. Change-Id: Ife6a3d017abcf0a33e49e47e51429e95d504343c
2020-08-17gdb: fix wrong indentation in symbol_needs_eval_contextSimon Marchi1-13/+13
gdb/ChangeLog: * loc.c (class symbol_needs_eval_context): Fix indentation. Change-Id: Ibf4e6a9ca9573b498737a61db116ee10b287b7f5
2020-08-17gdb: use bool in dwarf2_loc_desc_get_symbol_read_needsSimon Marchi1-4/+3
This variable is really a boolean, so use the bool type. gdb/ChangeLog: * dwarf2/loc.c (dwarf2_loc_desc_get_symbol_read_needs): Use bool. Change-Id: I814a47d1200f3b88722c54c822fd49607a6b77be
2020-08-09gdb: replace function pointer with `void *` data with function_viewSimon Marchi3-41/+26
Replace the function pointer + `void *` parameters of dwarf2_fetch_die_loc_sect_off and dwarf2_fetch_die_loc_cu_off with a function_view parameter. Change call sites to use a lambda function. This improves type-safety, so reduces the chances of errors. gdb/ChangeLog: * read.h (dwarf2_fetch_die_loc_sect_off, dwarf2_fetch_die_loc_cu_off): Replace function pointer + `void *` parameter with function_view. * read.c (dwarf2_fetch_die_loc_sect_off, dwarf2_fetch_die_loc_cu_off): Likewise. * loc.c (get_frame_pc_for_per_cu_dwarf_call): Remove. (per_cu_dwarf_call): Adjust. (get_frame_address_in_block_wrapper): Remove. (indirect_synthetic_pointer): Adjust. (get_ax_pc): Remove. (dwarf2_compile_expr_to_ax): Adjust. Change-Id: Ic9b6ced0c4128f2b75ca62e0ed638b0962a22859
2020-08-07Add code for processing version 5 DWP files (for use with DWARF v5).Caroline Tice1-52/+428
The DWARF v5 Spec describes a (slightly) new format for V5 .dwp files. This patch updates GDB to allow it to read/process .dwp files in the new DWARF v5 format, while continuing to be able to read/process .dwp files in the older V1 & V2 formats (older, pre-standard formats). The two major differences between the V2 and the V5 format are: - The inclusion of DWARF-v5-specific sections: .debug_loclists.dwo .debug_rnglists.dwo - The .dwp section identifier encodings have changed. The table below shows the old & new encodings. Notice the re-purposing of 5, 7 & 8 in particular. Val DW4 section DW4 section id DW5 section DW5 section id --- ----------------- -------------- ----------------- -------------- 1 .debug_info.dwo DW_SECT_INFO .debug_info.dwo DW_SECT_INFO 2 .debug_types.dwo DW_SECT_TYPES -- reserved 3 .debug_abbrev.dwo DW_SECT_ABBREV .debug_abbrev.dwo DW_SECT_ABBREV 4 .debug_line.dwo DW_SECT_LINE .debug_line.dwo DW_SECT_LINE 5 .debug_loc.dwo DW_SECT_LOC .debug_loclists.dwo DW_SECT_LOCLISTS 6 .debug_str_offsets.dwo .debug_str_offsets.dwo DW_SECT_STR_OFFSETS DW_SECT_STR_OFFSETS 7 .debug_macinfo.dwo DW_SECT_MACINFO .debug_macro.dwo DW_SECT_MACRO 8 .debug_macro.dwo DW_SECT_MACRO .debug_rnglists.dwo DW_SECT_RNGLISTS
2020-08-06gdb: move regcache::regcaches to regcache.cSimon Marchi1-0/+1
I don't really understand why `regcache_thread_ptid_changed` is a static method of `struct regcache` instead of being a static free function in regcache.c. And I don't understand why `current_regcache` is a static member of `struct regcache` instead of being a static global in regcache.c. It's not wrong per-se, but there's no other place where we do it like this in GDB (as far as I remember) and it just exposes things unnecessarily in the .h. Move them to be just static in regcache.c. As a result, registers_changed_ptid doesn't need to be friend of the regcache class anymore. Removing the include of forward_list in regcache.h showed that we were missing an include for it in dwarf2/index-write.c, record-btrace.c and sparc64-tdep.c. gdb/ChangeLog: * regcache.h (class regcache): Remove friend registers_changed_ptid. <regcache_thread_ptid_changed>: Remove. <regcaches>: Remove. * regcache.c (regcache::regcaches): Rename to... (regcaches): ... this. Make static. (get_thread_arch_aspace_regcache): Update. (regcache::regcache_thread_ptid_changed): Rename to... (regcache_thread_ptid_changed): ... this. Update. (class regcache_access): Remove. (regcaches_test): Update. (_initialize_regcache): Update. * sparc64-tdep.c, dwarf2/index-write.c, record-btrace.c: Include <forward_list>. Change-Id: Iabc25759848010cfbb7ee7e27f60eaca17d61c12
2020-08-05Fix variant part regressions with older Rust compilerTom Tromey1-9/+23
Older Rust compilers used special field names, rather than DWARF features, to express the variant parts of Rust enums. This is handled in gdb through a quirk recognizer that rewrites the types. Tom de Vries pointed out in PR rust/26197 that the variant part rewrite regressed this code. This patch fixes the problems: * Univariant enums were not handled properly. Now we simply call alloc_rust_variant for these as well. * There was an off-by-one error in the handling of ordinary enums. * Ordinary enums should have the size of their member types reset to match the size of the enclosing enum. (It's not clear to me if this is truly necessary, but it placates a test, and this is just legacy handling in any case.) Tested with Rust 1.12.0, 1.14.0, 1.19.0, 1.36.0, and 1.45.0 on x86-64 Fedora 32. There were some unrelated failures with 1.14.0 and 1.19,0; but considering that these are fairly old releases, I don't plan to look into them unless someone complains. Note that this patch will not fix all the issues in the PR. In that PR, Tom is using a somewhat unusual build of Rust -- in particular it uses an older (pre-DWARF variant part) LLVM with a newer Rust. I believe this compiler doesn't correctly implement the old-style name fallback; the details are in the bug. gdb/ChangeLog 2020-08-05 Tom Tromey <tromey@adacore.com> PR rust/26197: * dwarf2/read.c (alloc_rust_variant): Handle univariant case. (quirk_rust_enum): Call alloc_rust_variant for univariant case. Fix off-by-one and type size errors in ordinary case.
2020-08-04gdb: use bool in frame codeSimon Marchi1-1/+1
Change instances of int variables and return values used as boolean values to use the bool type. Shorten the comments of a few functions, because I think they go a bit too much in implementation details, which appear out of date anyway. Make other misc changes to the functions that are already being changed, such as using nullptr instead of NULL, dropping `struct` keywords and declaring variables when first used. gdb/ChangeLog: * frame.h (frame_id_p): Return bool. (frame_id_artificial_p): Return bool. (frame_id_eq): Return bool. (has_stack_frames): Return bool. (get_selected_frame): Fix typo in comment. (get_frame_pc_if_available): Return bool. (get_frame_address_in_block_if_available): Return bool. (get_frame_func_if_available): Return bool. (read_frame_register_unsigned): Return bool. (get_frame_register_bytes): Return bool. (safe_frame_unwind_memory): Return bool. (deprecated_frame_register_read): Return bool. (frame_unwinder_is): Return bool. * frame.c (struct frame_info) <prev_arch::p>: Change type to bool. <this_id::p>: Likewise. <prev_p>: Likewise. (frame_stash_add): Return bool. (get_frame_id): Use bool. (frame_id_build_special) Use bool. (frame_id_build_unavailable_stack): Use bool. (frame_id_build): Use bool. (frame_id_p): Return bool, use true/false instead of 1/0. (frame_id_artificial_p): Likewise. (frame_id_eq): Likewise. (frame_id_inner): Likewise. (get_frame_func_if_available): Likewise. (read_frame_register_unsigned): Likewise. (deprecated_frame_register_read): Likewise. (get_frame_register_bytes): Likewise. (has_stack_frames): Likewise. (inside_main_func): Likewise. (inside_entry_func): Likewise. (get_frame_pc_if_available): Likewise. (get_frame_address_in_block_if_available): Likewise. (frame_unwinder_is): Likewise. (safe_frame_unwind_memory): Likewise. (frame_unwind_arch): Likewise. Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a
2020-08-04[gdb/symtab] Handle invalid partial DIE referenceTom de Vries1-3/+1
When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE 0x1b7 in cache [from module amd64-entry-value-paramref]^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M ... because of invalid dwarf. In contrast, when using -readnow, we have: ... (gdb) file -readnow amd64-entry-value-paramref Reading symbols from amd64-entry-value-paramref... Expanding full symbols from amd64-entry-value-paramref... Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \ [in module amd64-entry-value-paramref] (gdb) ... Change the internal error into a Dwarf Error, such that we have: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M Dwarf Error: Cannot not find DIE at 0x1b7 \ [from module amd64-entry-value-paramref]^M ^M (No debugging symbols found in amd64-entry-value-paramref)^M (gdb) ... Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-04 Tom de Vries <tdevries@suse.de> PR symtab/23270 * dwarf2/read.c (find_partial_die): Change internal error into Dwarf Error.
2020-08-03[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user rangeTom de Vries1-0/+7
When reading an exec with a .debug_line section containing a vendor-specific extended opcode, we get: ... $ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode During symbol reading: mangled .debug_line section ... and reading of the .debug_line section is abandoned. The vendor-specific extended opcode should be ignored, as specified in the DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific standard opcodes are already ignored. ] Fix this by ignoring all vendor-specific extended opcodes. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * dwarf2/read.c (dwarf_decode_lines_1): Ignore DW_LNE_lo_user/DW_LNE_hi_user range. gdb/testsuite/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * lib/dwarf.exp (DW_LNE_user): New proc. * gdb.dwarf2/dw2-vendor-extended-opcode.c: New test. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey1-1/+2
A modified version of the gnat compiler (TBH I don't know if the modifications are relevant to this bug or not, but I figured I'd mention it) can generate a DWARF location expression like: <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure) <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop) <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type) <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and) When evaluated, this gives: Incompatible types on DWARF stack In Jakub's original message about DW_OP_GNU_variable_value: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html .. it says: The intended behavior is that the debug info consumer computes the value of that referenced variable at the current PC, and if it can compute it and pushes the value as a generic type integer into the DWARF stack Instead, gdb is using the variable's type -- but this fails with some operations, like DW_OP_and, which expect the types to match. I believe what was intended was for the value to be cast to the DWARF "untyped" type, which is what this patch implements. This patch also updates varval.exp to exhibit the bug. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op) <DW_OP_GNU_variable_value>: Cast to address type. gdb/testsuite/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to 'varval' location.
2020-07-25[gdb/symtab] Ignore zero line table entriesTom de Vries1-2/+3
The DWARF standard states for the line register in the line number information state machine the following: ... An unsigned integer indicating a source line number. Lines are numbered beginning at 1. The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. ... So, it's possible to have a zero line number in the DWARF line table. This is currently not handled by GDB. The zero value is read in as any other line number, but internally the zero value has a special meaning: end-of-sequence, so the line table entry ends up having a different interpretation than intended in some situations. I've created a test-case where various aspects are tested, which has these 4 interesting tests. 1. Next-step through a zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next 2. Next-step through a zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next 3. Show source location at zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 4. Show source location at zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 And we have the following results: 8.3.1, 9.2: ... FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt field": ... PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting", master: FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243, where clang emits zero line numbers. The way to fix all tests is to make sure line number zero internally doesn't clash with special meaning values, and by handling it appropriately everywhere. That however looks too intrusive for the GDB 10 release. Instead, we decide to ensure defined behaviour for line number zero by ignoring it. This gives us back the test results from before commit d8cc8af6a1, fixing PR26243. We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb 10 the cost for having defined behaviour. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line entries. gdb/testsuite/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * gdb.dwarf2/dw2-line-number-zero.c: New test. * gdb.dwarf2/dw2-line-number-zero.exp: New file.
2020-07-16gdb: fix issues with handling DWARF v5 rnglists & .dwo files.Caroline Tice1-48/+213
While experimenting with GDB on DWARF 5 with split debug (dwo files), I discovered that GDB was not reading the rnglist index properly (it needed to be reprocessed in the same way the loclist index does), and that there was no code for reading rnglists out of dwo files at all. Also, the rnglist address reading function (dwarf2_rnglists_process) was adding the base address to all rnglist entries, when it's only supposed to add it to the DW_RLE_offset_pair entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not handling several entry types. - Added 'reprocessing' for reading rnglist index (as is done for loclist index). - Added code for reading rnglists out of .dwo files. - Added several missing rnglist forms to dwarf2_rnglists_process. - Fixed bug that was alwayas adding base address for rnglists (only one form needs that). - Updated dwarf2_rnglists_process to read rnglist out of dwo file when appropriate. - Added new functions cu_debug_rnglist_section & read_rnglist_index. - Added new testcase, dw5-rnglist-test.{cc,exp} Special note about the new testcase: In order for the test case to test anything meaningful, it must be compiled with clang, not GCC. The way to do this is as follows: $ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp" This following version of clang was used for this testing: clang version 9.0.1-11 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d
2020-07-12gdb: add accessors to struct dynamic_propSimon Marchi2-48/+37
Add setters, to ensure that the kind and value of the property are always kept in sync (a caller can't forget one or the other). Add getters, such that we can assert that when a caller accesses a data bit of the property, the property is indeed of the corresponding kind. Note that because of the way `struct dynamic_prop` is allocated currently, we can't make the `m_kind` and `m_data` fields private. That would make the type non-default-constructible, and we would have to call the constructor when allocating them. However, I still prefixed them with `m_` to indicate that they should not be accessed from outside the class (and also to be able to use the name `kind` for the method). gdb/ChangeLog: * gdbtypes.h (struct dynamic_prop) <kind, set_undefined, const_val, set_const_val, baton, set_locexpr, set_loclist, set_addr_offset, variant_parts, set_variant_parts, original_type, set_original_type>: New methods. <kind>: Rename to... <m_kind>: ... this. Update all users to use the new methods instead. <data>: Rename to... <m_data>: ... this. Update all users to use the new methods instead. Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
2020-07-12gdb: remove TYPE_RANGE_DATA macroSimon Marchi1-1/+1
Remove it in favor of using type::bounds directly. gdb/ChangeLog: * gdbtypes.h (TYPE_RANGE_DATA): Remove. Update callers to use the type::bounds method directly. Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2
2020-07-10Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1Pedro Alves1-2/+16
Running the testsuite against an Asan-enabled build of GDB makes gdb.base/multi-target.exp expose this bug. scoped_restore_current_thread's ctor calls get_frame_id to record the selected frame's ID to restore later. If the frame ID hasn't been computed yet, it will be computed on the spot, and that will usually require accessing the target's memory and registers, which requires remote accesses. If the remote connection closes while we're computing the frame ID, the remote target exits its inferiors, unpushes itself, and throws a TARGET_CLOSE_ERROR error. If that happens, GDB can currently crash, here: > ==18555==ERROR: AddressSanitizer: heap-use-after-free on address 0x621004670aa8 at pc 0x0000007ab125 bp 0x7ffdecaecd20 sp 0x7ffdecaecd10 > READ of size 4 at 0x621004670aa8 thread T0 > #0 0x7ab124 in dwarf2_frame_this_id src/binutils-gdb/gdb/dwarf2/frame.c:1228 > #1 0x983ec5 in compute_frame_id src/binutils-gdb/gdb/frame.c:550 > #2 0x9841ee in get_frame_id(frame_info*) src/binutils-gdb/gdb/frame.c:582 > #3 0x1093faa in scoped_restore_current_thread::scoped_restore_current_thread() src/binutils-gdb/gdb/thread.c:1462 > #4 0xaee5ba in fetch_inferior_event(void*) src/binutils-gdb/gdb/infrun.c:3968 > #5 0xaa990b in inferior_event_handler(inferior_event_type, void*) src/binutils-gdb/gdb/inf-loop.c:43 > #6 0xea61b6 in remote_async_serial_handler src/binutils-gdb/gdb/remote.c:14161 > #7 0xefca8a in run_async_handler_and_reschedule src/binutils-gdb/gdb/ser-base.c:137 > #8 0xefcd23 in fd_event src/binutils-gdb/gdb/ser-base.c:188 > #9 0x15a7416 in handle_file_event src/binutils-gdb/gdbsupport/event-loop.cc:548 > #10 0x15a7c36 in gdb_wait_for_event src/binutils-gdb/gdbsupport/event-loop.cc:673 > #11 0x15a5dbb in gdb_do_one_event() src/binutils-gdb/gdbsupport/event-loop.cc:215 > #12 0xbfe62d in start_event_loop src/binutils-gdb/gdb/main.c:356 > #13 0xbfe935 in captured_command_loop src/binutils-gdb/gdb/main.c:416 > #14 0xc01d39 in captured_main src/binutils-gdb/gdb/main.c:1253 > #15 0xc01dc9 in gdb_main(captured_main_args*) src/binutils-gdb/gdb/main.c:1268 > #16 0x414ddd in main src/binutils-gdb/gdb/gdb.c:32 > #17 0x7f590110b82f in __libc_start_main ../csu/libc-start.c:291 > #18 0x414bd8 in _start (build/binutils-gdb/gdb/gdb+0x414bd8) What happens is that above, we're in dwarf2_frame_this_id, just after the dwarf2_frame_cache call. The "cache" variable that the dwarf2_frame_cache function returned is already stale. It's been released here, from within the dwarf2_frame_cache: (top-gdb) bt #0 reinit_frame_cache () at src/gdb/frame.c:1855 #1 0x00000000014ff7b0 in switch_to_no_thread () at src/gdb/thread.c:1301 #2 0x0000000000f66d3e in switch_to_inferior_no_thread (inf=0x615000338180) at src/gdb/inferior.c:626 #3 0x00000000012f3826 in remote_unpush_target (target=0x6170000c5900) at src/gdb/remote.c:5521 #4 0x00000000013097e0 in remote_target::readchar (this=0x6170000c5900, timeout=2) at src/gdb/remote.c:9137 #5 0x000000000130be4d in remote_target::getpkt_or_notif_sane_1 (this=0x6170000c5900, buf=0x6170000c5918, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9683 #6 0x000000000130c8ab in remote_target::getpkt_sane (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9790 #7 0x000000000130bc0d in remote_target::getpkt (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9623 #8 0x000000000130838e in remote_target::remote_read_bytes_1 (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len_units=64, unit_size=1, xfered_len_units=0x7fff6a29b9a0) at src/gdb/remote.c:8860 #9 0x0000000001308bd2 in remote_target::remote_read_bytes (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64, unit_size=1, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:8987 #10 0x0000000001311ed1 in remote_target::xfer_partial (this=0x6170000c5900, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:10988 #11 0x00000000014ba969 in raw_memory_xfer_partial (ops=0x6170000c5900, readbuf=0x6080000ad3bc "", writebuf=0x0, memaddr=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:918 #12 0x00000000014bb720 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1148 #13 0x00000000014bc3b5 in target_read_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1380 #14 0x00000000014bc593 in target_read (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64) at src/gdb/target.c:1419 #15 0x00000000014bbd4d in target_read_raw_memory (memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64) at src/gdb/target.c:1252 #16 0x0000000000bf27df in dcache_read_line (dcache=0x6060001eddc0, db=0x6080000ad3a0) at src/gdb/dcache.c:336 #17 0x0000000000bf2b72 in dcache_peek_byte (dcache=0x6060001eddc0, addr=0x7fffffffcdd8, ptr=0x6020001231b0 "") at src/gdb/dcache.c:403 #18 0x0000000000bf3103 in dcache_read_memory_partial (ops=0x6170000c5900, dcache=0x6060001eddc0, memaddr=0x7fffffffcdd8, myaddr=0x6020001231b0 "", len=8, xfered_len=0x7fff6a29bf20) at src/gdb/dcache.c:484 #19 0x00000000014bafe9 in memory_xfer_partial_1 (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1034 #20 0x00000000014bb212 in memory_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1076 #21 0x00000000014bb6b3 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, annex=0x0, readbuf=0x6020001231b0 "", writebuf=0x0, offset=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1133 #22 0x000000000164564d in read_value_memory (val=0x60f000029440, bit_offset=0, stack=1, memaddr=0x7fffffffcdd8, buffer=0x6020001231b0 "", length=8) at src/gdb/valops.c:956 #23 0x0000000001680fff in value_fetch_lazy_memory (val=0x60f000029440) at src/gdb/value.c:3764 #24 0x0000000001681efd in value_fetch_lazy (val=0x60f000029440) at src/gdb/value.c:3910 #25 0x0000000001676143 in value_optimized_out (value=0x60f000029440) at src/gdb/value.c:1411 #26 0x0000000000e0fcb8 in frame_register_unwind (next_frame=0x6210066bfde0, regnum=16, optimizedp=0x7fff6a29c200, unavailablep=0x7fff6a29c240, lvalp=0x7fff6a29c2c0, addrp=0x7fff6a29c300, realnump=0x7fff6a29c280, bufferp=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1144 #27 0x0000000000e10418 in frame_unwind_register (next_frame=0x6210066bfde0, regnum=16, buf=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1196 #28 0x0000000000f00431 in i386_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/i386-tdep.c:1969 #29 0x0000000000e39724 in gdbarch_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/gdbarch.c:3056 #30 0x0000000000c2ea90 in dwarf2_tailcall_sniffer_first (this_frame=0x6210066bfde0, tailcall_cachep=0x6210066bfee0, entry_cfa_sp_offsetp=0x0) at src/gdb/dwarf2/frame-tailcall.c:423 #31 0x0000000000c36bdb in dwarf2_frame_cache (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8) at src/gdb/dwarf2/frame.c:1198 #32 0x0000000000c36eb3 in dwarf2_frame_this_id (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8, this_id=0x6210066bfe40) at src/gdb/dwarf2/frame.c:1226 Note that remote_target::readchar in frame #4 throws TARGET_CLOSE_ERROR after the remote_unpush_target in frame #3 returns. The problem is that the TARGET_CLOSE_ERROR is swallowed by value_optimized_out in frame #25. If we fix that one, then we run into dwarf2_tailcall_sniffer_first swallowing the exception in frame #30 too. The attached patch fixes it by making those spots swallow fewer kinds of errors. gdb/ChangeLog: * frame-tailcall.c (dwarf2_tailcall_sniffer_first): Only swallow NO_ENTRY_VALUE_ERROR / MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR. * value.c (value_optimized_out): Only swallow MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR.
2020-07-06gdb: Python unwinders, inline frames, and tail-call framesAndrew Burgess1-36/+1
This started with me running into the bug described in python/22748, in summary, if the frame sniffing code accessed any registers within an inline frame then GDB would crash with this error: gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed. The problem is that, when in the Python unwinder I write this: pending_frame.read_register ("register-name") This is translated internally into a call to `value_of_register', which in turn becomes a call to `value_of_register_lazy'. Usually this isn't a problem, `value_of_register_lazy' requires the next frame (more inner) to have a valid frame_id, which will be the case (if we're sniffing frame #1, then frame #0 will have had its frame-id figured out). Unfortunately if frame #0 is inline within frame #1, then the frame-id for frame #0 can't be computed until we have the frame-id for #1. As a result we can't create a lazy register for frame #1 when frame #0 is inline. Initially I proposed a solution inline with that proposed in bugzilla, changing value_of_register to avoid creating a lazy register value. However, when this was discussed on the mailing list I got this reply: https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html Which led me to look at these two patches: [1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html [2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html When I considered patches [1] and [2] I saw that all of the issues being addressed here were related, and that there was a single solution that could address all of these issues. First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which shows that [1] and [2] regress the inline tail-call unwinder, the reason for this is that these two patches replace a call to gdbarch_unwind_pc with a call to get_frame_register, however, this is not correct. The previous call to gdbarch_unwind_pc takes THIS_FRAME and returns the $pc value in the previous frame. In contrast get_frame_register takes THIS_FRAME and returns the value of the $pc in THIS_FRAME; these calls are not equivalent. The reason these patches appear (or do) fix the regressions listed in [1] is that the tail call sniffer depends on identifying the address of a caller and a callee, GDB then looks for a tail-call sequence that takes us from the caller address to the callee, if such a series is found then tail-call frames are added. The bug that was being hit, and which was address in patch [1] is that in order to find the address of the caller, GDB ended up creating a lazy register value for an inline frame with to frame-id. The solution in patch [1] is to instead take the address of the callee and treat this as the address of the caller. Getting the address of the callee works, but we then end up looking for a tail-call series from the callee to the callee, which obviously doesn't return any sane results, so we don't insert any tail call frames. The original patch [1] did cause some breakage, so patch [2] undid patch [1] in all cases except those where we had an inline frame with no frame-id. It just so happens that there were no tests that fitted this description _and_ which required tail-call frames to be successfully spotted, as a result patch [2] appeared to work. The new test inline-frame-tailcall.exp, exposes the flaw in patch [2]. This commit undoes patch [1] and [2], and replaces them with a new solution, which is also different to the solution proposed in the python/22748 bug report. In this solution I propose that we introduce some special case logic to value_of_register_lazy. To understand what this logic is we must first look at how inline frames unwind registers, this is very simple, they do this: static struct value * inline_frame_prev_register (struct frame_info *this_frame, void **this_cache, int regnum) { return get_frame_register_value (this_frame, regnum); } And remember: struct value * get_frame_register_value (struct frame_info *frame, int regnum) { return frame_unwind_register_value (frame->next, regnum); } So in all cases, unwinding a register in an inline frame just asks the next frame to unwind the register, this makes sense, as an inline frame doesn't really exist, when we unwind a register in an inline frame, we're really just asking the next frame for the value of the register in the previous, non-inline frame. So, if we assume that we only get into the missing frame-id situation when we try to unwind a register from an inline frame during the frame sniffing process, then we can change value_of_register_lazy to not create lazy register values for an inline frame. Imagine this stack setup, where #1 is inline within #2. #3 -> #2 -> #1 -> #0 \______/ inline Now when trying to figure out the frame-id for #1, we need to compute the frame-id for #2. If the frame sniffer for #2 causes a lazy register read in #2, either due to a Python Unwinder, or for the tail-call sniffer, then we call value_of_register_lazy passing in frame #2. In value_of_register_lazy, we grab the next frame, which is #1, and we used to then ask for the frame-id of #1, which was not computed, and this was our bug. Now, I propose we spot that #1 is an inline frame, and so lookup the next frame of #1, which is #0. As #0 is not inline it will have a valid frame-id, and so we create a lazy register value using #0 as the next-frame-id. This will give us the exact same result we had previously (thanks to the code we inspected above). Encoding into value_of_register_lazy the knowledge that reading an inline frame register will always just forward to the next frame feels.... not ideal, but this seems like the cleanest solution to this recursive frame-id computation/sniffing issue that appears to crop up. The following two commits are fully reverted with this commit, these correspond to patches [1] and [2] respectively: commit 5939967b355ba6a940887d19847b7893a4506067 Date: Tue Apr 14 17:26:22 2020 -0300 Fix inline frame unwinding breakage commit 991a3e2e9944a4b3a27bd989ac03c18285bd545d Date: Sat Apr 25 00:32:44 2020 -0300 Fix remaining inline/tailcall unwinding breakage for x86_64 gdb/ChangeLog: PR python/22748 * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove special handling for inline frames. * findvar.c (value_of_register_lazy): Skip inline frames when creating lazy register values. * frame.c (frame_id_computed_p): Delete definition. * frame.h (frame_id_computed_p): Delete declaration. gdb/testsuite/ChangeLog: PR python/22748 * gdb.opt/inline-frame-tailcall.c: New file. * gdb.opt/inline-frame-tailcall.exp: New file. * gdb.python/py-unwind-inline.c: New file. * gdb.python/py-unwind-inline.exp: New file. * gdb.python/py-unwind-inline.py: New file.
2020-07-01Recognize -1 as a tombstone value in .debug_lineFangrui Song1-6/+7
LLD from 11 onwards (https://reviews.llvm.org/D81784) uses -1 to represent a relocation in .debug_line referencing a discarded symbol. Recognize -1 to fix gdb.base/break-on-linker-gcd-function.exp when the linker is a newer LLD. gdb/ChangeLog: * dwarf2/read.c (lnp_state_machine::check_line_address): Test -1.
2020-07-01Allow reference form for DW_AT_associated and DW_AT_allocated attributesAlok Kumar Sharma1-14/+2
Currently, GDB rejects the (die) reference form while it accepts exprloc form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings" in DWARF5 standard. Flang compiler assigns (die) reference to DW_AT_associated and DW_AT_allocated for some cases. gdb/ChangeLog * dwarf2/read.c (set_die_type): Removed conditions to restrict forms for DW_AT_associated and DW_AT_allocated attributes, which is already checked in function attr_to_dynamic_prop.
2020-06-30Fix bug in quirk_rust_enumTom Tromey1-1/+1
Tom de Vries pointed out that some Rust tests were failing after the variant part rewrite. He sent an executable, which helped track down this bug. quirk_rust_enum was passing 1 to alloc_rust_variant in one case. However, a comment earlier says: /* We don't need a range entry for the discriminant, but we do need one for every other field, as there is no default variant. */ In this case, we must pass -1 for this parameter. That is what this patch implements. gdb/ChangeLog 2020-06-30 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (quirk_rust_enum): Correctly call alloc_rust_variant for default-less enum.
2020-06-23gdb: add some more empty lines in loc.cSimon Marchi1-0/+17
Add some empty lines at places I forgot in the previous patch. gdb/ChangeLog: * dwarf2/loc.c (decode_debug_loclists_addresses): Add empty lines. Change-Id: I8a9f3766ede1ce750e0703023285dca873bce0da
2020-06-23gdb: add empty lines in loc.cSimon Marchi1-1/+41
I always found that some switch statements in this file were a bit too packed. I think having empty lines between each case helps with reading. I'm pushing this as obvious, I hope it won't be too controversial. gdb/ChangeLog: * dwarf2/loc.c (decode_debug_loc_dwo_addresses): Add empty lines. (dwarf2_find_location_expression): Likewise. (call_site_parameter_matches): Likewise. (dwarf2_compile_expr_to_ax): Likewise. (disassemble_dwarf_expression): Likewise. (loclist_describe_location): Likewise. Change-Id: I381366a0468ff1793faa612c46ef48a9d4773192
2020-06-17gdb: check for partial symtab presence in dwarf2_initialize_objfileSimon Marchi1-0/+8
This patch fixes an internal error that is triggered when loading the same binary twice with the index-cache on: $ ./gdb -q -nx --data-directory=data-directory (gdb) set index-cache on (gdb) shell mktemp -d /tmp/tmp.BLgouVoPq4 (gdb) set index-cache directory /tmp/tmp.BLgouVoPq4 (gdb) file a.out Reading symbols from a.out... (gdb) file a.out Load new symbol table from "a.out"? (y or n) y Reading symbols from a.out... /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2540: internal-error: void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, const gdb_byte*, offset_type): Assertion `per_bfd->all_comp_units.empty ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) This is what happens: 1. We load the binary the first time, partial symtabs are created, per_bfd->all_comp_units is filled from those. 2. Because index-cache is on, we also generate an index in the cache. 3. We load the binary a second time, in dwarf2_initialize_objfile we check: was an index already loaded for this BFD? No, so we try to read the index and fill the per-bfd using it. We do find an index, it's in the cache. 4. The function create_cus_from_index asserts (rightfully) that per_cu->all_comp_units is empty, and the assertion fails. This assertion verifies that we are not reading an index for a BFD for which we have already built partial symtabs or read another index. The index-cache gives a situation that isn't currently accounted for: a BFD for which we have built the partial symtabs the first time, but has an index the second time. This patch addresses it by checking for the presence of partial symtabs in dwarf2_initialize_objfile. If there are, we don't try reading the index. gdb/ChangeLog: * dwarf2/read.c (dwarf2_initialize_objfile): Check for presence of partial symtabs. gdb/testsuite/ChangeLog: * gdb.base/index-cache-load-twice.c: New. * gdb.base/index-cache-load-twice.exp: New. Change-Id: Ie05474c44823fcdff852b73170dd28dfd66cb6a2
2020-06-17gdb: Convert language la_get_symbol_name_matcher field to a methodAndrew Burgess1-1/+1
This commit changes the language_data::la_get_symbol_name_matcher function pointer member variable into a member function of language_defn. There should be no user visible changes after this commit. Before this commit access to the la_get_symbol_name_matcher function pointer was through the get_symbol_name_matcher function, which looked something like this (is pseudo-code): <return-type> get_symbol_name_matcher (language_defn *lang, <other args>) { if (current_language == ada) current_language->la_get_symbol_name_matcher (<other args>); else lang->la_get_symbol_name_matcher (<other args>); } In this commit I moved the get_symbol_name_matcher as a non-virtual function in the language_defn base class, I then add a new virtual method that is only used from within get_symbol_name_matcher, this can then be overridden by specific languages as needed. So we now have: class language_defn { <return-type> get_symbol_name_matcher (<args>) { if (current_language == ada) return current_language->get_symbol_name_matcher_inner (<args>); else return this->get_symbol_name_matcher_inner (<args>); } virtual <return-type> get_symbol_name_matcher_inner (<args>) { .... } } gdb/ChangeLog: * ada-lang.c (ada_get_symbol_name_matcher): Update header comment. (ada_language_data): Delete la_get_symbol_name_matcher initializer. (language_defn::get_symbol_name_matcher_inner): New member function. * c-lang.c (c_language_data): Delete la_get_symbol_name_matcher initializer. (cplus_language_data): Likewise. (cplus_language::get_symbol_name_matcher_inner): New member function. (asm_language_data): Delete la_get_symbol_name_matcher initializer. (minimal_language_data): Likewise. * cp-support.h (cp_get_symbol_name_matcher): Update header comment. * d-lang.c (d_language_data): Delete la_get_symbol_name_matcher initializer. * dictionary.c (iter_match_first_hashed): Update call to get_symbol_name_matcher. (iter_match_next_hashed): Likewise. (iter_match_next_linear): Likewise. * dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Likewise. * f-lang.c (f_language_data): Delete la_get_symbol_name_matcher initializer. (f_language::get_symbol_name_matcher_inner): New member function. * go-lang.c (go_language_data): Delete la_get_symbol_name_matcher initializer. * language.c (default_symbol_name_matcher): Update header comment, make static. (language_defn::get_symbol_name_matcher): New definition. (language_defn::get_symbol_name_matcher_inner): Likewise. (get_symbol_name_matcher): Delete. (unknown_language_data): Delete la_get_symbol_name_matcher initializer. (auto_language_data): Likewise. * language.h (language_data): Delete la_get_symbol_name_matcher field. (language_defn::get_symbol_name_matcher): New member function. (language_defn::get_symbol_name_matcher_inner): Likewise. (default_symbol_name_matcher): Delete declaration. * linespec.c (find_methods): Update call to get_symbol_name_matcher. * m2-lang.c (m2_language_data): Delete la_get_symbol_name_matcher initializer. * minsyms.c (lookup_minimal_symbol): Update call to get_symbol_name_matcher. (iterate_over_minimal_symbols): Likewise. * objc-lang.c (objc_language_data): Delete la_get_symbol_name_matcher initializer. * opencl-lang.c (opencl_language_data): Likewise. * p-lang.c (pascal_language_data): Likewise. * psymtab.c (psymbol_name_matches): Update call to get_symbol_name_matcher. * rust-lang.c (rust_language_data): Delete la_get_symbol_name_matcher initializer. * symtab.c (symbol_matches_search_name): Update call to get_symbol_name_matcher. (compare_symbol_name): Likewise.
2020-06-17gdb: Convert language la_class_name_from_physname field to a methodAndrew Burgess1-4/+3
This commit changes the language_data::la_class_name_from_physname function pointer member variable into a member function of language_defn. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-lang.c (ada_language_data) Delete la_class_name_from_physname initializer. * c-lang.c (c_language_data): Likewise. (cplus_language_data): Likewise. (cplus_language::class_name_from_physname): New member function. (asm_language_data): Delete la_class_name_from_physname initializer. (minimal_language_data): Likewise. * d-lang.c (d_language_data): Likewise. * dwarf2/read.c (guess_partial_die_structure_name): Update to call method on language_defn class. (guess_full_die_structure_name): Likewise. * f-lang.c (f_language_data): Delete la_class_name_from_physname initializer. * go-lang.c (go_language_data): Likewise. * language.c (language_class_name_from_physname): Delete. (unk_lang_class_name): Delete. (unknown_language_data): Delete la_class_name_from_physname initializer. (auto_language_data): Likewise. * language.h (language_data): Delete la_class_name_from_physname field. (language_defn::class_name_from_physname): New function. (language_class_name_from_physname): Delete declaration. * m2-lang.c (m2_language_data): Delete la_class_name_from_physname initializer. * objc-lang.c (objc_language_data): Likewise. * opencl-lang.c (opencl_language_data): Likewise. * p-lang.c (pascal_language_data): Likewise. * rust-lang.c (rust_language_data): Likewise.
2020-06-10[gdb/symtab] Enable ada .gdb_indexTom de Vries2-7/+36
Currently the .gdb_index is not enabled for ada executables (PR24713). Fix this by adding the required support in write_psymbols, similar to how that is done for .debug_names in debug_names::insert. Tested on x86_64-linux, with native and target board cc-with-gdb-index. gdb/ChangeLog: 2020-06-10 Tom de Vries <tdevries@suse.de> PR ada/24713 * dwarf2/index-write.c (struct mapped_symtab): Add m_string_obstack. (write_psymbols): Enable .gdb_index for ada. * dwarf2/read.c: Remove comment stating .gdb_index is unsupported for ada. gdb/testsuite/ChangeLog: 2020-06-10 Tom de Vries <tdevries@suse.de> * gdb.ada/ptype_union.exp: Remove PR24713 workaround.
2020-06-10[gdb/symtab] Fix name lookup in dw2_map_matching_symbolsTom de Vries1-14/+47
In commit 9a0bacfb08 "[gdb/symtab] Handle .gdb_index in ada language mode", a missing part of dw2_map_matching_symbols was added, containing a call to dw2_expand_symtabs_matching_symbol. However, the callback passed to that call has one problem: the callback has an argument "offset_type namei", which is ignored. Instead, match_name is passed as argument to dw2_symtab_iter_init, where a name lookup is done, which may or may not yield the same value as namei. Fix this by creating a new version of dw2_symtab_iter_init that takes a "offset_type namei" argument instead of "const char *name", and passing namei. Tested on x86_64-linux, with native and target board cc-with-gdb-index. gdb/ChangeLog: 2020-06-10 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (dw2_symtab_iter_init_common): Factor out of ... (dw2_symtab_iter_init): ... here. Add variant with "offset_type namei" instead of "const char *name" argument. (dw2_map_matching_symbols): Use "offset_type namei" variant of dw2_symtab_iter_init.
2020-06-08gdb: remove TYPE_FIELD_TYPE macroSimon Marchi1-18/+16
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use `type::field` and `field::type` directly. gdb/ChangeLog: * gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites to use type::field and field::type instead. Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
2020-06-08gdb: remove FIELD_TYPE macroSimon Marchi1-3/+2
Remove the `FIELD_TYPE` macro, changing all the call sites to use `field::type` directly. gdb/ChangeLog: * gdbtypes.h (FIELD_TYPE): Remove. Change all call sites to use field::type instead. Change-Id: I7673fedaa276e485189c87991a9043495da22ef5
2020-06-08gdb: add field::type / field::set_typeSimon Marchi1-9/+9
Add the `type` and `set_type` methods on `struct field`, in order to remoremove the `FIELD_TYPE` macro. In this patch, the `FIELD_TYPE` macro is changed to use `field::type`, so all the call sites that are useused to set the field's type are changed to use `field::set_type`. The next patch will remove `FIELD_TYPE` completely. Note that because of the name clash between the existing field named `type` and the new method, I renamed the field `m_type`. It is not private per-se, because we can't make `struct field` a non-POD yet, but it should be considered private anyway (not accessed outside `struct field`). gdb/ChangeLog: * gdbtypes.h (struct field) <type, set_type>: New methods. Rename `type` field to... <m_type>: ... this. Change references throughout to use type or set_type methods. (FIELD_TYPE): Use field::type. Change call sites that modify the field's type to use field::set_type instead. Change-Id: Ie21f866e3b7f8a51ea49b722d07d272a724459a0
2020-06-04gdb: really share partial symtabs when using .gdb_index or .debug_namesSimon Marchi1-22/+34
Fix/follow-up to commit 17ee85fc2a ("Share DWARF partial symtabs"). In the non-index case, where GDB builds partial symbols from scratch, two objfiles around the same BFD correctly share partial symtabs. The first objfile, which has to do all the work, saves a reference to the created partial symtabs in the shared per_bfd object (at the end of dwarf2_build_psymtabs). The second objfile, when it reaches dwarf2_build_psymtabs, sees that there are already partial symtabs built for this BFD and just uses it. However, that commit missed implementing the same sharing for cases where GDB uses .gdb_index or .debug_names to build the partial symtabs. This patch fixes it by having the first objfile to use the BFD set per_bfd->partial_symtabs at the end of dwarf2_read_gdb_index / dwarf2_read_debug_names. For the subsequent objfiles using that BFD, the partial symtabs are then picked up in dwarf2_initialize_objfile. This patch adds a test that mimics how the issue was originally triggered: 1. Load the test file twice, such that the second objfile re-uses the per_bfd object created for the first objfile. 2. Run to some point where in the backtrace there is a frame for a function that's in a CU that's not yet read in. 3. Check that this frame's information is complete in the "backtrace" output. Step 2 requires an address -> symbol lookup which uses the addrmap at objfile->partial_symtabs->psymtabs_addrmap. If the objfile->partial_symtabs link is not properly setup (as is the case before this patch), the symbol for that frame won't be found and we'll get a frame with incomplete information. The test fails without the fix when using boards "cc-with-gdb-index" and "cc-with-debug-names". gdb/ChangeLog: * dwarf2/read.c (dwarf2_read_gdb_index): Save partial_symtabs in the per_bfd object. (dwarf2_read_debug_names): Likewise. (dwarf2_initialize_objfile): Use partial_symtabs from per_bfd object when re-using a per_bfd object with an index. gdb/testsuite/ChangeLog: * gdb.dwarf2/share-psymtabs-bt.exp: New file. * gdb.dwarf2/share-psymtabs-bt.c: New file. * gdb.dwarf2/share-psymtabs-bt-2.c: New file. Change-Id: Ibb26210e2dfc03b80ba9fa56b875ba4cc58c0352
generated by cgit v1.1 at 2025-03-07 19:37:00 +0000