aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-29For DWARF v5 Dwarf Package Files (.dwp files), the section identifier ↵Caroline Tice2-12/+34
encodings have changed. This patch updates dwarf2.h to contain the new encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5). * dwarf2.h (enum dwarf_sect_v5): A new enum section for the sections in a DWARF 5 DWP file (DWP version 5).
2020-07-29Don't segfault on discarded section dynsymsAlan Modra2-1/+9
We get lots of errors before we get to this code, but let's not segfault. * elflink.c (bfd_elf_final_link): Don't segfault on local dynsyms defined in excluded sections.
2020-07-29Don't assert at ldwrite.c:212Alan Modra2-0/+6
When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP set, we need to set SEC_EXCLUDE here to avoid a problem later. * ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for discarded sections.
2020-07-29[tdep/s390] Fix Wmaybe-uninitialized in s390_displaced_step_fixupTom de Vries2-2/+8
When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see: ... src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \ displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)': src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \ function [-Wmaybe-uninitialized] 528 | if (insn[0] == op_basr && r2 == 0) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ ... The problem is that the compiler is unaware that 'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr': ... if (is_rr (insn, op_basr, &r1, &r2) || is_rx (insn, op_bas, &r1, &d2, &x2, &b2)) { /* Recompute saved return address in R1. */ regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1, amode | (from + insnlen)); /* Update PC iff the instruction doesn't actually branch. */ if (insn[0] == op_basr && r2 == 0) regcache_write_pc (regs, from + insnlen); } ... Fix this by storing the result of the call, and using it instead of 'insn[0] ==op_basr'. Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux. gdb/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> PR tdep/26280 * s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.
2020-07-29[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robustTom de Vries2-2/+7
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to problems in the prologue analyzer (filed as PR26310). Make the test-case more robust by avoiding to use the prologue analyzer: ... -gdb_breakpoint "bar1" +gdb_breakpoint "$srcfile:27" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines rather than function name.
2020-07-29Automatic date update in version.inGDB Administrator1-1/+1
2020-07-28Demangle function names when disassemblingAndrew Burgess7-11/+160
Andrew Burgess pointed out a regression, which he described in PR symtab/26270: ================ After commit: commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad) Date: Fri Apr 24 15:35:01 2020 -0600 Use the linkage name if it exists The disassembler no longer demangles function names in its output. So we see things like this: (gdb) disassemble tree_insert Dump of assembler code for function _Z11tree_insertP4nodei: .... Instead of this: (gdb) disassemble tree_insert Dump of assembler code for function tree_insert(node*, int): .... This is because find_pc_partial_function now returns the linkage name rather than the demangled name. ================ This patch fixes the problem by introducing a new "overload" of find_pc_partial_function, which returns the general_symbol_info rather than simply the name. This lets the disassemble command choose which name to show. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> PR symtab/26270: * symtab.h (find_pc_partial_function_sym): Declare. * cli/cli-cmds.c (disassemble_command): Use find_pc_partial_function_sym. Check asm_demangle. * blockframe.c (cache_pc_function_sym): New global. (cache_pc_function_name): Remove. (clear_pc_function_cache): Update. (find_pc_partial_function_sym): New function, from find_pc_partial_function. (find_pc_partial_function): Rewrite using find_pc_partial_function_sym. gdb/testsuite/ChangeLog 2020-07-28 Andrew Burgess <andrew.burgess@embecosm.com> PR symtab/26270: * gdb.cp/disasm-func-name.cc: New file. * gdb.cp/disasm-func-name.exp: New file.
2020-07-28Update "disassemble" helpTom Tromey2-5/+10
Pedro pointed out that disassemble/m should be documented after disassemble/s, because /m is deprecated. This patch does so, and adds a usage line. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * cli/cli-cmds.c (_initialize_cli_cmds): Rearrange "disassemble" help. Add usage.
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey4-1/+14
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-28Implement xfer_partial TARGET_OBJECT_SIGNAL_INFO for NetBSDKamil Rytarowski4-0/+217
NetBSD implements reading and overwriting siginfo_t received by the tracee. With TARGET_OBJECT_SIGNAL_INFO signal information can be examined and modified through the special variable $_siginfo. Implement the "get_siginfo_type" gdbarch method for NetBSD architectures. As with Linux architectures, cache the created type in the gdbarch when it is first created. Currently NetBSD uses an identical siginfo type on all architectures, so there is no support for architecture-specific fields. gdb/ChangeLog: * nbsd-nat.h (nbsd_nat_target::xfer_partial): New declaration. * nbsd-nat.c (nbsd_nat_target::xfer_partial): New function. * nbsd-tdep.c (nbsd_gdbarch_data_handle, struct nbsd_gdbarch_data) (init_nbsd_gdbarch_data, get_nbsd_gdbarch_data) (nbsd_get_siginfo_type): New. (nbsd_init_abi): Install gdbarch "get_siginfo_type" method. (_initialize_nbsd_tdep): New
2020-07-28PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu6-16/+38
There is no need to check $pkg_cv_[]$1[]_LIBS works if package check failed. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if $pkg_failed = no. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28[gdb/build] Fix Wmaybe-uninitialized in gdb_optional.hTom de Vries2-0/+8
When building with CFLAGS/CXXFLAGS="-O2 -g -Wall", we run into: ... In file included from src/gdb/exceptions.h:23, from src/gdb/utils.h:24, from src/gdb/defs.h:630, from src/gdb/record-btrace.c:22: src/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, \ const btrace_thread_info*, const btrace_insn_iterator*, \ const btrace_insn_iterator*, gdb_disassembly_flags)': src/gdb/ui-out.h:352:18: warning: \ 'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' may be used \ uninitialized in this function [-Wmaybe-uninitialized] 352 | m_uiout->end (Type); | ~~~~~~~~~~~~~^~~~~~ src/gdb/record-btrace.c:795:35: note: \ 'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' was declared here 795 | gdb::optional<ui_out_emit_list> asm_list; | ^~~~~~~~ ... This is reported as PR gcc/80635 - "[8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning". Silence the warning by using the workaround suggested here ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c53 ): ... union { struct { } m_dummy; T m_item; + volatile char dont_use; // Silences -Wmaybe-uninitialized warning. }; ... Build on x86_64-linux. gdbsupport/ChangeLog: 2020-07-28 Tom de Vries <tdevries@suse.de> PR build/26281 * gdb_optional.h (class optional): Add volatile member to union contaning m_dummy and m_item.
2020-07-28PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu7-2/+71
It is quite normal to have headers without library on multilib OSes. Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS works. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if $pkg_cv_[]$1[]_LIBS works. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)H.J. Lu7-3/+92
Since (%bp)/(%ebp)/(%rbp) are encoded as 0(%bp)/0(%ebp)/0(%rbp), use disp32/disp16 on 0(%bp)/0(%ebp)/0(%rbp) for {disp32}. Note: Since there is no disp32 on 0(%bp), use disp16 instead. PR gas/26305 * config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on (%bp)/(%ebp)/(%rbp) for {disp32}. * doc/c-i386.texi: Update {disp32} documentation. * testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests. * testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests. * testsuite/gas/i386/pseudos.d: Updated. * testsuite/gas/i386/x86-64-pseudos.d: Likewise.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess9-57/+153
This commit unifies all of the Python register lookup code (used by Frame.read_register, PendingFrame.read_register, and gdb.UnwindInfo.add_saved_register), and adds support for using a gdb.RegisterDescriptor for register lookup. Currently the register unwind code (PendingFrame and UnwindInfo) allow registers to be looked up either by name, or by GDB's internal number. I suspect the number was added for performance reasons, when unwinding we don't want to repeatedly map from name to number for every unwind. However, this kind-of sucks, it means Python scripts could include GDB's internal register numbers, and if we ever change this numbering in the future users scripts will break in unexpected ways. Meanwhile, the Frame.read_register method only supports accessing registers using a string, the register name. This commit unifies all of the register to register-number lookup code in our Python bindings, and adds a third choice into the mix, the use of gdb.RegisterDescriptor. The register descriptors can be looked up by name, but once looked up, they contain GDB's register number, and so provide all of the performance benefits of using a register number directly. However, as they are looked up by name we are no longer tightly binding the Python API to GDB's internal numbering scheme. As we may already have scripts in the wild that are using the register numbers directly I have kept support for this in the API, but I have listed this method last in the manual, and I have tried to stress that this is NOT a good method to use and that users should use either a string or register descriptor approach. After this commit all existing Python code should function as before, but users now have new options for how to identify registers. gdb/ChangeLog: * python/py-frame.c: Remove 'user-regs.h' include. (frapy_read_register): Rewrite to make use of gdbpy_parse_register_id. * python/py-registers.c (gdbpy_parse_register_id): New function, moved here from python/py-unwind.c. Updated the return type, and also accepts register descriptor objects. * python/py-unwind.c: Remove 'user-regs.h' include. (pyuw_parse_register_id): Moved to python/py-registers.c. (unwind_infopy_add_saved_register): Update to use gdbpy_parse_register_id. (pending_framepy_read_register): Likewise. * python/python-internal.h (gdbpy_parse_register_id): Declare. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py: Update to make use of a register descriptor. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Update descriptions for PendingFrame.read_register and gdb.UnwindInfo.add_saved_register. (Frames In Python): Update description of Frame.read_register.
2020-07-28gdb: Add a find method for RegisterDescriptorIteratorAndrew Burgess6-1/+84
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class, this allows gdb.RegisterDescriptor objects to be looked up directly by register name rather than having to iterate over all registers. This will be of use for a later commit. I've documented the new function in the manual, but I don't think a NEWS entry is required here, as, since the last release, the whole register descriptor mechanism is new, and is already mentioned in the NEWS file. gdb/ChangeLog: * python/py-registers.c: Add 'user-regs.h' include. (register_descriptor_iter_find): New function. (register_descriptor_iterator_object_methods): New static global methods array. (register_descriptor_iterator_object_type): Add pointer to methods array. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Add additional tests. gdb/doc/ChangeLog: * python.texi (Registers In Python): Document new find function.
2020-07-28PR25022 testcase segfault for generic ELF linker targetsAlan Modra3-39/+36
Even a testcase that is expected to fail shouldn't segfault. * elf.c (assign_section_numbers): Comment. Don't segfault on discarded sections when setting linked-to section for generic ELF linker. * elflink.c (bfd_elf_match_symbols_in_sections): Allow NULL info.
2020-07-28More just-syms changesAlan Modra3-7/+22
* ldlang.c (lang_check): Don't complain about relocs or merge attributes from --just-symbols input. * testsuite/ld-misc/just-symbols.exp: Just dump .data section. Don't run test on a number of targets.
2020-07-28Re: Allow new just-symbols test to run on XCOFF and PEAlan Modra2-1/+9
This ensures we don't match random data *before* the line we want to see, ie. that --just-symbols has excluded section contents from just-symbols-0.o. Oops, missed the ChangeLog entry before too. * testsuite/ld-misc/just-symbols-1.dd: Revert last change.
2020-07-28Automatic date update in version.inGDB Administrator1-1/+1
2020-07-27Use SIGTRAP si_code values for all FreeBSD architectures on 11.3 and later.John Baldwin2-3/+14
Fixes to set correct si_code values (such as TRAP_BRKPT) were made to the remaining FreeBSD architectures (MIPS and sparc64) in the head branch leading up to 12.0 and were merged back between the 11.2 and 11.3 releases. gdb/ChangeLog: * fbsd-nat.h: Include <osreldate.h>. Define USE_SIGTRAP_SIGINFO for all architectures on FreeBSD 11.3 and later.
2020-07-27Remove unused declaration from gcore.hTom Tromey2-1/+4
gcore.h declares load_corefile, but there are no other mentions of this in the source. This patch removes it. Tested by grep and rebuilding. gdb/ChangeLog 2020-07-27 Tom Tromey <tromey@adacore.com> * gcore.h (load_corefile): Don't declare.
2020-07-27Allow new just-symbols test to run on XCOFF and PEAlan Modra4-36/+45
* testsuite/ld-misc/just-symbols.exp: Run for x86_64 PE too. Set LDFLAGS for PE and XCOFF. * testsuite/ld-misc/just-symbols.ld: Accept XCOFF mapped .data.
2020-07-27Accept --just-symbols symbols as absolute for xcoffAlan Modra2-6/+19
This patch is aimed at curing just-symbols-1.o: loader reloc in unrecognized section `*ABS*' for xcoff by treating symbols defined by --just-symbols objects as absolute. * xcofflink.c (xcoff_need_ldrel_p): Accept --just-symbols symbols and similar as absolute. (bfd_xcoff_import_symbol): Don't fuss over absolute symbol redefinitions here.
2020-07-27Prevent strange "section mentioned in a -j option but not found"Alan Modra2-2/+7
"objdump -s -j .bss" results in a message that indicates objdump couldn't find a .bss section when present. Fix that. * objdump.c (dump_section): Don't return without calling process_section_p.
2020-07-27ctf test ERROR: $target-cc does not existAlan Modra2-10/+19
* testsuite/lib/ld-lib.exp (check_ctf_available): Check first that target compiler is available.
2020-07-27[GOLD] Power10 stub selectionAlan Modra4-234/+548
gold version of commit e10a07b32dc1. * options.h (DEFINE_enum): Add optional_arg__ param, adjust all uses. (General_options): Add --power10-stubs and --no-power10-stubs. * options.cc (General_options::finalize): Handle --power10-stubs. * powerpc.cc (set_power10_stubs): Don't set when --power10-stubs=no. (power10_stubs_auto): New. (struct Plt_stub_ent): Add toc_ and tocoff_. Don't use a bitfield for indx_. (struct Branch_stub_ent): Add toc_and tocoff_. Use bitfields for iter_, notoc_ and save_res_. (add_plt_call_entry): Set toc_. Adjust resizing conditions for --power10-stubs=auto. (add_long_branch_entry): Set toc_. (add_eh_frame, define_stub_syms): No longer use const_iterators for plt and long branch stub iteration. (build_tls_opt_head, build_tls_opt_tail): Change parameters and return value. Move tests for __tls_get_addr to callers. (plt_call_size): Handle --power10-stubs=auto. (branch_stub_size): Likewise. (Stub_table::do_write): Likewise. (relocate): Likewise.
2020-07-27doc: Replace preceeded with precededH.J. Lu4-5/+13
binutils/ * doc/binutils.texi: Replace preceeded with preceded. gas/ * doc/as.texi: Replace preceeded with preceded.
2020-07-27[gdb/build] Fix typo sys/sockets.h -> sys/socket.hTom de Vries4-8/+11
I'm running into a build breaker: ... src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int socklen_t’ 65 | typedef int socklen_t; | ^~~~~~~~~ In file included from ../gnulib/import/unistd.h:40, from /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42, from /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120, from src/gdb/defs.h:28, from src/gdb/ser-tcp.c:20: /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef __socklen_t socklen_t’ 277 | typedef __socklen_t socklen_t; | ^~~~~~~~~ ... after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in MinGW builds". The root cause is a typo in gdb/configure.ac, using sys/sockets.h where sys/socket.h was meant: ... AC_CHECK_HEADERS([sys/sockets.h]) ... Fix the typo. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-07-27 Tom de Vries <tdevries@suse.de> * configure.ac: Fix sys/sockets.h -> sys/socket.h typo. * config.in: Regenerate. * configure: Regenerate.
2020-07-27Automatic date update in version.inGDB Administrator1-1/+1
2020-07-26libctf: compilation failure on MinGW due to missing errno valuesEli Zaretskii3-0/+15
This commit fixes a compilation failure in a couple of libctf files due to the use of EOVERFLOW and ENOTSUP, which are not defined when compiling on MinGW. libctf/ChangeLog: PR binutils/25155: * ctf-create.c (EOVERFLOW): If not defined by system header, redirect to ERANGE as a poor man's substitute. * ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead. (cherry picked from commit 50500ecfefd6acc4c7f6c2a95bc0ae1945103220)
2020-07-26Don't unnecessarily redefine 'socklen_t' type in MinGW builds.Eli Zaretskii8-6/+75
The original configure-time tests in gdb/ and gdbserver/ failed to detect that 'socklen_t' is defined in MinGW headers because the test program included only sys/socket.h, which is absent in MinGW system headers. However on MS-Windows this data type is declared in another header, ws2tcpip.h. The modified test programs try using ws2tcpip.h if sys/socket.h is unavailable. Thanks to Joel Brobecker who helped me regenerate the configure scripts and the config.in files. gdb/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate. gdbserver/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate.
2020-07-26MIPS/binutils/testsuite: Correct mips.exp test ABI/emul/endian arrangementMaciej W. Rozycki23-53/+258
The binutils testsuite supports involving LD in processing test cases and with the MIPS target that has the same issues the LD testsuite does. So to support LD in the MIPS part of the binutils testsuite similarly to commit 86b24e15c45b ("MIPS/LD/testsuite: Correct comm-data.exp test ABI/emul/endian arrangement") update the mips.exp test script to: - correctly select emulations for targets using non-traditional MIPS emulations, - correctly select ABIs for targets that do not support all of them, - use the default endianness selection where possible to benefit targets that support only one, - simplify test invocation by providing ABI-specific `run_dump_test' wrappers, specifically `run_dump_test_o32', `run_dump_test_n32' and `run_dump_test_n64', which remove the need to use conditionals across the Expect script or to repeat ABI-specific GAS and LD flags with each invocation, borrowing changes from commit 78da84f99405 ("MIPS/LD/testsuite: Correct mips-elf.exp test ABI/emul/endian arrangement"). As a side effect this disables o32 ABI testing for targets that are not supposed to support them and do not with LD, but still have such support with BFD and GAS due to our inflexibility in configuration. Ultimately we ought to support having o32 completely disabled. binutils/ * testsuite/binutils-all/mips/mips.exp (run_dump_test_abi) (run_dump_test_o32, run_dump_test_n32, run_dump_test_n64): New procedures. (has_newabi): Remove variable. (has_abi, abi_asflags, abi_ldflags): New associative array variables. (irixemul): New variable. Replace `run_dump_test' calls where applicable throughout with `run_dump_test_o32', `run_dump_test_n32' and `run_dump_test_n64' as appropriate. Use `noarch' for tests that require their own architecture setting. * testsuite/binutils-all/mips/mips-ase-1.d: Remove GAS flags. * testsuite/binutils-all/mips/mips-ase-2.d: Likewise. * testsuite/binutils-all/mips/mips-ase-3.d: Likewise. * testsuite/binutils-all/mips/mips-note-2-n32.d: Likewise. * testsuite/binutils-all/mips/mips-note-2-n64.d: Likewise. * testsuite/binutils-all/mips/mips-note-2.d: Likewise. * testsuite/binutils-all/mips/mips-note-2r-n32.d: Likewise. * testsuite/binutils-all/mips/mips-note-2r-n64.d: Likewise. * testsuite/binutils-all/mips/mips-note-2r.d: Likewise. * testsuite/binutils-all/mips/mips-reginfo-n32.d: Likewise. * testsuite/binutils-all/mips/mips-reginfo.d: Likewise. * testsuite/binutils-all/mips/mips16-extend-noinsn.d: Likewise. * testsuite/binutils-all/mips/mips16-pcrel.d: Likewise. * testsuite/binutils-all/mips/mips16-alias.d: Remove `-32' from GAS flags. * testsuite/binutils-all/mips/mips16-extend-insn.d: Likewise. * testsuite/binutils-all/mips/mips16-noalias.d: Likewise. * testsuite/binutils-all/mips/mips16-undecoded.d: Likewise. * testsuite/binutils-all/mips/mips16e2-extend-insn.d: Likewise. * testsuite/binutils-all/mips/mips16e2-undecoded.d: Likewise. * testsuite/binutils-all/mips/mixed-micromips.d: Likewise. * testsuite/binutils-all/mips/mixed-mips16.d: Likewise.
2020-07-26Automatic date update in version.inGDB Administrator1-1/+1
2020-07-25gdb/fortran: resolve dynamic types when readjusting after an indirectionAndrew Burgess9-19/+233
After dereferencing a pointer (in value_ind) or following a reference (in coerce_ref) we call readjust_indirect_value_type to "fixup" the type of the resulting value object. This fixup handles cases relating to the type of the resulting object being different (a sub-class) of the original pointers target type. If we encounter a pointer to a dynamic type then after dereferencing a pointer (in value_ind) the type of the object created will have had its dynamic type resolved. However, in readjust_indirect_value_type, we use the target type of the original pointer to "fixup" the type of the resulting value. In this case, the target type will be a dynamic type, so the resulting value object, once again has a dynamic type. This then triggers an assertion later within GDB. The solution I propose here is that we call resolve_dynamic_type on the pointer's target type (within readjust_indirect_value_type) so that the resulting value is not converted back to a dynamic type. The test case is based on the original test in the bug report. gdb/ChangeLog: PR fortran/23051 PR fortran/26139 * valops.c (value_ind): Pass address to readjust_indirect_value_type. * value.c (readjust_indirect_value_type): Make parameter non-const, and add extra address parameter. Resolve original type before using it. * value.h (readjust_indirect_value_type): Update function signature and comment. gdb/testsuite/ChangeLog: PR fortran/23051 PR fortran/26139 * gdb.fortran/class-allocatable-array.exp: New file. * gdb.fortran/class-allocatable-array.f90: New file. * gdb.fortran/pointer-to-pointer.exp: New file. * gdb.fortran/pointer-to-pointer.f90: New file.
2020-07-25Automatic date update in version.inGDB Administrator1-1/+1
2020-07-25[gdb/symtab] Ignore zero line table entriesTom de Vries5-2/+217
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-24config/debuginfod.m4: Use PKG_CHECK_MODULESAaron Merey13-382/+855
Use PKG_CHECK_MODULES to set debuginfod autoconf vars. Also add pkg.m4 to config/. ChangeLog: * config/debuginfod.m4: use PKG_CHECK_MODULES. * config/pkg.m4: New file. * configure: Rebuild. * configure.ac: Remove AC_DEBUGINFOD. ChangeLog/binutils: * Makefile.am: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS. * Makefile.in: Rebuild. * configure: Rebuild. * doc/Makefile.in: Rebuild. ChangeLog/gdb: * Makefile.in: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS. * configure: Rebuild.
2020-07-24[gdb/testsuite] Require gnatmake-8 for gdb.ada/mi_prot.expTom de Vries2-0/+8
With gcc-7, I run into: ... gcc -c -I./ -gnata -Isrc/gdb/testsuite/gdb.ada/mi_prot -g -lm -I- \ src/gdb/testsuite/gdb.ada/mi_prot/prot.adb^M prot.adb:21:04: info: "Obj_Type" is frozen here, aspects evaluated at this \ point^M prot.adb:23:09: visibility of aspect for "Obj_Type" changes after freeze \ point^M gnatmake: "src/gdb/testsuite/gdb.ada/mi_prot/prot.adb" compilation error^M compiler exited with status 1 ... FAIL: gdb.ada/mi_prot.exp: compilation prot.adb ... Fix this by requiring gnatmake-8 for this test-case. Tested on x86_64-linux, with gnatmake-7, gnatmake-8 and gnatmake-11. gdb/testsuite/ChangeLog: 2020-07-24 Tom de Vries <tdevries@suse.de> PR testsuite/26293 * gdb.ada/mi_prot.exp: Require gnatmake-8.
2020-07-24Update documentation on how to make a releaseNick Clifton2-10/+34
2020-07-24Move the xc16x target to the obsolete listNick Clifton2-2/+6
2020-07-24Updated German translation for the opcodes sub-directoryNick Clifton2-245/+319
2020-07-24Automatic date update in version.inGDB Administrator1-1/+1
2020-07-23Fix BZ 26294 - Add period to help text for maint print core-file-backed-mappingsKevin Buettner2-1/+7
gdb/ChangeLog: PR corefiles/26294 * corelow.c (_initialize_corelow): Add period to help text for "maintenance print core-file-backed-mappings".
2020-07-23PR ld/26288: Allow the use of `--just-symbols' with ET_EXEC inputMaciej W. Rozycki7-1/+90
Fix a regression from commit a87e1817a435 ("Have the linker fail if any attempt to link in an executable is made.") and do not reject ET_EXEC input supplied with the `--just-symbols' option. Such use is legitimate as the file requested is not actually linked and only the symbols are extracted. Furthermore it is often the most useful application, as already observed in our documentation for the option, where it allows "to refer symbolically to absolute locations of memory defined in other programs." Provide a set of tests for the use of ET_EXEC with `--just-symbols'. These are excluded however for SH/PE targets because they complain if a section's VMA is 0: ld: zero vma section reloc detected: `.text' #0 f=32795 ld: zero vma section reloc detected: `.data' #1 f=291 and for x86_64/PE targets because they seem to hardwire the VMA: 100000000 12000000 01000000 00000000 00000000 ................ ld/ PR ld/26288 * ldelf.c (ldelf_after_open): Do not reject ET_EXEC input supplied with `--just-symbols'. * testsuite/ld-misc/just-symbols.exp: New test script. * testsuite/ld-misc/just-symbols-1.dd: New test dump. * testsuite/ld-misc/just-symbols.ld: New test linker script. * testsuite/ld-misc/just-symbols-0.s: New test source. * testsuite/ld-misc/just-symbols-1.s: New test source.
2020-07-23PR ld/26288: Revert obsolete part of PR ld/26047 fixMaciej W. Rozycki2-7/+9
Revert commit a3fc941881e4 ("Stop the linker from accepting executable ELF files as inputs to other links."), which has been made obsolete by commit a87e1817a435 ("Have the linker fail if any attempt to link in an executable is made."). An earlier check triggers added with the latter commit making the piece of code removed dead. ld/ PR ld/26288 Revert: PR 26047 * ldelf.c (ldelf_after_open): Fail if attempting to link one executable into another.
2020-07-23Don't touch frame_info objects if frame cache was reinitializedPedro Alves6-29/+144
This fixes yet another bug exposed by ASAN + multi-target.exp Running an Asan-enabled GDB against gdb.multi/multi-target.exp exposed yet another latent GDB bug. See here for the full log: https://sourceware.org/pipermail/gdb-patches/2020-July/170761.html As Simon described, the problem is: - We create a new frame_info object in restore_selected_frame (by calling find_relative_frame) - The frame is allocated on the frame_cache_obstack - In frame_unwind_try_unwinder, we try to find an unwinder for that frame - While trying unwinders, memory read fails because the remote target closes, because of "monitor exit" - That calls reinit_frame_cache (as shown above), which resets frame_cache_obstack - When handling the exception in frame_unwind_try_unwinder, we try to set some things on the frame_info object (like *this_cache, which in fact tries to write into frame_info::prologue_cache), but the frame_info object is no more, it went away with the obstack. Fix this by maintaining a frame cache generation counter. Then in exception handling code paths, don't touch frame objects if the generation is not the same as it was on entry. This commit generalizes the gdb.server/server-kill.exp testcase and reuses it to test the scenario in question. The new tests fail without the GDB fix. gdb/ChangeLog: * frame-unwind.c (frame_unwind_try_unwinder): On exception, don't touch THIS_CACHE/THIS_FRAME if the frame cache was cleared meanwhile. * frame.c (frame_cache_generation, get_frame_cache_generation): New. (reinit_frame_cache): Increment FRAME_CACHE_GENERATION. (get_prev_frame_if_no_cycle): On exception, don't touch PREV_FRAME/THIS_FRAME if the frame cache was cleared meanwhile. * frame.h (get_frame_cache_generation): Declare. gdb/testsuite/ChangeLog: * gdb.server/server-kill.exp (prepare): New, factored out from the top level. (kill_server): New. (test_tstatus, test_unwind_nosyms, test_unwind_syms): New. (top level) : Call test_tstatus, test_unwind_nosyms, test_unwind_syms.
2020-07-23[gdb/tui] Fix Wmaybe-uninitialized warning in tui-winsource.cTom de Vries2-0/+11
When compiling with CFLAGS/CXXFLAGS="-O0 -g -Wall" and using g++ 11.0.0, we run into: ... src/gdb/tui/tui-winsource.c: In function \ 'void tui_update_all_breakpoint_info(breakpoint*)': src/gdb/tui/tui-winsource.c:427:58: warning: '<unknown>' may be used \ uninitialized [-Wmaybe-uninitialized] 427 | for (tui_source_window_base *win : tui_source_windows ()) | ^ In file included from src/gdb/tui/tui-winsource.c:38: src/gdb/tui/tui-winsource.h:236:30: note: by argument 1 of type \ 'const tui_source_windows*' to 'tui_source_window_iterator \ tui_source_windows::begin() const' declared here 236 | tui_source_window_iterator begin () const | ^~~~~ src/gdb/tui/tui-winsource.c:427:58: note: '<anonymous>' declared here 427 | for (tui_source_window_base *win : tui_source_windows ()) | ^ ... The warning doesn't make sense for an empty struct, PR gcc/96295 has been filed about that. For now, work around the warning by defining a default constructor. Build on x86_64-linux. gdb/ChangeLog: 2020-07-23 Tom de Vries <tdevries@suse.de> PR tui/26282 * tui/tui-winsource.h (struct tui_source_windows::tui_source_windows): New default constructor.
2020-07-23gdb/disassembly: Update to handle non-statement addressesAndrew Burgess4-6/+215
After the introduction of support for non-statement addresses in the line table, the output for 'disassemble /m' can be broken in some cases. With the /m format disassembly GDB associates a set of addresses with each line, these addresses are then sorted and printed for each line. When the non-statement support was added GDB was incorrectly told to ignore non-statement instructions, and not add these to the result table. This means that these instructions are completely missing from the output. This commit removes the code that caused non-statement lines to be ignored. A result of this change is that GDB will now potentially include new line numbers in the 'disassemble /m' output, lines that previously were only in the line table as non-statement lines will now appear in the disassembly output. This feels like an improvement though. gdb/ChangeLog: * disasm.c (do_mixed_source_and_assembly_deprecated): Don't exclude non-statement entries. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-disasm-over-non-stmt.exp: New file.
2020-07-22Fix more bugs in gdb testglue wrapper handlingSandra Loosemore2-12/+22
In commit 24ac169ac5a918cd82b7485935f0c40a094c625e, this patch: 2020-02-21 Shahab Vahedi <shahab@synopsys.com> * lib/gdb.exp (gdb_wrapper_init): Reset "gdb_wrapper_initialized" to 0 if "wrapper_file" does not exist. attempted to fix problems finding the gdb test wrapper gdb_tg.o in some tests that cd to some non-default directory by rebuilding also the test wrapper in that directory. This had the side-effect of leaving these .o files in various places in the GDB source directory tree. Furthermore, while the tests that cd to some non-default directory cannot run on remote host, the code that was added to probe for the presence of the wrapper file was also specific to host == build. This patch reverts the problematic parts of that commit and replaces it with forcing use of an absolute (rather than relative) pathname to the .o file for linking when host == build. While debugging this patch, I also observed that use of the construct "[info exists gdb_wrapper_file]" was not reliable for detecting when that variable had been initialized by gdb_wrapper_init. I rewrote that so that the variable is always initialized and has a value of an empty string when no wrapper file is needed. 2020-07-22 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * lib/gdb.exp (gdb_wrapper_file, gdb_wrapper_flags): Initialize to empty string at top level. (gdb_wrapper_init): Revert check for file existence on build. Build the wrapper in its default place, not a build-specific location. When host == build, make the pathname absolute. (gdb_compile): Delete leftover declaration of gdb_wrapper_initialized. Check gdb_wrapper_file being an empty string instead of uninitialized.
generated by cgit v1.1 at 2025-09-19 07:46:27 +0000