aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-27Expand dynamic type documentationTom Tromey2-2/+25
This expands the Python dynamic type documentation, as suggested by Christian. gdb/doc/ChangeLog 2020-04-27 Tom Tromey <tromey@adacore.com> * python.texi (Types In Python): Mention missing fields. Add dynamic type example.
2020-04-27gdbsupport: include cstdlib in common-defs.hSimon Marchi2-0/+9
In PR 25731 [1], the following build failure was reported: ../../binutils-gdb/gdb/gdbtypes.c:1254:10: error: no member named 'abs' in namespace 'std'; did you mean simply 'abs'? = ((std::abs (stride) * element_count) + 7) / 8; ^~~~~~~~ abs /usr/include/stdlib.h:129:6: note: 'abs' declared here int abs(int) __pure2; ^ The original report was using: $ gcc -v Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin15.6.0 Note that I was _not_ able to reproduce using: $ g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin19.3.0 The proposed fix is to include <cstdlib> in addition to <stdlib.h>. Here's an excerpt of [2] relevant to this problem: These headers [speaking of the .h form] are allowed to also declare the same names in the std namespace, and the corresponding cxxx headers are allowed to also declare the same names in the global namespace: including <cstdlib> definitely provides std::malloc and may also provide ::malloc. Including <stdlib.h> definitely provides ::malloc and may also provide std::malloc Since we use std::abs, we should not assume that our include of stdlib.h declares an `abs` function in the `std` namespace. If we replace the include of stdlib.h with cstdlib, then we fall in the opposite situation. A standard C++ library may decide to only put the declarations in the std namespace, requiring us to prefix all standard functions with `std::`. I'm not against that, but for the moment I think the safest way forward is to just include both. Note that I don't know what effect this patch can have on any stdlib.h fix provided by gnulib. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25731 [2] https://en.cppreference.com/w/cpp/header#C_compatibility_headers gdbsupport/ChangeLog: * common-defs.h: Include cstdlib.h.
2020-04-27Fix remaining inline/tailcall unwinding breakage for x86_64Luis Machado4-3/+55
Commit 5939967b355ba6a940887d19847b7893a4506067 fixed inline frame unwinding breakage for some targets (aarch64, riscv, s390...) but regressed a few amd64 testcases related to tailcalls. Given the following example situation... Frame #-1 - sentinel frame Frame # 0 - inline frame Frame # 1 - normal frame ... suppose we're at level #1 and call into dwarf2_tailcall_sniffer_first. We'll attempt to fetch PC, which used to be done via the gdbarch_unwind_pc call (before 5939967b355ba6a940887d19847b7893a4506067), but now it is being handled by the get_frame_register function. gdbarch_unwind_pc will attempt to use frame #1's cache to retrieve information about the PC. Here's where different architectures behave differently. x86_64 will find a dwarf rule to retrieve PC from memory, at a CFA + offset location. So the PC value is readily available and there is no need to create a lazy value. For aarch64 (and others), GCC doesn't emit an explicit location for PC, so we eventually will find that PC is DWARF2_FRAME_REG_UNSPECIFIED. This is known and is handled by GDB by assuming GCC really meant DWARF2_FRAME_REG_SAME_VALUE. This means we'll attempt to fetch the register value from frame #0, via a call to frame_unwind_got_register, which will trigger the creation of a lazy value that requires a valid frame id for frame #0. We don't have a valid id for frame #0 yet, so we assert. Given the above, the following patch attempts to handle the situation without being too hacky. We verify if the next frame is an inline frame and if its frame id has been computed already. If it hasn't been computed yet, then we use the safer get_frame_register function, otherwise we use the regular gdbarch_unwind_pc hook. gdb/ChangeLog: 2020-04-27 Luis Machado <luis.machado@linaro.org> * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Handle problematic inline frame unwinding situation. * frame.c (frame_id_computed_p): New function. * frame.h (frame_id_computed_p): New prototype.
2020-04-27GAS: Allow automatically assigned entries in the file table to be reassigned ↵Nick Clifton2-51/+71
if the source file specifically requests to use the assigned slot. PR 25878 * dwarf2dbg.c (struct file_entry): Add auto_assigned field. (assign_file_to_slot): New function. Fills in an entry in the files table. (allocate_filenum): Use new function. (allocate_filename_to_slot): Use new function. If the specified slot entry is already in use, but was chosen automatically then reassign the automatic entry.
2020-04-27Automatic date update in version.inGDB Administrator1-1/+1
2020-04-26Remove class_pseudoTom Tromey2-1/+5
The class_pseudo constant is unused, so this removes it. Tested by rebuilding. gdb/ChangeLog 2020-04-26 Tom Tromey <tom@tromey.com> * command.h (enum command_class) <class_pseudo>: Remove.
2020-04-26readelf: NULL dereferenceAlan Modra2-30/+16
This fixes another missing error check. * readelf.c (get_num_dynamic_syms): Check DT_MIPS_XHASH was read before dereferencing, and gracefully return. Remove gnu_hash_error variable. Free gnu hash arrays if number of syms found is zero.
2020-04-26Fix comments and whitespace in lookup_cmd_compositionPhilippe Waroquiers2-29/+34
2020-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * cli/cli-decode.c (lookup_cmd_composition): Fix comments and whitespace.
2020-04-26Improve -mlfence-after-loadliuhongt21-40/+587
1.Implict load for POP/POPF/POPA/XLATB, no load for Anysize insns 2. Add -mlfence-before-ret=shl/yes, adjust operand size of or/not/shl according to ret's. 3. Issue warning for REP CMPS/SCAS since they would affect control flow behavior. 4. Adjust testcases and documents. gas/Changelog: * config/tc-i386.c (lfence_before_ret_shl): New member. (load_insn_p): implict load for POP/POPA/POPF/XLATB, no load for Anysize insns. (insert_after_load): Issue warning for REP CMPS/SCAS. (insert_before_before): Handle iret, Handle -mlfence-before-ret=shl, Adjust operand size of or/not/shl to ret's, (md_parse_option): Change -mlfence-before-ret=[none|not|or] to -mlfence-before-ret=[none/not/or/shl/yes]. Enable -mlfence-before-ret=shl when -mlfence-beofre-indirect-branch=all and no explict -mlfence-before-ret option. (md_show_usage): Ditto. * doc/c-i386.texi: Ditto. * testsuite/gas/i386/i386.exp: Add new testcases. * testsuite/gas/i386/lfence-load-b.d: New. * testsuite/gas/i386/lfence-load-b.e: New. * testsuite/gas/i386/lfence-load.d: Modified. * testsuite/gas/i386/lfence-load.e: New. * testsuite/gas/i386/lfence-load.s: Modified. * testsuite/gas/i386/lfence-ret-a.d: Modified. * testsuite/gas/i386/lfence-ret-b.d: Modified. * testsuite/gas/i386/lfence-ret-c.d: New. * testsuite/gas/i386/lfence-ret-d.d: New. * testsuite/gas/i386/lfence-ret.s: Modified. * testsuite/gas/i386/x86-64-lfence-load-b.d: New. * testsuite/gas/i386/x86-64-lfence-load.d: Modified. * testsuite/gas/i386/x86-64-lfence-load.s: Modified. * testsuite/gas/i386/x86-64-lfence-ret-a.d: Modified. * testsuite/gas/i386/x86-64-lfence-ret-b.d: Modified. * testsuite/gas/i386/x86-64-lfence-ret-c.d: New. * testsuite/gas/i386/x86-64-lfence-ret-d.d: New * testsuite/gas/i386/x86-64-lfence-ret-e.d: New. * testsuite/gas/i386/x86-64-lfence-ret.e: New. * testsuite/gas/i386/x86-64-lfence-ret.s: New.
2020-04-26Automatic date update in version.inGDB Administrator1-1/+1
2020-04-25Remove unused code block in inf_ptrace_target::waitKamil Rytarowski2-38/+5
Remove unused PT_GET_PROCESS_STATE block. It used to be used by OpenBSD, but it is now reimplemented independently in obsd-nat.c. gdb/ChangeLog: * inf-ptrace.c (inf_ptrace_target::wait): Remove `PT_GET_PROCESS_STATE' block. Change-Id: I9b872df8517b658c0dfe889fc1e4a7009bc5c076
2020-04-25[gdb/testsuite] Add target board debug-typesTom de Vries2-0/+45
This patch adds a target board debug-types that switches on -fdebug-types-section by default. This -fdebug-types-section option is a gcc option that enables the generation of a .debug_types section, which is only effective for DWARF version 4. There are two other boards that enable this: dwarf4-gdb-index and fisson, but while those test some meaningful combination of options, this board is intended to test only -fdebug-types-section. Current results with gcc 7.5.0 are: ... === gdb Summary === # of expected passes 75832 # of unexpected failures 2841 # of expected failures 130 # of known failures 75 # of unresolved testcases 22 # of untested testcases 37 # of unsupported tests 83 ... Related known issues: - PR gcc/90232 - "gcc drops top-level dies with -fdebug-types-section" - PR gdb/25875 - "segv in ada_discrete_type_low_bound" - PR gdb/14148 - "-fdebug-types-section regresses static scope of types" Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-25 Tom de Vries <tdevries@suse.de> * boards/debug-types.exp: New file.
2020-04-25gdb/testsuite: Remove build paths from test namesAndrew Burgess2-2/+8
Having paths in test names makes it harder to compare results from different builds of GDB. gdb/testsuite/ChangeLog: * gdb.btrace/multi-inferior.exp: Avoid paths in test names.
2020-04-25Automatic date update in version.inGDB Administrator1-1/+1
2020-04-24Remove symbol_get_demangled_nameTom Tromey3-21/+10
Now that symbol_get_demangled_name is only used by general_symbol_info methods, and because these methods already check the symbol's language to decide what to return, symbol_get_demangled_name is no longer needed. This patch removes it. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * symtab.h (symbol_get_demangled_name): Don't declare. * symtab.c (symbol_get_demangled_name): Remove. (general_symbol_info::natural_name) (general_symbol_info::demangled_name): Update.
2020-04-24Fix Rust test casesTom Tromey2-1/+7
PR rust/25025 notes that some Rust test cases fail. Debugging gdb revealed that the Rust compiler emits different linkage names that demangle to the same result. Enabling complaints when reading the test case is enough to show it: During symbol reading: Computed physname <generics::identity<f64>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17h8540b320af6656d6E>) - DIE at 0x424 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics] During symbol reading: Computed physname <generics::identity<u32>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17hae302fad0c33bd7dE>) - DIE at 0x459 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics] ... This patch changes the DWARF reader to prefer the computed physname, rather than the output of the demangler, for Rust. This fixes the bug. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> PR rust/25025: * dwarf2/read.c (dwarf2_physname): Do not demangle for Rust.
2020-04-24Use the linkage name if it existsTom Tromey8-17/+80
The DWARF reader has had some odd code since the "physname" patches landed. In particular, these patches caused PR symtab/12707; namely, they made it so "set print demangle off" no longer works. This patch attempts to fix the problem. It arranges to store the linkage name on the symbol if it exists, and it changes the DWARF reader so that the demangled name is no longer (usually) stored in the symbol's "linkage name" field. c-linkage-name.exp needed a tweak, because it started working correctly. This conforms to what I think ought to happen, so this seems like an improvement here. compile-object-load.c needed a small change to use symbol_matches_search_name rather than directly examining the linkage name. Looking directly at the name does the wrong thing for C++. There is still some name-related confusion in the DWARF reader: * "physname" often refers to the logical name and not what I would consider to be the "physical" name; * dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and return different strings -- but this seems like at least one name too many. For example, Fortran requires dwarf2_full_name, but other languages do not. * To my surprise, dwarf2_physname prefers the form emitted by the demangler over the one that it computes. This seems backward to me, given that the partial symbol reader prefers the opposite, and it seems to me that this choice may perform better as well. I didn't attempt to clean up these things. It would be good to do, but whenever I contemplate it I get caught up in dreams of truly rewriting the DWARF reader instead. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> PR symtab/12707: * dwarf2/read.c (add_partial_symbol): Use the linkage name if it exists. (new_symbol): Likewise. * compile/compile-object-load.c (get_out_value_type): Use symbol_matches_search_name. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> PR symtab/12707: * gdb.python/py-symbol.exp: Update expected results for linkage_name test. * gdb.cp/print-demangle.exp: New file. * gdb.base/c-linkage-name.exp: Fix test. * gdb.guile/scm-symbol.exp: Update expected results for linkage_name test.
2020-04-24Don't call compute_and_set_names for partial symbolsTom Tromey6-102/+75
As mentioned in another thread, there's currently no need to call compute_and_set_names for partial symbols. Because the DWARF partial symbol reader constructs demangled names, this call can only demangle a name by mistake. So, this patch changes the DWARF reader to simply set the linkage name on the new symbol. This is equivalent to what was done before. There should be no user-visible change from this patch, aside from gdb speeding up a bit. ... there *should* be, but this regressed dw2-namespaceless-anonymous.exp. However, upon examination, I think that test is incorrect. It puts a mangled name into DW_AT_name, and it puts the variable at the top level, not in a namespace. This isn't what C++ compilers ought to do. So, this patch also updates the test case. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * dwarf2/read.c (add_partial_symbol): Do not call compute_and_set_names. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * gdb.dwarf2/dw2-namespaceless-anonymous.S: Remove. * gdb.dwarf2/dw2-namespaceless-anonymous.c: New file. * gdb.dwarf2/dw2-namespaceless-anonymous.exp: Use DWARF assembler.
2020-04-24Use the new add_psymbol_to_list overloadTom Tromey2-64/+68
This changes the DWARF reader to use the new add_psymbol_to_list overload. There should be no visible changes due to this patch. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * dwarf2/read.c (add_partial_symbol): Use new add_psymbol_to_list overload.
2020-04-24Introduce new add_psymbol_to_list overloadTom Tromey3-24/+44
This adds a new overload of add_psymbol_to_list. This one takes an already constructed psymbol and adds it to the bcache and the appropriate list. This seemed cleaner than continuing to add parameters to the existing add_psymbol_to_list, and is more in line with how full symbols are constructed. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * psymtab.c (add_psymbol_to_bcache): Simplify calling convention. (add_psymbol_to_list): New overload. Make old overload call new one. * psympriv.h (add_psymbol_to_list): New overload.
2020-04-24Add attribute::value_as_string methodTom Tromey4-12/+34
The full DIE reader checks that an attribute has a "string" form in some spots, but the partial DIE reader does not. This patch brings the two readers in sync for one specific case, namely when examining the linkage name. This avoids regressions in an existing DWARF test case. A full fix for this problem would be preferable. An accessor like DW_STRING should always check the form. However, I haven't attempted that in this series. Also the fact that the partial and full readers can disagree like this is a design flaw. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * dwarf2/read.c (partial_die_info::read) <case DW_AT_linkage_name>: Use value_as_string. (dwarf2_string_attr): Use value_as_string. * dwarf2/attribute.h (struct attribute) <value_as_string>: Declare method. * dwarf2/attribute.c (attribute::value_as_string): New method.
2020-04-24Fix two latent Rust bugsTom Tromey2-0/+7
Two methods on general_symbol_info did not handle the language_rust case. I don't think these problems can be noticed with the current code (which is why the bugs went unnoticed), but a future patch will change this. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * symtab.c (general_symbol_info::natural_name) (general_symbol_info::demangled_name): Check for language_rust.
2020-04-24Move the rust "{" hackTom Tromey2-6/+17
The DWARF reader has a special case to work around a bug in some versions of the Rust compiler -- it ignores mangled names that contain a "{" character. I noticed that this check should probably be in dw2_linkage_name rather than only in dwarf2_physname. The former is called in some cases that the latter is not. Also, I noticed that this work is not done for the partial DIE reader, so this patch adds the check there as well. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * dwarf2/read.c (dw2_linkage_name): Move Rust "{" hack here... (dwarf2_physname): ... from here. (partial_die_info::read): Add Rust "{" hack.
2020-04-24Convert symbol_set_demangled_name to a methodTom Tromey5-25/+32
This changes symbol_set_demangled_name to be a method on general_symbol_info, and updates the users. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> * symtab.h (struct general_symbol_info) <set_demangled_name>: New method. (symbol_set_demangled_name): Don't declare. * symtab.c (general_symbol_info::set_demangled_name): Rename from symbol_set_demangled_name. (general_symbol_info::set_language) (general_symbol_info::compute_and_set_names): Update. * minsyms.c (minimal_symbol_reader::install): Update. * dwarf2/read.c (new_symbol): Update.
2020-04-24[gdb/testsuite] Fix language in dw2-bad-mips-linkage-name.expTom de Vries2-3/+8
The test-case gdb.dwarf2/dw2-bad-mips-linkage-name.exp has a CU with language C, which contains a subprogram with a C++-mangled name as its DW_AT_mips_linkage_name attribute. Fix this by changing the language of the CU to C++. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Set language of CU to C++.
2020-04-24Update test cases that work with minimal encodingsTom Tromey6-104/+221
Some test cases already work fine with minimal encodings (in some cases perhaps due to the variant parts series) This patch updates these tests as appropriate. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * gdb.ada/frame_arg_lang.exp: Run with multiple -fgnat-encodings values. * gdb.ada/funcall_ref.exp: Run with multiple -fgnat-encodings values. Update test for minimal encodings. * gdb.ada/lang_switch.exp: Update test for minimal encodings. * gdb.ada/var_rec_arr.exp: Run with multiple -fgnat-encodings values. Update test for minimal encodings.
2020-04-24Add Python support for dynamic typesTom Tromey8-4/+91
This changes the gdb Python API to add support for dynamic types. In particular, this adds an attribute to gdb.Type, and updates some attributes to reflect dynamic sizes and field offsets. There's still no way to get the dynamic type from one of its concrete instances. This could perhaps be added if needed. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * python/py-type.c (convert_field): Handle FIELD_LOC_KIND_DWARF_BLOCK. (typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH. (typy_get_dynamic): Nw function. (type_object_getset): Add "dynamic". * NEWS: Add entry. gdb/doc/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * python.texi (Types In Python): Document new features. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * gdb.ada/variant.exp: Add Python checks. * gdb.rust/simple.exp: Add dynamic type checks.
2020-04-24Add tests for Ada changesTom Tromey8-86/+276
The previous patches largely came without test cases. This was done to make the patches easier to review; as most of the patches were needed before existing tests could be updated. This patch adds a new test and updates some existing tests to test all the settings of -fgnat-encodings. This ensures that tests are run both with the old-style "magic symbol name" encoding, and the new-style DWARF encoding. Note that in one case, a test is modified to be more lax. See the comment in mi_var_array.exp. I didn't want to fix this in this series, as it's already complicated enough. However, I think it could be fixed; I will file a bug for it. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * gdb.ada/mi_var_array.exp: Try all -fgnat-encodings settings. Make array type matching more lax. * gdb.ada/mi_var_union.exp: Try all -fgnat-encodings settings. * gdb.ada/mi_variant.exp: New file. * gdb.ada/mi_variant/pck.ads: New file. * gdb.ada/mi_variant/pkg.adb: New file. * gdb.ada/packed_tagged.exp: Try all -fgnat-encodings settings. * gdb.ada/unchecked_union.exp: Try all -fgnat-encodings settings.
2020-04-24Update Ada ptype support for dynamic typesTom Tromey2-0/+135
The DWARF reader was updated to handle variant parts and some other selected features for Ada; but the Ada "ptype" code was not touched. This patch changes the Ada ptype code to handle the new types properly. Test cases for this and for some of the other code in this series are in a separate patch. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * ada-typeprint.c (print_choices, print_variant_part) (print_record_field_types_dynamic): New functions. (print_record_field_types): Use print_record_field_types_dynamic.
2020-04-24Add support for variable field offsetsTom Tromey8-45/+218
In Ada, a field can have a variable offset. This patch adds support for this case to gdb, using the existing dynamic type resolution code. Doing just this, though, would break C++ virtual base handling. It turns out that virtual base handling only worked by the ugliest of hacks. In particular, the DWARF reader would call decode_locdesc for a virtual base location. Here's an example of such an expression from gdb's m-static test case: <241> DW_AT_data_member_location: 6 byte block: 12 6 48 1c 6 22 (DW_OP_dup; DW_OP_deref; DW_OP_lit24; DW_OP_minus; DW_OP_deref; DW_OP_plus) When examining this, decode_locdesc would treat DW_OP_deref as a no-op and compute some answer (here, -24). This would be stored as the offset. Later, in gnu-v3-abi.c, the real offset would be computed by digging around in the vtable. This patch cleans up this area. In particular, it now evaluates the location expression on demand. Note there is a new FIXME in gnu-v3-abi.c. I think some of the callers are incorrect here, and have only worked because this member is unused. I will file a bug for this. I didn't fix this problem in this series because I felt it was already too complex. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (handle_data_member_location): New overload. (dwarf2_add_field): Use it. (decode_locdesc): Add "computed" parameter. Update comment. * gdbtypes.c (is_dynamic_type_internal): Also look for FIELD_LOC_KIND_DWARF_BLOCK. (resolve_dynamic_struct): Handle FIELD_LOC_KIND_DWARF_BLOCK. * gdbtypes.c (is_dynamic_type_internal): Add special case for C++ virtual base classes. * gnu-v3-abi.c (gnuv3_baseclass_offset): Handle FIELD_LOC_KIND_DWARF_BLOCK. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * gdb.ada/variant.exp: Add dynamic field offset tests. * gdb.ada/variant/pck.ads (Nested_And_Variable): New type. * gdb.ada/variant/pkg.adb: Add new variables.
2020-04-24Add support for dynamic type lengthsTom Tromey8-9/+156
In Ada, a type with variant parts can have a variable length. This patch adds support for this to gdb, by integrating the length computation into the dynamic type resolution code. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (read_structure_type): Handle dynamic length. * gdbtypes.c (is_dynamic_type_internal): Check TYPE_HAS_DYNAMIC_LENGTH. (resolve_dynamic_type_internal): Use TYPE_DYNAMIC_LENGTH. * gdbtypes.h (TYPE_HAS_DYNAMIC_LENGTH, TYPE_DYNAMIC_LENGTH): New macros. (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_SIZE>: New constant. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * gdb.ada/variant.exp: New file * gdb.ada/variant/pkg.adb: New file * gdb.ada/variant/pck.adb: New file
2020-04-24Rewrite the existing variant part codeTom Tromey6-415/+558
This rewrites the existing variant part code to follow the new model implemented in the previous patch. The old variant part code is removed. This only affects Rust for the moment. I tested this using various version of the Rust compiler, including one that emits old-style enum debuginfo, exercising the quirks code. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (struct variant_field): Rewrite. (struct variant_part_builder): New. (struct nextfield): Remove "variant" field. Add "offset". (struct field_info): Add "current_variant_part" and "variant_parts". (alloc_discriminant_info): Remove. (alloc_rust_variant): New function. (quirk_rust_enum): Update. (dwarf2_add_field): Set "offset" member. Don't handle DW_TAG_variant_part. (offset_map_type): New typedef. (convert_variant_range, create_one_variant) (create_one_variant_part, create_variant_parts) (add_variant_property): New functions. (dwarf2_attach_fields_to_type): Call add_variant_property. (read_structure_type): Don't handle DW_TAG_variant_part. (handle_variant_part, handle_variant): New functions. (handle_struct_member_die): Use them. (process_structure_scope): Don't handle variant parts. * gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): Remove. (struct discriminant_info): Remove. (enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: Remove. (struct main_type) <flag_discriminated_union>: Remove. * rust-lang.c (rust_enum_p, rust_empty_enum_p): Rewrite. (rust_enum_variant): Return int. Remove "contents". Rewrite. (rust_print_enum, rust_print_struct_def, rust_evaluate_subexp): Update. * valops.c (value_union_variant): Remove. * value.h (value_union_variant): Don't declare.
2020-04-24Prefer existing data when evaluating DWARF expressionTom Tromey10-34/+104
When evaluating a DWARF expression, the dynamic type resolution code will pass in a buffer of bytes via the property_addr_info. However, the DWARF expression evaluator will then proceed to read memory from the inferior, even when the request could be filled from this buffer. This, in turn, is a problem in some cases; and specifically when trying to handle the Ada scenario of extracting a variable-length value from a packed array. Here, the ordinary DWARF expression cannot be directly evaluated, because the data may appear at some arbitrary bit offset. So, it is unpacked into a staging area and then the expression is evaluated -- using an address of 0. This patch fixes the problem by arranging for the DWARF evaluator, in this case, to prefer passed-in memory when possible. The type of the buffer in the property_addr_info is changed to an array_view so that bounds checking can be done. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_discrete_type_high_bound, ada_discrete_type_low) (ada_value_primitive_packed_val): Update. * ada-valprint.c (ada_value_print_1): Update. * dwarf2/loc.c (evaluate_for_locexpr_baton): New struct. (dwarf2_locexpr_baton_eval): Take a property_addr_info rather than just an address. Use evaluate_for_locexpr_baton. (dwarf2_evaluate_property): Update. * dwarf2/loc.h (struct property_addr_info) <valaddr>: Now an array_view. * findvar.c (default_read_var_value): Update. * gdbtypes.c (compute_variant_fields_inner) (resolve_dynamic_type_internal): Update. (resolve_dynamic_type): Change type of valaddr parameter. * gdbtypes.h (resolve_dynamic_type): Update. * valarith.c (value_subscripted_rvalue): Update. * value.c (value_from_contents_and_address): Update.
2020-04-24Allow DWARF expression to push the initial addressTom Tromey3-6/+24
Some DWARF expressions must be evaluated by first pushing the object address onto the evaluation stack. This patch adds this ability. This functionality is not used yet, but it will be used in a later patch. This is split out for easier review and also because it improved the patch series ordering. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add "push_initial_value" parameter. (dwarf2_evaluate_property): Likewise. * dwarf2/loc.h (dwarf2_evaluate_property): Update.
2020-04-24Add new variant part codeTom Tromey5-28/+338
This patch adds the infrastructure for the new variant part code. At this point, nothing uses this code. This is done in a separate patch to make it simpler to review. I examined a few possible approaches to handling variant parts. In particular, I considered having a DWARF variant part be a union (similar to how the Rust code works now); and I considered having type fields have a flag indicating that they are variants. Having separate types seemed bad conceptually, because these variants aren't truly separate -- they rely on the "parent" type. And, changing how fields worked seemed excessively invasive. So, in the end I thought the approach taken in this patch was both simple to implement and understand, without losing generality. The idea in this patch is that all the fields of a type with variant parts will be stored in a single field array, just as if they'd all been listed directly. Then, the variants are attached as a dynamic property. These control which fields end up in the type that's constructed during dynamic type resolution. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * gdbtypes.c (is_dynamic_type_internal): Check for variant parts. (variant::matches, compute_variant_fields_recurse) (compute_variant_fields_inner, compute_variant_fields): New functions. (resolve_dynamic_struct): Check for DYN_PROP_VARIANT_PARTS. Use resolved_type after type is made. (operator==): Add new cases. * gdbtypes.h (TYPE_HAS_VARIANT_PARTS): New macro. (struct discriminant_range, struct variant, struct variant_part): New. (union dynamic_prop_data) <variant_parts, original_type>: New members. (enum dynamic_prop_node_kind) <DYN_PROP_VARIANT_PARTS>: New constant. (enum dynamic_prop_kind) <PROP_TYPE, PROP_VARIANT_PARTS>: New constants. * value.c (unpack_bits_as_long): Now public. * value.h (unpack_bits_as_long): Declare.
2020-04-24Rename "variant" to "ppc_variant"Tom Tromey2-5/+10
I wanted to use the name "variant" to represent a DWARF variant, but it turned out there was an existing structure of that name. This renames the existing variant to "ppc_variant". gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * rs6000-tdep.c (struct ppc_variant): Rename from "variant". (variants, find_variant_by_arch, rs6000_gdbarch_init): Update.
2020-04-24Add WOW64 exception numbers to $_siginfo.ExceptionCode enumHannes Domani2-0/+6
gdb/ChangeLog: 2020-04-24 Hannes Domani <ssbssa@yahoo.de> * windows-tdep.c (exception_values): Add WOW64 exception numbers.
2020-04-24Move OpenBSD-only functions from inf-ptrace to obsd-natKamil Rytarowski5-81/+90
All major BSDs implement PT_GET_PROCESS_STATE, but they differ in details and want to implement follow-fork functionality differently. gdb/ChangeLog: * inf-ptrace.h (follow_fork, insert_fork_catchpoint) (remove_fork_catchpoint, post_startup_inferior) (post_attach): Move... * obsd-nat.h (follow_fork, insert_fork_catchpoint) (remove_fork_catchpoint, post_startup_inferior) (post_attach): ...here. * inf-ptrace.c (follow_fork, insert_fork_catchpoint) (remove_fork_catchpoint, post_startup_inferior) (post_attach): Move... * obsd-nat.c (follow_fork, insert_fork_catchpoint) (remove_fork_catchpoint, post_startup_inferior) (post_attach): ...here.
2020-04-24[gdb/testsuite] Reset errcnt in clean_restartTom de Vries2-2/+10
When running test-case gdb.base/readnever.exp without commit 96038148d0e "[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we run into an error: ... ERROR: (eof) GDB never initialized. testcase gdb/testsuite/gdb.base/readnever.exp completed in 0 seconds ... If we additionally run test-case gdb.base/realname-expand.exp, we get an unresolved for the first test: ... UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on ... Using -v we find out that the UNRESOLVED is due the error triggered in the previous test-case: ... (gdb) set basenames-may-differ on^M (gdb) Error/Warning threshold exceeded: 1 0 (max. 1 3) UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on ... So, the error count of one test spills into the next test, even though we do a clean restart. That seems like a bad idea. Fix this by resetting errcnt (as well as warncnt) in clean_restart, such that we have: ... Running src/gdb/testsuite/gdb.base/readnever.exp ... ERROR: (eof) GDB never initialized. Running src/gdb/testsuite/gdb.base/realname-expand.exp ... PASS: gdb.base/realname-expand.exp: set basenames-may-differ on ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (clean_restart): Reset errcnt and warncnt.
2020-04-24Fix Windows debugging regressionTom Tromey3-1/+23
The updated pending stop series introduced a regression in Windows debugging. When stopped at a software breakpoint, we would adjust the PC each time it was requested -- however, more than a single adjustment is incorrect. This patch introduces a new flag that is used to ensure the adjustment only happens a single time. No similar change is needed in gdbserver, because it adjusts the PC in a different way. I still can't run the gdb test suite on Windows, but I can run the internal AdaCore test suite there; and this fixes the regressions there. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> * nat/windows-nat.h (struct windows_thread_info) <pc_adjusted>: New member. * windows-nat.c (windows_fetch_one_register): Check pc_adjusted. (windows_nat_target::get_windows_debug_event) (windows_nat_target::wait): Set pc_adjusted.
2020-04-24[gdb/testsuite] Compile dwzbuildid-mismatch more quietlyTom de Vries2-1/+6
When running test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index, we have: ... Running src/gdb/testsuite/gdb.dwarf2/dwzbuildid.exp ... gdb compile failed, warning: File "dwzbuildid5.o" has a different \ build-id, file skipped could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch warning: File "dwzbuildid5.o" has a different build-id, file skipped Error while writing index for `dwzbuildid-mismatch': could not find \ '.gnu_debugaltlink' file for dwzbuildid-mismatch ... and likewise for target board cc-with-debug-names. These are gdb-add-index warnings and errors due to the executable dwzbuildid-mismatch having a build-id mismatch. Be less verbose by adding "quiet" to the compile flags. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dwzbuildid.exp: Add quiet to dwzbuildid-mismatch compile flags.
2020-04-24[gdb/testsuite] Compile gdb.dwarf2/dw2-error.exp quietlyTom de Vries2-1/+5
When running test-case gdb.dwarf2/dw2-error.exp with target board cc-with-gdb-index, we get: ... Running src/gdb/testsuite/gdb.dwarf2/dw2-error.exp ... gdb compile failed, Dwarf Error: wrong version in compilation unit header \ (is 153, should be 2, 3, 4 or 5) [in module \ build/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/.tmp/dw2-error] ... and similar for target board cc-with-debug-names. Be less verbose by adding "quiet" to the compile flags. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-error.exp: Add quiet to compile flags.
2020-04-24[gdb/testsuite] Reduce errors after gdb exit in default_gdb_startTom de Vries3-2/+32
When running test-case gdb.base/readnever.exp with target board readnow, and without commit 96038148d0e "[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we run into a bunch of errors, starting with: ... spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \ --readnever^M gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M ERROR: : spawn id exp9 not open while executing "expect { -i exp9 -timeout 10 -re "$gdb_prompt $" { verbose "Setting height to 0." 2 } ... The illegal combination of --readnow and --readnever causes gdb to start, print an error message and exit. There's a gdb_expect in default_gdb_start that is supposed to detect the initial gdb prompt and handle related problems, but since there's no eof case it succeeds, and default_gdb_start continues as if the gdb prompt had been detected, causing the error above. Fix this by adding an eof case to the gdb_expect, such that we have the more accurate: ... ERROR: (eof) GDB never initialized. ... Further errors are triggered in clean_restart, because we're not testing for gdb_start success. Fix this by detecting gdb_start failure, and bailing out. Finally, we're running into further errors in gdb.base/readnever.exp because we're not testing for clean_restart success. Fix this by making clean_restart return -1 upon error, and testing for this. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (default_gdb_start): Handle eof. (clean_restart): Detect and handle gdb_start failure. Return -1 upon failure. * gdb.base/readnever.exp: Handle clean_restart failure.
2020-04-24[gdb/contrib] Use temp dir for gdb-add-index in cc-with-tweaks.shTom de Vries2-9/+10
When running test-case gdb.dwarf2/gdb-index.exp cleanly by issuing this command: ... $ rm -Rf build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index ... before running, it passes both with native and target board cc-with-gdb-index. But when we run the test-case first with native and then with cc-with-gdb-index without intermediate cleanup, we get instead: ... Running src/gdb/testsuite/gdb.dwarf2/gdb-index.exp ... gdb compile failed, cc-with-tweaks.sh: Index file \ build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index \ exists, won't clobber. === gdb Summary === # of untested testcases 1 ... What happens is that the native run produces a file build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index, which causes gdb/contrib/cc-with-tweaks.sh to hit this code: ... index_file="${output_file}.gdb-index" if [ "$want_index" = true ] && [ -f "$index_file" ] then echo "$myname: Index file $index_file exists, won't clobber." >&2 exit 1 fi ... The gdb-add-index script has a problem that it uses temp files alongside the executable, filed as PR25843. The code in cc-with-tweaks.sh attempts to detect the case that creating such a temp file would overwrite an pre-existing file. It however does this only for a single file, while gdb-add-index uses more temporary files: - <exec>.gdb-index - <exec>.debug_names - <exec>.debug_str - <exec>.debug_str.merge - <exec>.debug_str.err Fix this by working around PR25843 in a more generic way: - move the executable into a temp directory - execute gdb-add-index, allowing it to create any temp file alongside the executable in the temp directory - move the executable back to the original location Tested on x86_64-linux, with target board cc-with-debug-index. gdb/ChangeLog: 2020-04-24 Tom de Vries <tdevries@suse.de> * contrib/cc-with-tweaks.sh: Remove <exec>.gdb-index file handling. Run gdb-add-index inside temp dir.
2020-04-24readelf: memory leaks in process_dynamic_sectionAlan Modra2-66/+82
This fixes some code that assumed only one PT_LOAD would contain DT_SYMTAB. Which is normally the case, but fuzzers thoroughly mess with object files. * readelf.c (get_num_dynamic_syms): Check for nbuckets and nchains non-zero. (process_dynamic_section): Call get_num_dynamic_syms once rather than in segment loop. Break out of segment loop on a successful load of dynamic symbols. Formatting. (process_object): Return error status from process_dynamic_section.
2020-04-24Automatic date update in version.inGDB Administrator1-1/+1
2020-04-23Fix infinite loop in is_linked_with_cygwin_dllTom Tromey2-8/+14
There were some Windows timeouts after the last merge. Debugging showed that these were caused by an infinite loop in is_linked_with_cygwin_dll when reading C:\Windows\SysWOW64\win32u.dll. This patch fixes the problem by ensuring that the loop always makes progress. gdb/ChangeLog 2020-04-23 Tom Tromey <tromey@adacore.com> * windows-tdep.c (is_linked_with_cygwin_dll): Always update "iter" in loop.
2020-04-23Fix inline frame unwinding breakageLuis Machado2-1/+8
There has been some breakage for aarch64-linux, arm-linux and s390-linux in terms of inline frame unwinding. There may be other targets, but these are the ones i'm aware of. The following testcases started to show numerous failures and trigger internal errors in GDB after commit 1009d92fc621bc4d017029b90a5bfab16e17fde5, "Find tailcall frames before inline frames". gdb.opt/inline-break.exp gdb.opt/inline-cmds.exp gdb.python/py-frame-inline.exp gdb.reverse/insn-reverse.exp The internal errors were of this kind: binutils-gdb/gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed. After a lengthy investigation to try and find the cause of these assertions, it seems we're dealing with some fragile/poorly documented code to handle inline frames and we are attempting to unwind from this fragile section of code. Before commit 1009d92fc621bc4d017029b90a5bfab16e17fde5, the tailcall sniffer was invoked from dwarf2_frame_prev_register. By the time we invoke the dwarf2_frame_prev_register function, we've probably already calculated the frame id (via compute_frame_id). After said commit, the call to dwarf2_tailcall_sniffer_first was moved to dwarf2_frame_cache. This is very early in a frame creation process, and we're still calculating the frame ID (so compute_frame_id is in the call stack). This would be fine for regular frames, but the above testcases all deal with some inline frames. The particularity of inline frames is that their frame ID's depend on the previous frame's ID, and the previous frame's ID relies in the inline frame's registers. So it is a bit of a messy situation. We have comments in various parts of the code warning about some of these particularities. In the case of dwarf2_tailcall_sniffer_first, we attempt to unwind the PC, which goes through various functions until we eventually invoke frame_unwind_got_register. This function will eventually attempt to create a lazy value for a particular register, and this lazy value will require a valid frame ID. Since the inline frame doesn't have a valid frame ID yet (remember we're still calculating the previous frame's ID so we can tell what the inline frame ID is) we will call compute_frame_id for the inline frame (level 0). We'll eventually hit the assertion above, inside get_frame_id: -- /* If we haven't computed the frame id yet, then it must be that this is the current frame. Compute it now, and stash the result. The IDs of other frames are computed as soon as they're created, in order to detect cycles. See get_prev_frame_if_no_cycle. */ gdb_assert (fi->level == 0); -- It seems to me we shouldn't have reached this assertion without having the inline frame ID already calculated. In fact, it seems we even start recursing a bit when we invoke get_prev_frame_always within inline_frame_this_id. But a check makes us quit the recursion and proceed to compute the id. Here's the call stack for context: #0 get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2109 RECURSION - #1 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124 #2 0x0000aaaaaae95768 in inline_frame_this_id (this_frame=0xaaaaab85a670, this_cache=0xaaaaab85a688, this_id=0xaaaaab85a6d0) at ../../../repos/binutils-gdb/gdb/inline-frame.c:165 #3 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:550 #4 0x0000aaaaaae19318 in get_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:582 #5 0x0000aaaaaae13480 in value_of_register_lazy (frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/findvar.c:296 #6 0x0000aaaaaae16c00 in frame_unwind_got_register (frame=0xaaaaab85a730, regnum=30, new_regnum=30) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:268 #7 0x0000aaaaaad52604 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=30) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1296 #8 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1229 #9 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1320 #10 0x0000aaaaaab76574 in aarch64_dwarf2_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32) at ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:1114 #11 0x0000aaaaaad52724 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1316 #12 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1229 #13 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1320 #14 0x0000aaaaaae16a84 in default_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:223 #15 0x0000aaaaaae32124 in gdbarch_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/gdbarch.c:3074 #16 0x0000aaaaaad4f15c in dwarf2_tailcall_sniffer_first (this_frame=0xaaaaab85a730, tailcall_cachep=0xaaaaab85a830, entry_cfa_sp_offsetp=0x0) at ../../../repos/binutils-gdb/gdb/dwarf2/frame-tailcall.c:388 #17 0x0000aaaaaad520c0 in dwarf2_frame_cache (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1190 #18 0x0000aaaaaad52204 in dwarf2_frame_this_id (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, this_id=0xaaaaab85a790) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1218 #19 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame.c:550 #20 0x0000aaaaaae1c958 in get_prev_frame_if_no_cycle (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:1927 #21 0x0000aaaaaae1cc44 in get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2006 FIRST CALL - #22 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124 #23 0x0000aaaaaae18f68 in skip_artificial_frames (frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:495 #24 0x0000aaaaaae193e8 in get_stack_frame_id (next_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:596 #25 0x0000aaaaaae87a54 in process_event_stop_test (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6857 #26 0x0000aaaaaae86bdc in handle_signal_stop (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6381 #27 0x0000aaaaaae84fd0 in handle_inferior_event (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:5578 #28 0x0000aaaaaae81588 in fetch_inferior_event (client_data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:4020 #29 0x0000aaaaaae5f7fc in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../../repos/binutils-gdb/gdb/inf-loop.c:43 #30 0x0000aaaaaae8d768 in infrun_async_inferior_event_handler (data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:9377 #31 0x0000aaaaaabff970 in check_async_event_handlers () at ../../../repos/binutils-gdb/gdb/async-event.c:291 #32 0x0000aaaaab27cbec in gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:194 #33 0x0000aaaaaaef1894 in start_event_loop () at ../../../repos/binutils-gdb/gdb/main.c:356 #34 0x0000aaaaaaef1a04 in captured_command_loop () at ../../../repos/binutils-gdb/gdb/main.c:416 #35 0x0000aaaaaaef3338 in captured_main (data=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1254 #36 0x0000aaaaaaef33a0 in gdb_main (args=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1269 #37 0x0000aaaaaab6e0dc in main (argc=6, argv=0xfffffffff348) at ../../../repos/binutils-gdb/gdb/gdb.c:32 The following patch addresses this by using a function that unwinds the PC from the next (inline) frame directly as opposed to creating a lazy value that is bound to the next frame's ID (still not computed). gdb/ChangeLog: 2020-04-23 Luis Machado <luis.machado@linaro.org> * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Use get_frame_register instead of gdbarch_unwind_pc.
2020-04-23[gdb/symtab] Prefer def over decl (inter-CU case, with context)Tom de Vries4-5/+26
This is a follow-up patch on "[PATCH][gdb/symtab] Prefer def over decl (inter-CU case)" ( https://sourceware.org/pipermail/gdb-patches/2020-April/167489.html ). Consider the test-case from that patch. It contains a decl and def of var a in different CUs, and tests whether var a can be printed using the def, even if the decl is found first. However, the test-case does this in a contextless environment, so if we add to the test-case like this to set the context to the CU containing main: ... gdb_test "p a" { = \{1, 2\}} + +if ![runto_main] then { + fail "can't run to main" + return 0 +} + +gdb_test "p a" { = \{1, 2\}} ... then the second test fails, because the decl is found in the context. Fix this by preferring defs over decls in lookup_global_symbol. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-04-23 Tom de Vries <tdevries@suse.de> * symtab.c (lookup_global_symbol): Prefer def over decl. gdb/testsuite/ChangeLog: 2020-04-23 Tom de Vries <tdevries@suse.de> * gdb.base/decl-before-def.exp: Run to main and print a again.
2020-04-23[gdb/symtab] Prefer def over decl (inter-CU case)Tom de Vries8-12/+124
When running test-case gdb.threads/tls.exp with target board -readnow, we have: ... (gdb) print a_thread_local^M Cannot find thread-local storage for process 0, executable file tls/tls:^M Cannot find thread-local variables on this target^M (gdb) FAIL: gdb.threads/tls.exp: print a_thread_local ... while with native we have: ... (gdb) print a_thread_local^M Cannot read `a_thread_local' without registers^M (gdb) PASS: gdb.threads/tls.exp: print a_thread_local ... The difference in behaviour can be explained as follows. Without -readnow, we have two a_thread_locals, the def and the decl, each in a different CU: ... $ gdb -batch outputs/gdb.threads/tls/tls \ -ex "maint expand-symtabs" \ -ex "print a_thread_local" \ -ex "maint print symbols" \ | grep "a_thread_local;" Cannot read `a_thread_local' without registers int a_thread_local; computed at runtime int a_thread_local; unresolved ... and with -readnow, we have the opposite order: ... $ gdb -readnow -batch outputs/gdb.threads/tls/tls \ -ex "maint expand-symtabs" \ -ex "print a_thread_local" \ -ex "maint print symbols" \ | grep "a_thread_local;" Cannot find thread-local storage for process 0, executable file tls/tls: Cannot find thread-local variables on this target int a_thread_local; unresolved int a_thread_local; computed at runtime ... Fix the FAIL by preferring the def over the decl (something we already do intra-CU since the fix for PR24971, commit 93e55f0a03 "[gdb/symtab] Prefer var def over decl"). Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-04-23 Tom de Vries <tdevries@suse.de> PR symtab/25807 * block.c (best_symbol, better_symbol): Promote to external. * block.h (best_symbol, better_symbol): Declare. * symtab.c (lookup_symbol_in_objfile_symtabs): Prefer def over decl. gdb/testsuite/ChangeLog: 2020-04-23 Tom de Vries <tdevries@suse.de> * gdb.base/decl-before-def-decl.c: New test. * gdb.base/decl-before-def-def.c: New test. * gdb.base/decl-before-def.exp: New file.
generated by cgit v1.1 at 2025-09-26 18:41:38 +0000