From 2bc7af1ff7732451b6a7b09462a815c3284f9613 Mon Sep 17 00:00:00 2001 From: Nick Clifton Date: Sun, 27 Jul 2025 09:56:42 +0100 Subject: [PATCH] This is the 2.45 release --- ChangeLog.git | 276618 ++++++++++++++++++++++++++++++ bfd/configure | 20 +- bfd/development.sh | 4 +- bfd/po/bfd.pot | 158 +- bfd/version.m4 | 2 +- binutils/configure | 20 +- binutils/po/binutils.pot | 1117 +- gas/configure | 20 +- gas/po/gas.pot | 274 +- gprof/configure | 20 +- gprofng/configure | 20 +- gprofng/doc/version.texi | 4 +- gprofng/libcollector/configure | 20 +- ld/configure | 20 +- ld/po/ld.pot | 258 +- libiberty/functions.texi | 59 +- opcodes/configure | 20 +- src-release.sh | 2 +- 18 files changed, 277653 insertions(+), 1003 deletions(-) create mode 100644 ChangeLog.git diff --git a/ChangeLog.git b/ChangeLog.git new file mode 100644 index 00000000000..ba5ed49397e --- /dev/null +++ b/ChangeLog.git @@ -0,0 +1,276618 @@ +2025-07-27 Nick Clifton + + Oops - test files accidentally omitted from previous deltas + +2025-07-27 Indu Bhagat + + [PATCH] doc: sframe: mention errata 1 of SFrame version 2 + With the changes of an added flag SFRAME_F_FDE_FUNC_START_PCREL, s390x + support and new section type SHT_GNU_SFRAME, indicate that this document + specifies the errata 1 of SFrame version 2. This will help distinguish + the document / specification better from previous releases. + + libsframe/doc/ + * sframe-spec.texi: Mention errata 1 of SFrame version 2. + +2025-07-27 Indu Bhagat + + [PATCH] readelf: objdump: sframe: fix dumping with section name + Fix PR binutils/33186 - No SFrame dump if section name is not .sframe + + When the section name is not ".sframe", ensure that readelf and objdump + are able to dump a section of type SHT_GNU_SFRAME and not fail if the + user specifies the new section name. + + For objdump, in dump_dwarf_section (), use the match string of ".sframe" + to find the corresponding debug_displays[] item for SFrame section. + Doing this ensures that any call to dump_dwarf_section () with the + section pointing to the SFrame section (with name possibly different + from ".sframe") will successfully dump the SFrame section. + + If the SFrame section is named anything but ".sframe", and user does not + specify the name of the SFrame section either, the documented behaviour + is that the default section name is assumed to be ".sframe". So the + following (albeit counter intuitive) is expected at this time: + + $ readelf -S sort | grep sframe + [NN] .sframe2 GNU_SFRAME 0000000000NNNNNN 0000NNNN + + (Note section name .sframe2). + + $ objdump --sframe sort + + sort: file format elf64-x86-64 + + No .sframe section present + + (Similarly for readelf as well). + + For objdump, set dump_sframe_section_name to ".sframe" if user specifies + no section name. In the error checking done in dump_sframe_section, add + the case when user specifies a valid section name but one that does not + contain SFrame section data. For sections generated with Binutils >= + 2.45, this can be checked with section type of SHT_GNU_SFRAME. + Previously these sections were SHT_PROGBITS with name ".sframe". + + Similar changes in readelf. + + Add a test each for objdump and readelf to dump a renamed section. Use + gas_sframe_check to limit the execution of these tests only when a gas + supporting SFrame format is present. + + binutils/ + PR binutils/33186 + * objdump.c (dump_dwarf_section): Set match to ".sframe" which + corresponds to the name in the debug_displays[] entry for + SFrame section. + (dump_sframe_section): Check if the user specified section name + contains SFrame data. + (main): Set default section name to ".sframe". + * readelf.c (display_debug_section): Adjust checks to find the + debug_diplays[] item for the input arg SFrame section. + Use id instead of i, as it is more readable. + + binutils/testsuite/ + PR binutils/33186 + * binutils-all/x86-64/objdump-sframe-01.d: New test. + * binutils-all/x86-64/readelf-sframe-01.d: New test. + * binutils-all/x86-64/sframe-func.s: New test. + +2025-07-27 Indu Bhagat + + [PATCH] gas: sframe: command line option takes precedence over gas directive to emit .sframe section. + Fix PR gas/33175 sframe: --gsframe=no does not disable when .cfi_sections directive with .sframe + + --gsframe=no should also disable generation of SFrame section when explicit CFI directive: .cfi_sections .sframe is specified in the input. + This means we need to track whether SFrame generation was explicitly disabled by the user. + Introduce a new enum to facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and GEN_SFRAME_DISABLED. + While fixing the bug by adding the enum, keep the upcoming requirement in mind: we will also need to disambiguate between --enable-default-sframe and user-specified --gsframe/--gsframe=yes. + The intent is to not display SFrame related warnings or errors like: as_bad (_(".sframe not supported for target")); for unsupported targets if --enable-default-sframe is in effect. + This implies we need to have a four state enum ( GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED, GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED) gas + +2025-07-27 GDB Administrator + + Automatic date update in version.in + +2025-07-26 GDB Administrator + + Automatic date update in version.in + +2025-07-25 Alice Carlotti + + gas/NEWS: Add AArch64 updates + +2025-07-25 Alice Carlotti + + gas/doc: Update AArch64 Architecture Extensions + Add faminmax, move a couple of misplaced entries, and improve a few + other entries. + + The documentation now lists every recognised extension name, with the + exception of a couple of aliases that are deliberately undocumented. + +2025-07-25 Alice Carlotti + + aarch64: Fix sve2p2/sme2p2 dependencies + Change dependency on sve2/sme2 to sve2p1/sme2p1. + +2025-07-25 Rainer Orth + + ld: Force SHELL=/bin/bash in ld for Solaris [PR32580] + As described in PR ld/32580, when using SHELL=/bin/sh or /bin/ksh on + Solaris, the generated linker scripts get corrupted. So far, the only + workaround is to enforce /bin/bash instead. + + This is a major nuisance for developers and users alike, so this patch + automates this by overriding SHELL in ld/configure.ac. + + Tested on amd64-pc-solaris2.11 in three configurations: + + * CONFIG_SHELL unset + + * CONFIG_SHELL=/bin/ksh + + * CONFIG_SHELL='/bin/bash --norc' + + In the first two cases, SHELL was set to /bin/bash as desired, while in + the third it was left unchanged. + + 2025-07-24 Rainer Orth + + ld: + PR ld/32580 + * configure.ac <*-*-solaris2*>: Enforce SHELL=/bin/bash. + * configure: Regenerate. + + (cherry picked from commit 96ad2fd3c0c0414110fe58ed4ee511f49768fa3d) + +2025-07-25 GDB Administrator + + Automatic date update in version.in + +2025-07-24 Indu Bhagat + + gas: sframe: fix PR gas/33170 + SFrame generation code assumes that since DW_CFA_restore means + restoration of the state of the register to the one at the beginning of + the function, there must be a state to restore to (hence the gas_assert + (cie_fre)). + + This assumption needs adjustment. DW_CFA_restore may be present in the + very beginning of a (e.g., cold) function, with no initialized state for + SFrame functions to restore to. + + gas/ + PR gas/33170 + * gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if + CIE FRE is not yet setup. + gas/testsuite/ + PR gas/33170 + * gas/cfi-sframe/cfi-sframe.exp: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test. + + (cherry picked from commit 83eeaf917873a550656faf9a38cd14e0f4c521b1) + +2025-07-24 H.J. Lu + + strip: Properly handle LLVM IR bitcode + commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d + Author: H.J. Lu + Date: Sun May 4 05:12:46 2025 +0800 + + strip: Add GCC LTO IR support + + added "-R .gnu.lto_.*" to strip to remove all GCC LTO sections. When + "-R .gnu.lto_.*" is used, the plugin target is ignored so that all LTO + sections are stripped as the regular sections. It works for the slim + GCC LTO IR since the GCC LTO IR is stored in the regular sections. When + the plugin target is ignored, the GCC LTO IR can be recognized as the + normal object files. But it doesn't work for the slim LLVM IR which + is stored in a standalone file. + + 1. Add bfd_check_format_matches_lto and bfd_check_format_lto to take an + argument, lto_sections_removed, to indicate if all LTO sections should + be removed. + 2. Update strip to always enable the plugin target so that the plugin + target is enabled when checking for bfd_archive. + 3. Update strip to ignore the plugin target for bfd_object when all LTO + sections should be removed. If the object is unknown, copy it as an + unknown file without any messages. + 4. Treat the "-R .llvm.lto" strip option as removing all LTO sections. + + bfd/ + + PR binutils/33198 + * format.c (bfd_check_format_lto): New function. + (bfd_check_format): Call bfd_check_format_matches_lto. + (bfd_check_format_matches): Renamed to ... + (bfd_check_format_matches_lto): This. Add an argument, + lto_sections_removed, to indicate if all LTO sections should be + removed and don't match the plugin target if lto_sections_removed + is true. + (bfd_check_format_matches): Call bfd_check_format_matches_lto. + * bfd-in2.h: Regenerated. + + binutils/ + + PR binutils/33198 + * objcopy.c (copy_archive): Call bfd_check_format_lto, instead + of bfd_check_format, and pass lto_sections_removed. Remove the + non-fatal message on unknown element since it will be copied as + an unknown file. + (copy_file): Don't check lto_sections_removed when enabling LTO + plugin in strip. + (copy_file): Ignore the plugin target first if all LTO sections + should be removed. Try with the plugin target next if ignoring + the plugin target failed to match the format. + (strip_main): Also set lto_sections_removed for -R .llvm.lto. + * testsuite/binutils-all/x86-64/pr33198.c: New file. + * testsuite/binutils-all/x86-64/x86-64.exp (run_pr33198_test): + New. + Run binutils/33198 tests. + * testsuite/lib/binutils-common.exp (llvm_plug_opt): New. + (CLANG_FOR_TARGET): New. Set to "clang" for native build if + "clang -v" reports "clang version". + + (cherry picked from commit f752be8f916efa70aea9c2e4f664c75690fd136c) + +2025-07-24 Alan Modra + + PR 33197 [AVR] Incorrect syntax in generated ldscript + Rearrange scripttempl/avr.sc to avoid oddities of shells expanding + ${RELOCATING+stuff} in here documents where "stuff" contains quoted + strings. Also I think it is better to avoid multi-line "stuff" as it + can be tricky to spot the ending brace. + + (cherry picked from commit ae114fb523efe908f9e807359e2f494ee64d2801) + +2025-07-24 GDB Administrator + + Automatic date update in version.in + +2025-07-23 GDB Administrator + + Automatic date update in version.in + +2025-07-22 Nick Clifton + + Updated translations for various sub-directories + +2025-07-22 Torbjörn SVENSSON + + ld: Rename a file on Windows fails if target already exists + To rename a file on Windows, the target name cannot exist. Removing file + prior to renaming ensures this is handled. + To remove a file on Windows, the file cannot be open. Closing the bfd + handle ensures this is handled. + Moved call to free on isympp / osympp to after bfd is closed to align + with comment earlier in the cmdline_add_object_only_section function. + + (cherry picked from commit 233cd5946413108bf4902b22a9cb23ad0a468f5e) + +2025-07-21 Dmitrii Bordukov + + gprofng: do not skip weak symbols + PR gprofng/33151 + + gprofng ignores functions that are compiled as weak symbols. This + heavily affects C++ class methods that are always compiled by g++ + and clang++ as weak symbols. In this case 'gprofng display text' + just displays @ADDRESS() instead of proper method + name. + + The bug has been introduced in the commit 470a0288a818. + +2025-07-18 Alan Modra + + Remove sframe relocs against discarded sections + Commit d7f343eaad3f testsuite change resulted in a regression for + s390x-linux. This extends the x86_64 fix to other targets. + + PR ld/33156 + * elf-bfd.h (RELOC_AGAINST_DISCARDED_SECTION): Remove .sframe + relocs too. + + (cherry picked from commit fcf7470408aa0508fbe99abb99547757a348383d) + +2025-07-17 Indu Bhagat + + libsframe: relax the assertion limit for fre_start_addr + Fix PR ld/33131 Failed assertion when linking gccgo + + Make amendments in both sframe_decoder_get_fre and + sframe_encoder_add_fre. + + Since GNU as and the dw2gencfi code generally accepts such CFI, its best + to allow in SFrame FREs too. + + libsframe/ + PR ld/33131. + * sframe.c (sframe_decoder_get_fre): Relax the assertion a bit. + (sframe_encoder_add_fre): Likewise. + + (cherry picked from commit 387efef5fef727cbe52099dcd5012905c4205be3) + +2025-07-16 Sam James + + gas: improve --gsframe documentation + I omitted documentation in 8aad677a12832885acd5be1de8f41e740b8e713d in + error. Rectify that with: + 1) changing ---help to mention bare `--gsframe` too, as we're not + getting rid of that; + + 2) adding the new --gsframe=[no|yes] form to as.texi. + + PR gas/33125 + * gas/as.c (parse_args): Tweak --gsframe= help text. + * gas/doc/as.texi: Document --gsframe=[no|yes]. + + (cherry picked from commit 50c1c57426db6e1c7b44b4d05f0b07fcba91f890) + +2025-07-16 H.J. Lu + + gas: Re-indent case OPTION_SFRAME: + PR gas/33125 + * gas/as.c (parse_args): Re-indent case OPTION_SFRAME: + + (cherry picked from commit 1535d2a0ce4e474f1a42e8b8720de01b7dc1f656) + +2025-07-16 Sam James + + gas: support --gsframe=no + Being able to explicitly disable SFrames on the command line is useful, + especially when looking at a gas that enables SFrames by default. The + binutils testsuite will benefit from this as there's testcases that don't + expect their presence. + + In summary: + * Nothing is passed => no SFrames (no change from before) + * --gsframe is passed => SFrames (no change from before) + * --gsframe=yes is passed => SFrames (previously rejected) + * --gsframe-no is passed => no SFrames (previously rejected) + + PR gas/33125 + * gas/as.c (parse_args): Accept --gsframe=no, --gsframe=yes. + + (cherry picked from commit 8aad677a12832885acd5be1de8f41e740b8e713d) + +2025-07-16 H.J. Lu + + x86-64: Remove sframe relocs against discarded sections + Since unlike eh_frame editing code, sframe editing code keeps + R_X86_64_NONE reloc as is, its r_offset is wrong, we must not + generate R_X86_64_NONE reloc in sframe section against discarded + sections for "ld -r". + + bfd/ + + PR ld/33156 + * elf64-x86-64.c (elf_x86_64_relocate_section): Also remove + sframe relocations against discarded sections for "ld -r". + + ld/ + + PR ld/33156 + * testsuite/ld-elf/eh-group.exp (as_gsframe): New. + Assemble eh-group.o with $as_gsframe. + + (cherry picked from commit d7f343eaad3f34c76657b9996e6253b4f9a218d5) + +2025-07-16 H.J. Lu + + sframe: Allow input R_*_NONE relocations + "ld -r" generates R_*_NONE relocations in sframe section if input + relocations in sframe section are against discarded section. Allow + input R_*_NONE relocations if there are more relocation entries than + SFrame entries, instead of assuming number of SFrame entries == number + of relocation entries. + + bfd/ + + PR ld/33127 + * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Allow input + R_*_NONE relocations if there are more relocation entries than + SFrame entries. + + ld/ + + PR ld/33127 + * testsuite/ld-x86-64/sframe-reloc-2a.s: New file. + * testsuite/ld-x86-64/sframe-reloc-2b.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run PR ld/33127 tests. + + (cherry picked from commit 5f9bf0cf711a153a0a20d6ff88181e9a6775bdba) + +2025-07-16 H.J. Lu + + ld: Clear map_head_is_link_order for .gnu_object_only + Clear map_head_is_link_order when generating .gnu_object_only section so + that lang_add_section can add new sections and .sframe sections will be + properly merged by _bfd_elf_merge_section_sframe. + + PR ld/33146 + * ldlang.c (cmdline_emit_object_only_section): Clear + map_head_is_link_order. + * testsuite/ld-plugin/lto.exp (as_gsframe): New. + (lto_link_tests): Add $as_gsframe to compile lto-4b.o and + lto-4c.o. + + (cherry picked from commit 939eb467b21de5d18ee703755fb9704a525cfe21) + +2025-07-16 Alan Modra + + Re: gas: Move gas_sframe_check to binutils-common.exp + PR ld/33146 + + Correct TCL errors trying to access error output file in commit + ef7a634dc01d. In fact, get rid of the output file test entirely since + gas exit status is sufficient. + + Also there is no need to firstly check for ELF support. + + Set check_as_sframe_result, and remove ld-lib.exp check_as_sframe. + + (cherry picked from commit a57a3a169ea9ec79977949c9c8dccd3a2a615fae) + +2025-07-16 H.J. Lu + + gas: Move gas_sframe_check to binutils-common.exp + Move gas_sframe_check to binutils-common.exp so that it can be used in + linker tests to check if a target assembler supports --gsframe. + + binutils/ + + PR ld/33146 + * testsuite/lib/binutils-common.exp (gas_sframe_check): Moved + from cfi-sframe.exp. Replace gas_host_run with remote_exec. + + gas/ + + PR ld/33146 + * testsuite/gas/cfi-sframe/cfi-sframe.exp (gas_sframe_check): + Moved to binutils-common.exp. + + (cherry picked from commit ef7a634dc01df3d78f208c93316b52937d3fe8f4) + +2025-07-15 Alan Modra + + s390x sframe regressions + Commit 6ab3f09a682a resulted in regressions. + s390x-linux-gnu FAIL: SFrame simple link + s390x-linux-gnu FAIL: SFrame for plt0 and pltN + + Commit 939eb467b21d exposed the problem further. + s390x-linux-gnu FAIL: LTO 4a + s390x-linux-gnu FAIL: LTO 4c + s390x-linux-gnu FAIL: LTO 4d + + * elf64-s390.c (elf_s390_create_dynamic_sections): Set plt_sframe + ELF section type. + + Reviewed-by: Jens Remus + (cherry picked from commit 168c017e206894effdefa919bff29880165fae13) + +2025-07-15 Nick Clifton + + Updated translations for various sub-directories + +2025-07-15 Rainer Orth + + Only parse attributes in ELF sections with the SHT_GNU_ATTRIBUTES type if the OS is not Solaris. Set the is_solaris flag for Sparc solaris architectures + PR 33153 + +2025-07-14 Nick Clifton + + Updated Ukranian translation for the opcodes sub-directory + + Updated Ukranian translation for the binutils sub-directory + + Updated Spanish translation for the gas sub-directory + +2025-07-14 Nelson Chu + + gas/NEWS: Corrected the information about mapping symbol $x for risc-v + +2025-07-14 Aaron Griffith + + gas: accept leading zeros on dollar local labels in z80 sdcc compat mode + SDCC assembly output uses 5-digit numeric dollar sign labels, padded + with zeros. Commit 226749d made these invalid, and broke the Z80 SDCC + compatibility mode in GAS. + + https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b + + This restores SDCC compatibility by replacing the leading zeros with + spaces when inside dollar local labels and when SDCC compatibility is + enabled. It also restores the SDCC test case to represent actual + syntax emitted by SDCC, and adds a note explaining the purpose of + the test. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33030 + +2025-07-13 Nick Clifton + + Fix compile time warning message about optarg parameter shadowing global variable + + Update version number on 2.45 branch + + Add markers for 2.45 branch + +2025-07-13 Tom de Vries + + [gdb/build] Work around GCC ipa-modref bug + PR mi/32571 reports the following problem: + ... + $ gdb -q -batch -ex "b bla.c:100" + + Make breakpoint pending on future shared library load? (y or [n]) \ + [answered N; input not from terminal] + ... + while this is expected: + ... + $ gdb -q -batch -ex "b bla.c:100" + No symbol table is loaded. Use the "file" command. + Make breakpoint pending on future shared library load? (y or [n]) \ + [answered N; input not from terminal] + ... + + A few factors in reproducing this are building gdb using gcc 14, + "-O2 -flto=auto" and --disable-nls. For more details, see the PR. + + This turns out to be caused by a GCC PR [1], more specifically a problem in + ipa-modref. + + Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0, + assuming the GCC 16.1 release will contain a fix. + + Tested on aarch64-linux and x86_64-linux. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571 + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 + +2025-07-13 GDB Administrator + + Automatic date update in version.in + +2025-07-12 Aaron Griffith + + gdb: add Aaron Griffith to gdb/MAINTAINERS + +2025-07-12 Indu Bhagat + + ld/aarch64elf: add support for DT_AARCH64_MEMTAG_STACK dynamic tag + Add new command line option -z memtag-stack for aarch64 elf. This + option instructs the linker to generate the necessary dynamic tag + DT_AARCH64_MEMTAG_STACK, which the dynamic loader can then use to + protect the stack memory with PROT_MTE. Linker issues an + 'unrecognized option' error when -z memtag-stack is specified for + non-aarch64 based emulations. + + readelf displays the dynamic tag when present: + + $ readelf -d + Dynamic section at offset 0xfdd8 contains XX entries: + Tag Type Name/Value + 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] + 0x000000000000000c (INIT) 0x400520 + 0x000000000000000d (FINI) 0x400b64 + 0x0000000000000019 (INIT_ARRAY) 0x41fdc8 + ... ... ... + 0x000000007000000c (AARCH64_MEMTAG_STACK) 0x1 + ... ... ... + + ChangeLog: + + * bfd/elfnn-aarch64.c (elfNN_aarch64_late_size_sections): Emit + DT_AARCH64_MEMTAG_STACK dynamic tag. + * bfd/elfxx-aarch64.h (struct aarch64_memtag_opts): Add new + member for tracking whether stack access uses MTE insns. + * binutils/readelf.c (get_aarch64_dynamic_type): Handle + DT_AARCH64_MEMTAG_STACK. + * ld/emultempl/aarch64elf.em: Add new command line option. + * ld/ld.texi: Add documentation for -z memtag-stack. + * ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test. + * ld/testsuite/ld-aarch64/dt-memtag-stack.d: New test. + + include/ChangeLog: + + * elf/aarch64.h (DT_AARCH64_MEMTAG_STACK): New definition. + +2025-07-12 Indu Bhagat + + ld/aarch64elf: add support for DT_AARCH64_MEMTAG_MODE dynamic tag + Add new command line option -z memtag-mode= to aarch64 elf, + where can be one of none, sync, or async. For mode of sync or + async, a DT_AARCH64_MEMTAG_MODE dynamic tag with a value of 0 or 1 + respectively is emitted. + + readelf displays the dynamic tag when present: + + $ readelf -d + Dynamic section at offset 0xfdd8 contains XX entries: + Tag Type Name/Value + 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] + 0x000000000000000c (INIT) 0x400520 + 0x000000000000000d (FINI) 0x400b64 + 0x0000000000000019 (INIT_ARRAY) 0x41fdc8 + ... ... ... + 0x0000000070000009 (AARCH64_MEMTAG_MODE) 0x1 + ... ... ... + + Note that this patch doesn't add support for the "asymm" MTE mode, + which is an Armv8.7 extension. + + ChangeLog: + + * bfd/elfnn-aarch64.c (struct elf_aarch64_link_hash_table): Add + new member for memtag properties. + (bfd_elfNN_aarch64_set_options): New argument to pass memtag + properties. + (elfNN_aarch64_late_size_sections): Emit DT_AARCH64_MEMTAG_MODE + dynamic tag. + * bfd/elfxx-aarch64.h: New definition for the various memtag + properties. + * binutils/readelf.c (get_aarch64_dynamic_type): Handle + DT_AARCH64_MEMTAG_MODE. + * ld/emultempl/aarch64elf.em: Likewise. + * ld/ld.texi: Add documentation for the new option + -z memtag-mode. + * ld/testsuite/ld-aarch64/aarch64-elf.exp: New test. + * ld/testsuite/ld-aarch64/dt-memtag.d: New test. + * ld/testsuite/ld-aarch64/dt-memtag-mode.s: New test. + + include/ChangeLog: + + * elf/aarch64.h (DT_AARCH64_MEMTAG_MODE): New definition. + +2025-07-12 Indu Bhagat + + ld: aarch64: make EH Frame parsing aware of augmentation char 'G' + As per the DWARF for the Arm 64-bit Architecture (AArch64) + specification, the augmentation char 'G' indicates that associated + frames may modify MTE tags on the stack space they use. + + Add knowledge of the 'G' augmentation char to the EH Frame parsing + code. + + ChangeLog: + + * bfd/elf-eh-frame.c (_bfd_elf_parse_eh_frame): Accommodate + augmentation char 'G'. + * ld/testsuite/ld-aarch64/aarch64-elf.exp: New test. + * ld/testsuite/ld-aarch64/mte-tagged-frame-bar.s: New test. + * ld/testsuite/ld-aarch64/mte-tagged-frame-foo.s: New test. + * ld/testsuite/ld-aarch64/mte-tagged-frame.d: New test. + +2025-07-12 Indu Bhagat + + gas: aarch64: suppport CFI directive .cfi_mte_tagged_frame + Process a new aarch64-specific CFI directive: .cfi_mte_tagged_frame + (LLVM uses this CFI directive already). The CFI directive, when + present for a function, indicates that the stack frame for the + function may modify the MTE tags of the stack space it uses. The + assembler emits char 'G' in the CIE augmentation string to indicate + the same. + + ChangeLog: + + * gas/config/tc-aarch64.c (s_aarch64_mte_tagged_frame): New + definition. + * gas/config/tc-aarch64.h (tc_fde_entry_extras): Add + memtag_frame_p. + (tc_cie_entry_extras): Likewise. + (tc_fde_entry_init_extra): Likewise. + (tc_cie_fde_equivalent_extra): Likewise. + (tc_cie_entry_init_extra): Likewise. + * gas/doc/c-aarch64.texi: Add documentation for + .cfi_mte_tagged_frame directive. + * gas/testsuite/gas/aarch64/mte_tagged_stack.d: New test. + * gas/testsuite/gas/aarch64/mte_tagged_stack.s: New test. + +2025-07-12 Indu Bhagat + + binutils: make read_cie aware of new augmentation char 'G' + This allows objdump/readelf to dump DWARF/EH Frame info when the stack + frame makes use of MTE tagging. + + ChangeLog: + + * binutils/dwarf.c (is_aarch64_augmentation): Add handling for augmentation + char 'G'. + + --- + [No change in V3] + +2025-07-12 Jose E. Marchesi + + bfd: fix recognition of arch-specific augmentations + This patch fixes _bfd_elf_parse_eh_frame so it will not recognize + machine/architecture specific augmentation characters in EH Frame + CFIs. + + Regtested in x86_64-linux-gnu and aarch64-linux-gnu. + + bfd/ChangeLog: + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Recognize augmentation + 'B' only if targetting aarch64. + +2025-07-12 Jose E. Marchesi + + binutils: factorize handling of arch-specific DWARF augmentations + This patch factorizes the handling of architecture/machine specific + augmentation characters in CIEs. + + Based on an idea proposed by Richard Earnshaw. + + binutils/ChangeLog: + + * dwarf.c (is_mach_augmentation_ftype): New type. + (is_mach_augmentation): New variable. + (is_nomach_augmentation): New function. + (is_aarch64_augmentation): Likewise. + (init_dwarf_by_elf_machine_code): Set is_mach_augmentation as + appropriate. + (init_dwarf_by_bfd_arch_and_mach): Likewise. + (read_cie): Handle architecture-specific augmentation characters + in a generic way. + +2025-07-12 Jose E. Marchesi + + binutils: generalize init_dwarf_regnames_by_* functions + This patch renames the functions: + + init_dwarf_regnames_by_elf_machine_code + init_dwarf_regnames_by_bfd_arch_and_mach + + to + + init_dwarf_by_elf_machine_code + init_dwarf_by_bfd_arch_and_mach + + The idea is to start using these functions to perform general + architecture/machine specific initializations beyond register names. + + Regtested in x86_64-linux-gnu and aarch64-linux-gnu targets. + + binutils/ChangeLog: + + * dwarf.c (init_dwarf_regnames_by_elf_machine_code): Rename to + init_dwarf_by_elf_machine_code. + (init_dwarf_regnames_by_bfd_arch_and_mach): Rename to + init_dwarf_by_bfd_arch_and_mach. + * dwarf.h: Adjust prototypes accordingly. + * readelf.c (process_file_header): Adjust call to + init_dwarf_regnames_by_elf_machine_code accordingly. + * objdump.c (dump_dwarf): Adjust call to + init_dwarf_regnames_by_bfd_arch_and_mach accordingly. + +2025-07-12 Alice Carlotti + + aarch64: Add support for --march=armv9.6-a + +2025-07-12 Alice Carlotti + + aarch64: Disable sysreg guards by default + Add a new flag -menable-sysreg-checking to restore previous behaviour. + This existing behaviour is quite inconsistent, so the gating will + probably be updated in the future. (In particular, many system + registers are currently gated with the architecture version they were + released with instead of the lower architecture version that they + actually require). + + This patch retains the +d128 requirement for msrr/mrrs. + + Co-Authored-By: Srinath Parvathaneni + +2025-07-12 Alice Carlotti + + aarch64: Add missing F_STRICT flags + By default, NIL qualifiers are treated as matching any qualifier when + checking operand constraints. For many SVE instructions, this would + allow operands with missing type suffixes to be assembled as if they had + any explicit type specified. To prevent this, the F_STRICT flag is used + to specify that NIL qualifiers should match only NIL qualifiers. + + Unfortunately, several SVE instructions incorrectly omitted this + F_STRICT flag. The bug has existed in the *MATMUL_SVE* macros since + they were added in 2019. The macro LUT_SVE2_INSN was added last year, + and the other incorrect macros are new in this release. + + LUTv2_SME2_INSN and LUTv2_SME2p1_INSN were not actually broken, because + we reject untyped vector lists already during parsing. However, I have + added the F_STRICT flag here anyway, since this is more consistent and + would be more robust if those operands start accepting untyped vector + lists in the future. The new luti4 tests are the only ones that were + already rejected before this change. + + BFLOAT16_SVE_INSN has been unused since it was originally added, so I + just deleted the macro. + + The SVE LUT instructions were using the lut instruction class, which + has special handling only for SIMD operands, and isn't recognised by + aarch64_decode_variant_using_iclass (which sets the qualifiers during + decode for most SVE instructions). To prevent these instructions + failing to disassemble, I changed their instruction class to sve_misc. + +2025-07-12 Alice Carlotti + + aarch64: Remove redundant feature requirements + Many instructions explicitly specified SVE/SVE2/SME/SME2 as a required + feature when it was already implied by another required feature (at + least while the SME->SVE2 implication is retained internally). These + redundant features were used to determine both the valid symbol names + for immediate operands, and the choice of error message for invalid + movprfx sequences. Those two scenarios no longer use architecture + features, so the redundant features are now truly redundant. + +2025-07-12 Alice Carlotti + + aarch64: Use operand class to select movprfx error + Previously the choice of error message for an invalid movprfx sequence + used the architecture requirements to determine whether an instruction + was an SVE instruction or not. This meant specifying SVE or SVE2 as an + explicit architecture requirement for all SVE instructions, even when + this was already implied by another feature. As more architecture + features are added and with the partial removal of the SME->SVE2 + dependency, these extra feature requirements were getting messier and + easier to forget. + + Instead, we now look at the operand types. If there is an SVE_REG, + SVE_REGLIST or PRED_REG operand, then we treat the instruction as an SVE + instruction. This does change behaviour slightly, but it only affects + the choice of error message and the new choice should be a bit more + consistent. + + There is one testsuite update required, because Ezra's SVE_AES2 patch + temporarily broke classification of FEAT_SVE_AES instructions. This + patch restores the original behaviour. + +2025-07-12 Alice Carlotti + + aarch64: Refactor exclusion of reg names in immediates + When parsing immediate values, register names should not be + misinterpreted as symbols. However, for backwards compatibility we need + to permit some newer register names within older instructions. The + current mechanism for doing so depends on the list of explicit + architecture requirements for the instructions, which is fragile and + easy to forget, and grows increasingly messy as more architecture + features are added. + + This patch add explicit flags to each opcode to indicate which set of + register names is disallowed in each instance. These flags are + mandatory for all opcodes with immediate operands, which ensures that + the choice of disallowed names will always be deliberate and explicit. + + This patch should have no functional change. + +2025-07-12 Alice Carlotti + + aarch64: Remove redundant ORs with 0 + +2025-07-12 Indu Bhagat + + libsframe: bump version to 2.0 + Remove LIBSFRAME_1.1, LIBSFRAME_1.0 nodes and add a new LIBSFRAME_2.0 + node (non-inheritance version) to create new global versioned symbols. + Also announce libsframe.so.2 in NEWS. + + New APIs: + sframe_decoder_get_flags; + sframe_decoder_get_offsetof_fde_start_addr; + sframe_encoder_get_flags; + sframe_encoder_get_offsetof_fde_start_addr; + + Removed APIs: (already deprecated since X-2 release) + sframe_get_funcdesc_with_addr; + + APIs with changed semantics: + sframe_decoder_get_funcdesc_v2; + sframe_encoder_add_funcdesc_v2; + sframe_encoder_write; + + lisbframe/ + * libsframe.ver: Define new LIBSFRAME_2.0. + * libtool-version: Bump the 'current' numeral to indicate a binary + incompatible release. + include/ + * sframe-api.h (sframe_get_funcdesc_with_addr): Remove + deprecated interface. + libsframe/ + * sframe.c (sframe_get_funcdesc_with_addr): Likewise. + binutils/ + * NEWS: Announce new versioned release of libsframe. + +2025-07-12 Indu Bhagat + + libsframe: fixup comment and minor style issues + Also, use ATTRIBUTE_UNUSED consistently. + + libsframe/ + * sframe.c (sframe_encoder_add_funcdesc): Fix function-level + comment and use ATTRIBUTE_UNUSED consistently. + (sframe_encoder_add_funcdesc_v2): Use ATTRIBUTE_UNUSED + consistently. + +2025-07-12 Indu Bhagat + + gas: elf: binutils: add new section type SHT_GNU_SFRAME + So far, SFrame sections were of type SHT_PROGBITS. + + As per ELF specification, SHT_PROGBITS indicates that the section holds + information defined by the program, whose format and meaning are + determined solely by the program. + + On the linker side, SHT_PROGBITS should be reserved for the simple "cat + contents after applying relocs" semantics. + + Currently, the only way to know that a section contains SFrame stack + trace data is if consumer checks for section name. Such a check for + section name is not quite conformant to ELF principles. + + Some of this was discussed here + https://sourceware.org/pipermail/binutils/2025-March/140181.html + + With this change, the SFrame sections generated by gas, ld will have + section type set to SHT_GNU_SFRAME. The new section type is defined in + the SHT_LOOS/SHT_HIOS space. The SFrame parsing routine + _bfd_elf_parse_sframe () now admits sections only when the the section + type is SHT_GNU_SFRAME. + + No special handling / validation is done at the moment for the case of + manual creation of SFrame sections via obj_elf_section (). Add function + level comments for now to add a note about this. + + Although the default handling for (sh_type >= SHT_LOOS && sh_type <= + SHT_HIOS) is sufficient when SHT_GNU_SFRAME is in that range, it makes + sense to add it as a case of its own. + + bfd/ + * elf-sframe.c (_bfd_elf_parse_sframe): Check if section type is + SHT_GNU_SFRAME. + (_bfd_elf_set_section_sframe): Set SHT_GNU_SFRAME for output + SFrame section. + * elflink.c (obj_elf_section): Use section type for check + instead of section name. + * elfxx-x86.c: Set SHT_GNU_SFRAME for SFrame sections for + .plt* sections. + * elf.c (bfd_section_from_shdr): Add case for SHT_GNU_SFRAME. + binutils/ + * readelf.c (get_os_specific_section_type_name): Add + SHT_GNU_SFRAME. + gas/ + * NEWS: Announce emitted SFrame sections have SHT_GNU_SFRAME + set. + * config/obj-elf.c (obj_elf_attach_to_group): Add comments to + indicate no special handling for SFrame yet. + * dw2gencfi.c (cfi_finish): Set SHT_GNU_SFRAME for emitted + SFrame section. + ld/ + * NEWS: Announce emitted SFrame sections have SHT_GNU_SFRAME + set. + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Add new test. + * gas/cfi-sframe/cfi-sframe-common-1b.d: New test. + * gas/cfi-sframe/cfi-sframe-common-1b.s: New test. + include/ + * elf/common.h (SHT_GNU_SFRAME): Add new section type for SFrame + stack trace information. + libsframe/doc/ + * sframe-spec.texi: Add expected ELF section type. + +2025-07-12 Indu Bhagat + + gas: sframe: guard block with support_sframe_p + SFrame is generated for ELF targets only. Guard the block with + support_sframe_p like others for consistency. + + Also, in a later commit, we would like to do a: + elf_section_type (sframe_seg) = SHT_GNU_SFRAME; + + This cannot be done for non-ELF targets, hence the need to guard with + some pre-processor conditional to enable it for only OBJ_ELF. Guarding + with support_sframe_p works for now, because those targets that support + SFrame define support_sframe_p: + - x86_64 and aarch64 define support_sframe_p when OBJ_ELF is defined + - s390x has no non-LEF target. + + We continue to issue an error on targets where SFrame is not supported: + .sframe not supported for target + + gas/ + * dw2gencfi.c (cfi_finish): Guard with support_sframe_p. + (support_sframe_p): Remove stub to define to false for backends + not supporting SFrame. + +2025-07-12 WANG Xuerui + + {binutils, gas, ld}/NEWS: Announce LoongArch changes in 2.45 + +2025-07-12 WANG Xuerui + + LoongArch: Un-skip cross-segment alignment compensation during relax pass 2 + It turned out wrong to skip compensating for segment alignment if the + current section is closed for deletion, as my recent system update with + binutils trunk revealed link failures of many high-profile packages such + as ffmpeg, numpy and wxGTK -- the dreaded "relocation truncated to fit" + errors regarding improperly produced R_LARCH_PCREL20_S2. + + As it's near 2.45 branching time, revert the problematic change and + XFAIL the original test case for now. + + Suggested-by: Xi Ruoyao + +2025-07-12 Alan Modra + + MIPS: Fix linker for REL TLS HI16/LO16 relocs + With REL targets TLS HI16/LO16 relocations need to combine the low part + with the high part just as all the remaining HI16/LO16 relocations, so + as to determine the borrow in calculation correctly. + + 2025-07-12 Alan Modra + + bfd/ + PR 19977 + * elfxx-mips.c (tls_hi16_reloc_p): New function. + (mips_elf_add_lo16_rel_addend): Handle tls relocs. + (_bfd_mips_elf_relocate_section): Likewise. + + 2025-07-12 Maciej W. Rozycki + + ld/ + PR 19977 + * testsuite/ld-mips-elf/pr19977.d: New test. + * testsuite/ld-mips-elf/pr19977-mips16.d: New test. + * testsuite/ld-mips-elf/pr19977-micromips.d: New test. + * testsuite/ld-mips-elf/pr19977-r.d: New test. + * testsuite/ld-mips-elf/pr19977-r-mips16.d: New test. + * testsuite/ld-mips-elf/pr19977-r-micromips.d: New test. + * testsuite/ld-mips-elf/pr19977-r.s: New test source. + * testsuite/ld-mips-elf/pr19977.ld: New test linker script. + * testsuite/ld-mips-elf/mips-elf.exp: Run the new tests. + +2025-07-12 Alan Modra + + MIPS: Correct HI/LO rel reloc howto special_function entries + This corrects the DTPREL_HI16/LO16 and TPREL_HI16/LO16 howtos to use + _bfd_mips_elf_{hi,lo}16_reloc special functions, in order to support + addends outside the range [0,32767] on these relocations. + + R_MIPS_GOT_HI16, R_MIPS_GOT_LO16, R_MIPS_CALL_HI16 and R_MIPS_CALL_LO16 + are left alone as it seems that we (quite reasonably) only support + zero addends for those relocs. + + PR 19977 + bfd/ + * elf32-mips.c (elf_mips_howto_table_rel): Set special_function + to _bfd_mips_elf_hi16_reloc for R_MIPS_TLS_DTPREL_HI16 and + R_MIPS_TLS_TPREL_HI16. Set special_function to + _bfd_mips_elf_lo16_reloc for R_MIPS_TLS_DTPREL_LO16 and + R_MIPS_TLS_TPREL_LO16 + (elf_mips16_howto_table_rel): Likewise for + R_MIPS16_TLS_DTPREL_HI16, R_MIPS16_TLS_DTPREL_LO16, + R_MIPS16_TLS_TPREL_HI16 and R_MIPS16_TLS_TPREL_LO16. + (elf_micromips_howto_table_rel): Likewise for + R_MICROMIPS_TLS_DTPREL_HI16, R_MICROMIPS_TLS_DTPREL_LO16, + R_MICROMIPS_TLS_TPREL_HI16 and R_MICROMIPS_TLS_TPREL_LO16. + * elf64-mips.c (mips_elf64_howto_table_rel): Similarly. + (mips16_elf64_howto_table_rel): Similarly. + (micromips_elf64_howto_table_rel): Similarly. + * elfn32-mips.c: As for elf64-mips.c. + gas/ + * testsuite/gas/mips/pr19977.d, + * testsuite/gas/mips/pr19977.s: New test. + * testsuite/gas/mips/mips.exp: Run it. + +2025-07-12 Maciej W. Rozycki + + PR 19977: MIPS: Add missing pairing for REL PCHI/PCLO relocations + Just as with all HI/LO 16-bit partial relocations the newly-introduced + MIPSr6 PC-relative R_MIPS_PCHI16 and R_MIPS_PCLO16 relocations require + pairing for correct borrow propagation from the low part to the high + part with REL targets, another case for PR 19977. + + Unlike with absolute relocation, there is a complication here in that + both parts represent a calculation that is relative to the PC at the + individual relocation's location rather than both referring to the + location of the R_MIPS_PCHI16 relocation, normally applied to an AUIPC + instruction, the location of which is used for the run-time calculation + executed by hardware. + + To take this semantics into account, the addend of the R_MIPS_PCLO16 + relocation matching a given R_MIPS_PCHI16 relocation is expected to be + adjusted in the source assembly file for the distance between the two + relocations in a single pair, so that once both relocations have been + calculated by the linker, the expression calculated at run time is such + as if the combined 32-bit immediate was added at the location of the + AUIPC instruction. + + So for matching R_MIPS_PCHI16 and R_MIPS_PCLO16 relocations into pairs + GAS needs to check for the distance between the two relocations to be + equal to the difference between the addends supplied, and then the + linker has to subtract the low part of the distance between the two + relocations from the low part in calculating the high part, so as to + factor in any borrow. + + A further complication is that `_bfd_mips_elf_lo16_reloc' handler is + supplied with the addend differently depending on whether it has been + called by GAS via `bfd_install_relocation', or by the generic linker via + `bfd_perform_relocation'. In the former case the addend is supplied + with the relocation itself while in the latter one it comes from the + field being relocated. + + We currently ignore the addend supplied with the relocation and it works + for calculating absolute high-part relocations, because the same addend + has been previously supplied with them when `_bfd_mips_elf_hi16_reloc' + was called, however this approach does not work for the PC-relative case + because as noted above the low-part addend is different and we need to + consistently apply the distance adjustment both with GAS and LD. + + Since the supplied addend and one retrieved from field being relocated + won't ever be both nonzero, just use the sum of the two values. + + The low-part addend in `mips_elf_add_lo16_rel_addend' always comes from + the field being relocated, so there's no complication there, we just + need to apply the same adjustment. + + New linker test cases verify that the same ultimate machine code is + produced both for ELF and S-record output formats, ensuring that the + both the MIPS/ELF linker and the generic linker behave in the correct + way, consistent with each other. + +2025-07-12 Maciej W. Rozycki + + MIPS/BFD: Use helper function for LO relocation sign-extension + A calculation for LO relocations has been recently fixed with commit + ce08b3bb19b3 ("MIPS/BFD: Fix RELA handling of borrow in the generic + linker"), however it was missed that for the updated arithmetic we + already have a helper function available, `_bfd_mips_elf_sign_extend'. + + Replace the open-coded statement then with an equivalent call to said + function. No functional change. + +2025-07-12 Maciej W. Rozycki + + MIPS/LD/testsuite: Remove duplicate HI/LO relocation test dump files + There are only nonessential differences between corresponding o32 and + n32 HI/LO relocation test dump files, so reduce the number of files by + reusing the same dump between the two ABIs. Adjust test naming, also + for the n64 ABI, for consistency with other tests. + +2025-07-12 GDB Administrator + + Automatic date update in version.in + +2025-07-11 Indu Bhagat + + libsframe: testsuite: fix PR libsframe/33140 + Commit 0d4d5a2633f missed some necessary adjustments to the testcase + after rebase. SFrame FDE function start address data is now an offset + in PCREL encoding; reflect with a new flag SFRAME_F_FDE_START_ADDR_PCREL + in the header. + + Adjust the newly added testcase. + + PR libsframe/33140 SFrame test failures on x86-64 + + libsframe/testsuite/ + * libsframe.find/plt-findfre-2.c: Adjust for the new FDE func + start addr encoding. + +2025-07-11 Simon Marchi + + gdb: remove two unused includes of gdbcore.h + clangd claims they are unused. + + Change-Id: I3c5e16279ff3b59679b8262a9d24a6e515a718f5 + +2025-07-11 Simon Marchi + + gdb: fix formatting in solib.c + There are many instances of `_ (...)` that should be `_(...)`, fix them. + + Change-Id: I9715019c9b62b72208b4849f3cfd531964480dd2 + +2025-07-11 Simon Marchi + + gdb/solib-svr4: use program space from solib in find_debug_base_for_solib + Instead of using the current global program space, I think it makes + sense to fetch the program space from the solib. The comment for + solib::objfile indicates that it may be nullptr (which is true), but in + this case, the callers (all in + svr4_iterate_over_objfiles_in_search_order) find the solib from an + objfile, so we know that solib::objfile (the link in the opposite + direction) is set for these solibs at this point. + + Change-Id: I75037d0b2c39ab1b3a3792432be134e200438efe + Approved-by: Kevin Buettner + +2025-07-11 Guinevere Larsen + + gdb/record: Add support for more vmov-style instructions + This commit adds support for a few more vmov instructions: + * VMOV[LH|HL]PS + * VMOVLPD + * VMOVHP[S|D] + * VMOVDDUP + + And associated tests. The testsuite had some minor re-working, adding a + function to zero buffers, to make later tests less fragile. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for AVX conversion instructions. + WIP + + This commit adds support for instructions to convert from one type to + another, which are in the form: + * VCVTDQ2[PS|PD] + * VCVTPS2[DQ|PD] + * VCVTPD2[PS|DQ] + * VCVTSD2[SI|SS] + * VCVTSI2[SS|SD] + * VCVTSS2[SD|SI] + * VCVTTP[S|D]2DQ + * VCVTTS[S|D]2SI + + It also adds support to vpsadbw, since it was trivial and only one + instruction. Finally, I have slightly reorder the case statements to + keep them in numerical order. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for 'pack' AVX instructions + This commit adds support for the following instructions VPACK[S|U]S[WB|DW] and associated tests. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for comis instructions + This commit adds support for the following instructions: + * VCOMIS[S|D] + * VUCOMIS[S|D] + + And associanted tests. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for AVX blend instructions + This commit supports for the following instructions: + * VBLENDP[S|D] + * VBLENDVP[S|D] + * VPBLEND[D|W|VB] + + and test them. + +2025-07-11 Guinevere Larsen + + gdb/record: add support to vinsert and vextract instructions + This patch adds support for the following instructions: + * VEXTRACT[F128|I128|PS] + * VINSERT[F128|I128|PS] + * VPEXTR[B|W|D|Q] + + And associated test. For some reason, it seems that the extract + instructions deal with the output register as though it was the first + source register, so they use ModRM.r/m and VEX.B, instead of the usual + ModRM.reg and VEX.R. This meant that the opcode collision with + vbroadcastsd wasn't trivial. It can be easily solved by checking the + VEX.map_select field, so soslving it was very easy. + + The VPEXTR instructions had several complicated collisions, and notably, + vpextrw to a register works completely different to any other + instruction in the family, so the code is messy, but it should be + correct. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for more AVX broadcast instructions + This commit adds support for 3 instructions: + * VBROADCASTSS + * VBROADCASTSD + * VBROADCASTF128 + + and extends the function vpbroadcast_test to include these. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for permutation instructions + This commit adds recording support for the following instructions: + * VPERM2[I|F]128 + * VPERM[D|Q|PD|PS] + * VPERMILP[S|D] + + And associated tests. + +2025-07-11 Guinevere Larsen + + gdb/record: add support for AVX/AVX2 shuffle instructions + This commit adds support for the following instructions: + * VPSHUF[B|D|HW|LW] + * VSHUFP[S|D] + + and the associated test. + +2025-07-11 Guinevere Larsen + + gdb/record: Add support for AVX/AVX2 shift instructions + This commit adds record-full support to the following instructions: + + * VPSLL[W|D|Q|DQ] + * VPSRL[W|D|Q|DQ] + * VPSRA[W|D] + + With both dynamic and constant shifts, and the associated tests. + Notably, vpsraq is not available for AVX or AVX2 instruction sets, only + AVX512. vpsradq does not seem to be available with any instruction set. + +2025-07-11 Guinevere Larsen + + gdb/record: support more AVX arithmetic instructions + This commit adds support to the following AVX/AVX2 instructions: + * VPADD[B|W|D|Q] + * VPMUL[LW|LD|HW|HUW|UDQ] + * VXORP[S|D] + * VPAND[|N] + + This required some reworking on the loop that processes instruction + prefixes, because the opcode for VPMULLD overlapped with a valid + instruction prefix. To fix that, rather than using "goto out_prefixes", + this commit changes the infinite loop to only run while we don't find + another VEX prefix. That should be OK, as the intel manual (page 526 on + the March 2024 edition) says that the VEX prefix is always the last one. + +2025-07-11 Ezra Sitorus + + aarch64: Support for FEAT_SVE_AES2 + FEAT_SVE_AES2 implements the SVE multi-vector Advanced Encryption + Standard and 128-bit destination element polynomial multiply long + instructions, when the PE is not in Streaming SVE mode. + + aarch64: Support for FEAT_LSUI + FEAT_LSUI introduces unprivileged variants of load and store instructions so + that clearing PSTATE.PAN is never required in privileged software. + +2025-07-11 Ezra Sitorus + + aarch64: Support for FEAT_PCDPHINT + FEAT_PCDPHINT - Producer-consumer data placement hints - is an optional + ISA extension that provides hint instructions to indicate: + - a store in the current execution thread is generating data at a specific + location, which a thread of execution on one or more other observers is + waiting on. + - the thread of execution on the current PE will read a location that may not + yet have been written with the value to be consumed. + + This extension introduces: + - STSHH, a hint instruction, with operands (policies) keep and strm + - PRFM *IR*, a new prefetch memory operand. + +2025-07-11 Jens Remus + + s390: Announce s390 64-bit (s390x) SFrame V2 support in binutils + The preceding commits add s390 64-bit (s390x) support in binutils to + generate SFrame stack trace information (.sframe section) in the + assembler from CFI directives (with option --gsframe), generate .sframe + section for linker-generated .plt section in the linker, and dump SFrame + information in objdump and readelf (with option --sframe). + + binutils/ + * NEWS: Announce s390 64-bit (s390x) SFrame V2 support in + as, ld, objdump, and readelf. + + gas/ + * NEWS: Update s390 64-bit (s390x) SFrame V2 support in + assembler. + +2025-07-11 Jens Remus + + s390: sframe: Test handling of .cfi_def_cfa_register + Port x86-64 test for handling of .cfi_def_cfa_register from commit + 3602da6fa285 ("gas: sframe: fix handling of .cfi_def_cfa_register") + to s390x. + + gas/testsuite/ + PR gas/32879 + * gas/cfi-sframe/cfi-sframe.exp: Add new test for handling of + .cfi_def_cfa_register on s390x. + * gas/cfi-sframe/cfi-sframe-s390x-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-3.s: Likewise. + + Bug: https://sourceware.org/PR32879 + +2025-07-11 Jens Remus + + s390: Store SFrame CFA offset adjusted and scaled down + In SFrame V2 the size of the offsets following an SFrame FRE can be + either signed 8-bit, 16-bit, or 32-bit integer, with the largest offset + determining their size: + 1. CFA offset from CFA base register + 2. RA (stack save slot) offset from CFA, usually -48 on s390x if saved + 3. FP (stack save slot) offset from CFA, usually -72 on s390x if saved + The FP and RA offsets from CFA, when FP/RA saved on the stack, usually + have fixed values that fit into signed 8-bit SFrame offsets. Likewise + the DWARF register numbers on s390x of general registers (GR; 0-15) and + floating-point registers (FPR; 16-31), when FP/RA saved in registers. + With that the CFA offset from CFA base register has the greatest impact + on the signed SFrame offset size. + + The s390x ELF ABI defines the stack pointer (SP) to be 8-byte aligned + [1] and the CFA as SP at call site + 160 [2]. The CFA offset from CFA + base register is therefore always a multiple of 8. + + On s390x store the SFrame CFA offset from CFA base register scaled down + by the s390x-specific CFA alignment factor of 8, in addition to the + adjustment by the s390x-specific CFA adjustment of -160, to further + improve the use of signed 8-bit SFrame offsets. This is similar to the + DWARF data alignment factor getting factored out from certain offsets + stored in DWARF CFI. + + [1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame + Allocation", https://github.com/IBM/s390x-abi/releases + [2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"), + https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88 + + include/ + * sframe.h (SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR): Define + s390x-specific CFA offset alignment factor. + (SFRAME_V2_S390X_CFA_OFFSET_ENCODE, + SFRAME_V2_S390X_CFA_OFFSET_DECODE): Scale down/up by + SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR. + + libsframe/ + * doc/sframe-spec.texi (s390x, + SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR): Document s390x- + specific CFA offset alignment factor. + +2025-07-11 Jens Remus + + s390: Store SFrame CFA offset adjusted + In SFrame V2 the size of the offsets following an SFrame FRE can be + either signed 8-bit, 16-bit, or 32-bit integer, with the largest offset + determining their size: + 1. CFA offset from CFA base register + 2. RA (stack save slot) offset from CFA, usually -48 on s390x if saved + 3. FP (stack save slot) offset from CFA, usually -72 on s390x if saved + The FP and RA offsets from CFA, when FP/RA saved on the stack, usually + have fixed values that fit into signed 8-bit SFrame offsets. Likewise + the DWARF register numbers on s390x of general registers (GR; 0-15) and + floating-point registers (FPR; 16-31), when FP/RA saved in registers. + With that the CFA offset from CFA base register has the greatest impact + on the signed SFrame offset size. + + The s390x ELF ABI [1] defines the CFA as stack pointer (SP) at call + site +160. [2] Therefore the minimum CFA offset from CFA base register + on s390x is 160. This does not fit into a signed 8-bit integer and + therefore effectively prevents any use of signed 8-bit SFrame offsets + on s390x. + + For s390x store the CFA offset from CFA base register adjusted by -160 + to enable the use of signed 8-bit SFrame offsets. + + [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases + [2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"), + https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88 + + include/ + * sframe.h (SFRAME_S390X_CFA_OFFSET_ADJUSTMENT): Define + s390x-specific CFA offset adjustment. + (SFRAME_V2_S390X_CFA_OFFSET_ENCODE, + SFRAME_V2_S390X_CFA_OFFSET_DECODE): New s390x-specific + macros. Use SFRAME_S390X_CFA_OFFSET_ADJUSTMENT to en-/decode + CFA offset. + + bfd/ + * elf64-s390.c (elf_s390x_sframe_plt_fre): Use + SFRAME_V2_S390X_CFA_OFFSET_ENCODE on CFA offset to store it + adjusted and switch to 8-bit offsets. + + gas/ + * gen-sframe.c (sframe_fre_set_cfa_offset): For s390x use + SFRAME_V2_S390X_CFA_OFFSET_ENCODE on CFA offset to store it + adjusted. + (sframe_fre_get_cfa_offset): New helper. For s390x use + SFRAME_V2_S390X_CFA_OFFSET_DECODE on CFA offset to undo its + adjustment. + (sframe_xlate_do_def_cfa_register): Use new helper + sframe_fre_get_cfa_offset. + + libsframe/ + * sframe.c (sframe_fre_get_cfa_offset): For s390x use + SFRAME_V2_S390X_CFA_OFFSET_DECODE on CFA offset to undo its + adjustment. + * doc/sframe-spec.texi (s390x, + SFRAME_S390X_CFA_OFFSET_ADJUSTMENT, + SFRAME_V2_S390X_CFA_OFFSET_ENCODE, + SFRAME_V2_S390X_CFA_OFFSET_DECODE): Document s390x-specific + adjustment of CFA offset. + + libsframe/testsuite/ + * libsframe.find/plt-findfre-2.c (add_plt0_fde, add_pltn_fde): + Use SFRAME_V2_S390X_CFA_OFFSET_ENCODE to enable use of 1-byte + SFrame offsets. + + Suggested-by: Indu Bhagat + +2025-07-11 Jens Remus + + libsframe: Add test for PLT0 and PLTN with only one FRE each + On s390x the PLT0 and PLTN entries are described with one SFrame FRE + each. Add a test case for this particularity. + + libsframe/testsuite/ + * libsframe.find/find.exp (plt-findfre-2): Add new test. + * libsframe.find/plt-findfre-2.c: New test for PLT0 and PLTN + with only one FRE each. + * libsframe.find/local.mk (plt-findfre-2): Add new test. + + libsframe/ + * Makefile.in: Regenerate. + +2025-07-11 Jens Remus + + s390: Add SFrame stack trace information for .plt section + Enable SFrame stack tracing through PLT entries. Based on x86-64. + + On s390x both PLT0 and PLTn entries are 32-bytes in size. Their code + neither alters the stack pointer (SP), frame pointer (FP), nor return + address (RA) registers. Therefore the PLT0 can be represented using + a SFrame FDE of type PCINC with a single SFrame FRE and the PLTn can + be represented using a SFrame FDE of type PCMASK, with a repetition + block size of 32 (PLTn size), and a single SFrame FRE. + + Note that as both the PLT0 entry and the PLTn entries have equal size + and could both be represented using the identical SFrame FRE, the whole + .plt section on s390x could be represented using a single SFrame FDE of + type PCMASK, with a repetition block size of 32 (PLT0 and PLTn size), + and a single SFrame FRE. Keep the x86-64 logic with separate SFrame + FDEs for PLT0 and PLTn, to ease potential generalization of the .sframe + for .plt generation logic among architectures. + + bfd/ + * elf64-s390.c: Include sframe.h and sframe-api.h. + (PLT_SFRAME_FDE_START_OFFSET, SFRAME_PLT0_MAX_NUM_FRES, + SFRAME_PLTN_MAX_NUM_FRES, elf_s390x_sframe_plt_fre, + elf_s390x_sframe_plt): New .sframe template for .plt section. + (elf_s390_link_hash_table): Add plt_cfe_ctx, plt_sframe, and + sframe_plt fields. + (_bfd_s390_elf_create_sframe_plt): New function. Fill in + .sframe section for .plt section. + (_bfd_s390_elf_write_sframe_plt): New function. Write .sframe + section. + (elf_s390_create_dynamic_sections): Create .sframe section for + .plt section. + (elf_s390_late_size_sections): Call + _bfd_s390_elf_create_sframe_plt and + _bfd_s390_elf_write_sframe_plt. + (elf_s390_finish_dynamic_sections): Write .plt section start + into .sframe FDE covering .plt section. Call + _bfd_elf_merge_section_sframe on htab->plt_sframe. + + ld/ + * NEWS: Add news entry. + + ld/testsuite/ + * ld-s390/s390.exp: Add new test. + * ld-s390/sframe-plt-1.d: New linker-generated .sframe for .plt + test. + * ld-s390/sframe-simple-1.d: Adjust expected test output due to + linker-generated .sframe for .plt. + +2025-07-11 Jens Remus + + s390: Represent FP without RA saved in SFrame + If an architecture uses both SFrame RA and FP tracking SFrame assumes + that the RA offset is the 2nd offset and the FP offset is the 3rd offset + following a SFrame FRE. An architecture does not necessarily need to + save both on the stack (or in register) at the same time or even at all. + SFrame cannot represent FP without RA saved on stack (or in a register), + since it cannot distinguish whether the 2nd offset is the RA or FP + offset. + + For s390x use an invalid SFrame RA offset from CFA value of zero as + padding to represent the FP being saved when the RA is not saved. This + aligns with the existing invalid SFrame fixed RA offset from CFA value + of zero. In a stack tracer this then also naturally falls into place, + as it can skip restoring the RA in the topmost frame, if both the fixed + RA offset (from SFrame header) and the RA offset (from FDE) are zero, + without any need to test architecture-specific flags. + + include/ + * sframe.h (SFRAME_FRE_RA_OFFSET_INVALID): New define. Used as + padding offset. + * sframe-api.h (sframe_fre_get_ra_offset): Add comment that for + s390x an offset value of SFRAME_FRE_RA_OFFSET_INVALID indicates + that the RA is not saved. + + gas/ + * gen-sframe.c (get_fre_num_offsets): For s390x account padding + RA offset, if FP without RA saved. + (sframe_get_fre_offset_size): Likewise. + (output_sframe_row_entry): For s390x write a padding RA offset, + if FP without RA needs to be represented. + (sframe_do_fde): Enable FP without RA saved to be represented + on s390x. + + libsframe/ + * sframe.c (sframe_fre_get_ra_offset): Add comment that for + s390x an offset value of SFRAME_FRE_RA_OFFSET_INVALID indicates + that the RA is not saved. + * sframe-dump.c (dump_sframe_func_with_fres): Treat invalid + RA offsets as if they were undefined. Display them as "U" + to distinguish them. + * doc/sframe-spec.texi (s390x): Document s390x-specific use of + SFRAME_FRE_RA_OFFSET_INVALID to represent FP without RA saved. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Rename s390x-specific tests. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.s: Rename + to ... + * cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-2.s: This. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-2.d: Likewise. + Update test verification pattern accordingly. + * cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.s: Rename + to ... + * cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-2.s: This. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-2.d: Likewise. + Update test verification pattern accordingly. + +2025-07-11 Jens Remus + + s390: Represent FP/RA saved in register in SFrame + GCC on s390x, when in a leaf function, can be observed to save the + frame pointer (FP) and/or return address (RA) register in a floating- + point registers (FPR) instead of on the stack. This is declared using + the following CFI directive: + + .cfi_register , + + SFrame cannot represent the FP and/or RA being saved in another + register. It does only track the CFA base register (SP/FP), CFA offset + from CFA base register, and FP and RA save area offsets from CFA. + + On s390x the FP and/or RA are only saved in another FPR when in a leaf + function. That is a function that does not call any other function. + Therefore it can ever only be the topmost function in a call chain. + An unwinder by default has access to all registers of the function that + is the topmost on the call stack. Therefore no further information + is required to restore FP/RA from the FPR. + + Represent FP/RA saved in another register on s390x, by encoding the + DWARF register number shifted by one to the left with the least- + significant bit set in the offset as follows: + + offset = (regnum << 1) | 1 + + The use of the least-significant bit of the offset as indication is + possible, as the stack pointer (SP), the CFA, and any register save + area slots are 8-byte aligned according to the s390x ELF ABI: + - The stack pointer (SP) "shall maintain an 8-byte alignment". [1] + - The CFA is defined as SP at call site +160. [2] + - Pointers and 8-byte integers, such as general register values, must + be 8-byte aligned. [3] + SFrame FP and RA stack offsets must therefore always be a multiple of + 8 on s390x. Note that for the same reason the DWARF data alignment + factor is -8 on s390x (see DWARF2_CIE_DATA_ALIGNMENT). + + Add s390x-specific SFrame (error) tests for FP/RA saved in FPRs in leaf + function. + + [1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame + Allocation", https://github.com/IBM/s390x-abi/releases + [2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"), + https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88 + [3]: s390x ELF ABI, section "Fundamental Types", table "Scalar types", + https://github.com/IBM/s390x-abi/releases + + include/ + * sframe.h (SFRAME_V2_S390X_OFFSET_IS_REGNUM): New s390x- + specific macro to test whether an SFrame FP/RA offset is a DWARF + register number. + (SFRAME_V2_S390X_OFFSET_ENCODE_REGNUM): New s390x-specific macro + to encode a DWARF register number into an SFrame FP/RA offset. + (SFRAME_V2_S390X_OFFSET_DECODE_REGNUM): New s390x-specific macro + to decode an SFrame FP/RA offset into a DWARF register number. + * sframe-api.h (sframe_fre_get_fp_offset, + sframe_fre_get_fp_offset): Add comment that for s390x the offset + may be an encoded register number. + + gas/ + * gen-sframe.c (s390_sframe_xlate_do_register): New S390- + specific function. Uses SFRAME_V2_S390X_OFFSET_ENCODE_REGNUM to + represent FP/RA saved in another register on s390x. + (sframe_xlate_do_register): Invoke s390_sframe_xlate_do_register + on s390x. + + libsframe/ + * sframe.c (sframe_fre_get_fp_offset, sframe_fre_get_fp_offset): + Add comment that for s390x the offset may be an encoded register + number. + * sframe-dump.c (is_sframe_abi_arch_s390x): New helper to test + whether ABI/arch is s390x. + (dump_sframe_func_with_fres): Use + SFRAME_V2_S390X_OFFSET_IS_REGNUM and + SFRAME_V2_S390X_OFFSET_DECODE_REGNUM to dump FP/RA saved in + another register on s390x. + * doc/sframe-spec.texi (s390x): Document s390x-specific + representation of FP/RA saved in another register. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Update s390x-specific SFrame + (error) tests. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.s: Rename + to ... + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.d: + Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-1.s: This. Test + no longer triggers a warning, as SFrame can represent FP and RA + saved in registers. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: Test + now triggers a different warning, as SFrame can represent FP and + RA saved in registers, but not FP without RA saved in register. + +2025-07-11 Jens Remus + + s390: Initial support to generate .sframe from CFI directives in assembler + This introduces initial support to generate .sframe from CFI directives + in assembler on s390 64-bit (s390x). Due to SFrame V2 format + limitations it has the following limitations, some of them getting + addressed by subsequent patches, which cause generation of SFrame FDE + to be skipped: + + - SFrame FP/RA tracking only supports register contents being saved on + the stack (i.e. .cfi_offset). It does not support FP/RA register + contents being saved in other registers (i.e. .cfi_register). GCC on + s390x can be observed to save the FP/RA register contents in floating- + point registers, but only in leaf functions. + This issue is detailed further and resolved in the subsequent commit + "s390: Represent FP/RA saved in register in SFrame". + + - SFrame FP/RA tracking cannot represent FP without RA saved. This is + because the format assumes SFrame FDE offset2 to be the RA offset, if + there are two offsets, and offset3 to be the FP offset, if there are + three offsets. There is no mean to distinguish whether offset2 is the + RA or FP offset, if there are only two offsets. + This issue is detailed further and resolved in the subsequent commit + "s390: Represent FP without RA saved in SFrame". + + - SFrame assumes a dedicated FP register number. The s390x ELF ABI [1] + does only designate register 11 as preferred FP register number. In + general GCC and Clang on s390x use register 11 as frame pointer. + GCC on s390x can be observed to use register 14 as frame pointer in + the stack clash protector in the function prologue. + glibc on s390x contains hand-written assembler code that uses + register 12 as frame pointer. + + This s390x support is largely based on the AArch64 support from commit + b52c4ee46657 ("gas: generate .sframe from CFI directives"). + + The SFrame ABI/arch identifier SFRAME_ABI_S390X_ENDIAN_BIG is introduced + for s390x and added to the SFrame format specification. + + The s390x ELF ABI [1] specifies the following C calling conventions for + s390x architecture: + - Register 15 is the stack pointer (SP). + - Register 14 contains the return address (RA) at function entry. + - There is no dedicated frame pointer register. Register 11 is the + preferred frame pointer (FP). [2] GCC and Clang in general use + register 11 as frame pointer. + - The CFA is defined as SP at call site +160. [3] The SP at call site + can therefore be derived from the CFA using a SP value offset from CFA + of -160. + + The s390x ELF ABI [1] does not assign any standard save slot to each + register in the register save area of a stack frame. Neither the + return address (RA, r14) nor preferred frame pointer (FP, r11) + necessarily need to be saved. Therefore SFrame RA and FP tracking is + used. + + Support for SFrame on s390 is only enabled for the 64-bit s390x ELF ABI + (z/Architecture with 64-bit addressing mode). It is disabled for the + 32-bit s390 ELF ABI (ESA/390 or z/Architecture with 32-bit addressing + mode). + + s390x-specific SFrame assembler and linker tests are added, including + error tests for use of a non-preferred frame pointer (FP) register and + specification of a non-default return address (RA) register. + + [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases + [2]: s390x ELF ABI, commit f00421825979 ("Add information about the frame + pointer register"), + https://github.com/IBM/s390x-abi/commit/f00421825979 + [3]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"), + https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88 + + include/ + * sframe.h: Add reference to s390x architecture in comments. + (SFRAME_ABI_S390X_ENDIAN_BIG): Define SFrame ABI/arch identifier + for s390x. + (SFRAME_S390X_SP_VAL_OFFSET): Define s390x-specific SP value + offset from CFA. + + libsframe/ + * sframe.c (need_swapping): Add SFRAME_ABI_S390X_ENDIAN_BIG. + * doc/sframe-spec.texi (SFRAME_ABI_S390X_ENDIAN_BIG, s390x, + SFRAME_S390X_SP_VAL_OFFSET): Document SFrame ABI/arch identifier + for s390x, add references to s390x architecture, and document + s390x-specifics, such as the SP value offset from CFA of -160. + + gas/ + * config/tc-s390.h: s390x support to generate .sframe from CFI + directives in assembler. + (support_sframe_p): Define. + (SFRAME_CFA_SP_REG, SFRAME_CFA_FP_REG, SFRAME_CFA_RA_REG): + Define. + (sframe_ra_tracking_p): Define. + (sframe_cfa_ra_offset): Define. + (sframe_get_abi_arch): Define. + * config/tc-s390.c: s390x support to generate .sframe from CFI + directives in assembler. + (s390_sframe_cfa_sp_reg, s390_sframe_cfa_fp_reg, + s390_sframe_cfa_ra_reg): New. Initialize to DWARF register + numbers of stack pointer (SP, r15), preferred frame pointer + (FP, r11), and return address (RA, r14) registers. + (s390_support_sframe_p): New function. Return true if s390x. + (s390_sframe_ra_tracking_p): New function. Return true. + (s390_sframe_cfa_ra_offset): New function. Return + SFRAME_CFA_FIXED_RA_INVALID. + (s390_sframe_get_abi_arch): New function. Return + SFRAME_ABI_S390X_ENDIAN_BIG if s390x, otherwise zero. + * gen-sframe.c: Add reference to s390x architecture in comments. + (sframe_xlate_do_val_offset): Add support for s390x-specific + SFRAME_S390X_SP_VAL_OFFSET. + * NEWS: Add news entry. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Enable common SFrame tests for + s390x. Add s390x-specific SFrame (error) tests. + * gas/cfi-sframe/cfi-sframe-s390x-1.d: New s390x-specific SFrame + test. + * gas/cfi-sframe/cfi-sframe-s390x-1.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-2.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-err-1.d: New s390x-specific + SFrame error test that uses a non-default frame-pointer register + as CFA base register. + * gas/cfi-sframe/cfi-sframe-s390x-err-1.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-err-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-err-2.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-err-3.d: New s390x-specific + SFrame error test that uses a non-default return address + register. + * gas/cfi-sframe/cfi-sframe-s390x-err-3.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-1.d: New s390x- + specific SFrame test that saves RA and FP individually on the + stack. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-1.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.d: New + s390x-specific SFrame error test that saves FP and RA + individually, to trigger FP without RA saved. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-offset-err-1.s: Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.d: New + s390x-specific SFrame error test that saves FP and RA + individually in registers. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-1.s: + Likewise. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.d: New + s390x-specific SFrame error test that saves RA and FP + individually in registers. + * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-err-2.s: + Likewise. + + ld/testsuite/ + * ld-s390/s390.exp: Add simple SFrame test. + * ld-s390/sframe-simple-1.d: New simple SFrame test. + * ld-s390/sframe-bar.s: Likewise. + * ld-s390/sframe-foo.s: Likewise. + +2025-07-11 Jens Remus + + s390: Explicitly list linker dump tests + Generating the linker dump test list using file globbing makes it + difficult to exclude specific tests under certain circumstances. List + them explicitly instead. This enables to add tests in the future that + can be excluded. While at it reorganize how s390 linker tests get + run for s390x. + + ld/testsuite/ + * ld-s390/s390.exp: Reorganize and explicitly list linker dump + tests. + +2025-07-11 Jens Remus + + sframe: Ignore section padding when converting endianness + The .sframe section may have a trailing padding due to the architecture- + specific default section alignment. Do not treat this padding as error + when converting between target and host endianness. + + This can be observed when building Binutils with SFrame s390x support on + x86-64 for s390x using configure option "--target=s390x-ibm-linux-gnu" + and running the GAS test suite. + + While at it reuse the determined SFrame section header size. + + libsframe/ + * sframe.c (flip_sframe): Ignore .sframe section padding. Reuse + SFrame header size. + + Reported-by: Indu Bhagat + +2025-07-11 GDB Administrator + + Automatic date update in version.in + +2025-07-10 Alan Modra + + AM_PO_SUBDIRS + Swap AM_PO_SUBDIRS and ZW_GNU_GETTEXT_SISTER_DIR lines in + */configure.ac. ZW_GNU_GETTEXT_SISTER_DIR indirectly invokes + AC_REQUIRE(AM_PO_SUBDIRS) so results in AM_PO_SUBDIRS being emitted + before ZW_GNU_GETTEXT_SISTER_DIR if it hasn't already been invoked. + +2025-07-10 Alan Modra + + gas v850 md_convert_frag + The v850 md_convert_frag function oddly calls subseg_change twice + (commit 1cd986c58543). Neither call is needed, because that is done + in size_seg. + + Convert the fr_opcode fixup field back (to an opindex, not fx_r_type) + using a cast rather than a union, since we used casts when setting up + those values. I guess the union was added to silence compiler + warnings about wrong-size casts, but unfortunately results in the + wrong value being retrieved on big-endian hosts. + + Change "buffer" to a char* as there is no need to make it an + unsigned char*, and that way requires fewer casts. Finally, fix + formatting and use uintptr_t when make the rs_machine_dependent frags. + + Remove subseg_change calls from cr16, crx, mn10200, mn10300, and sh + md_convert_frag too. + +2025-07-10 Alan Modra + + union alpha_macro_arg + Rename the old enum alpha_macro_arg to alpha_macro_argset, and create + a union alpha_macro_arg to use in all the alpha_macro.emit functions. + This avoids intptr_t casts on retrieving index values and void* casts + on storing them in the alpha_macros array. + +2025-07-10 Nelson Chu + + sim: riscv: Fix build issue due to INSN_CLASS_C was changed to INSN_CLASS_ZCA + +2025-07-10 Matthieu Longo + + libiberty: sync with gcc + Import the following commits from GCC as of r16-2170-g2f2e9bcfb0fd9c: + 0fd98b6f9f2 libiberty: add routines to handle type-sensitive doubly linked lists + +2025-07-10 Nelson Chu + + RISC-V: Fixed wrong imply result for zce when -march=rv32id_zce + The entry of "zce imply zcf" needs check_implicit_for_zcf, so it needs to be + placed after the entries of "whatever imply f". Otherwise the implicit zcf + may be missed. Also merge the march-implu-zce* testcases into imply testcases. + +2025-07-10 Nelson Chu + + RISC-V: Clarify the imply rule of c + This also fix the imply result for .option rvc. + + Imply zcf when c and f and rv32 + Imply zcd when c and d + Imply zca when c + + Changed INSN_CLASS_C to INSN_CLASS_ZCA + Changed INSN_CLASS_F_AND_C to INSN_CLASS_ZCF + Changed INSN_CLASS_D_AND_C to INSN_CLASS_ZCD + Changed INSN_CLASS_ZIHINTNTL_AND_C to INSN_CLASS_ZIHINTNTL_AND_ZCA + +2025-07-10 Nelson Chu + + RISC-V: Deprecate ".option arch, -ext" for users due to its controversial use + Before we figure out the whole remove situations for ".option arch, -ext", and + have any RISC-V public spec defines it, we should just deprecate it. + +2025-07-10 GDB Administrator + + Automatic date update in version.in + +2025-07-09 Indu Bhagat + + gas: ld: sframe: add new internal header + for SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS. + + The intention of creating an abstraction like + SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS is to address the concern that there + should be a central place to enforce harmonious flags between GNU as and + ld. At the moment, the only flag that needs to be enforced is + SFRAME_F_FDE_FUNC_START_PCREL. + + sframe.h and sframe-api.h are installed headers by libsframe for the + specification and implementation respectively. Adding a definition like + SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS does not fit in either. Create a + new internal header instead to keep the definition uncoupled from + sframe.h and sframe-api.h. Rename the previously added + SFRAME_F_LD_MUSTHAVE_FLAGS to define the new + SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS. + + bfd/ + * elf-sframe.c (_bfd_elf_merge_section_sframe): Use the new + internal header and SFRAME_V2_GNU_AS_LD_ENCODING_FLAGS. + gas/ + * gen-sframe.c (output_sframe_internal): Likewise. + include/ + * sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): Move from.. + * sframe-internal.h: ..to here. New file. + +2025-07-09 Alan Modra + + Merge init_private_section_data with copy_private_section_data + init_private_section_data is used by the linker and is a special case + of copy_private_section_data that copies a reduced set of section data + from input to output. Merge the two functions, adding a link_info + param to copy_private_section_data and remove init_private_section_data. + + gas remove assorted unnecessary casts + This continues the saga of removing unnecessary casts, and making + small code tidies in gas. Hopefully this sees the last of K&R + anachronisms. + + gas standardise md_section_align + The point here is that when valueT is 64 bits and int is 32 bits, + 1 << align doesn't work for shifts larger than the size of int. (Not + that anyone is likely to use such large alignments in real code.) + + gas function arg casts + This patch removes more unnecessary arg casts in various function + calls. + + gas fixups + Remove unnecessary arg casts in fix_new and similar calls. + + gas char/unsigned char casts + This patch removes many unneeded casts to char or unsigned char. It's + worth noting that safe-ctype.h macros ISDIGIT and the like cope with + either signed or unsigned char. + In some cases a cast to unsigned char is replaced by anding with 0xff, + which accomplishes the same thing but doesn't rely on char being eight + bits. The patch also removes pointer casts, and a few unsigned char + pointer variables. + + gas alpha sign extension macros + Use standard sign extend and range checking using unsigned + expressions that don't rely on implementation defined right shifts or + size of short and int. + +2025-07-09 Alan Modra + + gas md_number_to_chars + Calls to md_number_to_chars don't need to cast their value arg (*). + Remove those casts. avr_output_property_recode made a call to + md_number_to_chars with size of 1. Simplify that. tc-bpf.c + md_convert_frag used write_insn_bytes that simply copied input to + output. Dispense with that nonsense, and similarly in a couple of + other places where md_number_to_chars was called with size 1. + + *) unless the value arg is an expression that needs a cast, eg. tic54x + emit_insn where the shift left could trigger signed overflow UB + without a cast. + +2025-07-09 Alan Modra + + z8k opcode_entry_type + z8k opcode_entry_type.func is never used as a function pointer, only + as a pointer to a pseudo_typeS. Change it to a void*. + + gas various other void* casts + This removes assorted unneeded casts of void* pointers, and casts when + passing args to void* parameters or storing to void* pointers. The + patch also changes obj-coff.c stack_push to take a void* parameter, + and replaces an odd memcpy in tc-metag.c find_insn_templates with a + simple assignment. + + gas various other const pointer changes + This removes a bunch of casts involving const pointers, in some cases + by making variables const pointers so a cast is not needed. In a + couple of places the cast hid errors with "&array" written rather than + "array", see iq2000_macro_defs and s_pru_align. tc-xgate.c cmp_opcode + is changed to be the standard qsort predicate to avoid a function + cast. + + gas d30v_insn plus other non-const pointers + d30v has a bunch of casts that are only needed due to various types + missing a const. Fix that. + + gas alloc casts + All of the various memory allocation function return a "void *" + pointer, which needs no cast to assign to other pointer types. + + gas bfd_put and bfd_get arg casts + bfd_{h_,}put_* and bfd_{h_,}get_* have "void *" pointer params + nowadays. We don't need casts on their pointer args. We also don't + need to cast values passed to bfd_put. + + gas NULL casts + This removes many unnecessary NULL casts. I'm also adding a few arg + casts in concat calls, to make the code consistent. Advice from quite + a few years ago was that it's better to use the exact type for args + corresponding to function ellipses, in case NULL is defined as plain + 0. (I think that happened with some early 64-bit systems. Plain NULL + ought to be OK nowadays.) + + gas s3_FAIL and s7_FAIL + s3_FAIL is defined as 0x80000000 which is unsigned, but everywhere it + is used it is cast to int. Get rid of that silliness, and likewise + for s7_FAIL. + + gas more enum casts + Remove more unnecessary enum casts. + + gas bfd_reloc_code_real_type + Enumeration constants are integer types, so there should be no need to + cast such constants to int in expressions. (Perhaps some older gccs + warned, I checked back to gcc-4.5.) Remove some of those unnecessary + casts. Also remove unnecessary casts to bfd_reloc_code_real_type. + + gas add_ecoff_symbol + * ecoff.c: Remove unnecessary arg casts in add_ecoff_symbol + calls throughout file. + +2025-07-09 Alan Modra + + gas frag_var + Many frag_var calls have unnecessary casts on arguments, no doubt from + the days when binutils was written for K&R C. (ie. functions were not + prototyped so you needed to cast anything that didn't match the + expected type after default promotions, as you still do for args + matching a function ellipsis.) Remove those casts. + + * config/tc-alpha.c (s_alpha_comm): Use offset_T for cur_size + to avoid need for casts. Remove casts from frag_var args. + * config/tc-ia64.c (obj_elf_vms_common): Remove casts from + frag_var args. + * config/tc-m32r.c (m32r_scomm): Likewise. + * config/tc-m68hc11.c (build_jump_insn): Likewise. + (build_dbranch_insn): Likewise. + * config/tc-m68k.c (md_assemble): Likewise. + * config/tc-microblaze.c (microblaze_s_lcomm): Likewise. + * config/tc-mmix.c (s_loc): Likewise. + * config/tc-ppc.c (ppc_elf_lcomm, ppc_comm): Likewise. + * config/tc-score.c (s3_s_score_lcomm): Likewise. + * config/tc-score7.c (s7_s_score_lcomm): Likewise. + * config/tc-sh.c (sh_cons_align): Likewise. + * config/tc-sparc.c (s_reserve, s_common): Likewise. + (sparc_cons_align): Likewise. + * config/tc-tic4x.c (tic4x_seg_alloc, tic4x_bss): Likewise. + * config/tc-tic54x.c (tic54x_bss, tic54x_space): Likewise. + (tic54x_usect, tic54x_field): Likewise. + * config/tc-tic6x.c (s_tic6x_scomm): Likewise. + * config/tc-v850.c (v850_offset, v850_comm): Likewise. + * frags.c (frag_align, frag_align_pattern, frag_align_code): Likewise. + * gen-sframe.c (output_sframe_row_entry): Likewise. + (output_sframe_funcdesc): Likewise. + * read.c (s_fill, do_org, s_space, emit_leb128_expr): Likewise. + * symbols.c (colon)): Likewise. + +2025-07-09 Alan Modra + + gas pointer to int and vice versa + Use "intptr_t" or "uintptr_t" for these conversions, not "long" which + is wrong on LLP64 systems, or "size_t" which is better but still not + the correct type. + + * config/tc-alpha.c (emit_ldXu, emit_ldX, emit_uldXu, emit_uldX), + (emit_stX, emit_ustX, emit_sextX): Use correct type when + converting vlgsize pointer to in. Use "int" rather than + "long" for result. + * config/tc-ia64.c (generate_unwind_image): Use intptr_t cast + when passing personality_routine to frag_var. + * config/tc-ppc.c (ppc_frob_symbol ): Use uintptr_t cast + when converting symbol pointer to valueT. + * config/tc-v850.c (md_assemble): Use intptr_t cast when + loading integer opindex. + +2025-07-09 GDB Administrator + + Automatic date update in version.in + +2025-07-08 Alice Carlotti + + aarch64: Add support for FEAT_SVE2p2 and FEAT_SME2p2 + + aarch64: Reorder virtual feature dependencies + This will improve readability when more combinations of "SVE* or SME*" + are added. + +2025-07-08 First Last + + gdb/reverse: Add 2 AVX instructions VADDSUBPS and VADDSUBPD + add support to recording 2 missing AVX instructions: vaddsubps and vaddsubpd, and add associated tests. + + Approved-By: Guinevere Larsen + +2025-07-08 Vladimir Mezentsev + + gprofng: support external debug info + Use bfd_follow_gnu_debuglink() and bfd_follow_gnu_debugaltlink() to find files + with debug info. + If necessary, gprofng-archive copies these files to EXP/archives. + + For each executable, gprofng creates the Elf class twice. + One of them was a memory leak. + Fixed this by adding a new argument to Stabs::Stabs(). + + gprofng/ChangeLog + 2025-07-07 Vladimir Mezentsev + + PR 32147 + PR 30194 + * src/Disasm.cc (get_funcname_in_plt): Use the executable file instead + of the debug information file. + * src/Dwarf.h: Define debug_alt_strSec. + * src/DwarfLib.cc: Add support for DW_FORM_GNU_ref_alt, + DW_FORM_GNU_strp_alt. + * src/Elf.h (find_gnu_debug_files, get_dwr_section): New functions. + * src/Elf.cc: Likewise. + * src/Experiment.cc (copy_file): Add the const qualifier. + * src/Experiment.h: Likewise. + * src/LoadObject.cc (get_elf, openDebugInfo): Find files with debug info. + * src/LoadObject.h: Remove unused variables. + * src/Module.cc: Remove an argument in openDebugInfo(). + * src/Stabs.cc (Stabs::Stabs): Add the Elf* argument. + * src/Stabs.h: Likewise. + * src/gp-archive.cc: Archive files with debug info. + * src/gp-archive.h (archive_file): New function. + +2025-07-08 Tom Tromey + + Fix wchar.exp test case per review + A recent patch of mine modified wchar.exp, but I failed to notice one + part of the review. This patch updates the code to conform to the + review comments. + +2025-07-08 Nick Clifton + + New Malay translation for bfd/ and new Spanish translation for gas/ + +2025-07-08 Mark Goncharov + + RISC-V: Fix libpath_suffix selection for ldscript + When building a cross-compiler ld for RISC-V Linux systems, you can specify + target=riscv64*-linux* to create a linker that supports both 32-bit + (-march=rv32*) and 64-bit (-march=rv64*) architectures. The specified -march + value populates the EMULATION_NAME variable, which determines the default + linker script selection. For proper riscv64 target support, the build process + must prepare both elf32lriscv* and elf64lriscv* linker scripts. These should + align with the standard RISC-V Linux sysroot directory structure. + +2025-07-08 Nelson Chu + + RISC-V: Fixed mapping symbol for .option norvc directive + + RISC-V: Fixed dis-assembler to set correct xlen from mapping symbol + + RISC-V: Fixed that .option push/pop won't recover the xlen + + RISC-V: Added testcase to show the current rvc and xlen problems + +2025-07-08 Linsen Zhou + + RISC-V: Bind defined symbol locally in PIE + Reference commit 1dcb9720d62cd053a72c31881b7724ce9f74332c + + bfd/ + * elfnn-riscv.c (RISCV_COPY_INPUT_RELOC): Bind defined symbol + locally in PIE. + + ld/ + * testsuite/ld-riscv-elf/pie-bind-locally-a.s: New test source. + * testsuite/ld-riscv-elf/pie-bind-locally-b.s: Likewise. + * testsuite/ld-riscv-elf/pie-bind-locally-rv32.d: New testcase. + * testsuite/ld-riscv-elf/pie-bind-locally-rv64.d: Likewise. + +2025-07-08 GDB Administrator + + Automatic date update in version.in + +2025-07-07 Vladimir Mezentsev + + gprofng: remove ElfReloc class and unused functions and declarations + class ElfReloc is not used after we started use libbfd. + Removed ElfReloc and other unused declarations. + + gprofng/ChangeLog + 2025-07-03 Vladimir Mezentsev + + * src/Disasm.cc: Remove unused functions and variables. + * src/Disasm.h: Likewise. + * src/Dwarf.cc: Likewise. + * src/DwarfLib.cc: Likewise. + * src/DwarfLib.h: Likewise. + * src/Elf.cc: Likewise. + * src/Elf.h: Likewise. + * src/Stabs.cc: Likewise. + * src/Stabs.h: Likewise. + +2025-07-07 Tom Tromey + + Correctly handle L'\\' + Hannes filed a bug that pointed out that: + + print L'\\' + + ... did not work correctly. The bug is in convert_escape, which + simply transcribes the backslash character, rather than convert it + between encodings. + + This patch fixes the error. I also turned a macro into a lambda to + clean up this code a little. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33124 + Reviewed-By: Tom de Vries + Tested-By: Hannes Domani + +2025-07-07 WANG Xuerui + + LoongArch: Allow to relax instructions into NOPs after handling alignment + Right now, LoongArch linker relaxation is 2-pass, since after alignment + is done, byte deletion can no longer happen. However, as the alignment + pass also shrinks text sections, new relaxation chances may well be + created after alignment is done. Although at this point we can no longer + delete unused instructions without disturbing alignment, we can still + replace them with NOPs; popular LoongArch micro-architectures can + eliminate NOPs during execution, so we can expect a (very) slight + performance improvement from those late-created relaxation chances. + + To achieve this, the number of relax passes is raised to 3 for + LoongArch, and every relaxation handler except loongarch_relax_align is + migrated to a new helper loongarch_relax_delete_or_nop, that either + deletes bytes or fills the bytes to be "deleted" with NOPs, depending on + whether the containing section already has undergone alignment. Also, + since no byte can be deleted during this relax pass, in the pass the + pending_delete_ops structure is no longer allocated, and + loongarch_calc_relaxed_addr(x) degrades to the trivial "return x" in + this case. + + In addition, previously when calculating distances to symbols, an + extra segment alignment must be considered, because alignment may + increase distance between sites. However in the newly added 3rd pass + code size can no longer increase for "closed" sections, so we can skip + the adjustment for them to allow for a few more relaxation chances. + + A simple way to roughly measure this change's effectiveness is to check + how many pcalau12i + addi.d pairs are relaxed into pcaddi's. Taking a + Firefox 140.0.2 test build of mine as an example: + + Before: 47842 pcaddi's in libxul.so + After: 48089 + + This is a 0.5% increase, which is kind of acceptable for a peephole + optimization like this; of which 9 are due to the "relax"ed symbol + distance treatment. + +2025-07-07 GDB Administrator + + Automatic date update in version.in + +2025-07-06 Jens Remus + + ld: bfd: sframe: Update section size also for relocatable links + For relocatable links the output .sframe section size may be wrong. + This can be observed when dumping the SFrame information from the x86-64 + sframe-reloc-1 test: + + Name Address Off Size + .sframe 0000000000000000 000110 00007f + + Offset Type Symbol's Value Symbol's Name + Addend + 000000000000001c R_X86_64_PC32 0000000000000000 .text + 1c + 0000000000000030 R_X86_64_PC32 0000000000000000 .text + 65 + + 0x00000000 e2de0201 0300f800 02000000 08000000 ................ + 0x00000010 1e000000 00000000 28000000 00000000 ........(....... + 0x00000020 35000000 00000000 04000000 00000000 5............... + 0x00000030 00000000 25000000 0f000000 04000000 ....%........... + offset 1st FRE---^^^^^^^^ ^^^^^^^^---number of FREs + 0x00000040 00000000 00030801 0510f004 0410f034 ...............4 + FDE info---^^ | begin of FDEs + 0x00000050 0508f000 03080105 10f00404 10f02405 ..............$. + 11111112222222223333333334444---FRE 1, 2, 3, 4 + 0x00000060 08f00000 00000000 00000000 00000000 ................ + 4444^^^^... + 0x00000070 00000000 00000000 00000000 000000 ............... + ...^^^^^^---excessive section + + When running the x86-64 test cross build on a big-endian system, such + as s390x, objdump and readelf fail to dump the SFrame information with + the following error message: + + Error: SFrame decode failure: Buffer does not contain SFrame data. + + This is because the following check in flip_sframe() fails, which gets + only invoked if the endianness of the SFrame data is different from the + host system one: + + /* All FDEs and FREs must have been endian flipped by now. */ + if ((j != ihp->sfh_num_fres) || (bytes_flipped != (buf_size - hdrsz))) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + With: + j=8, ihp->sfh_num_fres=8, bytes_flipped=70, buf_size=127, hdrsz=28 + + While at it, remove the incorrect code comment. There is no + relationship between "do not update size" and the fact that the + "contents have not been relocated". + + bfd/ + * elf-sframe.c (_bfd_elf_write_section_sframe): Update section + size also for relocatable links. + +2025-07-06 Indu Bhagat + + NEWS: sframe: mention new semantics for SFrame FDE function start addr + The SFrame FDE's function start address is always emitted as follows by + GAS and ld: it is the offset of the start PC of the respective function + from the FDE field itself. + + GAS and ld will emit a flag SFRAME_F_FDE_FUNC_START_PCREL set to 1 + when emitting the field in this encoding. + + * binutils/NEWS: Announce the change of encoding for SFrame FDE + func start addr field. + * gas/NEWS: Announce the emission of new flag + SFRAME_F_FDE_FUNC_START_PCREL. + * ld/NEWS: Likewise. Relocatable links are now fixed. + +2025-07-06 Indu Bhagat + + ld: bfd: sframe: fix incorrect r_offset in RELA entries + PR/32666 Incorrect .rela.sframe when using ld -r + + Input SFrame sections are merged using _bfd_elf_merge_section_sframe (), + which clubs all SFrame FDEs together in one blob and all SFrame FREs in + another. This, of course, means the offset of an SFrame FDE in the output + section cannot be simply derived from the output_offset of the sections. + + Fix this by providing _bfd_elf_sframe_section_offset () which returns + the new offset of the SFrame FDE in the merged SFrame section. + + Unlike EH_Frame sections, which also use the _bfd_elf_section_offset (), + to update the r_offset, SFrame sections have distinct merging semantics. + In case of SFrame, the SFrame FDE will not simply sit at location + "sec->output_offset + offset of SFrame FDE in sec". Recall that information + layout in an SFrame section is as follows: + SFrame Header + SFrame FDE 1 + SFrame FDE 2 + ... + SFrame FDEn + SFrame FREs (Frame Row Entries) + Note how the SFrame FDEs and SFrame FREs are clubber together in groups + of their own. + + Next, also note how the elf_link_input_bfd () does a: + irela->r_offset += o->output_offset; + This, however, needs to be avoided for SFrame sections because the + placement of all FDEs is at the beginning of the section. So, rather than + conditionalizing this as follows: + if (o->sec_info_type != SEC_INFO_TYPE_SFRAME) + irela->r_offset += o->output_offset; + the implementation in _bfd_elf_sframe_section_offset () does a reverse + adjustment, so that the generic parts of the linking process in + elf_link_input_bfd () are not made to do SFrame specific adjustments. + + Add a new enum to track the current state of the SFrame input section + during the linking process (SFRAME_SEC_DECODED, SFRAME_SEC_MERGED) for + each input SFrame section. This is then used to assert an assumption + that _bfd_elf_sframe_section_offset () is being used on an input SFrame + sections which have not been merged (via + _bfd_elf_merge_section_sframe ()) yet. + + bfd/ + * elf-bfd.h: New declaration. + * elf-sframe.c (_bfd_elf_sframe_section_offset): New definition. + * elf.c (_bfd_elf_section_offset): Adjust offset if SFrame + section. + ld/testsuite/ + * ld-x86-64/x86-64.exp: New test. + * ld-x86-64/sframe-reloc-1.d: New test. + +2025-07-06 Indu Bhagat + + bfd: gas: ld: libsframe: adopt new encoding for FDE func start addr field + This patch convenes a set of changes in bfd, gas, ld, libsframe towards + moving to the new encoding for the 'sfde_func_start_address' field in + SFrame FDE. + + First, gas must now mark all SFrame sections with the new flag + SFRAME_F_FDE_FUNC_START_PCREL. gas was already emitting the field + in the said encoding. + + * gas/gen-sframe.c (output_sframe_internal): Emit the flag + SFRAME_F_FDE_FUNC_START_PCREL. + + Similarly for ld, adopt the new semantics of sfde_func_start_address + consistently. This means: + - When merging SFrame sections, check that all input SFrame sections + have the SFRAME_F_FDE_FUNC_START_PCREL flag set. If the check + fails, ld errors out. + - When merging SFrame sections, keep even the in-memory contents of + the FDE function start address (buffer passed to libsframe + sframe_encoder_write () for writing out) encoded in the new + semantics. While it is, in theory, possible that instead of doing this + change here, we adjust the value of sfde_func_start_address at the final + write (sframe_encoder_write) time. But latter is not favorable for + maintenanance and may be generally confusing for developers. + - When creating SFrame for PLT entries, emit flag + SFRAME_F_FDE_FUNC_START_PCREL. + + include/ + * sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): New definition. + bfd/ + * elf-sframe.c (_bfd_elf_merge_section_sframe): Check for flag + combinatation SFRAME_F_LD_MUSTHAVE_FLAGS set for all input and + output SFrame sections. If not, error out. Also, adopt the new + semantics of function start address encoding. + * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Emit flag + SFRAME_F_FDE_FUNC_START_PCREL. + + Next, for dumping SFrame sections, now that we are emitting the same + encoding in GAS, non-relocatable and relocatable SFrame links, it is the + time to set relocate to TRUE in debug_displays[]. + + binutils/ + * dwarf.c (struct dwarf_section_display): Allow sframe sections + to now be relocated. + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Update the + test. Relocatable SFrame sections now display non-zero value + (appropriate function start address). + + Now, as the SFrame sections on-disk and in-memory use the new semantics of + sfde_func_start_address encoding (i.e., function start address is the + offset from the sfde_func_start_address field to the start PC), the + calculation to make it human readable (i.e., relatable to the addresses + in .text sections) needs adjustment. + + libsframe/ + * sframe-dump.c (dump_sframe_func_with_fres): Adjust the + function start address for dumping. + + Now that both the emission of the new encoding, and the relocation of + sections before dumping them is in place, it is time to adjust the + testcases. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-aarch64-1.d: Update expected output + to include SFRAME_F_FDE_FUNC_START_PCREL instead of NONE. + * gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-aarch64-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-aarch64-4.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-10.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-11.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-9.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: Likewise. + * gas/cfi-sframe/common-empty-1.d: Likewise. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + ld/testsuite/ + * ld-aarch64/sframe-simple-1.d: Update expected output to + include SFRAME_F_FDE_FUNC_START_PCREL. + * ld-x86-64/sframe-ibt-plt-1.d: Likewise. + * ld-x86-64/sframe-plt-1.d: Likewise. + * ld-x86-64/sframe-pltgot-1.d: Likewise. + * ld-x86-64/sframe-pltgot-2.d: Likewise. + * ld-x86-64/sframe-simple-1.d: Likewise. + + Naturally, the change of semantics for 'SFrame FDE function start address' + has consequences on the implementation in libsframe. As per the new + semantics: + - Function start address in the SFrame FDE (sfde_func_start_address) + is an offset from the FDE function start address field to the start + PC of the associated function. + + Note that, the libsframe library brings the SFrame section contents into + its own memory to create a sframe_decoder_ctx object via sframe_decode + (). Many internal and user-interfacing APIs then may use + sframe_decoder_ctx object to interact and fulfill the work. + + In context of changing semantics for sfde_func_start_address, following + relevant examples may help understand the impact: + - sframe_find_fre () finds a the SFrame stack trace data (SFrame FRE) + given a lookup offset (offset of lookup_pc from the start of SFrame + section). Now that the sfde_func_start_address includes the + distance from the sfde_func_start_address field to the start of + SFrame section itself, the comparison checks of + sfde_func_start_address with the incoming lookup offset need + adjustment. + - Some internal functions (sframe_get_funcdesc_with_addr_internal () + finds SFrame FDE by using binary seach comparing + sfde_func_start_address fields, etc.) need adjustments. + - sframe_encoder_write () sorts the SFrame FDEs before writing out + the SFrame data. Sorting of SFrame FDE via the internal function + sframe_sort_funcdesc() needs adjustments: the new encoding of + sfde_func_start_address means the distances are not from the same + anchor, so cannot be sorted directly. + + This patch takes the approach of adding a new internal function: + - sframe_decoder_get_secrel_func_start_addr (): This function returns + the offset of the start PC of the function from the start of SFrame + section, i.e., it gives a section-relative offset. + + As the sframe_decoder_get_secrel_func_start_addr () API needs the value + of the function index in the FDE list, another internal API needs + sframe_fre_check_range_p () adjustments too. + + Sorting the FDEs (via sframe_sort_funcdesc ()) is done by first bringing + all offsets in sfde_func_start_address relative to start of SFrame + section, followed by sorting, and then readjusting the offsets accroding + to the new position in the FDE list. + + libsframe/ + * sframe.c (sframe_decoder_get_secrel_func_start_addr): New + static function. + (sframe_fre_check_range_p): Adjust the interface a bit. + (sframe_get_funcdesc_with_addr_internal): Use + sframe_decoder_get_secrel_func_start_addr () when comparing + sfde_func_start_address with user input offset. + (sframe_find_fre): Adopt the new semantics. + (sframe_sort_funcdesc): Likewise. + + For the libsframe testsuite, use the new encoding for FDE func start + addr: distance between the FDE sfde_func_start_address field and the + start PC of the function itself. + + Use SFRAME_F_FDE_FUNC_START_PCREL flag, though the sframe_encode () + interface in libsframe applies no sanity checks for the encoding itself. + + libsframe/testsuite/ + * libsframe.find/findfre-1.c: Adjust to use the new + SFRAME_F_FDE_FUNC_START_PCREL specific encoding. + * libsframe.find/findfunc-1.c: Likewise. + * libsframe.find/plt-findfre-1.c: Likewise. + * libsframe/testsuite/libsframe.decode/DATA2: Update data file + due to usage of new SFRAME_F_FDE_FUNC_START_PCREL flag. + * libsframe/testsuite/libsframe.encode/encode-1.c: Use flag + SFRAME_F_FDE_FUNC_START_PCREL. + +2025-07-06 Indu Bhagat + + objdump, readelf: sframe: apply relocations before textual dump + PR libsframe/32589 - function start address is zero in SFrame section dump + + Currently, readelf and objdump display the SFrame sections in ET_REL + object files with function start addresses of each function as 0. This + makes it difficult to correlate SFrame stack trace information with the + individual functions in the object file. + + For objdump, use the dump_dwarf () interface to dump SFrame section. + Similarly, for readelf, use the display_debug_section () interface to + dump SFrame section. These existing interfaces (for DWARF debug + sections) already support relocating the section contents before + dumping, so lets use them for SFrame sections as well. + + When adding a new entry for SFrame in debug_option_table[], use char + 'nil' and the option name of "sframe-internal-only". This is done so + that there is no additional (unnecessary) user-exposed ways of dumping + SFrame sections. Additionally, we explicitly disallow the + "sframe-internal-only" from external/user input in --dwarf (objdump). + Similarly, "sframe-internal-only" is explicitly matched and disallowed + from --debug-dump (readelf). + + For objdump and readelf, we continue to keep the same error messaging as + earlier: + + $ objdump --sframe=sframe bubble_sort.o + ... + No sframe section present + + $ objdump --sframe=.sfram bubble_sort.o + ... + No .sfram section present + + $ objdump --sframe=sframe-internal-only sort + ... + No sframe-internal-only section present + + Similarly for readelf: + + $ readelf --sframe= bubble_sort.o + readelf: Error: Section name must be provided + $ readelf --sframe=.sfram bubble_sort.o + readelf: Warning: Section '.sfram' was not dumped because it does not exist + $ readelf --sframe=sframe bubble_sort.o + readelf: Warning: Section 'sframe' was not dumped because it does not exist + + PS: Note how this patch adds a new entry to debug_displays[] with a + relocate value set to FALSE. This will be set to TRUE in a subsequent + patch ("bfd: gas: ld: libsframe: emit func start addr field as an offset + from FDE") when fixes are made to emit the value of the + 'sfde_func_start_address' field in the new encoding + SFRAME_F_FDE_FUNC_START_PCREL across gas and ld. + + binutils/ + * dwarf.c (display_sframe): New definition. + (dwarf_select_sections_all): Enable SFrame section too. + (struct dwarf_section_display): Add entry for SFrame section. + * dwarf.h (enum dwarf_section_display_enum): Add enumerator for + SFrame. + * objdump.c (dump_section_sframe): Remove. + (dump_sframe_section): Add new definition. + (dump_bfd): Use dump_sframe_section. + * binutils/readelf.c (dump_section_as_sframe): Remove. + +2025-07-06 Indu Bhagat + + include: sframe: doc: define new flag SFRAME_F_FDE_FUNC_START_PCREL + Add a new flag SFRAME_F_FDE_FUNC_START_PCREL to SFrame stack trace + format. If set, this flag indicates that the function start address + field (sfde_func_start_address) is the offset to the function start + address from the SFrame FDE function start address field itself. + + Such an encoding is friendlier to the exisitng PC-REL relocations + available in the ABIs supported in SFrame: AMD64 (R_X86_64_PC32) and + AArch64 (R_AARCH64_PREL32). In subsequent patches, we will make the + implementation in gas and ld to both: + - emit the values in the same (above-mentioned) encoding uniformly. + - set the flag SFRAME_F_FDE_FUNC_START_PCREL in the SFrame header + for consumers to be able to distinguish. + + Define SFRAME_V2_F_ALL_FLAGS in sframe.h to help keep the implementation + less error-prone by keeping a set of all defined flags at a central + place. Adjust the check in sframe_header_sanity_check_p () to use the + SFRAME_V2_F_ALL_FLAGS instead. + + Add documentation for SFRAME_F_FDE_FUNC_START_PCREL. Update the + documentation about the encoding of the sfde_func_start_address field. + + Also, update the section "Changes from Version 1 to Version 2" to + include the specification of the new flag SFRAME_F_FDE_FUNC_START_PCREL + as an erratum to the SFrame Version 2 specification. + + include/ + * sframe.h (SFRAME_F_FDE_FUNC_START_PCREL): New definition. + (SFRAME_V2_F_ALL_FLAGS): Likewise. + libsframe/ + * sframe-dump.c (dump_sframe_header_flags): Update to include + the new flag SFRAME_F_FDE_FUNC_START_PCREL. + * sframe.c (sframe_header_sanity_check_p): Use + SFRAME_V2_F_ALL_FLAGS. + libsframe/doc/ + * sframe-spec.texi: Add details about the new flag. Also update + the defails about the sfde_func_start_address encoding. + +2025-07-06 Indu Bhagat + + include: libsframe: add APIs for offsetof FDE func start addr field + These APIs will be later used by the linker to arrange SFrame FDEs in + the output SFrame section. + + include/ + * sframe-api.h (sframe_decoder_get_offsetof_fde_start_addr): New + declaration. + (sframe_encoder_get_offsetof_fde_start_addr): Likewise. + + libsframe/ + * libsframe.ver: List the new APIs. + * sframe.c (sframe_decoder_get_offsetof_fde_start_addr): New + definition. + (sframe_encoder_get_offsetof_fde_start_addr): Likewise. + +2025-07-06 Indu Bhagat + + libsframe: refactor code for dumping section flags + To prepare code for accommodating new flag additions easily as the + format evolves. + + libsframe/ + * sframe-dump.c (SFRAME_HEADER_FLAGS_STR_MAX_LEN): Remove. + (dump_sframe_header_flags): .. to here. New definition. + (PRINT_FLAG): New definition. + (dump_sframe_header): Move some implementation from here .. + +2025-07-06 Indu Bhagat + + include: libsframe: add APIs for SFrame header flags + Add new APIs, one each for getting flags from the SFrame decoder and + SFrame encoder context objects respectively. + + These will later be used by the linker to uniformly access the flags, + given the SFrame decoder and SFrame encoder objects. + + Use the new API, where applicable, within libsframe. + + include/ + * sframe-api.h (sframe_decoder_get_flags): New declaration. + (sframe_encoder_get_flags): Likewise. + libsframe/ + * libsframe.ver: List new APIs. + * sframe.c (sframe_decoder_get_flags): New definition. + (sframe_encoder_get_flags): Likewise. + (sframe_get_funcdesc_with_addr_internal): Use the new API. + (sframe_encoder_get_flags): Likewise. + (sframe_encoder_write_sframe): Likewise. + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Remove empty pic-and-nonpic-1-r6.s file + It was never used, pushed by mistake along with pic-and-nonpic-1a-r6.s. + +2025-07-06 Alan Modra + + MIPS: Correct HI/LO rela reloc howto special_function entries + The patch corrects the mips16 and micromips rela tables to *not* + use _bfd_mips_elf_{hi,lo}16_reloc. These special functions are + inappropriate for RELA relocs where addends are in the reloc rather + than in the section contents. See corresponding rela R_MIPS howtos. + + bfd/ + * elf64-mips.c (mips16_elf64_howto_table_rela) + : Use _bfd_mips_elf_generic_reloc + special_function. + (micromips_elf64_howto_table_rela) + : Similarly. + * elfn32-mips.c: As for elf64-mips.c. + +2025-07-06 Maciej W. Rozycki + + MIPS/BFD: Fix RELA handling of borrow in the generic linker + Fix an issue with `_bfd_mips_elf_generic_reloc' not taking into account + any borrow from the lower part in the handling of relocations of the + HI/LO kind and resulting in incorrect calculations made for RELA targets + in the generic used for non-ELF output such as S-records. This doesn't + trigger for REL targets because they call `_bfd_mips_elf_generic_reloc' + indirectly from `_bfd_mips_elf_lo16_reloc' so as to obtain a complete + 32-bit addend from relocation pairs and in calculating the addend the + latter function uses a hack to work around the lack of borrow handling + in the former function. + + The MIPS/ELF linker is unaffected as it uses its own calculations. + + Correct the calculation of the relevant partial relocations made in + `_bfd_mips_elf_generic_reloc' then to take the borrow into account and + remove the hack from `_bfd_mips_elf_lo16_reloc' as no longer needed. + + Add generic linker test cases accordingly expecting the same disassembly + from srec output produced as from ELF output produced by the MIPS/ELF + linker. + +2025-07-06 Maciej W. Rozycki + + MIPS/testsuite: Expand GAS and LD HI/LO relocation coverage + Expand test coverage for HI/LO relocation handling and add conventional + MIPS and microMIPS GAS tests as well as conventional MIPS, microMIPS, + and MIPS16e2 LD tests, covering R_MIPS_HI16, R_MIPS_LO16, R_MIPS16_HI16, + R_MIPS16_LO16, R_MICROMIPS_HI16, and R_MICROMIPS_LO16 relocations, as + well as 64-bit R_MIPS_HIGHEST, R_MIPS_HIGHER, R_MICROMIPS_HIGHEST, and + R_MICROMIPS_HIGHER relocations. + + Modify the linker script so as to retain the `.MIPS.abiflags' section so + as to disassemble MIPS16e2 code correctly, as MIPS16e2 ASE information + is only carried in that section and not in ELF file header's `e_flags'. + + MIPS16e2 and microMIPS code requires at least the MIPS32r2 ISA (or the + MIPS64r2 one for the n32 and n64 ABIs), which is incompatible with the + `mips:5900' linker output architecture and causes link failures such as: + + ./ld-new: tmpdir/mips-hilo1.o: linking mips:isa32r2 module with previous mips:5900 modules + ./ld-new: failed to merge target specific data of file tmpdir/mips-hilo1.o + + Therefore exclude `mips*el-ps2-elf*' targets from microMIPS and MIPS16e2 + LD testing. + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Switch mips16-hilo tests to new disassembly format + Switch the o32 and n32 mips16-hilo MIPS LD tests to the new disassembly + format, to reduce discrepancies in output in preparation to reuse for + generic linker tests. + + Taking the first line of disassembly output as an example the difference + is: + + 00500000 6c00 li a0,0 + + vs: + + 0x0000000000500000 6c00 li a0,0 + + for ELF and srec input respectively with the currently used older format + requested with `--prefix-addresses', but with the new disassembly format + it is exactly the same between the two input formats and no information + that we need is lost in the transition: + + 500000: 6c00 li a0,0 + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Remove symbol table output from mips16-hilo tests + The o32 and n32 mips16-hilo MIPS LD tests request symbol table output + only to discard it in matching. The symbol table is not relevant to + these tests, so remove it from output requested and adjust matching + patterns accordingly. + + MIPS/testsuite: Fix %hi usage across MIPS16 GAS/LD tests + Fix a couple of places in MIPS GAS and LD R_MIPS16_HI16/R_MIPS16_LO16 + relocation tests where the %hi operator has been incorrectly used, but + the %lo operator is expected to complement the preceding %hi operation. + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Fix mips16-hilo IRIX 6 emulation failures + IRIX 6 emulations place external small common symbols in the regular + common section instead of the small common section. With mips16-hilo + test this leads to a different symbol assignment to memory locations + between o32 and n32 ABIs, as follows: + + --- o32.map + +++ n32.map + @@ -46,23 +46,22 @@ + *(.sdata) + 0x00765430 . = 0x765430 + + -.bss 0x00765430 0x7d8 + +.bss 0x00765430 0x7d9 + *(.bss) + .bss 0x00765430 0x3f0 tmpdir/mips16-hilo.o + .bss 0x00765820 0x0 tmpdir/mips16-hilo1.o + *(COMMON) + - COMMON 0x00765820 0x3e8 tmpdir/mips16-hilo.o + + COMMON 0x00765820 0x3e9 tmpdir/mips16-hilo.o + 0x00765820 big_external_common + + 0x00765c08 small_external_common + + -.sbss 0x00765c08 0x2 + +.sbss 0x00765c09 0x1 + *(.sbss) + - .sbss 0x00765c08 0x1 tmpdir/mips16-hilo.o + + .sbss 0x00765c09 0x1 tmpdir/mips16-hilo.o + *(.scommon) + - .scommon 0x00765c09 0x1 tmpdir/mips16-hilo.o + - 0x00765c09 small_external_common + + /DISCARD/ + *(*) + LOAD tmpdir/mips16-hilo.o + LOAD tmpdir/mips16-hilo1.o + -OUTPUT(tmpdir/dump elf32-bigmips) + +OUTPUT(tmpdir/dump elf32-nbigmips) + + which in turn causes a testsuite regression. Since the specific mapping + of symbols does not matter for the scope of the test, reorder the small + common section ahead of SBSS, so that the `small_external_common' symbol + ends up in the same place regardless of whether via the regular common + section or the small common section. Adjust embedded addresses in the + disassembly expected accordingly, removing the regression concerned: + + mips-sgi-irix6 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32 + mips64el-ps2-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32 + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Unify o32/n32 mips16-hilo test output + The mips16-hilo MIPS LD test case is supposed to produce the same final + linked output regardless of whether the o32 or n32 ABI has been chosen + for assembly. Reuse o32 output for the n32 test then. + +2025-07-06 Maciej W. Rozycki + + MIPS/LD/testsuite: Set architecture for MIPS16 HI/LO tests + Remove regressions across MIPSr6 targets with the MIPS16 HI/LO tests, + which are incompatible with the default architecture of these targets: + + mips-img-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mips-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mips64-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mips64-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32 + mips64el-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mips64el-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32 + mipsel-img-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsel-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa32r6-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa32r6-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa32r6el-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa32r6el-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6-linux-gnuabi64 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6el-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6el-linux-gnuabi64 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + mipsisa64r6el-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs + +2025-07-06 Maciej W. Rozycki + + MIPS/GAS/testsuite: Cover microMIPS HI/LO relocation pairing + Add a GAS test case for R_MICROMIPS_HI16/R_MICROMIPS_LO16 REL relocation + pairing, analogous to one for R_MIPS16_HI16/R_MIPS16_LO16 relocations. + + MIPS/GAS/testsuite: Remove useless whitespace from mips16-hilo-match test + Remove trailing whitespace and extraneous new-line characters from + mips16-hilo-match.d test case. + +2025-07-06 Alan Modra + + gas pending_bundle_size assert + oss-fuzz managed to trigger this assert, by assembling directives in + the absolute section. Avoid this using similar code to that in + frags.c:frag_new (commit 2dc2dfa7d7a5). + + gas bundle support + Use valueT when calculating sizes, since fr_fix is that type. + unsigned int was fine for sane code, but can lose to fuzzed input. + + ubsan: gas resolve_symbol_value + Avoid signed overflow when resolving constant +/- constant. + +2025-07-06 Indu Bhagat + + libsframe: fix error code in sframe_decode + When sanity check of SFrame header fails, set error code to + SFRAME_ERR_BUF_INVAL instead of the current SFRAME_ERR_NOMEM. + +2025-07-06 GDB Administrator + + Automatic date update in version.in + +2025-07-05 Tom de Vries + + [gdb/tdep] Fix selftest scoped_mmap on freebsd + On x86_64-freebsd, I run into: + ... + $ gdb -q -batch -ex "maint selftest scoped_mmap" + Running selftest scoped_mmap. + Self test failed: self-test failed at scoped_mmap-selftests.c:50 + + Failures: + scoped_mmap + + Ran 1 unit tests, 1 failed + ... + + The problem is that this call: + ... + ::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE, + MAP_ANONYMOUS | MAP_PRIVATE, 0, 0); + ... + returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0. + + If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd. On linux, fd is + ignored but -1 is recommended for portability. + + Fix this by using fd == -1 instead. + + Tested x86_64-freebsd and x86_64-linux. + +2025-07-05 Tom de Vries + + [gdb/tdep] Fix doc string of kvm pcb/proc command + On x86_64-freebsd, I ran into: + ... + $ gdb -q -batch -ex "maint selftest help_doc_invariants" + Running selftest help_doc_invariants. + help doc broken invariant: command 'kvm pcb' help doc first line is not \ + terminated with a '.' character + Self test failed: self-test failed at command-def-selftests.c:120 + + Failures: + help_doc_invariants + + Ran 1 unit tests, 1 failed + ... + + Fix this by adding the missing terminating dot. + + Likewise for the kvm proc command. + + Tested on x86_64-freebsd. + +2025-07-05 Andrew Burgess + + gdb: create gdb.sum/gdb.log summary after using check-all-boards + Use the contrib/dg-extract-results.sh script to create a gdb.sum and + gdb.log summary after running the check-all-boards make target. + + Having the results from all the boards merged into a single file + isn't (maybe) the most useful, but it isn't a bad thing. However, the + great thing about merge the results is that the totals are also + merged. + + The 'check-all-boards' recipe can then extract these totals, just as + we do for the normal 'check' recipe, this makes is much easier to + spot if there are any unexpected failures when using + 'check-all-boards'. + + Reviewed-By: Keith Seitz + +2025-07-05 Andrew Burgess + + contrib: sync dg-extract-results.{sh,py} with GCC + Sync the dg-extract-results.{sh,py} scripts with GCC, up to commit + 4e9104ae5455a3c02c2a7e07f52e6bc574cc761d. + + This extends the dg-extract-results scripts to handle GDB's + 'unexpected core files' count. + + contrib/ChangeLog: + + * dg-extract-results.py: Handle GDB's unexpected core file count. + * dg-extract-results.sh: Likewise. + + Reviewed-By: Keith Seitz + +2025-07-05 Pietro Monteiro + + sim: ppc: use correct macros + AC_STRUCT_ST_* are the names of the autoconf macros, the C + preprocessor macros defined by autoconf/authoeader are + HAVE_STRUCT_STAT_ST_*. + + Approved-By: Andrew Burgess + +2025-07-05 Pietro Monteiro + + sim: configury: fix obsolete macros + Running `autoreconf -vf -Wall' in the sim directory shows errors about the use + of obsolete macros. This patch fix the issues with macros used or defined in + the sim directory. However, it doesn't fix all warnings. There's 1 autoconf + warning from `config/pkg.m4', and many automake warnings about target + shadowing. It cuts a lot of the noise down and makes an upgrade to + autoconf 2.71+ easier. + + - Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997 + + - Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203 + + - Replace AC_ERROR by AC_MSG_ERROR + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fERROR-2034 + + - Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213 + + - Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176 + + - Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180 + + - Remove AC_STRUCT_ST_BLOCKS. It is not obsolete, but it's already covered by a + AC_CHECK_MEMBERS call. + + - Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER} + https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ + Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693 + + Approved-By: Tom Tromey + +2025-07-05 Pietro Monteiro + + gdb: add Pietro Monteiro to gdb/MAINTAINERS + +2025-07-05 GDB Administrator + + Automatic date update in version.in + +2025-07-04 Jan Beulich + + gas: introduce .errif and .warnif + Rather than having people resort to indirect means to issue a certain + kind of diagnostic conditionally upon an expression which can (or + should) only be evaluated when all sections were sized and all symbols + had their final values established, provide directives to directly + achieve this. + +2025-07-04 Jan Beulich + + gas: add a means to programmatically determine the assembler version + It has been more than once that I would have wanted to have a way to + know the gas version in assembly sources, perhaps for use with .if. Add + such a pre-defined symbol, introducing the common pattern GAS() + for any such symbols. The use of parentheses is to keep the risk of + collisions with users' symbols as low as possible. (Possible future + arch-specific symbols may want to use GAS(:).) + + Similarly permit determining whether the assembler is a released + version. The exact value probably isn't of much use, it's more the + defined-ness that one might care about. Yet the symbol needs to have + some value anyway. + + While by default pre-defined symbols won't be emitted to the symbol + table, introduce -emit-local-absolute to allow requesting this. Re- + purpose flag_strip_local_absolute to become tristate, with a negative + value indicating to also emit pre-defined symbols. + +2025-07-04 Jan Beulich + + cris/testsuite: don't use --em= + Using such abbreviations is fine when written on an interactive command + line by a human. In scripts and alike, doing so risks colliding with + later option additions, as is about to occur for gas: Shortly there'll + be --emit-local-absolute. + +2025-07-04 GDB Administrator + + Automatic date update in version.in + +2025-07-03 Simon Marchi + + gdb/linux-nat: initialize lwp_info::syscall_state + When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan, + I get: + + /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind' + ERROR: GDB process no longer exists + GDB process exited with wait status 3026417 exp9 0 1 + UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork + + The error happens here: + + #0 __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50 + #1 0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=, Val=) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551 + #2 0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906 + #3 0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044 + #4 0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381 + #5 0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 , ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607 + #6 0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 , ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398 + #7 0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593 + + I believe the problem is that lwp_info::syscall_state is never + initialized. Fix that by initializing it with TARGET_WAITKIND_IGNORE. + This is the value we use elsewhere when resetting this field to mean + "not stopped at a syscall". + + Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb + Approved-By: Tom Tromey + +2025-07-03 Thiago Jung Bauermann + + bfd/aarch64-linux: Support reading and writing the GCS core file note + Reviewed-By: Luis Machado + +2025-07-03 Simon Marchi + + gdb/testsuite: remove spurious whitespace in gdb.python/py-symbol.exp + Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536 + +2025-07-03 Simon Marchi + + gdb/alpha-tdep: add empty line + This was suggested in review, to separate the comment from the following + code. + + Change-Id: I077ad4545ee5ef1d362dcfacf585400e26dfdb29 + +2025-07-03 GDB Administrator + + Automatic date update in version.in + +2025-07-02 Yodel Eldar + + gdb/alpha: Redefine fpcr with fpcr_flags type + This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr. + + For details on the floating-point control register (fpcr), please see + the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it + consists of a 64-bit bitfield with most bits reserved/unused. All but a + pair of the used bits are boolean flags; the exception, DYN_RM, is a + 2-bit enum indicating the IEEE rounding mode and is defined as a + dyn_rm_enum type in the target description annex. + + [1] https://archive.org/details/dec-alpha_arch_ref + + Approved-By: Simon Marchi + Change-Id: Iea54c9e201faae6147a03de124b0368752bce060 + +2025-07-02 Yodel Eldar + + gdb/alpha: Add target description support + This commit adds target description support for Alpha. + + The target description obviates the alpha_register_type and + alpha_register_name functions in alpha-tdep.c. Removal of + alpha_register_reggroup_p was considered but ultimately abandoned, + because the "info regs" command would no longer omit the zero, fpcr, and + unique registers from its output (they are neither vector nor float + types). + + Register types in the target description annex match the types that the + alpha_register_type function returned. + + The locally defined register_names array was moved out of + alpha_register_name and renamed to alpha_register_names as a static + global; calls to alpha_register_name have been replaced with direct + access of the array. + + The patch follows the code pattern outlined in the following GDB + Internals Wiki entry: + + https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + Change-Id: If4b25a891228388519074a31a682e33358c71063 + +2025-07-02 Tom de Vries + + [gdb/testsuite] Use support_displaced_stepping in gdb.arch/amd64-disp-step-avx.exp + In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp + on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then + I found support_displaced_stepping, which seems more appropriate and + descriptive. + + Fix this by requiring support_displaced_stepping instead. + + Tested on x86_64-freebsd. + +2025-07-02 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd + With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into: + ... + (gdb) continue + Continuing. + + Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35 + 35 nop + (gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end + ... + + This happens while executing this bit of the test-case: + ... + # Turn "debug displaced" on to make sure a displaced step is actually + # executed, not an inline step. + gdb_test_no_output "set debug displaced on" + + gdb_test "continue" \ + "Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \ + "continue to ${test_end_label}" + ... + + The problem is that on x86_64, displaced stepping is only supported for linux. + Consequently, the "prepared successfully" message is missing. + + Fix this by requiring linux. + + Approved-by: Kevin Buettner + + Tested on x86_64-freebsd. + +2025-07-02 GDB Administrator + + Automatic date update in version.in + +2025-07-01 Tom Tromey + + Fix handling of terminal escape sequences in TUI + A user noticed that if the remote sends terminal escape sequences from + the "monitor" command, then these will not be correctly displayed when + in TUI mode. + + I tracked this down to remote.c emitting one character at a time -- + something the TUI output functions did not handle correctly. + + I decided in the end to fix in this in the ui-file layer, because the + same bug seems to affect logging and, as is evidenced by the test case + in this patch, Python output in TUI mode. + + The idea is simple: buffer escape sequences until they are either + complete or cannot possibly be recognized by gdb. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126 + Approved-By: Andrew Burgess + +2025-07-01 Jens Remus + + x86: ld: sframe: Remove SFrame NULL FRE template + A SFrame NULL FRE template is used as NULL value in some but not all + instances to initialize unused elements of SFrame FRE pointer arrays of + fixed size. Additionally it is erroneously used as SFrame FRE template + for PLT GOT entries. + + Define a separate SFrame FRE template for PLT GOT entries with the same + properties as the SFrame NULL FRE and use that for all PLT GOT entries. + Remove the SFrame NULL FRE template, as initialization of unused array + elements is not required, as demonstrated by the instances where it was + not done. + + bfd/ + * elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove. + (elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for + PLT GOT entries. + (elf_x86_64_sframe_non_lazy_plt, + elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused + FRE array elements with elf_x86_64_sframe_null_fre. Use + elf_x86_64_sframe_pltgot_fre1 for PLT GOT. + (elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use + elf_x86_64_sframe_pltgot_fre1 for PLT GOT. + +2025-07-01 Bruce McCulloch + + libctf: doc: add __float128 and SIMD vector classification to spec. + This patch adds two additional distinct types (__float128 and the SIMD + vector type generated from the vector_size attribute) to the umbrella of + two existing types (long double and array, respectively). These types + were previously invalid, producing CTF_K_UNKNOWN in the case of + __float128 or a float in the case of the SIMD vector. This patch will + cleanly allow these types to be represented more accurately without + breaking back-compat. + + Reviewed-by: Nick Alcock + +2025-07-01 Nick Alcock + + libctf: add root-visibility-addition test + libctf/ + * testsuite/libctf-writable/ctf-nonroot-addition.*: New test. + +2025-07-01 Nick Alcock + + libctf: create: check the right root-visible flag when adding enumerands + The root-visible flag we're dealing with here is directly out of the dict, + not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT + or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero + otherwise. Fix the test. + + libctf/ + * ctf-create.c (ctf_add_enumerator): Fix root-visibility test. + +2025-07-01 Nick Alcock + + libctf: create: addition of non-root types should not return root types + If you add a non-root type to a dict, you should always get a new, unique + type ID back, even if a root-visible type with the same name already exists. + Unfortunately, if the root-visible type is a forward, and you're adding a + non-root-visible struct, union, or enum, the machinery to detect forwards + and promote them to the concrete type fires in this case and returns the + root-visible type! If this is an enum being inserted hidden because its + enumerands conflict with some other enum, this will lead to failure later + on: in any case, it's seriously counterintuitive to add a non-root- visible + type and get a root-visible one instead. + + Fix this by checking the root-visible flag properly and only checking for + forwards if this type is root-visible. (This may lead to a certain degree + of proliferation of non-root-visible forwards: we can add a cleanup pass for + those later if needed.) + + libctf/ + * ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when + doing forward promotion. + (ctf_add_union_sized): Likewise. + (ctf_add_enum): Likewise. + + Reviewed-by: Bruce McCulloch + +2025-07-01 Alan Modra + + MIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16 + In rela howtos these relocations should not be using + _bfd_mips_elf_got16_reloc. That special function is for extracting + addends from section contents, and only for that (ie. it doesn't + subtract gp). Make these rela howtos like the corresponding + R_MIPS_GOT16 rela howto. + + * elf64-mips.c (mips16_elf64_howto_table_rela ): + Use _bfd_mips_elf_generic_reloc. + (micromips_elf64_howto_table_rela ): Likewise. + * elfn32-mips.c (elf_mips16_howto_table_rela ): + Likewise. + (elf_micromips_howto_table_rela ): Likewise. + +2025-07-01 GDB Administrator + + Automatic date update in version.in + +2025-06-30 WANG Xuerui + + RISC-V: [gprofng] Allow building gprofng without asm/hwprobe.h + The code is actually able to gracefully fallback if the syscall number + of riscv_hwprobe is not available at build time, but it still depended + on the header unconditionally. In certain environments + such as one of crosstool-NG's Canadian Cross build step (binutils for + host), or one with very outdated kernel headers, the header will not be + present, causing the build to fail. + + While the relevant projects/environments should be fixed nevertheless, + a configure-time check for is helpful for fixing gprofng + builds with released versions of ct-ng etc. + +2025-06-30 Vladimir Mezentsev + + Fix typos in binutils/dwarf.c + binutils/ChangeLog + 2025-06-29 Vladimir Mezentsev + + * dwarf.c: Change "/usrlib64/debug/usr" to "/usr/lib64/debug/usr/" and + .gun_debugaltlink to .gnu_debugaltlink. + +2025-06-30 GDB Administrator + + Automatic date update in version.in + +2025-06-29 Simon Marchi + + gdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPAT + When building without expat, we get a missing make_target_solib_ops + error: + + /usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()': + /home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()' + + Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33118 + Change-Id: I76fe4698c6b71bd76096e6cdcbacf8de42a3eb43 + Tested-by: Thiago Jung Bauermann + +2025-06-29 GDB Administrator + + Automatic date update in version.in + +2025-06-28 H.J. Lu + + x86-64.exp: Correct pr26808.dump to pr27708.dump + Change + + verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr26808.dump" 1 + + to + + verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr27708.dump" 1 + + * testsuite/binutils-all/x86-64/x86-64.exp: Correct pr26808.dump + to pr27708.dump. + +2025-06-28 Tom de Vries + + [gdb/tdep] Add "maint set console-translation-mode " command + On MSYS2, say we record a brief gdb session using TERM=dumb script: + ... + $ gdb -q + (gdb) print 1 + $1 = 1 + (gdb) q + ... + + When looking at the resulting typescript, we notice something odd: + ... + $ gdb -q^M + (gdb) print 1^M + $1 = 1^M^M + (gdb) q^M + ... + + For some reason, we have "$1 = 1\r\r\n(gdb) ". + + Looking at the documentation of _setmode [1], it mentions translation mode + _O_TEXT as a mode in which "\n" is translated into "\r\n" on output. + + So, it looks like this translation happens twice. + + Add a command "maint set console-translation-mode " command that + allows us to set the translation mode of stdout/stderr to binary, such that we + get instead: + ... + $ gdb -q -ex "maint set console-translation-mode binary"^M + (gdb) print 1^M + $1 = 1^M + (gdb) q^M + ... + + Since we run into this in the testsuite, add + "maint set console-translation-mode binary" to INTERNAL_GDBFLAGS. + + Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre + Muller. + + Compared to that proposal, I dropped the name testsuite-mode, because the + behaviour is not specific to the testsuite. + + Also I chose values binary/text instead of on/off because eventually there may + be other translation mode values that we need [4]. + + Co-Authored-By: Pierre Muller + Reviewed-By: Eli Zaretskii + + [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode + [2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html + [3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html + [4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants + +2025-06-28 GDB Administrator + + Automatic date update in version.in + +2025-06-27 Thiago Jung Bauermann + + GDB: maint: Fix build on FreeBSD + While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64, + I hit this warning converted to an error: + + In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37: + /home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field] + 64 | long m_start_space; + | ^ + 1 error generated. + gmake[2]: *** [Makefile:1973: maint.o] Error 1 + + I used the default compiler on this system: + + $ c++ --version + FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) + Target: aarch64-unknown-freebsd14.3 + Thread model: posix + InstalledDir: /usr/bin + + The problem is that the only two places that use m_start_space are + guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with + it. + + Build-tested on aarch64-unknown-freebsd14.3. + + Approved-By: Simon Marchi + +2025-06-27 GDB Administrator + + Automatic date update in version.in + +2025-06-26 Simon Marchi + + gdb/solib: C++ify solib_ops + Convert solib_ops into an abstract base class (with abstract methods, + some of them with default implementations) and convert all the existing + solib_ops instances to solib_ops derived classes / implementations. + + Prior to this patch, solib_ops is a structure holding function pointers, + of which there are only a handful of global instances (in the + `solib-*.c` files). When passing an `solib_ops *` around, it's a + pointer to one of these instances. After this patch, there are no more + global solib_ops instances. Instances are created as needed and stored + in struct program_space. These instances could eventually be made to + contain the program space-specific data, which is currently kept in + per-program space registries (I have some pending patches for that). + + Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a + pointer to the appropriate solib_ops implementation for the gdbarch. + This is replaced with the `gdbarch_make_solib_ops` method, which returns + a new instance of the appropriate solib_ops implementation for this + gdbarch. This requires introducing some factory functions for the + various solib_ops implementation, to be used as `gdbarch_make_solib_ops` + callbacks. For instance: + + solib_ops_up + make_linux_ilp32_svr4_solib_ops () + { + return std::make_unique (); + } + + The previous code is full of cases of tdep files copying some base + solib_ops implementation, and overriding one or more function pointer + (see ppc_linux_init_abi, for instance). I tried to convert all of this + is a class hierarchy. I like that it's now possible to get a good + static view of all the existing solib_ops variants. The hierarchy looks + like this: + + solib_ops + ├── aix_solib_ops + ├── darwin_solib_ops + ├── dsbt_solib_ops + ├── frv_solib_ops + ├── rocm_solib_ops + ├── svr4_solib_ops + │ ├── ilp32_svr4_solib_ops + │ ├── lp64_svr4_solib_ops + │ ├── linux_ilp32_svr4_solib_ops + │ │ ├── mips_linux_ilp32_svr4_solib_ops + │ │ └── ppc_linux_ilp32_svr4_solib_ops + │ ├── linux_lp64_svr4_solib_ops + │ │ └── mips_linux_lp64_svr4_solib_ops + │ ├── mips_nbsd_ilp32_svr4_solib_ops + │ ├── mips_nbsd_lp64_svr4_solib_ops + │ ├── mips_fbsd_ilp32_svr4_solib_ops + │ └── mips_fbsd_lp64_svr4_solib_ops + └── target_solib_ops + └── windows_solib_ops + + The solib-svr4 code has per-arch specialization to provide a + link_map_offsets, containing the offsets of the interesting fields in + `struct link_map` on that particular architecture. Prior to this patch, + arches would set a callback returning the appropriate link_map_offsets + by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened + to set the gdbarch's so_ops to `&svr_so_ops`. I converted this to an + abstract virtual method of `struct svr4_solib_ops`, meaning that all + classes deriving from svr4_solib_ops must provide a method returning the + appropriate link_map_offsets for the architecture. I renamed + `set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`. This + function is still necessary because it also calls + set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for + that, we could get rid of it. + + There is an instance of CRTP in mips-linux-tdep.c, because both + mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need + to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops + and linux_lp64_svr4_solib_ops), but they both want to override the + in_dynsym_resolve_code method with the same implementation. + + The solib_ops::supports_namespaces method is new: the support for + namespaces was previously predicated by the presence or absence of a + find_solib_ns method. It now needs to be explicit. + + There is a new progspace::release_solib_ops method, which is only needed + for rocm_solib_ops. For the moment, rocm_solib_ops replaces and wraps + the existing svr4_solib_ops instance, in order to combine the results of + the two. The plan is to have a subsequent patch to allow program spaces to have + multiple solib_ops, removing the need for release_solib_ops. + + Speaking of rocm_solib_ops: it previously overrode only a few methods by + copying svr4_solib_ops and overwriting some function pointers. Now, it + needs to implement all the methods that svr4_solib_ops implements, in + order to forward the call. Otherwise, the default solib_ops method + would be called, hiding the svr4_solib_ops implementation. Again, this + can be removed once we have support for multiple solib_ops in a + program_space. + + There is also a small change in how rocm_solib_ops is activated. Prior + to this patch, it's done at the end of rocm_update_solib_list. Since it + overrides the function pointer in the static svr4_solib_ops, and then + overwrites the host gdbarch, so_ops field, it's something that happens + only once. After the patch though, we need to set rocm_solib_ops in all + the program spaces that appear. We do this in + rocm_solib_target_inferior_created and in the new + rocm_solib_target_inferior_execd. After this, I will explore doing a + change where rocm_solib_ops is only set when we detect the ROCm runtime + is loaded. + + Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9 + Approved-By: Pedro Alves + +2025-06-26 Simon Marchi + + gdb/progspace: add solib_ops pointer in program_space + The subsequent C++ification patch in this series will allocate one + instance of solib_ops per program space. That instance will be held in + struct program_space. As a small step towards this, add an `solib_ops + *` field to `struct program_space`. This field represents the solib_ops + currently used to manage the solibs in that program space. Initialize + it with the result of `gdbarch_so_ops` in `post_create_inferior`, and + use it whenever we need to do some solib stuff, rather than using + `gdbarch_so_ops` directly. + + The difficulty here is knowing when exactly to set and unset the solib + ops. What I have here passes the testsuite on Linux, but with more + testing we will probably discover more spots where it's needed. + + The C++ification patch will turn this field into a unique pointer. + + With this patch, the message we get when running "info + linker-namespaces" becomes always the same, so update the test in + gdb.base/dlmopen-ns-ids.exp. + + Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656 + Approved-By: Pedro Alves + Reviewed-By: Guinevere Larsen + +2025-06-26 Simon Marchi + + gdb/solib: use solib::ops for operations that concern a single solib + For operations that concern a single solib, use the solib_ops backlink + added in the previous patch (solib::ops), instead of using the solib_ops + from the gdbarch. This is a small / easy step towards not using + gdbarch_so_ops, which is necessary for the C++ification patch later in + this series. + + There is no change in behavior expected. + + Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff + Approved-By: Pedro Alves + +2025-06-26 Simon Marchi + + gdb/solib: add solib -> solib_ops backlink + The subsequent C++ification commit makes it so that one struct solib_ops + is instantiated for each program space. For some operations, it will + then become necessary to be able to get the right solib_ops instance + from a given solib. Add an solib -> solib_ops backlink for that. + + Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4 + Approved-By: Pedro Alves + +2025-06-26 Simon Marchi + + gdb/solib: fix formatting of "info linker-namespaces" error message + Add spaces after the first period and add a period at the end, resulting + in: + + (gdb) info linker-namespaces + ❌️ Current inferior does not support linker namespaces. Use "info sharedlibrary" instead. + + Change-Id: Ib3f1647cedcdb68852a3c63df26ea3e6f791b1b1 + Approved-By: Pedro Alves + +2025-06-26 Simon Marchi + + gdb/testsuite: check that "info shared" and "info linker-namespaces" before running don't crash + While writing my solib_ops C++ification series, I broke this, and it + didn't seem to be caught by the testsuite. Add a test for those. + + The exact message for "info linker-namespaces" varies depending on the + solib_ops of the target architecture (whether ops->num_active_namespaces + is nullptr or not). For now, just accept any message (a crash will + still be caught). A later patch in this series will make the message + consistent and update this test. + + Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683 + Approved-By: Pedro Alves + +2025-06-26 Vladimir Mezentsev + + gprofng: need to know that experiment was created on big-endian machine + gprofng/ChangeLog + 2025-06-25 Vladimir Mezentsev + + * configure.ac: Add AC_C_BIGENDIAN. + * common/config.h.in: Rebuild. + * configure: Rebuild. + * libcollector/collector.c (log_header_write): Save big-endian flag. + * src/DbeSession.h (is_bigendian): New function. + * src/DbeSession.cc: Likewise. + * src/Experiment.cc: Set 'bigendian' and 'need_swap_endian'. + * src/Experiment.h: New field 'bigendian'. + * src/LoadObject.cc: Remove an unused variable. + * src/LoadObject.h: Likewise. + +2025-06-26 Simon Marchi + + gdb: remove some stray "void" + Fix these little typos from commit 5fe70629ceaf ("Change file + initialization to use INIT_GDB_FILE macro"). + + Change-Id: Ib9ae29988dfda1165de47467087f154624916629 + +2025-06-26 Nick Clifton + + Updated Spanish translations for opcodes and gas + +2025-06-26 Andrew Burgess + + gdb/testsuite: handle failure to start process for later attach test + Commit: + + commit b23903836007d1acaf7f8c059ab000ee83fcebfa + Date: Tue Mar 21 13:01:26 2023 +0100 + + gdb: linux-namespaces: enter user namespace when appropriate + + added a new test gdb.base/user-namespace-attach.exp. It has been + reported that this test will sometimes fail, like this: + + (gdb) attach 184732 + Attaching to process 184732 + warning: process 184732 is a zombie - the process has already terminated + ptrace: Operation not permitted. + (gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior + + the test tries to run the 'unshare' application. Sometimes though, + the application is present, but the set of flags used is not + supported (maybe due to restrictions on the local machine), so we see + behaviour like this: + + $ unshare --mount --map-root-user /bin/true; echo $? + unshare: unshare failed: Operation not permitted + 1 + + Handle this case by first running 'unshare' with the same flags, but + using '/bin/true', if this fails then assume the flags are not + supported, and skip the test. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108 + +2025-06-26 Tom Tromey + + Change file initialization to use INIT_GDB_FILE macro + This patch introduces a new macro, INIT_GDB_FILE. This is used to + replace the current "_initialize_" idiom when introducing a per-file + initialization function. That is, rather than write: + + void _initialize_something (); + void + _initialize_something () + { + ... + } + + ... now you would write: + + INIT_GDB_FILE (something) + { + ... + } + + The macro handles both the declaration and definition of the function. + + The point of this approach is that it makes it harder to accidentally + cause an initializer to be omitted; see commit 2711e475 ("Ensure + cooked_index_entry self-tests are run"). Specifically, the regexp now + used by make-init-c seems harder to trick. + + New in v2: un-did some erroneous changes made by the script. + + The bulk of this patch was written by script. + Regression tested on x86-64 Fedora 41. + +2025-06-26 GDB Administrator + + Automatic date update in version.in + +2025-06-25 Srinath Parvathaneni + + aarch64: Add supports for FEAT_PoPS feature and DC instructions. + This patch add support for FEAT_PoPS feature which can be enabled + through +pops command line flag. + + This patch also adds support for following DC instructions and the + spec can be found here [1]. + 1. "dc cigdvaps" enabled on passing +memtag+pops command line flags. + 2. "dc civaps" enabled on passing +pops command line flag. + + [1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Instructions?lang=en + +2025-06-25 Andrew Burgess + + gdb: remove final m_stream->emit_style_escape calls from pager_file + After the last commit there were still a couple of calls to + m_stream->emit_style_escape in the pager_file class. As discussed in + the last commit, these are likely wrong, but I'd not been able to + produce any bugs because of them. + + The reason why there are no bugs is that these calls are, I think, + entirely redundant. Consider this block: + + if (m_wrap_column) + { + /* We are about to insert a newline at an historic + location in the WRAP_BUFFER. Before we do we want to + restore the default style. To know if we actually + need to insert an escape sequence we must restore the + current applied style to how it was at the WRAP_COLUMN + location. */ + m_applied_style = m_wrap_style; + m_stream->emit_style_escape (ui_file_style ()); + /* If we aren't actually wrapping, don't output + newline -- if chars_per_line is right, we + probably just overflowed anyway; if it's wrong, + let us keep going. */ + m_stream->puts ("\n"); + } + + What we know (see previous commit) is that the call: + + m_stream->emit_style_escape (ui_file_style ()); + + is dangerous as m_stream->m_applied_style is going to be out of sync + with its current state. Actually, m_stream->m_applied_style is likely + to be the default style as it is not updated elsewhere. So why does + this not cause problems? + + Well, GDB's style output is always done in tightly scoped regions. + That means if we want to print some styled output, and then apply a + wrap point the code might look like this: + + fprintf_styled (gdb_stdout, file_name_style, "some text"); + gdb_stdout->wrap_here (4); + + But, after printing 'some text', the style of gdb_stdout will have + returned to the default style. + + My claim is that, whenever we encounter a wrap_here call, the stream + in question will _always_ have been returned to the default style. + + This means that, in the block above, the call: + + m_stream->emit_style_escape (ui_file_style ()); + + will never emit anything because it depends on a check against + m_stream->m_applied_style, which will always mean that the above call + does nothing. But that's OK. By chance, we'll have always placed the + stream into a default style state anyway, so no harm done. + + Similarly, the other call: + + /* Having finished inserting the wrapping we should + restore the style as it was at the WRAP_COLUMN. */ + m_stream->emit_style_escape (m_wrap_style); + + Tries to return m_stream to the state it was in at the point of the + wrap_here call. But, as described above, this will always be the + default style, so the above call will do nothing, but that just + happens to be exactly what we want! + + So what does this commit do? + + Well, I "fix" the above code by removing the + m_stream->emit_style_escape calls and replacing them with calls to + puts, passing in the escape sequence for the required style, but only + if the m_stream style as tracked by pager_file::m_stream_style + indicates this is needed. + + Got the reasons given above, this should mean there is no change after + this patch. We still shouldn't be emitting any extra escape + sequences. But, should we ever manage to get into a state where we + call wrap_here with a stream in a style other than the default, then + this should mean things work as expected. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2025-06-25 Andrew Burgess + + gdb: styling fixes around and for the pagination prompt + This commit fixes a couple of issues relating to the pagination + prompt and styling. The pagination prompt is this one: + + --Type for more, q to quit, c to continue without paging-- + + I did try to split this into multiple patches, based on the three + issues I describe below, but in the end, the fixes were all too + interconnected, so it ended up as one patch that makes two related, + but slightly different changes: + + 1. Within the pager_file class, relying on the m_applied_style + attribute of the wrapped m_stream, as is done when calling + m_stream->emit_style_escape, is not correct, so stop doing that, and + + 2. Failing to update m_applied_style within the pager_file class can + leave that attribute out of date, which can then lead to styling + errors later on, so ensure m_applied_style is always updated. + + The problems I have seen are: + + 1. After quitting from a pagination prompt, the next command can + incorrectly style its output. This was reported as bug PR + gdb/31033, and is fixed by this commit. + + 2. The pagination prompt itself could be styled. The pagination + prompt should always be shown in the default style. + + 3. After continuing the output at a pagination prompt, GDB can fail + to restore the default style the next time the output (within the + same command) switches back to the default style. + + There are tests for all these issues as part of this patch. + + The pager_file class is a sub-class of wrapped_file, this means that a + pager_file is itself a ui_file, while it also manages a pointer to a + ui_file object (called m_stream). An instance of pager_file can be + installed as the gdb_stdout ui_file object. + + Output sent to a pager_file is stored within an internal + buffer (called m_wrap_buffer) until we have a complete line, when the + content is flushed to the wrapped m_stream. If sufficient lines have + been written out then the pager_file will present the pagination + prompt and allow the user to continue viewing output, or quit the + current command. + + As a pager_file is a ui_file, it has an m_applied_style member + variable. + + The managed stream (m_stream) is also a ui_file, and so also has an + m_applied_style member variable. + + In some places within the pager_file class we attempt to change the + current style of the m_stream using calls like this: + + m_stream->emit_style_escape (style); + + See pager_file::emit_style_escape, pager_file::prompt_for_continue, + and pager_file::puts. These calls will end up in + ui_file::emit_style_escape, which tries to skip emitting unnecessary + style escapes by checking if the requested style matches the current + m_applied_style value. + + The m_applied_style value is updated by calls to the emit_style_escape + function. + + The problem here is that most of the time pager_file doesn't change + the style of m_stream by calling m_stream->emit_style_escape. Most of + the time, style changes are performed by pager_file writing the escape + sequence into m_wrap_buffer, and then later flushing this buffer to + m_stream by calling m_stream->puts. + + It has to be done this way. Calling m_stream->emit_style_escape + would, if it actually changed the style, immediately change the style + by emitting an escape sequence. But pager_file doesn't want that, it + wants the style change to happen later, when m_wrap_buffer is + flushed. + + To avoid excessive style escape sequences being written into + m_wrap_buffer, the pager_file::m_applied_style performs a function + similar to the m_applied_style within m_stream, it tracks the current + style for the end of m_wrap_buffer, and only allows style escape + sequences to be emitted if the style is actually changing. + + However, a consequence of this is the m_applied_style within m_stream, + is not updated, which means it will be out of sync with the actual + current style of m_stream. If we then try to make a call to + m_stream->emit_style_escape, if the style we are changing too happens + to match the out of date style in m_stream->m_applied_style, then the + style change will be ignored. + + And this is indeed what we see in pager_file::prompt_for_continue with + the call: + + m_stream->emit_style_escape (ui_file_style ()); + + As m_stream->m_applied_style is not being updated, it will always be + the default style, however m_stream itself might not actually be in + the default style. This call then will not emit an escape sequence as + the desired style matches the out of date m_applied_style. + + The fix in this case is to call m_stream->puts directly, passing in + the escape sequence for the desired style. This will result in an + immediate change of style for m_stream, which fixes some of the + problems described above. + + In fact, given that m_stream's m_applied_style is always going to be + out of sync, I think we should change all of the + m_stream->emit_style_escape calls to instead call m_stream->puts. + + However, just changing to use puts doesn't fix all the problems. + + I found that, if I run 'apropos time', then quit at the first + pagination prompt. If for the next command I run 'maintenance time' I + see the expected output: + + "maintenance time" takes a numeric argument. + + However, everything after the first double quote is given the command + name style rather than only styling the text between the double + quotes. + + Here is GDB's stack while printing the above output: + + #2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754 + #3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73 + #4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905 + #5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945 + #6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128 + + The interesting frames here are #3, in here `this` is the pager_file + for GDB's stdout, and this passes its m_applied_style to frame #2 as + the `in_style` argument. + + If the m_applied_style is wrong, then frame #2 will believe that the + wrong style is currently in use as the default style, and so, after + printing 'maintenance time' GDB will switch back to the wrong style. + + So the question is, why is pager_file::m_applied_style wrong? + + In pager_file::prompt_for_continue, there is an attempt to switch back + to the default style using: + + m_stream->emit_style_escape (ui_file_style ()); + + If this is changed to a puts call (see above) then this still leaves + pager_file::m_applied_style out of date. + + The right fix in this case is, I think, to instead do this: + + this->emit_style_escape (ui_file_style ()); + + this will update pager_file::m_applied_style, and also send the + default style to m_stream using a puts call. + + While writing the tests I noticed that I was getting unnecessary style + reset sequences emitted. + + The problem is that, around pagination, we don't really know what + style is currently applied to m_stream. The + pager_file::m_applied_style tracks the style at the end of + m_wrap_buffer, but this can run ahead of the current m_stream style. + For example, if the screen is currently full, such that the next + character of output will trigger the pagination prompt, if the next + call is actually to pager_file::emit_style_escape, then + pager_file::m_applied_style will be updated, but the style of m_stream + will remain unchanged. When the next character is written to + pager_file::puts then the pagination prompt will be presented, and GDB + will try to switch m_stream back to the default style. Whether an + escape is emitted or not will depend on the m_applied_style value, + which we know is different than the actual style of m_stream. + + It is, after all, only when m_wrap_buffer is flushed to m_stream that + the style of m_stream actually change. + + And so, this commit also adds pager_file::m_stream_style. This new + variable tracks the current style of m_stream. This really is a + replacement for m_stream's ui_file::m_applied_style, which is not + accessible from pager_file. + + When content is flushed from m_wrap_buffer to m_stream then the + current value of pager_file::m_applied_style becomes the current style + of m_stream. But, when m_wrap_buffer is filling up, but before it is + flushed, then pager_file::m_applied_style can change, but + m_stream_style will remain unchanged. + + Now in pager_file::emit_style_escape we are able to skip some of the + direct calls to m_stream->puts() used to emit style escapes. + + After all this there are still a few calls to + m_stream->emit_style_escape(). These are all in the wrap_here support + code. I think that these calls are technically broken, but don't + actually cause any issues due to the way styling works in GDB. I + certainly haven't been able to trigger any bugs from these calls yet. + I plan to "fix" these in the next commit just for completeness. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31033 + + Approved-By: Tom Tromey + +2025-06-25 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-warning.exp with python 3.6 + On openSUSE Tumbleweed (with python 3.13), I get: + ... + (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("") + python gdb.warning()^M + Python Exception : \ + function missing required argument 'text' (pos 1)^M + Error occurred in Python: function missing required argument 'text' (pos 1)^M + (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning() + ... + + But on openSUSE Leap 15.6 (with python 3.6), I get instead: + ... + (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("") + python gdb.warning()^M + Python Exception : \ + Required argument 'text' (pos 1) not found^M + Error occurred in Python: Required argument 'text' (pos 1) not found^M + (gdb) FAIL: gdb.python/py-warning.exp: python gdb.warning() + ... + + Fix this by updating the regexp. + + Tested on x86_64-linux. + + PR testsuite/33104 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33104 + +2025-06-25 Matthieu Longo + + readelf: invalid error message triggered when last tag is an empty string + Disclaimer: this issue cannot occur with Object Attributes v1 (OAv1) while + using the GNU binutils because a value of '\0' (empty string) for a tag + with a string value is considered as the default value for the attribute, + and consequently is eliminated by gas from the output object file during + the serialization. + + An empty string is a valid value for a NTBS tag in both OAv1 and OAv2 [1] + cases. However, contrarily to OAv1, a OAv2 subsection can be required and + so, tags in this subsection might have to be present even if the value is + the default. To comply with this requirement, the OAv2 serializer won't + drop the default values. + + In the case where a NTBS tag has the value '\0' and is last in the object + attributes section, the current code in readelf used for dumping the object + attributes incorrectly detects an overflow, and prints out an error message + for a corrupted string tag. + + This patch fixes the detection of the overflow so that it now accept an + empty string in the last tag of the object attributes section. + + It also fixes the previous tests for the empty NTBS case and the non-null + terminated string one. The fix was also tested in the context of OAv2's + patch series [1] where the issue was originally detected. No regression + was found. + + [1]: https://inbox.sourceware.org/binutils/20250509151319.88725-1-matthieu + .longo@arm.com/ + +2025-06-25 Matthieu Longo + + arm testsuite: add two corner cases for EABI string attributes + The current testsuite for gas/readelf lacked two tests for EABI build + attributes: + - one when the final attribute is an empty string. + - one when the final attribute is a string missing the NULL terminator. + + Those two issues cannot occur with Object Attributes v1 (OAv1) sections + created by the GNU binutils. Indeed a value of '\0' (empty string) for a + tag with a string value is considered as the default value for the + attribute, and consequently is eliminated by Gas from the output object + file during the serialization. + However, readelf should be able to process correctly files of an unknown + origin that could contain those two use cases. + + This patch adds the two tests mentioned above. The first one is marked + as XFAIL because the empty string is not processed correctly by readelf + when it is in the last position. The second one passes, but simply print + out "[...]" without mentioning that the NTBS is corrupted. + + A following patch will fix the bug in readelf, and will amend the newly + introduced tests. + +2025-06-25 Tom de Vries + + [gdb/testsuite] Fix gdb.base/infcall-failure.exp on freebsd + On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get: + ... + (gdb) continue + Continuing. + + Program received signal SIGSEGV, Segmentation fault. + Address not mapped to object. + 0x0000000000400522 in func_segfault () at infcall-failure.c:24 + 24 return *p; /* Segfault here. */ + Error in testing condition for breakpoint 2: + The program being debugged was signaled while in a function called from GDB. + GDB remains in the frame where the signal was received. + To change this behavior use "set unwind-on-signal on". + Evaluation of the expression containing the function + (func_segfault) will be abandoned. + When the function is done executing, GDB will silently stop. + (gdb) FAIL: $exp: target_async=on: target_non_stop=on: \ + run_cond_hits_segfault_test: continue + ... + + The problem is that the regexp in the test-case doesn't expect the + "Address not mapped to object." bit. + + Fix this by updating the regexp. + + Approved-by: Kevin Buettner + + Tested on x86_64-freebsd and x86_64-linux. + +2025-06-25 GDB Administrator + + Automatic date update in version.in + +2025-06-24 Jiawei + + RISC-V: Add Profiles RVA/B23S64 support. + This patch adds support for the RISC-V Profiles RVA23S64 and RVB23S64. + + Version log: + Fix wrong test for rvb23s. + + bfd/ChangeLog: + + * elfxx-riscv.c: New Profiles. + + gas/ChangeLog: + + * testsuite/gas/riscv/attribute-rva23s.d: New test. + * testsuite/gas/riscv/attribute-rvb23s.d: New test. + +2025-06-24 Tom de Vries + + [gdb/testsuite] Make gdb.dap/log-message.exp more robust + PR testsuite/31831 reports the following failure in the + gdb.dap/log-message.exp test-case (formatted for readability): + ... + { "type": "event", + "event": "output", + "body": { + "category": "stdout", + "output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n" + }, + "seq": 13 + } + FAIL: $exp: logging output (checking body category) + ... + for a gdb 14.2 based package. + + The output event listed above is a result from the setBreakpoints request. + + The test-case issues the setBreakpoints request and waits for the + corresponding response, but doesn't wait for the output event, and + consequently the output event is read by: + ... + dap_wait_for_event_and_check "logging output" output \ + {body category} console \ + {body output} "got 23 - 23 = 0" + ... + which triggers the failure. + + I'm not able to reproduce this, but it looks worth fixing regardless. + + We're fixing this on trunk though, and the output event looks different, and + there's one more output event: + ... + { "type": "event", + "event": "output", + "body": { + "category": "stdout", + "output": "No source file named log-message.c.\n" + }, + "seq": 4 + } + { "type": "event", + "event": "output", + "body": { + "category": "stdout", + "output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n" + }, + "seq": 5 + } + ... + + Fix this by waiting for these two output events, making the test-case a bit + more robust. + + It is possible that one or both of these output events will be read by + dap_check_request_and_response "set breakpoint", and in that case restashing + them (for which there's currently no infrastructure) would be an easy way of + handling this. But I haven't been able to trigger that, so I'm leaving that + for if and when it does. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831 + +2025-06-24 Tom Tromey + + Allow DAP "threads" request when inferior is running + A user pointed out that DAP allows the "threads" request to work when + the inferior is running. This is documented in the overview, not the + specification. + + While looking into this, I found a few other issues: + + * The _thread_name function was not marked @in_gdb_thread. + This isn't very important but is still an oversight. + + * DAP requires all threads to have a name -- the field is not optional + in the "Thread" type. + + * There was no test examining events resulting from the inferior + printing to stdout. + + This patch fixes all these problems. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33080 + +2025-06-24 Tom Tromey + + Use "MS" for .debug_str + I changed my system linker to 'mold', but then I saw some gdb test + failures. This patch fixes a subset of the failures. + + dw2-strp.exp was failing, and investigating showed that there were two + .debug_str sections. I tracked this down to the .S file not using the + correct section flags. + + This patch fixes this problem, plus the other instances I could find. + (Strangely, these did not all cause problems, however.) I also + changed the DWARF assembler to always use these flags for .debug_str. + +2025-06-24 Jan Beulich + + gas/doc: -v / -version / --version / --verbose + Split -v from -version/--version. They aren't the same; -v long form is + --verbose, which so far wasn't mentioned at all. + +2025-06-24 Jiawei + + RISC-V: Update Profiles string in RV23. + Update the Profiles string in RV23 to include the extensions 'b' and 'supm'. + + bfd/ChangeLog: + + * elfxx-riscv.c: Update Profiles string in RV23. + + gas/ChangeLog: + + * testsuite/gas/riscv/attribute-19.d: Update test string. + * testsuite/gas/riscv/attribute-20.d: Ditto. + +2025-06-24 Nelson Chu + + gas/NEWS: Updated for RISC-V + + ld/NEWS,binutils/NEWS: Updated supports for RISC-V zicfiss and zicfilp + + RISC-V: Fxied failed testsuites when building rv32-linux + +2025-06-24 Kito Cheng + + RISC-V: Support for unlabeled landing pad PLT generation + This patch adds support for generating unlabeled landing pad PLT entries + for the RISC-V architecture. Unlabeled landing pad will place a LPAD + instruction at the PLT entry and PLT header, also PLT header will have + few changes due to the offset is different from the original one. + + Ref: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417 + +2025-06-24 Kito Cheng + + RISC-V: Implment the merge logic for GNU_PROPERTY_RISCV_FEATURE_1_AND + GNU_PROPERTY_RISCV_FEATURE_1_AND will perform a bitwise AND operation + on the properties of the input files. + +2025-06-24 Kito Cheng + + RISC-V: Add GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED + This patch adds two new GNU properties for RISC-V: + GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED. + + We only add readelf and define the properties in this patch. + + Ref: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417 + +2025-06-24 Kito Cheng + + RISC-V: Refactor PLT generation + The goal of this refactor is to improve the possiblity of having + different PLT generation code for different RISC-V ABIs. The changes + include: + - Extract PLT generation logic into individual functions. + - Keep the PLT generation data in riscv_elf_link_hash_table. + + In the following patches, we will use this framework to implement + different PLT. + +2025-06-24 GDB Administrator + + Automatic date update in version.in + +2025-06-23 Pawel Kupczak + + gdb: return after stack alignment skip if current_pc is reached + Make sure we bail out early from amd64_analyze_prologue if CURRENT_PC + is reached to avoid unnecessary call to amd64_analyze_frame_setup. + + Approved-By: Andrew Burgess + +2025-06-23 Pawel Kupczak + + gdb: correct endbr64 instruction handling in amd64_analyze_prologue + Compilers can put a sequence aligning the stack at the entry of a + function. However with -fcf-protection enabled, "endbr64" is + generated before. Current implementation of amd64 prologue analyzer + first checks for stack alignment and then for "endbr64", which is not + correct. This behavior was introduced with patch "gdb: handle endbr64 + instruction in amd64_analyze_prologue". In case both are generated, + prologue will not be skipped. This patch swaps the order so that + "endbr64" is checked first and adds a regression test. i386-tdep + implementation also already had those checked in the correct order, + that is stack alignment is after endbr64. + + Given such source compiled with gcc 11.4.0 via: + gcc -O0 main.c -o main + + ``` + #include + + void + foo (int id) + { + volatile __attribute__ ((__aligned__ (64))) int a; + volatile char *p = (char *) alloca (id * 12); + p[2] = 'b'; + } + + int + main (int argc, char **argv) + { + foo (argc + 1); + return 1; + } + ``` + + we get such function entry for foo (generated with objdump -d): + ``` + 0000000000001149 : + 1149: f3 0f 1e fa endbr64 + 114d: 4c 8d 54 24 08 lea 0x8(%rsp),%r10 + 1152: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp + 1156: 41 ff 72 f8 push -0x8(%r10) + 115a: 55 push %rbp + 115b: 48 89 e5 mov %rsp,%rbp + 115e: 41 52 push %r10 + 1160: 48 81 ec a8 00 00 00 sub $0xa8,%rsp + 1167: 89 7d 8c mov %edi,-0x74(%rbp) + ... + ``` + + The 3 instructions following endbr64 align the stack. If we were to set + a breakpoint on foo, gdb would set it at function's entry: + ``` + (gdb) b foo + Breakpoint 1 at 0x1149 + (gdb) r + ... + Breakpoint 1, 0x0000555555555149 in foo () + (gdb) disassemble + Dump of assembler code for function foo: + => 0x0000555555555149 <+0>: endbr64 + 0x000055555555514d <+4>: lea 0x8(%rsp),%r10 + 0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp + 0x0000555555555156 <+13>: push -0x8(%r10) + 0x000055555555515a <+17>: push %rbp + 0x000055555555515b <+18>: mov %rsp,%rbp + 0x000055555555515e <+21>: push %r10 + 0x0000555555555160 <+23>: sub $0xa8,%rsp + 0x0000555555555167 <+30>: mov %edi,-0x74(%rbp) + ... + ``` + + With this patch fixing the order of checked instructions, gdb can + properly analyze the prologue: + ``` + (gdb) b foo + Breakpoint 1 at 0x115e + (gdb) r + ... + Breakpoint 1, 0x000055555555515e in foo () + (gdb) disassemble + Dump of assembler code for function foo: + 0x0000555555555149 <+0>: endbr64 + 0x000055555555514d <+4>: lea 0x8(%rsp),%r10 + 0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp + 0x0000555555555156 <+13>: push -0x8(%r10) + 0x000055555555515a <+17>: push %rbp + 0x000055555555515b <+18>: mov %rsp,%rbp + => 0x000055555555515e <+21>: push %r10 + 0x0000555555555160 <+23>: sub $0xa8,%rsp + 0x0000555555555167 <+30>: mov %edi,-0x74(%rbp) + ... + ``` + + Approved-By: Andrew Burgess + +2025-06-23 Pawel Kupczak + + gdb: refactor amd64_analyze_prologue + Refactor amd64_analyze_prologue so it clearly reflects what is the order + of operations in the prologue that we expect to encounter, as is the + case for i386's implementation. + + Approved-By: Andrew Burgess + +2025-06-23 Andrew Burgess + + gdb/testsuite: use TESTS from make-check-all.sh + Update the make-check-all.sh script to use TESTS rather than passing + the test names within RUNTESTFLAGS. This addresses the following + issue: + + I was running some tests like this: + + make -C gdb check-all-boards TESTS="gdb.base/break*.exp" + + And I was finding that I would get lots of DUPLICATE test results, + which is not what I expected. + + What's happening here is that the 'make check-all-boards' rule runs + the 'make-check-all.sh' script, which then runs 'make check' with + various board files. + + However, passing TESTS=... to the initial 'make check-all-boards' + command invocation automatically causes the TESTS value to be added to + the MAKEFLAGS environment variable, this is then picked up by the + later calls to 'make check'. + + Now, in GDB's testfile/Makefile, we check for TESTS, and if this is + set, we expand the value and set `expanded_tests_or_none`. Otherwise, + if TESTS is not set, expanded_tests_or_none is left empty. + + Finally, when handling 'make check', the value of + `expanded_tests_or_none` is passed through to dejagnu, along with the + RUNTESTFLAGS value. + + What this means is that, when make-check-all.sh passes the test names + in the RUNTESTFLAGS, then dejagnu ends up seeing the list of tests + twice, once from RUNTESTFLAGS, and once from expanded_tests_or_none, + and this is why I was seeing duplicate testnames. + + The easiest fix for the above is to have make-check-all.sh pass the + test names using TESTS="...", this will override the TESTS="..." value + already present in MAKEFLAGS, and means dejagnu will see the test + names just once. + + Additionally, this is a start towards allowing parallel test running + from the make-check-all.sh script. Parallel test running only works + if the test names are passed in TESTS, and not in RUNTESTFLAGS. + Currently, in testsuite/Makefile, if RUNTESTFLAGS is not empty, then + we force single threaded test running. But with this change, at least + for the `local` board, we can now benefit from multi-threaded test + running, as this board has an empty RUNTESTFLAGS now. For the other + boards we'd need to set FORCE_PARALLEL in order to benefit from + parallel test running, but we'll need to double check that all the + board files actually support parallel test running first, so I'm + leaving that for another day. + +2025-06-23 H.J. Lu + + objcopy: Don't extend the output section size + Since the output section contents are copied from the input, don't + extend the output section size beyond the input section size. + + PR binutils/33049 + * objcopy.c (copy_section): Don't extend the output section + size beyond the input section size. + +2025-06-23 H.J. Lu + + elf: Report corrupted group section + Report corrupted group section instead of trying to recover. + + PR binutils/33050 + * elf.c (bfd_elf_set_group_contents): Report corrupted group + section. + +2025-06-23 Andrew Burgess + + gdb: filename completion for pipe command -- the shell command bit + This commit adds filename completion for the shell command part of + the pipe command. This is a follow on from this commit: + + commit 036e5c0c9121d0ac691dbf408a3bdf2bf3501d0f + Date: Mon May 19 20:54:54 2025 +0100 + + gdb: use quoted filename completion for the shell command + + which fixed the completion for the 'shell' command itself. + + Like with the 'shell' command, we don't offer completions of command + names pulled from $PATH, we just offer filename completion, which is + often useful for arguments being passed to commands. Maybe in the + future we could add completion for command names too (for both 'pipe' + and the 'shell' command), but that is left for a future commit. + + There's some additional testing. + +2025-06-23 Benjamin Berg + + gdb: linux-namespaces: enter user namespace when appropriate + The use of user namespaces is required for normal users to use mount + namespaces. Consider trying this as an unprivileged user: + + $ unshare --mount /bin/true + unshare: unshare failed: Operation not permitted + + The problem here is that an unprivileged user doesn't have the + required permissions to create a new mount namespace. If, instead, we + do this: + + $ unshare --mount --map-root-user /bin/true + + then this will succeed. The new option causes unshare to create a + user namespace in which the unprivileged user is mapped to UID/GID 0, + and so gains all privileges (inside the namespace), the user is then + able to create the mount namespace as required. + + So, how does this relate to GDB? + + When a user attaches to a process running in a separate mount + namespace, GDB makes use of a separate helper process (see + linux_mntns_get_helper in nat/linux-namespaces.c), which will then use + the `setns` function to enter (or try to enter) the mount namespace of + the process GDB is attaching too. The helper process will then handle + file I/O requests received from GDB, and return the results back to + GDB, this allows GDB to access files within the mount namespace. + + The problem here is that, switching to a mount namespace requires that + a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within + its user namespace (actually it's a little more complex, see 'man 2 + setns'). Assuming GDB is running as an unprivileged user, then GDB + will not have the required permissions. + + However, if GDB enters the user namespace that the `unshare` process + created, then the current user will be mapped to UID/GID 0, and will + have the required permissions. + + And so, this patch extends linux_mntns_access_fs (in + nat/linux-namespace.c) to first try and switch to the user namespace + of the inferior before trying to switch to the mount namespace. If + the inferior does have a user namespace, and does have elevated + privileges within that namespace, then this first switch by GDB will + mean that the second step, into the mount namespace, will succeed. + + If there is no user namespace, or the inferior doesn't have elevated + privileges within the user namespace, then the switch into the mount + namespace will fail, just as it currently does, and the user will need + to give elevated privileges to GDB via some other mechanism (e.g. run + as root). + + This work was originally posted here: + + https://inbox.sourceware.org/gdb-patches/20230321120126.1418012-1-benjamin@sipsolutions.net + + I (Andrew Burgess) have made some cleanups to the code to comply with + GDB's coding standard, and the test is entirely mine. This commit + message is also entirely mine -- the original message was very terse + and required the reader to understand how the various namespaces + work and interact. The above is my attempt to document what I now + understand about the problem being fixed. + + I've left the original author in place as the core of the GDB change + itself is largely as originally presented, but any inaccuracies in the + commit message, or problems with the test, are all mine. + + Co-Authored-by: Andrew Burgess + +2025-06-23 Andrew Burgess + + gdb: only use /proc/PID/exe for local f/s with no sysroot + This commit works around a problem introduced by commit: + + commit e58beedf2c8a1e0c78e0f57aeab3934de9416bfc + Date: Tue Jan 23 16:00:59 2024 +0000 + + gdb: attach to a process when the executable has been deleted + + The above commit extended GDB for Linux, so that, of the executable + for a process had been deleted, GDB would instead try to use + /proc/PID/exe as the executable. + + This worked by updating linux_proc_pid_to_exec_file to introduce the + /proc/PID/exe fallback. However, the result of + linux_proc_pid_to_exec_file is then passed to exec_file_find to + actually find the executable, and exec_file_find, will take into + account the sysroot. In addition, if GDB is attaching to a process in + a different MNT and/or PID namespace then the executable lookup is + done within that namespace. + + This all means two things: + + 1. Just because linux_proc_pid_to_exec_file cannot see the + executable doesn't mean that GDB is actually going to fail to + find the executable, and + + 2. returning /proc/PID/exe isn't useful if we know GDB is then going + to look for this within a sysroot, or within some other + namespace (where PIDs might be different). + + There was an initial attempt to fix this issue here: + + https://inbox.sourceware.org/gdb-patches/20250511141517.2455092-4-kilger@sec.in.tum.de/ + + This proposal addresses the issue in PR gdb/32955, which is all about + the namespace side of the problem. The fix in this original proposal + is to check the MNT namespace inside linux_proc_pid_to_exec_file, and + for the namespace problem this is fine. But we should also consider + the sysroot problem. + + And for the sysroot problem, the fix cannot fully live inside + linux_proc_pid_to_exec_file, as linux_proc_pid_to_exec_file is shared + between GDB and gdbserver, and gdbserver has no sysroot. + + And so, I propose a slightly bigger change. + + Now, linux_proc_pid_to_exec_file takes a flag which indicates if + GDB (or gdbserver) will look for the inferior executable in the + local file system, where local means the same file system as GDB (or + gdbserver) is running in. + + This local file system check is true if: + + 1. The MNT namespace of the inferior is the same as for GDB, and + + 2. for GDB only, the sysroot must either be empty, or 'target:'. + + If the local file system check is false then GDB (or gdbserver) is + going to look elsewhere for the inferior executable, and so, falling + back to /proc/PID/exe should not be done, as GDB will end up looking + for this file in the sysroot, or within the alternative MNT + namespace (which in also likely to be a different PID namespace). + + Now this is all a bit of a shame really. It would be nice if + linux_proc_pid_to_exec_file could return /proc/PID/exe in such a way + that exec_file_find would know that the file should NOT be looked for + in the sysroot, or in the alternative namespace. But fixing that + problem would be a much bigger change, so for now lets just disable + the /proc/PID/exe fallback for cases where it might not work. + + For testing, the sysroot case is now tested. + + I don't believe we have any alternative namespace testing. It would + certainly be interesting to add some, but I'm not proposing any with + this patch, so the code for checking the MNT namespace has been tested + manually by me, but isn't covered by a new test I'm adding here. + + Author of the original fix is listed as co-author here. Credit for + identifying the original problem, and proposing a solution belongs to + them. + + Co-Authored-By: Fabian Kilger + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32955 + +2025-06-23 Andrew Burgess + + gdb: better warning when attaching, and executable is unknown + Currently, when attaching to a process, if the user hasn't told GDB + which executable they are going to be debugging, GDB will try to + figure out the executable from the running process. + + There are two (for this patch) interesting places where this can fail, + both in exec_file_locate_attach. + + First GDB calls target_pid_to_exec_file, this does target specific + "stuff" to find the name of the executable file. If this returns NULL + then GDB will give a warning and return. + + After this we need to "find" the executable. This is where we apply + things like the sysroot in order to transform the executable path. + This is done by calling exec_file_find, and this too can return NULL + to indicate that the executable couldn't be found. + + Currently, if exec_file_find returns NULL then GDB doesn't give a + warning, instead we push on and call try_open_exec_file passing in the + NULL pointer as the filename string. This has the effect of removing + the current executable from the current program space. + + However, exec_file_locate_attach already checks there is no executable + attached to the current program space. If there was, then there would + be no need to try and lookup the executable from the running process. + So calling try_open_exec_file with a NULL string is, I claim, + pointless. + + But worse, calling try_open_exec_file with a NULL string means that + GDB prints the message: "No executable file now.", which, while + correct, isn't (I think) very helpful. To me this message indicates + that we've moved from a state of having an executable to a state of + not having one, which isn't correct. + + I think we should introduce a new warning in exec_file_locate_attach, + which is printed if the executable cannot be found. + + So, before this patch GDB's output looked like this: + + (gdb) attach 12345 + Attaching to process 12345 + No executable file now. + warning: Could not load vsyscall page because no executable was specified + 0x00007f0978b94557 in ?? () + (gdb) + + After this patch the output now looks like this: + + (gdb) attach 12345 + Attaching to process 12345 + No executable has been specified, and target executable /tmp/my-exec (deleted) could not be found. Try using the "file" command. + warning: Could not load vsyscall page because no executable was specified + 0x00007f0978b94557 in ?? () + (gdb) + + This warning includes the name of the file that GDB was looking for, + and gives a hint that the 'file' command should be used to tell GDB + which executable is being debugged. Much better. + + There's no test for this change in this commit. The next commit fixes + another (semi-related) bug, and includes a test that checks for this + warning string. + +2025-06-23 Andrew Burgess + + gdbserver: include sys/stat.h for 'struct stat' + Tom de Vries reported a build failure on x86_64-w64-mingw32 after + commit: + + commit bd389c9515d240f55b117075b43184efdea41287 + Date: Wed Jun 11 22:52:16 2025 +0200 + + gdb: implement linux namespace support for fileio_lstat and vFile::lstat + + The build failure looks like this: + + ../../src/gdbserver/hostio.cc: In function 'void handle_lstat(char*, int*)': + ../../src/gdbserver/hostio.cc:544:63: error: cannot convert '_stat64*' to 'stat*' + 544 | ret = the_target->multifs_lstat (hostio_fs_pid, filename, &st); + | ^~~ + | | + | _stat64* + In file included from ./../../src/gdbserver/server.h:58, + from : + ./../../src/gdbserver/target.h:448:74: note: initializing argument 3 of 'virtual int process_stratum_target::multifs_lstat(int, const char*, stat*)' + 448 | virtual int multifs_lstat (int pid, const char *filename, struct stat *sb); + | ~~~~~~~~~~~~~^~ + + The problem is that in sys/stat.h for mingw, 'stat' is #defined to + _stat64, but target.h doesn't include sys/stat.h, and so doesn't see + this #define. + + However, target.h does, by luck, manages to see the actual definition + of 'struct stat', which isn't in sys/stat.h itself, but is in some + other header that just happens to be pulled in by chance. + + As a result of all this, the declaration of + process_stratum_target::multifs_lstat in target.h uses 'struct stat' + for its argument type, while the call in hostio.cc, uses 'struct + _stat64' as its argument type, which causes the build error seen + above. + + The fix is to include sys/stat.h in target.h so that the declaration's + argument type will change to 'struct _stat64' (via the #define). + +2025-06-23 GDB Administrator + + Automatic date update in version.in + +2025-06-22 GDB Administrator + + Automatic date update in version.in + +2025-06-21 Stafford Horne + + or1k: Fix disassembly for little-endian binaries + There are some OpenRISC CPUs that have their binaries stored in + little-endian format. Using objdump to disassemble these is + problematic, as some instructions fail to disassemble, for example: + + objdump -D -b binary -EB -m or1k test_be.bin + + 0: 18 60 07 27 l.movhi r3,0x727 + 4: a8 63 0e 00 l.ori r3,r3,0xe00 + 8: 9c 63 ff ff l.addi r3,r3,-1 + c: bc 43 00 00 l.sfgtui r3,0 + 10: 13 ff ff fe l.bf 0x8 + 14: 44 00 48 00 l.jr r9 + + objdump -D -b binary -EL -m or1k test_le.bin + + 0: 27 07 60 18 *unknown* + 4: 00 0e 63 a8 l.ori r3,r3,0xe00 + 8: ff ff 63 9c *unknown* + c: 00 00 43 bc l.sfgtui r3,0 + 10: fe ff ff 13 *unknown* + 14: 00 48 00 44 l.jr r9 + + It was found that the hash function was using the still little-endian + buffer to extract the opcode used for the hash lookup. This didn't work + as it was pulling the wrong hashcode causing instruction lookup to fail. + + Fix the hash function by using the normalized/byte-swapped value instead + of the buffer. + +2025-06-21 GDB Administrator + + Automatic date update in version.in + +2025-06-20 Aleksandar Rikalo + + gdbsupport: Use xsnprintf() instead of strcat() in print-utils + Theoretically, in functions core_addr_to_string_nz() and + core_addr_to_string(), strcat() can overflow, so use a safe + approach using xsnprintf(). + + Change-Id: Ib9437450b3634dc35077234f462a03a8640242d4 + +2025-06-20 Aleksandar Rikalo + + gdb: Remove redundant null check + This patch simplifies the code at two points by removing redundant + null checks. There is no functional impact. + + Reviewed-By: Keith Seitz + Approved-By: Pedro Alves + Change-Id: I76e1c7fad00e8fcb24ced7bfd75d19cdd6266c32 + +2025-06-20 Srinath Parvathaneni + + aarch64: Support 2024 Debug Architecture system registers. + This patch adds support for following system registers and the spec + can be found here[1]. + 1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE + and Armv9.5-A architecture and these are enabled by passing + -march=armv9.5-a+profile. + 2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture + and these are enabled by passing -march=armv9.5-a. + 3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing + -march=armv8.8-a. + + [1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Registers?lang=en + +2025-06-20 Kirill Radkin + + gdbserver: Update require_int function to parse offset for pread packet + Currently gdbserver uses the require_int() function to parse the + requested offset (in vFile::pread packet and the like). This function + allows integers up to 0x7fffffff (to fit in 32-bit int), however the + offset (for the pread system call) has an off_t type which can be + larger than 32-bit. + + This patch allows require_int() function to parse offset up to the + maximum value implied by the off_t type. + + Approved-By: Pedro Alves + Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c + +2025-06-20 GDB Administrator + + Automatic date update in version.in + +2025-06-19 Simon Marchi + + gdb/testsuite: run isort on gdb.server/fileio-packets.py + `pre-commit run --all-files` found this. + + Change-Id: I8db09b12cf184d32351ff2c579bdaa8cf6f80ac3 + +2025-06-19 Simon Marchi + + gdb/dwarf: change CUs -> units in print_stats + Change the messages to reflect that these numbers includes type units, + not only compile units. + + Change-Id: Id2f511d4666e5cf92112be917d72ff76791b7e1d + Approved-by: Kevin Buettner + +2025-06-19 Ezra Sitorus + + aarch64: Support for FEAT_LSFE + FEAT_LSFE - Large System Float Extension - implements A64 base atomic + floating-point in-memory instructions. + +2025-06-19 Ezra Sitorus + + aarch64: Support for FEAT_SVE_F16F32MM, FEAT_F8F16M, FEAT_F8F32MM + FEAT_SVE_F16F32MM introduces the SVE half-precision floating-point + matrix multiply-accumulate to single-precision instruction. + + FEAT_F8F32MM introduces the Advanced SIMD 8-bit floating-point matrix + multiply-accumulate to single-precision instruction. + + FEAT_F8F16MM introduces the Advanced SIMD 8-bit floating-point matrix + multiply-accumulate to half-precision instruction. + +2025-06-19 Ezra Sitorus + + aarch64: Support for FEAT_CMPBR + FEAT_CMPBR - Compare and branch instructions. This patch adds these + instructions: + - CB (register) + - CB (immediate) + - CBH + - CBB + + where CC is one of the following: + - EQ + - NE + - GT + - GE + - LT + - LE + - HI + - HS + - LO + - LS + +2025-06-19 Ezra Sitorus + + aarch64: Add occmo flag for FEAT_OCCMO + FEAT_OCCMO support was introduced, but the feature flags were missing. + This patch adds these flags, as well as splitting up the tests to test + occmo vs occmo+memtag operands. + + aarch64: Support for FEAT_SVE_BFSCALE + FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in + Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also + introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE + and BFMUL. + +2025-06-19 Andrew Burgess + + gdb/python: introduce gdb.warning() function + This commit adds a new gdb.warning() function. This function takes a + string and then calls GDB's internal warning() function. This will + display the string as a warning. + + Using gdb.warning() means that the message will get the new emoji + prefix if the user has that feature turned on. Also, the message will + be sent to gdb.STDERR without the user having to remember to print to + the correct stream. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-06-19 GDB Administrator + + Automatic date update in version.in + +2025-06-18 WANG Xuerui + + LoongArch: Batch-delete bytes at the end of each relax trip + Previously, memmove and reloc/symbol adjustments happened at each + loongarch_relax_delete_bytes() call, which is O(n^2) time complexity and + leads to unacceptable (multiple hours) linking times for certain inputs + with huge number of relaxable sites -- see the linked issue for details. + + To get rid of the quadratic behavior, defer all delete ops to the end of + each relax trip, with the buffer implemented with the splay tree from + libiberty. The individual relaxation handlers are converted to handle + symbol values and relocation offsets as if all preceding deletions + actually happened, by querying a cumulative offset from the splay tree; + the accesses should be efficient because they are mostly sequential + during a relaxation trip. The exact relaxation behavior remains largely + unchanged. + + Example running times before and after the change with the test case in + the linked issue (mypy transpiled C), cross-linking on Threadripper + 3990X: + Before: 4192.80s user 1.09s system 98% cpu 1:10:53.52 total + After: 1.76s user 0.74s system 98% cpu 2.539 total - ~1/2382 the time! + + Also tested with binutils (bootstrapping self), CPython 3.14 and LLVM + 20.1.6; all passed the respective test suites. + + Link: https://github.com/loongson-community/discussions/issues/56 + +2025-06-18 GDB Administrator + + Automatic date update in version.in + +2025-06-17 Fabian Kilger + + gdb: query inferior's filesystem for build-id debug files + This fixes a bug related to build-id files with linux namespaces. + Specifically, we expect the debug files to be present inside the container, + thus the container filesystem should be queried if the program is running + inside one. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956 + Approved-By: Andrew Burgess + +2025-06-17 Fabian Kilger + + gdb: implement linux namespace support for fileio_lstat and vFile::lstat + The new algorithm to look for a build-id-based debug file + (introduced by commit 22836ca88591ac7efacf06d5b6db191763fd8aba) + makes use of fileio_lstat. As lstat was not supported by + linux-namespace.c, all lstat calls would be performed on the host + and not inside the namespace. Fixed by adding namespace lstat + support. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956 + + Approved-By: Andrew Burgess + +2025-06-17 Andrew Burgess + + gdbserver: fix vFile:stat to actually use 'stat' + This commit continues the work of the previous two commits. + + In the following commits I added the target_fileio_stat function, and + the target_ops::fileio_stat member function: + + * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet + * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation + * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet + * 22836ca8859 gdb: check for multiple matching build-id files + + Unfortunately I messed up, despite being called 'stat' these function + actually performed an 'lstat'. The 'lstat' is the correct (required) + implementation, it's the naming that is wrong. + + Additionally, to support remote targets, these commit added the + vFile::stat packet, which again, performed an 'lstat'. + + In the previous two commits I changed the GDB code to replace 'stat' + with 'lstat' in the fileio function names. I then added a new + vFile:lstat packet which GDB now uses instead of vFile:stat. + + And that just leaves the vFile:stat packet which is, right now, + performing an 'lstat'. + + Now, clearly when I wrote this code I fully intended for this packet + to perform an lstat, it's the lstat that I needed. But now, I think, + we should "fix" vFile:stat to actually perform a 'stat'. + + This is risky. This is a change in remote protocol behaviour. + + Reasons why this might be OK: + + - vFile:stat was only added in GDB 16, so it's not been "in the + wild" for too long yet. If we're quick, we might be able to "fix" + this before anyone realises I messed up. + + - The documentation for vFile:stat is pretty vague. It certainly + doesn't explicitly say "this does an lstat". Most implementers + would (I think), given the name, start by assuming this should be + a 'stat' (given the name). Only if they ran the full GDB + testsuite, or examined GDB's implementation, would they know to + use lstat. + + Reasons why this might not be OK: + + - Some other debug client could be connecting to gdbserver, sending + vFile:stat and expecting to get lstat behaviour. This would break + after this patch. + + - Some other remote server might have implemented vFile:stat + support, and either figured out, or copied, the lstat behaviour + from gdbserver. This remote server would technically be wrong + after this commit, but as GDB no longer uses vFile:stat, then this + will only become a problem if/when GDB or some other client starts + to use vFile:stat in the future. + + Given the vague documentation for vFile:stat, and that it was only + added in GDB 16, I think we should fix it now to perform a 'stat', and + that is what this commit does. + + The change in behaviour is documented in the NEWS file. I've improved + the vFile:stat documentation in the manual to better explain what is + expected from this packet, and I've extended the existing test to + cover vFile:stat. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-06-17 Andrew Burgess + + gdbserver: add vFile:lstat packet support + In the following commits I added the target_fileio_stat function, and + the target_ops::fileio_stat member function: + + * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet + * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation + * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet + * 22836ca8859 gdb: check for multiple matching build-id files + + Unfortunately I messed up, despite being called 'stat' these function + actually performed an 'lstat'. The 'lstat' is the correct (required) + implementation, it's the naming that is wrong. + + In the previous commit I fixed the naming within GDB, renaming 'stat' + to 'lstat' throughout. + + However, in order to support target_fileio_stat (as was) on remote + targets, the above patches added the vFile:stat packet, which actually + performed an 'lstat' call. This is really quite unfortunate, and I'd + like to do as much as I can to try and clean up this mess. But I'm + mindful that changing packets is not really the done thing. + + So, this commit doesn't change anything. + + Instead, this commit adds vFile:lstat as a new packet. + + Currently, this packet is handled identically as vFile:stat, the + packet performs an 'lstat' call. + + I then update GDB to send the new vFile:lstat instead of vFile:stat + for the remote_target::fileio_lstat implementation. + + After this commit GDB will never send the vFile:stat packet. + + However, I have retained the 'set remote hostio-stat-packet' control + flag, just in case someone was trying to set this somewhere. + + Then there's one test in the testsuite which used to disable the + vFile:stat packet, that test is updated to now disable vFile:lstat. + + There's a new test that does a more direct test of vFile:lstat. This + new test can be extended to also test vFile:stat, but that is left for + the next commit. + + And so, after this commit, GDB sends the new vFile:lstat packet in + order to implement target_ops::fileio_lstat. The new packet is more + clearly documented than vFile:stat is. But critically, this change + doesn't risk breaking any other clients or servers that implement + GDB's remote protocol. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-06-17 Andrew Burgess + + gdb: rename target_fileio_stat to target_fileio_lstat + In the following commits I added the target_fileio_stat function, and + the target_ops::fileio_stat member function: + + * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet + * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation + * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet + * 22836ca8859 gdb: check for multiple matching build-id files + + Unfortunately, I messed up when adding this API. The actual + underlying call is lstat, not stat. + + This commit tries to clear up some of the confusion by renaming things + to target_fileio_lstat and target_ops::fileio_lstat. + + After this change the function names now match the underlying + implementation. + + One problem remains though. In order to support target_fileio_stat + for remote target the above patches added the vFile:stat packet to GDB + and gdbserver. The implementation of this packet still does an lstat + though, which is a bit of a shame. I'm going to try and fix that in + later commits. + + This commit is just a rename within GDB, there should be no user + visible changes. + + Approved-By: Tom Tromey + +2025-06-17 Simon Marchi + + gdb/dwarf: rename get_cu -> get_unit + This method returns type units too, so "get_unit" is a better name. + + Change-Id: I6ec9de3f783637a3e206bcaaec96a4e00b4b7d31 + Approved-By: Tom Tromey + +2025-06-17 oltolm + + gdb/dap: allow more requests when the process is running + Makes it possible to set and remove other types of breakpoints while the + process is running. Makes debugging more convenient. + + Approved-By: Tom Tromey + +2025-06-17 Timur + + gdb/record: Support csrrci instruction in risc-v + During testing csr instructions in risc-v, it occurs that instruction csrrci + is unsupported for recording process and there is such warning: + 'warning: Currently this instruction with len 4(100174f3) is unsupported', so + recording failed. This patch fixes this error. + +2025-06-17 timurgol007 + + gdb: add Timur Golubovich to gdb/MAINTAINERS + +2025-06-17 Tom de Vries + + [gdb/testsuite] Set interactive-mode to on + With MSYS2 and test-case gdb.ada/assign_1.exp, we get: + ... + (gdb) dir^M + Reinitialize source path to empty? (y or n) \ + [answered Y; input not from terminal]^M^M + Source directories searched: $cdir;$cwd^M^M + (gdb) + ... + + GDB automatically answers the query, because interactive-mode is off: + ... + (gdb) show interactive-mode^M + Debugger's interactive mode is auto (currently off).^M^M + ... + + The correct value is on, because GDB was started in a terminal. + + For some reason, the auto value of interactive-mode is off instead. According + to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite + as an interactive setup. + + Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that + we get: + ... + (gdb) dir^M + Reinitialize source path to empty? (y or n) y^M + Source directories searched: $cdir;$cwd^M^M + (gdb) + ... + and no longer need fixes like commit be740e7cc62 ("testsuite: skip + confirmation in 'gdb_reinitialize_dir'") + + The fix is essentially the same as in aforementioned patch. + + For consistency, we apply the fix for all platforms. + + Co-Authored-By: Pierre Muller + Approved-By: Tom Tromey + + [1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html + +2025-06-17 Tom de Vries + + [gdb/testsuite] Set TERM to dumb by default + With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I + get: + ... + builtin_spawn gdb -q ... + ^[[6n(gdb) ERROR: GDB never initialized. + ... + + This is not specific to gdb, other tools produce the same CSI sequence, and + consequently we run into trouble in other places (like get_compiler_info). + + Fix this by default-setting TERM to dumb. + + We do this for all platforms, to avoid test-cases passing on one platform but + failing on another. + + For test-cases that set TERM to something other than dumb, handle the CSI + sequence in default_gdb_start. + + Approved-By: Tom Tromey + + PR testsuite/33072 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072 + +2025-06-17 GDB Administrator + + Automatic date update in version.in + +2025-06-16 Indu Bhagat + + bfd: fix a minor typo + +2025-06-16 Guinevere Larsen + + gdb/doc: Explain linker namespaces + Recent GDB commits added more features related to linker namespaces and + documented them on the manual, but did not add a convenient way for a + user to understand what they are. This commit adds a quick explanation + of what they are. + + It also fixes the inconsistency of using "linker namespaces" and + "linkage namespaces", by always using the first form to avoid user + confusion. + + Approved-By: Eli Zaretskii + +2025-06-16 Andrew Burgess + + gdb/doc: remove stray comma from gdb.flush description + Remove comma from: gdb.flush([, stream]) . I suspect this was a copy + and paste from gdb.write(string [, stream]) where the comma is + correct. + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: disable forward progress requirement in amd_dbgapi_target_breakpoint::check_status + ROCgdb handles target events very slowly when running a test case like + this, where a breakpoint is preset on HipTest::vectorADD: + + for (int i=0; i < numDevices; ++i) { + HIPCHECK(hipSetDevice(i)); + hipLaunchKernelGGL(HipTest::vectorADD, dim3(blocks), dim3(threadsPerBlock), 0, stream[i], + static_cast(A_d[i]), static_cast(B_d[i]), C_d[i], N); + } + + What happens is: + + - A kernel is launched + - The internal runtime breakpoint is hit during the second + hipLaunchKernelGGL call, which causes + amd_dbgapi_target_breakpoint::check_status to be called + - Meanwhile, all waves of the kernel hit the breakpoint on vectorADD + - amd_dbgapi_target_breakpoint::check_status calls process_event_queue, + which pulls the thousand of breakpoint hit events from the kernel + - As part of handling the breakpoint hit events, we write the PC of the + waves that stopped to decrement it. Because the forward progress + requirement is not disabled, this causes a suspend/resume of the + queue each time, which is time-consuming. + + The stack trace where this all happens is: + + #32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587 + #33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 , regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504 + #34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973 + #35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890 + #36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915 + #37 0x0000555559fc3ca5 in regcache::cooked_write (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850 + #38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858 + #39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460 + #40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873 + #41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006 + #42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890 + #43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126 + #44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169 + #45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621 + #46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750 + #47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42 + #48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513 + + Fix that performance problem by disabling the forward progress + requirement in amd_dbgapi_target_breakpoint::check_status, before + calling process_event_queue, so that we can process all events + efficiently. + + Since the same performance problem could theoritically happen any time + process_event_queue is called with forward progress requirement enabled, + add an assert to ensure that forward progress requirement is disabled + when process_event_queue is invoked. This makes it necessary to add a + require_forward_progress call to amd_dbgapi_finalize_core_attach. It + looks a bit strange, since core files don't have execution, but it + doesn't hurt. + + Add a test that replicates this scenario. The test launches a kernel + that hits a breakpoint (with an always false condition) repeatedly. + Meanwhile, the host process loads an unloads a code object, causing + check_status to be called. + + Bug: SWDEV-482511 + Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec + Approved-by: Lancelot Six + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: factor out require_forward_progress overload to target one inferior + A following patch will want to call require_forward_progress for a given + inferior. Extract a new require_forward_progress overload from the + existing require_forward_progress function that targets a specific + inferior. + + Change-Id: I54f42b83eb8443d4d91747ffbc86eaeb017f1e49 + Approved-by: Lancelot Six + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_one_event + Pass the amd_dbgapi_inferior_info object from process_event_queue to + process_one_event. Since process_event_queue pulls events for one + specific inferior, we know for which inferior the event is. This + removes the need for process_one_event to do two dbgapi calls to get the + relevant pid. If also removes one inferior lookup. + + Change-Id: I22927e4b6251513eb3be95785082058aa3d09954 + Approved-by: Lancelot Six + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_event_queue + A following patch will make process_event_queue access a field of + amd_dbgapi_inferior_info. Prepare for this by making + process_event_queue accept an amd_dbgapi_inferior_info object, instead + of a process id. + + Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b + Approved-by: Lancelot Six + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: add assert in require_forward_progress + I didn't have a problem in this area, but it seems to me that this + pre-condition should always hold. We should only disable forward + progress requirement if the target says it's ok to do so. Otherwise, we + could get in a situation where we wait for events from amd-dbgapi, which + will never arrive, because amd-dbgapi didn't actually resume things. + + Change-Id: Ifc49f55c7874924b7c47888b8391a07a01d960fc + Approved-by: Lancelot Six + +2025-06-16 Simon Marchi + + gdb/amd-dbgapi: remove unnecessary AMD_DBGAPI_EVENT_KIND_NONE argument + Rely on the default value. + + Change-Id: I08c683de005806c5c5d29ed7f9b0c6de81b49a01 + Approved-By: Lancelot Six + +2025-06-16 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-source-styling-2.exp with TERM=dumb + When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I + get: + ... + (gdb) set style enabled on^M + warning: The current terminal doesn't support styling. \ + Styled output might not appear as expected.^M + (gdb) FAIL: $exp: set style enabled on + ... + + Fix this by using with_ansi_styling_terminal on clean_restart. + + Tested on x86_64-linux. + +2025-06-16 GDB Administrator + + Automatic date update in version.in + +2025-06-15 GDB Administrator + + Automatic date update in version.in + +2025-06-14 H.J. Lu + + objcopy: Correctly check archive element for LTO IR + commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d + Author: H.J. Lu + Date: Sun May 4 05:12:46 2025 +0800 + + strip: Add GCC LTO IR support + + added: + + @@ -3744,6 +3768,12 @@ copy_archive (bfd *ibfd, bfd *obfd, const char + *output_target, + goto cleanup_and_exit; + } + + +#if BFD_SUPPORTS_PLUGINS + + /* Copy LTO IR file as unknown object. */ + + if (bfd_plugin_target_p (ibfd->xvec)) + ^^^^ A typo, should be this_element. + + ok_object = false; + + else + +#endif + if (ok_object) + { + ok = copy_object (this_element, output_element, input_arch); + + to check if the archive element is a LTO IR file. "ibfd" is the archive + BFD. "this_element" should be used to check for LTO IR in the archive + element. Fix it by replacing "ibfd" with "this_element". + + PR binutils/33078 + * objcopy.c (copy_archive): Correctly check archive element for + LTO IR. + * testsuite/binutils-all/objcopy.exp (strip_test_archive): New. + Run strip_test_archive. + +2025-06-14 Jeremy Bryant + + * gdb/doc/gdb.texinfo (Emacs): Refer to Emacs manual + The manual section on using GDB under Emacs is out-of-date and + duplicates existing and comprehensive documentation in the Emacs + manual. + + Replace the section by a short introduction and reference. + + Approved-By: Eli Zaretskii + +2025-06-14 Stafford Horne + + or1k: Add support for numcores and coreid sprs + These are needed when running GCC tests for newlib toolchains built with + multicore support. Without these SPRs we get the following warnings + when running tests. + + spawn or1k-elf-run ./20000112-1.exe^M + WARNING: l.mfspr with invalid SPR address 0x80^M + WARNING: l.mfspr with invalid SPR address 0x81^M + WARNING: l.mfspr with invalid SPR address 0x81^M + WARNING: l.mfspr with invalid SPR address 0x81^M + + Support is added by defining the SPRs in the cgen machine definition and + regenerating the machine code. In or1k/or1k.c we initialize NUMCORES to + 1 and COREID to 0 as the sim has only one CPU. In or1k/traps.c we allow + returning the NUMCORES and COREID spr values in the mfspr function. + +2025-06-14 GDB Administrator + + Automatic date update in version.in + +2025-06-13 Simon Marchi + + gdbsupport: make gdb::parallel_for_each's n parameter a template parameter + This value will likely never change at runtime, so we might as well make + it a template parameter. This has the "advantage" of being able to + remove the unnecessary param from gdb::sequential_for_each. + + Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674 + Approved-By: Tom Tromey + +2025-06-13 Simon Marchi + + gdb: re-work parallel-for-selftests.c + I find this file difficult to work with and modify, due to how it uses + the preprocessor to include itself, to generate variations of the test + functions. Change it to something a bit more C++-y, with a test + function that accepts a callback to invoke the foreach function under + test. + + Change-Id: Ibf1e2907380a88a4f8e4b4b88df2b0dfd0e9b6c8 + +2025-06-13 Simon Marchi + + gdb/dwarf: make cooked_index_flag's to_string handle IS_SYNTHESIZED + Change-Id: Iaac252aa2abbe169153e79b84f956cda172c69d1 + +2025-06-13 Jan Beulich + + x86: don't constrain %axl/%cxl + They can be used like their %al/%cl counterparts everywhere else; + there's no apparent reason why they shouldn't be usable as accumulator / + shift count respectively. Enforcing such a restriction only makes + writing heavily macro-ized code more cumbersome. + +2025-06-13 Jan Beulich + + x86: swap operands in OUT-with-immediate template + In a number of places we assume that immediates come first in the set of + operands. It is mere luck that so far OUT, having operands the other way + around, wasn't negatively impacted by this. + + Leverage this to have a few loops start from the first non-immediate + operand (or in one case to stop there). Note, however, that + process_immext() inserts an immediate last, so especially all output_*() + functions cannot be changed in the same way. + +2025-06-13 H.J. Lu + + elf: Return false if output_section is NULL + Return false if output_section is NULL so that on input + + https://sourceware.org/bugzilla/attachment.cgi?id=16131 + + objcopy generates + + objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3] + objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3] + objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879 + objcopy: /tmp/stv73zYw/OrcError.cpp.o[.text._ZN4llvm3orc8orcErrorENS0_12OrcErrorCodeE]: bad value + + instead of + + objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x22000000) in group [3] + objcopy: /tmp/objcopy-poc(OrcError.cpp.o): invalid entry (0x21000000) in group [3] + objcopy: /tmp/objcopy-poc(OrcError.cpp.o)(.text._ZNK12_GLOBAL__N_116OrcErrorCategory7messageB5cxx11Ei): relocation 29 has invalid symbol index 1160982879 + Segmentation fault (core dumped) + + PR binutils/33075 + * elf.c (elf_map_symbols): Return false if output_section is + NULL. + +2025-06-13 Jan Beulich + + x86: refine UD kind-of-insns + While documentation of these continues to be lacking sufficient detail, + it is becoming increasingly clear that in 66f1eba0b7e8 ("x86: correct + UDn") I went too far with requiring operands, to populate a ModR/M byte. + AMD hardware appears to always behave as indicated as "may" in PM 3.36, + which for all practical purposes means there's no ModR/M byte. The SDM + (rev 087) indicates that such behavior can occur on older hardware for + UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while + newly adding such a form also for UD0. Because of the ambiguity, there's + no good/easy way of handling both possibilities in the disassembler, + which hence remains unaltered. + + Further, from all information I'm able to gather, the 0F opcode space + was only introduced with the i286; bump the minimal hardware requirement + for all UD accordingly. + +2025-06-13 Jan Beulich + + gas: switch convert_to_bignum() to taking just an expression + Both callers, despite spelling things differently, now pass the same + input for its 2nd parameter. Therefore, as was supposed to be the case + anyway, this 2nd parameter isn't needed anymore - the function can + calculate "sign" all by itself from the incoming expression. Instead + make the function return the resulting value, for emit_expr_with_reloc() + to consume for setting its "extra_digit" local variable. + +2025-06-13 Jan Beulich + + gas: also maintain signed-ness for O_big expressions + Interestingly emit_leb128_expr() already assumes X_unsigned is properly + set for O_big. Adjust its conversion-to-bignum to respect the incoming + flag, and have convert_to_bignum() correctly set it on output. + + It further can't be quite right that convert_to_bignum() depends on + anything other than the incoming expression. Therefore adjust + emit_expr_with_reloc() to be in line with the other invocation. + + This also requires an adjustment for SH, which really should have been + part of 762acf217c40 ("gas: maintain O_constant signedness in more + cases"). + +2025-06-13 Jeremy Drake + + bfd: populate delay import directory in PE header + Previously, the delay import table was constructed but its rva and size + were never put into the PE optional header. + + dlltool: respect use-nul-prefixed-import-tables option for delaylib + Noticed the extra zeros while inspecting the output. + + ld,dlltool: move read-only delayimp data into .rdata + This allows the delay IAT to be in its own section with nothing else, as + required by IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION, documented at + https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#load-configuration-layout + +2025-06-13 LIU Hao + Jeremy Drake + + bfd,ld,dlltool: Emit delay-load import data into its own section + A delay-import symbol (of a function) is resolved when a call to it is made. + The delay loader may overwrite the `__imp_` pointer to the actual function + after it has been resolved, which requires the pointer itself be in a + writeable section. + + Previously it was placed in the ordinary Import Address Table (IAT), which + is emitted into the `.idata` section, which had been changed to read-only + in db00f6c3aceabbf03acdb69e74b59b2d2b043cd7, which caused segmentation + faults when functions from delay-import library were called. This is + PR 32675. + + This commit makes DLLTOOL emit delay-import IAT into `.didat`, as specified + by Microsoft. Most of the code is copied from `.idata`, except that this + section is writeable. As a side-effect of this, PR 14339 is also fixed. + + Using this DEF: + + ``` + ; ws2_32.def + LIBRARY "WS2_32.DLL" + EXPORTS + WSAGetLastError + ``` + + and this C program: + + ``` + // delay.c + #define WIN32_LEAN_AND_MEAN 1 + #include + #include + + ///////////////////////////////////////////////////////// + // User code + ///////////////////////////////////////////////////////// + + DWORD WINAPI WSAGetLastError(void); + extern PVOID __imp_WSAGetLastError; + + int + main(void) + { + fprintf(stderr, "before delay load, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError); + SetLastError(123); + fprintf(stderr, "WSAGetLastError() = %d\n", WSAGetLastError()); + fprintf(stderr, "after delay load, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError); + __imp_WSAGetLastError = (PVOID) 1234567; + fprintf(stderr, "after plain write, __imp_WSAGetLastError = %p\n", __imp_WSAGetLastError); + } + + ///////////////////////////////////////////////////////// + // Overridden `__delayLoadHelper2` facility + ///////////////////////////////////////////////////////// + + extern char __ImageBase[]; + PVOID WINAPI ResolveDelayLoadedAPI(PVOID ParentModuleBase, LPCVOID DelayloadDescriptor, + PVOID FailureDllHook, PVOID FailureSystemHook, + FARPROC* ThunkAddress, ULONG Flags); + FARPROC WINAPI DelayLoadFailureHook(LPCSTR name, LPCSTR function); + + FARPROC WINAPI __delayLoadHelper2(LPCVOID pidd, FARPROC* ppfnIATEntry) + { + return ResolveDelayLoadedAPI(&__ImageBase, pidd, NULL, (PVOID) DelayLoadFailureHook, + ppfnIATEntry, 0); + } + ``` + + This program used to crash: + + ``` + $ dlltool -nn -d ws2_32.def -y delay_ws2_32.a + $ gcc -g delay.c delay_ws2_32.a -o delay.exe + $ ./delay.exe + before delay load, __imp_WSAGetLastError = 00007FF6937215C6 + Segmentation fault + ``` + + After this commit, it loads and calls `WSAGetLastError()` properly, and + `__imp_WSAGetLastError` is writeable: + + ``` + $ dlltool -nn -d ws2_32.def -y delay_ws2_32.a + $ gcc -g delay.c delay_ws2_32.a -o delay.exe + $ ./delay.exe + before delay load, __imp_WSAGetLastError = 00007FF76E2215C6 + WSAGetLastError() = 123 + after delay load, __imp_WSAGetLastError = 00007FFF191FA720 + after plain write, __imp_WSAGetLastError = 000000000012D687 + ``` + + Reference: https://learn.microsoft.com/en-us/windows/win32/secbp/pe-metadata#import-handling + +2025-06-13 GDB Administrator + + Automatic date update in version.in + +2025-06-12 Tom Tromey + + Minor grammar fix in DAP comment + I noticed a minor grammer issue in a comment in DAP. + +2025-06-12 Klaus Gerlicher + + gdb, linespec: avoid multiple locations with same PC + Setting a BP on a line like this would incorrectly yield two BP locations: + + 01 void two () { {int var = 0;} } + + (gdb) break 1 + Breakpoint 1 at 0x1164: main.cpp:1. (2 locations) + + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y + 1.1 y 0x0000000000001164 in two() at main.cpp:1 + 1.2 y 0x0000000000001164 in two() at main.cpp:1 + + In this case decode_digits_ordinary () returns two SALs, exactly matching the + requested line. One for the entry PC and one for the prologue end PC. This + was + tested with GCC, CLANG and ICPX. Subsequent code tries to skip the prologue + on these PCs, which in turn makes them the same. + + To fix this, ignore SALs with the same PC and program space when adding to the + list of SALs. + + This will then properly set only one location: + + (gdb) break 1 + Breakpoint 1 at 0x1164: file main.cpp, line 1 + + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y 0x0000000000001164 in two() at main.cpp:1 + + Approved-By: Simon Marchi + +2025-06-12 Andrew Burgess + + gdb: convert linux-namespaces debug to the new(er) debug scheme + Convert 'set debug linux-namespaces' to the new(er) debug scheme. As + part of this change I converted the mnsh_debug_print_message function, + which previously printed its output, to instead return a std::string, + this string is then printed using linux_namespaces_debug_printf. The + mnsh_debug_print_message function is only used as part of the debug + output. + + I also updated one place in the code where debug_linux_namespaces, the + debug control variable, which is a boolean, was assigned an integer. + + When debug is turned on then clearly the output is now different, but + in all other cases, there should be no user visible change in GDB + after this commit. + + Approved-By: Tom Tromey + +2025-06-12 Richard Ball + + aarch64: Add support for FEAT_FPRCVT + FEAT_FPRCVT introduces new versions of previous instructions. + The instructions are used to convert between floating points and + Integers. These new versions take as operands SIMD&FP registers + for both the source and destination register. FEAT_FPRCVT also + enables the use of some existing AdvSIMD instructions in + streaming mode. However, no changes are needed in gas to support this. + +2025-06-12 GDB Administrator + + Automatic date update in version.in + +2025-06-11 Aaron Griffith + + gdb: fix size of z80 "add ii,rr" and "ld (ii+d),n" instructions + The tables in z80-tdep.c previously either gave these instructions the + wrong size, or failed to recognize them by using the wrong masks, or + both. The fixed instructions alongside their representation in octal are: + + * add ii,rr: [0335] 00r1 (where r & 1 == 1) + [0375] 00r1 + * ld (ii+d,n): [0335] 0066 + [0375] 0066 + + Prefix bytes inside [] do not count towards instruction length in + these tables. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33066 + Approved-By: Tom Tromey + +2025-06-11 Thiago Jung Bauermann + + GDB: doc: Improve AArch64 subsubsection titles and index entries in gdb.texinfo + Remove period from subsubsection titles in the AArch64 configuration-specific + subsection, and expand acronyms. + + Regarding @cindex entries, remove periods and standardise their order + and the position of "AArch64" to make it easier to find them by + using the index-searching commands of Info readers that offer TAB + completion. + + Approved-By: Eli Zaretskii + +2025-06-11 Matthieu Longo + + Arm tests: reduce objdump's output and improve some matching patterns + Linker scripts can change the sections order in the output. Some matching + patterns in tests try to detect the end of a section by detecting the + beginning of the next one. However, they mistakenly enforce the name of + the next section without any need. This caused the tests to break due to + minor changes to the linker scripts. + + This patch adds '-j ' to the arguments of objdump + to dump only relevant information for the tests. This removed the issue + related to the ordering of the sections. The matching patterns were also + made stricter to match better the expected output. + +2025-06-11 Pedro Alves + + gdb testsuite: Introduce allow_multi_inferior_tests and use it throughout + The Windows port does not support multi-process debugging. Testcases + that want to exercise multi-process currently FAIL and some hit + cascading timeouts. Add a new allow_multi_inferior_tests procedure, + meant to be used with require, and sprinkle it throughout testcases as + needed. + + Approved-by: Kevin Buettner + Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb + +2025-06-11 Pedro Alves + + gdb testsuite: Introduce allow_fork_tests and use it throughout + Cygwin debugging does not support follow fork. There is currently no + interface between the debugger and the Cygwin runtime to be able to + intercept forks and execs. Consequently, testcases that try to + exercise fork/exec all FAIL, and several hit long cascading timeouts. + + Add a new allow_fork_tests procedure, meant to be used with require, + and sprinkle it throughout testcases that exercise fork. + + Note that some tests currently are skipped on targets other than + Linux, with something like: + + # Until "set follow-fork-mode" and "catch vfork" are implemented on + # other targets... + # + if {![istarget "*-linux*"]} { + continue + } + + However, some BSD ports also support fork debugging nowadays, and the + testcases were never adjusted... That is why the new allow_fork_tests + procedure doesn't look for linux. + + With this patch, on Cygwin, I get this: + + $ make check TESTS="*/*fork*.exp" + + ... + === gdb Summary === + + # of expected passes 6 + # of untested testcases 1 + # of unsupported tests 31 + + Reviewed-By: Keith Seitz + Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978 + +2025-06-11 Pedro Alves + + gdb.multi/attach-no-multi-process.exp: Detect no remote non-stop + Running gdb.multi/attach-no-multi-process.exp on Cygwin, where + GDBserver does not support non-stop mode, I see: + + FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads + FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout) + FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout) + + Let's ignore the first "info threads" fail. The timeouts look like + this: + + builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346 + Listening on port 2346 + target extended-remote localhost:2346 + Remote debugging using localhost:2346 + Non-stop mode requested, but remote does not support non-stop + (gdb) gdb_do_cache: can_spawn_for_attach ( ) + builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process + attach 14540 + FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout) + info threads + FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout) + + Note the "Non-stop mode requested, but remote does not support + non-stop" line. + + The intro to gdb_target_cmd_ext says: + + # gdb_target_cmd_ext + # Send gdb the "target" command. Returns 0 on success, 1 on failure, 2 on + # unsupported. + + That's perfect here, we can just use gdb_target_cmd_ext instead of + gdb_target_cmd, and check for 2 (unsupported). That's what this patch + does. + + However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the + case where the remote target says it does not support non-stop. That + is also fixed by this patch. + + With this, we no longer get those timeout fails. We get instead: + + target extended-remote localhost:2346 + Remote debugging using localhost:2346 + Non-stop mode requested, but remote does not support non-stop + (gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP + + Approved-by: Kevin Buettner + Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236 + +2025-06-11 Pedro Alves + + Convert gdb.base/watchpoint-hw-attach.exp to spawn_wait_for_attach + On Cygwin, starting an inferior under GDB, and detaching it, quitting + GDB, and then closing the shell, like so: + + (gdb) start + (gdb) detach + (gdb) quit + # close shell + + ... hangs the parent shell of GDB (not GDB!) until the inferior + process that was detached (as it is still using the same terminal GDB + was using) exits too. + + This leads to odd failures in gdb.base/watchpoint-hw-attach.exp like + so: + + detach + Detaching from program: .../outputs/gdb.base/watchpoint-hw-attach/watchpoint-hw-attach, process 16580 + [Inferior 1 (process 16580) detached] + (gdb) FAIL: gdb.base/watchpoint-hw-attach.exp: detach + + Fix this by converting the testcase to spawn the inferior outside GDB, + with spawn_wait_for_attach. + + With this patch, the testcase passes cleanly on Cygwin, for me. + + Approved-By: Tom Tromey + Change-Id: I8e3884073a510d6fd2fff611e1d26fc808adc4fa + +2025-06-11 dongjianqiang (A) + + ld: arm32: fix segfault when linking foreign BFDs [PR32870] + PR ld/32870 + + The linker may occasionally need to process a BFD that is from a + non-Arm architecture. There will not be any Arm-specific tdata in + that case, so skip such BFDs when looking for iplt information as the + necessary tdata will not be present. + +2025-06-11 Tom Tromey + + Fix Solaris build + Commit 58984e4a ("Use gdb::function_view in iterate_over_threads") + broke the Solaris build. This patch attempts to fix it, changing + find_signalled_thread to have the correct signature, and correcting a + couple of problems in sol_thread_target::get_ada_task_ptid. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33073 + +2025-06-11 Jan Beulich + + ld/PE: special-case relocation types only for COFF inputs + In 72cd2c709779 ("ld/PE: no base relocs for section (relative) ones") I + made a pre-existing problem quite a bit worse: When looking at a + relocation's (numerical) howto->type, that value is meaningful only if + the object was of corresponding COFF type. ELF objects in particular + have their own enumeration. As it stands, specifically the not entirely + unusual R_X86_64_32 and R_X86_64_32S did no longer have relocations + emitted for them, due to matching R_AMD64_SECTION and R_AMD64_SECREL in + value respectively. + + arm: ignore inapplicable .arch=no... + Unlike for command line options, where a base architecture needs to be + provided explicitly, the .arch directive doesn't have such a + requirement. Therefore it is odd that disabling of an inapplicable + extension isn't silently ignored; claiming "not allowed for the current + base architecture" is at best misleading. Alter the error path to emit a + more "soft" diagnostic in that case instead. + +2025-06-11 Matthieu Longo + + AArch64 variant PCS tests: remove RWX permissions on segments + The symbols of variant PCS functions require special handling. The variant PCS + tests check both the relocation information and the markings in the symbol table. + Those tests dump a lot of addresses, so a custom linker script, variant_pcs.ld + was used to control reliably the addresses of the sections. + + However, the linker script does not provide information enough to the linker to + assess the right set of permisssions on segments (i.e. Read/Write/Execute). + This insufficiency caused the linker to bundle all the sections in a same segment + with the union of all the required permissions, i.e. RWX. + A segment with such lax permissions constitutes a security hole, so the linker + emits the following warning message: + has a LOAD segment with RWX permissions. + This warning message is noisy in the tests, and has no reason to exist. + + This issue can be addressed in two ways: + - either by providing the right set of permissions on a section so that the + linker assigns them to a segment with compatible permissions. + - or by providing alignment constraints so that the linker can move the sections + automatically to a new segment and set the right permission for non-executable + data. + + The second option seems to be the preferred approach, even if not explicitly + recommended. Examples of linker scripts for AArch64 are available at [1]. + This patch reorganizes the linker script to eliminate RWX segments by changing + the order of the sections and their offset. The tests needed to be amended to + match the new addresses. + + [1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in + -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when + -building-an-executable?lang=en + +2025-06-11 Matthieu Longo + + AArch64 BTI/PAC PLT tests: remove RWX permissions on segments + The bti-far.ld and bti-plt.ld scripts don't provide information enough to the + linker to assess the right set of permisssions on segments (i.e. Read/Write/Execute). + This insufficiency caused the linker to bundle all the sections in a same segment + with the union of all the required permissions, i.e. RWX. + A segment with such lax permissions constitutes a security hole, so the linker + emits the following warning message: + has a LOAD segment with RWX permissions. + This warning message is noisy in the tests, and has no reason to exist. + + This issue can be addressed in two ways: + - either by providing the right set of permissions on a section so that the + linker assigns them to a segment with compatible permissions. + - or by providing alignment constraints so that the linker can move the sections + automatically to a new segment and set the right permission for non-executable + data. + + The second option seems to be the preferred approach, even if not explicitly + recommended. Examples of linker scripts for AArch64 are available at [1]. + The fixes in bti-far.ld and bti-plt.ld are the same, except that bti-far.ld also + contains a ".far" section, to make sure that it generates the trampolines correctly. + + [1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in + -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when + -building-an-executable?lang=en + +2025-06-11 Matthieu Longo + + AArch64 tests: remove RWX permissions on segments + aarch64.ld is the linker script used by most of the relocation tests in AArch64 + testsuite. The script does not provide information enough to the linker to assess + the right set of permisssions on segments (i.e. Read/Write/Execute). + This insufficiency caused the linker to bundle all the sections in a same segment + with the union of all the required permissions, i.e. RWX. + A segment with such lax permissions constitutes a security hole, so the linker + emits the following warning message: + has a LOAD segment with RWX permissions. + This warning message is noisy in the tests, and has no reason to exist. + + This issue can be addressed in two ways: + - either by providing the right set of permissions on a section so that the + linker assigns them to a segment with compatible permissions. + - or by providing alignment constraints so that the linker can move the sections + automatically to a new segment and set the right permission for non-executable + data. + + The second option seems to be the preferred approach, even if not explicitly + recommended. Examples of linker scripts for AArch64 are available at [1]. + + [1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in + -armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when + -building-an-executable?lang=en + +2025-06-11 Yury Khrustalev + + aarch64: Add system registers for 2024 MPAM extension + This patch adds support for new system registers introduced in the + 2024 MPAM extension (Memory Partitioning and Monitoring): + + Available in Armv9.3-A: + MPAMBW0_EL1, + MPAMBW1_EL1, + MPAMBW1_EL12, + MPAMBW2_EL2, + MPAMBW3_EL3, + MPAMBWCAP_EL2, + MPAMBWIDR_EL1 + + Available in Armv9.3-A with SME: + MPAMBWSM_EL1 + + The details can be found in [1]. + + [1]: https://developer.arm.com/documentation/ddi0601/latest + +2025-06-11 Yury Khrustalev + + aarch64: Add definitions for missing architecture bits + Complete macros for feature bits for v9.1-A, v9.2-A, v9.3-A, + and v9.4-A. + +2025-06-11 GDB Administrator + + Automatic date update in version.in + +2025-06-10 Alan Modra + + gas md_apply_fix value casts + These are all innocuous but unneeded. pdp11 and ppc are only formatting. + + gas md_apply_fix bad casts + ns32k and z8k cast a valueT pointer to a long pointer when loading + md_apply_fix's value. That's quite wrong if the types have different + sizes, as they may eg. on a 32-bit host with 64-bit bfd support. + sparc also loads the value via a cast pointer, but at least in that + case the cast is to the same size pointer. None of these casts are + needed. Get rid of them. + +2025-06-10 Alan Modra + + loongarch gcc-4.5 build fixes + Yet another case of missing fields in struct initialisation, which + I've replaced with a memset, and some complaints about identifiers + shadowing global declarations. Fixing the shadowing in + loongarch-parse.y is easy. This one isn't so easy: + gas/expr.c: In function 'expr': + gas/expr.c:1891:12: error: declaration of 'is_unsigned' shadows a global declaration + include/opcode/loongarch.h:224:14: error: shadowed declaration is here + + opcode/loongarch.h declares lots of stuff that shouldn't be made + available to generic gas code, so I've removed that header from + tc-loongarch.h and moved the parts of TC_FORCE_RELOCATION_SUB_LOCAL + and TC_FORCE_RELOCATION_SUB_LOCAL that need LARCH_opts to functions + in tc-loongarch.c + + * config/loongarch-parse.y (loongarch_parse_expr): Rename + param to avoid shadowing. + * config/tc-loongarch.c (loongarch_assemble_INSNs): Use memset + rather than struct initialisation. + (loongarch_force_relocation_sub_local): New function. + (loongarch_force_relocation_sub_same): Likewise. + * config/tc-loongarch.h: Don't include opcode/loongarch.h. + (loongarch_force_relocation_sub_local): Declare, and.. + (TC_FORCE_RELOCATION_SUB_LOCAL): ..use here. + (loongarch_force_relocation_sub_same): Declare, and.. + (TC_FORCE_RELOCATION_SUB_SAME): ..use here. + +2025-06-10 Alan Modra + + kvx gcc-4.5 build fixes + More missing struct initialisers, for expressionS vars that in this + case don't need to be initialised. Also an error: redefinition of + typedef 'symbolS'. OK, so don't use a typedef. + + csky gcc-4.5 build fix + gcc-4.5 warns about missing csky_cpus struct initialisers. Fix that + by providing everything in the init macros and the zero sentinel, + rather than just a single {0} as allowed by C99. + + gas m68hc11 use standard qsort predicate signature + Avoid a function cast when using cmp_opcode with qsort. + + Re: Further rs_code_align support refinement + Don't write the repeating nop pattern if it won't be used for alpha + handle_align too. + +2025-06-10 Alan Modra + + gas: xtensa build failure with --enable-64-bit-bfd + A 32-bit host with --enable-64-bit-bfd --target=xtensa-lx106-elf give: + gas/config/tc-xtensa.c: In function ‘xg_get_best_chain_entry’: + gas/config/tc-xtensa.c:7689:11: error: absolute value function ‘labs’ given an argument of type ‘offsetT’ {aka ‘long long int’} but has parameter of type ‘long int’ which may cause truncation of value [-Werror=absolute-value] + 7689 | if (labs (off) >= J_RANGE - J_MARGIN) + | ^~~~ + + Let's not use labs. Unlike labs vma_abs deliberately returns an + unsigned value, and does the negation in an unsigned type so that + signed overflow can't happen. + + * config/tc-xtensa.c (vma_abs): New function. + (xg_get_best_chain_entry, xg_get_fulcrum, xg_find_best_trampoline), + (xg_is_relaxable_fixup): Use in place of labs. + +2025-06-10 Alan Modra + + dlltool invalid free + This is a followup to commt 619f863c55ca "dlltool memory leaks". + The name passed to def_name is freed, so if missing we can't just + use "". strdup it. + + * defparse.y (opt_name): xstrdup empty string. + +2025-06-10 Matthieu Longo + + AArch64, Arm and TIC6x tests: fix typo in linker scripts + The linker scripts for AArch64 and TIC6x were probably originally copied from + Arm testsuite, and contain the same typo in the name of the attributes section. + + This patch fixes the typo across all the testsuites. + +2025-06-10 Simon Marchi + + gdb/dwarf2: remove erroneous comment in open_and_init_dwo_file + When writing commit 28f15782adab ("gdb/dwarf: read multiple .debug_info.dwo + sections"), I initially thought that the gcc behavior of producing multiple + .debug_info.dwo sections was a bug (it is not). I updated the commit + message, but it looks like this comment stayed. Remove it, since it can + be misleading. + + Change-Id: I027712d44b778e836f41afbfafab993da02726ef + Approved-By: Tom Tromey + +2025-06-10 Jiawei + + RISC-V: Add Smrnmi extension imply relation. + This patch adds the dependency of Smrnmi extension on Zicsr extension. + + bfd/ChangeLog: + + * elfxx-riscv.c: New imply. + + gas/ChangeLog: + + * testsuite/gas/riscv/imply.d: New test check. + * testsuite/gas/riscv/imply.s: New imply test. + +2025-06-10 Dongyan Chen + + RISC-V: Add support for svvptc extension. + This implements the svvptc extensons, version 1.0[1]. + + [1] https://github.com/riscv/riscv-svvptc + + bfd/ChangeLog: + + * elfxx-riscv.c: New extension. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + +2025-06-10 GDB Administrator + + Automatic date update in version.in + +2025-06-09 Simon Marchi + + gdb/solib-svr4: remove svr4_have_link_map_offsets + While C++ifying the solib code, I concluded that all arches that use + SVR4 libraries do provide link map offsets, so I think this function is + unnecessary now. + + Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7 + Approved-By: Tom Tromey + +2025-06-09 Pedro Alves + + Adjust gdb.cp/cpexprs.exp for Cygwin + Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see: + + break base::~base + Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135. + (gdb) continue + Continuing. + + Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135 + 135 ~base (void) { } // base::~base + (gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base + + Here, the breakpoint only got one location because both the in-charge + and the not-in-charge dtors are identical and got the same address: + + $ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base" + ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base() + ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base() + + While on Cygwin, we get two locations for the same breakpoint, which + the testcase isn't expecting: + + break base::~base + Breakpoint 117 at 0x100402678: base::~base. (2 locations) + (gdb) continue + Continuing. + + Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135 + 135 ~base (void) { } // base::~base + (gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base + + We got two locations because the in-charge and the not-in-charge dtors + have different addresses: + + $ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base" + outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base() + outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base() + + On Cygwin, we also see the typical failure due to not expecting the + inferior to be multi-threaded: + + (gdb) continue + Continuing. + [New Thread 628.0xe08] + + Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336 + 336 derived d; + (gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd + + Both issues are fixed by this patch, and now the testcase passes + cleanly on Cygwin, for me. + + Reviewed-By: Keith Seitz + Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1 + +2025-06-09 Pedro Alves + + gdb.threads/thread-execl, don't re-exec forever + I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that + surprising since we can't follow-exec on Cygwin). Looking at the + process list running on the machine, we end up with a thread-execl.exe + process constantly respawning another process [1]. + + We see the same constant-reexec if we launch gdb.thread/thread-execl + manually on the shell: + + $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl + # * doesn't exit, constantly re-execing * + ^C + + Prevent this leftover constantly-re-execing scenario by making the + testcase program only exec once. We now get: + + $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl + $ # exits immediately after one exec. + + On Cygwin, the testcase now fails reasonably quickly, and doesn't + leave stale processes behind. + + Still passes cleanly on x86-64 GNU/Linux. + + [1] Cygwin's exec emulation spawns a new Windows process for the new + image. + + Approved-By: Andrew Burgess + Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb + +2025-06-09 Pedro Alves + + Support core dumping testcases with Cygwin's dumper + Cygwin supports dumping ELF cores via a dumper.exe utility, see + https://www.cygwin.com/cygwin-ug-net/dumper.html. + + When I run a testcase that has the "kernel" generate a corefile, like + gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and + generates an ELF core file, however, the testsuite doesn't find the + generated core: + + Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ... + WARNING: can't generate a core file - core tests suppressed - check ulimit -c + + The file is correctly put under $coredir, e.g., like so: + + outputs/gdb.base/corefile/coredir.8926/corefile.exe.core + + The problem is in this line in core_find: + + foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" { + + Note that that isn't looking for "${binfile}.core" inside + ${coredir}... That is fixed in this patch. + + However, that still isn't sufficient for Cygwin + dumper, as in that + case the core is going to be called foo.exe.core, not foo.core. Fix + that by looking for foo.exe.core in the core dir as well. + + With this, gdb.base/corefile.exp and other tests that use core_find + now run. They don't pass cleanly, but at least now they're exercised. + + Approved-By: Tom Tromey + Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e + +2025-06-09 Pedro Alves + + Adjust gdb.base/sigall.exp for Cygwin + The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently. + + From: + + Thread 1 "sigall" received signal SIGPWR, Power fail/restart. + 0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll + (gdb) FAIL: gdb.base/sigall.exp: get signal LOST + + we see two issues. The test is expecting "Program received ..." which + only appears if the inferior is single-threaded. All Cygwin inferiors + are multi-threaded, because both Windows and the Cygwin runtime spawn + a few helper threads. + + And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase + already knows to treat them the same on SPARC64 GNU/Linux. We just + need to extend the relevant code to treat Cygwin the same. + + With this, the test passes cleanly on Cygwin. + + Approved-By: Tom Tromey + Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667 + +2025-06-09 Pedro Alves + + Adjust gdb.arch/amd64-watchpoint-downgrade.exp for Cygwin + The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the + output of debugging a single-thread program, like so, on e.g., + GNU/Linux: + + starti + Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade + warning: watchpoint 1 downgraded to software watchpoint + + Program stopped. + 0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2 + + However, on Cygwin, where all inferiors are multi-threaded (because + both Windows and the Cygwin runtime spawn a few helper threads), we + get: + + starti + Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade + [New Thread 4652.0x17e4] + warning: watchpoint 1 downgraded to software watchpoint + + Thread 1 stopped. + 0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll + + This commit adjusts the testcase to work with either output. + + (Note GDB may print a thread name after the thread number.) + + Approved-by: Kevin Buettner + Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c + +2025-06-09 Pedro Alves + + Adjust gdb.base/bp-permanent.exp for Cygwin + On Cygwin, all inferiors are multi-threaded, because both Windows and + the Cygwin runtime spawn a few helper threads. Adjust the + gdb.base/bp-permanent.exp testcase to work with either single- or + multi-threaded inferiors. + + Approved-by: Kevin Buettner + Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2 + +2025-06-09 Pedro Alves + + Adjust gdb.base/bp-cond-failure.exp for Cygwin + Currently on Cygwin, I get: + + Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ... + FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue + FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue + + On GNU/Linux, we see: + + Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21 + 21 return 0; /* Multi-location breakpoint here. */ + (gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue + + While on Cygwin, we see: + + Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21 + 21 return 0; /* Multi-location breakpoint here. */ + (gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue + + The difference is the "Thread 1" part in the beginning of the quoted + output. It appears on Cygwin, but not on Linux. That's because on + Cygwin, all inferiors are multi-threaded, because both Windows and the + Cygwin runtime spawn a few helper threads. + + Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to + work with either single- or multi-threaded inferiors. + + The testcase passes cleanly for me after this. + + Approved-by: Kevin Buettner + Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349 + +2025-06-09 Alice Carlotti + + MAINTAINERS: Add myself as an AArch64 maintainer + +2025-06-09 Richard Earnshaw + + aarch64: Increase the number of feature words to 3 + Now that most of the effort of updating the number of feature words is + handled by macros, add an additional one, taking the number of + supported features to 192. + +2025-06-09 Richard Earnshaw + + aarch64: use macro trickery to automate feature array size replication + There are quite a few macros that need to be changed when we need to + increase the number of words in the features data structure. With + some macro trickery we can automate most of this so that a single + macro needs to be updated. + + With C2X we could probably do even better by using recursion, but this + is still a much better situation than we had previously. + + A static assertion is used to ensure that there is always enough space + in the flags macro for the number of feature bits we need to support. + +2025-06-09 Yury Khrustalev + + aarch64: Fix typos in opcode headers + +2025-06-09 Alan Modra + + change some listing.c variables to unsigned. + The values are unsigned, and changing the types allows some casts to + be removed. + +2025-06-09 Alan Modra + + dwarf2dbg.c line_entry.next assert + I was puzzling over how it was correct to cast what is clearly a + struct line_entry** pointer to a struct line_entry* pointer for a + few moments, and was going to write a comment but then decided we + really don't require the "next" pointer to be where it is. Replace + the assert with an inline function that does any necessary pointer + adjustments. + + * dwarf2dbg.c (line_entry.next): Delete static assertion. + (line_entry_at_tail): New inline function. + (dwarf2_gen_line_info_1, dwarf2_finish): Replace casts in + set_or_check_view arguments with line_entry_at_tail. + +2025-06-09 Alan Modra + + str_hash_find casts + Putting an explicit cast on the void* return from str_hash_find isn't + necessary and doesn't add much to code clarity. In other cases, poor + choice of function parameter types, eg. "void *value" in + tc-aarch64.c checked_hash_insert rather than "const void *value" leads + to needing (void *) casts all over the place just to cast away const. + Fix that by correcting the parameter type. (And it really is a const, + the function and str_hash_insert don't modify the strings.) + This patch also removes some unnecessary casts in hash.c + +2025-06-09 Alan Modra + + str_hash_find_int + This changes the internal representation of string_tuple.value from + a void* to an intptr_t, removing any concerns that code wanting to + store an integer value will use values that are trap encodings or + suchlike for a pointer. The ISO C standard says any void* can be + converted to intptr_t and back again and will compare equal to the + original pointer. It does *not* say any intptr_t can be converted to + void* and back again to get the original integer.. + + Two new functions, str_hash_find_int and str_hash_insert_int are + provided for handling integer values. str_hash_find_int returns + (intptr_t) -1 on failing to find the key string. + + Most target code need minimal changes to use the new interface, but + some simplification is possible since now a zero can be stored and + differentiated from the NULL "can't find" return. (Yes, that means + (intptr_t) -1 can't be stored.) + + I've changed the avr_no_sreg_hash dummy value to zero, and the + loongarch register numbers don't need to be incremented. loongarch + also doesn't need to store an empty key string (if it ever did). + +2025-06-09 Alan Modra + + metag build error + gas/config/tc-metag.c: In function ‘parse_dsp_addr’: + gas/config/tc-metag.c:4386:29: error: ‘regs[0]’ may be used uninitialized [-Werror=maybe-uninitialized] + 4386 | if (!is_addr_unit (regs[0]->unit) && + | ~~~~~~~^~~~~~ + + It looks like regs_read can be zero with "l" non-NULL, so this gcc + complaint is accurate. + + * config/tc-metag.c (parse_dsp_addr, parse_dget_set): Check + regs_read. + +2025-06-09 GDB Administrator + + Automatic date update in version.in + +2025-06-08 GDB Administrator + + Automatic date update in version.in + +2025-06-07 Tom de Vries + + [gdb/build] Fix buildbreaker in hardwire_setbaudrate + When building on x86_64-cygwin, I run into: + ... + In file included from gdbsupport/common-defs.h:203, + from gdb/defs.h:26, + from : + gdb/ser-unix.c: In function ‘void hardwire_setbaudrate(serial*, int)’: + gdbsupport/gdb_locale.h:28:20: error: expected ‘)’ before ‘gettext’ + 28 | # define _(String) gettext (String) + | ^~~~~~~ + gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’ + 43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \ + | ^ + gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’ + 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); + | ^~~~~~~~~~~~~~~~~~~~~~ + gdb/ser-unix.c:590:31: note: in expansion of macro ‘_’ + 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); + | ^ + gdbsupport/gdb_locale.h:28:28: note: to match this ‘(’ + 28 | # define _(String) gettext (String) + | ^ + gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’ + 43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \ + | ^ + gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’ + 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); + | ^~~~~~~~~~~~~~~~~~~~~~ + ... + + Fix this by dropping the unneeded _() on the gdb_assert_not_reached argument. + + PR build/33064 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33064 + +2025-06-07 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/dyn-bit-offset.exp on s390x + On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get: + ... + (gdb) print spr^M + $1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M + (gdb) FAIL: $exp: print spr + print spr.field^M + $2 = -6^M + (gdb) FAIL: $exp: print spr.field + ... + + On x86_64-linux, with the same compiler version I get: + ... + (gdb) print spr^M + $1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M + (gdb) XFAIL: $exp: print spr + print spr.field^M + $2 = -4^M + (gdb) PASS: $exp: print spr.field + ... + + In both cases, we're hitting the same compiler problem, but it manifests + differently on little and big endian. + + Make sure the values seen for both little and big endian trigger xfails + for both tests. + + Printing spr.field gives the expected value -4 for x86_64, but that's an + accident. Change the actual spr.field value to -5, to make sure + that we get the same number of xfails on x86_64 and s390x. + + Finally, make the xfails conditional on the compiler version. + + Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux. + + Approved-By: Andrew Burgess + + PR testsuite/33042 + https://sourceware.org/bugzilla/show_bug.cgi?id=33042 + +2025-06-07 Georg-Johann Lay + + AVR: ld/32968 - Assert that .progmem data resides in the lower 64 KiB. + This patch locates the linker stubs / trampolines *after* all the .progmem + sections. This is the natural placement since progmem data has to reside + in the lower 64 KiB (it is accessed using LPM), whereas the linker stubs + are only required to be located in the lower 128 KiB of program memory. + (They must be in the range of EICALL / EIJMP with EIND = 0.) + + The current location of the linker stubs was motivated by an invalid test + case from PR13812 that allocates more than 64 KiB of progmem data. + + The patch adds an assertion that makes sure that no progmem data is + allocated past 0xffff. + + Data that is accessed using ELPM should be located to .progmemx so that + no .progmem addresses are wasted. .progmemx was introduced in 2017 and + is used by __memx, __flashx and by the current AVR-LibC. + (The compiler uses .jumptables.gcc for its jump dispatch tables since + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 / GCC v4.9.2). + + PR ld/32968 + ld/ + * scripttempl/avr.sc: Move the trampolines section after the + .progmem sections. Assert that .progmem is in the lower 64 KiB. + +2025-06-07 GDB Administrator + + Automatic date update in version.in + +2025-06-06 Andrew Burgess + + gdb/guile: fix memory leak in gdbscm_parse_command_name + For reference see the previous commit. + + Fix a memory leak in gdbscm_parse_command_name when a guile exception + is thrown. To reveal the memory leak I placed the following content + into a file 'leak.scm': + + (use-modules (gdb)) + (register-command! + (make-command + "break cmd" + #:command-class COMMAND_OBSCURE + #:invoke (lambda (self arg from-tty) + (display "Hello World")))) + + Then in GDB: + + (gdb) source leak.scm + ERROR: In procedure register-command!: + In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd" + Error while executing Scheme code. + + Running this under valgrind reveals a memory leak for 'result' and + 'prefix_text' from gdbscm_parse_command_name. + + Another leak can be revealed with this input script: + + (use-modules (gdb)) + (register-command! + (make-command + "unknown-prefix cmd" + #:command-class COMMAND_OBSCURE + #:invoke (lambda (self arg from-tty) + (display "Hello World")))) + + This one occurs earlier in gdbscm_parse_command_name, and now only + 'result' leaks. + + The problem is that, when guile throws an exception then a longjmp is + performed from the function that raise the exception back to the guile + run-time. A consequence of this is that no function local destructors + will be run. + + In gdbscm_parse_command_name, this means that the two function locals + `result` and `prefix_text` will not have their destructors run, and + any memory managed by these objects will be leaked. + + Fix this by assigning nullptr to these two function locals before + throwing an exception. This will cause the managed memory to be + deallocated. + + I could have implemented a fix that made use of Guile's dynwind + mechanism to register a cleanup callback, however, this felt like + overkill. At the point the exception is being thrown we know that we + no longer need the managed memory, so we might as well just free the + memory at that point. + + With this fix in place, the two leaks are now fixed in the valgrind + output. + + Approved-By: Tom Tromey + +2025-06-06 Andrew Burgess + + gdb/python/guile: remove some explicit calls to xmalloc + In gdbpy_parse_command_name (python/py-cmd.c) there is a call to + xmalloc that can easily be replaced with a call to + make_unique_xstrndup, which makes the code easier to read (I think). + + In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be + applied to remove an identical xmalloc call. And there is an + additional xmalloc call, which can also be replaced with + make_unique_xstrndup in the same way. + + The second xmalloc call in gdbscm_parse_command_name was also present + in gdbpy_parse_command_name at one point, but was replaced with a use + of std::string by this commit: + + commit 075c55e0cc0a68eeab777027213c2f545618e844 + Date: Wed Dec 26 11:05:57 2018 -0700 + + Remove more calls to xfree from Python + + I haven't changed the gdbscm_parse_command_name to use std::string + though, as that doesn't work well with the guile exception model. + Guile exceptions work by performing a longjmp from the function that + raises the exception, back to the guile run-time. The consequence of + this is that destructors are not run. For example, if + gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any + function local objects in gdbscm_parse_command_name will not have + their destructors called. + + What this means is that, for the existing `result` and `prefix_text` + locals, any allocated memory managed by these objects will be leaked + if an exception is called. However, fixing this is pretty easy, one + way is to just assign nullptr to these locals before raising the + exception, this would cause the allocated memory to be released. + + But for std::string it is harder to ensure that the managed memory has + actually been released. We can call std::string::clear() and then + maybe std::string::shrink_to_fit(), but this is still not guaranteed + to release any managed memory. In fact, I believe the only way to + ensure all managed memory is released, is to call the std::string + destructor. + + And so, for functions that can throw a guile exception, it is easier + to just avoid std::string. + + As for the memory leak that I identify above; I'll fix that in a + follow on commit. + + Approved-By: Tom Tromey + +2025-06-06 Guinevere Larsen + + gdb/solib: make _linker_namespace use selected frame + When the convenience variable $_linker_namespace was introduced, I meant + for it to print the namespace of the frame that where the user was + stopped. However, due to confusing what "current_frame" and + "selected_frame" meant, it instead printed the namespace of the + lowermost frame. + + This commit updates the code to follow my original intent. Since the + variable was never in a GDB release, updating the behavior should not + cause any disruption. It also adds a test to verify the functionality. + + Approved-By: Tom Tromey + +2025-06-06 Indu Bhagat + + bfd: sframe: fix typo in comments + bfd/ + * elflink.c (elf_link_input_bfd): Replace ctf frame with SFrame. + +2025-06-06 Alexey Lapshin + + gdb: unix: allow to use custom baud rate + Modern unix systems allow to set custom baud rate instead of predefined in termios.h. + + - To use this in Linux it must have BOTHER macro in "asm/termio.h" + - MacOS could handle this using IOSSIOSPEED passed to ioctl() + + Approved-By: Simon Marchi + Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7 + +2025-06-06 Alexey Lapshin + + gdb: unix: extend supported baudrate B_codes + Added B_codes that may be supported in some unix systems + + Approved-By: Simon Marchi + Change-Id: I48624d6573dc6c72e26818dd44b24182c1dabb70 + +2025-06-06 Simon Marchi + + gdb/amd-dbgapi: remove one xfree + Replace a manual xfree with unique_xmalloc_ptr. + + Change-Id: Id4d2065e3294c4761fe3c852962360712b53d7a8 + Approved-By: Tom Tromey + Approved-by: Lancelot Six (amdgpu) + +2025-06-06 Simon Marchi + + gdb/solib-rocm: remove one xfree + Replace a manual xfree with unique_xmalloc_ptr. + + Change-Id: I12a20106545905f1a80d069fc0555812cc3d6680 + Approved-By: Tom Tromey + Approved-by: Lancelot Six (amdgpu) + +2025-06-06 Tom Tromey + + Fix regression with DW_AT_bit_offset handling + Internal AdaCore testing using -gdwarf-4 found a spot where GCC will + emit a negative DW_AT_bit_offset. However, my recent signed/unsigned + changes assumed that this value had to be positive. + + I feel this bug somewhat invalidates my previous thinking about how + DWARF attributes should be handled. + + In particular, both GCC and LLVM at understand that a negative bit + offset can be generated -- but for positive offsets they might use a + smaller "data" form, which is expected not to be sign-extended. LLVM + has similar code but GCC does: + + if (bit_offset < 0) + add_AT_int (die, DW_AT_bit_offset, bit_offset); + else + add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset); + + What this means is that this attribute is "signed but default + unsigned". + + To fix this, I've added a new attribute::confused_constant method. + This should be used when a constant value might be signed, but where + narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension. + + I examined the GCC and LLVM DWARF writers to come up with the list of + attributes where this applies, namely DW_AT_bit_offset, + DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM + always emits it as unsigned, so we're safe here). + + This patch corrects the bug and imports the relevant test case. + + Regression tested on x86-64 Fedora 41. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837 + Approved-By: Simon Marchi + +2025-06-06 Andrew Burgess + + gdb: prevent assertion after 'set debug breakpoint on' + Turns out that using 'set debug breakpoint on' will trigger an + assertion for 'catch' style breakpoints, e.g.: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) catch exec + Catchpoint 1 (exec) + (gdb) set debug breakpoint on + (gdb) start + [breakpoint] dump_condition_tokens: Tokens: { INFERIOR: "1" } + Temporary breakpoint 2 at 0x401198: file /tmp/hello.c, line 18. + [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT + Starting program: /tmp/hello.x + [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT + ../../gdb-16.1/gdb/gdbarch-gen.c:1764: internal-error: gdbarch_addr_bit: Assertion `gdbarch != NULL' failed. + .... etc ... + + The problem is that catch breakpoints don't set the + bp_location::gdbarch member variable, they a "dummy" location added + with a call to add_dummy_location (breakpoint.c). + + The breakpoint_location_address_str function (which is only used for + breakpoint debug output) relies on bp_location::gdbarch being set in + order to call the paddress function. + + I considered trying to ensure that the bp_location::gdbarch variable + is always set to sane value. For example, in add_dummy_location I + tried copying the gdbarch from the breakpoint object, and this does + work for the catchpoint case, but for some of the watchpoint cases, + even the breakpoint object has no gdbarch value set. + + Now this seemed a little suspect, but, the more I thought about it, I + wondered if "fixing" the gdbarch was allowing me to solve the wrong + problem. + + If the gdbarch was set, then this would allow us to print the address + field of the bp_location, which is going to be 0, after all, as this + is a dummy location, which has no address. + + But does it really make sense to print the address 0? For some + targets, 0 is a valid address. But that wasn't an address we actually + selected, it's just the default value for dummy locations. + + And we already have a helper function bl_address_is_meaningful, which + returns false for dummy locations. + + So, I propose that in breakpoint_location_address_str, we use + bl_address_is_meaningful to detect dummy locations, and skip the + address printing code in that case. + + For testing, I temporarily changed insert_bp_location so that + breakpoint_location_address_str was always called, even when + breakpoint debugging was off. I then ran the whole testsuite. + Without the fixes included in this commit I saw lots of assertion + failures, but with the fixes from this commit in place, I now see no + assertion failures. + + I've added a new test which reveals the original assertion failure. + + Approved-By: Simon Marchi + +2025-06-06 Guinevere Larsen + + gdb/configure: Fix POSIX non-compliance + My recent GDB commit: + + commit 4b42385c470c5f72f158f382f4d9c36f927aa84f + Author: Guinevere Larsen + Date: Wed Feb 12 08:25:46 2025 -0300 + gdb: Make dwarf support optional at compile time + + Introduced a change that made the configure script not POSIX compliant, + by using fallthrough in some case statements. This commit reworks that + part of the change to only use if statements, so that no code is + duplicated but things remain POSIX compliant. + + Reviewed-by: Sam James + Approved-By: Tom Tromey + +2025-06-06 Pedro Alves + + Make default_gdb_exit resilient to failed closes + For some reason, when testing GDB on Cygwin, I get: + + child process exited abnormally + while executing + "exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)"" + (procedure "close_wait_program" line 20) + invoked from within + "close_wait_program $shell_id $pid" + (procedure "standard_close" line 23) + invoked from within + "standard_close "Windows-ROCm"" + ("eval" body line 1) + invoked from within + "eval ${try}_${proc} \"$dest\" $args" + (procedure "call_remote" line 42) + invoked from within + "call_remote "" close $host" + (procedure "remote_close" line 3) + invoked from within + "remote_close host" + (procedure "log_and_exit" line 30) + invoked from within + "log_and_exit" + + When that happens from within clean_restart, clean_restart doesn't + clear the gdb_spawn_id variable, and then when clean_restart starts up + a new GDB, that sees that gdb_spawn_id is already set, so it doesn't + actually spawn a new GDB, and so clean_restart happens to reuse the + same GDB (!). Many tests happen to actually work OK with this, but + some don't, and the failure modes can be head-scratching. + + Of course, the failure to close GDB should be fixed, but when it + happens, I think it's good to not end up with the current weird state. + Connecting the "child process exit abnormally" errors at the end of a + testcase run with weird FAILs in other testcases took me a while (as + in, weeks!), it wasn't obvious to me immediately. + + Thus, this patch makes default_gdb_exit more resilient to failed + closes, so that gdb_spawn_id is unset even is closing GDB fails, and + we move on to start a new GDB. + + Approved-By: Andrew Burgess + Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2 + +2025-06-06 Pedro Alves + + gdb_test_multiple: Anchor prompt match if -lbl + The testcase added by this patch has a gdb_test_multiple call that + wants to match different lines of output that all have a common + prefix, and do different actions on each. Instead of a single regular + expression with alternatives, it's clearer code if the different + expressions are handled with different "-re", like so: + + gdb_test_multiple "command" "" -lbl { + -re "^command(?=\r\n)" { + exp_continue + } + -re "^\r\nprefix foo(?=\r\n)" { + # Some action for "foo". + exp_continue + } + -re "^\r\nprefix bar(?=\r\n)" { + # Some action for "bar". + exp_continue + } + -re "^\r\nprefix \[^\r\n\]*(?=\r\n)" { + # Some action for all others. + exp_continue + } + -re "^\r\n$::gdb_prompt $" { + gdb_assert {$all_prefixes_were_seen} $gdb_test_name + } + } + + Above, the leading anchors in the "^\r\nprefix..." matches are needed + to avoid too-eager matching due to the common prefix. Without the + anchors, if the expect output buffer happens to contain at least: + + "\r\nprefix xxx\r\nprefix foo\r\n" + + ... then the "prefix foo" pattern match inadvertently consumes the + first "prefix xxx" line. + + Without the anchor in the prompt match, like: + + -re "\r\n$::gdb_prompt $" { + gdb_assert {$all_prefixes_were_seen} $gdb_test_name + } + + Or the equivalent: + + -re -wrap "" { + gdb_assert {$all_prefixes_were_seen} $gdb_test_name + } + + ... then if the expect buffer contains: + + "\r\nmeant-to-be-matched-by-lbl\r\nprefix foo\r\n$gdb_prompt " + + ... then the prompt regexp matches this, consuming the "prefix" line + inadvertently, and we get a FAIL. The built-in regexp matcher for + -lbl doesn't get a chance to match the + "\r\nmeant-to-be-matched-by-lbl\r\n" part, because the built-in prompt + match appears first within gdb_test_multiple. + + By adding the anchor to the prompt regexp, we avoid that problem. + + However, the same expect output buffer contents will still match the + built-in prompt regexp. That is what is fixed by this patch. It + makes it so that if -lbl is specified, the built-in prompt regexp has + a leading anchor. + + Original idea for turning this into a gdb.testsuite/ testcase by Tom + de Vries . + + Approved-By: Tom de Vries + Change-Id: Ic2571ec793d856a89ee0d533ec363e2ac6036ea2 + +2025-06-06 Tom de Vries + + [gdb] Fix typo in gdb/break-catch-syscall.c + Fix typo "if the feature if supported" -> "if the feature is supported". + +2025-06-06 Jan Beulich + + x86/Solaris: cope with new HANDLE_ALIGN behavior + Extend the expectation adjustments done by 83d94ae428b1 ("tidy x86 + HANDLE_ALIGN") to the Solaris clone of an affected testcase. + +2025-06-06 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.multi/attach-while-running.exp + With test-case gdb.multi/attach-while-running.exp usually I get: + ... + (gdb) run &^M + Starting program: attach-while-running ^M + (gdb) PASS: $exp: run & + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + add-inferior^M + [New inferior 2]^M + Added inferior 2 on connection 1 (native)^M + (gdb) PASS: $exp: add-inferior + ... + or: + ... + (gdb) run & + Starting program: attach-while-running + (gdb) PASS: $exp: run & + add-inferior + [New inferior 2] + Added inferior 2 on connection 1 (native) + (gdb) PASS: $exp: add-inferior + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + ... + but sometimes I run into: + ... + (gdb) run & + Starting program: attach-while-running + (gdb) PASS: $exp: run & + add-inferior + [New inferior 2] + Added inferior 2 on connection 1 (native) + (gdb) [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + FAIL: $exp: add-inferior (timeout) + ... + + Fix this by using -no-prompt-anchor. + + Tested on x86_64-linux. + +2025-06-06 Tom de Vries + + [gdb/tdep] Don't call WaitForSingleObject with INFINITE arg + I decided to try to build and test gdb on Windows. + + I found a page on the wiki [1] suggesting three ways of building gdb: + - MinGW, + - MinGW on Cygwin, and + - Cygwin. + + I picked Cygwin, because I've used it before (though not recently). + + I managed to install Cygwin and sufficient packages to build gdb and start the + testsuite. + + However, testsuite progress ground to a halt at gdb.base/branch-to-self.exp. + [ AFAICT, similar problems reported here [2]. ] + + I managed to reproduce this hang by running just the test-case. + + I attempted to kill the hanging processes by: + - first killing the inferior process, using the cygwin "kill -9" command, and + - then killing the gdb process, likewise. + + But the gdb process remained, and I had to point-and-click my way through task + manager to actually kill the gdb process. + + I investigated this by attaching to the hanging gdb process. Looking at the + main thread, I saw it was stopped in a call to WaitForSingleObject, with + the dwMilliseconds parameter set to INFINITE. + + The backtrace in more detail: + ... + (gdb) bt + #0 0x00007fff196fc044 in ntdll!ZwWaitForSingleObject () from + /cygdrive/c/windows/SYSTEM32/ntdll.dll + #1 0x00007fff16bbcdcf in WaitForSingleObjectEx () from + /cygdrive/c/windows/System32/KERNELBASE.dll + #2 0x0000000100998065 in wait_for_single (handle=0x1b8, howlong=4294967295) at + gdb/windows-nat.c:435 + #3 0x0000000100999aa7 in + windows_nat_target::do_synchronously(gdb::function_view) + (this=this@entry=0xa001c6fe0, func=...) at gdb/windows-nat.c:487 + #4 0x000000010099a7fb in windows_nat_target::wait_for_debug_event_main_thread + (event=, this=0xa001c6fe0) + at gdb/../gdbsupport/function-view.h:296 + #5 windows_nat_target::kill (this=0xa001c6fe0) at gdb/windows-nat.c:2917 + #6 0x00000001008f2f86 in target_kill () at gdb/target.c:901 + #7 0x000000010091fc46 in kill_or_detach (from_tty=0, inf=0xa000577d0) + at gdb/top.c:1658 + #8 quit_force (exit_arg=, from_tty=from_tty@entry=0) + at gdb/top.c:1759 + #9 0x00000001004f9ea8 in quit_command (args=args@entry=0x0, + from_tty=from_tty@entry=0) at gdb/cli/cli-cmds.c:483 + #10 0x000000010091c6d0 in quit_cover () at gdb/top.c:295 + #11 0x00000001005e3d8a in async_disconnect (arg=) + at gdb/event-top.c:1496 + #12 0x0000000100499c45 in invoke_async_signal_handlers () + at gdb/async-event.c:233 + #13 0x0000000100eb23d6 in gdb_do_one_event (mstimeout=mstimeout@entry=-1) + at gdbsupport/event-loop.cc:198 + #14 0x00000001006df94a in interp::do_one_event (mstimeout=-1, + this=) at gdb/interps.h:87 + #15 start_event_loop () at gdb/main.c:402 + #16 captured_command_loop () at gdb/main.c:466 + #17 0x00000001006e2865 in captured_main (data=0x7ffffcba0) at gdb/main.c:1346 + #18 gdb_main (args=args@entry=0x7ffffcc10) at gdb/main.c:1365 + #19 0x0000000100f98c70 in main (argc=10, argv=0xa000129f0) at gdb/gdb.c:38 + ... + + In the docs [3], I read that using an INFINITE argument to WaitForSingleObject + might cause a system deadlock. + + This prompted me to try this simple change in wait_for_single: + ... + while (true) + { + - DWORD r = WaitForSingleObject (handle, howlong); + + DWORD r = WaitForSingleObject (handle, + + howlong == INFINITE ? 100 : howlong); + + if (howlong == INFINITE && r == WAIT_TIMEOUT) + + continue; + ... + with the timeout of 0.1 second estimated to be: + - small enough for gdb to feel reactive, and + - big enough not to consume too much cpu cycles with looping. + + And indeed, the test-case, while still failing, now finishes in ~50 seconds. + + While there may be an underlying bug that triggers this behaviour, the failure + mode is so severe that I consider it a bug in itself. + + Fix this by avoiding calling WaitForSingleObject with INFINITE argument. + + Tested on x86_64-cygwin, by running the testsuite past the test-case. + + Approved-By: Pedro Alves + + PR tdep/32894 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32894 + + [1] https://sourceware.org/gdb/wiki/BuildingOnWindows + [2] https://sourceware.org/pipermail/gdb-patches/2025-May/217949.html + [3] https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject + +2025-06-06 GDB Administrator + + Automatic date update in version.in + +2025-06-05 Simon Marchi + + gdb/solib-svr4: make svr4_info::debug_loader_name an std::string + Remove some manual memory management. + + Change-Id: I9c752d35a70e3659509fed57df1c9a8d27ecc742 + Approved-By: Tom Tromey + +2025-06-05 Guinevere Larsen + + gdb/solib: rename convenience variable to _linker_namespace + Based on feedback from IRC and PR solib/32959, this commit renames the + recently introduced convenience variable $_current_linker_namespace to + the shorter name $_linker_namespace. This makes it more in line with + existing convenience variables such as $_thread and $_inferior, and + faster to type. + + It should be ok to simply change the name because the variable was never + released to the public, so there should be no existing scripts depending + on the name. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32959 + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + Approved-By: Tom Tromey + +2025-06-05 Guinevere Larsen + + gdb/solib: Change type of convenience variable _current_linker_namespace + Based on IRC feedback since commit 6a0da68c036a85a46415aa0dada2421eee7c2269 + + gdb: add convenience variables around linker namespace debugging + + This commit changes the type of the _current_linker_namespace variable + to be a simple integer. This makes it easier to use for expressions, + like breakpoint conditions or printing from a specific namespace once + that is supported, at the cost of making namespace IDs slightly less + consistent. + + This is based on PR solib/32960, where no negative feedback was given + for the suggestion. + + The commit also changes the usage of "linkage namespaces" to "linker + namespaces" in the NEWS file, to reduce chance of confusion from an end + user. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32960 + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-06-05 Tom de Vries + + [gdb/testsuite] Fix gdb.base/bp-permanent.exp with gcc 15 + With test-case gdb.base/bp-permanent.exp and gcc 15 I run into: + ... + gdb compile failed, bp-permanent.c: In function 'test_signal_nested': + bp-permanent.c:118:20: error: passing argument 2 of 'signal' from \ + incompatible pointer type [-Wincompatible-pointer-types] + 118 | signal (SIGALRM, test_signal_nested_handler); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ + | | + | void (*)(void) + In file included from bp-permanent.c:20: + /usr/include/signal.h:88:57: note: expected '__sighandler_t' \ + {aka 'void (*)(int)'} but argument is of type 'void (*)(void)' + ... + + Fix this by adding an int parameter to test_signal_nested_handler. + + Tested on x86_64-linux. + + PR testsuite/32756 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 + +2025-06-05 GDB Administrator + + Automatic date update in version.in + +2025-06-04 Nick Alcock + + libctf: use __attribute__((__gnu_printf__)) where appropriate + We don't use any GNU-specific printf args, but this prevents warnings about + %z, observed on MinGW even though every libc anyone is likely to use there + supports %z perfectly well, and we're not stopping using it just because + MinGW complains. Doing this means we stand more chance of seeing *actual* + problems on such platforms without them being drowned in noise. + + We turn this off on clang, which doesn't support __gnu_printf__. + + Suggested by Eli Zaretskii. + + libctf/ + PR libctf/31863 + * ctf-impl.h (_libctf_printflike_): Use __gnu_printf__. + +2025-06-04 Nick Alcock + + libctf, dedup: reclaim space wasted by duplicate hidden types + In normal deduplicating links, we insert every type (identified by its + unique hash) precisely once. But conflicting types appear in multiple + dicts, so for those, we loop, inserting them into every target dict + in turn (each corresponding to an input dict that type appears in). + But in cu-mapped links, some of those dicts may have been merged into + one: now that we are hiding duplicate conflicting types more + aggressively in such links, we are getting duplicate identical hidden + types turning up in large numbers. + + Fix this by eliminating them in cu-mapping phase 1 (the phase in which this + merging takes place), by checking to see if a type with this hash has + already been inserted in this dict and skipping it if so. This is + redundant and a waste of time in other cu-mapping phases and in normal + links, but in cu-mapped links it saves a few tens to hundreds of kilobytes + in kernel-sized links. + + libctf/ + PR libctf/33047 + * ctf-dedup.c (ctf_dedup_emit_type): Check for already-emitted + types in cu-mapping phase 1. + +2025-06-04 Nick Alcock + + libctf: dedup: preserve non-root flag across normal links + The previous commits dropped preservation of the non-root flag in ctf_link + and arranged to use it somewhat differently to track conflicting types in + cu-mapped CUs when doing cu-mapped links. This was necessary to prevent + entirely spuriously hidden types from appearing on the output of such links. + + Bring it (and the test for it) back. The problem with the previous design + was that it implicitly assumed that the non-root flag it saw on the input + was always meant to be preserved (when in the final phase of cu-mapped links + it merely means that conflicting types were found in intermediate links), + and also that it could figure out what the non-root flag on the input was by + sucking in the non-root flag of the input type corresponding to an output in + the output mapping (which maps type hashes to a corresponding type on some + input). + + This method of getting properties of the input type *does* work *if* that + property was one of those hashed by the ctf_dedup_hash_type process. In + that case, every type with a given hash will have the same value for all + hashed-in properties, so it doesn't matter which one is consulted (the + output mapping points at an arbitrary one of those input types). But the + non-root flag is explicitly *not* hashed in: as a comment in + ctf_dedup_rhash_type notes, being non-root is not a property of a type, and + two types (one non-root, one not) can perfectly well be the same type even + though one is visible and one isn't. So just copying the non-root flag from + the output mapping's idea of the input type will copy in a value that is not + stabilized by the hash, so is more-or-less random! + + So we cannot do that. We have to do something else, which means we have to + decide what to do if two identical types with different nonroot flag values + pop up. The most sensible thing to do is probably to say that if all + instances of a type are non-root-visible, the linked output should also be + non-root-visible: any root-visible types in that set, and the output type is + root-visible again. + + We implement this with a new cd_nonroot_consistency dynhash, which maps type + hashes to the value 0 ("all instances root-visible"), 1 ("all instances + non-root-visible") or 2 ("inconsistent"). After hashing is over, we save a + bit of memory by deleting everything from this hashtab that doesn't have a + value of 1 ("non-root-visible"), then use this to decide whether to emit any + given type as non-root-visible or not. + + However... that's not quite enough. In cu-mapped links, we want to + disregard this whole thing because we just hide everything -- but in phase + 2, when we take the smushed-together CUs resulting from phase 1 and + deduplicate them against each other, we want to do what the previous commits + implemented and ignore the non-root flag entirely, instead falling back to + preventing clashes by hiding anything that would be considered conflicting. + We extend the existing cu_mapped parameter to various bits of ctf_dedup so + that it is now tristate: 0 means a normal link, 1 means the smush-it- + together phase of cu-mapped links, and 2 means the final phase of cu-mapped + links. We do the hide-conflicting stuff only in phase 2, meaning that + normal links by GNU ld can always respect the value of the nonroot flag put + on types in the input. + + (One extra thing added as part of this: you can now efficiently delete the + last value returned by ctf_dynhash_next() by calling + ctf_dynhash_next_remove.) + + We bring back the ctf-nonroot-linking test with one tweak: linking now works + on mingw as long as you're using the ucrt libc, so re-enable it for better + test coverage on that platform. + + libctf/ + PR libctf/33047 + * ctf-hash.c (ctf_dynhash_next_remove): New. + * ctf-impl.h (struct ctf_dedup) [cd_nonroot_consistency]: New. + * ctf-link.c (ctf_link_deduplicating): Differentiate between + cu-mapped and non-cu-mapped links, even in the final phase. + * ctf-dedup.c (ctf_dedup_hash_type): Callback prototype addition. + Get the non-root flag and pass it down. + (ctf_dedup_rhash_type): Callback prototype addition. Document + restrictions on use of the nonroot flag. + (ctf_dedup_populate_mappings): Populate cd_nonroot_consistency. + (ctf_dedup_hash_type_fini): New function: delete now-unnecessary + values from cd_nonroot_consistency. + (ctf_dedup_init): Initialize it. + (ctf_dedup_fini): Destroy it. + (ctf_dedup): cu_mapping is now cu_mapping_phase. Call + ctf_dedup_hash_type_fini. + (ctf_dedup_emit_type): Use cu_mapping_phase and + cd_nonroot_consistency to propagate the non-root flag into outputs + for normal links, and to do name-based conflict checking only for + phase 2 of cu-mapped links. + (ctf_dedup_emit): cu_mapping is now cu_mapping_phase. Adjust + assertion accordingly. + * testsuite/libctf-writable/ctf-nonroot-linking.c: Bring back. + * testsuite/libctf-writable/ctf-nonroot-linking.lk: Likewise. + +2025-06-04 Nick Alcock + + libctf: dedup: improve hiding of conflicting types in the same dict + If types are conflicting, they are usually moved into separate child dicts + -- but not always. If they are added to the same dict by the cu-mapping + mechanism (as used e.g. for multi-TU kernel modules), we can easily end + up adding multiple conflicting types with the same name to the same dict. + + The mechanism used for turning on the non-root-visible flag in order to do + this had a kludge attached which always hid types with the same name, + whether or not they were conflicting. This is unnecessary and can hide + types that should not be hidden, as well as hiding bugs. Remove it, and + replace it with two different approaches: + + - for everything but cu-mapped links (the in-memory first phase of a link + with ctf_link_add_cu_mapping in force), check for duplicate names if + types are conflicting, and mark them as hidden if the names are found. + This will never happen in normal links (in an upcoming commit we will + suppress doing even this much in such cases). + + - for cu-mapped links, the only case that merges multiple distinct target + dicts into one, we apply a big hammer and simply hide everything! The + non-root flag will be ignored in the next link phase anyway (which dedups + the cu-mapped pieces against each other), and this way we can be sure + that merging multiple types cannot incur name clashes at this stage. + + The result seems to work: the only annoyance is that when enums with + conflicting enumerators are found in a single cu-mapped child (so, really + multiple merged children), you may end up with every instance of that enum + being hidden for reasons of conflictingness. I don't see a real way to + avoid that. + + libctf/ + PR libctf/33047 + * ctf-dedup.c (ctf_dedup_emit_type): Only consider non + conflicting types. Improve type hiding in the presence of clashing + enumerators. Hide everything when doing a cu-mapped link: they will + be unhidden by the next link pass if nonconflicting. + +2025-06-04 Nick Alcock + + Revert "libctf: fix linking of non-root-visible types" + This reverts commit 87b2f673102884d7c69144c85a26ed5dbaa4f86a. + + It is based on a misconception, that hidden types in the deduplicator + input should always be hidden in the output. For cu-mapped links, + and final links following cu-mapped links, this is not true: we want + to hide inputs if they were conflicting on the output and no more. + + We will reintroduce the testcase once a better fix is found. + + libctf/ + PR libctf/33047 + * ctf-dedup.c (ctf_dedup_emit_type): Don't respect the nonroot flag. + * testsuite/libctf-writable/ctf-nonroot-linking.c: Removed. + * testsuite/libctf-writable/ctf-nonroot-linking.lk: Removed. + +2025-06-04 Dmitry Chestnykh + + aarch64: Support id_aa64fpfr0_el1, id_aa64pfr2_el1 + +2025-06-04 Andrew Burgess + + gdb/python/guile: fix segfault from nested prefix command creation + A commit I recently pushed: + + commit 0b5023cc71d3af8b18e10e6599a3f9381bc15265 + Date: Sat Apr 12 09:15:53 2025 +0100 + + gdb/python/guile: user created prefix commands get help list + + can trigger a segfault if a user tries to create nested prefix + commands. For example, this will trigger a crash: + + (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE) + (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE) + + Fatal signal: Segmentation fault + ... etc ... + + If the user adds an actual parameter under 'prefix-1' before creating + 'prefix-2', then everything is fine: + + (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE) + (gdb) python gdb.Parameter('prefix-1 param-1', gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE) + + The mistake in the above patch is in how gdbpy_parse_command_name is + used. The BASE_LIST output argument from this function points to the + list of commands for the prefix, not to the prefix command itself. + + So when gdbpy_parse_command_name is called for 'prefix-1 prefix-2', + BASE_LIST points to the list of commands associated with 'prefix-1', + not to the actual 'prefix-1' cmd_list_element. + + Back in cmdpy_init, from where gdbpy_parse_command_name was called, I + was walking back from the first entry in BASE_LIST to figure out if + this was a "show" prefix command or not. However, if BASE_LIST is + empty then there is no first item, and this would trigger the + segfault. + + The solution it to extend gdbpy_parse_command_name to also return the + prefix cmd_list_element in addition to the existing values. With this + done, and cmdpy_init updated, the segfault is now avoided. + + There's a new test that would trigger the crash without the patch. + + And, of course, the above commit also broke guile in the exact same + way. And the fix is exactly the same. And there's a guile test too. + + NOTE: We should investigate possibly sharing some of this boiler plate + helper code between Python and Guile. But not in this commit. + + Approved-By: Tom Tromey + +2025-06-04 Tom de Vries + + [gdb/testsuite] Fix gdb.base/exec-invalid-sysroot.exp + Since commit d462550c91c ("gdb/testsuite: also compile foll-exec.exp as C++"), + we run into: + ... + Running gdb.base/exec-invalid-sysroot.exp ... + gdb compile failed, foll-exec.c: In function 'main': + foll-exec.c:35:52: error: 'EXECD_PROG' undeclared (first use in this function) + printf ("foll-exec is about to execlp(%s)...\n", EXECD_PROG); + ^~~~~~~~~~ + foll-exec.c:35:52: note: each undeclared identifier is reported only once \ + for each function it appears in + ... + + Fix this by default-defining EXECD_PROG to "execd-prog". + + Tested on x86_64-linux. + +2025-06-04 Rui Ueyama + + Reject compressed sections exceding 4 GiB on LLP64 machines + According to the zlib FAQ (*1), zlib does not support compressed data + larger than 4 GiB when the compiler's long type is 32 bits. Therefore, + we need to report an error if a zlib-compressed debug section exceeds + 4 GiB on LLP64 machines. + + (*1) https://zlib.net/zlib_faq.html#faq32 + +2025-06-04 Indu Bhagat + + sframe: fix PR libsframe/33051 + Fix PR libsframe/Bug 33051 - ASAN: heap-buffer-overflow + ../../src/libsframe/sframe.c:1054 in + sframe_get_funcdesc_with_addr_internal + + The previous commit 9d2a24349e2 (libsframe: correct binary search for + SFrame FDE) adapted the binary search logic in + sframe_get_funcdesc_with_addr_internal. Adjusting the upper end of the + search index was missed. + + The search must only be done for FDEs starting at index 0 and up until + num_fdes - 1. Prior logic of searching (before commit 9d2a24349e2) was + a bit different. + + libsframe/ + * sframe.c: Use the correct high index. + +2025-06-04 GDB Administrator + + Automatic date update in version.in + +2025-06-03 Andrew Burgess + + gdb/testsuite: also compile foll-exec.exp as C++ + For a long time, Fedora GDB has carried a test that performs some + basic testing that GDB can handle 'catch exec' related commands for a + C++ executable. + + The exact motivation for this test has been lost in the mists of time, + but looking at the test script, the concern seems to be that GDB would + have problems inserting C++ related internal breakpoints if a non C++ + process is execd from a C++ one. + + There's no actual GDB fix associated with the Fedora test. This + usually means that the issue was fixed upstream long ago. This patch + does seem to date from around 2010ish (or maybe earlier). + + Having a look through the upstream tests, I cannot see anything that + covers this sort of thing (C++ to C exec calls), and I figure it + cannot hurt to have some additional testing in this area, and so I + wrote this patch. + + I've taken the existing foll-exec.exp test, which compiles a C + executable and then execs a different C executable, and split it into + two copies. + + We now have foll-exec-c.exp and foll-exec-c++.exp. These tests + compile a C and C++ executable respectively. Then within each of + these scripts both a C and C++ helper application is built, which can + then be execd from the main test executable. + + And so, we now cover 4 cases, the initial executable can be C or C++, + and the execd process can be C or C++. + + As expected, everything passes. This is just increasing test + coverage. + + Approved-By: Simon Marchi + +2025-06-03 Guinevere Larsen + + gdb: Make dwarf support optional at compile time + This commit allows a user to enable or disable dwarf support at + compilation time. To do that, a new configure option is introduced, in + the form of --enable-gdb-dwarf-support (and the accompanying --disable + version). By default, dwarf support is enabled, so no behavior changes + occur if a user doesn't use the new feature. If support is disabled, no + .c files inside the dwarf2/ subfolder will be compiled into the final + binary. + + To achieve this, this commit also introduces the new macro + DWARF_FORMAT_AVAILABLE, which guards the definitions of functions + exported from the dwarf reader. If the macro is not defined, there are a + couple behaviors that exported functions may have: + * no-ops: several functions are used to register things at + initialization time, like unwinders. These are turned into no-ops + because the user hasn't attempted to read DWARF yet, there's no point + in warning that DWARF is unavailable. + * warnings: similar to the previous commit, if dwarf would be read or + used, the funciton will emit the warning "No dwarf support available." + * throw exceptions: If the code that calls a function expects an + exceptin in case of errors, and has a try-catch block, an error with + the previous message is thrown. + + I believe that the changed functions should probalby be moved to the + dwarf2/public.h header, but that require a much larger refactor, so it + is left as a future improvement. + + Finally, the --enable-gdb-compile configure option has been slightly + changed, since compile requires dwarf support. If compile was requested + and dwarf was disabled, configure will throw an error. If the option was + not used, support will follow what was requested for dwarf (warning the + user of what is decided). + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2025-06-03 Guinevere Larsen + + gdb: wrap mdebug debuginfo reading in ifdefs + This commit aims to allow a user to enable or disable mdebug support at + compilation time. To do that, a new configure option is added, called + --enable-gdb-mdebug-support (and the accompanying --disable version). By + default, support is enabled, and if a user decides to disable support, + the file mdebugread.c won't be compiled in the final binary, and the + macro MDEBUG_FORMAT_AVAILABLE won't be defined. + + That macro is used to control the definitions of mdebug reading, either + the actual definition in mdebugread.c, or a static inline version that + only emits the following warning: + + > No mdebug support available. + + Ideally, we'd like to guard the entirity of mdebugread in the macro, but + the alpha-mdebug-tdep file uses those directly, and I don't think we + should restrict alpha hosts to requiring that debug format compiled in, + nor do I understand the tdep file enough to be comfortable disentangling + the requirements. + + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2025-06-03 Guinevere Larsen + + gdb: Use multiple minimal_symbol_readers in mipscoff_symfile_read + Currently, mipscoff_symfile_read uses a single minimal_symbol_reader to + get all minimal symbols from mdebug-formatted debuginfo, and from + alphacoff. This pattern has been around since minimal_symbol_reader has + been introduced, and from own research, there's no need to use the same + reader. This made it so mipscoff_symfile_read could call + mdebug_build_psymtabs directly, since the latter needs a reference to + the minsym reader object. The issue is that future commits need a + unified entrance point to read debuginfo, and this pattern is very + different to how elf does mdebug reading. + + In fact, the elf mdebug reader does some preparatory steps and then + calls mdebug_build_psymtabs, so what the mips version does is just + spread these preparatory steps through the mipscoff function instead. + + To make it easier for future commits to query debuginfo support + dynamically (as opposed to assuming things at compile time), this commit + introduces a new mipsmdebug_build_psymtabs function, which does similar + preparatory steps as elfmdebug_build_psymtabs. It is added to + mdebugread.c to help with maintaining a separation between reading an + objfile (in mipsread.c) and its debuginfo (mdebug), so that in the + future we have an easier time selectively disabling debuginfo formats + at compilation time. This should have no visible changes for the end + user. + + The new function must receive the pointers to ecoff_debug_swap and + ecoff_debug_info because finding those structures based on the bfd + object necessitates including the headers libcoff.h and libecoff.h, + and those headers can't be included at the same time as libaout.h + - which mdebugread.c already uses. + + Approved-By: Tom Tromey + +2025-06-03 Nick Clifton + + Add checks for illegal symbol binding and type values when reading ELF symbols. + PR 33019 + +2025-06-03 Andrew Burgess + + gdb/python/guile: user created prefix commands get help list + Consider GDB's builtin prefix set/show prefix sub-commands, if they + are invoked with no sub-command name then they work like this: + + (gdb) show print + print address: Printing of addresses is on. + print array: Pretty formatting of arrays is off. + print array-indexes: Printing of array indexes is off. + print asm-demangle: Demangling of C++/ObjC names in disassembly listings is off. + ... cut lots of lines ... + (gdb) set print + List of set print subcommands: + + set print address -- Set printing of addresses. + set print array -- Set pretty formatting of arrays. + set print array-indexes -- Set printing of array indexes. + set print asm-demangle -- Set demangling of C++/ObjC names in disassembly listings. + ... cut lots of lines ... + + Type "help set print" followed by set print subcommand name for full documentation. + Type "apropos word" to search for commands related to "word". + Type "apropos -v word" for full documentation of commands related to "word". + Command name abbreviations are allowed if unambiguous. + (gdb) + + That is 'show print' lists the values of all settings under the + 'print' prefix, and 'set print' lists the help text for all settings + under the 'set print' prefix. + + Now, if we try to create something similar using the Python API: + + (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE) + (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN) + (gdb) show my-prefix + (gdb) set my-prefix + + Neither 'show my-prefix' or 'set my-prefix' gives us the same details + relating to the sub-commands that we get with the builtin prefix + commands. + + This commit aims to address this. + + Currently, in cmdpy_init, when a new command is created, we always set + the commands callback function to cmdpy_function. It is within + cmdpy_function that we spot that the command is a prefix command, and + that there is no gdb.Command.invoke method, and so return early. + + This commit changes things so that the rules are now: + + 1. For NON prefix commands, we continue to use cmdpy_function. + 2. For prefix commands that do have a gdb.Command.invoke + method (i.e. can handle unknown sub-commands), continue to use + cmdpy_function. + 3. For all other prefix commands, don't use cmdpy_function, instead + use GDB's normal callback function for set/show prefixes. + + This requires splitting the current call to add_prefix_cmd into either + a call to add_prefix_cmd, add_show_prefix_cmd, or + add_basic_prefix_cmd, as appropriate. + + After these changes, we now see this: + + (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE) │ + (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN) + (gdb) show my-prefix │ + my-prefix foo: The current value of 'my-prefix foo' is "off". + (gdb) set my-prefix + List of "set my-prefix" subcommands: + + set my-prefix foo -- Set the current value of 'my-prefix foo'. + + Type "help set my-prefix" followed by subcommand name for full documentation. + Type "apropos word" to search for commands related to "word". + Type "apropos -v word" for full documentation of commands related to "word". + Command name abbreviations are allowed if unambiguous. + (gdb) + + Which matches how a prefix defined within GDB would act. + + I have made the same changes to the Guile API. + +2025-06-03 Tom Tromey + + Clean up comment in dw2-ranges-psym-warning.exp + This removes a trailing backslash from a comment in + dw2-ranges-psym-warning.exp. This backslash causes Emacs to try to + reindent the next line. This happens because comments are weird in + Tcl -- they are not exactly syntactic and the backslash still acts as + a line-continuation marker here. + +2025-06-03 Indu Bhagat + + sframe: doc: add date to the pdf output + libsframe/doc/ + * sframe-spec.texi: Include date with each publication. + +2025-06-03 Tom Tromey + + Handle dynamic DW_AT_data_bit_offset + In Ada, a field can have a dynamic bit offset in its enclosing record. + + In DWARF 3, this was handled using a dynamic + DW_AT_data_member_location, combined with a DW_AT_bit_offset -- this + combination worked out ok because in practice GNAT only needs a + dynamic byte offset with a fixed offset within the byte. + + However, this approach was deprecated in DWARF 4 and then removed in + DWARF 5. No replacement approach was given, meaning that in strict + mode there is no way to express this. + + This is a DWARF bug, see + + https://dwarfstd.org/issues/250501.1.html + + In a discussion on the DWARF mailing list, a couple people mentioned + that compilers could use the obvious extension of a dynamic + DW_AT_data_bit_offset. I've implemented this for LLVM: + + https://github.com/llvm/llvm-project/pull/141106 + + In preparation for that landing, this patch implements support for + this construct in gdb. + + New in v2: renamed some constants and added a helper method, per + Simon's review. + + New in v3: more renamings. + + Approved-By: Simon Marchi + +2025-06-03 Andrew Burgess + + gdb: support zero inode in generate-core-file command + It is possible, when creating a shared memory segment (i.e. with + shmget), that the id of the segment will be zero. + + When looking at the segment in /proc/PID/smaps, the inode field of the + entry holds the shared memory segment id. + + And so, it can be the case that an entry (in the smaps file) will have + an inode of zero. + + When GDB generates a core file, with the generate-core-file (or its + gcore alias) command, the shared memory segment should be written into + the core file. + + Fedora GDB has, since 2008, carried a patch that tests this case. + There is no fix for GDB associated with the test, and unfortunately, + the motivation for the test has been lost to the mists of time. This + likely means that a fix was merged upstream without a suitable test, + but I've not been able to find and relevant commit. The test seems to + be checking that the shared memory segment with id zero, is being + written to the core file. + + While looking at this test and trying to work out if it should be + posted upstream, I saw that GDB does appear to write the shared memory + segment into the core file (as expected), which is good. However, GDB + still isn't getting this case exactly right, there appears to be no + NT_FILE entry for the shared memory mapping if the mapping had an id + of zero. + + In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via + the gdbarch_find_memory_regions call) to correctly write the shared + memory segment into the core file, however, in + linux_make_mappings_corefile_notes, when we use + linux_find_memory_regions_full to create the NT_FILE note, we call + back in to dump_note_entry_p for each mapping, and in here we reject + any mapping with a zero inode. + + The result of this, is that, for a shared memory segment with a + non-zero id, after loading the core file, the shared memory segment + will appear in the 'proc info mappings' output. But, for a shared + memory segment with a zero id, the segment will not appear in the + 'proc info mappings' output. + + I initially tried just dropping the inode check in this function (see + previous commit 1e21c846c27, which I then reverted in commit + 998165ba99a. + + The problem with dropping the inode check is that the special kernel + mappings, e.g. '[vvar]' would now get a NT_FILE entry. In fact, any + special entry except '[vdso]' and '[vsyscall]' which are specifically + checked for in dump_note_entry_p would get a NT_FILE entry, which is + not correct. + + So, instead, I propose that if the inode is zero, and the filename + starts with '[' and finished with ']' then we should not create a + NT_FILE entry. But otherwise a zero inode should not prevent a + NT_FILE entry being created. + + The test for this change is a bit tricky. The original Fedora + test (mentioned above) has a loop that tries to grab the shared memory + mapping with id zero. This was, unfortunately, not very reliable. + + I tried to make this more reliable by going multi-threaded, and + waiting for longer, see my proposal here: + + https://inbox.sourceware.org/gdb-patches/0d389b435cbb0924335adbc9eba6cf30b4a2c4ee.1741776651.git.aburgess@redhat.com + + But this was still not great. On further testing this was only + passing (i.e. managing to find the shared memory mapping with id zero) + about 60% of the time. + + However, I realised that GDB finds the shared memory id by reading the + /proc/PID/smaps file. But we don't really _need_ the shared memory id + for anything, we just use the value (as an inode) to decide if the + segment should be included in the core file or not. The id isn't even + written to the core file. So, if we could intercept the read of the + smaps file, then maybe, we could lie to GDB, and tell it that the id + was zero, and then see how GDB handles this. + + And luckily, we can do that using a preload library! + + We already have a test that uses a preload library to modify GDB, see + gdb.threads/attach-slow-waitpid.exp. + + So, I have created a new preload library. This one intercepts open, + open64, close, read, and pread. When GDB attempts to open + /proc/PID/smaps, the library spots this and loads the file contents + into a memory buffer. The buffer is then modified to change the id of + any shared memory mapping to zero. Any reads from this file are + served from the modified memory buffer. + + I tested on x86-64, AArch64, PPC, s390, and ARM, all running various + versions of GNU/Linux. The requirement for open64() came from my ARM + testing. The other targets used plain open(). + + And so, the test is now simple. Start GDB with the preload library in + place, start the inferior and generate a core file. Then restart GDB, + load the core file, and check the shared memory mapping was included. + This test will fail with an unpatched GDB, and succeed with the patch + applied. + + Tested-By: Guinevere Larsen + +2025-06-03 Piotr Rudnicki + + gdb: handle struct and union types in evaluate_subexp_for_address_base + Suppose a function returns a struct and a method of that struct is + called. E.g.: + + struct S + { + int a; + int get () { return a; } + }; + + S f () + { + S s; + s.a = 42; + return s; + } + + ... + int z = f().get(); + ... + + GDB is able to evaluate the expression: + + (gdb) print f().get() + $1 = 42 + + However, type-checking the expression fails: + + (gdb) ptype f().get() + Attempt to take address of value not located in memory. + + This happens because the `get` function takes an implicit `this` + pointer, which in this case is the value returned by `f()`, and GDB + wants to get an address for that value, as if passing the implicit + this pointer. However, during type-checking, the struct value + returned by `f()` is a `not_lval`. + + A similar issue exists for union types, where methods called on + temporary union objects would fail type-checking in the same way. + + Address the problems by handling `TYPE_CODE_STRUCT` and + `TYPE_CODE_UNION` in `evaluate_subexp_for_address_base`. + + With this change, for struct's method call, we get + + (gdb) ptype f().get() + type = int + + Add new test cases to file gdb.cp/chained-calls.exp to test this change. + + Regression-tested in X86-64 Linux. + +2025-06-03 Piotr Rudnicki + + gdb: remove unused argument in evaluate_subexp_for_address_base + Remove the unused 'struct expression *exp' parameter from + evaluate_subexp_for_address_base and also do some format cleanup. + +2025-06-03 Tom de Vries + + [gdb/cli] Use captured per_command_time in worker threads + With test-case gdb.base/maint.exp, I ran into: + ... + (gdb) file maint^M + Reading symbols from maint...^M + (gdb) mt set per-command on^M + (gdb) Time for "DWARF indexing worker": ...^M + Time for "DWARF indexing worker": ...^M + Time for "DWARF indexing worker": ...^M + Time for "DWARF indexing worker": ...^M + Time for "DWARF skeletonless type units": ...^M + Time for "DWARF add parent map": ...^M + Time for "DWARF finalize worker": ...^M + Time for "DWARF finalize worker": ...^M + Time for "DWARF finalize worker": ...^M + Time for "DWARF finalize worker": ...^M + Time for "DWARF finalize worker": ...^M + FAIL: $exp: warnings: per-command: mt set per-command on (timeout) + mt set per-command off^M + 2025-05-31 09:33:44.711 - command started^M + (gdb) PASS: $exp: warnings: per-command: mt set per-command off + ... + + I didn't manage to reproduce this by rerunning the test-case, but it's fairly + easy to reproduce using a file with more debug info, for instance gdb: + ... + $ gdb -q -batch -ex "file build/gdb/gdb" -ex "mt set per-command on" + ... + + Due to the default "mt dwarf synchronous" == off, the file command starts + building the cooked index in the background, and returns immediately without + waiting for the result. + + The subsequent "mt set per-command on" implies "mt set per-command time on", + which switches on displaying of per-command execution time. + + The "Time for" lines are the result of those two commands, but these lines + shouldn't be there because "mt per-command time" == off at the point of + issuing the file command. + + Fix this by capturing the per_command_time variable, and using the captured + value instead. + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + + PR cli/33039 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33039 + +2025-06-03 GDB Administrator + + Automatic date update in version.in + +2025-06-02 Simon Marchi + + gdb/dwarf2: update call_site::target comment + This comment refers to the field location kind enum, even though call + sites were moved to their own enum in 7eb21cc70224 ("Change + call_site_target to use custom type and enum"). Update it. + + Change-Id: I089923170c919853efb2946529221a4b55e720c1 + +2025-06-02 Andrew Burgess + + gdb: use quoted filename completion for the shell command + With the quoted filename completion work that I did last year the + deprecated_filename_completer function will now only complete a single + word as a filename, for example: + + (gdb) save breakpoints /tm + + The 'save breakpoints' command uses the deprecated_filename_completer + completion function. In the above '/tm' will complete to '/tmp/' as + expected. However, if you try this: + + (gdb) save breakpoints /tmp/ /tm + + The second '/tm' will not complete for GDB 16.x, but will complete + with GDB 15.x as GDB 15.x is before my changes were merged. + + What's actually happening here is that, before my changes, the + filename completion was breaking words on white space, so in the above + the first '/tmp/' and the second '/tm' are seen as separate words for + completion, the second word is therefore seen as the start of a new + filename. + + After my changes, deprecated_filename_completer allows spaces to be + part of the filename, so in the above, GDB is actually trying to + complete a filename '/tmp/ /tm' which likely doesn't exist, and so + completion stops. + + This change for how deprecated_filename_completer works makes sense, + commands like 'save breakpoints' take their complete command arguments + and treat it as a single filename, so given this: + + (gdb) save breakpoints /tmp/ /tm + + GDB really will try to save breakpoints to a file called '/tmp/ /tm', + weird as that may seem. How GDB interprets the command arguments + didn't change with my completion patches, I simply brought completion + into line with how GDB interprets the arguments. + + The patches I'm talking about here are this set: + + * 4076f962e8c gdb: split apart two different types of filename completion + * dc22ab49e9b gdb: deprecated filename_completer and associated functions + * 35036875913 gdb: improve escaping when completing filenames + * 1d1df753977 gdb: move display of completion results into completion_result class + * bbbfe4af4fb gdb: simplify completion_result::print_matches + * 2bebc9ee270 gdb: add match formatter mechanism for 'complete' command output + * f2f866c6ca8 gdb: apply escaping to filenames in 'complete' results + * 8f87fcb1daf gdb: improve gdb_rl_find_completion_word for quoted words + * 67b8e30af90 gdb: implement readline rl_directory_rewrite_hook callback + * 1be3b2e82f7 gdb: extend completion of quoted filenames to work in brkchars phase + * 9dedc2ac713 gdb: fix for completing a second filename for a command + * 4339a3ffc39 gdb: fix filename completion in the middle of a line + + Bug PR gdb/32982 identifies a problem with the shell command; + completion broke between 15.x and 16.x. The shell command also uses + deprecated_filename_completer for completion. But consider a shell + command line: + + (gdb) shell ls /tm + + The arguments to the shell command are 'ls /tm' at the point is + pressed. Under the old 15.x completion GDB would split the words on + white space and then try to complete '/tm' as a filename. + + Under the 16.x model, GDB completes all the arguments as a single + filename, that is 'ls /tm', which is unlikely to match any filenames, + and so completion fails. + + The fix is to write a custom completion function for the shell_command + function (cli/cli-cmds.c), this custom completion function will skip + forward to find the last word in the arguments, and then try to + complete that, so in the above example, GDB will skip over 'ls ', and + then tries to complete '/tm', which is exactly what we want. + + Given that the filenames passed to the shell command are forwarded to + an actual shell, I have switched over the new quoted filename + completion function for the shell command, this means that white space + within a filename will be escaped with a backslash by the completion + function, which is likely what the user wants, this means the filename + will arrive in the (actual) shell as a single word, rather than + splitting on white space and arriving as two words. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32982 + + Reviewed-By: Tom Tromey + +2025-06-02 Tom Tromey + + Fix DAP defer_stop_events implementation + DAP requests have a "defer_stop_events" option that is intended to + defer the emission of any "stopped" event until after the current + request completes. This was needed to handle async continues like + "finish &". + + However, I noticed that sometimes DAP tests can fail, because a stop + event does arrive before the response to the "stepOut" request. I've + only noticed this when the machine is fairly loaded -- for instance + when I'm regression-testing a series, it may occur in some of the + tests mid-series. + + I believe the problem is that the implementation in the "request" + function is incorrect -- the flag is set when "request" is invoked, + but instead it must be deferred until the request itself is run. That + is, the setting must be captured in one of the wrapper functions. + + Following up on this, Simon pointed out that introducing a delay + before sending a request's response will cause test case failures. + That is, there's a race here that is normally hidden. + + Investigation showed that that deferred requests can't force event + deferral. This patch implements this; but more testing showed many + more race failures. Some of these are due to how the test suite is + written. + + Anyway, in the end I took the radical approach of deferring all events + by default. Most DAP requests are asynchronous by nature, so this + seemed ok. The only case I found that really required this is + pause.exp, where the test (rightly) expects to see a 'continued' event + while performing an inferior function call. + + I went through all events and all requests and tried to convince + myself that this patch will cause acceptable behavior in every case. + However, it's hard to be completely sure about this approach. Maybe + there are cases that do still need an event before the response, but + we just don't have tests for them. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32685 + Acked-By: Simon Marchi + +2025-06-02 Patrick Monnerat + + gdb: introduce a per-interpreter event servicing method + This allows an interpreter to override internal calls to + gdb_do_one_event in case the former needs to handle alternate event + sources. + + The default action is to call gdb_do_one_event and this is not overriden + in current internal interpreters. However this feature allows to easily + embed Tcl/Tk in insight that needs to concurrently handle Tcl events for + GUI handling. + + In all cases, an interpreter event servicing method must call + gdb_do_one_event at some point. + + All internal event servicing calls from gdb now direct to the + interpreter-specific method rather than gdb_do_one_event itself. + +2025-06-02 Tom de Vries + + [gdb/python] Reimplement F405 fix + At commit 34b0776fd73^, flake8 reports the following F405 warnings: + ... + $ pre-commit run flake8 --file gdb/python/lib/gdb/__init__.py + flake8...................................................................Failed + - hook id: flake8 + - exit code: 1 + + F405 'flush' may be undefined, or defined from star imports: _gdb + F405 'write' may be undefined, or defined from star imports: _gdb + F405 'STDOUT' may be undefined, or defined from star imports: _gdb + F405 'STDERR' may be undefined, or defined from star imports: _gdb + ... + F405 'selected_inferior' may be undefined, or defined from star imports: _gdb + F405 'execute' may be undefined, or defined from star imports: _gdb + F405 'parameter' may be undefined, or defined from star imports: _gdb + ... + + The F405s are addressed by commit 34b0776fd73 ('Suppress some "undefined" + warnings from flake8'). + + The problem indicated by the first F405 is that the use of flush here: + ... + class _GdbFile(object): + ... + def flush(self): + flush(stream=self.stream) + ... + cannot be verified by flake8. It concludes that either, flush is undefined, + or it is defined by this "star import": + ... + from _gdb import * # noqa: F401,F403 + ... + + In this particular case, indeed flush is defined by the star import. + + This can be addressed by simply adding: + ... + flush(stream=self.stream) # noqa: F405 + ... + but that has only effect for flake8, so other analyzers may report the same + problem. + + The commit 34b0776fd73 addresses it instead by adding an "import _gdb" and + adding a "_gdb." prefix: + ... + _gdb.flush(stream=self.stream) + ... + + This introduces a second way to specify _gdb names, but the first one still + remains, and occasionally someone will use the first one, which then requires + fixing once flake8 is run [1]. + + While this works to silence the warnings, there is a problem: if a developer + makes a typo: + ... + _gdb.flash(stream=self.stream) + ... + this is not detected by flake8. + + This matters because although the python import already complains: + ... + $ gdb -q -batch -ex "python import gdb" + Exception ignored in: + Traceback (most recent call last): + File "__init__.py", line 63, in flush + _gdb.flash(stream=self.stream) + AttributeError: module '_gdb' has no attribute 'flash' + ... + that doesn't trigger if the code is hidden behind some control flow: + ... + if _var_mostly_false: + flash(stream=self.stream) + ... + + Instead, fix the F405s by reverting commit 34b0776fd73 and adding a second + import of _gdb alongside the star import which lists the names used locally: + ... + from _gdb import * # noqa: F401,F403 + +from _gdb import ( + + STDERR, + + STDOUT, + + Command, + + execute, + + flush, + + parameter, + + selected_inferior, + + write, + +) + ... + + This gives the following warnings for the flash typo: + ... + 31:1: F401 '_gdb.flush' imported but unused + 70:5: F811 redefinition of unused 'flush' from line 31 + 71:9: F405 'flash' may be undefined, or defined from star imports: _gdb + ... + + The benefits of this approach compared to the previous one are that: + - the typo is noticed, and + - when using a new name, the F405 fix needs to be done once (by adding it to + the explicit import list), while previously the fix had to be applied to + each use (by adding the "_gdb." prefix). + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] Commit 475799b692e ("Fix some pre-commit nits in gdb/__init__.py") + +2025-06-02 GDB Administrator + + Automatic date update in version.in + +2025-06-01 Tom Tromey + + Have bfd_thread_init fail when thread-local storage is unavailable + If thread-local storage is unavailable, bfd_thread_init should fail, + because in this case BFD can't be used from multiple threads -- it + relies on TLS working. + +2025-06-01 Tom de Vries + + [gdb/tdep] Fix gdb.ada/finish-var-size.exp on ppc64le-linux + On openSUSE Tumbleweed ppc64le-linux using gcc 14.3.0, with a gdb 16.3 based + package and test-case gdb.ada/finish-var-size.exp, I run into: + ... + (gdb) finish^M + Run till exit from #0 pck.get (value=true) at pck.adb:19^M + 0x0000000100004a20 in p () at finish-var-size/p.adb:18^M + 18 V : Result_T := Get (True);^M + Value returned is $1 = ^M + (gdb) FAIL: gdb.ada/finish-var-size.exp: finish + ... + + Function pck.get returns type Result_T: + ... + type Array_Type is array (1 .. 64) of Integer; + + type Maybe_Array (Defined : Boolean := False) is + record + Arr : Array_Type; + Arr2 : Array_Type; + end record; + + type Result_T (Defined : Boolean := False) is + record + case Defined is + when False => + Arr : Maybe_Array; + when True => + Payload : Boolean; + end case; + end record; + ... + and uses r3 as address of the return value, which means + RETURN_VALUE_STRUCT_CONVENTION, but while executing finish_command we do: + ... + return_value + = gdbarch_return_value_as_value (gdbarch, + read_var_value (sm->function, nullptr, + callee_frame), + val_type, nullptr, nullptr, nullptr); + ... + and get: + ... + (gdb) p return_value + $1 = RETURN_VALUE_REGISTER_CONVENTION + ... + + This is caused by this check in ppc64_sysv_abi_return_value: + ... + /* In the ELFv2 ABI, aggregate types of up to 16 bytes are + returned in registers r3:r4. */ + if (tdep->elf_abi == POWERPC_ELF_V2 + && valtype->length () <= 16 + ... + which succeeds because valtype->length () == 0. + + Fix this by also checking for !TYPE_HAS_DYNAMIC_LENGTH (valtype). + + [ I also tested a version of this patch using "!is_dynamic_type (valtype)" + instead, but ran into a regression in test-case gdb.ada/variant-record.exp, + because type T: + ... + Length : constant Positive := 8; + subtype Name_T is String (1 .. Length); + + type A_Record_T is + record + X1 : Natural; + X2 : Natural; + end record; + + type Yes_No_T is (Yes, No); + type T (Well : Yes_No_T := Yes) is + record + case Well is + when Yes => + Name : Name_T; + when No => + Unique_Name : A_Record_T; + end case; + end record; + ... + while being dynamic, also has a non-zero size, and is small enough to be + returned in registers r3:r4. ] + + Fixing this causes the test-case to fail with the familiar: + ... + warning: Cannot determine the function return value. + Try compiling with -fvar-tracking. + ... + and indeed using -fvar-tracking makes the test-case pass. + + Tested on ppc64le-linux. + + PR tdep/33000 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33000 + +2025-06-01 Alan Modra + + weakref gas internal error + This horrible testcase (cleaned up from oss-fuzz) + r=x*2 + x=r-r + .weakref r,x + r=r-5 + triggers resolve_symbol_value "gas_assert (final_val == 0)" in weakref + handling. + + * read.c (assign_symbol): Clear weakrefr. + +2025-06-01 Alan Modra + + decompress_contents: fuss over 32-bit long + Some 64-bit compilers have a 32-bit long, which could result in an + endless loop if uncompressed_size is larger than 4G. + +2025-06-01 Rui Ueyama + + PR 33033, Support compressed debug sections larger than 4 GiB + z_stream's avail_in and avail_out are defined as "unsigned int", so it + cannot decode an entire compressed stream in one pass if the stream is + larger than 4 GiB. The simplest solution to this problem is to use zlib's + convenient uncompress2() function, which handles the details for us. + +2025-06-01 GDB Administrator + + Automatic date update in version.in + +2025-05-31 Tom Tromey + + Do not allocate macro_scope on the heap + I noticed that there's no particular reason to allocate the + macro_scope objects on the heap. They can be passed around by value + just as easily. + + Approved-By: Simon Marchi + +2025-05-31 Tom Tromey + + Define TLS in bfd.c if not already defined + If configure decides that thread-local storage isn't available, it + does not define "TLS". However, this is used unconditionally in a + definition. So, define it if it isn't already defined. + +2025-05-31 GDB Administrator + + Automatic date update in version.in + +2025-05-30 Alan Modra + + PR 33020 segv in _bfd_elf_strtab_offset + The PR fuzzer testcase creates a SHT_NOBITS .debug_info section, then + triggers a bug in --compress-debug-sections=zlib whereby sh_name is + set to -1 in elf_fake_sections as a flag to indicate the name is not + set yet (may change to zdebug_*), but the section never hits the debug + compression code in assign_file_positions_for_non_load_sections that + is responsible for setting sh_name. + + PR 33020 + * elf.c (_bfd_elf_init_reloc_shdr): Rename delay_st_name_p + param to delay_sh_name_p. + (elf_fake_sections): Rename delay_st_name_p to delay_sh_name_p. + Don't set delay_sh_name_p for no contents debug sections. + +2025-05-30 Alan Modra + + Revert "Replace assertions with error return values, thus ensuring an illegal memory access does not occur." + This reverts commit 429fb15134cfbdafe2b203086ee05d827726b63b. + +2025-05-30 Andrew Pinski + + gprofng: Use __x86_64__ instead of __x86_64 + With some compilers, only __x86_64__ is defined so use that + instead of __x86_64. + + gprofng/ChangeLog + 2025-05-30 Andrew Pinski + * common/core_pcbe.c: s/__x86_64/__x86_64__/. + * common/cpu_frequency.h: Likewise. + * common/cpuid.c: Likewise. + * common/gp-defs.h: Likewise. + * common/hwctable.c: Likewise. + * libcollector/libcol-i386-dis.c: Likewise. + * libcollector/libcol_util.h: Likewise. + +2025-05-30 Tom Tromey + + Remove some Rust expression helpers + When I did the big expression conversion, I left some helper functions + lying around, primarily because the conversion was already quite large + and I didn't want to add on. + + This patch removes a couple such helpers, turning them into methods on + the appropriate operation objects. + + Approved-By: Simon Marchi + +2025-05-30 Simon Marchi + + gdb: fix DW_AT_compile_unit -> DW_TAG_compile_unit in comment + While (mistakenly) grepping for DW_AT_compile_unit, I found this typo. + + Change-Id: I04d97d7b1b27eacfca9da3853711b6092d330575 + +2025-05-30 Nick Clifton + + Prevent illegal memory access when generating map file entries for ifuncs removed by garbage collection + +2025-05-30 Tom Tromey + + Require Python 3.4 + I believe we previously agreed that the minimum supported Python + version should be 3.4. This patch makes this change, harmonizing the + documentation (which was inconsistent about the minimum version) and + the code. + + New in v2: rebased, and removed a pre-3.4 workaround from __init__.py. + + Reviewed-By: Eli Zaretskii + Approved-by: Kevin Buettner + Acked-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31870 + +2025-05-30 Nick Clifton + + Replace assertions with error return values, thus ensuring an illegal memory access does not occur. + PR 33020 + + Updated Malay translation for the bfd/ sub-directory + +2025-05-30 Alan Modra + + elf symbol size + This changes elf_obj_sy.size from being malloc'd to being on the notes + obstack. That means no code needs to free these expressions, which in + turn means that the size expression can be shared when cloning + symbols. Nothing modifies the size expressions except when resolving. + In all cases I could see, if the size changes the entire expression is + replaced. + + The patch also extracts code from elf_copy_symbol_attributes into a + separate function for use by riscv and aarch64. + + * config/obj-elf.c (elf_obj_symbol_clone_hook): Delete. + (elf_copy_symbol_size): New function, extracted and modified from.. + (elf_copy_symbol_attributes): ..here. + (obj_elf_size): Don't free size and use notes_alloc. + (elf_frob_symbol): Don't free size. + (elf_format_ops): Zero symbol_clone_hook. + * config/obj-elf.h (elf_obj_symbol_clone_hook): Delete. + (obj_symbol_clone_hook): Don't define. + (elf_copy_symbol_size): Declare. + * config/tc-aarch64.c (aarch64_elf_copy_symbol_attributes): Delete. + * config/tc-aarch64.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as + elf_copy_symbol_size. + * config/tc-alpha.c (s_alpha_end): notes_alloc symbol size exp. + * config/tc-ia64.c (dot_endp): Likewise. + * config/tc-kvx.c (kvx_endp): Likewise. + * config/tc-mips.c (s_mips_end): Likewise. + * config/tc-riscv.c (riscv_elf_copy_symbol_attributes): Delete. + * config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as + elf_copy_symbol_size. + +2025-05-30 Alan Modra + + gas symbol_remove + If a symbol is at the start of the symbol chain then symbol_rootP + points at the symbol and symbol->x->previous is NULL. Testing either + condition is sufficient, there is no need to test both. Similarly for + the symbol at the end of the symbol chain. + + I'm testing the previous/next pointer because it's most likely that + the symbol is not at the start/finish of the chain and thus we need to + use that pointer. + + * symbols.c (symbol_remove): Tidy list handling. + (symbol_append, symbol_clone, symbol_insert): Likewise. + +2025-05-30 Alan Modra + + Reduce rs_align_code memory for small alignments + On x86, MAX_MEM_FOR_RS_ALIGN_CODE is 35, when the most common + alignment is 2**3 or 2**4, where the max memory required for the + alignment nops is 7 and 15 bytes respectively. So there is some + memory wasted since commit 83d94ae428b1. It's not a large amount, + especially considering that frag overhead on x86_46 is 144 bytes, + but even so I'd rather not be blamed for increasing gas memory usage. + + So to reduce the memory we'd like to take the alignment into + consideration when initialising an rs_align_code frag. The only + difficulty here is start_bundle making an rs_align_code frag with an + alignment of zero initially, then later increasing the alignment. We + change that to use the bundle alignment when setting up the frag. I + think that is sufficient as bundle_align_p2 can't change in the middle + of a start_bundle/finish_bundle sequence. + + I haven't modified any targets other than x86 in this patch. Most + won't benefit much due to using fairly small MAX_MEM_FOR_RS_ALIGN_CODE. + + * read.c (start_bundle): Create rs_align_code frag with + bundle_align_p2 alignment, then set to zero alignment. + (finish_bundle): Adjust comment. + * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Pass p2align and max + to macro. + * config/tc-i386.h (HANDLE_ALIGN): Assert that max_bytes is + sufficient for nop padding. + (max_mem_for_rs_align_code): New inline function. + (MAX_MEM_FOR_RS_ALIGN_CODE): Use it. + * config/tc-aarch64.h: Adjust MAX_MEM_FOR_RS_ALIGN_CODE. + * config/tc-alpha.h: Likewise. + * config/tc-arc.h: Likewise. + * config/tc-arm.h: Likewise. + * config/tc-epiphany.h: Likewise. + * config/tc-frv.h: Likewise. + * config/tc-ia64.h: Likewise. + * config/tc-kvx.h: Likewise. + * config/tc-loongarch.h: Likewise. + * config/tc-m32r.h: Likewise. + * config/tc-metag.h: Likewise. + * config/tc-mips.h: Likewise. + * config/tc-nds32.h: Likewise. + * config/tc-ppc.h: Likewise. + * config/tc-riscv.h: Likewise. + * config/tc-rl78.h: Likewise. + * config/tc-rx.h: Likewise. + * config/tc-score.h: Likewise. + * config/tc-sh.h: Likewise. + * config/tc-sparc.h: Likewise. + * config/tc-spu.h: Likewise. + * config/tc-tilegx.h: Likewise. + * config/tc-tilepro.h: Likewise. + * config/tc-visium.h: Likewise. + * config/tc-xtensa.h: Likewise. + +2025-05-30 GDB Administrator + + Automatic date update in version.in + +2025-05-29 Guinevere Larsen + + gdb: update corner case when canonicalizing riscv syscall names + The script syscalls/riscv-canonicalize-syscall-gen.py has been recently + introduced to help support record-full in riscv systems. However, it + was developed before commit 432eca4113d5748ad284a068873455f9962b44fe, + which made the GDB enum more consistent, which forced the python script + to have a corner case for the "gdb_old_mmap" case. + + Since the aforementioned commit has already been merged, we need to + update the special case for the mmap syscall. A special case is still + needed because the script would expect that the glibc sources call the + syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which + happens unfortunately. + + This commit doesn't change the .c file because it was already fixed by a + different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was + pushed as obvious to fix the build issues. + + Approved-By: Tom Tromey + +2025-05-29 Jorenar + + gdb/dap: fix completion request for empty strings + When DAP completion requests receives empty string to complete, + the script crashes due trying to access element -1 from list + being a result of `text.splitlines()` (which for `text == ""` + evaluates into empty list). + + This patch adds simple check if `text` is populated, and when it + is not, skips transformations and assigns correct result directly. + + Approved-By: Tom Tromey + +2025-05-29 Simon Marchi + + gdb, gdbsupport: fix all `;;` instances + I forgot to fix a `;;` typo when pushing a previous patch. Fix it, and + fix all the other instances I could find in the code base. + + Change-Id: I298f9ffb1a5157925076ef67b439579b1aeeaa2b + +2025-05-29 Pedro Alves + + Fix build when RUSAGE_THREAD is not available & add warning + Building current GDB on Cygwin, fails like so: + + /home/pedro/gdb/src/gdbsupport/run-time-clock.cc: In function ‘void get_run_time(user_cpu_time_clock::time_point&, system_cpu_time_clock::time_point&, run_time_scope ’: + /home/pedro/gdb/src/gdbsupport/run-time-clock.cc:52:13: error: ‘RUSAGE_THREAD’ was not declared in this scope; did you mean ‘SIGEV_THREAD’? + 52 | who = RUSAGE_THREAD; + | ^~~~~~~~~~~~~ + | SIGEV_THREAD + + Cygwin does not implement RUSAGE_THREAD. Googling around, I see + Cygwin is not alone, other platforms don't support it either. For + example, here is someone suggesting an alternative for darwin/macos: + https://stackoverflow.com/questions/5652463/equivalent-to-rusage-thread-darwin + + Fix this by falling back to process scope if thread scope can't be + supported. I chose this instead of returning zero usage or some other + constant, because if gdb is built without threading support, then + process-scope run time usage is the right info to return. + + But instead of falling back silently, print a warning (just once), + like so: + + (gdb) maint set per-command time on + ⚠️ warning: per-thread run time information not available on this platform + + ... so that developers on other platforms at least have a hint + upfront. + + This new warning also shows on platforms that don't have getrusage in + the first place, but does not show if the build doesn't support + threading at all. + + New tests are added to gdb.base/maint.exp, to expect the warning, and + also to ensure other "mt per-command" sub commands don't trigger the + new warning. + + Change-Id: Ie01b916b62f87006f855e31594a5ac7cf09e4c02 + Approved-By: Simon Marchi + Approved-By: Tom Tromey + +2025-05-29 Simon Marchi + + gdb/solib: make solib_ops::solib_create_inferior_hook optional + The solib-target implementation of solib_create_inferior_hook is empty. + Make that method / function pointer optional. + + Change-Id: Ie27b8d2c4fc6df74069ac8f88fbe69cf88a6662d + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/solib: make solib_ops::in_dynsym_resolve_code optional + Two solib ops implementations have dummy implementations for the + in_dynsym_resolve_code callback. Make it optional, to avoid this. + + Change-Id: I786776fb82ce1b96335a97713fbfe8074c84c00c + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/solib: make implementation of solib_ops::open_symbol_file_object optional + The only solib implementation that implements open_symbol_file_object is + SVR4. All others just return 0. Make it optional, to avoid having + these empty functions. + + Change-Id: I835197a73323d39231d071f9a9eaac2553f10726 + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/solib: boolify in_dynsym_resolve_code functions + Change-Id: I66f5986e1a2452e3817f326d908b2e49f99e2fc6 + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/solib: move solist.h content to solib.h + I don't think that the file solist.h is useful. It would make sense to + have `struct solib` in solib.h. And then, all that would remain is + `struct solib_ops` and some solib-related function declarations. So, + move it all to solib.h. + + Change-Id: I20ecf19787c378066f2c7a6a8a737c1db7c55d9a + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/progspace: rename progspace::so_list, make private + Rename the field to m_solib_list, make it private. Update users to go + through the accessor. + + Change-Id: Id720c3a0b1781f4acf31e0dc626f1bd23ed8b39a + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb: fix stale references to so_list + Adjust some comments and function names that refer to the ancient + so_list type. + + Update some other stale comments in solib-svr4.c at the same time. + + Change-Id: Ia42efa6554d0cc6abb4183b6bffc96c6358c5735 + Reviewed-By: Guinevere Larsen + +2025-05-29 Simon Marchi + + gdb/solib: remove so_ prefix from so_name and so_original_name + The `so_` prefix is unnecessary here, it's already clear by the fact + that they are field of the solib type (and previously so_list). + + Change-Id: I2c6773afc121d7631901e602913ea8a068840d0b + Reviewed-By: Guinevere Larsen + +2025-05-29 GDB Administrator + + Automatic date update in version.in + +2025-05-28 Tom de Vries + + [gdb/symtab] Note errors in process_skeletonless_type_units + With a hello world a.out, and using the compiler flags from target board + dwarf5-fission-debug-types: + ... + $ gcc -gdwarf-5 -fdebug-types-section -gsplit-dwarf ~/data/hello.c + ... + I run into: + ... + $ gdb -q -batch a.out + terminate called after throwing an instance of 'gdb_exception_error' + ... + + What happens is that an error is thrown due to invalid dwarf, but the error is + not caught, causing gdb to terminate. + + In a way, this is a duplicate of PR32861, in the sense that we no longer run + into this after: + - applying the proposed patch (work around compiler bug), or + - using gcc 9 or newer (compiler bug fixed). + + But in this case, the failure mode is worse than in PR32861. + + Fix this by catching the error in + cooked_index_worker_debug_info::process_skeletonless_type_units. + + With the patch, we get instead: + ... + $ gdb -q -batch a.out + Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \ + .debug_str.dwo section in CU at offset 0x0 [in module a.out] + ... + + While we're at it, absorb the common use of + cooked_index_worker_result::note_error: + ... + try + { + ... + } + catch (gdb_exception &exc) + { + (...).note_error (std::move (exc)); + } + ... + into the method and rename it to catch_error, resulting in more compact code + for the fix: + ... + (...).catch_error ([&] () + { + ... + }); + ... + + While we're at it, also use it in + cooked_index_worker_debug_info::process_units which looks like it needs the + same fix. + + Tested on x86_64-linux. + + PR symtab/32979 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32979 + +2025-05-28 Alan Modra + + elfedit: segv with --enable-x86-feature + PR 33024 + PR 33025 + * elfedit.c (update_gnu_property): Sanity check program headers. + + Further rs_code_align support refinement + Don't write the repeating nop pattern if it won't be used. + +2025-05-28 Alexandra Hájková + + Call restore_original_signal_state after GDB forks. + When I run GDB under Valgrind, GDB seems to segfault + displaying: + + Fatal signal: Segmentation fault + ----- Backtrace ----- + 0x2803f7 ??? + 0x3c9696 ??? + 0x3c9899 ??? + 0x55f8fcf ??? + 0x486c000 ??? + --------------------- + A fatal error internal to GDB has been detected, further + debugging is not possible. GDB will now terminate. + + This is a bug, please report it. For instructions, see: + . + + warning: linux_ptrace_test_ret_to_nx: PC 0x5821c09d is neither near return address 0x486c000 nor is the return instruction 0x4f8f4a! + + but then, acts like nothing happened and excutes normally. This is + because it's the child from linux_ptrace_test_ret_to_nx that + segfaults and parent GDB carries on normally. Restore the original + signal states to not to print confusing backtrace. After restoring, + only such warning is displayed: + + warning: linux_ptrace_test_ret_to_nx: WSTOPSIG 19 is neither SIGTRAP nor SIGSEGV! + +2025-05-28 Alan Modra + + PR 33029 segv in dwarf2_finish with --gdwarf-5 + Specifying --gdwarf-5 with a source lacking a ".file 0" directive + results in this segfault. + + * dwarf2dbg.c (out_debug_str): Use files[1] if files[0] is + empty regardless of dwarf level. + +2025-05-28 Alan Modra + + PR 33023 memory leak in objdump when specifying --endian + * objdump.c (disassemble_data): Free modified xvec and replace + original. + + PR 33021, buffer overflow in write_dwarf_eh_frame_hdr + * elf-eh-frame.c (write_dwarf_eh_frame_hdr): Use size of + contents, not section size, in bfd_set_section_contents call. + + PR 33018 segv in elf_x86_64_scan_relocs + * elf64-x86-64.c (elf_x86_64_scan_relocs): Error on NULL howto. + Use bfd_reloc_offset_in_range. + +2025-05-28 GDB Administrator + + Automatic date update in version.in + +2025-05-27 Simon Marchi + + gdb: make objfile_has_full_symbols and objfile_has_symbols methods of objfile + They seem like good candidates to become methods, just like + objfile::has_partial_symbols. + + Change-Id: Ic6df83012629c1137708b8ceb327f9868d8abcb5 + Reviewed-By: Guinevere Larsen + +2025-05-27 Thiago Jung Bauermann + + gdb/testsuite: Clarify -lbl option in gdb_test_multiple + I was a bit confused about the -lbl option in gdb_test_multiple, and needed + to read its implementation to determine that it would be useful for my + needs. Explicitly mention what the option does and why it's useful to + hopefully help other developers. + + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2025-05-27 Thiago Jung Bauermann + + gdb/testsuite: Fix flakiness in gdb.base/default.exp + The Linaro CI runs the GDB testsuite using the read1 tool, which + significantly increases the time it takes DejaGNU to read inferior output. + On top of that sometimes the test machine has higher than normal load, + which causes tests to run even slower. + + Because gdb.base/default.exp tests some verbose commands such as "info + set", it sometimes times out while waiting for the complete command + output when running in the Linaro CI environment. + + Fix this problem by consuming each line of output from the most verbose + commands with gdb_test_multiple's -lbl (line-by-line) option — which + causes DejaGNU to reset the timeout after each match — and also by + breaking up regular expressions that try to match more than 2000 + characters (the default Expect buffer size) in one go into multiple + matches. + + Some tests use the same regular expression, so I created a procedure for + them. This is the case for "i" / "info", "info set" / "show", and "set + print" tests. + + The tests for "show print" don't actually test their output, so this + patch improves them by checking some lines of the output. + + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2025-05-27 GDB Administrator + + Automatic date update in version.in + +2025-05-27 Alan Modra + + ALPHA_R_OP_STORE + In commit db4ab410dec3 I rewrote OP_STORE handling to support writing + near the end of a section. The rewrite had some bugs, fixed in commit + 3e02c4891dcb. However I wasn't entirely happy with the code writing + the bitfield: + - it doesn't support 64-bit fields with a bit offset, + - the code is duplicated and inelegant, + - the stack ought to be popped whenever seeing one of these relocs, + even if the reloc can't be applied. + This patch fixes all of the above. + + In addition, it is clear from the OP_STORE description in the ABI that + a 64-bit field is encoded as 0 in r_size, so I've decoded that in + alpha_ecoff_swap_reloc_in. The aborts there are not appropriate as + they can be triggered by user input (fuzzed object files). Also, + stack underflow wasn't checked in alpha_relocate_section. + + * coff-alpha.c (alpha_ecoff_swap_reloc_in): Replace aborts + with asserts. Decode ALPHA_R_OP_STORE r_size of zero. + (write_bit_field): New function. + (alpha_ecoff_get_relocated_section_contents): Use it. + (alpha_relocate_section): Here too. Catch stack underflow. + +2025-05-26 Jens Remus + + libsframe: handle SFrame FRE start/end IP offsets as unsigned + The SFrame FRE start address (fre_start_addr) is defined as unsigned + 32-bit integer, as it is an offset from SFrame FDE function start + address (sfde_func_start_address) and functions only grow upwards + (towards higher addresses). + + The SFrame FRE start IP offset is a synonym to the SFrame FRE start + address. The SFrame FRE end IP offset is either the value of the + subsequent FDE start address minus one, if that exists, or the FDE + function size minus one otherwise. Both should therefore be handled + as unsigned 32-bit integer. + + In libsframe the "lookup PC" (pc) and SFrame FDE function start address + (sfde_func_start_address) are both signed integers, as they are actually + offsets from the SFrame section. The unsigned FDE start/end IP offsets + may therefore only be safely compared against the offset of the lookup + PC from FDE function start address if the FDE function start address is + lower or equal to the lookup PC, as this guarantees the offset to be + always positive: + + Given: + + lookup_pc = pc - sframe_addr + + sfde_func_start_address = func_start_addr - sframe_addr + + If the FDE function start address is lower or equal than the lookup PC, + which both are signed offsets from SFrame section, then the function + start address is also lower or equal to the PC, which are both unsigned: + + sfde_func_start_address <= lookup_pc + func_start_addr - sframe_addr <= pc - sframe_addr + func_start_addr <= pc + + With that the offset of the lookup PC from FDE function start address + (lookup_pc - sfde_func_start_address) must always be positive, if + FDE function start address is lower or equal to the lookup PC: + + lookup_pc - sfde_func_start_address + = pc - sframe_addr - (func_start_addr - sframe_addr) + = pc - func_start_addr + + libsframe/ + * sframe.c (sframe_find_fre): Define and handle start_ip_offset + and end_ip_offset as unsigned (same as FRE fre_start_addr). + (sframe_fre_check_range_p): Likewise. Define PC offset (from + function start address) as unsigned. + +2025-05-26 Jens Remus + + libsframe: stop search for SFrame FRE if its start IP is greater than PC + The SFrame FREs for an SFrame FDE are sorted on their start address. + Therefore the linear search for a matching SFrame FRE can be stopped, + if its start address is greater than the searched for PC. + + libsframe/ + * sframe.c (sframe_find_fre): Stop search if FRE's start IP is + greater than PC. + +2025-05-26 Jens Remus + + libsframe: correct binary search for SFrame FDE + sframe_get_funcdesc_with_addr_internal erroneously returns the last FDE, + if its function start address is lower than the searched for address. + + Simplify the binary search for a SFrame FDE for a given address. Only + return an FDE, if the searched for address is within the bounds of the + FDE function start address and function size. + + libsframe/ + * sframe.c (sframe_get_funcdesc_with_addr_internal): Correct + binary search for SFrame FDE. + + libsframe/testsuite/ + * libsframe.find/plt-findfre-1.c: Add test for out of range + PLT6. + +2025-05-26 Indu Bhagat + + libsframe: testsuite: improve findfunc-1 testcase + The testcase had usages of some magic numbers, making it difficult to + keep up when format changes come along. + + libsframe/testsuite/ + * libsframe.find/findfunc-1.c: Restructure a bit. Run test for two + ways of placement of .sframe and .text. + +2025-05-26 Indu Bhagat + + libsframe: testsuite: improve findfre-1 testcase + The testcase had usages of some magic numbers, making it difficult to + keep up when format changes come along. + + libsframe/testsuite/ + * libsframe.find/findfre-1.c: Restructure a bit. Run test for two + ways of placement of .sframe and .text. + +2025-05-26 Indu Bhagat + + libsframe: fix issue finding FRE in PCMASK type SFrame FDEs + SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK are used for repetitive code + patterns, e.g., pltN entries. For SFrame FDEs of type + SFRAME_FDE_TYPE_PCMASK, sframe_fre_check_range_p erroneously tested the + given PC instead of the masked PC offset from function start address. + Therefore it only worked correctly by chance, e.g., if the function start + address was aligned on the repetition block size. + + For regular SFrame FDEs the PC offset from function start address must + be within a SFrame FRE's start IP offset and end IP offset. For SFrame + FDEs of type SFRAME_FDE_TYPE_PCMASK, the masked PC offset must be within + that range. + + SFrame FRE start/end IP offsets are relative to the SFrame FDE function + start address. For regular SFrame FDEs, the PC offset from function + start address must be within a SFrame FRE's start IP offset and end IP + offset. For SFRAME_FDE_TYPE_PCMASK type FDEs, the masked PC offset must + be within that range. + + Exercise the testcase for a variety of placements; without the fix some + of these tests will fail. Also, make the testcase itself easier to + follow by adding appropriate vars where applicable. + + libsframe/ + * sframe.c (sframe_fre_check_range_p): Fix logic for + SFRAME_FDE_TYPE_PCMASK type FDE. + libsframe/testsuite/ + * libsframe.find/plt-findfre-1.c: Adjust the test for a variety + of placements of .sframe and .plt. + + Co-Authored-by: Jens Remus + +2025-05-26 Indu Bhagat + + gas: sframe: handle .cfi_same_value + Fix PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas + + As per documentation, .cfi_same_value indicates that the current value + of register is the same like in the previous frame, i.e. no restoration + needed. + + gas/ + * gen-sframe.c (sframe_xlate_do_same_value): New definition. + (sframe_do_cfi_insn): Handle DW_CFA_same_value. + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Add new tests. + * gas/cfi-sframe/cfi-sframe-common-11.d: New test. + * gas/cfi-sframe/cfi-sframe-common-11.s: New test. + +2025-05-26 Tom de Vries + + [gdb] Factor out compare_pointers + Factor out compare_pointers, use it in compare_symbols and compare_msymbols, + and add comments about unstable sorting result. + + Tested on x86_64-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Andrew Burgess + +2025-05-26 Tom de Vries + + [gdb] Partially stabilize sort in compare_{symbols,msymbols} + In compare_symbols in gdb/linespec.c: + ... + uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace (); + uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace (); + + if (uia < uib) + return true; + if (uia > uib) + return false; + ... + we compare pointers to struct program_space, which gives unstable sorting + results. + + The assumption is that this doesn't matter, but as PR32202 demonstrates, + sometimes it does. + + While PR32202 is fixed elsewhere, it seems like a good idea to stabilize this + comparison, because it comes at a small cost and possibly prevents + hard-to-reproduce user-visible ordering issues. + + Fix this by comparing the program space IDs instead of the pointers. + + Likewise in compare_msymbols. + + Tested on x86_64-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Andrew Burgess + +2025-05-26 Tom de Vries + + [gdb/breakpoints] Stabilize info breakpoints output + With test-case gdb.multi/pending-bp-del-inferior.exp, occasionally I run into: + ... + (gdb) info breakpoints^M + Num Type Disp Enb Address What^M + 3 dprintf keep y ^M + printf "in foo"^M + 3.1 y 0x004004dc in foo at $c:21 inf 2^M + 3.2 y 0x004004dc in foo at $c:21 inf 1^M + (gdb) FAIL: $exp: bp_pending=false: info breakpoints before inferior removal + ... + + The FAIL happens because the test-case expects: + - breakpoint location 3.1 to be in inferior 1, and + - breakpoint location 3.2 to be in inferior 2 + but it's the other way around. + + I managed to reproduce this with a trigger patch in + compare_symbols from gdb/linespec.c: + ... + uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace (); + uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace (); + + - if (uia < uib) + + if (uia > uib) + return true; + - if (uia > uib) + + if (uia < uib) + return false; + ... + + The order enforced by compare_symbols shows up in the "info breakpoints" + output because breakpoint::add_location doesn't enforce an ordering for equal + addresses: + ... + auto ub = std::upper_bound (m_locations.begin (), m_locations.end (), + loc, + [] (const bp_location &left, + const bp_location &right) + { return left.address < right.address; }); + m_locations.insert (ub, loc); + ... + + Fix this by using new function bp_location_is_less_than + (forwarding to bp_location_ptr_is_less_than) in breakpoint::add_location. + + Tested on x86_64-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Andrew Burgess + + PR gdb/32202 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32202 + +2025-05-26 Tom de Vries + + [gdb/breakpoints] Rename bp_location_is_less_than to bp_location_ptr_is_less_than + In breakpoint.c, we have: + ... + /* A comparison function for bp_location AP and BP being interfaced to + std::sort. Sort elements primarily by their ADDRESS (no matter what + bl_address_is_meaningful says), secondarily by ordering first + permanent elements and tertiarily just ensuring the array is sorted + stable way despite std::sort being an unstable algorithm. */ + + static int + bp_location_is_less_than (const bp_location *a, const bp_location *b) + ... + + There are few problems here: + - the return type is int. While std::sort allows this, because int is + convertible to bool, it's clearer to use bool directly, + - it's not abundantly clear from either function name or comment that we can + use this to sort std::vector but not + std::vector, and + - the comment mentions AP and BP, but there are no such parameters. + + Fix this by: + - changing the return type to bool, + - renaming the function to bp_location_ptr_is_less_than and mentioning + std::vector in the comment, and + - updating the comment to use the correct parameter names. + + Tested on x86_64-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Andrew Burgess + +2025-05-26 Janne Ramstedt + + alpha, bfd: Fixes for ALPHA_R_OP_STORE + ALPHA_R_OP_STORE copies one byte too many and also will cause out of + range error when it tries to copy from the end of section. Since + "endbyte" is already rounded to next full byte, there is enough bits + to copy and the additional "+ 1" is erroneous in bytes count. I also + believe size is incorrectly decreased. + +2025-05-26 Markus Metzger + + gdb, btrace: remove record_btrace_target::supports_*() + Let's not introduce support for breakpoint types the target beneath does + not support, even though we could while replaying. + + Otherwise, users may set breakpoints during replay that then couldn't be + inserted into the target when switching back to recording. + + Approved-By: Andrew Burgess + +2025-05-26 Lulu Cai + + LoongArch: overflow and underflow checks for R_LARCH_32_PCREL + Relocation overflows can silently write incorrect value to + the file, so overflow checks are added to avoid this. + +2025-05-26 GDB Administrator + + Automatic date update in version.in + +2025-05-25 GDB Administrator + + Automatic date update in version.in + +2025-05-24 Simon Marchi + + gdb/solib-svr4: check that solib is SVR4 in tls_maybe_fill_slot and tls_maybe_erase_slot + Functions tls_maybe_fill_slot and tls_maybe_erase_slot blindly assume + that the passe solibs come from solib-svr4. This is not always the + case, because they are called even on the systems where the solib + implementation isn't solib-svr4. Add some checks to return early in + that case. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32990 + Change-Id: I0a281e1f4826aa1914460c2213f0fae1bdc9af7c + Tested-By: Hannes Domani + Approved-By: Andrew Burgess + +2025-05-24 Simon Marchi + + gdb: use local addrmap_mutable in addrmap selftest + There is no need to allocate the addrmap_mutable on the heap. + + Change-Id: Ia6ec17101a44ae5eaffbf3382c9639414ce5343e + Approved-By: Andrew Burgess + +2025-05-24 Simon Marchi + + gdb: turn CHECK_ADDRMAP_FIND into a function + Replace the macro with a function. I don't see a need to use a macro + here, a function is easier to read. + + Change-Id: I22370040cb546470498d64939b246b03700af398 + Approved-By: Andrew Burgess + +2025-05-24 Tom de Vries + + [gdb/build] Fix unused var in lookup_dwo_unit_in_dwp + On x86_64-linux, with gcc 7.5.0 I ran into a build breaker: + ... + gdb/dwarf2/read.c: In function ‘dwo_unit* lookup_dwo_unit_in_dwp()’: + gdb/dwarf2/read.c:7403:22: error: unused variable ‘inserted’ \ + [-Werror=unused-variable] + auto [it, inserted] = dwo_unit_set.emplace (std::move (dwo_unit)); + ^ + ... + + Fix this by dropping the unused variable. + + Tested on x86_64-linux, by completing a build. + +2025-05-24 Simon Marchi + + gdb: guard include with CXX_STD_THREAD + Change-Id: I4335fbfdabe49778fe37b08689eec59be94c424b + +2025-05-24 GDB Administrator + + Automatic date update in version.in + +2025-05-23 Andrew Burgess + + gdb/NEWS: minor white space fix + Spotted a small white space mistake in the NEWS file. Fixed. + +2025-05-23 Simon Marchi + + gdb: include in dwarf2/read.h + The buildbot pointed out this compilation failure on AlmaLinux, with g++ + 8.5.0, which is not seen on more recent systems: + + CXX gdbtypes.o + In file included from ../../binutils-gdb/gdb/gdbtypes.c:39: + ../../binutils-gdb/gdb/dwarf2/read.h:639:8: error: ‘mutex’ in namespace ‘std’ does not name a type + std::mutex dwo_files_lock; + ^~~~~ + ../../binutils-gdb/gdb/dwarf2/read.h:639:3: note: ‘std::mutex’ is defined in header ‘’; did you forget to ‘#include ’? + ../../binutils-gdb/gdb/dwarf2/read.h:35:1: + +#include + + ../../binutils-gdb/gdb/dwarf2/read.h:639:3: + std::mutex dwo_files_lock; + ^~~ + + Fix it by including in dwarf2/read.h. + + Change-Id: Iba334a3dad217c86841a5e804d0f386876f5ff2f + +2025-05-23 Tom de Vries + + [gdb] Make make-init-c more robust + In commit 2711e4754fc ("Ensure cooked_index_entry self-tests are run"), we + rewrite the function definition of _initialize_dwarf2_entry into a normal + form that allows the make-init-c script to detect it: + ... + void _initialize_dwarf2_entry (); + -void _initialize_dwarf2_entry () + +void + +_initialize_dwarf2_entry () + ... + + Update make-init-c to also detect the "void _initialize_dwarf2_entry ()" + variant. + + Tested on x86_64-linux, by reverting commit 2711e4754fc, rebuilding and + checking that build/gdb/init.c doesn't change. + +2025-05-23 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/fission-dw-form-strx.exp + Add a dwarf assembly test-case using a DW_FORM_strx in a .dwo file. + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + +2025-05-23 Simon Marchi + + gdb/dwarf: split dwo_lock in more granular locks + The dwo_lock mutex is used to synchronize access to some dwo/dwp-related + data structures, such as dwarf2_per_bfd::dwo_files and + dwp_file::loaded_{cus,tus}. Right now the scope of the lock is kind of + coarse. It is taken in the top-level lookup_dwo_unit function, and held + while the thread: + + - looks up an existing dwo_file in the per-bfd hash table for the given + id/signature + - if there's no existing dwo_file, attempt to find a .dwo file, open + it, build the list of units it contains + - if a new dwo_file was created, insert it in the per-bfd hash table + - look up the desired unit in the dwo_file + + And something similar for the dwp code path. This means that two + indexing thread can't read in two dwo files simultaneously. This isn't + ideal in terms of parallelism. + + This patch breaks this lock into 3 more fine grained locks: + + - one lock to access dwarf2_per_bfd::dwo_files + - one lock to access dwp_file::loaded_{cus,tus} + - one lock in try_open_dwop_file, where we do two operations that + aren't thread safe (bfd_check_format and gdb_bfd_record_inclusion) + + Unfortunately I don't see a clear speedup on my computer with 8 threads. + But the change shouldn't hurt, in theory, and hopefully this can be a + piece that helps in making GDB scale better on machines with many cores + (if we ever bump the max number of worker threads). + + This patch uses "double-checked locking" to avoid holding the lock(s) + for the whole duration of reading in dwo files. The idea is, when + looking up a dwo with a given name: + + - with the lock held, check for an existing dwo_file with that name in + dwarf2_per_bfd::dwo_files, if found return it + - if not found, drop the lock, load the dwo file and create a dwo_file + describing it + - with the lock held, attempt to insert the new dwo_file in + dwarf2_per_bfd::dwo_files. If an entry exists, it means another + thread simultaneously created an equivalent dwo_file, but won the + race. Drop the new dwo_file and use the existing one. The new + dwo_file is automatically deleted, because it is help by a unique_ptr + and the insertion into the unordered_set fails. + + Note that it shouldn't normally happen for two threads to look up a dwo + file with the same name, since different units will point to different + dwo files. But it were to happen, we handle it. This way of doing + things allows two threads to read in two different dwo files + simulatenously, which in theory should help get better parallelism. The + same technique is used for dwp_file::loaded_{cus,tus}. + + I have some local CI jobs that run the fission and fission-dwp boards, + and I haven't seen regressions. In addition to the regular testing, I + ran a few tests using those boards on a ThreadSanitizer build of GDB. + + Change-Id: I625c98b0aa97b47d5ee59fe22a137ad0eafc8c25 + Reviewed-By: Andrew Burgess + +2025-05-23 Simon Marchi + + gdb/dwarf: allocate DWP dwarf2_section_info with new + For the same reason as explained in the previous patch (allocations on + obstacks aren't thread-safe), change the allocation of + dwarf2_section_info object for dwo files within dwp files to use "new". + + The dwo_file::section object is not always owned by the dwo_file, so + introduce a new "dwo_file::section_holder" object that is only set when + the dwo_file owns the dwarf2_section_info. + + Change-Id: I74c4608573c7a435bf3dadb83f96a805d21798a2 + Approved-By: Tom Tromey + +2025-05-23 Simon Marchi + + gdb/dwarf: allocate dwo_unit with new + The following patch reduces the duration where the dwo_lock mutex is + taken. One operation that is not thread safe is the allocation on + dwo_units on the per_bfd obstack: + + dwo_unit *dwo_unit = OBSTACK_ZALLOC (&per_bfd->obstack, struct dwo_unit); + + We could take the lock around this allocation, but I think it's just + easier to avoid the problem by having the dwo_unit objects allocated + with "new". + + Change-Id: Ida04f905cb7941a8826e6078ed25dbcf57674090 + Approved-By: Tom Tromey + +2025-05-23 Tom Tromey + + Handle an argument-less operator in the C++ name parser + While debugging a new failure in my long-suffering "search-in-psyms" + series, I found that the C++ name canonicalizer did not handle a case + like "some_name::operator new []". This should remove the space, + resulting in "some_name::operator new[]" -- but does not. + + This happens because the parser requires an operator to be followed by + argument types. That is, it's expected. + + However, it seems to me that we do want to be able to canonicalize a + name like this. It will appear in the DWARF as a DW_AT_name, and + furthermore it could be entered by the user. + + This patch fixes this problem by changing the grammar to supply the + "()" itself, then removing the trailing "()" when changing to string + form (in the functions that matter). + + This isn't ideal -- it might miss a very obscure case involving the + gdb extension of providing fully-qualified names for function-local + statics -- but it improves the situation at least. + + It's possible a better solution might be to rewrite the name + canonicalizer. I was wondering if this could perhaps be done without + reference to the grammar -- just by examining the tokens. However, + that's much more involved. + + Let me know what you think. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32939 + Reviewed-By: Keith Seitz + +2025-05-23 Nick Alcock + + libctf: archive, open: when opening, always set errp to something + ctf_arc_import_parent, called by the cached-opening machinery used by + ctf_archive_next and archive-wide lookup functions like + ctf_arc_lookup_symbol, has an err-pointer parameter like all other opening + functions. Unfortunately it unconditionally initializes it whenever + provided, even if there was no error, which can lead to its being + initialized to an uninitialized value. This is not technically an + API-contract violation, since we don't define what happens to the error + value except when an error happens, but it is still unpleasant. + + Initialize it only when there is an actual error, so we never initialize it + to an uninitialized value. + + While we're at it, improve all the opening pathways: on success, set errp to + 0, rather than leaving it what it was, reducing the likelihood of + uninitialized error param returns in callers too. (This is inconsistent + with the treatment of ctf_errno(), but the err value being a parameter + passed in from outside makes the divergence acceptable: in open functions, + you're never going to be overwriting some old error value someone might want + to keep around across multiple calls, some of which are successful and some + of which are not.) + + Soup up existing tests to verify all this. + + Thanks to Bruce McCulloch for the original patch, and Stephen Brennan for + the report. + + libctf/ + PR libctf/32903 + * ctf-archive.c (ctf_arc_open_internal): Zero errp on success. + (ctf_dict_open_sections): Zero errp at the start. + (ctf_arc_import_parent): Intialize err. + * ctf-open.c (ctf_bufopen): Zero errp at the start. + * testsuite/libctf-lookup/add-to-opened.c: Make sure one-element + archive opens update errp. + * testsuite/libctf-writable/ctf-compressed.c: Make sure real archive + opens update errp. + +2025-05-23 Jiawei + + RISC-V: Add support for RISC-V Profiles 23. + This patch adds support for RISC-V RVA23 and RVB23 Profiles[1]. + + [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified + + bfd/ChangeLog: + + * elfxx-riscv.c: New profiles. + + gas/ChangeLog: + + * testsuite/gas/riscv/attribute-19.d: New test. + * testsuite/gas/riscv/attribute-20.d: New test. + +2025-05-23 Jiawei + + RISC-V: Add support for RISC-V Profiles 20/22. + This patch introduces support for RISC-V Profiles RV20 and RV22 [1], + enabling developers to utilize these profiles through the -march option. + + [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 + + bfd/ChangeLog: + + * elfxx-riscv.c (struct riscv_profiles): New struct. + (riscv_parse_extensions): New argument. + (riscv_find_profiles): New checking function. + (riscv_parse_subset): Add Profiles handler. + + gas/ChangeLog: + + * NEWS: Add RISC-V Profiles. + * doc/as.texi: Update -march input type. + * doc/c-riscv.texi: Ditto. + * testsuite/gas/riscv/option-arch-fail.l: Modify hint info. + * testsuite/gas/riscv/attribute-17.d: New test. + * testsuite/gas/riscv/attribute-18.d: New test. + * testsuite/gas/riscv/march-fail-rvi20u64v.d: New test. + * testsuite/gas/riscv/march-fail-rvi20u64v.l: New test. + +2025-05-23 GDB Administrator + + Automatic date update in version.in + +2025-05-23 QBos07 + + PR 3298 Fix SuperH relaxation overriding wrong intruction + when doing load store switching it wrongly adjusts the address of the + R_SH_USES reloc and not the actual offset from that instruction. This is + an issue if the pc-relative function call relaxation gets done in a + later pass wich will result in overriding the wrong instruction. + +2025-05-22 Alan Modra + + rs_fill_nop and md_generate_nops + Make rs_fill_nop behave like rs_fill in using a repeat count + (fr_offset) to emit fr_var length repeated nop patterns. Besides + being more elegant, this reduces memory required for large .nops + directives. + + * as.h (rs_fill_nop): Update comment. + * config/tc-i386.c (i386_generate_nops): Handle rs_fill_nop as + for rs_align_code. + * config/tc-i386.h (MAX_MEM_FOR_RS_SPACE_NOP): Define. + * listing.c (calc_hex): Handle rs_fill_nop as for rs_fill. + * read.c (MAX_MEM_FOR_RS_SPACE_NOP): Define. + (s_nops): Use MAX_MEM_FOR_RS_SPACE_NOP setting up frag. + * write.c (write_contents): Call md_generate_nops for rs_fill_nop + before the fr_fix part is written, so that rs_fill_nop can be + handled as for rs_fill. + +2025-05-22 Alan Modra + + Re: gas .align limit + Now that rs_align_code has been corrected for all targets, put the + .align limit back to bits_per_address-1. Also fix a comment. + + * frags.h (fr_var): Correct comment. + * read.c (TC_ALIGN_LIMIT): Revert commit ff4c03516c change. + +2025-05-22 Alan Modra + + tidy x86 HANDLE_ALIGN + Reduce memory requirement for .align in code. + + I've changed some of the tests to use "clc" rather than "nop", so that + code emitted by .p2align can be clearly seen. + + * config/tc-i386.c (i386_output_nops): Merge into.. + (i386_generate_nops): ..here. Put shorter nop first. For + rs_align_code make use of the fact that the last fr_var bytes + are output repeatedly rather than repeating them here. + * config/tc-i386.h (HANDLE_ALIGN): Don't test max_bytes. + (MAX_MEM_FOR_RS_ALIGN_CODE): Update. + * testsuite/gas/i386/nops-1.s, + * testsuite/gas/i386/nops-2.s, + * testsuite/gas/i386/nops-3.s, + * testsuite/gas/i386/nops-4.s, + * testsuite/gas/i386/nops16-1.s: Replace "nop" with "clc". + * testsuite/gas/i386/align-branch-6.d, + * testsuite/gas/i386/nop-1-suffix.d, + * testsuite/gas/i386/nop-1.d, + * testsuite/gas/i386/nop-1.l, + * testsuite/gas/i386/nop-2.d, + * testsuite/gas/i386/nop-4.d, + * testsuite/gas/i386/nop-5.d, + * testsuite/gas/i386/nops-1-core2.d, + * testsuite/gas/i386/nops-1.d, + * testsuite/gas/i386/nops-10.d, + * testsuite/gas/i386/nops-2.d, + * testsuite/gas/i386/nops-3.d, + * testsuite/gas/i386/nops-4.d, + * testsuite/gas/i386/nops-4a-i686.d, + * testsuite/gas/i386/nops-5.d, + * testsuite/gas/i386/nops-6.d, + * testsuite/gas/i386/nops-7.d, + * testsuite/gas/i386/nops-9.d, + * testsuite/gas/i386/nops16-1.d, + * testsuite/gas/i386/x86-64-align-branch-6.d, + * testsuite/gas/i386/x86-64-nop-1.d, + * testsuite/gas/i386/x86-64-nop-5.d, + * testsuite/gas/i386/x86-64-nops-1-core2.d, + * testsuite/gas/i386/x86-64-nops-1-pentium.d, + * testsuite/gas/i386/x86-64-nops-1.d, + * testsuite/gas/i386/x86-64-nops-2.d, + * testsuite/gas/i386/x86-64-nops-3.d, + * testsuite/gas/i386/x86-64-nops-4-core2.d, + * testsuite/gas/i386/x86-64-nops-4.d, + * testsuite/gas/i386/x86-64-nops-5.d, + * testsuite/gas/i386/x86-64-nops-6.d, + * testsuite/gas/i386/x86-64-nops-7.d: Adjust to suit. + +2025-05-22 Alan Modra + + tidy target HANDLE_ALIGN + avr, kvx, metag, mn10300, nds32, v850, visium, and wasm32 targets + defined HANDLE_ALIGN without defining MAX_MEM_FOR_RS_ALIGN_CODE. This + can result in a rather large chunk of memory being allocated. Fix + that by a combination of changing the default allocation to one byte + and/or defining a target MAX_MEM_FOR_RS_ALIGN_CODE. + + arm wanted to write out the entire set of nops, and limited allowed + code alignment to 64 bytes to prevent large memory allocations. + Fix that by making use of the fact that rs_align_code frags repeat + fr_var bytes at fr_literal + fr_fix to fill out the required area. + Fix metag, nds32 and kvx too, which it seems copied either arm or x86 + in similarly not making use of repeating patterns. + + It's worth mentioning that my tidy to kvx changed the order of nop + bundles, placing a short bundle first rather than last. + + epiphany was totally broken in that uninitialised data was written out + for any alignment requiring more than three bytes of fill. + + ppc created a new frag to handle a branch over a large number of nops. + This saves 4 bytes per rs_align_code frag, and most times the branch + isn't used so it is generally a win for memory usage, but I figured + the extra code complexity wasn't worth it. So that code of mine goes. + visium copied the same scheme, so that goes too. + + This leaves x86 as the only target making large allocations for + alignment frags. + + * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Default to 1. + * config/tc-aarch64.c (aarch64_handle_align): Remove always true + condition. + * config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Move to be + adjacent to HANDLE_ALIGN define. + * config/tc-arm.c (arm_handle_align): Allow alignment of more + than MAX_MEM_FOR_RS_ALIGN_CODE bytes. Just write one repeat + of nop pattern to frag. + (arm_frag_align_code): Delete function. + * config/tc-arm.h (MAX_MEM_ALIGNMENT_BYTES): Don't define. + (MAX_MEM_FOR_RS_ALIGN_CODE): Set to 7. + (md_do_align): Don't define. + (arm_frag_align_code): Don't declare. + * config/tc-epiphany.c (epiphany_handle_align): Correct frag + so that nop_pattern repeats rather than random data. + * config/tc-epiphany.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. + * config/tc-kvx.c (kvx_make_nops): Merge into.. + (kvx_handle_align): ..here. Put short nop bundle first, + followed by repeated full nop bundle. + * config/tc-kvx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. + * config/tc-m32c.h (HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE): + Don't define. + * config/tc-metag.c (metag_handle_align): Just write one + repeat of nop pattern to frag. + * config/tc-metag.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. + * config/tc-nds32.c (nds32_handle_align): Just write one + repeat of nop pattern to frag. + * config/tc-nds32.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. + * config/tc-ppc.c (ppc_handle_align): Don't make a new frag + for branch. + * config/tc-ppc.h (MAX_MEM_FOR_RS_ALIGN_CODE): Increase to 8. + * config/tc-visium.c (visium_handle_align): Don't make a new + frag for branch. + * config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. + * config/tc-wasm32.h (HANDLE_ALIGN): Don't define. + * testsuite/gas/epiphany/nop.d, + * testsuite/gas/epiphany/nop.s: New test. + * testsuite/gas/epiphany/allinsn.exp: Run it. + * testsuite/gas/kvx/nop-align.d: Adjust. + +2025-05-22 Andrew Burgess + + gdb: reorder checks in validate_exec_file + While reviewing another patch I was briefly confused by a call to + target_pid_to_exec_file coming from validate_exec_file while attaching + to a process when I had not previously set an executable. + + The current order of actions in validate_exec_file is: + + 1. Get name of current executable. + 2. Get name of executable from the current inferior. + 3. If either of (1) or (2) return NULL, then there's nothing to + check, early return. + + I think it would be cleaner if we instead did this: + + 1. Get name of current executable. + 3. If (1) returned NULL then there's nothing to check, early return. + 3. Get name of executable from the current inferior. + 4. If (3) returned NULL then there's nothing to check, early return. + + This does mean there's an extra step, but I don't think the code is + any more complex really, and we now avoid trying to extract the name + of the executable from the current inferior unless we really need it. + This avoids the target_pid_to_exec_file call that I was seeing, which + for remote targets does avoid a packet round trip (not that I'm + selling this as an "optimisation", just noting the change). + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-22 Tom Tromey + + Ensure cooked_index_entry self-tests are run + While looking at code coverage for gdb, I noticed that the + cooked_index_entry self-tests were not run. I tracked this down to a + formatting error in cooked-index-entry.c. + + I suspect it might be better to use a macro to define these + initialization functions. That would probably remove the possibility + for this kind of error. + +2025-05-22 Vladimir Mezentsev + + gprofng: fix 32892 source line level information not available with "-g -O2" + gprofng did not read the .debug_rnglists section for dwarf-5. + Another problem was that gprofng ignored DW_AT_abstract_origin + As a result, gprofng skiped Dwarf for all functions declared as: + <1>: Abbrev Number: 43 (DW_TAG_subprogram) + DW_AT_abstract_origin: <0xe168> + DW_AT_linkage_name: _ZN10Bool_ArrayD2Ev + + gprofng/ChangeLog + 2025-05-19 Vladimir Mezentsev + + PR 32892 + * src/Dwarf.cc: Read the .debug_rnglists section. + Support DW_AT_abstract_origin. + * src/Dwarf.h: Likewise. + * src/DwarfLib.cc: Likewise. + * src/DwarfLib.h: Likewise. + * src/LoadObject.cc (dump_functions): Print mangled names for aliases. + * src/Stabs.cc (fixSymtabAlias): Set 'alias' correctly. + * src/Symbol.cc (find_symbols): Add argument where to collect symbols. + * src/Symbol.h: Likewise. + +2025-05-22 Jiawei + + RISC-V: Add support for Smcdeleg and Ssccfg extensions. + This patch rebases the original patch from Nelson's implement[1]. + + Added new extension Smcdeleg and Ssccfg with a new CSR, scountinhibit.[2] + + Co-Authored-By: Nelson Chu + Co-Authored-By: Jiawei Chen + + [1] https://patchwork.sourceware.org/project/binutils/patch/20240620045359.47513-1-nelson@rivosinc.com/ + [2] https://github.com/riscvarchive/riscv-smcdeleg-ssccfg/releases/tag/v1.0.0 + + bfd/ChangeLog: + + * elfxx-riscv.c: New extensions. + + gas/ChangeLog: + + * NEWS: Mention new extensions. + * config/tc-riscv.c (enum riscv_csr_class): New CSR class. + (riscv_csr_address): Add support for Ssccfg. + * testsuite/gas/riscv/csr-version-1p10.d: New test for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p10.l: New warning for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p11.d: New test for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p11.l: New warning for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p12.d: New test for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p12.l: New warning for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p13.d: New test for Ssccfg CSR. + * testsuite/gas/riscv/csr-version-1p13.l: New warning for Ssccfg CSR. + * testsuite/gas/riscv/csr.s: New Ssccfg CSR. + * testsuite/gas/riscv/imply.d: New imply check. + * testsuite/gas/riscv/imply.s: New implies. + * testsuite/gas/riscv/march-help.l: New helping info. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_SCOUNTINHIBIT): New CSR address. + (DECLARE_CSR): Add Ssccfg CSR. + +2025-05-22 Lulu Cai + + LoongArch: Warning about incorrect 3rd argument of .align + 344b1e0f5f7 Introduced range-check 3rd argument of .align, incorrect + value are not converted silently. added warning message to fix regression. + +2025-05-22 GDB Administrator + + Automatic date update in version.in + +2025-05-22 Alan Modra + + ubsan: integer overflow in tc-i386.c:offset_in_range + or $9223372036854775808,%eax + runtime error: negation of -9223372036854775808 cannot be represented + in type 'offsetT' (aka 'long'); cast to an unsigned type to negate + this value to itself + + * config/tc-i386.c (offset_in_range): Avoid signed overflow. + +2025-05-21 Tom Tromey + + Minor spelling fixes in gdb directory + I ran codespell on the gdb directory and fixed a number of minor + problems. In a couple cases I replaced a "gdb spelling" (e.g., + "readin") with an English one ("reading") where it seemed harmless. + + I also added "Synopsis" as an accepted spelling. + + gdb is nowhere near codespell-clean. + + Approved-By: Tom de Vries + +2025-05-21 GDB Administrator + + Automatic date update in version.in + +2025-05-20 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh + I forgot to run test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp with + make-check-all.sh, and consequently failed to notice that it fails with for + instance target board fission-dwp. + + The test-case does: + ... + source $srcdir/$subdir/dw-form-strx.exp.tcl + ... + and in that tcl file, prepare_for_testing fails, so a -1 is returned, but + that is ignored by the source command. + + Fix this by using require, but rather that testing the result of the source + command, communicate success by setting a global variable + prepare_for_testing_done. + + Likewise in gdb.dwarf2/dw-form-strx.exp. + + Also, the test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp fails for target + board readnow, because the DWARF error occurs during a different command than + expected. + + Fix this by just skipping the test-case in that case. + + Tested on x86_64-linux. + + Reported-by: Simon Marchi + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.debuginfod codespell-clean + Make gdb.debuginfod codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.guile codespell-clean + Make gdb.guile codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.mi codespell-clean + Make gdb.mi codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.opt codespell-clean + Make gdb.opt codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.pascal codespell-clean + Make gdb.pascal codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.reverse codespell-clean + Make gdb.reverse codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.rocm codespell-clean + Make gdb.rocm codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.stabs codespell-clean + Make gdb.stabs codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.xml codespell-clean + Make gdb.xml codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Make gdb.tui codespell-clean + Make gdb.tui codespell-clean and add the dir to the pre-commit + configuration. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [gdb/testsuite] Fix gdbsever typo + I noticed a typo in the testsuite, twice: gdbsever. Fix these. + + Codespell doesn't detect it, so add a new file + gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver + entry, and update gdb/contrib/setup.cfg to use it. + + Approved-By: Tom Tromey + +2025-05-20 Tom de Vries + + [pre-commit] Add codespell-clean gdb/testsuite dirs + The following gdb/testsuite subdirs are codespell-clean: + ... + $ for d in gdb/testsuite/gdb.*; do \ + echo -n "$d:"; \ + codespell --config ./gdb/contrib/setup.cfg $d \ + | wc -l; \ + done 2>&1 \ + | grep :0 + gdb/testsuite/gdb.ctf:0 + gdb/testsuite/gdb.dap:0 + gdb/testsuite/gdb.gdb:0 + gdb/testsuite/gdb.go:0 + gdb/testsuite/gdb.modula2:0 + gdb/testsuite/gdb.objc:0 + gdb/testsuite/gdb.opencl:0 + gdb/testsuite/gdb.perf:0 + gdb/testsuite/gdb.replay:0 + gdb/testsuite/gdb.server:0 + gdb/testsuite/gdb.testsuite:0 + ... + + Add them to the pre-commit configuration. + + Approved-By: Tom Tromey + +2025-05-20 Andreas Schwab + + libiberty: sync with gcc + Import the following commits from GCC as of r16-614-g9d039eff453f77: + 31dd621796f libiberty: add ldirname function + f3d07779fdb libiberty: Append to AC_CHECK_DECLS [PR119218]. + 90183362524 libiberty, gcc: Add memrchr to libiberty and use it [PR119283]. + 43717ee9064 libiberty: Fix off-by-one when collecting range expression + +2025-05-20 Alan Modra + + ubsan: undefined shift in loongarch_elf_add_sub_reloc_uleb128 + An oss-fuzz testcase found: + runtime error: shift exponent 140 is too large for 32-bit type 'int' + OK, that's just a completely silly uleb, but we ought to be able to + handle 64 bits here. + + * elfxx-loongarch.c (loongarch_elf_add_sub_reloc_uleb128): Formatting. + Don't left shift int. Avoid shifts larger than bits in a bfd_vma. + +2025-05-20 GDB Administrator + + Automatic date update in version.in + +2025-05-19 Dimitar Dimitrov + + sim: testsuite: Fix build with host GCC15 + Simulator testsuite build started failing with host GCC-15: + + bits-tst.c:323:1: error: function declaration isn’t a prototype [-Werror=strict-prototypes] + bits-tst.c: In function ‘main’: + bits-tst.c:323:1: error: old-style function definition [-Werror=old-style-definition] + + Fix by including string.h to get the required prototypes, and changing + main's declaration to modern C. + + Approved-By: Tom Tromey + +2025-05-19 Alan Modra + + ubsan: integer overflow in s_fill + Silence ubsan warning. We don't worry about wrap-around in most + places that adjust abs_section_offset, so don't fuss over an overflow + in the multiplication here. + + * read.c (s_fill): Replace "long" vars with offsetT and valueT. + Avoid signed overflow calculating abs_section_offset. + +2025-05-19 Tsukasa OI + + RISC-V: Add implication from the XTheadZvamo extension + T-Head/XuanTie's vector extension documentation states that their vector + extensions are based on the standard vector extension draft, + version 0.7.1. + + In that draft, it is rare to see dependencies between extensions as + in the ratified version ... except: "Zvamo" -> "Zaamo". + + cf. + + > If vector AMO instructions are supported, then the scalar Zaamo + > instructions (atomic operations from the standard A extension) + > must be present. + + Note that using the words like "imply" or "depend" for extensions + weren't a common practice to represent dependencies between extensions + at the time the documentation was created. + + The "Zaamo" was not ratified as an extension at the time but this is a + subset of the "A" extension and defines scalar AMO operations (while + "Zvamo" -- NOT in the ratified specification -- defines vector AMO ops). + + The important part is that the T-Head/XuanTie's documentation just + states that the "Zvamo" (draft) extension is renamed to "XTheadZvamo". + It means, this implication should have been preserved in some way. + + > The extension Zvamo is renamed to XTheadZvamo. + + cf. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): Add implication + "XTheadZvamo" -> "Zaamo". + + gas/ChangeLog: + + * testsuite/gas/riscv/imply.s: Add "XTheadZvamo" implication. + * testsuite/gas/riscv/imply.d: Ditto. + +2025-05-19 Tsukasa OI + + RISC-V: Add implicit dependency to the XTheadVector extension + While this dependency is not directly stated in the documentation, + the XTheadVector extension cannot work without the Zicsr extension + (the documentation does not specify CSR access instruction subset + either as in the Zkr extension or the seed CSR section in the manual). + + Also, making an implication to the Zicsr extension is in parity with + the ratified vector extensions (in GNU Binutils, the Zve32x extension -- + a dependency of V -- depends on the Zvl32b and Zicsr extensions). + + This commit adds this implicit dependency. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): Add implicit + dependency "XTheadVector" -> "Zicsr". + + gas/ChangeLog: + + * testsuite/gas/riscv/imply.s: Add implicit "XTheadVector" + dependency to the "Zicsr" extension. + * testsuite/gas/riscv/imply.d: Ditto. + +2025-05-19 Tsukasa OI + + RISC-V: Wider conflicts with the XTheadVector extension + T-Head/XuanTie's "XTheadVector" is based on a draft version of the now + standard vector extensions and it conflicts with not just the "V" + extension but all of its subsets. + + This commit makes "XTheadVector" conflict with the "Zve32x" extension, + which is the smallest subset of the standard vector extensions. Still, + a reference to "V" is preserved in the error message + as the documentation suggests: + + > Therefore, the XTheadVector extension and the V extension are + > in conflict. + + cf. + + Note that, instructions in the "XTHeadZvamo" extension currently has + no conflicts with other extensions, even after addition of the "Zabha" + extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_parse_check_conflicts): + Make "XTheadVector" conflict with not just "V" but its subsets. + + gas/ChangeLog: + + * testsuite/gas/riscv/x-thead-vector-fail.d: Test a vector + subset "Zve32x" to test failures. + * testsuite/gas/riscv/x-thead-vector-fail.l: Reflect change + in the error message. + +2025-05-19 Jens Remus + + s390: Simplify test for absolute symbol + Simplify the test whether a symbol is absolute, by using the helper + bfd_is_abs_symbol. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Use + bfd_is_abs_symbol to test whether symbol is absolute. + +2025-05-19 Jens Remus + + s390: Prevent GOT access rewrite for misaligned symbols + Dereferences of GOT slots with lgrl or lg for global symbols are + rewritten to larl to get get rid of the extra memory access. However + this is invalid for: + + - symbols marked for absolute addressing + - symbols at odd addresses (larl can handle only even addresses) + + Commit e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain + symbols") added checks for the above. But instead of checking the + address of a symbol for being halfword aligned, it tries to deduce + this from whether the symbol value and section the symbol is defined + in are halfword aligned. The way it is done has two issues: + + 1. The use of bfd_section_from_elf_index to obtain the section the + symbol is defined in may not return the one that remains in the + output. For instance for COMDAT sections getting deduplicated + the section retrieved using bfd_section_from_elf_index may not be + the same as h->root.u.def.section. If COMDAT sections of same + group signature have different alignment properties the wrong + one may be checked. This may then lead to an erroneous rewrite + of lgrl %rX, sym@GOTENT to larl %rX, sym, although the symbol in + the remaining section is not properly aligned, triggering an + "relocation for misaligned symbol" error at link-time. + + This may for instance occur when mixing C++ modules compiled with + GCC and Clang, as GCC emits a 2-byte alignment and Clang a 1-byte + alignment for COMDAT sections containing type information: + + $ cat sample.cpp + #include + struct A {}; + const std::type_info &q() { return typeid(A); } + + $ g++ -c sample.cpp -o sample_gcc.o + $ clang++ -c sample.cpp -o sample_clang.o + $ readelf -WS sample_gcc.o sample_clang.o + + Produces (reformatted and reduced): + File Name Off Size ES Flg Lk Inf Al + sample_gcc.o .rodata._ZTS1A 000080 000004 00 AG 0 0 2 + sample_clang.o .rodata._ZTS1A 000058 000003 00 AG 0 0 1 + + 2. The symbol may end up at an even address, if both the symbol value + and the section defining the symbol are 1-byte aligned. While this + does not trigger an error, it fails an opportunity to rewrite a GOT + access. + + In a Linux Kernel build this causes ~15k GOT accesses using lgrl to + be skipped to be rewritten to larl. + + Resolve both issues by simply checking whether the symbol address is + halfword aligned. Do not check the symbol value nor section defining + the symbol for halfword alignment. + + bfd/ + PR ld/32969 + * elf64-s390.c (elf_s390_relocate_section): Only rewrite + lgrl/lg from GOT to larl if symbol address is halfword aligned. + + ld/testsuite/ + PR ld/32969 + * ld-s390/s390.exp (pr32969_64-1, pr32969_64-2): Add tests for + rewrite of GOT access when COMDAT section deduplication is + involved. + * ld-s390/pr32969_64-1.dd: New test for rewrite of GOT access + when COMDAT section deduplication is involved. + * ld-s390/pr32969_64-2.dd: Likewise. + * ld-s390/pr32969a.s: Likewise. + * ld-s390/pr32969b.s: Likewise. + * ld-s390/pr32969c.s: Likewise. + + Bug: https://sourceware.org/PR32969 + Fixes: e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain symbols") + Reported-by: Ilya Leoshkevich + +2025-05-19 Jens Remus + + s390: Improve diagnostic for reloc against misaligned sym + Report the BFD in which a misaligned symbol is defined in the error + message. This complements commit 906f69cf65da ("IBM zSystems: Issue + error for *DBL relocs on misaligned symbols"). While at it reword + the error message. + + Old error message text (re-wrapped): + (+): misaligned symbol `' () for + relocation + + New error message text (re-wrapped): + (+): relocation against misaligned symbol + `' () in + + Note that the linker tests do not require to be updated, as they match + against the pattern ".*misaligned symbol.*", which has not changed in + the error message. + + bfd/ + PR ld/32969 + * elf64-s390.c (elf_s390_relocate_section): Report BFD + in which a misaligned symbol is defined in error message. + + Bug: https://sourceware.org/PR32969 + Suggested-by: Ilya Leoshkevich + +2025-05-19 Indu Bhagat + + gas: sframe: handle .cfi_undefined + Fix PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas + + In context of SFrame generation, it is incorrect to simply ignore all + .cfi_undefined. We may ignore only those .cfi_undefined which are for + registers of no interest (similar to whats done for other CFI + directives). + + gas/ + * gen-sframe.c (sframe_xlate_do_cfi_undefined): New definition. + (sframe_do_cfi_insn): Handle .cfi_undefined. + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Add new tests. + * gas/cfi-sframe/cfi-sframe-common-10.d: New test. + * gas/cfi-sframe/cfi-sframe-common-10.s: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-4.s: New test. + +2025-05-19 Indu Bhagat + + gas: sframe: reword diagnostic to address ambiguity + The current warning text of "skipping SFrame FDE" does not unabiguously + indicate that the SFrame FDE is not generated in the output section. + Reword the diagnostic to say "no SFrame FDE emitted" as requested. + + Adjust the testcases for the updated warning. + +2025-05-19 Indu Bhagat + + gas: sframe: i386: have the backend specify the RA too + To process some CFI directives like .cfi_undefined and .cfi_same_value, + it is necessary for correctness to detect all cases when the register + used is one of SP, FP or RA. + + Currently, the backends needed to specify the SFRAME_CFA_RA_REG only in + the case of those ABIs where RA tracking was necessary, e.g. AArch64. + For AMD64, since the return address is always at a fixed offset from the + CFA, RA tracking was disabled. + + The backends must now specify the applicable return address register via + SFRAME_CFA_RA_REG. This is necessary so that SFrame generation code can + then properly handle the cases when RA is used like so: + .cfi_undefined + or, + .cfi_same_value + + Detecting these cases is necessary for correctness. E.g., on AMD64, we + need to skip FDE generation as the above constructs cannot be + represented in SFrame yet. + + This change is a prerequisite to fixing the two PRs: + + PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas + PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas + + In the SFrame generation code in gen-sframe.c, instead of using + SFRAME_FRE_RA_TRACKING ifdef's, we now simply rely on the API + sframe_ra_tracking_p () to detect if RA-tracking is enabled for the + target. + + While at it, use const variables for x86 backend. + + ChangeLog: + + * gas/config/tc-i386.c (x86_sframe_cfa_ra_reg): New definition. + * gas/config/tc-i386.h (REG_RA): New definition. + (SFRAME_CFA_RA_REG): New declaration. + * gas/gen-sframe.c (SFRAME_FRE_RA_TRACKING): Remove. + +2025-05-19 GDB Administrator + + Automatic date update in version.in + +2025-05-18 Christina Schimpe + + bfd: Handle note of type NT_X86_SHSTK + +2025-05-18 GDB Administrator + + Automatic date update in version.in + +2025-05-17 GDB Administrator + + Automatic date update in version.in + +2025-05-16 Tom Tromey + + Update comment for find_field_create_baton + Andrew pointed out that a recent commit neglected to update the + comment for find_field_create_baton. This patch fixes the oversight. + +2025-05-16 Alan Modra + + ubsan: emit_inc_line_addr integer overflow + Commit 07cf922195d1 fixed the one in size_inc_line_addr. Silly me + missed the identical overflow in emit_inc_line_addr + +2025-05-16 Alan Modra + + gas .align limit + At the moment we allow alignment of up to half the address space, + which is stupidly large and results in OOM on x86_64. Change that to + 1G alignment in text sections. Also fix the warning message on + exceeding max allowed alignment. + + * read.c (TC_ALIGN_LIMIT): Limit to 30 in text sections. + (s_align): Correct "alignment too large" value. + +2025-05-16 Alan Modra + + ld testsuite fail with --disable-plugins + * testsuite/config/default.exp (dep_plug_opt): Don't set unless + check_plugin_api_available returns true. + +2025-05-16 Jan Beulich + + gas: adjust a comparison in s_align() + In 344b1e0f5f79 ("gas: range-check 3rd argument of .align et al") I + neglected to consider compilers which warn about signed/unsigned + mismatches in comparisons (which is somewhat odd when the signed value is + already known to be non-negative). + + gas: range-check 3rd argument of .align et al + Negative values would have been silently converted to large positive + ones, which may not be the user's intention. Similarly overly large + values would have been silently truncated. Warn them instead, and zap + such values. + +2025-05-16 Collin Funk + + ld/doc: Remove '.info' suffix in @ref, etc + Texinfo 7.2 began showing warnings like: + + ld.texi:1026: warning: do not set .info suffix in reference for manual `gcc.info' + ld.texi:9689: warning: do not set .info suffix in reference for manual `binutils.info' + + The Texinfo developers plan to stop removing the '.info' suffix + internally in a future release so without this patch the references will + break in the future. + +2025-05-16 Collin Funk + + binutils/doc: Remove '.info' suffix in @ref, etc + Texinfo 7.2 began showing warnings like: + + binutils.texi:882: warning: do not set .info suffix in reference for manual `ld.info' + binutils.texi:1365: warning: do not set .info suffix in reference for manual `ld.info' + + The Texinfo developers plan to stop removing the '.info' suffix + internally in a future release so without this patch the references will + break in the future. + +2025-05-16 Jan Beulich + + x86: improve matching diagnostics when %st is involved + Diagnosing operand size vs operand type mismatches doesn't work very + well when GPRs and FPRs are in the same register class, distinguished + just by size. Introduce a separate RegFP class. + + x86: move Anysize check in operand_size_match() + Anysize is applicable to memory operands only. Move the check to where + memory operands are handled. (The RegSIMD part there was questionable + altogether.) + + x86: improve matching diagnostics when "accumulator" registers are involved + In templates, the expectation of an "accumulator" register to be used is + expressed solely by operand size; there's no "class" specifier there. + Hence operand_size_match() is too eager in invoking + match_{operand,simd}_size(), resulting in "operand size mismatch" errors + when it's the type (of register), not the size that's wrong. + Interestingly adjustments there alone lead to no error at all then: To + "compensate", operand_type_match() needs to disambiguate register types + when register instances are specified in the template (matching the + actual operand), by checking a match (overlap) in operand sizes. + + x86: fold Accum checking in operand_size_match() + There's little point invoking match_{operand,simd}_size() twice per + loop; in fact the SIMD case with D set simply doesn't exist. Amend the + checks by one looking at the given operand, just like we already have + been doing for memory ones. + +2025-05-16 Jan Beulich + + x86: improve matching diagnostics + Many times in the past I was puzzled by seeing "operand size mismatch" + when really "operand type mismatch" would be far more appropriate. As it + turns out, there were at least two flaws: In the single operand case we + didn't propagate i.error to match_template()'s local specific_error when + noticing a type mismatch. And then operand_size_match() was too eager in + invoking match_mem_size(): Especially the Unspecified attribute can get + in the way there when the expected operand isn't a memory one (and hence + Unspecified would not be set in the operand template, whereas it's + uniformly set for memory operands in AT&T syntax). + + (In the x86-64-lkgs-inval testcase the particular error for the two + bogus Intel syntax forms doesn't really matter; all we ought to care + about there isthat there is _some_ error.) + +2025-05-16 Jan Beulich + + x86: drop bogus accumulator check + Accum is an "instance", not a "class". With present enumerator values of + Reg and Accum, the 2nd check simply did the same as the first. In fact + checking for the accumulator (%rax) isn't necessary here at all, because + there's no case where an individual template would permit alternatively + a memory operand or the (qword) accumulator; only "any GPR" is ever + being paired with "memory". + +2025-05-16 Tsukasa OI + + RISC-V: check offsets when linker relaxation is disabled + The assembler partially relied on the linker to check whether the + offset is valid. However, some optimization logic (added later) + removes relocations relative to local symbols without checking offsets. + + For instance, it caused following code to silently emit wrong jumps + (to the jump instruction "." itself) without relocations: + + > .option norelax + > j .+0x200000 # J (or JAL) instruction cannot encode this offset. + > j .+1 # Jump to odd address is not valid. + + This commit adds offset checks where necessary. + + gas/ChangeLog: + + * config/tc-riscv.c (md_apply_fix): Check offsets when the + relocation relative to a local symbol is being optimized out. + * testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure + case where the branch offset is invalid. + * testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto. + * testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto. + * testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case. + * testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto. + * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure + case only on RV64 where the PC-relative offset exceed limits. + * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto. + * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto. + * testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test + case for RV32 so that no errors occur. + * testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case. + * testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto. + +2025-05-16 dysun + + RISC-V: Add zilsd & zclsd support + Ref: https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc + + + Co-developed-by: LIU Xu + Co-developed-by: ZHAO Fujin + +2025-05-16 GDB Administrator + + Automatic date update in version.in + +2025-05-15 Indu Bhagat + + gas: sframe: avoid creating more symbols than necessary for FRE offset + Each SFrame FDE contains an offset to the start of its respective SFrame + FREs in the sfde_func_start_fre_off field. To generate this offset, + fre_symbols[] array is being used. The number of elements of this array + is currently set to the total number of SFrame FREs in the entire SFrame + section. This is more than unnecessary. We only need to track as many + points as the number of SFrame FDEs. + + gas/ + * gen-sframe.c (output_sframe_internal): Size fde_fre_symbols + with the number of SFrame FDEs. + +2025-05-15 Tom Tromey + + Fix regression with dynamic array bounds + Kévin discovered that commit ba005d32b0f ("Handle dynamic field + properties") regressed a test in the internal AdaCore test suite. + + The problem here is that, when writing that patch, I did not consider + the case where an array type's bounds might come from a member of a + structure -- but where the array is not defined in the structure's + scope. + + In this scenario the field-resolution logic would trip this condition: + + /* Defensive programming in case we see unusual DWARF. */ + if (fi == nullptr) + return nullptr; + + This patch reworks this area, partly backing out that commit, and + fixes the problem. + + In the new code, I chose to simply duplicate the field's location + information. This isn't totally ideal, in that it might result in + multiple copies of a baton. However, this seemed nicer than tracking + the DIE/field correspondence for every field in every CU -- my + thinking here is that this particular dynamic scenario is relatively + rare overall. Also, if the baton cost does prove onerous, we could + intern the batons somewhere. + + Regression tested on x86-64 Fedora 41. I also tested this using the + AdaCore internal test suite. + + Tested-By: Simon Marchi + +2025-05-15 Andreas Schwab + + ld: rename ldirname to stat_ldirname + It conflicts with the ldirname function that will be added in the next + libiberty sync. + + ld/: + * ldlang.c (stat_ldirname): Rename from ldirname, all uses + changed. + +2025-05-15 Andreas Schwab + + gdb: rename ldirname to gdb_ldirname + It conflicts with the ldirname function that will be added in the next + libiberty sync. + +2025-05-15 H.J. Lu + + binutils: Don't complain plugin with all LTO sections removed + When all LTO sections have been removed, the BFD lto_type is set to + lto_non_ir_object by bfd_set_lto_type. In this case, don't complain + needing a plugin when seeing a LTO slim symbol. + + bfd/ + + PR binutils/32967 + * archive.c (_bfd_compute_and_write_armap): Call + bfd_lto_slim_symbol_p to check LTO slim symbol. + * bfd-in2.h: Generated. + * bfd.c (bfd_lto_slim_symbol_p): New. + + binutils/ + + PR binutils/32967 + * nm.c (filter_symbols): Call bfd_lto_slim_symbol_p to check + LTO slim symbol. + + ld/ + + PR binutils/32967 + * testsuite/ld-plugin/lto-binutils.exp: Run PR binutils/32967 + tests. + * testsuite/ld-plugin/strip-1a-s-all.nd: New file. + +2025-05-15 GDB Administrator + + Automatic date update in version.in + +2025-05-15 Alan Modra + + gas .file 0 vs. dwarf5 + Support added in commit 3417bfca676f for dwarf5 directory table 0 + assumed that .file 0 was always the first debug .file directive. + That's not necessarily true. + + * dwarf2dbg.c (get_directory_table_entry): Don't assume entry + 1 is available after putting DW_AT_comp_dir in entry 0. Pass + pwd as file0_dirname to recursive call to avoid another + getpwd in the case file0_dirname is NULL. + +2025-05-14 Rohr, Stephan + + testsuite: fix gdb_exit for MinGW target + GDB is not properly exited via 'remote_close host' when running the + testsuite in a MinGW environment. Use the 'quit' command to properly + exit the GDB debugging session. + + Approved-By: Tom Tromey + +2025-05-14 Rohr, Stephan + + testsuite: get windows PID on MinGW target + Also translate the MinGW PID to the Windows PID when running on a MinGW + target. + + Approved-By: Tom Tromey + +2025-05-14 Tom Tromey + + Fix create_breakpoint_parse_arg_string self-test + The emoji patch broke the create_breakpoint_parse_arg_string self-test + when gdb is running on a suitable terminal. The problem is that the + test case doesn't take the error prefix string into account. + + This patch fixes the test by having it compare the exception message + directly, rather than relying on the result of exception_print. I did + try a different approach, of having the test mimic exception_print, + but this one seemed cleaner to me. + + Approved-By: Simon Marchi + +2025-05-14 Tom Tromey + + Add initializers to field_of_this_result + This adds initializers to field_of_this_result, so that certain spots + don't have to memset it. This approach seems safer and cleaner. + + Approved-By: Simon Marchi + +2025-05-14 Tom Tromey + + Fix some pre-commit nits in gdb/__init__.py + I noticed that pre-commit has some complaints (flake8 and codespell) + about gdb/__init__.py. This patch fixes these. + + Approved-By: Tom de Vries + +2025-05-14 Alan Modra + + resbin: don't pass NULL as printf %s arg + Fix three place where a NULL could be passed to "toosmall". + +2025-05-14 Alan Modra + + gas .file sanity check + Currently we allow insane file numbers that cause gas to allocate up + to 4G of memory for a file array. Trim that a little to 1G (which + still allows insane file numbers up to 33554431), and tidy function + parameter types so that we only need one file number sanity check. + + * dwarf2dbg.c (assign_file_to_slot): Take a valueT file number. + Reduce max files array size. + (allocate_filename_to_slot): Take a valueT file number. + (dwarf2_directive_filename): Don't duplicate file number + sanity check here. + +2025-05-14 Richard Earnshaw + + Remove Marcus Shawcroft from the MAINTAINERS file + Marcus has resigned from the project. + +2025-05-14 H.J. Lu + + ld/testsuite: Use $plug_opt for --plugin option + Use $plug_opt for --plugin usage, instead of running: + + run_host_cmd "$CC_FOR_TARGET" "-print-prog-name=liblto_plugin.so" + + PR binutils/21479 + * testsuite/ld-plugin/lto-binutils.exp (lto_plugin): Removed. + Replace "--plugin $lto_plugin" with $plug_opt. + * testsuite/ld-plugin/lto.exp (lto_plugin): Removed. + Replace "--plugin $lto_plugin" with $plug_opt. + +2025-05-14 Matthieu Longo + + Remove annoying spaces from objcopy.exp + + Remove annoying spaces from bfd/elfxx-aarch64.c + + Remove annoying space from gas/config/obj-elf.c + +2025-05-14 H.J. Lu + + strip: Add GCC LTO IR support + Add GCC LTO IR support to strip by copying GCC LTO IR input as unknown + object file. Don't enable LTO plugin in strip unless all LTO sections + should be removed, assuming all LTO sections will be removed with + -R .gnu.lto_.*. Add linker LTO tests for strip with --strip-unneeded + and GCC LTO IR inputs. + + binutils/ + + PR binutils/21479 + * objcopy.c: Include "plugin-api.h" and "plugin.h". + (lto_sections_removed): New. + (command_line_switch): Add OPTION_PLUGIN. + (strip_options): Likewise. + (strip_usage): Display "--plugin NAME". + (copy_unknown_file): New function. + (copy_unknown_object): Call copy_unknown_file. + (copy_archive): Copy input LTO IR member as unknown object. + (copy_file): Set input target to "plugin" for strip if it is + unset unless all LTO sections should be removed. Copy input + LTO IR file as unknown file. + (strip_main): Call bfd_plugin_set_program_name. Handle + OPTION_PLUGIN. Set lto_sections_removed to true if all GCC + LTO sections should be removed. + * doc/binutils.texi: Document --plugin for strip. + + ld/ + + PR binutils/21479 + * testsuite/ld-plugin/lto-binutils.exp: New file. + * testsuite/ld-plugin/strip-1a-fat.c: Likewise. + * testsuite/ld-plugin/strip-1a-fat.rd: Likewise. + * testsuite/ld-plugin/strip-1b-fat.c: Likewise. + * testsuite/ld-plugin/strip-1b-fat.rd: Likewise. + * testsuite/ld-plugin/strip-1a.c: Likewise. + * testsuite/ld-plugin/strip-1b.c: Likewise. + * testsuite/lib/ld-lib.exp (run_cc_link_tests): Add optional + trailing ld options. + +2025-05-14 Sam James + + ld: fix C23 issue in vers7 test + This test is UNSUPPORTED on arm64 with GCC 15 (which defaults to -std=gnu23) + because it now prototypes "no arguments". + + PR ld/32546 + * ld-elfvers/vers7.c: Fix function definitions for C23. + +2025-05-14 GDB Administrator + + Automatic date update in version.in + +2025-05-13 Alice Carlotti + + aarch64: Replace incorrect comment + The comment explaining the placement of the cfinv entry before the + generic msr entry in the opcode table was incorrect. The issue is + unrelated to the all ones bitmask for cfinv, and is actually due the + large number of architectural aliases of the msr instruction. + +2025-05-13 Andrew Burgess + + gdb/python: new gdb.ParameterPrefix class + This commit adds a new gdb.ParameterPrefix class to GDB's Python API. + + When creating multiple gdb.Parameters, it is often desirable to group + these together under a sub-command, for example, 'set print' has lots + of parameters nested under it, like 'set print address', and 'set + print symbol'. In the Python API the 'print' part of these commands + are called prefix commands, and are created using gdb.Command objects. + + However, as parameters are set via the 'set ....' command list, and + shown through the 'show ....' command list, creating a prefix for a + parameter usually requires two prefix commands to be created, one for + the 'set' command, and one for the 'show' command. + + This often leads to some duplication, or at the very least, each user + will end up creating their own helper class to simplify creation of + the two prefix commands. + + This commit adds a new gdb.ParameterPrefix class. Creating a single + instance of this class will create both the 'set' and 'show' prefix + commands, which can then be used while creating the gdb.Parameter. + + Here is an example of it in use: + + gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE) + + This adds 'set my-prefix' and 'show my-prefix', both of which are + prefix commands. The user can then add gdb.Parameter objects under + these prefixes. + + The gdb.ParameterPrefix initialise method also supports documentation + strings, so we can write: + + gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE, + "Configuration setting relating to my special extension.") + + which will set the documentation string for the prefix command. + + Also, it is possible to support prefix commands that use the `invoke` + functionality to handle unknown sub-commands. This is done by + sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or + 'invoke_show' to handle the 'set' or 'show' prefix command + respectively. + + Reviewed-By: Eli Zaretskii + +2025-05-13 Andrew Burgess + + gdb/guile: generate general description string for parameters + This commit builds on the previous one, and auto-generates a general + description string for parameters defined via the Guile API. This + brings the Guile API closer inline with the Python API. It is worth + reading the previous commit to see some motivating examples. + + This commit updates get_doc_string in guile/scm-param.c to allow for + the generation of a general description string. Then in + gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is + used to generate a suitable default. + + This does invalidate (and so the commit removes) this comment that was + in gdbscm_make_parameter: + + /* If doc is NULL, leave it NULL. See add_setshow_cmd_full. */ + + First, Python already does exactly what I'm proposing here, and has + done for a while, with no issues reported. And second, I've gone and + read add_setshow_cmd_full, and some of the functions it calls, and can + see no reasoning behind this comment... + + ... well, there is one reason that I can think of, but I'll discuss + that more below. + + With this commit, if I define a parameter like this: + + (use-modules (gdb)) + (register-parameter! (make-parameter + "print test" + #:command-class COMMAND_NONE + #:parameter-type PARAM_BOOLEAN)) + + Then, in GDB, I now see this behaviour: + + (gdb) help show print test + Show the current value of 'print test'. + This command is not documented. + (gdb) help set print test + Set the current value of 'print test'. + This command is not documented. + (gdb) + + The two 'This command is not documented.' lines are new. This output + is what we get from a similarly defined parameter using the Python + API (see the previous commit for an example). + + I mentioned above that I can think of one reason for the (now deleted) + comment in gdbscm_make_parameter about leaving the doc field as NULL, + and that is this: consider the following GDB behaviour: + + (gdb) help show style filename foreground + Show the foreground color for this property. + (gdb) + + Notice there is only a single line of output. If I want to get the + same behaviour from a parameter defined in Guile, I might try skipping + the #:doc argument, but (after this commit), if I do that, GDB will + auto-generate some text for me, giving two lines of output (see + above). + + So, next, maybe I try setting #:doc to the empty string, but if I do + that, then I get this: + + (use-modules (gdb)) + (register-parameter! (make-parameter + "print test" + #:doc "" + #:command-class COMMAND_NONE + #:parameter-type PARAM_BOOLEAN)) + + (gdb) help show print test + Show the current value of 'print test'. + + (gdb) + + Notice the blank line, that's not what I wanted. In fact, the only + way to get rid of the second line is to leave the 'doc' variable as + NULL in gdbscm_make_parameter, which, due to the new auto-generation, + is no longer possible. + + This issue also existed in the Python API, and was addressed in + commit: + + commit 4b68d4ac98aec7cb73a4b276ac7dd38d112786b4 + Date: Fri Apr 11 23:45:51 2025 +0100 + + gdb/python: allow empty gdb.Parameter.__doc__ string + + After this commit, an empty __doc__ string for a gdb.Parameter is + translated into a NULL pointer passed to the add_setshow_* command, + which means the second line of output is completely skipped. + + And this commit includes the same solution for the Guile API. Now, + with this commit, and the Guile parameter using an empty '#:doc' + string, GDB has the following behaviour: + + (gdb) help show print test + Show the current value of 'print test'. + (gdb) + + This matches the output for a similarly defined parameter in Python. + +2025-05-13 Andrew Burgess + + gdb/guile: improve auto-generated strings for parameters + Consider this user defined parameter created in Python: + + class test_param(gdb.Parameter): + def __init__(self, name): + super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + self.value = True + + test_param('print test') + + If this is loaded into GDB, then we observe the following behaviour: + + (gdb) show print test + The current value of 'print test' is "on". + (gdb) help show print test + Show the current value of 'print test'. + This command is not documented. + (gdb) help set print test + Set the current value of 'print test'. + This command is not documented. + (gdb) + + If we now define the same parameter using Guile: + + (use-modules (gdb)) + (register-parameter! (make-parameter + "print test" + #:command-class COMMAND_NONE + #:parameter-type PARAM_BOOLEAN)) + + And load this into a fresh GDB session, we see the following: + + (gdb) show print test + Command is not documented is off. + (gdb) help show print test + This command is not documented. + (gdb) help set print test + This command is not documented. + (gdb) + + The output of 'show print test' doesn't make much sense, and is + certainly worse than the Python equivalent. For both the 'help' + commands it appears as if the first line is missing, but what is + actually happening is that the first line has become 'This command is + not documented.', and the second line is then missing. + + The problems can all be traced back to 'get_doc_string' in + guile/scm-param.c. This is the guile version of this function. There + is a similar function in python/py-param.c, however, the Python + version returns one of three different strings depending on the use + case. In contrast, the Guile version just returns 'This command is + not documented.' in all cases. + + The three cases that the Python code handles are, the 'set' string, + the 'show' string, and the general 'description' string. + + Right now the Guile get_doc_string only returns the general + 'description' string, which is funny, because, in + gdbscm_make_parameter, where get_doc_string is used, the one case that + we currently don't need is the general 'description' string. Instead, + right now, the general 'description' string is used for both the 'set' + and 'show' cases. + + In this commit I plan to bring the Guile API a little more inline with + the Python API. I will update get_doc_string (in scm-param.c) to + return either a 'set' or 'show' string, and gdbscm_make_parameter will + make use of these strings. + + The changes to the Guile get_doc_string are modelled on the Python + version of this function. It is also worth checking out the next + commit, which is related, and helps motivate how the changes have been + implemented in this commit. + + After this commit, the same Guile parameter description shown above, + now gives this behaviour: + + (gdb) show print test + The current value of 'print test' is off. + (gdb) help show print test + Show the current value of 'print test'. + (gdb) help set print test + Set the current value of 'print test'. + (gdb) + + The 'show print test' output now matches the Python behaviour, and is + much more descriptive. The set and show 'help' output are now missing + the second line when compared to the Python output, but the first line + is now correct, and I think this is better than the previous Guile + output. + + In the next commit I'll address the problem of the missing second + line. + + Existing tests have been updated to expect the new output. + +2025-05-13 Andrew Burgess + + gdb/python: allow empty gdb.Parameter.__doc__ string + I was recently attempting to create some parameters via the Python + API. I wanted these parameters to appear similar to how GDB handles + the existing 'style' parameters. + + Specifically, I was interested in this behaviour: + + (gdb) help show style filename foreground + Show the foreground color for this property. + (gdb) help set style filename foreground + Set the foreground color for this property. + (gdb) + + Notice how each 'help' command only gets a single line of output. + + I tried to reproduce this behaviour via the Python API and was unable. + + The problem is that, in order to get just a single line of output like + this, the style parameters are registered with a call to + add_setshow_color_cmd with the 'help_doc' being passed as nullptr. + + On the Python side, when parameters are created, the 'help_doc' is + obtained with a call to get_doc_string (python/py-param.c). This + function either returns the __doc__ string, or a default string: "This + command is not documented.". + + To avoid returning the default we could try setting __doc__ to an + empty string, but setting this field to any string means that GDB + prints a line for that string, like this: + + class test_param(gdb.Parameter): + __doc__ = "" + def __init__(self, name): + super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + self.value = True + + test_param('print test') + + Then in GDB: + + (gdb) help set print test + Set the current value of 'print test'. + + (gdb) + + The blank line is the problem I'd like to solve. + + This commit makes a couple of changes to how parameter doc strings are + handled. + + If the doc string is set to an empty string, then GDB now converts + this to nullptr, which removes the blank line problem, the new + behaviour in GDB (for the above `test_param`) is: + + (gdb) help set print test + Set the current value of 'print test'. + (gdb) + + Next, I noticed that if the set/show docs are set to empty strings, + then the results are less than ideal: + + class test_param(gdb.Parameter): + set_doc = "" + def __init__(self, name): + super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + self.value = True + + test_param('print test') + + And in GDB: + + (gdb) help set print test + + This command is not documented. + (gdb) + + So, if the set/show docs are the empty string, GDB now forces these to + be the default string instead, the new behaviour in GDB is: + + (gdb) help set print test + Set the current value of 'print test'. + This command is not documented. + (gdb) + + I've added some additional asserts; the set/show docs should always be + non-empty strings, which I believe is the case after this commit. And + the 'doc' string returned from get_doc_string should never nullptr, + but could be empty. + + There are new tests to cover all these changes. + +2025-05-13 Andrew Burgess + + gdb/python/guile: check for invalid prefixes in Command/Parameter creation + The manual for gdb.Parameter says: + + If NAME consists of multiple words, and no prefix parameter group + can be found, an exception is raised. + + This makes sense; we cannot create a parameter within a prefix group, + if the prefix doesn't exist. And this almost works, so: + + (gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + Python Exception : Could not find command prefix xxx. + Error occurred in Python: Could not find command prefix xxx. + + The prefix 'xxx' doesn't exist, and we get an error. But, if we try + multiple levels of prefix: + + (gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) + + This completes without error, however, we didn't get what we were + maybe expecting: + + (gdb) show print xxx foo + Undefined show print command: "xxx foo". Try "help show print". + + But we did get: + + (gdb) show print foo + The current value of 'print foo' is "off". + + GDB stopped scanning the prefix string at the unknown 'xxx', and just + created the parameter there. I don't think this makes sense, nor is + it inline with the manual. + + An identical problem exists with gdb.Command creation; GDB stops + parsing the prefix at the first unknown prefix, and just creates the + command there. The manual for gdb.Command says: + + NAME is the name of the command. If NAME consists of multiple + words, then the initial words are looked for as prefix commands. + In this case, if one of the prefix commands does not exist, an + exception is raised. + + So again, the correct action is, I believe, to raise an exception. + + The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB + calls lookup_cmd_1 to look through the prefix string and return the + last prefix group. If the very first prefix word is invalid then + lookup_cmd_1 returns NULL, and this case is handled. However, if + there is a valid prefix, followed by an invalid prefix, then + lookup_cmd_1 will return a pointer to the last valid prefix list, and + will update the input argument to point to the start of the invalid + prefix word. This final case, where the input is left pointing to an + unknown prefix, was previously not handled. + + I've fixed gdbpy_parse_command_name, and added tests for command and + parameter creation to cover this case. + + The exact same error is present in the guile API too. The guile + documentation for make-parameter and make-command says the same things + about unknown prefixes resulting in an exception, but the same error + is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've + fixed that too, and added some tests. + +2025-05-13 GDB Administrator + + Automatic date update in version.in + +2025-05-12 Simon Marchi + + gdb/dwarf: skip broken .debug_macro.dwo + Running gdb.base/errno.exp with gcc <= 13 with split DWARF results in: + + $ make check TESTS="gdb.base/errno.exp" RUNTESTFLAGS="CC_FOR_TARGET=gcc-13 --target_board=fission" + (gdb) break -qualified main + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7549: internal-error: locate_dwo_sections: Assertion `!dw_sect->readin' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ... + FAIL: gdb.base/errno.exp: macros: gdb_breakpoint: set breakpoint at main (GDB internal error) + + The assert being hit has been added in 28f15782adab ("gdb/dwarf: read + multiple .debug_info.dwo sections"), but it merely exposed an existing + problem. + + gcc versions <= 13 are affected by this bug: + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 + + Basically, it produces .dwo files with multiple .debug_macro.dwo + sections, with some unresolved links between them. I think that this + macro debug info is unusable, and all we can do is ignore it. + + In locate_dwo_sections, if we detect a second .debug_macro.dwo section, + forget about the previous .debug_macro.dwo and any subsequent one. This + will effectively make it as if the macro debug info wasn't there at all. + + The errno test seems happy with it: + + # of expected passes 84 + # of expected failures 8 + + Change-Id: I6489b4713954669bf69f6e91865063ddcd1ac2c8 + Approved-By: Tom Tromey + +2025-05-12 Simon Marchi + + gdb/dwarf: move loops into locate_dw{o,z}_sections + For a subsequent patch, it would be easier if the loop over sections + inside locate_dwo_sections (I want to maintain some state for the + duration of the loop). Move the for loop in there. And because + locate_dwz_sections is very similar, modify that one too, to keep both + in sync. + + Change-Id: I90b3d44184910cc2d86af265bb4b41828a5d2c2e + Approved-By: Tom Tromey + +2025-05-12 oltolm + + gdb/dap: fix decode_source + The documentation for the Source interface says + + * The path of the source to be shown in the UI. + * It is only used to locate and load the content of the source if no + * `sourceReference` is specified (or its value is 0). + + but the code used `path` first. I fixed it to use `sourceReference` first. + + Approved-By: Tom Tromey + +2025-05-12 Keith Seitz + + [PATCH] Add syscall tests when following/detaching from fork + breakpoints/13457 discusses issues with syscall catchpoints when + following forks, lamenting that there is no coverage for the + various permutations of `follow-fork-mode' and `detach-on-fork'. + + This is an attempt to try and cover some of this ground. Unfortunately + the state of syscall support when detaching after the fork is + very, very inconsistent across various architectures. [I've tested + extensively Fedora/RHEL platforms.] + + Right now, the only reliable platform to run tests on is x86_64/i?86 + for the specific case where we do not detach from the fork. Consequently, + this patch limits testing to those architectures. + + I have updated breakpoints/13457 with my findings on failures with the + detaching case. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457 + Approved-By: Andrew Burgess + +2025-05-12 Ezra Sitorus + + aarch64: Support for FEAT_RME_GPC3 + FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces + a method for defining a set of windows in the memory map for which + Granule Protection Checks are skipped, and instead applies a set of + default settings associated with the window. + + This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to + access this sysreg since this feature is optional from armv9.5-a. + +2025-05-12 Ezra Sitorus + + aarch64: Support for FEAT_OCCMO + FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces + system instructions that provides software with a mechanism to publish + writes to the Outer cache level. + +2025-05-12 Patrick Monnerat + + gdbsupport/event-loop: do not truncate poll timeouts to lower second + In update_wait_timeout function, microseconds were not taken into account + in poll timeout computation, resulting in 100% cpu time consumption in + the event loop while waiting for a sub-second timeout. + + The bug has been introduced in commit c2c6d25. + + This patch adds the microseconds converted to milliseconds in poll + timeout computation. Conversion by excess (ceil) is performed to + avoid the same problem with sub-millisecond timeouts too. + +2025-05-12 Andrew Burgess + + gdb: pass std::string from linux_find_memory_regions_full + Update linux_find_memory_region_ftype to take 'const std::string &' + instead of 'const char *', update the two functions which are passed + as callbacks to linux_find_memory_regions_full. + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-12 Andrew Burgess + + gdb: remove unnecessary function declaration + There's no need to declare a function immediately before its + definition. Lets not do that. + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-12 Andrew Burgess + + gdb: move extra checks into dump_note_entry_p + Now that dump_note_entry_p is always called (see previous commit), we + can move some of the checks out of linux_make_mappings_callback into + dump_note_entry_p. + + The checks only exist in linux_make_mappings_callback because, before + the previous commit, we couldn't be sure that dump_note_entry_p would + be called or not, so linux_make_mappings_callback had to run its own + checks. + + Now that dump_note_entry_p is always called we can rely on that + function to filter out which mappings should result in an NT_FILE + entry, and linux_make_mappings_callback can just create an entry for + everything it is passed. + + As a result of this change I was able to remove the inode argument + from linux_make_mappings_callback and + linux_find_memory_regions_thunk. The inode check has now moved to + dump_note_entry_p. + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-12 Andrew Burgess + + gdb: always call should_dump_mapping_p during core file creation + This commit moves the logic for whether should_dump_mapping_p is + called out of linux_find_memory_regions_full and pushes it down into + the two callback functions that are used as the should_dump_mapping_p + callback; `dump_mapping_p` and `dump_note_entry_p`. + + Older Linux kernels don't make the 'Anonymous' information available + in the smaps file, and currently, GDB handles this by not calling the + should_dump_mapping_p callback in linux_find_memory_regions_full, + instead the answer is hard-coded to true. + + This is (maybe) fine for dump_mapping_p, but for dump_note_entry_p, + this choice makes little sense. The dump_note_entry_p function + doesn't even use the anonymous mapping information. + + I propose that the 'has_anonymous' check should be moved out of + linux_find_memory_regions_full, and pushed into dump_mapping_p. Then + in dump_note_entry_p there will be no has_anonymous check; it just + isn't needed. + + This allows linux_find_memory_regions_full to be simplified a little, + and will allow some additional clean ups in + linux_make_mappings_callback, which is the partner function to + dump_note_entry_p (see linux_make_mappings_corefile_notes), now that + we know dump_note_entry_p is always called. This follow on clean up + will be done in a later commit in this series. + + Looking at dump_mapping_p, I do wonder if the ::has_anonymous check + could be moved later in the function. The first few checks in + dump_mapping_p don't rely on the anonymous information, so running + them might give better results. However, the lack of the anonymous + information is only for older kernels, so testing any changes in this + area would likely require spinning up an older kernel, and as the + years pass, we likely care about this case less. So for now I've left + the ::has_anonymous check as the first thing in dump_mapping_p as this + keeps the existing behaviour. + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-12 Andrew Burgess + + gdb: pass struct smaps_data to linux_dump_mapping_p_ftype + Simplify the argument passing in linux_find_memory_regions_full when + calling the should_dump_mapping_p callback. Instead of pulling all + the components from the smaps_data object and passing them separately, + just pass the smaps_data object. + + I think this change is justified on its own; the code seems cleaner, + and easier to read to my eye. But additionally, in a later commit in + this series I want to pass smaps_data::has_anonymous to the + should_dump_mapping_p callback, which would mean adding yet another + argument, and I think the argument list is already long enough. + Changing the function now to pass the smaps_data object means that I + will already have the ::has_anonymous field available in the later + commit. + + There should be no user visible changes after this commit. + + Approved-By: Simon Marchi + +2025-05-12 Andrew Burgess + + gdb: use bool more in linux-tdep.c + Convert linux_dump_mapping_p_ftype to return a bool, and then update + everything that is needed to handle the fallout from this change. + + There should be no user visible changes from this commit. + + Approved-By: Simon Marchi + +2025-05-12 Tankut Baris Aktemur + + gdb: add '-stopped' and '-running' options to "info threads" + Add two options to "info threads": `-stopped` and `-running`. + + The purpose of these options is to filter the output of the command. + The `-stopped` option means "print stopped threads only" and, + similarly, `-running` means "print the running threads only". When + both options are provided by the user, the indication is that the user + wants the union. That is, the output contains both stopped and + running threads. + + Suppose we have an application with 5 threads, 2 of which have hit a + breakpoint. The "info threads" command in the non-stop mode gives: + + (gdb) info threads + Id Target Id Frame + * 1 Thread 0x7ffff7d99740 (running) + 2 Thread 0x7ffff7d98700 something () at file.c:30 + 3 Thread 0x7ffff7597700 (running) + 4 Thread 0x7ffff6d96700 something () at file.c:30 + 5 Thread 0x7ffff6595700 (running) + (gdb) + + Using the "-stopped" flag, we get + + (gdb) info threads -stopped + Id Target Id Frame + 2 Thread 0x7ffff7d98700 something () at file.c:30 + 4 Thread 0x7ffff6d96700 something () at file.c:30 + (gdb) + + Using the "-running" flag, we get + + (gdb) info threads -running + Id Target Id Frame + * 1 Thread 0x7ffff7d99740 (running) + 3 Thread 0x7ffff7597700 (running) + 5 Thread 0x7ffff6595700 (running) + (gdb) + + Using both flags prints all: + + (gdb) info threads -stopped -running + Id Target Id Frame + * 1 Thread 0x7ffff7d99740 (running) + 2 Thread 0x7ffff7d98700 something () at file.c:30 + 3 Thread 0x7ffff7597700 (running) + 4 Thread 0x7ffff6d96700 something () at file.c:30 + 5 Thread 0x7ffff6595700 (running) + (gdb) + + When combined with a thread ID, filtering applies to those threads that + are matched by the ID. + + (gdb) info threads 3 + Id Target Id Frame + 3 Thread 0x7ffff7597700 (running) + (gdb) info threads -stopped 3 + No threads matched. + (gdb) + + Regression-tested on X86_64 Linux. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Guinevere Larsen + Approved-by: Pedro Alves + + gdb: update "info threads" output when no threads match the arguments + If "info threads" is provided with the thread ID argument but no such + threads matching the thread ID(s) are found, GDB prints + + No threads match ''. + + Update this output to the more generalized + + No threads matched. + + The intention is that the next patch, and potentially future ones, + will extend the command with more filter/match arguments. We cannot + customize the output to each such argument. Hence, be more generic. + + Reviewed-By: Eli Zaretskii + Approved-by: Pedro Alves + + gdb: pass info_threads_opts to print_thread_info_1 + The "info threads" command tracks its options in a struct named + 'info_threads_opts', which currently has only one option. Pass the + whole options object to helper functions, instead of passing + the option value individually. This is a refactoring to make adding + more options easier. + + Reviewed-By: Guinevere Larsen + Approved-by: Pedro Alves + + Automatic date update in version.in + +2025-05-11 Alan Modra + + ubsan: size_inc_line_addr integer overflow + Fix a fuzzer testcase where a large positive line_delta causes signed + overflow when subtracting -5. Signed overflow is perfectly OK here. + +2025-05-11 Alan Modra + + msan: use of uninitialised data in get_cie_info + This completely bogus oss-fuzz x86 testcase results in a read from an + uninitialised (at the time check_eh_frame is called) part of an insn + frag: + .section .debug_frame + orl $1,x + .long x + .uleb128 0,x,0 + x: + + Fix the problem by verifying the assumption in get_cie_info that a CIE + starts at the beginning of .eh_frame or .debug_frame. Or at least + exclude silliness involving instructions placed there. That seems a + useful sanity check. Also sanity check sizes of initial FDE fields. + + Yes, this doesn't completely stop the problem since you could place an + insn with a relocated field later in the CIE. If fuzzers find such a + testcase I'll ignore it. + + * ehopt.c (struct cie_info): Add "f" field. + (get_cie_info): Return a bool. Verify frag at start of chain + is one with the CIE size found by check_eh_frame. + (check_eh_frame): Save CIE start frag. Only accept 4 or 8 + byte fields in state_saw_size, state_saw_cie_offset and + state_saw_pc_begin. Formatting. Localise "fix" variable. + +2025-05-11 GDB Administrator + + Automatic date update in version.in + +2025-05-10 Tiezhu Yang + + gdb: LoongArch: Emulate floating-point branch instructions + Add bceqz and bcnez cases in loongarch_insn_is_cond_branch() and + loongarch_next_pc() to emulate floating-point branch instructions. + + Here are the references: + + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_bceqz_bcnez + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#table-table-of-instruction-encoding + + Approved-by: Kevin Buettner + +2025-05-10 GDB Administrator + + Automatic date update in version.in + +2025-05-10 Peter Bergner + + MAINTAINERS: Update my email address + Update my email address and move up Surya's name as the main PPC contact. + +2025-05-09 Tom Tromey + + Fix two comments in cli-style.c + I noticed that a couple of new comments in cli-style.c mentioned the + wrong command name. This patch fixes the comments. + + Move "show style sources" documentation + I noticed that I had inadvertently put the "set style warning-prefix" + documentation between the paragraph for "set style sources" and the + paragraph for "show style sources". This patch moves the latter up a + bit to clean this up. + +2025-05-09 Alice Carlotti + + aarch64: Mark predicate-as-counter pseudo instructions + Using explicit pseudo aliases is clearer and more consistent with other + instruction aliases. + + This does not change behaviour. For the non-alias instructions + (everything except mov) we already picked the first matching entry for + disassembly by default. For mov we picked the last matching aliased + entry, which remained the original alias since do_misc_decoding doesn't + recognise OP_MOV_PN_PN. + +2025-05-09 Alice Carlotti + + aarch64: Mark clearbhb as a pseudo instruction + This was an early name for the clrbhb hint instruction. Some software + was written with the old name before it was renamed, so we support it + for assembly but should never use it in disassembly. + + This patch has no functional change, because we already pick (by + default) the last matching alias in the opcode table, and clrbhb is + listed later than clearbhb. + +2025-05-09 Alice Carlotti + + aarch64: Merge dgh tests into system.d + + aarch64: Fix dgh disassembly + + aarch64: Mark SME mova aliases + This will only change behaviour during disassembly with -M no-aliases. + + aarch64: Mark rev64 as a pseudo instruction + This is more natural than raising the priority of rev with F_P1, and + is functionally equivalent. + + aarch64: Add new test original-missing-misc.d + This test file includes all the remaining untested instructions that + weren't part of a larger group of new or existing tests. + + aarch64: Add new test mov-wide.d + Only movn was previously untested. + + aarch64: Add new test exception-generation.d + svc and dcps* were already tested, but are included here as part of the + same encoding group. + + aarch64: Add new test conditional-compare.d + The register form of ccmp was already tested. + + aarch64: Add new test branch-cond-pseudos.d + beq, bne, bcs and bcc were already tested, and bge and ble are also used + in scfi tests. + + aarch64: Add new test ldst-unpriv.d + All instructions were previously untested. + + aarch64: Add new test ldst-extend-general.d + All instructions were previously untested. + + aarch64: Add new test dp-general-two-source.d + lsl was already tested but is included here as part of the same encoding + group. + + aarch64: Add new test dp-general-one-source.d + rev16 and the 64-bit rev/rev64 instructions were already tested, but are + included here as part of the same encoding group. + + aarch64: Add new test addsub-carry.d + All instructions were previously untested. + + aarch64: Add new test advsimd-scalar-doubling-mul.d + All instructions were previously untested. + + aarch64: Add new test advsimd-scalar-two-reg-misc.d + sqabs, sqneg, abs and neg were already tested, but are included here as + part of the same encoding group. + + aarch64: Add new test advsimd-scalar-shift-immediate.d + All instructions were previously untested. + + aarch64: Add new test advsimd-scalar-three-same.d + All instructions were previously untested. + + aarch64: Add new test advsimd-copy.d + Only smov and the second dup variant were previously untested. However, + the only test for umov was a disassembly test with -M no-aliases, and + the first dup variant was only tested in assembly in diagnostic.d with + the non-architectural syntax `dup v0.2d, v1.2d[0]`. + + aarch64: Add new test advsimd-permute.d + All instructions were previously untested. + + aarch64: Add new test advsimd-modified-immediate.d + All instructions (7 opcode table entries) were previously untested. + + aarch64: Add new test advsimd-two-reg-misc-hilo.d + All instructions were previously untested. + + aarch64: Add new test advsimd-two-reg-misc.d + sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was + already assembled in an error test (sve-reg-diagnostic.d), but they are + all included here as part of the same encoding group. + + aarch64: Add new test advsimd-mul-element.d + All instructions were previously untested. + + aarch64: Add new test advsimd-widening-narrowing.d + All instructions were previously untested. + + aarch64: Add new test advsimd-three-same.d + All instructions except orr/mov were previously untested. + + aarch64: Add missing widening fmops test + Also remove the valid instructions from the test for invalid + instructions - this meant that the instruction was previously being + tested for assembly but not disassembly. + + aarch64: Add tests for fabd, urecpe and ursqrt + Other instructions in the encoding group are tested in advsimd-fp16.d, + so add these instructions to the existing test file. + + aarch64: Add tests for fcvt, fcvtzs and fcvtzu + Other instructions in the encoding group are tested in float-fp16.d, so + add these instructions to the existing test file. + + aarch64: Add tests for csdb and eret to system.d + + aarch64: Add test for ands and bics + The other instructions in the encoding group are tested in shifted.d, so + add these to the existing test file. + + aarch64: Adjust float-fp16.d test patterns + Adjust the test to match instruction addresses of any length. + + aarch64: Adjust advsimd-fp16.d test patterns + Adjust the test to match instruction addresses of any length, and escape + literal '.' characters for a stricter match. + + aarch64: Adjust shifted.d test patterns + Adjust the test to match any instruction addresses, so that the test can + be extended more easily. + + aarch64: Eliminate AARCH64_OPND_SVE_ADDR_R + Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept + implicit XZR offsets. Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands + to support instructions where an XZR offset is allowed but must be + specified explicitly. This allows the removal of the duplicate opcode + table entries using AARCH64_OPND_SVE_ADDR_R. + +2025-05-09 Alice Carlotti + + aarch64: Disallow invalid SVE addressing modes + The fix for PR22988 in 2018 added a new operand AARCH64_OPND_SVE_ADDR_R + to support implicit XZR offsets, but this fix had several flaws that + meant it accepted several invalid addressing modes: + + 1. The base register type wasn't properly checked when the optional + register offset was omitted. This meant that + ldff1b {z1.s}, p1/z,[z1.d] + was parsed as if it were + ldff1b z1.d, p1/z, [x1.d, xzr]. + + 2. The explicit offset parsing didn't include a shift type, so the new + operand would incorrectly parse + ldff1h{z0.s}, p0/z, [x0, x0] + as if it were + ldff1h{z0.s}, p0/z, [x0, x0, lsl #1]. + + 3. Regardless of the above correctness issues, support for implicit + offsets should have been added by amending the operands in the existing + opcode table entries, instead of adding new duplicate table entires. + + Issue 1 can be fixed by using an "if" instead of an "else if" in + parse_operands, while issue 2 can be fixed by failing when the first + condition is false. This patch applies just these two fixes, leaving + issue 3 to be addressed in a subsequent more invasive patch. + + The instructions removed from the test sme-5.d are architecturally + invalid. The new tests cover all of the affected ldff1 variants; the + issue also affected SME ZA ld1*/st1* instructions using the same operand + type. + +2025-05-09 Jerry Zhang Jian + Kito Cheng + + RISC-V: Support Zce 1.0 + Zce is the extension defined in code-size-reduction + + Ref: https://github.com/riscvarchive/riscv-code-size-reduction + +2025-05-09 Tsukasa OI + + RISC-V: Base for complex extension implications + Thanks to the commit 48558a5e5471 ("RISC-V: Allow nested implications for + extensions"), we can write complex extension implications in theory. + However, to actually do that, we need to pass more information to + check_func. + + For example, we want to imply 'Zcf' from 'F' if and only if the 'Zce' + extension is also enabled and XLEN is 32. Passing rps is a way to + enable this. + + This commit prepares for such complex extension implications. + +2025-05-09 Jiawei + + RISC-V: Add augmented hypervisor extension 'sha' support. + The augmented hypervisor extension 'sha'[1] is a new profile-defined extension + that captures the full set of features that are mandated to be supported along + with the H extension. + + https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile + + bfd/ChangeLog: + + * elfxx-riscv.c: New extension and implies. + + gas/ChangeLog: + + * NEWS: New extension. + * testsuite/gas/riscv/imply.d: New test for sha. + * testsuite/gas/riscv/imply.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extension. + +2025-05-09 Jiawei + + RISC-V: Add Privileged Architecture 1.13 CSRs. + This patch support RISC-V Privileged Architecture 1.13 CSRs 'medelegh' and + 'hedelegh'. More details between 1.12 and 1.13 see [1]. + + [1] https://github.com/riscv/riscv-isa-manual/blob/main/src/priv-preface.adoc + + Version log: Remove gas/po changes. + + bfd/ChangeLog: + + * cpu-riscv.c: New option. + * cpu-riscv.h (enum riscv_spec_class): Ditto. + + binutils/ChangeLog: + + * doc/binutils.texi: New option. + + gas/ChangeLog: + + * NEWS: Add priv-1.13 support. + * config/tc-riscv.c: New option. + * configure: Ditto. + * configure.ac: Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New CSR. + * testsuite/gas/riscv/csr-version-1p10.l: New warning. + * testsuite/gas/riscv/csr-version-1p11.d: New CSR. + * testsuite/gas/riscv/csr-version-1p11.l: New warning. + * testsuite/gas/riscv/csr-version-1p12.d: New CSR. + * testsuite/gas/riscv/csr-version-1p12.l: New warning. + * testsuite/gas/riscv/csr.s: New CSR. + * testsuite/gas/riscv/attribute-15.d: New test. + * testsuite/gas/riscv/attribute-16.d: New test. + * testsuite/gas/riscv/csr-version-1p13.d: New test. + * testsuite/gas/riscv/csr-version-1p13.l: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MEDELEGH): New CSR. + (CSR_HEDELEGH): Ditto. + (DECLARE_CSR): Ditto. + +2025-05-09 Chao-ying Fu + + RISC-V: Added vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp + Spec: + https://mips.com/wp-content/uploads/2025/03/P8700-F_Programmers_Reference_Manual_Rev1.82_3-19-2025.pdf + + Added MIPS vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp + with verison 1.0. + + Passed binutils testsuites of targets elf32/elf64/linux32/linux64. + +2025-05-09 GDB Administrator + + Automatic date update in version.in + +2025-05-08 Tom Tromey + + Change substitute_path_component to use std::string + This changes substitute_path_component to use std::string and + std::string_view, simplifying it greatly and removing some manual + memory management. + + Approved-By: Simon Marchi + +2025-05-08 Tom Tromey + + Move substitute_path_component + This moves substitute_path_component out of utils.c. I considered + making a new file for this (still could if someone wants that), but + since the only caller is in auto-load.c, I moved it there instead. + + I've also moved the tests into auto-load.c as well. This way + substitute_path_component can be static. + + Approved-By: Simon Marchi + +2025-05-08 GDB Administrator + + Automatic date update in version.in + +2025-05-08 Alan Modra + + windres: buffer overflow + bin_to_res_menuexitems can be called with random data offsets (and thus + remaining lengths), confusing code that expects 4-byte aligned data. + Prevent an item length adjustment for alignment exceeding the + remaining length and then overflowing. + + Remove unnecessary use of pragma once in pr25618 test + +2025-05-07 Jens Remus + + s390: Fix format specifier for VR in disassembler + Vector register (VR) numbers are unsigned. Use format specifier %u + instead of %i. + + Reported-by: Florian Krohm + +2025-05-07 GDB Administrator + + Automatic date update in version.in + +2025-05-06 Tom Tromey + + Do not set yydebug in cp-name-parser.y + This reverts the change to cp-name-parser.y, avoiding a TSan report. + + Approved-By: Simon Marchi + +2025-05-06 Tom Tromey + + Remove kfail from templates.exp + templates.exp has one remaining kfail. However, the output in + question has been stabilized ever since the cp-name-parser.y work -- + the test just wasn't updated. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8617 + Reviewed-By: Keith Seitz + +2025-05-06 Tom Tromey + + Rewrite bug references in templates.exp + templates.exp has many kfails that refer to old GNATS bug numbers. + This patch updates them to refer to Bugzilla instead. + + Reviewed-By: Keith Seitz + +2025-05-06 Andrew Burgess + + Revert "gdb: support zero inode in generate-core-file command" + This reverts commit 1e21c846c275fc6e387ca903a129096be2a53d0b. + + This change was causing unexpected mappings to be included in the core + files generated by GDB, which was triggering warnings when GDB opened + a core file, like this: + + warning: Can't open file [stack] during file-backed mapping note processing + + warning: Can't open file [vvar] during file-backed mapping note processing + + For now I'm reverting the above commit and will come to the list again + when I have a solution that addresses the original issue without also + including the unexpected mappings. + +2025-05-06 Tom Tromey + + Handle field with dynamic bit offset + I discovered that GCC emitted incorrect DWARF for the test case + included in this patch. Eric wrote a fix for GCC, but then he found + that gdb crashed on the resulting file. + + This test has a field that is at a non-constant bit offset from the + start of the type. DWARF 5 does not allow for this situation (I've + sent a report to the DWARF list), but DWARF 3 did allow for this via a + combination of an expression for the byte offset and then the use of + DW_AT_bit_offset. This looks like: + + <5><117a>: Abbrev Number: 17 (DW_TAG_member) + <117b> DW_AT_name : (indirect string, offset: 0x1959): another_field + ... + <1188> DW_AT_bit_offset : 6 + <1189> DW_AT_data_member_location: 6 byte block: 99 3d 1 0 0 22 (DW_OP_call4: <0x1193>; DW_OP_plus) + ... + <3><1193>: Abbrev Number: 2 (DW_TAG_dwarf_procedure) + <1194> DW_AT_location : 15 byte block: 97 94 1 37 1a 32 1e 23 7 38 1b 31 1c 23 3 (DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_lit7; DW_OP_and; DW_OP_lit2; DW_OP_mul; DW_OP_plus_uconst: 7; DW_OP_lit8; DW_OP_div; DW_OP_lit1; DW_OP_minus; DW_OP_plus_uconst: 3) + + Now, that combination is not fully general, in that the bit offset + must be a constant -- only the byte offset may really vary. However, + I couldn't come up with a situation where full generality is needed, + mainly because GNAT won't seem to pack fields into the padding of a + variable-length array. + + Meanwhile, the reason for the gdb crash is that the code handling + DW_AT_bit_offset assumes that the byte offset is a constant. This + causes an assertion failure. + + This patch arranges for DW_AT_bit_offset to be applied during field + resolution, when needed. + +2025-05-06 Tom Tromey + + Introduce apply_bit_offset_to_field helper function + This patch makes a new function, apply_bit_offset_to_field, that is + used to handle the logic of DW_AT_bit_offset. Currently there is just + a single caller, but the next patch will change this. + + Use OBSTACK_ZALLOC when allocating batons + I found some places in dwarf2/read.c that allocate a location baton, + but fail to initialize one of the fields. It seems safer to me to use + OBSTACK_ZALLOC here, so this patch makes this change. This will be + useful in a subsequent patch as well, where a new field is added to + one of the batons. + + Clean up handle_member_location + This removes a redundant check from handle_member_location, and also + changes the complaint -- currently it will issue the "complex + location" complaint, but really what is happening here is an + unrecognized form. + +2025-05-06 Tom Tromey + + Handle dynamic field properties + I found a situation where gdb could not properly decode an Ada type. + In this first scenario, the discriminant of a type is a bit-field. + PROP_ADDR_OFFSET does not handle this situation, because it only + allows an offset -- not a bit-size. + + My original approach to this just added a bit size as well, but after + some discussion with Eric Botcazou, we found another failing case: a + tagged type can have a second discriminant that appears at a variable + offset. + + So, this patch changes this code to accept a general 'struct field' + instead of trying to replicate the field-finding machinery by itself. + + This is handled at property-evaluation time by simply using a 'field' + and resolving its dynamic properties. Then the usual field-extraction + function is called to get the value. + + Because the baton now just holds a field, I renamed PROP_ADDR_OFFSET + to PROP_FIELD. + + The DWARF reader now defers filling in the property baton until the + fields have been attached to the type. + + Finally, I noticed that if the discriminant field has a biased + representation, then unpack_field_as_long would not handle this + either. This bug is also fixed here, and the test case checks this. + + Regression tested on x86-64 Fedora 41. + +2025-05-06 Tom Tromey + + Add new unpack_field_as_long overload + This introduces a new unpack_field_as_long that takes the field object + directly, rather than a type and an index. This will be used in the + next patch. + +2025-05-06 Tom Tromey + + Add resolve_dynamic_field + The final patch in this series will change one dynamic property + approach to use a struct field rather than an offset and a field type. + This is convenient because the reference in DWARF is indeed to a field + -- and this approach lets us reuse the field-extraction logic that + already exists in gdb. + + However, the field in question may have dynamic properties which must + be resolved before it can be used. This patch prepares for this by + introducing a separate resolve_dynamic_field function. + + This patch should cause no visible changes to behavior. + +2025-05-06 Tom Tromey + + Constify property_addr_info + This changes most places to use a const property_addr_info. This + seems more correct to me because normally the user of a + property_addr_info should not modify it. Furthermore, some functions + already take a const object, and for a subsequent patch it is + convenient if other functions do as well. + +2025-05-06 Lancelot SIX + + gdb/testsuite: Add require allow_hipcc_tests in gdb.rocm/mi-attach.exp + The gdb.rocm/mi-attach.exp test is missing a proper `require` check to + ensure that the current configuration can run ROCm tests. This issue + has been reported by Baris. + + This patch adds the missing `allow_hipcc_tests` requirement, and also + adds `load_lib rocm.exp` to enable this test. + + Change-Id: Ie136adfc2d0854268b92af5c4df2dd0334dce259 + Reviewed-By: Tankut Baris Aktemur + Approved-By: Tom Tromey + +2025-05-06 Andrew Burgess + + gdb: support zero inode in generate-core-file command + It is possible, when creating a shared memory segment (i.e. with + shmget), that the id of the segment will be zero. + + When looking at the segment in /proc/PID/smaps, the inode field of the + entry holds the shared memory segment id. + + And so, it can be the case that an entry (in the smaps file) will have + an inode of zero. + + When GDB generates a core file, with the generate-core-file (or its + gcore alias) command, the shared memory segment should be written into + the core file. + + Fedora GDB has, since 2008, carried a patch that tests this case. + There is no fix for GDB associated with the test, and unfortunately, + the motivation for the test has been lost to the mists of time. This + likely means that a fix was merged upstream without a suitable test, + but I've not been able to find and relevant commit. The test seems to + be checking that the shared memory segment with id zero, is being + written to the core file. + + While looking at this test and trying to work out if it should be + posted upstream, I saw that GDB does appear to write the shared memory + segment into the core file (as expected), which is good. However, GDB + still isn't getting this case exactly right. + + In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via + the gdbarch_find_memory_regions call) to correctly write the shared + memory segment into the core file, however, in + linux_make_mappings_corefile_notes, when we use + linux_find_memory_regions_full to create the NT_FILE note, we call + back into linux_make_mappings_callback for each mapping, and in here + we reject any mapping with a zero inode. + + The result of this, is that, for a shared memory segment with a + non-zero id, after loading the core file, the shared memory segment + will appear in the 'proc info mappings' output. But, for a shared + memory segment with a zero id, the segment will not appear in the + 'proc info mappings' output. + + I propose fixing this by not checking the inode in + linux_make_mappings_callback. The inode check was in place since the + code was originally added in commit 451b7c33cb3c9ec6272c36870 (in + 2012). + + The test for this bug, based on the original Fedora patch, can be + found on the mailing list here: + + https://inbox.sourceware.org/gdb-patches/0d389b435cbb0924335adbc9eba6cf30b4a2c4ee.1741776651.git.aburgess@redhat.com + + I have not committed this test into the tree though because the test + was just too unreliable. User space doesn't have any control over the + shared memory id, so all we can do is spam out requests for new shared + memory segments and hope that we eventually get the zero id. + + Obviously, this can fail; the zero id might already be in use by some + long running process, or the kernel, for whatever reason, might choose + to never allocate the zero id. The test I posted (see above thread) + did work more than 50% of the time, but it was far closer to a 50% + success rate than 100%, and I really don't like introducing unreliable + tests. + +2025-05-06 Andrew Burgess + + gdb/testsuite: add gcore_cmd_available predicate proc + Add a new gcore_cmd_available predicate proc that can be used in a + 'requires' line, and make use of it in a few tests. + + All of the tests I have modified call gdb_gcore_cmd as one of their + first actions and exit if the gcore command is not available, so it + makes sense (I think) to move the gcore command check into a requires + call. + + There should be no change in what is actually run after this commit. + +2025-05-06 Andrew Burgess + + gdb/python/guile: check if styling is disabled in Color.escape_sequence + I noticed that the gdb.Color.escape_sequence() method would produce an + escape sequence even when styling is disabled. + + I think this is the wrong choice. Ideally, when styling is + disabled (e.g. with 'set style enabled off'), GDB should not be + producing styled output. + + If a GDB extension is using gdb.Color to apply styling to the output, + then currently, the extension should be checking 'show style enabled' + any time Color.escape_sequence() is used. This means lots of code + duplication, and the possibility that some locations will be missed, + which means disabling styling no longer does what it says. + + I propose that Color.escape_sequence() should return the empty string + if styling is disabled. A Python extension can then do: + + python + c_none = gdb.Color('none') + c_red = gdb.Color('red') + print(c_red.escape_sequence(True) + + "Text in red." + + c_none.escape_sequence(True)) + end + + If styling is enable this will print some red text. And if styling is + disabled, then it will print text in the terminal's default color. + + I have applied the same fix to the guile API. + + I have extended the tests to cover this case. + + Approved-By: Tom Tromey + +2025-05-06 Alan Modra + + gas: input_scrub buffers + This tidies freeing of input_scrub buffers on failure paths, making + input_scrub_end iterate over any input_scrub_push'd files or string + buffers to clean up memory. + + * input-scrub.c (input_scrub_free): New function. + (input_scrub_pop): Call it rather than input_scrub_end. + (input_scrub_end): Iterate over next_saved_file freeing + buffers. + (input_scrub_next_buffer): Move sb_kill to input_scrub_free. + +2025-05-06 Alan Modra + + windres_get_* functions + windres_get_32 and similar have a length parameter that in most cases + is just the required length, so it is redundant. The few cases where + a variable length is passed are all in resrc.c. So, get rid of the + length parameter and introduce wrappers in resrc.c to check the + length. + +2025-05-06 GDB Administrator + + Automatic date update in version.in + +2025-05-05 Tom Tromey + + Fix sign of Ada rational constants + My earlier patch commit 0c03db90 ("Use correct sign in get_mpz") was + (very) incorrect. It changed get_mpz to check for a strict sign when + examining part of an Ada rational constant. However, in Ada the + "delta" for a fixed-point type must be positive, and so the components + of the rational representation will be positive. + + This patch corrects the error. It also renames the get_mpz function, + in case anyone is tempted to reuse this code for another purpose. + + Finally, this pulls over the test from the internal AdaCore test suite + that found this issue. + +2025-05-05 Vladimir Mezentsev + + gprofng: remove unused functions, duplicate macros + class Reloc is not used after commit + 13f614be23a gprofng: Refactor readSymSec for using BFD's asymbol struct + + Many common macros were defined in different sources. + Sometimes a macro was used, sometimes a macros value was used. + Removed unused macros and include files. + + gprofng/ChangeLog + 2025-05-03 Vladimir Mezentsev + + * common/gp-experiment.h: Define variables that are passed to + libcollector. Remove unused macros. + * libcollector/collector.c: Cleanup macros. + * libcollector/descendants.h: Likewise. + * libcollector/envmgmt.c: Likewise. + * libcollector/linetrace.c: Likewise. + * src/collect.h: Likewise. + * src/envsets.cc: Likewise. + * src/gp-collect-app.cc: Likewise. + * src/Stabs.cc: Remove class Reloc. + * src/Stabs.h: Likewise. + * src/ipcio.cc: Remove unused include files. + +2025-05-05 Vladimir Mezentsev + + gprofng: fix 32892 source line level information not available with "-g -O2" + gprofng ignored DW_AT_specification. + As a result, gprofng skiped Dwarf for all functions declared as: + < 2>:<0x0000f725> DW_TAG_subprogram(46) + DW_AT_linkage_name(110) "func_name" + DW_AT_declaration*(60) 0x1 (1) + < 1>:<0x00015acc> DW_TAG_subprogram(46) + DW_AT_specification(71) 0xf725 (63269) + + Another problem was that gprofng ignored DW_AT_ranges. + As a result, many functions are mapped to the module. + + gprofng/ChangeLog + 2025-05-01 Vladimir Mezentsev + + PR 32892 + * src/Dwarf.cc: Handle DW_AT_specification and DW_AT_ranges. + * src/DwarfLib.cc: Likewise. + * src/DwarfLib.h: Likewise. + * src/Dwarf.h (get_ranges): New function. + * src/Stabs.h (get_symbols): New function. + * src/Stabs.cc: Move Symbol class to src/Symbol.cc. + * src/Symbol.cc: New file. + * src/Symbol.h: New file. + * src/Makefile.am: Add Symbol.cc in build. + * src/Makefile.in: Rebuild. + * src/LoadObject.cc (dump_functions): Improve output for -dfunc option. + +2025-05-05 GDB Administrator + + Automatic date update in version.in + +2025-05-04 GDB Administrator + + Automatic date update in version.in + +2025-05-03 GDB Administrator + + Automatic date update in version.in + +2025-05-02 Tom de Vries + + [gdb/testsuite] Simplify gdb.tui/tui-layout-asm.exp + On x86_64-cygwin, with test-case gdb.tui/tui-layout-asm.exp I run into: + ... + WARNING: The following failure is probably due to the TUI window + width. See the comments in the test script for more + details. + FAIL: $exp: scroll to end of assembler (scroll failed) + ... + + The problem is as follows. + + On the TUI screen, we have: + 1 | 0x1004010ff <__gdb_set_unbuffered_output+95> nop | + 2 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x10040 | + ... + + We send the down key, which should have the effect of scrolling up. So, we + expect that the second line moves to the first line. + + That seems to be the case indeed: + ... + 1 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x1004080c8 <__imp___cxa_ | + ... + but the line has changed somewhat, so the matching fails. + + We could increase the width of the screen, as suggested in the test-case, but + I think that approach is fragile. + + Instead, fix this by relaxing the matching: just check that the line before + scrolling is fully contained in the line after scrolling, or the other way + around. + + Doing so gets us the next failure: + ... + FAIL: $exp: scroll to end of assembler (too much assembler) + ... + + The test-case states: + ... + if { $down_count > 250 } { + # Maybe we should accept this as a pass in case a target + # really does have loads of assembler to scroll through. + fail "$testname (too much assembler)" + ... + and I agree, so fix this by issuing a pass. + + This results in the test-case taking ~20 seconds, so reduce the maximum number + of scrolls from 250 to 25, bringing that down to ~10 seconds. + + Tested on x86_64-cygwin and x86_64-linux. + + PR testsuite/32898 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32898 + +2025-05-02 Tom de Vries + + [gdb/symtab] Throw DWARF error on out-of-bounds DW_FORM_strx + With the test-case contained in the patch, and gdb build with + -fsanitize=address we get: + ... + ==23678==ERROR: AddressSanitizer: heap-buffer-overflow ...^M + READ of size 1 at 0x6020000c30dc thread T3^[[1m^[[0m^M + ptype global_var^M + #0 0x2c6a40b in bfd_getl32 bfd/libbfd.c:846^M + #1 0x168f96c in read_str_index gdb/dwarf2/read.c:15349^M + ... + + The executable contains an out-of-bounds DW_FORM_strx attribute: + ... + $ readelf -wi $exec + <2eb> DW_AT_name :readelf: Warning: string index of 1 converts to \ + an offset of 0xc which is too big for section .debug_str + (indexed string: 0x1): + ... + and read_str_index doesn't check for this: + ... + info_ptr = (str_offsets_section->buffer + + str_offsets_base + + str_index * offset_size); + if (offset_size == 4) + str_offset = bfd_get_32 (abfd, info_ptr); + ... + and consequently reads out-of-bounds. + + Fix this in read_str_index by checking for the out-of-bounds condition and + throwing a DWARF error: + ... + (gdb) ptype global_var + DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \ + outside of .debug_str_offsets section in CU at offset 0x2d7 \ + [in module dw-form-strx-out-of-bounds] + No symbol "global_var" in current context. + (gdb) + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-05-02 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/dw-form-strx.exp + Add a test-case using DW_FORM_strx. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-05-02 Tom de Vries + + [gdbsupport] Reimplement phex and phex_nz as templates + Gdbsupport functions phex and phex_nz have a parameter sizeof_l: + ... + extern const char *phex (ULONGEST l, int sizeof_l); + extern const char *phex_nz (ULONGEST l, int sizeof_l); + ... + and a lot of calls use: + ... + phex (l, sizeof (l)) + ... + + Make this easier by reimplementing the functions as a template, allowing us to + simply write: + ... + phex (l) + ... + + Simplify existing code using: + ... + $ find gdb* -type f \ + | xargs sed -i 's/phex (\([^,]*\), sizeof (\1))/phex (\1)/' + $ find gdb* -type f \ + | xargs sed -i 's/phex_nz (\([^,]*\), sizeof (\1))/phex_nz (\1)/' + ... + and manually review: + ... + $ find gdb* -type f | xargs grep "phex (.*, sizeof.*)" + $ find gdb* -type f | xargs grep "phex_nz (.*, sizeof.*)" + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-05-02 Tom Tromey + + Use emoji to indicate errors and warnings + This patch adds, at long last, some emoji output to gdb. In + particular, warnings are indicated with the U+26A0 (WARNING SIGN), and + errors with U+274C (CROSS MARK). + + There is a new setting to control whether emoji output can be used. + It defaults to "auto", which means emoji will be used if the host + charset is UTF-8. Note that disabling styling will also disable + emoji, handy for traditionalists. + + I've refactored mingw console output a little, so that emoji will not + be printed to the console. Note the previous code here was a bit + strange in that it assumed that the first use of gdb_console_fputs + would be to stdout. + + This version lets the user control the prefixes directly, so different + emoji can be chosen if desired. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Keith Seitz + Reviewed-By: Guinevere Larsen + +2025-05-02 Chris Packham + + readline/tcap.h: Update definitions for C23 + C23 changes how function definitions like int `int tputs ()` are + interpreted. In older standards this meant that the function arguments + are unknown. In C23 this is interpreted as `int tputs (void)` so now + when we compile with GCC15 (which defaults to -std=gnu23) we get an + error such as + + readline/display.c:2839:17: error: too many arguments to function 'tputs'; expected 0, have 3 + + Add the function arguments for tgetent(), tgetflag(), tgetnum(), + tgetstr(), tputs() and tgoto(). + + Approved-By: Tom Tromey + +2025-05-02 Tom de Vries + + [gdb/testsuite] Fix gdb.reverse/time-reverse.exp timeout + After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with + test-case gdb.reverse/time-reverse.exp I run into: + ... + (gdb) continue^M + Continuing.^M + FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout) + ... + + The problem is that instruction stepping gets stuck in a loop with this call + stack: time -> __GI___clock_gettime -> __kernel_clock_gettime -> + __cvdso_clock_gettime. + + This is not specific to fsanitize=thread, it just makes gdb slow, which makes + instruction stepping slow, which results in the application getting stuck. + + I ran into this as well with a regular gdb build on a 32-bit i686 laptop with + 1GB of memory, an inherently slow setup. In that instance, I was able to + observe that the loop we're stuck in is the outer loop in do_coarse in linux + kernel source lib/vdso/gettimeofday.c. + + Fix this by setting "record full insn-number-max" to 2000, and handling + running into the limit. + + Initially I tried the approach of using "stepi 2000" instead of continue, but + that made the issue more likely to show up (for instance, I observed it after + building gdb with -O0 on aarch64-linux). + + Tested on aarch64-linux. + + Approved-By: Guinevere Larsen + + PR testsuite/32678 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678 + +2025-05-02 Tom de Vries + + [gdb/testsuite] Make gdb.reverse/time-reverse.exp more robust + I noticed that test-case gdb.reverse/time-reverse.exp contains: + ... + if [supports_process_record] { + # Activate process record/replay + gdb_test_no_output "record" "turn on process record" + ... + + So I tried out forcing supports_process_record to 0, and got: + ... + FAIL: gdb.reverse/time-reverse.exp: mode=syscall: info record + FAIL: gdb.reverse/time-reverse.exp: mode=syscall: reverse to marker1 + FAIL: gdb.reverse/time-reverse.exp: mode=syscall: check time record + FAIL: gdb.reverse/time-reverse.exp: mode=c: info record + FAIL: gdb.reverse/time-reverse.exp: mode=c: reverse to marker1 + FAIL: gdb.reverse/time-reverse.exp: mode=c: check time record + ... + + Fix this by requiring supports_process_record alongside supports_reverse. + + I also noticed when running make-check-all.sh that there were a lot of failures + with target board dwarf5-fission-debug-types. + + Fix this by not ignoring the result of "runto marker1". + + Then I noticed that $srcfile is used as a regexp. Fix this by applying + string_to_regexp. + + Tested on x86_64-linux. + + Approved-By: Guinevere Larsen + +2025-05-02 Tom Tromey + + Minor changes to Ada tests for gnat-llvm + I found a few more spots where a minor modification to a test lets it + pass with gnat-llvm: + + * For array_subcript_addr, gnat-llvm was not putting the array into + memory. Making the array larger works around this. + + * For bp_inlined_func, it is normal for gnat-llvm to sometimes emit a + call to an out-of-line copy of the function, so accept this. + + * For null_overload and type-tick-size, I've applied the usual fix for + keeping an unused local variable alive. + +2025-05-02 Tom de Vries + + [gdb/testsuite] Make gdb.threads/inf-thr-count.exp more readable + While investigating a timeout in gdb.threads/inf-thr-count.exp I noticed that + it uses quite some escaping, resulting in hard-to-parse regexps like + "\\\$$::decimal". + + Fix this by reducing the escaping using: + - quoting strings using {} instead of "", and + - string_to_regexp. + + Also use multi_line to split up long multi-line regexps. + + Tested on x86_64-linux. + +2025-05-02 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.threads/inf-thr-count.exp + With test-case gdb.threads/inf-thr-count.exp, check-readmore and + READMORE_SLEEP=1000 I run into: + ... + (gdb) set variable spin = 0^M + (gdb) ^M + Thread 1 "inf-thr-count" hit Breakpoint 2, breakpt () at /data/vries/gdb/src/gdb/testsuite/gdb.threads/inf-thr-count.c:49^M + 49 }^M + FAIL: gdb.threads/inf-thr-count.exp: set 'spin' flag to allow main thread to exit (timeout) + PASS: gdb.threads/inf-thr-count.exp: wait for main thread to stop + ... + + Fix this by using -no-prompt-anchor. + + Tested on x86_64-linux. + +2025-05-02 Jan Beulich + + aarch64: drop stray newlines + as_bad() already emits a newline; having extra ones leads to somewhat + distorted diagnostics. + + arm: drop stray newlines + Both as_bad() and as_warn() already emit a newline; having extra ones + leads to somewhat distorted diagnostics. + + COFF: correct function auxiliary symbol data clearing + It's unclear why the array part of the union was used there, when we're + dealing with a function. Originally, when 32-bit hosts and targets were + prevailing, the memset() in question ended up clearing the entire x_fcn, + while for 64-bit hosts/targets only x_lnnoptr would have been cleared. + Then a2c7ca15a560 ("Use stdint types in coff internal_auxent") made + things consistent, but imo in the wrong direction (and likely + unintentionally). Go back to what apparently was meant originally, using + the correct part of the union now. + +2025-05-02 Jan Beulich + + COFF: function auxiliary symbols + For one at least x86 gcc emits .def/.endef for functions, but no 2nd + pair to designate their ends (sizes). While we can't recover the sizes, + we can at least properly establish the chain of function symbols, which + of course requires to emit auxiliary symbols for every function symbol + even when there's no C_EFCN: We simply shouldn't be making their + insertion conditional upon there not being a function processing of + which is "in progress". + + In fact it was wrong to assign dual purpose to {,next_}set_end: + Functions don't have "ends" set, but links to the next one. The same + symbol table entry can serve both as an end marker and be a part of the + chain of (defined) functions; this can't be expressed by a single static + variable. Use what (again) becomes last_functionP for this purpose, + along with tracking what symbol C_EFCN should apply to. + + This then allows to undo exposing of the respective (supposedly static) + tracking variable, which PPC's XCOFF handling had introduced. Also + rename it back to what it was before its exposure. + + For now the new testcases are XFAIL for Arm64 since there, unlike for + Arm32, mapping symbols are emitted for COFF, too. + +2025-05-02 Jan Beulich + + gas: add new COFF-specific subdir in testsuite + ... and move the cofftag testcase there (from all/). Just like we have + one for ELF. + + Arm/COFF: accept .def outside of CCS mode + There's no reason to reject this common COFF directive when it doesn't + have any other meaning. + +2025-05-02 GDB Administrator + + Automatic date update in version.in + +2025-05-01 Alan Modra + + asan: null pointer as arg 2 of memcpy + Replace xmalloc+memcpy+free with xrealloc, avoiding the asan warning + on the initial allocation where we had memcpy(p,0,0). + + * cg_arcs.c (arc_add): Use xrealloc. + +2025-05-01 H.J. Lu + + dwarf: Properly check holes in .debug_ranges/debug_rnglists + Don't warn if the offset of the first entry in .debug_rnglists starts + right after the header. Warn holes in .debug_ranges and debug_rnglists + sections only if the last end pointer isn't the same as the current + start pointer. + + PR binutils/32927 + * dwarf.c (display_debug_ranges_list): Return the pointer to the + end. + (display_debug_ranges): Don't warn if the offset of the first + entry in .debug_rnglists starts right after the header. Warn a + hole only if the last end pointer is the same as the next pointer. + * testsuite/binutils-all/x86-64/dwarf4.s: New file. + * testsuite/binutils-all/x86-64/dwarf5.s: Likewise. + * testsuite/binutils-all/x86-64/pr32927-1.d: Likewise. + * testsuite/binutils-all/x86-64/pr32927-2.d: Likewise. + + Co-Authored-By: Alan Modra + +2025-05-01 GDB Administrator + + Automatic date update in version.in + +2025-04-30 Guinevere Larsen + + gdb/progspace: fix formatting issue + The previous commit had a small styling issue that I forgot to fix + before pushing. This commit fixes the styling issue. + +2025-04-30 Guinevere Larsen + + gdb: Stop exec_close looking like a UAF weakness + A recent static analyzer run flagged that program_space::exec_close + could be using a pointer after it has been freed. This is not true, as + the pointer is never dereferenced, the address is used for comparisons. + + However, to avoid false positives from static analyzers (or bogus + security bugs), this commit makes the code stop looking like a UAF by + moving the unique_ptr into a local unique_ptr, so that there is no way + someone would think memory could be used after being freed. + + Approved-By: Tom Tromey + +2025-04-30 Tom de Vries + + [gdb/testsuite] Don't compile read1.so with -fsanitize + After building gdb with: + ... + CFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread -fno-exceptions + CXXFLAGS= -O0 -g -fstack-protector-all -fsanitize=thread + ... + when doing: + ... + $ cd build/gdb + $ make check-read1 RUNTESTFLAGS=gdb.threads/clone-attach-detach.exp + ... + I run into: + ... + Running /data/vries/gdb/src/gdb/testsuite/gdb.threads/clone-attach-detach.exp ... + ThreadSanitizer:DEADLYSIGNAL + ==4799==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 \ + (pc 0x7f636029a947 bp 0x7f635dfbf090 sp 0x7f635dfbf028 T4824) + ==4799==The signal is caused by a READ memory access. + ==4799==Hint: address points to the zero page. + ThreadSanitizer:DEADLYSIGNAL + ThreadSanitizer: nested bug in the same thread, aborting. + ... + + This doesn't happen when doing the same from build/gdb/testsuite, because + CFLAGS doesn't get propagated from build/gdb. + + I'm not sure what is the root cause here, but when building with + -fsanitize, I'm interested in running the sanitizer on gdb, not on testsuite + utility libraries that are used with expect. + + Fix this by skipping -fsanitize when compiling read1.so and readmore.so. + + Tested on x86_64-linux, by rebuilding read1.so and running the test-case. + + Approved-By: Tom Tromey + +2025-04-30 Tom de Vries + + [gdb/testsuite] Handle asm frame in gdb.python/py-missing-objfile.exp + On arm-linux, with test-case gdb.python/py-missing-objfile.exp I get: + ... + (gdb) whatis global_exec_var^M + type = volatile exec_type^M + (gdb) FAIL: $exp: initial sanity check: whatis global_exec_var + ... + instead of the expected "type = volatile struct exec_type". + + The problem is that the current language is ASM instead of C, because the + inner frame at the point of the core dump has language ASM: + ... + #0 __libc_do_syscall () at libc-do-syscall.S:47 + #1 0xf7882920 in __pthread_kill_implementation () at pthread_kill.c:43 + #2 0xf784df22 in __GI_raise (sig=sig@entry=6) at raise.c:26 + #3 0xf783f03e in __GI_abort () at abort.c:73 + #4 0x009b0538 in dump_core () at py-missing-objfile.c:34 + #5 0x009b0598 in main () at py-missing-objfile.c:46 + ... + + Fix this by manually setting the language to C. + + Tested on arm-linux and x86_64-linux. + + PR testsuite/32445 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32445 + +2025-04-30 Tom de Vries + + [gdb/build] Fix Wformat errors in gdb/riscv-tdep.c + When building gdb with --enable-targets=all on arm-linux, I run into: + ... + gdb/riscv-tdep.c: In function ‘bool try_read(regcache*, int, ULONGEST&)’: + gdb/riscv-tdep.c:4887:18: error: format ‘%lx’ expects argument of type \ + ‘long unsigned int’, but argument 2 has type ‘ULONGEST’ \ + {aka ‘long long unsigned int’} [-Werror=format=] + 4887 | warning (_("Can not read at address %lx"), addr); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ... + and a few more Wformat errors, due to commit b9c7eed0c24 ("This commit adds + record full support for rv64gc instruction set"). + + Fix these by using hex_string. + + Tested by completing a build on arm-linux. + +2025-04-30 Kito Cheng + + RISC-V: Mark fgt.*/fge.* as instruction alias + They are instruction alias, but not mark correctly, and seems like we + don't have a good way to verify that since the disassembler doesn't + disassemble instruction into alias. + + [1] https://github.com/riscv-non-isa/riscv-asm-manual/pull/124 + +2025-04-30 Alan Modra + + PR 32896 testcase + Modify it a little to run on more targets. + + kvxelf.em: translate error messages + gettext calls were missing. Fix that, and change a couple of einfo + calls to fatal. + +2025-04-29 Simon Marchi + + gdb/dwarf: change a bunch of functions to be methods of cooked_index_worker_debug_info + Move a few functions exclusively used to process units to become methods + of cooked_index_worker_debug_info. Rename them to a more consistent + name scheme, which gets rid of outdated naming. The comments were also + quite outdated. + + Change-Id: I2e7dcc2e4ff372007dcb4f6c3d34187c9cc2da05 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: move cooked_index_worker_debug_info up + The next patch moves some functions to be methods of + cooked_index_worker_debug_info. Move cooked_index_worker_debug_info + above those functions, to make that easier (methods can't be defined + before the class declaration). + + Change-Id: I7723cb42efadb2cc86f2227b3c2fb275e2d620f9 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: clean up some cutu_reader::is_dummy() calls + This patch tries to standardize the places where we check if units are + dummy. When checking if a unit is dummy, it is not necessary to check + for some other conditions. + + - cutu_reader::is_dummy() is a superset of cutu_reader::cu() returning + nullptr, so it's not necessary to check if the cu method return + nullptr if also checking if the unit is dummy. + - cutu_reader::is_dummy() is a superset of cutu_reader::top_level_die() + returning nullptr, so same deal. + + Remove some spots that check for these conditions in addition to + cutu_reader::is_dummy(). + + In addition, also remove the checks for: + + !new_reader->top_level_die ()->has_children + + in cooked_indexer::ensure_cu_exists. IMO, it is not useful to special + case the units having a single DIE. Especially in this function, which + deals with importing things from another unit, a unit with a single DIE + would be an edge case that should not happen with good debug info. I + think it's preferable to have simpler code. + + Change-Id: I4529d7b3a0bd2891a60f41671de8cfd3114adb4a + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: avoid cutu_reader moves + In process_psymtab_comp_unit and ensure_cu_exists, we create a temporary + cutu_reader on the stack, then move it to a heap allocated cutu_reader + once we confirmed the unit is not dummy. I think it's unnecessary to + create a temporary cutu_reader. The only downside of not doing so is that if it + ends up that the CU is dummy, we made an allocation/deallocation for + nothing. Dummy CUs are a rare thing, it shouldn't change anything. + + This allows removing the cutu_reader move constructor. + + Change-Id: I44742d471c495055ee46db41c0e7bdfbd2d5c0b7 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: read multiple .debug_info.dwo sections + When building with gcc, with flags -gdwarf-5, -gsplit-dwarf and + -fdebug-types-section, the resulting .dwo files contain multiple + .debug_info.dwo sections. One for each type unit and one for the + compile unit. This is correct, as per DWARF 5, section F.2.3 ("Contents + of the Split DWARF Object Files"): + + The split DWARF object files each contain the following sections: + + ... + .debug_info.dwo (for the compilation unit) + .debug_info.dwo (one COMDAT section for each type unit) + ... + + GDB currently assumes that there is a single .debug_info.dwo section, + causing unpredictable behavior. For example, sometimes this crash: + + ==81781==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x508000007a71 at pc 0x58704d32a59c bp 0x7ffc0acc0bb0 sp 0x7ffc0acc0ba0 + READ of size 1 at 0x508000007a71 thread T0 + #0 0x58704d32a59b in bfd_getl32 /home/smarchi/src/binutils-gdb/bfd/libbfd.c:846 + #1 0x58704ae62dce in read_initial_length(bfd*, unsigned char const*, unsigned int*, bool) /home/smarchi/src/binutils-gdb/gdb/dwarf2/leb.c:92 + #2 0x58704aaf76bf in read_comp_unit_head(comp_unit_head*, unsigned char const*, dwarf2_section_info*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:47 + #3 0x58704aaf8f97 in read_and_check_comp_unit_head(dwarf2_per_objfile*, comp_unit_head*, dwarf2_section_info*, dwarf2_section_info*, unsigned char const*, rcuh_kind) /home/smarchi/src/binutils-gdb/gdb/dwarf2/comp-unit-head.c:193 + #4 0x58704b022908 in create_dwo_unit_hash_tables /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6233 + #5 0x58704b0334a5 in open_and_init_dwo_file /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7588 + #6 0x58704b03965a in lookup_dwo_cutu /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7935 + #7 0x58704b03a5b1 in lookup_dwo_comp_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8009 + #8 0x58704aff5b70 in lookup_dwo_unit /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2802 + + The first time that locate_dwo_sections gets called for a + .debug_info.dwo section, dwo_sections::info gets initialized properly. + The second time it gets called for a .debug_info.dwo section, the size + field in dwo_sections::info gets overwritten with the size of the second + section. But the buffer remains pointing to the contents of the first + section, because the section is already "read in". So the size does not + match the buffer. And even if it did, we would only keep the + information about one .debug_info.dwo, out of the many. + + First, add an assert in locate_dwo_sections to make sure we don't + try to fill in a dwo section info twice. Add the assert to other + functions with the same pattern, while at it. + + Then, change dwo_sections::info to be a vector of sections (just like we + do for type sections). Update locate_dwo_sections to append to that + vector when seeing a new .debug_info.dwo section. Update + open_and_init_dwo_file to read the units from each section. + + The problem can be observed by running some tests with the + dwarf5-fission-debug-types target board. For example, + gdb.base/condbreak.exp crashes (with the ASan failure shown above) + before the patch and passes after). + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119766 + + Change-Id: Iedf275768b6057dee4b1542396714f3d89903cf3 + Reviewed-By: Tom de Vries + +2025-04-29 Simon Marchi + + gdb/dwarf: scan .debug_info.dwo just once + When building -gsplit-dwarf and -fdebug-types-section in DWARF 5, the + resulting .dwo files will typically have a .debug_info.dwo section with + multiple type units followed by one compile unit: + + $ llvm-dwarfdump -F -color a-test.dwo | grep ' Unit' + 0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4) + 0x000008a4: Type Unit: length = 0x00000099, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'allocator', type_signature = 0x496a8791a842701b, type_offset = 0x0023 (next unit at 0x00000941) + ... + 0x000015c1: Compile Unit: length = 0x00000f58, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0xe8e359820d1c5803 (next unit at 0x0000251d) + + In open_and_init_dwo_file, we call create_dwo_cus_hash_table, which + scans the section, looking for compile units, then call + create_dwo_debug_types_hash_table, which scans the section again, + looking for type units. It would make more sense to scan the section + just once and handle both compile and type units at the same time. + + To achieve this, add create_dwo_unit_hash_tables, which knows how to + handle both unit kinds in a single scan. It replaces + create_dwo_cus_hash_table and create_dwo_debug_type_hash_table. Change + open_and_init_dwo_file to call it. + + Note that I removed the DWARF version check in open_and_init_dwo_file + when processing .debug_type.dwo sections: in DWARF 5, the + .debug_type.dwo sections will just not exist, so the + `dwo_file->sections.types` vector will be empty. + + Change-Id: I6e51d0ca06c258e0bf0e59927d62ae2df314a162 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: scan DWARF 5 DWO CUs by just reading the header + create_dwo_cus_hash_table is implemented by creating a cutu_reader + (which is somewhat heavy) for all units in a .dwo file. The purpose of + this cutu_reader is to be able to get the DWO ID, if it is specified by + a DW_AT_GNU_dwo_id attribute. + + In DWARF 5, however, the DWO ID is available in the CU header. We can + access it without accessing the DIEs, by just reading the header, which + is more lightweight. Add a new code path to create_dwo_cus_hash_table + that does that. The logic is copied from + create_dwo_debug_type_hash_table, which does this already. + + This change helps circumvent a performance problem I want to fix (the + same I was trying to fix in this patch [1]) when loading a file built + with -gdwarf-5, -gsplit-dwarf and -fdebug-types-section. In this + configuration, the produced .dwo files contain one compile unit and many + type units each. All units in a given .dwo share the same abbrev table. + Creating a cutu_reader for each unit meant re-reading the same abbrev + table over and over. What's particularly bad is that this is done with + the dwo_lock held, preventing other indexing threads from making + progress. + + To give a rough idea, here's the time take by each worker to index units + before this patch (on a rather large program): + + Time for "DWARF indexing worker": wall 18.627, user 0.885, sys 0.042, user+sys 0.927, 5.0 % CPU + Time for "DWARF indexing worker": wall 18.888, user 0.862, sys 0.042, user+sys 0.904, 4.8 % CPU + Time for "DWARF indexing worker": wall 19.172, user 1.848, sys 0.069, user+sys 1.917, 10.0 % CPU + Time for "DWARF indexing worker": wall 19.297, user 1.544, sys 0.051, user+sys 1.595, 8.3 % CPU + Time for "DWARF indexing worker": wall 19.545, user 3.408, sys 0.084, user+sys 3.492, 17.9 % CPU + Time for "DWARF indexing worker": wall 19.759, user 4.221, sys 0.117, user+sys 4.338, 22.0 % CPU + Time for "DWARF indexing worker": wall 19.789, user 4.187, sys 0.105, user+sys 4.292, 21.7 % CPU + Time for "DWARF indexing worker": wall 19.825, user 4.933, sys 0.135, user+sys 5.068, 25.6 % CPU + + And the times with this patch: + + Time for "DWARF indexing worker": wall 0.163, user 0.089, sys 0.029, user+sys 0.118, 72.4 % CPU + Time for "DWARF indexing worker": wall 0.176, user 0.096, sys 0.041, user+sys 0.137, 77.8 % CPU + Time for "DWARF indexing worker": wall 0.265, user 0.167, sys 0.054, user+sys 0.221, 83.4 % CPU + Time for "DWARF indexing worker": wall 0.353, user 0.257, sys 0.060, user+sys 0.317, 89.8 % CPU + Time for "DWARF indexing worker": wall 0.524, user 0.399, sys 0.088, user+sys 0.487, 92.9 % CPU + Time for "DWARF indexing worker": wall 0.648, user 0.517, sys 0.107, user+sys 0.624, 96.3 % CPU + Time for "DWARF indexing worker": wall 0.657, user 0.523, sys 0.107, user+sys 0.630, 95.9 % CPU + Time for "DWARF indexing worker": wall 0.753, user 0.612, sys 0.120, user+sys 0.732, 97.2 % CPU + + [1] https://inbox.sourceware.org/gdb-patches/20250326200002.136200-8-simon.marchi@efficios.com/ + + Change-Id: I34a422577e4c3ad7d478ec6df12a0e44d284c249 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb/dwarf: replace some "compile unit" terminology with "unit" + In DWARF 5 (and even previous versions, with type units), compile units + are just one type of units. In many places, we still use "compile + units" when in reality it would be better to talk about "units" (unless + we specifically want to talk about compile units). + + Rename comp-unit-head.{c.h} to unit-head.{c,h}, and do a big pass of + renames in it to remove the specific mentions of compile units, where in + fact we want to talk about units in general. + + Change-Id: Ia06c90ccb25756c366f269a12620f2f7c8378adb + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb: add some scoped_time_its to profile startup time + I'm investigating some issues where GDB takes a lot of time to start + up (read: for the DWARF index to be ready to do anything useful). + Adding those scoped_time_it instances helped me gain some insights about + where GDB spends time. I think they would be useful to have upstream, + to make investigating future problems easier. It would also be useful + to be able to give some numbers in the commit messages. + + Here's an example of what GDB outputs: + + Time for "minsyms install worker": wall 0.045, user 0.040, sys 0.004, user+sys 0.044, 97.8 % CPU + Time for "minsyms install worker": wall 0.511, user 0.457, sys 0.048, user+sys 0.505, 98.8 % CPU + Time for "minsyms install worker": wall 1.513, user 1.389, sys 0.111, user+sys 1.500, 99.1 % CPU + Time for "minsyms install worker": wall 1.688, user 1.451, sys 0.102, user+sys 1.553, 92.0 % CPU + Time for "minsyms install worker": wall 1.897, user 1.518, sys 0.089, user+sys 1.607, 84.7 % CPU + Time for "minsyms install worker": wall 2.811, user 2.558, sys 0.231, user+sys 2.789, 99.2 % CPU + Time for "minsyms install worker": wall 3.257, user 3.049, sys 0.188, user+sys 3.237, 99.4 % CPU + Time for "minsyms install worker": wall 3.617, user 3.089, sys 0.211, user+sys 3.300, 91.2 % CPU + Time for "DWARF indexing worker": wall 19.517, user 0.894, sys 0.075, user+sys 0.969, 5.0 % CPU + Time for "DWARF indexing worker": wall 19.807, user 0.891, sys 0.086, user+sys 0.977, 4.9 % CPU + Time for "DWARF indexing worker": wall 20.270, user 1.559, sys 0.119, user+sys 1.678, 8.3 % CPU + Time for "DWARF indexing worker": wall 20.329, user 1.878, sys 0.147, user+sys 2.025, 10.0 % CPU + Time for "DWARF indexing worker": wall 20.848, user 3.483, sys 0.224, user+sys 3.707, 17.8 % CPU + Time for "DWARF indexing worker": wall 21.088, user 4.285, sys 0.295, user+sys 4.580, 21.7 % CPU + Time for "DWARF indexing worker": wall 21.109, user 4.501, sys 0.274, user+sys 4.775, 22.6 % CPU + Time for "DWARF indexing worker": wall 21.198, user 5.087, sys 0.319, user+sys 5.406, 25.5 % CPU + Time for "DWARF skeletonless type units": wall 4.024, user 3.858, sys 0.115, user+sys 3.973, 98.7 % CPU + Time for "DWARF add parent map": wall 0.092, user 0.086, sys 0.004, user+sys 0.090, 97.8 % CPU + Time for "DWARF finalize worker": wall 0.278, user 0.241, sys 0.009, user+sys 0.250, 89.9 % CPU + Time for "DWARF finalize worker": wall 0.307, user 0.304, sys 0.000, user+sys 0.304, 99.0 % CPU + Time for "DWARF finalize worker": wall 0.727, user 0.719, sys 0.000, user+sys 0.719, 98.9 % CPU + Time for "DWARF finalize worker": wall 0.913, user 0.901, sys 0.003, user+sys 0.904, 99.0 % CPU + Time for "DWARF finalize worker": wall 0.776, user 0.767, sys 0.004, user+sys 0.771, 99.4 % CPU + Time for "DWARF finalize worker": wall 1.897, user 1.869, sys 0.006, user+sys 1.875, 98.8 % CPU + Time for "DWARF finalize worker": wall 2.534, user 2.512, sys 0.005, user+sys 2.517, 99.3 % CPU + Time for "DWARF finalize worker": wall 2.607, user 2.583, sys 0.006, user+sys 2.589, 99.3 % CPU + Time for "DWARF finalize worker": wall 3.142, user 3.094, sys 0.022, user+sys 3.116, 99.2 % CPU + + Change-Id: I9453589b9005c3226499428ae9cab9f4a8c22904 + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdb: add scoped_time_it + New in v2: + + - actually use m_enabled in the constructor and destructor + - output using gdb_stdlog->write_async_safe instead of gdb_printf + + scoped_time_it is a small utility that measures and prints how much time + a given thread spent in a given scope. Similar to the time(1) command, + it prints the time spent in user mode, system mode, and the wall clock + time. It also prints the CPU utilization percentage, which is: + + (user + sys) / wall + + This can help spot cases where the workload is not well balanced between + workers, or the CPU utilization is not optimal (perhaps due to + contention around a lock for example). + + To use it, just add it in some scope. For instance, a subsequent patch + adds it here: + + workers.add_task ([this, task_count, iter, last] () + { + scoped_time_it time_it ("DWARF indexing worker"); + process_cus (task_count, iter, last); + }); + + On destruction, if enabled, it prints a line showing the time spent by + that thread, similar to what time(1) prints. + + The example above prints this (one line for each worker thread): + + Time for "DWARF indexing worker": wall 0.173, user 0.120, sys 0.034, user+sys 0.154, 89.0 % CPU + Time for "DWARF indexing worker": wall 0.211, user 0.144, sys 0.047, user+sys 0.191, 90.5 % CPU + Time for "DWARF indexing worker": wall 0.368, user 0.295, sys 0.057, user+sys 0.352, 95.7 % CPU + Time for "DWARF indexing worker": wall 0.445, user 0.361, sys 0.072, user+sys 0.433, 97.3 % CPU + Time for "DWARF indexing worker": wall 0.592, user 0.459, sys 0.113, user+sys 0.572, 96.6 % CPU + Time for "DWARF indexing worker": wall 0.739, user 0.608, sys 0.115, user+sys 0.723, 97.8 % CPU + Time for "DWARF indexing worker": wall 0.831, user 0.677, sys 0.140, user+sys 0.817, 98.3 % CPU + Time for "DWARF indexing worker": wall 0.949, user 0.789, sys 0.144, user+sys 0.933, 98.3 % CPU + + The object is only enabled if per_command_time (controlled by "maint set + per-command time") is true at construction time. I wanted to avoid + adding a new command for now, but eventually if there are too many + scoped_time_it around the code base and we want to be able to enabled + them selectively (e.g. just the ones in the DWARF reader, or in the + symbol searching functions, etc), we could have a dedicated command for + that. + + I added this functionality to GDB because it relies on gdb_printf and + per_command_time, but if we ever need it in gdbsupport, I'm sure we + could find a way to put it there. + + Change-Id: I5416ac1448f960f44d85f8449943d994198a271e + Approved-By: Tom Tromey + +2025-04-29 Simon Marchi + + gdbsupport: move run_time_clock::now(user, system) out of run_time_clock + It is completely unrelated to run_time_clock, so I don't think it makes + sense to have it as a static function there. + + Move it to be a free function named "get_run_time". + + Change-Id: I0c3e4d3cc44ca37e523c94d72f7cd66add95645e + Approved-By: Tom Tromey + +2025-04-29 Tom Tromey + + Handle base type without DW_AT_byte_size + DWARF says that a base type can have DW_AT_bit_size, without + DW_AT_byte_size. However, gdb does not correctly handle this; in + fact, it crashes, as pointed out in this LLVM merge request: + + https://github.com/llvm/llvm-project/pull/137123 + + This patch reworks the base type size logic a bit to handle this + situation. + + Tested-by: Kevin Buettner + Approved-by: Kevin Buettner + +2025-04-29 Keith Seitz + + [gdb/contrib] Add script to license check new files + While reading through gdb-patches backlog after a return + from PTO, I noticed that a newly added file was licensed + with "MIT", and that license was not listed in Fedora's + gdb.spec file. [Fedora no longer supports "effective" + licenses.] + + That lead me to this simple script which generates a list + of all the newly added files between two given commits and + scans these files for licenses. + + Example usage: + bash$ cd /path/to/binutils-gdb/gdb + bash$ ./contrib/license-check-new-files.sh -s gdb-15-branchpoint gdb-16-branchpoint + Scanning directories gdb*/... + gdb/contrib/common-misspellings.txt: no longer in repo? + gdb/contrib/spellcheck.sh: no longer in repo? + gdbsupport/unordered_dense.h: MIT + + I don't think anything in here is Fedora- or RPM-specific, + so I'd like to submit this for consideration for inclusion + in contrib/. I believe other distros may find it useful. + + Approved-By: Tom Tromey + +2025-04-29 Jeremy Bryant + + Change acronym BFD to Binary File Descriptor. + This fixes a typo in gdb/README. + + Approved-By: Tom Tromey + +2025-04-29 Tom de Vries + + [gdb/testsuite] Fix gdb.base/ptype.exp with gcc 15 + With test-case gdb.base/ptype.exp and gcc 15 I run into: + ... + (gdb) ptype old_fptr^M + type = double (*)(void)^M + (gdb) FAIL: $exp: ptype old_fptr (compiler doesn't emit unprototyped types) + ... + + Since C23, non-prototype function declarations are no longer supported, so + "double (*old_fptr) ()" is interpreted as "double (*old_fptr) (void)". + + We could try to fix this by detecting the language dialect used, and accepting + the output in that case, but that feels fragile. + + We could try to fix this by hard-coding the language dialect, but that doesn't + work for all compilers. + + So instead, we opt for the simplest solution: just accept this output, and + produce a pass. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/32756 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 + +2025-04-29 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-objfile.exp with gcc 15 + When running test-case gdb.python/py-objfile.exp with gcc 15, we get: + ... + (gdb) p main^M + $2 = {int (void)} 0x40066c
^M + (gdb) FAIL: $exp: print main with debug info + ... + + The source file declares main as "int main ()" + ... + and until C23 this meant a non-prototype function declaration and we'd have: + ... + (gdb) p main^M + $2 = {int ()} 0x40066c
^M + ... + + However, starting C23 "int main ()" is simply equivalent to "int main (void)". + + Fix this by: + - declaring main as "int main (void)" in the test-case, and + - updating the regexp to expect an "int (void)" prototype. + + Likewise in gdb.base/jit-bfd-name.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/32756 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 + +2025-04-29 Tom de Vries + + [gdb/testsuite] Don't use string_to_regexp twice in gdb.base/options.exp + In test-case gdb.base/options.exp, in proc test_completer_recognizes we have: + ... + set expected_re [string_to_regexp $input_line] + test_gdb_complete_unique $input_line $expected_re + ... + + However, the first thing we do in proc test_gdb_complete_unique is to apply + string_to_regexp to the second argument: + ... + proc test_gdb_complete_unique { + input_line + complete_line + {append_char " "} + {max_completions false} + {testname ""} + } { + set complete_line_re [string_to_regexp $complete_line] + test_gdb_complete_unique_re \ + $input_line \ + $complete_line_re \ + $append_char \ + $max_completions\ + $testname + } + ... + + This happens to not cause any FAILs at the moment, but this should be done + only once. + + Fix this not using string_to_regexp in proc test_completer_recognizes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-04-29 Tom de Vries + + [gdb] Handle nullptr gdb_std{err,out} in {gdbpy,ioscm}_flush + Using the trigger patch described in the previous commit, I get: + ... + $ gdb + (gdb) error detected on stdin + + Fatal signal: Segmentation fault + ----- Backtrace ----- + 0x64c7b3 gdb_internal_backtrace_1 + /data/vries/gdb/src/gdb/bt-utils.c:127 + 0x64c937 _Z22gdb_internal_backtracev + /data/vries/gdb/src/gdb/bt-utils.c:196 + 0x94db83 handle_fatal_signal + /data/vries/gdb/src/gdb/event-top.c:1021 + 0x94dd48 handle_sigsegv + /data/vries/gdb/src/gdb/event-top.c:1098 + 0x7f372be578ff ??? + 0x10b7c0a _Z9gdb_flushP7ui_file + /data/vries/gdb/src/gdb/utils.c:1527 + 0xd4b938 gdbpy_flush + /data/vries/gdb/src/gdb/python/python.c:1624 + 0x7f372d73b276 _PyCFunction_FastCallDict + Objects/methodobject.c:231 + 0x7f372d73b276 _PyCFunction_FastCallKeywords + Objects/methodobject.c:294 + 0x7f372d794a09 call_function + Python/ceval.c:4851 + 0x7f372d78e838 _PyEval_EvalFrameDefault + Python/ceval.c:3351 + 0x7f372d796e6e PyEval_EvalFrameEx + Python/ceval.c:754 + 0x7f372d796e6e _PyFunction_FastCall + Python/ceval.c:4933 + 0x7f372d796e6e _PyFunction_FastCallDict + Python/ceval.c:5035 + 0x7f372d6fefc8 _PyObject_FastCallDict + Objects/abstract.c:2310 + 0x7f372d6fefc8 _PyObject_Call_Prepend + Objects/abstract.c:2373 + 0x7f372d6fe162 _PyObject_FastCallDict + Objects/abstract.c:2331 + 0x7f372d700705 callmethod + Objects/abstract.c:2583 + 0x7f372d700705 _PyObject_CallMethodId + Objects/abstract.c:2640 + 0x7f372d812a41 flush_std_files + Python/pylifecycle.c:699 + 0x7f372d81281d Py_FinalizeEx + Python/pylifecycle.c:768 + 0xd4d49b finalize_python + /data/vries/gdb/src/gdb/python/python.c:2308 + 0x9587eb _Z17ext_lang_shutdownv + /data/vries/gdb/src/gdb/extension.c:330 + 0xfd98df _Z10quit_forcePii + /data/vries/gdb/src/gdb/top.c:1817 + 0x6b3080 _Z12quit_commandPKci + /data/vries/gdb/src/gdb/cli/cli-cmds.c:483 + 0x1056577 stdin_event_handler + /data/vries/gdb/src/gdb/ui.c:131 + 0x1986970 handle_file_event + /data/vries/gdb/src/gdbsupport/event-loop.cc:551 + 0x1986f4b gdb_wait_for_event + /data/vries/gdb/src/gdbsupport/event-loop.cc:672 + 0x1985e0c _Z16gdb_do_one_eventi + /data/vries/gdb/src/gdbsupport/event-loop.cc:263 + 0xb66f2e start_event_loop + /data/vries/gdb/src/gdb/main.c:402 + 0xb670ba captured_command_loop + /data/vries/gdb/src/gdb/main.c:466 + 0xb68b9b captured_main + /data/vries/gdb/src/gdb/main.c:1344 + 0xb68c44 _Z8gdb_mainP18captured_main_args + /data/vries/gdb/src/gdb/main.c:1363 + 0x41a3b1 main + /data/vries/gdb/src/gdb/gdb.c:38 + --------------------- + A fatal error internal to GDB has been detected, further + debugging is not possible. GDB will now terminate. + + This is a bug, please report it. For instructions, see: + . + + Segmentation fault (core dumped) + $ q + ... + + Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and + likewise in ioscm_flush) such that we get instead: + ... + $ gdb + (gdb) error detected on stdin + $ q + ... + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + +2025-04-29 Tom de Vries + + [gdb] Fix sig_write for null gdb_stderr + When running test-case gdb.tui/tui-layout-asm.exp with target board + dwarf5-fission-debug-types, the test-case fails and I get a core dump: + ... + # of unexpected core files 1 + ... + + Looking at the backtrace of the core file, what seems to be happening is that: + - gdbpy_flush attempts to flush gdb_stdout, which is nullptr + - that causes a segfault + - gdb intercepts this and starts to handle it using handle_fatal_signal + - handle_fatal_signal calls sig_write, which attempts to write to gdb_stderr, + which is nullptr, + - that causes another segfault + - gdb exits + + I managed to reproduce the problem by the following trigger patch in + stdin_event_handler: + ... + - if (error) + + if (1 || error) + { + current_ui = main_ui; + ui->unregister_file_handler (); + - if (main_ui == ui) + + if (1 || main_ui == ui) + { + gdb_printf (gdb_stderr, _("error detected on stdin\n")); + + gdb_stderr = nullptr; + + gdb_stdout = nullptr; + + gdb_stdlog = nullptr; + quit_command ((char *) 0, 0); + } + ... + which gives us: + ... + $ gdb + (gdb) error detected on stdin + Segmentation fault (core dumped) + $ q + ... + + Fix sig_write to handle the case that gdb_stderr == nullptr, such that we get + instead: + ... + $ gdb + (gdb) error detected on stdin + + Fatal signal: Segmentation fault + ----- Backtrace ----- + ... + --------------------- + A fatal error internal to GDB has been detected, further + debugging is not possible. GDB will now terminate. + + This is a bug, please report it. For instructions, see: + . + + Segmentation fault (core dumped) + $ q + ... + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + +2025-04-29 Tom de Vries + + [gdb] Factor out sig_write + Lambda function sig_write: + ... + const auto sig_write = [] (const char *msg) -> void + { + gdb_stderr->write_async_safe (msg, strlen (msg)); + } + ... + is defined a few times. + + Factor this out into a regular function. + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + +2025-04-29 H.J. Lu + + elf: Properly set sh_offset for .tbss sections + Set sh_offset for .tbss sections to their nominal offset after aligning. + They are not loaded from disk so the value doesn't really matter, except + when the .tbss section is the first one in a PT_TLS segment. In that + case, it sets the p_offset for the PT_TLS segment, which according to + the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align. + + bfd/ + + PR ld/32896 + * elf.c (assign_file_positions_for_load_sections): Properly set + sh_offset for .tbss sections. + + ld/ + + PR ld/32896 + * testsuite/ld-elf/tbss4.d: New file. + * testsuite/ld-elf/tbss4.s: Likewise. + +2025-04-29 Vladimir Mezentsev + + gprofng not reading references correctly in Dwarf + Fixed as specified in the DWARF standard: + The first type of reference can identify any debugging information entry + within the containing unit. This type of reference is an offset from the first + byte of the compilation header for the compilation unit containing + the reference. There are five forms for this type of reference. + There are fixed length forms for one, two, four and eight byte offsets + (respectively, DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, and DW_FORM_ref8). + There is also an unsigned variable length offset encoded form that uses + unsigned LEB128 numbers (DW_FORM_ref_udata). + + gprofng/ChangeLog + 2025-04-27 Vladimir Mezentsev + + * src/DwarfLib.cc (set_die): Handling DWARF references (DW_FORM_ref1, + DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata). + * src/Dwarf.cc: Likewise. + +2025-04-29 H.J. Lu + + dwarf: Dump .debug_loclists only for DWARF-5 + .debug_loclists section is loaded into debug_information as DWARF-5 debug + info and .debug_loc section is loaded into debug_information as pre-DWARF-5 + debug info. When dumping .debug_loc section, we should only process + pre-DWARF-5 debug info in debug_information. When dumping .debug_loclists + section, we should only process DWARF-5 info in debug_information. + + binutils/ + + PR binutils/32809 + * dwarf.c (display_debug_loc): Dump .debug_loclists only for + DWARF-5. + + ld/ + + PR binutils/32809 + * testsuite/ld-x86-64/dwarf4.s: New file. + * testsuite/ld-x86-64/dwarf5a.s: Likewise. + * testsuite/ld-x86-64/dwarf5b.s: Likewise. + * testsuite/ld-x86-64/pr32809.d: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run pr32809. + +2025-04-29 GDB Administrator + + Automatic date update in version.in + +2025-04-28 Tom Tromey + + Fix "set debug parser" + While debugging my longer series, I discovered that I broken "set + debug parser" a couple years ago. This patch fixes it and adds a + minimal test case so that it, hopefully, will not break again. + + This patch also adds parser debugging to the C++ name canonicalizer. + + Thanks to Tom de Vries for fixing the test case. + +2025-04-28 Maciej W. Rozycki + + Regenerate more configury files for 64-bit BFD detection fix + The fix for 64-bit BFD detection omitted the regeneration of a bunch + of configury files; fix that. + +2025-04-28 Maciej W. Rozycki + + Fix 64-bit BFD detection causing build failures + We have a discrepancy with 64-bit BFD handling across our component + subdirectories leading to link failures such as: + + ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha' + ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64' + ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch' + ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips' + [...] + + with some configurations having a 32-bit host and 64-bit BFD, such as: + `--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'. + This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and + other subdirectorses and has been a regression from commit 1d5269c994bf + ("unify 64-bit bfd checks"). + + For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used + combined with this logic in bfd/configure.ac: + + case ${host64}-${target64}-${want64} in + *true*) + wordsize=64 + bfd64_libs='$(BFD64_LIBS)' + all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)' + [...] + ;; + false-false-false) + wordsize=32 + all_backends='$(BFD32_BACKENDS)' + ;; + esac + + where the value of ${wordsize} switches between 32-bit and 64-bit BFD + via these pieces: + + #define BFD_ARCH_SIZE @wordsize@ + + and: + + #if BFD_ARCH_SIZE >= 64 + #define BFD64 + #endif + + in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h". + + Then ${host64} is determined in bfd/configure.ac from the host's word + size, via the host's pointer size: + + if test "x${ac_cv_sizeof_void_p}" = "x8"; then + host64=true + fi + + And ${target64} is determined in bfd/configure.ac from the target's word + size: + + if test ${target_size} = 64; then + target64=true + fi + + Where multiple targets have been requested with `--enable-targets=all' + the presence of any 64-bit target will set "true" here. + + Finally ${want64} is set according to `--enable-64-bit-bfd' user option + with an arrangement involving BFD_64_BIT: + + BFD_64_BIT + if test $enable_64_bit_bfd = yes ; then + want64=true + else + want64=false + fi + + which also, redundantly, checks and sets its result upon the host's word + size. Lastly ${want64} is also selectively set by target fragments in + bfd/config.bfd, which mostly if not completely overlaps with ${target64} + setting as described above. + + Conversely other subdirectories only rely on BFD_64_BIT, so they fail to + notice that BFD is 64-bit and do not enable their 64-bit handling where + the host requested is 32-bit and 64-bit BFD has been enabled other than + with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c + enables calls to its numerous own 64-bit backends by checking the BFD64 + macro from "bfd.h", however does not actually enable said backends in + its Makefile. Hence the link errors quoted above. + + Address the problem then by moving the `--enable-64-bit-bfd' option back + to bfd/configure.ac and remove the call to BFD_64_BIT from there and + then rewrite the macro in terms of checking for the presence of BFD64 + macro in "bfd.h", which is the canonical way of determining whether BFD + is 64-bit or not. + + Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/ + fragment used to before the problematic commit: + + if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then + + run the preprocessor on "bfd.h", which allows to invoke the macro from + configure.ac files placed in subdirectories located at deeper levels, by + relying on the preprocessor's search path. + + This requires however that the invokers rely on `all-bfd' rather than + `configure-bfd' for their `configure' invocation stage, because "bfd.h" + is made by `make all' rather than `configure' in bfd/. + + Do not cache the result of this check however, as reconfiguring a tree + such as to flip `--enable-64-bit-bfd' on or to change a secondary target + may affect BFD64 and we have no access to information about secondary + targets in BFD_64_BIT. + + Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used + anywhere. + + Last but not least remove the hack from gdb/configure.ac to fail builds + for `mips*-*-*' hosts where `--enable-targets=all' has been requested, + but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds + complete successfully now, having enabled 64-bit BFD implicitly. + + Tested-By: Guinevere Larsen + Tested-By: Luis Machado + Approved-By: Alan Modra + Approved-By: Luis Machado + +2025-04-28 Tom de Vries + + [gdb/testsuite] Avoid generating gdb_leak_detector.cpython-.pyc + After running test-case gdb.python/py-color-leak.exp in a container where I + don't have PYTHONDONTWRITEBYTECODE set, I get: + ... + $ ls src/gdb/testsuite/gdb.python/__pycache__/ + gdb_leak_detector.cpython-313.pyc + ... + + Fix this by setting sys.dont_write_bytecode to True in the python scripts + importing the module. + + Tested on x86_64-linux. + +2025-04-28 Surya Kumari Jangala + + Update binutils/MAINTAINERS for PPC + binutils/ + * MAINTAINERS: Add myself as PPC maintainer. + +2025-04-28 Surya Kumari Jangala + + PowerPC: Support for Prefixed Add Immediate Shifted Instruction (RFC02686) + opcodes/ + * ppc-opc.c (insert_si32, extract_si32, insert_nsi32, + extract_nsi32): New functions. + (SI32, NSI32, P_D_SI32_MASK, P_DRAPCREL_SI32_MASK): New macros. + (IMM32): Update for new macros. + (powerpc_opcodes): Add plis, paddis, psubis. + + gas/ + * testsuite/gas/ppc/future.s: New test. + * testsuite/gas/ppc/future.d: Likewise. + +2025-04-28 GDB Administrator + + Automatic date update in version.in + +2025-04-27 GDB Administrator + + Automatic date update in version.in + +2025-04-26 Tom Tromey + + Add "maint canonicalize" command + This adds a new "maint canonicalize" command that can be used to see + the canonical form of a C++ name. I've needed this a few times when + debugging gdb. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Tom de Vries + +2025-04-26 Tom de Vries + + [gdb/contrib] Add codespell:ignore-begin/ignore-end (disabled) + It would be useful to tell codespell to ignore blocks of code. + + A feature ignore-multiline-regex exists, which can be used to implement this: + ... + $ codespell --ignore-multiline-regex \ + 'codespell:ignore-begin.*codespell:ignore-end' + ... + + Unfortunately there's a bug in codespell where using -w in + combination with --ignore-multiline-regex drops all newlines in the updated + file. + + In absence of a fix, commit this solution disabled, to locally document the + current state of this feature. + +2025-04-26 GDB Administrator + + Automatic date update in version.in + +2025-04-25 Tom Tromey + + Fix d10v sim build with GCC 15 + The d10v sim fails when built with GCC 15. From the bug: + + d10v/table.c:171:17: error: initialization of ‘void (*)(struct sim_state *, SIM_CPU *)’ {aka ‘void (*)(struct sim_state *, struct _sim_cpu *)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types] + 171 | { 0,0,0,0,0,0,0,(void (*)())0,0,{0,0,0}}, + | ^ + d10v/table.c:171:17: note: (near initialization for ‘Simops[165].func’) + + The bug here is that this is the wrong function pointer type. Since + '0' is perfectly fine here, this patch simply removes the cast. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32900 + Approved-By: Tom de Vries + +2025-04-25 Tom de Vries + + [pre-commit] Add codespell-log commit-msg hook + Now that we're using codespell to check spelling in gdb files, can we use + codespell to bring this spelling warning: + ... + $ echo usuable | codespell - + 1: usuable + usuable ==> usable + ... + to: + ... + $ git commit -a -m "Usuable stuff" + ... + ? + + First, let's look at a straightforward commit-msg hook implementation: + ... + - id: codespell + name: codespell-commit-msg + verbose: true + always_run: true + stages: [commit-msg] + ... + installed using: + ... + $ pre-commit install -t commit-msg + ... + + When trying the commit, we get: + ... + $ echo "/* bla */" >> gdb/gdb.c + $ git commit -a -m "Usuable stuff" + black................................................(no files to check)Skipped + flake8...............................................(no files to check)Skipped + isort................................................(no files to check)Skipped + codespell............................................(no files to check)Skipped + check-include-guards.................................(no files to check)Skipped + black................................................(no files to check)Skipped + flake8...............................................(no files to check)Skipped + codespell............................................(no files to check)Skipped + codespell-commit-msg.....................................................Failed + - hook id: codespell + - duration: 0.06s + - exit code: 65 + + .git/COMMIT_EDITMSG:1: Usuable ==> Usable + + check-include-guards.................................(no files to check)Skipped + $ + ... + + The commit was aborted, but the commit message is still there: + ... + $ cat .git/COMMIT_EDITMSG + Usuable stuff + ... + + We can retry and edit the commit message to clean up the typo: + ... + $ git commit -e -F .git/COMMIT_EDITMSG -a + ... + but it's a bit cumbersome. + + Furthermore, say we fix a typo and want to document this in the commit log, and + do: + ... + $ git commit -m "Fixed typo: useable -> usable" -a + ... + + This commit cannot succeed, unless we add a codespell ignore tag, which feels + like taking it too far. + + Both these problems can be addressed by setting things up in such a way that + the commit always succeeds, and codespell output is shown as a hint. + + Ideally, we'd tell to pre-commit to implement this using some setting, but + there doesn't seem to be one. + + So we use some indirection. Instead of using native codespell, use a local + hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit, + which calls codespell. + + Using this approach, we get: + ... + $ echo "/* bla */" >> gdb/gdb.c + $ git commit -a -m "Usuable stuff" + black................................................(no files to check)Skipped + flake8...............................................(no files to check)Skipped + isort................................................(no files to check)Skipped + codespell............................................(no files to check)Skipped + check-include-guards.................................(no files to check)Skipped + black................................................(no files to check)Skipped + flake8...............................................(no files to check)Skipped + codespell............................................(no files to check)Skipped + check-include-guards.................................(no files to check)Skipped + codespell-log............................................................Passed + - hook id: codespell-log + - duration: 0.18s + + codespell-log-internal...................................................Failed + - hook id: codespell + - exit code: 65 + + .git/COMMIT_EDITMSG:1: Usuable ==> Usable + + [codespell/codespell-log-2 d081bd25a40] Usuable stuff + 1 file changed, 1 insertion(+) + $ + ... + + This is obviously convoluted, but it works. Perhaps we can propose a + pre-commit improvement (always_pass) and simplify this eventually. + + Checked new script codespell-log.sh with shell-check. + + Approved-By: Simon Marchi + +2025-04-25 Guinevere Larsen + + gdb: fix 32 bit build + The recent commit dbbb9cfd3708a5b09b449c6cbc4d74dfec13904d added a + message using %ld to print an std::vector::size, which is of size_t + type. on 64 bit machines, size_t will be an unsigned long int, making + %ld work just fine, but on 32 bit ones, size_t will be unsigned int, + which causes the build to fail. + + This commit fixes that by using %zu instead. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32901 + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-25 Guinevere Larsen + + Revert "gdb: update corner case when canonicalizing riscv syscall names" + This reverts commit b2aba1ce1326df73c03641e1cb01d2c5aa577015. + That commit was pushed in error, as I confused which patch was approved + in the list + +2025-04-25 Pali Roh?r + + BFD linker: Allow target backends to provide alternate entry names. + PR 30144 + +2025-04-25 Simon Marchi + + gdb/dwarf: add dwarf2_cu::find_die method + I added this small helper method in the series I'm writing, to make + finding a DIE by section offset a bit nicer than using the unordered_set + methods. It doesn't have any dependencies, so I thought I would submit + it on its own. + + Change-Id: If7313194ab09d9bd6d6a52c24eb6fd9a9c1b76e0 + Approved-by: Kevin Buettner + +2025-04-25 GDB Administrator + + Automatic date update in version.in + +2025-04-24 Simon Marchi + + gdbsupport: add missing include guard to remote-args.h + Also, fix a type in "namespace". + + Change-Id: I3e5d1d49c765a035217437c0635b12dc28e41bf6 + +2025-04-24 Simon Marchi + + pre-commit autoupdate + Run `pre-commit autoupdate`. This brings in new versions of isort and + flake8. + + Change-Id: I55f8b51b100e090e9a210338f46e10cf131a4aa7 + Approved-By: Tom Tromey + +2025-04-24 Simon Marchi + + gdb: fix some flake8 F824 warnings + flake8 7.2.0 appears to have this new warning: + + F824: global name / nonlocal name is unused: name is never assigned in scope + + It points out a few places in our code base where "global" is not + necessary, fix them. + + Change-Id: Ia6fb08686977559726fefe2a5bb95d8dcb298bb0 + Approved-By: Tom Tromey + +2025-04-24 Tom Tromey + + Use correct sign extension for enumeration types + This changes update_enumeration_type_from_children to use the correct + sign-extension method on the attribute. The logic here is a bit + complicated: if the enum has an underlying type, then we use that + type's signed-ness to interpret attributes; otherwise we must assume + attributes are encoded as signed values. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use bool in update_enumeration_type_from_children + This is just a small preliminary cleanup to use 'bool' in + update_enumeration_type_from_children. + +2025-04-24 Tom Tromey + + Remove dead code from dwarf2_const_value_data + dwarf2_const_value_data checks the size of the data like so: + + if (bits < sizeof (*value) * 8) + ... + else if (bits == sizeof (*value) * 8) + ... + else + ... + + However, 'bits' can only be 8, 16, 32, or 64. And, because 'value' is + a LONGEST, which is alwasy 64-bit, the final 'else' can never be + taken. + + This patch removes the dead code. And, because this was the only + reason for a non-void return value, the return type is changed as + well. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::signed_constant in attribute::as_boolean + This changes attribute::as_boolean to use attribute::signed_constant. + This is maybe overkill but lets any reasonable constant form through. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use correct sign for variant part discriminants + The discriminant value for a variant part may be signed or unsigned, + depending on the type of the variant. This patch changes the DWARF + reader to delay interpretation of the relevant attribute until the + signed-ness is known. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use correct sign in get_mpz + This changes dwarf2/read.c:get_mpz to use the correct sign-extension + function. Normally a rational constant uses signed values, but a + purely unsigned form also seems fine here. This adds a new + attribute::form_is_strictly_unsigned, which is more precise than + form_is_unsigned (which accepts a lot of forms that aren't really for + ordinary constants). + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::unsigned_constant for DW_AT_data_member_location + This changes the DWARF reader to use attribute::unsigned_constant for + DW_AT_data_member_location. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::unsigned_constant for DW_AT_data_bit_offset + This changes the DWARF reader to use attribute::unsigned_constant when + examining DW_AT_data_bit_offset. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use correct sign for DW_AT_GNU_bias + DW_AT_GNU_bias may be signed or unsigned, depending on the underlying + type. This patch changes the DWARF reader to examine the type before + decoding the attribute. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::unsigned_constant for DW_AT_bit_stride + DW_AT_bit_stride uses an unsigned constant, so make this explicit in + the reader. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::signed_constant for fixed-point scale + This changes the DWARF reader to use attribute::signed_constant for + DW_AT_binary_scale and DW_AT_decimal_scale. (FWIW these were the + attributes that first lead me to find this problem.) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Introduce attribute::signed_constant + This introduces a new method, attribute::signed_constant. This should + be used wherever DWARF specifies a signed integer constant, or where + this is implied by the context. It properly handles sign-extension + for DW_FORM_data*. + + To my surprise, there doesn't seem to be a pre-existing sign-extension + function. I've added one to common-utils.h alongside the align + functions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Tom Tromey + + Use attribute::unsigned_constant for sizes + This changes the DWARF reader to use attribute::unsigned_constant for + DW_AT_bit_size, DW_AT_byte_size, DW_AT_data_byte_size, and + DW_AT_string_length. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + +2025-04-24 Guinevere Larsen + + gdb: update corner case when canonicalizing riscv syscall names + The script syscalls/riscv-canonicalize-syscall-gen.py has been recently + introduced to help support record-full in riscv systems. However, it + was developed before commit 432eca4113d5748ad284a068873455f9962b44fe, + which made the GDB enum more consistent, which forced the python script + to have a corner case for the "gdb_old_mmap" case. + + Since the aforementioned commit has already been merged, we need to + update the special case for the mmap syscall. A special case is still + needed because the script would expect that the glibc sources call the + syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which + happens unfortunately. + + This commit doesn't change the .c file because it was already fixed by a + different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was + pushed as obvious to fix the build issues. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Tom Tromey + + Fix documentation for gdb.blocked_signals + gdb exports a context manager named gdb.blocked_signals, but the + documentation erroneously refers to it as gdb.block_signals. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32891 + Approved-By: Eli Zaretskii + Approved-By: Tom de Vries + +2025-04-24 Kevin Buettner + + Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + New test - gdb.base/tls-dlobj.exp + This test exercises musl_link_map_to_tls_module_id() and + glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c. + + Prior to writing this test, I had only written what is now named + 'musl_link_map_to_tls_module_id' and it worked for both GLIBC and + MUSL. Once I wrote this new test, tls-dlobj.exp, there were a number + of tests which didn't work with GLIBC. This led me to write a + GLIBC-specific link map to module id function, i.e, + 'glibc_link_map_to_tls_module_id'. + + It only has one compilation scenario, in which the pthread(s) library + is used - as noted in a comment, it became too much of a hassle to try + to KFAIL things, though it certainly could have been done in much the + same was as was done in gdb.base/multiobj.exp. It didn't seem that + important to do so, however, since I believe that the other tests + have adequate coverage for different compilation scenarios. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + New test - gdb.base/tls-multiobj.exp + This test exercises GDB's internal TLS support when both the main + program and several shared libraries have TLS variables. It also + tests existing (non-internal) TLS support too. + + It tests using two compilation scenarios, "default", in which + libpthread is not linked with the program and libraries as well + as one which does use libpthread. + + It tests link map address to module id mapping code in GDB + in addition to the ability of GDB to traverse TLS data structures + with several libraries in play. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + New test - gdb.base/tls-nothreads.exp + This commit introduces a new test, gdb.base/tls-nothreads.exp. + + It has a test case, a C file, which has several TLS variables in the + main program, which, once compiled and linked, should end up (in ELF + files) in .tdata and .tbss. The test compiles the program in a number + of different ways, making sure that each variable is accessible + regardless of how it was compiled. + + Note that some of the compilation scenarios end up with a statically + linked executable. Prior to this series of commits, accessing TLS + variables from a statically linked program on Linux did not work. + For certain targets (x86_64, aarch64, s390x, riscv, and ppc64), + all on Linux, support has been added to GDB for accessing thread + local storage in statically linked executables. This test is + important for testing those build scenarios. + + But it's also important to make sure that GDB's internal TLS support + works for other scenarios too. In order to accomplish that, the + tests are also run in a mode which forces the internal support to + be used. + + It also adds a new file, gdb.base/tls-common.exp.tcl, which includes + some common definitions used by the three new TLS tests, including + the one added by this commit. In particular, it sets a TCL variable, + 'internal_tls_linux_targets' which list the targets mentioned earlier. + This means that as internal TLS support is added for other targets, + the target should be listed in just one file as opposed to three + (or more if other tests using tls-common.exp.tcl are added). + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Delete disabled i386 internal TLS support + As mentioned in the previous commit, this commit deletes the disabled + code which could be used to implement internal TLS support for the + i386 target. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Internal, but disabled, TLS support for i386 + This commit shows how internal TLS address lookup support could + be implemented for the i386 target. + + Unfortunately, it doesn't work due to I386_GSBASE_REGNUM being + unavailable for Linux targets. I looked at trying to access the + gsbase register via PTRACE_GET_THREAD_AREA, but did not understand + it well enough to finish it. Since the i386 target is much less + important than it used to be, I gave up working on it. + + I don't want to leave this disabled code in our sources, so I + will delete it in the next commit, however, this commit will be + in our git repo, so it'll be available for someone with sufficient + interest in the i386 target to look at. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x + For each architecture, aarch64, x86_64, riscv, ppc64, and s390x, + this commit defines a suitable 'get_tls_dtv_addr' method and, + when necessary, a 'get_tls_dtp_offset' method. + + It also registers svr4_tls_get_thread_local_address, defined in + svr4-tls-tdep.c (in an earlier commit), as the + get_thread_local_address gdbarch method. It also registers its + architecture specific code using svr4_tls_register_tls_methods(). + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Implement internal TLS address lookup for select Linux targets + This commit adds non-architecture-specific support for internal TLS + address lookup for targets which register their support with the new + file svr4-tls-tdep.c. By "internal", I mean support which does not + rely on libthread_db. Knowledge of how to traverse TLS data + structures is contained in this commit along with the next commit + containing architecture specific knowledge regarding TLS offsets, + registers, and such. + + The new function 'svr4_tls_get_thread_local_address' is a gdbarch method. + It should be passed as an argument to + set_gdbarch_get_thread_local_address in architecture specific + -linux-tdep.c files which wish to offer internal TLS support. + + The architecture specific tdep files need to define a get_tls_dtv_addr + method - as the name suggests, it needs to return the address of the + DTV (dynamic thread vector) via architecture specific means. This + usually entails fetching the thread pointer via a register or registers + assigned to this purpose, and then using that value to locate the + address of the DTV from within the TCB (thread control block). + + Additionally, some architectures also need to provide a DTP offset, + which is used by the MUSL C library to adjust the value obtained + from a DTV entry to that of the start of the TLS block for a particular + thread. This is provided, when necessary, by a get_tls_dtp_offset + method. + + Both methods, get_tls_dtv_addr and get_tls_dtp_offset, are registered + with data structures maintained by linux-tdep.c via the new function + svr4_tls_register_tls_methods(). Thus, for example, on RISC-V, + riscv_linux_init_abi() will make the following two calls, the first + for registering the internal get_thread_local_address gdbarch method + and the second for registering riscv-specific methods for obtaining + the DTV address and DTP offset: + + set_gdbarch_get_thread_local_address (gdbarch, + svr4_tls_get_thread_local_address); + svr4_tls_register_tls_methods (info, gdbarch, riscv_linux_get_tls_dtv_addr, + riscv_linux_get_tls_dtp_offset); + + Internal TLS support is provided for two C libraries, GLIBC, and MUSL. + Details for accessing the various TLS data structures differ between + these libraries. As a consequence, linux-tdep.h defines a new enum, + svr4_tls_libc, with values svr4_tls_libc_unknown, svr4_tls_libc_musl, + and svr4_tls_libc_glibc. A new static function libc_tls_sniffer uses + heuristics to (try to) decide whether a program was linked against + GLIBC or MUSL. Working out what the heuristics should be, especially + for statically linked binaries, turned out to be harder than I thought + it would be. + + A new maintenance setting, force-internal-tls-address-lookup, has been + added, which, when set to 'on', will (as the name suggests) force the + internal TLS lookup mechanisms to be used. Otherwise, if thread_db + support is available (via the thread stratum), that will be preferred + since it should be more accurate. I expect that this setting will be + mostly used by test cases in the GDB test suite. The new test cases + that are part of this series all use it, with iterations using both + 'on' and 'off' for all of the tests therein. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Track and fetch TLS module ids for MUSL and GLIBC + This commit adds, to solib-svr4.h and solib-svr4.c, functions + glibc_link_map_to_tls_module_id and musl_link_map_to_tls_module_id for + use with callers in a new file svr4-tls-tdep.c (which is not in this + commit). It adds a number of helper functions for implementing link + map to module id support. + + It also renames existing function 'find_program_interpreter' to + 'svr4_find_program_interpreter' and makes it visible to other source + files within GDB. It will be used in the libc sniffing code in + svr4-tls-tdep.c in a later commit in this series. The libc sniffer is + needed in order to know which link map to module id function to call + as the method for determining module ids differs between libc / + dynamic linker implementations. These details are discussed in + comments in the patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Allow TLS access to work in gdb.server/no-thread-db.exp + The patches later in the series add GDB-internal TLS support for + certain targets. This commit updates the "print foo" test in + gdb.server/no-thread-db.exp to accept either a TLS failure (when + libthread_db isn't available) or printing the correct answer, which + will occur when GDB's internal TLS address resolution can be used. + + I'm making this change prior to the commits which actually add + the GDB-internal TLS support in order to avoid tripping regression + testers. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Kevin Buettner + + Don't attempt to find TLS address when target has no registers + This commit fixes two bugs, one of which is Bug 25807, which occurs + when target_translate_tls_address() is called from + language_defn::read_var_value in findvar.c. I found it while testing on + aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local + into a FAIL due to a GDB internal error. Now, with this commit in place, + the KFAIL/FAIL turns into a PASS. + + In addition to the existing test just noted, I've also added a test to + the new test case gdb.base/tls-nothreads.exp. It'll be tested, using + different scenarios, up to 8 times: + + PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: after exit: print tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: after exit: print tls_tbss_1 + + There is a related problem that occurs when target_translate_tls_address + is called from find_minsym_type_and_address() in minsyms.c. It can be + observed when debugging a program without debugging symbols when the + program is not executing. I've written a new test for this, but it's + (also) included in the new test case gdb.base/tls-nothreads.exp, found + later in this series. Depending on the target, it can run up to 8 + times using different scenarios. E.g., on aarch64, I'm seeing these + PASSes, all of which test this change: + + PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1 + PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1 + + In an earlier version of this commit (v4), I was checking whether the + target has registers in language_defn::read_var_value in findvar.c and + in find_minsym_type_and_address in minsyms.c, printing suitable error + messages in each case. In his review of this commit for the v4 + series, Tom Tromey asked whether it would be better to do this check + in target_translate_tls_address. I had considered doing that for the + v4 (and earlier) series, but I wanted to print slightly different + messages at each check. Also, read_var_value in findvar.c was already + printing a message in some cases and I had arranged for the later + check in that function to match the original message. + + However, while I had added a target-has-registers check at two of the + call sites for target_translate_tls_address, I hadn't added it at the + third call site which is in dwarf_expr_context::execute_stack_op() in + dwarf2/expr.c. I believe that in most cases, this is handled by the + early check in language_defn::read_var_value... + + else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ()) + error (_("Cannot read `%s' without registers"), var->print_name ()); + + ...but it's entirely possible that dwarf_expr_context::execute_stack_op() + might get called in some other context. So it makes sense to do the + target-has-registers check for that case too. And rather than add yet + another check at that call site, I decided that moving the check and + error message to target_translate_tls_address makes sense. + + I had to make the error messages that it prints somewhat more generic. + In particular, when called from language_defn::read_var_value, the + message printed by target_translate_tls_address no longer matches the + earlier message that could be printed (as shown above). That meant + that the test cases which check for this message, gdb.threads/tls.exp, + and gdb.base/tls-nothreads.exp had to be adjusted to account for the + new message. Also, I think it's valuable to the user to know (if + possible) the name of the variable that caused the error, so I've + added an optional parameter to target_translate_tls_address, providing + the name of the variable, if it's known. Therefore, the message + that's printed when the target-has-registers test fails is one of the + following: + + When the TLS variable isn't known (due to being called from + dwarf_expr_context::execute_stack_op): + + "Cannot translate TLS address without registers" + + When the TLS variable is known (from either of the other two call sites + for target_translate_tls_address): + + "Cannot find address of TLS symbol `%s' without registers" + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807 + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-24 Simon Marchi + + gdb: fix completion of anonymous struct members + Completing fields inside an anonymous struct does not work. With: + + struct commit_counters_hot { + union { + struct { + long owner; + }; + char padding[16]; + }; + }; + + I get: + + (gdb) complete print cc_hot. + print cc_hot.padding + + After this patch, I get: + + (gdb) complete print cc_hot. + print cc_hot.owner + print cc_hot.padding + + Update break1.c to include an anonymous struct. The tests that complete + "z_field" inside gdb.base/completion.exp would start to fail without the + fix. + + Change-Id: I46b65a95ad16b0825de58dfa241777fe57acc361 + Reviewed-By: Keith Seitz + +2025-04-24 Simon Marchi + + gdb: fix some Python files formatting + Running `pre-commit run --all-files` introduces these fixes. + + Change-Id: I2e363fdf988b66d83008265b3ca8d1120f84b95d + +2025-04-24 Andrew Burgess + + gdb: add remote argument passing unit tests + This commit adds some remote argument passing unit tests. There are + not many tests right now -- there are known bugs in the remote + argument passing mechanism (see PR gdb/28392) -- but some simple cases + are covered here, and I plan to add additional tests once I've fixed + more of the problems with the existing argument handling code. + + The tests take an inferior argument string, this is the string that + GDB would carry around as inferior::m_args. This string is then split + using gdb::remote_args::split, this gives a vector of strings, these + are the strings that are passed over the remote protocol. These split + strings are validated as part of the test. + + The split strings are then combined using gdb::remote_args::join which + gives the inferior argument string that gdbserver will use, this is + held in server.cc as program_args, this joined string is then checked + as part of the test. + + There are no changes to GDB's behaviour as part of this commit, other + than adding the new tests which can be run with: + + (gdb) maintenance selftest remote-args + Running selftest remote-args. + Ran 1 unit tests, 0 failed + + Tested-By: Guinevere Larsen + +2025-04-24 Andrew Burgess + + gdb: move remote arg splitting and joining into gdbsupport/ + This is a refactoring commit. When passing inferior arguments to + gdbserver we have two actions that need to be performed, splitting and + joining. + + On the GDB side, we take the inferior arguments, a single string, and + split the string into a list of individual arguments. These are then + sent to gdbserver over the remote protocol. + + On the gdbserver side we receive the list of individual arguments and + join these back together into a single inferior argument string. + + In the next commit I plan to add some unit testing for this remote + argument passing process. Ideally, for unit testing, we need the code + being tested to be located in some easily callable function, rather + than being inline at the site of use. + + So in this commit I propose to move the splitting and joining logic + out into a separate file, we can then use this within GDB and + gdbserver when passing arguments between GDB and gdbserver, but we can + also call the same functions for some unit testing. + + In this commit I'm not adding the unit tests, they will be added next, + so for now there should be no user visible changes after this commit. + + Tested-By: Guinevere Larsen + +2025-04-24 Claudiu Zissulescu + + gas: sframe: fix handling of .cfi_def_cfa_register + Fix PR gas/32879 sframe: Assembler internal error when translating + cfi_def_cfa_register + + As per the documentation, .cfi_def_cfa_register modifies a rule for + computing CFA; the register is updated, but the offset remains the same. + + While translating .cfi_def_cfa_register into SFrame context, we use the + information from last translated FRE to set the CFA offset. However, + there may be cases when the last translated FRE is empty. Use last FRE + only if available. + +2025-04-24 GDB Administrator + + Automatic date update in version.in + +2025-04-24 Andrew Burgess + + gdb/python: keyword arguments for gdb.Color.escape_sequence + GDB's Python documentation does make it clear that keywords arguments + are supported for functions that take 2 or more arguments. The + documentation makes no promise for keyword argument support on + functions that only take a single argument. + + That said, I'm a fan of keyword arguments, I think they help document + the code, and make intentions clearer, even for single argument + functions. + + As I'm changing gdb.Color anyway (see previous commit), I'd like to + add keyword argument support to gdb.Color.escape_sequence, even though + this is a single argument method. This should be harmless for anyone + who doesn't want to use keywords, but adds the option for those of us + that do. + + I've also removed a redundant check that the 'self' argument was a + gdb.Color object; Python already ensures this is the case. + + And I have folded the check that the single argument is a bool into + the gdb_PyArg_ParseTupleAndKeywords call, this means that the error + message will include the incorrect type name now, which should make + debugging issues easier. + + Tests have been extended to cover both cases -- it appears the + incorrect argument type error was not previously tested, so it is + now. + + Approved-By: Tom Tromey + +2025-04-24 Andrew Burgess + + gdb/python: keyword args for Color.__init__ + GDB's Python API documentation is clear: + + Functions and methods which have two or more optional arguments allow + them to be specified using keyword syntax. + + The gdb.Color.__init__ method matches this description, but doesn't + support keyword arguments. + + This commit fixes this by adding keyword argument support. + + There's a new test to cover this functionality. + + Approved-By: Tom Tromey + +2025-04-24 Andrew Burgess + + gdb/doc: tweaks to documentation for gdb.Color + While reading through the documentation for the new gdb.Color class I + spotted a couple of things which I thought could be improved: + + * I replaced @code{Color} with @code{gdb.Color}. Most of the other + classes are referenced with the 'gdb.' prefix, so this makes + gdb.Color consistent. Including the 'gdb.' prefix makes it far + easier to search the documentation to find relevant content. And + finally, my understanding is that usually in Python code, the + class would be written as 'gdb.Color' unless the user specifically + pulls 'Color' into the current scope using 'from gdb import + Color'. + + * Replace 'colorspace' with 'color space'. There was already a use + of the two word form in the documentation (for gdb.Color), so this + just makes things consistent. + + * Removed use of @var on two @defun lines. No other @defun lines + use @var, so the use of @var here was making the output + inconsistent, e.g. in the 'info' output, @var causes the string to + be capitalised. + + * Rename the 'color-space' argument to 'color_space' for + Color.__init__. In the next commit I plan to add Python keyword + argument support to this function, which means the argument name + needs to be a valid keyword (i.e. must not contain the '-' + character). + + * Added a pointer to where the @samp{COLORSPACE_} constants can be + found. These constants are referenced before they are defined in + the documentation, which is fine, but I think it is a good idea to + let the user know where the constants can be found when we first + reference them. + + * Remove use of 'self' for the Color.escape_sequence documentation. + There are a few functions that do include 'self' as an argument (I + think this is a mistake) but the vast majority don't. I think not + including 'self' is the better approach; a user wouldn't be + expected to explicitly pass 'self', this is done automatically by + Python as a result of calling the method on an object. So I've + removed the reference to 'self' from this method. + + Approved-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-04-23 Andrew Burgess + + gdb/python: don't use PyObject_IsInstance in py-unwind.c + I've been reviewing all uses of PyObject_IsInstance, and I believe + that the use of PyObject_IsInstance in py-unwind.c is not entirely + correct. The use of PyObject_IsInstance is in this code in + frame_unwind_python::sniff: + + if (PyObject_IsInstance (pyo_unwind_info, + (PyObject *) &unwind_info_object_type) <= 0) + error (_("A Unwinder should return gdb.UnwindInfo instance.")); + + The problem is that PyObject_IsInstance can return -1 to indicate an + error, in which case a Python error will have been set. Now, the + above code appears to handle this case, it checks for '<= 0', however, + frame_unwind_python::sniff has this near the start: + + gdbpy_enter enter_py (gdbarch); + + And looking in python.c at 'gdbpy_enter::~gdbpy_enter ()', you'll + notice that if an error is set then the error is printed, but also, we + get a warning about an unhandled Python exception. Clearly, all + exceptions should have been handled by the time the gdbpy_enter + destructor is called. + + I've added a test as part of this commit that exposes this problem, + the current output is: + + (gdb) backtrace + Python Exception : error in Blah.__class__ + warning: internal error: Unhandled Python exception + Python Exception : A Unwinder should return gdb.UnwindInfo instance. + #0 corrupt_frame_inner () at /home/andrew/projects/binutils-gdb/build.dev-g/gdb/testsuite/../../../src.dev-g/gdb/test> + (gdb) + + An additional observation is that we use PyObject_IsInstance to check + that the return value is a gdb.UnwindInfo, or a sub-class. However, + gdb.UnwindInfo lacks the Py_TPFLAGS_BASETYPE flag, and so cannot be + sub-classed. As such, PyObject_IsInstance is not really needed, we + could use PyObject_TypeCheck instead. The PyObject_TypeCheck function + only returns 0 or 1, there is no -1 error case. Switching to + PyObject_TypeCheck then, fixes the above problem. + + There's a new test that exposes the problems that originally existed. + + Approved-By: Tom Tromey + +2025-04-23 Andrew Burgess + + gdb/python: don't use PyObject_IsInstance in py-registers.c + In python/py-registers.c we make use of PyObject_IsInstance. The + PyObject_IsInstance can return -1 for an error, 0 for false, or 1 for + true. + + In py-registers.c we treat the return value from PyObject_IsInstance + as a boolean, which means both -1 and 1 will be treated as true. + + If PyObject_IsInstance returns -1 for an error, this will be treated + as true, we will then invoke undefined behaviour as the pyo_reg_id + object will be treated as a gdb.RegisterDescriptor, even though it + might not be. + + I noticed that the gdb.RegisterDescriptor class does not have the + Py_TPFLAGS_BASETYPE flag, and therefore cannot be inherited from. As + such, using PyObject_IsInstance is not necessary, we can use + PyObject_TypeCheck instead. The PyObject_TypeCheck function only + returns 0 or 1, so we don't need to worry about the error case. + + Approved-By: Tom Tromey + +2025-04-23 Simon Marchi + + gdb/testsuite: split gdb.dwarf2/macro-source-path.exp + Because it runs so many variations, the test + gdb.dwarf2/macro-source-path.exp takes about 2:40 minutes to run for me, + in a non-optimized build. These days I often run all tests under + gdb.dwarf2, as a sanity test for my changes, and so I often have to wait + for this test to complete. + + Split the test, to allow it to complete faster when running the + testsuite in parallel. After this patch, running all the + gdb.dwarf2/macro-source-path-*.exp tests in parallel takes me about 1 + minute. It's more that I would expect, I would expect the time to be + divided by nearly 5, but it's already better than what we have now. + + Change-Id: I07e4e1f234cf57d9b0c1c027f08061615714a4d5 + Acked-By: Tom de Vries + +2025-04-23 Timur + + gdb: fix riscv record-full push + When I (Guinevere) pushed commit + b9c7eed0c2409fc640129a38d80a2bf1212b464a I accidentally used an outdated + version of the patch. This current patch fixes the importation of that + patch based on the actually approved version instead. + +2025-04-23 Tom de Vries + + [gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp + With a gdb 16.2 based package, I ran into: + ... + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: input still accepted + interrupt + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: interrupt + set var do_wait=0 + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: set var do_wait=0 + continue& + Cannot execute this command while the selected thread is running. + (gdb) + Program received signal SIGINT, Interrupt. + PASS: gdb.base/bg-execution-repeat.exp: c 1&: continue& + 0x00007ffff7cf1503 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6 + FAIL: gdb.base/bg-execution-repeat.exp: c 1&: breakpoint hit 2 (timeout) + ... + + Fix this by waiting for "Program received signal SIGINT, Interrupt" after + issuing the interrupt command. + + Tested on x86_64-linux. + +2025-04-23 Andrew Burgess + + gdb/python: don't use PyObject_IsInstance in gdbpy_is_color + The gdbpy_is_color function uses PyObject_IsInstance, and converts the + return from PyObject_IsInstance to a bool. + + Unfortunately, PyObject_IsInstance can return -1, 0, or 1, for error, + failure, or success respectively. When converting to a bool both -1 + and 1 will convert to true. + + Additionally, when PyObject_IsInstance returns -1 an error will be + set. + + What this means is that, if gdbpy_is_color is called with a non + gdb.Color object, and the PyObject_IsInstance check raises an error, + then (a) GDB will continue as if the object is a gdb.Color object, + which is likely going to invoke undefined behaviour, see + gdbpy_get_color for example, and (b) when GDB eventually returns to + the Python interpreter, due to an error being set, we'll see: + + Python Exception : PyEval_EvalFrameEx returned a result with an error set + Error occurred in Python: PyEval_EvalFrameEx returned a result with an error set + + However, after the previous commit, gdb.Color can no longer be + sub-classed, this means that fixing the above problems is easy, we can + replace the PyObject_IsInstance check with a PyObject_TypeCheck, the + PyObject_TypeCheck function only returns 0 or 1, there's no -1 error + case. + + It's also worth noting that PyObject_TypeCheck is the function that is + more commonly used within GDB's Python API implementation, include the + py-color.c use there were only 4 PyObject_IsInstance uses. Of the + remaining 3, 2 are fine, and one other (in py-disasm.c) is also + wrong. I'll address that in a separate patch. + + There's also a new test included which exposes the above issue. + + Approved-By: Tom Tromey + +2025-04-23 Andrew Burgess + + gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.Color + Remove the Py_TPFLAGS_BASETYPE flag from the gdb.Color type. This + effectively makes gdb.Color final; users can no longer create classes + that inherit from gdb.Color. + + Right now I cannot think of any cases where inheritance would be + needed over composition for a simple type like gdb.Color. If I'm + wrong, then it's easy to add Py_TPFLAGS_BASETYPE back in later, this + would be an extension of the API. But it's much harder to remove the + flag later as that might break existing user code (note: there has + been no release of GDB yet that includes the gdb.Color type). + + Introducing this restriction makes the next commit easier. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-04-23 Andrew Burgess + + gdb/python: stop using PyObject_IsInstance in py-disasm.c + The PyObject_IsInstance function can return -1 for errors, 0 to + indicate false, and 1 to indicate true. + + I noticed in python/py-disasm.c that we treat the result of + PyObject_IsInstance as a bool. This means that if PyObject_IsInstance + returns -1, then this will be treated as true. The consequence of + this is that we will invoke undefined behaviour by treating the result + from the _print_insn call as if it was a DisassemblerResult object, + even though PyObject_IsInstance raised an error, and the result might + not be of the required type. + + I could fix this by taking the -1 result into account, however, + gdb.DisassemblerResult cannot be sub-classed, the type doesn't have + the Py_TPFLAGS_BASETYPE flag. As such, we can switch to using + PyObject_TypeCheck instead, which only return 0 or 1, with no error + case. + + I have also taken the opportunity to improve the error message emitted + if the result has the wrong type. Better error message make debugging + issues easier. + + I've added a test which exposes the problem when using + PyObject_IsInstance, and I've updated the existing test for the + improved error message. + + Approved-By: Tom Tromey + +2025-04-23 Guinevere Larsen + + gdb: fix building with all targets + Commit b9c7eed0c2409fc640129a38d80a2bf1212b464a recently introduced + a build failure, because the file gdb/riscv-canonicalize-syscall-gen.c + hasn't been added to the ALL_64_TARGET_OBS variable in the makefile, + leading to a linker issue. This commit fixes that. + + Also, turns out, the new file was slightly outdated, as the gdb_old_mmap + syscall has been renamed to gdb_sys_old_mmap in commit + 432eca4113d5748ad284a068873455f9962b44fe. This commit also fixes that + on the generated file itself, to quickly fix the build. A followup + commit will fix the python file responsible for generating the .c file. + +2025-04-23 Guinevere Larsen + + GDB: Introduce "info linker-namespaces" command + Continuing to improve GDB's ability to debug linker namespaces, this + commit adds the command "info linker- namespaces". The command is + similar to "info sharedlibrary" but focused on improved readability + when the inferior has multiple linker namespaces active. This command + can be used in 2 different ways, with or without an argument. + + When called without argument, the command will print the number of + namespaces, and for each active namespace, it's identifier, how many + libraries are loaded in it, and all the libraries (in a similar table to + what "info sharedlibrary" shows). As an example, this is what GDB's + output could look like: + + (gdb) info linker-namespaces + There are 2 linker namespaces loaded + There are 3 libraries loaded in linker namespace [[0]] + Displaying libraries for linker namespace [[0]]: + From To Syms Read Shared Object Library + 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6 + 0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6 + (*): Shared library is missing debugging information. + + There are 4 libraries loaded in linker namespace [[1]] + Displaying libraries for linker namespace [[1]]: + From To Syms Read Shared Object Library + 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7fb9000 0x00007ffff7fbe000 Yes gdb.base/dlmopen-ns-ids/dlmopen-lib.so + 0x00007ffff7bc4000 0x00007ffff7caa000 Yes (*) /lib64/libm.so.6 + 0x00007ffff79d1000 0x00007ffff7bc4000 Yes (*) /lib64/libc.so.6 + (*): Shared library is missing debugging information. + + When called with an argument, the argument must be a namespace + identifier (either with or without the square brackets decorators). In + this situation, the command will truncate the output to only show the + relevant information for the requested namespace. For example: + + (gdb) info linker-namespaces 0 + There are 3 libraries loaded in linker namespace [[0]] + Displaying libraries for linker namespace [[0]]: + From To Syms Read Shared Object Library + 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6 + 0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6 + (*): Shared library is missing debugging information. + + The test gdb.base/dlmopen-ns-id.exp has been extended to test this new + command. Because some gcc and glibc defaults can change between + systems, we are not guaranteed to always have libc and libm loaded in a + namespace, so we can't guarantee the number of libraries, but the range + of the result is 2, so we can still check for glaring issues. + + Reviewed-By: Eli Zaretskii + Approved-by: Kevin Buettner + +2025-04-23 Guinevere Larsen + + gdb: factor out printing a table of solibs for info sharedlibrary + The next patch will add a new command that will print libraries in a + manner very similar to the existing "info sharedlibrary" command. To + make that patch simpler to review, this commit does the bulk of + refactoring work, since it ends up being a non-trivial diff to review. + + No functional changes are expected after this commit. + + Approved-by: Kevin Buettner + +2025-04-23 Guinevere Larsen + + gdb: add convenience variables around linker namespace debugging + This commit adds 2 simple built-in convenience variables to help users + debug an inferior with multiple linker namespaces. The first is + $_active_linker_namespaces, which just counts how many namespaces have SOs + loaded onto them. The second is $_current_linker_namespace, and it tracks + which namespace the current location in the inferior belongs to. + + This commit also introduces a test ensuring that we track namespaces + correctly, and that a user can use the $_current_linker_namespace + variable to set a conditional breakpoint, while linespec changes aren't + finalized to make it more convenient. + + Reviewed-By: Eli Zaretskii + Approved-by: Kevin Buettner + +2025-04-23 Tankut Baris Aktemur + + gdb: print target in print_target_wait_results + Extend `print_target_wait_results` to print the target from which the + wait result came. + + Approved-By: Pedro Alves + +2025-04-23 Timur + + This commit adds record full support for rv64gc instruction set + It includes changes to the following files: + - gdb/riscv-linux-tdep.c, gdb/riscv-linux-tdep.h: adds facilities to record + syscalls. + - gdb/riscv-tdep.c, gdb/riscv-tdep.h: adds facilities to record execution of + rv64gc instructions. + - gdb/configure.tgt: adds new files for compilation. + - gdb/testsuite/lib/gdb.exp: enables testing of full record mode for RISC-V + targets. + - gdb/syscalls/riscv-canonicalize-syscall-gen.py: a script to generate + function that canonicalizes RISC-V syscall. This script can simplify support + for syscalls on rv32 and rv64 system (currently support only for rv64). To + use this script you need to pass a path to a file with syscalls description + from riscv-glibc (example is in the help message). The script produces a + mapping from syscall names to gdb_syscall enum. + - gdb/riscv-canonicalize-syscall.c: the file generated by the previous script. + - gdb/doc/gdb.texinfo: notification that record mode is enabled in RISC-V. + - gdb/NEWS: notification of new functionality. + + Approved-By: Guinevere Larsen + Approved-By: Andrew Burgess + +2025-04-23 Sam James + + gdb: fix bashism in configure.ac + Use '=', not '==', as configure has a #!/bin/sh shebang and must work + with non-bash shells. + + Fixes: c4375bc51c861dfa384a01bdb2e460e115710bf9 + +2025-04-23 Tom de Vries + + [gdb/testsuite] Add selftest disassemble-s390x + In commit a98a6fa2d8e ("s390: Add arch15 instructions"), support for + new instructions was added to libopcodes, but the added tests only exercise + this for gas. + + Add a unit test disassemble-s390x that checks gdb's ability to + disassemble one of these instructions: + ... + $ gdb -q -batch -ex "maint selftest -v disassemble-s390x" + Running selftest disassemble-s390x. + 0xb9 0x68 0x00 0x03 -> clzg %r0,%r3 + Ran 1 unit tests, 0 failed + ... + + Tested on x86_64-linux and s390x-linux. + +2025-04-23 Tom de Vries + + [gdb/testsuite] Update regexp in gdb.debuginfod/fetch_src_and_symbols.exp + Since commit 7b80401da00 ("Handle DWARF 5 separate debug sections"), test-case + gdb.debuginfod/fetch_src_and_symbols.exp fails here: + ... + (gdb) file fetch_src_and_symbols_alt.o^M + Reading symbols from fetch_src_and_symbols_alt.o...^M + warning: could not find supplementary DWARF file \ + (fetch_src_and_symbols_dwz.o) for fetch_src_and_symbols_alt.o^M + (gdb) FAIL: $exp: no_url: file fetch_src_and_symbols_alt.o + ... + because this is expected: + ... + (gdb) file fetch_src_and_symbols_alt.o^M + Reading symbols from fetch_src_and_symbols_alt.o...^M + warning: could not find '.gnu_debugaltlink' file for \ + fetch_src_and_symbols_alt.o^M + (gdb) PASS: $exp: no_url: file fetch_src_and_symbols_alt.o + ... + + Fix this by updating the regexp. + + Tested on x86_64-linux. + +2025-04-23 Lulu Cai + + LoongArch: Add test for divide by zero in instructions + Added tests for division/modulo by zero for instruction expressions. + +2025-04-23 Alan Modra + + string merge section map output + This fixes an inconsistency in the linker map file, where string merge + sections (other than the first) kept their sizes. String merge + sections of like entsize all are accounted in the fisrt string merge + section size. + + * ldlang.c (print_input_section): Print SEC_EXCLUDE section size + as zero. + +2025-04-23 GDB Administrator + + Automatic date update in version.in + +2025-04-23 Alan Modra + + PR 32603 followup, remove %F from einfo + No uses of %F remain. + + * ldmisc.c (vfinfo): Remove %F handling. + +2025-04-22 Tom Tromey + + Add "-5" flag to cc-with-tweaks + This adds a "-5" flag to cc-with-tweaks, mirroring dwz's "-5" flag, + and also adds a new cc-with-dwz-5 target board. + + The "-5" flag tells dwz to use the DWARF 5 .debug_sup section in + multi-file mode. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808 + +2025-04-22 Tom Tromey + + Handle DWARF 5 separate debug sections + DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in + multi-file mode. This is handled via some new forms, and a new + .debug_sup section. + + This patch adds support for this to gdb. It is largely + straightforward, I think, though one oddity is that I chose not to + have this code search the system build-id directories for the + supplementary file. My feeling was that, while it makes sense for a + distro to unify the build-id concept with the hash stored in the + .debug_sup section, there's no intrinsic need to do so. + + This in turn means that a few tests -- for example those that test the + index cache -- will not work in this mode. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808 + Acked-By: Simon Marchi + +2025-04-22 Tom Tromey + + Remove 'read' call from dwz_file::read_string + dwz_file::read_string calls 'read' on the section, but this isn't + needed as the sections have all been pre-read. + + This patch makes this change, and refactors dwz_file a bit to make + this more obvious -- by making it clear that only the "static + constructor" can create a dwz_file. + + Approved-By: Simon Marchi + Tested-By: Alexandra Petlanova Hajkova + +2025-04-22 Andrew Burgess + + gdb/testsuite: fix incorrect comment in py-color.exp + There was a comment in gdb.python/py-color.exp that was probably left + over from a copy & paste, it incorrectly described what the test + script was testing. + + Fixed in this commit. + + There's no change in what is tested with this commit. + +2025-04-22 Andrew Burgess + + gdb/python: address some coding style issues in py-color.c + A few minor GNU/GDB coding style issues in py-color.c: + + - Space after '&' reference operator in one place. + - Some excessive indentation on a couple of lines. + - Spaces after '!' logical negation operator. + - Using a pointer as a bool in a couple of places. + + There should be no functional changes after this commit. + +2025-04-22 Andrew Burgess + + gdb/python: remove stray white space in error message + Spotted a stray white space at the end of an error message. Removed, + and updated the py-breakpoint.exp test to check this case. + +2025-04-22 Andrew Burgess + + gdb/doc: use @samp{} in Python docs + In this review: + + https://inbox.sourceware.org/gdb-patches/86sem6ase5.fsf@gnu.org + + it was pointed out that I should use @samp{} around some text I was + adding to the documentation. However, the offending snippet of + documentation was something I copied from elsewhere in python.texi. + This commit fixes the original to use @samp{}. + +2025-04-22 Andrew Burgess + + gdb/python: fix memory leak of gdb.Color objects + I noticed that this commit: + + commit 6447969d0ac774b6dec0f95a0d3d27c27d158690 + Date: Sat Oct 5 22:27:44 2024 +0300 + + Add an option with a color type. + + has an unnecessary `Py_INCREF (self);` in gdb.Color.__init__. This + means that the reference count on all gdb.Color objects (that pass + through __init__) will be +1 from where they should normally be, and + this will stop the gdb.Color objects from being deallocated. + + Fix by removing the Py_INCREF call. + + Add a test which exposes the memory leak. + + Approved-By: Tom Tromey + +2025-04-22 Andrew Burgess + + gdb/python: restructure the existing memory leak tests + We currently have two memory leak tests in gdb.python/ and there's a + lot of duplication between these two. + + In the next commit I'd like to add yet another memory leak test, which + would mean a third set of scripts which duplicate the existing two. + And three is where I draw the line. + + This commit factors out the core of the memory leak tests into a new + module gdb_leak_detector.py, which can then be imported by each + tests's Python file in order to make writing the memory leak tests + easier. + + I've also added a helper function to lib/gdb-python.exp which captures + some of the common steps needed in the TCL file in order to run a + memory leak test. + + Finally, I use this new infrastructure to rewrite the two existing + memory leak tests. + + What I considered, but ultimately didn't do, is merge the two memory + leak tests into a single TCL script. I did consider this, and for the + existing tests this would be possible, but future tests might require + different enough setup that this might not be possible for all future + tests, and now that we have helper functions in a central location, + the each individual test is actually pretty small now, so leaving them + separate seemed OK. + + There should be no change in what is actually being tested after this + commit. + + Approved-By: Tom Tromey + +2025-04-22 Tom Tromey + + Remove ui_file::reset_style + ui_file::reset_style doesn't seem to be needed. This patch removes + it. Regression tested on x86-64 Fedora 40. + +2025-04-22 ZENG Hao + + gdb: fix ui-style regex initializing order + This fixes a crash on Windows NT 4.0, where windows-nat failed dynamic loading + some Win32 functions and print a warning message with styled string, which + depends on ui-style regex. By using `compiled_regex` constructor, the regex is + guaranteed to be initialized before `_initialize_xxx` functions. + + Approved-By: Tom Tromey + +2025-04-22 Jens Remus + + gas: sframe: Fix typo in comment on SFrame identifier + gas/config/ + * tc-aarch64.c (aarch64_sframe_get_abi_arch): Fix typo in + comment on SFrame identifier. + * tc-aarch64.h (aarch64_sframe_get_abi_arch, + sframe_get_abi_arch): Likewise. + * tc-i386.c (x86_sframe_get_abi_arch): Likewise. + * tc-i386.h (x86_sframe_get_abi_arch, sframe_get_abi_arch): + Likewise. + + Reported-by: Indu Bhagat + +2025-04-22 Vladimir Mezentsev + + gprofng: fix 32889 Typo in documentation + gprofng/ChangeLog + 2025-04-18 Vladimir Mezentsev + + * doc/gprofng_ug.texi: Fix typo. + +2025-04-22 Vladimir Mezentsev + + gprofng: fix 32886 wrong mapping from instruction to line number + On Intel, gprofng should adjusts return addresses, including user leaf functions. + + gprofng/ChangeLog + 2025-04-18 Vladimir Mezentsev + + * src/CallStack.cc (add_stack): Adjust return addresses on Intel. + +2025-04-22 Michael J. Eager + + MicroBlaze: Make sure we see memory breakpoints before reading + For linux target, when trying to run a program from gdb, the + following defect is seen: + + Program received signal SIGILL, Illegal instruction. + 0x48004674 in _dl_debug_state () from target:/lib/ld.so.1 + + * microblaze-linux-tdep.c (microblaze_linux_memory_remove_breakpoint): + Call make_scoped_restore_show_memory_breakpoints + +2025-04-22 GDB Administrator + + Automatic date update in version.in + +2025-04-21 GDB Administrator + + Automatic date update in version.in + +2025-04-21 Alan Modra + + avoid bogus format-overflow error + Seen on x86_64-linux Ubuntu 24.04.2 using gcc-13.3.0 with + CFLAGS="-m32 -g -O2 -fsanitize=address,undefined" + + In function ‘sprintf’, + inlined from ‘s_mri_for’ at gas/config/tc-m68k.c:6941:5: + /usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=] + 30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 31 | __glibc_objsize (__s), __fmt, + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 32 | __va_arg_pack ()); + | ~~~~~~~~~~~~~~~~~ + + Rewrite the code without sprintf, as in other parts of s_mri_for. + See also commit 760fb390fd4c and following commits. + + Note that adding -D_FORTIFY_SOURCE=0 to CFLAGS (which is a good idea + when building with sanitizers) merely transforms the sprintf_chk error + here into one regarding plain sprintf. + +2025-04-21 Alan Modra + + bfd_check_format_matches error paths + Tidy early out errors which didn't free matching_vector. Don't + bfd_preserve_restore if we get to err_ret from the first + bfd_preserve_save, which might fail from a memory allocation leaving + preserve.marker NULL. Also take bfd_lock a little earlier before + modifying abfd->format to simplify error return path from a lock + failure. + + rescoff: close bfd on failure paths + Also free malloc'd relocs. + +2025-04-20 Simon Marchi + + gdb/dwarf: make some more functions methods of cutu_reader + These are only used by cutu_reader, so make them methods of cutu_reader. + This makes it a bit more obvious in which context this code is called. + + lookup_dwo_unit_in_dwp can't be made a method of cutu_reader, as it is + used in another context (lookup_dwp_signatured_type / + lookup_signatured_type), which happens during CU expansion. + + Change-Id: Ic62c3119dd6ec198411768323aaf640ed165f51b + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: look up .dwp file ahead of time + get_dwp_file lazily looks for a .dwp file for the given objfile. It is + called by indexing workers, when a cutu_reader object looks for a DWO + file. It is called with the "dwo_lock" held, meaning that the first + worker to get there will do the work, while the others will wait at the + lock. + + I'm trying to reduce the time where this lock is taken and do other + refactorings to make it easier to reason about the DWARF reader code. + Moving the lookup of the .dwp file ahead, before we start parallelizing + work, helps makes things simpler, because we can then assume everywhere + else that we have already checked for a .dwp file. + + Put the call to open_and_init_dwp_file in dwarf2_has_info, right next to + where we look up .dwz files. I used the same try-catch pattern as for + the .dwz file lookup. + + Change-Id: I615da85f62a66d752607f0dbe9f0372dfa04b86b + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: replace some per_objfile parameters with per_bfd + Following a previous patch, these functions can accept a per_bfd + instead of a per_objfile. + + Change-Id: Iacc8924d2e49a05920d9a7fde2f7584f709fbdd2 + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: pass section to create_dwp_hash_table + Instead of passing a boolean to create_dwp_hash_table to select the + section to read, it's simpler to just pass the section. + + Change-Id: Ie043c31e80518239f6403288dcf03f7769c58e8c + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: remove unnecessary dwarf2_section_info:::read calls + The sections would have been read already in + dwarf2_locate_common_dwp_sections or dwarf2_locate_dwo_sections, with + this call: + + dw_sect->read (objfile); + + Change-Id: Ice0ed5d9a2070967826a59b2d6f724451ace22f4 + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: remove per_objfile parameter from read_and_check_comp_unit_head + It is no longer needed. + + Change-Id: I22b21b12dc9f74a423bca355d4d83f0167e75f34 + Approved-By: Tom Tromey + +2025-04-20 Simon Marchi + + gdb/dwarf: remove dwarf2_section_info::get_size + The comment over dwarf2_section_info::get_size says: + + In other cases, you must call this function, because for compressed + sections the size field is not set correctly until the section has + been read + + From what I can see (while debugging a test case compiled with -gz on + Linux), that's not true. For compressed sections, bfd_section_size + returns the uncompressed size. asection::size contains the uncompressed + size while asection::compressed_size contains the compressed size: + + (top-gdb) p sec + $13 = (asection *) 0x521000119778 + (top-gdb) p sec.compressed_size + $14 = 6191 + (top-gdb) p sec.size + $15 = 12116 + + I therefore propose to remove dwarf2_section_info::get_size, as it + appears that reading in the section is orthogonal to knowing its size. + + If the assumption above is false, it would be nice to document in which + case it's false. + + I checked the callers, and I don't think that we need to add any + dwarf2_section_info::read calls to compensate for the fact that get_size + used to do it. + + Change-Id: I428571e532301d49f1d8242d687e1fcb819b75c1 + Approved-By: Tom Tromey + +2025-04-20 GDB Administrator + + Automatic date update in version.in + +2025-04-19 Tom Tromey + + Remove some obsolete comments from ada-varobj.c + I noticed a few spots in ada-varobj.c that refer to calling xfree, + where the type in question has changed to std::string. This patch + removes these obsolete comments. + +2025-04-19 GDB Administrator + + Automatic date update in version.in + +2025-04-18 Vladimir Mezentsev + + Fix 32885 gprofng --help should state where to report bugs + gprofng/ChangeLog + 2025-04-17 Vladimir Mezentsev + + * src/gp-archive.cc: Fix the --help output. + * src/gp-collect-app.cc: Likewise. + * src/gp-display-src.cc: Likewise. + * src/gp-display-text.cc: Likewise. + * src/gprofng.cc: Likewise. + +2025-04-18 Alan Modra + + build error with 32-bit host and 64-bit time_t + A fix for commit c4fce3ef2927. + + loongarch gas resolving constant expressions + The test added in commit 4fe96ddaf614 results in an asan complaint: + loongarch-parse.y:225:16: runtime error: left shift of negative value -1 + To avoid the complaint, perform left shifts as unsigned (which gives + the same result on 2's complement machines). Do the same for + addition, subtraction and multiplication. Furthermore, warn on + divide/modulus by zero. + +2025-04-18 GDB Administrator + + Automatic date update in version.in + +2025-04-17 Tom de Vries + + [gdb/testsuite] Don't run to main in gdb.cp/cplusfuncs.exp + After building gdb with -fsanitize=threads, and running test-case + gdb.cp/cplusfuncs.exp, I run into a single timeout: + ... + FAIL: gdb.cp/cplusfuncs.exp: info function operator=( (timeout) + ... + and the test-case takes 2m33s to finish. + + This is due to expanding CUs from libstdc++. + + After de-installing package libstdc++6-debuginfo, the timeout disappears and + testing time goes down to 9 seconds. + + Fix this by not running to main, which brings testing time down to 3 seconds. + + With a gdb built without -fsanitize=threads, testing time goes down from 11 + seconds to less than 1 second. + + Tested on x86_64-linux. + + Reviewed-By: Keith Seitz + +2025-04-17 Tom Tromey + + Clean up value_struct_elt_bitpos + value_struct_elt_bitpos is weird: it takes an in/out value parameter, + and it takes an error string parameter. However, it only has a single + caller, which never uses the "out" value. + + I think it was done this way to mimic value_struct_elt. However, + value_struct_elt is pretty ugly and I don't think it's worth + imitating. + + This patch cleans up value_struct_elt_bitpos a bit. + + Approved-By: Simon Marchi + +2025-04-17 Yury Khrustalev + + testsuite: fix typo in bti-plt-1-b.d test + This test is not supposed to use -z force-bti + + aarch64: ld: add tests for combination of bti and memory-seal + Both BTI and memory sealing require use of GNU properties and + we should check that there is no interference. + +2025-04-17 Yury Khrustalev + + aarch64: ld: Fix scanning of GNU properties for AARCH64_FEATURE_1_AND + Fixes [1]. Previously iteration over GNU properties of an input file + could stop before reaching GNU_PROPERTY_AARCH64_FEATURE_1_AND which + would result in incorrect inference of properties of the output file. + + In the particular use case described in [1], the memory seal property + GNU_PROPERTY_MEMORY_SEAL with number 3, if present in the input file, + prevented reading information from GNU_PROPERTY_AARCH64_FEATURE_1_AND + property due to filtering by property number. + + [1] PR32818 https://sourceware.org/bugzilla/show_bug.cgi?id=32818 + +2025-04-17 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/clone-attach-detach.exp + With test-case gdb.threads/clone-attach-detach.exp I usually get: + ... + (gdb) attach &^M + Attaching to program: clone-attach-detach, process ^M + [New LWP ]^M + (gdb) PASS: $exp: bg attach : attach + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + ... + but sometimes I run into: + ... + (gdb) attach &^M + Attaching to program: clone-attach-detach, process ^M + [New LWP ]^M + (gdb) [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + FAIL: $exp: bg attach : attach (timeout) + ... + + I managed to reproduce this using make target check-readmore and + READMORE_SLEEP=100. + + Fix this using -no-prompt-anchor. + + Tested on x86_64-linux. + + Approved-By: Simon Marchi + +2025-04-17 Simon Marchi + + gdb: fix bugs in gdb/copyright.py, make it use glob patterns + gdb/copyright.py currently changes some files that it shouldn't: + + - despite having a `gnulib/import` entry in EXCLUDE_LIST, it does + change the files under that directory + - it is missing `sim/Makefile.in` + + Change the exclude list logic to use glob patterns. This makes it + easier to specify exclusions of full directories or files by basename, + while simplifying the code. + + Merge EXCLUDE_LIST and NOT_FSF_LIST, since there's no fundamental reason + to keep them separate (they are treated identically). I kept the + comment that explains that some files are excluded due to not being + FSF-licensed. + + Merge EXCLUDE_ALL_LIST in EXCLUDE_LIST, converting the entries to glob + patterns that match everywhere in the tree (e.g. `**/configure`). + + Tested by running the script on the parent commit of d01e823438c7 + ("Update copyright dates to include 2025") and diff'ing the result with + d01e823438c7. The only differences are: + + - the files that we don't want to modify (gnulib/import and + sim/Makefile.in) + - the files that need to be modified by hand + + Running the script on latest master produces no diff. + + Change-Id: I318dc3bff34e4b3a9b66ea305d0c3872f69cd072 + Reviewed-By: Guinevere Larsen + +2025-04-17 Simon Marchi + + gdb: make typing strict in gdb/copyright.py + Add `pyright: strict` at the top of the file, then adjust the fallouts. + This annotation is understood by pyright, and thus any IDE using pyright + behind the scenes (VSCode and probably others). + + I presume that any GDB developer running this script is using a recent + enough version of Python, so specify the type annotations using the + actual types when possible (e.g. `list[str]` instead of + `typing.List[str]`). I believe this required Python 3.9. + + Change-Id: I3698e28555e236a03126d4cd010dae4b5647ce48 + Reviewed-By: Guinevere Larsen + +2025-04-17 GDB Administrator + + Automatic date update in version.in + +2025-04-16 Tom de Vries + + [gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp + With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a + timeout: + ... + (gdb) c 1& + Will stop next time breakpoint 1 is reached. Continuing. + (gdb) PASS: $exp: c 1&: c 1& + + Breakpoint 2, foo () at bg-execution-repeat.c:23 + 23 return 0; /* set break here */ + PASS: $exp: c 1&: breakpoint hit 1 + + Will stop next time breakpoint 2 is reached. Continuing. + (gdb) PASS: $exp: c 1&: repeat bg command + print 1 + $1 = 1 + (gdb) PASS: $exp: c 1&: input still accepted + interrupt + (gdb) PASS: $exp: c 1&: interrupt + + Program received signal SIGINT, Interrupt. + foo () at bg-execution-repeat.c:24 + 24 } + PASS: $exp: c 1&: interrupt received + set var do_wait=0 + (gdb) PASS: $exp: c 1&: set var do_wait=0 + continue& + Continuing. + (gdb) PASS: $exp: c 1&: continue& + FAIL: $exp: c 1&: breakpoint hit 2 (timeout) + ... + + I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1" + in the .c file. + + The timeout happens as follows: + - with the inferior stopped at main, gdb continues (command c 1&) + - the inferior hits the breakpoint at foo + - gdb continues (using the repeat command functionality) + - the inferior is interrupted + - inferior variable do_wait gets set to 0. The assumption here is that the + inferior has progressed enough that do_wait is set to 1 at that point, but + that happens not to be the case. Consequently, this has no effect. + - gdb continues + - the inferior sets do_wait to 1 + - the inferior enters the wait function, and wait for do_wait to become 0, + which never happens. + + Fix this by moving the "do_wait = 1" to before the first call to foo. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2025-04-16 Alan Modra + + buffer overrun in read_coff_res_dir + * rescoff.c (read_coff_res_dir): Add more sanity checking. + Tidy and correct existing checks. + + resbin.c formatting fixes + Also remove unnecessary casts on memory alloc function returns. + + Re: windres: buffer overflow in bin_to_res_toolbar + Commit 9e68cae4fdfb broke the check I added in commit 4846e543de95. + Add missing "return NULL". + +2025-04-16 GDB Administrator + + Automatic date update in version.in + +2025-04-16 Tom Tromey + + Use gdb::unordered_set for Ada symbol cache + This changes the Ada symbol cache to use gdb::unordered_set rather + than an htab. + + Approved-By: Simon Marchi + +2025-04-15 Tom Tromey + + Use gdb::string_set for decoded_names_store + This patch changes decoded_names_store to use a gdb::string_set rather + than an htab. + + Approved-By: Simon Marchi + +2025-04-15 Tom de Vries + + [gdb/ada] Fix gdb.ada/overloads.exp on s390x + On s390x-linux, with test-case gdb.ada/overloads.exp and gcc 7.5.0 I run into: + ... + (gdb) print Oload(CA)^M + Could not find a match for oload^M + (gdb) FAIL: $exp: print Oload(CA) + ... + + The mismatch happens here in ada_type_match: + ... + return ftype->code () == atype->code (); + ... + with: + ... + (gdb) p ftype->code () + $3 = TYPE_CODE_TYPEDEF + (gdb) p atype->code () + $4 = TYPE_CODE_ARRAY + ... + + At the start of ada_type_match, typedefs are skipped: + ... + ftype = ada_check_typedef (ftype); + atype = ada_check_typedef (atype); + ... + but immediately after this, refs are skipped: + ... + if (ftype->code () == TYPE_CODE_REF) + ftype = ftype->target_type (); + if (atype->code () == TYPE_CODE_REF) + atype = atype->target_type (); + ... + which in this case makes ftype a typedef. + + Fix this by using ada_check_typedef after skipping the refs as well. + + Tested on x86_64-linux and s390x-linux. + + Approved-By: Tom Tromey + + PR ada/32409 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32409 + +2025-04-15 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/scalar_storage.exp on s390x + On s390x-linux, with test-case gdb.ada/scalar_storage.exp we have: + ... + (gdb) print V_LE^M + $1 = (value => 126, another_value => 12, color => 3)^M + (gdb) FAIL: gdb.ada/scalar_storage.exp: print V_LE + print V_BE^M + $2 = (value => 125, another_value => 9, color => green)^M + (gdb) KFAIL: $exp: print V_BE (PRMS: DW_AT_endianity on enum types) + ... + + The KFAIL is incorrect in the sense that gdb is behaving as expected. + + The problem is incorrect debug info, so change this into an xfail. + + Furthermore, extend the xfail to cover V_LE. + + Tested on s390x-linux and x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/32875 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32875 + +2025-04-15 Simon Marchi + + gdb/dwarf: skip type units in create_dwo_cus_hash_table + When compiling with -gsplit-dwarf -fdebug-types-section, DWARF 5 + .debug_info.dwo sections may contain some type units: + + $ llvm-dwarfdump -F -color a-test.dwo | head -n 5 + a-test.dwo: file format elf64-x86-64 + + .debug_info.dwo contents: + 0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4) + + In this case, create_dwo_cus_hash_table wrongly creates a dwo_unit for + it and adds it to dwo_file::cus. create_dwo_debug_type_hash_table later + correctly creates a dwo_unit that it puts in dwo_file::tus. + + This can be observed with: + + $ ./gdb -nx -q --data-directory=data-directory -ex 'maint set dwarf sync on' -ex "maint set worker-threads 0" -ex "set debug dwarf-read 2" -ex "file a.out" -batch + ... + [dwarf-read] create_dwo_cus_hash_table: Reading .debug_info.dwo for /home/smarchi/build/binutils-gdb/gdb/a-test.dwo: + [dwarf-read] create_dwo_cus_hash_table: offset 0x0, dwo_id 0xb499dcf29e2928c4 + [dwarf-read] create_dwo_cus_hash_table: offset 0x8a4, dwo_id 0x496a8791a842701b + [dwarf-read] create_dwo_cus_hash_table: offset 0x941, dwo_id 0xefd13b3f62ea9fea + ... + [dwarf-read] create_dwo_debug_type_hash_table: Reading .debug_info.dwo for /home/smarchi/build/binutils-gdb/gdb/a-test.dwo + [dwarf-read] create_dwo_debug_type_hash_table: offset 0x0, signature 0xb499dcf29e2928c4 + [dwarf-read] create_dwo_debug_type_hash_table: offset 0x8a4, signature 0x496a8791a842701b + [dwarf-read] create_dwo_debug_type_hash_table: offset 0x941, signature 0xefd13b3f62ea9fea + ... + + Fix it by skipping anything that isn't a compile unit in + create_dwo_cus_hash_table. After this patch, the debug output of + create_dwo_cus_hash_table only shows one created dwo_unit, as we expect. + + I couldn't find any user-visible problem related to this, I just noticed + it while debugging. + + Change-Id: I7dddf766fe1164123b6702027b1beb56114f25b1 + Reviewed-By: Tom de Vries + +2025-04-15 Simon Marchi + + gdb/dwarf: rename some functions to specify "dwo" + Rename some functions to make it clearer that they are only relevant + when dealing with DWO files. + + Change-Id: Ia0cd3320bf16ebdbdc3c09d7963f372e6679ef7c + Reviewed-By: Tom de Vries + +2025-04-15 Marek Pikuła + + RISC-V: Add missing disassembler option `max` + The flag already exists but it's not been exposed to user. + +2025-04-15 GDB Administrator + + Automatic date update in version.in + +2025-04-14 Alan Modra + + PR 32871 ld/ldmain.c#L425 incorrect location of #endif + Fix commit c4fce3ef2927 brace position. + + windres: don't exit so much on errors in read_coff_rsrc + windres code has the habit of exiting on any error. That's not so + bad, but it does make oss-fuzz ineffective when testing windres. Fix + many places that print errors and exit to instead print the error and + pass status up the call chain. In the process of doing this, I + noticed write_res_file was calling bfd_close without checking return + status. Fixing that resulted in lots of testsuite failures. The + problem was a lack of bfd_set_format in windres_open_as_binary, which + leaves the output file as bfd_unknown format. As it happens this + doesn't make any difference in writing the output binary file, except + for the bfd_close return status. + + windres: buffer overflow in bin_to_res_toolbar + oss-fuzz testcase manages to hit a buffer overflow. Sanity check + by passing the buffer length to bin_to_res_toolbar and ensuring reads + don't go off the end of the buffer. + + Re: ld: Skip the LTO archive member only for the earlier DSO + Add -fPIC when compiling the test, to fix complaints on some targets + about certains relocation not being valid for shared libraries. + +2025-04-14 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.arch/aarch64-sve-sigunwind.exp + There's currently no test for unwinding the SVE registers from a signal + frame, so add one. + + Tested on aarch64-linux-gnu native. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2025-04-14 Jan Beulich + + ld/PE: restrict non-zero default DLL characteristics to MinGW + While commit ef6379e16dd1 ("Set the default DLL chracteristics to 0 for + Cygwin based targets") tried to undo the too broad earlier 514b4e191d5f + ("Change the default characteristics of DLLs built by the linker to more + secure settings"), it didn't go quite far enough. Apparently the + assumption was that if it's not MinGW, it must be Cygwin. Whether it + really is okay to default three of the flags to non-zero on MinGW also + remains unclear - sadly neither of the commits came with any description + whatsoever. (Documentation also wasn't updated to indicate the restored + default.) + + Setting effectively any of the DLL characteristics flags depends on + properties of the binary being linked. While defaulting to "more secure" + is a fair goal, it's only the programmer who can know whether their code + is actually compatible with the respective settings. On the assumption + that the change of defaults was indeed deliberate (and justifiable) for + MinGW, limit them to just that. In particular, don't default any of the + flags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At + least the mere applicability of the high-entropy-VA bit is pretty + questionable there in the first place - UEFI applications, after all, + run in "physical mode", i.e. either unpaged or (where paging is a + requirement, like for x86-64) direct-mapped. + + The situation is particularly problematic with NX-compat: Many UEFI + implementations respect the "physical mode" property, where permissions + can't be enforced anyway. Some, like reportedly OVMF, even have a build + option to behave either way. Hence successfully testing a UEFI binary on + any number of systems does not guarantee it won't crash elsewhere if the + flag is wrongly set. + + Get rid of excess semicolons as well. + +2025-04-14 Jan Beulich + + bfd/ELF/x86: avoid layering violation in link hash table entry init + There's no reason not to do as the comment says, just like all other + architectures do when they need custom field: Call the allocation method + of the "superclass". Which is the ELF one, of which in turn the BFD one + is the "superclass", dealt with accordingly by + _bfd_elf_link_hash_newfunc(). + + bfd/aout: drop add_one_symbol() hook + The need for this has disappeared with c65c21e1ffd1 ("various i386-aout + and i386-coff target removal"), with a few other users having got + removed just a few days earlier; avoid the unnecessary indirection. + +2025-04-14 Jan Beulich + + bfd/COFF: propagate function size when copying/linking ELF objects + While COFF, unlike ELF, doesn't have a generic way to express symbol + size, there is a means to do so for functions. When inputs are ELF, + propagate function sizes, including the fact that a symbol denotes a + function, to the output's symbol table. + + Note that this requires hackery (cross-object-format processing) in two + places - when linking, global symbols are entered into a global hash + table, and hence relevant information needs to be updated there in that + case, while otherwise the original symbol structures can be consulted. + + For the setting of ->u.syment.n_type the later writing of the field to + literal 0 needs to be dropped from coff_write_alien_symbol(). It was + redundant anyway with an earlier write of the field using C_NUL. + +2025-04-14 Jan Beulich + + x86: move PadLock enumerators + ... to be all in one group. This helps code generation for code like + + || is_cpu (&i.tm, CpuPadLock) + || is_cpu (&i.tm, CpuPadLockRNG2) + || is_cpu (&i.tm, CpuPadLockPHE2) + || is_cpu (&i.tm, CpuPadLockXMODX) + + that we have (effectively) twice. + +2025-04-14 Piotr Rudnicki + + gdb: add check for empty array + With the command before the change, gdb crashes with message: + (gdb) p 1 == { } + Fatal signal: Segmentation fault + + After the fix in this commit, gdb shows following message: + (gdb) p 1 == { } + size of the array element must not be zero + + Add new test cases to file gdb.base/printcmds.exp to test this change + + Approved-By: Tom Tromey + +2025-04-14 Andrew Burgess + + gdb: add an assert to cmd_list_element constructor + The cmd_list_element::doc variable must be non-nullptr, otherwise, in + `help_cmd` (cli/cli-decode.c), we will trigger an assert when we run + one of these lines: + + gdb_puts (c->doc, stream); + + or, + + gdb_puts (alias->doc, stream); + + as gdb_puts requires that the first argument (the doc string) be + non-nullptr. + + Better, I think, to assert when the cmd_list_element is created, + rather than catching an assert later when 'help CMD' is used. + + I only ran into this case when messing with the Python API command + creation code, I accidentally created a command with a nullptr doc + string, and only found out when I ran 'help CMD' and got an + assertion. + + While I'm adding this assertion, I figure I should also assert that + the command name is not nullptr too. Looking through cli-decode.c, + there seems to be plenty of places where we assume a non-nullptr name. + + Built and tested on x86-64 GNU/Linux with an all-targets build; I + don't see any regressions, so (I hope) there are no commands that + currently violate this assertion. + + Approved-By: Simon Marchi + +2025-04-14 GDB Administrator + + Automatic date update in version.in + +2025-04-13 WANG Xuerui + + LoongArch: Support LA32R aliases rdcnt{vl,vh,id}.w + These LA32R instructions are in fact special cases of the LA32S/LA64 + rdtime{l,h}.w (with only one output operand instead of two, the other + one being forced to $zero), but are named differently in the LA32R + ISA manual nevertheless. + + As the LA32R names are more memorable to a degree (especially for those + having difficulties remembering which operand corresponds to the node + ID), support them by making them aliases of the corresponding LA32S/LA64 + instruction respectively, and make them render as such in disassembly. + +2025-04-13 GDB Administrator + + Automatic date update in version.in + +2025-04-12 Piotr Rudnicki + + gdb: add Piotr Rudnicki to gdb/MAINTAINERS + +2025-04-12 GDB Administrator + + Automatic date update in version.in + +2025-04-11 Andrew Burgess + + gdb: silence some 'Can't open file' warnings from core file loading + But PR gdb/20126 highlights a case where GDB emits a large number of + warnings like: + + warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing + warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing + warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing + warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing + ... etc ... + + when opening a core file. This commit aims to avoid at least some of + these warnings. + + What we know is that, for at least some of these cases, (e.g. the + '(deleted)' mappings), the content of the mapping will have been + written into the core file itself. As such, the fact that the file + isn't available ('/SYSV604b7d00' at least is a shared memory mapping), + isn't really relevant, GDB can still provide access to the mapping, by + reading the content from the core file itself. + + What I propose is that, when processing the file backed mappings, if + all of the mappings for a file are covered by segments within the core + file itself, then there is no need to warn the user that the file + can't be opened again. The debug experience should be unchanged, as + GDB would have read from the in-core mapping anyway. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30126 + +2025-04-11 Simon Marchi + + gdb: add forward declarations in maint.h + Editing maint.h with clangd shows some errors about obj_section and + objfile being unknown. Add some forward declarations for them. + + Change-Id: Ic4dd12a371198fdf740892254a8f2c1fae2846b9 + +2025-04-11 Andrew Burgess + + bfd: fix missing warnings from bfd_check_format_matches + In PR gdb/31846 the user reported an issue where GDB is unable to find + the build-id within an ELF, despite the build-id being + present (confirmed using readelf). + + The user was able to try several different builds of GDB, and in one + build they observed the warning: + + warning: BFD: FILENAME: unable to decompress section .debug_info + + But in may other builds of GDB this warning was missing. + + There are, I think, a couple of issues that the user is running into, + but this patch is about why the above warning is often missing from + GDB's output. + + I wasn't able to reproduce a corrupted .debug_info section such that + the above warning would be triggered, but it is pretty easy to patch + the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that + the call to bfd_init_section_decompress_status is reported as a + failure, thus triggering the warning. There is a patch that achieves + this in the bug report. + + I did this, and can confirm that on my build of GDB, I don't see the + above warning, even though I can confirm that the _bfd_error_handler + call (in _bfd_elf_make_section_from_shdr) is being reached. + + The problem is back in format.c, in bfd_check_format_matches. This + function intercepts all the warnings and places them into a + per_xvec_messages structure. These warnings are then printed with a + call to print_and_clear_messages. + + If bfd_check_format_matches finds a single matching format, then + print_and_clear_messages, will print all warnings associated with that + single format. + + But if no format matches, print_and_clear_messages will print all the + warnings, so long as all targets have emitted the same set of + warnings, and unfortunately, that is not the case for me. + + The warnings are collected by iterating over bfd_target_vector and + trying each target. My target happens to be x86_64_elf64_vec, and, as + expected this target appears in bfd_target_vector. + + However, bfd_target_vector also includes DEFAULT_VECTOR near the top. + And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me, + the x86_64_elf64_vec entry appears twice in bfd_target_vector, this + means that x86_64_elf64_vec ends up being tried twice, and, as each + try generates one warning, the x86_64_elf64_vec entry in the + per_xvec_messages structure, has two warnings, while the other + per_xvec_messages entries only have one copy of the warning. + + Because of this difference, print_and_clear_messages decides not to + print any of the warnings, which is not very helpful. + + I considered a few different approaches to fix this issue: + + We could de-duplicate warnings in the per_xvec_messages structure as + new entries are added. So for any particular xvec, each time a new + warning arrives, if the new warning is identical to an existing + warning, then don't record it. This might be an interesting change in + the future, but for now I rejected this solution as it felt like a + bodge, the duplicate warnings aren't really from a single attempt at + an xvec, but are from two distinct attempts at the same xvec. And so: + + I wondered if we could remove the duplicate entries from + bfd_target_vector. Or if we could avoid processing the same xvec + twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard + to do, but bfd_target_vector also includes SELECT_VECS, which I think + could contain more duplicates. Changing bfd_check_format_matches to + avoid attempting any duplicate vectors would now require more + complexity than a single flag, and I felt there was an easier + solution, which was: + + I propose that within bfd_check_format_matches, within the loop that + tries each entry from bfd_target_vector, as we switch to each vector + in turn, we should delete any existing warnings within the + per_xvec_messages structure for the target vector we are about to try. + + This means that, if we repeat a target, only the last set of warnings + will survive. + + With this change in place, print_and_clear_messages now sees the same + set of warnings for each target, and so prints out the warning + message. + + Additionally, while I was investigating this issue I managed to call + print_and_clear_messages twice. This caused a crash because the first + call to print_and_clear_messages frees all the associated memory, but + leaves the per_xvec_messages::next field pointing to the now + deallocated object. I'd like to propose that we set the next field to + NULL in print_and_clear_messages. This clearly isn't needed so long + as print_and_clear_messages is only called once, but (personally) I + like to set pointers back to NULL if the object they are pointing to + is free and the parent object is going to live for some additional + time. I can drop this extra change if people don't like it. + + This change doesn't really "fix" PR gdb/31846, but it does mean that + the warning about being unable to decompress .debug_info should now be + printed consistently, which is a good thing. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846 + + Reviewed-By: Alan Modra + +2025-04-11 Guinevere Larsen + + gdb/testsuite: fix gdb.base/dlmopen-ns-ids.exp racy test + The recently included gdb.base/dlmopen-ns-ids.exp test can sometimes + fail the call to get_integer_valueof when trying to check the namespace + ID of the fourth dlopened SO, for apparently no reason. + + What's happening is that the call to get_first_so_ns doesn't necessarily + consume the GDB prompt, and so get_integer_valueof will see the prompt + immediately and not find the value the test is looking for. + + To fix this, the test was changed so that we consume all of the output + of the command "info sharedlibrary", but only set the namespace ID for + the first occurrence of the SO we're looking for. The command now also + gets the solib name as a parameter, to reduce the amount of output. + + Co-Authored-By: Tom de Vries + Approved-By: Tom de Vries + +2025-04-11 GDB Administrator + + Automatic date update in version.in + +2025-04-10 H.J. Lu + + ld: Skip the LTO archive member only for the earlier DSO + commit 2707d55e539ef323dd14a1293e762bf3d9739ee7 + Author: Michael Matz + Date: Mon Mar 31 15:57:08 2025 +0200 + + skipped the LTO archive member even when the earlier item is also an + archive. Instead, skip the LTO archive member only if the earlier item + is a shared library. + + bfd/ + + PR ld/32846 + PR ld/32854 + * elflink.c (elf_link_add_archive_symbols): Skip the LTO archive + member only if the earlier item is a shared library. + + ld/ + + PR ld/32846 + PR ld/32854 + * testsuite/ld-plugin/lto.exp: Run ld/32846 test. + * testsuite/ld-plugin/pr32846a.c: New file. + * testsuite/ld-plugin/pr32846b.c: Likewise. + * testsuite/ld-plugin/pr32846c.c: Likewise. + * testsuite/ld-plugin/pr32846d.c: Likewise. + * testsuite/ld-plugin/pr32846e.c: Likewise. + +2025-04-10 Tom de Vries + + [gdb/cli] Fix typo in cli-dump.c + Fix the folowing typo: + ... + $ codespell --config gdb/contrib/setup.cfg gdb/cli + gdb/cli/cli-dump.c:400: useable ==> usable + ... + and add gdb/cli to the pre-commit codespell configuration. + + Approved-By: Tom Tromey + +2025-04-10 Tom de Vries + + [gdb/unittests] Ignore spellcheck warning in rsp-low-selftests.c + Ignore the following spellcheck warning: + ... + $ codespell --config gdb/contrib/setup.cfg gdb/unittests + gdb/unittests/rsp-low-selftests.c:54: fo ==> of, for, to, do, go + ... + and add gdb/unittests to the pre-commit codespell configuration. + + Approved-By: Tom Tromey + +2025-04-10 Tom de Vries + + [gdb/config] Fix codespell warnings + Fix the following codespell warnings: + ... + $ codespell --config gdb/contrib/setup.cfg gdb/config + gdb/config/djgpp/README:178: unitialized ==> uninitialized + gdb/config/djgpp/djconfig.sh:126: conatain ==> contain + ... + and add gdb/config to the pre-commit codespell configuration. + + Approved-By: Tom Tromey + +2025-04-10 Alan Modra + + PR32858 ld segfault on fuzzed object + We missed one place where it is necessary to check for empty groups. + + PR 32858 + * elflink.c (elf_gc_sweep): Protect against empty group. + +2025-04-10 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/fission-with-type-unit.exp with remote host + When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote + host configuration, say host board local-remote-host and target board + remote-gdbserver-on-localhost, I run into: + ... + (gdb) maint expand-symtabs^M + During symbol reading: Could not find DWO CU \ + fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \ + [in module /home/remote-host/fission-with-type-unit]^M + warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \ + by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M + (gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs + ... + + Fix this by adding the missing download to remote host of the .dwo file. + + Tested by running make-check-all.sh on x86_64-linux. + +2025-04-10 GDB Administrator + + Automatic date update in version.in + +2025-04-09 Matthieu Longo + + aarch64 tests: escape dot in regex pattern to really match a dot + +2025-04-09 Simon Marchi + + gdb/testsuite: fix copyright years in gdb.dwarf2/fission-with-type-unit.{c,exp} + When writing the test, I copied these copyright entries from another + file but forgot to adjust the dates, do that now. + + Change-Id: Ie458ad4ec81062b5ef24f78334f3d0920c99b318 + +2025-04-09 Simon Marchi + + gdbsupport: fix Makefile.in copyright dates + Commit d01e823438 ("Update copyright dates to include 2025") incorrectly + changed the dates in Makefile.in. Re-run `autoreconf` in the gdbsupport + directory to fix that up. + + Change-Id: Ifcdb6f2257e7a456439dfc3e7848db934a4b16b4 + +2025-04-09 Simon Marchi + + sim: fix Makefile.in copyright dates + Commit d01e823438 ("Update copyright dates to include 2025") incorrectly + changed the dates in Makefile.in. Re-run `autoreconf` in the sim + directory to fix that up. + + Change-Id: Ia02a54e5330d77b490cc7745eee3d281c7888eec + +2025-04-09 Simon Marchi + + gnulib: revert copyright date changes in imported files + Commit d01e823438 ("Update copyright dates to include 2025") changed the + dates in the gnulib imported source files, it probably shouldn't have. + Re-run update-gnulib.sh to restore those files. + + gnulib/Makefile.in was also incorrectly modified, running the script + fixes that too. + + Change-Id: I5d081f3438b9480130a92f59fd9fede33c121f9c + +2025-04-09 Tom de Vries + + [gdb/testsuite] Allow thread exited message in gdb.threads/infcall-from-bp-cond-simple.exp + With a gdb 15.2 based package and test-case + gdb.threads/infcall-from-bp-cond-simple.exp, I ran into: + ... + Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \ + infcall-from-bp-cond-simple.c:51 + 51 return 1; /* Nested breakpoint. */ + Error in testing condition for breakpoint 2: + The program being debugged stopped while in a function called from GDB. + Evaluation of the expression containing the function + (function_with_breakpoint) will be abandoned. + When the function is done executing, GDB will silently stop. + [Thread 0x7ffff73fe6c0 (LWP 951822) exited] + (gdb) FAIL: $exp: target_async=on: target_non_stop=on: \ + run_bp_cond_hits_breakpoint: continue + ... + + The test fails because it doesn't expect the "[Thread ... exited]" message. + + I have tried to reproduce this test failure, both using 15.2 and current + trunk, but haven't managed. + + Regardless, I think the message is harmless, so allow it to occur, both in + run_bp_cond_segfaults and run_bp_cond_hits_breakpoint. + + Tested on x86_64-linux. + + PR testsuite/32785 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32785 + +2025-04-09 Tom de Vries + + [gdb/symtab] Handle DW_OP_entry_value at function entry + On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into: + ... + (gdb) p sizeof (a)^M + $2 = ^M + (gdb) FAIL: $exp: o1: printed size of optimized out vla + ... + + The variable a has type 0xbf: + ... + <1>: Abbrev Number: 12 (DW_TAG_array_type) + DW_AT_type : <0xe3> + DW_AT_sibling : <0xdc> + <2>: Abbrev Number: 13 (DW_TAG_subrange_type) + DW_AT_type : <0xdc> + DW_AT_upper_bound : 13 byte block: + a3 1 5a 23 1 8 20 24 8 20 26 31 1c + (DW_OP_entry_value: (DW_OP_reg10 (a0)); + DW_OP_plus_uconst: 1; DW_OP_const1u: 32; + DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; + DW_OP_lit1; DW_OP_minus) + ... + which has an upper bound using a DW_OP_entry_value, and since the + corresponding call site contains no information to resolve the value of a0 at + function entry: + ... + <2><6b>: Abbrev Number: 6 (DW_TAG_call_site) + <6c> DW_AT_call_return_pc: 0x638 + <74> DW_AT_call_origin : <0x85> + ... + evaluting the dwarf expression fails, and we get . + + My first thought was to try breaking at *f1 instead of f1 to see if that would + help, but actually the breakpoint resolved to the same address. + + In other words, the inferior is stopped at function entry. + + Fix this by resolving DW_OP_entry_value when stopped at function entry by + simply evaluating the expression. + + This handles these two cases (x86_64, using reg rdi): + - DW_OP_entry_value: (DW_OP_regx: 5 (rdi)) + - DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4) + + Tested on x86_64-linux. + + Tested gdb.base/vla-optimized-out.exp on riscv64-linux. + + Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on + riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so + I haven't tested the current version there. + +2025-04-09 Jens Remus + + s390: Add support for z17 as CPU name + So far IBM z17 was identified as arch15. Add the real name, as it has + been announced. [1] + + [1]: IBM z17 announcement letter, AD25-0015, + https://www.ibm.com/docs/en/announcements/z17-makes-more-possible + + gas/ + * config/tc-s390.c (s390_parse_cpu): Add z17 as alternate CPU + name for arch15. + * doc/c-s390.texi: Likewise. + * doc/as.texi: Likewise. + + opcodes/ + * s390-mkopc.c (main): Add z17 as alternate CPU name for arch15. + +2025-04-09 Tom de Vries + + [gdb/tdep] Handle ldaex and stlex in {thumb,arm}_deal_with_atomic_sequence_raw + The Linaro CI reported a regression [1] in test-case + gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix + gdb.base/step-over-syscall.exp with glibc 2.41"). + + Investigation shows that it's a progression in the sense that the test-case + fails at a later point than before. + + The cause for the test-case failure is that an atomic sequence + ldaex/adds/strex is not skipped over when instruction stepping, leading to a + hang (in the sense of not being able to instruction-step out of the loop + containing the atomic sequence). + + The arm target does have support for recognizing atomic sequences, but it + fails because it doesn't recognize the ldaex insn. + + Fix this by: + - adding a new function ldaex_p which recognizes ldaex instructions, based + on information found in opcodes/arm-dis.c, and + - using ldaex_p in thumb_deal_with_atomic_sequence_raw. + + I was not able to reproduce the failure in its original setting, but I + was able to do so using a test.c: + ... + static void exit (int status) { + while (1) + ; + } + void _start (void) { + int a = 0; + __atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE); + exit (0); + } + ... + compiled like this: + ... + $ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static + ... + giving this atomic sequence of 32-bit Thumb-2 instructions: + ... + 100ce: e8d3 1fef ldaex r1, [r3] + 100d2: f101 0101 add.w r1, r1, #1 + 100d6: e843 1200 strex r2, r1, [r3] + ... + + Without the fix, after 100 stepi's we're still in _start (and likewise with + 10.000 stepi's): + ... + $ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100" + ... + 0x000100dc in _start () + 1: x/i $pc + => 0x100dc <_start+26>: bne.n 0x100ce <_start+12> + ... + but with the fix we've managed to progress to exit: + ... + $ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100" + ... + 0x000100c0 in exit () + 1: x/i $pc + => 0x100c0 : b.n 0x100c0 + ... + + Having addressed the "-mthumb" case, do we need a similar fix for "-marm"? + + Adding "-marm" in the compilation line mentioned above gives the following + atomic sequence: + ... + 100e4: e1931e9f ldaex r1, [r3] + 100e8: e2811001 add r1, r1, #1 + 100ec: e1832f91 strex r2, r1, [r3] + ... + and gdb already recognizes it as such because of this statement: + ... + if ((insn & 0xff9000f0) != 0xe1900090) + return {}; + ... + + The trouble with this statement is that it requires knowledge of arm + instruction encoding to understand which cases it does and doesn't cover. + + Note that the corresponding comment only mentions ldrex: + ... + /* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */ + ... + but evidently at least some forms of ldaex are also detected. + + So, also use ldaex_p in arm_deal_with_atomic_sequence_raw. This may or may + not be redundant, but at least ldaex_p is explicit and precise about what it + supports. + + Likewise for stlex (generated when using __ATOMIC_RELEASE instead of + __ATOMIC_ACQUIRE in the example above). + + Tested in arm-linux chroot on aarch64-linux. + + Reviewed-By: Thiago Jung Bauermann + Co-Authored-By: Thiago Jung Bauermann + Approved-By: Luis Machado + + PR tdep/32796 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796 + + [1] https://linaro.atlassian.net/browse/GNU-1541 + +2025-04-09 GDB Administrator + + Automatic date update in version.in + +2025-04-08 Tom Tromey + + Simplify print_doc_line + print_doc_line uses a static buffer and manually manages memory. I + think neither of these is really needed, so this patch rewrites the + function to use std::string. The new implementation tries to avoid + copying when possible. + + Regression tested on x86-64 Fedora 40. + + Reviewed-By: Keith Seitz + +2025-04-08 Simon Marchi + + gdb: remove unused includes in maint.c + These includes are reported as unused by clangd. + + Change-Id: I1cde043244f9efe350310955b2a02ac874be12b3 + +2025-04-08 Simon Marchi + + gdb/dwarf2: pass correct dwarf2_cu to lookup_dwo_id in create_cus_hash_table + Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader") + introduced a regression when handling files compiled with "-gsplit-dwarf + -fdebug-types-section" (at least with clang): + + $ cat test.cpp + #include + + int main() + { + std::vector v; + return v.size (); + } + $ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test + $ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs" + Reading symbols from ./test... + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed. + + In the main file, we have a skeleton CU with a certain DWO ID: + + 0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ... + + In the .dwo file, the first unit is a type unit with a certain type + signature: + + 0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ... + + and the split compile unit matching the DWO ID from the skeleton from + the main file comes later: + + 0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ... + + The problem introduced by the aforementioned commit is that when + creating a dwo_unit structure representing the type unit, we use the + signature (DWO id) from the skeleton, instead of the signature from the + type unit's header. As a result, all dwo_units get created with the + same signature (the DWO id) and only the first unit gets inserted in the + hash table. When looking up the comp unit by DWO ID later on, we + wrongly find the type unit, and try to expand a type unit as a comp + unit, hitting the assert. + + Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which + yields a dwarf2_cu built from parsing the type unit's header. This + dwarf2_cu contains the comp_unit_header with the correct signature. Fix + the code to use `reader.cu ()` again. + + Another thing that enables this bug is the fact that since DWARF 5, type + and compile units are all in .debug_info, and therefore read by + create_cus_hash_table, so they both end up in dwo_file::cus. Type units + should end up in dwo_file::tus, otherwise they won't be found by + lookup_dwo_cutu. This bug hasn't given me trouble so far, so I'm not + fixing it right now, but it's on my todo list. + + The problem can be seen with some tests, when using the + dwarf5-fission-debug-types board: + + $ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++" + Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ... + FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error) + + But this patch also adds a DWARF assembler-based test that triggers the + internal error. + + Note that the new test does not use the build_executable_and_dwo_files + proc, because I found that it is subtly broken and doesn't work to put + multiple units in a single .dwo file. The debug abbrev offset field in + the second unit's header would be 0, when it should have been something + else. The problem is that no linking is ever done to generate the .dwo + file, so the relocation that would apply for this field is never + applied. Instead, I generate two DWARF debug infos separately and link + the .dwo file using gdb_compile, it seems to work fine. + + Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a + Approved-By: Tom Tromey + +2025-04-08 Simon Marchi + + gdb/testsuite/dwarf: fix abbrev section name when putting type unit in DWO file + Fix what looks like a copy paste error resulting in the wrong abbrev + section name. The resulting section name in my test was + ".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo". + + Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4 + Approved-By: Tom Tromey + +2025-04-08 Simon Marchi + + gdb/testsuite/dwarf: add support to generate DWARF 5 split compile units + Add support to the DWARF assembler to generate DWARF 5 split compile + units. The assembler knows how to generate DWARF < 5 split compile + units (fission), DWARF 5 compile units, but not DWARF 5 split compile + units. What's missing is: + + - using the right unit type in the header: skeleton for the unit in the + main file and split_compile for the unit in the DWO file + - have a way for the caller to specify the DWO ID that will end up in + the unit header + + Add a dwo_id parameter to the cu proc. In addition to specifying the + DWO ID, the presence of this parameter tells the assembler to use the + skeleton or split_compile unit type. + + This is used in a subsequent patch. + + Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9 + Approved-By: Tom Tromey + +2025-04-08 Simon Marchi + + gdb/testsuite: add DWARF 5 + split DWARF + type units board + I'm currently fixing bugs and performance issues when GDB encounters + this particular configuration. Since split DWARF + type units makes GDB + take some code paths not taken by any other board files, I think it + deserves to be its own board file. One particularity is that the + produced .dwo files have a .debug_info.dwo section that contains some + ype units, in addition to the compile unit. + + Add that board to make-check-all.sh. + + Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c + Approved-By: Tom Tromey + +2025-04-08 Tom Tromey + + Update copyright dates to include 2025 + This updates the copyright headers to include 2025. I did this by + running gdb/copyright.py and then manually modifying a few files as + noted by the script. + + Approved-By: Eli Zaretskii + +2025-04-08 Alexandra Hájková + + Rename set-solib-absolute-prefix.exp to x86-set-solib-absolute-prefix.exp + and move it from gdb.base to gdb.arch as it's a target specific test. + + Reviewed-by: Maciej W. Rozycki + Approved-By: Tom Tromey + +2025-04-08 Lulu Cai + + LoongArch: Warn about right shifts of negative numbers + The GNU Assembler User Guide says that the right shift operator ">>" + in an expression is the same as the C operator. + + On LoongArch the assembler directives and instructions do not treat + negative numbers ">>" the same way. The directives treats negative + numbers ">>" as logical right shifts while the instructions treats them + as arithmetic right shifts. + + The right shift of negative numbers in the instructions may be changed + from an arithmetic right shift to a logical right shift in the future, + and a warning is issued for this. + +2025-04-08 GDB Administrator + + Automatic date update in version.in + +2025-04-07 Tom de Vries + + [gdb/cli] Use debug info language to pick pygments lexer + Consider the following scenario: + ... + $ cat hello + + int + main (void) + { + printf ("hello\n"); + return 0; + } + $ gcc -x c hello -g + $ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out + Reading symbols from a.out... + (gdb) start + Temporary breakpoint 1 at 0x4005db: file hello, line 6. + Starting program: /data/vries/gdb/a.out + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + + Temporary breakpoint 1, main () at hello:6 + 6 printf ("hello\n"); + ... + + This doesn't produce highlighting for line 6, because: + - pygments is used for highlighting instead of source-highlight, and + - pygments guesses the language for highlighting only based on the filename, + which in this case doesn't give a clue. + + Fix this by: + - adding a language parameter to the extension_language_ops.colorize interface, + - passing the language as found in the debug info, and + - using it in gdb.styling.colorize to pick the pygments lexer. + + The new test-case gdb.python/py-source-styling-2.exp excercises a slightly + different scenario: it compiles a c++ file with a .c extension, and checks + that c++ highlighting is done instead of c highlighting. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR cli/30966 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966 + +2025-04-07 Tom de Vries + + [gdb/tui] Don't try deferred curses initialization twice + I noticed that if deferred curses initialization fails, for instance when + using TERM=dumb, and we try the same again, we run into the same error: + ... + $ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable" + Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] + Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] + ... + + I think it's better to try deferred curses initialization only once. + + Fix this by changing bool tui_finish_init into a tribool, and using + TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we + get instead: + ... + $ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable" + Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] + Cannot enable the TUI + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-04-07 Michael Matz + + [lto] Fix symlookup in archives vs shared + when a shared library defines 'foo@@FOO' (default version), + a static archive defines 'foo', the shared lib comes in front + of the archive and under effect of --as-needed, and the requesting + object file uses LTO, then the link editor was wrongly including + the definition from the static archive. It must use the one + from the shared lib, like in the non-LTO or the --no-as-needed case. + See the added testcase that would wrongly print "FAIL" before + this patch. + + The problem stems from several connected problems: + (1) only the decorated symbol was entered into first_hash (the hash + table designed to handle definition order in the pre-LTO-plugin + phase of the symbol table walks) + (2) in the archive symbol walk only the undecorated name would be + looked up in first_hash (and hence not found due to (1)) + (3) in the archive symbol walk first_hash would only be consulted + when the linker hash table had a defined symbol. In pre-LTO + phase shared lib symbols aren't entered into the linker symbol + table. + + So: add also the undecorated name into first_hash when it stems from + a default version and consult first_hash in the archive walker also + for currently undefined symbols. If it has an entry which doesn't + point to the archive, then it comes from an earlier library (shared or + static), and so _this_ archive won't provide the definition. + +2025-04-07 Alan Modra + + xcoff dynamic symbol string sanity + Sanity check symbol string table offsets, and tidy structs. "long" + isn't a good choice for _l_zeroes and _l_offset since it can be 64 + bits which blows out the size of the symbol struct unnecessarily. + Also, all of the sizes in internal_ldsym need only be 32 bits, but I + made them size_t because I didn't want to audit all expressions using + them for overflow. + + bfd/ + * xcofflink.c (_bfd_xcoff_canonicalize_dynamic_symtab): Sanity + check symbol _l_offset. + (xcoff_link_add_dynamic_symbols), + (xcoff_link_check_dynamic_ar_symbols): Likewise. + include/ + * coff/xcoff.h (struct internal_ldhdr): Tidy types. + (struct internal_ldsym): Use uint32_t for _l_zeroes and _l_offset. + +2025-04-07 Alan Modra + + xcoff buffer overflow + Much of the xcoff code is not well protected against fuzzed object file + attacks. This sanity checks some values in ".loader". + + * xcofflink.c (xcoff_get_ldhdr): New function. + (_bfd_xcoff_get_dynamic_symtab_upper_bound), + (_bfd_xcoff_canonicalize_dynamic_symtab), + (_bfd_xcoff_get_dynamic_reloc_upper_bound), + (_bfd_xcoff_canonicalize_dynamic_reloc), + (xcoff_link_add_dynamic_symbols), + (xcoff_link_check_dynamic_ar_symbols): Use xcoff_get_ldhdr. + +2025-04-07 Alan Modra + + buffer overflow in nds32_elf_do_9_pcrel_reloc + * elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Properly bounds + check relocation field. + (nds32_elf_hi20_reloc, nds32_elf_generic_reloc): Likewise. + (nds32_elf_final_link_relocate): Likewise. + +2025-04-07 Guinevere Larsen + + gdb: Introduce user-friendly namespace identifier for "info shared" + GDB has had basic support for linkage namespaces for some time already, + but only in the sense of managing multiple copies of the same shared + object being loaded, and a very fragile way to find the correct copy of + a symbol (see PR shlibs/32054). + + This commit is the first step in improving the user experience around + multiple namespace support. It introduces a user-friendly identifier for + namespaces, in the format [[]], that will keep consistent between + dlmopen and dlclose calls. The plan is for this identifier to be usable + in expressions like `print [[1]]::var` to find a specific instance of a + symbol, and so the identifier must not be a valid C++ or Ada namespace + identifier, otherwise disambiguation becomes a problem. Support for + those expressions has not been implemented yet, it is only mentioned to + explain why the identifier looks like this. + + This syntax was chosen based on the C attributes, since nothing in GDB + uses a similar syntax that could confuse users. Other syntax options + that were explored were "#" and "@". The former was + abandoned because when printing a frame, the frame number is also + printed with #, so in a lot of the context in which that the + identifier would show up, it appears in a confusing way. The latter + clashes with the array printing syntax, and I believe that the having + "@N::foo" working completely differently to "foo@2" would also lead to a + bad user experience. + + The namespace identifiers are stored via a vector inside svr4_info + object. The vector stores the address of the r_debug objects used by + glibc to identify each namespace, and the user-friendly ID is the index + of the r_debug in the vector. This commit also introduces a set storing + the indices of active namespaces. The glibc I used to develop this patch + (glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a + deactivated namespace, and requesting a new namespace when a namespace + was previously closed will reuse that namespace. Because of how this is + implemented, this patch lets GDB easily track the exact namespace IDs + that the inferior will see. + + Finally, two new solib_ops function pointers were added, find_solib_ns + and num_active_namespaces, to allow code outside of solib-svr4 to find + and use the namespace identifiers and the number of namespaces, + respectively. As a sanity check, the command `info sharedlibrary` has + been changed to display the namespace identifier when the inferior has + more than one active namespace. With this final change, a couple of tests + had to be tweaked to handle the possible new column, and a new test has + been created to make sure that the column appears and disappears as + needed, and that GDB can track the value of the LMID for namespaces. + + Approved-by: Kevin Buettner + +2025-04-07 Jeremy Drake + + bfd: add load config size workaround for i386 XP and earlier + Per the Microsoft PE documentation, XP and earlier on i686 require the + Size field to be 64, rather than the actual size as required on other + architectures. I have confirmed Windows 11 accepts either 64 or the + actual size for i386 images, but only the actual size for x86_64 images. + + bfd: fill in PE load config directory entry + This is filled in with the rva of _load_config_used if defined (much + like _tls_used), and the size is the first 32-bit value at that symbol. + + bfd: adjust a few error messages + Rationalize the error messages in _bfd_XXi_final_link_postscript(). + They now all correctly refer to DataDirectory instead of DataDictionary, + and use unified format strings, so fewer translations are needed. + + bfd: properly use bfd_get_symbol_leading_char() in peXXigen + This function returns the leading char to use, so we cannot just assume + it will always be '_' or '\0'. + +2025-04-07 Jan Beulich + + bfd/COFF: drop link_add_one_symbol() hook + The need for this has disappeared with dc12032bca08 ("Remove m68k-aout + and m68k-coff support"); avoid the unnecessary indirection. + + Sadly, with ld/pe-dll.c using the wrapper, the removal requires moving + the declaration out of libcoff.h, to properly export the underlying BFD + function. + +2025-04-07 Jan Beulich + + nm: fall back to heuristic when ELF symbol has zero size + Size being set for a symbol isn't a strict requirement in ELF. For ones + not having their size set, fall back to the same logic as used for non- + ELF, non-COFF symbols. + + While there switch to using elf_symbol_from() instead of kind of open- + coding it. + +2025-04-07 Jan Beulich + + nm: also retrieve size for COFF function symbols + Like ELF for all symbols, COFF can record size for at least function + ones. Use that - if available - in preference to the distance-to-next- + symbol heuristic. + + To be able to use the new test there, make TI C54x follow TI C4x in + providing .sdef to cover for .def already having different meaning. + +2025-04-07 Claudiu Zissulescu + + gprofng: Remove duplicate symbols + Remove all duplicate symbols which can be in SymLst. The duplication + is due to processing of both static and dynamic symbols. The + Stabs::removeDupSyms function is called before computing symbol + aliases. + + Introduce a new vector function (i.e., truncate()), that truncates a + vector lenght to the given new count. This functionis used by + removeDupSyms function. + +2025-04-07 Claudiu Zissulescu + + gprofng: Refactor readSymSec for using BFD's asymbol struct + This patch refactors a number of gprofng internal functions for using + more BFD data types and functions. + Stabs::readSymSec is a function which reads the symbols of an ELF file + mapping them into an internal structure. To use BFD asymbols, the + Elf::elf_getsym is changed from custom reading of the symbols from + .symtab and .dynsym section to BFD enable functions. A new function is + introduced which returns the number of either static or dynamic symbols, + named Elf::elf_getSymCount. Both Elf functions are used by + Stabs::readSymSec refactoring. + + Also, this patch removes reading symbols, SUNW_ldnsym section as it is + only used by now defunct Studio compiler. However, it adds the reading + of both static and dynamic symbols, previously, only either one was + processed. + +2025-04-07 Claudiu Zissulescu + + gprofng: Remove check_Relocs() function + check_Relocs() function is not anylonger required as it can only + handle Studio compiler relocs, now defunct. Remove this function. + +2025-04-07 GDB Administrator + + Automatic date update in version.in + +2025-04-06 GDB Administrator + + Automatic date update in version.in + +2025-04-06 Thiago Jung Bauermann + + gdbserver: regcache: Update comment in supply_regblock + Since commit 84da4a1ea0ae ("gdbserver: refactor the definition and uses of + supply_regblock") there is no case where supply_regblock is passed a + nullptr for the BUF argument, and there is even a gdb_assert to make + sure of it. + + Therefore remove that part of the documentation comment. + +2025-04-05 GDB Administrator + + Automatic date update in version.in + +2025-04-04 Jan Beulich + + objcopy: also check --file-alignment option argument + ... to be a power of two, just like --section-alignment does. + + binutils: run objcopy set-section-alignment also for COFF + There's no reason to limit this to just ELF. TI C30 and Z8k don't encode + section alignment in the section entries though (which can't be quite + right, or there would need to be another means by which to express + alignment needs), so --set-section-alignment simply has no effect there. + +2025-04-04 Jan Beulich + + objcopy: constrain --section-alignment to PE binaries again + PR binutils/32732 + + The --set-section-alignment option is what ought to be used on object + files; --section-alignment should be affecting PE binaries only, and + only the value stored in the header. Sections don't individually have + alignment recorded there; see 6f8f6017a0c4 ("PR27567, Linking PE files + adds alignment section flags to executables"). + + Undo the core part of 121a3f4b4f4a ("Update objcopy's + --section-alignment option so that it sets the alignment flag on..."), + which includes removing the testcase again, while leaving all secondary + changes in place. (Note that the testcase did fail anyway for + i?86-interix, with objdump saying "option -P/--private not supported by + this file".) + +2025-04-04 Jan Beulich + + ar/objcopy: harmonize .exe suffix stripping + With it only being the tail of the name which wants checking, using + lbasename() isn't helpful. Mirror what objcopy.c:main() does to ar.c, + merely chaning the plain int of the local variable to size_t. + + binutils: properly split ar and ranlib + By not linking the exact same object file twice, in particular ranlib can + benefit quite a bit from the compiler eliminating dead code. + + binutils: properly split objcopy and strip + By not linking the exact same object file twice, in particular strip can + benefit quite a bit from the compiler eliminating dead code. + +2025-04-04 Tom Tromey + + Make gdb/guile codespell-clean + This cleans up the last codespell reports in the Guile directory and + adds gdb/guile to pre-commit. + + It also tells codespell to ignore URLs. I think this is warranted + because many URLs don't really contain words per se; and furthermore + if any URL-checking is needed at all, it would be for liveness and not + spelling. + + Also I was wondering why the codespell config is in contrib and not + gdb/setup.cfg. + + Approved-By: Tom de Vries + +2025-04-04 Tom Tromey + + Make gdb/python codespell-clean + This cleans up the last codespell report in the Python directory and + adds gdb/python to pre-commit. + + Approved-By: Tom de Vries + +2025-04-04 GDB Administrator + + Automatic date update in version.in + +2025-04-03 Simon Marchi + + gdb/dwarf: rename cache -> abbrev_cache + "cache" is just a bit too generic to be clear. + + Change-Id: I8bf01c5fe84e076af1afd2453b1a115777630271 + +2025-04-03 Tom Tromey + + Many minor typo fixes + I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos. + Most of what remains is trickier, i.e., spots where a somewhat natural + name of something in the code is flagged as a typo. + + Reviewed-By: Tom de Vries + +2025-04-03 Tom de Vries + + [gdb/testsuite] Fix xfail in gdb.ada/array_of_variant.exp + In commit af2b87e649b ("[gdb/testsuite] Add xfail for PR gcc/101633"), I added + an xfail that was controlled by variable old_gcc, triggering the xfail for + gcc 7 and before, but not for gcc 8 onwards: + ... + set old_gcc [expr [test_compiler_info {gcc-[0-7]-*}]] + ... + + In commit 1411185a57e ("Introduce and use gnat_version_compare"), this changed + to: + ... + set old_gcc [gnat_version_compare <= 7] + ... + which still triggered the xfail for gcc 7, because of a bug in + gnat_version_compare. + + After that bug got fixed, the xfail was no longer triggered because the gnatmake + version is 7.5.0, and [version_compare {7 5 0} <= {7}] == 0. + + We could have the semantics for version_compare where we clip the input + arguments to the length of the shortest, and so we'd have + [version_compare {7 5 0} <= {7}] == [version_compare {7} <= {7}] == 1. + + But let's stick with the current version-sort semantics, and fix this by + using [gnat_version_compare < 8] instead. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-04-03 Tom de Vries + + [gdb/testsuite] Add gdb.testsuite/version-compare.exp + Add a test-case gdb.testsuite/version-compare.exp that excercises proc + version_compare, and a note to proc version_compare that it considers + v1 < v1.0 instead of v1 == v1.0. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-04-03 Martin Simmons + + Fix parsing .debug_aranges section for signed addresses. + Some architectures, such as MIPS, have signed addresses and this changes + read_addrmap_from_aranges to record them as signed when required. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32658 + Approved-By: Tom Tromey + +2025-04-03 Tom Tromey + + Fix pp.rs test for gccrs + gccrs still can't process all of gdb's Rust tests, but I did manage to + manually test it on a few. In addition to filing some bug reports, I + came up with this patch. + + There are two fixes here. First, gccrs emits tuple field names as + integers ("0", "1", etc) whereas rustc uses a leading double + underscore ("__0", "__1", etc). This patch changes gdb to accept the + gccrs output, which IMO makes sense (and for which there's already a + rustc feature request). + + Second, it changes rust_struct_anon::evaluate to use check_typedef. + This is a gdb necessity in general, so could be described as an + oversight; but in this case it works around the gccrs oddity that most + named types are emitted as DW_TAG_typedef. I've filed a gccrs bug + report for that. + +2025-04-03 Tom de Vries + + [pre-commit] Add codespell-clean gdb subdirs + As an alternative to adding the gdb dir to codespell while it's still not + codespell-clean [1], add gdb subdirs which are codespell-clean. + + Found using: + ... + $ for d in $(find gdb -maxdepth 1 -type d | egrep -v "testsuite|gdb$"); do \ + echo -n "$d: "; \ + codespell --config gdb/contrib/setup.cfg $d 2>/dev/null \ + | wc -l; \ + done 2>&1 \ + | grep ": 0" + gdb/tui: 0 + gdb/target: 0 + gdb/data-directory: 0 + gdb/po: 0 + gdb/system-gdbinit: 0 + gdb/mi: 0 + gdb/syscalls: 0 + gdb/arch: 0 + gdb/regformats: 0 + gdb/compile: 0 + ... + + Verified using: + ... + $ pre-commit run codespell --all-files + codespell................................................................Passed + ... + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2025-March/216781.html + +2025-04-03 LIU Hao + + ld/testsuite/ld-pe: Escape dots in regular expressions + + ld/ChangeLog: + * testsuite/ld-pe/secidx.d: Escape dots in regular expressions. + +2025-04-03 GDB Administrator + + Automatic date update in version.in + +2025-04-02 Tom Tromey + + Clean up cooked_index::done_reading + The cooked index worker maintains the state for the various state + transition in the scanner. It is held by the cooked_index while + scanning is in progress, then deleted once this has completed. + + I noticed that none of the arguments to cooked_index::done_reading + were really needed -- the cooked_index already has access to the + worker should it need it. Removing these parameters makes the code a + bit simpler and also cleans up some confusing code around the use of + the deferred warnings object. + + Regression tested on x86-64 Fedora 40. + + Approved-By: Simon Marchi + +2025-04-02 Tom Tromey + + Update copyright.py + copyright.py needed an addition for unordered_dense.h. + + Then, when running it, I saw it complain about some .pyc files I had + in the source tree. I don't know why I had these, but the script + should ignore them. + + For this, Kévin suggested using "git ls-files" to determine which + files to update -- that should automatically exclude any random files + in the tree. This version of the patch makes this change. + + There were complaints about some sim/ppc files that were renamed. + Ignoring the entire directory seems simpler given the comment. + + I also made a few more minor changes: + + * Removed the 'CVS' exclusion, as this hasn't been relevant in years. + + * Moved the 'copying.c' exclusion to EXCLUDE_LIST + + * Changed the script to run from the top level (we could have it + automatically find this if we really wanted). + + After this lands, I plan to run it and check in the result. The patch + may be too large (and certainly too uninteresting) to post, so if/when + this happens I will send a brief note to the list about it. + + Approved-By: Simon Marchi + +2025-04-02 Simon Marchi + + gdb/dwarf2: remove unused includes + Remove some includes reported as unused by clangd. + + Change-Id: I841938c3c6254e4f0d154a1e172c4968ff326333 + +2025-04-02 Simon Marchi + + gdb: remove unused includes in dbxread.c + Remove includes reported as unused by clangd. + + Change-Id: I12e5cf254d211f42f3cfdab90d1f42a5986e53a3 + +2025-04-02 Luis Machado + + Fix gdbserver crashes on SVE/SME-enabled systems + Commit 51e6b8cfd649013ae16a3d00f1451b2531ba6bc9 fixed a + regression for SVE/SME registers on gdb's side by using a <= comparison for + regcache's raw_compare assertion check. We seem to have failed to do the same + for gdbserver's raw_compare counterpart. + + With the code as it is, I'm seeing a lot of crashes for gdbserver on a machine + with SVE enabled. For instance, with the following invocation: + + make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.base/break.exp + + Running /work/builds/binutils-gdb/gdb/testsuite/../../../../repos/binutils-gdb/gdb/testsuite/gdb.base/break.exp ... + FAIL: gdb.base/break.exp: test_break: run until function breakpoint + FAIL: gdb.base/break.exp: test_break: run until breakpoint set at a line number (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(6) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(5) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(4) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(3) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(2) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:function(1) breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until quoted breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: run until file:linenum breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: breakpoint offset +1 + FAIL: gdb.base/break.exp: test_break: step onto breakpoint (the program is no longer running) + FAIL: gdb.base/break.exp: test_break: setting breakpoint at } + FAIL: gdb.base/break.exp: test_break: continue to breakpoint at } (the program is no longer running) + FAIL: gdb.base/break.exp: test_no_break_on_catchpoint: runto: run to main + FAIL: gdb.base/break.exp: test_break_nonexistent_line: runto: run to main + FAIL: gdb.base/break.exp: test_break_default: runto: run to main + FAIL: gdb.base/break.exp: test_break_silent_and_more: runto: run to main + FAIL: gdb.base/break.exp: test_break_line_convenience_var: runto: run to main + FAIL: gdb.base/break.exp: test_break_user_call: runto: run to main + FAIL: gdb.base/break.exp: test_finish_arguments: runto: run to main + FAIL: gdb.base/break.exp: test_next_with_recursion: kill program + FAIL: gdb.base/break.exp: test_next_with_recursion: run to factorial(6) + FAIL: gdb.base/break.exp: test_next_with_recursion: continue to factorial(5) (the program is no longer running) + FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5) + FAIL: gdb.base/break.exp: test_next_with_recursion: next to recursive call (the program is no longer running) + FAIL: gdb.base/break.exp: test_next_with_recursion: next over recursive call (the program is no longer running) + FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5.1) + FAIL: gdb.base/break.exp: test_next_with_recursion: continue until exit at recursive next test (the program is no longer running) + FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until function breakpoint, optimized file + FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until breakpoint set at small function, optimized file (the program is no longer running) + FAIL: gdb.base/break.exp: test_rbreak_shlib: rbreak junk + + Adjusting the regcache raw_compare assertion check to use <= fixes + the problem on aarch64-linux on a SVE-capable system. + + This patch also adds a simple selftest to gdbserver that validates this + particular case by simulating a raw_compare operation. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32775 + + Approved-By: Simon Marchi + +2025-04-02 Nick Clifton + + Add optional filename argument to the linker's --stats option, allowing extra resource use information to be reported. + +2025-04-02 Alexandra Hajkova + + Add gdb.base/set-solib-absolute-prefix.exp + Compile a 32-bit x86 executable and then stop within a system call. + Change the sysroot to a non-existent directory, GDB should try (and + fail) to reload the currently loaded shared libraries. However, GDB + should retain the symbols for the vDSO library as that is not loaded + from the file system. + + Check the backtrace to ensure that the __kernel_vsyscall symbol is + still in the backtrace, this indicates GDB still has the vDSO + symbols available. + + This test was present in Fedora for a long time and was + originally written by Jan Kratochvil for this fix + 829a902da291e72ad17e8c44fa8d9ead3db41b1f. + + Co-Authored-By: Jan Kratochvil + Approved-By: Andrew Burgess + +2025-04-02 GDB Administrator + + Automatic date update in version.in + +2025-04-01 Simon Marchi + + gdb: move addrmap::relocate method to addrmap_fixed + The relocate method of addrmap is unnecessarily virtual. Only + addrmap_fixed provides a meaningful implementation. Move the method to + addrmap_fixed only and make it non-virtual. + + Change-Id: If61d5e70abc12c17d1e600adf0dd0707e77a6ba2 + Approved-By: Tom Tromey + +2025-04-01 Tom de Vries + + [gdb/contrib] Support gdb in codespell section of setup.cfg + Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg, + specifically adding files in the skip line. + + This allows us to run codespell from the command line on the gdb dir: + ... + $ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l + 1665 + ... + without running into warnings in generated files. + + Approved-By: Tom Tromey + +2025-04-01 Tom Tromey + + Update cooked_index comment + This updates the cooked_index comment with some notes about object + lifetimes, in an attempt to make navigating this code a bit simpler. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Add cooked_index_worker::done_reading + The two readers currently using cooked_index_worker shared some code. + This patch factors this out into a new "done_reading" method. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Remove cooked_index_worker::result_type + cooked_index_worker::result_type is an ad hoc tuple type used for + transferring data between phases of the indexer. It's a bit unwieldy + and another patch I'm working on would be somewhat nicer without it. + + This patch removes the type. Now cooked_index_ephemeral objects are + transferred instead, which is handy because they already hold the + needed state. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Add addrmap_mutable::clear + It was convenient to add a 'clear' method to addrmap_mutable. The + cleanest way to do this was to change the class to lazily initialize + its 'tree' member. This also makes addrmap_mutable::operator= a bit + less weird. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Update comments from moved methods + This updates the "See xyz.h" comments for all the methods that were + moved earlier in this series. Perhaps I should have removed them + instead. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Move cooked_index_worker to cooked-index-worker.[ch] + This moves the cooked_index_worker class to cooked-index-worker.[ch]. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Change includes in cooked-index-worker.h + This changes cooked-index-worker.h to include the new header files. + This breaks the circular dependency that would otherwise be introduced + in the next patch. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Move cooked_index_shard to new files + This moves cooked_index_shard to a couple of new files, + dwarf2/cooked-index-shard.[ch]. The rationale is the same as the + previous patch: cooked-index.h had to be split to enable other + cleanups. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Move cooked_index_entry to new files + This moves cooked_index_entry and some related helper code to a couple + of new files, dwarf2/cooked-index-entry.[ch]. + + The main rationale for this is that in order to finish this series and + remove "cooked_index_worker::result_type", I had to split + cooked-index.h into multiple parts to avoid circular includes. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Make language_requires_canonicalization 'static' + language_requires_canonicalization is only called from cooked-index.c, + so mark it as static. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Rename cooked_index_storage + This renames cooked_index_storage to cooked_index_worker_result, + making its function more clear. It also updates the class comment to + as well. + + Approved-By: Simon Marchi + +2025-04-01 Tom Tromey + + Rename cooked-index-storage.[ch] + A discussion with Simon made me realize that cooked_index_storage + isn't a very clear name, especially now that it's escaped from read.c. + While it does provide some storage (I guess any object does in a + sense), it is really a helper for cooked_index_worker -- a temporary + object that is destroyed after reading has completed. + + This patch renames this file. Later patches will rename the class and + move cooked_index_worker here, something I think is reasonable given + that cooked_index_storage is really something of a helper class for + cooked_index_worker. + + Approved-By: Simon Marchi + +2025-04-01 Alan Modra + + PR32829, SEGV on objdump function debug_type_samep + u.kenum is always non-NULL, see debug_make_enum_type. + + PR 32829 + * debug.c (debug_type_samep): Correct incomplete enum test. + (debug_write_type): Remove dead code. + +2025-04-01 Alan Modra + + ubsan: nds32 undefined shift + Avoid implementation defined behaviour right shift of negative values, + and undefined behaviour left shift of negative values. While this + change might give different results in the top bit of a bfd_vma + (rightshift is 1), that doesn't matter as only the bottom 8 bits of + the relocation are used. + + * elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Calculate relocation + using a bfd_vma type. + +2025-04-01 Alan Modra + + Formatting fixes for elf-attrs.c + +2025-04-01 Tom Tromey + + Check gnatmake version in gnat_version_compare + Tom de Vries pointed out that my earlier change to + gnat_version_compare made it actually test gcc's version -- not + gnat's. + + This patch changes gnat_version_compare to examine gnatmake's version, + while preserving the nicer API. + + Approved-By: Tom de Vries + +2025-04-01 Clément Chigot + + binutils/testsuite: don't tail the same input and output file + The output file could be created before the input is gathered by tail, + erasing the later before it's being proceeded. + + This happened on rare cases when performing remote tests on + Ubuntu 24.04. + +2025-04-01 Clément Chigot + + binutils/testsuite: move objdump test output into tmpdir + "objdump.out" is a testsuite trace and thus should be created within the + tmpdir. + +2025-04-01 GDB Administrator + + Automatic date update in version.in + +2025-03-31 Thiago Jung Bauermann + + testsuite: fix is_aarch32_target + Commit + + c221b2f77080 Testsuite: Add gdb_can_simple_compile + + changed the source file name extension of the test program from .s to .c + resulting in compile fails. This, in turn, causes is_aarch32_target + checks to fail. + + Change the test source from an assembly program to a C program using + inline assembly. + + is_amd64_regs_target had a similar problem, which was fixed by commit + + 224d30d39365 testsuite: fix is_amd64_regs_target + + This fix — and commit message — are mostly copied from it. + + Approved-By: Simon Marchi + +2025-03-31 Michael Eager + + gdbserver: Add support for MicroBlaze host microblaze*-*-linux* + +2025-03-31 Tom de Vries + + [gdb/record] Make enum gdb_syscall value names consistent + In enum gdb_syscall, there are 3 entries that do not have the gdb_sys_ prefix + ... + $ grep gdb_old_ gdb/linux-record.h + gdb_old_select = 82, + gdb_old_readdir = 89, + gdb_old_mmap = 90, + ... + like all the other entries: + ... + gdb_sys_restart_syscall = 0, + gdb_sys_exit = 1, + gdb_sys_fork = 2, + gdb_sys_read = 3, + ... + + The three correspond to these entries in + arch/x86/entry/syscalls/syscall_32.tbl: + ... + [ [noreturn]] + 82 i386 select sys_old_select compat_sys_old_select + 89 i386 readdir sys_old_readdir compat_sys_old_readdir + 90 i386 mmap sys_old_mmap compat_sys_ia32_mmap + ... + + As we can see, the enum uses the entry point name, but without the sys_ + prefix. + + There doesn't seem to be a good reason for this. + + There's another enum value: + ... + gdb_sys_old_getrlimit = 76, + ... + corresponding to: + ... + 76 i386 getrlimit sys_old_getrlimit compat_sys_old_getrlimit + ... + where we do use the sys_ prefix. + + Fix this by consistenly using the gdb_sys_ prefix in enum gdb_syscall. + + No functional changes. + + Approved-By: Simon Marchi + +2025-03-31 Tom de Vries + + [gdb/contrib] Remove spellcheck.sh + Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and + associated file gdb/contrib/common-misspellings.txt. + + Approved-By: Tom Tromey + +2025-03-31 Tom de Vries + + [gdb] Check strpbrk against nullptr + In noticed two occurrences of "if (strpbrk (...))". + + Fix this style issue by checking against nullptr. + +2025-03-31 Lancelot SIX + + gdbsupport/common-inferior.c: Fix mingw build + A recent change (512ca2fca4b "gdb: split up + construct_inferior_arguments") introduced a build failure for mingw: + + CXX common-inferior.o + .../gdb/gdbsupport/common-inferior.cc: In function ‘std::string escape_characters(const char*, const char*)’: + .../gdb/gdbsupport/common-inferior.cc:62:20: error: ‘argv’ was not declared in this scope; did you mean ‘arg’? + 62 | if (strpbrk (argv[i], special)) + | ^~~~ + | arg + .../gdb/gdbsupport/common-inferior.cc:62:25: error: ‘i’ was not declared in this scope + 62 | if (strpbrk (argv[i], special)) + | ^ + + This patch fixes that. + + Change-Id: I07ade607bc4516627b433085b07d9d198d8e4b4a + Approved-By: Tom de Vries + +2025-03-31 Martin Storsjö + + ld/PE: Add another mingw UCRT library name to the autoexport exclusion list + Since 2020, mingw-w64 provides a C runtime import library variant + named "libucrtapp" too, exclude this one from autoexports like + the others. + +2025-03-31 Tom de Vries + + [pre-commit] Add codespell hook + Add a pre-commit codespell hook for directories gdbsupport and gdbserver, + which are codespell-clean: + ... + $ pre-commit run codespell --all-files + codespell................................................................Passed + ... + + A non-trivial question is where the codespell configuration goes. + + Currently we have codespell sections in gdbsupport/setup.cfg and + gdbserver/setup.cfg, but codespell doesn't automatically use those because the + pre-commit hook runs codespell at the root of the repository. + + A solution would be to replace those 2 setup.cfg files with a setup.cfg in the + root of the repository. Not ideal because generally we try to avoid adding + files related to subdirectories at the root. + + Another solution would be to add two codespell hooks, one using + --config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and + add a third one once we start supporting gdb. Not ideal because it creates + duplication, but certainly possible. + + I went with the following solution: a setup.cfg file in gdb/contrib (alongside + codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport. + + So, what can this new setup do for us? Let's demonstrate by simulating a typo: + ... + $ echo "/* aways */" >> gdbsupport/agent.cc + ... + + We can check unstaged changes before committing: + ... + $ pre-commit run codespell --all-files + codespell................................................................Failed + - hook id: codespell + - exit code: 65 + + gdbsupport/agent.cc:282: aways ==> always, away + ... + + Likewise, staged changes (no need for the --all-files): + ... + $ git add gdbsupport/agent.cc + $ pre-commit run codespell + codespell................................................................Failed + - hook id: codespell + - exit code: 65 + + gdbsupport/agent.cc:282: aways ==> always, away + ... + + Or we can try to commit, and run into the codespell failure: + ... + $ git commit -a + black................................................(no files to check)Skipped + flake8...............................................(no files to check)Skipped + isort................................................(no files to check)Skipped + codespell................................................................Failed + - hook id: codespell + - exit code: 65 + + gdbsupport/agent.cc:282: aways ==> always, away + + check-include-guards.................................(no files to check)Skipped + ... + which makes the commit fail. + + Approved-By: Tom Tromey + +2025-03-31 GDB Administrator + + Automatic date update in version.in + +2025-03-30 Tom de Vries + + [gdb/tdep] Fix mmap syscall mapping + There are a few spots where an mmap system call is mapped onto enum + gdb_syscall value gdb_sys_mmap2. + + Strictly speaking, this is incorrect. + + Fix this by mapping to enum gdb_syscall value gdb_old_mmap instead. + + No functional changes: both gdb_old_mmap and gdb_sys_mmap2 are handled the + same in record_linux_system_call. + + Tested by rebuilding on x86_64-linux. + +2025-03-30 Tom de Vries + + [gdb] Skip selftest with warning + With the selftest register_name, we run into a few warning: + ... + $ gdb -q -batch -ex "maint selftest register_name" 2>&1 \ + | grep -B1 warning: + Running selftest register_name::m68hc11. + warning: No frame soft register found in the symbol table. + -- + Running selftest register_name::m68hc12. + warning: No frame soft register found in the symbol table. + -- + Running selftest register_name::m68hc12:HCS12. + warning: No frame soft register found in the symbol table. + ... + + We already filter out these architectures in other selftests because of the + same warning. + + Do the same in this selftest. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2025-03-30 GDB Administrator + + Automatic date update in version.in + +2025-03-29 Andrew Burgess + + gdb: remove disable_breakpoints_in_shlibs function + I think there is a problem with the disable_breakpoints_in_shlibs + function: it can disable breakpoint locations without calling + notify_breakpoint_modified. This means that the Python API's + breakpoint_modified event will not trigger, nor will the MI send a + breakpoint modified event. + + I started looking at disable_breakpoints_in_shlibs because of an + earlier commit: + + commit 8c48ec7a6160aed0d1126c623443935e4435cd41 + Date: Thu Aug 29 12:34:15 2024 +0100 + + gdb: handle dprintf breakpoints when unloading a shared library + + Currently disable_breakpoints_in_shlibs is only called from one + location, clear_solib in solib.c. clear_solib also calls + notify_solib_unloaded for every solib in the program_space of + interest, and notify_solib_unloaded will call + disable_breakpoints_in_unloaded_shlib via the solib_unloaded + observer. These two function, disable_breakpoints_in_shlibs and + disable_breakpoints_in_unloaded_shlib are very similar in what they + do. + + I think that we can remove the disable_breakpoints_in_shlibs call, and + instead, tweak how we call disable_breakpoints_in_unloaded_shlib in + order to get the same end result, except that, after this change, we + will call notify_breakpoint_modified, which means the Python API event + will trigger, and the MI events will be emitted. + + All that disable_breakpoints_in_shlibs does is disable some + breakpoints. + + Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the + same set of breakpoints, call notify_breakpoint_modified, and + then (for some breakpoint types) print a message telling the user that + the breakpoint has been disabled. However, this function will ignore + any breakpoints that are already disabled. + + As disable_breakpoints_in_shlibs disables the same set of breakpoints, + the result of the current code is that disable_breakpoints_in_shlibs + serves only to prevent the notify_breakpoint_modified call, which I + think is wrong, and to prevent the user message being printed, which I + think is reasonable. + + If we remove the disable_breakpoints_in_shlibs call without making any + additional changes, then we start to see some message printed in cases + like this: + + (gdb) start + The program being debugged has been started already. + Start it from the beginning? (y or n) y + warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so" + Temporary breakpoint 3 at 0x40113e: file test.c, line 9. + Starting program: /tmp/shared-lib-test/test.x + + Notice the 'warning:' line, which is new. I think this is confusing + because, in most cases the breakpoint will be enabled again by the + time the inferior reaches `main` and stops. + + In the future I'm interested in exploring if GDB could be smarter + about when to print these 'Temporarily disabling breakpoints ...' + messages so that if the 'start' command does mean a breakpoint is left + disabled, then the user would be informed. However, I don't propose + doing that work immediately, and certainly not in this commit. For + now, my intention is to leave things as they are right now, GDB + doesn't warn about disabling breakpoints during an inferior re-start. + + To achieve this I think we need to pass a new argument to + disable_breakpoints_in_unloaded_shlib which controls whether we should + print a message about the breakpoint being disabled or not. With this + added we can now silence the warning when the inferior is + restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called + from clear_solib), but keep the warning for cases like stepping over a + dlclose() call in the inferior. + + After this commit, GDB now emits breakpoint modified events (in Python + and/or MI) when a breakpoint is disabled as a result of all shared + libraries being unloaded. This will be visible in two places that I + can thing of, the 'nosharedlibrary' command, and when an inferior is + restarted. + +2025-03-29 H.J. Lu + + x86: Add {noimm8s} pseudo prefix + Instruction templates with only sign-extended 8-bit immediate operand + also have a second template with full-operand-size immediate operand + under a different opcode. Add {noimm8s} pseudo prefix to exclude + templates with only sign-extended 8-bit immediate operand. + + gas/ + + PR gas/32811 + * config/tc-i386.c (pseudo_prefixes): Add no_imm8s. + (operand_size_match): Return false for templates with only sign- + extended 8-bit immediate operand if {noimm8s} is used. + (parse_insn): Handle Prefix_NoImm8s. + * doc/c-i386.texi: Document {noimm8s}. + * testsuite/gas/i386/pseudos.s: Add tests for {noimm8s}. + * testsuite/gas/i386/x86-64-pseudos.s: Likewise. + * testsuite/gas/i386/pseudos.d: Updated. + * testsuite/gas/i386/x86-64-pseudos.d: Likewise. + + opcodes/ + + PR gas/32811 + * opcodes/i386-opc.h (Prefix_NoImm8s): New. + * i386-opc.tbl: Add {noimm8s} pseudo prefix. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Likewise. + +2025-03-29 H.J. Lu + + gprof: Always compile tests with -g + Always compile gprof testsuite with -g for line number info checked by + tst-gmon-gprof-l.sh. + + PR gprof/32779 + * testsuite/Makefile.am (GPROF_FLAGS): Add -g. + (COMPILE): Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS)". + (LINK) Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS) $(AM_LDFLAGS) + $(LDFLAGS) -o $@". + * testsuite/Makefile.in: Regenerated. + +2025-03-29 GDB Administrator + + Automatic date update in version.in + +2025-03-28 Andrew Burgess + + gdb: reduce breakpoint-modified events for dprintf b/p + Consider this backtrace within GDB: + + #0 notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083 + #1 0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523 + #2 0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641 + #3 0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476 + #4 0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298 + + Whenever breakpoint_re_set is called we re-build the commands that the + dprintf b/p will execute and store these into the breakpoint. The + commands are re-built in update_dprintf_command_list and stored into + the breakpoint object in breakpoint_set_commands. + + Now sometimes these commands can change, dprintf_breakpoint::re_set + explains one case where this can occur, and I'm sure there must be + others. But in most cases the commands we recalculate will not + change. This means that the breakpoint modified event which is + emitted from breakpoint_set_commands is redundant. + + This commit aims to eliminate the redundant breakpoint modified events + for dprintf breakpoints. This is done by adding a commands_equal call + to the start of breakpoint_set_commands. + + The commands_equal function is a new function which compares two + command_line objects and returns true if they are identical. Using + this function we can check if the new commands passed to + breakpoint_set_commands are identical to the breakpoint's existing + commands. If the new commands are equal then we don't need to change + anything on the new breakpoint, and the breakpoint modified event can + be skipped. + + The test for this commit stops at a dlopen() call in the inferior, + sets up a dprintf breakpoint, then uses 'next' to step over the + dlopen() call. When the library loads GDB call breakpoint_re_set, + which calls dprintf_breakpoint::re_set. But in this case we don't + expect the calculated command string to change, so we don't expect to + see the breakpoint modified event. + +2025-03-28 Keith Seitz + + Fix gstack issues + With commit fb2ded33c1e519659743047ed7817166545b6d91, I added + Fedora's gstack script to gdb. Some issues have arisen since + then, and this patch addresses those issues: + + . As Sam James recently noted[1], PKGVERSION and VERSION + need to be quoted. + . A Fedora user reported the misuse of --readnever, which + causes gstack to omit filename and line number information in the + backtrace[Red Hat BZ 2354997]. + + [1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/ + Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997 + +2025-03-28 Jens Remus + + x86: Pass $NOPIE_LDFLAGS to undefined weak tests + Some distributions configure GCC with --enable-default-pie, so that it + defaults to compile with -fPIE and link with -pie, which is unexpected + by some of the tests. Therefore link the PDE test programs with + $NOPIE_LDFLAGS to disable PIE. + + This complements commit a7eaf017f959 ("Use NOPIE_CFLAGS and + NOPIE_LDFLAGS to disable PIE"). + + ld/testsuite/ + PR ld/21090 + * ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to + disable PIE for the non-PIE versions of the test. + + Bug: https://sourceware.org/PR21090 + +2025-03-28 Jens Remus + + ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF visibility tests + Some distributions configure GCC with --enable-default-pie, so that it + defaults to compile with -fPIE and link with -pie, which is unexpected + by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS + and link the test programs with $NOPIE_LDFLAGS. + + Commit 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added + $NOPIE_CFLAGS when compiling sh1np.o and sh2np.o. It missed to add it + to mainnp.o. + + ld/testsuite/ + PR ld/21090 + * ld-vsb/vsb.exp (visibility_test): Add support for optional + ldflags argument and use it when linking the test program. + (mainnp.o): Compile with $NOPIE_CFLAGS. + (vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS. + + Fixes: 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") + Bug: https://sourceware.org/PR21090 + +2025-03-28 Jens Remus + + ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to even more ELF shared tests + Some distributions configure GCC with --enable-default-pie, so that it + defaults to compile with -fPIE and link with -pie, which is unexpected + by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS + and link the test programs with $NOPIE_LDFLAGS. + + Commit 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF + tests") added $NOPIE_CFLAGS when compiling sh1np.o. It missed to add it + to sh2np.o and mainnp.o. + + ld/testsuite/ + PR ld/21090 + * ld-shared/shared.exp (shared_test): Add support for optional + ldflags argument and use it when linking the test program. + (sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS. + (shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS. + + Fixes: 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests") + Bug: https://sourceware.org/PR21090 + +2025-03-28 Jens Remus + + ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr21964-4 + Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on + Fedora 41. The reason is that GCC on Ubuntu is configured with + --enable-default-pie, so that it defaults to compile with -fPIE + and link with -pie, which causes the test to erroneously fail. + + ld/testsuite/ + PR ld/21090 + * ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and + link with $NOPIE_LDFLAGS. + + Bug: https://sourceware.org/PR21090 + +2025-03-28 Jens Remus + + ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr19719 + Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41 + but not on Ubuntu 24.10. The reason is that GCC on Ubuntu is configured + with --enable-default-pie, so that it defaults to compile with -fPIE + and link with -pie, which hides the test fail. + + ld/testsuite/ + PR ld/21090 + * ld-elf/shared.exp: Compile pr19719 (non-PIE) with + $NOPIE_CFLAGS and link with $NOPIE_LDFLAGS. + + Bug: https://sourceware.org/PR21090 + +2025-03-28 Marek Pikuła + + RISC-V: Don't show support for 1.9.1 priv spec + The privileged spec 1.9.1 support was removed since binutils 2.43. The + linker only recognizes it and then reports a warning that it may + conflict with other spec versions. + + While the support is removed, binutils should still recognize it, but it + shouldn't be exposed to the user in `disassember-options` help. + +2025-03-28 Marek Pikuła + + doc/riscv: Add description of disassembler options + Up to this point, no mention of RISC-V-specific disassembler options was + mentioned in binutils documentation. This patch includes description for + all of the currently supported options. + +2025-03-28 GDB Administrator + + Automatic date update in version.in + +2025-03-27 Craig Blackmore + Andrew Burgess + + gdb: Fix assertion failure when inline frame #0 is duplicated + Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces + the following incorrect backtrace: + + #0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49 + #1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 + #2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50 + #3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + (gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 + + The expected output, which we get with `bt`, is: + + #0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49 + #1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 + + The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer + frame ids having already been computed and stashed. Unlike other + frames, frame #0's id does not get computed immediately. + + The test passes with `bt` because when applying python frame filters, + the call to `bootstrap_python_frame_filters` happens to compute the id + of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to + stash frame #2's id, the cycle is detected. + + The test fails with `bt -no-filters` because frame #0's id has not been + stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash + frame #2's id which succeeds and the cycle is only detected later when + trying to stash frame #4's id. Doing `stepi` after the incorrect + backtrace would then trigger an assertion failure when trying to stash + frame #0's id because it is a duplicate of #2's already stashed id. + + In `get_prev_frame_always_1`, if this_frame is inline frame 0, then + compute and stash its frame id before returning the previous frame. + This ensures that the id of inline frame 0 has been stashed before + `get_prev_frame_maybe_check_cycle` is called on older frames. + + The test case has been updated to run both `bt` and `bt -no-filters`. + +2025-03-27 Tom de Vries + + [gdb/contrib] Drop two words from codespell-ignore-words.txt + Tom Tromey mentioned [1] that the words "invokable" and "useable" + present in codespell-ignore-words.txt should be dropped. + + Do so and fix the following typos: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport + gdbsupport/common-debug.h:218: invokable ==> invocable + gdbsupport/event-loop.cc:84: useable ==> usable + ... + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html + +2025-03-27 Tom de Vries + + [gdb/contrib] Add SME to codespell-ignore-words.txt + Ignore the following codespell detection: + ... + $ codespell --config gdbserver/setup.cfg gdbserver + gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS + ... + by adding SME to codespell-ignore-words.txt. + + [gdbserver] Fix typo in tracepoint.cc + Fix a typo: + ... + $ codespell --config gdbserver/setup.cfg gdbserver/tracepoint.cc + gdbserver/tracepoint.cc:951: mistakingly ==> mistakenly + ... + + [gdbsupport] Ignore pathc in codespell check in gdb_tilde_expand.cc + Ignore the following codespell detections: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport + gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch + gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch + ... + by adding codespell:ignore comments. + + [gdbsupport] Fix a typo in common-debug.h + Fix a typo: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h + gdbsupport/common-debug.h:109: re-used ==> reused + ... + +2025-03-27 oltolm + Simon Farre + + gdb/dap - Add CompletionsRequest + Use GDB/MI command "-complete" to implement. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31140 + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2025-03-27 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp + In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run + into: + ... + (gdb) inferior 2 + [Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)] + [Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running) + (gdb) print global_var = 555 + $1 = 555 + (gdb) print global_var + $2 = 556 + (gdb) FAIL: $exp: all-stop: access mem \ + (print global_var after writing, inf=2, iter=1) + ... + + I managed to reproduce this on current trunk using a reproducer patch (posted + in the PR). + + The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix + gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced + an increment of global_var at the start of main. + + This created a race between: + - gdb modifying global_var, and + - the inferior modifying global_var. + + Fix this by: + - adding a new empty function setup_done, + - adding a call to setup_done after the increment of global_var, and + - rather than running to main, running to setup_done. + + Tested on x86_64-linux. + + PR testsuite/32822 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822 + +2025-03-27 Haochen Jiang + + x86: Remove AVX10.2 256 bit rounding support + Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit + rounding is not that useful because we currently have rounding feature + directly on E-core now and no need to use 256-bit rounding as somehow + a workaround. This patch will remove all the support and backport to + Binutils 2.44. + + gas/ChangeLog: + + * NEWS: Mention support removal. + * config/tc-i386.c (build_evex_prefix): Remove U bit encode. + (check_VecOperands): Remove ymm check for rounding. + (s_insn): Revise .insn comment. + * testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm + rounding related test. + * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/evex.d: Ditto. + * testsuite/gas/i386/evex.s: Ditto. + * testsuite/gas/i386/i386.exp: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-evex.d: Ditto. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-rounding-intel.d: Removed. + * testsuite/gas/i386/avx10_2-rounding-inval.l: Removed. + * testsuite/gas/i386/avx10_2-rounding-inval.s: Removed. + * testsuite/gas/i386/avx10_2-rounding.d: Removed. + * testsuite/gas/i386/avx10_2-rounding.s: Removed. + * testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed. + * testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed. + * testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed. + + opcodes/ChangeLog: + + * i386-dis.c (struct instr_info): Remove U bit. + (get_valid_dis386): Roll back to APX condition. + * i386-opc.tbl: Remove ymm rounding support. + * i386-tbl.h: Regenerated. + +2025-03-27 GDB Administrator + + Automatic date update in version.in + +2025-03-26 Guinevere Larsen + + gdb/testsuite: Force DWARF debuginfo where applicable in AIX systems + In the AIX systems available for testing in the gcc compile farm, the + default debug information format is stabs. This is a problem for many + reasons, mainly that stabs is not as complete as dwarf and stabs is + being deprecated in the next release. In the current state, we have: + PASS: 39798 + FAIL: 7405 + When running these tests, I unfortunately didn't have the foresight to + save the number of unsupported and untested cases. + + To improve testing there, this patch changes the gdb_compile TCL proc, so + that if we're running tests in AIX, we requested debug info, and we + haven't explicitly asked for some debuginfo format, gdb_compile will add + -gdwarf to the compilation line, forcing DWARF to be used. After this + patch, we get: + PASS: 74548 + FAIL: 5963 + + So not only do we have fewer failures, there are tens of thousands of + tests that are no longer skipped. + + Approved-By: Tom Tromey + +2025-03-26 Jens Remus + + ld: Correct test pr19719 naming mix-up + The suffix "defined/undefined" in the ld test pr19719 name specifies + whether weak fun() is defined or undefined is mixed up. + + The test builds an executable and a shared library. The latter in two + flavors, one with weak fun() defined (libpr19719a.so, "defined") and + one without weak fun() defined (libpr19719b.so, "undefined"). + + The first "Run $exe fun [...]" invocation uses libpr19719b.so as + libpr19719.so, which is build from dummy.c, which does not define fun. + Thus fun is undefined during this test run. + + The second "Run $exe fun [...]" invocation uses libpr19719a.so as + libpr19719.so, which is build from pr19719d.c, which does define fun. + Thus fun is defined during this test run. + + Correct the test naming mix-up accordingly. + + ld/testsuite/ + * ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming + mix-up of when weak fun is un-/defined. + +2025-03-26 Guinevere Larsen + + gdb: add configure option to disable compile + GDB's compile subsystem is deeply tied to GDB's ability to understand + DWARF. A future patch will add the option to disable DWARF at configure + time, but for that to work, the compile subsystem will need to be + entirely disabled as well, so this patch adds that possibility. + + I also think there is motive for a security conscious user to disable + compile for it's own sake. Considering that the code is quite + unmaintained, and depends on an equally unmaintained gcc plugin, there + is a case to be made that this is an unnecessary increase in the attack + surface if a user knows they won't use the subsystem. Additionally, this + can make compilation slightly faster and the final binary is around 3Mb + smaller. But these are all secondary to the main goal of being able to + disable dwarf at configure time. + + To be able to achieve optional compilation, some of the code that + interfaces with compile had to be changed. All parts that directly + called compile things have been wrapped by ifdefs checking for compile + support. The file compile/compile.c has been setup in a similar way to + how python's and guile's main file has been setup, still being compiled + but only for with placeholder command. + + Finally, to avoid several new errors, a new TCL proc was introduced to + gdb.exp, allow_compile_tests, which checks if the "compile" command is + recognized before the inferior is started and otherwise skips the compile + tests. All tests in the gdb.compile subfolder have been updated to use + that, and the test gdb.base/filename-completion also uses this. The proc + skip_compile_feature_tests to recognize when the subsystem has been + disabled at compile time. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-03-26 Guinevere Larsen + + gdb: Remove compile-related attributes from struct language + The following patch will add a configure option to disable the compile + subsystem at compilation time. To do that, nearly all code that + interfaces with compile should be confined to the compile sub-folder. + + This commit is the first step, removing the compile-related method from + the language struct and adding 2 new functions to compile.c that do the + same job in a slightly different way. Adding things to the language + struct is a more extendable way to add support for languages, but + considering compile is quite bit-rotted and questionably supported, I + don't think it will be extended any time soon, and using ifdefs to + handle disabling compile with configure felt like a messier solution. + + There should be no visible changes after this commit. + + Approved-By: Tom Tromey + +2025-03-26 Simon Marchi + + gdb/dwarf: use reference in cutu_reader::cutu_reader interface + Change some parameters to be references instead of pointers, when the + value must not be nullptr. I'd like to do this more of this kind of + change, but I have to limit the scope of the change, otherwise there's + just no end (and some local variables could also be turned into + references). So for now, just do it the cutu_reader constructors. + + Change-Id: I9442c6043726981d58f9b141f516c590c0a71bcc + Approved-By: Tom Tromey + +2025-03-26 Simon Marchi + + gdb/dwarf: update comment of cutu_reader::cutu_reader (the DWO variant) + The comment on this constructor is really outdated. Update it to better + reflect the reality today. + + I'd eventually like to change this cutu_reader constructor not to use + dwarf2_per_cu, because it seems like an abuse of dwarf2_per_cu just to + pass 3 values. But for now, just document the existing behavior. + + Change-Id: Id96db020c361e64d9b0d2f25d51950b206658aa2 + Approved-By: Tom Tromey + +2025-03-26 Simon Marchi + + gdb/dwarf: remove redundant read of dwo_name + lookup_dwo_unit receives the name of the DWO unit to look up, as read + from the DW_AT_dwo_name attribute of the skeleton DIE. But then, it + doesn't use it: + + /* Yeah, we look dwo_name up again, but it simplifies the code. */ + dwo_name = dwarf2_dwo_name (comp_unit_die, cu); + + Perhaps this comment made sense at some point, but with the code we have + today, I don't understand it. It should be fine to use the name passed + as a parameter, which the caller also obtained by calling + dwarf2_dwo_name. + + Change-Id: I84723e12726f77e4202d042428ee0eed9962ceb8 + Approved-By: Tom Tromey + +2025-03-26 WANG Xuerui + + LoongArch: Fix disassembly option parsing stopping at the first option + Turns out the return value of parse_loongarch_dis_option acts as an + error code, and previously the function always signified failure with + a non-zero return value, making only the first disassembly option get + to take effect. + + Fix by adding the missing `return 0`'s to the two success code paths. + +2025-03-26 Roland McGrath + + ld: Support RELRO in aarch64-elf target + Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so + enable `-z relro` and related features. Make aarch64-elf match. + There is no reason to think that a "generic ELF" target should + have any particular set of features disabled. + +2025-03-26 Jerry Zhang Jian + + RISC-V: add Smrnmi 1.0 instruction support + Add instruction `mnret' support + + Ref: + https://github.com/riscv/riscv-isa-manual/blob/bb8b9127f81965eeff2d150c211d1c89376591c4/src/rnmi.adoc + https://github.com/riscv/riscv-opcodes/blob/946eb673874b3a0f2474d1424dc28bc7ee53c306/extensions/rv_smrnmi + + bfd/ChangeLog: + * elfxx-riscv.c: Add new Smrnmi instruction class handling + + gas/ChangeLog: + * testsuite/gas/riscv/smrnmi.s: New test for mnret + * testsuite/gas/riscv/rmrnmi.d: Likewise + + include/ChangeLog: + * opcode/ricsv-opc.h: Add MATCH_MNRET, MASK_MNRET + * opcode/riscv.h: Add new instruction class + + opcodes/ChangeLog: + * riscv-opc.c: Add `mnret' instruction + +2025-03-26 GDB Administrator + + Automatic date update in version.in + +2025-03-25 Simon Marchi + + gdb/dwarf: use std::equal_range in cooked_index_shard::find + Looking at `cooked_index_shard::find`, I thought that we could make a + small optimization: when finding the upper bound, we already know the + lower bound. And we know that the upper bound is >= the lower bound. + So we could pass `lower` as the first argument of the `std::upper_bound` + call to cut the part of the search space that is below `lower`. + + It then occured to me that what we do is basically what + `std::equal_range` is for, so why not use it. Implementations of + `std::equal_range` are likely do to things as efficiently as possible. + + Unfortunately, because `cooked_index_entry::compare` is sensitive to the + order of its parameters, we need to provide two different comparison + functions (just like we do know, to the lower_bound and upper_bound + calls). But I think that the use of equal_range makes it clear what the + intent of the code is. + + Regression tested using the various DWARF target boards on Debian 12. + + Change-Id: Idfad812fb9abae1b942d81ad9976aeed7c2cf762 + Approved-By: Tom Tromey + +2025-03-25 Simon Marchi + + gdb/dwarf: remove unnecessary comparison in cooked_index_entry::compare + I believe that the `(mode == MATCH && a == munge ('<'))` part of the + condition is unnecesary. Or perhaps I don't understand the algorithm. + + The use of "munge" above effectively makes it so that the template + portion of names is completely ignored for the sake of the comparison. + + Then, in the condition, this: + + a == munge ('<') + + is functionally equivalent to + + a == '\0' + + If `a` is indeed '\0', and `b` is also '\0', then we would have taken + the earlier branch: + + if (a == b) + return 0; + + If `b` is not '\0', then we won't take this branch and we'll go into the + final comparison: + + return a < b ? -1 : 1; + + So, as far as I can see, there is no case where `mode == MATCH`, where + we're going to use this special `return 0`. + + Regression tested using the various DWARF target boards on Debian 12. + + Change-Id: I5ea0463c1fdbbc1b003de2f0a423fd0073cc9dec + Approved-By: Tom Tromey + +2025-03-25 Nick Clifton + + Delete the ARM sub-directory of the SIM directory. + +2025-03-25 GDB Administrator + + Automatic date update in version.in + +2025-03-24 Simon Marchi + + gdb/dwarf: move CU check up in cutu_reader::read_cutu_die_from_dwo + We have this pattern of check in multiple places: + + /* Skip dummy compilation units. */ + if (m_info_ptr >= begin_info_ptr + this_cu->length () + || peek_abbrev_code (abfd, m_info_ptr) == 0) + m_dummy_p = true; + + In all places except one (read_cutu_die_from_dwo), this is done after + reading the unit header but before potentially reading the first DIE. + The effect is that we consider dummy units that have no DIE at all. + Either the "data" portion of the unit (the portion after the header) has + a size of zero, or the first abbrev code is 0, i.e. "end of list". + + According to this old commit I found [1], dummy CUs were used as filler + for incremental LTO linking. A comment reads: + + WARNING: If THIS_CU is a "dummy CU" (used as filler by the incremental + linker) then DIE_READER_FUNC will not get called. + + In read_cutu_die_from_dwo, however, this check is done after having read + the first DIE. So at the time of the check, m_info_ptr has already been + advanced just past the first DIE. As a result, compilations units with + a single DIE are considered (erroneously, IMO) as dummy. + + In commit aab6de1613df ("gdb/dwarf: fix spurious error when encountering + dummy CU") [2], I mentioned a real world case where compilation units + with a single top-level DIE were being considered dummy. I believe that + those units should not actually have been treated as dummy. A CU with + just one DIE may not be very interesting, but I don't see any reason to + consider it dummy. + + Move the dummy check above the read_toplevel_die call, and return early + if the CU is dummy. + + I am 99% convinced that it's not even possible to encounter an empty + unit here, and considered turning it into an assert (it did pass the + testsuite). This function is passed a dwo_unit, and functions that + create a dwo_unit are: + + - create_debug_type_hash_table (creates a dwo_unit for each type unit + found in a dwo file) + - create_cus_hash_table (creates a dwo_unit for each comp unit found in + a dwo file) + - create_dwo_unit_in_dwp_v1 + - create_dwo_unit_in_dwp_v2 + - create_dwo_unit_in_dwp_v5 + + In the first two, there are already dummy checks, so we wouldn't even + get to read_cutu_die_from_dwo for such an empty CU. However, in the + last three, there is no such checks, we just trust the dwp file's index + and create dwo_units out of that. So I guess it would be possible to + craft a broken dwp file with a CU that has no DIE. Out of caution, I + didn't switch that to an assert, but I also don't really know what would + be the mode of failure if that were to happen. + + Regtested using the various DWARF target boards on Debian 12. + + [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/dee91e82ae87f379c90fddff8db7c4b54a116609#dd409f60ba6f9c066432dafbda7093ac5eec76d1_3434_3419 + [2] https://gitlab.com/gnutools/binutils-gdb/-/commit/aab6de1613df693059a6a2b505cc8f20d479d109 + + Change-Id: I90e6fa205cb2d23ebebeae6ae7806461596f9ace + Approved-By: Tom Tromey + +2025-03-24 Simon Marchi + + gdb/dwarf: remove cutu_reader::read_cutu_die_from_dwo abbrev table parameter + This parameter is always used to set cutu_reader::m_dwo_abbrev_table. + Remove the parameter, and have read_cutu_die_from_dwo set the field + directly. + + Change-Id: I6c0c7d23591fb2c3d28cdea1befa4e6b379fd0d3 + Approved-By: Tom Tromey + +2025-03-24 Ezra Sitorus + + aarch64: Add missing FEAT_MEC dc encodings and gate sysregs + FEAT_MEC support was introduced in [1]. However, the dc instruction was + missing these encodings: + - DC CIPAE + - DC CIGDPAE + + Furthermore, the Arm ARM states that FEAT_MEC is an optional extension, + introduced for v9.2-a. + Therefore, these sysregs: + - MECIDR_EL2 + - MECID_P0_EL2 + - MECID_A0_EL2 + - MECID_P1_EL2 + - MECID_A1_EL2 + - VMECID_P_EL2 + - VMECID_A_EL2 + - MECID_RL_A_EL3 + + which were introduced in that commit now require -march=armv9.2-a at the very + least to be enabled, as well as the dc encodings. + + opcodes/ChangeLog: + * aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae". + * aarch64-sys-regs.def: Add V8_7A as a requirement for the above system + registers. + + gas/testsuite/gas/ChangeLog + * aarch64/mec-invalid.s: Add .arch directive. + * aarch64/mec.d: Add .arch directive and check for cipae, cigdpae. + * aarch64/mec.s: Add MEC data cache operations test. + * aarch64/mec-arch-bad.d: New test to check for bad arch version. + * aarch64/mec-arch-bad.l: Above. + + [1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3 + + Regression tested on aarch64-none-elf + +2025-03-24 Tom Tromey + + Introduce gdb_bfd_canonicalize_symtab + bfd_canonicalize_symtab stores the symbols in the BFD, and returns + pointers to these. The ELF reader does not reuse these stored + symbols, so each call to bfd_canonicalize_symtab causes an allocation. + + This interacts poorly with code like arm_pikeos_osabi_sniffer, which + searches the BFD symbol when called. + + PR gdb/32758 points out a particularly pathological case: using "maint + info sections" on a program with a large number of sections (10000) + will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G. + + I'm not sure BFD always worked this way. And, fixing BFD was an + option. However it seemed maybe better for GDB to adapt, since + adapting would mean that the fix would apply to all BFD back ends, and + not just ELF. + + To that end, this patch adds a new gdb_bfd_canonicalize_symtab and + changes all callers of bfd_canonicalize_symtab to use it instead. + This new function caches the result in the per-BFD object. + + I looked into having this return a view of "const asymbol *". However + both the compile module and machoread modify the returned symbols. + And while I think this is wrong, I haven't tried to fix this here. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758 + +2025-03-24 Tom Tromey + + Add compile test for color option + Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)") + fixed a compilation error in color_option_def when building with + clang. It seemed to me that it would be good to add a compile test + for this code. + +2025-03-24 GDB Administrator + + Automatic date update in version.in + +2025-03-23 GDB Administrator + + Automatic date update in version.in + +2025-03-22 GDB Administrator + + Automatic date update in version.in + +2025-03-21 Lancelot SIX + + gdb/testsuite: Test the effect of amdgpu-precise memory + The gdb.rocm/precise-memory.exp test currently checks that the "amdgpu + precise-memory" setting can be set. It does not test that this setting + has any meaningful effect. + + This patch extends this test to ensure that precise-memory has the + expected behaviour. + + Change-Id: I58f72a51a566f04fc89114b94ee656c2e7ac35bb + Approved-by: Pedro Alves + +2025-03-21 Lancelot SIX + + gdb/testsuite/lib/rocm: Drop hip_devices_support_precise_memory + Remove hip_devices_support_precise_memory as this is not used anymore. + + Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967 + Approved-by: Pedro Alves + +2025-03-21 Lancelot SIX + + gdb/testsuise: gdb.rocm/precise-memory.exp to not require hip_devices_support_precise_memory + The gdb.rocm/precise-memory.exp test adjusts its behaviour based on the + value returned by hip_devices_support_precise_memory. This function has + static assumption regarding HW capabilities, which might not be + accurate. + + Adjust the test so it does not assume anything about HW capabilities, + but instead just ensure that GDB behaves consistently. + + Change-Id: Ie1f9c6219b88b94f6d461a254b2ad616b92db6b9 + Approved-by: Pedro Alves + +2025-03-21 Tom Tromey + + Introduce die_info::children and use it + This adds a new die_info::children method. This returns a range that + can be used to iterate over a DIE's children. + + Then this goes through and updates all the relevant loops to use + foreach instead. This is a net code reduction. + + You'll note that in some places the code was checking the tag as well, + like: + + while (child_die && child_die->tag) + + I believe this can't happen and is just a copy-paste oddity from the + old days. + + Approved-By: Simon Marchi + +2025-03-21 Tom Tromey + + Rename die_info::sibling to die_info::next + I want to add support for C++ foreach iteration over DIE siblings. + + I considered writing a custom iterator for this, but it would be + largely identical to the already-existing next_iterator. I didn't + want to duplicate the code... + + Then I tried parameterizing next_iterator by having it take an + optional pointer-to-member template argument. However, this would + involve changes in many places, because currently a next_iterator can + be instantiated before the underlying type is complete. + + So in the end I decided to rename die_info::sibling to die_info::next. + This name is slightly worse but (1) IMO it isn't really all that bad, + nobody would have blinked if it was called 'next' in the initial + patch, and (2) with the change to iteration it is barely used. + + Approved-By: Simon Marchi + +2025-03-21 Tom Tromey + + Simplify warning_pre_print + This changes warning_pre_print to not include the text "warning", + which is now unconditional. I think this is a bit clearer, and anyway + it is convenient to support the next patch. + + Reviewed-By: Keith Seitz + +2025-03-21 Tom Tromey + + Do not use warning_pre_print in linux-thread-db.c + linux-thread-db.c may print "warning_pre_print" before displaying an + error message. This seems like a mistake to me, and furthermore I + think it's best to be as sparing as possible with uses of + warning_pre_print, so this patch removes the prefix. + + Reviewed-By: Keith Seitz + +2025-03-21 Andrew Burgess + + gdb: check styled status of source cache entries + Currently GDB's source cache doesn't track whether the entries within + the cache are styled or not. This is pretty much fine, the assumption + is that any time we are fetching source code, we do so in order to + print it to the terminal, so where possible we always want styling + applied, and if styling is not applied, then it is because that file + cannot be styled for some reason. + + Changes to 'set style enabled' cause the source cache to be flushed, + so future calls to fetch source code will regenerate the cache entries + with styling enabled or not as appropriate. + + But this all assumes that styling is either on or off, and that + switching between these two states isn't done very often. + + However, the Python API allows for individual commands to be executed + with styling turned off via gdb.execute(). See commit: + + commit e5348a7ab3f11f4c096ee4ebcdb9eb2663337357 + Date: Thu Feb 13 15:39:31 2025 +0000 + + gdb/python: new styling argument to gdb.execute + + Currently the source cache doesn't handle this case. Consider this: + + (gdb) list main + ... snip, styled source code displayed here ... + (gdb) python gdb.execute("list main", True, False, False) + ... snip, styled source code is still shown here ... + + In the second case, the final `False` passed to gdb.execute() is + asking for unstyled output. + + The problem is that, `get_source_lines` calls `ensure` to prime the + cache for the file in question, then `extract_lines` just pulls the + lines of interest from the cached contents. + + In `ensure`, if there is a cache entry for the desired filename, then + that is considered good enough. There is no consideration about + whether the cache entry is styled or not. + + This commit aims to fix this, after this commit, the `ensure` function + will make sure that the cache entry used by `get_source_lines` is + styled correctly. + + I think there are two approaches I could take: + + 1. Allow multiple cache entries for a single file, a styled, and + non-styled entry. The `ensure` function would then place the + correct cache entry into the last position so that + `get_source_lines` would use the correct entry, or + + 2. Have `ensure` recalculate entries if the required styling mode is + different to the styling mode of the current entry. + + Approach #1 is better if we are rapidly switching between styling + modes, while #2 might be better if we want to keep more files in the + cache and we only rarely switch styling modes. + + In the end I chose approach #2, but the good thing is that the changes + are all contained within the `ensure` function. If in the future we + wanted to change to strategy #1, this could be done transparently to + the rest of GDB. + + So after this commit, the `ensure` function checks if styling is + currently possible or not. If it is not, and the current entry is + styled, then the current entry only is dropped from the cache, and a + new, unstyled entry is created. Likewise, if the current entry is + non-styled, but styling is required, we drop one entry and + recalculate. + + With this change in place, I have updated set_style_enabled (in + cli/cli-style.c) so the source cache is no longer flushed when the + style settings are changed, the source cache will automatically handle + changes to the style settings now. + + This problem was discovered in PR gdb/32676. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676 + + Approved-By: Tom Tromey + +2025-03-21 Jan Beulich + + strip: don't corrupt PE binary's section/file alignment + Section and file alignment are supposed to remain unaltered when PE + binaries are stripped. While this is the case when they're strip-ed + individually, passing multiple such files to strip would reset the + two values to their defaults in all but the first of those binaries. + +2025-03-21 Jan Beulich + + aarch64: simplify RCPC3 unpredictable logic + The original observation was that STILP is warned about when everything + is fine. Documentation, not just for STILP, says explicitly that + behavior is identical to respective pre-existing insns (for STILP in + particular that's STP). With that it's unclear why distinct logic was + added: Other code can be re-used, simply distinguishing by the number of + operands. This was diagnostics also end up more consistent. + + Along with adding some STILP uses to the (positive) testcase, also add a + pair of STLR to similarly demonstrate that the register overlap goes + without warning when there's no write-back. + +2025-03-21 Dongyan Chen + + RISC-V: Ssnpm, smnpm and smmpm imply zicsr. + According to the spec[1], imply zicsr for ssnpm, smnpm and smmpm. + + [1] https://github.com/riscv/riscv-j-extension/blob/master/zjpm/instructions.adoc + + bfd/ChangeLog: + + * elfxx-riscv.c: imply zicsr. + +2025-03-21 GDB Administrator + + Automatic date update in version.in + +2025-03-20 Tom de Vries + + [gdbsupport] Fix typo in common-inferior.h + Fix the following typo: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport/ + gdbsupport/common-inferior.h:57: elemets ==> elements + ... + +2025-03-20 H.J. Lu + + x86-64: Remove the unused pr19636-3d.d + Remove the unused pr19636-3d.d since static Position Dependent Executable + doesn't have a dynamic symbol table. + + PR ld/32807 + * testsuite/ld-x86-64/pr19636-3d.d: Removed. + +2025-03-20 Tom de Vries + + [gdb/testsuite] Fix typos in gdb.threads/infcall-from-bp-cond-simple.exp + Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp. + +2025-03-20 Tom Tromey + + Fix grammar error in dwarf2/attribute.h + A recent patch of mine had a comment with bad grammar; apparently I + didn't finish editing it. This patch cleans it up. + +2025-03-20 Tom de Vries + + [gdb/testsuite] Add missing returns in gdb.threads/infcall-from-bp-cond-simple.c + While investigating PR32785 I noticed a missing return statement in + worker_func, and compiling with -Wreturn-type showed another in + function_that_segfaults: + ... + $ gcc gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c -Wreturn-type + infcall-from-bp-cond-simple.c: In function ‘function_that_segfaults’: + infcall-from-bp-cond-simple.c:46:1: warning: \ + control reaches end of non-void function [-Wreturn-type] + 46 | } + | ^ + infcall-from-bp-cond-simple.c: In function ‘worker_func’: + infcall-from-bp-cond-simple.c:58:1: warning: \ + control reaches end of non-void function [-Wreturn-type] + 58 | } + | ^ + ... + + Fix these by adding the missing returns. + +2025-03-20 Tom de Vries + + [gdb/build] Fix build with gcc 9 + Since commit a691853148f ("gdb/python: introduce gdbpy_registry"), when + building gdb with gcc 9, I run into: + ... + In file included from gdb/varobj.c:38:0: + gdb/python/python-internal.h:1211:47: error: expected ‘;’ before ‘<’ token + using StorageKey = typename registry::key; + ^ + ... + due to this code: + ... + template + class gdbpy_registry + { + ... + + template + using StorageKey = typename registry::key; + + template + Storage *get_storage (O *owner, const StorageKey &key) const + { ... } + + ... + } + ... + + As an experiment, I tried out eliminating the type alias: + ... + template + Storage *get_storage (O *owner, + const typename registry::key &key) const + { ... } + ... + and got instead: + ... + In file included from gdb/varobj.c:38:0: + gdb/python/python-internal.h:1211:63: error: non-template ‘key’ used as template + Storage *get_storage (O *owner, + const typename registry::key &key) const + ^~~ + gdb/python/python-internal.h:1211:63: note: use ‘registry::template key’ \ + to indicate that it is a template + ... + + Following that suggestion, I tried: + ... + template + Storage * + get_storage (O *owner, + const typename registry::template key &key) const + { ... } + ... + which fixed the problem. + + Likewise, adding the template keyword in the type alias fixes the original + problem, so fix it like that. + + Tested on x86_64-linux. + +2025-03-20 GDB Administrator + + Automatic date update in version.in + +2025-03-19 Sam James + + gcore: quote PKGVERSION + Same as 3bed686102cb14552d2ed1b83336453d7ce0dd47. I didn't hit an issue + here -- I think because my /bin/sh is dash and gdb-add-index has a /bin/sh + shebang, while gcore uses bash, but it's still worth fixing (we certainly + do NOT want this to be an array). + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 + +2025-03-19 Sam James + + gdb-add-index: quote PKGVERSION + In Gentoo, we configure our gdb with `--with-pkgversion=` with + "Gentoo VERSION XXXX" where XXX depends on patching (not that we patch + gdb really these days) or vanilla. + + Since 71f193a5c1cb02dcde6ac160cdab88e9725862bb, this goes wrong, yielding + ``` + /usr/bin/gdb-add-index: 25: Syntax error: "(" unexpected + ``` + + with lines 25-26 being: + ``` + PKGVERSION=(Gentoo 9999 vanilla) + VERSION=17.0.50.20250319-git + ``` + + Quote both assignments (PKGVERSION by necessity, VERSION for consistency + or symmetry). + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 + +2025-03-19 Jan Vrany + + gdb/python: convert gdb.Symtab_and_line to use gdbpy_registry + This commit converts gdb.Symtab_and_line to use gdbpy_registry for + lifecycle management. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: convert gdb.Symtab to use gdbpy_registry + This commit converts gdb.Symtab to use gdbpy_registry for lifecycle + management. Since gdb.Symtab only holds on the struct symtab * (and + prev/next links) the default invalidator can be used. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: convert gdb.Type to use gdbpy_registry + This commit converts gdb.Type to use gdbpy_registry for lifecycle + management. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: convert gdb.Symbol to use gdbpy_registry + This commit converts gdb.Symbol to use gdbpy_registry for lifecycle + management. Since gdb.Symbol only holds on the struct symbol * (and + prev/next links) the default invalidator can be used. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: introduce gdbpy_registry + This commit introduces new template class gdbpy_registry to simplify + Python object lifecycle management. As of now, each of the Python + object implementations contain its own (copy of) lifecycle management + code that is largely very similar. The aim of gdbpy_registry is to + factor out this code into a common (template) class in order to simplify + the code. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: do not hold on gdb.Type object from gdb.Value + Previous commit changed type_to_type_object() so each time it is + called with particular struct value* it returns the same object. + + Therefore there's no longer need to hold on type objects (gdb.Type) + from struct value_object in order to preserve identity of gdb.Type + objects held in value_object::type and value_object::dynamic_type + members. This in turn allowed for some simplification in various + functions. + + While at it I changed a couple of NULLs to nullptrs. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: preserve identity for gdb.Type objects + This commit changes type_to_type_object() so that each it is called + with a particular struct type * it returns the very same gdb.Type + object. + + This is done in the same way as for gdb.Symtab objects in earlier commit + ("gdb/python: preserve identity for gdb.Symtab objects") except that + types may be either objfile-owned or arch-owned. + + Prior this commit, arch-owned objects we not put into any list (like + objfile-owned ones) so they could not be easily looked up. This commit + changes the code so arch-owned list are put into per-architecture list + which is then used (solely) for looking up arch-owned gdb.Type. + + Another complication comes from the fact that when objfile is about to + be freed, associated gdb.Type instances are not merely invalidated + (like it is done with gdb.Symtab or gdb.Symbol objects) but instead the + type is copied and the copy is arch-owned. So we need two different + "deleters", one for objfile-owned types that copies the type (as before) + and then insert the object to per-architecture list and another one + for arch-owned types. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_line + Previous commit changed symtab_to_symtab_object() so each time it is + called with particula struct symtab* it returns the same object. + + Therefore there's no longer need to hold on symtab object (gdb.Symtab) + from struct sal_object in order to preserve identity of Symtab object + held in gdb.Symtab_and_line.symtab property. This in turn allowed for + some simplification in various functions. + + While at it I changed a couple of NULLs to nullptrs. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: preserve identity for gdb.Symbol objects + This commit changes symbol_to_symbol_object() so that each it is called + with a particular struct symbol * it returns the very same gdb.Symbol + object. + + This is done in the same way as for gdb.Symtab objects in earlier commit + ("gdb/python: preserve identity for gdb.Symtab objects") except that + symbols may be either objfile-owned or arch-owned. + + Prior this commit, arch-owned objects we not put into any list (like + objfile-owned ones) so they could not be easily looked up. This commit + changes the code so arch-owned list are put into per-architecture list + which is then used (solely) for looking up arch-owned gdb.Symbol. + + Approved-By: Tom Tromey + +2025-03-19 Jan Vrany + + gdb/python: preserve identity for gdb.Symtab objects + This commit changes symtab_to_symtab_object() so that each it is called + with a particular struct symtab * it returns the very same gdb.Symtab + object. + + This is done by searching per-objfile linked list of instances and - if + found - return it rather than creating new gdb.Symtab. + + Approved-By: Tom Tromey + +2025-03-19 Simon Marchi + + gdb: change set_internalvar_function to take a unique pointer + This makes the transfer of ownership a bit clearer, even though the + internal_function is still held with a raw pointer inside internalval. + + Change-Id: Ie8d13270b64737b92291532acfbfcbc992b482b5 + Reviewed-By: Guinevere Larsen + +2025-03-19 Simon Marchi + + gdb: handle INTERNALVAR_FUNCTION in clear_internalvar + While checking the list of leaks reported by ASan, I found that + clear_internalvar doesn't free the internal_function object owned by the + internalvar when the internalvar is of kind INTERNALVAR_FUNCTION, fix + that. + + Change-Id: I78f53b83b97bae39370a7b5ba5e1cec70626d66a + Reviewed-By: Guinevere Larsen + +2025-03-19 Simon Marchi + + gdb: clear internalvar on destruction + The data associated to an internalvar is destroyed when changing the + kind of the internalvar, but not when it is destroyed. Fix that by + calling clear_internalvar in ~internalvar. + + A move constructor becomes needed to avoid freeing things multiple times + when internalvars are moved (and if we forget it, clang helpfully gives + us a -Wdeprecated-copy-with-user-provided-dtor warning). + + Change-Id: I427718569208fd955ea25e94d341dde356725033 + Reviewed-By: Guinevere Larsen + +2025-03-19 Simon Marchi + + gdb: C++-ify internal_function + Change the `name` field to std::string, add constructor. Remove + function `create_internal_function`, since it becomes a trivial wrapper + around the constructor. + + Change-Id: Ifc8b1282c442e1930bcd69d6e140128067e49563 + Reviewed-By: Guinevere Larsen + +2025-03-19 Andrew Burgess + + gdb/python: new styling argument to gdb.execute + Currently, gdb.execute emits styled output when the command is sending + its output to GDB's stdout, and produces unstyled output when the + output is going to a string. + + But it is not unreasonable that a user might wish to capture styled + output from a gdb.execute call, for example, the user might want to + display the styled output are part of some larger UI output block. + + At the same time, I don't think it makes sense to always produce + styled output when capturing the output in a string; if what the user + wants is to parse the output, then the style escape sequences make + this far harder. + + I propose that gdb.execute gain a new argument 'styling'. When False + we would always produce unstyled output, and when True we would + produce styled output if styling is not disabled by some other means. + + For example, if GDB's 'set style enabled' is off, then I think + gdb.execute() should respect that. My assumption here is that + gdb.execute() might be executed by some extension. If the extension + thinks "styled output world work here", but the user hates styled + output, and has turned it off, then the extension should not be + forcing styled output on the user. + + I chose 'styling' instead of 'styled' as the Python argument name + because we already use 'styling' in gdb.Value.format_string, and we + don't use 'styled' anywhere else. This is only a little bit of + consistency, but I still think it's a good thing. + + The default for 'styling' will change depending on where the output is + going. When gdb.execute is sending the output to GDB's stdout then + the default for 'styling' is True. When the output is going to a + string, then the default for 'styling' will be False. Not only does + this match the existing behaviour, but I think this makes sense. By + default we assume that output captured in a string is going to be + parsed, and therefore styling markup is unhelpful, while output going + to stdout should receive styling. + + This fixes part of the problem described in PR gdb/32676. That bug + tries to capture styled source listing in a string, which wasn't + previously possible. + + There are some additional issues with capturing source code; GDB + caches the source code in the source code cache. However, GDB doesn't + check if the cached content is styled or not. As a consequence, if + the first time the source of a file is shown it is unstyled, then the + cached will hold the unstyled source code, and future requests will + return that unstyled source. I'll address this issue in a separate + patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676 + + Approved-By: Tom Tromey + +2025-03-19 Andrew Burgess + + gdb: show full shared library memory range in 'info sharedlibrary' + On GNU/Linux (and other targets that use solib-svr4.c) the 'info + sharedlibrary' command displays the address range for the .text + section of each library. This is a fallback behaviour implemented in + solib_map_sections (in solib.c), for targets which are not able to + provide any better information. + + The manual doesn't really explain what the address range given means, + and the .text fallback certainly isn't described. The manual for + 'info sharedlibrary' just says: + + 'info share REGEX' + 'info sharedlibrary REGEX' + Print the names of the shared libraries which are currently loaded + that match REGEX. If REGEX is omitted then print all shared + libraries that are loaded. + + In this commit I propose that we should change GDB so that the full + library address range is listed for GNU/Linux (and other solib-svr4 + targets). Though it is certainly useful to know where the .text for a + library is, not all code is placed into the .text section, and data, + or course, is stored elsewhere, so the choice of .text, though not a + crazy default, is still a pretty arbitrary choice. + + We do also have 'maintenance info sections', which can be used to find + the location of a specific section. This is of course, a maintenance + command, but we could make this into a real user command if we wanted, + so the information lost by this change to 'info sharedlibrary' is + still available if needed. + + There is one small problem. After this commit, GDB is still under + reporting the extents of some libraries, in some cases. + + What I observe is that sometimes, for reasons that I don't currently + understand, the run-time linker will over allocate memory for the .bss + like sections, e.g. the ELF says that 1 page is required, but 2 or 4 + pages will be allocated instead. As a result, GDB will under report + the extent of the library, with the end address being lower than + expected. This isn't always the case though, in many cases the + allocates are as I would expect, and GDB reports the correct values. + + However, as we have been under reporting for many years, I think this + update, which gets things a lot closer to reality, is a big step in + the right direction. We can always improve the results more later + on if/when the logic behind the over allocations become clearer. + + For testing I've compared the output of 'info proc mappings' with the + output of 'info sharedlibrary' (using a script), using GDB to debug + itself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64, + and other than the over allocation problem described above, the + results all look good to me. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2025-03-19 Wataru Ashihara + + gdbserver: fix build on NetBSD + The function remove_thread() was changed to a method in 2500e7d7d (gdbserver: + make remove_thread a method of process_info). + + Change-Id: I4b2d8a6f84b5329b8d450b268fa9453fe424914e + +2025-03-19 GDB Administrator + + Automatic date update in version.in + +2025-03-18 Simon Marchi + + gdb/dwarf: use gdb::unordered_set for cooked_index_storage::m_reader_hash + Replace an htab with gdb::unordered_set. I think we could also use the + dwarf2_per_cu pointer itself as the identity, basically have the + functional equivalent of: + + gdb::unordered_map + + But I kept the existing behavior of using dwarf2_per_cu::index as the + identity. + + Change-Id: Ief3df9a71ac26ca7c07a7b79ca0c26c9d031c11d + Approved-By: Tom Tromey + +2025-03-18 Simon Marchi + + gdb/dwarf: remove type_unit_group + The type_unit_group is an indirection between a stmt_list_hash (possible + dwo_unit + line table section offset) and a type_unit_group_unshareable + that provides no real value. In dwarf2_per_objfile, we maintain a + stmt_list_hash -> type_unit_group mapping, and in dwarf2_per_objfile, we + maintain a type_unit_group_unshareable mapping. The type_unit_group + type is empty and only exists to have an identity and to be a link + between the two mappings. + + This patch changes it so that we have a single stmt_list_hash -> + type_unit_group_unshareable mapping. + + Regression tested on Debian 12 amd64 with a bunch of DWARF target + boards. + + Change-Id: I9c5778ecb18963f353e9dd058e0f8152f7d8930c + Approved-By: Tom Tromey + +2025-03-18 Simon Marchi + + gdb/dwarf: use gdb::unordered_map for dwarf2_per_bfd::{quick_file_names_table,type_unit_groups} + Change these two hash tables to use gdb::unordered_map. I changed these + two at the same time because they both use the same key, a + stmt_list_hash. Unlike other previous patches that used a + gdb::unordered_set, use an unordered_map here because the key isn't + found in the element itself (well, it was before, because of how htab + works, but it didn't need to be). + + You'll notice that the type_unit_group structure is empty. That + structure isn't really needed. It is removed in the following patch. + + Regression tested on Debian 12 amd64 with a bunch of DWARF target + boards. + + Change-Id: Iec2289958d0f755cab8198f5b72ecab48358ba11 + Approved-By: Tom Tromey + +2025-03-18 Tom Tromey + + Remove is_nonnegative and as_nonnegative + This removes attribute::is_nonnegative and attribute::as_nonnegative + in favor of a call to unsigned_constant. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Handle DW_END_default + I noticed that gdb doesn't handle DW_END_default. This patch adds + support for this. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Assume DW_AT_alignment is unsigned + This changes get_alignment to assume that DW_AT_alignment refers to an + unsigned value. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Assume DW_AT_decl_line is unsigned + This changes read_decl_line and new_symbol to assume that + DW_AT_decl_line should refer to an unsigned value. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use form name in complaint in dwarf2_record_block_entry_pc + This changes dwarf2_record_block_entry_pc to issue a complaint using + the form name rather than a value. This seems more correct to me. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Introduce and use attribute::unsigned_constant + This introduces a new 'unsigned_constant' method on attribute. This + method can be used to get the value as an unsigned number. Unsigned + scalar forms are handled, and signed scalar forms are handled as well + provided that the value is non-negative. + + Several spots in the reader that expect small DWARF-defined constants + are updated to use this new method. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Rename form_is_signed to form_is_strictly_signed + This renames attribute::form_is_signed to form_is_strictly_signed. I + think this more accurately captures what it does: it says whether a + form will always use signed data -- not whether a form might use + signed data, which DW_FORM_data* do depending on context. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 + Approved-By: Simon Marchi + +2025-03-18 Tom de Vries + + [gdb/testsuite] Fix gdb.base/enum_cond.exp on arm-linux + On arm-linux, I run into: + ... + gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \ + the output is to use 32-bit enums; use of enum values across objects may fail + UNTESTED: gdb.base/enum_cond.exp: failed to compile + ... + + Fix this by using -nostdlib. + + Tested on arm-linux and x86_64-linux. + + Approved-By: Simon Marchi + +2025-03-18 Simon Marchi + + gdb/dwarf: set m_top_level_die directly in read_cutu_die_from_dwo + read_cutu_die_from_dwo currently returns the dwo's top-level DIE through + a parameter. Following the previous patch, all code paths end up + setting m_top_level_die. Simplify this by having read_cutu_die_from_dwo + set m_top_level_die directly. I think it's easier to understand, + because there's one less indirection to follow. + + Change-Id: Ib659f1d2e38501a8fe2b5dd0ca2add3ef55e8d60 + Approved-By: Tom Tromey + +2025-03-18 Simon Marchi + + gdb/dwarf: fix spurious error when encountering dummy CU + I built an application with -gsplit-dwarf (i.e. dwo), and some CUs are + considered "dummy" by the DWARF reader. That is, the top-level DIE + (DW_TAG_compile_unit) does not have any children. Here's the skeleton: + + 0x0000c0cb: Compile Unit: length = 0x0000001d, format = DWARF32, version = 0x0005, unit_type = DW_UT_skeleton, abbr_offset = 0x529b, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000c0ec) + + 0x0000c0df: DW_TAG_skeleton_unit + DW_AT_stmt_list [DW_FORM_sec_offset] (0x09dee00f) + DW_AT_dwo_name [DW_FORM_strp] ("CMakeFiles/lib_crl.dir/crl/dispatch/crl_dispatch_queue.cpp.dwo") + DW_AT_comp_dir [DW_FORM_strp] ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl") + DW_AT_GNU_pubnames [DW_FORM_flag_present] (true) + + And here's the entire debug info in the .dwo file: + + .debug_info.dwo contents: + 0x00000000: Compile Unit: length = 0x0000001a, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000001e) + + 0x00000014: DW_TAG_compile_unit + DW_AT_producer [DW_FORM_strx] ("GNU C++20 14.2.1 20250207 -mno-direct-extern-access -mtune=generic -march=x86-64 -gsplit-dwarf -g3 -gz=none -O2 -std=gnu++20 -fPIC -fno-strict-aliasing") + DW_AT_language [DW_FORM_data1] (DW_LANG_C_plus_plus_14) + DW_AT_name [DW_FORM_strx] ("/home/simark/src/tdesktop/Telegram/lib_crl/crl/dispatch/crl_dispatch_queue.cpp") + DW_AT_comp_dir [DW_FORM_strx] ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl") + + When loading the binary in GDB, I see some warnings: + + $ ./gdb -q -nx --data-directory=data-directory -ex 'maint set dwarf sync on' -ex "file /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop" + Reading symbols from /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop... + DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc0cb + DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc152 + DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc194 + DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc1b5 + (gdb) + + It turns out that these errors are not really justified. What happens + is: + + - cutu_reader::read_cutu_die_from_dwo return 0, indicating that the CU + is "dummy" + - back in cutu_reader::cutu_reader, we omit setting m_top_level_die to + the DIE from the dwo file, meaning that m_top_level_die keeps + pointing to the DIE from the main file (DW_TAG_skeleton_unit) + - later, in cutu_reader::prepare_one_comp_unit, there is a check that + m_top_level_die->tag is one of DW_TAG_{compile,partial,type}_unit, + which triggers + + My proposal to fix this is to set m_top_level_die even if the CU is + dummy. Even if the top-level DIE does not have any children, I don't + see any reason to leave cutu_reader::m_top_level_die in a different + state than when the CU is not dummy. + + While at it, set m_dummy_p directly in read_cutu_die_from_dwo, instead + of returning a value and having the caller do it. This is all inside + cutu_reader anyway. + + Change-Id: I483a68a369bb461a8dfa5bf2106ab1d6a0067198 + Approved-By: Tom Tromey + +2025-03-18 Simon Marchi + + gdb/dwarf: remove create_dwo_cu_reader + This function, as can be seen by its comment, is a remnant of past + design. Inline its content into create_cus_hash_table. + + Change-Id: Id900bae2cdce8f33bf01199fb1d366646effc76e + Approved-By: Tom Tromey + +2025-03-18 Andrew Burgess + + gdb: split up construct_inferior_arguments + The function construct_inferior_arguments (gdbsupport/common-inferior.cc) + currently escapes all special shell characters. After this commit + there will be two "levels" of quoting: + + 1. The current "full" quoting, where all posix shell special + characters are quoted, and + + 2. a new "reduced" quoting, where only the characters that GDB sees + as special (quotes and whitespace) are quoted. + + After this, almost all construct_inferior_arguments calls will use the + "full" quoting, which is the current quoting. The "reduced" quoting + will be used in this commit to restore the behaviour that was lost in + the previous commit (more details below). + + In the future, the reduced quoting will be useful for some additional + inferior argument that I have planned. I already posted my full + inferior argument work here: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + But that series is pretty long, and wasn't getting reviewed, so I'm + posted the series in parts now. + + Before the previous commit, GDB behaved like this: + + $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' + (gdb) show args + Argument list to give program being debugged when it is started is "$FOO". + + Notice that with 'startup-with-shell' off, the argument was left as + just '$FOO'. But after the previous commit, this changed to: + + $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' + (gdb) show args + Argument list to give program being debugged when it is started is "\$FOO". + + Now the '$' is escaped with a backslash. This commit restores the + original behaviour, as this is (currently) the only way to unquoted + shell special characters into arguments from the GDB command line. + The series that I listed above includes a new command line option for + GDB which provides a better approach for controlling the quoting of + special shell characters, but that work requires these patches to be + merged first. + + I've split out the core of construct_inferior_arguments into the new + function escape_characters, which takes a set of characters to escape. + Then the two functions escape_shell_characters and + escape_gdb_characters call escape_characters with the appropriate + character sets. + + Finally, construct_inferior_arguments, now takes a boolean which + indicates if we should perform full shell escaping, or just perform + the reduced escaping. + + I've updated all uses of construct_inferior_arguments to pass a + suitable value to indicate what escaping to perform (mostly just + 'true', but one case in main.c is different), also I've updated + inferior::set_args to take the same boolean flag, and pass it through + to construct_inferior_arguments. + + Tested-By: Guinevere Larsen + +2025-03-18 Andrew Burgess + + gdb: remove the !startup_with_shell path from construct_inferior_arguments + In the commit: + + commit 0df62bf09ecf242e3a932255d24ee54407b3c593 + Date: Fri Oct 22 07:19:33 2021 +0000 + + gdb: Support some escaping of args with startup-with-shell being off + + nat/fork-inferior.c was updated such that when we are starting an + inferior without a shell we now remove escape characters. The + benefits of this are explained in that commit, but having made this + change we can now make an additional change. + + Currently, in construct_inferior_arguments, when startup_with_shell is + false we construct the inferior argument string differently than when + startup_with_shell is true; when true we apply some escaping to + special shell character, when false we don't. + + This commit simplifies construct_inferior_arguments by removing the + !startup_with_shell case, and instead we now apply escaping in all + cases. This is fine because, thanks to the above commit the escaping + will be correctly removed again when we call into nat/fork-inferior.c. + + We should think of construct_inferior_arguments and + nat/fork-inferior.c as needing to cooperate in order for argument + handling to work correctly. + + construct_inferior_arguments converts a list of separate arguments + into a single string, and nat/fork-inferior.c splits that single + string back into a list of arguments. It is critical that, if + nat/fork-inferior.c is expecting to remove a "layer" of escapes, then + construct_inferior_arguments must add that expected "layer", + otherwise, we end up stripping more escapes than expected. + + The great thing (I think) about the new configuration, is that GDB no + longer cares about startup_with_shell at the point the arguments are + being setup. We only care about startup_with_shell at the point that + the inferior is started. This means that a user can set the inferior + arguments, and then change the startup-with-shell setting, and GDB + will do what they expect. + + Under the previous system, where construct_inferior_arguments changed + its behaviour based on startup_with_shell, the user had to change the + setting, and then set the arguments, otherwise, GDB might not do what + they expect. + + There is one slight issue with this commit though, which will be + addressed by the next commit. + + For GDB's native targets construct_inferior_arguments is reached via + two code paths; first when GDB starts and we combine arguments from + the command line, and second when the Python API is used to set the + arguments from a sequence. It's the command line argument handling + which we are interested in. + + Consider this: + + $ gdb --args /tmp/exec '$FOO' + (gdb) show args + Argument list to give program being debugged when it is started is "\$FOO". + + Notice that the argument has become \$FOO, the '$' is now quoted. + + This is because, by quoting the argument in the shell command that + started GDB, GDB was passed a literal $FOO with no quotes. In order + to ensure that the inferior sees this same value, GDB added the extra + escape character. When GDB starts with a shell we pass \$FOO, which + results in the inferior seeing a literal $FOO. + + But what if the user _actually_ wanted to have the shell GDB uses to + start the inferior expand $FOO? Well, it appears this can't be done + from the command line, but from the GDB prompt we can just do: + + (gdb) set args $FOO + (gdb) show args + Argument list to give program being debugged when it is started is "$FOO". + + And now the inferior will see the shell expanded version of $FOO. + + It might seem like we cannot achieve the same result from the GDB + command line, however, it is possible with this trick: + + $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' + (gdb) show args + Argument list to give program being debugged when it is started is "$FOO". + (gdb) show startup-with-shell + Use of shell to start subprocesses is off. + + And now the $FOO is not escaped, but GDB is no longer using a shell to + start the inferior, however, we can extend our command line like this: + + $ gdb -eiex 'set startup-with-shell off' \ + -ex 'set startup-with-shell on' \ + --args /tmp/exec '$FOO' + (gdb) show args + Argument list to give program being debugged when it is started is "$FOO". + (gdb) show startup-with-shell + Use of shell to start subprocesses is on. + + Use an early-initialisation option to disable startup-with-shell, this + is done before command line argument processing, then a normal + initialisation option turns startup-with-shell back on after GDB has + processed the command line arguments! + + Is this useful? Yes, absolutely. Is this a good user experience? + Absolutely not. And I plan to add a new command line option to + GDB (and gdbserver) that will allow users to achieve the same + result (this trick doesn't work in gdbserver as there's no + early-initialisation there) without having to toggle the + startup-with-shell option. The new option can be found in the series + here: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + The problem is that, that series is pretty long, and getting it + reviewed is just not possible. So instead I'm posting the individual + patches in smaller blocks, to make reviews easier. + + So, what's the problem? Well, by removing the !startup_with_shell + code path from GDB, there is no longer a construct_inferior_arguments + code path that doesn't quote inferior arguments, and so there's no + longer a way, from the command line, to set an unquoted '$FOO' as an + inferior argument. Obviously, this can still be done from GDB's CLI + prompt. + + The trick above is completely untested, so this regression isn't going + to show up in the testsuite. + + And the breakage is only temporary. In the next commit I'll add a fix + which restores the above trick. + + Of course, I hope that this fix will itself, only be temporary. Once + the new command line options that I mentioned above are added, then + the fix I add in the next commit can be removed, and user should start + using the new command line option. + + After this commit a whole set of tests that were added as xfail in the + above commit are now passing. + + A change similar to this one can be found in this series: + + https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ + + which I reviewed before writing this patch. I don't think there's any + one patch in that series that exactly corresponds with this patch + though, so I've listed the author of the original series as co-author + on this patch. + + Co-Authored-By: Michael Weghorn + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + +2025-03-18 Tom Tromey + + Preserve a local variable in a gdb test + I found another Ada test where LLVM optimizes away an unused local + variable. This patch fixes this problem -- but note the test now + fails for a different (currently expected) reason. + +2025-03-18 Nick Clifton + + Updated translations for BFD and BINUTILS sub-directories + +2025-03-18 Tom Tromey + + Use gdb unordered map in regcache.c + This changes a couple spots in regcache.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in tui-io.c + This changes tui.c to use gdb::unordered_map. ui_file_style::color is + changed a little as well; operator< is no longer needed, but a simple + hash function is added. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set and map in cp-namespace.c + This changes cp-namespace.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in xml-tdesc.c + This changes xml-tdesc.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set and map in unit tests + This changes some unit test code to use gdb:unordered_set and + gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in target.c + This changes corelow.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in ravenscar.c + This changes ravenscar.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set and map in Python layer + This changes a couple of files in the Python layer to use + gdb:unordered_set and gdb::unordered_map. Another use exists but I + think it is being handled by Jan's series. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set in linux-procfs.c + This changes linux-procfs.c to use gdb:unordered_set. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in linux-nat.c + This changes one spot in linux-nat.c to use gdb::unordered_map. + (There are still other spots that could be converted.) + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map for complaints + This changes the complaints code to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in stap-probe.c + This changes stap-probe.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in inferior.h + This changes inferior.h to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in ada-exp.y + This changes ada-exp.y to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set in symtab.c + This changes symtab.c to use gdb:unordered_set. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in gdb_bfd.c + This changes gdb_bfd.c to use gdb:unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered map in dictionary.c + This changes dictionary.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set in breakpoint.c + This changes breakpoint.c to use gdb:unordered_set. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use gdb unordered set and map in corelow.c + This changes corelow.c to use gdb:unordered_set and + gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-18 Tom Tromey + + Use scoped_fd in linux-nat.c:proc_mem_file + This changes linux-nat.c:proc_mem_file to use a scoped_fd and fixes up + the users. Regression tested on x86-64 Fedora 40. + + Approved-by: Kevin Buettner + +2025-03-18 Tom de Vries + + [gdb/tdep] Use SYSCALL_MAP_RENAME for aarch64 and loongarch + There are currently two functions using macros SYSCALL_MAP and + UNSUPPORTED_SYSCALL_MAP: aarch64_canonicalize_syscall, and + loongarch_canonicalize_syscall. + + Here [1] I propose to do the same in i386_canonicalize_syscall, using one + additional macro: SYSCALL_MAP_RENAME. + + Add the same macro in aarch64_canonicalize_syscall and + loongarch_canonicalize_syscall, and use it to map aarch64_sys_mmap and + loongarch_sys_mmap to gdb_sys_mmap2. + + While we're at it: + - reformat the macro definitions to be more readable, + - add missing macro undefs in aarch64_canonicalize_syscall, and + - fix indentation in aarch64_canonicalize_syscall. + + No functional changes. + + Tested by rebuilding on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + [1] https://sourceware.org/pipermail/gdb-patches/2025-March/216230.html + +2025-03-18 Jerry Zhang Jian + + RISC-V: Support pointer masking extension 1.0 + - Adding Ssnpm, Smnpm, Smmpm, Sspm, and Supm + - No new CSR added + - Pointer masking only applies to RV64 + - Ref: https://github.com/riscv/riscv-j-extension/releases/download/pointer-masking-ratified/pointer-masking-ratified.pdf + +2025-03-18 Nelson Chu + + gas/NEW: Updated news related to mapping symbol and extensions for risc-v + +2025-03-18 Jin Ma + + RISC-V: Add extension XTheadVdot for T-Head VECTOR vendor extension [1] + T-Head has a range of vendor-specific instructions. Therefore + it makes sense to group them into smaller chunks in form of + vendor extensions. + + This patch adds the additional extension "XTheadVdot" based on the + "V" extension, and it provides four 8-bit multiply and add with + 32-bit instructions for the "v" extension. The 'th' prefix and the + "XTheadVector" extension are documented in a PR for the + RISC-V toolchain conventions ([2]). + + Co-Authored-By: Lifang Xia + + [1] https://github.com/XUANTIE-RV/thead-extension-spec/tree/master/xtheadvdot + [2] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add support + for "XTheadVdot" extension. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + + * doc/c-riscv.texi: Likewise. + * testsuite/gas/riscv/march-help.l: Likewise. + * testsuite/gas/riscv/x-thead-vdot.d: New test. + * testsuite/gas/riscv/x-thead-vdot.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_TH_VMAQA_VV): New. + * opcode/riscv.h (enum riscv_insn_class): Add insn class for + XTheadVdot. + + opcodes/ChangeLog: + + * riscv-opc.c: Likewise. + +2025-03-18 Nelson Chu + + RISC-V: Avoid parsing arch string repeatedly for dis-assembler + Since we now always generate $x+isa for now, these would increase the + dis-assemble time by parsing the same architecture string repeatedly. We + already have `arch_str' field into `subset_list' to record the current + architecture stirng, but it's only useful for assembler, since dis-assembler + and linker don't need it before. Now for dis-assembler, we just need to + update the `arch_str' after parsing the architecture stirng, and then avoid + parsing repeatedly if the strings are the same. + + RISC-V: Free the returned string of riscv_arch_str if we call it multiple times + The string returned from riscv_arch_str is allocated by xmalloc, so once we + called it multiple times, we should keep the newest one for the output elf + architecture attribute, but free the remaining unused strings. + + RISC-V: Fixed riscv_update_subset1 returning wrong boolean value + The riscv_update_subset1 returning wrong boolean value if the + riscv_parse_check_conflicts isn't called, though the current return value + doesn't really useful. + +2025-03-18 GDB Administrator + + Automatic date update in version.in + +2025-03-17 Simon Marchi + + gdb/dwarf: remove unused cooked_index::cooked_index parameter + Following the previous patch, this parameter is now unused. Remove it. + + Change-Id: I7e96a3ba61ad9a0d6b64f9129aeeb9a8f3da22a7 + Approved-By: Tom Tromey + +2025-03-17 Simon Marchi + + gdbsupport: add some -Wunused-* warning flags + Add a few -Wunused-* diagnostic flags that look useful. Some are known + to gcc, some to clang, some to both. Fix the fallouts. + + -Wunused-const-variable=1 is understood by gcc, but not clang. + -Wunused-const-variable would be undertsood by both, but for gcc at + least it would flag the unused const variables in headers. This doesn't + make sense to me, because as soon as one source file includes a header + but doesn't use a const variable defined in that header, it's an error. + With `=1`, gcc only warns about unused const variable in the main source + file. It's not a big deal that clang doesn't understand it though: any + instance of that problem will be flagged by any gcc build. + + Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156 + Approved-By: Tom Tromey + +2025-03-17 Simon Marchi + + gdbsupport: re-format and sort warning flags + Put them one per line and sort alphabetically. + + Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59 + Approved-By: Tom Tromey + +2025-03-17 Andrew Burgess + + gdb-add-index: add --help and --version options + Update the gdb-add-index script to offer --help and --version options. + + The script currently accepts the argument '-dwarf-5' with a single + leading '-'. As two '--' is more common for long options, the + preferred argument form is now '--dwarf-5', the docs have been + updated, and the new help text uses this form. + + For backward compatibility, the old '-dwarf-5' form is still + accepted. + + The new arguments are '--help' or '-h', but I also accept '-help' for + consistency with '-dwarf-5'. And likewise for the version argument. + + Handling of the gdb-add-index script is done basically the same as for + gcore and gstack; we use config.status to create a .in file within the + build directory, which is then processed by the Makefile to create the + final script. + + The difference with gdb-add-index is that I left the original script + as gdb/contrib/gdb-add-index.sh rather than renaming it to something + like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are + handled (though they are not in the contrib directory). + + The reason for this is that the contrib/cc-with-tweaks.sh script looks + for gdb-add-index.sh within the gdb/contrib/ source directory. + + As the only reason we process gdb-add-index.sh into the build + directory is to support the PKGVERSION and VERSION variables, allowing + cc-with-tweaks to continue using the unprocessed version seems + harmless, and avoids having to change cc-with-tweaks.sh at all. + + I tested that I can still run tests using the cc-with-gdb-index target + board, and that the installed gdb-add-index script correctly shows a + version number when asked. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-03-17 Andrew Burgess + + gdb: make cli_styling static within cli/cli-style.c + The cli_styling variable is controlled by 'set style enabled on|off' + user setting, and is currently globally visible. + + In a couple of places we access this variable directly, though in + ui-file.c the accesses are all performed through term_cli_styling(), + which is a function that wraps checking cli_styling along with a check + that GDB's terminal supports styling. + + In a future commit, I'd plan to add a new parameter to gdb.execute() + which will allow styling to be temporarily suppressed. In an earlier + proposal, I made gdb.execute() disable styling by changing the value + of cli_styling, however, this approach has a problem. + + If gdb.execute() is used to run 'show style enabled', the changing + cli_styling will change what is printed. Similarly, if gdb.execute() + is used to execute 'set style enabled on|off' then having + gdb.execute() save and restore the value of cli_styling will undo the + adjustment from 'set style enabled ...'. + + So what I plan to do in the future, is add a new control flag which + can be used to temporarily disable styling. + + To make this new control variable easier to add, lets force everyone + to call term_cli_styling() to check if styling is enabled or not. To + force everyone to use term_cli_styling() this commit makes cli_styling + static within gdb/cli/cli-style.c. + + Approved-By: Tom Tromey + +2025-03-17 Andrew Burgess + + gdb: fix typo in NEWS file + The following commit introduced a typo to the NEW file: + + commit d21f28a067e94e0ab6548d97f650c14be76bfbde + Date: Sat Mar 15 12:03:50 2025 +0000 + + gdb/python: remove unused argument from builtin_disassemble + + this commit fixes it. + + I've also reworded the NEWS entry a little. Simon pointed out in + review that the unused argument was also documented in Python's help() + output, which I hadn't mentioned in the NEWS entry. I've updated the + NEWS entry to just highlight that the now removed argument was never + mentioned in the manual, I think that's all that really matters. + +2025-03-17 Simon Marchi + + gdb/dwarf: use gdb::unordered_set for seen_names + Direct replacement of an htab with a gdb::unordered_set. + + Using a large test program, I see a small but consistent performance + improvement. The "file" command time goes on average from 7.88 to 7.73 + seconds (~2%). To give a rough estimate of the scale of the test + program, the 8 seen_names hash tables (one for each worker thread) had + between 173846 and 866961 entries. + + Change-Id: I0157cbd04bb55338bb1fcefd2690aeef52fe3afe + Approved-By: Tom Tromey + +2025-03-17 Lucy Kingsbury + + Fix Guile pretty printer display hints + All 3 valid Guile pretty printer display hints are treated as the + value "string". As a result, if a printer specifies "array" or + "map", the output is instead formatted as a string. + + This humble patch corrects the issue. + +2025-03-17 Clément Chigot + + ld/testsuite: add gnu property section in nto-stack-note* + A GNU property section is now always generated when `-z stack-size` is + passed. This was probably introduced by GNU Property refactoring + within elfxx-aarch64.c. + +2025-03-17 GDB Administrator + + Automatic date update in version.in + +2025-03-16 GDB Administrator + + Automatic date update in version.in + +2025-03-15 Andrew Burgess + + gdb/python: remove unused argument from builtin_disassemble + This commit: + + commit 15e15b2d9cd3b1db68f99cd3b047352142ddfd1c + Date: Fri Sep 17 18:12:34 2021 +0100 + + gdb/python: implement the print_insn extension language hook + + added the gdb.disassembler.builtin_disassemble Python API function. + By mistake, the implementation accepted two arguments, the second + being a "memory_source". + + However, this second argument was never used, it was left over from an + earlier proposed version of the API. + + Luckily, the only place the unused argument was documented was in the + NEWS file and in the output of `help(gdb.builtin_disassemble)`, and + neither of these locations really describe what the argument was, or + how it would be used. The manual only describes the first (actually + used) argument, so I think we are safe enough to delete the unused + argument. + + This allows some additional cleanup, with the store for the argument + also being deleted. + + As the NEWS file did originally document the second argument, I have + added a NEWS entry to explain the argument has now been removed. + + This could potentially break users code if they somehow decided to + pass a second argument, however, fixing things is as simple as + removing the second (unused) argument. + + Approved-By: Simon Marchi + +2025-03-15 Andrew Burgess + + gdb/python: handle non-utf-8 character from gdb.execute() + I noticed that it was not possible to return a string containing non + utf-8 characters using gdb.execute(). For example, using the binary + from the gdb.python/py-source-styling.exp test: + + (gdb) file ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling + Reading symbols from ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling... + (gdb) set style enabled off + (gdb) list 26 + 21 int some_variable = 1234; + 22 + 23 /* The following line contains a character that is non-utf-8. This is a + 24 critical part of the test as Python 3 can't convert this into a string + 25 using its default mechanism. */ + 26 char c[] = "�"; /* List this line. */ + 27 + 28 return 0; + 29 } + (gdb) python print(gdb.execute('list 26', to_string=True)) + Python Exception : 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte + Error occurred in Python: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte + + It is necessary to disable styling before the initial 'list 26', + otherwise the source will be passed through GNU source highlight, and + GNU source highlight seems to be smart enough to figure out the + character encoding, and convert it to UTF-8. This conversion is then + cached in the source cache, and the later Python gdb.execute call will + get back a pure UTF-8 string. + + If source styling is disabled, then GDB caches the string without the + conversion to UTF-8, now the gdb.execute call gets back the string + with a non-UTF-8 character within it, and Python throws an error + during its attempt to create a string object. + + I'm not, at this point, proposing a solution that tries to guess the + source file encoding, though I guess such a thing could be done. + Instead, I think we should make use of the host_charset(), as set by + the user with 'set host-charset ....' during the creation of the + Python string. + + To do this, in execute_gdb_command, we should switch from + PyUnicode_FromString, which requires the input be a UTF-8 string, to + using PyUnicode_Decode, which allows GDB to specify the string + encoding. We will use host_charset(). + + With this done, it is now possible to list the file contents using + gdb.execute(), with the contents passing through a string: + + (gdb) set host-charset ISO-8859-1 + (gdb) python print(gdb.execute('list 26', to_string=True), end='') + 21 int some_variable = 1234; + 22 + 23 /* The following line contains a character that is non-utf-8. This is a + 24 critical part of the test as Python 3 can't convert this into a string + 25 using its default mechanism. */ + 26 char c[] = "À"; /* List this line. */ + 27 + 28 return 0; + 29 } + (gdb) + + There are already plenty of other places in GDB's Python code where we + use PyUnicode_Decode to create a string from something that might + contain user generated content, so I believe this is the correct + approach. + +2025-03-15 GDB Administrator + + Automatic date update in version.in + +2025-03-14 H.J. Lu + + elf: Clear the SEC_ALLOC bit for NOLOAD note sections + When generating an ELF output file, if a note section is marked as + NOLOAD, clear the SEC_ALLOC bit so that it won't be treated as an + SHF_ALLOC section, like a .bss style section. + + PR ld/32787 + * ld.texi: Update NOLOAD for ELF output files. + * ldlang.c (lang_add_section): Clear the SEC_ALLOC bit for NOLOAD + note sections for ELF output files. + * testsuite/ld-elf/pr32787.d: New file. + * testsuite/ld-elf/pr32787.t: Likewise. + +2025-03-14 Tom Tromey + + Remove std::hash specialization + C++11 initially omitted specialization of std::hash for enumeration + types, but this was rectified in LWG issue 2148. This patch removes a + redundant specialization. Tested by rebuilding. + + Approved-By: Simon Marchi + +2025-03-14 Simon Marchi + + gdb/dwarf: assume that no dwarf2_cu exist when calling load_full_comp_unit + After staring at the code, I got convinced that it was not possible for + load_full_comp_unit to be called while a dwarf2_cu object exists in + per_objfile for this_cu. If you follow all callers of + load_full_comp_unit, you can see that all calls to load_full_comp_unit + (except one, see below) are gated one way or another by the fact that: + + per_objfile->get_cu (per_cu) == nullptr + + Some calls are gated by maybe_queue_comp_unit returning true. If it + returns true, then necessarily the dwarf2_cu is unset for that per_cu. + + The spot that didn't seem to check for whether the dwarf2_cu is already + set before calling load_full_comp_unit is dw2_do_instantiate_symtab. It + didn't trigger when running the testsuite, but I could imagine a made up + case where the dwarf2_cu would already be set because we looked up a DIE + reference to it (follow_die_ref) for whatever reason. Then, something + would cause the symtab for that CU to be expanded and + dw2_do_instantiate_symtab to be called. + + I added a check in that function, because it seemed prudent to do so. + All other load_cu calls are gated by this check, so it makes this call + look just like the others. + + Finally, because all call sites that use cutu_reader::release_cu pass + nullptr for `existing_cu` (and therefore cutu_reader creates a new + dwarf2_cu), we know that cutu_reader::release_cu will always return a + non-nullptr value. Add an assert in it and remove checks in + load_full_comp_unit and read_signatured_type. + + Change-Id: I496be34bd4bf7edfa38d5135cf4bc4ccd960abe2 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: remove existing_cu parameter of load_full_comp_unit + Following the previous patch, all callers now pass the same thing: + + per_objfile->get_cu (this_cu) + + Remove that parameter and to the call in the function itself. + + Change-Id: Iafd36b058d7b95efae518bb65035c6a03728b018 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: assume that source_cu->dies is always set in follow_die_offset + After staring at the code for a while, I got convinced that it's not + possible for cu->dies to be nullptr in follow_die_offset. It might be a + leftover from the psymtab days. + + In most cases, we see that the dwarf2_cu passedas `*ref_cu` has been + obtained by doing: + + per_objfile->get_cu (per_cu); + + The only way for a dwarf2_cu to end up in the per_objfile like this is + through load_full_comp_unit or read_signatured_type. Both of these + functions call `reader.read_all_dies ()` (which loads the DIEs in memory + and assigns dwarf2_cu::dies) before transferring the newly created + dwarf2_cu to the per_objfile. So any dwarf2_cu obtained through + + per_objfile->get_cu (per_cu) + + ... will have its DIEs set. + + The only case today I'm aware of of a dwarf2_cu without DIEs is in the + cooked indexer. It creates a cutu_reader, but does not call + read_all_dies. Instead, it gets the info_ptr from the cutu_reader and + reads the DIEs from the section buffer directly, on its own. But this + is an entirely different code path that doesn't assign dwarf2_cu + objects to per_objfile. + + So, remove the code path in follow_die_offset that tests for + `source_cu->dies == NULL`. I added an assert at the top of the function + to verify that `source_cu->dies` is always non-nullptr, as a way to + test my hypothesis. We could probably get rid of it, but I left it + there because it doesn't cost much to have it. + + Change-Id: I97f269f092128800850aa5e64eda7032c2edec60 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: rename local variables in follow_die_offset + Rename some local variables to better make the distinction between the + source and target CUs. + + Change-Id: I8b43fac91b8a6f1ca6fd1972846fd6bf28608fe3 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: remove unnecessary per_objfile parameter in cooked_indexer::ensure_cu_exists + The per_objfile object can be obtained from the cutu_reader. This is + actually how both callers get it in order to pass it as argument. + + Change-Id: Iac134ded247d841f80ab5ca55dd9055b556410c3 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: remove some _1 suffixes + These methods don't have (or no longer have) a counterpart without the + _1 suffix, so remove the suffix. + + Change-Id: Ifdfe4fb3b6b09c6bb9e30c27acf9f9ecbcb207f2 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: remove cutu_reader::keep, add cutu_reader::release_cu + This is a bit subjective, but I often struggle to understand what + cutu_reader::keep is meant to do (keep what, where). Perhaps it's just + a question of bad naming, but I think it's a bit confusing for + cutu_reader to transfer the ownership of the dwarf2_cu to the + per_objfile directly. + + Add the cutu::release_cu method and make the caller of cutu_reader + transfer the ownership to the per_objfile object. + + Right now, it is theoretically possible for release_cu to return + nullptr, so I made callers check the return value. A patch later in + this series will change release_cu to ensure it always return + non-nullptr, so those callers will get simplified. + + Change-Id: I3103ff894d1654a95c9d69001073c218501c988a + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: change cutu_reader::read_die_and_siblings to cutu_reader::read_all_dies + After construction of a cutu_reader, only the top-level DIE has been + read in memory. If the caller wants to access the full DIE tree, it + does: + + reader.top_level_die ()->child + = reader.read_die_and_siblings (reader.top_level_die ()); + + I don't really like this poking into cutu_reader's data structures from + the outside, I would prefer if that work was done by cutu_reader. + Rename the read_die_and_siblings method to read_all_dies, and do that + work inside cutu_reader. + + I also moved these operations inside the read_all_dies method: + + gdb_assert (cu->die_hash.empty ()); + cu->die_hash.reserve (cu->header.get_length_without_initial () / 12); + + ... + + cu->dies = reader.top_level_die (); + + The rationale for this is that read_all_dies (and the functions it + calls) is responsible for filling the die_hash set. So I think it makes + sense for it to do the reserve. + + It is also cutu_reader's job, currently, to create and fill the fields + of dwarf2_cu. So I think it makes sense for it to set cu->dies, after + having read the DIEs in memory. + + Change-Id: I088c2e0b367db7d1f67e8c9e2d5b0d61165292fc + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: access m_info_ptr directly instead of passing info_ptr around + The few methods of cutu_reader that read DIEs into memory generally + receive an info_ptr that says where to start reading and return another + one (either by return value or parameter) indicating where the caller + should continue reading. + + We can avoid all this passing around by having these methods access + m_info_ptr directly. This allows changing some methods that read DIEs + to return `die_info *`, instead of returning it by parameter, which just + makes the code simpler to read, I think. + + The only method that meaningfully reads and writes m_info_ptr (except + the places that initially set it up) is read_full_die_1. It reads and + increments m_info_ptr once to read the abbrev and once again to read + each attribute. Other methods use it for logging. + + The methods cutu_reader::read_attribute and + cutu_reader::read_attribute_value do not touch m_info_ptr directly, + because they are used in cooked-indexer.c, which appears to read some + things in a non-linear fashion, unlike cutu_reader's DIE-reading + methods. The cooked indexer calls cutu_reader::info_ptr to get the + m_info_ptr value just after the top-level DIE, and then it does its own + attribute reading after that. + + Change-Id: I251f63d13d453a2827b21349760da033171880e2 + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: factor out to cutu_reader::skip_one_attribute method + I was reading cutu_reader::skip_one_die, and thought that the code to + skip one attribute made it quite difficult to read. Factor this code + out to a new method, to get it out of the way. + + As a bonus, it transforms one goto in a recursion call, which is also + easier to follow. Unfortunately, I have no idea how to test + DW_FORM_indirect, as it doesn't seem to appear anywhere in the + testsuite, and I don't think that compilers often emit that. + + Change-Id: I2257b3e594aafb7c7da52ddd55baa651cefb802f + Approved-By: Tom Tromey + +2025-03-14 Simon Marchi + + gdb/dwarf: remove pretend_language parameter from load_full_{comp,type}_unit + I noticed that load_full_comp_unit and load_full_type_unit didn't use + their pretend_language parameter. Remove them, and then remove more + things that were needed to get the language value to that point, + including the dwarf2_queue_item field. + + Change-Id: Ie8cb21c54ae49da065a1b0a20bf18ccb93961d1a + Approved-By: Tom Tromey + +2025-03-14 Richard Allen + + gprof: only process line numbers for intersection of vmas and histograms + Some programs like RTOS firmware may have a large number of symbols. + The profile information in the profile data file includes histogram + records, which capture low PC and high PC of program execution. If all + histogram records come in the profile data file before any call-graph + records and basic-block records, we can look up only the line numbers + within low PC and high PC in histogram records, which reduces processing + time for such a firmware from ~2 minutes to ~2 seconds. + + Add symbol table access function, get_symtab, get_symtab_direct and + set_symtab to delay loading the symbol table until its first use. + + * aarch64.c (aarch64_find_call): Call get_symtab to get the + symbol table pointer + * alpha.c (alpha_find_call): Likewise. + * basic_blocks.c (bb_read_rec): Likewise. + (bb_write_blocks): Likewise. + (print_exec_counts): Likewise. + (print_annotated_source): Likewise. + * call_graph.c (cg_tally): Likewise. + (cg_write_arcs): Likewise. + * cg_arcs.c (cycle_link): Likewise. + (propagate_flags): Likewise. + (cg_assemble): Likewise. + * cg_print.c (cg_print): Likewise. + (cg_print_index): Likewise. + (cg_print_function_ordering): Likewise. + * corefile.c: Include "gmon_io.h". + (core_create_syms_from): Call get_symtab_direct to get the + symbol table pointer. + (core_create_function_syms): Likewise. + (core_create_line_syms): Likewise. If all histogram records + come in the profile data file before any call-graph records and + basic-block records, we can look up only the line numbers within + low PC and high PC in histogram records. + * gmon_io.c (gmon_histograms_first): New. + (gmon_out_read): Set gmon_histograms_first to true if all + histogram records come first. + (gmon_out_write): Call get_symtab to get the symbol table + pointer. + * hist.c (scale_and_align_entries): Likewise. + (hist_assign_samples_1): Likewise. + (hist_print): Likewise. + * i386.c (i386_find_call): Likewise. + * mips.c (mips_find_call): Likewise. + * sparc.c (sparc_find_call): Likewise. + * sym_ids.c (sym_id_parse): Likewise. + * vax.c (vax_find_call): Likewise. + * gmon_io.h (gmon_histograms_first): New. + * gprof.c (man): Don't create profile info. + (symtab_init): New. + * gprof.h (symtab_init): New. + * symtab.c (symtab): Changed to static. + (get_symtab_direct): New. + (get_symtab): Likewise. + (set_symtab): Likewise. + * symtab.h (symtab): Removed. + (get_symtab_direct): New. + (get_symtab): Likewise. + (set_symtab): Likewise. + + Co-Authored-By: H.J. Lu + +2025-03-14 Jan Beulich + + gas: permit wider-than-byte operands for .cfi_escape + Some DW_CFA_* and DW_OP_* take wider than byte, but non-LEB128 operands. + Having to hand-encode such when needing to resort to .cfi_escape isn't + very helpful. + + gas: permit LEB128 operands for .cfi_escape + Many DW_CFA_* and DW_OP_* take LEB128 operands. Having to hand-encode + such when needing to resort to .cfi_escape isn't very helpful. + + gas: make NO_LISTING work again + Presumably since no target enables this and there's also no configure + control, builds with NO_LISTING defined didn't really work anymore. + Convert fallback functions to macros and add #ifndef in a few places. + (Behavior is different for affected command line options vs directives: + The former are rejected as unrecognized, while the latter are silently + ignored. I think that's fair enough.) + + gas: include .cfi_* generated data in listing + These are data generating directives not overly different from e.g. + .byte and .long. Whatever (directly) results from should also be + represented in the listing, if one was requested. It's just that the + output data is generated much later than the parsing of the directive + arguments. + +2025-03-14 Jan Beulich + + gas: deal with the need for relocations from .cfi_{escape,fde_data} + Ignoring return values often isn't a good idea. The Sparc assembler in + particular would report an internal error if an expression with + relocation specifier is used with .cfi_escape, when the same works fine + with .byte. Propagate the relocation indicator up from + do_parse_cons_expression(), and eventually into emit_expr_with_reloc(). + + dot_cfi_fde_data(), only retaining the expression's X_add_number, would + require further work. Simply report the lack of support there. While + there, also check that what we were dealt is actually a constant. + +2025-03-14 GDB Administrator + + Automatic date update in version.in + +2025-03-13 Andrew Burgess + + gdb/testsuite: fix undefined variable in gdb.ada/scalar_storage.exp + Commit: + + commit be382ece165eefa3e65f61bfb6b2aa2ee95dd6b4 + Date: Wed Feb 12 09:35:26 2025 -0700 + + Check for compiler support in scalar_storage.exp + + Introduced an undefined variable use in gdb.ada/scalar_storage.exp, + fixed by this commit. + +2025-03-13 Simon Marchi + + gdb/dwarf: keep going even if reading macro information fails + On Debian 12, with gcc 12 and ld 2.40, I get some failures when running: + + $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission" + + I think I stumble on this bug [1], preventing the test from doing + anything that requires expanding the compilation unit: + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style + Reading symbols from testsuite/outputs/gdb.base/style/style... + (gdb) p main + DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style] + (gdb) + + The error is thrown here: + + #0 0x00007ffff693f0a1 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 + #1 0x0000555569ce6852 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:203 + #2 0x0000555569ce690f in throw_verror (error=GENERIC_ERROR, fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", ap=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdbsupport/common-exceptions.cc:211 + #3 0x000055556879c0cb in verror (string=0x555562a9fc40 "%s pointing outside of %s section [in module %s]", args=0x7fffffff8df0) at /home/smarchi/src/binutils-gdb/gdb/utils.c:193 + #4 0x0000555569cfa88d in error (fmt=0x555562a9fc40 "%s pointing outside of %s section [in module %s]") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:45 + #5 0x000055556667dbff in dwarf2_section_info::read_string (this=0x61b000042a08, objfile=0x616000055e80, str_offset=262811, form_name=0x555562886b40 "DW_FORM_strp") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/section.c:211 + #6 0x00005555662486b7 in dwarf_decode_macro_bytes (per_objfile=0x616000056180, builder=0x614000006040, abfd=0x6120000f4b40, mac_ptr=0x60300004f5be "", mac_end=0x60300004f5bb "\002\004", current_file=0x62100007ad70, lh=0x60f000028bd0, section=0x61700008ba78, section_is_gnu=1, section_is_dwz=0, offset_size=4, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional = {...}, include_hash=..., cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:511 + #7 0x000055556624af0e in dwarf_decode_macros (per_objfile=0x616000056180, builder=0x614000006040, section=0x61700008ba78, lh=0x60f000028bd0, offset_size=4, offset=0, str_section=0x61700008bac8, str_offsets_section=0x61700008baf0, str_offsets_base=std::optional = {...}, section_is_gnu=1, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:934 + #8 0x000055556642cb82 in dwarf_decode_macros (cu=0x61700008b600, offset=0, section_is_gnu=1) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:19435 + #9 0x000055556639bd12 in read_file_scope (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6366 + #10 0x0000555566392d99 in process_die (die=0x6210000885c0, cu=0x61700008b600) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5310 + #11 0x0000555566390d72 in process_full_comp_unit (cu=0x61700008b600, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:5075 + + The exception is then only caught at the event-loop level + (start_event_loop), causing the whole debug info reading process to be + aborted. I think it's a little harsh, considering that a lot of things + could work even if we failed to read macro information. + + Catch the exception inside read_file_scope, print the exception, and + carry on. We could go even more fine-grained: if reading the string for + one macro definition fails, we could continue reading the macro + information. Perhaps it's just that one macro definition that is + broken. However, I don't need this level of granularity, so I haven't + attempted this. Also, my experience is that macro reading fails when + the compiler or linker has a bug, in which case pretty much everything + is messed up. + + With this patch, it now looks like: + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style + Reading symbols from testsuite/outputs/gdb.base/style/style... + (gdb) p main + While reading section .debug_macro.dwo: DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style] + $1 = {int (int, char **)} 0x684
+ (gdb) + + In the test I am investigating (gdb.base/style.exp with the fission + board), it allows more tests to run: + + -# of expected passes 107 + -# of unexpected failures 17 + +# of expected passes 448 + +# of unexpected failures 19 + + Of course, we still see the error about the macro information, and some + macro-related tests still fail (those would be kfailed ideally), but + many tests that are not macro-dependent now pass. + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 + + Change-Id: I0bdb01f153eff23c63c96ce3f41114bb027e5796 + Approved-By: Tom Tromey + +2025-03-13 Simon Marchi + + gdb/testsuite: fail less catastrophically in gdb.base/style.exp + On Debian 12, with gcc 12 and ld 2.40, I get some failures when running: + + $ make check TESTS="gdb.base/style.exp" RUNTESTFLAGS="--target_board=fission" + + I think I stumble on this bug [1], preventing to do the + disassembling that the test needs: + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/style/style + Reading symbols from testsuite/outputs/gdb.base/style/style... + (gdb) x/1i *main + DW_FORM_strp pointing outside of .debug_str section [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/style/style] + (gdb) + + The regexp in get_single_disassembled_insn fails to match, the insn + variable doesn't get set, and we get one of those unreadable TCL stack + traces: + + ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/style.exp. + ERROR: tcl error code TCL READ VARNAME + ERROR: can't read "insn": no such variable + while executing + "return $insn" + (procedure "get_single_disassembled_insn" line 4) + invoked from within + "get_single_disassembled_insn" + ("uplevel" body line 18) + invoked from within + "uplevel 1 $body" + invoked from within + ... + + Check the return value of the regexp call, return an empty string on + failure. Log a failure, so that we have a trace that something went + wrong, in case the tests done by the caller happen to pass by change. + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 + + Change-Id: I5123d4cc0034da85a093a8531a22e972c10d94ca + Approved-By: Tom Tromey + +2025-03-13 Andrew Burgess + + gcore/doc: fix mistake in the gcore man page + The gcore man page says that the default prefix for a generated core + file will be 'gcore', i.e. we'll create files like 'gcore.pid'. In + reality the default is 'core'. + + As far as I can tell, the default has been 'core' for years, and the + docs used to say that the default was 'core', but the docs were + changed by mistake in commit: + + commit 129eb0f1f16dc7a49799a024a7bcb109d954a1e7 + Date: Fri Jul 27 00:52:23 2018 -0400 + + Improve gcore manpage and clarify "-o" option + + So, lets bring the docs back inline with the code. + + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2025-03-13 Andrew Burgess + + gcore: add -h|--help options, and improve help/usage message output + Like the previous commit, this copies a lot from: + + commit fb2ded33c1e519659743047ed7817166545b6d91 + Date: Fri Dec 20 12:46:11 2024 -0800 + + Add gstack script + + And adds -h | --help options to the gcore script, and smartens up the + help and usage output messages. + + The usage text is now split over several lines (as it was getting a + bit long), and an input error suggests using `--help` instead of + printing the full usage string. + + These changes bring gcore and gstack closer in behaviour. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2025-03-13 Andrew Burgess + + gcore: add -v or --version option to show version number + Based on the work in this commit: + + commit fb2ded33c1e519659743047ed7817166545b6d91 + Date: Fri Dec 20 12:46:11 2024 -0800 + + Add gstack script + + This commit adds a '-v' or '--version' option to the existing gcore + script. This new option causes the script to print its version + number, and then exit. + + I needed to adjust the getopts handling a little in order to support + the long form '--version' argument, but as this makes gcore more + consistent with gstack, then this seems like a good thing. + + The usage message is now getting a little long. Don't worry, I plan + to clean that up in the next commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2025-03-13 Tom de Vries + + [gdb/record] Fix out-of-bounds write in aarch64_record_asimd_load_store + After compiling gdb with -fstack-protector-all, and running test-case + gdb.reverse/getrandom.exp on aarch64-linux, we run into + "Stack smashing detected" in function aarch64_record_asimd_load_store. + + This is reported in PR record/32784. + + This happens due to an out-of-bounds write to local array record_buf_mem: + ... + uint64_t record_buf_mem[24]; + ... + when recording insn: + ... + B+>0xfffff7ff4d10 st1 {v0.16b-v3.16b}, [x0] + ... + + We can fix this by increasing the array size to 128, but rather than again + hardcoding a size, reimplement record_buf_mem as std::vector. + + Tested on aarch64-linux. + + Approved-By: Guinevere Larsen + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32784 + +2025-03-13 Tom de Vries + + [gdb/record] Support recording syscall accept4 + While reviewing the enum gdb_syscall entries with values >= 500, I noticed + that gdb_sys_accept exists, but gdb_sys_accept4 doesn't, while recording + support is essentially the same, given that the difference in interface is + only an extra int parameter: + ... + int accept (int sockfd, struct sockaddr *addr, socklen_t *addrlen); + int accept4 (int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags); + ... + + Fix this by: + - adding gdb_sys_accept4, + - supporting it in record_linux_system_call alongside gdb_sys_accept, and + - mapping to gdb_sys_accept4 in various syscall canonicalization functions. + + The usual thing to do before the rewrite of i386_canonicalize_syscall would + have been to use the value from arch/x86/entry/syscalls/syscall_32.tbl: + ... + gdb_sys_accept4 = 364, + ... + but that's no longer necessary, so instead we use some >= 500 value: + ... + gdb_sys_accept4 = 533, + ... + to steer clear of the space where ppc_canonicalize_syscall and + s390_canonicalize_syscall do hard-coded number magic. + + Tested on x86_64-linux, with and without target board unix/-m32, and + aarch64-linux. + + Approved-By: Guinevere Larsen + +2025-03-13 Tom de Vries + + [gdb/tdep] Rewrite i386_canonicalize_syscall + On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case + gdb.reverse/recvmsg-reverse.exp, I run into: + ... + (gdb) continue^M + Continuing.^M + Process record and replay target doesn't support syscall number 360^M + Process record: failed to record execution log.^M + ^M + Program stopped.^M + 0xf7fc5575 in __kernel_vsyscall ()^M + (gdb) FAIL: $exp: continue to breakpoint: marker2 + ... + + The syscall number 360 in i386 is for syscall socketpair, as we can see in + arch/x86/entry/syscalls/syscall_32.tbl: + ... + + 360 i386 socketpair sys_socketpair + ... + + Function i386_canonicalize_syscall assumes that any syscall below 500 maps to + an identically valued enum in enum gdb_syscall: + ... + static enum gdb_syscall + i386_canonicalize_syscall (int syscall) + { + enum { i386_syscall_max = 499 }; + + if (syscall <= i386_syscall_max) + return (enum gdb_syscall) syscall; + else + return gdb_sys_no_syscall; + } + ... + + However, that's not the case. The value of gdb_sys_socketpair is not 360, + but 512: + ... + enum gdb_syscall { + ... + gdb_sys_getrandom = 355, + gdb_sys_statx = 383, + ... + gdb_sys_socketpair = 512, + ... + + Consequently, when record_linux_system_call is called with + syscall == i386_canonicalize_syscall (360), we hit the default case here: + .... + switch (syscall) + { + ... + default: + gdb_printf (gdb_stderr, + _("Process record and replay target doesn't " + "support syscall number %d\n"), syscall); + return -1; + break; + } + ... + rather than hitting the case for gdb_sys_socketpair. + + I initially wrote a trivial fix for this, changing the value of + gdb_sys_socketpair to 360. However, Andreas Schwab pointed out that there are + other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that + make assumptions about specific values of enum gdb_syscall, and fixing this + for i386 may break things for ppc or s390. + + So instead, I decided to rewrite i386_canonicalize_syscall to match the + approach taken in aarch64_canonicalize_syscall, which allows + gdb_sys_socketpair to keep the same value. + + So, fix this by: + - adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for + each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl, + - using gdb/i386-syscalls.def to define enum i386_syscall, and + - using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to + define the mapping from enum i386_syscall to enum gdb_syscall in + i386_canonicalize_syscall. + + I've created the mapping as follows: + - I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping + using SYSCALL_MAP for each syscall, + - I attempted to compile this and used the compilation errors about + non-existing gdb_sys_ values to change those entries to + UNSUPPORTED_SYSCALL_MAP, which got me a compiling version, + - I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to + SYSCALL_MAP_RENAME where necessary, + - I then reviewed syscalls below 500 that mapped to a gdb_syscall value below + 500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and + - reviewed the mapping for gdb_syscall entries >= 500. + + On the resulting mapping, I was able to do the following sanity check: + ... + for (int i = 0; i < 500; ++i) + { + int res = i386_canonicalize_syscall (i); + if (res == i) + continue; + if (res == -1) + continue; + if (res >= 500) + continue; + gdb_assert_not_reached (""); + } + } + ... + to make sure that any syscall below 500 either: + - maps to the same number, + - is unsupported, or + - maps to a number >= 500. + + Coming back to our original problem, the socket pair syscall is addressed by + an entry: + ... + SYSCALL_MAP (socketpair); + ... + which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512). + + Tested on x86_64-linux with target board unix/-m32. + + Approved-By: Guinevere Larsen + + PR tdep/32770 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770 + +2025-03-13 Simon Marchi + + gdb/dwarf: use all_units_range in dwarf2_base_index_functions::expand_all_symtabs + Commit 292041562289 ("gdb/dwarf: use ranged for loop in some spots") + broke some tests notably gdb.base/maint.exp with the fission board. + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/maint/maint -ex start -ex "maint expand-sym" -batch + ... + Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/break.c:43 + 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */ + /usr/include/c++/14.2.1/debug/safe_iterator.h:392: + In function: + gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>& + gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::operator++() + [with _Iterator = gnu_cxx:: + normal_iterator*, + std::vector, + std::allocator > > + >; _Sequence = std::debug::vector >; _Category = std::forward_iterator_tag] + + Error: attempt to increment a singular iterator. + + Note that this is caught because I build with -D_GLIBCXX_DEBUG=1. + Otherwise, it might crash more randomly, or just not crash at all (but + still be buggy). + + While iterating on the all_units vector, some type units get added + there: + + #0 add_type_unit (per_bfd=0x51b000044b80, section=0x50e0000c2280, sect_off=0, length=74, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2576 + #1 0x00005555618a3a40 in lookup_dwo_signatured_type (cu=0x51700009b580, sig=4367013491293299229) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2664 + #2 0x00005555618ee176 in queue_and_load_dwo_tu (dwo_unit=0x521000120e00, cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8329 + #3 0x00005555618eeafe in queue_and_load_all_dwo_tus (cu=0x51700009b580) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:8366 + #4 0x00005555618966a6 in dw2_do_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1695 + #5 0x00005555618968d4 in dw2_instantiate_symtab (per_cu=0x50f0000043c0, per_objfile=0x516000065a80, skip_partial=true) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1719 + #6 0x000055556189ac3f in dwarf2_base_index_functions::expand_all_symtabs (this=0x502000024390, objfile=0x516000065780) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1977 + + This invalidates the iterator in + dwarf2_base_index_functions::expand_all_symtabs, which is caught by the + libstdc++ debug mode. + + I'm not entirely sure that it is correct to append type units from dwo + files to the all_units vector like this. The + dwarf2_find_containing_comp_unit function expects a precise ordering of + the elements of the all_units vector, to be able to do a binary search. + Appending a type unit at the end at this point certainly doesn't respect + that ordering. + + For now I'd just like to undo the regression. Do that by using + all_units_range in the ranged for loop. I will keep in mind to + investigate whether this insertion of type units in all_units after the + fact really makes sense or not. + + Change-Id: Iec131e59281cf2dbd12d3f3d163b59018fdc54da + +2025-03-13 Simon Marchi + + gdb/dwarf: remove unused parameter of create_dwo_cu_reader + Change-Id: I0c5b7591eab8e6616b653be7c04bc75159427ad6 + +2025-03-13 Simon Marchi + + gdb/dwarf: remove unnecessary braces + Change-Id: I3cd6b932d0dfb4cc07b6d48a1dc9ec35e7bfa03e + +2025-03-13 Simon Marchi + + gdb/dwarf: use ranged for loop in some spots + I noticed that these loops could be written to avoid the iteration + variable `i`. + + Change-Id: I8b58eb9913b6ac8505ee45eb8009ef7027236cb9 + +2025-03-13 GDB Administrator + + Automatic date update in version.in + +2025-03-12 Sam James + + gprofng: regenerate Makefile.in + Needed after 90803ffdcc4d8c3d17566bf8dccadbad312f07a9. + + gprofng/ChangeLog + * src/Makefile.in: Regenerate. + +2025-03-12 Zheng Junjie + + gprofng: Fix cross-compilation binary name. + commit d25ba4596e85da6d8af78c88b5917e14763afbe1 create symbolic link + no care cross-compilation prefix. + + gprofng/ChangeLog + 2025-02-10 Zheng Junjie + * src/Makefile.am: create symbolic link respect cross-compilation. + * src/Makefile.in: Rebuild. + +2025-03-12 Tom Tromey + + Use correct types in string-set.h + My earlier patch to introduce string-set.h used the wrong type in the + hash functions. This patch fixes the error. + +2025-03-12 Simon Marchi + + gdb: remove unused includes in exceptions.c + These are reported as unused by clangd. + + Change-Id: I54b3fba4d7a73c955a9a26c0d340a384b2d37b32 + +2025-03-12 Simon Marchi + + gdb: remove trailing whitespaces in exceptions.c + Change-Id: Icc7b468b85c09a9721fc9580892c9ad424e0a29a + +2025-03-12 Simon Marchi + + gdb: remove include from process-stratum-target.h + It is reported as unused by clangd. + + Change-Id: I73c03577c521c1b71128409b5cf085a4d1785080 + +2025-03-12 GDB Administrator + + Automatic date update in version.in + +2025-03-11 Tom Tromey + + Use gdb map in mi-cmds.c + This changes mi-cmds.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb map in py-connection.c + This changes py-connection.c to use gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set in dwarf2/aranges.c + This changes dwarf2/aranges.c to use gdb::unordered_set. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set in all_non_exited_process_targets + This changes all_non_exited_process_targets to return + gdb::unordered_set. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set and map in remote.c + This changes remote.c to use gdb::unordered_set and + gdb::unordered_map. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set and map in mi-main.c + This changes mi-main.c to use gdb::unordered_set and + gdb::unordered_map. + + this may change the order of core ids that are emitted, but that seems + fine as MI generally doesn't guarantee ordering. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb::function_view in iterate_over_threads + This C++-ifies iterate_over_threads, changing it to accept a + gdb::function_view and to return bool. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set and map in TUI + This changes the TUI to use gdb::unordered_map and gdb::unordered_set + rather than the std:: variants. + + Approved-By: Simon Marchi + +2025-03-11 Tom Tromey + + Use gdb set and map in source_cache + This changes source_cache to use gdb::unordered_map and + gdb::unordered_set rather than the std:: variants. + + Approved-By: Simon Marchi + +2025-03-11 Tom de Vries + + [gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41 + On openSUSE Tumbleweed, with glibc 2.41, when running test-case + gdb.base/step-over-syscall.exp I run into: + ... + (gdb) stepi^M + 0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M + 1: x/i $pc^M + => 0x7ffff7cfd09b <__abort_lock_rdlock+29>: syscall^M + (gdb) p $eax^M + $1 = 14^M + (gdb) FAIL: $exp: fork: displaced=off: syscall number matches + FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout) + ... + + We're stepi-ing through fork trying to find the fork syscall, but encounter + another syscall. + + The test-case attempts to handle this: + ... + gdb_test_multiple "stepi" "find syscall insn in $syscall" { + -re ".*$syscall_insn.*$gdb_prompt $" { + # Is the syscall number the correct one? + if {[syscall_number_matches $syscall]} { + pass $gdb_test_name + } else { + exp_continue + } + } + -re "x/i .*=>.*\r\n$gdb_prompt $" { + incr steps + if {$steps == $max_steps} { + fail $gdb_test_name + } else { + send_gdb "stepi\n" + exp_continue + } + } + } + ... + but fails to do so because it issues an exp_continue without issuing a new + stepi command, and consequently the "find syscall insn in fork" test times + out. + + Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping + one syscall would produce: + ... + FAIL: $exp: fork: displaced=off: syscall number matches + PASS: $exp: fork: displaced=off: syscall number matches + DUPLICATE: $exp: fork: displaced=off: syscall number matches + ... + + Fix this by: + - not producing PASS or FAIL in syscall_number_matches, and + - issuing stepi when encountering another syscall. + + While we're at it, fix indentation in syscall_number_matches. + + Tested on x86_64-linux, specifically: + - openSUSE Tumbleweed (glibc 2.41), and + - openSUSE Leap 15.6 (glibc 2.38). + + PR testsuite/32780 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780 + +2025-03-11 GDB Administrator + + Automatic date update in version.in + +2025-03-10 Tom Tromey + + Remove pid from test name in gcore-memory-usage.exp + The new gcore-memory-usage.exp test puts a PID into a test case name, + causing spurious comparison failures. This patch changes the test + name to avoid this. + +2025-03-10 Tom Tromey + + Add string cache and use it in cooked index + The cooked index needs to allocate names in some cases -- when + canonicalizing or when synthesizing Ada package names. This process + currently uses a vector of unique_ptrs to manage the memory. + + Another series I'm writing adds another spot where this allocation + must be done, and examining the result showed that certain names were + allocated multiple times. + + To clean this up, this patch introduces a string cache object and + changes the cooked indexer to use it. I considered using bcache here, + but bcache doesn't work as nicely with string_view -- because bcache + is fundamentally memory-based, a temporary copy of the contents must + be made to ensure that bcache can see the trailing \0. Furthermore, + writing a custom class lets us avoid another copy when canonicalizing + C++ names. + + Approved-By: Simon Marchi + +2025-03-10 Simon Marchi + + Revert past commits + I accidentally pushed my work-in-progress branch... revert that. Sorry + for the noise :(. + + The list of commits reverted are: + + ae2a50a9ae15 attempt to revamp to the CU/TU list + e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles" + 6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name + 32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def + b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them + 30ba74418982 gdb/dwarf: track comp and type units count + bedb4e09f292 gdb/dwarf: remove unnecessary braces + b4f18de12c77 gdb/dwarf: use ranged for loop in some pots + + Change-Id: I80aed2847025f5b15c16c997680783b39858a703 + +2025-03-10 Simon Marchi + + attempt to revamp to the CU/TU list + Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7 + +2025-03-10 Simon Marchi + + gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles" + This was useful to me, to debug some problems. + + Before printing cooked index entries, print a list of CUs and TUs. The + information printed for each is a bit arbitrary, I took a look at the + types and printed what seemed relevant. + + An example of output for a CU: + + [0] ((dwarf2_per_cu_data *) 0x50f000007840) + type: DW_UT_compile + offset: 0x0 + size: 0x1bff + artificial: false + GDB lang: c++ + DWARF lang: DW_LANG_C_plus_plus + + And for a TU: + + [2] ((signatured_type *) 0x511000040000) + type: DW_UT_type + offset: 0x0 + size: 0x94 + signature: 0x2e966c0dc94b065b + + I moved the call to cooked_index_functions::wait before printing the + CU/TU list, otherwise trying to call "maint print objfiles" quickly, + like this, would lead to an internal error: + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig -ex "maint print objfiles" + + This is because dwarf2_per_cu_data::m_unit_type was not yet set, when + trying to read it. Waiting for the index to be built ensures that it is + set, since setting the unit type is done as a side-effect somewhere. + + Change-Id: Ic810ec3bb4d3f5abb481cf1cee9b2954ff4f0874 + +2025-03-10 Simon Marchi + + gdb/dwarf: add dwarf_source_language_name + Add dwarf_source_language_name, to convert a DW_LANG_* constant to + string. This will be used in a following patch. + + Change-Id: I552ebd318e2e770d590de5920edbd0b75075c1b7 + Approved-By: Tom Tromey + +2025-03-10 Simon Marchi + + libiberty: move DW_LANG_* definitions to dwarf2.def + In order to get a "DW_LANG_* to string" function: + + - move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def + - add the necessary macros in dwarf2.h to generate the enumeration + - add the necessary macros in dwarfnames.c to generate the "to string" + function + + include/ChangeLog: + + * dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then + undefine. + (enum dwarf_source_language): Remove. + (get_DW_LANG_name): Declare. + * dwarf2.def: Define DW_LANG_* constants. + + libiberty/ChangeLog: + + * dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define + then undefine. + + Change-Id: I440aa2b1f55c7585d7e44c8fa7c41310b0ef2b3a + Cc: binutils@sourceware.org + +2025-03-10 Simon Marchi + + gdb/dwarf: move index unit vectors to debug names reader and use them + Since these vectors contain the CU and TU lists as found in the + .debug_names header, it seems like they are meant to be used by the + .debug_names reader when handling a DW_IDX_compile_unit or + DW_IDX_type_unit attribute. The value of the attribute would translate + directly into an index into one of these vectors. + + However there's something fishy: it looks like these vectors aren't + actually used in practice. They are used in the + dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used + anywhere. + + The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the + dwarf2_per_bfd::get_cu method, assuming that all compile units are + placed before type units in the dwarf2_per_bfd::all_units vector. I see + several problems with that: + + 1. I found out [1] that the dwarf2_per_bfd::all_units didn't always + have the CUs before the TUs. So indexing dwarf2_per_bfd::all_units + with that assumption will not work. + + 2. The dwarf2_find_containing_comp_unit function assumes an ordering of + units by section offset (among other criteria) in order to do a + binary search. Even though it's probably commonly the case, nothing + guarantees that the order of CUs and TUs in the .debug_names header + (which defines the indices used to refer to them) will be sorted by + section offset. It's not possible to make + dwarf2_find_containing_comp_unit (assuming it wants to do a binary + search by section offset) and the DW_IDX_compile_unit / + DW_IDX_type_unit handlers use the same vector. + + 3. I have not tested this, but in the presence of a dwz supplementary + file, the .debug_names reader should probably not put the units from + the main and dwz files in the same vectors to look them up by index. + Presumably, if both the main and dwz files have a .debug_names + index, they have distinct CU / TU lists. So, an CU index of 1 in an + index entry in the main file would refer to a different CU than an + index of 1 in an index entry in the dwz file. The current code + doesn't seem to account for that, it just indexes + dwarf2_per_bfd::all_units. + + Since those vectors are kind of specific to the .debug_names reader, + move them there, in the mapped_debug_names_reader struct. Then, update + the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them. + + [1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4 + + Change-Id: I3958d70bb3875268143471da745aa09336ab2500 + +2025-03-10 Simon Marchi + + gdb/dwarf: track comp and type units count + A subsequent commit will remove the all_comp_units and all_type_units + array views, since the all_units vector will no longer be segmented + between comp and type units. Some callers still need to know the number + of each kind, so track that separately. + + Change-Id: I6ef184767a96e5be095bbf9142aa850adbb083ac + +2025-03-10 Simon Marchi + + gdb/dwarf: remove unnecessary braces + Change-Id: If0b38b860e79771a16ea914af3e337fca0ee3a7d + +2025-03-10 Simon Marchi + + gdb/dwarf: use ranged for loop in some pots + I noticed that these loops could be written to avoid the iteration + variable `i`. + + Change-Id: Ia3717acbbf732f0337870d35ac60fe6400383324 + +2025-03-10 Simon Marchi + + gdb/dwarf: save DWARF version in dwarf2_loclist_baton, remove it from dwarf2_per_cu + When running: + + $ make check TESTS="gdb.cp/cpexprs-debug-types.exp" RUNTESTFLAGS="--target_board=fission" + + I get: + + (gdb) break -qualified main + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.h:295: internal-error: version: Assertion `m_dwarf_version != 0' failed. + + The problem is that dwarf2_per_cu objects created in the + read_cutu_die_from_dwo code path never have their DWARF version set. A + seemingly obvious solution would be to add a call to + dwarf2_per_cu::set_version in there (there's a patch in the referenced + PR that does that). However, this comment in + read_comp_units_from_section is a bit scary: + + /* Init this asap, to avoid a data race in the set_version in + cutu_reader::cutu_reader (which may be run in parallel for the cooked + index case). */ + this_cu->set_version (cu_header.version); + + I don't know if a DWO file can be read while the cooked indexer runs, so + if it would be a problem here, but I prefer to be safe than sorry. This + patch side-steps the problem by deleting the DWARF version from + dwarf2_per_cu. + + The only users of dwarf2_per_cu::version are the loclists callbacks in + `loc.c`. Add the DWARF version to dwarf2_loclist_baton and modify those + callbacks to get the version from there instead. Initialize that new + field in fill_in_loclist_baton. + + I like this approach because there is no version field that is possibly + unset now. + + I wasn't keen on doing this at first because I thought it would waste + space, but the dwarf2_loclist_baton has 7 bytes of padding at the end + anyway, so we might as well use that. + + Cc: Ricky Zhou + Cc: Tom de Vries + Cc: Tom Tromey + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309 + Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52 + Approved-By: Tom Tromey + +2025-03-10 Tom Tromey + + Use flags enum for cooked_index_entry::full_name + I found a small bug coming from a couple of recent patches of mine for + cooked_index_entry::full_name. + + First, commit aab26529b30 (Add "Ada linkage" mode to + cooked_index_entry::full_name) added a small hack to optionally + compute the Ada linkage name. + + Then, commit aab2ac34d7f (Avoid excessive CU expansion on failed + matches) changed the relevant expand_symtabs_matching implementation + to use this feature. + + However, the feature was used unconditionally, causing a bad side + effect: the non-canonical name is now used for all languages, not just + Ada. But, for C++ this is wrong. + + Furthermore, consider the declaration of full_name: + + const char *full_name (struct obstack *storage, + bool for_main = false, + bool for_ada_linkage = false, + const char *default_sep = nullptr) const; + + ... and then consider this call in cooked_index::dump: + + gdb_printf (" qualified: %s\n", + entry->full_name (&temp_storage, false, "::")); + + Oops! The "::" is silently converted to 'true' here. + + To fix both of these problems, this patch changes full_name to accept + a flags enum rather than booleans. This avoids the type-safety + problem. + + Then, full_name is changed to remove the "Ada" flag when the entry is + not in fact an Ada symbol. + + Regression tested on x86-64 Fedora 40. + + Approved-By: Simon Marchi + +2025-03-10 Tom Tromey + + Remove eval_op_scope + eval_op_scope is very similar to + scope_operation::evaluate_for_address. This patch combines the two + into a single method of scope_operation. + + Regression tested on x86-64 Fedora 40. + + Approved-By: Simon Marchi + +2025-03-10 Simon Marchi + + gdb/dwarf: rename comp_unit_die to top_level_die + The name "comp_unit_die" is a bit misleading, because it can also + represent a type unit (DW_TAG_type_unit). I think that "top_level_die" + is clear. + + Change-Id: Ibaac99897f0ac7499f0f82caeed3385e1e6ee870 + Approved-By: Tom Tromey + +2025-03-10 Simon Marchi + + gdb/dwarf: add doc for cutu_reader::is_dummy + Change-Id: Ifb80557187c12822bdea7ad400c32c3dce968a7f + Approved-By: Tom Tromey + +2025-03-10 Tom Tromey + + Fix check-include-guards.py + I noticed that check-include-guards.py doesn't error in certain + situations -- but in situations where the --update flag would cause a + file to be changed. + + This patch changes the script to issue an error for any discrepancy. + It also fixes the headers that weren't correct. + + Approved-By: Simon Marchi + +2025-03-10 H.J. Lu + + gprof: Append -l to tst-gmon-gprof-l.sh data files + Append -l to tst-gmon-gprof-l.sh data files to avoid conflicts with + tst-gmon-gprof.sh data files. + + * testsuite/tst-gmon-gprof-l.sh (actual): Append -l. + (expected): Likewise. + (expected_dot): Likewise. + +2025-03-10 H.J. Lu + + gprof: Add a simple test for gprof -l + Verify that "gprof -l" works properly. + + * testsuite/Makefile.am (check_SCRIPTS): Add tst-gmon-gprof-l.sh. + * testsuite/Makefile.in: Regenerated. + * testsuite/tst-gmon-gprof-l.sh: New. + +2025-03-10 Alan Modra + + meaningless p_offset for zero p_filesz PT_LOAD + This patch avoids generating PT_LOAD segments that trip a bug in + glibc's loader. + + PR 25237 + PR 32763 + * elf.c (assign_file_positions_for_load_sections): Don't put + p_offset zero for empty PT_LOAD. + +2025-03-10 Alan Modra + + Further tidies to bed->p_align code + align_pagesize was used for two things, reducing p->p_align from + maxpagesize to the bed->p_align value (section alignment permitting), + and increasing p->p_align above maxpagesize if section alignment + required that. This patch untangles those two, making align_pagesize + only do the former. p->p_align is set directly for the latter. I've + made that change to p->p_align only when D_PAGED to keep things + consistent with other early assignments to p->p_align. p->p_align is + set later according to section alignment when not D_PAGED. + + I've also moved the place where align_pagesize adjusts p->p_align to + be with other code setting p->p_align. That seemed better to me than + leaving it until the last possible moment. Note that it isn't + necessary to have this adjustment done inside a test for a PT_LOAD + header, since we never set align_pagesize non-zero outside a PT_LOAD + test. + + * elf.c (assign_file_positions_for_load_sections): Clear + align_pagesize whenever we have a section alignment more than + bed->p_align. Set p->p_align rather than align_pagesize + when section alignment exceeds maxpagesize. Assign p->p_align + from align_pagesize earlier. + +2025-03-10 Alan Modra + + Tidy code handling bed->p_align a little. + No functional changes here, just preparation for the next patch. + + * elf.c (assign_file_positions_for_load_sections): Replace + p_align_p and p_align with align_pagesize. Revise comments + on code handling bed->p_align. + +2025-03-10 Jens Remus + + ld: Cleanup sframe_decoder_init_func_bfdinfo use of reloc cookie + The loop did set cookie->rel to the i-th relocation twice. At the + beginning using the loop counter. At the end by incrementing. One + approach is sufficient. + + Change cookie to pointer-to-const, replace cookie->rel by rel, + initialize before the loop and increment at the end, and merge the + two assertions (for cookie->rel) into one. + + While at it change sec to pointer-to-const. + + bfd/ + * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Cleanup use + of relocation cookie. + +2025-03-10 Jens Remus + + gas: Use SFrame header and FDE field sizes when generating .sframe + The use of SFRAME_RELOC_SIZE in generation of SFrame stack trace + information from CFI directives erroneously suggested that this could + be used to configure a different relocation size. But in practice it + is tied to the SFrame field sizes it is used for and therefore cannot + be changed. + + Replace the uses of SFRAME_RELOC_SIZE by the size of the respective + SFrame header and FDE fields when emitting SFrame information. While + at it enhance some comments. + + gas/ + * gen-sframe.c (SFRAME_RELOC_SIZE): Delete. + (sizeof_member): Define. + (output_sframe_funcdesc): Use size of SFrame FDE fields instead + of SFRAME_RELOC_SIZE. + (output_sframe_internal): Use size of SFrame header fields + instead of SFRAME_RELOC_SIZE. + +2025-03-10 GDB Administrator + + Automatic date update in version.in + +2025-03-09 Nelson Chu + + RISC-V: PR32772, fixed segfault caused by the accidental removal of `h != NULL' + bfd/ + PR 32772 + * elfnn-riscv.c (riscv_elf_relocate_section): Fixed segfault caused by + the accidental removal of `h != NULL' when handling a call to an + undefined weak function. + +2025-03-09 Brandon Belew + + Fix segfault if target_fileio_read_alloc fails + Check for target_fileio_read_alloc failure in linux_fill_prpsinfo + before dereferencing buffer. This fixes a segfault in the 'gcore' + command when attached to certain remote targets. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32441 + Approved-By: Andrew Burgess + +2025-03-09 GDB Administrator + + Automatic date update in version.in + +2025-03-08 Alan Modra + + bfd_elf_parse_attr_section_v1 buffer overflow + This function has a misleading parameter "contents", which usually + means an entire section contents is passed. However in this case the + actual sections contents plus one is passed, leading to miscalculating + the end of the buffer. + + * elf-attrs.c (bfd_elf_parse_attr_section_v1): Delete hdr and + contents param. Add p and p_end as params. + (_bfd_elf_parse_attributes): Adjust to suit. + +2025-03-08 H.J. Lu + + gprof: Compile tst-gmon.c with -O2 -fno-omit-frame-pointer + Compile tst-gmon.c with -O2 -fno-omit-frame-pointer to ensure proper call + graph generation. + + PR gprof/32768 + * configure.ac: Compile tst-gmon.c with -fno-omit-frame-pointer. + * configure: Regenerated. + * testsuite/Makefile.am (GPROF_FLAGS): Add -O2 + -fno-omit-frame-pointer. + (AM_CFLAGS): Removed. + (COMPILE): Append $(GPROF_FLAGS). + (LINK): Likewise. + * testsuite/Makefile.in: Regenerated. + +2025-03-08 Tom de Vries + + [gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32 for AMD + When running test-case gdb.base/step-over-syscall.exp with target board + unix/-m32 on an AMD processor, I run into: + ... + (gdb) x/2i $pc^M + => 0xf7fc9575 <__kernel_vsyscall+5>: syscall^M + 0xf7fc9577 <__kernel_vsyscall+7>: int $0x80^M + (gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction + stepi^M + [Detaching after fork from child process 65650]^M + 0xf7fc9579 in __kernel_vsyscall ()^M + 1: x/i $pc^M + => 0xf7fc9579 <__kernel_vsyscall+9>: pop %ebp^M + (gdb) $exp: fork: displaced=off: stepi fork insn + print /x $pc^M + $2 = 0xf7fc9579^M + (gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi + FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall + ... + + The problem is that the syscall returns at the "pop %ebp" insn, while the + test-case expects it to return at the "int $0x80" insn. + + This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite] + Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence + used there used the "sysenter" insn instead of the "syscall" insn. + + Fix this by extending the fix for commit 14852123287 to also handle the + "syscall" insn. + + Tested on x86_64-linux, both using an AMD and Intel processor. + + PR testsuite/32439 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32439 + +2025-03-08 Simon Marchi + + gdb/dwarf: call other cutu_reader constructor in ensure_lang and dw2_get_file_names + PR 32742 shows this failing: + + $ make check TESTS="gdb.ada/access_to_unbounded_array.exp" RUNTESTFLAGS="--target_board=fission" + Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.ada/access_to_unbounded_array.exp ... + FAIL: gdb.ada/access_to_unbounded_array.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:23 (GDB internal error) + + Or, interactively: + + $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.ada/access_to_unbounded_array/foo-all -ex 'b foo.adb:23' -batch + /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19567: internal-error: set_lang: Assertion `old_value == language_unknown || old_value == language_minimal || old_value == lang' failed. + + The symptom is that for a given dwarf2_per_cu, the language gets set + twice. First, set to `language_ada`, and then, to `language_minimal`. + It's unexpected for the language of a CU to get changed like this. + + The CU at offset 0x0 in the main file looks like: + + 0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034) + + 0x0000000b: DW_TAG_compile_unit + DW_AT_low_pc [DW_FORM_addr] (0x000000000000339a) + DW_AT_high_pc [DW_FORM_data8] (0x0000000000000432) + DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000) + DW_AT_GNU_dwo_name [DW_FORM_strp] ("b~foo.dwo") + DW_AT_comp_dir [DW_FORM_strp] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array") + DW_AT_GNU_pubnames [DW_FORM_flag_present] (true) + DW_AT_GNU_addr_base [DW_FORM_sec_offset] (0x00000000) + DW_AT_GNU_dwo_id [DW_FORM_data8] (0x277aee54e7bd47f7) + + This refers to the DWO file b~foo.dwo, whose top-level DIE is: + + .debug_info.dwo contents: + 0x00000000: Compile Unit: length = 0x00000b63, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000b67) + + 0x0000000b: DW_TAG_compile_unit + DW_AT_producer [DW_FORM_GNU_str_index] ("GNU Ada 14.2.1 20250207 -fgnat-encodings=minimal -gdwarf-4 -fdebug-types-section -fuse-ld=gold -gnatA -gnatWb -gnatiw -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -gnatws -mtune=generic -march=x86-64") + DW_AT_language [DW_FORM_data1] (DW_LANG_Ada95) + DW_AT_name [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array/b~foo.adb") + DW_AT_comp_dir [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array") + DW_AT_GNU_dwo_id [DW_FORM_data8] (0xdbeffefab180a2cb) + + The thing to note is that the language attribute is only present in the + DIE in the DWO file, not on the DIE in the main file. + + The first time the language gets set is here: + + #0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_ada, dw_lang=DW_LANG_Ada95) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788 + #1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff10bf2b0, cu=0x51700008e000, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029 + #2 0x000055556159f740 in cutu_reader::cutu_reader (this=0x7ffff10bf2b0, this_cu=0x50f0000044b0, per_objfile=0x516000066080, abbrev_table=0x510000004640, existing_cu=0x0, skip_partial=false, pretend_language=language_minimal, cache=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3371 + #3 0x00005555615a547a in process_psymtab_comp_unit (this_cu=0x50f0000044b0, per_objfile=0x516000066080, storage=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3799 + #4 0x00005555615a9292 in cooked_index_worker_debug_info::process_cus (this=0x51700008dc80, task_number=0, first=std::unique_ptr = {...}, end=std::unique_ptr = {...}) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4122 + + In this code path (particularly this specific cutu_reader constructir), + the work is done to find and read the DWO file. So the language is + properly identifier as language_ada, all good so far. + + The second time the language gets set is: + + #0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_minimal, dw_lang=0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788 + #1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff0f42730, cu=0x517000091b80, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029 + #2 0x00005555615a1822 in cutu_reader::cutu_reader (this=0x7ffff0f42730, this_cu=0x50f0000044b0, per_objfile=0x516000066080, pretend_language=language_minimal, parent_cu=0x0, dwo_file=0x0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3464 + #3 0x000055556158c850 in dw2_get_file_names (this_cu=0x50f0000044b0, per_objfile=0x516000066080) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1956 + #4 0x000055556158f4f5 in dw_expand_symtabs_matching_file_matcher (per_objfile=0x516000066080, file_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2157 + #5 0x00005555616329e2 in cooked_index_functions::expand_symtabs_matching (this=0x50200002ab50, objfile=0x516000065780, file_matcher=..., lookup_name=0x0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=..., lang_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:15912 + #6 0x0000555562ca8a14 in objfile::map_symtabs_matching_filename (this=0x516000065780, name=0x50200002ad90 "break pck.adb", real_path=0x0, callback=...) at /home/smarchi/src/binutils-gdb/gdb/symfile-debug.c:207 + #7 0x0000555562d68775 in iterate_over_symtabs (pspace=0x513000005600, name=0x50200002ad90 "break pck.adb", callback=...) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:727 + + Here, we use the other cutu_reader constructor, the one that does not + look up the DWO file for the passed CU. If a DWO file exists for this + CU, the caller is expected to pass it as a parameter. That cutu_reader + constructor also ends up setting the language of the CU. But because it + didn't read the DWO file, it didn't figure out the language is + language_ada, so it tries to set the language to the default, + language_minimal. + + A question is: why do we end up trying to set the CU's language is this + context. This is completely unrelated to what we're trying to do, that + is get the file names from the line table. Setting the language is a + side-effect of just constructing a cutu_reader, which we need to look up + attributes in dw2_get_file_names_reader. There are probably some + cleanups to be done here, to avoid doing useless work like looking up + and setting the CU's language when all we need is an object to help + reading the DIEs and attributes. But that is future work. + + The same cutu_reader constructor is used in + `dwarf2_per_cu::ensure_lang`. Since this is the version of cutu_reader + that does not look up the DWO file, it will conclude that the language + is language_minimal and set that as the CU's language. In other words, + `dwarf2_per_cu::ensure_lang` will get the language wrong, pretty ironic. + + Fix this by using the other cutu_reader constructor in those two spots. + Pass `per_objfile->get_cu (this_cu)`, as the `existing_cu` parameter. I + think this is necessary, because that constructor has an assert to check + that if `existing_cu` is nullptr, then there must not be an existing + `dwarf2_cu` in the per_objfile. + + To avoid getting things wrong like this, I think that the second + cutu_reader constructor should be reserved for the spots that do pass a + non-nullptr dwo_file. The only spot at the moment in + create_cus_hash_table, where we read multiple units from the same DWO + file. In this context, I guess it makes sense for efficiency to get the + dwo_file once and pass it down to cutu_reader. For that constructor, + make the parameters non-optional, add "non-nullptr" asserts, and update + the code to assume the passed values are not nullptr. + + What I don't know is if this change is problematic thread-wise, if the + functions I have modified to use the other cutu_reader constructor can + be called concurrently in worker threads. If so, I think it would be + problematic. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32742 + Change-Id: I980d16875b9a43ab90e251504714d0d41165c7c8 + Approved-By: Tom Tromey + +2025-03-08 Tom Tromey + + Avoid excessive CU expansion on failed matches + PR symtab/31010 points out that something like "ptype INT" will expand + all CUs in a typical program. The OP further points out that the + original patch for PR symtab/30520: + + https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html + + ... did solve the problem, but the patch changed after (my) review and + reintroduced the bug. + + In cooked_index_functions::expand_symtabs_matching, the final + component of a split name is compared with the entry's name using the + usual method of calling get_symbol_name_matcher. + + This code iterates over languages and tries to split the original name + according to each style. But, the Ada splitter uses the decoded name + -- "int". This causes every C or C++ CU to be expanded. + + Clearly this is wrong. And, it seems to me that looping over + languages and trying to guess the splitting style for the input text + is probably bad. However, fixing the problem is not so easy (again + due to Ada). I've filed a follow-up bug, PR symtab/32733, for this. + + Meanwhile, this patch changes the code to be closer to the + originally-submitted patch. This works because the comparison is now + done between the full name and the "lookup_name_without_params" + object, which is a less adulterated variant of the original input. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010 + Tested-By: Simon Marchi + +2025-03-08 Tom Tromey + + Use wild matching for lookup_name_info::match_any + Currently, lookup_name_info::match_any symbol_name_match_type::FULL. + However, this seems wrong. Consider the expand_symtabs_matching + implementation of the cooked index: it compares name components, and + then if all the components match, it checks: + + if ((match_type == symbol_name_match_type::FULL + || (lang != language_ada + && match_type == symbol_name_match_type::EXPRESSION))) + { + if (parent != nullptr) + continue; + + That is, if the component-matching loop did not finish, and a full + match is requested, then fail to match. This handles cases where the + index is asked to look up "b::c" but finds "a::b::c". + + However, match_any should match, well, any. So, it seems to me that + checking any parent matches is irrelevant -- and therefore this should + use wild matching. + +2025-03-08 GDB Administrator + + Automatic date update in version.in + +2025-03-07 Tom Tromey + + Handle ">>" in cp-name-parser.y + I noticed that a certain name didn't work correctly when trying to + remove the parameters. I put this into lookup_name_info-selftests.c. + + I tracked this down to the fact that cp-name-parser.y doesn't handle + ">>" to end templates. This patch fixes this in a simple way -- + accepting the "RSH" token where appropriate and then un-pushing a ">". + +2025-03-07 Tom Tromey + + Minor cleanups to cpname_state + This changes cpname_state to have a constructor and some inline + initializers. + +2025-03-07 Simon Marchi + + gdb/dwarf: move cooked_indexer to cooked-indexer.{h,c} + Move the cooked_indexer class declaration to a new cooked-indexer.h + file, and the implementation to cooked-indexer.c. + + Change-Id: Ibff3b06045b2af65fa9516097acf732d7c2d9414 + Approved-By: Tom Tromey + +2025-03-07 Simon Marchi + + gdb/dwarf: move cooked_index_storage to cooked-index-storage.{h,c} + cooked_index_storage is currently declared in `cooked-index.h` and + implemented in `read.c`. Move all that to new + `cooked-index-storage.{h,c}` files. + + Change-Id: I2a07eb446d8a07b15c5664dfe01e3a820cdd45be + Approved-By: Tom Tromey + +2025-03-07 Simon Marchi + + gdb/dwarf: move cutu_reader to read.h + In order to move some things outside of read.c, cutu_reader needs to be + in a header file. + + Change-Id: Ib26d7949c55867848d109332caf2efb1a6e72923 + Approved-By: Tom Tromey + +2025-03-07 Georg-Johann Lay + + AVR: gas/32704 - Improve code generation for __gcc_isr. + The prologue generated by __gcc_isr can be improved in + situations where: + + * ZERO_REG is needed, and + * SREG is not clobbered by the ISR, and + * avr-gcc provides a GPR >= R16 with the Done chunk, and + * Code generation is for ordinary AVRs (not AVRrc). + + For example, the prologue for + + volatile char var; + + __attribute__((signal)) void __vector_1 (void) + { + var = 1; + var = 0; + } + + may be + + 00000000 <__vector_1>: + 0: 8f 93 push r24 + 2: 1f 92 push r1 + 4: 80 e0 ldi r24, 0 + 6: 18 2e mov r1, r24 + + instead of the code as currently generated by GAS: + + 00000000 <__vector_1>: + 0: 1f 92 push r1 + 2: 1f b6 in r1, SREG + 4: 1f 92 push r1 + 6: 11 24 clr r1 + 8: 8f 93 push r24 + + which consumes more stack, time and code than needed. + + gas/ + PR gas/32704 + PR gas/21683 + * config/tc-avr.c (avr_isr): bool-ize. + (avr_emit_insn): Emit "mov" code as MOV R1,. + (avr_isr_stack_t): New typedef. + (avr_emit_push, avr_emit_pop): New static functions. + (avr_patch_gccisr_frag): Overhaul prologue and epilogue + generation. + +2025-03-07 Nick Clifton + + Fix imm20 range check in MSP430 port of gas + +2025-03-07 Jan Beulich + + gas: don't permit "repeat" expressions with .cfi_{escape,fde_data} + Repeat counts greater than 1 will emit data directly into the current + (sub-)section. That's wrong with .cfi_*, which defer data emission until + much later: N-1 instances of the specified data would not end up in + .eh_frame (or whatever the section that CFI data was specified to go + into). Simply disallow "repeat" expressions in such cases. + + gas/listing: drop forward declarations + These aren't needed (anymore); all static functions are defined before + their first use. + + gas: centralize declaration of listing_tail + Besides it being somewhat off to have three decls scattered across the + code base, it is generally bad practice for the definition of a symbol + to not also observe its declaration (making sure the two won't go out of + sync). + + objdump: permit disassembling multiple individual functions + Compilers may split functions, e.g. into a "hot" and "cold" part, or + they may emit special case instantiations (e.g. as a result of IPA). It + can be helpful to be able to disassemble all of the parts or clones in + one go. Permit using "--disassemble=" multiple times. + + objdump: properly disassemble successive functions of the same name + ... when only their symbol was requested for disassembly. Addressing the + respective FIXME is as easy as coverting the "else" there to an if() + with the opposite condition, thus accounting for the disabling the + original if() may have effected. + +2025-03-07 Jan-Benedict Glaw + + Fix missing int argument warning + This warning (per -Werror) breaks the build using a recent GCC + with recent userland. + + Approved-By: Tom Tromey + +2025-03-07 Tom de Vries + + [gdb/tdep] Support REX2 and EVEX prefix + The following amd64 insn: + ... + 0: 67 d5 44 8d 3d 00 00 00 00 lea 0x0(%eip),%r31d + ... + uses the REX2 prefix [1], which is currently not supported in + amd64_get_insn_details. + + Add the missing support in amd64_get_insn_details, as well as a corresponding + unit test. + + Likewise for an amd64 insn using an EVEX prefix [2]: + ... + 0: 62 f1 7c 48 28 05 00 fc ff ff vmovaps -0x400(%rip),%zmm0 + ... + + Tested on x86_64-linux. + + PR tdep/32725 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32725 + + [1] https://en.wikipedia.org/wiki/VEX_prefix + [2] https://en.wikipedia.org/wiki/EVEX_prefix + +2025-03-07 Tom de Vries + + [gdb/tdep] Fix vmovdqu decoding + PR tdep/31952 reports that displaced stepping over an instruction pointer + relative insn "vmovdqu 0x20(%rip),%ymm1" gives the wrong results. + + This is caused by misclassification of the insn in amd64_get_insn_details, + which results in details.modrm_offset == -1, while the instruction in fact + does have a modrm byte. + + The instruction is encoded as follows: + ... + 400557: c5 fe 6f 0d 20 00 00 00 vmovdqu 0x20(%rip),%ymm1 + ... + where: + - "0xc5 0xfe" is the vex2 prefix, + - "0x6f" is the opcode, + - "0x0d" is the modrm byte, and + - "0x20 0x00 0x00 0x00" is a 32-bit displacement. + + The problem is related to details.opcode_len, which is 1. + + While it is true that the length of the opcode in the insn (0x6f) is 1 byte, + the vex2 prefix implies that we're encoding an 2-byte opcode beginnning + with 0x0f [1]. + + Consequently, we should be using the twobyte_has_modrm map rather than the + onebyte_has_modrm map. + + Fix this in amd64_get_insn_details, and add a selftest to check this. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31952 + + [1] https://en.wikipedia.org/wiki/VEX_prefix + +2025-03-07 Tom de Vries + + [gdb/tdep] Make amd64_get_insn_details more regular + In amd64_get_insn_details, I found this code with a comment explaining why + enc_prefix_offset is not set: + ... + else if (vex2_prefix_p (*insn)) + { + /* Don't record the offset in this case because this prefix has + no REX.B equivalent. */ + insn += 2; + } + ... + which I didn't understand until I looked at the only use of enc_prefix_offset, + in fixup_riprel: + ... + /* REX.B should be unset (VEX.!B set) as we were using rip-relative + addressing, but ensure it's unset (set for VEX) anyway, tmp_regno + is not r8-r15. */ + if (insn_details->enc_prefix_offset != -1) + { + gdb_byte *pfx = &dsc->insn_buf[insn_details->enc_prefix_offset]; + if (rex_prefix_p (pfx[0])) + pfx[0] &= ~REX_B; + else if (vex3_prefix_p (pfx[0])) + pfx[1] |= VEX3_NOT_B; + else + gdb_assert_not_reached ("unhandled prefix"); + } + ... + + Fix this by: + - setting enc_prefix_offset for the vex2 case in amd64_get_insn_details, + making the function more regular and easier to understand, and + - handling the vex2 case in the "enc_prefix_offset != -1" clause in + fixup_riprel. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Add vzeroupper and vzeroall in amd64-insn-decode selftest + After I posted a tentative patch for PR31952, Alexander Monakov pointed out + that the patch broke instruction decoding for instructions vzeroall and + vzeroupper. + + Add selftests for these two instructions in amd64-insn-decode, both using + vex2 and vex3 prefixes. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Add vex2_to_vex3 + I noticed here [1] that the vex2 prefix is essentially a special case of the + vex3 prefix, meaning it's possible to rewrite any insn with a vex2 prefix into + an equivalent one with a vex3 prefix. + + Add function vex2_to_vex3 that does precisely that, in the selftests + namespace. + + Add a selftest that exercises this function. + + Tested on x86_64-linux. + + [1] https://en.wikipedia.org/wiki/VEX_prefix + +2025-03-07 Tom de Vries + + [gdb/tdep] Factor out part of fixup_riprel + Factor out the part of fixup_riprel that patches the insn, and use it in a + unit test. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Fix rip-relative insn handling in amd64_get_used_input_int_reg + I wanted to add a unit test for an an rip-relative amd64 insn, so I did: + ... + $ gcc -fPIE hello.c + ... + and used an rip-relative insn from main: + ... + 4005db: 48 8d 3d 1e 00 00 00 lea 0x1e(%rip),%rdi + ... + + While writing the unit test, I found that amd64_get_used_input_int_reg returns + rbp as input register. + + Fix this by using rip_relative_p in amd64_get_used_input_int_reg to handle + this case. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Factor out rip_relative_p + Factor out rip_relative_p, and rewrite it to use MODRM_MOD_FIELD and + MODRM_RM_FIELD. + + No functional changes. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Add amd64-insn-decode selftest + Add a selftest that checks the results of amd64_get_insn_details and related + functions for two basic instructions. + + Add a parameter assumptions to amd64_get_used_input_int_regs, to make sure + that this selftest: + ... + /* INSN: add %eax,(%rcx). */ + ... + SELF_CHECK (amd64_get_used_input_int_regs (&details, false) + == ((1 << EAX_REG_NUM) | (1 << ECX_REG_NUM))); + ... + passes because it found the "%eax" in the insn, rather than passing because of + this assumption: + ... + /* Assume RAX is used. If not, we'd have to detect opcodes that implicitly + use RAX. */ + used_regs_mask |= 1 << EAX_REG_NUM; + ... + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Factor out amd64_get_used_input_int_regs + The function amd64_get_unused_input_int_reg consists of two parts: + - finding the used int registers in an insn, and + - picking an unused int register. + + Factor out the first part as new function amd64_get_used_input_int_regs. + + No functional changes. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 3 + While reading amd64_get_unused_input_int_reg, I noticed that it avoids picking + RSP, which has to do with how the result of the only call to it is going to be + used. + + Likewise for picking a register in the RAX ... RDI range. + + Fix this by: + - adding an allowed_regs_mask parameter to amd64_get_unused_input_int_reg, and + - properly documenting the value of the corresponding argument in fixup_riprel. + + No functional changes. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 2 + I noticed that amd64_get_unused_input_int_reg uses a signed int for a bit + mask: + ... + /* 1 bit for each reg */ + int used_regs_mask = 0; + ... + + There's an assert: + ... + gdb_assert (used_regs_mask < 256); + ... + which is meant to assert on register numbers >= 8, but if for instance + sizeof (used_regs_mask) == 4 and used_regs_mask == (1 << 31), then that is not + caught because of the signedness. + + We could fix this by changing the type to unsigned int, but that only + guarantees 16 bits in the reg mask. Intel CPUs with the APX extension support + 32 int registers. + + The implementation of amd64_get_unused_input_int_reg doesn't support analyzing + registers with register number >= 8 yet, but now that we're changing the type, + it seems like a good idea to anticipate this. + + Fix this by using uint32_t. + + Likewise, update the loop over the reg mask: + ... + for (i = 0; i < 8; ++i) + { + if (! (used_regs_mask & (1 << i))) + return i; + ... + to handle any used_regs_mask value rather than just those for + register number < 8. + + Tested on x86_64-linux. + +2025-03-07 Tom de Vries + + [gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 1 + While reading amd64_get_unused_input_int_reg, I noticed that it first asserts, + then throws an internal_error if no unused register can be found. + + Looking at the documentation of gdbarch_displaced_step_copy_insn, it seems + that a failure can be indicated less abruptly, by returning a nullptr. + + Fix this by: + - returning -1 in case of failure to find an unused register in + amd64_get_unused_input_int_reg, and + - propagating this to amd64_displaced_step_copy_insn. + + Tested on x86_64-linux. + +2025-03-07 Jan Beulich + + gas: leave expression symbols alone when processing equates + PR gas/32721 + In this bogus piece of code distilled from fuzzing and slightly edited: + + A=%eax|%! + Y=A + Z=A + or $6,Z + + the first of the equates with A on the rhs changes A's section (due to + the use of S_GET_VALUE()), from expression to register, thus yielding Y + in the expression section (and X_op being O_symbol), but Z in the + register section (and X_op being O_register with X_add_value being -1). + There shouldn't be random O_register expressions, though, for targets + setting md_register_arithmetic to false. Plus both Y and Z would better + be exchangeable. + + In pseudo_set() wire handling of O_symbol expressions referencing a + symbol in the expression section to that of other stuff ending up in + this section. + + Also avoid bogus O_register expressions to be created, for targets + setting md_register_arithmetic to false: S_GET_VALUE() would resolve + any arithmetic, which must not happen for such targets. To be on the + safe side for such targets, also amend resolve_register(). Correct + another earlier oversight there too (affecting at least Z80), by using + the new expr_copy() helper there as well. + + Undo 46b9f07dfe79 ("PR 32721, internal error in + tc-i386.c:parse_register"), albeit without losing the simplification it + did. + +2025-03-07 Jan Beulich + + v850: improve linker scripts for relocatable linking + Quite a few constructs where unconditional when they should take + $RELOCATING into account. The original observation was that output of + "ld -r" had .text start at 0x00100000. + +2025-03-07 Jan Beulich + + gas: fold is_end_of_line[] into lex_type[] + ... by way of introducing LEX_EOL and LEX_EOS. As a prereq convert the + remaining open-coded accesses. + + The Alpha change is actually a functional one: The array slot for '!' + having been set to 1 is very unlikely to have been correct. 1 means "end + of line", when surely "end of statement" was always meant. + +2025-03-07 Jan Beulich + + include: drop bout.h + gas'es obj-bout.c was dropped about 20 years ago, while bfd's bout.c was + dropped almost 7 years ago. Time for the unused header to go away, too. + + rl78: drop redundant statement separator check + With the switch to the use of is_end_of_stmt() in 2dd0370c433d + ("rl78: use is_whitespace()") the open-coded checking against + line_separator_chars[] can be dropped. + + Z8k: use is_end_of_stmt() + ... instead of open-coding it. + + x86: use is_end_of_stmt() + ... instead of open-coding it. + + VAX: use is_end_of_stmt() + ... instead of open-coding it. This also fixes two array underrun + issues, when plain char is a signed type. + + TILEPro: use is_end_of_stmt() + ... instead of open-coding it. Also convert a variable to plain char + (allowing to drop two casts), which is how it's actually used. + + Tile-Gx: use is_end_of_stmt() + ... instead of open-coding it. Also convert a variable to plain char + (allowing to drop two casts), which is how it's actually used. + + C6x: use is_end_of_stmt() + ... instead of open-coding it. + +2025-03-07 Jan Beulich + + C54x: use is_end_of_stmt() + ... instead of open-coding it. + + In tic54x_stringer() this also fixes an array overrun issue: Converting + plain char to unsigned int could have yielded huge values when plain + char is a signed type. + + In subsym_substitute() also convert a local variable to plain char, as + that's what it's really holding (and how it's used everywhere else). + +2025-03-07 Jan Beulich + + C4x: use is_end_of_stmt() + ... instead of open-coding it. + + C30: use is_end_of_stmt() + ... instead of open-coding it. + + Sparc: use is_end_of_stmt() + ... instead of open-coding it. This also fixes two array underrun + issues, when plain char is a signed type. + + SH: use is_end_of_stmt() + ... instead of open-coding it. + + Score: use is_end_of_stmt() + ... instead of open-coding it. + + RISC-V: use is_end_of_stmt() + ... instead of open-coding it. + + pru: use is_end_of_stmt() + ... instead of open-coding it. + + PPC: use is_end_of_stmt() + ... instead of open-coding it. + + MMIX: use is_end_of_stmt() + ... instead of open-coding it. + + MIPS: use is_end_of_stmt() + ... instead of open-coding it. + + MicroBlaze: use is_end_of_stmt() + ... instead of open-coding it. + + M68k: use is_end_of_stmt() + ... instead of open-coding it. + + M68HC1x: use is_end_of_stmt() + ... instead of open-coding it. With this there's no need for op_end (and + hence op_start) to be other than pointer to plain char. Which in turn + eliminates the need for several questionable casts. + + IQ2000: use is_end_of_stmt() + ... instead of open-coding it. + + LoongArch: use is_end_of_stmt() + ... instead of open-coding it. + + HP-PA: use is_end_of_stmt() + ... instead of open-coding it. + + dlx: use is_end_of_stmt() + ... instead of open-coding it. + + C-Sky: use is_end_of_stmt() + ... instead of open-coding it. + + cris: use is_end_of_stmt() + Fix use of is_end_of_line[] directly instead of through the + is_end_of_stmt() macro. + + aarch64: use is_end_of_stmt() + ... instead of open-coding it. + + Arm: use is_end_of_stmt() + ... instead of open-coding it. This also fixes an array underrun issue: + The wrong casting to plain int could have yielded negative values when + plain char is a signed type. + + Alpha: use is_end_of_stmt() + ... instead of open-coding it. Note that writes to the array need to be + left alone; they can only be converted when the array is folded into + lex_type[]. + + Mach-O: use is_end_of_stmt() + ... instead of open-coding it. + + ELF: use is_end_of_stmt() + ... instead of open-coding it. + + {,E}COFF: use is_end_of_stmt() + ... instead of open-coding it. Convert a variable's type to plain char + then as well, as that's what it's really holding (and how it's used + everywhere else). + +2025-03-07 H.J. Lu + + gprof: Update PR gprof/32764 test + 1. Remove gmon.out first before generating it in the configure check. + 2. Make tst-gmon-gprof.out depend on the gprof binary. + 3. Check that gmon.out is non-empty. + 4. Don't include in tst-gmon.c. + + PR gprof/32764 + * configure.ac: Remove gmon.out first. + * configure: Regenerated. + * testsuite/Makefile.am (tst-gmon-gprof.out): Depend on + $(GPROF). + * testsuite/Makefile.in: Regenerated. + * testsuite/tst-gmon-gprof.sh: Check that gmon.out is non-empty. + * testsuite/tst-gmon.c: Don't include . + +2025-03-07 Nelson Chu + + RISC-V: Go PLT for CALL/JUMP/RVC_JUMP if `h->plt.offset' isn't -1 + I got an request about the undefined behaviors, considering the following case, + + $ cat test.c + void main () + { + foo(); + } + $ cat lib.h + void foo(void); + $ riscv64-unknown-linux-gnu-gcc test.c + riscv64-unknown-linux-gnu/bin/ld: /tmp/ccRO8fJl.o: in function `main': + test.c:(.text+0x8): undefined reference to `foo' + collect2: error: ld returned 1 exit status + $ riscv64-unknown-linux-gnu-gcc test.c -Wl,--unresolved-symbols=ignore-in-object-files + $ qemu-riscv64 a.out + Segmentation fault (core dumped) + + Testing with x86 and aarch64, they won't get the segfault since they go plt + for the undefined foo symbol. So, after applying this patch, I can get the + following too, + + $ qemu-riscv64 a.out + a.out: symbol lookup error: a.out: undefined symbol: foo + + The change of this patch should only affect the call behavior, which refer + to an undefined (weak) symbol, when building an dynamic executable. I think + the pic/pie behavior won't be affected as usual. + +2025-03-07 H.J. Lu + + gprof: Copy a simple test from glibc + Copy a simple gprof test from glibc to test the basic gprof functionality. + + 1. Tested natively on Linux/x86-64 and Linux/i686. + 2. Tested for the x86_64-solaris cross target without cross-compiler. + 3. Tested for the aarch64-linux-gnu cross target with cross-compiler. + + PR gprof/32764 + * Makefile.am (SUBDIRS): Add testsuite + * configure.ac (AC_CONFIG_FILES): Removed. + (AC_OUTPUT): Add Makefile testsuite/Makefile + po/Makefile.in:po/Make-in. + (AM_CONDITIONAL): Add NATIVE. + * Makefile.in: Regenerated. + * configure: Likewise. + * testsuite/Makefile.am: New file. + * testsuite/tst-gmon-gprof.sh: Likewise. + * testsuite/tst-gmon.c: Likewise. + * testsuite/Makefile.in: Generated. + +2025-03-07 GDB Administrator + + Automatic date update in version.in + +2025-03-06 Alan Modra + + Re: ld: Add a test for PR ld/25237 + Delete the test. It doesn't make sense to check a linker hack for + a meaningless p_offset. + +2025-03-06 Tom de Vries + + [gdb] Fix typos in NEWS + Fix typos: + ... + mainenance ==> maintenance + epilgoue ==> epilogue + commnds ==> commands + readibility ==> readability + informations ==> information + throwed ==> threw + compiletime ==> compile time + namepace ==> namespace + reqired ==> required + explicity ==> explicitly + reqired ==> required + ... + + [gdb/python] Fix typos + Fix typos: + ... + gdb/python/py-framefilter.c:749: indention ==> indentation + gdb/python/py-framefilter.c:837: indention ==> indentation + gdb/python/py-lazy-string.c:35: sting ==> string + gdb/python/py-progspace.c:119: Retun ==> Return + gdb/python/py-progspace.c:139: Retun ==> Return + ... + + [gdb/python] Fix typos in lib + Fix typos: + ... + gdb/python/lib/gdb/disassembler.py:84: dissables ==> disables + gdb/python/lib/gdb/command/xmethods.py:40: experession ==> expression + ... + + [gdb/guile] Fix typos + Fix typos: + ... + gdb/guile/scm-lazy-string.c:41: sting ==> string + gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy + ... + + [gdb/doc] Fix typos in gdb.texinfo + Fix typos: + ... + preprend -> prepend + wth -> with + Connnections -> Connections + ... + + [gdb/doc] Fix typos in annotate.texinfo + Fix typos: + ... + Dependant ==> Dependent + ... + + [gdb/doc] Fix typos in python.texi + Fix typos: + ... + atribute ==> attribute + ... + + [gdb/nat] Fix typos + Fix typos: + ... + exising ==> existing + afer ==> after + ... + + [gdb/tui] Fix typos + Fix typos: + ... + gdb/tui/tui.c:64: releated ==> related + gdb/tui/tui-io.c:50: releated ==> related + ... + + [gdb/cli] Fix typos + Fix typos: + ... + gdb/cli/cli-utils.h:85: fuction ==> function + gdb/cli/cli-decode.c:2457: Ambigous ==> Ambiguous + ... + + [gdb] Fix typos in gdbarch_components.py + Fix typos in gdbarch_components.py: + ... + tranformations ==> transformations + charater ==> character + Noe -> Note + ... + and regenerate gdb/gdbarch-gen.h. + +2025-03-06 Tom Tromey + + Update ada_add_block_renamings for compiler changes + With the hierarchical name patches to GNAT, ada_add_block_renamings + must now be updated as well -- the comment there about the supported + forms of DW_TAG_imported_declaration is no longer correct, and now + full names must sometimes be constructed during the lookup process. + +2025-03-06 Tom Tromey + + Add support for hierarchical Ada names + In the near future, GNAT will start emitting DWARF names in a more + standard way -- specifically, the package structure will be indicated + by nested DW_TAG_module DIEs and a given entity will be nested in its + package and only have a simple name. + + This patch changes gdb to understand this style of naming, while still + supporting the existing GNAT output. + + A few special cases are needed. I've commented them. + + The name-computing code for the full DWARF reader is very complicated + -- much too complicated, in my opinion. There are already several + bugs in bugzilla about this (search for "physname"... but there are + others as well), so I haven't filed any new ones. + + When I started this project, I thought it would solve some memory + overuse issues we sometimes see from how the index-sharding code + interacts with the GNAT-specific post-pass. However, to my surprise, + the Ada code in gdb relies on some details of symbol naming, and so + I've had to add code here to synthesize "linkage" names in some cases. + This is unfortunate, but I think can eventually be fixed; I will file + a bug to track this issue. + +2025-03-06 Tom Tromey + + Add "Ada linkage" mode to cooked_index_entry::full_name + Unfortunately, due to some details of how the Ada support in gdb + currently works, the DWARF reader will still have to synthesize some + "full name" entries after the cooked index has been constructed. + + You can see one particular finding related to this in: + + https://sourceware.org/bugzilla/show_bug.cgi?id=32142 + + This patch adds a new flag to cooked_index_entry::full_name to enable + the construction of these names. + + I hope to redo this part of the Ada support eventually, so that this + code can be removed and the full-name entries simply not created. + +2025-03-06 Tom Tromey + + Store new Ada entries in cooked_index_shard::m_entries + handle_gnat_encoded_entry might create synthetic cooked index entries + for Ada packages. These aren't currently kept in m_entries, but it + seems to me that they should be, particularly because a forthcoming + GNAT will emit explicit DW_TAG_module for these names -- with this + change, the indexes will be roughly equivalent regardless of which + compiler was used. + +2025-03-06 Tom Tromey + + Handle DW_TAG_module for Ada + This updates read_module_type to turn DW_TAG_module into a + TYPE_CODE_NAMESPACE when the CU represents Ada code. + + Note that the GNAT that generates this isn't generally available yet + and so this shouldn't have an impact on current code. + +2025-03-06 Tom Tromey + + Add "synthetic" marker for index entries + Currently, gdb will synthesize DW_TAG_module entries for Ada names. + These entries are treated specially by the index writer, + + When GNAT starts emitting DW_TAG_module, the special case will be + incorrect, because there will be non-synthetic DW_TAG_module entries + in the index. + + This patch arranges to mark the synthetic entries and changes the + index writer to follow. + +2025-03-06 Tom Tromey + + Use DW_TAG_module for Ada + In GCC we decided to use DW_TAG_module to represent Ada packages, so + make this same decision in gdb. This also updates tag_matches_domain + to handle this case. + + Use dwarf2_full_name when computing type names + This changes a few spots in the DWARF reader to use dwarf2_full_name + when computing the name of a type. This gives the correct name when a + type is nested in a namespace. This oddity probably wasn't noticed + before because some of the types in question are either normally + anonymous in C++ (e.g, array type) or do not appear in a namespace + (base type). + +2025-03-06 Tom Tromey + + Compare unqualified names in ada_identical_enum_types_p + With the coming changes to GNAT, gdb must compare the unqualified + names of two enum types. + + Currently, GNAT will fully-qualify enumeration constant names, so for + instance one might see "enum_with_gap__lit4" as the name. + + GNAT also may emit a copy of an enumeration type when a newtype is + involved. E.g., in the arr_acc_idx_w_gap.exp test case, this can + occur for the base type of this subtype: + + type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3; + + (Note that the base type of this subrange is anonymous.) + + With some forthcoming changes to GNAT, these names will no longer be + qualified -- and because the newtype is anonymous, they can't be + identically qualified. But, in gdb we still want "lit4" to resolve + without ambiguity in this scenario. + + The fix is to change ada_identical_enum_types_p to compare unqualified + enum names. This will work correctly with both variants of the + compiler, and with -fgnat-encodings=all as well. + +2025-03-06 Tom Tromey + + Use ada_identical_enum_types_p in ada_atr_enum_rep + With the coming changes to GNAT, we may see two distinct but + equivalent enum types in the DWARF. In this case, it's better to use + ada_identical_enum_types_p rather than types_equal when comparing + these types... something that matters when using 'Enum_Rep. + +2025-03-06 Tom Tromey + + Fixes to gdb.ada/fun_overload_menu.exp + This patch applies a few fixes to gdb.ada/fun_overload_menu.exp. + + It adds some comments to the source and uses this to extract line + numbers. This is used to ensure that two otherwise-equivalent results + are in fact different, so that the test really checks that the result + is correct. + + It also changes the test_menu proc to accept a list of possible + results. This lets the test work regardless of the order in which the + menu items are presented by gdb. + + Finally, like an earlier patch, it changes the test to optionally + accept unqualified names from gdb. + +2025-03-06 Tom Tromey + + Allow multiple locations in homonym.exp + With some forthcoming changes to GNAT, the two Get_Value functions in + this test case will end up with the same name (with the current GNAT, + one ends up with a "__2" suffix). This change will cause one test to + set multiple breakpoints; this patch changes the test to work with + either version of the compiler. + +2025-03-06 Tom Tromey + + Fix type name in ptype-o.exp + The "Rec" type in ptype-o.exp is currently named "prog__rec" by the + compiler. However, with my changes to GNAT, the type will no longer + have a prefix, as it is local to a procedure. + + Changing this to just use "rec" works fine with the new compiler, but + then fails with older compilers. To allow correct operation with both + compilers, this patch simply moves the type into a new package. This + doesn't affect the meaning of the test, which is just ensuring that + ptype/o works in a certain case. + + Note that the more obvious fix of just using "ptype/o rec" does not + work with the current GNAT. I haven't investigated this but I did + file a bug to track it: + + https://sourceware.org/bugzilla/show_bug.cgi?id=32169 + +2025-03-06 Tom Tromey + + Allow unqualified names in Ada tests + Currently, when a type is declared in a subprogram that isn't part of + a package, gdb will give this type a qualified name. E.g., in the + program for gdb.ada/arr_arr.exp: + + procedure Foo is + type Array2_First is array (24 .. 26) of Integer; + + gdb will name this type 'foo.array2_first'. + + However, with some coming changes to GNAT (and with the remainder of + this series applied as well), this will no longer happen. Instead, + such types will be given their local name. IMO this makes more sense + anyway. + + This patch updates most of the Ada tests to allow either form in the + spots where it matters. Both are accepted so that the tests continue + to work with older versions of GNAT. (A few tests are handled in + separate patches; this patch only contains the straightforward + changes.) + +2025-03-06 Tom Tromey + + Fix latent crash in ada_variant_discrim_name + ada_variant_discrim_name does this: + + for (discrim_end = name + strlen (name) - 6; discrim_end != name; + + If NAME is too short, this will construct an invalid pointer, perhaps + causing a crash. + + This patch arranges to check the length first. + +2025-03-06 Tom Tromey + + Allow for anonymous Ada enumeration types + With some forthcoming changes to GNAT, gdb might see a nameless enum + in ada_resolve_enum, causing a crash. This patch allows an anonymous + enum type to be considered identical to a named type when the contents + are identical. + +2025-03-06 Tom Tromey + + Add a quit to maint_print_all_sections + If you have many sections, "maint print sections" can take a very long + time (due to a bug). If you happen to "c" at the pagination prompt, + this can't be interrupted. This patch adds a QUIT to the loop to at + least allow interruption. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758 + Reviewed-By: Guinevere Larsen + +2025-03-06 Tom de Vries + + [gdbserver] Drop abbreviations in gdbserver/xtensa-xtregs.cc + In gdbserver/xtensa-xtregs.cc, there's a table: + ... + const xtensa_regtable_t xtensa_regmap_table[] = { + /* gnum,gofs,cpofs,ofs,siz,cp, dbnum, name */ + { 44, 176, 0, 0, 4, -1, 0x020c, "scompare1" }, + { 0 } + }; + ... + on which codespell triggers: + ... + $ codespell --config ./gdbserver/setup.cfg gdbserver + gdbserver/xtensa-xtregs.cc:34: siz ==> size, six + ... + + Fix this by laying out the table in vertical fashion, and using the full field + names instead of the abbreviations ("size" instead of "siz", "offset" instead + of "ofs", etc). + + Approved-By: Simon Marchi + +2025-03-06 Tom Tromey + + Use 'const' in some gdbarch methods + This changes a couple of gdbarch methods to use 'const' for an + "asymbol *" parameter. These methods shouldn't be modifying the + underlying symbol in the BFD. + + Approved-By: Simon Marchi + +2025-03-06 Tom de Vries + + [gdbserver] Add codespell section in setup.cfg + Add a codespell section in new config file gdbserver/setup.cfg, similar to the + one in gdbsupport/setup.cfg. + + There's just one item left: + ... + $ codespell --config ./gdbserver/setup.cfg gdbserver + gdbserver/xtensa-xtregs.cc:34: siz ==> size, six + ... + +2025-03-06 Simon Marchi + + gdb/dwarf: remove unnecessary `this->` in read.c + I like using `this->` when it's unclear that the method or field + accessed is within the current class, but when accessing a private + member prefixed with `m_`, it's unnecessary, as the prefix makes it + clear. Remove some instances of it (some coming from the previous + patch, other pre-existing) to de-clutter the code a bit. + + Change-Id: Ia83d0bce51d222fa3ac3d756d50170ec6ed12b94 + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: make all fields of cutu_reader private + Make all fields of cutu_reader private, then add getters for whatever + needs to be accessed outside of cutu_reader. This should help spot + what's used by cutu_reader itself, and what is used by others. + + Change-Id: I71cb73fffa5d70cc9c7fc68bf74db937e84c2db1 + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: pass dwarf2_cu instead of cutu_reader to two functions + These functions don't need to receive a cutu_reader, they only use it to + obtain the contained dwarf2_cu, so change them to accept a dwarf2_cu. + This helps reduce the creep of cutu_reader a little bit. + + Change-Id: Iebb3c4697a4aec638b47423b3ac59077d4fa5090 + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: move a bunch of DIE-reading functions to cutu_reader + With the hope of organizing things better and spotting patterns that + could lead to simplification, move all these functions to be methods of + cutu_reader. At least, this gives a good picture of what the entry + points for DIE and attribute reading are, by looking at what methods are + public. + + Right now, my vague understanding of cutu_reader is that it does 3 + things: + + - it provides means to navigate and read the DIE tree, abstracting + things like whether the real content is in a DWO file or not + - it builds a dwarf2_cu object, for its own use but also for the use of + the caller + - it fills in missing details in the passed in dwarf2_per_cu + + In the future, I'd like to separate those concerns. I think that + cutu_reader could retain the first one of those concerns, while the + other two could be done by other classes or functions, perhaps using + cutu_reader under the hood. + + Change-Id: I04e0d6c864bbc09c7071ac8e9493e1e54c093d68 + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: add empty lines in cutu_reader::read_cutu_die_from_dwo comment + I find it much more readable this way, with one idea per paragraph. + + Change-Id: Ib31b410867c8444e0f3200681881f54f1b8ebea8 + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: make init_cu_die_reader a method of cutu_reader + init_cu_die_reader is only used inside cutu_reader, to initialize fields + of cutu_reader, so make it a private method. + + Change-Id: Iaa80d4dbb8d0fa35bcac18ee70e147276874cc1b + Approved-By: Tom Tromey + +2025-03-06 Simon Marchi + + gdb/dwarf: make read_cutu_die_from_dwo a method of cutu_reader + read_cutu_die_from_dwo is only used as a helper to cutu_reader, so make + it a private method of cutu_reader. + + Remove the "result_reader" parameter, because it's always "this". + + Change-Id: I7df6162137451c160f0e6bf3539569fcb2421eff + Approved-By: Tom Tromey + +2025-03-06 Tom de Vries + + [gdbsupport] Add codespell section in setup.cfg + When running codespell on gdbsupport, we get: + ... + $ codespell gdbsupport + gdbsupport/common-debug.h:218: invokable ==> invocable + gdbsupport/osabi.h:51: configury ==> configurable + gdbsupport/ChangeLog-2020-2021:344: ro ==> to, row, rob, rod, roe, rot + gdbsupport/ChangeLog-2020-2021:356: contaning ==> containing + gdbsupport/common.m4:19: configury ==> configurable + gdbsupport/Makefile.am:97: configury ==> configurable + gdbsupport/Makefile.in:811: configury ==> configurable + gdbsupport/event-loop.cc:84: useable ==> usable + gdbsupport/configure:15904: assigment ==> assignment + ... + + Some of these files we want to skip in a spell check, because they're + generated. We also want to skip ChangeLogs, we don't actively maintain those. + + Add a file gdbsupport/setup.cfg with a codespell section, that skips those + files. The choice for setup.cfg (rather than say .codespellrc) comes from the + presence of gdb/setup.cfg. + + That leaves invokable, configury and useable. I think configury is a common + expression in our context, and for invokable and useable I don't manage to + find out whether they really need rewriting, so I'd rather leave them alone + for now. + + Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in + gdbsupport/setup.cfg. + + This makes the directory codespell clean: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport + $ + ... + + Because codespell seems to interpret filenames relative to the working + directory rather than relative to the config file, and the filename used in + gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple + invocation doesn't work: + ... + $ cd gdbsupport + $ codespell + ... + because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt. + + We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but + likewise that breaks this invocation: + ... + $ codespell --config gdbsupport/setup.cfg gdbsupport + ... + + I can't decide which one is worse, so I'm sticking with + gdb/contrib/codespell-ignore-words.txt for now. + + Approved-By: Simon Marchi + +2025-03-06 Simon Marchi + + gdb: remove unnecessary local variable in pager_file::puts + The lineptr variable isn't really necessary, we can just keep using + linebuffer, since the original value is linebuffer isn't needed. Remove + lineptr, and fix some comparisons to be explicit. + + Change-Id: If2f7df43bf79efd40149e46d5c77f9bc0439f879 + Approved-By: Tom Tromey + +2025-03-06 Tom de Vries + + [gdbserver] Fix some typos + Fix typos in gdbserver: + ... + gdbreplay.cc:444: substract ==> subtract + notif.cc:35: Enque ==> Enqueue + notif.cc:42: enque ==> enqueue + i387-fp.cc:233: simplifed ==> simplified + i387-fp.cc:508: simplifed ==> simplified + linux-arc-low.cc:221: shoudn't ==> shouldn't + linux-sparc-low.cc:112: ans ==> and + linux-ppc-low.cc:1134: Followings ==> Following + linux-ppc-low.cc:1160: Followings ==> Following + linux-ppc-low.cc:1193: Followings ==> Following + linux-ppc-low.cc:1226: Followings ==> Following + configure.ac:141: defintions ==> definitions + ... + + Regenerate configure from configure.ac using autoconf. + +2025-03-06 Tom Tromey + + Use "::" as separator for Fortran in cooked index + This teaches cooked_index_entry::full_name that "::" is the separator + for Fortran. I don't know enough Fortran to write a test case for + this. However, a different series I am working on has a regression if + this patch is not applied. + + Approved-By: Simon Marchi + +2025-03-06 Tom Tromey + + Avoid double-decoding in ada_add_global_exceptions + I noticed that ada_add_global_exceptions calls ada_decode on + 'search_name' -- and then passes this to name_matches_regex, which + also calls ada_decode. + + name_matches_regex is also used later, where the result of + 'natural_name ()' is passed to it -- but natural_name also calls + ada_decode. + + So, I think the call to ada_decode in name_matches_regex is redundant. + This patch removes it, and turns name_matches_regex into an inner + function to avoid propagating its use. + + Note that, right now, the DWARF implementation of + expand_symtabs_matching does not in fact pass an encoded name to this + callback. So, this code remains slightly (but currently harmlessly) + wrong. expand_symtabs_matching is fixed by another pending series of + mine. + +2025-03-06 Tom de Vries + + [gdbsupport] Fix some typos + Fix typos: + ... + mentionning -> mentioning + suppported -> supported + aligment -> alignment + ... + + [gdb] Fix typos in some selftests + Fix typos: + ... + figured on out -> figured one out + fpr -> for + hopefuly -> hopefully + ... + +2025-03-06 H.J. Lu + + Revert "gprof: only process line numbers for intersection of vmas and histograms" + This reverts commit b8189cf9e40bd90502c9a2ce0df39dd54419bea4 to fix + PR gprof/32764: + + https://sourceware.org/bugzilla/show_bug.cgi?id=32764 + +2025-03-06 GDB Administrator + + Automatic date update in version.in + +2025-03-05 H.J. Lu + + ld: Update PR ld/25237 test + 1. Skip targets which don't support the .bss section alignment, 1 << 16. + 2. Replace .bss with ".section .bss". + 3. Use ".zero 0xb60000" for targets which pad the section to its alignment. + + PR ld/25237 + * testsuite/ld-elf/pr25237.d: Skip avr-*-* and h8300-*-*. + Update expected segment size to 0xb60000. + * testsuite/ld-elf/pr25237.s: Use ".section .bss" and + ".zero 0xb60000". + +2025-03-05 Guinevere Larsen + + gdb/testsuite: add test for memory requirements of gcore + For a long time, Fedora has been carrying an out-of-tree patch with a + similar test to the one proposed in this patch, that ensures that the + memory requirements don't grow with the inferior's memory. It's been + so long that the context for why this test exists has been lost, but + it looked like it could be interesting for upstream. + + The test runs twice, once with the inferior allocating 4Mb of memory, + and the other allocating 64Mb. My plan was to find the rate at which + things increase based on inferior size, and have that tested to ensure + we're not growing that requirement accidentally, but my testing + actually showed memory requirements going down as the inferior increases, + so instead I just hardcoded that we need less than 2Mb for the command, + and it can be tweaked later if necessary. + + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb: do not handle a NULL linebuffer in pager_file::puts + This patch [1] has shown that different implementations of ui_file::puts + handle a NULL line differently. pager_file::puts handles a NULL + argument gracefully, as a no-op, while other implementations don't and + likely crash. This causes subtle bugs: things will be working until the + current ui_file is suddenly not a pager_file anymore. I think it would + be better to be consistent here, so change pager_file::puts to not + accept a NULL line. + + A regular test run on Linux shows no regression. + + [1] https://inbox.sourceware.org/gdb-patches/edfe6e17-1c20-4a4c-944f-247ff71b6c10@simark.ca/T/#m864aea10de8ca6fa84757971fcbaf3180e2eaefa + + Change-Id: Ieb465c86cd2c42a248cf481cd174c8622ef6724b + Approved-By: Tom Tromey + +2025-03-05 Tom Tromey + + Inconsistent treatment of template parameters in DWARF reader + I noticed that if you hack some clean_restart calls into + paramless.exp, the test will fail. That is, the test currently relies + on the desired CUs already being expanded when trying to set a + breakpoint -- which is clearly a bug, the CU expansion state should + not affect "break". + + I tracked this down to incorrect construction of a lookup_name_info in + cooked_index_functions::expand_symtabs_matching. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510 + Approved-By: Simon Marchi + +2025-03-05 Simon Marchi + + gdb/dwarf: store dwo_file_up in dwo_file_set + Heap-allocated dwo_file objects, stored in dwarf2_per_bfd::dwo_files, + are never freed. They are created in one of the + create_dwo_unit_in_dwp_* or lookup_dwo_cutu functions. I confirmed this + by running: + + $ make check TESTS="gdb.cp/anon-ns.exp" RUNTESTFLAGS="--target_board=fission-dwp" + $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.cp/anon-ns/anon-ns -ex "p main" -ex "file" -batch + + ... and checking the ASan leak report. I also debugged this invocation + of GDB, placed a breakpoint on ~dwo_file, and didn't see any hit. + + Change the dwo_file set to hold dwo_file_up objects. When the + dwarf2_per_bfd object gets destroyed, dwo_file objects will + automatically get destroyed. With this change, I see the related leaks + disappear in the ASan leak report, and my ~dwo_file breakpoint gets hit + when debugging GDB. + + Change-Id: Icb38539c3f9e553f3625c625a00fc63dd6e9f3c5 + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: make dwarf2_per_bfd::dwo_files a gdb::unordered_set + Change the dwarf2_per_bfd::dwo_files htab to a gdb::unordered_set. + + No behavior change expected, except maybe the failure case in + lookup_dwo_cutu. If open_and_init_dwo_file returns nullptr, the + previous code would leave the slot value empty (nullptr). Is this + legit? With the new hash table, the only thing we can do really is not + attempt to insert the nullptr value. + + Change-Id: I63992f388b1197e696ded4ea483634e8ae67fce4 + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: change htabs holding dwo_unit objects to gdb::unordered_set + Change a few occurences of htabs holding `dwo_unit *` values, using + their signature as identity, to gdb::unordered_set. + allocate_dwo_unit_table and allocate_dwp_loaded_cutus_table appeared to + create hash tables with identical behavior, so they both use the same + set type now. + + The only expected change in behavior is that when there are multiple + units with the same signature, we will now keep the unit previously in + the set, rather than overwriting it. But this seems ok, as it's a case + of bad DWARF. + + Also, in the complaint in create_debug_type_hash_table, I think we + previously erroneously printed the same sect_off twice. + + Change-Id: I57739977735ee1fd5c7b754107f5624f0621baa5 + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: remove unused local variable in create_debug_type_hash_table + Change-Id: I40679fbe32a8a1a9cced085532c83f06affc294c + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: remove unnecessary parameters to create_{cus,debug_type}_hash_table + In create_cus_hash_table, we can get the section and hash table from the + dwo_file directly. + + In create_debug_type_hash_table, we can get the hash table from the + dwo_file directly - the section varies. + + Change-Id: I1d5ef49df98fe2620e12b83484b28cd7398f24ae + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: remove die_reader_specs + die_reader_specs is a relic of some past design, today it only serves as + (useless) a base class for cutu_reader. Remove it and move all its + fields to cutu_reader. + + Change-Id: I5d55018eb8c6e0b828ef5d2f6d09b2047d1a5912 + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: remove unnecessary parameter of create_cus_hash_table + We can use `cu->per_objfile` instead of passing down a + dwarf2_per_objfile explicitly. + + Change-Id: Ie1fd93d9e7a74d09b857f1f0909d7441b79ed893 + Approved-By: Tom Tromey + +2025-03-05 Simon Marchi + + gdb/dwarf: remove unnecessary local variable in dw2_get_file_names_reader + It seems like the lh_cu variable is not necessary, we can just use + this_cu. + + Change-Id: Ic2ed6ee82faf1fb5d340cd92dc8ef15434b20cb8 + Approved-By: Tom Tromey + +2025-03-05 Daniel Starke + + gdb: fix null pointer dereference on missing PATH variable + When running "show" with missing PATH variable a null pointer is being + dereferenced in path_info(). + + path_command() correctly checks whether PATH has been set before using it. + It then calls path_info() which retrieves the variable again but fails to + perform the null pointer test on it. As a result, the application crashes with + SIGSEGV on Windows for example. + + Fix this by handling the null pointer case in path_info() accordingly. + + Co-Authored-By: Simon Marchi + Approved-By: Tom Tromey + Change-Id: I41ef10f00802d3163793491454190008e78f5dc1 + +2025-03-05 Tom Tromey + + Create dwarf2/parent-map.c + This creates a new file, dwarf2/parent-map.c, to hold some code + related to parent maps. This helps shrink read.c a bit. + + Approved-By: Simon Marchi + +2025-03-05 Tom Tromey + + Dump debug names index + This changes the .debug_names reader to dump the contents of the + index. This follows what the cooked index does, and also fixes a + couple of test failures when run with the debug-names board: + forward-spec-inter-cu.exp and backward-spec-inter-cu.exp. + + Approved-By: Simon Marchi + +2025-03-05 Nick Clifton + + elfxx-aarch64.c: Replace nested function with a static inline version instead. + +2025-03-05 H.J. Lu + + ld: Add a test for PR ld/25237 + PR ld/25237 + * testsuite/ld-elf/pr25237.d: New file. + * testsuite/ld-elf/pr25237.s: Likewise. + +2025-03-05 H.J. Lu + + ld: Pass -Wl,-z,lazy to compiler for i386 lazy binding tests + Pass -Wl,-z,lazy to compiler for i386 tests which require lazy binding + to support compilers which default to non-lazy binding. + + PR ld/32762 + * testsuite/ld-i386/i386.exp: Pass -Wl,-z,lazy for + "Build ifunc-1a with PIE -z ibtplt" test. + * testsuite/ld-i386/no-plt.exp: Pass -Wl,-z,lazy for + "Build libno-plt-1b.so", "No PLT (dynamic 1a)", + "No PLT (dynamic 1b)", "No PLT (dynamic 1c)", + "No PLT (PIE 1e)", "No PLT (PIE 1f)", "No PLT (PIE 1g)" tests. + +2025-03-05 GDB Administrator + + Automatic date update in version.in + +2025-03-04 Simon Marchi + + gdb/dwarf: pass is_dwz to dwarf2_per_cu constructor + It is always known at construction time whether a dwarf2_per_cu is + built to represent a unit from a dwz file or not, so pass that + information through the constructor. + + Change-Id: I278c1894ed606451aad02e830085190bb724c473 + Approved-By: Tom Tromey + +2025-03-04 Simon Marchi + + gdb/dwarf: make dwarf2_get_dwz_file a method of dwarf2_per_bfd + dwarf2_get_dwz_file looks more or less like a simple getter of + dwarf2_per_bfd::dwz_file, so make it into a method. + + I typically avoid the `get_` prefix for getters, but that would conflict + with the field name here. + + Change-Id: Idd0d5b1bd3813babf438b20aac514b19c77cfc18 + Approved-By: Tom Tromey + +2025-03-04 Simon Marchi + + gdb/dwarf: remove create_cu_from_index_list + I noticed that create_cu_from_index_list is only used in + read-gdb-index.c, so I started by moving it there. But given that this + function is use at only one spot and doesn't do much, I opted to inline + its code in the caller instead. + + Change-Id: Iebe0dc20d345fa70a2f11aa9ff1a04fe26a31407 + Approved-By: Tom Tromey + +2025-03-04 Tom Tromey + + Check whether gnatmake can link with -shared + Currently, gnat-llvm does not ship a shared libgnat. This patch + changes the relevant test to check whether linking with -shared + actually works. + + Check whether gnatmake supports -Og + gnat-llvm does not support the -Og flag. This arranges to check for + this flag before using it. + +2025-03-04 Tom Tromey + + Look for -fgnat-encodings option + gnat-llvm does not support the -fgnat-encodings option, and does not + emit GNAT encodings at all -- it only supports the equivalent of GCC's + "minimal" encodings; which is to say, ordinary DWARF. + + This patch changes gdb to test whether gnatmake supports this flag and + adapt accordingly. foreach_gnat_encoding is changed to pretend that + the "minimal" mode is in effect, as some test examine the mode. + +2025-03-04 Tom Tromey + + Check -fvar-tracking via ada_simple_compile + A couple of Ada tests check whether the C compiler supports + -fvar-tracking. However, this doesn't really work when using + gnat-llvm, because that will invoke clang under the hood. This patch + arranges to check gnatmake instead, which is more robust even when + toolchains are mix-and-matched. + + Introduce ada_simple_compile + This introduces ada_simple_compile, an Ada-specific analog of + gdb_simple_compile. gdb_compile_test is split into two procs to make + this possible. ada_simple_compile isn't used in this patch but will + be by later patches in this series. + + Check for compiler support in scalar_storage.exp + gnat-llvm does not currently handle Scalar_Storage_Order. This patch + changes the scalar_storage.exp test to check the compiler error + messages and report "unsupported" in this case. This way, the test + ought to start working automatically if this feature is added to + gnat-llvm. + +2025-03-04 Matthieu Longo + + refactoring elf_find_and_remove_property + This refactoring focuses primarily on code readability and reuse. + - Use the already defined _bfd_elf_find_property instead of another + raw for-loop. + - Extract _bfd_elf_remove_property out of the function body. + + refactoring _bfd_elf_get_property + - Extract _bfd_elf_find_property and _bfd_elf_insert_property from the + function's body to improve the code readability. + - Export _bfd_elf_find_property's symbol as it will be used in a later + commit. + + refactoring bfd_linear_search_one_with_gnu_property + - remove the definition of the search predicate outside of the for loop. + - change the function's return type to struct to adopt a more functional + coding style. + +2025-03-04 Matthieu Longo + + aarch64: setup_gnu_properties only creates the notes section when none exists + The creation of .note.gnu.property section should not be based on the + presence of GNU properties, but rather on whether this section exits + or not. + However, there is one exception to this: PR23900 [1]. Old linkers were + treating .note.gnu.property as a generic note section, so old objects + might contain properties inside .note instead of .note.gnu.property. In + this case, the section won't be detected but the properties are still + parsed. So the absence of the .note.gnu.property section is necessary + but not enough to create the section. The condition of the creation of + the section has also to include the absence of GNU properties. + + [1] PR23900: https://sourceware.org/bugzilla/show_bug.cgi?id=23900 + +2025-03-04 Matthieu Longo + + clean-up bfd/elf-attrs.c: move specific-code to parse object attributes v1 into a new function + + clean-up bfd: rename functions for object attributes v1 + + clean-up aarch64: move the name of the build attributes section into include/elf/aarch64.h + + clean-up create_obj_attrs_section: comment about .gnu.attributes VS .gnu.build.attributes + + clean-up: move writing of build attributes section into a function + - add obj_build_attributes to struct elf_backend_data similarly sframe. + - new function _bfd_elf_write_section_build_attributes encapsulating the + writing of the build attributes section into a function. + +2025-03-04 Matthieu Longo + + clean-up readelf: simplify and flatten body of process_attributes + - use find_section_by_type() instead of a for-loop. + - reindent the whole function accordingly. + - move declaration of variables nearer from their usage. + - prune else branch by using a goto in the error case. + + diff --git a/binutils/readelf.c b/binutils/readelf.c + index 6d3ec65a8a1..878012da8f0 100644 + --- a/binutils/readelf.c + +++ b/binutils/readelf.c + @@ -19268,42 +19268,32 @@ process_attributes (Filedata * filedata, + unsigned char * (* display_pub_attribute) (unsigned char *, const unsigned char * const), + unsigned char * (* display_proc_gnu_attribute) (unsigned char *, unsigned int, const unsigned char * const)) + { + - Elf_Internal_Shdr * sect; + - unsigned i; + - bool res = true; + - + /* Find the section header so that we get the size. */ + - for (i = 0, sect = filedata->section_headers; + - i < filedata->file_header.e_shnum; + - i++, sect++) + - { + - unsigned char * contents; + - unsigned char * p; + + Elf_Internal_Shdr * sect = find_section_by_type (filedata, proc_type); + + if (sect == NULL) + + sect = find_section_by_type (filedata, SHT_GNU_ATTRIBUTES); + + - if (sect->sh_type != proc_type && sect->sh_type != SHT_GNU_ATTRIBUTES) + - continue; + + if (sect == NULL) + + /* No section, exit without error. */ + + return true; + + - contents = (unsigned char *) get_data (NULL, filedata, sect->sh_offset, 1, + - sect->sh_size, _("attributes")); + + unsigned char * contents = (unsigned char *) + + get_data (NULL, filedata, sect->sh_offset, 1, sect->sh_size, _("attributes")); + if (contents == NULL) + - { + - res = false; + - continue; + - } + + return false; + + - p = contents; + + bool res = true; + + unsigned char * p = contents; + /* The first character is the version of the attributes. + Currently only version 1, (aka 'A') is recognised here. */ + if (*p != 'A') + { + printf (_("Unknown attributes version '%c'(%d) - expecting 'A'\n"), *p, *p); + res = false; + + goto free_data; + } + - else + - { + - uint64_t section_len; + + - section_len = sect->sh_size - 1; + + uint64_t section_len = sect->sh_size - 1; + p++; + + while (section_len > 0) + @@ -19456,10 +19446,9 @@ process_attributes (Filedata * filedata, + attr_len = 0; + } + } + - } + + +free_data: + free (contents); + - } + + return res; + } + +2025-03-04 Matthieu Longo + + clean-up bfd/elf-attrs.c: change return type of uleb128_size to unsigned + + clean-up: fix conflicting symbol with unknown from bfd/elf-bfd.h + + clean-up: fix annoying spaces in binutils/readelf.c + + clean-up: fix annoying spaces in bfd/elf-bfd.h + +2025-03-04 Tom Tromey + + Display entry offset for .debug_names + Since commit ad6dde5aaae ("gdb/dwarf: write offset to parent entry for + DW_IDX_parent"), gdb now emits a .debug_names where the DW_IDX_parent + attribute refers to the parent entry's offset -- previously, due to + some confusion in the standard, gdb used the index of the parent's + name table entry. + + This patch changes the .debug_names display code to display each + entry's offset. This makes it easy to refer from a DW_IDX_parent to + the correct entry. + + The new output looks like this: + + [...] + Symbol table: + [ 1] circular1: <0><1> DW_TAG_module DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x19> DW_IDX_GNU_language=19 + [...] + [ 6] found: <0x28><2> DW_TAG_subprogram DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x38> DW_IDX_GNU_language=19 DW_IDX_parent=<0x0> + + Here you can see that DW_IDX_parent=0 refers to "circular1: <0>". + +2025-03-04 Tom Tromey + + Obvious comment fix in cooked-index.h + I noticed that cooked-index.h still refers to a vector of parent maps, + but the code itself actually uses a parent_map here. + +2025-03-04 GDB Administrator + + Automatic date update in version.in + +2025-03-03 Alan Modra + + ecoff: check result of stat + * ecoff.c (_bfd_ecoff_write_armap): Don't use statbuf.st_mtime + if stat call returns non-zero. Use ARMAP_TIME_OFFSET rather + than its expansion. + +2025-03-03 Alan Modra + + objdump: is_same_section + This fixes a deficiency in commit 660df28acfa1, which should have used + the same logic as that in sym_ok. Ideally both places would not + compare section names, but it can be a little tricky to match a + section in the real object file with a section in a debug file. + Extend commit 39f0547e554d to use section name, vma and size. + + * objcopy (is_same_section): New function. + (compare_symbols, sym_ok): Use it here. + +2025-03-03 Alan Modra + + rescoff: ensure file is PE + read_coff_rsrc makes one check on object file contents, the existence + of a .rsrc section. It doesn't check that the file is PE but blindly + accesses bfd pe_data. Fix that by adding the necessary checks. + Also, the "resources nest too deep" error isn't an overrun, ie. the + "address out of bounds" message isn't correct. Fix that too. + + windres: delete function forward declaraions + Most of these were not needed, and moving a few functions around + removes the need for any. + +2025-03-03 Alan Modra + + Move BFD_FAKE_SECTION to libbfd.h + BFD_FAKE_SECTION and its sidekick GLOBAL_SYM_INIT don't need to be + cluttering bfd.h, and probably shouldn't be used outside bfd/. To + make them internal to bfd, make the bfd ecoff small common section + declaration global so it can be used instead of a duplicate in + gas/ecoff.c. Oddly this needs to go in bfd/ecofflink.c rather than + bfd/ecoff.c as the former is compiled for all targets needing the + ecoff small common section (some via a call in gas/config/obj-elf.c to + a function in gas/ecoff.c) while the latter is not. + + While doing this rename ecoff_scom_section to _bfd_ecoff_scom_section + and remove support for traditional C from GLOBAL_SYM_INIT. + +2025-03-03 Tom Tromey + + Add language to type unit in debug-names-tu.exp.tcl + I think debug-names-tu.exp.tcl only passes by accident -- the type + unit does not have a language, which gdb essentially requires. + + This isn't noticeable right now because the type unit in question is + expanded in one phase and then the symbol found in another. However, + I'm working on a series that would regress this. + + This patch partially fixes the problem by correcting the test case, + adding the language to the TU. + + Hoewver, it then goes a bit further and arranges for this information + not to be written to .debug_names. Whether or not a type should be + considered "static" seems like something that is purely internal to + gdb, so this patch has the entry-creation function apply the + appropriate transform. + + It also may make sense to change the "debug_names" proc in the test + suite to process attributes more like the ordinary "cu" proc does. + +2025-03-03 Simon Marchi + + gdb/dwarf: remove unnecessary abfd parameter in dwarf2_per_bfd::locate_sections + The parameter `abfd` is always the same as `this->obfd`, there is no + need to pass it as a parameter. + + Change-Id: If7ad58ad4efdf6b070cbf2b8a73436bd8b452fa6 + Approved-By: Tom Tromey + +2025-03-03 Simon Marchi + + gdb/dwarf: rename dwarf2_per_cu_data -> dwarf2_per_cu + This scratches an itch I had for a while. I don't know why this struct + type has "data" in its name. Others like "dwarf2_per_objfile" and + "dwarf2_per_bfd" don't. The primary job of a structure is to hold data, + there's no need to specify it. It also makes the name a bit shorter, + which is always nice. + + Rename related types too. + + Change-Id: Ifb63195ff105809fc15b502f639c0bb4d18a675e + Approved-By: Tom Tromey + Reviewed-By: Guinevere Larsen + +2025-03-03 Simon Farre + + Bploc should try to return full path + Compilers often emit relative paths in the line number program, + relative to the build directory for that compilation unit (if it's + DWARF>=4 I think). + + Therefore use symtab->fullname() when not null as this seemingly + has attempted path normalization for the symtab and only + fall back on symtab->filename which will never be null if that fails. + + This has a much better UX. Applications may choose to expose + this name as a clickable link to some file, at which point + a non-normalized and non-absolute path would lead nowhere. + + When I wrote this feature the first time, I don't think this + relative-to-cu-scheme was as prevalent in the output of gcc/clang + for DWARF. + + Approved-By: Tom Tromey + +2025-03-03 Tom de Vries + + [gdb/doc] Indicate in which languages 'filename'::funcaddr works + In the docs I read [1]: + ... + In this section, we discuss operators that you can use in GDB expressions + regardless of your programming language. + + ... + + GDB supports these operators, in addition to those common to programming + languages: + + ‘::’ allows you to specify a variable in terms of the file or function + where it is defined. See Program Variables. + ... + + In fact, this is not supported in Ada: + ... + (gdb) b *'foo.adb'::foo + No file or function "foo.adb'". + (gdb) + ... + and likewise in a few other working languages. + + Fix this by making this restriction explicit. + + Approved-By: Eli Zaretskii + + PR gdb/32753 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32753 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Expressions.html + +2025-03-03 Tom de Vries + + [gdb/doc] Fix address location with file prefix + In the docs I read [1]: + ... + Address locations indicate a specific program address. They have the + generalized form *address. + + funcaddr + + An address of a function or procedure derived from its name. + ... + + 'filename':funcaddr + + Like funcaddr above, but also specifies the name of the source file + explicitly. This is useful if the name of the function does not specify + the function unambiguously, e.g., if there are several functions with + identical names in different source files. + ... + + This is incorrect, the notation is in fact 'filename'::funcaddr. + + Fix this by correcting the typo, and add a reference to "variable name + conflict", where the concept is explained in more detail. + + Approved-By: Eli Zaretskii + + PR gdb/32748 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32748 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html + +2025-03-03 Tom de Vries + + [gdb/doc] Don't advertise *&function for pascal and modula-2 + In the docs I read [1]: + ... + Address locations indicate a specific program address. They have the + generalized form *address. + + ... + + funcaddr + + An address of a function or procedure derived from its name. + ... + In Pascal and Modula-2, this is &function. + ... + + I tried "break *&function" for Pascal and Modula-2, and this doesn't work, + while "break *function" works fine. + + Fix this by updating the documentation to reflect actual behaviour. + + Approved-By: Eli Zaretskii + + PR gdb/32754 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32754 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html + +2025-03-03 Simon Marchi + + gdb: remove some unused includes from printcmd.c + clangd reports them as unused. + + Change-Id: I50a3c13db128ffe1630364f707d66a24ce11d352 + +2025-03-03 Simon Marchi + + gdb: remove unused include from frame.c + clangd reports it as unused. + + Change-Id: I636e57747d3c42ce6615a14d4cf5dc115628a73d + +2025-03-03 Kito Cheng + + RISC-V: Support ssqosid extension with version 1.0. + It only add one new CSR: `srmcfg`. + + Ref: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 + +2025-03-03 Andrew Oates + + RISC-V: Re-define mapping symbol $x to the file elf architecture attribute + The mapping symbol "$x" without an ISA string "means using ISA + configuration from ELF attribute."[1]. Currently the code does not + reset the subset_list. This means that a previous mapping symbol that + overrides the ISA string will continue to be used, rather than the + default string set in the ELF file's .riscv.attributes section. This + can cause incorrect or failed instruction decodings. + + In practice, this causes problems when disassembling code generated by + LLVM, which (unlike gas) does not emit explicit mapping symbols at the + start of each section. + + This change stores the default architecture string seen at the beginning + of disassembly in the global parse data struct, and restores that to + subset_list whenever a bare "$x" symbol is seen. + + [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol + + Before this patch, the mapping-x.s was dumped as, + + 00000000 <.text>: + 0: 00000013 nop + 4: 0001 .insn 2, 0x0001 + 6: 0001 .insn 2, 0x0001 + + Which is caused by the definiation of $x was conflict with the psABI. + +2025-03-03 Nelson Chu + + RISC-V: Stop generating mapping symbol $x, replace with $x. + The psABI defined $x to the architecture which is same as the file elf + attribute. But GNU defined it to that is same as the previous $x, + and always generated $x at the begining of each section. That is + because considering two objects have different architecture in their elf + attributes, then $x will always be wrong after linking since the merged + arch string will be changed. For example, object A with rv32ic and object + B with rv32ia, $x from A is rv32ic and $x from B is rv32ia, but the final + output is rv32ica, so $x from A and B need to be updated to rv32ic and + rv32ia by linker respectively. I think let linker to do this is not good, + so in order to follow the psABI, we will stop generating the $x for now. + Instead, all $x will be replaced with the corresponding $x. The + dis-assembler will also treat $x like what psABI defined. + +2025-03-03 GDB Administrator + + Automatic date update in version.in + +2025-03-02 Richard Allen + + gprof: only process line numbers for intersection of vmas and histograms + Some programs like RTOS firmware may have a large number of symbols. + + By loading the histograms before loading symbols, we can look up + only the line numbers that were captured in the histogram file, + which reduces processing time for such a firmware from ~2 minutes + to ~2 seconds. + +2025-03-02 GDB Administrator + + Automatic date update in version.in + +2025-03-01 Richard Allen + + gprof: fix symbol miscount by merging passes + Instead of fixing "somebody miscounted" errors, + this patch combines the core_create_line_syms() + passes, and dynamically expands the ltab buffer. + + Reducing the number of passes will make future + optimizations simpler. + +2025-03-01 Richard Allen + + gprof: remove unused variables + + gprof: speed up line-by-line for MIPS/PowerPC/RISCV/SuperH + Roughly halves the number of bfd_find_nearest_line() calls, + about 40% less time for a few different large ELF files. + + gprof: rename min_insn_size to insn_boundary + This distinction is important for architecures like Xtensa, + where 2B and 3B instructions are common, but the correct + value for instruction iteration is 1B, not 2B. + + gprof: remove ASCII formfeed/0x0C bytes from source code + +2025-03-01 GDB Administrator + + Automatic date update in version.in + +2025-02-28 Simon Marchi + + gdb/dwarf: add dwarf2_per_bfd::filename and use it where possible + I noticed we quite often use: + + bfd_get_filename (per_bfd->obfd) + + Add a shortcut for that. + + Change-Id: I4e33925a481fd44088386510b01936d38e1d7d38 + Approved-By: Andrew Burgess + +2025-02-28 Andrew Carlotti + + Add Vim swap files to .gitignore + This matches the exclusion added to the GCC .gitignore file in 2022. + +2025-02-28 Nick Alcock + + libctf: fix cv-qualified unnamed struct/union field lookup + GCC permits not only unnamed structs and unions, but cv-qualified ones. + Our earlier fix in 6c3a38777b38a2ad87e2b2bcec4567578d1c83ec supported + unnamed structs and unions, but only unqualified ones. + + Resolving away cvr-quals of nameless fields (and, irrelevantly, typedefs) + is easy and fixes this problem. + + Tests adjusted accordingly. + + libctf/ + PR libctf/32746 + * ctf-types.c (ctf_member_next): Resolve away cv-quals. + (ctf_member_info): Likewise. + * testsuite/libctf-lookup/struct-iteration-ctf.c: Add a cv-qualified + type or two: make sure to keep a non-qualified one. + * testsuite/libctf-lookup/struct-iteration.c: Verify consistency + of ctf_member_next and ctf_member_info. + * testsuite/libctf-lookup/struct-iteration.lk: Adjust. + + Tested-by: Stephen Brennan + +2025-02-28 Nick Alcock + + libctf: fix slices of slices and of enums + Slices had a bunch of horrible usability problems. In particular, while + towers of cv-quals are resolved away by functions that need to do it, towers + of cv-quals with slices in the middle are not resolved away by functions + like ctf_enum_value that can see through slices: resolving volatile -> slice + -> const -> enum will leave it with a 'const', which will error pointlessly, + annoying callers, who reasonably expect slices to be more invisible than + this. (The user-callable ctf_type_resolve still does not resolve away + slices, because this is the only way users can see that the slices are there + at all.) + + This is induced by a fix for another wart: ctf_add_enumerator does not + resolve anything away at all, so you can't even add enumerators to const or + volatile enums -- and more problematically, you can't add enumerators to + enums with an explicit encoding without resolving away the types by hand, + since ctf_add_enum_encoded works by returning a slice! ctf_add_enumerator + now resolves away all of those, so any cvr-or-typedef-or-slice-qual + terminating in an enum can be added to, exactly as callers likely expect. + + (New tests added.) + + libctf/ + * ctf-create.c (ctf_add_enumerator): Resolve away cvr-qualness. + * ctf-types.c (ctf_type_resolve_unsliced): Don't terminate at + the first slice. + * testsuite/libctf-writable/slice-of-slice.*: New test. + +2025-02-28 Nick Alcock + + readelf, objdump: fix ctf dict leak + ctf_archive_next returns an opened dict, which must be closed by the caller. + + Thanks to Alan Modra for spotting this. + + binutils/ + * objdump.c (dump_ctf): Close dict. + * readelf.c (dump_section_as_ctf): Likewise. + +2025-02-28 Jonas 'Sortie' Termansen + + Remove unnecessary non-standard & unportable inclusions. + is not needed and not standardized and is just an alias for + . + + is not needed and not standardized and contains a kitchen + sink of various unportable definitions not agreed upon and best done + manually or through other headers. + + These fixes are needed to compile binutils on Sortix and other operating + systems with a strict POSIX.1-2024 libc without obsolete features. + +2025-02-28 Tom de Vries + + [gdb/testsuite] Fix gdb.base/nostdlib.exp on aarch64 + On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into: + ... + (gdb) continue^M + Continuing.^M + warning: Temporarily disabling breakpoints for unloaded shared library \ + "/lib/ld-linux-aarch64.so.1"^M + ^M + Breakpoint 2, _start () at nostdlib.c:20^M + 20 {^M + (gdb) FAIL: $exp: pie=pie: continue to marker + ... + + This happens as follows: + - the test-case sets a breakpoint on *_start, + - the breakpoint resolves to *_start in the executable, + - the executable is started, and the breakpoint resolves to *_start in the + dynamic linker, + - execution stops at *_start in the dynamic linker, + - the test-case issues a continue, expecting to continue to the breakpoint on + marker, + - while continuing, the dynamic linker is reported as unloaded, + - the breakpoint again resolves to *_start in the executable, + - execution stops at *_start in the executable, and + - the test-case concludes that it failed to "continue to marker". + + This doesn't happen on x86_64-linux. There, after the executable is started, + the breakpoint again resolves to *_start in the exec. + + This is similar to what happens when printing _start. + + On aarch64-linux, we print the _start in the dynamic linker: + ... + $ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \ + -ex "b _start" \ + -ex run \ + -ex "print _start" \ + -ex "info break" + Breakpoint 1 at 0x2bc: file nostdlib.c, line 23. + + Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22 + 22 ENTRY (_start) + $1 = {void (void)} 0xfffff7fd6ac0 <_start> + Num Type Disp Enb Address What + 1 breakpoint keep y + breakpoint already hit 1 time + 1.1 y 0x0000aaaaaaaa02bc in _start at nostdlib.c:23 + 1.2 y 0x0000fffff7fd6ac0 in _start at dl-start.S:22 + ... + + On x86_64-linux, we print the _start in the exec: + ... + Breakpoint 1 at 0x2c5: file nostdlib.c, line 23. + + Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \ + /lib64/ld-linux-x86-64.so.2 + $1 = {void (void)} 0x5555555542c1 <_start> + Num Type Disp Enb Address What + 1 breakpoint keep y + breakpoint already hit 1 time + 1.1 y 0x00005555555542c5 in _start at nostdlib.c:23 + 1.2 y 0x00007ffff7fe4f00 <_start> + ... + + The difference may be down to the availability of debug info for the _start in + the dynamic linker. + + Finally, the described scenario on aarch64-linux is not deterministic. The + behavior depends on the dynamic linker being reported as unloaded, which has + been classified as a GLIBC bug, so that might get fixed. + + Ideally this test-case would stop at both *_start in the executable and the + dynamic linker, but in absense of a way to specify this reliably (see PR32748), + fix this by making this a temporary breakpoint, ensuring that the breakpoint + will only trigger once. + + Approved-by: Kevin Buettner + + PR testsuite/32743 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743 + +2025-02-28 Simon Marchi + + gdb, gdbserver, gdbsupport: fix some namespace comment formatting + I noticed a + + // namespace selftests + + comment, which doesn't follow our comment formatting convention. I did + a find & replace to fix all the offenders. + + Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c + +2025-02-28 GDB Administrator + + Automatic date update in version.in + +2025-02-27 Simon Marchi + + gdb/dwarf: fix failed assertion in dwarf2_find_containing_comp_unit selftest + Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr + section") added some asserts in the dwarf2_per_cu_data constructor to + verify that the passed dwarf2_per_bfd and dwarf2_section_info are not + nullptr. However, the dummy dwarf2_per_cu_data objects created in the + dwarf2_find_containing_comp_unit selftests are passed nullptr for those + parameters. + + I prefer to keep the asserts in place, as protection for the non-test + code and as self documentation, so fix this by passing some dummy + pointers in the test. + + Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a + Reviewed-By: Tom de Vries + +2025-02-27 Simon Marchi + + gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor + Most of the time, the length of a unit is known when constructing a + dwarf2_per_cu_data or signatured_type. Add a construtor parameter for + it. In the few cases where it isn't, pass 0, which leaves it unset. + + Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96 + Reviewed-By: Tom de Vries + +2025-02-27 Nick Clifton + + Updated translations for bfd and gold + +2025-02-27 H.J. Lu + + x86-64: Pass -z separate-code to ld for -z mark-plt tests + Pass -z separate-code to ld for -z mark-plt tests to fix: + + FAIL: ld-x86-64/mark-plt-1a + FAIL: ld-x86-64/mark-plt-1b + FAIL: ld-x86-64/mark-plt-1c + FAIL: ld-x86-64/mark-plt-1d + FAIL: ld-x86-64/mark-plt-1a-x32 + FAIL: ld-x86-64/mark-plt-1b-x32 + FAIL: ld-x86-64/mark-plt-1c-x32 + FAIL: ld-x86-64/mark-plt-1d-x32 + + when binutils is configured with --disable-separate-code. + + * ld-x86-64/mark-plt-1a-x32.d: Pass -z separate-code to ld. + * ld-x86-64/mark-plt-1a.d: Likewise. + * ld-x86-64/mark-plt-1b-x32.d: Likewise. + * ld-x86-64/mark-plt-1b.d: Likewise. + * ld-x86-64/mark-plt-1c-x32.d: Likewise. + * ld-x86-64/mark-plt-1c.d: Likewise. + * ld-x86-64/mark-plt-1d-x32.d: Likewise. + * ld-x86-64/mark-plt-1d.d: Likewise. + +2025-02-27 GDB Administrator + + Automatic date update in version.in + +2025-02-26 Indu Bhagat + + gas: sframe: partially process DWARF unwind info in CFI_escape + CFI_escape is most commonly used to include DWARF expressions in the + unwind information. One may also use CFI_escape to add OS-specific CFI + opcodes. Up until now, SFrame generation process would skip generating + SFrame FDE at the mere sight of a CFI_escape opcode. + + Fine tune the handling of CFI_escape for SFrame generation by explicitly + checking for few "harmless" (in context of SFrame generation) + CFI_escape DWARF info: + - DW_CFA_expression affecting registers of no significance to SFrame + stack trace info + - DW_CFA_value_offset affecting registers of no significance to SFrame + stack trace info + + Expose the current cfi_escape_data structure in dw2gencfi.c to the + relevant header file to allow SFrame generation APIs to use it too. + + Valid unwind info may be split across multiple .cfi_escape directives. + Conversely, it is also allowed to simply put multiple DWARF expressions + and/or operations in a single .cfi_escape directive. Handling all of + these cases correctly will need parsing/processing that is not deemed + worth the effort in context of SFrame generation; We continue to skip + generating SFrame FDE for these cases and warn the user. + + In future, SFrame stack trace format may support non-SP/FP as base + register (albeit in limited form). Add an explicit check in + sframe_xlate_do_escape_expr (to test against the current CFA register) + to ensure the functionality continues to work. + + Use differentiated warning text in sframe_xlate_do_val_offset to avoid + confusion to the user as the same function is used for handling + .cfi_val_offset and .cfi_escape DW_CFA_val_offset,... + + Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64 + and aarch64 (and s390x too). + + gas/ + * gas/dw2gencfi.c (struct cfi_escape_data): Move from ... + * gas/dw2gencfi.h (struct cfi_escape_data): ... to. + * gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string + for .cfi_escape conditionally. + (sframe_xlate_do_escape_expr): New definition. + (sframe_xlate_do_escape_val_offset): Likewise. + (sframe_xlate_do_cfi_escape): Likewise. + (sframe_do_cfi_insn): Handle CFI_escape explicitly. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe.exp: Add new tests. + * gas/cfi-sframe/cfi-sframe-common-9.d: New test. + * gas/cfi-sframe/cfi-sframe-common-9.s: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test. + * gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test. + +2025-02-26 Charlie Jenkins + + RISC-V: Fix abort when displaying data and partial instructions + If data is encountered that is not a power of two, dump all of the data with + a .byte directive. The current largest support risc-v instruction length + is 22, so the data over 22 bytes will be displayed by, + .insn, 22, ... + .byte. + +2025-02-26 Clément Chigot + + ld/testsuite: add -z separate-code to sframe x86_64 tests + Those tests were generated by a linker having "-z separate-code" on by + default. However, being controlled by a configure option, it can be off + by default. Forcing the option as part of the tests ensures clean + results in both cases. + +2025-02-26 Tom de Vries + + [gdb/build] Fix unused var in dwarf2/read.c + On x86_64-linux, with gcc 7.5.0 I ran into a build breaker: + ... + gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’: + gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \ + [-Werror=unused-variable] + auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr); + ^ + ... + + Fix this by dropping the unused variable. + + Tested on x86_64-linux, by completing a build. + +2025-02-26 Simon Marchi + + gdb/dwarf: fix signature_type created with nullptr section + Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data + constructor") introduced a regression when using dwp. It can be + reproduced with: + + $ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp" + + Then, to investigate: + + $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int' + Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets... + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info' + + Commit c44ab627b02 removed the assignment of signatured_type::section + (dwarf2_per_cu_data::section, really) in + fill_in_sig_entry_from_dwo_entry with the justification that the section + was already set when constructing the signatured_type. Well, that was + true except for one spot in lookup_dwp_signatured_type which passes a + nullptr section to add_type_unit. + + Fix that by passing the section to add_type_unit in that one spot. This + is the same section that would have been set by + fill_in_sig_entry_from_dwo_entry before. + + Add some asserts in the dwarf2_per_cu_data constructor to verity that + the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr. + + Change-Id: If27dae6b4727957c96defc058c7e4be31472005b + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739 + Co-Authored-By: Tom de Vries + Approved-By: Tom Tromey + +2025-02-26 Simon Marchi + + gdb/dwarf: convert dwarf2_per_bfd::signatured_types to a gdb::unordered_set + I'd like to add these asserts in dwarf2_per_cu_data's constructor: + + gdb_assert (per_bfd != nullptr); + gdb_assert (section != nullptr); + + However, these dummy instances of signatured_type, used as hash table + lookup keys, are in the way: + + signatured_type find_sig_entry (nullptr, nullptr, sect_offset {}, sig); + + This motivated me to convert the dwarf2_per_bfd::signatured_types hash + table to a gdb::unordered_set. This allows finding an entry by simply + passing the signature (an integer) and removes the need to create dummy + signatured_type objects. + + There is one small unfortunate pessimization: + lookup_dwo_signatured_type, for instance, does a lookup by signature to + find an existing signatured_type. If not found, it adds a new one by + calling add_type_unit. The current code passes down the slot where to + put the new element, avoiding an extra hash when inserting the new + signatured_type. With the new code, I don't see a way to do that. This + is probably negligible, but it bugs me. If we used a map of signature + -> signatured_type, I would see a way, but then it would waste space. + + I see one change in behavior, that is not really important IMO. In + read_comp_units_from_section, if duplicate signature type entries are + detected, the code prior to this patch overwrites the existing + signatured_type in the hash table with the new one. With this patch, + the existing signatured_type is kept: the call to emplace does not + insert the value if an existing equal value exists. + + Other than that, no behavior change expected. + + Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e + Approved-By: Tom Tromey + +2025-02-26 Simon Marchi + + gdb/dwarf: change some per-objfile functions to be per-bfd + I identified the following functions that currently take a + dwarf2_per_objfile, but could take a less specific dwarf2_per_bfd. + + - try_open_dwop_file + - open_dwo_file + - open_dwp_file + + The uses of the per-objfile object in try_open_dwop_file can be replaced + with equivalent per-bfd ones. + + Change-Id: Ia31fa0b988375e86a715ee863d4ec3c572ce89c0 + Approved-By: Tom Tromey + +2025-02-26 Simon Marchi + + gdb/dwarf: use dwz_file::filename in a few spots + I found a few spots where the existing dwz_file::filename method could + be used. + + Change-Id: I0522b1e3abbfac2f392f9ec777c37b242ee236d8 + Approved-By: Tom Tromey + +2025-02-26 Simon Marchi + + gdb: move "gdb:function_view" into quick-symbol.h typedefs + All users of these typedefs use them inside a gdb::function_view. Move + the gdb::function_view in the typedefs themselves. This shortens the + types in function signatures and helps with readability, IMO. + + Rename them to remove the `_ftype` suffix: this suffix is not as + relevant in C++ as it was in C. With function_view, the caller can pass + more than just a simple "function". Anyway, I think it's clearer to + name them after the role the callback has (listener, matcher, etc). + + Adjust some related comments. + + Change-Id: Iaf9f8ede68b51ea9e4d954792e8eb90def8659a6 + Approved-By: Tom Tromey + +2025-02-26 Simon Marchi + + gdb/dwarf: initialize tu_stats fields + Initialize fields of tu_stats to 0, remove the explicit default + initialization of dwarf2_per_bfd::tu_stats. + + Change-Id: I98b2d5c4171291a3df2569466559174fb7cf32b6 + Approved-By: Tom Tromey + +2025-02-26 GDB Administrator + + Automatic date update in version.in + +2025-02-25 Tom Tromey + + Remove struct print_one_inferior_data + struct print_one_inferior_data is not used, so remove it. + +2025-02-25 Simon Marchi + + gdb/dwarf: remove unused include in read.c + This include is reported as unused by clangd. + + Change-Id: I95b73f85607537551ef54e46551197d1371d621b + +2025-02-25 Simon Marchi + + gdb/amd-dbgapi: add displaced stepping support + Implement the target_ops displaced stepping methods to add displaced + stepping support when debugging AMD GPU programs. The knowledge of how + to prepare and finish displaced steps is provided by the amd-dbgapi + library, so the code here is relatively straightforward. No need to + parse instructions or handle fixups, that is done by the lib We just + need to remember, for each thread doing a displaced step, the displaced + stepping id given by the library. + + Add a test to exercise the new functionality. The compiler generates + DWARF that GDB doesn't understand yet [1], so trying to step over a + breakpoint with DWARF present gives: + + (gdb) si + Unhandled dwarf expression opcode 0xe9 + + The test purposefully builds the binary without DWARF info to circumvent + this. + + [1] https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html + + Change-Id: I53f459221a42d4b02a6041eadb8cf554500e2162 + Approved-By: Lancelot Six (amdgpu) + +2025-02-25 Simon Marchi + + gdb: add target displaced stepping support + The amd-dbgapi library, used in the AMD GPU port, has the capability to + prepare and cleanup displaced step operations. In order to use it, add + the following target_ops methods: + + - supports_displaced_step + - displaced_step_prepare + - displaced_step_finish + - displaced_step_restore_all_in_ptid + + Prior to this patch, displaced stepping preparation and cleanup is done + solely by gdbarches. Update infrun to use these new target methods + instead of gdbarch hooks. To keep the behavior for other architectures + unchanged, make the default implementations of the new target_ops method + forward to the thread's gdbarch. + + displaced_step_restore_all_in_ptid won't be needed for the AMD GPU port, + but was added for completeness. It would be weird for infrun displaced + stepping code to call target methods except for that one thing where it + calls a gdbarch method. + + Since this patch only adds infrastructure, no behavior change is + expected. + + Change-Id: I07c68dddb5759a55cd137a711d2679eedc0d9285 + +2025-02-25 Simon Marchi + + gdb/amd-dbgapi: use gdb::unordered_map + Since we have gdb::unordered_map, swap std::unordered_map for that. + + Change-Id: If2ef652fe18c1a440a25cff6131d29e37091bdbe + Approved-By: Lancelot Six (amdgpu) + +2025-02-25 Ciaran Woodward + + Fix mkdir_recursive on windows when CWD is root + On windows, when creating a directory with an absolute path, + mkdir_recursive would start by trying to make 'C:'. + + On windows, this has a special meaning, which is "the current + directory on the C drive". So the first thing it tries to do + is create the current directory. + + Most of the time, this fails with EEXIST, so the function + continues as expected. However if the current directory is + C:/, trying to create that causes EPERM, which causes the + function to prematurely terminate. + + (The same applies for any drive letter.) + + This patch resolves this issue, by skipping the drive letter + so that it is never sent to the mkdir call. + + Approved-By: Tom Tromey + +2025-02-25 Jens Remus + + x86: SFrame FDE for PLT0 does not use repetition block size + The SFrame FDE for the PLT0 entry is of type PCINC, which does does not + make use of the type PCMASK repetition block size. Therefore generate + the FDE with a repetition block size of zero. + + bfd/ + * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use FDE + repetition block size of zero for PLT0. + +2025-02-25 Ciaran Woodward + + gdb/remote: Set the thread of the remote before sending qRcmd. + GDB allows remotes to implement extension commands which can + be accessed using the 'monitor' command. + + This allows remotes to implement functionality which does not + exist in GDB for whatever reason (doesn't make sense, too + specific to one target, etc.) + + However, before this change, the remote would not necessarily know + which thread/inferior was currently selected on the GDB client. + This prevents the implementation of any 'monitor' commands which are + specific to a single inferior/thread on the remote. + + This is because GDB informs the remote of the current thread + lazily - only when it is relevant to the RSP command next being + sent. + + qRcmd is the underlying RSP command used for monitor commands, so + this change ensures that GDB will update the remote with the + 'current' thread if it has changed since the remote was last + informed. + + Approved-By: Tom Tromey + +2025-02-25 Andrew Burgess + + gdb/windows: remove disable_breakpoints_in_shlibs call + I noticed that the disable_breakpoints_in_shlibs function disables + breakpoints without calling notify_breakpoint_modified. This commit + is one step towards fixing this issue. + + There are currently only two uses of disable_breakpoints_in_shlibs, + one in clear_solib (in solib.c), and the other in + windows_nat_target::do_initial_windows_stuff (in windows-nat.c). + + I believe that the call in windows-nat.c can be shown to be redundant, + and therefore can be removed. + + windows_nat_target::do_initial_windows_stuff is called from two + places: windows_nat_target::attach and + windows_nat_target::create_inferior, these are the target_ops + functions used to attach to a running process, or for creating a new + process, and are only called from attach_command or run_command_1, + both in infcmd.c. + + Both attach_command and run_command_1 call target_pre_inferior before + calling the relevant target_ops function. + + In target_pre_inferior, so long as the target doesn't have a global + solist (and windows doesn't), we always call no_shared_libraries (from + solib.c), which calls clear_solib (also in solib.c), which in turn + calls disable_breakpoints_in_shlibs. + + My claim then, is that, any time we reach the + disable_breakpoints_in_shlibs call in + windows_nat_target::do_initial_windows_stuff, we will have always have + called disable_breakpoints_in_shlibs already via clear_solib. + + I think it should be safe to remove the disable_breakpoints_in_shlibs + call from windows_nat_target::do_initial_windows_stuff. There should + be no user visible changes. + + My ultimate goal, which I'll address in follow on commits, is to + delete disable_breakpoints_in_shlibs completely. Removing this call + means that we only have one disable_breakpoints_in_shlibs call + remaining in GDB. + + Testing for this change has been minimal. My only Windows build + machine is not great, and I've never managed to get DejaGNU running in + that environment. This commit builds, and a few basic, manual tests + seem fine, but beyond that, this change is untested. + + Approved-By: Tom Tromey + +2025-02-25 Tom de Vries + + gdb: don't show incorrect source file in source window + Consider the test-case sources main.c and foo.c: + + $ cat main.c + extern int foo (void); + + int + main (void) + { + return foo (); + } + $ cat foo.c + extern int foo (void); + + int + foo (void) + { + return 0; + } + + and main.c compiled with debug info, and foo.c without: + + $ gcc -g main.c -c + $ gcc foo.c -c + $ gcc -g main.o foo.o + + In TUI mode, if we run to foo: + + $ gdb -q a.out -tui -ex "b foo" -ex run + + it gets us "[ No Source Available ]": + + ┌─main.c─────────────────────────────────────────┐ + │ │ + │ │ + │ │ + │ [ No Source Available ] │ + │ │ + │ │ + └────────────────────────────────────────────────┘ + (src) In: foo L?? PC: 0x400566 + ... + Breakpoint 1, 0x0000000000400566 in foo () + (gdb) + + But after resizing (pressing ctrl- in the gnome-terminal), we + get instead the source for main.c: + + ┌─main.c─────────────────────────────────────────┐ + │ 3 int │ + │ 4 main (void) │ + │ 5 { │ + │ 6 return foo (); │ + │ 7 } │ + │ │ + │ │ + └────────────────────────────────────────────────┘ + (src) In: foo L?? PC: 0x400566 + ... + Breakpoint 1, 0x0000000000400566 in foo () + (gdb) + + which is inappropriate because we're stopped in function foo, which is + not in main.c. + + The problem is that, when the window is resized, GDB ends up calling + tui_source_window_base::rerender. The rerender function has three + cases, one for when the window already has some source code + content (which is not the case here), a case for when the inferior is + active, and we have a selected frame (which is the case that applies + here), and a final case for when the inferior is not running. + + For the case which we end up in, the source code window has no + content, but the inferior is running, so we have a selected frame, GDB + calls the get_current_source_symtab_and_line() function to get the + symtab_and_line for the current location. + + The get_current_source_symtab_and_line() will actually return the last + recorded symtab and line location, not the current symtab and line + location. + + What this means, is that, if the current location has no debug + information, get_current_source_symtab_and_line() will return any + previously recorded location, or failing that, the default (main) + location. + + This behaviour of get_current_source_symtab_and_line() also causes + problems for the 'list' command. Consider this pure CLI session: + + (gdb) break foo + Breakpoint 1 at 0x40110a + (gdb) run + Starting program: /tmp/a.out + + Breakpoint 1, 0x000000000040110a in foo () + (gdb) list + 1 extern int foo (void); + 2 + 3 int + 4 main (void) + 5 { + 6 return foo (); + 7 } + (gdb) list . + Insufficient debug info for showing source lines at current PC (0x40110a). + (gdb) + + However, if we look at how GDB's TUI updates the source window during + a normal stop, we see that GDB does a better job of displaying the + expected contents. Going back to our original example, when we start + GDB with: + + $ gdb -q a.out -tui -ex "b foo" -ex run + + we do get the "[ No Source Available ]" message as expected. Why is + that? + + The answer is that, in this case GDB uses tui_show_frame_info to + update the source window, tui_show_frame_info is called each time a + prompt is displayed, like this: + + #0 tui_show_frame_info (fi=...) at ../../src/gdb/tui/tui-status.c:269 + #1 0x0000000000f55975 in tui_refresh_frame_and_register_information () at ../../src/gdb/tui/tui-hooks.c:118 + #2 0x0000000000f55ae8 in tui_before_prompt (current_gdb_prompt=0x31ef930 "(gdb) ") at ../../src/gdb/tui/tui-hooks.c:165 + #3 0x000000000090ea45 in std::_Function_handler::_M_invoke (__functor=..., __args#0=@0x7ffc955106b0: 0x31ef930 "(gdb) ") at /usr/include/c++/9/bits/std_function.h:300 + #4 0x00000000009020df in std::function::operator() (this=0x5281260, __args#0=0x31ef930 "(gdb) ") at /usr/include/c++/9/bits/std_function.h:688 + #5 0x0000000000901c35 in gdb::observers::observable::notify (this=0x31dda00 , args#0=0x31ef930 "(gdb) ") at ../../src/gdb/../gdbsupport/observable.h:166 + #6 0x00000000008ffed8 in notify_before_prompt (prompt=0x31ef930 "(gdb) ") at ../../src/gdb/event-top.c:518 + #7 0x00000000008fff08 in top_level_prompt () at ../../src/gdb/event-top.c:534 + #8 0x00000000008ffdeb in display_gdb_prompt (new_prompt=0x0) at ../../src/gdb/event-top.c:487 + + If we look at how tui_show_frame_info figures out what source to + display, it doesn't use get_current_source_symtab_and_line(), instead, + it finds a symtab_and_line directly from a frame_info_pt. This means + we are not dependent on get_current_source_symtab_and_line() returning + the current location (which it does not). + + I propose that we change tui_source_window_base::rerender() so that, + for the case we are discussing here (the inferior has a selected + frame, but the source window has no contents), we move away from using + get_current_source_symtab_and_line(), and instead use find_frame_sal + instead, like tui_show_frame_info does. + + This means that we will always use the inferior's current location. + + Tested on x86_64-linux. + + Reviewed-By: Tom de Vries + Reported-By: Andrew Burgess + Co-Authored-By: Andrew Burgess + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32614 + +2025-02-25 Tom de Vries + + [libctf] Fix warning: @xref should not appear on @multitable line + When building gdb, I run into: + ... + ctf-spec.texi:809: warning: @xref should not appear on @multitable line + ... + + The line in question is: + ... + @multitable {Kind} {@code{CTF_K_VOLATILE}} {Indicates a type that cannot be represented in CTF, or that} {@xref{Pointers typedefs and cvr-quals}} + ... + which defines a prototype row with 4 columns. + + However, the table only has 3 colums: + ... + @headitem Kind @tab Macro @tab Purpose + ... + + Fix the warning by removing the item in the prototype row representing a fourth column. + + Tested on aarch64-linux. + + PR libctf/32044 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32044 + +2025-02-25 GDB Administrator + + Automatic date update in version.in + +2025-02-24 Tom de Vries + + [gdb/testsuite] Exit left-over gdb in gdb.mi/mi-break.exp + After test-case gdb.mi/mi-break.exp, a gdb instance is left running. + + The test-case starts two instances using mi_clean_restart, one using + separate-mi-tty. + + For each instance, gdb_exit is called once, from two different locations: + - mi_clean_restart, and + - gdb_finish. + + But this doesn't seem to be effective for the separate-mi-tty case. + + Fix this by calling gdb_mi_exit at the end of proc test_break. + + Likewise in a few more more test-case. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/32709 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709 + +2025-02-24 Kevin Buettner + + Use ui_out for "info checkpoints" + In his review of my recent checkpoint work (commit e5501dd4321), + Andrew Burgess suggested that I use GDB's structured table generation + mechanism for the "info checkpoints" command. This patch does + that. + + Andrew also recommended using print_stack_frame() for the "Frame" + column. I tried this, but ran into some problems, which are described + in a comment in the code. I got it to mostly work, except for the + case when the current/active fork is running. Switching context away + from and then back to a running fork doesn't work. It could, perhaps, + be made to work, but I'm not convinced that the checkpoint facility is + important enough to expend the effort for this case. So, instead, + I simply adapted the existing checkpoint frame printing code to + use the ui_out machinery instead of gdb_printf. + + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb/styling: only check TERM environment once, during initialisation + We currently check the TERM environment variable any time we call one + of the ui_file::can_emit_style_escape() functions. This seems + excessive. + + During GDB's startup we also check for the NO_COLOR environment + variable and disable styling if this is set. + + I propose that we combine these two checks, and perform them just once + during startup (as the current NO_COLOR check is currently done). As + with the NO_COLOR check, if the TERM variable is set to "dumb" + indicating that styling is not supported then we should just set + cli_styling to false. + + This does mean that the user can then 'set style enabled on', even for + a dumb terminal, which was not possible previously. Before this + commit the "dumb" terminal check was separate and would prevent + styling even if 'set style enabled on' was in effect. + + Of course, trying to turn on styling in a dumb terminal might not give + the results that a user hope for. And so, I have implemented a check + in `set_style_enabled`, so in a dumb terminal a user will see this: + + (gdb) set style enabled on + warning: The current terminal doesn't support styling. Styled output might not appear as expected. + + After which GDB will try to emit styling. We could, potentially, + prevent styling being enabled instead of emitting a warning, but I'm + inclined to let the user turn on styling if they really want to. + + Approved-By: Kevin Buettner + Acked-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb/tui: use correct setting to control asm window styling + Currently the TUI's asm window uses `source_styling` to control + styling. This setting is supposed to be for styling of source files + though, and the asm window displays disassembler output. + + We have a different setting for this `disassemble_styling`, which is + controlled with 'set style disassembler enabled on|off'. + + Switch to use the correct control variable. + + I've written a new test for this, but this required some additions to + the tuiterm library in order to grab character attributes for a screen + region. + + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb/doc: fix help text for 'set style disassembler enabled' + The help text for 'set/show style disassembler enable' was output of + date. It talks about GDB requiring the Python Pygments library, but + for many common architectures this is no longer the case, libopcode is + used for styling. + + The Python Pygments library is still used as a fallback for those + architectures that libopcode doesn't currently style. + + I've updated the help text to try and explain all this. The manual + was already updated. + + Approved-By: Eli Zaretskii + +2025-02-24 Tom de Vries + + [gdb/doc] Fix documentation of handle SIGKILL + Here ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Signals.html ) I + read: + ... + GDB has the ability to detect any occurrence of a signal in your program. You + can tell GDB in advance what to do for each kind of signal. + ... + + However, here ( https://man7.org/linux/man-pages/man2/ptrace.2.html ) I read: + ... + While being traced, the tracee will stop each time a signal is + delivered, even if the signal is being ignored. (An exception is + SIGKILL, which has its usual effect.) + ... + + So, it seems to be that for SIGKILL we can't tell GDB in advance what to do. + + Fix the documentation to reflect this. + + Approved-By: Eli Zaretskii + + PR gdb/32714 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32714 + +2025-02-24 Rudnicki, Piotr + + gdb, testsuite, rust: fix for empty array + For the Rust language, to avoid segmentation fault in case of an empty + array, do not try to copy any elements, but allocate and return + the empty array immediately. + + With the command before the change, gdb crashes with message: + + (gdb) set lang rust + (gdb) p [1;0] + Fatal signal: Segmentation fault + + After the fix in this commit, gdb shows following message: + (gdb) set lang rust + (gdb) p [1;0] + $1 = [] + + Update the existing test case gdb.rust/expr.exp to verify the change. + + Approved-By: Tom Tromey + +2025-02-24 Nick Clifton + + objdump: Inform users if RELR relocs are present in a file when using the -r or -R options and no regular relocs are present. + PR 32459 + +2025-02-24 Shahab Vahedi + + gdb/testsuite/lib/rocm.exp: Fix a typo in a comment + "Check we have ..." --> "Check if we have ..." + + This is for consistency with the previous comment and + the code downstream. + +2025-02-24 Andrew Burgess + + gdb: handle empty locspec when printing breakpoints + For background reading, please see the previous patch, and the patch + before that! + + After the last two patches, internal breakpoints can now be marked as + shlib_disabled if the library in which they are placed is unloaded. + + The patch before last discusses a situation related to the + gdb.base/nostdlib.exp test, when run on a GNU/Linux glibc based system + where executables are compiled as PIE by default. + + In this case it is observed that the dynamic linker will actually + report itself as unloaded (i.e. remove itself from the list of + currently loaded shared libraries). This behaviour is likely a bug in + the dynamic linker, but this behaviour exists in released versions of + the dynamic linker, so GDB should (if the cost is not too great) be + changed to handle this situation. + + This commit handles a problem with the 'maint info breakpoints' + command. + + When the dynamic linker is unloaded the 'shlib event' breakpoint is + marked as shlib_disabled (i.e. placed into the pending state). When + displaying the breakpoint in the 'maint info breakpoints' output, GDB + will try to print the locspec (location_spec *) as a string + + Unfortunately, the locspec will be nullptr as the internal breakpoints + are not created via a location_spec, this means that GDB ends up + trying to call location_sepc::to_string() on a nullptr, resulting in + undefined behaviour (and a crash). + + For most internal breakpoint types this is not a problem. If we + consider bp_longjmp_master for example, if the shared library + containing a breakpoint of this type is unloaded then first GDB marks + the breakpoint as shlib_disabled, then after unloading the shared + library breakpoint_re_set is called, which will delete the internal + breakpoint, and then try to re-create it (if needed). As a result, + the user never gets a change to run 'maint info breakpoints' on a + bp_longjmp_master breakpoint in the shlib_disabled state. + + But bp_shlib_event and bp_thread_event breakpoints are not deleted and + recreated like this (see internal_breakpoint::re_set), so it is + possible, in rare cases, that we could end up trying to view one of + these breakpoint in a shlib_disabled state, and it would be nice if + GDB didn't crash as a result. + + I've updated the printing code to check for and handle this case, and + I've updated the docs to mention this (rare) case. + + For testing, I've extended gdb.base/nostdlib.exp to compile as + pie and nopie, and then run 'maint info breakpoints'. If we're + running on a buggy glibc then this will trigger the crash. I don't + know how I can trigger this problem without a buggy glibc as this + would require forcing the dynamic linker to be unloaded. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb: disable internal b/p when a solib is unloaded + Bug PR gdb/32079 highlights an issue where GDB will try to remove a + breakpoint for a shared library that has been unloaded. This will + trigger an error from GDB like: + + (gdb) next + 61 dlclose (handle[dl]); + (gdb) next + warning: error removing breakpoint 0 at 0x7ffff78169b9 + warning: error removing breakpoint 0 at 0x7ffff7730b57 + warning: error removing breakpoint 0 at 0x7ffff7730ad3 + 54 for (dl = 0; dl < 4; ++dl) + (gdb) + + What happens is that as the inferior steps over the dlclose() call, + GDB notices that the library has been unloaded and calls + disable_breakpoints_in_unloaded_shlib. However, this function only + operates on user breakpoints and tracepoints. + + In the example above what is happening is that the test loads multiple + copies of libc into different linker namespsaces. When we 'next' over + the dlclose call one of the copies of libc is unloaded. As GDB placed + longjmp master breakpoints within the copy of libc that was just + unloaded, the warnings we see are GDB trying (and failing) to remove + these breakpoints. + + I think the solution is for disable_breakpoints_in_unloaded_shlib to + handle all breakpoints, even internal ones like the longjmp master + breakpoints. + + If we do this then the breakpoint will be marked as shlib_disabled and + also will be marked as not inserted. Later when we call + breakpoint_re_set() and the longjmp breakpoints are deleted we will no + longer try to remove them. + + This solution is inspired by a patch suggested in the bug report: + + https://sourceware.org/bugzilla/show_bug.cgi?id=32079#c3 + + There are some differences with my approach compared to the patch + suggested in the bug. First I have no need to delete the breakpoint + inside disable_breakpoints_in_unloaded_shlib as an earlier patch in + this series arranged for breakpoint_re_set to be called when shared + libraries are removed. Calling breakpoint_re_set will take care of + deleting the breakpoint for us. For details see the earlier commit + titled: + + gdb: fixes for code_breakpoint::disabled_by_cond logic + + Next, rather than only handling bp_longjmp and bp_longjmp_master, I + allow all breakpoints to be handled. I also only give the warning + about disabling breakpoints for user breakpoints, I don't see the + point of warning the user about internal b/p changes. + + With this done the issues in PR gdb/32079 are resolved. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079 + + Tested-By: Hannes Domani + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb: don't clear inserted flag in disable_breakpoints_in_unloaded_shlib + This commit removes the clearing of bp_location::inserted from + disable_breakpoints_in_unloaded_shlib, my claim is that this call is + not needed (any more), and with the next commit, this line actually + causes some problems. + + The disable_breakpoints_in_unloaded_shlib function was added back in + 2004 with commit 84acb35a5a97c, and from this first version the + function cleared the bp_location::inserted flag. The motivation for + this is that the shared library might have already been unmapped, in + which case, a later attempt to remove the location could fail. + + In 2013 a similar function disable_breakpoints_in_freed_objfile was + added. This function also cleared bp_location::inserted for similar + reasons. This code was added in commit: + + commit 63644780babdca3f40e1978a236b6cd78473c91b + Date: Tue Mar 12 11:10:18 2013 +0100 + + New remove-symbol-file command. + + Then in 2014 the clearing of bp_location::inserted was removed from + disable_breakpoints_in_freed_objfile in the commit: + + commit 08351840eabb44799e3d01026610420758f4fa40 + Date: Tue Apr 22 23:19:19 2014 +0100 + + Stale breakpoint instructions, spurious SIGTRAPS. + + The reason that clearing the ::inserted flag was removed in this + commit is that if the disable_breakpoints_in_freed_objfile function + was called when the b/p were actually inserted, and the memory for the + associated objfile wasn't actually unmapped, then we could end up + leaving breakpoints inserted into the inferior, which leads to + spurious SIGTRAPs. + + In the next commit I'll change disable_breakpoints_in_unloaded_shlib + so that all breakpoints, not just user breakpoints, will be + disabled (via shlib_disabled) when a shared library is unloaded. This + addresses PR gdb/32079, see the next commit for a fuller justification + for this change. + + The problem is that when I tested the next commit I ran into some + regressions from the gdb.base/nostdlib.exp test when run on an AArch64 + GNU/Linux system where executables are compiled as PIE by default. + This test compiles a simple binary with the -nostdlib flag. + + What happens is this: + + - The executable is compiled as PIE, this means that we get a + dynamically linked executable, the dynamic linker is used to + perform the PIE relocation, but the executable uses no other + shared libraries. + + - When GDB starts the inferior, initially the dynamic linker is + discovered as a shared library being used by the application, GDB + loads in the library and its debug symbols, placing the internal + "shlib event" breakpoints so that future shared library events can + be tracked. + + - For the target I tested on systemtap probes were not used, instead + GDB fell back to the old style even breakpoint. + + - As the inferior progresses, after the PIE relocation has been + performed, the dynamic linker performs some house keeping on the + list of shared libraries being used by the application. During + this process the dynamic linker is removed from the list of shared + libraries being used by the inferior, this causes GDB see a shared + library event, which GDB understands to mean that it should unload + the dynamic linker from the inferior. + + I spoke with the glibc engineers at RH, and the feeling is that + this is likely a bug (it's still being investigated). But I don't + think it really matters if this is a bug or not. There are + versions of glibc in the wild that have this behaviour, so GDB + should (if the cost is not too great) be updated to handle this. + + Obviously after removing the dynamic linker from the list of + shared libraries, the dynamic linker is not actually unmapped, + that would not be possible, it's the dynamic linker that does the + unmapping, so the dynamic linker is left mapped into the + inferior's address space. + + - With the next patch in place all breakpoints (user and internal) + within the dynamic linker are disabled (shlib_disabled) and + currently marked as not inserted (bp_location::inserted flag is + cleared). + + - Having processed the shared library event GDB then resumes the + inferior. As the shared library event is not a full stop of the + inferior (i.e. we don't remove all breakpoints before handling the + event), all of the breakpoints in the dynamic linker are still + inserted, but are now marked as not-inserted. + + - GDB then resumes the inferior and immediately hits the breakpoint + that is still inserted. As GDB thinks this breakpoint is not + inserted, this is reported to the user as a SIGTRAP. + + The fix I think is just to not clear the bp_location::inserted flag in + disable_breakpoints_in_unloaded_shlib. This will leave the breakpoint + as inserted in the case above. GDB will now be able to successfully + resume the inferior after the shared library event (knowing there is a + breakpoint inserted GDB will step over it and continue as expected). + The next time the inferior performs a full stop the now shlib_disabled + breakpoint will be removed from the inferior we would want. + + For the usual case, where a shared library is being unloaded due to + say a dlclose, the breakpoints in the library will be marked as + disabled, but will be left inserted. The next time remove_breakpoints + is called GDB will try to remove those breakpoint locations. If the + removal fails, as the breakpoint is marked shlib_disabled, GDB will + hide the error message from the user and just assume that the shared + library has been unmapped. This functionality was first added in 2008 + in commit 879d1e6b4674bc8. + + There are two aspects to testing this change. First whether no + clearing the ::inserted flag causes general problems. That is tested + by running the full testsuite (I see no regressions). + + Then there is the specific problem that caused me to make this + change. That issue only occurs on AArch64, with GNU/Linux using + glibc, when the executable is compiled as PIE, and doesn't use any + shared libraries other than the dynamic linker (which can be the + gdb.base/nostdlib.exp test if run on the right system). What I don't + know is how to recreate this setup in a more general form. + + We can't use add-symbol-file/remove-symbol-file as that passes through + disable_breakpoints_in_freed_objfile instead, which the ::installed + flag is already not adjusted. + + Also the bug doesn't trigger on x86 targets due to code in + handle_signal_stop which sees the inserted breakpoint, and decides + this must be a breakpoint that actually exists in the program, and + then because gdbarch_decr_pc_after_break returns non-zero for x86, GDB + steps the inferior past the breakpoint. This is the big difference + from AArch64 where gdbarch_decr_pc_after_break returns zero, and so + the inferior gets stuck hitting the unexpectedly inserted breakpoint. + + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb: handle dprintf breakpoints when unloading a shared library + While working on the previous commit I realised that GDB would not + handle dprintf breakpoints correctly when a shared library was + unloaded. + + Consider this example using the test binary from shlib-unload.exp. In + the function 'foo' we create a dprintf is in a shared library: + + (gdb) b 59 + Breakpoint 1 at 0x401215: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c, line 59. + (gdb) r + Starting program: /tmp/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/shlib-unload/shlib-unload + + Breakpoint 1, main () at /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload.c:59 + 59 res = dlclose (handle); /* Break here. */ + (gdb) dprintf foo,"In foo" + Dprintf 2 at 0x7ffff7fc50fd: file /tmp/projects/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/shlib-unload-lib.c, line 23. + (gdb) n + Error in re-setting breakpoint 2: Function "foo" not defined. + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + warning: error removing breakpoint 2 at 0x7ffff7fc50fd + Cannot remove breakpoints because program is no longer writable. + Further execution is probably impossible. + 60 assert (res == 0); + (gdb) + + What happens here is that as the inferior steps over the dlclose call + the shared library containing 'foo' is unloaded and + disable_breakpoints_in_unloaded_shlib is called. However in + disable_breakpoints_in_unloaded_shlib we have this check: + + if (b.type != bp_breakpoint + && b.type != bp_jit_event + && b.type != bp_hardware_breakpoint + && !is_tracepoint (&b)) + continue; + + As the dprintf has type bp_dprintf then this check triggers and we + ignore the dprintf, meaning the dprintf is not disabled. When the + inferior stops after the 'next' GDB tries to remove all breakpoints + but the dprintf can no longer be removed, the memory in which it was + placed has been unmapped from the inferior. + + The fix is to start using is_breakpoint() in + disable_breakpoints_in_unloaded_shlib instead of the bp_breakpoint and + bp_hardware_breakpoint checks. The is_breakpoint() function also + checks for bp_dprintf. + + With this fix in place GDB now correctly disables the breakpoint and + we no longer see the warning about removing the breakpoint. + + During review it was pointed out that PR gdb/23149 and PR gdb/20208 + both describe something similar, though for these bugs, the inferior + is restarted (which unloads all currently loaded shlib) rather than + passing over the dlclose. But the consequences are pretty similar. + I've included a test which covers this case. + + One additional thing that these two bugs did show though is that + disable_breakpoints_in_shlibs also needs to start using is_breakpoint + for the same reason. Without this change, when an inferior is + restarted we get a warning like this for dprintf breakpoints: + + warning: Temporarily disabling breakpoints for unloaded shared library "..." + + but we don't get a similar warning for "normal" breakpoints. This is + because disable_breakpoints_in_shlibs is called from clear_solib, + which is called when an inferior is restarted. + + It is best not to think too hard about disable_breakpoints_in_shlibs, + as this function is pretty broken, e.g. it doesn't call + notify_breakpoint_modified, despite modifying the breakpoints. But + for now I'm ignoring that, but fixing this is definitely on my list + for my next set of breakpoint related fixes, it's just that a lot of + these breakpoint fixes end up being depending on one another, but I + want to avoid making this series too long. So for now, I'm ignoring + the existing bug (missing breakpoint modified events), and fixing + disable_breakpoints_in_shlibs to cover dprintf. + + With these fixes in place, the two bugs mentioned above should be + fixed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23149 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20208 + + Tested-By: Hannes Domani + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb: restructure disable_breakpoints_in_unloaded_shlib + This commit rewrites disable_breakpoints_in_unloaded_shlib to be more + like disable_breakpoints_in_freed_objfile. Instead of looping over + all b/p locations, we instead loop over all b/p and then over all + locations for each b/p. + + The advantage of doing this is that we can fix the small bug that was + documented in a comment in the code: + + /* This may cause duplicate notifications for the same breakpoint. */ + notify_breakpoint_modified (b); + + By calling notify_breakpoint_modified() as we modify each location we + can potentially send multiple notifications for a single b/p. + + Is this a bug? Maybe not. After all, at each notification one of the + locations will have changed, so its probably fine. But it's not + ideal, and we can easily do better, so lets do that. + + There's a new test which checks that we only get a single notification + when the shared library is unloaded. Note that the test is written as + if there are multiple related but different tests within the same test + file ... but there aren't currently! The next commit will add another + test proc to this test script at which point the comments will make + sense. I've done this to avoid unnecessary churn in the next commit. + + Tested-By: Hannes Domani + Approved-By: Tom Tromey + +2025-02-24 Andrew Burgess + + gdb: fixes for code_breakpoint::disabled_by_cond logic + I spotted that the code_breakpoint::disabled_by_cond flag doesn't work + how I'd expect it too. The flag appears to be "sticky" in some + situations; once a code_breakpoint::disabled_by_cond flag is marked + true, then, in some cases the flag wont automatically become false + again, even when you'd think it should. + + The problem is in update_breakpoint_locations. In this function, + which is called as a worker of code_breakpoint::re_set, GDB computes a + new set of locations for a breakpoint, the new locations are then + installed into the breakpoint. + + However, before installing the new locations GDB attempts to copy the + bp_location::enabled and bp_location::disabled_by_cond flag from the + old locations into the new locations. + + The reason for copying the ::enabled flag makes sense. This flag is + controlled by the user. When we create the new locations if GDB can + see that a new location is equivalent to one of the old locations, and + if the old location was disabled by the user, then the new location + should also be disabled. + + However, I think the logic behind copying the ::disabled_by_cond flag + is wrong. The disabled_by_cond flag is controlled by GDB and should + toggle automatically. If the condition string can be parsed then the + flag should be false (b/p enabled), if the condition string can't be + parsed then the flag should be true (b/p disabled). + + As we always parse the condition string in update_breakpoint_locations + before we try to copy the ::enabled flag value then the + ::disabled_by_cond flag should already be correct, there's no need to + copy over the ::disabled_by_cond value from the old location. + + As a concrete example, consider a b/p placed within the main + executable, but with a condition that depends on a variable within a + shared library. + + When the b/p is initially created the b/p will be disabled as the + condition string will be invalid (the shared library variable isn't + available yet). + + When the inferior starts the shared library is loaded and the + condition variable becomes available to GDB. When the shared library + is loaded breakpoint_re_set is called which (eventually) calls + update_breakpoint_locations. + + A new location is computed for the breakpoint and the condition string + is parsed. As the shared library variable is now know the expression + parses correctly and ::disabled_by_cond is left false for the new + location. + + But currently GDB spots that the new location is at the same address + as the old location and copies disabled_by_cond over from the old + location, which marks the b/p location as disabled. This is not what + I would expect. + + The solution is simple, don't copy over disabled_by_cond. + + While writing a test I found another problem though. The + disabled_by_cond flag doesn't get set true when it should! This is + the exact opposite of the above. + + The problem here is in solib_add which is (despite the name) called + whenever the shared library set changes, including when a shared + library is unloaded. + + Imagine an executable that uses dlopen/dlclose to load a shared + library. Given an example of a b/p in the main executable that has a + condition that uses a variable from our shared library, a library + which might be unloaded with dlclose. + + My expectation is that, when the library is unloaded, GDB will + automatically mark the breakpoint as disabled_by_cond, however, this + was not happening. + + The problem is that in solib_add we only call breakpoint_re_set when + shared libraries are added, not when shared libraries are removed. + + The solution I think is to just call breakpoint_re_set in both cases, + now the disabled_by_cond flag is updated as I'd expect. + + Unfortunately, making this change causes a regression when running: + + make check-gdb \ + TESTS="gdb.trace/change-loc.exp" \ + RUNTESTFLAGS="--target_board=native-gdbserver" + + This test unloads a shared library and expects breakpoints within the + shared library to enter the PENDING state (because the bp_location's + shlib_disabled flag will be set). However, the new call to + breakpoint_re_set means that this is no longer the case. + + The breakpoint_re_set call means that update_breakpoint_locations is + called, which then checks if all locations for a breakpoint are + pending or not. In this test not all locations are pending, and so + GDB recalculates the locations of each breakpoint, this means that + pending locations are discarded. + + There is a but report PR gdb/32404 which mentions the problems with + shlib_disabled pending breakpoints, and how they are prone to being + randomly deleted if the user can cause GDB to trigger a call to + breakpoint_re_set. This patch just adds another call to + breakpoint_re_set, which triggers this bug in this one test case. + + For now I have marked this test as KFAIL. I do plan to try and + address the pending (shlib_disabled) breakpoint problem in the future, + but I'm not sure when that will be right now. + + There are, of course, tests to cover all these cases. + + During review I was pointed at bug PR gdb/32079 as something that this + commit might fix, or help in fixing. + + And this commit is part of the fix for that bug, but is not the + complete solution. However, the remaining parts of the fix for that + bug are not really related to the content of this commit. + + The problem in PR gdb/32079 is that the inferior maps multiple copies + of libc in different linker namespaces using dlmopen (actually libc is + loaded as a consequence of loading some other library into a different + namespace, but that's just a detail). The user then uses a 'next' + command to move the inferior forward. + + GDB sets up internal breakpoints on the longjmp symbols, of which + there are multiple copies (there is a copy in every loaded libc). + + However, the 'next' command is, in the problem case, stepping over a + dlclose call which unloads one of the loaded libc libraries. + + In current HEAD GDB in solib_add we fail to call breakpoint_re_set() + when the library is unloaded; breakpoint_re_set() would delete and + then recreate the longjmp breakpoints. As breakpoint_re_set() is not + called GDB thinks that the the longjmp breakpoint in the now unloaded + libc still exists, and is still inserted. + + When the inferior stops after the 'next' GDB tries to delete and + remove the longjmp breakpoint which fails as the libc in which the + breakpoint was inserted is no longer mapped in. + + When the user tries to 'next' again GDB tries to re-insert the still + existing longjmp breakpoint which again fails as the memory in which + the b/p should be inserted is no longer part of the inferior memory + space. + + This commit helps a little. Now when the libc library is unmapped GDB + does call breakpoint_re_set(). This deletes the longjmp breakpoints + including the one in the unmapped library, then, when we try to + recreate the longjmp breakpoints (at the end of breakpoint_re_set) we + don't create a b/p in the now unmapped copy of libc. + + However GDB does still think that the deleted breakpoint is inserted. + The breakpoint location remains in GDB's data structures until the + next time the inferior stops, at which point GDB tries to remove the + breakpoint .... and fails. + + However, as the b/p is now deleted, when the user tries to 'next' GDB + no longer tries to re-insert the b/p, and so one of the problems + reported in PR gdb/32079 is resolved. + + I'll fix the remaining issues from PR gdb/32079 in a later commit in + this series. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079 + + Tested-By: Hannes Domani + Approved-By: Tom Tromey + +2025-02-24 GDB Administrator + + Automatic date update in version.in + +2025-02-23 Tom Tromey + + Fix formatting in dwarf2/index-write.c + I noticed a spot in dwarf2/index-write.c that was mis-formatted. This + fixes it. + +2025-02-23 Milica Matic + + MIPS: Apply coding guidelines: indentation + Format mips-tdep.c code as described on links: + + https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards + https://www.gnu.org/prep/standards/standards.html#Comments + + correcting indentation as required. + + Approved-by: Kevin Buettner + Approved-by: Maciej W. Rozycki + +2025-02-23 Milica Matic + + MIPS: Apply coding guidelines: tabs + Format mips-tdep.c code as described on links: + + https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards + https://www.gnu.org/prep/standards/standards.html#Comments + + converting spaces to tabs and fixing alignment as appropriate. + + Approved-by: Kevin Buettner + Approved-by: Maciej W. Rozycki + +2025-02-23 Milica Matic + + MIPS: Apply coding guidelines: sentences + Format mips-tdep.c code as described on links: + + https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards + https://www.gnu.org/prep/standards/standards.html#Comments + + capitalizing sentences and adding full stops and spaces after them. + + Approved-by: Kevin Buettner + Approved-by: Maciej W. Rozycki + +2025-02-23 Milica Matic + + MIPS: Apply coding guidelines: new lines + Format mips-tdep.c code as described on links: + + https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards + https://www.gnu.org/prep/standards/standards.html#Comments + + removing and adding new lines as appropriate. + + Approved-by: Kevin Buettner + Approved-by: Maciej W. Rozycki + +2025-02-23 Milica Matic + + MIPS: Apply coding guidelines: trailing space + Format mips-tdep.c code as described on links: + + https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards + https://www.gnu.org/prep/standards/standards.html#Comments + + removing trailing space. + + Approved-by: Kevin Buettner + Approved-by: Maciej W. Rozycki + +2025-02-23 Alan Modra + + gas: avoid dangling pointers into freed memory + The oss-fuzz gas fuzzer is quite broken in that it doesn't + reinitialise all gas and bfd static variables between runs. Since gas + naughtily modifies bfd_und_section and bfd_abs_section those bfd + statics can hold pointers into freed memory between runs. + This patch fixes oss-fuzz issue 398060144. + +2025-02-23 Alan Modra + + PR 32731 ub sanitizer accessing filenames_reversed + tic4x-coff and mcore-pe tickle this bug by a peculiarity of their + default ld scripts. + + PR 32731 + * ldlang.c (lang_add_wild): Init filenames_reversed when no + filespec. + +2025-02-23 GDB Administrator + + Automatic date update in version.in + +2025-02-22 Maximilian Ciric + + MIPS objdump: Recognize o64 ABI names + Add gpr and fpr names for the o64 ABI to objdump. + + With the recent addition of both EABIs, this completes support for the + standard ABI options (ABI-breaking options such as -modd-spreg or + -mabi=32 -mfp64 notwithstanding). The names have been verified against + GCC's usage of the registers. Notably, the only(?) documentation that + defines the o64 ABI at + + https://gcc.gnu.org/projects/mipso64-abi.html + + appears to contain a mistake w.r.t. floating-point arguments. In + particular: + + > If the first and second arguments floating-point arguments to a + > function are 32-bit values, they are passed in $f12 and $f14. + + As from 4.0.0 this does not happen in GCC's implementation of the ABI; + a pair of single-float arguments are still passed in $f12 and $f13, the + same as when one or both of the arguments are double-precision floats. + The registers $f12, $f13 and $f14 have been named $fa0, $fa1 and $ft10 + to match the implementation. + +2025-02-22 GDB Administrator + + Automatic date update in version.in + +2025-02-21 Shahab Vahedi + + gdb/testsuite/rocm.exp: Use system GPU(s) to detect features + gdb/testsuite/rocm.exp: Use system GPU(s) to detect features + + Background + ---------- + This patch revisits the purpose of hcc_amdgpu_targets{} in + order to address the separation of concerns between: + + - GPU targets passed to the compiler. This kind of target + is passed as an argument to flags like "--offload-arch=...", + "--targets=...", etc. + + - GPU targets as in available GPU devices on the system. This + is crucial for finding which capabilities are available, + and therefore which tests should be executed or skipped. + + Code change + ----------- + - A new "find_amdgpu_devices{}" procedure is added. It is + responsible for listing the GPU devices that are available + on the system. + + - "hcc_amdgpu_targets{}" is rewritten to use the newly added + "find_amdgpu_devices{}" when there's no environment variable + (HCC_AMDGPU_TARGET) set. + + - The output of "hcc_amdgpu_targets{}" is now only used in + places that set the target for the building toolchains. + + - The output of "find_amdgpu_devices{}" is used anywhere that + needs to evaluate the GPU features. + + Approved-By: Lancelot Six (amdgpu) + Change-Id: Ib11021dbe674aa40192737ede78284a1bc531513 + +2025-02-21 Jan Beulich + + IQ2000: drop maintainer + After I found his email bouncing, Stan, via private communication which + Nick helped with, has indicated that - having retired - he won't any + longer fulfill the maintainer role here. + +2025-02-21 Jan Beulich + + x86: GOT is an ELF-only entity + Make md_undefined_symbol() conditional upon dealing with ELF, much like + other architectures (e.g. Arm32 and Arm64) have it. This avoids errors + in gas and even assertions in libbfd when "accidentally" e.g. a COFF- + targeting source file uses "_GLOBAL_OFFSET_TABLE_" for whatever reason. + + While there also convert the final return statement to properly use + NULL. + + NB: In principle 64-bit Mach-O knows GOT, too. Yet only an i?86-macho + assembler can be built right now, as per configure.tgt. Pretty clearly + adjustments to gotrel[] would also be necessary before these targets + could actually work reasonably cleanly. + +2025-02-21 Jan Beulich + + ix86: drop dead part of a conditional in elf_i386_convert_load_reloc() + A few lines up we would have already bailed when "baseless && is_pic". + +2025-02-21 Jan Beulich + + ix86: restrict use of GOT32X relocs + The ELF linker rejects use of this reloc type without a base register + for PIC code. Suppress its use by gas in such cases. + + To keep things building for non-ELF, include the entire containing if() + in an #ifdef: All consumers of ->fx_tcbit* live in such conditionals as + well, hence there's no reason to keep the producer active. + +2025-02-21 Jan Beulich + + x86-64: further tighten convert-load-reloc checking + REX2.M affects what insn we're actually dealing with, so we better check + this to avoid transforming (future) insns we must not touch. + + x86: widen @got{,pcrel} support to PUSH and APX IMUL + With us doing the transformation to an immediate operand for MOV and + various ALU insns, there's little reason to then not support the same + conversion for the other two insns which have respective immediate + operand forms. Unfortunately for IMUL (due to the 0F opcode prefix) + there's no suitable relocation, so the pre-APX forms cannot be marked + for relaxation in the assembler. + + x86/APX: use CS: in place of ES: in @gotpcrel and @gottpoff relaxation + H.J. requested this adjustment; I'm unaware of any specific technical + background. + +2025-02-21 Jan Beulich + + ix86: tighten convert-load-reloc checking + Just like was done recently for x86-64 (commit 4998f9ea9d35): Even if + the assembler avoids using the relaxable relocation for inapplicable + insns, the relocation type can still appear for other reasons. Be more + thorough in the opcode checking we do, to avoid bogusly altering other + insns. + + Furthermore correct an opcode mask (even if with the added condition + that's now fully benign). + +2025-02-21 GDB Administrator + + Automatic date update in version.in + +2025-02-20 Simon Marchi + + gdb/doc: fix sentence in save gdb-index` command doc + The part "... this command by default creates it produces a single ..." + sounds wrong. Replace with "... this command by default produces a + single ...". + + Change-Id: I39cc533fa5a2bf473ca9e361ee0e6426d7d37ac6 + +2025-02-20 Tom Tromey + + Fix "compilation unit" matching in dwarf-font-lock-keywords + Today I learned that, at least on my system (Fedora 40), the printf + "%#x" format will produce "0" rather than "0x0" when given 0 as an + argument. + + This causes dwarf-mode.el to not correctly fontify the very first + "Compilation Unit" line it sees. + + This patch adapts dwarf-mode.el. As always, this patch bumps the + version number for easier installation. + + I am checking this in. + +2025-02-20 Simon Marchi + + gdb/doc: fix .debug_index -> .gdb_index + Change-Id: Ibd8d6c35c2cc02e309f83b11b5fd1172dfa05283 + +2025-02-20 Simon Marchi + + gdb/compile: add missing entry in bfd_link_callbacks array + clang 19 fails to build gdb with this error: + + /home/simark/src/binutils-gdb/gdb/compile/compile-object-load.c:302:3: error: cannot initialize a member subobject of type 'void (*)(const char *, ...) __attribute__((noreturn))' with an lvalue of type 'void (const char *, ...)' + 302 | link_callbacks_einfo, /* einfo */ + | ^~~~~~~~~~~~~~~~~~~~ + + This illustrates that the bfd_link_callbacks array is missing an entry + for the "fatal" callback, add it. + + The fatal field was added very recently, in d26161914 ("PR 32603, more + ld -w misbehaviour"). We're lucky that the new callback was marked with + the noreturn attribute and that clang checks that, otherwise this would + have gone unnoticed. + + Change-Id: I68b63d89f2707359e6254da23bdc0776b0e03ba2 + +2025-02-20 Tom Tromey + + Handle optional lines correctly in gdb.ada/complete.exp + While working on another series, I discovered that the existing code + in gdb.ada/complete.exp that conditionally accepts a completion does + not work correctly. The code assumes that wrapping a line in "(...)?" + will make the entire line optional, but really this will only match a + blank line. + + Meanwhile, I needed this same patch for a second series I'm working + on, so I've pulled this out. As it only affects Ada, I am going to + check it in. + +2025-02-20 Tom Tromey + + Small get_tib_address cleanups + I noticed a non-bool-like use of target_get_tib_address in + windows-tdep.c. After fixing this I thought it would be good to + document the target method; and this also lead to some non-bool-like + commentary in remote.c. This patch fixes all of these nits. + + Approved-By: Simon Marchi + +2025-02-20 Guinevere Larsen + + GDB: add stabs deprecation warning + Now that stabs is deprecated, we should probably warn our users of it + before removing support, so that they have time to react and either make + themselves heard, or fix things on their end so that they can still debug + their applications. + + This commit adds a new function that emits a warning whenever GDB does + stabs reading. Since there are several places where stabs is + re-invented, this warning had to be added to many places, but I think I + managed to warn everywhere relevant without duplicating warnings. + + Also, the test gdb.stabs/weird.exp explicitly checks for GDB warnings + when reading stabs, so it had to be updated to account for the + deprecation warning. It is done generically, since it will be removed in + the next release anyway. + + Approved-By: Tom Tromey + +2025-02-20 Alan Modra + + PR 32721, internal error in tc-i386.c:parse_register + pr30117 showed one of the assertions added by 4d1bb7955a8b was too + strict. oss-fuzz also found the second assertion to be too strict, + with this testcase distilled from 7k of garbage source: + + A=%eax%%! + Y=A + Z=A + or $6,Z + + PR 32721 + * config/tc-i386.c (parse_register): Move "know" into + condition. Simplify. + +2025-02-20 Tom Tromey + + Hoist language-finding in expand_symtabs_matching + Right now, cooked_index_functions::expand_symtabs_matching computes + the language for each component of a split name, using the language of + the corresponding entry. + + Instead, I think that we want to do all the comparisons using the + final entry's language. I don't think there's a way to trigger bad + behavior here right now, but with another series I'm working on, we + end up with some entries whose language can't reliably be determined; + and in this case using the final entry's language avoids issues. + + I suspect we could also dispense with the per-segment name-matcher + lookup as well. + +2025-02-20 Tom Tromey + + Move producer checks to dwarf2_cu + This changes the various producer-checking functions to be methods on + dwarf2_cu. It adds a few new caching members as well -- every one + that could reasonably be done this way has been converted, with the + only exception being a gdbarch hook. + + Note the new asserts in the accessors. Without the earlier + prepare_one_comp_unit change, these could trigger in some modes. + +2025-02-20 Tom Tromey + + Make prepare_one_comp_unit a method of cutu_reader + This changes prepare_one_comp_unit to be a private method of + cutu_reader. This should make it somewhat simpler to reason about. + +2025-02-20 Tom Tromey + + Clean up calls to prepare_one_comp_unit + Currently, prepare_one_comp_unit is called somewhat haphazardly: it is + mostly called when a CU is read, but some places manage to instantiate + a cutu_reader* without calling it, and some code (e.g., + read_file_scope) calls it without really needing to. + + Aside from contributing to the general confusion around CU reading, + this doesn't really cause problems in the current tree. However, it + is possible for the DWARF reader to check the CU's producer before it + is ever set -- which is certainly unintended. + +2025-02-20 Tom Tromey + + Move producer_is_realview to producer.c + This moves the producer_is_realview to producer.c. + +2025-02-20 Tom Tromey + + Clean up DW_TAG_namelist handling in new_symbol + In dwarf2/read.c:new_symbol, DW_TAG_namelist is listed in the same + part of the "switch" as other tags. However, it effectively shares no + code with these. This patch splits it into its own case. + + Longer term I think new_symbol should be split up drastically. + +2025-02-20 GDB Administrator + + Automatic date update in version.in + +2025-02-19 Georg-Johann Lay + + gas/config/tc-avr.c: Fix an indentation glitch. + gas/ + * config/tc-avr.c (md_assemble): Fix indentation. + +2025-02-19 Lancelot Six + + gdb/mi: Fix segfault when attaching a rocm process with MI + When using the MI interpreter, if someone was to attach to a ROCm + process which has active GPU waves, GDB would issue a segfault as + follows: + + attach 1994813 + &"attach 1994813\n" + ~"Attaching to process 1994813\n" + =thread-group-started,id="i1",pid="1994813" + =thread-created,id="1",group-id="i1" + =thread-created,id="2",group-id="i1" + ~"[New LWP 1994828]\n" + *running,thread-id="2" + =thread-created,id="3",group-id="i1" + ~"[New LWP 1994825]\n" + *running,thread-id="3" + =thread-created,id="4",group-id="i1" + ~"[New LWP 1994823]\n" + *running,thread-id="4" + ^done + =library-loaded,... + [...] + ~"[Thread debugging using libthread_db enabled]\n" + ~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n" + =thread-created,id="5",group-id="i1" + &"\n\n" + &"Fatal signal: " + &"Segmentation fault" + &"\n" + &"----- Backtrace -----\n" + &"Backtrace unavailable\n" + &"---------------------\n" + &"A fatal error internal to GDB has been detected, further\ndebugging is not possible. GDB will now terminate.\n\n" + &"This is a bug, please report it." + &" For instructions, see:\n" + &"" + &"." + &"\n\n" + Segmentation fault + + The issue comes from using a non-initialized pointer in mi_on_resume_1: + + if (!mi->running_result_record_printed && mi->mi_proceeded) + { + gdb_printf (mi->raw_stdout, "%s^running\n", + mi->current_token ? mi->current_token : ""); + } + + In this instance, "mi->current_token" has an uninitialized value. This is a + regression introduced by: + + commit def2803789208a617c429b5dcf2026decb25ce0c + Date: Wed Sep 6 11:02:00 2023 -0400 + + gdb/mi: make current_token a field of mi_interp + + Before this patch, current_token was a global implicitly 0-initialized. Since + it is now a class field, it is not 0-initialized by default anymore. This + patch changes this. + + Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8 + Approved-By: Simon Marchi + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: add logging for CU expansion + I was trying to get an understanding of which CUs were expanded when, + and how much time it was taking. I wrote this patch to add some logging + related to that, and I think it would be useful to have upstream, to + better understand performance problems related to over-eager CU + expansion, for example. + + - add DWARF_READ_SCOPED_DEBUG_START_END + - use it in process_queue, to wrap the related expansion messages + together + - add a message in maybe_queue_comp_unit when enqueuing a comp unit + - add timing information to messages in process_queue, indicating how + much time it took to expand a given symtab + - count the number of expansions done in a single call to process_queue + + [dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ... + [dwarf-read] process_queue: Expanding symtab of CU at offset 0xc + [dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2 + [dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s + [dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b + [dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s + [dwarf-read] process_queue: Done expanding 2 symtabs. + [dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ... + + Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2 + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: set is_debug_types in signatured_type constructor + This makes it more obvious that all created signatured_type objects have + this flag set. + + Also, remove an unnecessary assignment in create_cus_hash_table: when + constructing the dwarf2_per_cu_data object, is_debug_types is already + initialized to 0/false. + + Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4 + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: pass section to dwarf2_per_cu_data constructor + Same as the previous patch, but for the containing section. + + Change-Id: I469147cce21525d61b3cf6edd9a9f4b12027c176 + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor + Similar to the previous patch, but for the offset within the containing + section. + + Change-Id: I1d76e1f88002bca924e0b12fd78c7ea49d36c0ec + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: pass dwarf2_per_bfd to dwarf2_per_cu_data constructor + Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set + the per_bfd field there. All "real" instantiations of + dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd + backlink, this makes it a bit more obvious. The instantiations of + dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones + used to do hash map lookups and the ones used in selftests. + + Remove an unnecessary assignment of per_bfd in + fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when + the signatured_type object is constructor (before that, it was set in + allocate_signatured_type). + + Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: change some functions from "per objfile" to "per bfd" + I noticed that the following functions accept a "dwarf2_per_objfile", + but they can actually accept a less specific "dwarf2_per_bfd". This + makes it more obvious that the work they do is per BFD and not per + objfile. + + - add_type_unit + - lookup_dwo_file_slot + - create_dwo_unit_in_dwp_v1 + - create_dwp_v2_or_v5_section + - create_dwo_unit_in_dwp_v2 + - create_dwo_unit_in_dwp_v5 + - lookup_dwo_unit_in_dwp + + Change-Id: I200cd77850ce0ffa29fc1b9d924056fdce2559f8 + Approved-By: Tom Tromey + +2025-02-19 Simon Marchi + + gdb/dwarf: std::unordered_{set,map} -> gdb::unordered_{set,map} throughout + No behavior changes expected. + + Change-Id: I16ff6c67058362c65cc8edb05d1948e48be6b2e1 + Approved-By: Tom Tromey + +2025-02-19 Qwinci + + gdb/remote: don't error if qGetTIBAddr is unsupported + This change makes it possible to debug PE executables run in e.g. Qemu + without needing to set osabi to none, it breaks backtrace + and commands like finish if frame pointers are not present but SEH unwind info is. + + Approved-By: Tom Tromey + +2025-02-19 Hui Li + + gdb: LoongArch: Extend the maximum number of hardware watchpoints + The maximum number of load/store watchpoints and fetch instruction + watchpoints is 14 each according to LoongArch Reference Manual [1], + so extend the maximum number of hardware watchpoints from 8 to 14. + + A new struct user_watch_state_v2 was added into uapi in the related + kernel commit 531936dee53e ("LoongArch: Extend the maximum number of + watchpoints") [2], but there may be no struct user_watch_state_v2 in + the system header in time. Modify the struct loongarch_user_watch_state + in GDB which is same with the uapi struct user_watch_state_v2. + + As far as I can tell, the only users for this struct in the userspace + are GDB and LLDB, there are no any problems of software compatibility + between the application and kernel according to the analysis. + + The compatibility problem has been considered while developing and + testing. When the applications in the userspace get watchpoint state, + the length will be specified which is no bigger than the sizeof struct + user_watch_state or user_watch_state_v2, the actual length is assigned + as the minimal value of the application and kernel in the generic code + of ptrace: + + kernel/ptrace.c: ptrace_regset(): + + kiov->iov_len = min(kiov->iov_len, + (__kernel_size_t) (regset->n * regset->size)); + + if (req == PTRACE_GETREGSET) + return copy_regset_to_user(task, view, regset_no, 0, + kiov->iov_len, kiov->iov_base); + else + return copy_regset_from_user(task, view, regset_no, 0, + kiov->iov_len, kiov->iov_base); + + For example, there are four kind of combinations, all of them work well. + + (1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200; + (2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344; + (3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200; + (4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200. + + BTW, LLDB also made this change in the related commit ff79d83caeee + ("[LLDB][LoongArch] Extend the maximum number of watchpoints") [3] + + [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e + [3] https://github.com/llvm/llvm-project/commit/ff79d83caeee + +2025-02-19 Alan Modra + + bintuils/dwarf.c indentation fixes + plus a few other formatting fixes. + +2025-02-19 Alan Modra + + binutils/dwarf.c debug_information leak + It is possible with fuzzed files to have num_debug_info_entries zero + after allocating space for debug_information, leading to multiple + allocations. + + * dwarf.c (process_debug_info): Don't test num_debug_info_entries + to determine whether debug_information has been allocated, + test alloc_num_debug_info_entries. + +2025-02-19 Tankut Baris Aktemur + + gdbserver, remote: introduce "id_str" in the "qXfer:threads:read" XML + GDB prints the target id of a thread in various places such as the + output of the "info threads" command in the "Target Id" column or when + switching to a thread. A target can define what to print for a given + ptid by overriding the `pid_to_str` method. + + The remote target is a gateway behind which one of many various + targets could be running. The remote target converts a given ptid to + a string in a uniform way, without consulting the low target at the + server-side. + + In this patch we introduce a new attribute in the XML that is sent in + response to the "qXfer:threads:read" RSP packet, so that a low target + at the server side, if it wishes, can specify what to print as the + target id of a thread. + + Note that the existing "name" attribute or the "extra" text provided + in the XML are not sufficient for the server-side low target to + achieve the goal. Those attributes, when present, are simply appended + to the target id by GDB. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Thiago Jung Bauermann + Approved-By: Simon Marchi + +2025-02-19 GDB Administrator + + Automatic date update in version.in + +2025-02-18 Alan Modra + + PR32715, ld-elf/pr29072 fail with --disable-default-execstack + --disable-default-stack is an alias for --enable-default-execstack=no. + The existing check only looked for the latter config option. + + PR 32715 + * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Look + in config.h for result of --enable-default-execstack. + +2025-02-18 Alan Modra + + PR32716, objdump -i memory leak + PR binutils/32716 + * bucomm.c (display_info): Free arg.info. + +2025-02-18 Alan Modra + + PR32703, Null pointer dereference in bfd/linker.c + NULL is a possible return from bfd_section_already_linked_table_lookup + if out-of-memory. + + PR 32703 + * linker.c (_bfd_generic_section_already_linked): Catch + bfd_section_already_linked_table_lookup failure. + * coffgen.c (_bfd_coff_section_already_linked): Likewise. + +2025-02-18 Tankut Baris Aktemur + + testsuite, mi: prevent buffer overflow in get_mi_thread_list + If there is a large number of threads in the input program, the expect + buffer in `get_mi_thread_list` would become full. Prevent this by + consuming the buffer in small pieces. + + Regression-tested using the gdb.mi tests. + + Approved-By: Simon Marchi + +2025-02-18 Tom de Vries + + [gdb/testsuite] Don't start gdb in gdb.base/gstack.exp + In test-case gdb.base/gstack.exp we start a gdb implicitly using + prepare_for_testing. + + The gdb is not really used, but its spawn_id (available in variable + gdb_spawn_id) is used in a gdb_test_multiple, which is used to interact with + the gstack process. + + Usually, a running gdb is cleaned up at test-case exit in gdb_finish, which + calls gdb_exit, which by default calls gdb_default_exit, which does + 'send_gdb "quit\n"'. + + However, this sends a quit to the host process expect is currently talking to, + defined by board_info(host,fileid), and after spawning gstack that's gstack, not + gdb. + + Fix this by: + - using build_executable instead of prepare_for_testing to not spawn an unused + gdb, and + - changing the gdb_test_multiple into a gdb_expect, eliminating the implicit use + of gdb_spawn_id. + + Tested on x86_64-linux. + + Reviewed-By: Keith Seitz + + PR testsuite/32709 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709 + +2025-02-18 Tom de Vries + + [gdb] Fix some typos + Fix typos: + ... + overriden -> overridden + reate -> create + ... + + Tested on x86_64-linux. + I + +2025-02-18 H.J. Lu + + ld: Add tests for PR ld/32690 + Without + + commit 230a788eb28a64d628e623068c44add2a24aa5d3 + Author: Alan Modra + Date: Tue Feb 18 08:54:06 2025 +1030 + + PR32690, assertion failure in lang_size_relro_segment + + this test triggers the linker error: + + .../ld: internal error .../ld/ldlang.c 6618 + collect2: error: ld returned 1 exit status + + with GCC 10 or above on x86-64. + + PR ld/32690 + * testsuite/ld-elf/elf.exp: Run PR ld/32690 tests. + * testsuite/ld-elf/pr32690.h: New file. + * testsuite/ld-elf/pr32690a.c: Likewise. + * testsuite/ld-elf/pr32690b.c: Likewise. + +2025-02-18 Alan Modra + + Re: bfd_set_section_alignment errors. + Fix another one for aarch64. + +2025-02-18 Alan Modra + + Use bfd_link_align_section in a few more places + Some of these aren't relevant to the relro bug. Some are. They all + matter if early estimation of section layout needs to be good. + + PR ld/32690 + * elf32-bfin.c (bfin_adjust_dynamic_symbol), + * elf32-hppa.c (elf32_hppa_late_size_sections), + * elf32-microblaze.c (microblaze_elf_adjust_dynamic_symbol), + * elf32-nds32.c (nds32_elf_adjust_dynamic_symbol), + * elf64-ppc.c (size_global_entry_stubs), + * elflink.c (_bfd_elf_tls_setup), + * elfxx-mips.c (mips_elf_add_la25_intro), + (mips_elf_add_la25_trampoline), + (_bfd_mips_elf_adjust_dynamic_symbol), + * elfxx-x86.c (_bfd_x86_elf_late_size_sections): Use + bfd_link_align_section to ensure correct output section + alignment. + +2025-02-18 GDB Administrator + + Automatic date update in version.in + +2025-02-17 Alan Modra + + bfd_set_section_alignment errors + I noticed when making the change from "einfo" to "fatal" that the + alignment error in _bfd_elf_link_create_gnu_property_sec lacked a %P, + and then decided that a bfd_set_section_alignment that can't happen + does not merit a separate error message. elfxx-x86.c had copied the + same code, so fix that too. In fact, every bfd_set_section_alignment + call in elfxx-x86.c will always return true absent some future + programming error. This patch makes those that accompany making a + section lose their "failed to align " error and share the "failed to + create" error. Those that are changing alignment of a section created + elsewhere now abort on bfd_set_section_alignment returning false. + + PR 32603, more ld -w misbehaviour + Commit 8d97c1a53f3d claimed to replace all einfo calls using %F with + a call to fatal. It did so only for the ld/ directory. This patch + adds a "fatal" to linker callbacks, and replaces those calls in bfd/ + too. + +2025-02-17 Alan Modra + + PR32690, assertion failure in lang_size_relro_segment + This introduces a new function which should be used whenever the + linker needs to increase section alignment after mapping input to + output sections. + + PR ld/32690 + * linker.c (bfd_link_align_section): New function. + * elflink.c (_bfd_elf_adjust_dynamic_copy): Use it. + * bfd-in2.h: Regenerate. + +2025-02-17 Simon Marchi + + gdb/dwarf: make maybe_queue_comp_unit return bool + Change-Id: I9a6bf27b72f7efb1cc4cea5345db14969e794bdb + + gdb/dwarf: remove spurious space + Change-Id: I420280721cb734a2e061743309bf9b25d2179f8f + +2025-02-17 Simon Marchi + + gdb: remove unused include in symfile-debug.c + This is reported as unused by clangd. + + Change-Id: Ida5a93b632cd4477fb91df1ab0edf66f12a28f64 + +2025-02-17 Simon Marchi + + gdb: remove unused include in objfiles.h + clangd reports this include as unused. + + Change-Id: I6a4224d8aa581fea2336da124c89ade09f573af3 + +2025-02-17 Tankut Baris Aktemur + + testsuite, mi: fix indentation in get_mi_thread_list + The `get_mi_thread_list` procedure's body is incorrectly indented. + Fix it. + + There is one line that was already long. Consider it an exception and + don't bother breaking it. + +2025-02-17 GDB Administrator + + Automatic date update in version.in + +2025-02-16 Andrew Oates + + gdb: fix color_option_def compile error (clang) + color_option_def was added in commit 6447969d0 ("Add an option with a + color type."), but not used. + + The color_option_def constructor passes the wrong number of arguments + to the option_def constructor. Since color_option_def is a template and + never actually instantiated, GCC does not fail to compile this. clang + generates an error (see below). + + This passes nullptr to the extra_literals_ option_def ctor argument, + which matches what filename_option_def above it does. + + clang's generated error: + ../../gdb/cli/cli-option.h:343:7: error: no matching constructor for initialization of 'option_def' + : option_def (long_option_, var_color, + ^ ~~~~~~~~~~~~~~~~~~~~~~~~ + ../../gdb/cli/cli-option.h:50:13: note: candidate constructor not viable: requires 8 arguments, but 7 were provided + constexpr option_def (const char *name_, + ^ + ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 7 were provided + struct option_def + ^ + ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 7 were provided + + Approved-By: Tom de Vries + +2025-02-16 GDB Administrator + + Automatic date update in version.in + +2025-02-15 Alan Modra + + score-elf gas SEGV + Commit 3fb6f5457e5b typoed an array subscript. + + * config/tc-score7.c (s7_gen_reloc): Correct array subscript. + * testsuite/gas/score/pr32700.d, + * testsuite/gas/score/pr32700.s: New test. + * testsuite/gas/score/relax.exp: Run it. + +2025-02-15 Alan Modra + + PR32698, potential null pointer dereference in tekhex.c + PR 32698 + * tekhex.c (find_chunk): Remove unnecessary casts. + (insert_byte): Check and return status from find_chunk. + (move_section_contents): Likewise. + (tekhex_get_section_contents, tekhex_set_arch_mach): Return + status from move_section_contents. + (first_phase): Check and return status from first_phase. + +2025-02-15 Alan Modra + + riscv disassembler leak + Commit 3f61a38b5e81 moved the disassembler subset_list from a static + variable to disassembler private_data. It is now malloc'd in + riscv_init_disasm_info so should be freed when disassemble_free_target + runs. + + * riscv-dis.c (disassemble_free_riscv): Free subset_list. + +2025-02-15 Anghelo Carvajal + + MIPS objdump: Add `eabi32` and `eabi64` ABI options + Extend gpr and fpr register names with names suitable for both EABIs. + + Heavily inspired by the EABI documenation written by Eric Christopher, + which can be read at + https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html + + 2025-02-15 Anghelo Carvajal + + * mips-dis.c (mips_fpr_names_eabi32): New variable. + (mips_fpr_names_eabi64): New variable. + (mips_abi_choices): Add "eabi32" and "eabi64" options. + +2025-02-15 Maciej W. Rozycki + + MIPS/GAS/testsuite: Reuse n64 GPR disassembly for n32 + The MIPS ABI register names are the same between n64 and n32, so remove + duplication and use n64 GPR disassembly output for the n32 test as well. + The tests were developed long before we gained output reuse support. + + MIPS/GAS: Fix comment about "img" vendor configurations + Adjust a comment about "img" vendor configurations to comply with the + GNU coding standards. + +2025-02-15 Maciej W. Rozycki + + MIPS/GAS: Set default CPU to MIPS64r6 for 64-bit "img" configurations + Fix broken commit 070961b377b3 ("MIPS: Set r6 as default arch if vendor + is img") that sets up GAS in an inconsistent way where "img" vendor has + been used with a 64-bit configuration, such as `mips64-img-linux-gnu'. + In that case GAS is set up to use a 64-bit ABI by default combined with + the MIPS32r6 CPU, which is 32-bit. + + Consequently GAS always fails to assemble even trivial input, producing + a message such as: + + Assembler messages: + Error: -march=mips32r6 is not compatible with the selected ABI + .../gas/testsuite/gas/all/nop.s:2: Error: `gp=32' used with a 64-bit ABI + + unless the defaults have been suitably overridden either for the ABI or + the CPU. + + Set the default CPU to MIPS64r6 for 64-bit "img" vendor configurations + then and adjust the GAS testsuite accordingly, removing 1048 FAIL and 3 + ERROR regression test results for the `mips64-img-linux-gnu' and + `mips64el-img-linux-gnu' targets each. + +2025-02-15 Maciej W. Rozycki + + MIPS/GAS/testsuite: Support negated targets for default architecture + Add support for giving negated targets in the list of targets passed to + `mips_arch_create' for the purpose of setting the default architecture. + This is so that a subset of targets can be excluded from matching within + a broader set of targets. + +2025-02-15 Ivan Kokshaysky + + alpha, ld: remove -taso option + The -taso switch was quite useful 25 years ago for porting 32-bit + code with broken integer-pointer casting. Not anymore. The EF_ALPHA_32BIT + Linux support is going to be dropped in kernel v6.14 [1], NetBSD and OpenBSD + never had it, so there is no point in keeping the -taso option around. + + Also remove alpha special case that uses -taso from gdb.base/dump.exp + in gdb testsuite. + + [1] https://lore.kernel.org/all/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org + + Reviewed-By: Maciej W. Rozycki + Approved-By: Andrew Burgess + +2025-02-15 GDB Administrator + + Automatic date update in version.in + +2025-02-14 Andrew Burgess + + gdb/testsuite: clean ups in gdb.python/py-source-styling.exp + The top comment in gdb.python/py-source-styling.exp was completely + wrong, clearly a cut&paste job from elsewhere. Write a comment that + actually reflects what the test does. + + I've also moved the allow_python_tests check earlier in the file. + + And I changed some 'return -1' into just 'return'. I'm not aware that + the '-1' adds any value. + + I also folded a 'pass $gdb_test_name' into the preceding gdb_assert, + which I think is neater. + + There is no change in what is actually being tested after this commit. + + Approved-By: Tom Tromey + +2025-02-14 Andrew Burgess + + gdb/tui: use maybe_update for source centring in an extra case + I noticed that, with recent versions of GDB, when the TUI is enabled + before the inferior is started, the source code display is not as + helpful as it used to be. Here's a simple test program being + displayed using GDB 15.2, at this point the inferior has not started, + all I've done is 'tui enable': + + ┌─hello.c────────────────────────────────────────────────┐ + │ 10 return 0; │ + │ 11 } │ + │ 12 │ + │ 13 /* The main function. */ │ + │ 14 │ + │ 15 int │ + │ 16 main () │ + │ 17 { │ + │ 18 printf ("Hello World\n"); │ + │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ + │ 20 return 0; │ + │ 21 } │ + │ │ + │ │ + └────────────────────────────────────────────────────────┘ + + Compare this to GDB 16.2: + + ┌─hello.c────────────────────────────────────────────────┐ + │ 17 { │ + │ 18 printf ("Hello World\n"); │ + │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ + │ 20 return 0; │ + │ 21 } │ + │ │ + │ │ + │ │ + │ │ + │ │ + │ │ + │ │ + │ │ + │ │ + └────────────────────────────────────────────────────────┘ + + I think the new layout is not as good because it is missing the + context of the function name. The new behaviour started with the + commit: + + commit 49e607f511c1fab82a0116990a72d1915c74bb4a + Author: Stephan Rohr + Date: Sat Aug 3 02:07:42 2024 -0700 + + gdb: adjust the default place of 'list' to main's prologue + + I don't think the new behaviour is really a problem with that commit, + rather, when using 'tui enable' before the inferior has started GDB + ends up calling tui_source_window_base::rerender(), and then passes + through the code path which calls update_source_window_with_addr(). + + When using 'tui enable' after the inferior has started, GDB again + calls tui_source_window_base::rerender(), but this time has a frame, + and so takes the second code path, which centres the selected source + line, and then calls update_source_window. + + The point is that the update_source_window_with_addr() path doesn't + include the logic to centre the source line. + + Before the above commit this was fine as GDB's default location would + be prior to main, and so we got the "good" TUI output. After the + above commit the default location is now main's prologue, and without + the centring logic, the first line shown is main's prologue. + + I propose fixing this by having update_source_window_with_addr() call + maybe_update(). This will first check if the requested line is + already visible, and if not, show the requested line with centring + applied. + + After this commit, the 'tui enable' state is now: + + ┌─hello.c─────────────────────────────────────────────────────┐ + │ 11 } │ + │ 12 │ + │ 13 /* The main function. */ │ + │ 14 │ + │ 15 int │ + │ 16 main () │ + │ 17 { │ + │ 18 printf ("Hello World\n"); │ + │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ + │ 20 return 0; │ + │ 21 } │ + │ │ + │ │ + │ │ + └─────────────────────────────────────────────────────────────┘ + + It's not identical to the old behaviour, but that was never the + objective, we do however, see the context around main's prologue, + which will usually be enough to see the function name and return type, + which I think is useful. + + Approved-By: Tom Tromey + +2025-02-14 Andrew Burgess + + gdb/tui: update maybe_update to take gdbarch + This is a refactor to setup for the next commit. + + The maybe_update function currently takes a frame_info_ptr&, however, + it only uses this to get the frame's gdbarch. + + In the next commit I want to call maybe_update when I have a gdbarch, + but no frame_info_ptr& (the inferior hasn't even started). + + So, update maybe_update to take the gdbarch, and update the callers to + pass that through. Most callers already have the gdbarch to hand, but + in one place I do need to extract this from the frame_info_ptr&. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2025-02-14 Tom Tromey + + Handle DW_FORM_data4 in read-debug-names.c + The recent .debug_names patches caused the writer to emit + DW_FORM_data4. Unfortunately the reader did not handle this form. + + This patch updates the reader to handle a few DW_FORM_data* forms. + + The complaint that is there went unnoticed -- I only found this when + debugging a failure in another series. More evidence, IMO, that + complaints should be removed. + + I think the reason the failure itself went unnoticed is that the + symbol table code in gdb often works by accident, and in particular in + small programs like the ones in the test suite, it's often the case + that a CU will be expanded for some other reason, causing the test to + pass without really touching the index code. The aforementioned + series is aimed at fixing this. + + It would probably be good to unify the abbrev/form code to some + degree, but it's mildly a pain as some forms don't make sense here and + because we recently discovered other issues with gdb's DW_FORM_data* + handling. + + Approved-By: Simon Marchi + +2025-02-14 Simon Marchi + + gdbserver: use `gdb::unordered_map` + Replace the few uses of `std::unordered_map` in gdbserver with + `gdb::unordered_map`. + + The only one of these that is likely to ever see a lot of elements is + probably `process_info::m_ptid_thread_map`. It was added precisely to + improve performance when there are a lot of threads, so I guess using + `gdb::unordered_map` here won't hurt. I changed the others too, since + it's easy. + + Change-Id: Ibc4ede5245551fdd7717cb349a012d05726f4363 + Reviewed-By: Stephan Rohr + +2025-02-14 Simon Marchi + + gdb/dwarf: unique_ptr cleanup + Throughout gdb/dwarf2, use `*_up` typedefs. Add a few missing typedefs, + and move some so they are, ideally, just after the corresponding class. + + Change-Id: Iab5cd8fc2e9989d4bd8d4868586703c2312f254f + Approved-By: Tom Tromey + +2025-02-14 Simon Marchi + + gdb/dwarf: rename cooked_index_worker subclasses + Rename them to include "worker" in the name. Otherwise, it's easy to be + confused and think that they are sub-classes of "cooked_index". + + Change-Id: I625ef076f9485f3873db530493f60a53d02c1991 + Approved-By: Tom Tromey + +2025-02-14 Simon Marchi + + gdb/dwarf: use term "shard" instead of "index" + A bit more changes as in 8e745eac7db3 ("gdb/dwarf: rename + cooked_index::m_vector to m_shards"). I think it's clearer if the term + "index" is reserved for the whole thing, while "shard" or "index shard" + are used for the parts. + + Change-Id: I457bb0016a70f3f9918f4a3c3977262a7801705b + Approved-By: Tom Tromey + +2025-02-14 Simon Marchi + + gdb/python/dap: prefix internal attributes with underscore + I'm currently reading the DAP code, and I think this would help. This + is pretty much standard Python style, we do it as some places but not + others. I think it helps readability, by saying that this attribute + isn't mean to be accessed outside the class. + + A similar pass could be done for internal methods, I haven't done that. + + Change-Id: I8e8789b39adafe62d14404d19f7fc75e2a364e01 + Approved-By: Tom Tromey + +2025-02-14 Andrew Burgess + + gdb: only update m_last_subfile after writing a line table entry + While working on another patch which changes how we parse the line + DWARF line tables I noticed what I think is a minor bug in how we + process the line tables. + + What I noticed is that my new line table parser was adding more END + markers into the parsed table than GDB's current approach. This + difference was observed when processing the debug information for + libstdc++. + + Here is the line table from the new test, this is a reasonable + reproduction of the problem case that I observed in the actual debug + line table: + + Contents of the .debug_line section: + + dw2-skipped-line-entries-1.c: + File name Line number Starting address View Stmt + dw2-skipped-line-entries-1.c 101 0x40110a x + + /tmp/dw2-skipped-line-entries-2.c: + dw2-skipped-line-entries-2.c 201 0x401114 x + + /tmp/dw2-skipped-line-entries-3.c: + dw2-skipped-line-entries-3.c 301 0x40111e x + + /tmp/dw2-skipped-line-entries-1.c: + dw2-skipped-line-entries-1.c 102 0x401128 x + dw2-skipped-line-entries-1.c 103 0x401128 x + dw2-skipped-line-entries-1.c 104 0x401128 x + + /tmp/dw2-skipped-line-entries-2.c: + dw2-skipped-line-entries-2.c 211 0x401128 + + /tmp/dw2-skipped-line-entries-3.c: + dw2-skipped-line-entries-3.c 311 0x401132 + + /tmp/dw2-skipped-line-entries-1.c: + dw2-skipped-line-entries-1.c 104 0x40113c + dw2-skipped-line-entries-1.c 105 0x401146 x + dw2-skipped-line-entries-1.c - 0x401150 + + The problem is caused by the entry for line 211. Notice that this + entry is at the same address as the previous entries. Further, the + entry for 211 is a non-statement entry, while the previous entries are + statement entries. + + As the entry for line 211 is a non-statement entry, and the previous + entries at that address are statement entries in a different symtab, + it is thought that it is better to prefer the earlier entries (in + dw2-skipped-line-entries-1.c), and so the entry for line 211 will be + discarded. + + As GDB parses the line table it switches between the 3 symtabs (based + on source filename) adding the relevant entries to each symtab. + Additionally, as GDB switches symtabs, it adds an END entry to the + previous symtab. + + The problem then is that, for the line 211 entry, this is the only + entry in dw2-skipped-line-entries-2.c before we switch symtab again. + But the line 211 entry is discarded. This means that GDB switches + from dw2-skipped-line-entries-1.c to dw2-skipped-line-entries-2.c, and + then on to dw2-skipped-line-entries-3.c without ever adding an entry + to dw2-skipped-line-entries-2.c. + + And here then is the bug. GDB updates its idea of the previous symtab + not when an entry is written into a symtab, but every time we change + symtab. + + In this case, when we switch to dw2-skipped-line-entries-3.c we add + the END marker to dw2-skipped-line-entries-2.c, even though no entries + were written to dw2-skipped-line-entries-2.c. At the same time, no + END marker is ever written into dw2-skipped-line-entries-1.c as the + dw2-skipped-line-entries-2.c entry (for line 211) was discarded. + + Here is the 'maint info line-table' for dw2-skipped-line-entries-1.c + before this patch: + + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 101 0x000000000040110a 0x000000000040110a Y + 1 END 0x0000000000401114 0x0000000000401114 Y + 2 102 0x0000000000401128 0x0000000000401128 Y + 3 103 0x0000000000401128 0x0000000000401128 Y + 4 104 0x0000000000401128 0x0000000000401128 Y + 5 104 0x000000000040113c 0x000000000040113c + 6 105 0x0000000000401146 0x0000000000401146 Y + 7 END 0x0000000000401150 0x0000000000401150 Y + + And after this patch: + + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 101 0x000000000040110a 0x000000000040110a Y + 1 END 0x0000000000401114 0x0000000000401114 Y + 2 102 0x0000000000401128 0x0000000000401128 Y + 3 103 0x0000000000401128 0x0000000000401128 Y + 4 104 0x0000000000401128 0x0000000000401128 Y + 5 END 0x0000000000401132 0x0000000000401132 Y + 6 104 0x000000000040113c 0x000000000040113c + 7 105 0x0000000000401146 0x0000000000401146 Y + 8 END 0x0000000000401150 0x0000000000401150 Y + + Notice that we gained an extra entry, the END marker that was added at + position #5 in the table. + + Now, does this matter? I cannot find any bugs that trigger because of + this behaviour. + + So why fix it? First, the current behaviour is inconsistent, as we + switch symtabs, we usually get an END marker in the previous symtab. + But occasionally we don't. I don't like things that are inconsistent + for no good reason. And second, as I said, I want to change the line + table parsing. To do this I want to check that my new parser creates + an identical table to the current parser. But my new parser naturally + "fixes" this inconsistency, so I have two choices, do extra work to + make my new parser bug-compatible with the current one, or fix the + current one. I'd prefer to just fix the current line table parser. + + There's a test that includes the above example and checks that the END + markers are put in the correct place. But as I said, I've not been + able to trigger any negative behaviour from the current solution, so + there's no test that exposes any broken behaviour. + + Approved-By: Tom Tromey + +2025-02-14 Jan Beulich + + x86: drop redundant i.operands checks from output_disp() + The opcode space, major opcode, and - where applicable - opcode + extension checks fully qualify the insns we're after; operand matching + has been done far earlier, so wrong operand counts cannot occur here. + + x86: drop redundant checks from ISA-used version determination + All F16C and all FMA insns are VEX-encoded; there's no need to check + for their Cpu* attributes. + +2025-02-14 Jan Beulich + + x86: correct ISA-used version recording + Updating should be based solely on the current instruction. For example, + recording of VEX-encoded insns as v3 should be independent of there + being earlier AMX insns. + + Further for BASELINE only a very limited set of the + GNU_PROPERTY_X86_FEATURE_2_* bits should actually be taken into account: + Most of the bits represent advanced (later) features (XSAVE, XSAVEOPT, + and XSAVEC for example being part of v3). + +2025-02-14 Jan Beulich + + gas: fix rs_fill_nop listing + In commit a0094f1a70e1 ("gas: make .nops output visible in listing") I + was wrongly assuming fr_fix would be zero for rs_fill_nop, when that's + only a side effect of listing_newline() inserting dummy frags, but only + when file/line did actually change from the previous invocation. This is + in particular not going to be true when the .nops directive isn't the + first statement on a line. + +2025-02-14 Jan Beulich + + x86/APX: make .insn extended-EVEX capable + So far tricks had to be played to use .insn to encode extended-EVEX + insns; the X4 bit couldn't be controlled at all. Extend the syntax just + enough to cover all features, taking care to reject invalid feature + combinations (albeit aiming at being as lax there as possible, to offer + users as much flexibility as we can - we don't, after all, know what + future will bring). + + In a pre-existing testcase replace all but one .byte; the one that needs + to remain wants to have EVEX.U clear in a way that's neither + controllable via AVX10/256 embedded rounding (would otherwise also set + EVEX.ND), nor via the index register (EVEX.X4), as there's no memory + operand. For one of the converted instances ModR/M.mod needs correcting: + An 8-bit displacement requires that to be 1, not 2. Also adjust source + comments to better represent what the bad insns mimic. + +2025-02-14 Kito Cheng + + RISC-V: Add missing doc for OP_V + +2025-02-14 Kito Cheng + + RISC-V: Add OP_VE for .insn + OP_VE is the opcode space for crypto vector instructions. + + Ref: + https://github.com/riscv/riscv-isa-manual/blob/main/src/vector-crypto.adoc#crypto-vector-cryptographic-instructions + +2025-02-14 Hau Hsu + + RISC-V: Make SSAMOSWAP.W available for rv64 + Previously we limited SSAMOSWAP.W only available on RV32, but it should + be available on RV64 as well. + + See + https://github.com/riscv/riscv-cfi/blob/main/src/cfi_backward.adoc + https://github.com/riscv/riscv-isa-manual/blob/702a3e6e843235a2a13b918ae6938b04f8974ffc/src/unpriv-cfi.adoc#L789 + +2025-02-14 GDB Administrator + + Automatic date update in version.in + +2025-02-13 Alan Modra + + dlltool memory leaks + dlltool copies strings with strdup all over the place, seeming to take + the attitude that anything might be modified. That leads to lots of + memory leaks. Fixing the leaks by removing the strdup calls of course + means you need to take good care that strings *aren't* modified. This + isn't as easy as it sounds due to functions like xlate that have + const char* params but then manage to modify the strings. I've fixed + xlate, but if I've missed something somewhere then this patch likely + will break dlltool. Testsuite coverage of dlltool isn't good. + + The leaks in defparse.y are small. It also is a little work to verify + that all the strings I'm freeing in defparse.y are in fact malloc'd, + which is no doubt why the leaks are there. + + Using bfd_xalloc in make_one_lib_file and functions called from there + results in memory being freed automatically at the bfd_close in + make_one_lib_file, without any fuss. + + The patch also makes use of xasprintf to replace xmalloc followed by + sprintf. + + * defparse.y (opt_name2): Free incoming ID strings after + adding prefix/suffix. + * dlltool.c (struct ifunct): Constify char* fields. + (struct iheadt, struct dlist): Likewise. + (set_dll_name_from_def, def_heapsize, def_stacksize), + (def_section, assemble_file): Use xasprintf. + (def_name, def_library): Free dll_name and name. + (def_description, new_directove): Don't strdup incoming args. + (append_import): Likewise. + (def_import): Free module after appending dllext. + (run): Free temp_base. + (scan_filtered_symbols): Don't segfault on NULL strchr return. + Remove unnecessary strdup. + (scan_drectve_symbols): Likewise. Constify pointers. + Use bfd_malloc_and_get_section. Use xmemdup. + (add_excludes): Use xasprintf and xstrdup. + (gen_exp_file): Free xlate return. Constify pointer to suit + struct changes. Free copy. + (xlate): Always copy arg. Use xasprintf and xstrdup. + (make_imp_label): Add bfd arg. Use bfd_xalloc. + (gen_lib_file): Adjust to suit. + (make_one_lib_file): Likewise. Use bfd_xalloc for section data + and relocs. Simplify code calling xlate, and free xlate return. + (dll_name_list_free_contents): Flatten recursion. + (mangle_defs): Free d_export_vec. + (main): Formatting. Use xasprintf. + * resres.c (write_res_id): Free section data. + +2025-02-13 Alan Modra + + gas: replace bfd_alloc with notes_alloc + bfd_alloc can return NULL on out-of-memory so code needs to check the + return value and print an error. That check was missing in write.c. + notes_alloc won't return NULL, instead the underlying obstack_alloc + prints an OOM message and the process exits. This is more convenient, + and when the bfd_alloc memory is attached to the gas output bfd it is + released only slightly before the notes obstack. + + * config/obj-macho.c (obj_mach_o_set_indirect_symbols): Use + notes_calloc rather than bfd_zalloc. + * write.c (set_symtab): Use notes_alloc. + +2025-02-13 Alan Modra + + gas obj-coff memory leaks + This patch addresses memory leaks in gas that show up when running the + testsuite on x86_64-w64-mingw32. The seh_ctx_cur, and weak sym naming + leaks can occur many times during assembly. The symbol hook and + section leaks are not so important since this memory needs to persist + until closing the output bfd. + + * config/obj-coff-seh.c (do_seh_endproc): Free seh_ctx_cur and + its fields. + * config/obj-coff-seh.h (struct seh_context): Remove unused + "next" field. + * config/obj-coff.c (coff_obj_symbol_new_hook): Use notes_alloc + for aux entries. + (coff_obj_symbol_clone_hook): Likewise. + (obj_coff_def): Don't strdup name unless we need to do so + for tc_canonicalize_symbol_name. Free after making symbol. + (weak_name2altname, weak_altname2name): Return a char*. + (weak_uniquify): Use notes_concat. + (pecoff_obj_set_weak_hook, pecoff_obj_clear_weak_hook): Free name + returned by weak_name2altname. + (coff_frob_symbol): Similarly for weak_altname2name. + (obj_coff_section): Use notes_memdup0. + * symbols.h: Add include guard. + (notes_memdup0): New inline function. + +2025-02-13 Tom Tromey + + Remove assumption from py-symbol.exp + The current py-symbol.exp test makes an assumption about which symbol + will be returned first. I don't think gdb should really make promises + about the order in which the symbols are listed, though, and a series + I am working on changes this behavior. This patch changes the test to + merely ensure that both symbols are returned. + + Approved-By: Simon Marchi + +2025-02-13 Kevin Buettner + + Update my maintenance areas in MAINTAINERS file + I've dropped maintenance of the mep target. Additionally, I'm removed + myself as an authorized committer for PowerPC, ia64, AIX, and + GNU/Linux PPC native. + +2025-02-13 Christina Schimpe + + gdb, testsuite: Rename set_sanitizer procedures to append_environment. + The procedures set_sanitizer_1, set_sanitizer and set_sanitizer_default + are used for the configuration of ASAN specific environment variables. + However, they are actually generic. Rename them to append_environment* + so that their purpose is more clear. + + Approved-By: Tom Tromey + +2025-02-13 Klaus Gerlicher + + aarch64: fix a crash during maintenance print cooked-registers + On aarch64 with pauth enabled a crash when can be seen when + using "maintenance print cooked-registers". + + This happens because the register dump code tries to read + a pseudo reg that is not handled here because it is supposedly + only used in unwinding. + + Fix this by returning a zero value typed as a built-in uint64. + + Approved-By: Luis Machado + +2025-02-13 GDB Administrator + + Automatic date update in version.in + +2025-02-12 Tom Tromey + + Reorder gnatmake arguments in inline-section-gc.exp, again + Tom de Vries pointed out that commit 8cfa1fc4 ("Reorder gnatmake + arguments in inline-section-gc.exp") caused a regression with an older + version of dejagnu. + + This patch works around that problem by further reordering the + arguments to gnatmake and also arranging to leave gnatmake in "-margs" + mode. + +2025-02-12 Tom Tromey + + Add copyright header to gnat_debug_info_test.adb + I noticed that gdb/testsuite/lib/gnat_debug_info_test.adb is missing a + copyright header. This adds one, using the date range from the + original commit. + +2025-02-12 Simon Marchi + + gdb: cleanup includes in mi/ + Remove a few includes reported as unused by clangd. + + Change-Id: I7365b7cce04c9ef1a4164764191303914da42ef9 + +2025-02-12 GDB Administrator + + Automatic date update in version.in + +2025-02-11 Rohr, Stephan + + gdb: remove check for minimal symbols in 'start_command' + GDB aborts the 'start' command if the minimal symbols cannot be + resolved. On Windows, GDB reads the minimal symbols from the COFF + header of the PE file. The symbol table is deprecated and the + number of symbols in the COFF header may be zero: + + https://learn.microsoft.com/en-us/windows/win32/debug/pe-format + + This is reproducible with clang version 18.1.8 on Windows: + + clang++ -g -O0 -gdwarf -fuse-ld=lld test.cpp -o test_clang + + The COFF file header shows: + + FILE HEADER VALUES + 8664 machine (x64) + E number of sections + 66E889EC time date stamp Mon Sep 16 21:41:32 2024 + FB400 file pointer to symbol table + 0 number of symbols + F0 size of optional header + 22 characteristics + + GDB is not able to read the minimal symbols; the `start' command fails + with an error: + + (gdb) start + No symbol table loaded. Use the "file" command. + + Manually inserting a breakpoint in main works fine: + + (gdb) tbreak main + Temporary breakpoint 1 at 0x14000100c: file test.cpp, line 6. + (gdb) run + Starting program: C:\test-clang + + Temporary breakpoint 1, main () at test.cpp:6 + 6 std::cout << "Hello World.\n"; + + Remove the check entirely; a 'NOT_FOUND_ERROR' is thrown if 'main' + cannot be resolved. The error is consumed in 'create_breakpoint ()' + and an error message is displayed to the user. + + Approved-by: Kevin Buettner + Reviewed-By: Guinevere Larsen + +2025-02-11 Simon Marchi + + gdb/dwarf: rename cooked_index::m_vector to m_shards + I think that is clearer and helps readability. + + Rename a few iteration variables from "index" or "idx" to "shard". In + my mental model, the "index" is the whole thing, so it's confusing to + use that word when referring to shards. + + Change-Id: I208cb839e873c514d1f8eae250d4a16f31016148 + Approved-By: Tom Tromey + +2025-02-11 Simon Marchi + + gdb/dwarf: remove cooked_index::vec_type + I find this typedef to be confusing. The name is a bit too generic, so + it's not clear what it represents. When using the typedef for a + cooked_index_shard unique pointer, I think that spelling out the vector + type is not overly long. + + Change-Id: I99fdab5cd925c37c3835b466ce40ec9c1ec7209d + Approved-By: Tom Tromey + +2025-02-11 Kito Cheng + + RISC-V: Add .bfloat16 directive + RISC-V already support bfloat16 instruciton like Zfbfmin, Zvfbfmin and + Zvfbfwma, so I think it's reasonable to add .bfloat16 directive to + support bfloat16 data type. + + And the code logic mostly support by common code already. + +2025-02-11 Nelson Chu + + RISC-V: Move all global static target stuff into private data for disassembler. + I got a request said that the JDK multi-thread compiler may be broken + if two or more threads are trying to print/disassemble stuff, and filling + the disassemble_info, setting callbacks, and grabbing the function pointer + to disasm at the same time. Since such as the target global static stuff, + including subset of extensions and mapping symbol stuff, seems to only be + one globally. Ideally, for dis-assembler, all global static target stuff + should/can be better to be defined into the target private data, since they + are target-dependency. + + opcodes/ + * riscv-dis.c: Moved all global static target-dependency stuff into + riscv_private_data, including architecture and mapping symbol stuff. + (set_default_riscv_dis_options): Updated since global static target- + dependency stuff are moved into riscv_private_data. + (parse_riscv_dis_option_without_args): Likewise. + (parse_riscv_dis_option): Likewise. + (parse_riscv_dis_options): Likewise. + (maybe_print_address): Likewise. + (print_reg_list): Likewise. + (riscv_get_spimm): Likewise. + (print_insn_args): Likewise. + (riscv_disassemble_insn): Likewise. + (riscv_update_map_state): Likewise. + (riscv_search_mapping_symbol): Likewise. + (riscv_data_length): Likewise. + (print_insn_riscv): Likewise. Call the riscv_init_disasm_info before + parsing any disassembler options, since the related stuff are moved + into riscv_private_data. + (riscv_init_disasm_info): Likewise. Parse and set the architecture + string and privileged spec version since riscv_get_disassembler is + no longer needed. + (riscv_get_disassembler): Removed. + (disassemble_free_riscv): Only free the subset_list if + riscv_private_data exsits. + * disassemble.c (disassembler): Since riscv_get_disassembler is + removed, call to print_insn_riscv. + * disassemble.h: Removed extern riscv_get_disassembler. + +2025-02-11 GDB Administrator + + Automatic date update in version.in + +2025-02-10 Flavio Cruz + + Port GDB to Hurd x86_64. + This port extends the existing i686 port to support x86_64 by reusing + existing code whenever it makes sense. + + * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and + position of amd64 registers in the different Hurd structs. + The signal code is very similar to i686, except the trampoline code + is adapted. + * gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.h + and adapt it for x86_64. + * gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn + and reuse it for x86_64. + * gdb/configure.host: recognize gnu64 as a host. + * gdb/configure.nat: recognize gnu64 host and update existing i386gnu to + reuse the new shared files. + * gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use + amd64-gnu-tdep.c. + * gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is + copied from i386-gnu-nat.c. This makes it similar to amd64. + * gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this for + i386 and amd64. Updated REG_ADDR to use one of the structures. Added + VALID_REGISTER to make sure it's a register we can provide at this time + (not all of them are available in amd64). FLAGS_REGISTER is either rfl + or efl depending on the arch. Renamed functions and class from i386 to x86 + whenever they can be reused. + + Tested on Hurd x86_64 and i686. + +2025-02-10 Maciej W. Rozycki + + MIPS16/GAS: Streamline forced size suffix handling code + Clean up after commit 112cf77b1855 ("MIPS: use is_whitespace()") and + untangle the code flow in the handling of forced size suffixes, noting + that owing to the loop right above the only data `c' can hold at this + point is '\0', '.', or a white-space character. No functional change. + +2025-02-10 Maciej W. Rozycki + + MIPS16/GAS: Reject instructions that end with a dot + Fix a regression from commit 3fb49709438e ("MIPS16/GAS: Fix forced size + suffixes with argumentless instructions") and reject MIPS16 instructions + that end with a dot and no forced size suffix following, e.g.: + + $ cat test.s + .set mips16 + foo: + break. + entry. + addiu. $2, 0x7fff + addiu. $3, $2, 0 + .align 8, 0 + $ as -32 -o test.o test.s + $ objdump -d test.o + + test.o: file format elf32-tradbigmips + + Disassembly of section .text: + + 00000000 : + 0: e805 break + 2: e809 entry + 4: f7ef 4a1f addiu v0,32767 + 8: 4260 addiu v1,v0,0 + ... + $ + + Add a test accordingly, also verifying invalid forced size suffixes. + +2025-02-10 Maciej W. Rozycki + + MIPS/BFD: Remove redundant "want64=true" settings + Clean up after commit 29c108c96106 ("MIPS: Support `-gnuabi64' target + triplet suffix for 64-bit Linux targets") and discard individual MIPS + "want64=true" settings, the use of which has been superseded by commit + 42429eacb42f ("Require a 64-bit bfd_vma for MIPS ELF") back in 2013[1]. + + References: + + [1] + +2025-02-10 Andrew Burgess + + gdb/tui: use tui_batch_rendering more + While working on the commit: + + commit 4f28b020a3416ac87ac12cf7ae3625a4bc178975 + Date: Wed Feb 5 20:12:03 2025 +0000 + + gdb/tui: use wrefresh if output is not surpressed + + I spotted some places where tui_win_info::refresh_window() was being + called when suppress_output was false. This means that there is no + tui_batch_rendering in place on the call stack, and so, after that + commit, we might be performing more wrefresh() calls than necessary. + + Before the above commit we would have been calling wnoutrefresh() and, + due to the missing tui_batch_rendering, there might have been a delay + before doupdate() was called. + + To (hopefully) make screen updates smoother, this commit adds + tui_batch_rendering in a few places where it is possible that there + might be multiple window updates performed, this will mean the final + write to screen is deferred until the tui_batch_rendering goes out of + scope. + + Other than possibly smother screen updates, there should be no user + visible changes after this commit. + + Approved-By: Tom Tromey + +2025-02-10 Andrew Burgess + + gdb/tui: remove unnecessary wmove call from tui_status_window + I've been looking recently at when the TUI calls wnoutrefresh vs + wrefresh, and the ordering of other screen update actions relative to + these calls. + + I noticed in tui_status_window::rerender() a call to wmove() that is + placed after the refresh_window() call. This surely means that the + cursor is moved, but, this update is not sent to the screen. + + But we call wmove() at the start of tui_status_window::rerender() + before anything is sent to the screen, so the final wmove() call is + pointless as far as I can tell. + + I propose removing it. This is trivial, but removing pointless work + like this slowly makes the TUI code easier to understand. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2025-02-10 Guinevere Larsen + + gdb: Deprecate stabs debug info + GCC has deprecated stabs generation in GCC 12 and entirely removed it in + GCC 13, which was released in April 2023. At the time it was proposed + that GDB deprecate stabs as well, but the decision was to support it a + bit longer. With this patch, it'll be deprecated on GDB 17, and removed + on GDB 18, which following the current cadence, will be released early + 2026, meaning we will have supported stabs for nearly 3 years longer + than GCC, which I think is reasonable. + + As pointed out in the previous discussion on this topic[1], there are + several existing issues on the code, and none of the current maintainers + knows how to fix it. Unless someone steps up to fix this before the + removal on GDB 18, I don't see why we should keep this old code that + breaks all conventions of modern debuginfo readers and doesn't even + work, instead of being able to further advance adjacent code. + + Finally, deprecating and removing stabs will make a.out/dbx inferiors be + essentially unsupported, as the only debuginfo GDB supports for those + formats is stabs, meaning users would only have assembly-level debugging + for that format. With that in mind, this commit deprecates the a.out/dbx + format as well. + + [1] https://inbox.sourceware.org/gdb-patches/20230119174156.654402-1-tom@tromey.com/ + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210 + Approved-By: Tom Tromey + +2025-02-10 Simon Marchi + + gdb/dwarf: create multiple cooked index shards when reading .debug_names + New in v2: + + - install address map in a single shard + - update test gdb.mi/mi-sym-info.exp to cope with the fact that + different symbols could be returned when using --max-results + + When playing with the .debug_names reader, I noticed it was + significantly slower than the DWARF scanner. Using a "performance" + build of GDB (with optimization, no runtime sanitizer enabled, etc), I + measure with the following command on a rather large debug info file + (~4 GB): + + $ time ./gdb -q -nx --data-directory=data-directory -iex 'maint set dwarf sync on' -batch + + This measures the time it takes for GDB to build the cooked index (plus + some startup and exit overhead). I have a version of the binary without + .debug_names and a version with .debug_names added using gdb-add-index. + The results are: + + - without .debug_names: 7.5 seconds + - with .debug_names: 24 seconds + + This is a bit embarrassing, given that the purpose of .debug_names is to + accelerate things :). The reason is that the .debug_names processing is + not parallelized at all, while the DWARF scanner is heavily + parallelized. + + The process of creating the cooked index from .debug_names is roughly in + two steps: + + 1. scanning of .debug_names and creation of cooked index entries (see + mapped_debug_names_reader::scan_all_names) + 2. finalization of the index, name canonicalization and sorting of the + entries (see cooked_index::set_contents). + + This patch grabs a low hanging fruit by creating multiple cooked index + shards instead of a single one during step one. Just doing this allows + the second step of the processing to be automatically parallelized, as + each shard is sent to a separate thread to be finalized. + + With this patch, I get: + + - without .debug_names: 7.5 seconds + - with .debug_names: 9.7 seconds + + Not as fast as we'd like, but it's an improvement. + + The process of scanning .debug_names could also be parallelized to shave + off a few seconds. My profiling shows that out of those ~10 seconds of + excecution, about 6 are inside scan_all_names. Assuming perfect + parallelization with 8 threads, it means that at best we could shave + about 5 seconds from that time, which sounds interesting. I gave it a + shot, but it's a much more intrusive change, I'm not sure if I will + finish it. + + This patch caused some regressions in gdb.mi/mi-sym-info.exp with the + cc-with-debug-names board, in the test about the `--max-results` switch. + It appears at this test is relying on the specific symbols returned when + using `--max-results`. As far as I know, we don't guarantee which + specific symbols are returned, so any of the matching symbols could be + returned. + + The round robin method used in this patch to assign index entries to + shards ends up somewhat randomizing which CU gets expanded first during + the symbol search, and therefore which order they appear in the + objfile's CU list, and therefore which one gets searched first. + + I meditated on whether keeping compunits sorted within objfiles would + help make things more stable and predictable. It would somewhat, but it + wouldn't remove all sources of randomness. It would still possible for + a call to `expand_symtabs_matching` to stop on the first hit. Which + compunit gets expanded then would still be dependent on the specific + `quick_symbol_functions` internal details / implementation. + + Commit 5b99c5718f1c ("[gdb/testsuite] Fix various issues in + gdb.mi/mi-sym-info.exp") had already started to make the test a bit more + flexible in terms of which symbols it accepts, but with this patch, I + think it's possible to get wildly varying results. I therefore modified + the test to count the number of returned symbols, but not expect any + specific symbol. + + Change-Id: Ifd39deb437781f72d224ec66daf6118830042941 + Approved-By: Tom Tromey + +2025-02-10 Simon Marchi + + gdb/dwarf: allow for cooked_index_shard::m_addrmap to be nullptr + The following patch makes the .debug_names reader create multiple cooked + index shards, only one of them having an address map. The others will + have a nullptr address map. + + Change the code using cooked_index_shard::m_addrmap to account for the + fact that it can be nullptr. + + Change-Id: Id05b974e661d901dd43bb5ecb3a8fcfc15abc7ed + Approved-By: Tom Tromey + +2025-02-10 Simon Marchi + + gdb/dwarf: write offset to parent entry for DW_IDX_parent + New in v2: + + - add doc + - fix computation of offset in entry pool + + Due to a mistake in the DWARF 5 spec, the way that GDB interprets + DW_IDX_parent when generating and reading .debug_names is not correct. + + In Section 6.1.1.2, the parent index entry attribute is described as: + + Parent debugging information entry, a reference to the index entry for + the parent. This is represented as the offset of the entry relative to + the start of the entry pool. + + But in Table 6.1, DW_IDX_parent is described as: + + Index of name table entry for parent + + These two contradict each other. The former is the correct one and the + latter is an unfortunate leftover from an earlier version of the + proposal, according to [1]. It does make sense, because pointing to a + name table entry is ambiguous, while poiting to an index entry directly + is not. Unfortunately, GDB implemented pointing to a name table entry. + + Changes on the writer side: + + - For each written pool entry, remember the offset within the pool. + + - Change the DW_IDX_parent form to DW_FORM_data4. + + Using DW_FORM_udata isn't an option, because we don't know the actual + value when doing the first pass of writing the pool (see next point), + so we wouldn't know how many bytes to reserve, if we used a + variable-size encoding. + + Using a fixed 4 bytes encoding would be an issue if the entry pool + was larger than 4 GiB, but that seems unlikely. + + Note that clang uses DW_FORM_ref4 for this, but I'm not sure it is + appropriate, since forms of the reference class are specified as + referring "to one of the debugging information entries that describe + the program". Since we're not referring to a DIE, I decided to stay + with a form of the "constant" class. I think that readers will be + able to understand either way. + + - Write a dummy 4 byte number when writing the pool, then patch those + values later. This is needed because parents can appear before their + children in the pool (there's no way to ensure that parents always + appear before their children), so we might now know at first what + value to put in. + + - Add a `write_uint` method to `class data_buf` to support that use + case of patching a value in the middle of the data buffer. + + - Simplify the type of `m_name_to_value_set`, we no longer need to + track the index at which a name will be written at. + + - Produce a new augmentation string, "GDB3", to be able to distinguish + "old" and "new" indexes. It would be possible for a reader to + distinguish the two semantics of DW_IDX_parent using the form. + However, current versions of GDB don't do that, so they would be + confused trying to read a new index. I think it is preferable to use + a new augmentation string so that they will reject a new index + instead. + + Changes on the reader side: + + - Track the GDB augmentation version, in addition to whether the + augmentation string indicates the index was produced by GDB. + + - When reading index entries, maintain a "pool offset" -> "cooked index + entry" mapping, to be able to find parents by pool offset. + + - When resolving parents, keep the existing behavior of finding parents + by name table index if the augmentation string is "GDB2. Otherwise, + look up parents by pool offset. This assumes that .debug_names from + other producers (if/when we add support for reading them) use pool + offsets for DW_IDX_parent. This at least what clang does. + + - Simplify augmentation string comparison a bit by using array views. + + Update the "Extensions to ‘.debug_names’" section of the documentation + to reflect the new augmentation string version. + + Tested by: + + - manually producing executables with "GDB2" and "GDB3" .debug_names + sections and reading them. + - running the testsuite with the cc-with-debug-names board + + [1] https://lists.dwarfstd.org/pipermail/dwarf-discuss/2025-January/002618.html + + Change-Id: I265fa38070b86ef320e0a972c300d1d755735d8d + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2025-02-10 Simon Marchi + + gdbsupport: add gdb::make_array_view overload to create from an array + I think this overload will be useful for the following reasons. + Consider a templated function like this: + + template + void func(gdb::array_view view) {} + + Trying to pass an array to this function doesn't work, as template + argument deduction fails: + + test.c:698:8: error: no matching function for call to ‘func(int [12])’ + 698 | func (array); + | ~~~~~^~~~~~~ + test.c:686:6: note: candidate: ‘template void func(gdb::array_view)’ + 686 | void func(gdb::array_view view) {} + | ^~~~ + test.c:686:6: note: template argument deduction/substitution failed: + test.c:698:8: note: mismatched types ‘gdb::array_view’ and ‘int*’ + 698 | func (array); + | ~~~~~^~~~~~~ + + Similarly, trying to compare a view with an array doesn't work. This: + + int array[12]; + gdb::array_view view; + + if (view == array) {} + + ... fails with: + + test.c:698:8: error: no matching function for call to ‘func(int [12])’ + 698 | func (array); + | ~~~~~^~~~~~~ + test.c:686:6: note: candidate: ‘template void func(gdb::array_view)’ + 686 | void func(gdb::array_view view) {} + | ^~~~ + test.c:686:6: note: template argument deduction/substitution failed: + test.c:698:8: note: mismatched types ‘gdb::array_view’ and ‘int*’ + 698 | func (array); + | ~~~~~^~~~~~~ + + With this new overload, we can do: + + func (gdb::make_array_view (array)); + + and + + if (view == gdb::make_array_view (array)) {} + + This is not ideal, I wish that omitting `gdb::make_array_view` would + just work, but at least it allows creating an array view and have the + element type automatically deduced from the array type. + + If someone knows how to make these cases "just work", I would be happy + to know how. + + Change-Id: I6a71919d2d5a385e6826801d53f5071b470fef5f + Approved-By: Tom Tromey + +2025-02-10 Hui Li + + gdb: LoongArch: Improve the handling of atomic sequence + In the current code, when using software single-step to debug atomic + instruction sequence, the execution of the atomic instruction sequence + may not be completed normally. + + Here is a test with setting a software watchpoint to execute in software + single-step mode: + + $ cat test.c + int a = 0; + int main() + { + a = 1; + return 0; + } + $ gcc -g test.c -o test + $ gdb test + .. + (gdb) start + .. + Temporary breakpoint 1, main () at test.c:4 + 4 a = 1; + (gdb) set can-use-hw-watchpoints 0 + (gdb) n + 5 return 0; + (gdb) watch a + Watchpoint 2: a + (gdb) c + Continuing. + + At this point, the program continues to execute and can not exit + normally because it incorrectly handled the following ll/sc atomic + sequence in __run_exit_handlers () from /lib64/libc.so.6 during + software single-step execution. + + 0x00007ffff7df7a48 <+408>: ld.d $t1, $s2, 1776 + 0x00007ffff7df7a4c <+412>: ll.w $t0, $t1, 0 + => 0x00007ffff7df7a50 <+416>: bne $t0, $zero, 20 # 0x7ffff7df7a64 <__run_exit_handlers+436> + 0x00007ffff7df7a54 <+420>: or $t3, $zero, $s4 + 0x00007ffff7df7a58 <+424>: sc.w $t3, $t1, 0 + 0x00007ffff7df7a5c <+428>: beq $zero, $t3, -16 # 0x7ffff7df7a4c <__run_exit_handlers+412> + 0x00007ffff7df7a60 <+432>: b 8 # 0x7ffff7df7a68 <__run_exit_handlers+440> + 0x00007ffff7df7a64 <+436>: dbar 0x700 + 0x00007ffff7df7a68 <+440>: slli.w $t0, $t0, 0x0 + + The root cause of this problem is that a breakpoint was inserted in the + middle of ll/sc atomic sequence during software single-step execution. + The execution result of the atomic instruction sequence is disrupted, + causing the program unable to complete the execution of the atomic + instruction sequence normally. + + Further explanation, if the current pc is 0x00007ffff7df7a50, it is a + conditional branch instruction, breakpoint should only be set at the + jump destination address (0x00007ffff7df7a64, which is outside of the + ll/sc atomic instruction sequence) and should not set at the address + of pc + 4 (0x00007ffff7df7a54, which is in the middle of ll/sc atomic + sequence). + + Modify a judgment condition in loongarch_deal_with_atomic_sequence() + to ensure that breakpoints can not be inserted in the middle of ll/sc + atomic sequence to address such issues. + +2025-02-10 Andrew Burgess + + gdb: fix selecting tail-call frames by name + I noticed that attempting to select a tail-call frame using 'frame + function NAME' wouldn't work: + + (gdb) bt + #0 func_that_never_returns () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:49 + #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 + #2 0x00000000004011a5 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:70 + (gdb) frame function func_that_tail_calls + No frame for function "func_that_tail_calls". + (gdb) up + #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 + 59 func_that_never_returns (); + (gdb) disassemble + Dump of assembler code for function func_that_tail_calls: + 0x000000000040117a <+0>: push %rbp + 0x000000000040117b <+1>: mov %rsp,%rbp + 0x000000000040117e <+4>: call 0x40116c + End of assembler dump. + (gdb) + + The problem is that the 'function' mechanism uses get_frame_pc() and + then compares the address returned with the bounds of the function + we're looking for. + + So in this case, the bounds of func_that_tail_calls are 0x40117a to + 0x401183, with 0x401183 being the first address _after_ the function. + + However, because func_that_tail_calls ends in a tail call, then the + get_frame_pc() is 0x401183, the first address after the function. As + a result, GDB fails to realise that frame #1 is inside the function + we're looking for, and the lookup fails. + + The fix is to use get_frame_address_in_block, which will return an + adjusted address, in this case, 0x401182, which is within the function + bounds. Now the lookup works: + + (gdb) frame function func_that_tail_calls + #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 + 59 func_that_never_returns (); + (gdb) + + I've extended the gdb.base/frame-selection.exp test to cover this + case. + +2025-02-10 Alan Modra + + tc-i386.c fix for oss-fuzz gas fuzzing + oss-fuzz fuzz_as is seriously broken with respect to gas static + variables, so much so that most fuzz_as reports should simply be + ignored. This patch is a fix for + https://oss-fuzz.com/testcase-detail/6268463220654080 + + * config/tc-i386.c (i386_md_end): Clear GOT_symbol. + +2025-02-10 H.J. Lu + + x86-64: Use x86_64_elf_howto_table for standard relocations + For standard relocations, use x86_64_elf_howto_table, instead of calling + elf_x86_64_rtype_to_howto. + + * elf64-x86-64.c (elf_x86_64_tls_transition): Use + x86_64_elf_howto_table, instead of elf_x86_64_rtype_to_howto. + (elf_x86_64_convert_load_reloc): Use x86_64_elf_howto_table, + instead of elf_x86_64_rtype_to_howto, for R_X86_64_PC32. + +2025-02-10 GDB Administrator + + Automatic date update in version.in + +2025-02-09 Tom Tromey + + Add dwarf2_per_bfd::start_reading + The cooked index "start_reading" method can only be called after the + dwarf2_per_bfd "index_table" member is set. This patch refactors this + code a little to centralize this constraint, adding a new + dwarf2_per_bfd::start_reading method and another (virtual) method to + dwarf_scanner_base. + + This removes some casts, but also is also useful to support another + series I'm working on where the .gdb_index is rewritten. + + Approved-By: Simon Marchi + +2025-02-09 Andrew Burgess + + gdb/testsuite: avoid incorrect symbols in gdb.base/condbreak-multi-context.cc + In a different series I tweak how disabled_by_cond is handled in + update_breakpoint_locations for code_breakpoint objects, see: + + https://inbox.sourceware.org/gdb-patches/cover.1734366277.git.aburgess@redhat.com + + But when I did this I ran into a regression in the test script + gdb.base/condbreak-multi-context.cc which I think is actually an issue + with this test. + + The test relies on creating a multi-location breakpoint with a + condition and having GDB disable some of the locations as the + condition is only valid in some of the locations. + + Here's an example of the test creating one such breakpoint: + + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context... + (gdb) break func if a == 10 + warning: failed to validate condition at location 1, disabling: + No symbol "a" in current context. + warning: failed to validate condition at location 3, disabling: + No symbol "a" in current context. + Breakpoint 1 at 0x401142: func. (3 locations) + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y + stop only if a == 10 + 1.1 N* 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23 + 1.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31 + 1.3 N* 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39 + (*): Breakpoint condition is invalid at this location. + (gdb) + + Notice that only location 1.2 is actually enabled, 1.1 and 1.3 are + disabled due to the condition 'a == 10' not being valid. + + However, notice that this b/p is created before GDB has started the + inferior. What I noticed is that if I first start the inferior then I + get a different behaviour: + + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context... + (gdb) start + Temporary breakpoint 1 at 0x40110e: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc, line 49. + Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/condbreak-multi-context/condbreak-multi-context + + Temporary breakpoint 1, main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:49 + 49 aobj.func (); + (gdb) break func if a == 10 + Breakpoint 2 at 0x401142: func. (3 locations) + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 breakpoint keep y + stop only if a == 10 + 2.1 y 0x0000000000401142 in Base::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:23 + 2.2 y 0x000000000040114e in A::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:31 + 2.3 y 0x000000000040115a in C::func() at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/condbreak-multi-context.cc:39 + (gdb) + + Notice that now all three locations are valid. + + What's actually happening is that, on my machine libm.so contains a + global symbol 'a' which for 2.1 and 2.3 is being used to satisfy the + condition. + + I don't believe this is actually the intention of the test, this is + just an unfortunate consequence of name collision. + + The test actually relies on the local variables 'a' and 'c', and my + libm.so contains a global version of both. + + So I propose that we just update the test, I've gone for the super + inventive 'aaa' and 'ccc'. With this change, after starting the + inferior I now see the expected behaviour where only one of the three + locations is enabled. + + However, while I'm fixing this I figure that it would be nice if the + test checked both cases, creating the breakpoints before starting the + inferior, and after starting the inferior. + + So I've updated the test to check both cases. This has meant + converting the mostly linear test script into a set of parameterised + functions which I then call with a flag to indicate if the inferior + should be started before of after creating the breakpoints. + + Approved-By: Tom Tromey + Tested-By: Hannes Domani + +2025-02-09 H.J. Lu + + x86: Return error for invalid relocation offset + Return error if relocation offset + relocation size > section size. + + bfd/ + + PR ld/32665 + * elf32-i386.c (elf_i386_scan_relocs): Return error for invalid + relocation offset. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + + ld/ + + PR ld/32665 + * testsuite/ld-x86-64/pr32665.err: New file. + * testsuite/ld-x86-64/pr32665.o.bz2: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run PR ld/32665 test. + +2025-02-09 Alan Modra + + Fix typo in objdump info/man page + +2025-02-09 Richard Allen + + gprof: fix odd inst len hist scale calculation + With even instruction sizes, this rounding never truncated. + Xtensa CPUs mostly use 2-3 byte instructions, and this can lead + to a histogram being captured with an odd length address range. + + This small truncation prevented gprof from parsing gmon.out files + containing multiple histograms when at least one of them has an + odd address range length and another has any other address range. + +2025-02-09 Richard Allen + + gprof: print values of mismatched histogram scales + + gprof: fix comment typos + + gprof: add missing newline to error text + +2025-02-09 Alan Modra + + PR32664, compressed debug section naming confusion + The pr326664 fuzzer testcase has two .debug_info sections, one + SHF_ALLOC, one not. SEC_DEBUGGING is never set for SHF_ALLOC sections + that happen to be named .debug_info, nor are they compressed. However + in this case we get an output section that is both SEC_ALLOC and + SEC_DEBUGGING which confuses code setting up the output section names + (.zdebug_* for compressed debug sections), resulting in a -1u index + into a string table. + + PR 32664 + * elf.c (elf_fake_sections): Do not delay naming of SEC_ALLOC + sections. + +2025-02-09 Andrew Burgess + + gdb/mi: include ranges in =library-unloaded event + Having looked at the dlmopen support in GDB, it occurred to me that + the current MI =library-unloaded event doesn't incude enough + information to be useful. + + Consider the gdb.mi/mi-dlmopen.exp test, this test loads libraries + into multiple linker namespaces, and then unloads these libraries. + + We should probably figure out a way to include the linker namepsace ID + in GDB's output, e.g. in the =library-loaded and =library-unloaded MI + events, and in the output of 'info sharedlibrary'. But this commit is + not about doing that. + + This commit includes the 'ranges' information in the =library-unloaded + event output. This is the same ranges information as is included in + the =library-loaded output. Even without the linker namespace ID, + this should allow MI consumers to figure out which library instance is + being unloaded. + + Here is the 'info sharedlibrary' output for mi-dlmopen.exp at the + point where all the shared libraries are loaded: + + info sharedlibrary + &"info sharedlibrary\n" + ~"From To Syms Read Shared Object Library\n" + ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" + ~"0x00007ffff7eda3d0 0x00007ffff7f4e898 Yes /lib64/libm.so.6\n" + ~"0x00007ffff7d0e800 0x00007ffff7e6dccd Yes /lib64/libc.so.6\n" + ~"0x00007ffff7fbd040 0x00007ffff7fbd116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" + ~"0x00007ffff7fb8040 0x00007ffff7fb80f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" + ~"0x00007ffff7bfe3d0 0x00007ffff7c72898 Yes /lib64/libm.so.6\n" + ~"0x00007ffff7a32800 0x00007ffff7b91ccd Yes /lib64/libc.so.6\n" + ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" + ~"0x00007ffff7fb3040 0x00007ffff7fb3116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" + ~"0x00007ffff7fae040 0x00007ffff7fae0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" + ~"0x00007ffff7ce1040 0x00007ffff7ce1116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" + ~"0x00007ffff7cdc040 0x00007ffff7cdc0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" + ~"0x00007ffff79253d0 0x00007ffff7999898 Yes /lib64/libm.so.6\n" + ~"0x00007ffff7759800 0x00007ffff78b8ccd Yes /lib64/libc.so.6\n" + ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" + ~"0x00007ffff7cd7040 0x00007ffff7cd7116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so\n" + ^done + (gdb) + + Notice that dlmopen-lib.1.so is loaded multiple times. Here is the + =library-unloaded event when one copy of this library is unloaded + before this patch: + + =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + thread-group="i1", + + It is not possible, given this information, to know which copy of + dlmopen-lib.1.so has actually been unloaded. An MI consumer would + need to query the full shared library list and update from that + information. + + After this patch the new output is: + + =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", + thread-group="i1", + ranges=[{from="0x00007ffff7fbd040",to="0x00007ffff7fbd116"}], + still-in-use="false" + + The new 'ranges' field allows an MI consumer to uniquely identify + which library instance was just unmapped. A frontent could, + e.g. update a library list with no need to query the full shared + library list. + + To include the 'ranges' field I updated mi_interp::on_solib_unloaded + to call a new helper function. The new helper function is split out + from the existing mi_output_solib_attribs. I was tempted to just call + mi_output_solib_attribs, but doing so would mean that the + 'symbols-loaded' field was also added to the =library-unloaded event, + however, the docs for 'symbols-unloaded' on =library-loaded says: + + The @var{symbols-loaded} field is emitted only for backward + compatibility and should not be relied on to convey any useful + information. + + And it seemed silly to add a fields to =library-unloaded, which I + would then document as something that should be ignored. The new + helper function means I can avoid emitting the 'symbols-loaded' + field. + + I have also added a 'still-in-use' field. When true this indicates + that the library was removed from the inferior's library list, but the + mapping was not removed from the inferior's address space as there is + another copy of the library that is still using the library. In the + above list, notice that ld-linux-x86-64.so.2 appears 3 times, but each + instance is mapped as 0x00007ffff7fca000. When one copy of + ld-linux-x86-64.so.2 is unloaded, here's the event: + + =library-unloaded,id="/lib64/ld-linux-x86-64.so.2", + target-name="/lib64/ld-linux-x86-64.so.2", + host-name="/lib64/ld-linux-x86-64.so.2", + thread-group="i1", + ranges=[{from="0x00007ffff7fca000",to="0x00007ffff7ff03f5"}], + still-in-use="true" + + The 'still-in-use' field is 'true', this indicates there are at least + one instance of this library remaining mapped at 0x00007ffff7fca000. + + Reviewed-By: Eli Zaretskii + +2025-02-09 Andrew Burgess + + gdb: include a still-mapped flag in solib unload notification + Consider the gdb.base/dlmopen.exp test case. The executable in this + test uses dlmopen to load libraries into multiple linker namespaces. + + When a library is loaded into a separate namespace, its dependencies + are also loaded into that namespace. + + This means that an inferior can have multiple copies of some + libraries, including the dynamic linker, loaded at once. + + However, glibc optimises at least the dynamic linker case. Though the + library appears to be mapped multiple times (it is in the inferior's + solib list multiple times), there is really only one copy mapped into + the inferior's address space. Here is the 'info sharedlibrary' output + on an x86-64/Linux machine once all the libraries are loaded: + + (gdb) info sharedlibrary + From To Syms Read Shared Object Library + 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7eda3d0 0x00007ffff7f4e898 Yes /lib64/libm.so.6 + 0x00007ffff7d0e800 0x00007ffff7e6dccd Yes /lib64/libc.so.6 + 0x00007ffff7fbd040 0x00007ffff7fbd116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so + 0x00007ffff7fb8040 0x00007ffff7fb80f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so + 0x00007ffff7bfe3d0 0x00007ffff7c72898 Yes /lib64/libm.so.6 + 0x00007ffff7a32800 0x00007ffff7b91ccd Yes /lib64/libc.so.6 + 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7fb3040 0x00007ffff7fb3116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so + 0x00007ffff7fae040 0x00007ffff7fae0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so + 0x00007ffff7ce1040 0x00007ffff7ce1116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so + 0x00007ffff7cdc040 0x00007ffff7cdc0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so + 0x00007ffff79253d0 0x00007ffff7999898 Yes /lib64/libm.so.6 + 0x00007ffff7759800 0x00007ffff78b8ccd Yes /lib64/libc.so.6 + 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 + 0x00007ffff7cd7040 0x00007ffff7cd7116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.2.so + + Notice that every copy of /lib64/ld-linux-x86-64.so.2 is mapped at the + same address. + + As the inferior closes the libraries that it loaded, the various + copies of the dynamic linker will also be unloaded. + + Currently, when this happens GDB calls notify_solib_unloaded, which + triggers the gdb::observers::solib_unloaded observer. This observer + will call disable_breakpoints_in_unloaded_shlib (in breakpoint.c), + which disables any breakpoints in the unloaded solib. + + The problem with this, is that, when the dynamic linker (or any solib) + is only really mapped once as is the case here, we only want to + disable breakpoints in the library when the last instance of the + library is unloaded. + + The first idea that comes to mind is that GDB should not emit the + solib_unloaded notification if a shared library is still in use, + however, this could break MI consumers. + + Currently, every time a copy of ld-linux-x86-64.so.2 is unloaded, + GDB's MI interpreter will emit a =library-unloaded event. An MI + consumer might use this to update the library list that it displays to + the user, and fewer notify_solib_unloaded calls will mean fewer MI + events, which will mean the MI consumer's library list could get out + of sync with GDB. + + Instead I propose that we extend GDB's solib_unloaded event to add a + new flag. The new flag indicates if the library mapping is still in + use within the inferior. Now the MI will continue to emit the + expected =library-unloaded events, but + disable_breakpoints_in_unloaded_shlib can check the new flag, when it + is true (indicating that the library is still mapped into the + inferior), no breakpoints should be disabled. + + The other user of the solib_unloaded observer, in bsd-uthread.c, + should, I think, do nothing if the mapping is still in use. This + observer is also disabling breakpoints when a library is unloaded. + + Most of the changes in this commit relate to passing the new flag + around for the event. The interesting changes are mostly in solib.c, + where the flag value is determined, and in breakpoint.c and + bsd-uthread.c, where the flag value is read. + + There's a new MI test, the source of which is mostly copied from the + gdb.base/dlmopen.exp test. This new test is checking we see all the + expected =library-unloaded events. + +2025-02-09 Andrew Burgess + + gdb/testsuite: restructure gdb.base/dlmopen.exp + In the next commit I want to add more tests to the dlmopen.exp script. + Doing this will be easier if the dlmopen.exp script was structured so + that the current tests were contained inside separatate procs. So + this commit moves all of the current tests within dlmopen into two + procs, and then calls these. + + There should be no changes to what is actually being tested in this + commit. + +2025-02-09 Michael Weghorn + + gdb: Support some escaping of args with startup-with-shell being off + I (Andrew Burgess) have taken this patch from this series: + + https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ + + I started off reviewing that series, but wanted to explore some + alternative strategies for solving the problems this series addresses. + However, this patch I think is super useful, so I've taken it mostly + as it was in the original series. + + I have made a few minor cleanups, and I've also added some more tests. + Any bugs should be considered mine (Andrew's), but I've left the + original author (Michael Weghorn) in place as the GDB side changes are + mostly their work. + + The function execv_argv::init_for_no_shell (gdb/nat/fork-inferior.c), + is passed a single string ALLARGS containing all of the inferior + arguments, and contains some custom code for splitting this argument + string into a vector of separate arguments. This function is used + when startup-with-shell is off (which is not the default). + + The algorithm in this function was just splitting on whitespace + characters, and ignoring any quoting, so for example: + + (gdb) set startup-with-shell off + (gdb) set args "first arg" second_arg + + would result in three arguments ("first), (arg"), and (second_arg) + being passed to the inferior (the parenthesis are not part of the + parsed arguments). + + This commit replaces this custom argument splitting with a use of the + existing gdb_argv class (which uses the libiberty buildargv function). + This does a better job of supporting quoting and escaping, so for the + example given above we now pass two arguments (first arg) + and (second_arg), which is certainly what I would have expected as a + GDB user. + + This commit changes the 'execv_argv' class accordingly and drops the + optimization to have all the 'char *' in 'm_argv' point to a single + string rather than allocating a separate string for each arg. This is + needed because we are now going to be stripping some escaping from the + arguments, for example: + + (gdb) set startup-with-shell off + (gdb) set args "literal \$" + + In this case we will pass the single argument (literal $) to the + inferior, the escaping backslash will be removed. This might seem + strange as usually the backslash would be stripped by the shell, and + now we have no shell. However, I think the consistent behaviour is a + good thing; whether we start with a shell or not the escaping will be + removed. + + Using gdb_argv will mean that quote characters are also stripped. If + we consider the first example again: + + (gdb) set startup-with-shell off + (gdb) set args "first arg" second_arg + + This is now going to pass (first arg) and (second_arg), the quotes + have been removed. If the user did want the original behaviour then + they are going to have to now do this: + + (gdb) set startup-with-shell off + (gdb) set args \"first arg\" second_arg + + or they could do this: + + (gdb) set startup-with-shell off + (gdb) set args '"first' 'arg"' second_arg + + This commit also extends the three tests that cover inferior argument + passing to cover the case where 'startup-with-shell' is off. All of + these new tests pass for native targets, but there are still problems + when using remote targets. + + The remote target problems arise because of how escaping is handled + while passing arguments to remote targets. I have a larger series + that aims to address this issue: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + This patch was originally part of that series, but getting a 14 patch + series reviewed is not easy, so I've pulled this patch out on its own + for now, and the new tests are (rather crudely) disabled for remote + targets. + + My hope is to work through my 14 patch series posting all of the + patches in smaller groups, which will hopefully make reviewing + easier. As more of that series gets merged, the remote argument + handling will improve, before, eventually, no tests will need to be + disabled. + + Co-Authored-By: Andrew Burgess + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + Reviewed-By: Keith Seitz + +2025-02-09 Alan Modra + + PR32663, ld buffer overflow reading .debug_info + When reading debug info to print an error message, we'll be reading + the debug info off disk, not using edited debug info. sec->rawsize + if non-zero is the correct size. + + PR 32663 + * dwarf2.c (_bfd_dwarf2_slurp_debug_info): Use + bfd_get_section_limit_octets to properly size debug sections. + +2025-02-09 Alan Modra + + PR32662, segv in _bfd_generic_link_output_symbols + asymbol flags zero can result from certain combinations of ELF st_info + binding and type. asymbol section is set to bfd_abs_section for + genuine absolute symbols and also ones with a bogus st_shndx. A + fuzzed ELF object with such a symbol can tickle a bug in generic + linker code added by commit d3a65d4dea to avoid an abort, resulting + in a segfault. This patch fixes the segfault by removing the + sym->section->owner->flags test. I think it should be OK to exclude + all symbols without any BSF flags set, not just IR symbols. + + PR 32662 + * linker.c (_bfd_generic_link_output_symbols): Exclude all + symbols with zero flags. Replace abort with assertion. + Tidy logic. + +2025-02-09 GDB Administrator + + Automatic date update in version.in + +2025-02-08 Andrew Burgess + + gdb/tui: use wrefresh if output is not surpressed + Recent work in the TUI has improved GDB's use of the curses + wnoutrefresh and doupdate mechanism, which improves performance by + batching together updates and then doing a single set of writes to the + screen when doupdate is finally called. + + The tui_batch_rendering type is a RAII class which, in its destructor, + calls doupdate to send the batched updates to the screen. + + However, if there is no tui_batch_rendering active on the call stack + then any wnoutrefresh calls will remain batched but undisplayed until + the next time doupdate happens to be called. + + This problem can be seen in PR gdb/32623. When an inferior is started + the 'Starting program' message is not immediately displayed to the + user. + + The 'Starting program' message originates from run_command_1 in + infcmd.c, the message is sent to the current_uiout, which will be the + TUI ui_out. After the message is sent, ui_out::flush() is called, + here's the backtrace when that happens: + + #0 tui_file::flush (this=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42 + #1 0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at ../../src/gdb/utils.c:1531 + #2 0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at ../../src/gdb/utils.c:1539 + #3 0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at ../../src/gdb/cli-out.c:250 + #4 0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at ../../src/gdb/ui-out.h:263 + #5 0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449 + #6 0x00000000009f599a in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:511 + + And if we check out tui_file::flush (tui-file.c) we can see that this + just calls tui_win_info::refresh_window(), which in turn, just uses + wnoutrefresh to batch any pending output. + + The problem is that, in the above backtrace, there is no + tui_batch_rendering active, and so there will be no doupdate call to + flush the output to the screen. + + We could add a tui_batch_rendering into tui_file::flush. And + tui_file::write. And tui_file::puts ..... + + ... but that all seems a bit unnecessary. Instead, I propose that + tui_win_info::refresh_window() should be changed. If suppress_output + is true (i.e. a tui_batch_rendering is active) then we should continue + to call wnoutrefresh(). But if suppress_output is false, meaning that + no tui_batch_rendering is in place, then we should call wrefresh(), + which immediately writes the output to the screen. + + Testing but PR gdb/32623 was a little involved. We need to 'run' the + inferior and check for the 'Starting program' message. But DejaGNUU + can only check for the message once it knows the message should have + appeared. But, as the bug is that output is not displayed, we don't + have any output hints that the inferior is started yet... + + In the end, I have the inferior create a file in the test's output + directory. Now DejaGNU can send the 'run' command, and wait for the + file to appear. Once that happens, we know that the 'Starting + program' message should have appeared. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32623 + + Approved-By: Tom Tromey + +2025-02-08 Alexandre Oliva + + sparc: define _GLOBAL_OFFSET_TABLE_ when referenced + GCC testsuite gcc.dg/20050321-2.c hit link errors on undefined + _GLOBAL_OFFSET_TABLE_. The compiler output referenced only + _GLOBAL_OFFSET_TABLE_-offsets to set it up, and to compute the + GOT-relative address of local symbols, none of which triggered the + machinery that enabled the creation of the dynamic section, so + _GLOBAL_OFFSET_TABLE_ ended up undefined. + + Enable the dynamic section if we find a relocation involving + _GLOBAL_OFFSET_TABLE_. While at that, optimize checks for references + to it. + + + for bfd/ChangeLog + + * elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Check for + _GLOBAL_OFFSET_TABLE_ references early, then compare hashed + symbols instead of strings. + (_bfd_sparc_elf_relocate_section): Compare hashed symbols. + + for ld/ChangeLog + + * testsuite/ld-sparc/got-def.s: New test. + * testsuite/ld-sparc/sparc.exp: Add it. + +2025-02-08 GDB Administrator + + Automatic date update in version.in + +2025-02-07 Alan Modra + + Re: x86-64: Estimate output section layout before sizing dynamic sections + Commit 73ab3b9825 results in a warning compiling eelf_x86_64_sol2.c, + breaking --enable-targets=all builds. + warning: ‘elf_x86_64_before_allocation’ defined but not used + + Fix this by hooking up the chain of before_allocation functions, so + x86_64-solaris2 calls elf_x86_64_before_allocation, while + sparc64-solaris2 calls gldelf64_sparc_sol2_before_allocation. + +2025-02-07 Lancelot SIX + + gdb/testsuite: fix "up to main" in gdb.base/corefile-exec-context.exp + On ubuntu systems with libc debug info available (libc6-dbg), I see the + following failures for the gdb.base/corefile-exec-context.exp testcase: + + show args + Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e". + (gdb) PASS: gdb.base/corefile-exec-context.exp: show args + up + #1 __pthread_kill_internal (signo=6, threadid=133859295332160) at ./nptl/pthread_kill.c:78 + 78 in ./nptl/pthread_kill.c + (gdb) FAIL: gdb.base/corefile-exec-context.exp: move up to main + + This failures is because the pattern used to parse the output of `up` + is not expecting what is seen when debugging information is present for + those frames. + + This patch adjusts the pattern to allow both possible outputs. + + Tested on ubuntu-22.04 and ubuntu24.04 with libc6-dbg installed for gdb + build with --with-separate-debug-dir=/usr/lib/debug. + + Change-Id: I217d4b20006d0ecdb4b7a71eeb8d01597ec5ac63 + Approved-By: Tom Tromey + +2025-02-07 Tom de Vries + + [gdb/corefiles] Fix segfault in core_target_open + On x86_64-freebsd, with test-case gdb.arch/i386-biarch-core.exp I run into a + segfault here in corelow.c:core_target_open: + ... + { + gdb::unique_xmalloc_ptr failing_command = make_unique_xstrdup + (bfd_core_file_failing_command (current_program_space->core_bfd ())); + if (failing_command != nullptr) + gdb_printf (_("Core was generated by `%s'.\n"), + failing_command.get ()); + } + ... + where bfd_core_file_failing_command returns nullptr, so the segfault happens + somewhere during "strdup (nullptr)". + + There doesn't seem to be a need to make a copy of the string, so fix this by + dropping the make_unique_xstrdup. + + Tested on x86_64-linux. + Tested the test-case on x86_64-freebsd. + + Approved-By: Tom Tromey + + PR corefiles/32634 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32634 + +2025-02-07 Tom de Vries + + [gdb/build] Fix x86_64-w64-mingw32 build by avoiding SCNx8 + With an x86_64-w64-mingw32 targeted cross-build on x86_64-linux, I run into: + ... + gdb/cli/cli-decode.c: \ + In function 'ui_file_style::color parse_cli_var_color(const char**)': + gdb/cli/cli-decode.c:2917:41: error: expected ')' before 'SCNx8' + int parsed_args = sscanf (*args, "#%2" SCNx8 "%2" SCNx8 "%2" SCNx8 "%n", + ... + + Apparantly, the definition of SCNx8 is missing in inttypes.h. + + Rewrite the sscanf call to use SCNx32, which is available. + + Tested by: + - completing aforementioned cross-build, and + - build & test on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + +2025-02-07 MayShao-oc + + x86: Support x86 Zhaoxin PadLock XMODX instructions + The CPUID EDX bit[28] indicates its enablement, and it includes REP + XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates + the support of modular exponentiation feature, both REP XMODEXP and + REP MONTMUL2 use it. + + gas/ChangeLog: + + * NEWS: Support Zhaoxin PadLock XMODX instructions. + * config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to + PadLockXMODX instructions. + (output_insn): Handle PadLockXMODX instructions. + * doc/c-i386.texi: Document PadLockXMODX. + * testsuite/gas/i386/i386.exp: Add PadLockXMODX test. + * testsuite/gas/i386/padlockxmodx.d: Ditto. + * testsuite/gas/i386/padlockxmodx.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add PadLockXMODX. + * i386-gen.c: Ditto + * i386-opc.h (CpuPadLockXMODX): New. + * i386-opc.tbl: Add Zhaoxin PadLock XMODX instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-02-07 Jan Beulich + + gas: suppress use of ISSPACE() / ISBLANK() + We want is_whitespace() to be used uniformly, no matter what this then + expands to. + +2025-02-07 GDB Administrator + + Automatic date update in version.in + +2025-02-06 H.J. Lu + + x86-64: Estimate output section layout before sizing dynamic sections + When sizing dynamic sections, elf_x86_64_scan_relocs converts GOTPCREL + relocations to R_X86_64_PC32, R_X86_64_32S or R_X86_64_32 for local + symbols. But at that time, since the output section layout is unknown, + the local symbol values can't be determined. Later linker issues an + error if the converted relocation overflows when resolving relocations + against these local symbols. Update the x86-64 ELF linker to estimate + output section layout before sizing dynamic sections and use the + preliminary output section layout info to skip the GOTPCREL relocation + conversion if the converted relocation overflows. + + bfd/ + + PR ld/32591 + * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Add an input + section argument. Use the lowest-addressed section to estimate + the __ehdr_start symbol value. Don't convert relocation if the + converted relocation will overflow. + + ld/ + + PR ld/32591 + * emultempl/elf-x86.em (elf_x86_64_before_allocation): + New. Defined for x86-64. + (LDEMUL_BEFORE_ALLOCATION): Likewise. + * testsuite/ld-x86-64/pr19609-2a.d: Don't fail. + * testsuite/ld-x86-64/pr19609-2b.d: Likewise. + * testsuite/ld-x86-64/pr19609-4a.d: Likewise. + * testsuite/ld-x86-64/pr19609-5d.d: Likewise. + * testsuite/ld-x86-64/pr19609-7a.d: Likewise. + * testsuite/ld-x86-64/pr19609-7c.d: Likewise. + * testsuite/ld-x86-64/pr32591-1.s: New file. + * testsuite/ld-x86-64/pr32591-1a-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-1a.d: Likewise. + * testsuite/ld-x86-64/pr32591-1a.t: Likewise. + * testsuite/ld-x86-64/pr32591-1b-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-1b.d: Likewise. + * testsuite/ld-x86-64/pr32591-1b.t: Likewise. + * testsuite/ld-x86-64/pr32591-1c-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-1c.d: Likewise. + * testsuite/ld-x86-64/pr32591-1c.t: Likewise. + * testsuite/ld-x86-64/pr32591-1d-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-1d.d: Likewise. + * testsuite/ld-x86-64/pr32591-1d.t: Likewise. + * testsuite/ld-x86-64/pr32591-2.s: Likewise. + * testsuite/ld-x86-64/pr32591-2-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-2.d: Likewise. + * testsuite/ld-x86-64/pr32591-2.t: Likewise. + * testsuite/ld-x86-64/pr32591-3.s: Likewise. + * testsuite/ld-x86-64/pr32591-3-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-3.d: Likewise. + * testsuite/ld-x86-64/pr32591-3.t: Likewise. + * testsuite/ld-x86-64/pr32591-4.s: Likewise. + * testsuite/ld-x86-64/pr32591-4-x32.d: Likewise. + * testsuite/ld-x86-64/pr32591-4.d: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run PR ld/32591 tests. + +2025-02-06 Tom de Vries + + [gdb/testsuite] Use -nostdlib in gdb.base/list-dot-nodebug.exp + When running test-case gdb.base/list-dot-nodebug.exp with target board + cc-with-gnu-debuglink, I run into: + ... + (gdb) list .^M + warning: 1 ../sysdeps/x86_64/crtn.S: No such file or directory^M + (gdb) FAIL: gdb.base/list-dot-nodebug.exp: debug=none: print before start + ... + + The problem is that the call to gdb_gnu_strip_debug in + gdb.base/list-dot-nodebug.exp has no effect, because the target board makes + sure that compilation delivers an executable that is already stripped, with a + .gnu_debuglink section linking to the debug info. + + Fix this by using -nostdlib instead of static, which means the call to + gdb_gnu_strip_debug can be removed. + + This also allows us to extend the test-case to excercise "list ." before + starting the inferior, for the debug=some scenario, which is currently + skipped: + ... + # We don't test "list ." before starting with some debug info + # because GDB will choose the symtab that has debuginfo, and + # print the copyright blurb. This test isn't interested (yet?) + # in checking if this default location choice is consistent. + ... + + While we're at it, make the effect of "list ." on the current source location + explicit using "info source" before and after "list .". + + While we're at it, make sure when running with target board + cc-with-gdb-index or cc-with-debug-names, that the failure to compile the + debug=none variant due to: + ... + Error while writing index ...: No debugging symbols + ... + doesn't stop the test-case from running the debug=some variant. + + Tested on x86_64-linux. + + Reviewed-By: Guinevere Larsen + +2025-02-06 Lancelot SIX + + gdb/testsuite: gdb.base/gcorebg.exp against installed binaries + It is possible to run GDB's testsuite against installed binaries rather + than the one from the build tree. For example, one could do: + + $ make check-gdb RUNTESTFLAGS=GDB=/usr/bin/gdb + + Running the testsuite this way causes error for gdb.base/gcorebg.exp: + + Running [...]/gdb/testsuite/gdb.base/gcorebg.exp ... + FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished + FAIL: gdb.base/gcorebg.exp: detached=detached: Core file generated by gcore + FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished + FAIL: gdb.base/gcorebg.exp: detached=standard: Core file generated by gcore + + This is due to 2 problems. + First, when running this way, the $GDB_DATA_DIRECTORY is not set (on + purpose) as the installed GDB does not need to be specified where to + find it. See this section in gdb/testsuite/lib/gdb.exp: + + if ![info exists GDB] { + [....] + } else { + # If the user specifies GDB on the command line, and doesn't + # specify GDB_DATA_DIRECTORY, then assume we're testing an + # installed GDB, and let it use its own configured data directory. + if ![info exists GDB_DATA_DIRECTORY] { + set GDB_DATA_DIRECTORY "" + } + } + + The testbg.exp file always assumes a non-empty GDB_DATA_DIRECTORY. As a + consequence, when calling the gcorebg binary with an empty argument + (i.e. missing argument), the program fails: + + gcorebg: [...]/gdb/testsuite/gdb.base/gcorebg.c:42: main: Assertion `argc == 5' failed. + FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished + + This patch does adjust the gcorebg.c and gcorebg.exp files to allow not + specifying the data-directory. + + The other issue is that the testsuite assumes that the `gcore` to test + is always the one from the build tree. However, if someone is testing + an installed binary by setting GDB, I think that person would expect to + test the `gcore` script next to the binary that was specified (unless + GCORE is specified to explicitly specified). This patch does that + adjustment as well. To that end, it needs to move the block setting + GCORE after the block setting GDB. + + Change-Id: I070e039903c0b5afeac357d8fac7d710ff6697b9 + Approved-By: Tom Tromey + +2025-02-06 Alan Modra + + PR 32603, ld -w misbehaviour + ld -w currently causes segmentation faults and other misbehaviour + since it changes einfo with %F in the format string (fatal error) to + not exit. This patch fixes that by introducing a new variant of einfo + called "fatal" that always exits, and replaces all einfo calls using + %F with a call to fatal without the %F. I considered modifying einfo + to inspect the first 2 or 4 chars in the format string, looking for + %F, but decided that was probably a bad idea given that translators + might have moved the %F. It's also a little nicer to inform the + compiler of a function that doesn't return. + + The patch also fixes some formatting nits, and makes use of %pA + to print section names in a couple of places in aix.em. + +2025-02-06 Nick Clifton + + Fix illegal memory access when linking a corrupt input file. + PR 32647 + +2025-02-06 Tom de Vries + + [gdb/build] Fix unused var in linux-fork.c + On x86_64-linux, with gcc 7.5.0 I ran into a build breaker: + ... + linux-fork.c: In function ‘void detach_checkpoint_command(const char*, int)’: + linux-fork.c:744:16: error: unused variable ‘inf’ [-Werror=unused-variable] + auto [fi, inf] = parse_checkpoint_id (args); + ^ + linux-fork.c: In function ‘void linux_fork_context(fork_info*, int, inferior*)’: + linux-fork.c:1020:22: error: unused variable ‘oldinf’ [-Werror=unused-variable] + auto [oldfp, oldinf] = find_fork_ptid (inferior_ptid); + ^ + ... + + Fix this by dropping the unused variables, similar how that was done in commit + bc13da1980c ("[gdb/build] Fix unused var in corelow.c"). + + Tested on x86_64-linux, by completing a build. + +2025-02-06 Tom Tromey + + Return bool from dwarf2_read_gdb_index + This changes dwarf2_read_gdb_index to return bool rather than int. + +2025-02-06 H.J. Lu + + x86: Use hehdr_start for __ehdr_start + Use hehdr_start for __ehdr_start instead of elf_link_hash_lookup. + + * elfxx-x86.c (elf_x86_linker_defined): Use hehdr_start if name + is NULL. + (_bfd_x86_elf_link_check_relocs): Pass NULL as __ehdr_start to + elf_x86_linker_defined. + +2025-02-06 GDB Administrator + + Automatic date update in version.in + +2025-02-05 Kevin Buettner + + Linux checkpoints: Update NEWS and gdb.texinfo regarding multiple inferiors + Reviewed-By: Eli Zaretskii + Reviewed-By: Tom Tromey + Approved-By: Andrew Burgess + +2025-02-05 Kevin Buettner + + Print only process ptids from linux-fork.c + This commit causes a "process ptid" to be passed to all calls + of target_pid_to_str in linux-fork.c. A "process ptid" is one + in which only the pid component is set to a non-zero value; + both the lwp and tid components are zero. + + The reason for doing this is that pids associated with checkpoints can + never be a thread due to the fact that checkpoints (which are + implemented by forking a process) can only (reasonably) work with + single-threaded processes. + + Without this commit, many of the "info checkpoints" commands + in gdb.multi/checkpoint-multi.exp will incorrectly show some + of the checkpoints as threads. E.g... + + Id Active Target Id Frame + * 1.0 y Thread 0x7ffff7cb5740 (LWP 581704) at 0x401199, file hello.c, line 51 + 1.2 n process 581716 at 0x401199, file hello.c, line 51 + 1.3 n process 581717 at 0x401199, file hello.c, line 51 + 2.1 n process 581708 at 0x401258, file goodbye.c, line 62 + 2.2 y Thread 0x7ffff7cb5740 (LWP 581712) at 0x401258, file goodbye.c, line 62 + 3.0 y Thread 0x7ffff7cb5740 (LWP 581713) at 0x40115c, file hangout.c, line 31 + 3.2 n process 581715 at 0x40115c, file hangout.c, line 31 + (gdb + + With this commit in place, the output looks like this instead: + + Id Active Target Id Frame + * 1.0 y process 535276 at 0x401199, file hello.c, line 51 + 1.2 n process 535288 at 0x401199, file hello.c, line 51 + 1.3 n process 535289 at 0x401199, file hello.c, line 51 + 2.1 n process 535280 at 0x401258, file goodbye.c, line 62 + 2.2 y process 535284 at 0x401258, file goodbye.c, line 62 + 3.0 y process 535285 at 0x40115c, file hangout.c, line 31 + 3.2 n process 535287 at 0x40115c, file hangout.c, line 31 + + (For brevity, I've removed the directory elements in each of the paths + above.) + + The testcase, gdb.multi/checkpoint-multi.exp, has been updated to + reflect the fact that only "process" should now appear in output + from "info checkpoints". + + Reviewed-By: Tom Tromey + Approved-By: Andrew Burgess + +2025-02-05 Kevin Buettner + + Capitalize output of successful checkpoint command + This commit causes the output of a "checkpoint" command to be + changed from: + + checkpoint N: fork returned pid DDDD + + to: + + Checkpoint N: fork returned pid DDDD + + This change was made to bring the output of the "checkpoint" command in + line with that of other commands, e.g.: + + (gdb) break main + Breakpoint 1 at ... + + (gdb) catch exec + Catchpoint 2 (exec) + + (gdb) add-inferior + [New inferior 2] + Added inferior 2 + + The tests gdb.base/checkpoint.exp, gdb.base/kill-during-detach.exp, + and gdb.multi/checkpoint-multi.exp have been updated to accept the new + (capitalized) output from the "checkpoint" command. + + Reviewed-By: Tom Tromey + Approved-By: Andrew Burgess + +2025-02-05 Kevin Buettner + + Make linux checkpoints work with multiple inferiors + The current linux checkpoint code, most of which may be found in + linux-fork.c, is quite broken when attempting to use more than + one inferior. Running GDB will show internal errors when starting + two inferiors, placing a checkpoint in one, then switching to + the other and doing one of the following commands, "restart", + "detach", "kill", or continue (to program exit). Test cases + for two of those scenarios may be found in this bug: + + https://sourceware.org/bugzilla/show_bug.cgi?id=31065 + + I've tested for each of the scenarios and many more in the new + test case, gdb.multi/checkpoint-multi.exp. + + I started off with the goal of fixing just those problems, and was + mostly successful with a much smaller patch, but doing "info + checkpoints" with more than one inferior didn't work correctly due to + some of the inferiors being in the wrong program space. That led me + to making the linux-fork code fully inferior-aware. + + Prior to this commit, the list of forks was being maintained in a + global named named 'fork_list'. I turned this into a per-inferior + data structure. There was also global named 'highest_fork_num' which + is also now part of the per-inferior struct. A registry key named + 'checkpoint_inferior_data_key' along with function + 'get_checkpoint_inferior_data' is used to access the per-inferior + data. This new function, get_checkpoint_inferior_data, is only + called by the new functions 'fork_list', 'reset_highest_fork_num', + and increment_highest_fork_num, each of which is passed a pointer to + the inferior. Most occurrences referring to the (previously) global + 'fork_list' have been replaced by 'fork_list (inf)'. In some + functions, where the 'fork_list' is referenced multiple times, a local + named 'fork_list' is declared and initialized instead, like this: + + auto &fork_list = ::fork_list (inf); + + The constructor for 'struct fork_info' has gained an additional + parameter. In addition to passing the pid of the new fork, we now + also pass the fork identifier, fork_num, to the constructor. This + integer is shown to the user in the "info checkpoints" command and + is provided by the user, perhaps in conjunction with the inferior + number, in commands which manipulate checkpoints, e.g. 'restart' and + 'delete checkpoint'. + + When checkpoints are used in only one inferior, this commit will + present information to the user and will accept checkpoint identifiers + to commands in much the same way as the code did before this commit. + Per Pedro Alves's recommendations, the "info checkpoints" command has + been changed somewhat. "info checkpoints" used to display "(main + process)" for the first process in the checkpoint list. This is no + longer done because it does not provide useful information. It also + used to display "", when the process is running and no useful + frame information may be displayed. This has been changed to + "(running)" in order to be more consistent with the output of the + "info threads" command. A new column has been added to the output for + showing the active process in the output from "info checkpoints". + This column will display 'y' for the active process and 'n' for the + others. For the active inferior a '*' is also printed preceding the + checkpoint identifier. Here's what things look(ed) like before and + after for just one inferior: + + Before: + + (gdb) info checkpoints + * 0 Thread 0x7ffff7cd3740 (LWP 84201) (main process) at 0x40114a, file hello.c, line 28 + 1 process 84205 at 0x401199, file hello.c, line 51 + 2 process 84206 at 0x4011a3, file hello.c, line 53 + + After: + + (gdb) info checkpoints + Id Active Target Id Frame + * 0 y process 551311 at 0x40114a, file hello.c, line 28 + 1 n process 551314 at 0x401199, file hello.c, line 51 + 2 n process 551315 at 0x4011a3, file hello.c, line 53 + + (The Thread versus process distinction is handled by another + patch - the "After" example assumes that patch is applied too.) + + When there are multiple inferiors, the "info checkpoints" output looks + like this: + + (gdb) info checkpoints + Id Active Target Id Frame + 1.0 y process 535276 at 0x401199, file hello.c, line 51 + 1.1 n process 535283 at 0x401199, file hello.c, line 51 + 1.2 n process 535288 at 0x401199, file hello.c, line 51 + 2.1 n process 535280 at 0x401258, file goodbye.c, line 62 + 2.2 y process 535284 at 0x401258, file goodbye.c, line 62 + * 3.0 y process 535285 at 0x40115c, file hangout.c, line 31 + 3.2 n process 535287 at 0x40115c, file hangout.c, line 31 + + A new function named 'parse_checkpoint_id' has been added. As its + name suggests, it's responsible for parsing a string representing a + checkpoint identifier. These identifiers may be either a decimal + number representing the checkpoint number in the current inferior or + two decimal numbers separated by '.', in which case the first is the + inferior number and the second is the checkpoint number in that + inferior. It is called by delete_checkpoint_command, + detach_checkpoint_command, info_checkpoints_command, and + restart_command. Calls to 'parse_checkpoint_id' replace calls to + 'parse_and_eval_long', plus error checking and error reporting code + near the calls to 'parse_and_eval_long'. As such, error checking and + reporting has been consolidated into a single function and the + messages output are more uniform, though this has necessitated changes + to the existing test case gdb.base/checkpoint.exp. + + The functions 'find_fork_ptid' and 'find_fork_pid' used to return a + pointer to a fork_info struct. They now return a pair consisting of + the pointer to a fork_info struct in addition to a pointer to the + inferior containing that checkpoint. + + 'find_fork_id' returns a pointer to a fork_info struct just as it did + before, but it's now gained a new parameter, 'inf', which is the + inferior in which to look. + + info_checkpoints_command used to simply iterate over the list of + forks (checkpoints), printing each one out. It now needs to iterate + over all inferiors and, for those which have checkpoints, it needs + to iterate over the list of checkpoints in that inferior. As noted + earlier, the format of the output has been changed so that checkpoint + identifiers incorporating an inferior number may be printed. + + linux_fork_context, called by restart_command, now contains code to + switch inferiors when the fork being restarted is in an inferior which + is different from the current one. The scoped_switch_fork_info class + now also contains code for switching inferiors in both the constructor + and destructor. + + gdb/linux-nat.c has a few changes. All but one of them are related + to passing the inferior to one of the linux-fork functions. But + one of the tests in linux_nat_target::detach has also changed in + a non-obvious way. In attempting to determine whether to call + linux_fork_detach(), that code used to do: + + if (pid == inferior_ptid.pid () && forks_exist_p ()) + + It's been simplified to: + + if (forks_exist_p (inf)) + + I had added the 'pid == inferior_ptid.pid ()' condition in late 2023 + while working on a detach bug. It was kind of a hack to prevent + calling linux_fork_detach() when in a different inferior. That's no + longer needed since the call to forks_exist_p does this directly - + i.e. it is now inferior-aware. + + Finally, the header file 'linux-fork.h' has been updated to reflect + the fact that add_fork, linux_fork_killall, linux_fork_detach, and + forks_exist_p all now require that a pointer to an inferior be passed + to these functions. Additionally (as mentioned earlier), + find_fork_pid now returns std::pair instead + 'of fork_info *'. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31065 + Reviewed-By: Tom Tromey + Approved-By: Andrew Burgess + +2025-02-05 Nick Clifton + + Fix another illegal memory access triggered by corrupt ELF input files. + PR 32644 + + Add even more checks for corrupt input when processing relocations for ELF files. + PR 32643 + + Prevent illegal memory access when checking relocs in a corrupt ELF binary. + PR 32641 + +2025-02-05 Yury Khrustalev + + aarch64: Add leading zeros to opcodes in aarch64-tbl.h + Opcodes and bitmasks are 32-bit numbers and omitting leading + zeros might be interpreted as if they are 28-bit. + + aarch64: Clean up whitespace in aarch64-tbl.h + Clean up whitespace for conforming to GNU coding standards + +2025-02-05 Nick Clifton + + Prevent an abort in the bfd linker when attempting to generate dynamic relocs for a corrupt input file. + PR 32638 + +2025-02-05 Guinevere Larsen + + gdb: restrict configure error with all targets and 64 bit bfd to mips + The recent commit b601c58034ed755fb765fc13782b6876bffd25d4 causes the + gdb configure to fail if --enable-targets=all was requested, but 64 bit + bfd was not enabled. This was due to a build failure first reported + against mips, and that I also encountered building on a 32 bit mips + system, but that looked like a general failure. + + Further examination showed that this is, in fact, mips-specific (or at + least, not completely generic) as other targets like debian-i386 and + 32-bit arm could build all targets just fine. + + This commit restricts the new error to only trigger in mips hosts. + + Approved-By: Andrew Burgess + +2025-02-05 Nick Clifton + + Prevent illegal memory access when indexing into the sym_hashes array of the elf bfd cookie structure. + PR 32636 + +2025-02-05 Jan Beulich + + gas MMIX: Use more of is_... framework like is_whitespace and is_end_of_stmt + Convert uses of ISSPACE() and testing for specific characters into + calls to is_whitespace and is_end_of_stmt. While doing that, also + remove some redundant tests, like ';' together with is_end_of_line[] + and is_whitespace and !is_end_of_line. + + Note the invalid casts being fixed as part of moving to is_... macros; + there were (unsigned int) where there should have been (unsigned char) + applied on char as index to is_end_of_line[]. + + Beware that the input language changes slightly: some constructs with + whitespace characters other than space and TAB are now invalid. + +2025-02-05 GDB Administrator + + Automatic date update in version.in + +2025-02-04 Tom de Vries + + [gdb/tui] Clean up asserts in tui_source_window_base::refresh_window + Commit 1c525b0e037 ("[gdb/tui] Fix assert in + tui_source_window_base::refresh_window") added an early return in + tui_source_window_base::refresh_window. + + Assert after the early return that "m_pad != nullptr", and clean up the + following asserts that allow for m_pad == nullptr. + + Tested on x86_64-linux. + + Reported-By: Andrew Burgess + Co-Authored-By: Andrew Burgess + Approved-By: Andrew Burgess + +2025-02-04 Tom de Vries + + [pre-commit] Require pre-commit version 3.2.0 + Recent commit 0bd340d6704 ("pre-commit autoupdate") bumped the isort version + to 6.0.0. + + Subsequently, I started running into: + ... + $ SKIP=flake8,isort pre-commit run + An error has occurred: InvalidManifestError: + ==> File /home/vries/.cache/pre-commit/repommstqefj/.pre-commit-hooks.yaml + ==> At Hook(id='isort') + ==> At key: stages + ==> At index 0 + =====> Expected one of commit, commit-msg, manual, merge-commit, \ + post-checkout, post-commit, post-merge, post-rewrite, prepare-commit-msg, \ + push but got: 'pre-commit' + Check the log at /home/vries/.cache/pre-commit/pre-commit.log + ... + + I found a similar PR [1], that explains that using pre-commit as a stage (as + isort 6.0.0 does) is supported starting pre-commit 3.2.0. + + Add minimum_pre_commit_version 3.2.0 in .pre-commit-config.yaml, as suggested + in the PR. + + After adding this, I get a more helpful message: + ... + $ SKIP=flake8,isort pre-commit run + An error has occurred: InvalidConfigError: + ==> File .pre-commit-config.yaml + ==> At Config() + ==> At key: minimum_pre_commit_version + =====> pre-commit version 3.2.0 is required but version 2.17.0 is installed. \ + Perhaps run `pip install --upgrade pre-commit`. + Check the log at /home/vries/.cache/pre-commit/pre-commit.log + ... + and after doing so which upgrades pre-commit to version 4.1.0, as well as + re-installing pre-commit using: + ... + $ pre-commit uninstall + $ pre-commit install + ... + I have a functional setup again. + + Interestingly, since pre-commit 4.1.0 runs in a python 3.11 environment, I no + longer need to skip flake8 and isort, as I needed to previously when the + system python 3.6 was used. + + Approved-By: Simon Marchi + + [1] https://github.com/psf/black/issues/4065 + +2025-02-04 Simon Marchi + + pre-commit: run flake8 on more Python files + pre-commit currently runs flake8 only on `gdb/python/**/*.py`. There + are more files we can run it on, without running it on all the testsuite + files. Add: + + - gdb/gdb-gdb.py.in + - gdb/*.py + - gdb/testsuite/*.py + + Fix the new errors that popped up: + + gdb/copyright.py:29:21: W605 invalid escape sequence '\*' + gdb/copyright.py:29:29: W605 invalid escape sequence '\*' + gdb/copyright.py:29:38: W605 invalid escape sequence '\*' + gdb/copyright.py:29:46: W605 invalid escape sequence '\*' + gdb/copyright.py:34:1: F401 'datetime' imported but unused + gdb/testsuite/analyze-racy-logs.py:150:9: E722 do not use bare 'except' + + Change-Id: Ia864c22d4f170d4e18ce3beb06a86c49966654b2 + Approved-By: Tom Tromey + +2025-02-04 Tom Tromey + + Reorder gnatmake arguments in inline-section-gc.exp + inline-section-gc.exp ends up passing "-lm" to gnatmake as an "marg" + -- meaning gnatmake should process it itself. However, the gnat-llvm + gnatmake does not know what to do with this, so the test fails. + + This patch rearranges the arguments so that the (implicit) trailing + -lm ends up being passed through to the linker. + +2025-02-04 Jens Remus + + doc: sframe: Clarify FDE/FRE function/range start address fields + The function start address in a SFrame FDE (sfde_func_start_address) + is encoded as a signed offset to the function start address from the + SFrame section. + + The PC range start address in a SFrame FRE (sfre_start_address) is + encoded as an unsigned offset to the range from the function start + address. + +2025-02-04 Jens Remus + + gas: Skip SFrame FDE if .cfi_val_offset specifies non-default offset + Unwinding of the stack pointer (SP) is performed using the assumed + default rule ".cfi_val_offset , 0", so that SP unwinds as: + + SP = CFA + + Warn if the CFI directive .cfi_val_offset is encountered for the + SP register with a different offset. + + gas/ + * gen-sframe.c (sframe_xlate_do_val_offset): Skip SFrame FDE + if non-default SP value offset. + +2025-02-04 Jens Remus + + gas: sframe: Use appropriate struct cfi_insn_data union members + Use the appropriate struct cfi_insn_data union members to access + fields when generating SFrame information from CFI directives. + + gas/ + * gen-sframe.c (sframe_xlate_do_def_cfa, sframe_xlate_do_offset, + sframe_xlate_do_val_offset): Access ri fields, as .cfi_def_cfa, + .cfi_offset, and .cfi_val_offset define a register and offset + value. + * (sframe_xlate_do_def_cfa_register): Access r field, as + .cfi_def_cfa_register defines a register. + +2025-02-04 Jan Vrany + + gdb/python: add void_type () method to gdb.Architecture object + This commit adds a new method to Python architecture objects that + returns a void type for that architecture. + + This will be useful later to create types for function symbols created + using Python extension code. + + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2025-02-04 Jan Vrany + + gdb/python: add domain property to gdb.Symbol + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2025-02-04 Jan Vrany + + gdb/python: add subblocks property to gdb.Block + This commit adds new propery "subblocks" to gdb.Block objects. This + allows Python to traverse block tree starting with global block. + + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2025-02-04 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/big_packed_array.exp on s390x-linux + When running test-case gdb.ada/big_packed_array.exp on s390x-linux, I run + into: + ... + (gdb) print bad^M + $2 = (0 => 0 , 1)^M + (gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad + ... + + This is with gcc 7.5.0, and this xfail should trigger: + ... + if { $have_xfail && [string is integer $last] \ + && [expr ($last & 0xf) == 0] } { + # gcc/101643 + setup_xfail *-*-* + } + ... + but it doesn't because $last is '1'. + + Fix this by using 0xf0 as mask for big endian. + + Tested on s390x-linux. + +2025-02-04 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/convvar_comp.exp on s390x-linux + When running test-case gdb.ada/convvar_comp.exp on s390x-linux, I get: + ... + (gdb) run ^M + Starting program: pb16_063 ^M + ^M + Breakpoint 1, pck.break_me (item=...) at pck.adb:17^M + 17 function Break_Me (Item : T) return Boolean is^M + (gdb) print item.started^M + Cannot access memory at address 0x0^M + (gdb) FAIL: gdb.ada/convvar_comp.exp: print item.started + ... + + This happens as follows. + + The parameter item is available in (DW_OP_fbreg: -168): + ... + <2><912>: Abbrev Number: 18 (DW_TAG_formal_parameter) + <913> DW_AT_name : (indirect string, offset: 0x14ca): item + <919> DW_AT_type : <0x929> + <91d> DW_AT_location : 3 byte block: 91 d8 7e (DW_OP_fbreg: -168) + ... + and according to the rules of -O0, it's considered to be available after the + prologue, which looks like this: + ... + 0000000001002998 : + 1002998: b3 c1 00 2b ldgr %f2,%r11 + 100299c: b3 c1 00 0f ldgr %f0,%r15 + 10029a0: e3 f0 ff 58 ff 71 lay %r15,-168(%r15) + 10029a6: b9 04 00 bf lgr %r11,%r15 + 10029aa: e3 20 b0 a0 00 24 stg %r2,160(%r11) + ... + + To detect the prologue, gdb checks the line info, which looks like this: + ... + pck.adb: + File name Line number Starting address View Stmt + pck.adb 17 0x1002998 x + pck.adb 17 0x1002998 1 x + pck.adb 19 0x10029b0 x + pck.adb 20 0x10029b8 x + pck.adb - 0x10029c6 + ... + and gdb concludes that it's an empty prologue, so we stop at 0x1002998 and + try to print parameter item, which is not available yet. + + For more details, see this comment in skip_prologue_using_sal: + ... + /* For languages other than assembly, treat two consecutive line + entries at the same address as a zero-instruction prologue. + ... + + The same thing happens on x86_64-linux, but it causes no problem there, + because amd64_skip_prologue decides not to trust the result: + ... + struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr); + + /* LLVM backend (Clang/Flang) always emits a line note before the + prologue and another one after. We trust clang and newer Intel + compilers to emit usable line notes. */ + if (post_prologue_pc + && (cust != NULL + && cust->producer () != nullptr + && (producer_is_llvm (cust->producer ()) + || producer_is_icc_ge_19 (cust->producer ())))) + return std::max (start_pc, post_prologue_pc); + ... + because the producer is GCC. + + Work around this by setting a breakpoint on the first statement of + pck.break_me instead. + + Tested on s390x-linux. + +2025-02-04 Tom de Vries + + [gdb/testsuite] Use c++ flag in c++ test-cases + In some cases, test-cases use c++, but don't add "c++" to the compilation + flags. This can cause problems with some compilers. + + Fix this in some test-cases. + + Approved-By: Tom Tromey + + PR testsuite/30380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30380 + +2025-02-04 Nick Clifton + + Update with latest changes to src-release.sh + + Rename 'binutils' to 'binutils_with_gold'. Rename 'bin_no_gold' to 'binutils'. Add 'gold' + +2025-02-04 Tom de Vries + + [gdb/testsuite] Fix gdb.base/list-dot-nodebug.exp on openSUSE + On openSUSE Leap 15.6 with test-case gdb.base/list-dot-nodebug.exp I run into: + ... + (gdb) list .^M + warning: 1 ../sysdeps/x86_64/crtn.S: No such file or directory^M + (gdb) FAIL: $exp: debug=none: print before start + ... + + The intent of the debug=none case is to generate an executable with no debug + info. However, we have quite a few CUs with debug info: + ... + $ readelf -wi outputs/gdb.base/list-dot-nodebug/list-dot-nodebug-none \ + | egrep -c " @ " + 431 + ... + + This is because this code: + ... + gdb_gnu_strip_debug $executable no-debuglink + ... + uses $executable, and the variable is set here: + ... + set executable ${testfile}-none + ... + which sets it to "list-dot-nodebug-none" and consequently + gdb_gnu_strip_debug cannot find it. + + Fix this by using "[standard_output_file $executable]" instead. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31721 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721 + +2025-02-04 Tom de Vries + + [gdb/tui] Remove stale title when showing "No Source Available" + When running test-case gdb.tui/main.exp, the last command discards the + executable file and symbol table: + ... + (gdb) file + No executable file now. + Discard symbol table from `main'? (y or n) [answered Y; input not from terminal] + No symbol file now. + (gdb) + ... + and we end up with this source window: + ... + +-tui-layout.c----------------------------------------------------------------+ + | | + | | + | | + | | + | | + | | + | [ No Source Available ] | + | | + | | + | | + | | + | | + | | + +-----------------------------------------------------------------------------+ + ... + + The source window title shouldn't be showing tui-layout.c. It's the source + file containing function main for the executable that was just discarded. + + Fix this by clearing the title in tui_source_window::erase_source_content. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-02-04 H.J. Lu + + elf: Store __ehdr_start hash in elf_link_hash_table + Since + + commit 97da0e2677c4a38df2406576428ec27d1da26e7c + Author: Alan Modra + Date: Wed Jan 12 23:42:23 2022 +1030 + + tweak __ehdr_start visibility and flags for check_relocs + + creates __ehdr_start hash in lang_symbol_tweaks, store __ehdr_start hash + in elf_link_hash_table so that we just need to lookup it up only once. + + bfd/ + + * elf-bfd.h (elf_link_hash_table): Add hehdr_start. + * elf.c (assign_file_positions_for_load_sections): Use + hehdr_start. + + ld/ + + * ldelf.c (ldelf_before_allocation): Use hehdr_start for + __ehdr_start hash. + * ldlang.c (lang_symbol_tweaks): Store hehdr_start hash in + hehdr_start. + +2025-02-04 H.J. Lu + + elflink.c: Replace bed->dynamic_sec_flags with flags + Since at the function entry, there is + + flags = bed->dynamic_sec_flags; + + we can replace bed->dynamic_sec_flags with flags. + + * elflink.c (_bfd_elf_create_got_section): Replace + bed->dynamic_sec_flags with flags. + (_bfd_elf_link_create_dynamic_sections): Likewise. + +2025-02-04 Simon Marchi + + pre-commit autoupdate + Run `pre-commit autoupdate`. + + This picks up a fresh Black version from 2025, and with it comes a small + but welcome formatting change. + + There is a new version of isort as well, but no formatting change there. + + Change-Id: Ie654a9c14c3a4096893011082668efb57c166fa4 + +2025-02-04 GDB Administrator + + Automatic date update in version.in + +2025-02-03 Tom de Vries + + [gdb/syscalls] Sync with strace v6.13 + After syncing with strace v6.13 using: + ... + $ update-linux-defaults.sh ~/upstream/strace.git + ... + we have a few new entries in linux-defaults.xml.in: + ... + + + + + ... + + Regenerate most *-linux.xml.in files using: + ... + $ ./update-linux-from-src.sh ~/upstream/linux-stable.git + ... + updating the copyright years, and do so manually for the remaining two. + + Then regenerate *-linux.xml using make, propagating the groups changes and + copyright years. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2025-02-03 Jan Beulich + + Z8k: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). At the same time use is_end_of_stmt() instead of an + open-coded check in adjacent code. + + Z80: use is_whitespace() + Replace an open-coded check and convert ISSPACE() uses. + + Xtensa: use is_whitespace() + Convert an open-coded check. + + xgate: use is_whitespace() + Convert an open-coded check. + + x86: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + wasm32: use is_whitespace() + Convert an open-coded check. + + Visium: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert an open-coded check. + + VAX: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + v850: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks as well as ISSPACE() + uses. At the same time use is_end_of_stmt() instead of a kind-of-open- + coded check in adjacent code. + + C6x: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert an ISSPACE() use. At the same time use + is_end_of_stmt() instead of open-coded checks in adjacent code. + + C54x: use is_whitespace() + Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead + of open-coded checks in adjacent code. The function also needs using in + next_line_shows_parallel(). + + C4x: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). At the same time use is_end_of_stmt() instead of + kind-of-open-coded checks in adjacent code. + + C30: use is_whitespace() + Convert an open-coded check. + + spu: use is_whitespace() + Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead + of a kind-of-open-coded check in adjacent code. + + Sparc: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + SH: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks as well as an + ISSPACE() use. At the same time use is_end_of_stmt() instead of + (kind-of-)open-coded checks in adjacent code. + + Score: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + S/390: use is_whitespace() + Convert ISSPACE() uses. At the same time use is_end_of_stmt() instead + of kind-of-open-coded checks in adjacent code. + + s12z: use is_whitespace() + Convert open-coded checks. At the same time use is_end_of_stmt() instead + of open-coded checks in adjacent code. This then also fixes the prior + use of a wrong cast for an array index: Plain char may, after all, be + signed. + + rx: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks as well as ISSPACE() + uses. At the same time use is_end_of_stmt() instead of an open-coded + check in adjacent code. + + rl78: use is_whitespace() + Replace open-coded checks and convert ISSPACE() uses. At the same time + use is_end_of_stmt() instead of an open-coded check in adjacent code. + + RISC-V: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Switch places already checking for tabs to use the + macro, too. + + pru: use is_whitespace() + Convert open-coded checks as well as an ISSPACE() use. + + PPC: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also switch ISSPACE() uses over. At the same time + use is_end_of_stmt() instead of an open-coded nul char check. + + PicoJava: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert ISSPACE(). At the same time use + is_end_of_stmt() instead of an open-coded check in adjacent code. + + PDP11: use is_whitespace() + Convert open-coded checks. + + NS32k: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + nds32: use is_whitespace() + Convert ISSPACE() uses. + + msp430: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert ISSPACE() uses. At the same time use + is_end_of_stmt() instead of open-coded checking in code needing touching + anyway. + + Moxie: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert ISSPACE() uses. At the same time use + is_end_of_stmt() instead of an open-coded check in adjacent code. While + at it also drop a redundant whitespace skipping loop. + + mn10300: use is_whitespace() + Convert open-coded checks as well as ISSPACE() uses. At the same time + use is_end_of_stmt() instead of kind-of-open-coded checks in adjacent + code. + + mn10200: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks as well as ISSPACE() + uses. At the same time use is_end_of_stmt() instead of kind-of-open- + coded checks in adjacent code. + +2025-02-03 Jan Beulich + + MIPS: use is_whitespace() + ... for consistency of recognition of what is deemed whitespace. + + At the same time use is_end_of_stmt() instead of an open-coded nul char + check, and check for statement end in the first place in + parse_relocation(). + +2025-02-03 Jan Beulich + + MicroBlaze: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert ISSPACE() uses. At the same time use + is_end_of_stmt() instead of an open-coded check in adjacent code. + + metag: use is_whitespace() + Replace the custom is_whitespace_char(). + + M*Core: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert ISSPACE() uses. At the same time use + is_end_of_stmt() instead of an open-coded check in adjacent code. + + M68k: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. At the same time use is_end_of_stmt() instead of open- + coded checks in adjacent code. + + M68HC1x: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. At the same time use is_end_of_stmt() instead of an + open-coded check in adjacent code. + + m32r: use is_whitespace() + Convert a lonely ISSPACE(). + + m32c: use is_whitespace() + Convert open-coded checks as well as the sole ISBLANK() use throughout + the gas/ tree. + + LoongArch: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + kvx: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. At the same time use is_end_of_stmt() instead of open- + coded checks in adjacent code. + + HP-PA: use is_whitespace() + Convert open-coded checks. At the same time use is_end_of_stmt() instead + of an open-coded check in adjacent code. + + H8/300: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). At the same time use is_end_of_stmt() instead of an + open-coded check in adjacent code. + + ft32: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also switch ISSPACE() uses over. At the same time + use is_end_of_stmt() instead of open-coded checks in adjacent code. + + fr30: use is_whitespace() + Convert open-coded checks. At the same time use is_end_of_stmt() instead + of an open-coded check in adjacent code. + + Epiphany: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + CRx: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also switch ISSPACE() uses over. + +2025-02-03 Jan Beulich + + cris: use is_whitespace() + Switch ISSPACE() uses over. + + Unlike many other targets, limiting whitespace checks to just blanks is + deemed okay here: Compilers wanting to use -f / #NO_APP are apparently + required to emit only blanks (without this being written down anywhere). + +2025-02-03 Jan Beulich + + CR16: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also switch ISSPACE() uses over. + + C-Sky: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also switch ISSPACE() uses over. At the same time + use is_end_of_stmt() instead of kind-of-open-coded checks. + + dlx: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. + + d30v: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. At the same time use is_end_of_stmt() instead of open- + coded checks in adjacent code. + + d10v: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Also convert open-coded checks where tabs were + already included. At the same time use is_end_of_stmt() instead of open- + coded checks in adjacent code. + + bpf: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). Various redundant nul char checks are also dropped, + where adjacent. At the same time use is_end_of_stmt() instead of an + open-coded nul char check. + + bfin: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + +2025-02-03 Jan Beulich + + gas/obj-*.c: use is_whitespace() + ... for consistency of recognition of what is deemed whitespace. + + In obj_elf_section_name() also generalize end-of-statement recognition + at the same time. Conversely drop the unused SKIP_SEMI_COLON() for COFF. + +2025-02-03 Jan Beulich + + avr: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + + aarch64: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). + +2025-02-03 Jan Beulich + + Arm: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). At the same time use is_end_of_stmt() instead of an + open-coded nul char check. + + In parse_neon_type() be more aggressive and remove the special casing of + certain characters altogether. The original default case simply having + "break" can't have been correct. + +2025-02-03 Jan Beulich + + arc: use is_whitespace() + Wherever blanks are permissible in input, tabs ought to be permissible, + too. This is particularly relevant when -f is passed to gas (alongside + appropriate input). At the same time use is_end_of_stmt() instead of + open-coded nul char checks. + + Alpha/EVAX: use is_whitespace() / is_end_of_stmt() + Don't open-code checking for ' ', '\t', and statement ending chars. + +2025-02-03 Jan Beulich + + gas: consolidate whitespace recognition + Let's extend lex_type[] to also cover whitespace, then having a simple + macro to uniformly recognize both blanks and tabs (and \r when it's not + EOL) as such. + + In macro.c use sb_skip_white() as appropriate, instead of open-coding + it. + +2025-02-03 GDB Administrator + + Automatic date update in version.in + +2025-02-02 Tom Tromey + + Avoid "text file busy" in dw2-using-debug-str.exp + When I run: + + runtest dw2-using-debug-str.exp + + ... if I examine the gdb.log, I see: + + objcopy: unable to copy file '[...]/dw2-using-debug-str'; reason: Text file busy + + This happens because the inferior is still running, and objcopy -- + despite the invocation seemingly not needing this -- tries to open it + for writing. + + This patch works around the objcopy oddity by having gdb exit (killing + the inferior) before the invocation. + + Fixing this points out that the test does not work in the + --target_board=cc-with-gdb-index case. This patch also arranges to + issue an "untested" here. + +2025-02-02 GDB Administrator + + Automatic date update in version.in + +2025-02-01 Tom Tromey + + Remove obsolete test from gdb.cp/var-tag.exp + There is a test in gdb.cp/var-tag.exp that is kfail'd. I happened + across this while working on another series and found that the PR it + referenced was closed as invalid. On that basis I think the test + should be deleted. + + Reviewed-By: Keith Seitz + +2025-02-01 Tom Tromey + + Show type- and function-domain in maint print psymbols + I neglected to update "maint print psymbols" when adding TYPE_DOMAIN + and FUNCTION_DOMAIN. This would have been mildly helpful when + debugging a series I am working on. This patch corrects the + oversight. + + Approved-By: Andrew Burgess + +2025-02-01 GDB Administrator + + Automatic date update in version.in + +2025-01-31 Tom Tromey + + Use "false" when setting cli_styling + I noticed a spot that uses 0 where "false" is more appropriate. + +2025-01-31 Tom Tromey + + Add space in name of Rust tuple type + The Rust compiler emits tuple type names with a space after the comma, + like "(i32, f64)". This changes rust-parse.c to follow. This isn't + ideal -- probably the DWARF reader should canonicalize these names -- + but it is a bit more robust if symbol lookup should change; and anyway + this feature of gdb is probably rarely used. + +2025-01-31 Andrew Carlotti + + aarch64: Support +sme+nosve permissively + There is inconsistency regarding whether or not +sme implies +sve2 and + whether +nosve2 implies +nosme. In particular, GCC 14 assumes the + dependency exists, and canonicalises target strings accordingly, whereas + LLVM treats the features as independent. + + This patch removes the positive implication while retaining the negative + implication. This is the more permissive choice in each case, and + allows us to support target strings written with either interpretation + in mind. + + This reduces our ability to detect invalid instructions, but we already + can't rely on this detection because gas doesn't know whether functions + might be executed in streaming mode and/or non-streaming mode. + + The aarch64_feature_enable_set change is functionally redundant within + this patch. It is included because the longer term intention is to + instead remove the workaround in aarch64_parse_features, once the + internal feature checks have been modified to support having both + AARCH64_FEATURE_SME set and AARCH64_FEATURE_SVE unset. + + Similarly, the dependency from +sme to +fp16 is currently redundant, but + this redundancy relies upon an incorrect dependency from +fcma to +fp16. + This can be fixed in the future, but it might require modifying internal + feature checks for a few FCMA instructions, so it's left unchanged for + now. + +2025-01-31 Andrew Carlotti + + aarch64: Fix fp8 feature dependencies + We agreed with LLVM that we shouldn't enforce the architectural + dependencies between fp8 muliplication features, so remove them. + + Additionally, fix a typo in the gating for FEAT_SME_F8F16 instructions, + which were mistakenly gated by +sme-f8f32 instead. Until now this + mistake had been masked by the dependency between the features. + +2025-01-31 Andrew Carlotti + + aarch64: Fix overly lax +frintts dependency + We agreed with LLVM that +frintts should only enable +fp, not +simd. + This also matches the dependency used in GCC. + +2025-01-31 Lulu Cai + + LoongArch: Do not relax against __[start|stop]_SECNAME symbol + +2025-01-31 Jan Beulich + + x86/APX: correct libbfd's EVEX Rn -> Bn transformations + In the recent GOTPCREL addition I screwed up, in clearing the Rn bits + afterwards rather than setting them. While that ought to be benign (for + the bits being ignored in situations like this), we still want to leave + "canonical" encodings. + + The pre-existing GOTTPOFF conversion wasn't doing quite correctly + either: We cannot assume the incoming Bn bits to be in a particular + state, as for the addressing form in question they're ignored as well. + + To address both, introduce a helper function. This is then also an + overall reduction of (source) code size (and use of "magic" numbers). + +2025-01-31 Jan Beulich + + x86/APX: GETSEC cannot be used with REX2 + It lives in a "forbidden" row, yet its disassembler table entry was + lacking a respective marker. + +2025-01-31 Jan Beulich + + x86: support RMPREAD insn + Like for RMPUPDATE documentation is about to change as far as operands + are concerned. They're merely the other way around here. + + While adjustind gas documentation, also add the missing RMPQUERY + counterparts there. + +2025-01-31 Jan Beulich + + x86: RMPUPDATE wants operands in different form + AMD are about to update their doc, to help clarify that what we + currently do isn't quite right: In particular it is not %rax but %rcx + which is affected by address size. In fact, that's a normal memory + operand, just not expressed via ModR/M byte, but fixed to (%rcx) (or + (%ecx) with 32-bit addressing). + + To support this in the assembler, generalize memory operand handling so + far specific to XLAT (which isn't really a string insn, but requires its + memory operand to be (%bx) / (%ebx) / (%rbx)). + + In the disassembler mimic handling after XLAT's, too. + +2025-01-31 Jan Beulich + + x86-64: omit "default" segment prefixes from string insn disassembly + Printing implicit %ds: and %es: prefixes is pretty meaningless in 64-bit + mode. The SDM explicitly omits them for the 64-bit forms, and it + obviously has them for the other ones only to cover non-64-bit modes + (oddly enough the AMD PM has them present). + +2025-01-31 Jan Beulich + + RISC-V: widen LEB128 support + Do away with at least one of the limitations - all other targets permit + multiple values to be specified with a single directive. Re-arrange the + logic further to also overcome an internal error in + riscv_insert_uleb128_fixes(), as e.g. observed by the all/sleb128-2 + testcase. This way there's also no need to parse expressions twice, + thus also not raising the same diagnostics (if any) twice. + + Note how this addresses a pre-existing XFAIL (where the comment wasn't + really applicable either for RISC-V). + + Also update documentation, also to mention that differences between + symbols may be used with .uleb128 (albeit I'm uncertain whether there + are limitations). + +2025-01-31 Tom Tromey + + Use "require" a two gdb.dwarf2 test files + A couple of ".tcl" files in gdb.dwarf2 escaped notice during the + "require" refactoring. This patch fixes these to use "require" rather + than if/return. + +2025-01-31 GDB Administrator + + Automatic date update in version.in + +2025-01-30 Alexandra Hájková + + gdb: add first gdbreplay test, connect.exp + When the changes on the remote protocol are made, + we want to test all the corner cases to prevent + regressions. Currently it can be tricky to simulate + some corner case conditions that would expose possible + regressions. When I want to add or change the remote + protocol packet, I need to hack gdbserver to send a + corrupted packet or an error to make sure GDB is able + to handle such a case. + + This test makes it easy to send a corruped packet or + an error message to GDB using the gdbreplay tool and + check GDB deals with it as we expect it to. + + This test starts a communication with gdbsever setting + the remotelog file. Then, it modifies the remotelog with + update_log proc, injects an error message instead of + the expected replay to the vMustReplyEmpty packet in order + to test GDB reacts to the error response properly. After + the remotelog modification, this test restarts GDB and starts + communication with gdbreply instead of the gdbserver using + the remotelog. + + Add a lib/gdbreplay-support.exp. update_log proc matches lines + from GDB to gdbserver in a remotelogfile. Once a match is found then + the custom line is used to build a replacement line to send from + gdbserver to GDB. + + Approved-By: Andrew Burgess + +2025-01-30 Tom Tromey + + Re-enable background reading + All the reported races have been fixed, so this patch re-enabled + background DWARF reading. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751 + Tested-By: Tom de Vries + +2025-01-30 Simon Marchi + + gdb: remove unused includes from dwarf2/index-write.c + These includes are reported as unused by clangd. + + Change-Id: Ibf3cdc881abad5f5969edca623412ceac7212149 + +2025-01-30 Simon Marchi + + gdb: remove includes from dwarf2/mapped-index.h + They are unused, according to clangd. + + Add some includes to other files, which were relying on transitive + includes. + + Change-Id: I3bcb4be93b3a18bf44a4068f4067e567f83e1d4f + +2025-01-30 Simon Marchi + + gdb: remove unused include from dwarf2/read.c + It is unused, according to clangd. + + Change-Id: Ieadb84a2b1953b70d82a28775472fd347a809a62 + +2025-01-30 Simon Marchi + + gdb: remove unused include, add forward declaration in dwarf2/parent-map.h + dwarf2_per_bfd is used but never declared in this file, forward-declare + it. + + dwarf2/types.h is unused, according to clangd. + + Change-Id: I324b68894008af20307030c9e36c5abe06e36a78 + +2025-01-30 Simon Marchi + + gdb: remove unused include in symtab.h + This include is unused, according to clangd. + + Change-Id: Ifbc2fe75b02c9ae9b3e2f1184bbcc4dc7095a554 + +2025-01-30 Simon Marchi + + gdb: include symtab.h in quick-symbol.h + quick-symbol.h uses domain_search_flags, defined in symtab.h. + + Change-Id: I5c4ae272da929eb6a8dd593bcd96a2aacf0ca99f + +2025-01-30 Nick Clifton + + Remove a couple of entries in the binutils MAINTAINERS file + +2025-01-30 Tom de Vries + + [gdb/testsuite] Handle unordered dict in gdb.python/py-mi-notify.exp + With test-case gdb.python/py-mi-notify.exp and python 3.4, I occasionally run + into: + ... + python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 }) + &"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n" + =-test-notification,data2="2",data1="1" + ^done + (gdb) + FAIL: $exp: python notification, with additional data (unexpected output) + ... + + In contrast, a passing version looks like: + ... + python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 }) + &"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n" + =-test-notification,data1="1",data2="2" + ^done + (gdb) + PASS: gdb.python/py-mi-notify.exp: python notification, with additional data + ... + + The python method "gdb.notify_mi(name, data)" has parameter data which is a + dictionary, and it iterates over that dictionary. + + The problem is that dictionaries are only guaranteed to be iterating in + insertion order starting python 3.7 (though cpython does this starting python + 3.6). + + Fix this in the same way as in commit 362a867f2ac ("[gdb/testsuite] Handle + unordered dict in gdb.python/py-mi-cmd.exp"): by allowing the alternative + order. + + Tested on x86_64-linux. + +2025-01-30 H.J. Lu + + x86-64: Remove pr19609-4c.d and pr19609-4d.d + Remove pr19609-4c.d and pr19609-4d.d since they are identical to + pr19609-4a.d and pr19609-4b.d, respectively. + + * testsuite/ld-x86-64/pr19609-4c.d: Removed. + * testsuite/ld-x86-64/pr19609-4d.d: Likewise. + * testsuite/ld-x86-64/pr19609-4e.d: Renamed to ... + * testsuite/ld-x86-64/pr19609-4c.d: This. + * testsuite/ld-x86-64/x86-64.exp: Updated. + +2025-01-30 GDB Administrator + + Automatic date update in version.in + +2025-01-29 Tom Tromey + + Use command style in cmd_show_list + cmd_show_list is a bit funny because it shows partial command names -- + for a command like "show abc xyz", it will only show "abc xyz". + + Nevertheless, I think it makes some sense to highlight these with the + command style. That is what this patch does. + +2025-01-29 Tom Tromey + + Remove "enabled" output from show_index_cache_command + show_index_cache_command prints whether the index-cache is enabled. + This text was added back in 2018 in commit 87d6a7aa (Add DWARF index + cache). Then in 2021, the enabling option was changed via commit + 7bc5c369 (gdb: introduce "set index-cache enabled", deprecate "set + index-cache on/off"). + + This latter change made this output, IMO, redundant. That is, + currently gdb will show: + + (gdb) show index-cache + ... + index-cache enabled: The index cache is off. + ... + The index cache is currently disabled. + + This patch removes the redundant output. + +2025-01-29 Tom Tromey + + Use command style in "help" command + This changes the help command to use the new command style when + displaying text like: + + List of "catch" subcommands: + + As a side effect, this mildly -- but not hugely -- cleans up some i18n + issues in help_list. The header comment for that function is also + changed to the gdb style. + + Finally, this function used to print something like: + + Type "help catch" followed by catch subcommand name for full documentation. + + The second "catch" here seems redundant to me, so this patch removes + it. + +2025-01-29 Tom Tromey + + Avoid calling help_list in more places + I think there is no need to have a prefix command that simply calls + help_list. Instead, add_basic_prefix_cmd can be used. This patch + changes the relevant instances. In one spot, add_setshow_prefix_cmd + is used instead. + +2025-01-29 Simon Marchi + + gdb: include cli/cli-style.h in darwin-nat.c + PR 32610 says: + + File gdb/darwin-nat.c is missing an #include statement of + "cli/cli-style.h". It is needed because there is a reference to class + object command_style in the .c file. + + I'm not able to build-test this change (I only have access to arm64 + macos machines, which GDB doesn't support yet), but I don't think I'm + doing things worse by adding this. + + Change-Id: I2a169664ff91b92caf27cb084334f2eb4df46aa5 + +2025-01-29 Andrew Burgess + + gdb/testsuite: add comments to line table from DWARF assembler + Add comments to the assembler generated by the DWARF assembler that + builds the line table. I found these comments useful when debugging + issues with the line table parsing. + + This patch should make no difference to what is being tested. The + test binaries should be unchanged after this commit. + + Approved-By: Kevin Buettner + +2025-01-29 Tankut Baris Aktemur + + gdbserver: fix the declared type of register_status in regcache + The register_status field of regcache is declared as `unsigned char *`. + This is incorrect, because `enum register_status` from + gdbsupport/common-regcache.h is based on signed char and + REG_UNAVAILABLE is defined as -1. Fix the declared type. + + Now that we are modifying the declaration, also use a unique_ptr + and make the field private. + + The get/set methods already use the correct type, but we update cast + operations in two places. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: refactor the definition and uses of supply_regblock + The supply_regblock function takes a pointer to a buffer as an + argument and implements two different behavior based on the pointer + being null. There are two cases where we pass nullptr, all in + tracepoint.cc, where we are essentially doing a reset on the regcache. + + In fast_tracepoint_ctx::regcache, register_status array does not + even exist. Hence, that use simply boils down to zeroing of register + data. Do this at the time of creating the buffer and remove the call + to supply_regblock. + + In fetch_traceframe_registers, inline the use with a call to `reset`. + + Hence, there are no more cases left, where a nullptr would be passed + to supply_regblock. Assert that the buffer argument is non-null and + simplify the implementation. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: define and use regcache::reset + Define a `reset` method for a regcache and use it for code + simplification. This patch allows further simplification in the next + patch. + + The reset method fills the register data with zeroes. For the use in + get_thread_regcache, this is added behavior, making the patch not a + pure refactoring, and may look like extra overhead. However, it is + better to avoid having arbitrary values left in the data buffer. + Hence, it is considered a behavioral improvement. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: use REG_UNKNOWN for a regcache's register statuses + When a regcache is initialized, the values of registers are not + fetched yet. Thus, initialize the register statuses to REG_UNKNOWN + instead of REG_UNAVAILABLE, because the latter rather means "we + attempted to fetch but could not obtain the value". + + The definitions of the reg status enums (from + gdbsupport/common-regcache.h) as a reminder: + + /* The register value is not in the cache, and we don't know yet + whether it's available in the target (or traceframe). */ + REG_UNKNOWN = 0, + + /* The register value is valid and cached. */ + REG_VALID = 1, + + /* The register value is unavailable. E.g., we're inspecting a + traceframe, and this register wasn't collected. Note that this + "unavailable" is different from saying the register does not + exist in the target's architecture --- in that case, the target + should have given us a target description that does not include + the register in the first place. */ + REG_UNAVAILABLE = -1 + + Similarly, when the regcache is invalidated, change all the statuses + back to REG_UNKNOWN. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: use unique_ptr for thread_info's regcache + Store the regcache pointer in thread_info as a unique_ptr. This + allows us delete the thread_info destructor. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: convert free_register_cache into a destructor of regcache + Convert the `free_register_cache` function into a destructor of the + regcache struct. In one place, we completely remove the call to free + the regcache object by stack-allocating the object. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: convert init_register_cache and new_register_cache into constructors + This is a refactoring that converts + + init_register_cache (struct regcache *regcache, + const struct target_desc *tdesc, + unsigned char *regbuf) + + into the constructor + + regcache (const target_desc *tdesc, unsigned char *regbuf) + + and converts + + new_register_cache (const struct target_desc *tdesc) + + into the constructor + + regcache (const target_desc *tdesc) + + Also use DISABLE_COPY_AND_ASSIGN for additional compile-time safety. + + Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and + with '--enable-inprocess-agent=yes'. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: use inheritance more to define tracepoint contexts + This is a continuation of the previous refactoring to use inheritance + in the definition of tracepoints contexts. Again, no behavioral change + is intended. + + Different tracepoint contexts are identified by the `type` field. The + field is used only in `get_context_regcache`, where we essentially + have 2 cases, each corresponding to a tracepoint context type. Remove + the `type` field and split the `get_context_regcache` function into 2 + virtual method implementations. + + Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and + '--enable-inprocess-agent=yes'. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: use inheritance to define tracepoint contexts + Use inheritance in the definition of tracepoint contexts. This is a + refactoring that aims to improve the code. No behavior should be + altered. + + Approved-By: Simon Marchi + +2025-01-29 Tankut Baris Aktemur + + gdbserver: add back lost comments in fast_tracepoint_ctx + Before the removal of the UST/static-tracepoint support, the + `static_tracepoint_ctx` struct contained comments for its fields, + whereas `fast_tracepoint_ctx` did not. Nevertheless, those comments + also applied to `fast_tracepoint_ctx`. With the removal of + `static_tracepoint_ctx`, the comments were lost, making + `fast_tracepoint_ctx` data members completely commentless. Add back + those comments. + + Approved-By: Simon Marchi + +2025-01-29 Andrew Burgess + + gdbserver: introduce and use new gdb::argv_vec class + In gdbserver there are a couple of places where we perform manual + memory management using a 'std::vector' with the vector owning + the strings within it. We need to take care to call + free_vector_argv() before leaving the scope to cleanup the strings + within the vector. + + This commit introduces a new class gdb::argv_vec which wraps around a + 'std::vector' and owns the strings within the vector, taking + care to xfree() them when the gdb::argv_vec is destroyed. + + Right now I plan to use this class in gdbserver. + + But this class will also be used to address review feedback on this + commit: + + https://inbox.sourceware.org/gdb-patches/72227f1c5a2e350ca70b2151d1b91306a0261bdc.1736860317.git.aburgess@redhat.com + + where I tried to introduce another 'std::vector' which owns + the strings. That patch will be updated to use gdb::argv_vec instead. + + The obvious question is, instead of introducing this new class, could + we change the APIs to avoid having a std::vector that owns the + strings? Could we use 'std::vector' or + 'std::vector>' instead? + + The answer is yes we could. + + I originally posted this larger patch set: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + however, getting a 14 patch series reviewed is just not possible, so + instead, I'm posting the patches one at a time. The earlier patch I + mentioned is pulled from the larger series. + + The larger series already includes changes to gdbserver which removes + the need for the 'std::vector', however, getting those changes + in depends (I think) on the patch I mention above. Hence we have a + bit of a circular dependency. + + My proposal is to merge this patch (adding gdb::argv_vec) and make use + of it in gdbserver. + + Then I'll update the patch above to also use gdb::argv_vec, which will + allow the above patch to get reviewed and merged. + + Then I'll post, and hopefully merge additional patches from my larger + inferior argument series, which will remove the need for gdb::argv_vec + from gdbserver. + + At this point, the only use of gdb::argv_vec will be in the above + patch, where I think it will remain, as I don't think that location + can avoid using 'std::vector'. + + Approved-By: Tom Tromey + +2025-01-29 Andrew Burgess + + gdb: move debug output inside block in dwarf_record_line_1 + The debug output that says a line has been recorded is currently + outside the `if` block which decides if the line should be recorded or + not. This means the debug output will claim the line was recorded, + when actually it wasn't! + + Fixed by moving the debug output inside the `if` block. + + Should be no user visible changes after this commit (except if debug + output is turned on). + + Approved-By: Tom Tromey + +2025-01-29 GDB Administrator + + Automatic date update in version.in + +2025-01-28 Michael J. Eager + + MicroBlaze: Add features/microblaze-linux.xml + This is a preparatory patch to support native linux port + of gdbserver for MicroBlaze + * gdb/features/Makefile : Add microblaze-expedite + * gdb/features/microblaze-linux.xml : New + * gdb/features/microblaze-linux.c : New (generated) + * gdb/regformats/microblaze-linux.dat : New (generated) + +2025-01-28 Tom de Vries + + [gdb/tui] Fix assert in tui_source_window_base::refresh_window + Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this: + ... + $ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \ + -ex "b f2"\ + -ex run + ... + (from a directory not containing a file called main.c to make sure that the + missing source stays missing) and then issue finish: + ... + (gdb) finish + Run till exit from #0 f2 (x=4) + at f2.c:5 + 0x0000000000400570 in main () + at main.c:7 + Value returned is $1 = 13 + (gdb) + ... + and use control- to decrease the font size (IOW increase the $LINES and + $COLUMNS) on the terminal, we get: + ... + gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \ + Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ... + + The tui_source_window_base class has variable m_pad which keeps track of a + curses pad that is used to display the source code or disassembly efficiently. + + The assert in tui_source_window_base::refresh_window triggers while preparing + to display part of the pad. + + The problem is that the window is in a state in which the pad is not used, + because m_content.empty () == true. Instead, it simply shows + "[ No Source Available ]". + + Fix this by bailing out of tui_source_window_base::refresh_window before + accessing the m_pad variable, if m_content.empty () == true. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR tui/32592 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592 + +2025-01-28 Tom de Vries + + [gdb/guile] Use SCM_DEBUG_TYPING_STRICTNESS 0 + I build gdb with libguile v2.0.9, and ran into: + ... + In file included from /usr/include/guile/2.0/libguile.h:56, + from ../../gdb/guile/guile-internal.h:30, + from ../../gdb/guile/scm-arch.c:26: + /usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)': + /usr/include/guile/2.0/libguile/tags.h:97:53: error: \ + operation on '*0' may be undefined [-Werror=sequence-point] + # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x)) + ~~~~~~~~~^~~~~ + ... + + Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0. + + We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK + when using libguile v2.0.10. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2025-01-28 Tom Tromey + + Fix gdb.ada/import.exp when using mold + We found that the gdb.ada/import.exp test fails when 'mold' is used as + the linker. This happens because mold decides to mark most of the + symbols in the executable as being file-local. I tend to think this + choice, while non-traditional, is probably fine. So, this patch fixes + the problem by changing the relevant Ada code to look for file-local + symbols as well. + + Furthermore, there are two overloads of lookup_minimal_symbol_linkage + that both have a final 'bool' parameter -- but with radically + different meanings. This patch somewhat clears up this confusion as + well. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31378 + +2025-01-28 Nick Clifton + + Add translations for various sub-directories + +2025-01-28 Andrew Burgess + + gdb/remote: add 'binary-upload' feature to guard 'x' packet use + This mailing list discussion: + + https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com + + highlighted the following issue with GDB's 'x' packet implementation. + + Unfortunately, LLDB also has an 'x' packet, but their implementation + is different to GDB's and so targets that have implemented LLDB's 'x' + packet are incompatible with GDB. + + The above thread is specifically about the 'rr' tool, but there could + be other remote targets out there that have this problem. + + The difference between LLDB and GDB is that GDB expects a 'b' prefix + on the reply data, while LLDB does not. The 'b' is important as it + allows GDB to distinguish between an empty reply (which will be a 'b' + prefix with no trailing data) and an unsupported packet (which will be + a completely empty packet). It is not clear to me how LLDB + distinguishes these two cases. + + See for discussion of the 'x' packet: + + https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r + + with the part specific to the 'b' marker in: + + https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/ + + I propose that we add a new feature 'binary-upload' which can be + reported by a stub in its qSupported reply. By default this feature + is "off", meaning GDB will not use the 'x' packet unless a stub + advertises this feature. + + I have updated gdbserver to send 'binary-upload+', and when I examine + the gdbserver log I can see this feature being sent back, and then GDB + will use the 'x' packet. + + When connecting to an older gdbserver, the feature is not sent, and + GDB does not try to use the 'x' packet at all. + + I also built the latest version of `rr` and tested using current HEAD + of master, where I see problems like this: + + (rr) x/10i main + 0x401106
: Cannot access memory at address 0x401106 + + Then tested using this patched version of GDB, and now I see: + + (rr) x/10i main + 0x401106
: push %rbp + 0x401107 : mov %rsp,%rbp + 0x40110a : mov 0x2f17(%rip),%rax # 0x404028 + ... etc ... + + and looking in the remote log I see GDB is now using the 'm' packet + instead of the 'x' packet. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593 + Reviewed-By: Eli Zaretskii + Reviewed-By: Tankut Baris Aktemur + +2025-01-28 Guinevere Larsen + + gdb/configure: fail configure if all targets requested with 32bit bfd + As PR sim/28684 explains, it isn't possible to compile GDB with all + targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd + is forced, so the build works, but in 32 bit hosts, that has to be + explicitly enabled. + + I ran into this when I tried compiling GDB on a mips64 machine running a + 32 bit OS. Along with the errors in the PR, several other architectures + are also required, notably aarch64 and other explicitly 64bit targets. + Additionally, some 32 bit files required for the gdb mips target aren't + added to the makefile. + + Considering the last comment in the bug says this isn't going to be + fixed on the binutils side, I didn't think it was worth trying to fix + the GDB side. Instead, this commit causes the configure script to fail + if all targets were requested and 64 bit bfd isn't enabled. If that is + ever fixed, we can revert this commit. + + I considered adding this to the top level configure script, but couldn't + figure out how to detect the situation in there, so this was my next + best idea. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684 + Approved-by: Kevin Buettner + +2025-01-28 Tom de Vries + + [gdb/doc] Fix "Standard Replies" xref + When building gdb with an older makeinfo (4.13), I run into: + ... + gdb/doc/gdb.texinfo:42613: warning: `.' or `,' must follow @xref, not `f'. + ... + + This is related to this line: + ... + @xref{Standard Replies} for standard error responses, and how to + respond indicating a command is not supported. + ... + + Fix this by adding a comma. + + Tested by rebuilding the docs. + + Reviewed-By: Eli Zaretskii + Co-Authored-By: Eli Zaretskii + +2025-01-28 GDB Administrator + + Automatic date update in version.in + +2025-01-27 Michael J. Eager + + MicroBlaze: Widen mask used in opcodes/microblaze-dis,c + Instead of using 0xFFFF0000, or with (~0xFFFF) to sign extend + negative 16-bit value and with (~0xFFFF) to extract higher order + address bits + + opcodes/ + * microblaze-dis.c: (print_insn_microblaze): Widen mask + (microblaze_get_target_address): Likewis + +2025-01-27 Jens Remus + + s390: Error if vector index register omitted in assembly + Vector index registers are currently only used in the VRV instruction + format. Unlike general purpose index registers an operand value of + zero (e.g. %v0, 0, or omitted) does not imply a zero value: + + "For VRV format instructions, a vector element is used in the formation + of the intermediate value. This vector element is an unsigned binary + integer value that is added to the base address and 12-bit displacement + to form a 64-bit intermediate sum. The vector element is designated by + a vector register and an element index. A zero V field accesses the + element in vector register zero and does not imply a zero value." [1] + + Therefore require vector index register operands to be specified in + assembler source. That is do require coding of D(VX,B) instead of + allowing to omit VX=0 as D(,B), D(B), or D. Emit an error message if + a mandatory vector index register is omitted: + + Error: operand : missing vector index register operand + + Note that this change is not backwards compatible. But any code that + omitted the specification of the vector index register is likely to be + in error. Therefore it is favorable to report an error than to stay + backward compatible. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + gas/ + * config/tc-s390.c (md_gather_operands): Do not allow + vector index register operands to be optionally omitted. + + gas/testsuite/ + * gas/s390/zarch-base-index-0.d (vgef): Remove tests with + omitted vector index register operands. + * gas/s390/zarch-base-index-0.s (vgef): Move tests with omitted + vector index register operands ... + * gas/s390/zarch-base-index-0-err.s (vgef): ... to here. + * gas/s390/zarch-base-index-0-err.l (vgef): Expect error + for omitted vector index register operands. + * gas/s390/zarch-omitted-base-index.d (vgef): Remove tests with + omitted vector index register operands. + * gas/s390/zarch-omitted-base-index.s (vgef): Move tests with + omitted vector index register operands ... + * gas/s390/zarch-omitted-base-index-err.s (vgef): ... to here. + * gas/s390/zarch-omitted-base-index-err.l (vgef): Expect error + for omitted vector index register operands. + * gas/s390/zarch-warn-areg-zero.l (vgef): Remove tests with + omitted vector index register operands. + * gas/s390/zarch-warn-areg-zero.s (vgef): Likewise. + +2025-01-27 Jens Remus + + s390: Do not warn about vector index register 0 in assembly + Vector index registers are currently only used in the VRV instruction + format. Unlike general purpose index registers an operand value of + zero (e.g. %v0, 0, or omitted) does not imply a zero value: + + "For VRV format instructions, a vector element is used in the formation + of the intermediate value. This vector element is an unsigned binary + integer value that is added to the base address and 12-bit displacement + to form a 64-bit intermediate sum. The vector element is designated by + a vector register and an element index. A zero V field accesses the + element in vector register zero and does not imply a zero value." [1] + + Therefore when using s390-specific assembler option "-mwarn-areg-zero" + do not warn if vector index register 0 is specified. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + gas/ + * config/tc-s390.c (md_gather_operands): Do not warn about + vector index register 0. + + gas/testsuite/ + * gas/s390/zarch-warn-areg-zero.l (vgef): Do not expect warning + about vector index register 0. + +2025-01-27 Jens Remus + + s390: Do not omit vector index register 0 in disassembly + Vector index registers are currently only used in the VRV instruction + format. Unlike general purpose index registers an operand value of + zero (e.g. %v0, 0, or omitted) does not imply a zero value: + + "For VRV format instructions, a vector element is used in the formation + of the intermediate value. This vector element is an unsigned binary + integer value that is added to the base address and 12-bit displacement + to form a 64-bit intermediate sum. The vector element is designated by + a vector register and an element index. A zero V field accesses the + element in vector register zero and does not imply a zero value." [1] + + Therefore do not omit vector index register 0 in disassembly, that is + disassemble D(VX,B) with VX=0 as D(VX,B) instead of D(B). Also do not + disassemble index register 0 as "0", that is disassemble D(VX,B) with + VX=0 as D(%v0,B) instead of D(0,B). Note that a base register 0 still + still gets disassembled as "0", that is D(VX,B) with B=0 disassembles + into D(VX,0). + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + opcodes/ + * s390-dis.c (s390_print_insn_with_opcode): Do not omit vector + index register 0 in disassembly. Disassemble it as %v0. + + gas/testsuite/ + * gas/s390/zarch-base-index-0.d (vgef): Expect vector index + register 0 in disassembly. + * gas/s390/zarch-omitted-base-index.d (vgef): Likewise. + + Suggested-by: Florian Krohm + +2025-01-27 Jens Remus + + s390: Additional tests for omitted base register operands + This complements commit aacf780bca29 ("s390: Allow to explicitly omit + base register operand in assembly"). + + gas/testsuite/ + * gas/s390/zarch-warn-areg-zero.l: Add tests for omitted base + register operands. + * gas/s390/zarch-warn-areg-zero.s: Likewise. + +2025-01-27 Jens Remus + + s390: Generate .eh_frame unwind information for .plt section + Enable unwinding using .eh_frame information through PLT entries. Based + on x86-64. + + This enhances stack traces if the instruction pointer is in a PLT entry. + For instance perf call graphs, when using --call-graph=dwarf, and Glibc + backtraces, when using backtrace() e.g. from a signal handler. + Note that GDB could already unwind through PLT entries using its s390- + specific prologue unwinder. + + Furthermore this lays the foundation to generate SFrame information for + the PLT section in the future. + + bfd/ + * elf64-s390.c: Include dwarf2.h. + (PLT_CIE_SIZE, PLT_FDE_SIZE, + PLT_FDE_START_OFFSET, PLT_FDE_LEN_OFFSET, + elf_s390x_eh_frame_plt): New .eh_frame template for .plt + section. + (elf_s390_link_hash_table): Add plt_eh_frame field. + (elf_s390_create_dynamic_sections): New s390-specific wrapper + around _bfd_elf_create_dynamic_sections. Create .eh_frame + section for .plt section. + (elf_backend_create_dynamic_sections): Register s390-specific + elf_s390_create_dynamic_sections. + (elf_s390_late_size_sections): Fill in .eh_frame section for + .plt section. Write .plt section size into .eh_frame FDE + covering .plt section. + (elf_s390_finish_dynamic_sections): Write .plt section start + into .eh_frame FDE covering .plt section. Call + _bfd_elf_write_section_eh_frame on on htab->plt_eh_frame + section. + + ld/ + * NEWS: Add news entry. + * emulparams/elf64_s390.sh: Include plt_unwind.sh. + + ld/testsuite/ + * ld-s390/plt_64-1_eh.wf: New PLT .eh_frame generation test. + * ld-s390/s390.exp: Link some existing test cases with + --no-ld-generated-unwind-info so that they do not fail. Run + new PLT .eh_frame generation test. + +2025-01-27 Jens Remus + + s390: Add basic PLT generation tests + ld/testsuite/ + * ld-s390/plt_31_non-pic-1.pd: New non-PIC/PIE PLT generation + test for 31-bit. + * ld-s390/plt_31_pic-1.pd: New PIC/PIE PLT generation test for + 31-bit. + * ld-s390/plt_31-1.wf: New PLT generation test for 31-bit. + * ld-s390/plt_64-1.pd: New PLT generation test for 64-bit. + * ld-s390/plt_64-1.wf: Likewise. + * ld-s390/plt-1.s: New PLT generation test for 31/64-bit. + * ld-s390/pltlib.s: Likewise. + * ld-s390/s390.exp: Run new PLT generation tests. + +2025-01-27 Jens Remus + + s390: Fix linker s390 emulation option parsing + Append s390-specific emulation options to the shell variables instead of + replacing their contents. + + ld/ + * emultempl/s390.em (PARSE_AND_LIST_LONGOPTS, + PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Append to + emulation options instead of replacing them. + + Fixes: b4cbbe8f7294 ("S/390: Add support for pgste marker") + +2025-01-27 Jens Remus + + s390: s390_machine leak + Simplify the .machine directive parsing logic, so that cpu_string is + always xstrdup'd and can therefore always be xfree'd before returning + to the caller. + + This resolves the following memory leak reported by ASAN: + + Direct leak of 13 byte(s) in 3 object(s) allocated from: + #0 0x3ff8aafbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x2aa338861cf in xmalloc ../../libiberty/xmalloc.c:149 + #2 0x2aa338868ff in xstrdup ../../libiberty/xstrdup.c:34 + #3 0x2aa320253cb in s390_machine ../../gas/config/tc-s390.c:2172 + #4 0x2aa31fddc7b in read_a_source_file ../../gas/read.c:1293 + #5 0x2aa31f4f7bf in perform_an_assembly_pass ../../gas/as.c:1223 + #6 0x2aa31f4f7bf in main ../../gas/as.c:1436 + #7 0x3ff8a02be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #8 0x3ff8a02bf33 in __libc_start_main_impl ../csu/libc-start.c:360 + #9 0x2aa31f5758f (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...) + + While at it add tests with double quoted .machine + "[+...]" values. + + gas/ + * config/tc-s390.c (s390_machine): Simplify parsing and free + cpu_string before returning. + + gas/testsuite/ + * gas/s390/machine-parsing-1.l: Add tests with double quoted + values. + * gas/s390/machine-parsing-1.s: Likewise. + +2025-01-27 Jens Remus + + s390: s390_machinemode leak + This resolves the following memory leak reported by ASAN: + + Direct leak of 17 byte(s) in 1 object(s) allocated from: + #0 0x3ffb32fbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x2aa149861cf in xmalloc ../../libiberty/xmalloc.c:149 + #2 0x2aa149868ff in xstrdup ../../libiberty/xstrdup.c:34 + #3 0x2aa1312391f in s390_machinemode ../../gas/config/tc-s390.c:2241 + #4 0x2aa130ddc7b in read_a_source_file ../../gas/read.c:1293 + #5 0x2aa1304f7bf in perform_an_assembly_pass ../../gas/as.c:1223 + #6 0x2aa1304f7bf in main ../../gas/as.c:1436 + #7 0x3ffb282be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #8 0x3ffb282bf33 in __libc_start_main_impl ../csu/libc-start.c:360 + #9 0x2aa1305758f (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...) + + gas/ + * config/tc-s390.c (s390_machinemode): Free mode_string before + returning. + +2025-01-27 Tom de Vries + + [gdb/build] Fix build with gcc 7.5.0 + When building gdb with gcc 7.5.0, I run into: + ... + gdb/dwarf2/cooked-index.c: In lambda function: + gdb/dwarf2/cooked-index.c:104:5: error: \ + the value of ‘_sch_tolower’ is not usable in a constant expression + }; + ^ + In file included from gdbsupport/gdb-safe-ctype.h:47:0, + from gdb/dwarf2/cooked-index.c:34: + include/safe-ctype.h:111:29: note: ‘_sch_tolower’ was not declared ‘constexpr’ + extern const unsigned char _sch_tolower[256]; + ^~~~~~~~~~~~ + ... + + This does not happen with gcc 8.2.1. + + Fix this by dropping the constexpr on lambda function munge in + cooked_index_entry::compare for gcc 7. + + Tested by completing the build on x86_64-linux. + + Approved-By: Tom Tromey + +2025-01-27 Tom de Vries + + [gdb/doc] Use more lower-case in @sc in the documentation + When building gdb with an older makeinfo (4.13), I run into: + ... + gdb/doc/gdb.texinfo:49064: warning: @sc argument all uppercase, thus no effect. + ... + + Using a grep, I found one more instance: + ... + $ grep @sc gdb/doc/*.tex* | egrep -v '@sc{[^A-Z]*}' + gdb/doc/gdb.texinfo:\ + Bit 1 (@sc{ZA}) shows whether the @code{ZA} register state is active (in use) or + gdb/doc/python.texi:\ + corresponding @sc{GDB/MI} command's output. Refer to the + ... + + Fix this by using lowercase letters in the @sc argument, similar to how that + was done in commit c96452ad168 ("Use lower-case in @sc in the documentation"). + + Tested by rebuilding the documentation. + +2025-01-27 Tom de Vries + + [gdb/doc] Fix qIsAddressTagged anchor + When building gdb with an older makeinfo (4.13), I run into: + ... + gdb/doc/gdb.texinfo:44159: @anchor expected braces. + gdb/doc/gdb.texinfo:44159: ` {qIsAddressTagged} + ... + + This is related to this line: + ... + @anchor {qIsAddressTagged} + ... + + Fix this by removing the space before the left brace. + + Tested by rebuilding the documentation. + +2025-01-27 Tom de Vries + + [gdb/doc] Fix gdb.unwinder docs + When building gdb with an older makeinfo (4.13), I run into: + ... + gdb/doc/python.texi:3015: warning: `(' follows defined name \ + `gdb.unwinder.Unwinder.__init__' instead of whitespace. + gdb/doc/python.texi:3041: warning: `(' follows defined name \ + `gdb.unwinder.FrameId.__init__' instead of whitespace. + ... + + The warnings are related to these two lines: + ... + @defun gdb.unwinder.Unwinder.__init__(name) + ... + @defun gdb.unwinder.FrameId.__init__(sp, pc, special = @code{None}) + ... + + Indeed, when checking the command and variable index, we can see that it + contains an incorrect entry: + ... + gdb.unwinder.FrameId.__init__(sp,: Unwinding Frames in Python + ... + + Fix this by adding a space before the left parenthesis. + + Tested by rebuilding the documentation and checking the command and variable + index. + +2025-01-27 Yury Khrustalev + + Fix some broken links in docs and comments + Reviewed-By Richard Earnshaw + +2025-01-27 Christopher Wellons + + Exclude libpthread from automatic export generation + Before this change, static linking libwinpthread, commonly distributed + as part of Mingw-w64, while using automatic symbol exports would export + the entire threading API, which is never wanted. This is always the case + when static linking libstdc++ built against libpthread. + +2025-01-27 GDB Administrator + + Automatic date update in version.in + +2025-01-26 H.J. Lu + + ld-x86-64/pr19609-2d.d: Move "#pass" to the end + * testsuite/ld-x86-64/pr19609-2d.d: Move "#pass" to the end. + +2025-01-26 Alan Modra + + loongson buffer overflow + bfd_elfNN_loongarch_set_data_segment_info can be called from the target + after_allocation function with a non-ELF hash table. This is seen in + the ld-elf pr21884 testcase. Fix the problem by first checking the + hash table type before writing to a loongarch_elf_hash_table field. + +2025-01-26 Alan Modra + + PR32599, objcopy -I ihex: invalid operation + Restores ihex get_symtab_upper_bound to what it was prior to commit + 394a3f4f8d. This will enable objcopy of other no-sym formats too. + + PR 32599 + * libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define + as _bfd_long_bfd_0. + * libbfd.h: Regenerate. + +2025-01-26 GDB Administrator + + Automatic date update in version.in + +2025-01-25 Alan Modra + + Re: ld plugin bfd_make_readable leak + Commit 3097045a18a8 runs into an abort in objalloc_free_block when the + memory being bfd_release'd wasn't bfd_alloc'd. Fix that. + + * coffgen.c (_bfd_coff_free_cached_info): Don't release + raw_syments when obj_coff_keep_raw_syms. + * libcoff-in.h (obj_coff_keep_raw_syms): Define. + (struct coff_tdata): Add keep_raw_syms. + * peicode.h (pe_ILF_build_a_bfd): Set obj_coff_keep_raw_syms. + * libcoff.h: Regenerate. + +2025-01-25 GDB Administrator + + Automatic date update in version.in + +2025-01-24 Tom Tromey + + Fix C++ template function matching in cooked index + In commit 64a97606 ("Support template lookups in + strncmp_iw_with_mode"), gdb was changed so that a command like "break + func" would match instantiations like "func>". + + The new indexer does not support this and so this is a regression. + This went unnoticed because gdb.linespec.cpcompletion.exp puts all + these functions into the main file, and this CU is expanded early. + + This patch fixes the bug by changing the cooked index entry comparison + function. It also updates the test to fail without this fix. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482 + +2025-01-24 Ciaran Woodward + + gdb/riscv: Add command to switch between numeric & abi register names + In RISC-V, the general registers can be shown in their abi + form (e.g. sp, a0) or their numeric form (e.g. x2, x10). + Depending on context/preference, someone may prefer to + see one form over the other. The disassembler already + supports this configuration, which can be changed using + the 'set disassembler-options numeric' command. + + This commit adds a new set/show command to change gdb's + preference: 'set riscv numeric-registers-names on/off'. + + If on, 'info registers' and other situations will print + the numeric register names, rather than the abi versions. + The alias generation has been modified so that the abi + versions are still available for access if specifically + requested such as 'print $ra'. This was done by changing + the behaviour of the code which adds the aliases: all + register names will be added as aliases, even if the name + is the primary one. + + There is also no functional downside to adding aliases + which are surplus-to-requirement, since they will be + ignored if there is a 'true' register with the same + name. + + Approved-By: Andrew Burgess + +2025-01-24 Tom de Vries + + [gdb/tdep] Fix gdb.ada/O2_float_param.exp on s390x-linux + With test-case gdb.ada/O2_float_param.exp on s390x-linux, I get: + ... + (gdb) frame^M + #0 callee.increment (val=99.0, val@entry=, msg=...) at callee.adb:19^M + 19 procedure Increment (Val : in out Float; Msg: String) is^M + (gdb) FAIL: $exp: scenario=all: frame + ... + + The frame command calls read_frame_arg to get: + - the current value of val, and + - the value of val at function entry. + + The first scenario succeeds, and the second scenario fails. + + For context and contrast, let's also investigate the first scenario: getting + the current value of val. + + Function parameter val: + ... + <2>: Abbrev Number: 4 (DW_TAG_formal_parameter) + DW_AT_name : val + DW_AT_type : <0xb86> + DW_AT_location : 0xab (location list) + ... + has location list: + ... + 000000ab 0000000001002928 0000000001002967 + (DW_OP_reg16 (f0)) + 000000be 0000000001002967 0000000001002968 + (DW_OP_reg24 (f8)) + 000000d1 0000000001002968 0000000001002974 + (DW_OP_GNU_regval_type: 24 (f8) <0xb29>; + DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus; + DW_OP_stack_value) + 000000ef 0000000001002974 0000000001002982 + (DW_OP_GNU_entry_value: (DW_OP_GNU_regval_type: 16 (f0) <0xb29>); + DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus; + DW_OP_stack_value) + 0000010f + ... + and since we're stopped at address 0x1002928: + ... + (gdb) print $pc + $1 = (access procedure) 0x1002928 + ... + we get the value from dwarf register 16. + + The s390x ABI [1] specifies that dwarf register 16 maps onto 8-byte register + f0 or 16-byte register v0 (where f0 is part of v0), and in this case (because + the v0 register is available) s390_dwarf_reg_to_regnum maps it to v0. + + Val is only 4 bytes: + ... + (gdb) ptype val + type = <4-byte float> + ... + and s390_value_from_register takes care to get the value from the correct part + of v0. + + The value of v0 is found in the prologue cache, and the value of parameter val + is printed. + + Now the second scenario: getting the value of val at function entry. + + FWIW, since we're stopped at function entry, we could simply return the same + value, reading the same register, but that's currently not implemented [2]. + + Instead we start from the fact that val is in dwarf reg 16 at function entry, + and then use call site information: + ... + <4>: Abbrev Number: 13 (DW_TAG_GNU_call_site) + DW_AT_low_pc : 0x1002a46 + DW_AT_abstract_origin: <0xdda> + <5>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter) + DW_AT_location : 1 byte block: 60 (DW_OP_reg16 (f0)) + DW_AT_GNU_call_site_value: 3 byte block: f5 18 2d \ + (DW_OP_GNU_regval_type: 24 (f8) <0xc42>) + <5>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter) + ... + to conclude that the value we're looking for is in dwarf reg 24, which + s390_dwarf_reg_to_regnum maps to v8. + + As before, s390_value_from_register takes care to get the value from the + correct part of v8. + + However, v8 is not available in the prologue cache, and we take a different + path and end up in s390_unwind_pseudo_register, where v8 and similar + (regnum_is_vxr_full) is unhandled, and we get: + ... + return value::allocate_optimized_out (type); + ... + which eventually causes the "error reading variable: register has not been + saved in frame". + + Fix this by handling the regnum_is_vxr_full case in + s390_unwind_pseudo_register, similar to how that is done in + s390_pseudo_register_read. + + Tested on s390x-linux. + + This also fixes test-case gdb.base/savedregs.exp. + + [1] https://github.com/IBM/s390x-abi + [2] https://sourceware.org/pipermail/gdb-patches/2024-September/211589.html + +2025-01-24 Tom de Vries + + [gdb/testsuite] Record less in gdb.reverse/time-reverse.exp + While stepping through gdb.reverse/time-reverse.exp I realized that we're + recording the instructions for resolving the PLT entries for functions time + and syscall, while that's not really the focus of the test-case. + + Limit the scope of the test, by calling the functions once before starting + to record. + + Also call "info record" after recording to make it clear how many + instructions were recorded. + + On x86_64-linux, before this patch (but with info record added), we have: + ... + $ grep "Log contains" gdb.log + Log contains 750 instructions. + Log contains 1218 instructions. + ... + and with this patch we have: + ... + $ grep "Log contains" gdb.log + Log contains 24 instructions. + Log contains 19 instructions. + ... + + Tested on x86_64-linux. + + Approved-By: Guinevere Larsen + +2025-01-24 Richard Earnshaw + + aarch64: Fix PLT fixups when BTI is used [PR32572] + PR ld/32572 + + There are two problems addressed in this PR. Firstly, the choice of + whether or not a PLT stub needs a BTI on entry was too strict, + resulting in non-pie executables not having a BTI on their stub. But + secondly, the logic to handle each stub types did not agree across the + various places where this information is used. + + The first issue is fixed by using bfd_link_executable rather than + bfd_link_pde. The second is addressed by recording a delta for PLT + stub alongside the stub itself. This is then used without needing + additional logic later on since it has been pre-calculated. + + A more comprehensive fix would involve creating a data structure to + describe each fixup, including a call-back function to apply any + relocations. But that's a fairly large change and not appropriate for + backporting. + +2025-01-24 Jan Beulich + + x86-64: tighten convert-load-reloc checking + Even if the assembler avoids using relaxable relocations for + inapplicable insns, such relocations can still appear for other reasons. + Be more thorough in the opcode checking we do, to avoid bogusly altering + other insns. + + Furthermore correct an opcode mask (even if with the added condition + that's now fully benign). + +2025-01-24 Jan Beulich + + x86/APX: widen @gotpcrel and @gottpoff support (incl to MOVRS) + If legacy-encoded arithmetic insns are eligible for @gotpcrel + relaxation, EVEX-encoded ones ought to be, too. + + Further anything that MOV-from-memory can be used for (and transformed + from) should then also extend to MOVRS. + + While extending the apx-load* testcases add -mrelax-relocations=yes to + the two ones which were missing this: Without this option the intended + testing would not occur on configurations defaulting the option to off. + +2025-01-24 GDB Administrator + + Automatic date update in version.in + +2025-01-23 Jose E. Marchesi + + bfd: fix generation of bfd.texi in out-of-tree builds + [In the sequel TS means $(top_srcdir) and TB means $(top_builddir)] + + The Texinfo file TS/bfd/doc/bfd.texi @includes many other .texi files + such as: + + bfdt.texi + bfdio.texi + section.texi + ... + + These .texi files are generated from the bfd/*.c source files, by a + program called `chew' that is distributed along with BFD, via some + default rules and macro magic in TS/bfd/doc/local.mk. Important + point: the .texi files are generated in TB/bfd/doc/, not TS/bfd/doc. + + Now, AM_MAKEINFOFLAGS in local.mk is defined as: + + AM_MAKEINFOFLAGS = --no-split -I "$(srcdir)/%D%" -I %D% + + Where %D% is 'doc/' in this case. Now, it looks like the directory + containing the .texi file is automatically inserted in the @include + search path, so the -I %D% above places TB/bfd/doc _after_ TS/bfd/doc. + + Since currently TS/bfd/doc/bfdt.texi is outdated and is missing some + nodes, the error above happens. + + This patch changes bfd/doc/local.mk to use -P to prepend the current + build directory to the @include search path, rather than -I, which + appends it. + + bfd/ChangeLog: + + 2025-01-23 Jose E. Marchesi + + * doc/local.mk (AM_MAKEINFOFLAGS): Prepend the build directory to + the @include search path. + * Makefile.in: Regenerate. + +2025-01-23 Tom de Vries + + [gdb/cli] Fix return from frame containing inline frame + Consider test-case gdb.base/return-3.exp: + ... + $ gdb -q outputs/gdb.base/return-3/return-3 + Reading symbols from outputs/gdb.base/return-3/return-3... + (gdb) + ... + + Function bar is an inlined function, and consequently we cannot return from + it: + ... + (gdb) b bar + Breakpoint 1 at 0x4006ac: file return-3.c, line 25. + (gdb) r + Starting program: return-3 + ... + Breakpoint 1, bar () at return-3.c:25 + 25 c++; + (gdb) return + Can not force return from an inlined function. + (gdb) + ... + + However, function foo is not an inline function, and we should be able to + return from it, but we get the same error message: + ... + (gdb) up + 31 bar (); + (gdb) return + Can not force return from an inlined function. + (gdb) + ... + + Fix this by using the selected frame rather than the current frame in + return_command, such that we get instead: + ... + (gdb) up + 31 bar (); + (gdb) return + 40 printf ("%d\n", c); + (gdb) + ... + + Tested on aarch64-linux. + + Reviewed-By: Guinevere Larsen + + PR cli/32479 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479 + +2025-01-23 Surya Kumari Jangala + + PowerPC: Add support for RFC02657 - AES acceleration instructions + opcodes/ + * ppc-opc.c (insert_m2, extract_m2): New functions. + (AESM, PGF1, XX2M, XX3M, XX3GF, XX2AES_MASK, XX2AESM_MASK, + XX3AES_MASK, XX3AESM_MASK, XX3GF_MASK): New macros. + (UIM): Update for new macros. + (powerpc_opcodes): Add xxaes128encp, xxaes192encp, xxaes256encp, + xxaesencp, xxaes128decp, xxaes192decp, xxaes256decp, xxaesdecp, + xxaes128genlkp, xxaes192genlkp, xxaes256genlkp, xxaesgenlkp, + xxgfmul128gcm, xxgfmul128xts, xxgfmul128. + + gas/ + * testsuite/gas/ppc/future.s: New test. + * testsuite/gas/ppc/future.d: Likewise. + +2025-01-23 Torbjörn SVENSSON + Guillaume VACHERIAS + + ld: fix alignment issue for ARM thumb long branch stub using PureCode section + When pure-code option is activated. The linker creates for M-profile architecures + a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte + alignment instead of 4-byte alignment. This is a problem for long branch stub + without pure-code section as it contains a 32-bit address as data, which is expected + to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed + by a long branch stub will result in a misalignment for the 32-bit address. + + An easy fix is to add a nop instruction after the branch to keep the section alignment + to 4 bytes. + +2025-01-23 Alan Modra + + ld plugin bfd_make_readable leak + bfd_make_readable leaks memory that could be freed by + _free_cached_info except that does too much in releasing all bfd + memory. (The fact that we had to hack around keeping the bfd filename + also indicates that releasing all bfd memory was too much.) So this + patch moves code releasing bfd_alloc'd memory to the COFF + _free_cached_info, where the syms and suchlike are released. This is + the memory that archive handling wants to release in the call there to + bfd_free_cached_info. + + * coffgen.c (_bfd_coff_free_cached_info): Release syms. + * opncls.c (_bfd_new_bfd): Correct error return path. + (_bfd_free_cached_info): Don't kill all abfd->memory. + (_bfd_delete_bfd): Adjust fallback for bfd_free_cached_info. + (bfd_make_readable): Call target bfd_free_cached_info and + _bfd_free_cached_info plus reinstate section_htab. + +2025-01-23 Alan Modra + + ld compact eh-frame leak + u.compact.extries wasn't being freed anywhere. Free it when + destroying the linker hash table. Also free u.dwarf.aray there in + case errors result in the linker not getting to the slightly earlier + free in write_dwarf_eh_frame_hdr. + + * elf-eh-frame.c (write_dwarf_eh_frame_hdr): Don't exit without + freeing u.dwarf.array. + * elflink.c (_bfd_elf_link_hash_table_free): Free u.compact.entries + and u.dwarf.array. + +2025-01-23 Alan Modra + + ld plugin.c concat leaks + * ldlang.c: Whitespace. + (stat_free, stat_concat): New functions. + * ldlang.h (stat_free, stat_concat): Declare. + * plugin.c (asymbol_from_plugin_symbol): Use stat_concat. + +2025-01-23 Alan Modra + + unusual eh_frame memory leak + This one happens with --gc-sections and a linker script that either + discards some or all .eh_frame sections (eg. ld-elf/pr14265 test) or + maps an input .eh_frame to some other named output section. In that + case the discarded/renamed .eh_frame won't have local_cies freed. + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Correct comment. + * elf.c (_bfd_elf_free_cached_info): Free eh_frame cies. + +2025-01-23 Alan Modra + + Another ldelf_before_allocation leak + This fixes an even more obvious leak. + + * ldelf.c (ldelf_before_allocation): Free copied elf_dt_audit. + Simplify loop. + +2025-01-23 Alan Modra + + More ld testsuite fixes + * testsuite/ld-elf/indirect.exp: Run compiler capability checks + using run_host_noleak. + * testsuite/ld-ifunc/ifunc.exp: Don't exit without restoring + ASFLAGS. Don't run ifuncmod5 twice. + +2025-01-23 Sam James + + ld: fix bashism in scripttempl/elf.sc + ld/ + PR ld/32580 + + * scripttempl/elf.sc: Fix '==' bashism. + +2025-01-23 GDB Administrator + + Automatic date update in version.in + +2025-01-22 Tom Tromey + + Remove gnatmake_version_at_least + This removes gnatmake_version_at_least in favor of using the more + flexible gnat_version_compare. I think these two version numbers + should be the same, as gnatmake is shipped with the compiler. + + Avoid crash with 'length + While testing gnat-llvm, I found a gdb crash when applying 'length to + a non-array type. This patch fixes the crash. + + Preserve local variables in another Ada test case + I found another Ada test case where gnat-llvm optimizes away the local + variables. This patch applies the same fix to it as previous patches. + +2025-01-22 Andrew Burgess + + bfd/doc: use abs_srcdir when creating symlinks + After commit: + + commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3 + Date: Fri Dec 3 00:23:20 2021 -0500 + + bfd: merge doc subdir up a level + + And the follow-up commit: + + commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33 + Date: Wed Oct 2 22:58:08 2024 +0300 + + bfd: fix unnecessary bfd.info regen + + There is still a problem building the bfd docs from a release tar + file. + + As the release tar file contains the pre-generated .texi files we + expect the bfd/doc build stage to symlink to the pre-existing .texi + files in the source tree. + + However, this is still not working as expected if $(srcdir) is + relative. The problem is this line in REGEN_TEXI: + + test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \ + + This is executed from the build/bfd/ directory, so if $(srcdir) is + relative, then this will get you from the bfd/ directory in the build + tree to the corresponding bfd/ directory in the src tree. However, + the symlink is created in the bfd/doc/ build directory. The relative + path will then fail to take you to the bfd/ directory in the src + tree. + + Fix this by using $(abs_srcdir) when creating the symlink. + + Approved-By: Nick Clifton + +2025-01-22 Tom de Vries + + [gdb/testsuite] Fix gdb.base/branch-to-self.exp on arm-linux + On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and + test-case gdb.base/branch-to-self.exp I run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Breakpoint 2, main () at branch-to-self.c:38^M + 38 for (;;); /* loop-line */^M + (gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint + si^M + 0x0040058c 38 for (;;); /* loop-line */^M + (gdb) FAIL: $exp: single-step: si + ... + + In contrast, on the same machine but with debian testing and gcc 14.2.0 we have: + ... + (gdb) continue^M + Continuing.^M + ^M + Breakpoint 2, main () at branch-to-self.c:38^M + 38 for (;;); /* loop-line */^M + (gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint + si^M + ^M + Breakpoint 2, main () at branch-to-self.c:38^M + 38 for (;;); /* loop-line */^M + (gdb) PASS: $exp: single-step: stepi + ... + + The difference is in the instruction(s) generated for the loop. + + In the passing case, we have: + ... + 588: eafffffe b 588 + ... + and in the failing case: + ... + 588: e320f000 nop {0} + 58c: eafffffd b 588 + ... + + The purpose of this part of the test-case is to: + - generate a branch instruction that jumps to itself, and + - set a breakpoint on it, and check that stepi-ing from that breakpoint + triggers the breakpoint again. + + As we can see, in the failing case we failed to generate a branch instruction + that jumps to itself, and consequently we cannot expect to hit the breakpoint + again after issuing a single si. + + Fix this by issuing stepi until we hit the breakpoint. + + Tested on arm-linux. + + Reviewed-by: Thiago Jung Bauermann + +2025-01-22 Jan Beulich + + x86/Solaris: correct support for Sun form of CMOV.S + PR gas/32579 + + The deprecated .s (swapped operand encoding) functionality got in the + way of properly recognizing this specific form. Move the Solaris- + specific code ahead of that. + +2025-01-22 Jan Beulich + + ld: replace another @progbits etc in an ELF testcase + The canonical form (in the testsuite) is %progbits and alike. + +2025-01-22 timhu2011 + + x86: Add missing @tab to separate columns in c-i386.texi + I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error. + + gas/ChangeLog: + + * doc/c-i386.texi: Add the missing @tab for .gmiccs and + .padlockphe2 + +2025-01-22 GDB Administrator + + Automatic date update in version.in + +2025-01-21 Tom de Vries + + [gdb/symtab] Fix gdb.base/fission-macro.exp with unix/-m32 + When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed + (using gcc 14) with target board unix/-m32, I get: + ... + (gdb) info macro FIRST^M + Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M + -DFIRST=1^M + (gdb) FAIL: $exp: \ + dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST + ... + instead of the expected: + ... + (gdb) info macro FIRST^M + Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M + (gdb) PASS: $exp: \ + dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST + ... + + A dwarf-5 .debug_str_offsets section starts with a header consisting of: + - an initial length (4 bytes for 32-bit and 12 bytes for 64-bit), + - a 2 byte version string, and + - 2 bytes padding + so in total 8 bytes for 32-bit and 16 bytes for 64-bit. + + This offset is calculated here in dwarf_decode_macros: + ... + str_offsets_base = cu->header.addr_size; + ... + which is wrong for both dwarf-5 cases (and also happens to be wrong for + dwarf-4). + + Fix this by computing str_offsets_base correctly for dwarf-5, for both the + 32-bit and 64-bit case. + + Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test + this with gcc-15, because gcc 14 and earlier don't have the fix for + PR debug/115066. + + Tested on x86_64-linux. + + Tested test-case using a current gcc trunk build, and gcc 14. + + Approved-By: Tom Tromey + + PR symtab/31897 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897 + +2025-01-21 Tom de Vries + + [gdb/testsuite] Use -g3 in gdb.base/lineinc.exp + The stated intention of test-case gdb.base/lineinc.exp is: + ... + # Test macro handling of #included files. + ... + + However, the test-case does not produce any macro debug information. + + Fix this by adding macros in the compilation flags. + + Tested on x86_64-linux. + +2025-01-21 Nick Clifton + + More updated translations + +2025-01-21 GDB Administrator + + Automatic date update in version.in + +2025-01-20 Alan Modra + + Support broken gcc test for gas string merge support + On casual reading of older gcc configure scripts it might be supposed + that the test for gas string merge support tries with %progbits after + a fail on ARM with @progbits. It doesn't succeed due to a bug. So to + support building of older gcc's for ARM without users having to edit + gcc sources, add a hack to gas. The hack can disappear in a few years + when building older gcc's likely requires other work too. + + I've changed the docs to reflect what we actually allow for .section + syntax prior to this patch. (No way should this hack be documented as + allowed!) + + PR 32491 + * config/obj-elf.c (obj_elf_section): Allow missing entsize + for ARM gcc configure bug. + * doc/as.texi: Correct syntax of ELF .section directive. + * testsuite/gas/elf/string.s, + * testsuite/gas/elf/string.d: Test it. + +2025-01-20 Alan Modra + + run_dump_test warning/error regexp + This allows you to specify a run_dump_test warning that may or may not + be present using + warning: (warning_text_goes_here)? + ie. the regexp matches an empty string. + +2025-01-20 Alan Modra + + asan ld builds without detect_leaks=0 + I found that building binutils with -fsanitize=address,undefined + results in much of the testsuite not being run. The problem is that + running gcc results in linker plugin memory leaks which of course are + errors, so the testsuite sees this as lack of compiler support. + + * testsuite/lib/ld-lib.exp (run_host_noleak): New proc. + (check_compiler_available, check_lto_available), + (check_lto_fat_available, check_lto_shared_available), + (check_ifunc_available, check_ifunc_attribute_available), + (check_libdl_available, check_gnu2_tls_available), + (compile_one_cc): Use run_host_noleak. + * testsuite/config/default.exp (compiler_supports): Likewise. + +2025-01-20 Maciej W. Rozycki + + LD: Remove duplicate 2.44 NEWS marker + Delete an extra 2.44 NEWS marker that has crept in by chance. + +2025-01-20 Nick Clifton + + Update translations for various sub-directories + + Update release readme for gold-in-branches change + +2025-01-20 Lulu Cai + + gas/NEWS,ld/NEWS: Announce LoongArch changes in 2.44 + +2025-01-20 Guinevere Larsen + + gdb/testsuite: Fix file location for gdb.base/backtrace-through-cu-nodebug + The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a + problem in the call to gdb_compile, that caused the .o files to be + outputted in the GDB file tree. This commit fixes the issues in the calls. + + Reported-By: Tom de Vries + Approved-By: Tom de Vries + +2025-01-20 Nick Clifton + + Update how-to-make-a-release document after creating the 2.44 branch + +2025-01-20 Richard Earnshaw + + gas: elf: Relax rules for SHF_STRING sections + Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections + declared with "S" (SHF_STRING) to specify the entity size, but then + would warn if the entity size was omitted, as with the old syntax. + + Unfortunately, since specifying the entity size is incompatible with + binutils 2.43 or earlier, this makes it impossible to specify a + strings section in source code without generating an assembly warning + (the new syntax isn't supported in older assemblers and the old syntax + generates warnings). + + Nevertheless, the old code was wrong in that it did not set the entity + size at all, in contravention of the ELF specification (though to date + there are no known cases where this mattered outside of mergeable + sections). + + Fix this by permitting the original syntax without a warning again, + but by defaulting the entity size to 1. This is compatible with the + most common case of strings being byte-based. + + Added some tests for the various flavours of declaration that we + support. + +2025-01-20 Alan Modra + + ldelf_before_allocation leak + ldelf_before_allocation is passed the audit and depaudit strings built + from command line args, then possibly adds to the depaudit string, + freeing the original. The new string isn't freed. Fix this leak by + keeping the string attached to the static vars. + + * ldelf.c (ldelf_before_allocation): Pass char** for audit + and depaudit. Adjust uses. + * ldelf.h (ldelf_before_allocation): Update prototype. + * gld${EMULATION_NAME}_before_allocation: Update call. + +2025-01-20 Alan Modra + + Re: elflink.c memory leaks + * elflink.c (elf_link_add_object_symbols): Free old_strtab + in another code path. Revert one unnecessary change in last + patch. + +2025-01-20 Alan Modra + + _bfd_elf_get_dynamic_symbols + This fixes an error path in _bfd_elf_get_dynamic_symbols, fixes the + minimum size required when reading DT_HASH header, and tidies + formatting in a few places. Nit-fixes all. + + Very likely we shouldn't be trying to mmap DT_DYNAMIC as it won't be + large enough for the mmap size threshold. + + * elf.c (_bfd_elf_get_dynamic_symbols): Use _bfd_munmap_temporary + in error return path rather than free. Corrent size passed to + offset_from_vma when reading DT_HASH header. Formatting. + +2025-01-20 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/non-trivial-retval.exp on arm-linux with gcc 13 + On arm-linux, with target board unix/-mthumb, we get: + ... + (gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here + p f1 (i1, i2)^M + $1 = {a = -136274256}^M + (gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command

+ ... + + This is not a problem with the inferior call, which works fine: + ... + (gdb) p f1 (23, 100) + $3 = {a = 123} + ... + but instead it's a problem with the location information: + ... + (gdb) p i1 + $1 = -136274356 + (gdb) p i2 + $2 = 100 + ... + which tells us to find the value of i1 in (DW_OP_fbreg: -12). + + The test-case passes if we drop -fvar-tracking, in which case the debug info + tells us to find the value of i1 in (DW_OP_fbreg: -20). + + This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing, + the code is the same, but -fvar-tracking does use the correct + '(DW_OP_fbreg: -20)'. + + There seems to be some bugfix in -fvar-tracking for gcc 14. + + Workaround the bug by using constants 23 and 100 instead of i1 and i2 when + using -fvar-tracking and gcc < 14. + + Tested on arm-linux. + + PR testsuite/32549 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549 + +2025-01-20 GDB Administrator + + Automatic date update in version.in + +2025-01-19 Alan Modra + + reloc caching + This arranges to free section relocs cached in elf_section_data. To + do that, some relocs stored there need to use bfd_malloc buffers + rather than bfd_alloc ones. + + * elf.c (_bfd_elf_free_cached_info): Free relocs. + * elf32-ppc.c (ppc_elf_relax_section): Realloc relocs rather + than malloc, copy, free old. + * elf64-ppc.c (get_relocs): bfd_malloc relocs. + * elflink.c (_bfd_elf_link_info_read_relocs): Always + bfd_malloc relocs. + +2025-01-19 Alan Modra + + sec->alloced and freeing section contents + This modifies _bfd_elf_free_cached_info to unmap/free section + contents. To do that we need to *not* free sections where contents + are bfd_alloc'd or point to constant strings or somesuch. I've chosen + to implement this be adding another flag to struct bfd_section, + "alloced" to say the section contents can't be freed. Most of the + patch is about setting that flag in many places. + +2025-01-19 Alan Modra + + _bfd_elf_munmap_section_contents + Do unmap/free cached contents to avoid some memory leaks we'd + otherwise see. + + * elf.c (_bfd_elf_munmap_section_contents): Clear pointers to + contents that we unmap/free rather than not unmapping/freeing. + +2025-01-19 Alan Modra + + Replace xmalloc with stat_alloc in ld parser + A few place dealing with ld script handling made some attempt to free + memory, but this was generally ignored and would be quite a lot of + work to implement. Instead, use the stat_obstack rather than + mallocing in many more cases. + + * ldexp.c (exp_get_fill): Use stat_alloc for fill. + * ldfile.c (ldfile_try_open_bfd): Don't free yylval fields. + * ldgram.y: Replace xmalloc with stat_alloc throughout. + * ldlang.c (stat_memdup, stat_strdup): New functions. + (ldirname): Use stat_memdup. Don't strdup ".". + (output_section_callback_sort): Use stat_alloc. + (output_section_callback_tree_to_list): Don't free. + (lang_memory_region_lookup): Use stat_strdup. + (lang_memory_region_alias): Likewise. + (add_excluded_libs): Use stat_alloc and stat_memdup. + (ldlang_add_undef, ldlang_add_require_defined): Use stat_strdup. + (lang_add_nocrossref, lang_leave_overlay): Use stat_alloc. + (realsymbol): Use stat_strdup for return value and always + free symbol. + (lang_new_vers_pattern, lang_new_vers_node): Use stat_alloc. + (lang_finalize_version_expr_head): Don't free. Delete FIXME. + (lang_register_vers_node): Don't free. + (lang_add_vers_depend): Use stat_alloc. + (lang_do_version_exports_section): Likewise. + (lang_add_unique): Use stat_alloc and stat_strdup. + (lang_append_dynamic_list): Use stat_alloc. + * ldlang.h (stat_memdup, stat_strdup): Declare. + * ldlex.l: Replace xstrdup with stat_strdup throughout. + Replace xmemdup with stat_memdup too. + * lexsup.c (parse_args): Don't free export list or dynamic + list. + +2025-01-19 Alan Modra + + Use stat_alloc in plugin + We never free the tv array. + + * plugin.c (plugin_load_plugins): Use stat_alloc. + +2025-01-19 Nick Clifton + + Change version to 2.44.50 and regenerate files + + Add name of 2.44 branch + + Add markers for bihnutils 2.44 branch + +2025-01-19 GDB Administrator + + Automatic date update in version.in + +2025-01-18 Alan Modra + + Re: binary outsymbols + The "of course to free outsymbols" turned out to be wrong. outsymbols + belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced + a double free. + + * srec.c (srec_write_symbols): Don't free outsymbols. + * tekhex.c (tekhex_write_object_contents): Likewise. + +2025-01-18 GDB Administrator + + Automatic date update in version.in + +2025-01-17 Tom Tromey + + Simplify get_frame_unwind_table + This simplifies get_frame_unwind_table, changing it to use the + registry 'emplace' method and to pass the initialization iterators to + the constructor. This fixes a build problem on x86 -- reported by the + auto-builder -- as a side effect. + + Tested-By: Guinevere Larsen + +2025-01-17 Guinevere Larsen + + gdb/reverse: Fix recording vmov[u|a]p[s|d] instructions + Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were + failing. In my machine xmm3 was consistently set to 0x54, but apparently + that is different depending on the system. This commit zeroes out xmm3 + at the start of the test instead. + + While debugging the test failures, I also noticed an issue where the + recording wasn't saving all the required memory. That happened because + vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to + share code paths, but the latter encodes memory modification size on + VEX.L whereas the former encodes in VEX.pp. So this commit fixed that, + and made the relevant tests more robust and complete. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561 + Approved-By: Guinevere Larsen + +2025-01-17 Tom Tromey + + Fix self-test crash + My earlier changes introduced a self-test crash. This patch fixes the + bug by introducing a new method overload into mock_mapped_index. + +2025-01-17 Andrew Burgess + + gdb/doc: some more details in the README file + After some recent discussions on the mailing list, I've made some + changes to the README to (I hope) provide more clarity. + + The changes I made are: + + 1. Removed the use of a lone 'HOST' on the configure line. I tried + this and 'configure' gave me a warning: + + configure: WARNING: you should use --build, --host, --target + + So I don't think this is approved practice any more. We should + encourage users to use `--host` instead. + + 2. Added and reworded the --host, --target, and --enable-targets + descriptions in the 'configure options' section. My goals here are + to clarify that 'cross-debugging' is really the same as 'remote + debugging', and also to make it clearer what the defaults are. + + 3. Added some additional text to the 'Remote debugging' section + mentioning that 'remote debugging' is basically the same as 'cross + debugging', given that we use 'cross-debugging' in the text above. + + Reviewed-By: Keith Seitz + +2025-01-17 Andrew Burgess + + gdb: quote inferior arguments, if needed, when opening a core file + This commit fixes an issue with the commit: + + commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a + Date: Thu Apr 25 09:36:43 2024 +0100 + + gdb: add gdbarch method to get execution context from core file + + The above commit improves GDB's ability to display inferior arguments + when opening a core file, however, if an argument includes white + space, then this is not displayed as well as it should be. For + example: + + (gdb) core-file /tmp/corefile-exec-context.2.core + [New LWP 4069711] + Reading symbols from /tmp/corefile-exec-context... + Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'. + Program terminated with signal SIGABRT, Aborted. + #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 + 50 return ret; + (gdb) show args + Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e". + (gdb) + + Notice the 'Core was generated by ...' line. In this case it is not + clear if the "e e e e e" is a single argument containing white space, + or 5 single arguments. + + But when we 'show args' it is immediately clear that this is a single + argument, as the white space is now escaped. + + This problem was caused by the above commit building the argument + string itself, and failing to consider white space escaping. + + This commit changes things around, first we place the arguments into + the inferior, then, to print the 'Core was generated by ...' line, we + ask the inferior for the argument string. In this way the quoting is + handled just as it is for 'show args'. The initial output is now: + + (gdb) core-file /tmp/corefile-exec-context.2.core + [New LWP 4069711] + Reading symbols from /tmp/corefile-exec-context... + Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'. + Program terminated with signal SIGABRT, Aborted. + #0 0x00007f4f007af625 in raise () from /lib64/libc.so.6 + (gdb) + + Much better. The existing test is extended to cover this case. + + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2025-01-17 Vladimir Mezentsev + + gprofng: update binutils/NEWS for 2.44 + ChangeLog + 2025-01-16 Vladimir Mezentsev + + * binutils/NEWS: Updated. + +2025-01-17 Vladimir Mezentsev + + gprofng: fix Segmentation Fault in DbeInstr::mapPCtoLine + The bug was filed against gprofng-gui (https://savannah.gnu.org/bugs/?66560). + + gprofng/ChangeLog + 2025-01-16 Vladimir Mezentsev + + * src/Hist_data.cc (DbeInstr::mapPCtoLine): Check for null pointer. + +2025-01-17 Andrew Carlotti + + aarch64: Fix sve2p1 gating and add missing instructions + Many FEAT_SVE2p1 instructions need to be enabled by either of two + different features (one for streaming mode, and one for non-streaming + mode). This patch adds correct gating conditions for these + instructions. + + There were also a few sve2p1 instructions missing altogether, so add + those as well. + + The testsuite is modified to check for all alternative enablement + conditions. In many cases this is done by adding an alternative + assembler commands to existing test files. For some SME/SME2 tests, + only some of the instructions are enabled by +sve2p1, so these are + copied into a separate test. For original SVE2p1 tests, the non-SME2p1 + instructions have been moved to a separate test file. + + There are also new tests for the newly added instructions. These + include a couple of fixme comments relating to bad error reporting, + which should be investigated later. + +2025-01-17 Tom Tromey + + Remove mapped_index_base + The base class mapped_index_base is no longer needed. Previously it + was used by both the .gdb_index and .debug_names readers, but the + latter now uses the cooked index instead. + + This patch removes mapped_index_base, merging it into + mapped_gdb_index. Supporting code that is specific to .gdb_index is + also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit, + which is nice. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504 + Approved-By: Andrew Burgess + +2025-01-17 Tom Tromey + + Remove gdb_index_unpack + gdb_index_unpack is not used and can be removed. The include of + extract-store-integer.h is also no longer needed by this file. + + Approved-By: Andrew Burgess + +2025-01-17 Tom Tromey + + Add missing includes of extract-store-integer.h + I found a number of .c files that need to include + extract-store-integer.h but that were only including it indirectly. + This patch adds the missing includes. This change enables the next + patch. + + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb/testsuite: Test for a backtrace through object without debuginfo + Fedora has been carrying this test since back in the Project Archer + days. A change back then caused GDB to stop being able to backtrace when + only some of the object files had debug information. Even though the + changed code never seems to have made its way into the main GDB project, + I think it makes sense to bring the test along to ensure something like + this doesn't pass unnoticed. + + Co-Authored-By: Jan Kratochvil + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: introduce ability to disable frame unwinders + Sometimes, in the GDB testsuite, we want to test the ability of specific + unwinders to handle some piece of code. Usually this is done by trying + to outsmart GDB, or by coercing the compiler to remove information that + GDB would rely on. Both approaches have problems as GDB gets smarter + with time, and that compilers might differ in version and behavior, or + simply introduce new useful information. This was requested back in 2003 + in PR backtrace/8434. + + To improve our ability to thoroughly test GDB, this patch introduces a + new maintenance command that allows a user to disable some unwinders, + based on either the name of the unwinder or on its class. With this + change, it will now be possible for GDB to not find any frame unwinders + for a given frame, which would previously cause GDB to assert. GDB will + now check if any frame unwinder has been disabled, and if some has, it + will just error out instead of asserting. + + Unwinders can be disabled or re-enabled in 3 different ways: + * Disabling/enabling all at once (using '-all'). + * By specifying an unwinder class to be disabled (option '-class'). + * By specifying the name of an unwinder (option '-name'). + + If you give no options to the command, GDB assumes the input is an + unwinder class. '-class' would make no difference if used, is just here + for completeness. + + This command is meant to be used once the inferior is already at the + desired location for the test. An example session would be: + + (gdb) start + Temporary breakpoint 1, main () at omp.c:17 + 17 func(); + (gdb) maint frame-unwinder disable ARCH + (gdb) bt + \#0 main () at omp.c:17 + (gdb) maint frame-unwinder enable ARCH + (gdb) cont + Continuing. + + This commit is a more generic version of commit 3c3bb0580be0, + and so, based on the final paragraph of the commit message: + gdb: Add switch to disable DWARF stack unwinders + <...> + If in the future we find ourselves adding more switches to disable + different unwinders, then we should probably move to a more generic + solution, and remove this patch. + this patch also reverts 3c3bb0580be0 + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434 + Co-Authored-By: Andrew Burgess + Reviewed-By: Eli Zaretskii + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + + temp adding completion + +2025-01-17 Guinevere Larsen + + gdb: Migrate frame unwinders to use C++ classes + Frame unwinders have historically been a structure populated with + callback pointers, so that architectures (or other specific unwinders) + could install their own way to handle the inferior. However, since + moving to C++, we could use polymorphism to get the same functionality + in a more readable way. Polymorphism also makes it simpler to add new + functionality to all frame unwinders, since all that's required is + adding it to the base class. + + As part of the changes to add support to disabling frame unwinders, + this commit makes the first baby step in using polymorphism for the + frame unwinders, by making frame_unwind a virtual class, and adds a + couple of new classes. The main class added is frame_unwind_legacy, + which works the same as the previous structs, using function pointers + as callbacks. This class was added to allow the transition to happen + piecemeal. New unwinders should instead follow the lead of the other + classes implemented. + + 2 of the others, frame_unwind_python and frame_unwind_trampoline, were added + because it seemed simpler at the moment to do that instead of reworking + the dynamic allocation to work with the legacy class, and can be used as + an example to future implementations. + + Finally, the cygwin unwinder was converted to a class since it was most + of the way there already. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Simon Marchi + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: add "unwinder class" to frame unwinders + A future patch will add a way to disable certain unwinders based on + different characteristics. This patch aims to make it more convenient + to disable related unwinders in bulk, such as architecture specific + ones, by identifying all unwinders by which part of the code adds it. + The classes, and explanations, are as follows: + + * GDB: An internal unwinder, added by GDB core, such as the unwinder + for dummy frames; + * EXTENSION: Unwinders added by extension languages; + * DEBUGINFO: Unwinders installed by the debug info reader; + * ARCH: Unwinders installed by the architecture specific code. + + Reviewed-By: Eli Zaretskii + Reviewed-by: Thiago Jung Bauermann + Approved-By: Simon Marchi + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: make gdbarch store a vector of frame unwinders + Before this commit, all frame unwinders would be stored in the obstack + of a gdbarch and accessed by using the registry system. This made for + unwieldy code, and unnecessarily complex logic in the frame_unwinder + implementation, along with making frame_unwind structs be unable to have + non-trivial destructors. + + Seeing as a future patch of this series wants to refactor the + frame_unwind struct to use inheritance, and we'd like to not restrict + the future derived classes on what destructors are allowed. In + preparation for that change, this commit changes the registry in gdbarch + to instead store an std::vector, which doesn't require using an obstack + and doesn't rely on a linked list. + + There should be no user-visible changes. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2025-01-17 MayShao-oc + + x86: Add CpuGMISM2 and CpuGMICCS + There are separate CPUID feature bits for SM2 and CCS instructions. + CCS is the acronym of Chinese Cipher System, it includes SM3 and SM4 + instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on + corresponding instructions. + + gas/ChangeLog: + + * config/tc-i386.c: Add gmism2 and gmiccs to replace gmi. + * doc/c-i386.texi: Ditto. + + opcodes/ChangeLog: + + * i386-gen.c: Add GMISM2 and GMICCS to replace GMI. + * i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to + replace CpuGMI. + * i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI + with GMICCS on sm3 and sm4 instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-17 Lulu Cai + + LoongArch: Allocate GOT entry for TLS DESC when -mno-relax is enabled + The type transition of TLSDESC is only done when -mrelax is enabled. + So when -mno-relax is enabled, keep GOT_TLS_GDESC to allocate the + GOT entry instead of just keeping GOT_TLS_IE. + +2025-01-17 Nick Clifton + + Sync config.guess and config.sub with latest versions from the config project. + +2025-01-17 Jan Beulich + + x86/APX: convert runtime special case to build-time one + cpu_flags_match() is a hot path. Move the special casing that + b7267244a355 ("Support Intel AMX-MOVRS") added there to i386-gen, thus + affecting only build time performance. + + x86: have .insn correctly consider AVX10.2's 256-bit embedded rounding + Deriving operand size may no longer assume 512-bit vector size when + embedded rounding is in use. In fact it was apparently wrong to do so + in the first place, as that's not correct for scalar insns. Drop the + rounding type check altogether; we fall back to EVEX.LIG when no + suitable operand was specified anyway, later in the function (and, btw, + similarly for VEX encodings). + +2025-01-17 Nelson Chu + + RISC-V: PR32499, Fix PR18841 segfault caused by ifunc relocation ordering + Even though the relocation isn't IRELATIVE, it still should be come last if + refering to ifunc symbol. In order to get the ifunc relocs properly sorted + the correct class needs to be returned. The code mimics what has been done + for x86, sparc, aarch64 and arm32. + + bfd/ + PR 18841 + PR 32499 + * elfnn-riscv.c (riscv_reloc_type_class): Handle ifunc relocation + ordering, even though it's not IRELATIVE, it still should be come + last if refering ifunc symbol. + +2025-01-17 Alan Modra + + cmdline_add_object_only_section leak + Free ofilename on error path. Don't bother testing "if (foo)" before + "free (foo)". + +2025-01-17 Alan Modra + + buffer overflow in cmdline_add_object_only_section + Seen running ld-plugin/lto-4r-c on x86_64-w64-mingw32 + + * ldlang.c (cmdline_add_object_only_section): Allocate one more + for output symbol buffer. + +2025-01-17 Alan Modra + + Silence asan warnings in resolve_symbol_value + The ".quad with division (fwdref)" gas test fails with asan warning + negation of -9223372036854775808 cannot be represented in type 'long int' + Fix this and another similar case. + + * symbols.c (resolve_symbol_value): Cast "left" to valueT + before negating. + +2025-01-17 H.J. Lu + + ld: Load the object only section when opening the mixed object file + Load the object only section when opening the mixed object file, instead + of loading it after all other input files have been loaded. This fixed + + .../ld/collect-ld: /tmp/ccZAoUIW.obj-only.o: in function `main': + .../ld/testsuite/ld-plugin/lto-10a.c:4: multiple definition of `main'; /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0x0): first defined here + .../ld/collect-ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0xc5): undefined reference to `WinMain' + collect2: error: ld returned 1 exit status + ... + FAIL: LTO 10 + + for x86_64-w64-mingw32 so that mixing LTO and non-LTO relocatable files + for "ld -r" works for both ELF and non-ELF platforms. + + * ld.texi: Remove "On ELF platforms" from documentation of mixing + LTO and non-LTO relocatable files for "ld -r". + * ldlang.c (cmdline_load_object_only_section): New. + (cmdline_check_object_only_section): Call it. + * testsuite/ld-plugin/lto.exp: Enable mixed LTO and non-LTO + relocatable output tests for all. + +2025-01-17 Alan Modra + + buffer overflow in score_elf_create_dynamic_relocation + score_elf_create_dynamic_relocation sets up three output dynamic + relocs from rel[0], rel[1] and rel[2]. When rel[0] is the last reloc + in a section this of course results in a buffer overflow. It's a + weird thing to do given that only one relocation is output. + + * elf32-score.c (score_elf_create_dynamic_relocation): Do not + set up three dynamic relocations when only one is output. + * elf32-score7.c: Likewise. + +2025-01-17 Alan Modra + + buffer overflow in mmix_elf_relocate_section + * elf64-mmix.c (mmix_elf_relocate_section): Correct size of + relocs shuffled by memmove. + +2025-01-17 Alan Modra + + xtensa unnecessary free + No path to "cleanup" label has internal_relocs malloc'd. + + * emultempl/xtensaelf.em (replace_insn_sec_with_prop_sec): Don't + free internal_relocs in cleanup. + +2025-01-17 Nelson Chu + + RISC-V: Added lost zcmt in gas imply testcase. + + gas/NEWS: Updated risc-v assembler support in 2.44. + +2025-01-17 Kito Cheng + + RISC-V: Use t2 for tail if Zicfilp enabled + This change is to make tail conform with software guarded jump of Zicfilp. The + reason to not choose t1 as the label register is that t1 is also as .got.plt + offset of _dl_runtime_resolve in PLT. + + See more: https://github.com/riscv-non-isa/riscv-asm-manual/pull/93 + +2025-01-17 Monk Chiang + + RISC-V: Support CFI Zicfiss and Zicfilp instructions and CSR. + https://github.com/riscv/riscv-cfi/releases/tag/v1.0 + + This patch only support the CFI instructions and CSR in assembler. + +2025-01-17 Nelson Chu + + RISC-V: Support ssctr/smctr extensions with version 1.0. + https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0 + + The privileged spec v1.10 already removed the sfence.vm instruction, and the + encoding of sfence.vm instruction is overlapped with the sctrclr instruction + of ssctr/smctr. But since the privileged spec v1.10 already removed the + sfence.vm, and we no longer support the privileged spec v1.9.1 for now, we + had to remove the sfence.vm. + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Imply zicsr for ssctr/smctr. + (riscv_supported_std_s_ext): Added ssctr/smctr with version 1.0. + (riscv_multi_subset_supports): Handle INSN_CLASS for ssctr/smctr. + (riscv_multi_subset_supports_ext): Likewise. + gas/ + * config/tc-riscv.c (enum riscv_csr_class, riscv_csr_address): + Added and handle CSR_CLASS_SSCTR and CSR_CLASS_SMCTR. + (riscv_is_priv_insn): Removed SFENCE_VM check. + * testsuite/gas/riscv/attribute-14e.d: Removed since sfence.vm is no + longer supported since privileged spec v1.10. + * testsuite/gas/riscv/attribute-14.s: Likewise. + * testsuite/gas/riscv/csr-version-1p10.d: Updated for ssctr/smctr CSRs. + * testsuite/gas/riscv/csr-version-1p10.l: Likewise. + * testsuite/gas/riscv/csr-version-1p11.d: Likewise. + * testsuite/gas/riscv/csr-version-1p11.l: Likewise. + * testsuite/gas/riscv/csr-version-1p12.d: Likewise. + * testsuite/gas/riscv/csr-version-1p12.l: Likewise. + * testsuite/gas/riscv/csr.s: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. + * testsuite/gas/riscv/march-help.l: Updated for ssctr/smctr. + * testsuite/gas/riscv/smctr-ssctr.d: New testcase for sctr instruction. + * testsuite/gas/riscv/smctr-ssctr.s: Likewise. + include/ + * opcode/riscv-opc.h: Added encoding macro for sctrclr, but removed + encoding macro for sfence.vm since encoding conflict. Added CSR + numbers for ssctr/smctr CSRs. + * opcode/riscv.h (enum riscv_insn_class): Added + INSN_CLASS_SMCTR_OR_SSCTR for sctrclr. + opcodes/ + * riscv-opc.c (riscv_opcodes): Added sctrclr, but removed sfence.vm + since encoding conflict. + +2025-01-17 Vladimir Mezentsev + + gprofng: don't check Elf when file is in archive + map.xml contains a checksum for all Elf files. + gprofng-archive archives a file only with the same checksum. + In gprofng-display-text no additional check is required. + + gprofng/ChangeLog + 2025-01-15 Vladimir Mezentsev + + * src/parse.cc: Don't check Elf when file is in archive. + +2025-01-17 Alan Modra + + Re: ld parser buffer leak + Apparently reflex doesn't have yyalloc. + + * ldlex.l (yy_create_string_buffer): Revert last change. + +2025-01-17 Haochen Jiang + + x86: Ignore rounding for vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd instead of reporting bad for disassembler + According to SDM, vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd treat + Rounding as Ignored when trying to using them. Thus, disassembler + should accept bytecode with rounding instead of reporting bad. + + For assembler, it needs some more time to decide how to deal + with that. + + gas/ChangeLog: + + * testsuite/gas/i386/evex.d: Add new testcase for vcvt[,u]dq2pd. + Change the output for vcvt[,u]si2sd. + * testsuite/gas/i386/evex.s: Ditto. + * testsuite/gas/i386/x86-64-evex.d: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-w.h: Add EXxEVexR64 for vcvt[,u]dq2pd. + * i386-dis.c (OP_Rounding): Mark EVEX_b as used to change the handle + for ignored rounding. + +2025-01-17 GDB Administrator + + Automatic date update in version.in + +2025-01-16 Alan Modra + + plugin_get_ir_dummy_bfd leak + * plugin.c (plugin_get_ir_dummy_bfd): Free bfd filename. + + ld parser buffer leak + * ldlex.l (<>): yy_delete_buffer current. + (yy_create_string_buffer): Use yyalloc. + +2025-01-16 Alan Modra + + write_build_id and write_package_metadata leaks + There isn't much sense in stashing contents in sec->contents + after those contents have been written. + + * ldelf.c (write_build_id): Don't assign sec->contents. + Free contents if malloc'd here. + (write_package_metadata): Likewise. + +2025-01-16 Alan Modra + + ldelf_search_needed leak + * ldelf.c (ldelf_search_needed): Free filename before returning. + + free ldfile search paths + * ldfile.c (ldfile_remap_input_free): Make static, call from.. + (ldfile_free): ..here. New function. + (ldfile_library_path_free, ldfile_script_free), + ( ldfile_arch_free): New functions. + (ldfile_find_command_file): Free script_dir. Move + script_search to file scope. + (ldfile_open_command_file_1): Delete FIXME comment. + * ldfile.h (ldfile_remap_input_free): Delete. + (ldfile_free): Declare. + * ldlang.c (lang_finish): Update. + +2025-01-16 Alan Modra + + output_section_statement leak + This frees output_section_statement data, which is currently only used + by elf targets but doing so for all targets is simpler and more + future proof than adding ths to ldelf_finish. (Doing it there + requires moving the function to ldelfgen.c.) + + * ldemul.c (finish_default): Free os->data. + +2025-01-16 H.J. Lu + + NEWS: Mention mixed LTO and non-LTO output support for ld -r + +2025-01-16 Nick Clifton + + Copy gcc commit e76df3586417d645dd84e8a1ab165605a8924796 to sourceware + + Have readelf sanitize the program interpreter string before displaying it. + +2025-01-16 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/implptr.exp regression + When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we + get: + ... + (gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar + break implptr.c:34^M + No compiled code for line 34 in file "implptr.c".^M + Make breakpoint pending on future shared library load? (y or [n]) n^M + (gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt) + ... + + This is a regression since commit dcaa85e58c4 ("gdb: reject inserting + breakpoints between functions"). + + The .debug_line info does not contain an entry with a line number lower than + 36, so gdb cannot map it to an address. + + Fix this by setting a breakpoint at the function containing line 34 instead. + + Tested on x86_64-linux. + + PR testsuite/32477 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477 + +2025-01-16 MayShao-oc + + x86: Support x86 Zhaoxin PadLock PHE2 instructions + The CPUID EDX bit[26] indicates its enablement, and it includes REP + XSHA384 and REP XSHA512. + + gas/ChangeLog: + + * NEWS: Support Zhaoxin PadLock PHE2 instructions. + * config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to + PadLockPHE2 instructions. + (output_insn): Handle PadLockPHE2 instructions. + * doc/c-i386.texi: Document PadLockPHE2. + * testsuite/gas/i386/i386.exp: Add PadLockPHE2 test. + * testsuite/gas/i386/padlock_phe2.d: Ditto. + * testsuite/gas/i386/padlock_phe2.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add PadLockPHE2. + * i386-gen.c: Ditto + * i386-opc.h (CpuPadLockPHE2): New. + * i386-opc.tbl: Add Zhaoxin PadLock PHE2 instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-16 Alan Modra + + disassemble_free_powerpc + This fixes leaks in a ppc disassembler buffer. I'm not sure now why I + used a private buffer for section contents, but I'm not going to + change that just now. + + * disassemble.h (disassemble_free_powerpc): Declare. + * disassemble.c (disassemble_free_target): Call it. + * ppc-dis.c (disassemble_free_powerpc): New function. + +2025-01-16 Alan Modra + + ppc plt sym memory leak + * elf32-ppc.c (add_stub_sym): Alloc the sym name. + + gas ppc .machine leak + * config/tc-ppc.c (ppc_machine): Free cpu_string. + +2025-01-16 Alan Modra + + elf64-ppc.c memory leaks + I've freed htab->relr in two places, first when we're done with it + in ppc64_elf_build_stubs, and also when freeing the hasn table to + catch cases where the linker exits early due to errors. + + * elf64-ppc.c (ppc64_elf_link_hash_table_free): Free htab->relr. + (ppc64_elf_build_stubs): Also free it here. + (ppc_add_stub): Copy stub_name when creating.. + (ppc64_elf_size_stubs): ..and always free stub_name. + (opd_entry_value): Free sym. + (ppc_build_one_stub): bfd_alloc stub sym name. + (build_global_entry_stubs_and_plt): Likewise. + (ppc64_elf_setup_section_lists): bfd_zalloc htab->sec_info. + +2025-01-16 Alan Modra + + gas HANDLE_ALIGN and frag_alloc + This adds the section to HANDLE_ALIGN args, so that the frag created + by the ppc backend can be properly allocated on the frag obstack. + I've added an extra param to frag_alloc too, for cases where we know + the frag requires at least some bytes in fr_literal. This simplifies + some existing code, for example in compress_debug and relax_segment. + In the case of the relax_segment code, I think we may have had a bug + there in using obstack_blank_fast, which doesn't check that the frag + has room. + + * config/tc-ppc.c (ppc_handle_align): Add section param, + use frag obstack to allocate frag. + * config/tc-ppc.h (HANDLE_ALIGN, ppc_handle_align): Add extra + param. + * config/tc-aarch64.h (HANDLE_ALIGN): Add extra param. + * config/tc-alpha.h: Likewise. + * config/tc-arc.h: Likewise. + * config/tc-arm.h: Likewise. + * config/tc-avr.h: Likewise. + * config/tc-epiphany.h: Likewise. + * config/tc-frv.h: Likewise. + * config/tc-i386.h: Likewise. + * config/tc-ia64.h: Likewise. + * config/tc-kvx.h: Likewise. + * config/tc-loongarch.h: Likewise. + * config/tc-m32c.h: Likewise. + * config/tc-m32r.h: Likewise. + * config/tc-metag.h: Likewise. + * config/tc-mips.h: Likewise. + * config/tc-mn10300.h: Likewise. + * config/tc-nds32.h: Likewise. + * config/tc-riscv.h: Likewise. + * config/tc-rl78.h: Likewise. + * config/tc-rx.h: Likewise. + * config/tc-sh.h: Likewise. + * config/tc-sparc.h: Likewise. + * config/tc-spu.h: Likewise. + * config/tc-tilegx.h: Likewise. + * config/tc-tilepro.h: Likewise. + * config/tc-v850.h: Likewise. + * config/tc-visium.h: Likewise. + * config/tc-wasm32.h: Likewise. + * config/tc-xtensa.h: Likewise. + * frags.h (frag_alloc): Update prototype. + * frags.c (frag_alloc): Add extra size param, allocate extra. + (frag_new): Update. + * subsegs.c (subseg_set_rest): Update frag_alloc call. + * write.c: Formatting. + (cvt_frag_to_fill): Pass sec to HANDLE_ALIGN. + (compress_frag): Update frag_alloc call. + (compress_debug): Use new frag_alloc to simplify frag sizing. + (relax_segment): Likewise. + +2025-01-16 Alan Modra + + binary outsymbols + This fixes leaks of outsymbols for various targets that use the + generic linker. The key fix here is to not generate output symbols + for targets that won't ever write symbols, and of course to free + outsymbols after they've been written in targets that do. Target + vector object_flags and section_flags are updated to better reflect + target capabilities, in particular not setting HAS_SYMS or SEC_RELOC + when the target does not support symbols or relocs. + + * binary.c (binary_vec): Update section_flags. + * linker.c (generic_add_output_symbol): Don't add to + outsymbols if !HAS_SYMS. + * srec.c (srec_write_symbols): Free outsymbols on return. + (srec_vec): Update object_flags and section_flags. + (symbolsrec_vec): Likewise. + * tekhex.c (tekhex_write_object_contents): Free outsymbols on + return. + (tekhex_vec): Update object_flags and section_flags. + * verilog.c (verilog_vec): Likewise. + +2025-01-16 Alan Modra + + tidy binary, ihex and verilog + * binary.c (binary_sizeof_headers): Delete function. Define + instead. + * ihex.c (ihex_sizeof_headers): Likewise. + (ihex_vec): Use _bfd_nosymbols for BFD_JUMP_TABLE_SYMBOLS. Delete + now unused defines. + * verilog.c: Delete unused defines. + +2025-01-16 Alan Modra + + genlink tidy + Some of the declarations in genlink.h are not used in current sources + apart from needing them in linker.c, so delete and/or move them there. + The patch also fixes a FIXME. It's actually quite easy to return + a failure from a hash traversal function. + + * genlink.h (_bfd_generic_link_hash_newfunc): Delete. + (_bfd_generic_link_output_symbols), + (generic_write_global_symbol_info), + (_bfd_generic_link_write_global_symbol): Move to.. + * linker.c: ..here, making functions static. + (generic_write_global_symbol_info): Add "failed". + (_bfd_generic_final_link): Handle wginfo.failed. + (_bfd_generic_link_write_global_symbol): Set wginfo->failed + on memory failures and return false rather than aborting. + +2025-01-16 Tom de Vries + + [gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.exp + Once in a while, I run into a timeout in test-case + gdb.threads/step-over-thread-exit.exp: + ... + (gdb) continue^M + Continuing.^M + [New Thread 0xfffff7cff1a0 (LWP 2874854)]^M + ^M + Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \ + my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M + 74 SYSCALL (my_exit, __NR_exit)^M + (gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M + FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \ + schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout) + ... + + I can reproduce it more frequently by running with taskset -c . + + Fix this by using -no-prompt-anchor. + + This requires us to add -no-prompt-anchor to proc gdb_test_multiple. + + Tested on aarch64-linux. + + PR testsuite/32489 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489 + +2025-01-16 Tom de Vries + + [gdb/python] Run black on gdb/gdbarch_components.py + The sourceware buildbot reported "python black formatter ( failure )" at + commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook"). + + Fix this by running the precommit hooks in a container with Python 3.11 using: + ... + $ pre-commit run --files gdb*/* + ... + +2025-01-16 Sergio Durigan Junior + + gdbserver: Fix build on MIPS + Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke + the build on MIPS because it's passing a non-existent "pid" argument + to "proc->for_each_thread". This commit fixes the problem by removing + the argument from the call. + +2025-01-16 GDB Administrator + + Automatic date update in version.in + +2025-01-15 Alan Modra + + x86 relr memory leaks + This fixes some x86 memory leaks. I think it would be possible to + free the relr data in _bfd_elf_x86_finish_relative_relocs if we + wanted to reclaim some memory earlier, but for tidying after errors we + likely would need to free in the hash_table_free function anyway. + + _bfd_x86_elf_link_relax_section is called via bfd_relax_section, + ie. whenever relaxation is enabled. This is a waste of time if + dt_relr relocs are not enabled since the function is there only to + handle relr. + + * elfxx-x86.c (elf_x86_link_hash_table_free): Free relr data. + (_bfd_x86_elf_link_relax_section): Return early + if !info->enable_dt_relr. Do set "again" false before early + returns. + +2025-01-15 Alan Modra + + Tidy elf_mmap_section_contents + It is simpler to clear the buffer pointer in the caller than pass + a param that controls clearing. + + * elf.c (elf_mmap_section_contents): Remove final_link param. + (_bfd_elf_mmap_section_contents): Instead set *buf to NULL here. + (_bfd_elf_link_mmap_section_contents): Adjust. + +2025-01-15 Alan Modra + + elf_x86_64_scan_relocs error paths + Fix some memory leaks. + + * elf64-x86-64.c (elf_x86_64_scan_relocs): Ensure error return + paths that should free relocs go via error_return. + +2025-01-15 Martin Storsjö + + Add support for IMPORT_CONST in ILF (MSVC style) import libraries + This is a very strange and obsolete kind of import type; it is + used for imported data just like IMPORT_DATA - but with an extra + odd caveat. + + The behaviour is explained at [1]; generating such import libraries + with current MSVC tools produces "warning LNK4087: CONSTANT keyword is + obsolete; use DATA". + + While obsolete, some import libraries within the Microsoft WDK (Windows + Driver Kit) do contain such symbols, which currently are ignored by + binutils and produce warnings about "file format not recognized". + + For IMPORT_CONST for a DLL exported symbol "foo", we should provide + the import library symbols "__imp_foo" and "foo". For IMPORT_DATA, we + only provide "__imp_foo", and for IMPORT_CODE, "foo" points at a thunk. + The odd/surprising thing for IMPORT_CONST is that the "foo" symbol also + points at the same thing as "__imp_foo", i.e. directly at the IAT + entry. + + [1] https://learn.microsoft.com/en-us/cpp/build/importing-using-def-files + +2025-01-15 Matthieu Longo + + aarch64: GCS tests for linking issues with dynamic objects + +2025-01-15 Matthieu Longo + + aarch64: check GCS feature in GNU properties of input dynamic objects + The Guarded Control Stack (GCS) feature requires that two things: + - at static link time, all the input objects of a link unit have to + be compatible with GCS. + - at runtime, the executable and the shared libraries which it + depends on have to be compatible with GCS. + Both of those criteria are checked with the GCS feature stored in + the GNU property note. + + The previous patch, adding support for the GCS feature check in GNU + note properties for input objects, ignored the input dynamic objects. + Although this support was better than no check, it was still + delaying the detection of compatibility issues up to the runtime + linker. + + In order to help the developer in detecting such an incompatibility + issue as early as possible, this patch adds a check for input dynamic + objects lacking the GCS marking. This check can be controlled via the + linker option '-z gcs-report-dynamic[=none|warning|error]'. By default, + if the option is omitted, it inherits the value from '-z gcs-report'. + However, the inherited value is capped to 'warning' as a user might + want to only report errors in the currently built module, and not the + shared dependencies. If a user also wants to error on GCS issues in + the shared libraries, '-z gcs-report-dynamic=error' will have to be + specified explicitly. + +2025-01-15 Tankut Baris Aktemur + + gdb: boolify the 'in_g_packet' field of remote's 'packet_reg' + Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in + remote.c. + +2025-01-15 Tankut Baris Aktemur + + gdbserver: remove an obsolete comment in tracepoint.cc + The comment + + /* Functions local to this file. */ + + has somehow been positioned above struct definitions, not functions. + Some static function declarations are given after the structs, to + where the comment could be moved, but the comment is not really + helpful. Therefore remove it. + +2025-01-15 Tankut Baris Aktemur + + gdbserver: remove forward declaration of struct tracepoint_hit_ctx + Remove the unnecessary forward declaration for `struct tracepoint_hit_ctx`. + +2025-01-15 Tom de Vries + + [gdb/tdep] Fix gdb.base/store.exp on s390x + On s390x-linux, I get: + ... + (gdb) print l^M + $29 = 0^M + (gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1 + ... + + So, we're in wack_doublest trying to print l, which is a copy of parameter u: + ... + register doublest l = u, r = v; + ... + which does have the expected value: + ... + (gdb) p u + $1 = -1 + ... + which is a long double, 16 bytes and looks like this: + ... + (gdb) p /x u + $3 = 0xbfff0000000000000000000000000000 + ... + + Parameter u is passed in two registers: + ... + <2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter) + <6a6> DW_AT_name : v + <69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \ + (DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8) + ... + and indeed we find the msw in r0 and the lsw in r1: + ... + (gdb) p /x $r0 + $4 = 0xbfff000000000000 + (gdb) p /x $r1 + $5 = 0x0 + (gdb) + ... + + Likewise, variable l consists of two registers: + ... + <2><6b5>: Abbrev Number: 13 (DW_TAG_variable) + <6b6> DW_AT_name : l + <6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \ + (DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8) + ... + and we find the same values there: + ... + (gdb) p /x $f8 + $6 = 0xbfff000000000000 + (gdb) p /x $f10 + $7 = 0x0 + ... + + So, we get the expected results when fetching the value from two gprs, but not + when fetching the value from two fprs. + + When fetching the values from the two fprs, we stumble upon a particularity of + the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24 + maps to both floating-point register f8 (8 bytes), and vector register v8 + (16 bytes). + + In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and + if available vector registers are preferred over floating-point registers, so + v8 is chosen, and used to fetch the value. + + Since the size of the DW_OP_piece is 8 bytes, and the register size is 16 + bytes, this bit in rw_pieced_value is activated: + ... + /* If the piece is located in a register, but does not + occupy the entire register, the placement of the piece + within that register is defined by the ABI. */ + bits_to_skip + += 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum, + p->size / 8); + ... + but since the default implemention default_dwarf2_reg_piece_offset does not + match the s390x ABI, we get the wrong answer. + + This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other + DWARF Location Woes" [2]. + + Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same + logic as in s390_value_from_register. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + + [1] https://github.com/IBM/s390x-abi + [2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces + +2025-01-15 Tom de Vries + + [gdb] Add gdbarch_dwarf2_reg_piece_offset hook + In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and + DW_OP_bit_piece are handled the same, but the standard tells us: + - DW_OP_piece: if the piece is located in a register, but does not occupy the + entire register, the placement of the piece within that register is defined + by the ABI. + - DW_OP_bit_piece: if the location is a register, the offset is from the least + significant bit end of the register. + + Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the + ABI-specific behaviour for DW_OP_piece. + + The default implementation of the hook is the behaviour of DW_OP_bit_piece, so + there should not be any functional changes. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2025-01-15 Tom de Vries + + [gdb/symtab] Add dwarf_expr_piece.op + Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of + which dwarf_location_atom caused a dwarf_expr_piece to be added. + + This is used in the following patch. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2025-01-15 Tom Tromey + + Fix help formatting for string and filename options + I happened to notice that "help add-inferior" said: + + -execFILENAME + FILENAME is the file name of the executable to use as the + main program. + + This is missing a space after "-exec". This patch fixes the bug. + + If ok'd on time I plan to check this in to the gdb-16 branch as well. + + Approved-by: Kevin Buettner + +2025-01-15 Hui Li + + gdbserver: LoongArch: Add hardware watchpoint/breakpoint support + LoongArch defines hardware watchpoint functions for fetch and load/store + operations, the related support for gdb was added in the following two + + commit c1cdee0e2c17 ("gdb: LoongArch: Add support for hardware watchpoint") + commit 6ced1278fc00 ("gdb: LoongArch: Add support for hardware breakpoint") + + Now, add hardware watchpoint and breakpoint support for gdbserver on + LoongArch. + + Here is a simple example + + $ cat test.c + #include + int a = 0; + int b = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + a = 2; + printf("a = %d\n", a); + b = 2; + printf("b = %d\n", b); + return 0; + } + $ gcc -g test.c -o test + + Execute on the target machine: + + $ gdbserver 192.168.1.100:1234 ./test + + Execute on the host machine: + + $ gdb ./test + ... + (gdb) target remote 192.168.1.100:1234 + ... + (gdb) b main + Breakpoint 1 at 0x1200006b8: file test.c, line 6. + (gdb) c + Continuing. + ... + Breakpoint 1, main () at test.c:6 + 6 printf("start test\n"); + (gdb) watch a + Hardware watchpoint 2: a + (gdb) hbreak 11 + Hardware assisted breakpoint 3 at 0x120000700: file test.c, line 11. + (gdb) c + Continuing. + + Hardware watchpoint 2: a + + Old value = 0 + New value = 1 + main () at test.c:8 + 8 printf("a = %d\n", a); + (gdb) c + Continuing. + + Hardware watchpoint 2: a + + Old value = 1 + New value = 2 + main () at test.c:10 + 10 printf("a = %d\n", a); + (gdb) c + Continuing. + + Breakpoint 3, main () at test.c:11 + 11 b = 2; + (gdb) c + Continuing. + [Inferior 1 (process 696656) exited normally] + + Output on the target machine: + + Process ./test created; pid = 696708 + Listening on port 1234 + Remote debugging from host 192.168.1.200, port 60742 + start test + a = 1 + a = 2 + b = 2 + + Child exited with status 0 + +2025-01-15 Hui Li + + gdb: LoongArch: Adjust loongarch_stopped_data_address() + loongarch_stopped_data_address() is a common function and will be used by + gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c + to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver + patch on LoongArch and is no effect for the current code. + + gdb: LoongArch: Adjust loongarch_{get,remove}_debug_reg_state() + loongarch_{get,remove}_debug_reg_state() are used as helper functions + by loongarch_linux_nat_target. We should move their definitions from + gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c. + + gdb: LoongArch: Remove loongarch_lookup_debug_reg_state() + loongarch_lookup_debug_reg_state() is a unused function, so we + can remove it. + +2025-01-15 H.J. Lu + + ld: Update gld${EMULATION_NAME}_place_orphan for PE/PEP + Similar to ldelf_place_orphan, initialize hold from orig_hold at run-time + in PE and PEP gld${EMULATION_NAME}_place_orphan. + + * emultempl/pe.em (orphan_init_done): Make it file scope. + (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for + the object-only output. + (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. + Initialize hold from orig_hold at run-time. + * emultempl/pep.em (orphan_init_done): Make it file scope. + (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for + the object-only output. + (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. + Initialize hold from orig_hold at run-time. + +2025-01-15 H.J. Lu + + ld: Correct ldelf_place_orphan + Remove the extra for loop and if statement in ldelf_place_orphan. + + * ldelf.c (ldelf_place_orphan): Remove the extra for loop and if + statement. + +2025-01-15 Jan Vrany + + gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require also avx2 + The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX + instructions but it actually also uses AVX2 instructions (like + vpcmpeqd). This caused the test to fail on CPUs that have AVX but not + AVX2. + + This commit adds check for AVX2. + + Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U + (has AVX2). + +2025-01-15 Alan Modra + + bfd_get_unique_section_name leak + The name returned by this function is used in asection->name, so + needs to persist until a bfd is closed. + + * section.c (bfd_get_unique_section_name): Return an alloc'd + string. + +2025-01-15 Alan Modra + + Free symtab_hdr.contents and a cache_size correction + symtab_hdr.contents looks to be malloc'd memory, except in one case. + Change that one case to also be malloc'd and free when we are done. + + * elf.c (swap_out_syms): bfd_malloc outbound_syms. + (_bfd_elf_free_cached_info): Free symtab_hdr.contents. + * elflink.c (init_reloc_cookie): Correct cache_size. locsyms + is an array of Elf_Internal_Sym. + +2025-01-15 Alan Modra + + elflink.c memory leaks + Many targets leaked parts of the elf_link_hash_table. Fix that by + making _bfd_elf_link_hash_table_init set up hash_table_free correctly, + so that targets that extend elf_link_hash_table without adding + anything that needs freeing, will use _bfd_elf_link_hash_table_free. + + * elflink.c (elf_link_add_object_symbols): Always free + nondeflt_vers. Don't return false without freeing. + (_bfd_elf_link_hash_table_init): Set hash_table_free here.. + (_bfd_elf_link_hash_table_create): ..rather than here. + (elf_link_swap_symbols_out): Don't free strtab here.. + (elf_link_add_object_symbols): ..do so here instead. Don't + omit freeing on some error return paths. + +2025-01-15 Alan Modra + + sframe memory leak + This is another case where an array isn't freed anywhere and needs to + persist a while, so allocate it with bfd_alloc. + + * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Add abfd + param. bfd_zalloc std_func_bfdinfo. + (_bfd_elf_parse_sframe): Adjust to suit. + +2025-01-15 Alan Modra + + eh-frame memory leaks + The set_loc array attached to eh-frame sec_info isn't freed, and is + used in _bfd_elf_eh_frame_section_offset. Rather than finding a + suitable late stage of linking past any b_e_e_f_s_o use, I decided + this might as well persist until the bfd is closed. + Some memory is freed in _bfd_elf_discard_section_eh_frame_hdr, but + the function isn't always called, so fix that too. + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc the + set_loc array. + (find_merged_cie): Use bfd_malloc rather than malloc. + (_bfd_elf_discard_section_eh_frame_hdr): Move condition under + which this function does anything except free memory from.. + * elflink.c (bfd_elf_discard_info): ..here. + +2025-01-15 Alan Modra + + Fix known minor objdump leak + * objdump.c (main): Free disassembler_options. + +2025-01-15 Andrew Burgess + + gdbserver: convert program_args to a single string + This commit changes how gdbserver stores the inferior arguments from + being a vector of separate arguments into a single string with all of + the arguments combined together. + + Making this change might feel a little strange; intuitively it feels + like we would be better off storing the arguments as a vector, but + this change is part of a larger series of work that aims to improve + GDB's inferior argument handling. The full series was posted here: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + But asking people to review a 14 patch series in unreasonable, so I'm + instead posting the patches in smaller batches. This patch can stand + alone, and I do think this change makes sense on its own: + + First, GDB already stores the inferior arguments as a single string, + so doing this moves gdbserver into line with GDB. The common code + into which gdbserver calls requires the arguments to be a single + string, so currently each target's create_inferior implementation + merged the arguments anyway, so all this commit really does is move + the merging up the call stack, and store the merged result rather than + storing the separate parts. + + However, the biggest reason for why this commit is needed, is an issue + with passing arguments from GDB to gdbserver when starting a new + inferior. + + Consider: + + (gdb) set args $VAR + (gdb) run + ... + + When using a native target the inferior will see the value of $VAR + expanded by the shell GDB uses to start the inferior. However, if + using an extended-remote target the inferior will see literally $VAR, + the unexpanded name of the variable, the reason for this is that, + although GDB sends '$VAR' to gdbserver, when gdbserver receives this, + it converts this to '\$VAR', which prevents the variable from being + expanded by the shell. + + The reason for this is that construct_inferior_arguments escapes all + special shell characters within its arguments, and it is + construct_inferior_arguments that is used to combine the separate + arguments into a single string. + + In the future I will change construct_inferior_arguments so that + it can apply different escaping strategies. When this happens we will + want to escape arguments coming from the gdbserver command line + differently than arguments coming from GDB (via a vRun packet), which + means we need to call construct_inferior_arguments earlier, at the + point where we know if the arguments came from the gdbserver command + line, or from the vRun packet. + + This argument escaping issue is discussed in PR gdb/28392. + + This commit doesn't fix any issues, nor does it change + construct_inferior_arguments to actually do different escaping, that + will all come later. This is purely a restructuring. + + There should be no user visible changes after this commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + Approved-By: Simon Marchi + +2025-01-15 Alan Modra + + PR32560 stack-buffer-overflow at objdump disassemble_bytes + There's always someone pushing the boundaries. + + PR 32560 + * objdump.c (MAX_INSN_WIDTH): Define. + (insn_width): Make it an unsigned long. + (disassemble_bytes): Use MAX_INSN_WIDTH to size buffer. + (main ): Restrict size of insn_width. + +2025-01-15 Tom de Vries + + [gdb/symtab] Require current language before symbol lookups + Test-case gdb.python/py-symbol.exp fails with various target boards, including + fission and gold-gdb-index. + + The problem here is that, in this test, the current language is still + unset (i.e., lazy) when the symbol lookup is done. It is eventually + set deep in the lookup -- but this then requires a reentrant symbol + lookup, which fails. (DWARF symbol lookup is not reentrant.) + + Fix this by: + - detecting symbol lookup reentrance using an assert, and + - requiring the current language to be set when entering symbol lookup. + + Tested on x86_64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR symtab/32490 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490 + +2025-01-15 Alan Modra + + Re: elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property + Don't run tests on targets without required support. Supply an + explicit -z nomemory-seal rather then relying on the harness default, + to lessen confusion for people looking at the test. Don't use numeric + labels for the sake of hppa64*-hpux, and run the tests there. Remove + incorrect comment about source editing. Also, xfail rather than + notarget failing tests with a list of target triples so we check that + the list is correct. + + Re: ld: Add --enable-memory-seal configure option + Commit 80dc29527ff9 accidentally removed an assignment to board_flags, + resulting in tcl errors 'can't read "board_flags": no such variable' + on sh4-linux-gnu. Fix that by calling [get_board_flags] in the + condition rather than reinstating the removed line since it seems most + configurations don't have a null STATIC_LDFLAGS. Do the same in + another similar test too. + +2025-01-15 GDB Administrator + + Automatic date update in version.in + +2025-01-14 Tom Tromey + + Use bool in decode_line_2_item + This changes decode_line_2_item::selected to bool. There was no + benefit to keeping this as a bitfield, so I removed that. Note that + the constructor already uses bool here. + + Approved-By: Simon Marchi + +2025-01-14 Tom Tromey + + Use bool for parameter of add_sal_to_sals + This changes add_sal_to_sals to use 'bool' rather than 'int'. + + Approved-By: Simon Marchi + +2025-01-14 Tom Tromey + + Use filename style in "show" commands + I found a few filename-related "show" commands that do not use the + filename style when displaying the file. This patch fixes the + oversight. + + Approved-By: Andrew Burgess + +2025-01-14 H.J. Lu + + ld: Parse linker script only once + Parsing linker script twice caused + + FAIL: ld-plugin/lto-3r + FAIL: ld-plugin/lto-5r + FAIL: PR ld/19317 (2) + + for x86_64-w64-mingw32 with the linker error: + + ./ld-new:built in linker script:27 assignment to location counter invalid outside of SECTIONS + + ldscripts/i386pep.xr has + + 24 .rdata : + 25 { + 26 *(.rdata) + 27 . = ALIGN(4); + 28 /* .ctors & .dtors */ + 29 /* .CRT */ + 30 /* ___crt_xl_end__ is defined in the TLS Directory support code */ + 31 } + + Remove ld_parse_linker_script to parse linker script only once. + + * ldlang.c (cmdline_emit_object_only_section): Don't call + ld_parse_linker_script. + * ldmain.c (main): Fold ld_parse_linker_script. + (ld_parse_linker_script): Removed. + +2025-01-14 H.J. Lu + + ld: Call cmdline_check_object_only_section only if plugin is enabled + * ldmain.c (add_archive_element): Call + cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS + is defined. + +2025-01-14 Yang Liu + + gdb/jit: fix jit-reader linetable integrity + The custom linetable functionality in GDB's JIT Interface has been broken + since commit 1acc9dca423f78e44553928f0de839b618c13766. + + In that commit, linetables were made independent from the objfile, which + requires objfile->section_offsets to be initialized. However, section_offsets + were never initialized in objfiles generated by GDB's JIT Interface + with custom jit-readers, leading to GDB crashes when stepping into JITed code + blocks with the following command already executed: + + jit-reader-load libmygdbjitreader.so + + This patch fixes the issue by initializing the minimum section_offsets required + for linetable parsing procedures. + + A minimal test is included. The test sets up some very simple line + table information, which is enough to trigger the bug. However, the + line table information is crafted such that none of the line table + entries will end up being displayed in GDB's output when the test is + run, as such, none of the expected output actually changes. + + It might be nice in the future to extend some of the jit tests to + actually test hitting line table entries added via the jit reader. + + Approved-By: Tom Tromey + +2025-01-14 Guinevere Larsen + + gdb/record: add support for AVX floating point arithmetic instructions + This commit adds support for the following types of instructions + relating to floating poitn values: add, mul, sub, min, div, max. + These are supported with packed or single values, and single or double + precision. + + Some of the instructions had opcode clashes, however, considering the + mechanics of recording the registers is the same on both instructions, + this is just marked with a comment. + + Approved-By: Guinevere Larsen + +2025-01-14 Guinevere Larsen + + gdb/record: add support for floating point vunpck instructions + This commit adds support for the AVX instructions vunpck[l|h][ps|pd] + instructions, which was pretty straightforward. + + This commit also fixes a mistake in the test, where "record stop" was + used after the recording was already stopped, if it failed during + vpunpck_test recording. It also improved the documentation at the start + of the relevant .c function. + + Approved-By: Guinevere Larsen + +2025-01-14 Guinevere Larsen + + gdb/record: add support for floating point vmov instructions + This commit updates GDB's record-full to be able to record vmov[ss|sd] + and vmov [u|a] [ps|pd] AVX instructions, and tests for them. + + Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions + of vmov?[ps|pd] have different opcodes. The mechanics of recording them + is the same, but the aligned version has opcodes 0x28 and 0x29, while + the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and + 0x11. + + Approved-By: Guinevere Larsen + +2025-01-14 Sam James + + ld: regenerate + 80dc29527ff9b5179741c360418e77e5064f2b69 contained some changes from + non-vanilla autoconf. Regenerate. + + ChangeLog: + + * config.in: Regenerate. + * configure: Regenerate. + +2025-01-14 Adhemerval Zanella + + ld: Add --enable-memory-seal configure option + Add --enable-memory-seal linker configure option to enable memory + sealing (GNU_PROPERTY_MEMORY_SEAL) by default. + + Change-Id: I4ce4ff33657f0f09b1ceb06210b6fcaa501f1799 + +2025-01-14 Adhemerval Zanella + + elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property + The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries + to be memory sealed by the loader, to avoid further changes of + PT_LOAD segments (such as unmapping or change permission flags). + This is done along with Linux kernel (the mseal syscall [1]), and + C runtime supports to instruct the kernel on the correct time during + program startup (for instance, after RELRO handling). This support + is added along the glibc support to handle the new gnu property [2]. + + This is a opt-in security features, like other security hardening + ones like NX-stack or RELRO. + + The new property is ignored if present on ET_REL objects, and only + added on ET_EXEC/ET_DYN if the linker option is used. A gnu property + is used instead of DT_FLAGS_1 flag to allow memory sealing to work + with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports + still do no support static-pie). + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370 + [2] https://sourceware.org/pipermail/libc-alpha/2024-September/160291.html + + Change-Id: Id47fadabecd24be0e83cff45653f7ce9a900ecf4 + +2025-01-14 Ella MA + + Fix a syntax error in sim/common/cgen-mem.h + +2025-01-14 H.J. Lu + + ld: Update mixed LTO and non-LTO relocatable output tests + Since mixed LTO and non-LTO relocatable output is only supported on ELF + platforms, limit these tests to ELF targets. Since powerpc64 elfv1 + defines a function symbol on its procedure descriptor, which is in a + data section, rather than on the code for that function, allow both D + and T for nm test on mixed object. + + * testsuite/ld-plugin/lto.exp: Limits mixed LTO and non-LTO + relocatable output tests to ELF targets. Allow both D and T for + nm test on mixed object. + +2025-01-14 Matthieu Longo + + aarch64 SFrame: skip with warning new CFI directive used with pauth_lr + Today, SFrame v2 specification does not describe how to encode the + information corresponding to the PAuth_LR PAC signing method (it only + supports PAuth PAC signing method). + SFrame v3 specification should hopefully specify it. + + In the meantime, if the GNU assembler finds .cfi_negate_ra_state_with_pc + and --gsframe is specified, it will output a warning to the user and + will fail to generate the FDE entry. + + A new SFrame test for .cfi_negate_ra_state_with_pc is also added to + reflect this issue. + + Approved-by: Indu Bhagat + +2025-01-14 Matthieu Longo + + aarch64 DWARF: add new CFI directive for PAuth_LR + This patch adds a new CFI directive (cfi_negate_ra_state_with_pc) which + set an additional bit in the RA state to inform that RA was signed with + SP but also PC as an additional diversifier. + + RA state | Description + 0b00 | Return address not signed (default if no cfi_negate_ra_state*) + 0b01 | Return address signed with SP (cfi_negate_ra_state) + 0b10 | Invalid state + 0b11 | Return address signed with SP+PC (cfi_negate_ra_state_with_pc) + + Approved-by: Indu Bhagat + Approved-by: Jan Beulich + +2025-01-14 Matthieu Longo + + aarch64 SFrame: use preferred CFI directive for AArch64 PAC + ARMv8.3 addded support for a new security feature named Pointer + Authentication. Support for this feature in SFrame already exists. + + In GCC 14 and older, the Sparc DWARF extension .cfi_gnu_window_save + is emitted instead of .cfi_negate_ra_state. + GCC 15 fixed this issue, but this behavior is preserved for backward + compatibility. + + The existing sframe test for AArch64 PAC was using .cfi_gnu_window_save. + This patch replaces this CFI in the existing test by the preferred one, + and adds a new test to check for backward compatibility when using + .cfi_gnu_window_save. + + Approved-by: Indu Bhagat + +2025-01-14 Matthieu Longo + + aarch64: make explicit that CFI gnu_window_save is for Sparc, not AArch64 + - add a detailed comment when parsing DW_CFA_GNU_window_save in SFrame to + explain why we are checking whether the targeted architecture is AArch64, + whereas this CFI is a Sparc extension. + - replace .cfi_gnu_window_save by .cfi_negate_ra_state in existing AArch64 + DWARF tests as this is the preferred directive since GCC 15. + - add a new AArch64 test to check backward compatibility with old GCC + versions that emits .cfi_gnu_window_save. + + Approved-by: Indu Bhagat + Approved-by: Richard Earnshaw + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove handling of the 'L' tracepoint action + Now that static tracepoint support is removed from gdbserver, it makes + sense to remove handling of the 'L' tracepoint action, too. The code + that checks received actions already has a default case that tolerates + unrecognized actions: + + default: + trace_debug ("unknown trace action '%c', ignoring...", *act); + + In case 'L' is unexpectedly received, we would at least be able to see + this in the logs. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove the static_tracepoint enum value + As a continuation of the previous patches that remove UST from + gdbserver, remove the `static_tracepoint` enum value from + `tracepoint_type` and all the associated code. + + Now that the last use of `write_e_static_tracepoints_not_supported` + is gone, also remove that function. + + The handling of the 'S' option, where the `static_tracepoint` enum + value was being used, is removed completely, because recognizing that + option makes sense only when static tracepoint support is announced. + + This patch is easier to view with "git show -w". + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: do not announce static tracepoint support + Remove the announcement that `qXfer:statictrace:read` and + `StaticTracepoints` are supported. Associated to this, remove the + handling of "qTfSTM", "qTsSTM", and "qTSTMat" packets and the + qXfer:statictrace:read handling. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove UST (static tracepoint) support (part 2) + With the removal of UST, the `in_process_agent_supports_ust` query + would essentially always be false. Remove the function and adjust + the uses, comments, and warning/error messages. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove UST (static tracepoint) support (part 1) + UST support in gdbserver is substantially outdated. Simon says: + + ...[having HAVE_UST defined] never happens nowadays because it used + a version of lttng-ust that has been deprecated for a loooong time + (the 0.x series). So everything in HAVE_UST just bitrots. It might + be possible to update all this code to use lttng-ust 2.x (1.x never + existed), but I don't think it's going to happen unless somebody + specifically asks for it. I would suggest removing support for UST + from gdbserver. ...If we ever want to resurrect the support for UST + and port to 2.x, we can get the code from the git history. + + This patch removes the support, mostly mechanically by deleting code + guarded by `#ifdef HAVE_UST`. After these removals, `struct + static_tracepoint_ctx` becomes unused. So, remove it, too. + + The following patches remove more code. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdb, doc: describe the 'L' tracepoint action + I noticed that 'L' is a tracepoint action but it is not defined in the + document. Add the description. + + Reviewed-By: Eli Zaretskii + +2025-01-14 Tankut Baris Aktemur + + gdb, doc: mention the 'S' option for the QTDP packet + I noticed that gdbserver accepts an 'S' option for the QTDP packet to + create a static tracepoint, but this is not mentioned in the document. + Update the document. + + I first thought about updating the argument as `[:Flen|:S]`, but then + opted for `[:Flen][:S]`. Although it is odd that ':F' and ':S' are + allowed to co-exist, the implementation at the gdbserver side allows + this and handles the packet arguments so that the right-most + positioned ':F' or ':S' overwrites the final tracepoint type. When + the documentation is missing, the implementation usually determines + the behavior. + + Reviewed-By: Eli Zaretskii + +2025-01-14 H.J. Lu + + ld: Call cmdline_check_object_only_section only if plugin is enabled + * ldfile.c (ldfile_try_open_bfd): Call + cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS + is defined. + +2025-01-14 Haochen Jiang + + x86: Remove "NE" in mnemonics for convert insns related to AI data types + NE is quite ambiguous and misleading in mnemonics since it should be + Rounding to Nearest Even, but could be mis-interpretated to No + Exception. + + Under its correct meaning, which means rounding, it should only be used + in down-convert, since up-convert is always exact for normal values + It could be difficult to judge which kind of convert it is if we have + the convert between same bit float types. + + For all AI data types including BF16 and FP8, the default rounding is + Rounding to Nearest Even. So removing them in mnemonics would reduce + burden for programmers to consider whether it should be added or not + in mnemonics and stop the ambiguous meaning on "NE" itself. + + If the convert itself is using a rounding mode other than RNE, it would + be explicitly added in mnemonics (e.g., Long used "T" and "BIAS" + introduced in AVX10.2). + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-cvt-intel.d: Refine testcases + according to mnemonics change. + * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Remove ne in mnemonics for + convert insns. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + x86: Rename VCOMSBF16 to VCOMISBF16 + The functionality for VCOMSBF16 is exactly the same as the VCOMISD/S/H. + The only difference is the bf16 type. Thus, it should be VCOMISBF16. + This patch would fix that. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase + according to mnemonics change. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Rename VCOMSBF16 to VCOMISBF16. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + x86: Remove "P" and "NE" in mnemonics for BF16 arithmetic insns + Since the bf16 is an AI data types, it will be implicitly packed. Thus, + "P" (for packed) is omitted in mnemonics from its introduction. AVX10.2 + BF16 arithmetic insns are introduced with "P" in mnemonics with packed. + This patch will remove them for consistency. + + NE is quite ambiguous and misleading in mnemonics since it should be + Rounding to Nearest Even, but could be mis-interpretated to No + Exception. While AI data types like BF16 and FP8 are using Rounding to + Nearest Even as default rounding modes. There is no need to use the + ambiguous mnemonics in AVX10.2 insns. This patch will also remove them. + + For convert insns, it will be handled in the upcoming patch. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase + according to new mnemonics. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Remove p and ne in bf16 mnemonics. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + Support Intel AMX-AVX512 + This patch will support AMX-AVX512. In disassmbler, we pull out all + GPR mode out of the vex length switch to make it more general. + + gas/ChangeLog: + + * NEWS: Mention the full support on DMR AMX ISAs. + * config/tc-i386.c: Add amx_avx512. + * doc/c-i386.texi: Document .amx_avx512. + * testsuite/gas/i386/x86-64.exp: Run AMX-AVX512 tests. + * testsuite/gas/i386/x86-64-amx-avx512-intel.d: New test. + * testsuite/gas/i386/x86-64-amx-avx512.d: Ditto. + * testsuite/gas/i386/x86-64-amx-avx512.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h: Add EVEX_LEN_0F384A_X86_64_W_0, + EVEX_LEN_0F386D_X86_64_W_0, EVEX_LEN_0F3A07_X86_64_W_0, + EVEX_LEN_0F3A77_X86_64_W_0. + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F384A_W_0_L_2, + PREFIX_EVEX_0F386D_W_0_L_2, PREFIX_EVEX_0F3A07_W_0_L_2, + PREFIX_EVEX_0F3A77_W_0_L_2. + * i386-dis-evex-w.h: Add EVEX_W_0F384A_X86_64, EVEX_W_0F386D_X86_64, + EVEX_W_0F3A07_X86_64, EVEX_W_0F3A77_X86_64. + * i386-dis-evex-x86-64.h: Add X86_64_EVEX_0F384A, X86_64_EVEX_0F386D, + X86_64_EVEX_0F3A07, X86_64_EVEX_0F3A77. + * i386-dis-evex.h: Ditto. + * i386-dis.c (EVEX_LEN_0F384A_X86_64_W_0): New. + (EVEX_LEN_0F386D_X86_64_W_0): Ditto. + (EVEX_LEN_0F3A07_X86_64_W_0): Ditto. + (EVEX_LEN_0F3A77_X86_64_W_0): Ditto. + (MOD_EVEX_0F384A_X86_64_W_0): Ditto. + (MOD_EVEX_0F386D_X86_64_W_0): Ditto. + (MOD_EVEX_0F3A07_X86_64_W_0): Ditto. + (MOD_EVEX_0F3A77_X86_64_W_0): Ditto. + (PREFIX_EVEX_0F384A_W_0_L_2): Ditto. + (PREFIX_EVEX_0F386D_W_0_L_2): Ditto. + (PREFIX_EVEX_0F3A07_W_0_L_2): Ditto. + (PREFIX_EVEX_0F3A77_W_0_L_2): Ditto. + (EVEX_W_0F384A_X86_64): Ditto. + (EVEX_W_0F386D_X86_64): Ditto. + (EVEX_W_0F3A07_X86_64): Ditto. + (EVEX_W_0F3A77_X86_64): Ditto. + (X86_64_EVEX_0F384A): Ditto. + (X86_64_EVEX_0F386D): Ditto. + (X86_64_EVEX_0F3A07): Ditto. + (X86_64_EVEX_0F3A77): Ditto. + (OP_VEX): Pull out all GPR mode out of the vector length switch. + * i386-gen.c (isa_dependencies): Add AMX-AVX512. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_AVX512): New. + (i386_cpu_flags): Add cpuamx_avx512. + * i386-opc.tbl: Add AMX-AVX512 instructions. + * i386-tbl.h: Regenerated. + +2025-01-14 Hu, Lin1 + Haochen Jiang + + Support Intel AMX-MOVRS + This patch will support AMX-MOVRS feature. Unlike all the other + AMX insns in vector space where we pass vex_len_table before + vex_w_table, we first pass vex_w_table for tileloaddrs[,t1] to + align with the order in EVEX space. The reason why we first pass + vex_w_table in EVEX space is due to AMX-AVX512, where tcvtrowd2ps + and tilemovrow with r32 shares the same opcode with tileloaddrs[,t1]. + All of them have evex.w = 0 but with different evex.length. Re-doing + that shortly is not ideal. + + APX_F extension is also implemented in this patch. The encoding will + be: + - EVEX.128.NP/66.MAP5.W0 F8/F9 !(11):rrr:100 for + T2RPNTLVW[Z0,Z1]RS[,T1] with NF=0. + - EVEX.128.F2/66.0F38.W0 4A !(11):rrr:100 FOR TILELOADDRS[,T1] with + NF=0. + + For APX_F extension, we could not use APX_F(AMX_TRANSPOSE&AMX_MOVRS) + since the transformation could not be done. Instead, we will use + AMX_TRANSPOSE & APX_F(AMX_MOVRS). Thus, we should set AMX_TRANSPOSE + for "any" for cpu_flags in assembler. Since it will only affect the + cpu_flags_match, handle that there. + + gas/ChangeLog: + + * config/tc-i386.c (cpu_arch): Add amx_movrs. + (cpu_flags_match): Set any bitfield for multiple cpuid + enabled insns. + * doc/c-i386.texi: Document .amx_movrs. + * testsuite/gas/i386/x86-64.exp: Run AMX-MOVRS tests. + * testsuite/gas/i386/x86-64-amx-movrs-intel.d: New test. + * testsuite/gas/i386/x86-64-amx-movrs-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs.d: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h (EVEX_LEN_0F384A_X86_64_W_0): New. + * i386-dis-evex-w.h (EVEX_W_0F384A_X86_64): Ditto. + * i386-dis-evex-x86-64.h (X86_64_EVEX_0F384A): Ditto. + * i386-dis-evex.h: New entry for AMX-MOVRS. + * i386-dis.c: + (PREFIX_VEX_0F384A_X86_64_L_0_W_0): New. + (PREFIX_VEX_MAP5_F8_X86_64_L_0_W_0): Ditto. + (PREFIX_VEX_MAP5_F9_X86_64_L_0_W_0): Ditto. + (X86_64_VEX_0F384A): Ditto. + (X86_64_VEX_MAP5_F8): Ditto. + (X86_64_VEX_MAP5_F9): Ditto. + (X86_64_EVEX_0F384A): Ditto. + (VEX_LEN_0F384A_X86_64_W_0): Ditto. + (VEX_LEN_MAP5_F8_X86_64): Ditto. + (VEX_LEN_MAP5_F9_X86_64): Ditto. + (EVEX_LEN_0F384A_X86_64_W_0): Ditto. + (VEX_W_0F384A_X86_64): Ditto. + (VEX_W_MAP5_F8_X86_64): Ditto. + (VEX_W_MAP5_F9_X86_64): Ditto. + (EVEX_W_0F384A_X86_64): Ditto. + (prefix_table): New entry for AMX-MOVRS. + (x86_64_table): Ditto. + (vex_len_table): Ditto. + (vex_w_table): Ditto. + (map5_f8_opcode): New. + (map5_f9_opcode): Ditto. + (get_valid_dis386): Handle VEX_MAP5 opcode for AMX-MOVRS. + * i386-gen.c (isa_dependencies): Add AMX_MOVRS. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_MOVRS): New. + (i386_cpu_flags): Add cpuamx_movrs. + * i386-opc.tbl: Add AMX-MOVRS instructions. + * i386-tbl.h: Regenerated. + +2025-01-14 Hu, Lin1 + Haochen Jiang + Lili Cui + + Support Intel MOVRS + This patch focus on supporting MOVRS ISA. We could take this full ISA + as four part: PREFETCHRST2, MOVRS, MOVRS APX_F extension and MOVRS AVX10.2 + extension. + + The APX_F extension for MOVRS will be: + - EVEX.LLZ.NP.MAP4.WIG 8A !(11):rrr:bbb for r8/m8 with NF=0 and + ND=0 + - EVEX.LLZ.NP/66.MAP4.SCALABLE 8B !(11):rrr:bbb for rv/mv with NF=0 + and ND=0 + + We did not merge the table together for APX_F since there is an explicit + x64 for movrs insn. The current APX_F() did not support the combination + between CPUIDs. Also, the space is different for legacy and apx_f forms. + + gas/ChangeLog: + + * NEWS: Support Intel MOVRS. + * config/tc-i386.c: Add MOVRS. + * doc/c-i386.texi: Document .movrs. + * testsuite/gas/i386/i386.exp: Run MOVRS tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Add MOVRS + tests. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + * testsuite/gas/i386/lfence-load.d: Add prefetchrst2. + * testsuite/gas/i386/lfence-load.s: Ditto. + * testsuite/gas/i386/nops-8.d: Ditto. + * testsuite/gas/i386/prefetch-intel.d: Ditto. + * testsuite/gas/i386/prefetch.d: Ditto. + * testsuite/gas/i386/x86-64-lfence-load.d: Ditto. + * testsuite/gas/i386/x86-64-lfence-load.s: Ditto. + * testsuite/gas/i386/x86-64-prefetch-intel.d: Ditto. + * testsuite/gas/i386/x86-64-prefetch.d: Ditto. + * testsuite/gas/i386/movrs-intel.d: New test. + * testsuite/gas/i386/movrs-inval.l: Ditto. + * testsuite/gas/i386/movrs-inval.s: Ditto. + * testsuite/gas/i386/movrs.d: Ditto. + * testsuite/gas/i386/movrs.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs.d: Ditto. + * testsuite/gas/i386/x86-64-movrs.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-intel-suffix.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-suffix.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-suffix.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_6F_X86_64. + * i386-dis-evex-x86.h: Add X86_64_EVEX_MAP5_6F. + * i386-dis-evex.h (evex_table): New entry for movrs. + * i386-dis.c (MOD_0F18_REG_4): New. + (PREFIX_EVEX_MAP5_6F_X86_64): Ditto. + (X86_64_0F388A): Ditto. + (X86_64_0F388B): Ditto. + (X86_64_EVEX_MAP5_6F): Ditto. + (three_byte_table): New entry for MOVRS. + (reg_table): Ditto. + (mod_table): Ditto. + (x86_64_table): Ditto. Also include i386-dis-evex-x86.h. + * i386-gen.c (cpu_flags): Add MOVRS. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (i386_cpu_flags): Add cpumovrs. + * i386-opc.tbl: Add MOVRS instrctions. + * i386-tbl.h: Regenerated. + +2025-01-14 Haochen Jiang + + x86: Remove mod_table pass for MVexSIBMEM + When using MVexSIBMEM, OP_M will help check modrm. Thus, no need + to pass mod_table. + + Since we have OP_M do the work, from now on, mod_table[] should + not gain any new entries, unless both slots of them are populated, + e.g., different modrm leading to different insns could not be + combined (Bad_Opcode is not the case since OP_M could handle that). + + opcodes/ChangeLog: + + * i386-dis.c: Remove mod_table pass for MVexSIBMEM. + +2025-01-14 GDB Administrator + + Automatic date update in version.in + +2025-01-13 H.J. Lu + + h8300: Handle .gnu_object_only section + PR ld/12291 + PR ld/12430 + PR ld/13298 + * config/tc-h8300.c (h8300_elf_section): Handle .gnu_object_only + section. + + ld: Document mixing LTO and non-LTO objects for -r + * ld.texi: Document mixing LTO and non-LTO relocatable files for + "ld -r". + +2025-01-13 H.J. Lu + + ld: Add LTO and none-LTO output support for ld -r + Link with mixed IR/non-IR objects + + * 2 kinds of object files + o non-IR object file has + * non-IR sections + o IR object file has + * IR sections + * non-IR sections + * The output of "ld -r" with mixed IR/non-IR objects should work with: + o Compilers/linkers with IR support. + o Compilers/linkers without IR support. + * Add the mixed object file which has + o IR sections + o non-IR sections: + * Object codes from IR sections. + * Object codes from non-IR object files. + o Object-only section: + * With section name ".gnu_object_only" and SHT_GNU_OBJECT_ONLY type + on ELF: + https://gitlab.com/x86-psABIs/Linux-ABI + #define SHT_GNU_OBJECT_ONLY 0x6ffffff8 /* Object only */ + * Contain non-IR object file. + * Input is discarded after link. + * Linker action: + o Classify each input object file: + * If there is a ".gnu_object_only" section, it is a mixed object file. + * If there is a IR section, it is an IR object file. + * Otherwise, it is a non-IR object file. + o Relocatable non-IR link: + * Prepare for an object-only output. + * Prepare for a regular output. + * For each mixed object file: + * Add IR and non-IR sections to the regular output. + * For object-only section: + * Extract object only file. + * Add it to the object-only output. + * Discard object-only section. + * For each IR object file: + * Add IR and non-IR sections to the regular output. + * For each non-IR object file: + * Add non-IR sections to the regular output. + * Add non-IR sections to the object-only output. + * Final output: + * If there are IR objects, non-IR objects and the object-only + output isn't empty: + * Put the object-only output into the object-only section. + * Add the object-only section to the regular output. + * Remove the object-only output. + o Normal link and relocatable IR link: + * Prepare for output. + * IR link: + * For each mixed object file: + * Compile and add IR sections to the output. + * Discard non-IR sections. + * Object-only section: + * Extract object only file. + * Add it to the output. + * Discard object-only section. + * For each IR object file: + * Compile and add IR sections to the output. + * Discard non-IR sections. + * For each non-IR object file: + * Add non-IR sections to the output. + * Non-IR link: + * For each mixed object file: + * Add non-IR sections to the output. + * Discard IR sections and object-only section. + * For each IR object file: + * Add non-IR sections to the output. + * Discard IR sections. + * For each non-IR object file: + * Add non-IR sections to the output. + + This is useful for Linux kernel build with LTO. + + bfd/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * bfd.c (bfd_lto_object_type): Add lto_mixed_object. + (bfd): Add object_only_section. + (bfd_group_signature): New. + * elf.c (special_sections_g): Add .gnu_object_only. + * format.c: Include "plugin-api.h" and "plugin.h" if + BFD_SUPPORTS_PLUGINS is defined. + (bfd_set_lto_type): Set type to lto_mixed_object for + GNU_OBJECT_ONLY_SECTION_NAME section. + (bfd_check_format_matches): Don't check the plugin target twice + if the plugin target is explicitly specified. + * opncls.c (bfd_extract_object_only_section): New. + * plugin.c (bfd_plugin_fake_text_section): New. + (bfd_plugin_fake_data_section): Likewise. + (bfd_plugin_fake_bss_section): Likewise. + (bfd_plugin_fake_common_section): Likewise. + (bfd_plugin_get_symbols_in_object_only): Likewise. + * plugin.c (add_symbols): Call + bfd_plugin_get_symbols_in_object_only and count + plugin_data->object_only_nsyms. + (bfd_plugin_get_symtab_upper_bound): Count + plugin_data->object_only_nsyms. + bfd_plugin_get_symbols_in_object_only and add symbols from + object only section. + (bfd_plugin_canonicalize_symtab): Remove fake_section, + fake_data_section, fake_bss_section and fake_common_section. + Set udata.p to NULL. Use bfd_plugin_fake_text_section, + bfd_plugin_fake_data_section, bfd_plugin_fake_bss_section and + bfd_plugin_fake_common_section. + Set udata.p to NULL. + * plugin.h (plugin_data_struct): Add object_only_nsyms and + object_only_syms. + * section.c (GNU_OBJECT_ONLY_SECTION_NAME): New. + * bfd-in2.h: Regenerated. + + binutils/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * objcopy.c (group_signature): Removed. + (is_strip_section): Replace group_signature with + bfd_group_signature. + (setup_section): Likewise. + * readelf.c (get_os_specific_section_type_name): Handle + SHT_GNU_OBJECT_ONLY. + + gas/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * testsuite/gas/elf/section9.s: Add the .gnu_object_only test. + * testsuite/gas/elf/section9.d: Updated. + + include/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * elf/common.h (SHT_GNU_OBJECT_ONLY): New. + + ld/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * ld.h (ld_config_type): Add emit_gnu_object_only and + emitting_gnu_object_only. + * ldelf.c (orphan_init_done): Make it file scope. + (ldelf_place_orphan): Rename hold to orig_hold. Initialize hold + from orig_hold at run-time. + (ldelf_finish): New. + * ldelf.h (ldelf_finish): New. + * ldexp.c (ldexp_init): Take a bfd_boolean argument to supprt + object-only output. + (ldexp_finish): Likewise. + * ldexp.h (ldexp_init): Take a bfd_boolean argument. + (ldexp_finish): Likewise. + * ldfile.c (ldfile_try_open_bfd): Call + cmdline_check_object_only_section. + * ldlang.c: Include "ldwrite.h" and elf-bfd.h. + * ldlang.c (cmdline_object_only_file_list): New. + (cmdline_object_only_archive_list): Likewise. + (cmdline_temp_object_only_list): Likewise. + (cmdline_lists_init): Likewise. + (cmdline_list_new): Likewise. + (cmdline_list_append): Likewise. + (print_cmdline_list): Likewise. + (cmdline_on_object_only_archive_list_p): Likewise. + (cmdline_object_only_list_append): Likewise. + (cmdline_get_object_only_input_files): Likewise. + (cmdline_arg): Likewise. + (setup_section): Likewise. + (copy_section): Likewise. + (cmdline_fopen_temp): Likewise. + (cmdline_add_object_only_section): Likewise. + (cmdline_emit_object_only_section): Likewise. + (cmdline_extract_object_only_section): Likewise. + (cmdline_check_object_only_section): Likewise. + (cmdline_remove_object_only_files): Likewise. + (lang_init): Take a bfd_boolean argument to supprt object-only + output. Call cmdline_lists_init. + (load_symbols): Call cmdline_on_object_only_archive_list_p + to check if an archive member should be loaded. + (lang_process): Handle object-only link. + * ldlang.h (lang_init): Take a bfd_boolean argument. + (cmdline_enum_type): New. + (cmdline_header_type): Likewise. + (cmdline_file_type): Likewise. + (cmdline_bfd_type): Likewise. + (cmdline_union_type): Likewise. + (cmdline_list_type): Likewise. + (cmdline_emit_object_only_section): Likewise. + (cmdline_check_object_only_section): Likewise. + (cmdline_remove_object_only_files): Likewise. + * ldmain.c (main): Call xatexit with + cmdline_remove_object_only_files. Pass FALSE to lang_init, + ldexp_init and ldexp_finish. Use ld_parse_linker_script. + Set link_info.output_bfd to NULL after close. Call + cmdline_emit_object_only_section if needed. + (add_archive_element): Call cmdline_check_object_only_section. + (ld_parse_linker_script): New. + * ldmain.h (ld_parse_linker_script): New. + * plugin.c (plugin_maybe_claim): Call + cmdline_check_object_only_section on claimed IR files. + * scripttempl/elf.sc: Also discard .gnu_object_only sections. + * scripttempl/elf64hppa.sc: Likewise. + * scripttempl/elfxtensa.sc: Likewise. + * scripttempl/mep.sc: Likewise. + * scripttempl/pe.sc: Likewise. + * scripttempl/pep.sc: Likewise. + * emultempl/aarch64elf.em (gld${EMULATION_NAME}_finish): Replace + finish_default with ldelf_finish. + * emultempl/alphaelf.em (alpha_finish): Likewise. + * emultempl/avrelf.em (avr_finish): Likewise. + * emultempl/elf.em (ld_${EMULATION_NAME}_emulation): Likewise. + * emultempl/ppc32elf.em (ppc_finish): Likewise. + * emultempl/ppc64elf.em (gld${EMULATION_NAME}_finish): Likewise. + * emultempl/spuelf.em (gld${EMULATION_NAME}_finish): Likewise. + * testsuite/ld-plugin/lto-10.out: New file. + * testsuite/ld-plugin/lto-10a.c: Likewise. + * testsuite/ld-plugin/lto-10b.c: Likewise. + * testsuite/ld-plugin/lto-10r.d: Likewise. + * testsuite/ld-plugin/lto-4.out: Likewise. + * testsuite/ld-plugin/lto-4a.c: Likewise. + * testsuite/ld-plugin/lto-4b.c: Likewise. + * testsuite/ld-plugin/lto-4c.c: Likewise. + * testsuite/ld-plugin/lto-4r-a.d: Likewise. + * testsuite/ld-plugin/lto-4r-b.d: Likewise. + * testsuite/ld-plugin/lto-4r-c.d: Likewise. + * testsuite/ld-plugin/lto-4r-d.d: Likewise. + * testsuite/ld-plugin/lto.exp (lto_link_tests): Prepare for + "LTO 4[acd]", "lto-4r-[abcd]" and "LTO 10" tests. + (lto_run_tests): Add "LTO 4[acd]" and "LTO 10" tests. + Build liblto-4.a. Run "lto-4r-[abcd]" tests. + Run lto-10r and create tmpdir/lto-10.o. + Add test for nm on mixed LTO/non-LTO object. + +2025-01-13 Aditya Vidyadhar Kamath + + Fix AIX CI build break. + In AIX a recent commit caused a build break with the error as shown below. + In file included from python/py-color.h:23, + from python/python.c:39: + python/python-internal.h:86:10: fatal error: Python.h: No such file or directory + 86 | #include + + In AIX, we run builds with and without python for our internal CI's. + + A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690 + missed to guard Python.h in HAVE_PYTHON macro. + + This commit is a fix for the same. + + Approved-By: Tom Tromey + +2025-01-13 Tom Tromey + + Handle case where DAP line can be None + A comment in bugzilla pointed out a bug in my earlier patch to handle + the DAP "linesStartAt1" setting. In particular, in the backtrace + code, "line" can be None, which would lead to an exception from + export_line. + + This patch fixes the problem. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468 + +2025-01-13 Jan Beulich + + bfd/ELF: slightly "better" file alignment for object files + PR gas/32435 + + Commit 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object + files") caused an issue in the Linux kernels modpost utility, which was + building upon .rodata sections to be 4-byte aligned in the file when + they have 4-byte alignment. While we don't want to revert back to + original behavior, apply the same alignment "capping" as done originally + in two other places also for "ordinary" sections. + +2025-01-13 Tankut Baris Aktemur + + gdb, doc: do a minor fix in the description of qTSTMat + Fix a typo and do a format change. + +2025-01-13 Simon Marchi + + gdb/jit: use correctly-sized array view in deprecated_frame_register_read call + Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in + register reading and unwinding") introduces a regression in + gdb.base/jit-reader.exp: + + $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/jit-reader/jit-reader -ex 'jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader.so' -ex r -batch + + This GDB supports auto-downloading debuginfo from the following URLs: + + Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] + Debuginfod has been disabled. + To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". + + Program received signal SIGTRAP, Trace/breakpoint trap. + Recursive internal problem. + + The "Recusive internal problem" part is not good, but it's not the point + of this patch. It still means we hit an internal error. + + The stack trace is: + + #0 internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53 + #1 0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...) + at /home/simark/src/binutils-gdb/gdb/frame.c:1207 + #2 0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496 + #3 0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988 + #4 0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100 + #5 0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143 + #6 0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 , this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042 + #7 0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 ) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138 + #8 0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209 + #9 0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996 + #10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033 + + The problem is that function `jit_unwind_reg_get_impl` passes field + `gdb_reg_value::value`, a gdb_byte array of 1 element (used as a + flexible array member), as the array view parameter of + `deprecated_frame_register_read`. This results in an array view of size + 1. The assertion in `frame_register_unwind` that verifies the passed in + buffer is larger enough to hold the unwound register value then fails. + + Fix this by explicitly creating an array view of the right size. + + Change-Id: Ie170da438ec9085863e7be8b455a067b531635dc + Reviewed-by: Thiago Jung Bauermann + +2025-01-13 Nelson Chu + + RISC-V: Cleanup the imply code and test cases for vendor xsf extensions. + +2025-01-13 GDB Administrator + + Automatic date update in version.in + +2025-01-12 Andrei Pikas + + Add an option with a color type. + Colors can be specified as "none" for terminal's default color, as a name of + one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc., + as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an + integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard + colors. Integers 8-15 are used for the so-called bright colors from the + aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm + extended 256-color palette (usually 6x6x6 cube plus gray ramp). In + general, 256-color palette is terminal dependent and sometimes can be + changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\". + + It is the responsibility of the user to verify that the terminal supports + the specified colors. + + PATCH v5 changes: documentation fixed. + PATCH v6 changes: documentation fixed. + PATCH v7 changes: rebase onto master and fixes after review. + PATCH v8 changes: fixes after review. + +2025-01-12 Tom Tromey + + Fix grammar in "Debug Names" node of the manual + I noticed that an article was missing in the "Debug Names" node. I'm + checking this in to correct the error. + +2025-01-12 Tom Tromey + + Remove unused declaration and macros + event-top.h declares the_prompts, but it is never defined. It's a + leftover from some ancient refactoring. + + Similarly, top.c defines a few prompt-related macros, but these are + unused. + + This patch removes these. + +2025-01-12 H.J. Lu + + ld: Update function prototypes for compilers defaulting to -std=gnu23 + Since GCC 15 defaults to -std=gnu23, update function prototypes in linker + tests for compilers defaulting to -std=gnu23. + + PR ld/32546 + * ld-shared/main.c (shlib_checkfunptr1): Update prototype for + compilers defaulting to -std=gnu23. + (shlib_checkfunptr2): Likewise. + * ld-shared/sh1.c (shlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + * ld-srec/sr1.c (fn1): Likewise. + (fn2): Likewise. + * ld-srec/sr2.c (fn1): Likewise. + (fn2): Likewise. + * ld-vsb/main.c (shlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + * ld-vsb/sh1.c (hlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + +2025-01-12 Sergio Durigan Junior + + Fix typo in gdb/csky-linux-tdep.c + This was flagged by Debian's lintian. + +2025-01-12 GDB Administrator + + Automatic date update in version.in + +2025-01-11 Tom Tromey + + Update comment in linespec.c + I belatedly realized I had forgotten to update a bool-related comment + in linespec.c. This patch fixes the oversight. + +2025-01-11 Tom Tromey + + Use bool in linespec + This changes various spots in linespec to use a bool rather than an + int. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Hoist lambda in linespec.c:add_matching_symbols_to_info + I noticed that two parts of linespec.c:add_matching_symbols_to_info + use the same lambda, and hoisting this seems slightly more efficient. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Minor cleanup in linespec.c:add_minsym + This cleans up a 'return' in linespec.c:add_minsym. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Use std::vector in linespec_state + This changes linespec_state to use a std::vector, and changes + linespec_canonical_name to use std::string. This removes some manual + memory management, including some odd cleanup code in in + decode_line_full. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Use gdb::unordered_set in linespec_state + This patch changes linespec_state to use gdb::unordered_set. This + simplifies the code a little and removes some manual management. It + also replaces address_entry with a std::pair, which simplifies the + code even more; and since this is a private type, IMO it doesn't + reduce readability at all. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Add constructor and destructor to linespec_state + This changes linespec_state to have real constructors and a + destructor. + + Approved-By: Simon Marchi + +2025-01-11 GDB Administrator + + Automatic date update in version.in + +2025-01-10 Thiago Jung Bauermann + + GDB: Use gdb::array_view for buffers used in register reading and unwinding + This allows checking the size of the given buffer. Changes + frame_register_unwind (), frame_unwind_register (), get_frame_register () + and deprecated_frame_register_read (). + + As pointed out by Baris, in the case of MIPS target code this is best + done by changing a couple of alloca-based buffers in + mips_read_fp_register_single and mips_print_fp_register to + gdb::byte_vector instances. + + Approved-By: Simon Marchi + +2025-01-10 Thiago Jung Bauermann + + GDB: frame: Make VALUEP argument optional in frame_register_unwind + It already accepts a nullptr value and a couple of places were always + calling it that way, so make it possible to omit the argument entirely. + + Approved-By: Simon Marchi + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_B16B16 feature. + This patch adds support for SME ZA-targeting non-widening BFloat16 instructions, + under tick FEAT_SME_B16B16 and command line flag "+sme-b16b16". + + FEAT_SME_B16B16 implements FEAT_SME2 and FEAT_SVE_B16B16, in accordance with that + "+sme-b16b16" enables "+sme2" and "+sve-b16b16". + + Also the test files related to FEAT_SME_B16B16 are prefixed with sme-b16b16*. + eg: sme-b16b16-1.s, sme-b16b16-1.d. + + The spec for this feature and instructions is availabe here [1]: + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE_B16B16 min and max instructions. + This patch adds support for SME Z-targeting multi-vector non-widening + BFloat16 instructions, under tick FEAT_SVE_B16B16 and command line flag + "+sve-b16b16+sme2". + + Also the test files related to FEAT_SVE_B16B16 (+sme2) are prefixed with + sve-b16b16-sme2*. + eg: sve-b16b16-sme2-1.s, sve-b16b16-sme2-1.d. + + The spec for this feature and instructions is availabe here [1]: + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE_B16B16 feature. + In the current code, SVE2 Bfloat16 instructions are implemented with tick + FEAT_B16B16 and command line flag "+b16b16" and this feature was suspended + due to incomplete support. + + In the new spec available here[1], FEAT_B16B16 is replaced with + FEAT_SVE_B16B16 and command line flag "+b16b16" is replace with "sve-b16b16". + + Also the test files related to FEAT_SVE_B16B16 are prefixed with sve-b16b16*. + eg: sve-b16b16-sve2-1.s, sve-b16b16-sve2-1.d. + + This patch supports the SVE Z-targeting non-widening BFloat16 instructions + with command line flag "+sve-b16b16+sve2". + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SVE-Instructions?lang=en + +2025-01-10 Andrew Carlotti + + aarch64: Make VGx4 symbol mandatory for fvdotb and fvdott + Add tests for this, and update the existing fvdotb and fvdott tests to + include the VGx4 symbol so that they continue to test for the intended + errors. + + aarch64: Rename AARCH64_OPND_SME_ZT0_INDEX2_12 + Rename to AARCH64_OPND_SME_ZT0_INDEX_MUL_VL. + + aarch64: Add tests for movt with missing "mul vl" + The error message really isn't appropriate (both here and elsewhere in + the test file), but I don't currently have time to investigate further. + + aarch64: Remove redundant sme-lutv2 qualifiers and operands + + aarch64: Fix incorrect gating of sme-lutv2 instructions + Only the strided form of the luti4 intrinsic requires FEAT_SME2p1. + +2025-01-10 Tom Tromey + + Minor test case updates for gnat-llvm + gnat-llvm seems to be a bit more aggressive about eliminating unused + variables. This patch improves the test results a tiny bit by + arranging for some variables to appear to be used. + + Note the copyright dates on the new files are done that way because I + simply copied existing files. + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_F16F16 fcvt and fcvtl instructions. + This patch adds support for FEAT_SME_F16F16 instructions fcvt and fcvtl, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + + aarch64: Add support for FEAT_SME_F16F16 fmla and fmls instructions. + This patch adds support for FEAT_SME_F16F16 instructions fmla and fmls, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + + aarch64: Add support for FEAT_SME_F16F16 fmops and fmopa instructions. + This patch adds support for FEAT_SME_F16F16 instructions fmops and fmopa, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_F16F16 feature. + This patch adds support for FEAT_SME_F16F16 feature (Non-widening + half-precision FP16 to FP16 arithmetic for SME2), which is enabled + using command line flags +sme-f16f16 to -march (which enables both + FEAT_SME2 and FEAT_SME_F16F16). + + There are couple of instructions (fadd and fsub variants) which should + be allowed by the assembler on either passing +sme-f16f16 or +sme-f8f16. + Those instructions are already supported in the current assembler, this + patch adds tests for those instructions as well. + +2025-01-10 Tom de Vries + + [gdb/tdep] Fix gdb.cp/non-trivial-retval.exp on riscv64-linux + With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into: + ... + (gdb) finish^M + Run till exit from #0 f1 (i1=i1@entry=23, i2=i2@entry=100) \ + at non-trivial-retval.cc:34^M + main () at non-trivial-retval.cc:163^M + 163 B b = f2 (i1, i2);^M + Value returned is $6 = {a = -5856}^M + (gdb) FAIL: $exp: finish from f1 + ... + where "Value returned is $6 = {a = 123}" is expected. + + The problem is that gdb thinks that the return value is in $a0: + ... + $ gdb -q -batch non-trivial-retval \ + -ex "b f1" \ + -ex run \ + -ex "set debug riscv infcall on" \ + -ex finish + Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34. + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1". + + Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34 + 34 { + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + main () at non-trivial-retval.cc:163 + 163 B b = f2 (i1, i2); + Value returned is $1 = {a = -3568} + ... + while $a0 actually contains a pointer to the returned value 123: + ... + (gdb) p /x $a0 + $3 = 0x3ffffff210 + (gdb) p *((unsigned int *)$a0) + $5 = 123 + ... + + The returned type is: + ... + class A + { + public: + A () {} + A (A &obj); + + int a; + }; + ... + which is a C++ aggregate with a nontrivial (because it's user-defined) copy + constructor: + + According to the ABI [1], indeed this is returned by reference: + ... + Values are returned in the same manner as a first named argument of the same + type would be passed. If such an argument would have been passed by + reference, the caller allocates memory for the return value, and passes the + address as an implicit first parameter. + ... + Aggregates larger than 2×XLEN bits are passed by reference and are replaced in + the argument list with the address, as are C++ aggregates with nontrivial copy + constructors, destructors, or vtables. + ... + + Fix this in riscv_call_arg_scalar_int by checking for + language_pass_by_reference ().trivially_copy_constructible. + + The vtable case is explictly mentioned in the ABI, but AFAIU already covered + by the nontrivial copy constructor case. + + The nontrivial destructor case is also not supported, but the testsuite + doesn't seem to trigger this. + + Fix this by: + - extending the test-case to cover this scenario, and + - fixing it in riscv_call_arg_scalar_int by checking for + language_pass_by_reference ().trivially_destructible. + + Tested on riscv64-linux. + + PR tdep/32152 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32152 + + Approved-By: Andrew Burgess + + [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc + +2025-01-10 Tom de Vries + + [gdb/testsuite] Fix gdb.rust/completion.exp timeout on riscv64-linux + On riscv64-linux, with test-case gdb.rust/completion.exp I run into the + following timeout: + ... + (gdb) complete break pars^M + FAIL: gdb.rust/completion.exp: complete break pars (timeout) + ... + + Replaying the scenario outside the testsuite show us that the command takes + ~13 seconds: + ... + $ gdb -q -batch -x gdb.in + ... + 2025-01-08 12:23:46.853 - command started + +complete break pars + break parse.rs + break parse_printf_format + break parse_running_mmaps_unix.rs + break parser.rs + 2025-01-08 12:23:59.600 - command finished + Command execution time: 12.677752 (cpu), 12.748565 (wall) + ... + while the timeout is 10 seconds. + + The riscv64 processor on the server (cfarm91) is not fast (a fair amount of + the skip_huge_test test-cases times out), but something else is going on as + well. + + For x86_64-linux, roughly measuring the size of debug info in the exec get us: + ... + $ readelf -wi outputs/gdb.rust/completion/completion | wc -l + 2007 + ... + while on the riscv64 server I get: + ... + $ readelf -wi outputs/gdb.rust/completion/completion | wc -l + 1606950 + ... + + So it seems reasonable that the test is somewhat slower on riscv64. + + Fix this by using timeout factor 2. + + Tested on riscv64-linux and x86_64-linux. + + Approved-By: Tom Tromey + +2025-01-10 MayShao-oc + + x86: Support x86 Zhaoxin PadLockRNG2 instruction + This patch adds support for Zhaoxin PadLock RNG2 instruction, the + CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2 + instruction. + + gas/ChangeLog: + + * NEWS: Support Zhaoxin PadLock RNG2 instruction. + * config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to + PadLock RNG2 instruction. + (output_insn): Handle PadLock RNG2 instruction. + * doc/c-i386.texi: Document PadLock RNG2. + * testsuite/gas/i386/i386.exp: Add PadLock RNG2 test. + * testsuite/gas/i386/padlock_rng2.d: Ditto. + * testsuite/gas/i386/padlock_rng2.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add PadLockRNG2. + * i386-gen.c: Ditto + * i386-opc.h (CpuPadLockRNG2): New. + * i386-opc.tbl: Add Zhaoxin PadLock RNG2 instruction. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-10 Jan Beulich + + gas: consolidate . latching + ... by purging dot_{frag,value}. Right now these two and dot_symbol are + updated independently, which can't be quite right. Centralize .-related + information in dot_symbol, updating it also where previously + dot_{frag,value} were updated. Since S_GET_VALUE() can't be used to + retrieve what used to be dot_value, introduce a new helper to fetch both + frag and offset. + +2025-01-10 Jan Beulich + + aarch64: re-work PR gas/27217 fix again + Commit c1723a8118f0 ("Arm64: re-work PR gas/27217 fix") really was only + a band-aid; Nick's original solution to the problem was technically + preferable, yet didn't work when . came into play. Undo most of that + change, now that expr_defer expression parsing mode latches dot as is + desired here. + + Also add testing for the . case, which I should have done already back + at the time. + +2025-01-10 Jan Beulich + + gas: make deferred expression evaluation generally latch dot + Deferring expression evaluation is often necessary. However, the value + current_location() records typically is intended to represent the + location at the point of use of the expression, with the exception being + .eqv (or its == equivalent). Change how expr_defer behaves in this + regard, and introduce a special mode just for pseudo_set() to use. + + Introduce a predicate to cover both "deferred" modes, and use it + everywhere except in current_location(), where only the new mode wants + checking for. + +2025-01-10 Tom de Vries + + [gdb/build, c++20] Fix build with gcc 10 + With gcc 10 and -std=c++20, we run into the same problem as reported in commit + 6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct"). + + The problem was fixed using: + ... + -template> + +template= 202002L + + = std::pmr::polymorphic_allocator + +#else + + = std::allocator + +#endif + + > + ... + but that doesn't work for gcc 10, because it defines __cplusplus differently: + ... + $ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus + #define __cplusplus 201709L + $ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus + #define __cplusplus 202002L + ... + + Fix this by using the library feature test macro + __cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined + for c++20: + ... + $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \ + | grep __cpp_lib_polymorphic_allocator + $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \ + | grep __cpp_lib_polymorphic_allocator + #define __cpp_lib_polymorphic_allocator 201902L + $ + ... + + A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work + around Werror=volatile in libguile.h"). Fix this by testing for 201709L + instead. + + Tested on x86_64-linux, by building gdb with + {gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}. + + PR build/32503 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503 + + Approved-By: Tom Tromey + + [1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator + +2025-01-10 Thiago Jung Bauermann + + GDB: trad-frame: Store length of value_bytes in trad_frame_saved_reg + The goal is to ensure that it is available in frame_unwind_got_bytes () to + make sure that the provided buf isn't larger than the size of the register + being provisioned. + + In the process, regcache's cached_reg_t::data also needed to be + converted to a gdb::byte_vector, so that the register contents' size can + be tracked. + + Approved-By: Simon Marchi + +2025-01-10 Thiago Jung Bauermann + + GDB: remote: Print total bytes received in debug message + This is useful information I missed while debugging issues with + the g packet reply. + + Reviewed-By: Tankut Baris Aktemur + Approved-By: Simon Marchi + +2025-01-10 GDB Administrator + + Automatic date update in version.in + +2025-01-09 Tom de Vries + + [gdb/tdep] Fix gdb.base/readnever.exp on s390x + On s390x-linux, I run into: + ... + (gdb) backtrace + #0 0x000000000100061a in fun_three () + #1 0x000000000100067a in fun_two () + #2 0x000003fffdfa9470 in ?? () + Backtrace stopped: frame did not save the PC + (gdb) FAIL: gdb.base/readnever.exp: backtrace + ... + + This is really due to a problem handling the fun_three frame. When generating + a backtrace from fun_two, everying looks ok: + ... + $ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \ + -ex "b fun_two" \ + -ex run \ + -ex bt + ... + #0 0x0000000001000650 in fun_two () + #1 0x00000000010006b6 in fun_one () + #2 0x00000000010006ee in main () + ... + + For reference the frame info with debug info (without -readnever) looks like this: + ... + $ gdb -q -batch outputs/gdb.base/readnever/readnever \ + -ex "b fun_three" \ + -ex run \ + -ex "info frame" + ... + Stack level 0, frame at 0x3fffffff140: + pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a + called by frame at 0x3fffffff1f0 + source language c. + Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c + Locals at 0x3fffffff140, Previous frame's sp in v0 + ... + + But with -readnever, like this instead: + ... + Stack level 0, frame at 0x0: + pc = 0x100061a in fun_three; saved pc = 0x100067a + called by frame at 0x3fffffff140 + Arglist at 0xffffffffffffffff, args: + Locals at 0xffffffffffffffff, Previous frame's sp in r15 + ... + + An obvious difference is the "Previous frame's sp in" v0 vs. r15. + + Looking at the code: + ... + 0000000001000608 : + 1000608: b3 c1 00 2b ldgr %f2,%r11 + 100060c: b3 c1 00 0f ldgr %f0,%r15 + 1000610: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) + 1000616: b9 04 00 bf lgr %r11,%r15 + ... + it becomes clear what is going on. This is an unusual prologue. + + Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack, + instead they're saved into call-clobbered floating point registers. + + [ For reference, this is the prologue of fun_two: + ... + 0000000001000640 : + 1000640: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) + 1000646: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) + 100064c: b9 04 00 bf lgr %r11,%r15 + ... + where the first instruction stores registers r11 to r15 to stack. ] + + Gdb fails to properly analyze the prologue, which causes the problems getting + the frame info. + + Fix this by: + - adding handling of the ldgr insn [1] in s390_analyze_prologue, and + - recognizing the insn as saving a register in + s390_prologue_frame_unwind_cache. + + This gets us instead: + ... + Stack level 0, frame at 0x0: + pc = 0x100061a in fun_three; saved pc = 0x100067a + called by frame at 0x3fffffff1f0 + Arglist at 0xffffffffffffffff, args: + Locals at 0xffffffffffffffff, Previous frame's sp in f0 + ... + and: + ... + (gdb) backtrace^M + #0 0x000000000100061a in fun_three ()^M + #1 0x000000000100067a in fun_two ()^M + #2 0x00000000010006b6 in fun_one ()^M + #3 0x00000000010006ee in main ()^M + (gdb) PASS: gdb.base/readnever.exp: backtrace + ... + + Tested on s390x-linux. + + PR tdep/32417 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417 + + Approved-By: Andreas Arnez + + [1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf + +2025-01-09 Tom de Vries + + [gdb/tdep] Use symbolic constants in s390_prologue_frame_unwind_cache + In s390_prologue_frame_unwind_cache there are two loops using a hardcoded + constant 16: + ... + for (i = 0; i < 16; i++) + if (s390_register_call_saved (gdbarch, S390_R0_REGNUM + i) + ... + for (i = 0; i < 16; i++) + if (s390_register_call_saved (gdbarch, S390_F0_REGNUM + i) + ... + + Fix this by using symbolic constants S390_NUM_GPRS and S390_NUM_FPRS instead. + + Tested on s390x-linux, by rebuilding. + + Approved-By: Andreas Arnez + +2025-01-09 Tankut Baris Aktemur + + gdbserver: introduce and use regcache::set_register_status + Introduce and use a setter method in regcache to set the status of a + register. There already exists get_register_status. So, it made + sense to add the setter to control access to the register_status + field. + + In two places, we also do cosmetic improvements to for-loops. + + Approved-By: Simon Marchi + +2025-01-09 Tom de Vries + + [gdb/testsuite] Run one more test-case with ASAN_OPTIONS=verify_asan_link_order=0 + After building gdb with asan, and running test-case + gdb.trace/basic-libipa.exp, I got: + ... + (gdb) run ^M + Starting program: basic-libipa ^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + ==7705==ASan runtime does not come first in initial library list; you should \ + either link runtime to your application or manually preload it with \ + LD_PRELOAD.^M + [Inferior 1 (process 7705) exited with code 01]^M + (gdb) FAIL: gdb.trace/basic-libipa.exp: runto: run to main + ... + + Fix this in the same way as in commit 75948417af8 ("[gdb/testsuite] Run two + test-cases with ASAN_OPTIONS=verify_asan_link_order=0"). + + Tested on x86_64-linux. + +2025-01-09 Tankut Baris Aktemur + + gdb: boolify thread_info's 'stop_requested' field + Boolify the field. The 'set_stop_requested' function was already + taking a bool parameter, whose value is assigned to the field. + + Approved-By: Andrew Burgess + +2025-01-09 Alan Modra + + PR32238, ld -r slowdown since 21401fc7bf + PR 32238 + * ldlang.c (struct out_section_hash_entry): Add "tail". + (output_section_statement_newfunc_1): New, extracted from.. + (output_section_statement_newfunc): ..here. Init tail. + (lang_output_section_statement_lookup): Use tail to avoid + list traversal. + +2025-01-09 Tankut Baris Aktemur + + gdbserver: dump 'xx...x' in collect_register_as_string for unavailable register + Fix 'collect_register_as_string' so that unavailable registers are + dumped as 'xx...x' instead of arbitrary values, in particular when + reporting expedited registers in a resume reply packet. This change + gives the opportunity that we can reuse 'collect_register_as_string' + in 'registers_to_string' for additional code simplification. + + Reviewed-By: Luis Machado + Approved-By: Simon Marchi + +2025-01-09 Alan Modra + + xfail quad-div2 test for am33 + + Excessive gas .irpt count + There is a test in do_repeat to error on "negative" repeat counts. + Just at what value a ssize_t is negative of course depends on the + host. Change the excessive repeat count to a fixed value, 0x80000000, + ie. what would be seen as negative on a 32-bit host. + +2025-01-09 Xiao Zeng + + ld: Utilize specific digit ranges for different numeral systems + * ldlex.l: Utilize specific digit ranges for different + numeral systems. + +2025-01-09 Charlie Jenkins + + RISC-V: Add partial instruction display tests + When objdump is specified with a stop address that ends up in the middle + of an instruction, the partial instruction is expected to be displayed. + These three tests check that the partial instruction is correctly + displayed when there are 1, 2, or 3 bytes of the instruction dumped. + +2025-01-09 Charlie Jenkins + + RISC-V: Fix display of partial instructions + As of commit e43d8768d909 ("RISC-V: Fix disassemble fetch fail return + value.") partial instructions are no longer displayed by objdump. While + that commit fixed the behavior of print_insn_riscv() returning the + arbitrary status value upon failure, it caused the behavior of dumping + instructions to change. Allow partial instructions to be displayed once + again and only return -1 if no part of the instruction was able to be + displayed. + + Fixes: e43d8768d909 ("RISC-V: Fix disassemble fetch fail return + value.") + + Acked-By: Andrew Burgess + +2025-01-09 GDB Administrator + + Automatic date update in version.in + +2025-01-08 Tom Tromey + + Rename two Ada test suite functions + I happened to notice that the Ada compiler emitted a warning when + compiling a couple of DAP tests. This wasn't intentional, and this + patch renames the functions to match the filename. + +2025-01-08 Thiago Jung Bauermann + + GDB, gdbserver: Convert regcache_register_size function to method + The regcache_register_size function has one implementation in GDB, and + one in gdbserver. Both of them have a gdb::checked_static_cast to their + corresponding regcache class. This can be avoided by defining a + pure virtual register_size method in the + reg_buffer_common class, which is then implemented by the reg_buffer + class in GDB, and by the regcache class in gdbserver. + + Calls to the register_size () function from methods of classes in the + reg_buffer_common hierarchy need to be changed to calls to the newly + defined method, otherwise the compiler complains that a matching method + cannot be found. + + Co-Authored-By: Simon Marchi + Approved-By: Simon Marchi + Reviewed-By: Tankut Baris Aktemur + Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3 + +2025-01-08 Tom de Vries + + [gdb/testsuite] Check gnatmake version in gdb.ada/scalar_storage.exp + On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into: + ... + (gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE + get_compiler_info: gcc-14-2-0 + print V_BE^M + $2 = (value => 126, another_value => 12, color => red)^M + (gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE + ... + + The test-case contains a corresponding kfail: + ... + # This requires a compiler fix that is in GCC 14. + if {[gcc_major_version] < 14} { + setup_kfail "DW_AT_endianity on enum types" *-*-* + } + ... + which doesn't trigger because it checks the gcc version rather than the + gnatmake version. + + Fix this by checking the gnatmake version instead. + + Tested on aarch64-linux and x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Require can_spawn_for_attach in gdb.base/gstack.exp + I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope + set to 1 and ran into: + ... + PASS: gdb.base/gstack.exp: spawn gstack + ptrace: Operation not permitted.^M + GSTACK-END^M + PASS: gdb.base/gstack.exp: gstack exits with no error + PASS: gdb.base/gstack.exp: gstack's exit status is 0 + FAIL: gdb.base/gstack.exp: got backtrace + ... + + Fix this by requiring can_spawn_for_attach. + + Tested on x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Require supports_process_record in gdb.reverse/test_ioctl_TCSETSW.exp + I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got: + ... + (gdb) record full^M + Process record: the current architecture doesn't support record function.^M + (gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full + ... + + Fix this by requiring supports_process_record. + + Tested on riscv64-linux and x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp for !supports_catch_syscall + I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got: + ... + (gdb) catch syscall write^M + The feature 'catch syscall' is not supported on this architecture yet.^M + (gdb) FAIL: $exp: mode=syscall: catch syscall write + ... + + Fix this by checking for supports_catch_syscall. + + Tested on riscv64-linux and x86_64-linux. + +2025-01-08 Vladimir Mezentsev + + Fix 32085 Source file not recognized for gcc 11.4.0-compiled code + gprofng cannot read compressed section. + In the next release we plan to use libbfd everywhere instead of our ELF reader. + But in this release I use bfd_get_full_section_contents() only + when bfd_is_section_compressed() returns true. + + gprofng/ChangeLog + 2025-01-06 Vladimir Mezentsev + + PR gprofng/32085 + * src/Elf.cc: Use bfd_get_full_section_contents to decompress a section. + * src/Elf.h: Define SEC_DECOMPRESSED. + +2025-01-08 Liwei Xu + Haochen Jiang + + Support Intel AMX-FP8 + In this patch, we will support AMX-FP8 feature. Since in the + foreseeable future, only AMX-MOVRS will also use VEX_MAP5, we + currently will not add a table of 256 entries and handle just + like MAP7. + + gas/ChangeLog: + + * config/tc-i386.c: Add amx_fp8. + * doc/c-i386.texi: Document .amx_fp8. + * testsuite/gas/i386/x86-64.exp: Run AMX-FP8 tests. + * testsuite/gas/i386/x86-64-amx-fp8-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-fp8-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8.d: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0): New. + (X86_64_VEX_MAP5_FD): Ditto. + (VEX_LEN_MAP5_FD_X86_64): Ditto. + (VEX_W_MAP5_FD_X86_64_L_0):Ditto. + (prefix_table): Add PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0. + (x86_64_table): Add X86_64_VEX_MAP5_FD. + (vex_len_table): Add VEX_LEN_MAP5_FD_X86_64. + (vex_w_table): Add VEX_W_MAP5_FD_X86_64_L_0. + * i386-gen.c: Add CPU_AMX_FP8_FLAGS and + CPU_ANY_AMX_FP8_FLAGS. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h: Add cpuamx_fp8. + * i386-opc.tbl: Add AMX_FP8 instructions. + * i386-tbl.h: Regenerated. + +2025-01-08 Tom Tromey + + Rename two maint commands + This renames two maint commands, removing a hyphen from + "check-symtabs" and "check-psymtabs"; that is, moving them under the + existing "maint check" prefix. + + Regression tested on x86-64 Fedora 40. + + Reviewed-By: Tom de Vries + Approved-By: Andrew Burgess + Reviewed-By: Eli Zaretskii + +2025-01-08 GDB Administrator + + Automatic date update in version.in + +2025-01-07 Nick Clifton + + Updated Malay translation for the bfd sub-directory + +2025-01-07 Tom Tromey + + Fix crash in DWARF indexer + Iain pointed out a crash in the DWARF indexer when run on a certain D + program. The DWARF in this case has a nameless enum class; this + causes an assertion failure. + + This patch arranges to simply ignore such types. The fact that an + enum class is nameless in this case appears to be a compiler bug. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518 + Approved-By: Tom de Vries + +2025-01-07 Christina Schimpe + + testsuite: adapt to new --debug command line option + Since commit "gdbserver: allow the --debug command line option to take a + value", gdbserver no longer supports + --debug + --remote-debug + --event-loop-debug. + + Instead, --debug now takes a comma separated list of components. + + The make check parameter GDBSERVER_DEBUG doesn't support these changes + yet. This patch fixes this, by adding the --debug gdbserver arguments, + as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for + GDBSERVER_DEBUG. Replay logging is still enabled by adding the + "replay" GDBSERVER_DEBUG argument. We can also configure "all" to + enable all of the available options. + + Now, for instance, we can use it as follows: + + make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp" + + or simply + + make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp" + + to enable all debug options. + + Approved-By: Tom Tromey + +2025-01-07 Tom Tromey + + Clarify documentation of signal numbers + A user was confused by the meaning of signal numbers in the gdb CLI. + For instance, when using "signal 3", exactly which signal is + delivered? Is it always 3, or is it always SIGQUIT? + + This patch attempts to clarify the documentation here. + +2025-01-07 Clément Chigot + + ld/testsuite: move board flags to ld_link + Both CFLAGS and LDFLAGS provided by dejagnu board configuration could be + required to perform a link. + + Up to now, those flags were pulled with run_cc_link_tests and + run_ld_link_exec_tests and then passed to ld_link process as arguments. + This means that calling `ld_link` outside those functions must remember + to manually pass them. + +2025-01-07 Clément Chigot + + ld/testsuite/lto: replace manual links by ld_link helper + Some tests are calling run_host_cmd in order to retrieve the + errors/warnings messages generated. + ld_link is also making them available through exec_output global + variable but as the advantages of taking the board configuration into + account unlike run_host_cmd. + + ld/testsuite: centralize board_cflags and board_ldflags + Those flags are retrieving the CFLAGS or LDFLAGS defined by the dejagnu + board. The same pattern was repeated many times. + +2025-01-07 Alan Modra + + Remove dead code in bfd_check_format_matches + Commit cb001c0d283d made code added in 64bfc2584c01 dead. Remove it. + +2025-01-07 GDB Administrator + + Automatic date update in version.in + +2025-01-06 Tom de Vries + + [gdb/cli] Show LOC_CONST_BYTES var for info locals + PR cli/32525 reports that a variable with this DWARF: + .. + <2><423>: Abbrev Number: 14 (DW_TAG_variable) + <424> DW_AT_name : var1867 + <42a> DW_AT_type : <0x2f8> + <42e> DW_AT_const_value : 8 byte block: 0 0 0 0 0 0 0 0 + ... + is not shown by info locals. + + Fix this by handling LOC_CONST_BYTES in iterate_over_block_locals. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32525 + + Approved-By: Tom Tromey + +2025-01-06 Jan Beulich + + x86/APX: simplify ENQCMD[,S} opcode table entries + APX_F() makes sense to use only for dual VEX/EVEX templates; ENQCMD{,S} + are legacy encoded though in their original forms. Make the entries + match the MOVDIR{I,64B} sibling ones. + +2025-01-06 Rainer Orth + + Fix procfs.c compilation + procfs.c compilation is currently broken on Solaris: + + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’: + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2067 | wait_retval = gdb::wait (&wstat); + | ^~~~ + In file included from ../gnulib/import/sys/wait.h:28, + from /usr/include/stdlib.h:16, + from /usr/gcc/14/include/c++/14.2.0/cstdlib:79, + from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99, + from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26, + from : + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2154 | int temp = gdb::wait (&wstat); + | ^~~~ + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’: + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2566 | gdb::wait (NULL); + | ^~~~ + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + + The use of gdb::wait was introduced in + + commit 4e4dfc4728622d83c5d600949024449e21de868a + Author: Tom de Vries + Date: Fri Nov 22 17:44:29 2024 +0100 + + [gdb] Add gdb::wait + + but obviously never tested. + + Fixed by including gdbsupport/eintr.h to provide the declaration. + + Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. + +2025-01-06 Jan Beulich + + x86/Intel: don't accept memory operands with J*CXZ and LOOP* + PR gas/31887 + + Like for, in particular, J such should be rejected. Simplify the + respective conditional in i386_intel_operand(), leveraging that + JumpAbsolute will never occur in the first template of a mnemonic- + specific group (thus making it unnecessary to exclude that one case). + + At this occasion do the same simplification later in the function as + well: The resulting two operands will uniformly be invalid for all + mnemonics other than CALL and JMP (and their AT&T counterparts, which + we've been wrongly accepting in Intel syntax) anyway. + +2025-01-06 Jan Beulich + + gas: special-case division / modulo by ±1 + Dividing the largest possible negative value by -1 generally is UB, for + the result not being representable at least in commonly used binary + notation. This UB on x86, for example, is a Floating Point Exception on + Linux, i.e. resulting in an internal error (albeit only when + sizeof(valueT) == sizeof(void *); the library routine otherwise involved + apparently deals with the inputs quite okay). + + Leave original values unaltered for division by 1; this may matter down + the road, in case we start including X_unsigned and X_extrabit in + arithmetic. For the same reason treat modulo by 1 the same as modulo by + -1. + + The quad and octa tests have more relaxed expecations than intended, for + X_unsigned and X_extrabit not being taken into account [yet]. The upper + halves can wrongly end up as all ones (for .octa, when !BFD64, even the + upper three quarters). Yet it makes little sense to address this just + for div/mod by ±1. quad-div2 is yet more special, to cover for most + 32-bit targets being unable to deal with forward-ref expressions in + .quad even when BFD64; even ones being able to (like x86) then still + don't get the values right. + +2025-01-06 Tom Tromey + + Handle linesStartAt1 in DAP + The DAP initialize request has a "linesStartAt1" option, where the + client can indicate that it prefers whether line numbers be 0-based or + 1-based. + + This patch implements this. I audited all the line-related code in + the DAP implementation. + + Note that while a similar option exists for column numbers, gdb + doesn't handle these yet, so nothing is done here. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468 + +2025-01-06 Tom Tromey + + Don't lex floating-point number in Rust field expression + Consider this Rust tuple: + + let tuple_tuple = ((23i32, 24i32), 25i32); + + Here, the value is a tuple whose first element is also a tuple. + You should be able to print this with: + + (gdb) print tuple_tuple.0.1 + + However, currently the Rust lexer sees "0.1" as a floating-point + number. + + This patch fixes the problem by introducing a special case in the + lexer: when parsing a field expression, the parser informs the lexer + that a number should be handled as a decimal integer only. + + This change then lets us remove the decimal integer special case from + lex_number. + + v2: I realized that the other DECIMAL_INTEGER cases aren't needed any + more. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32472 + +2025-01-06 Tom Tromey + + Remove "then" from test suite + This removes the "then" keyword from the test suite. Andrew did this + once before, but some new ones crept in. + + This also adds braces to the "if" conditions and normalizes the + failures to just use "return". + +2025-01-06 Tom Tromey + + Simplify traits.h using C++17 + This patch simplifies gdbsupport/traits.h by reusing some C++17 type + traits. I kept the local names, since they are generally better. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31423 + Approved-By: Simon Marchi + +2025-01-06 Tom de Vries + + [gdb/build] Use const_cast in fd_copy + Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did: + ... + fd_copy (fd_set *dst, const fd_set *src, int n) + { + FD_ZERO (dst); + for (int i = 0; i < n; ++i) + - if (FD_ISSET (i, src)) + + if (FD_ISSET (i, (fd_set *)src)) + ... + but according to [1] only const_cast may be used to cast away constness. + + Fix this by using const_cast. + + Tested by rebuilding on x86_64-linux. + + [1] https://en.cppreference.com/w/cpp/language/const_cast + +2025-01-06 Alan Modra + + ar and foreign object files + ar is supposed to make archives containing any sort of file, and it + generally does that. It also tries to make archives suited to target + object files stored. Some targets have peculiar archives. + + In one particular case we get into trouble trying to suit archives to + object files: where the target object file is recognised but that + target doesn't happen to support archives, and the default target has + a special archive format. For example, we'll get failures on + rs6000-aix if trying to add tekhex objects to a new archive. What + happens in that the tekhex object is recognised and its target vector + used to create an empty archive, ie. with _bfd_generic_mkarchive and + _bfd_write_archive_contents. An attempt is then made to open the + newly created archive. The tekhex target vector does not have a + check_format function to recognise generic archives, nor as it happens + do any of the xcoff or other targets built for rs6000-aix. + + It seems to me the simplest fix is to not use any target vector to + create archives where that vector can't also recognise them. That's + what this patch does, and to reinforce that I've removed target vector + support for creating empty archives from such targets. + + bfd/ + * i386msdos.c (i386_msdos_vec): Remove support for creating + empty archives. + * ihex.c (ihex_vec): Likewise. + * srec.c (srec_vec, symbolsrec_vec): Likewise. + * tekhex.c (tekhex_vec): Likewise. + * wasm-module.c (wasm_vec): Likewise. + * ptrace-core.c (core_ptrace_vec): Tidy. + * targets.c (bfd_target_supports_archives): New inline function. + * bfd-in2.h: Regenerate. + binutils/ + * ar.c (open_inarch): Don't select a target from the first + object file that can't read archives. Set output_filename + earlier. + * testsuite/binutils-all/ar.exp (thin_archive_with_nested): + Don't repeat --thin test using T. + (foreign_object): New test. + * testsuite/binutils-all/tek1.obj, + * testsuite/binutils-all/tek2.obj: New files. + +2025-01-06 Xiao Zeng + + RISC-V: Eliminate redundant instruction macro + include/ChangeLog: + + * opcode/riscv.h: Eliminate redundant instruction macro M_j. + +2025-01-06 GDB Administrator + + Automatic date update in version.in + +2025-01-05 Tom Tromey + + Some small cleanups in add_symbol_overload_list_qualified + This applies some more cleanups to add_symbol_overload_list_qualified, + consolidating calls to get_selected_block. + + It also moves the symtab expansion call after the code that walks up + from the selected block, merging two loops. + +2025-01-05 Tom Tromey + + Fix latent bug in Ada import symbol handling + The code in dwarf2/read.c:new_symbol that handles Ada 'import' symbols + has a bug. It uses the current scope, which by default this is the + file scope -- even for a global symbol like: + + <1><1186>: Abbrev Number: 4 (DW_TAG_variable) + <1187> DW_AT_name : (indirect string, offset: 0x1ad2): pkg__imported_var_ada + ... + <1196> DW_AT_external : 1 + + This disagrees with the scope computed by the DWARF indexer. + + Now, IMO new_symbol and its various weirdness really has to go. And, + ideally, this information would come from the indexer rather than + perhaps being erroneously recomputed. But meanwhile, this patch fixes + the issue at hand. + + This came up while working on another change that exposes the bug. + + Reviewed-By: Tom de Vries + +2025-01-05 GDB Administrator + + Automatic date update in version.in + +2025-01-04 Tom de Vries + + [gdb/testsuite] Add gdb.python/py-commands-breakpoint.exp + A recent discussion about what commands are allowed during + gdb.Breakpoint.stop, made me wonder if there would be less restrictions if + we'd do those commands as part of a breakpoint command list instead. + + Attribute gdb.Breakpoint.commands is a string with gdb commands, so I + tried implementing a new class PyCommandsBreakpoint, derived from + gdb.Breakpoint, that supports a py_commands method. + + My original idea was to forbid setting PyCommandsBreakpoint.commands, and do: + ... + def py_commands(self): + print("VAR: %d" % self.var) + self.var += 1 + gdb.execute("continue") + ... + but as it turns out 'gdb.execute("continue")' does not behave the same way as + continue. I've filed PR python/32454 about this. + + So the unsatisfactory solution is to first execute + PyCommandsBreakpoint.py_commands: + ... + def py_commands(self): + print("VAR: %d" % self.var) + self.var += 1 + ... + and then: + ... + self.commands = "continue" + ... + + I was hoping for a better outcome, but having done the work of writing this, I + suppose it has use as a test-case, perhaps also as an example of how to work + around PR python/32454. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32454 + +2025-01-04 Tom de Vries + + [gdb/tdep] Fix gdb.base/finish-pretty.exp on s390x + On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into: + ... + (gdb) finish + Run till exit from #0 foo () at finish-pretty.c:28 + main () at finish-pretty.c:40 + 40 return v.a + v.b; + Value returned has type: struct s. Cannot determine contents + (gdb) FAIL: $exp: finish foo prettyprinted function result + ... + + The function being finished is foo, which returns a value of type struct s. + + The ABI [1] specifies: + - that the value is returned in a storage buffer allocated by the caller, and + - that the address of this buffer is passed as a hidden argument in r2. + + GDB fails to print the value when finishing foo, because it doesn't know the + address of the buffer. + + Implement the gdbarch_get_return_buf_addr hook for s390x to fix this. + + This is based on ppc_sysv_get_return_buf_addr, the only other implementation + of gdbarch_get_return_buf_addr. For readability I've factored out + dwarf_reg_on_entry. + + There is one difference with ppc_sysv_get_return_buf_addr: only + NO_ENTRY_VALUE_ERROR is caught. If this patch is approved, I intend to submit + a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well. + + The hook is not guaranteed to work, because it attempts to get the value r2 + had at function entry. + + The hook can be called after function entry, and the ABI doesn't guarantee + that r2 is the same throughout the function. + + Using -fvar-tracking adds debug information, which allows the hook to succeed + more often, and indeed after adding this to the test-case, it passes. + + Do likewise in one more test-case. + + Tested on s390x-linux. + + Fixes: + - gdb.ada/finish-large.exp + - gdb.base/finish-pretty.exp + - gdb.base/retval-large-struct.exp + - gdb.cp/non-trivial-retval.exp + - gdb.ada/array_return.exp + + AFAICT, I've also enabled the hook for s390 and from the ABI I get the + impression that it should work, but I haven't been able to test it. + + [1] https://github.com/IBM/s390x-abi + +2025-01-04 Eli Zaretskii + + [gdb/readline] Fix link error on MinGW due to missing 'alarm' + The previous solution used symbols that exist only in MinGW64. + Add a stub implementation of 'alarm' for mingw.org's MinGW. + +2025-01-04 Eli Zaretskii + + [gdb/selftest] Fix 'help_doc_invariants' self-test + Running selftest help_doc_invariants. + help doc broken invariant: command 'signal-event' help doc has over-long line + Self test failed: self-test failed at unittests/command-def-selftests.c:121 + + The reason is that doc string of 'signal-event' doesn't have + newlines at end of its line. Fix by adding newlines. + +2025-01-04 Eli Zaretskii + + [gdb] Fix compilation error in event-top.c + CXX event-top.o + In file included from d:\usr\include\winsock2.h:69, + from ./../gdbsupport/gdb_select.h:30, + from event-top.c:43: + event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)': + event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive] + 1279 | if (FD_ISSET (i, src)) + | ^ + | | + | const fd_set* + d:\usr\include\winsock.h:164:50: note: initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)' + 164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set ) + | ~~~~~~~~^~~~~ + + Use an explicit type cast to prevent this. + + * gdb/event-top.c (fd_copy): Type-cast in call to FD_ISSET. + +2025-01-04 Tom de Vries + + [gdb/cli] Warn about forced return from signal trampoline + The Linaro CI reported a regression on arm-linux in test-case + gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply + workaround for PR gas/31115 a bit more") [1]: + ... + (gdb) return^M + Make __default_sa_restorer return now? (y or n) n^M + Not confirmed^M + (gdb) FAIL: $exp: return from handleri: \ + leave signal trampoline (got interactive prompt) + ... + + After installing package glibc-debuginfo and adding --with-separate-debug-dir + to the configure flags, I managed to reproduce the FAIL. + + The regression seems to be a progression in the sense that the function name + for the signal trampoline is found. + + After reading up on the signal trampoline [2] and the return command [3], my + understanding is that forced returning from the signal trampoline is + potentially unsafe, given that for instance the process signal mask won't be + restored. + + Fix this by: + - rather than using the name, using "signal trampoline" in the query, and + - adding a warning about returning from a signal trampoline, + giving us: + ... + (gdb) return^M + warning: Returning from signal trampoline does not fully restore pre-signal \ + state, such as process signal mask.^M + Make signal trampoline return now? (y or n) y^M + 87 dummy = 0; dummy = 0; while (!done);^M + (gdb) PASS: $exp: return from handleri: leave signal trampoline (in main) + ... + + Tested on x86_64-linux. + + Reviewed-by: Thiago Jung Bauermann + + [1] https://linaro.atlassian.net/browse/GNU-1459 + [2] https://man7.org/linux/man-pages/man2/sigreturn.2.html + [3] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Returning.html + +2025-01-04 Alan Modra + + ELF sec_info memory leaks + Use the bfd's objalloc memory so we don't need to free anything + attached to elf_section_data sec_info. Other uses of sec_info that + need to allocate memory already use bfd_alloc. + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc sec_info. + * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. + +2025-01-04 Alan Modra + + _bfd_write_ar_hdr + This has been broken since commit 8f95b6e44955 in 2010, and apparently + nobody has noticed. How we write archive headers depends on the + archive, not the contents. + + * libbfd-in.h (_bfd_write_ar_hdr): Correct. + * libbfd.h: Regenerate. + +2025-01-04 Tom de Vries + + [gdb/testsuite] Skip stabs board in make-check-all.sh + I ran make-check-all.sh with gdb.linespec/explicit.exp, and the only problems + were found with target board stabs. + + With target board unix the test-case runs in two seconds, but with target + board stabs it takes 12 seconds due to a timeout. + + Stabs support in gdb has been unmaintained for a while, and there's an ongoing + discussion to deprecate and remove it (PR symtab/31210). + + It seems unnecessary to excercise this unmaintained feature in + make-check-all.sh, so drop it. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210 + +2025-01-04 Fangrui Song + + skip -gfile: call fnmatch without FNM_FILE_NAME + fnmatch is called with the FNM_FILE_NAME flag so that `skip -gfi /usr/*` + doesn't match /usr/include/*. This makes the file matching feature not + useful for STL headers that reside in multiple directories. In + addition, the user cannot use a single `*` to match multiple leading + path components. + + Let's drop the FNM_FILE_NAME flag and remove the assertion from + gdb_filename_fnmatch (originally for the auto-load feature). + +2025-01-04 Alan Modra + + bfd_set_input_error + My recent change to closing archives showed some problems with the way + we stash errors for archive elements. The most obvious thing found + by oss-fuzz, is that if output archive elements are closed during + bfd_close of an archive, then we can't access the element filename + when printing the element. So change bfd_set_input_error to stash the + entire error message instead of input bfd and input error. + + * bfd.c (input_bfd, input_error): Delete. + (bfd_error, _bfd_error_buf): Move. + (_bfd_clear_error_data): Move. Make static. Clear bfd_error too. + (bfd_set_input_error): Print the error use bfd_asprintf here.. + (bfd_errmsg): ..not here. + (bfd_init): Update. + * opncls.c (bfd_close_all_done): Don't call _bfd_clear_error_data. + * libbfd.h: Regenerate. + +2025-01-04 GDB Administrator + + Automatic date update in version.in + +2025-01-03 Alan Modra + + macro nesting testcases + Fix a bunch of regressions. Don't start anything besides a label in + first column, don't name macros the same as directives, and make + labels global. + +2025-01-03 GDB Administrator + + Automatic date update in version.in + +2025-01-02 Vladimir Mezentsev + + gprofng: remove the old archiver + The first versions of Performance Analyzer archived only function names. + This is no longer used. We need a real elf-file. + + gprofng/ChangeLog + 2025-01-01 Vladimir Mezentsev + + * src/LoadObject.cc: Remove LoadObject::read_archive. + * src/LoadObject.h: Likewise. + * src/data_pckts.h: Remove unused declarations. + * src/parse.cc (process_seg_map_cmd): Don't look for the old archive. + +2025-01-02 H.J. Lu + + nesting[123].d: Replace Sone with Some in comment + * testsuite/gas/macros/nesting1.d: Replace Sone with Some in + comment. + * testsuite/gas/macros/nesting2.d: Likewise. + * testsuite/gas/macros/nesting3.d: Likewise. + +2025-01-02 H.J. Lu + + gas: Revert PR 32391 related commits to fix 3 regressions + 9f2e3c21f65 Fix the handling or arguments and macro pseudo-variables inside nested assembler macros. + + introduced 3 regressions of PR gas/32484, PR gas/32486 and PR gas/32487. + Revert all PR 32391 related commits and add tests for PR gas/32484, + PR gas/32486, PR gas/32487. + + PR gas/32484 + PR gas/32486 + PR gas/32487 + * testsuite/gas/macros/macros.exp: Run nesting1, nesting2 and + nesting3. + * testsuite/gas/macros/nesting1.d: New file. + * testsuite/gas/macros/nesting1.s: Likewise. + * testsuite/gas/macros/nesting2.d: Likewise. + * testsuite/gas/macros/nesting2.s: Likewise. + * testsuite/gas/macros/nesting3.d: Likewise. + * testsuite/gas/macros/nesting3.s: Likewise. + +2025-01-02 Haochen Jiang + + Support Intel AMX-TF32 + In this patch, we will support AMX-TF32. It is a simple ISA + comparing to the previous ones, so there is no special handling. + + gas/ChangeLog: + + * config/tc-i386.c: Add amx_tf32. + * doc/c-i386.texi: Document .amx_tf32. + * testsuite/gas/i386/x86-64.exp: Run AMX-TF32 tests. + * testsuite/gas/i386/x86-64-amx-tf32-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-tf32-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32.d: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (PREFIX_VEX_0F3848_X86_64_W_0_L_0): New. + (X86_64_VEX_0F3848): Ditto. + (VEX_LEN_0F3848_X86_64_W_0): Ditto. + (VEX_W_0F3848_X86_64): Ditto. + (prefix_table): Add PREFIX_VEX_0F3848_X86_64_W_0_L_0. + (x86_64_table): Add X86_64_VEX_0F3848. + (vex_len_table): Add VEX_LEN_0F3848_X86_64_W_0. + (vex_w_table): Add VEX_W_0F3848_X86_64. + * i386-gen.c (isa_dependencies): Add AMX_TF32. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_TF32): New. + (i386_cpu_flags): Add cpuamx_tf32. + * i386-opc.tbl: Add AMX-TF32 instructions. + * i386-tbl.h: Regenerated. + +2025-01-02 Haochen Jiang + Hu, Lin1 + + Support Intel AMX-TRANSPOSE + In this patch, we will support AMX-TRANSPOSE. Since AMX-TRANSPOSE + will be used with other CPUIDs very often, we put it into + CPU_FLAGS_COMMON. + + To implement TMM pair, we reused ImplicitGroup and adjust the condition + in process_operands for the instructions. + + APX_F extension is also handled in this patch, where it extends + T2RPNTLVW[Z0,Z1][,T1] to EVEX.128.NP/66.0F38.W0 6E/6F !(11):rrr:100 + with NF=0. + + Also, TTDPFP16PS should base on AMX_FP16, not AMX_BF16 in ISE055. + It would be fixed in ISE056. + + gas/ChangeLog: + + * config/tc-i386.c (cpu_arch): Add amx_transpose. + (_is_cpu): Ditto. + (process_operands): Adjust the condition for AMX-TRANSPOSE. + * doc/c-i386.texi: Document .amx_transpose. + * testsuite/gas/i386/x86-64.exp: Run AMX-TRANSPOSE tests. + * testsuite/gas/i386/x86-64-amx-transpose-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-transpose-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose.d: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (MOD_VEX_0F386E_X86_64_W_0): New. + (MOD_VEX_0F386F_X86_64_W_0): Ditto. + (PREFIX_VEX_0F385F_X86_64_W_0_L_0): Ditto. + (PREFIX_VEX_0F386B_X86_64_W_0_L_0): Ditto. + (PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0): Ditto. + (PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0): Ditto. + (X86_64_VEX_0F385F): Ditto. + (X86_64_VEX_0F386B): Ditto. + (X86_64_VEX_0F386E): Ditto. + (X86_64_VEX_0F386F): Ditto. + (VEX_LEN_0F385F_X86_64_W_0): Ditto. + (VEX_LEN_0F386B_X86_64_W_0): Ditto. + (VEX_LEN_0F386E_X86_64_W_0_M_0): Ditto. + (VEX_LEN_0F386F_X86_64_W_0_M_0): Ditto. + (VEX_W_0F385F_X86_64): Ditto. + (VEX_W_0F386B_X86_64): Ditto. + (VEX_W_0F386E_X86_64): Ditto. + (VEX_W_0F386F_X86_64): Ditto. + (mod_table): Add MOD_VEX_0F386E_X86_64_W_0, + MOD_VEX_0F386F_X86_64_W_0. + (prefix_table): Add PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0, + PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0. + Add new instructions for PREFIX_VEX_0F386C_X86_64_W_0_L_0. + (x86_64_table): Add X86_64_VEX_0F385F, X86_64_VEX_0F386B, + X86_64_VEX_0F386E, X86_64_VEX_0F386F. + (vex_len_table): Add VEX_LEN_0F385F_X86_64_W_0, + VEX_LEN_0F386B_X86_64_W_0, VEX_LEN_0F386E_X86_64_W_0_M_0, + VEX_LEN_0F386F_X86_64_W_0_M_0. + (vex_w_table): Add VEX_W_0F385F_X86_64, VEX_W_0F386B_X86_64, + VEX_W_0F386E_X86_64, VEX_W_0F386F_X86_64. + * i386-gen.c (cpu_flag_init): Add AMX_TRANSPOSE. + (cpu_flags): Add CpuAMX_TRANSPOSE. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_TRANSPOSE): New. + (i386_cpu): Add cpuamx_transpose. + * i386-opc.tbl: Add AMX-TRANSPOSE instructions. + * i386-tbl.h: Regenerated. + +2025-01-02 GDB Administrator + + Automatic date update in version.in + +2025-01-01 Alan Modra + + readelf memory leaks + This fixes multiple readelf memory leaks: + - The check functions used to validate separate debug info files + opened and read file data but didn't release the memory nor close + the file. + - A string table was being re-read into a buffer, leaking the old + contents. + - Decompressed section contents leaked. + + * dwarf.c (check_gnu_debuglink): Always call close_debug_file. + (check_gnu_debugaltlink): Likewise. + * readelf.c (process_section_headers): Don't read string_table + again if we already have it. + (maybe_expand_or_relocate_section): Add decomp_buf param to + return new uncompressed buffer. + (dump_section_as_strings, filedata->string_table): Free any + uncompressed buffer. + (process_file): Call close_debug_file rather than freeing + various filedata components. + +2025-01-01 Alan Modra + + objdump sym memory leak + The sym array should be freed even with a symcount of zero. + + * objdump.c (dump_bfd): Free syms before replacing with + extra_syms. Free extra_syms after adding to syms. + +2025-01-01 Alan Modra + + gnu_debuglink related memory leak + * opncls.c (bfd_fill_in_gnu_debuglink_section): Free section + contents on success too. + +2025-01-01 Alan Modra + + Close elements of output archive + When cleaning up an archive, close all its elements. This fixes a + number of ar memory leaks. + + bfd/ + * archive.c (_bfd_archive_close_and_cleanup): Close elements + of an archive open for writing. + binutils/ + * objcopy.c (copy_archive): Don't close output archive + elements here. + * dlltool.c (gen_lib_file): Likewise. + ld/ + * pe-dll.c (pe_dll_generate_implib): Don't close output + archive elements here. + +2025-01-01 Alan Modra + + ar.c memory leak fixme + Cure the leak by always mallocing the string in output_filename, + and freeing the old one any time we assign output_filename. + +2025-01-01 Alan Modra + + bfdtest1 loop check + Add a check that next_archived_file doesn't return the same element. + Seen with the following, which I think shows a bug with "ar r" and + thin archives as you get two copies of artest.a in artest2.a. + + $ rm tmpdir/artest* + $ ./ar rc tmpdir/artest.a tmpdir/bintest.o + $ ./ar rcT tmpdir/artest2.a tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest2.a + $ ./ar rcT tmpdir/artest2.a tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest2.a + oops: next_archived_file + +2025-01-01 Alan Modra + + thin archive with nested archive memory leak + The only reason to keep new_areldata around was for access to the + filename, but we now always take a copy in alloc'd memory. + + * archive.c (_bfd_get_elt_at_filepos): Free new_areldata when + it is not attached to bfd. + +2025-01-01 Alan Modra + + memory leak in gas dwarf2dbg.c + Found when running the pr27355 testcase. + + PR 27355 + PR 27426 + * dwarf2dbg.c (allocate_filename_to_slot): Update dirs_in_use. + +2025-01-01 Alan Modra + + gas obj-elf.c memory leaks + * config/obj-elf.c (obj_elf_section): Use notes_memdup for + linked_to_symbol_name. + (obj_elf_find_and_add_versioned_name): Use notes_alloc for + versioned_name. + + PR 32391 memory leak + * macro.c (sub_actual): Free newadd. + +2025-01-01 Alan Modra + + gas reloc_list memory leaks + Put these on the notes obstack too. + + * config/tc-wasm32.c (wasm32_leb128): Use notes_alloc for + reloc_list vars. + * read.c (s_reloc): Likewise. + * write.c (create_note_reloc): Likewise. + (write_object_file): Reset reloc_list after write_relocs. + +2025-01-01 Alan Modra + + gas tc_gen_reloc memory leaks + This makes all the tc_gen_reloc functions and the associated array in + write.c:write_relocs use notes_alloc rather than malloc. tc-hppa.c + tc_gen_reloc gets a few more changes, deleting some dead code, and + tidying code that duplicates prior initialisation. + +2025-01-01 Alan Modra + + gas gen-sframe memory leaks + More freeing required. + + * gen-sframe.c (all_sframe_fdes, last_sframe_fde): Move earlier, + make file scope. + (sframe_row_entry_new): Move earlier. + (sframe_row_entry_free): New function. + (sframe_fde_alloc, sframe_fde_free): Move earlier. + (sframe_fde_link): Delete. Expand into.. + (create_sframe_all): ..here. + (output_sframe_internal): Delete silly sframe_flags init. + Free fdes. Reset static vars. + (sframe_xlate_ctx_cleanup): Use sframe_row_entry_free. Free + remember_fre too. Don't re-init xlate_ctx we're about to drop. + * gen-sframe.h (all_sframe_fdes): Don't declare. + +2025-01-01 Alan Modra + + gas dw2gencfi memory leaks + Some of these could have remained as malloc'd memory, but that would + require quite a bit of code to traverse frch_cfi_data for example, and + would rely on matching cfi directives (ie. valid input). Just put + them on the notes obstack instead. + + * dw2gencfi.c (alloc_fde_entry): Use notes_calloc. + (alloc_cfi_insn_data): Likewise. + (cfi_end_fde): Don't free frch_cfi_data. + (cfi_add_label): Use notes_strdup. + (cfi_add_CFA_remember_state): Use notes_alloc. + (cfi_add_CFA_restore_state): Don't free. + (dot_cfi_escape): Use notes_alloc. + (cfi_finish): Free cies after each pass, not before. Clear + out static vars too. + +2025-01-01 Alan Modra + + gas include_dirs memory leak + This is the first of a series of patches aimed at making it possible + to configure with CFLAGS="-g -O2 -fsanitize=address,undefined" and run + the binutils and gas testsuite on x86_64-linux without using + ASAN_OPTIONS=detect_leaks=0. ie. the patch series is aimed at fixing + common gas, ar, objcopy, objdump, and readelf leaks. + + * config/tc-tic54x.c (md_begin): Make use of notes_strdup rather + than xstrdup to copy entries added to include_dirs. + * read.c (read_end): Free include_dirs array. + +2025-01-01 Alan Modra + + gas totalfrags + Avoid any possibility of signed overflow. (Seen on oss-fuzz). + + * frags.c (totalfrags): Make unsigned. + (get_frag_count): Return unsigned. + * frags.h (get_frag_count): Likewise. + +2025-01-01 Alan Modra + + PR 32507, PRIx64 in error messages on 32-bit mingw + People, including me, had forgotten that the bfd_error_handler just + handled standard printf format strings, not MSC %I64 and suchlike. + Using PRIx64 and similar in errors does not work if the host compiler + headers define those formats as the Microsoft %I64 variety. (We + handled %ll OK, editing it to %I64 on such hosts.) + + PR 32507 + * bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32 + in input strings if the host defines PRId64 as "I64d". + Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on + a preprocessor define. + +2025-01-01 Alan Modra + + Regen gprofng after copyright update + + Update year range in copyright notice of binutils files + +2025-01-01 GDB Administrator + + Automatic date update in version.in + +2024-12-31 Tom Tromey + + Use 'flags' when expanding symtabs in gdbpy_lookup_static_symbols + This changes gdbpy_lookup_static_symbols to pass the 'flags' parameter + to expand_symtabs_matching. This should refine the search somewhat. + Note this is "just" a performance improvement, as the loop over + symtabs already checks 'flags'. + + v2 also removes 'SEARCH_GLOBAL_BLOCK' and updates py-symbol.exp to + verify that this works properly. Thanks to Tom for this insight. + + Co-Authored-By: Tom de Vries + +2024-12-31 GDB Administrator + + Automatic date update in version.in + +2024-12-30 GDB Administrator + + Automatic date update in version.in + +2024-12-29 Joel Brobecker + + Update gdb/NEWS after GDB 16 branch creation. + This commit a new section for the next release branch, and renames + the section of the current branch, now that it has been cut. + +2024-12-29 Joel Brobecker + + Bump version to 17.0.50.DATE-git. + Now that the GDB 16 branch has been created, + this commit bumps the version number in gdb/version.in to + 17.0.50.DATE-git + + For the record, the GDB 16 branch was created + from commit ee29a3c4ac7adc928ae6ed1fed3b59c940a519a4. + + Also, as a result of the version bump, the following changes + have been made in gdb/testsuite: + + * gdb.base/default.exp: Change $_gdb_major to 17. + +2024-12-29 GDB Administrator + + Automatic date update in version.in + +2024-12-28 GDB Administrator + + Automatic date update in version.in + +2024-12-27 Jan Beulich + + bfd/ELF: refine segment index in filepos assignment diag + Reporting an internal loop index isn't helpful for the user to determine + which segment the problem is with. Report the PHDR index instead. + + ld/testsuite: replace aarch64 uses of load_lib + Using $srcdir/$subdir directly doesn't work, at least not with expect + 5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter + aspect which is crucial here). Make use of load_file instead. + +2024-12-27 Xi Ruoyao + + LoongArch: Reword message for unresolvable relocs + For PDE, "recompiling with -fPIE" just makes no sense. + + For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute + relocs, but not unresolveable PC-relative relocs: if the reloc is + already PC-relative, the problem is not the reloc is PC-relative or + absolute, but the reloc is not applicable for external symbols. + + If we hit an unresolvable reloc in PDE or an unresolvable PC-relative + reloc in PIE, it means the programmer has somehow wrongly instructed the + compiler to treat external symbols as local symbols. A misuse of + -mdirect-extern-access can cause the issue, so we can suggest + -mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching + symbol visibility can also cause the issue, so we should also suggest to + check the visibility. + +2024-12-27 Xi Ruoyao + + LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE + In a static PIE, undefined weak symbols should be just resolved to + runtime address 0, like those symbols with non-default visibility. This + was silently broken in all prior Binutils releases with "-static-pie + -mdirect-extern-access": + + $ cat t.c + int x (void) __attribute__ ((weak)); + + int + main (void) + { + __builtin_printf("%p\n", x); + } + $ gcc t.c -static-pie -mdirect-extern-access + $ ./a.out + 0x7ffff1d64000 + + Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for + shared libraries), the situation has been improved: the linker errors + out instead of silently producing a wrong output file. + + But logically, using -mdirect-extern-access for a static PIE perfectly + makes sense, and we should not prevent that even if the programmer uses + weak symbols. Linux kernel is such an example, and Linux < 6.10 now + fails to build with Binutils trunk. (The silent breakage with prior + Binutils releases was "benign" due to some blind luck.) + + While since the 6.10 release Linux has removed those potentially + undefined weak symbols (due to performance issue), we still should + support weak symbols in -mdirect-extern-access -static-pie and unbreak + building old kernels. + + Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/ + +2024-12-27 Xi Ruoyao + + LoongArch: Fix resolution of undefined weak hidden/protected symbols + An undefined weak hidden/protect symbol should be resolved to runtime + address 0, but we were actually resolving it to link-time address 0. So + in PIE or DSO the runtime address would be incorrect. + + Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w. + The latter does not always work because the immediate field of addi.w is + narrower, report an error in the case the addend is too large. + +2024-12-27 GDB Administrator + + Automatic date update in version.in + +2024-12-26 GDB Administrator + + Automatic date update in version.in + +2024-12-25 Alan Modra + + macro.c:871 heap-buffer-overflow + PR 32391 commit 9f2e3c21f6 fallout again. Also fix another 'macro' + may be used uninitialized. + +2024-12-25 Alan Modra + + buffer overflow in gas/app.c + This testcase: + .irp x x x " + .end # + .endr + manages to access lex[EOF]. + + xxx: Warning: end of file in string; '"' inserted + xxx:1: Warning: missing closing `"' + gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256] + Following that there is a buffer overflow. + + Stop this happening, and in other similar places, by checking for EOF. + +2024-12-25 GDB Administrator + + Automatic date update in version.in + +2024-12-24 Andrew Burgess + + gdb/testsuite: add some xfail in gdb.base/startup-with-shell.exp + There are two tests that fail in gdb.base/startup-with-shell.exp when + using the native-extended-remote board. I plan to fix these issues, + and I've posted a series that does just that: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + But until that series is reviewed, I thought I'd merge this commit, + which marks the FAIL as XFAIL and links them to the relevant bug + number. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + +2024-12-24 Andrew Burgess + + gdb/freebsd: port core file context parsing to FreeBSD + This commit implements the gdbarch_core_parse_exec_context method for + FreeBSD. + + This is much simpler than for Linux. On FreeBSD, at least the + version (13.x) that I have installer, there are additional entries in + the auxv vector that point directly to the argument and environment + vectors, this makes it trivial to find this information. + + If these extra auxv entries are not available on earlier FreeBSD, then + that's fine. The fallback behaviour will be for GDB to act as it + always has up to this point, you'll just not get the extra + functionality. + + Other differences compared to Linux are that FreeBSD has + AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is + the full path to the executable. On Linux AT_EXECFN is the command + the user typed, so this can be a relative path. + + This difference is handy as on FreeBSD we don't parse the mapped files + from the core file (are they even available?). So having the EXECPATH + means we can use that as the absolute path to the executable. + + However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be + the absolute path to the symlink, not to the underlying file. This is + probably a good thing, but it does mean there is one case we test on + Linux that fails on FreeBSD. + + On Linux if we create a symlink to an executable, then run the symlink + and generate a corefile. Now delete the symlink and load the core + file. On Linux GDB will still find (and open) the original + executable. This is because we use the mapped file information to + find the absolute path to the executable, and the mapped file + information only stores the real file names, not symlink names. + + This is a total edge case, I only added the deleted symlink test + originally because I could see that this would work on Linux. Though + it is neat that Linux finds this, I don't feel too bad that this fails + on FreeBSD. + + Other than this, everything seems to work on x86-64 FreeBSD (13.4) + which is all I have setup right now. I don't see why other + architectures wouldn't work too, but I haven't tested them. + +2024-12-24 Andrew Burgess + + gdb: improve GDB's ability to auto-load the exec for a core file + GDB already has a limited mechanism for auto-loading the executable + corresponding to a core file, this can be found in the function + locate_exec_from_corefile_build_id in corelow.c. + + However, this approach uses the build-id of the core file to look in + either the debug directory (for a symlink back to the executable) or + by asking debuginfod. This is great, and works fine if the core file + is a "system" binary, but often, when I'm debugging a core file, it's + part of my development cycle, so there's no build-id symlink in the + debug directory, and debuginfod doesn't know about the binary either, + so GDB can't auto load the executable.... + + ... but the executable is right there! + + This commit builds on the earlier commits in this series to make GDB + smarter. + + On GNU/Linux, when we parse the execution context from the core + file (see linux-tdep.c), we already grab the command pointed to by + AT_EXECFN. If this is an absolute path then GDB can use this to + locate the executable, a build-id check ensures we've found the + correct file. With this small change GDB suddenly becomes a lot + better at auto-loading the executable for a core file. + + But we can do better! Often the AT_EXECFN is not an absolute path. + + If it is a relative path then we check for this path relative to the + core file. This helps if a user does something like: + + $ ./build/bin/some_prog + Aborted (core dumped) + $ gdb -c corefile + + In this case the core file in the current directory will have an + AT_EXECFN value of './build/bin/some_prog', so if we look for that + path relative to the location of the core file this might result in a + hit, again, a build-id check ensures we found the right file. + + But we can do better still! What if the user moves the core file? Or + the user is using some tool to manage core files (e.g. the systemd + core file management tool), and the user downloads the core file to a + location from which the relative path no longer works? + + Well in this case we can make use of the core file's mapped file + information (the NT_FILE note). The executable will be included in + the mapped file list, and the path within the mapped file list will be + an absolute path. We can search for mapped file information based on + an address within the mapped file, and the auxv vector happens to + include an AT_ENTRY value, which is the entry address in the main + executable. If we look up the mapped file containing this address + we'll have the absolute path to the main executable, a build-id check + ensures this really is the file we're looking for. + + It might be tempting to jump straight to the third approach, however, + there is one small downside to the third approach: if the executable + is a symlink then the AT_EXECFN string will be the name of the + symlink, that is, the thing the user asked to run. The mapped file + entry will be the name of the actual file, i.e. the symlink target. + When we auto-load the executable based on the third approach, the file + loaded might have a different name to that which the user expects, + though the build-id check (almost) guarantees that we've loaded the + correct binary. + + But there's one more thing we can check for! + + If the user has placed the core file and the executable into a + directory together, for example, as might happen with a bug report, + then neither the absolute path check, nor the relative patch check + will find the executable. So GDB will also look for a file with the + right name in the same directory as the core file. Again, a build-id + check is performed to ensure we find the correct file. + + Of course, it's still possible that GDB is unable to find the + executable using any of these approaches. In this case, nothing + changes, GDB will check in the debug info directory for a build-id + based link back to the executable, and if that fails, GDB will ask + debuginfod for the executable. If this all fails, then, as usual, the + user is able to load the correct executable with the 'file' command, + but hopefully, this should be needed far less from now on. + +2024-12-24 Andrew Burgess + + gdb/testsuite: make some of the core file / build-id tests harder + We have a few tests that load core files, which depend on GDB not + auto-loading the executable that matches the core file. One of these + tests (corefile-buildid.exp) exercises GDB's ability to load the + executable via the build-id links in the debug directory, while the + other two tests are just written assuming that GDB hasn't auto-loaded + the executable. + + In the next commit, GDB is going to get better at finding the + executable for a core file, and as a consequence these tests could + start to fail if the testsuite is being run using a compiler that adds + build-ids by default, and is on a target (currently only Linux) with + the improved executable auto-loading. + + To avoid these test failures, this commit updates some of the tests. + + coredump-filter.exp and corefile.exp are updated to unload the + executable should it be auto-loaded. This means that the following + output from GDB will match the expected patterns. If the executable + wasn't auto-loaded then the new step to unload is harmless. + + The corefile-buildid.exp test needed some more significant changes. + For this test it is important that the executable be moved aside so + that GDB can't locate it, but we do still need the executable around + somewhere, so that the debug directory can link to it. The point of + the test is that the executable _should_ be auto-loaded, but using the + debug directory, not using GDB's context parsing logic. + + While looking at this test I noticed two additional problems, first we + were creating the core file more times than we needed. We only need + to create one core file for each test binary (total two), while we + previously created one core file for each style of debug info + directory (total four). The extra core files should be identical, and + were just overwriting each other, harmless, but still pointless work. + + The other problem is that after running an earlier test we modified + the test binary in order to run a later test. This means it's not + possible to manually re-run the first test as the binary for that test + is destroyed. + + As part of the rewrite in this commit I've addressed these issues. + + This test does change many of the test names, but there should be no + real changes in what is being tested after this commit. However, when + the next commit is added, and GDB gets better at auto-loading the + executable for a core file, these tests should still be testing what + is expected. + +2024-12-24 Andrew Burgess + + gdb: parse and set the inferior environment from core files + Extend the core file context parsing mechanism added in the previous + commit to also store the environment parsed from the core file. + + This environment can then be injected into the inferior object. + + The benefit of this is that when examining a core file in GDB, the + 'show environment' command will now show the environment extracted + from a core file. + + Consider this example: + + $ env -i GDB_TEST_VAR=FOO ./gen-core + Segmentation fault (core dumped) + $ gdb -c ./core.1669829 + ... + [New LWP 1669829] + Core was generated by `./gen-core'. + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x0000000000401111 in ?? () + (gdb) show environment + GDB_TEST_VAR=foo + (gdb) + + There's a new test for this functionality. + +2024-12-24 Andrew Burgess + + gdb: add gdbarch method to get execution context from core file + Add a new gdbarch method which can read the execution context from a + core file. An execution context, for this commit, means the filename + of the executable used to generate the core file and the arguments + passed to the executable. + + In later commits this will be extended further to include the + environment in which the executable was run, but this commit is + already pretty big, so I've split that part out into a later commit. + + Initially this new gdbarch method is only implemented for Linux + targets, but a later commit will add FreeBSD support too. + + Currently when GDB opens a core file, GDB reports the command and + arguments used to generate the core file. For example: + + (gdb) core-file ./core.521524 + [New LWP 521524] + Core was generated by `./gen-core abc def'. + + However, this information comes from the psinfo structure in the core + file, and this struct only allows 80 characters for the command and + arguments combined. If the command and arguments exceed this then + they are truncated. + + Additionally, neither the executable nor the arguments are quoted in + the psinfo structure, so if, for example, the executable was named + 'aaa bbb' (i.e. contains white space) and was run with the arguments + 'ccc' and 'ddd', then when this core file was opened by GDB we'd see: + + (gdb) core-file ./core.521524 + [New LWP 521524] + Core was generated by `./aaa bbb ccc ddd'. + + It is impossible to know if 'bbb' is part of the executable filename, + or another argument. + + However, the kernel places the executable command onto the user stack, + this is pointed to by the AT_EXECFN entry in the auxv vector. + Additionally, the inferior arguments are all available on the user + stack. The new gdbarch method added in this commit extracts this + information from the user stack and allows GDB to access it. + + The information on the stack is writable by the user, so a user + application can start up, edit the arguments, override the AT_EXECFN + string, and then dump core. In this case GDB will report incorrect + information, however, it is worth noting that the psinfo structure is + also filled (by the kernel) by just copying information from the user + stack, so, if the user edits the on stack arguments, the values + reported in psinfo will change, so the new approach is no worse than + what we currently have. + + The benefit of this approach is that GDB gets to report the full + executable name and all the arguments without the 80 character limit, + and GDB is aware which parts are the executable name, and which parts + are arguments, so we can, for example, style the executable name. + + Another benefit is that, now we know all the arguments, we can poke + these into the inferior object. This means that after loading a core + file a user can 'show args' to see the arguments used. A user could + even transition from core file debugging to live inferior debugging + using, e.g. 'run', and GDB would restart the inferior with the correct + arguments. + + Now the downside: finding the AT_EXECFN string is easy, the auxv entry + points directly too it. However, finding the arguments is a little + trickier. There's currently no easy way to get a direct pointer to + the arguments. Instead, I've got a heuristic which I believe should + find the arguments in most cases. The algorithm is laid out in + linux-tdep.c, I'll not repeat it here, but it's basically a search of + the user stack, starting from AT_EXECFN. + + If the new heuristic fails then GDB just falls back to the old + approach, asking bfd to read the psinfo structure for us, which gives + the old 80 character limited answer. + + For testing, I've run this series on (all GNU/Linux) x86-64. s390, + ppc64le, and the new test passes in each case. I've done some very + basic testing on ARM which does things a little different than the + other architectures mentioned, see ARM specific notes in + linux_corefile_parse_exec_context_1 for details. + +2024-12-24 Alan Modra + + arc: add_to_decodelist + Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three + entries to decodelist for each instruction disassembled. That can + waste a lot of cpu when the list grows large. What's more, + decodelist is static and nothing clears the list. So the list + persists from one file to the next if objdump is disassembling + multiple files in one invocation. Wrong disassembly might result. + + To fix this problem, I've moved decodelist to the arc private_data and + made it an array. I believe that init_disassemble_data will be + called, clearing private_data, for each file disassembled. That's + certainly true for objdump, and if I can see my way around gdb + constructors, it's also true for gdb. I don't think there is a + possibility of info.disassembler_options changing unless there is + first a call to init_disassebled_data. That means all of the option + parsing and bfd mach and e_flags decoding need only be done when + initialising the arc private_data. + + * arc-dis.c (addrtypenames_max, addrtypeunknown): Delete.. + (get_addrtype): ..substitute values here. Tidy. + (skipclass_t, linkclass, decodelist): Delete. + (enforced_isa_mask, print_hex): Delete. + (struct arc_disassemble_info): Add decode[], decode_count, + isa_mask, print_hex. + (init_arc_disasm_info): Tidy. + (add_to_decodelist): Delete, replacing with.. + (add_to_decode): ..this. Don't duplicate entries. + (skip_this_opcode): Adjust to suit. + (find_format_from_table, parse_option): Likewise. + (parse_disassembler_options): Likewise. Move code dealing + with bfd mach and eflags from.. + (print_insn_arc): ..here. Adjust for other changes. + +2024-12-24 Alan Modra + + PR 32324, Stripping BOLT'ed binaries leads to unwanted behaviour + This patch corrects layout for a PT_LOAD header that doesn't include + the ELF file header but does contain PHDRs and sections requiring + alignment. The required alignment (which was missing) is placed + before the PHDRs. + +2024-12-24 Alan Modra + + PR 32391 testcase + The new testcase results in these regressions: + hppa64-hp-hpux11.23 +FAIL: Nested macros (PR 32391) + hppa-hp-hpux10 +FAIL: Nested macros (PR 32391) + i386-darwin +FAIL: Nested macros (PR 32391) + + Fix the hppa regressions by ensuring that only symbols start on the + first column. + +2024-12-24 Alan Modra + + Fix error: macro may be used uninitialized + PR 32391 commit 9f2e3c21f6 fallout + +2024-12-24 GDB Administrator + + Automatic date update in version.in + +2024-12-23 Haochen Jiang + Jun Zhang + Zewei Mo + + Support Intel AVX10.2 minmax, vector copy and compare instructions + In this patch, we will support AVX10.2 minmax, vector copy and compare + instructions. This will finish the new instruction form support for + AVX10.2. Most of them are new instructions forms except for vmovd + and vmovw, which are extended usage from the old ones. + + gas/ChangeLog: + + * NEWS: Mention AVX10.2. + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-5-intel.d: New test. + * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h: Add EVEX_LEN_0F7E_P_1_W_1, + EVEX_LEN_0FD6_P_2_W_0, EVEX_LEN_MAP5_6E and EVEX_LEN_MAP5_7E. + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F2E, PREFIX_EVEX_0F2F, + PREFIX_EVEX_0F3A52, PREFIX_EVEX_0F3A53, PREFIX_EVEX_MAP5_2E, + PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_6E and PREFIX_EVEX_MAP5_7E. + * i386-dis-evex-w.h: Adjust EVEX_W_0F3A42, EVEX_W_0F7E_P_1 + and EVEX_W_0FD6. Add EVEX_W_MAP5_6E_P_1 and EVEX_W_MAP5_7E_P_1. + * i386-dis-evex.h: Add and adjust table entries for AVX10.2. + * i386-dis.c (PREFIX_EVEX_0F2E): New. + (PREFIX_EVEX_0F2F): Ditto. + (PREFIX_EVEX_0F3A52): Ditto. + (PREFIX_EVEX_0F3A53): Ditto. + (PREFIX_EVEX_MAP5_2E): Ditto. + (PREFIX_EVEX_MAP5_2F): Ditto. + (PREFIX_EVEX_MAP5_6E_L_0): Ditto. + (PREFIX_EVEX_MAP5_7E_L_0): Ditto. + (EVEX_LEN_0F7E_P_1_W_1): Ditto. + (EVEX_LEN_0FD6_P_2_W_0): Ditto. + (EVEX_LEN_MAP5_6E): Ditto. + (EVEX_LEN_MAP5_7E): Ditto. + (EVEX_W_MAP5_6E_P_1): Ditto. + (EVEX_W_MAP5_7E_P_1): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-23 GDB Administrator + + Automatic date update in version.in + +2024-12-22 Carlos Galvez + + Fix -Wenum-constexpr-conversion in enum-flags.h + This fixes PR 31331: + https://sourceware.org/bugzilla/show_bug.cgi?id=31331 + + Currently, enum-flags.h is suppressing the warning + -Wenum-constexpr-conversion coming from recent versions of Clang. + This warning is intended to be made a compiler error + (non-downgradeable) in future versions of Clang: + + https://github.com/llvm/llvm-project/issues/59036 + + The rationale is that casting a value of an integral type into an + enumeration is Undefined Behavior if the value does not fit in the + range of values of the enum: + https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 + + Undefined Behavior is not allowed in constant expressions, leading to + an ill-formed program. + + In this case, in enum-flags.h, we are casting the value -1 to an enum + of a positive range only, which is UB as per the Standard and thus not + allowed in a constexpr context. + + The purpose of doing this instead of using std::underlying_type is + because, for C-style enums, std::underlying_type typically returns + "unsigned int". However, when operating with it arithmetically, the + enum is promoted to *signed* int, which is what we want to avoid. + + This patch solves this issue as follows: + + * Use std::underlying_type and remove the custom enum_underlying_type. + + * Ensure that operator~ is called always on an unsigned integer. We do + this by casting the input enum into std::size_t, which can fit any + unsigned integer. We have the guarantee that the cast is safe, + because we have checked that the underlying type is unsigned. If the + enum had negative values, the underlying type would be signed. + + This solves the issue with C-style enums, but also solves a hidden + issue: enums with underlying type of std::uint8_t or std::uint16_t are + *also* promoted to signed int. Now they are all explicitly casted + to the largest unsigned int type and operator~ is safe to use. + + * There is one more thing that needs fix. Currently, operator~ is + implemented as follows: + + return (enum_type) ~underlying(e); + + After applying ~underlying(e), the result is a very large value, + which we then cast to "enum_type". This cast is Undefined Behavior + if the large value does not fit in the range of the enum. For + C++ enums (scoped and/or with explicit underlying type), the range + of the enum is the entire range of the underlying type, so the cast + is safe. However, for C-style enums, the range is the smallest + bit-field that can hold all the values of the enumeration. So the + range is a lot smaller and casting a large value to the enum would + invoke Undefined Behavior. + + To solve this problem, we create a new trait + EnumHasFixedUnderlyingType, to ensure operator~ may only be called + on C++-style enums. This behavior is roughly the same as what we + had on trunk, but relying on different properties of the enums. + + * Once this is implemented, the following tests fail to compile: + + CHECK_VALID (true, int, true ? EF () : EF2 ()) + + This is because it expects the enums to be promoted to signed int, + instead of unsigned int (which is the true underlying type). + + I propose to remove these tests altogether, because: + + - The comment nearby say they are not very important. + - Comparing 2 enums of different type like that is strange, relies + on integer promotions and thus hurts readability. As per comments + in the related PR, we likely don't want this type of code in gdb + code anyway, so there's no point in testing it. + - Most importantly, this type of comparison will be ill-formed in + C++26 for regular enums, so enum_flags does not need to emulate + that. + + Since this is the only place where the warning was suppressed, remove + also the corresponding macro in include/diagnostics.h. + + The change has been tested by running the entire gdb test suite + (make check) and comparing the results (testsuite/gdb.sum) against + trunk. No noticeable differences have been observed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 + Tested-by: Keith Seitz + Approved-By: Tom Tromey + +2024-12-22 Flavio Cruz + + gdb/hurd: remove VLA usage + Compilation will fail with -Werror=vla, which seems to be the default. + + Note that we don't need to allocate num_threads + 1 since the matching + algorithm works only on the num_threads as returned by task_threads. + + Change-Id: I276928d0ff3c52c7c7fe4edb857e5789cdabfcf7 + +2024-12-22 GDB Administrator + + Automatic date update in version.in + +2024-12-21 GDB Administrator + + Automatic date update in version.in + +2024-12-20 Keith Seitz + + Add gstack script + This commit adds support for a `gstack' command which Fedora has + been carrying for many years. gstack is a natural counterpart to + the gcore command. Whereas gcore dumps a core file, gstack prints + stack traces of a running process. + + There are many improvements over Fedora's version of this script. + The dependency on procfs is gone; gstack will run anywhere gdb + runs. The only runtime dependencies are bash and awk. + + The script includes suggestions from gdb/32325 to include + versioning and help. [If this approach to gdb/32325 is acceptable, + I could propagate the solution to gcore/gdb-add-index.] + + I've rewritten the documentation, integrating it into the User Manual. + The manpage is now output using this one source. + + Example run (on x86_64 Fedora 40) + + $ gstack --help + Usage: gstack [-h|--help] [-v|--version] PID + Print a stack trace of a running program + + -h, --help Print this message then exit. + -v, --version Print version information then exit. + $ gstack -v + GNU gstack (GDB) 16.0.50.20241119-git + $ gstack 12345678 + Process 12345678 not found. + $ gstack $(pidof emacs) + Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"): + #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 + #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 + #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 + #3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0 + #4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 + #5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 + #6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 + #7 0x0000000000000000 in ??? () + + Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000000000001 in ??? () + #2 0xffffffff00000001 in ??? () + #3 0x0000000000000001 in ??? () + #4 0x000000002104cfd0 in ??? () + #5 0x00007fd5eb9be320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000020f9b558 in ??? () + #2 0xffffffff00000003 in ??? () + #3 0x0000000000000003 in ??? () + #4 0x00007fd5d8000b90 in ??? () + #5 0x00007fd5eb1bd320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"): + #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 + #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 + #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 + #3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0 + #4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0 + #5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 + #6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 + #7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 + #8 0x0000000000000000 in ??? () + + Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000000000001 in ??? () + #2 0xffffffff00000001 in ??? () + #3 0x0000000000000001 in ??? () + #4 0x00007fd5cc000b90 in ??? () + #5 0x00007fd5e9e6c320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"): + #0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6 + #1 0x0000000000000000 in ??? () + + Since this is essentially a complete rewrite of the original + script and documentation, I've chosen to only keep a 2024 copyright date. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-12-20 Tom Tromey + + Minor cleanups in rust-lang.c + This patch is a few minor cleanups to rust-lang.c: renaming a + badly-named local variable, moving a couple of declarations into 'for' + headers, and using 'bool' in one spot. + +2024-12-20 Richard Earnshaw + + arm: fix incorrect assembly of stm{,ia} as push [PR32363] + PR/32363. + + Gas was incorrectly translating + stm sp!, {regs} + into + push {regs} + but this is invalid. Conversely, it was also failing to translate + stmfd sp!, {lowregs[, lr]} + into a 16-bit push instruction. Fortunately stmia SP! is unlikely to be + a common idiom on a full-descending stack as it writes values to the stack, + then immediately deallocates that bit of the stack. + + Fixed this and cleaned up the logic somewhat. While there, change some of + the ordering so that "ldm base, {base}" is transformed preferentially to + LDR. This is in keeping with the general preference in the Arm ARM for + avoiding single register LDM instructions. + +2024-12-20 Tom de Vries + + [gdb/cli] Don't prefill for operate-and-get-next of last command + Consider operate-and-get-next [1] in bash: + ... + $ echo 1 + 1 + $ echo 2 + 2 + $ (reverse-i-search)`': echo 1 + 1 + $ echo 2 + 2 + $ echo 1 + ... + + So, typing Ctrl-o: + - executes the recalled command, and + - prefills the next one (which then can be executed again with Ctrl-o). + + We have the same functionality in gdb, but when recalling the last command + from history with bash we have no prefill: + ... + $ echo 1 + 1 + $ (reverse-i-search)`': echo 1 + 1 + $ + ... + but with gdb do we have a prefill: + ... + (gdb) echo 1\n + 1 + (gdb) (reverse-i-search)`': echo 1\n + 1 + (gdb) echo 1\n + ... + + Following the principle of least surprise [2], I think gdb should do what bash + does. + + Fix this by: + - signalling this case in gdb_rl_operate_and_get_next using + "operate_saved_history = -1", and + - handling operate_saved_history == -1 in + gdb_rl_operate_and_get_next_completion. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR cli/32485 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485 + + [1] https://www.man7.org/linux/man-pages/man3/readline.3.html + [2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment + +2024-12-20 Tom Tromey + + Use block::is_static_block in ada-lang.c + This changes one spot in ada-lang.c to use block::is_static_block + rather than a hand-rolled implementation. Note this also fixes the + call -- what is currently written there is wrong. + + Approved-By: Tom de Vries + +2024-12-20 Tom Tromey + + Fix latent bug in gdbpy_lookup_static_symbols + gdbpy_lookup_static_symbols is missing an error check for the case + where symbol_to_symbol_object returns NULL. + + Approved-By: Tom de Vries + +2024-12-20 Nick Clifton + + Fix examples of the use of the linker script TYPE keyword + +2024-12-20 Tom de Vries + + [gdb/testsuite] Use -nostdlib in gdb.linespec/explicit.exp + On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run + into: + ... + (gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr" + Quit^M + ... + + The test-case already contains a related workaround: + ... + # Get rid of symbols from shared libraries, otherwise + # "b -source thr" could find some system library's + # source. + gdb_test_no_output "nosharedlibrary" + ... + but that doesn't work in this case because the debug info is in the executable + itself: + ... + The File Name Table (offset 0xb5): + Entry Dir Time Size Name + 1 0 0 0 abi-note.c + 2 1 0 0 types.h + 3 2 0 0 stdint-intn.h + 4 2 0 0 stdint-uintn.h + 5 3 0 0 elf.h + 6 4 0 0 thread_pointer.h + ... + due to debug info in some glibc object file. + + Fix this by: + - using -nostdlib, ensuring only debug info from the three test-case sources + is present in the executable, and + - adding a _start wrapping main. + + Tested on x86_64-linux and ppc64le-linux. + + Reviewed-By: Keith Seitz + + PR testsuite/31229 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229 + +2024-12-20 GDB Administrator + + Automatic date update in version.in + +2024-12-19 Alexandra Hájková + + elfcpp/dwarf.h: Add post DWARF5 constants to DW_LANG enum + Also add the post DWARF5 language codes to gold/gdb-index.cc + Gdb_index_info_reader::visit_top_die check as --gdb-index only + supports C and C++ languages and emits warning otherwise. + +2024-12-19 Tankut Baris Aktemur + + gdb, gdbserver: introduce the 'x' RSP packet for binary memory read + Introduce an RSP packet, 'x', for reading from the remote server + memory in binary format. The binary write packet, 'X' already exists. + The 'x' packet is essentially the same as 'm', except that the + returned data is in binary format. For transferring relatively large + data from the memory of the remote process, the 'x' packet can reduce the + transfer costs. + + For example, without this patch, fetching ~100MB of data from a remote + target takes + + (gdb) dump binary memory temp.o 0x00007f3ba4c576c0 0x00007f3bab709400 + 2024-03-13 16:17:42.626 - command started + 2024-03-13 16:18:24.151 - command finished + Command execution time: 32.136785 (cpu), 41.525515 (wall) + (gdb) + + whereas with this patch, we obtain + + (gdb) dump binary memory temp.o 0x00007fec39fce6c0 0x00007fec40a80400 + 2024-03-13 16:20:48.609 - command started + 2024-03-13 16:21:16.873 - command finished + Command execution time: 20.447970 (cpu), 28.264202 (wall) + (gdb) + + We see improvements not only when reading bulk data as above, but also + when making a large number of small memory access requests. + + For example, without this patch: + + (gdb) pipe x/100000xw $pc | wc -l + 2024-03-13 16:04:57.112 - command started + 25000 + 2024-03-13 16:05:10.798 - command finished + Command execution time: 9.952364 (cpu), 13.686581 (wall) + + With this patch: + + (gdb) pipe x/100000xw $pc | wc -l + 2024-03-13 16:06:48.160 - command started + 25000 + 2024-03-13 16:06:57.750 - command finished + Command execution time: 6.541425 (cpu), 9.589839 (wall) + (gdb) + + Another example, where we create a core file of a GDB process. + + (gdb) gcore /tmp/core.1 + ... + Command execution time: 85.496967 (cpu), 133.224373 (wall) + + vs. + + (gdb) gcore /tmp/core.1 + ... + Command execution time: 48.328885 (cpu), 115.032289 (wall) + + Regression-tested on X86-64 using the unix (default) and + native-extended-gdbserver board files. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-12-19 Tankut Baris Aktemur + + gdbserver: allow suppressing the next putpkt remote-debug log + When started with the --debug=remote flag, gdbserver enables the debug + logs for the received and sent remote packets. If the packet contents + are too long or contain verbatim binary data, printing the contents + may create noise in the logs or even distortion in the terminal output. + + Introduce a function, `suppress_next_putpkt_log`, that allows omitting + the contents of a sent package in the logs. This can be useful when a + certain packet handler knows that it is sending binary data. + + My first attempt was to implement this mechanism by passing an extra + parameter to putpt_binary_1 that could be controlled by the caller, + putpkt_binary or putpkt. However, all qxfer handlers, regardless of + whether they send binary or ascii data, cause the data to be sent via + putpkt_binary. Hence, the solution was going to be either too + suppressive or too intrusive. I opted for the approach where a package + handler would suppress the log explicitly. + + Approved-By: Tom Tromey + +2024-12-19 Tankut Baris Aktemur + + doc: fine-tune the documentation of the 'm' RSP packet + Revise a sentence to avoid misinterpretation. Move @cindex entries + before the text they index. Refer to trace frames regarding partial + reads. + + Approved-By: Eli Zaretskii + +2024-12-19 Nick Clifton + + Updated Serbian translation for the bfd sub-directory + + Fix the handling or arguments and macro pseudo-variables inside nested assembler macros. + PR 32391 + +2024-12-19 Jan Beulich + + bfd/ELF: refine PR binutils/31872 fix + The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case + of targets with only RELA support, where nevertheless object files using + REL exist. In particular objcopy will create such objects for x86-64 + when converting from an i?86 ELF object (this by itself probably isn't + quite right, but we ought to cope with what our own tools are doing). + + Restore the fallback to the RELA lookup, just without re-introducing the + blind NULL de-ref that was there before. + +2024-12-19 Jan Beulich + + PPC: drop redundant value conversion from md_assemble() + Just ahead of the enclosing OBJ_ELF conditional the exact same + conversion was already carried out, with "val" not further changed in + between. + + x86-64: correct CODE_5 relocs + Two of them had their numbers swapped; luckily they aren't really in use + just yet. Correct indentation as well while at it. + +2024-12-19 GDB Administrator + + Automatic date update in version.in + +2024-12-18 Alan Modra + + Adjust expected loongarch32 test results + readelf and objdump differ in output for 32-bit vs 64-bit. + + * testsuite/gas/loongarch/dwarf-regnum.d: Adjust to suit both + 32-bit and 64-bit output. + * testsuite/gas/loongarch/localpic.d: Likewise. + +2024-12-18 Alan Modra + + target_id for cr16 and vax + Both of these targets extend elf_link_hash_entry, so arguably should + set hash_table_id to something other than GENERIC_ELF_DATA. The patch + also sorts enum elf_target_id. + + Remove bfd_elf_allocate_object object_id param + This is another case where the proper object_id can be read from + elf_backend_data. + + Remove _bfd_elf_link_hash_table_init target_id param + hash_table_id can be set from elf_backend_data, now that all targets + have matching ELF_TARGET_ID and hash_table_init target_id. + +2024-12-18 Alan Modra + + Add a few elf_backend_data target ids + aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than + the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that. + These are all targets that use other than GENERIC_ELF_DATA in their + object and hash table ids. + + * elf32-am33lin.c, + * elf32-csky.c, + * elf64-ia64-vms.c, + * elf64-sparc.c, + * elfnn-aarch64.c, + * elfnn-kvx.c (ELF_TARGET_ID): Define. + +2024-12-18 Keith Seitz + + [doc] Update gdb-add-index manpage + The current gdb-add-index manual page is a bit out-of-date. This + commit fixes a few deficiencies: + + - gdb-add-index does not use objdump; it uses objcopy and readelf + - missing info on environment variables (in appropriate ENVIRONMENT section). + - missing mention of -dwarf-5 option + - adds important notice about FILENAME being writable + - explains exit status + - the script adds appropriate section(s) to the file; it does not + output new files with the section(s) + + Approved-By: Eli Zaretskii + +2024-12-18 Tom Tromey + + Add check-include-guards.py to pre-commit + This changes pre-commit to run check-include-guards.py. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Run check-include-guards.py + This patch is the result of running check-include-guards.py on the + current tree. Running it a second time causes no changes. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Add an include-checking script + This adds a new Python script that checks the header guards of all gdb + source files. It enforces a fairly strict formatting and naming + scheme. + + In particular, for a file "x/y-z.h" (relative to the repository root), + the include guard will be named "X_Y_Z_H". Only the '#ifndef' form is + allowed, not "#if !defined(...)". The trailing comment on the + "#endif" is also required. + + The script also tries to update files that appear to have the required + lines if they are in the wrong form or use the wrong name. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Fix some minor header file irregularities + The script in the next patch noticed some irregularities in some + headers: trailing or leading blank lines, or in one case a missing + copyright header. This patch fixes these. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Fix typo in Python documentation + Oleg pointed out that when renaming from "status" to "enabled" in the + Python TUI events patch, I neglected to update one spot in the + documentation. This patch fixes this. I'm checking it in as obvious. + + You can verify that this change is correct by examining + gdb/python/py-event-types.def. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 + +2024-12-18 Haochen Jiang + + Support Intel SM4 AVX10.2 extension + In this patch, we will support SM4 AVX10.2 extension part. It is + a promotion from VEX encoding to EVEX encoding. The EVEX encoding + is based on AVX10.2, which is the same as the upcoming MOVRS ISA. + Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS. + + While I have also tried to merge the table like AVX/AVX512, I + choose to just templatize the table. I am okay to go either way, + but slightly prefer the templatizing one since probably SM4 would + be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS + does not need that). Also, it is a tendancy that we will directly + provide EVEX encodings and no VEX encodings for vector instructions + since AVX10. This will make the adding in gas/config/tc-i386.c not + that worthy. + + gas/ChangeLog: + + * NEWS: Support Intel SM4 EVEX instructions. + * config/tc-i386.c (_is_cpu): Handle AVX10.2. + * testsuite/gas/i386/i386.exp: Run SM4 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-sm4-intel.d: Add SM4 tests. + * testsuite/gas/i386/avx10_2-256-sm4.d: Ditto. + * testsuite/gas/i386/avx10_2-256-sm4.s: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4.d: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4.s: Ditto. + * testsuite/gas/i386/avx10_2-sm4-inval.l: Ditto. + * testsuite/gas/i386/avx10_2-sm4-inval.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-sm4-inval.l: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-sm4-inval.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Add evex table entry for SM4. + * i386-dis.h: Ditto. + * i386-opc.h: (i386_cpu): Move AVX10.2 to CPU_FLAGS_COMMON. + * i386-opc.tbl: Add SM4 EVEX instructions. + * i386-init.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-18 GDB Administrator + + Automatic date update in version.in + +2024-12-17 Tom Tromey + + Minor C++-ification in rust-parse.c + This patch changes a few spots in rust-parse.c to use 'bool', and also + declares a couple of loop iteration variables in the loop headers. + I'm checking this in. + +2024-12-17 Flavio Cruz + + Hurd: do not include defs.h when compiling MiG stubs since they are compiled as C files + Otherwise, GDB will fail to compile for Hurd. + + Approved-By: Tom Tromey + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Update ARM64 xml files + There are some new syscalls in the latest upstream Linux kernel [1], + some archs updated the xml files in the recent commit 19f3450f7429 + ("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also + update ARM64 to reflect the reality. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70 + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Update LoongArch xml files + There are some new syscalls in the latest upstream Linux kernel [1][2][3], + update the xml files for LoongArch to reflect the reality. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7697a0fe0154 + [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff388fe5c481 + [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70 + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Remove tips for LoongArch xml files + After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number", + no need to do special handling when generating xml file for LoongArch, + just remove the tips in the file comment. + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Handle __NR3264_ prefixed syscall number + In gdb commit a08dc2aa004b ("gdb: syscalls: Add loongarch-linux.xml.in"), + we find: + + There exist some __NR3264_ prefixed syscall numbers, replace them + with digital numbers according to /usr/include/asm-generic/unistd.h + and sort them by syscall number manually, maybe we can modify the + script to do it automatically in the future. + + It is time to do it now, just handle __NR3264_ prefixed syscall number + automatically in the script update-linux.sh. + + By the way, a Linux kernel patch did the similar change [1]. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6e1cc6b7220 + + Approved-By: Tom de Vries + +2024-12-17 Matthieu Longo + + aarch64: testsuite: remove macro expansion messages from expected error output + gas generates an information diagnostic message for every context + invoking a macro and generating a warning or error message. + For the specific case of sysreg tests, this pollutes the expected + error output for no benefit in term of test debug or testing coverage. + + This patch aims at stopping such diagnostic messages to be generated + for the failure tests by providing --no-info flag to gas. + It also removed from the expected outputs the information messages + related to macro expansions. + +2024-12-17 Matthieu Longo + + gas: add new command line options to control diagnostic informational messages + gas currently emits informational messages for context information along warnings. + In the context of system register tests in AArch64 backend, these messages + pollute the tests when checking for error message patterns in stderr output. + + This patch aims at providing two new flags while preserving the existing + behavior if none of the options is provided. + * --info, similar to the existing --warn flag to enable diagnostic + informational messages (default behavior). + * --no-info, similar to the existing --no-warn flag to disable diagnostic + informational messages. + + It also adds the flags to the existing documentation, and command manual. + +2024-12-17 Nick Clifton + + nm: Avoid potential segmentation fault when displaying symbols without version info. + PR 32467 + +2024-12-17 Tankut Baris Aktemur + + gdbserver: return tracked register status in regcache_raw_read_unsigned + In regcache_raw_read_unsigned, we unconditionally return REG_VALID as + the register status. This does not seem right, since the register may + in fact be in another state, such as REG_UNAVAILABLE. Return the + tracked status. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbsupport: fix a typo in a comment in common-regcache.h + Fix a typo. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: rename regcache's registers_valid to registers_fetched + The registers_valid field of the regcache struct is used for tracking + whether we have attempted to fetch all the registers from the target. + Its name does not reflect this well, I think. It falsely gives the + impression that all the registers are valid. This may conflict an + individual register status, which could be REG_UNAVAILABLE. To better + reflect the purpose, rename the field to "registers_fetched". + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: boolify regcache fields + The registers_valid and registers_owned fields of the regcache struct + are of type int. Make them bool. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: check for nullptr condition in regcache::get_register_status + A regcache can be initialized with a register value buffer, in which + case, the register_status pointer is null. This condition is checked + in set_register_status, but not in get_register_status. Do this check + for consistence and safety. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: convert regcache_cpy into regcache::copy_from + Convert the free `regcache_cpy` function to a method of the + regcache struct. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache + Boolify the 'fetch' parameter of the get_thread_regcache function. + + All of the current uses pass true for this parameter. Therefore, define + its default value as true and remove the argument from the uses. + + We still keep the parameter, though, to give downstream targets the + option to obtain a regcache without having to fetch the whole + contents. Our (Intel) downstream target is an example. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: by-pass regcache to access tdesc only + The `get_thread_regcache` function has a `fetch` option to skip + fetching the registers from the target. It seems this option is set + to false only at uses where we just need to access the tdesc through + the regcache of the current thread, as in + + struct regcache *regcache = get_thread_regcache (current_thread, 0); + ... regcache->tdesc ... + + Since the tdesc of a regcache is set from the process of the thread + that owns the regcache, we can simplify the code to access the tdesc + via the process, as in + + ... current_process ()->tdesc ... + + This is intended to be a refactoring with no behavioral change. + + Tested only for the linux-x86-low target. + + Approved-By: Simon Marchi + +2024-12-17 Alan Modra + + Re: score and mmix target_id + elflink.c checks elf_object_id(ibfd) == elf_hash_table_id(hash_table) + in a number of places. Make them match. + +2024-12-17 GDB Administrator + + Automatic date update in version.in + +2024-12-16 Tom Tromey + + Use correct type for saved signal handler + A user noticed that the sim assigns the result of a call to 'signal' + to a variable like: + + RETSIGTYPE (*prev_sigint) (); + + However, it's more correct to use (int) here. + + This patch fixes the error. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32466 + Approved-By: Andrew Burgess + +2024-12-16 Tom Tromey + + Fix readline build on mingw + Upstream readline 8.2 does not build on mingw. This patch fixes the + build, but I do not know how well it works. + + I've submitted this to readline here: + + https://lists.gnu.org/archive/html/bug-readline/2024-11/msg00007.html + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 + +2024-12-16 Tom Tromey + + Import GNU Readline 8.2 + This imports readline 8.2 patch 13. + + This time around I thought I would try to document the process. + + First I have a checkout of the upstream readline repository. I make a + local branch there, based on the previous upstream import. In this + case that was readline 8.1; see gdb commit b4f26d541aa. + + Then, I apply all readline changes from the gdb repository since the + previous readline import. In this case that is up to commit + 3dee0baea2e in the gdb repo. + + After this, I "git merge" from the relevant upstream commit. In the + past I feel like I used a tag, but readline is managed very strangely + and I didn't see a tag. So I just used the patch 13 commit, aka + commit 037d85f1 upstream. + + Then I fixed all the merge conflicts. Re-running autoconf requires a + symlink from '../../config' into the gdb tree, due to the local + m4_include addition. It's possible other hacks like this are + required, I don't remember how I set things up in the past. + + After this, I did a build + test of gdb. I also did a mingw + cross-hosted build, because that's caused build failures in past + imports. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 + Reviewed-by: Sam James + +2024-12-16 Tom Tromey + + Greatly speed up rbreak + While debugging another issue, I noticed that 'rbreak' on a large + program was very slow. In particular, with 'maint time 1': + + (gdb) with pagination off -- rbreak ^command_display + [...] + Command execution time: 1940.646332 (cpu), 1960.771517 (wall) + + "ps" also reported that, after this command, gdb's VSZ was 4619360. + + Looking into this, I found something strange. When 'rbreak' found a + function "f" in file "file.adb", it would try to set the breakpoint + using "break 'file.adb':'f'". + + This then interacted somewhat poorly with linespec. linespec first + expands all the symtabs matching "file.adb", but in this program this + results in thousands of CU expansions (probably due to inlining, but I + did not investigate). + + There is probably a linespec bug here. It would make more sense for + it to combine the file- and symbol- lookups, as this is more + efficient. I plan to file a bug about this at least. + + I tracked this "file:function" style of linespec to the earliest days + of gdb. Back then, "break function" would only break on the first + "function" that was found -- it wasn't until much later that we + changed gdb to break on all matching functions. So, I think that + rbreak was written this way to try to work around this limitation, and + it seems to me that this change obsoleted the need for rbreak to + mention the file at all. + + That is, "break file:function" is redundant now, because plain + "break function" will redo that same work -- just more efficiently. + (The only exception to this is the case where a file is given + to rbreak -- here the extra filtering is still needed.) + + This patch implements this. On the aforementioned large program, with + this patch, rbreak still sets all the desired breakpoints (879 of + them) but is now much faster: + + (gdb) with pagination off -- rbreak ^command_display + [...] + Command execution time: 91.702648 (cpu), 92.770430 (wall) + + It also reduces the VSZ number to 2539216. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340 + Approved-By: Pedro Alves + +2024-12-16 Tom Tromey + + Don't let exception terminate 'rbreak' + 'rbreak' searches symbols and then sets a number of breakpoints. If + setting one of the breakpoints fails, then 'rbreak' will terminate + before examining the remaining symbols. + + However, it seems to me that it is better for 'rbreak' to keep going + in this situation. That is what this patch implements. + + This problem can be seen by writing an Ada program that uses "pragma + import" to reference a symbol that does not have debug info. In this + case, the program will link but setting a breakpoint on the imported + name will not work. + + I don't think it's possible to write a reliable test for this, as it + depends on the order in which symtabs are examined. + + New in v2: rbreak now shows how many breakpoints it made and also how + many errors it encountered. + + Regression tested on x86-64 Fedora 40. + + Approved-By: Andrew Burgess + +2024-12-16 Tom Tromey + + Re-run isort + I noticed that an earlier commit caused a change in the isort output. + This patch repairs the problem. + +2024-12-16 Andrew Burgess + + gdb/testsuite: rename test source file to avoid glibc clash + After posting this series: + + https://inbox.sourceware.org/gdb-patches/cover.1733742925.git.aburgess@redhat.com + + I got a failure report from the Linaro CI system. I eventually + tracked the issue down to a filename clash with glibc. I was able to + reproduce the issue when I installed the glibc debug information on to + my local machine, and ran the gdb.base/dlmopen.exp test as updated in + the above series. + + Here's what's happening: + + There is a file called dlmopen.c within glibc, within the glibc source + tree the file can be found at ./dlfcn/dlmopen.c. When this file is + compiled it appears that the glibc build system first enters the dlfcn + directory, and then compiles the file using the relative path + ./dlmopen.c, here's a snippet of the DWARF: + + <0>: Abbrev Number: 12 (DW_TAG_compile_unit) + DW_AT_producer : (alt indirect string, offset: 0x16433) t + DW_AT_language : 29 (C11) + DW_AT_name : (indirect line string, offset: 0x5c8f): dlmopen.c + DW_AT_comp_dir : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn + DW_AT_low_pc : 0x8a4c0 + DW_AT_high_pc : 408 + DW_AT_stmt_list : 0x68ec1 + + The important thing here is the DW_AT_name, which is just "dlmopen.c". + + The gdb.base/dlmopen.exp test also has a source file called + "dlmopen.c". + + The dlmopen.exp test makes use of the clean_restart TCL proc, which + calls gdb_reinitialize_dir, which resets the source directories search + path to '$cdir:$cwd', and then prepends the test source directory to + the front of the list, so the source directory search path will look + something like: + + /tmp/src/gdb/testsuite/gdb.base/gdb.base:$cdir:$cwd + + In the existing test we try to place a breakpoint on 'dlmopen.c:64'. + This is the line tagged 'bp.main' in the source file. This currently + works fine. GDB searches through the symtabs and finds two matches, + the test dlmopen.c, and the glibc dlmopen.c. For each GDB tries to + convert line 64 into an address. + + For the testsuite source file this is fine, we get the address of the + line tagged 'bp.main' from the source, and the breakpoint is created. + + For the glibc source file though, at least, for the version available + to me, line 64 happens to be the closing '}' of a function, and there + isn't a line table entry for this exact line. So GDB searches forward + looking for the next line in order to place a breakpoint there. The + next line GDB finds is the start of the next function, and so GDB + rejects this location due to commit: + + commit dcaa85e58c4ef50a92908e071ded631ce48c971c + Date: Wed May 1 10:47:47 2024 +0100 + + gdb: reject inserting breakpoints between functions + + So we managed to avoid creating two breakpoint locations in this case, + but only by pure good luck. + + In my updates to the test though I try to create a breakpoint at line + 61 in addition to the breakpoint at line 64. So now the breakpoint + spec is 'dlmopen.c:61'. + + Just as before, GDB identifies the 'dlmopen.c' could mean two files, + and searches for line 61 in both. The test source works as expected + and the breakpoint is created in the desired location. + + But this time, line 61 in the glibc source file is an actual line, + with actual code, and so GDB places a breakpoint at this location. + + This second breakpoint, in glibc is entirely unexpected (by the + dlmopen.exp test script). Unfortunately, the inferior hits this + second glibc breakpoint before it hits the actual breakpoint within + the main test executable, this throws the test off and causes some + failures. + + In trying to fix this, I did wonder if I could just specify the full + path to the source file, instead of using just 'dlmopen.c:61'. + However, this doesn't work. + + Remember that the glibc source file is recorded as just 'dlmopen.c'. + So, when GDB tries to figure out the absolute path to this source + file, the source directory search path is used. In this case, the + first entry in the source directory search path is the gdb.base/ + directory in the GDB source tree. GDB looks in this directory and + finds a dlmopen.c, and so GDB assumes that this is the file in + question. + + Thus, GDB actually thinks that both files _are_ the same source file. + Indeed, when GDB stops at the incorrect (glibc) breakpoint, and lists + the source code, it actually lists the source code from the correct + file. This confused me to begin with, GDB reported the wrong + function (the glibc function), but listed code from the correct file + and line. + + Now on my machine I have installed the package that provides the glibc + source code. If I change the source directory search path so that + $cdir is first instead of the gdb.base/ from the GDB source tree, this + fixes the listing the wrong file problem. GDB does not realise that + the files are different, and if I create the breakpoint using the + absolute path then only a single breakpoint location is created. + However, this relies on the developer having both the glibc debug + information, and the glibc source package installed, this doesn't seem + like a great requirement to have in place. + + So instead, I propose that we just take the easy way out, rename the + test source file. By doing this all the issues are avoided. The test + now creates a breakpoint at 'dlmopen-main.c:61', and there is only one + file with this name found, so we only get a single breakpoint location + created. + + I renamed the source file, but not the dlmopen.exp file because the + test already makes use of multiple source files, so having a range of + different names didn't feel that bad, but if this bothers people, I + could rename both the .exp and main .c file, just let me know. + + If you want to explore this issue for yourself then try with + installing the glibc debug information for your system, and ensure + that your GDBs under test are able to find the glibc debug + information. You can then either apply the series I linked above, or, + you can modify the existing test source so that the line tagged as + 'bp.main' becomes line 61, I just deleted 3 lines from the big comment + at the head of the file. + + Of course, reproducing this does depend on how glibc is compiled, + which could change from system to system, or overtime. I reproduced + this issue on Fedora 39 with glibc-2.38-19. + + With this patch applied I no longer see any regressions when I apply + the above linked series. + + While making these changes I took the opportunity to update the test + script to make better use of standard_testfile and build_executable. + + Reviewed-By: Keith Seitz + Approved-By: Tom Tromey + +2024-12-16 Nick Clifton + + Update translations for the opcodes directory for the French and Serbian languages. + +2024-12-16 Jan Beulich + + ld/doc: properly separate @samp from @item + At least makeinfo 4.13 doesn't tolerate @item@samp, considering it a + single command. + +2024-12-16 Alan Modra + + mach-o segment section count assertion + Add an assertion that verifies we have filled the mdata->sections + array in bfd_mach_o_flatten_sections. + + score and mmix target_id + These targets currently use GENERIC_ELF_DATA as their target_id, but + that isn't exactly correct. While their bfd tdata is generic elf, + their elf_section_data is extended with extra target data. Add + MMIX_ELF_DATA and SCORE_ELF_DATA. + + goodbye aout_section_data + aout_section_data->relocs isn't set by anything, so delete it. + +2024-12-16 Alan Modra + + record_section_with_aarch64_elf_section_dat + Nowhere in the aarch64 backend is the list created by this function + examined, and in any case there are much simpler ways to determine the + type of elf_section_data attached to a bfd ELF section. It will + always be according to the target_id of the section owner. + + Delete sections_with_aarch64_elf_section_data and everything + associated with it. + +2024-12-16 Alan Modra + + section tdata tidy + Any _new_section_hook that is not itself called from another + _new_section_hook will always see used_by_bfd NULL. Remove those + NULL checks in such hooks, and tidy code a little. + +2024-12-16 Lulu Cai + + LoongArch: Fix bfd ld failed test case + This test case requires host gcc, and different distributions have + different default configurations for gcc, which can cause address value + mismatches. + Therefore, it is fixed by passing consistent options and using regular + expressions. + +2024-12-16 GDB Administrator + + Automatic date update in version.in + +2024-12-15 Alan Modra + + Move modification of bfd abs and und back to gas + In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and + instead put the gas modification of bfd's *ABS* and *UND* sections in + bfd_make_section_old_way. More recently in commit 8b5a21249537 I made + tekhex symbol creation use bfd_make_section_old_way for symbol + sections. After that we saw numerous non-repeatable oss-fuzz reports + of accesses to freed memory involving relocation symbols. I think + what is happening is: + + A tekhex testcase with an absolute symbol is run through the tool, + modifying bfd_abs_section.symbol to point to a symbol on the bfd's + objalloc memory. On closing that bfd bfd_abs_section.symbol points to + freed memory. + + A second testcase is run through the tool with some access to the + *ABS* symbol. This triggers the invalid memory access. + + The same thing could happen if a user runs objdump or nm with two + files on the command line, the first being a tekhex file with absolute + symbols, or if ld is given tekhex input among other files. Clearly, + it's a bad idea to modify the *ABS* or *UND* sections for input files. + + bfd/ + * section.c (bfd_make_section_old_way): Don't call + _new_section_hook for standard abs, com, und and ind sections. + gas/ + * as.c (bfd_std_section_init): New function. + (perform_an_assembly_pass): Move section initialisation to.. + (gas_init): ..here. Use bfd_std_section_init. + +2024-12-15 GDB Administrator + + Automatic date update in version.in + +2024-12-14 oltolm + + fix Windows build + Fix the Windows build that was broken in "Introduce \"command\" styling". + + Approved-By: Tom Tromey + +2024-12-14 Alexandra Hájková + + display_lang: Add descriptions for post DWARF5 constants + Describe all the new post DWARF5 language codes from the latest sync + of include/dwarf.h with gcc. + +2024-12-14 Alan Modra + + Delete asection.symbol_ptr_ptr + This field is always set to point to asection.symbol, and no code ever + changes it from its initial value. With one exception. elfxx-mips.c + creates two sections with separate pointers to their symbols, and uses + those as asection.symbol_ptr_ptr. Those pointers aren't modified, + so they disappear in this patch too. + +2024-12-14 Tom de Vries + + [gdb/dap] Fix regressions with python 3.6 + With test-case gdb.dap/ada-arrays.exp, on Leap openSUSE 15.6 with python 3.6, + I run into: + ... + Python Exception : 'type' object is not subscriptable + Error occurred in Python: 'type' object is not subscriptable + ERROR: tcl error sourcing ada-arrays.exp. + ... + + This is due to using a python 3.9 construct: + ... + thread_ids: dict[int, int] = {} + ... + + Fix this by using typing.Dict instead. + + Tested on x86_64-linux. + +2024-12-14 GDB Administrator + + Automatic date update in version.in + +2024-12-13 Alan Modra + + xcoff ldrel and tls sections + * xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Use + .tdata and .tbss section symbols. + (xcoff_create_ldrel): Abort on h and hsec both NULL. + +2024-12-13 Tom de Vries + + [gdb] Fix tsan warning: signal handler spoils errno + When building gdb with -fsanitize=thread and running test-case + gdb.base/bg-exec-sigint-bp-cond.exp, I run into: + ... + ==================^M + WARNING: ThreadSanitizer: signal handler spoils errno (pid=25422)^M + #0 handler_wrapper gdb/posix-hdep.c:66^M + #1 decltype ({parm#2}({parm#3}...)) gdb::handle_eintr<>() \ + gdbsupport/eintr.h:67^M + #2 gdb::waitpid(int, int*, int) gdbsupport/eintr.h:78^M + #3 run_under_shell gdb/cli/cli-cmds.c:926^M + ... + + Likewise in: + - tui_sigwinch_handler with test-case gdb.python/tui-window.exp, and + - handle_sighup with test-case gdb.base/quit-live.exp. + + Fix this by saving the original errno, and restoring it before returning [1]. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html + +2024-12-13 oltolm + + gdb/dap: allow some requests when the process is running + It is impossible to set a breakpoint when the process is running, + which I find annoying. LLDB does not have this restriction. I made + `setBreakpoints` and `breakpointLocations` work when the process is + running. Probably more requests can be changed, but I only need these + two at the moment. + + Approved-By: Tom Tromey + +2024-12-13 Oleg Tolmatcev + + gdb-dap: fix gdb.error: Frame is invalid. + When you try to use a frame on one thread and it was created on + another you get an error. I fixed it by creating a map from a frame ID + to a thread ID. When a frame is created it is added to the map. When + you try to find a frame for an id it checks if it is on the correct + thread and if not switches to that thread. I had to store the frame id + instead of the frame itself in a "_ScopeReference". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32133 + Approved-By: Tom Tromey + +2024-12-13 Marek Pikuła + + gitignore: Add .devcontainer to ignored + Some people might use devcontainer to set up development environment. + Ignore this directory, similar to other existing IDE-specific ignores. + +2024-12-13 Nick Clifton + + Give unique names to s390 assembler opcode tests. + +2024-12-13 Jan Beulich + + msp430/gas: correct BFD_RELOC_32 handling + It was likely a copy-and-paste oversight that bfd_putl16() was used here + from the very beginning. And of course there's a difference only if the + value to be stored is different from the value that's already there; + typically both are 0. + + gas: avoid UB on signed multiplication in resolve_symbol_value() + Commit 487b0ff02dda ("ubsan: signed integer multiply overflow") touched + only one of the two affected places (the 3rd, resolve_expression(), is + already using valueT type local variables). + +2024-12-13 Alan Modra + + xcoff reading dynamic relocs + This adds a sanity check to relocation symbol indices, and tidies code + a little. + + The patch does result in a couple of testsuite failures + rs6000-aix7.2 +FAIL: TLS relocations (32-bit) + rs6000-aix7.2 +FAIL: TLS relocations (64-bit) + + That seems reasonable to me, because prior to this patch l_symndx was + being set to -1 and -2 for .tdata and .tbss symbols resulting in a + buffer overflow when accessing the syms array. + + bfd/ + * xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Prevent + symbol array overflow on invalid relocation symbol index. + Tidy code for relocs against standard sections. + (xcoff_create_ldrel): Remove cast. + include/ + * coff/xcoff.h (struct internal_ldrel): Make l_symndx uint32_t. + Make l_rtype and l_rsecnm int16_t. + +2024-12-13 Alan Modra + + small coffgen.c tidy + _bfd_coff_free_cached_info should always call + _bfd_generic_bfd_free_cached_info, even if _bfd_coff_free_symbols + returns an error. (It won't return an error here, but let's not leave + anyone wondering about _bfd_coff_free_cached_info.) + + * coffgen.c (_bfd_coff_free_cached_info): Ignore return status + of _bfd_coff_free_symbols. + +2024-12-13 Alan Modra + + objdump: Delete close optimisation + In commit cd6581da62c3, Nick made an optimisation that was reasonable + at the time, but then pr22032 came along and commit 7c0ed39626e3 made + bfd_close_all_done free memory. So Nick's optimisation is now + ineffective, and the comment wrong. + + * objdump.c (display_file): Delete last_file param. Update + caller. Call bfd_close always. + +2024-12-13 Tom Tromey + + Reuse "title" style for list headers + This patch reuses the "title" style for titles -- in particular the + header line of a list display. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 Tom Tromey + + Replace uses of "title" style with "command" + Currently the "title" style is only used when printing command names. + The "title" name itself is probably a misnomer, but meanwhile this + patch changes the existing uses to instead use the new "command" style + for consistency. + + The "title" style is not removed; see the next patch. + + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 Tom Tromey + + Introduce "command" styling + This adds a new "command" style that is used when styling the name of + a gdb command. + + Note that not every instance of a command name that is output by gdb + is changed here. There is currently no way to style error() strings, + and there is no way to mark up command help strings. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747 + Reviewed-By: Eli Zaretskii + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 GDB Administrator + + Automatic date update in version.in + +2024-12-12 Tom Tromey + + Lock bfd_stat and bfd_get_mtime + PR gdb/31713 points out some races when using the background DWARF + reader. + + This particular patch fixes some of these, namely the ones when using + the sim. In this case, the 'load' command calls reopen_exec_file, + which calls bfd_stat, which introduces a race. + + BFD only locks globals -- concurrent use of a single BFD must be + handled by the application. To this end, this patch adds locked + wrappers for bfd_stat and bfd_get_mtime. + + I couldn't reproduce these data races but the original reporter tested + the patch and confirms that it helps. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713 + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Fix races involving _bfd_section_id + BFD's threading approach is that global variables are guarded by a + lock. However, while implementing this, I missed _bfd_section_id. A + user pointed out, via Thread Sanitizier, that this causes a data race + when gdb's background DWARF reader is enabled. + + This patch fixes the problem by using the BFD lock in most of the + appropriate spots. However, in ppc64_elf_setup_section_lists I chose + to simply assert that multiple threads are not in use instead. (Not + totally sure if this is good, but I don't think this can be called by + gdb.) + + I chose locking in bfd_check_format_matches, even though it is a + relatively big hammer, because it seemed like the most principled + approach, and anyway if this causes severe contention we can always + revisit the decision. Also this approach means we don't need to add + configury to check for _Atomic, or figure out whether bfd_section_init + can be reworded to make "rollback" unnecessary. + + I couldn't reproduce these data races but the original reporter tested + the patch and confirms that it helps. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713 + +2024-12-12 Tom Tromey + + Fix formatting in gdb.ada/lazy-string.exp + This fixes a formatting issue and corrects a comment in the new + gdb.ada/lazy-string.exp. I meant to do this in an earlier patch but + forgot to save. + +2024-12-12 Tom Tromey + + Use generic_printstr from ada_language::printstr + Currently, if you create a lazy string while in Ada language mode, the + string will be rendered strangely, like: + + "["d0"]["9f"]["d1"]["80"]["d0"]["b8"]... + + This happens because ada_printstr does not really handle UTF-8 + decoding. + + This patch changes ada_language::printstr to use generic_printstr when + UTF-8 is used. + + Note that this code could probably be improved some more -- the + current patch only addresses the narrow case of the Python API. I've + filed a follow-up bug (PR ada/32413) for the remaining changes. + + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Add text to gdbreplay --help output + I noticed that gdbreplay --help is rather sparse -- it doesn't even + mention the names of the options it accepts. + + This patch updates the help output to be more complete. + + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Fix GNAT version check in gdb.ada + Commit 1411185a ("Introduce and use gnat_version_compare") changed the + Ada tests to use a new proc for version checking. Unfortunately this + patch inadvertently reversed the sense of the test in + packed_array_assign.exp. + + After fixing this, I went through that patch again and looked for + other problems. I found one spot where the wrong syntax was used, and + some others where I believe the sense of the test was inverted. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32444 + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Make rs6000-tdep.c:variants 'const' + I noticed that rs6000-tdep.c has a global "variants" array that can be + marked "const", moving it into rodata. + + Approved-By: Andrew Burgess + +2024-12-12 Alexandra Hájková + + mangle_style: Add new DWARF5 constants + Update bfd/dwarf2.c with the post DWARF5 language codes which + were added after DWARF5 was finalized. Adding them makes it + possible to return the mangling style for the new language + codes for Ada 2005 Fortran, C++, C and Assembly. + + Reviewed-By: Andrew Burgess + Approved-By: Jan Beulich + +2024-12-12 Alan Modra + + Revert bfd_use_reserved_id patch + Commit fc1cfaa5f1 and bc110b6e40 were made to avoid testsuite + regressions on a number of targets that used bfd id in symbol hashing. + Since it no longer seems necessary to start plugin bfd id's from -1 + and count down, revert the functional changes in those patches. + +2024-12-12 Alan Modra + + Use bfd id to validate dwarf2 cache + Using a bfd pointer to validate the cache isn't very robust. If a bfd + is closed somehow without clearing the cache, then it's possible that + another bfd is opened using the same memory and thus orig_bfd compares + equal to the new bfd. + + * dwarf2.c (struct dwarf2_debug): Add orig_bfd_id. Delete + orig_bfd. + (_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id. + +2024-12-12 Alan Modra + + close last arfile before processing current arfile + This also reduces peak memory a little. + + * dlltool.c (identify_search_archive): Close last_arfile earlier. + Report an error if bfd_openr_next_archived_file returns the same + bfd. Localise variables. + * nm.c (display_archive): Likewise. + * objdump.c (display_any_bfd): Likewise. + * size.c (display_archive): Likewise. + +2024-12-12 Alan Modra + + nm.c free_lineno_cache + free_lineno_cache frees symbol and relocation data used when displaying + line number info for symbols (nm -l). Currently that is done when + closing the bfd, but that's not ideal for archives since that results + in two bfds worth of memory in use. + + * nm.c (display_rel_file): Call free_lineno_cache here.. + (display_archive, display_file): ..not here. + +2024-12-12 Alan Modra + + tdata related object_p tidy for various formats + The aout object_p function copies any existing tdata. Apparently this + was done for hp300, an old target that is no longer supported. See + commit ebd241352942. This isn't useful for current sources, nor is it + necessary or useful any more to preserve tdata in object_p functions + when a target doesn't match. When I was fixing this, I noticed some + object_p functions rudely didn't release memory on failures, and + others had nits in the bfd_error returns. + + * aoutx.h (some_aout_object_p): Don't restore previous tdata + on failure. Don't copy any existing tdata. + * archive.c (bfd_generic_archive_p): Don't restore previous + tdata on failure. + * pdp11.c (some_aout_object_p): Likewise. + * coff-rs6000.c (_bfd_xcoff_archive_p): Allocate both artdata + and extension in one call. Don't restore previous tdata on + failure. + * coff64-rs6000.c (xcoff64_archive_p): Likewise. + * coffgen.c (coff_real_object_p): Don't restore previous + tdata on failure. + * ihex.c (ihex_object_p): Likewise. Simplify release of tdata + on scan failure. + * mach-o.c (bfd_mach_o_scan): Don't set tdata here. Do set + error on read_command failure. + (bfd_mach_o_header_p): Set tdata here, release on failure. + Tidy bfd_error return values. + (bfd_mach_o_fat_archive_p): Tidy error return values. + * mmo.c (mmo_mkobject): Do not test current tdata. + * pef.c (bfd_pef_scan_start_address): Set bfd_error on + failure. + (bfd_pef_scan): Don't set tdata here. + (bfd_pef_object_p): Set tdata here, release on failure. Tidy + bfd_error return values. + (bfd_pef_xlib_object_p): Tidy bfd_error return values. + * srec.c (srec_object_p): Don't restore previous tdata on + failure. Do release tdata on failure. + (symbolsrec_object_p): Likewise. + * tekhex.c (tekhex_object_p): Don't ignore tekhex_mkobject + failure. Release tdata on failure. + * vms-alpha.c (alpha_vms_object_p): Don't restore previous + tdata on failure. Simplify release of tdata. + * xsym.c (bfd_sym_scan): Don't set tdata here. + (bfd_sym_object_p): Set tdata here. Release on failure. + +2024-12-12 GDB Administrator + + Automatic date update in version.in + +2024-12-11 Tom Tromey + + Fix gdbreplay checksum calculation + I needed to use gdbreplay today. It didn't work quite right, and + using "set debug remote 1" showed that gdb was rejecting some + responses like: + + [remote] Sending packet: $vCont?#49 + [remote] Junk: #vCont? + [remote] Junk: 8vCont? + [remote] Junk: 3vCont? + [remote] Received Ack + + The checksum recalculation seems to have gone wrong. Looking at the + code, it seems like 'where_csum' is calculated inconsistently: in the + main loop it is after the '#' but in the "== 0" case it is before the + '#'. + + This patch fixes the problem and also avoids a string copy. + + CC: Alexandra Hájková + Approved-By: Andrew Burgess + +2024-12-11 Alexandra Hájková + + dwarf_lang_to_enum_language: Map new DWARF5 constants + Add new DWARF5 language codes to gdb/dwarf2/read.c where + they are converted to GDB language names. The codes + were added to include/dwarf.h by syncing with gcc, Ada language + codes were added to dwarf.h earlier. + + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2024-12-11 Jens Remus + + gdb: s390: Correct record/replay of may/mayr insn + The IBM z/Architecture Principles of Operation [1] specifies that the + R1 operand of the may and mayr instructions designates may designate + either the lower- or higher-numbered register of a floating-point- + register (FPR) pair. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + gdb/ + * s390-tdep.c (s390_process_record): may/mayr operand R1 may + designate lower- or higher numbered register of FPR pair. + +2024-12-11 GDB Administrator + + Automatic date update in version.in + +2024-12-10 Vladimir Mezentsev + + gprofng: fix sorting in Hist_data::sort + If the '-name soname' option is used, the fake '' function is expanded + with the name loadobject. + + gprofng/ChangeLog + 2024-12-09 Vladimir Mezentsev + + * src/Hist_data.cc (Hist_data::sort): Fix sorting. + +2024-12-10 Tom de Vries + + [gdb/testsuite] Use setVariable in gdb.dap/scopes.exp + The test-case gdb.dap/scopes.exp contains the following outdated comment: + ... + # setVariable isn't implemented yet, so use the register name. + ... + + Now that setVariable is implemented, use it to set variable scalar, and remove + the bit that sets the first register. That part is known to fail on s390x, + because the first register isn't writeable [1]. + + Tested on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html + +2024-12-10 Tom de Vries + + [gdb/testsuite] Fix gdb.dap/step-out.exp on s390x + With test-case gdb.dap/step-out.exp on s390x-linux, I get: + ... + >>> {"seq": 7, "type": "request", "command": "scopes", "arguments": {"frameId": 0}} + Content-Length: 569^M + ^M + {"request_seq": 7, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 1, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 114, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}]}, "success": true, "seq": 21}PASS: gdb.dap/step-out.exp: get scopes success + FAIL: gdb.dap/step-out.exp: three scopes + ... + + The problem is that the test-case expects three scopes: + ... + lassign $scopes scope reg_scope return_scope + ... + but the return_scope is missing because this doesn't work: + ... + $ gdb -q -batch outputs/gdb.dap/step-out/step-out \ + -ex "b function_breakpoint_here" \ + -ex run \ + -ex finish + ... + Value returned has type: struct result. Cannot determine contents + ... + + This is likely caused by a problem in gdb, but there's nothing wrong the DAP + support. + + Fix this by: + - allowing two scopes, and + - declaring the tests of return_scope unsupported. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2024-12-10 Tom de Vries + + [gdb/testsuite] Fix fails in gdb.python/py-arch-reg-groups.exp + Since commit e69d35f45e0 ("Use ui-out table in "maint print reggroups""), + test-case gdb.python/py-arch-reg-groups.exp fails with check-read1: + ... + FAIL: $exp: Same number of registers groups found + FAIL: $exp: all register groups match + ... + + Fix this by adding a gdb_test_multiple clause that matches the command. + + Tested on x86_64-linux. + +2024-12-10 WANG Xuerui + + LoongArch: Default to a maximum page size of 64KiB + As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1), + LoongArch machines are not limited in page size choices, and currently + page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux. + While 16KiB is the most common, the current BFD code says it is the + maximum; this is not correct, and as an effect, almost all existing + binaries are incompatible with a 64KiB kernel because the sections are + not sufficiently aligned, while being totally fine otherwise. + This is needlessly complicating integration testing [1]. + + This patch fixes the inconsistency, and also brings BFD behavior in line + with that of LLD [2]. + + [1] https://github.com/loongson-community/discussions/issues/47 + [2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183 + + bfd/ + * elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB. + (ELF_MINPAGESIZE): Define as 4KiB. + (ELF_COMMONPAGESIZE): Define as 16KiB. + + ld/ + * testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after + changing the target max page size to 64KiB. + * testsuite/ld-loongarch-elf/data-got.d: Likewise. + * testsuite/ld-loongarch-elf/desc-relex.d: Likewise. + * testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise. + * testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work + as intended by not checking exact instruction words. + * testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise. + +2024-12-10 GDB Administrator + + Automatic date update in version.in + +2024-12-09 Alan Modra + + Re: gprofng: use gprofng- prefix for gprofng binaries + Commit d25ba4596e85 mangled ZLIBINC to ZLIgp-C. Fix that. + +2024-12-09 Peter Bergner + + PowerPC: Disallow r0 as a base register for the hashst and hashchk insns + Using r0 as a base address register in the ROP hashst and hashchk instructions + is invalid. Modify the assembler to catch that illegal use and emit an error. + + opcodes/ + * ppc-opc.c (insert_ras): Update error message and function comment. + (powerpc_opcodes) : Use RAS. + +2024-12-09 Tom Tromey + + Introduce NoOpStringPrinter + We discovered that attempting to print a very large string-like array + would succeed on the CLI, but in DAP would cause the "variables" + request to fail with: + + value requires 67038491 bytes, which is more than max-value-size + + This turns out to be a limitation in Value.format_string, which + de-lazy-ifies the value. + + This patch fixes this problem by introducing a new NoOpStringPrinter + class, and then using it for string-like values. This printer returns + a lazy string, which solves the problem. + + Note there are some special cases where we do not want to return a + lazy string. I've documented these in the code. I considered making + gdb.Value.lazy_string handle these cases -- for example it could + return 'self' rather than a lazy string in some situations -- but this + approach was simpler. + +2024-12-09 Tom Tromey + + Clean up 0-length handling in gdbpy_create_lazy_string_object + gdbpy_create_lazy_string_object will throw an exception if you pass it + a NULL pointer without also setting length=0 -- the default, + length==-1, will fail. This seems bizarre. Furthermore, it doesn't + make sense to do this check for array types, as an array can have a + zero length. This patch cleans up the check and makes it specific to + TYPE_CODE_PTR. + +2024-12-09 Tom Tromey + + Reject non-string types in gdb.Value.lazy_string + Currently, gdb.Value.lazy_string will allow the conversion of any + object to a "lazy string". However, this was never the intent and is + weird besides. This patch changes this code to correctly throw an + exception in the non-matching cases. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20769 + +2024-12-09 Tom Tromey + + Fix error check in gdb_py_test_silent_cmd + I added a new test using gdb_py_test_silent_cmd, and then was + surprised to find out that the new test passed -- it caused a Python + exception and I had expected it to fail. This patch fixes this proc + to detect this situation and fail. + +2024-12-09 Tom Tromey + + Omit artificial symbols from DAP variables response + While testing DAP, we found a situation where a compiler-generated + variable caused the "variables" request to fail -- the variable in + question being an apparent 67-megabyte string. + + It seems to me that artificial variables like this aren't interesting + to DAP users, and the gdb CLI omits these as well. + + This patch changes DAP to omit these variables, adding a new + gdb.Symbol.is_artificial attribute to make this possible. + +2024-12-09 Tom Tromey + + Defer DAP launch command until after configurationDone + PR dap/32090 points out that gdb's DAP "launch" sequencing is + incorrect. The current approach (which is itself a 2nd + implementation...) was based on a misreading of the spec. The spec + has since been clarified here: + + https://github.com/microsoft/debug-adapter-protocol/issues/497 + + The clarification here is that a client is free to send the "launch" + (or "attach") request at any point after the "initialized" event has + been sent by gdb. However, the "launch" does not cause any action to + be taken -- and does not send a response -- until after + "configurationDone" has been seen. + + This patch implements this by arranging for the launch and attach + commands to return a DeferredRequest object. + + All the tests needed updates. I've also added a new test that checks + that the deferred "launch" request can be cancelled. (Note that the + cancellation is lazy -- it also waits until configurationDone is seen. + This could be fixed, but I was not sure whether it is important to do + so.) + + Finally, the "launch" command has a somewhat funny sequencing now. + Simply sending the command and waiting for a response yielded strange + results if the inferior did not stop -- in this case, the repsonse was + never sent. So now, the command is split into two parts, with some + setup being done synchronously (for better error propagation) and the + actual "run" being done async. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090 + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Add DAP deferred requests + This adds a new "deferred request" capability to DAP. The idea here + is that if a request returns a DeferredRequest object, then no + response is sent immediately to the client. Instead, the request is + pending until the deferred request is rescheduled. + + Some minor refactorings, particularly in cancellation, were needed to + make this work. + + There's no use of this in the tree yet -- that is the next patch. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Allow cancellation of DAP-thread requests + This patch started as an attempt to fix the comment in + CancellationHandler.cancel, but while working on it I found that the + code could be improved as well. + + The current DAP cancellation code only handles the case where work is + done on the gdb thread -- by checking for cancellation in + interruptable_region. This means that if a request is handled + completely in tthe DAP thread, then cancellation will never work. + + Now, this isn't a bug per se. DAP doesn't actually require that + cancellation succeed. In fact, I think it can't, because cancellation + is inherently racy. + + However, a coming patch will add a sort of "pending" request, and it + would be nice if that were cancellable before any commands are sent to + the gdb thread. + + No test in this patch, but one will arrive at the end of the series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Refactor CancellationHandler in DAP + This refactors the DAP CancellationHandler to be a context manager, + and reorganizes the caller to use this. This is a bit more robust and + also simplifies a subsequent patch in this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Add call_function_later to DAP + This adds a new call_function_later API to DAP. This arranges to run + a function after the current request has completed. This isn't used + yet, but will be at the end of this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Reimplement DAP delayed events + This patch changes how delayed events are implemented in DAP. The new + implementation makes it simpler to add a delayed function call, which + will be needed by the final patch in this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Reimplement DAP's stopAtBeginningOfMainSubprogram + Right now, stopAtBeginningOfMainSubprogram is implemented "by hand", + but then later the launch function uses "starti" to implement + stopOnEntry. This patch unifies this code and rewrites it to use + "start" when appropriate. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom de Vries + + [gdb/symtab] Apply workaround for PR gas/31115 a bit more + In commit 8a61ee551ce ("[gdb/symtab] Workaround PR gas/31115"), I applied a + workaround for PR gas/31115 in read_func_scope, fixing test-case + gdb.arch/pr25124.exp. + + Recently I noticed that the test-case is failing again. + + Fix this by factoring out the workaround into a new function fixup_low_high_pc + and applying it in dwarf2_die_base_address. + + While we're at it, do the same in dwarf2_record_block_ranges. + + Tested on arm-linux with target boards unix/-marm and unix/-mthumb. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-12-09 Tom de Vries + + [gdb/syscalls] Generate aarch64-linux.xml.in in update-linux-from-src.sh + Currently aarch64-linux.xml.in is skipped by update-linux-from-src.sh: + ... + $ ./update-linux-from-src.sh ~/upstream/linux-stable.git/ + Skipping aarch64-linux.xml.in, no syscall.tbl + ... + $ + ... + and instead we use update-linux.sh. + + This works fine, but requires an aarch64 system with recent system headers, + which makes it harder to pick up the latest changes in the linux kernel. + + Fix this by updating ./update-linux-from-src.sh to: + - build the linux kernel headers for aarch64 + - use update-linux.sh with those headers to generate + aarch64-linux.xml.in. + + Regenerating aarch64-linux.xml.in using current trunk of linux-stable gives me + these changes: + ... + + + + + + + + + ... + which are the same changes I see for the other architectures. + + Note that the first step, building the linux kernel headers is a cross build + and should work on any architecture. + + But the second step, update-linux.sh uses plain gcc rather than a cross-gcc, + so there is scope for problems, but we seem to get away with this on + x86_64-linux. + + So, while we could constrain this to only generate aarch64-linux.xml.in on + aarch64-linux, I'm leaving this unconstrained. + + For aarch64-linux.xml.in, this doesn't matter much to me because I got an + aarch64-linux system. + + But I don't have a longaarch system, and the same approach seems to work + there. I'm leaving this for follow-up patch though. + + Tested on aarch64-linux and x86_64-linux. Verified with shellcheck. + +2024-12-09 Mark Wielaard + + Include gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c + Commit c8889b913175 ("gdb, gdbserver, gdbsupport: remove some unused + gdb_vecs.h includes") removed gdbsupport/gdb_vecs.h from various + header files. This caused an compile issue for gdb/s390-linux-nat.c + + ../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_watchpoint(CORE_ADDR, int, target_hw_bp_type, expression*)’: + ../../binutils-gdb/gdb/s390-linux-nat.c:875:11: error: ‘unordered_remove’ was not declared in this scope + 875 | unordered_remove (state->watch_areas, ix); + | ^~~~~~~~~~~~~~~~ + ../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_hw_breakpoint(gdbarch*, bp_target_info*)’: + ../../binutils-gdb/gdb/s390-linux-nat.c:928:11: error: ‘unordered_remove’ was not declared in this scope + 928 | unordered_remove (state->break_areas, ix); + | ^~~~~~~~~~~~~~~~ + + Fix this by including gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c. + +2024-12-09 Tankut Baris Aktemur + + gdbserver: remove 'struct' in 'struct thread_info' declarations + Remove the 'struct' keyword in occurrences of 'struct thread_info'. + This is a code clean-up. + + Tested by rebuilding. + + Approved-By: Simon Marchi + +2024-12-09 Nick Clifton + + Add linker diagnostic message about missing static libraries + +2024-12-09 Andrew Burgess + + gdb: allow core file containing special characters on the command line + After the commit: + + commit 03ad29c86c232484f9090582bbe6f221bc87c323 + Date: Wed Jun 19 11:14:08 2024 +0100 + + gdb: 'target ...' commands now expect quoted/escaped filenames + + it was no longer possible to pass GDB the name of a core file + containing any special characters (white space or quote characters) on + the command line. For example: + + $ gdb -c /tmp/core\ file.core + Junk after filename "/tmp/core": file.core + (gdb) + + The problem is that the above commit changed the 'target core' command + to expect quoted filenames, so before the above commit a user could + write: + + (gdb) target core /tmp/core file.core + [New LWP 2345783] + Core was generated by `./mkcore'. + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x0000000000401111 in ?? () + (gdb) + + But after the above commit the user must write: + + (gdb) target core /tmp/core\ file.core + + or + + (gdb) target core "/tmp/core file.core" + + This is part of a move to make GDB's filename argument handling + consistent. + + Anyway, the problem with the '-c' command line flag is that it + forwards the filename unmodified through to the 'core-file' command, + which in turn forwards to the 'target core' command. + + So when the user, at a shell writes: + + $ gdb -c "core file.core" + + this arrives in GDB as the unquoted string 'core file.core' (without + the single quotes). GDB then forwards this to the 'core-file' + command as if the user had written this at a GDB prompt: + + (gdb) core-file core file.core + + Which then fails to parse due to the unquoted white space between + 'core' and 'file.core'. + + The solution I propose is to escape any special characters in the core + file name passed from the command line before calling 'core-file' + command from main.c. + + I've updated the corefile.exp test to include a test for passing a + core file containing a white space character. While I was at it I've + modernised the part of corefile.exp that I was touching. + +2024-12-09 Andrew Burgess + + gdb: make core_target_open static + The core_target_open function is only used in corelow.c, so lets make + it static. + + There should be no user visible changes after this commit. + +2024-12-09 Andrew Burgess + + gdb: use 'const' more in a couple of small breakpoint functions + Make the 'struct breakpoint *' argument 'const' in user_breakpoint_p + and pending_breakpoint_p. And make the 'struct bp_location *' + argument 'const' in bl_address_is_meaningful. + + There should be no user visible changes after this commit. + +2024-12-09 Lulu Cai + + LoongArch: Assign DWARF register numbers to register aliases + .cfi directives only support the use of register numbers and not + register names or aliases. + + This commit adds support for 4 formats, for example: + .cfi_offset r1, 8 + .cfi_offset ra, 8 + .cfi_offset $r1,8 + .cfi_offset $ra,8 + + The above .cfi directives are equivalent and all represent dwarf + register number 1. + + Display register aliases as specified in the psABI during disassembly. + +2024-12-09 GDB Administrator + + Automatic date update in version.in + +2024-12-08 GDB Administrator + + Automatic date update in version.in + +2024-12-07 Simon Marchi + + gdbserver: simplify win32 process removal + In the spirit of encapsulation, I'm looking to remove the need for + external code to access the "ptid -> thread" map of process_info, making + it an internal implementation detail. The only remaining use is in + function clear_inferiors, and it led me down this rabbit hole: + + - clear_inferiors is really only used by the Windows port and doesn't + really make sense in the grand scheme of things, I think (when would + you want to remove all threads of all processes, without removing + those processes?) + + - ok, so let's remove clear_inferiors and inline the code where it's + called, in function win32_clear_inferiors + + - the Windows port does not support multi-process, so it's not really + necessary to loop over all processes like this: + + for_each_process ([] (process_info *process) + { + process->thread_list ().clear (); + process->thread_map ().clear (); + }); + + We could just do: + + current_process ()->thread_list ().clear (); + current_process ()->thread_map ().clear (); + + (or pass down the process from the caller, but it's not important + right now) + + - so, the code that we've inlined in win32_clear_inferiors does 3 + things: + + - clear the process' thread list and map (which deletes the + thread_info objects) + + - clear the dll list, which just basically frees some objects + + - switch to no current process / no current thread + + - let's now look at where this win32_clear_inferiors function is used: + + - in win32_process_target::kill, where the process is removed just + after + + - in win32_process_target::detach, where the process is removed + just after + + - in win32_process_target::wait, when handling a process exit. + After this returns, we could be in handle_target_event (if async) + or resume (if sync), both in `server.cc`. In both of these + cases, target_mourn_inferior gets called, we end up in + win32_process_target::mourn, which removes the process + + - in all 3 cases above, we end up removing the process, which takes + care of the 3 actions listed above: + + - the thread list and map get cleared when the process gets + destroyed + + - same with the dll list + + - remove_process switches to no current process / current thread + if the process being removed is the current one + + - I conclude that it's probably unnecessary to do the cleanup in + win32_clear_inferiors, because it's going to get done right after + anyway. + + Therefore, this patch does: + + - remove clear_inferiors, remove the call in win32_clear_inferiors + + - remove clear_dlls, which is now unused + + - remove process_info::thread_map, which is now unused + + - rename win32_clear_inferiors to win32_clear_process, which seems more + accurate + + win32_clear_inferiors also does: + + for_each_thread (delete_thread_info); + + which also makes sure to delete all threads, but it also deletes the + Windows private data object (windows_thread_info), so I'll leave this + one there for now. But if we could make the thread private data + destruction automatic, on thread destruction, it could be removed, I + think. + + There should be no user-visible change with this patch. Of course, + operations don't happen in the same order as before, so there might be + some important detail I'm missing. I'm only able to build-test this, if + someone could give it a test run on Windows, it would be appreciated. + + Change-Id: I4a560affe763a2c965a97754cc02f3083dbe6fbf + +2024-12-07 GDB Administrator + + Automatic date update in version.in + +2024-12-06 Alan Modra + + fix dependencies for ld/emultemp/nto.em + Don't use "." to source .em files, use "source_em". + +2024-12-06 Simon Marchi + + gdb: make objfile::make actually use its pspace parameter + Fix an oversight in commit 8991986e2413 ("gdb: pass program space to + objfile::make"). + + Change-Id: I263eec6e94dde0a9763f831d2d87b4d300b6a36a + +2024-12-06 Simon Marchi + + gdb, gdbserver, gdbsupport: remove some unused gdb_vecs.h includes + Remove some includes reported as unused by clangd. Add some to files + that actually need it. + + Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363 + +2024-12-06 Guinevere Larsen + + gdb: Fix use-after-free when an objfile has no symbols to load + The recent commit moved an initialization of an objfile_holder in + syms_from_objfile_1 much earlier in the function, to better deal with + when GDB is unable to read the objfile format. + + However, there is an early exit from syms_from_objfile_1 when the + objfile can be understood, but has no symbols. That was not releasing + the objfile_holder, so the objfile was being unlinked from the program + space, but the process of reading the objfile was being continued, + leading to use-after-frees flagged by the Address Sanitizer. + + This commit fixes that UAF by making the objfile_holder release the + objfile right before the early exit. + + This commit also changes the test gdb.base/dump.exp since that was the + original test that flagged the UAF, but at the end of the test the + generated files were being deleted, meaning we couldn't redo the test + manually after the fact. That final deletion was removed + + Reported-by: Simon Marchi + Approved-By: Simon Marchi + +2024-12-06 Hannes Domani + + Reduce WOW64 code duplication + Currently we have duplicate code for each place where + windows_thread_info::context is touched, since for WOW64 processes + it has to do the equivalent with wow64_context instead. + + For example this code...: + + #ifdef __x86_64__ + if (windows_process.wow64_process) + { + th->wow64_context.ContextFlags = WOW64_CONTEXT_ALL; + CHECK (Wow64GetThreadContext (th->h, &th->wow64_context)); + ... + } + else + #endif + { + th->context.ContextFlags = CONTEXT_DEBUGGER_DR; + CHECK (GetThreadContext (th->h, &th->context)); + ... + } + + ...changes to look like this instead: + + windows_process.with_context (th, [&] (auto *context) + { + context->ContextFlags = WindowsContext::all; + CHECK (get_thread_context (th->h, context)); + ... + } + + The actual choice if context or wow64_context are used, is handled by + this new function in windows_process_info: + + template + auto with_context (windows_thread_info *th, Function function) + { + #ifdef __x86_64__ + if (wow64_process) + return function (th != nullptr ? th->wow64_context : nullptr); + else + #endif + return function (th != nullptr ? th->context : nullptr); + } + + The other parts to make this work are the templated WindowsContext class + which give the appropriate ContextFlags for both types. + And there are also overloaded helper functions, like in the case of + get_thread_context here, call either GetThreadContext or + Wow64GetThreadContext. + + According git log --stat, this results in 120 lines less code. + + Approved-By: Tom Tromey + +2024-12-06 H.J. Lu + + gold: Update expected outputs in testsuite/pr26936.sh + Update expected outputs in testsuite/pr26936.sh to match the assembler + outputs changed by: + + a96a8b7367b2cd51ff32c69e516dfbe0204c8008 is the first bad commit + commit a96a8b7367b2cd51ff32c69e516dfbe0204c8008 (HEAD) + Author: Jan Beulich + Date: Mon Dec 2 09:38:47 2024 +0100 + + x86: always set ISA_1_BASELINE property for 64-bit objects + + PR gold/32422 + * testsuite/pr26936.sh: Updated. + +2024-12-06 Nelson Chu + + RISC-V: PR27566, consider ELF_MAXPAGESIZE/COMMONPAGESIZE for gp relaxations. + For default linker script, if a symbol's value outsides the bounds of the + defined section, then it may cross the data segment alignment, so we should + reserve more size about MAXPAGESIZE and COMMONPAGESIZE when doing gp + relaxations. Otherwise we may meet the truncated errors since the data + segment alignment might move the section forward. + + bfd/ + PR 27566 + * elfnn-riscv.c (_bfd_riscv_relax_lui): Consider MAXPAGESIZE and + COMMONPAGESIZE if the symbol's value outsides the bounds of the + defined section. + (_bfd_riscv_relax_pc): Likewise. + ld/ + PR 27566 + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + * testsuite/ld-riscv-elf/relax-data-segment-align*: New testcase + for pr27566. Without this patch, the rv32 binutils will meet + truncated errors for this testcase. + +2024-12-06 GDB Administrator + + Automatic date update in version.in + +2024-12-05 Simon Marchi + + gdbserver/win32-low.cc: remove use of `all_threads` + Fix this: + + gdbserver/win32-low.cc: In function ‘void child_delete_thread(DWORD, DWORD)’: + gdbserver/win32-low.cc:192:7: error: ‘all_threads’ was not declared in this scope; did you mean ‘using_threads’? + 192 | if (all_threads.size () == 1) + | ^~~~~~~~~~~ + | using_threads + + Commit 9f77b3aa0bfc ("gdbserver: change 'all_processes' and + 'all_threads' list type") changed the type of `all_thread` to an + intrusive_list, without changing this particular use, which broke the + build because an intrusive_list doesn't know its size, so it doesn't + have a `size()` method. The subsequent commit removed `all_threads`, + leading to the error above. + + Fix it by using the number of threads of the concerned process instead. + My rationale: as far as I know, GDBserver on Windows only supports one + process at a time, so there's no need to iterate over all processes. If + we made GDBserver for Windows support multiple processes, my intuition + is that we'd want this check to use the number of threads of the + concerned process, not the number of threads overall. + + Add the method `process_info::thread_count`, to get the number of + threads of the process. + + I'm not really sure what this check is for in the first place, Hannes + Domani said that this check didn't seem to trigger on Windows 7 and 11. + Perhaps it was necessary before. + + Change-Id: I84d6226532b887d99248cf3be90f5065fb7a074a + Tested-By: Hannes Domani + +2024-12-05 Simon Marchi + + gdbserver: add and use `process_info::find_thread(ptid)` + Add an overload of `process_info::find_thread` that finds a thread by + ptid. Use it in two spots. + + Change-Id: I2b7fb819bf4f83f7bd37f8641c38e878119b3814 + +2024-12-05 Nick Clifton + + Fix clang compile time warning about optarg parameter shadowing optarg global variable. + +2024-12-05 Hu, Lin1 + Zewei Mo + Haochen Jiang + Levy Hsu + + Support Intel AVX10.2 satcvt instructions + In this patch, we will support AVX10.2 satcvt instructions. All of them + are new instruction forms. In current documentation, it is still + VCVTTNEBF162I[,U]BS, but it will change to VCVTTBF162I[,U]BS eventually. + + In table part, we used temporary iterator to reduce redundancy. + It definitely could be done for legacy cvt insns, but it is out of this + patch's scope. + + gas/ChangeLog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt-intel.d: New test. + * testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_68, PREFIX_EVEX_MAP5_69, + PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B, PREFIX_EVEX_MAP5_6C, + PREFIX_EVEX_MAP5_6D. + * i386-dis-evex-w.h: Add EVEX_W_MAP5_6C_P_0, EVEX_W_MAP5_6C_P_2, + EVEX_W_MAP5_6D_P_0, EVEX_W_MAP5_6D_P_2. + * i386-dis-evex.h (prefix_table): Add PREFIX_EVEX_MAP5_68, + * PREFIX_EVEX_MAP5_69, PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B. + * i386-dis.c: (PREFIX_EVEX_MAP5_68): New. + (PREFIX_EVEX_MAP5_69): Ditto. + (PREFIX_EVEX_MAP5_6A): Ditto. + (PREFIX_EVEX_MAP5_6B): Ditto. + (PREFIX_EVEX_MAP5_6C): Ditto. + (PREFIX_EVEX_MAP5_6D): Ditto. + (EVEX_MAP5_6C_P_0): Ditto. + (EVEX_MAP5_6C_P_2): Ditto. + (EVEX_MAP5_6D_P_0): Ditto. + (EVEX_MAP5_6D_P_2): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-05 H.J. Lu + Haochen Jiang + + x86: Eliminate unnecessary {evex} prefixes + For several instructions including vps{l,r}l{d,q,w,dq} and vpsra{d,w}, + their VEX part do not have the following version: + + vpsrlw $0x1f,(%r15,%rcx,4),%xmm0 + + Thus, {evex} prefix should not be inserted when their second operand is + memory, while we still need them for register as second operand. Add a + new macro %ME to solve this problem. + + For vpsraq, there is no VEX version, so the {evex} prefix should always + be eliminated. + + gas/ChangeLog: + + PR binutils/32403 + * testsuite/gas/i386/i386.exp: Run new test. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/evex-only.d: New test. + * testsuite/gas/i386/evex-only.s: Ditto. + * testsuite/gas/i386/x86-64-evex-only.d: Ditto. + * testsuite/gas/i386/x86-64-evex-only.s: Ditto. + + opcodes/ChangeLog: + + PR binutils/32403 + * i386-dis-evex-reg.h: Use %ME instead of %XE for vps{l,r}l{w,dq} + and vpsraw. Split table for vpsra{d,q}. + * i386-dis-evex-w.h: Use %ME instead of %XE for vps{l,r}l{d,q} + and vpsrad. Eliminate vpsraq {evex} prefix. + * i386-dis-evex.h: Split table for vpsra{d,q}. + * i386-dis.c: (EVEX_W_0F72_R_4): New. + (EVEX_W_0FE2): Ditto. + (struct dis386): Add comment for %ME. + (putop): Handle %ME. + +2024-12-05 GDB Administrator + + Automatic date update in version.in + +2024-12-04 Andrew Burgess + + gdb: fix parsing of DIEs with both low/high pc AND ranges attributes + After the commit: + + commit b9de07a5ff74663ff39bf03632d1b2ea417bf8d5 + Date: Thu Oct 10 11:37:34 2024 +0100 + + gdb: fix handling of DW_AT_entry_pc of inlined subroutines + + GDB's buildbot CI testing highlighted this assertion failure: + + (gdb) c + Continuing. + ../../binutils-gdb/gdb/block.h:203: internal-error: set_entry_pc: Assertion `start >= this->start () && start < this->end ()' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + FAIL: gdb.base/break-probes.exp: run til our library loads (GDB internal error) + + This assertion was in the new function set_entry_pc and is asserting + that the default_entry_pc() value is within the blocks start/end + range. + + The default_entry_pc() is the value GDB will use as the entry-pc if + the DWARF doesn't specifically override the entry-pc. This value is + calculated as: + + 1. The start address of the first sub-range within the block, if the + block has more than 1 range, or + + 2. The low address (from DW_AT_low_pc) for the block. + + If the block only has a single range then this means the block was + defined with low/high pc attributes (case #2 above). These low/high + pc values are what block::start() and block::end() return. This means + that by definition, if the block is continuous, the above assert + cannot trigger as 'start', the default_entry_pc() would be equivalent + to block::start(). + + This means that, for the assert to trigger, the block must have + multiple ranges, and the first address of the first range is not + within the blocks low/high address range. This seems wrong. + + I inspected the state at the time the assert triggered and discovered + the block's start() address. Then I removed the assert and restarted + GDB. I was now able to inspect the blocks at the offending address: + + (gdb) maintenance info blocks 0x7ffff7dddaa4 + Blocks at 0x7ffff7dddaa4: + from objfile: [(objfile *) 0x44a37f0] /lib64/ld-linux-x86-64.so.2 + [(block *) 0x46b30c0] 0x7ffff7ddd5a0..0x7ffff7dde8a6 + entry pc: 0x7ffff7ddd5a0 + is global block + symbol count: 4 + is contiguous + [(block *) 0x46b3020] 0x7ffff7ddd5a0..0x7ffff7dde8a6 + entry pc: 0x7ffff7ddd5a0 + is static block + symbol count: 9 + is contiguous + [(block *) 0x46b2f70] 0x7ffff7ddda00..0x7ffff7dddac3 + entry pc: 0x7ffff7ddda00 + function: __GI__dl_find_dso_for_object + symbol count: 4 + is contiguous + [(block *) 0x46b2e10] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + inline function: __GI__dl_find_dso_for_object + symbol count: 5 + is contiguous + [(block *) 0x46b2a40] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + symbol count: 1 + is contiguous + [(block *) 0x46b2970] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + symbol count: 2 + address ranges: + 0x7ffff7ddda0e..0x7ffff7ddda77 + 0x7ffff7ddda90..0x7ffff7ddda96 + + I've left everything in for context, but the only really interesting + bit is the very last block, it's low/high range is: + + 0x7ffff7dddaa4..0x7ffff7dddac3 + + but it has separate ranges: + + 0x7ffff7ddda0e..0x7ffff7ddda77 + 0x7ffff7ddda90..0x7ffff7ddda96 + + which are all outside the low/high range. This is what triggers the + assert. But why does that block exist at all? + + What I believe is happening is that we're running into a bug in older + versions of GCC. The buildbot failure was with an 8.5 gcc, and Tom de + Vries also reported seeing failures when using version 7 and 8 gcc, + but not with gcc 9 and onward. + + Looking at the DWARF I can see that the problematic block is created + from this DIE: + + <4><15efb>: Abbrev Number: 83 (DW_TAG_lexical_block) + <15efc> DW_AT_abstract_origin: <0x15e9f> + <15efe> DW_AT_low_pc : 0x7ffff7dddaa4 + <15f06> DW_AT_high_pc : 31 + + which links via DW_AT_abstract_origin to: + + <2><15e9f>: Abbrev Number: 80 (DW_TAG_lexical_block) + <15ea0> DW_AT_ranges : 0x38e0 + <15ea4> DW_AT_sibling : <0x15eca> + + And so we can see that <15efb> has got both low/high pc attributes and + a ranges attribute. + + If I widen my checking to parents of DIE <15efb> then I see that they + also have DW_AT_abstract_origin, however, there is something + interesting going on, the parent DIEs are linking to a different DIE + tree than <15efb>. + + What I believe is happening is this, we have an abstract instance + tree, this is rooted at a DW_AT_subprogram, and contains all the + blocks, variables, parameters, etc, that you would expect. As this is + an abstract instance, then there are no low/high pc attributes, and no + ranges attributes in this tree. This makes sense. + + Now elsewhere we have a DW_TAG_subprogram (not + DW_TAG_inlined_subroutine) which links via + DW_AT_abstract_origin to the abstract DW_AT_subprogram. This case is + documented in the DWARF 5 spec in section 3.3.8.3, and describes an + Out-of-Line Instance of an Inlined Subroutine. Within this out of + line instance many of the DIE correctly link back, using + DW_AT_abstract_origin to the abstract instance tree. This tree also + includes the DIE <15e9f>, which is where our problem DIE references. + + Now, to really confuse things, within this out-of-line instance we + have a DW_TAG_inlined_subroutine, which is another instance of the + same abstract instance tree! This would seem to indicate a recursive + call to the inline function, and the compiler, for some reason, needed + to instantiate an out of line instance of this function. + + And it is within this nested, inlined subroutine, that the problem DIE + exists. The problem DIE is referencing the corresponding DIE within + the out of line instance tree, but I am convinced this must be a (long + fixed) GCC bug, and that the problem DIE should be referencing the DIE + within the abstract instance tree. + + I'm aware that the above is pretty confusing. The actual DWARF would + be a around 200 lines long, so I'd like to avoid dumping it in here. + But here's my attempt at representing what's going on in a minimal + example. The numbers down the side represent the section offset, not + the nesting level, and I've removed any attributes that are not + relevant: + + <1> DW_TAG_subprogram + <2> DW_TAG_lexical_block + <3> DW_TAG_subprogram + DW_AT_abstract_origin <1> + <4> DW_TAG_lexical_block + DW_AT_ranges ... + <5> DW_TAG_inlined_subroutine + DW_AT_abstract_origin <1> + <6> DW_TAG_lexical_block + DW_AT_abstract_origin <4> + DW_AT_low_pc ... + DW_AT_high_pc ... + + The lexical block at <6> is linking to <4> when it should be linking + to <2>. + + There is one additional thing that we might wonder about, which is, + when calculating the low/high pc range for a block, why does GDB not + make use of the range information and expand the range beyond the + defined low/high values? + + The answer to this is in dwarf_get_pc_bounds_ranges_or_highlow_pc in + dwarf/read.c. This is where the low/high bounds are calculated. What + we see is that GDB first checks for a low/high attribute pair, and if + that is present, this defines the address range for the block. Only + if there is no DW_AT_low_pc do we check for the DW_AT_ranges, and use + that to define the extent of the block. And this makes sense, section + 3.5 of the DWARF-5 spec says: + + The lexical block entry may have either a DW_AT_low_pc and DW_AT_high_pc + pair of attributes or a DW_AT_ranges attribute whose values encode the + contiguous or non-contiguous address ranges, respectively, of the machine + instructions generated for the lexical block... + + Section 3.5 is specifically about lexical blocks, but the same + wording, about it being either low/high OR ranges is repeated for + other DW_TAG_ types. + + So this explains why GDB doesn't use the ranges to expand the problem + blocks ranges; as the first DIE has low/high addresses, these are + used, and the ranges is not consulted. + + It is only later in dwarf2_record_block_ranges that we create a range + based off the low/high pc, and then also process the ranges data, this + allows the problem block to exist with ranges that are outside the + low/high range. + + To solve this I considered a number of options: + + 1. Prevent loading certain attributes from an abstract instance. + + Section 3.3.8.1 of the DWARF-5 spec talks about which attributes are + appropriate to place in an abstract instance. Any attribute that + might vary between instances should not appear in an abstract + instance. DW_AT_ranges is included as an example in the + non-exhaustive list of attributes that should not appear in an + abstract instance. + + Currently in dwarf2_attr (dwarf2/read.c), when we see a + DW_AT_abstract_origin attribute, we always follow this to try and find + the attribute we are looking for. But we could change this function + so that we prevent this following for attributes that we know should + not be looked up in an abstract instance. This would solve the + problem in this case by preventing us finding the DW_AT_ranges in the + incorrect abstract instance. + + 2. Filter the ranges. + + Having established a blocks low/high address range in + dwarf_get_pc_bounds_ranges_or_highlow_pc, we could allow + dwarf2_record_block_ranges to parse the ranges, but we could reject + any range that extends outside the blocks defined start and end + addresses. + + For well behaved DWARF where we have either low/high or ranges, then + the blocks start/end are defined from the range data, and so, by + definition, every range would be acceptable. + + But in our problem case we would reject all of the invalid ranges. + + This is my least favourite solution as it feels like rejecting the + ranges is tackling the problem too late on. + + 3. Don't try to parse ranges when we have low/high attributes. + + This option involves updating dwarf2_record_block_ranges to match the + behaviour of dwarf_get_pc_bounds_ranges_or_highlow_pc, and, I believe, + to match the DWARF spec: don't try to read range data from + DW_AT_ranges if we have low/high pc attributes. + + In our case this solves the issue because the problematic DIE has the + low/high attributes, and it then links to the wrong DIE which happens + to have DW_AT_ranges. With this change in place we don't even look + for the DW_AT_ranges. + + If the problem were reversed, and the initial DIE had DW_AT_ranges, + but the incorrectly referenced DIE had the low/high pc attributes, + we would pick up the wrong addresses, but this wouldn't trigger any + asserts. The reason is that dwarf_get_pc_bounds_ranges_or_highlow_pc + would also find the low/high addresses from the incorrectly referenced + DIE, and so we would just end up with a block which had the wrong + address ranges, but the block would be self consistent, which is + different to the problem we hit here. + + In the end, in this commit I went with solution #3, having + dwarf_get_pc_bounds_ranges_or_highlow_pc and + dwarf2_record_block_ranges be consistent seems sensible. However, I + do wonder if in the future we might want to explore solution #1 as an + additional safety feature. + + With this patch in place I'm able to run the gdb.base/break-probes.exp + without seeing the assert that CI testing highlighted. I see no + regressions when testing on x86-64 GNU/Linux with gcc 9.3.1. + + Note: the diff in this commit looks big, but it's really just me + indenting the code. + + Approved-By: Tom Tromey + +2024-12-04 Tom de Vries + + [gdb/tdep] Remove includes of gdbsupport/common-defs.h + In commit 18d2988e5da ("gdb, gdbserver, gdbsupport: remove includes of early + headers") all includes of gdbsupport/common-defs.h where removed, but + commit c1cdee0e2c1 ("gdb: LoongArch: Add support for hardware watchpoint") + reintroduced some. + + Fix this by removing them. + + Tested by doing this on x86_64-linux: + ... + $ make \ + nat/loongarch-hw-point.o \ + nat/loongarch-linux.o \ + nat/loongarch-linux-hw-point.o + CXX nat/loongarch-hw-point.o + CXX nat/loongarch-linux.o + CXX nat/loongarch-linux-hw-point.o + ... + + Approved-By: Simon Marchi + +2024-12-04 Simon Marchi + + [gdb/build] Fix build breaker on mingw-w64 + The mingw-w64 build breaks currently: + ... + In file included from gdb/cli/cli-cmds.c:58: + gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’: + gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \ + did you mean ‘gdb::waitpid’? + 77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); + | ^~~~~~~ + | gdb::waitpid + gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here + 75 | waitpid (pid_t pid, int *wstatus, int options) + | ^~~~~~~ + ... + + This is a regression since commit 658a03e9e85 ("[gdbsupport] Add + gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from + run_under_shell, where it was used conditionally: + ... + #if defined(CANT_FORK) || \ + (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK)) + ... + #else + ... + int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0); + ... + to gdb::waitpid, where it's used unconditionally: + ... + inline pid_t + waitpid (pid_t pid, int *wstatus, int options) + { + return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); + } + ... + + Likewise for ::wait. + + Guard these uses with HAVE_WAITPID and HAVE_WAIT. + + Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux. + + Reported-By: Simon Marchi + Co-Authored-By: Tom de Vries + +2024-12-04 Simon Marchi + + gdbserver: make thread_target_data a method of thread_info + Make the field private, change the free function to be a method. + + Change-Id: I05010e7d1bd58ce3895802eb263c029528427758 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: make thread_regcache_data / set_thread_regcache_data methods of thread_info + Make the field private, change the free functions to be methods. + + Change-Id: Ifd8ed2775dddefc73a0e00126182e1db02688af4 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: make get_thread_lwp a function + Replace the macro with a static inline function. + + Change-Id: I1cccf5b38d6a412d251763f0316902b07cc28d16 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: remove macro get_lwp_thread + I was thinking of changing this macro to a function, but I don't think + it adds much value over just accessing the field directly. + + Change-Id: I5dc63e9db0773549c5b55a1279212e2d1213f50c + Approved-By: Tom Tromey + +2024-12-04 Stephan Rohr + + gdb, testsuite: fix TCL error in 'gdb.base/structs.exp' + A failure of 'runto_main' in 'start_structs_test' results in a TCL + error. The return value of 'start_structs_test' function is evaluated + inside an if conditional clause, which expects a boolean value. Return + '-1' on failure to avoid the error. + + Reviewed-By: Keith Seitz + Approved-By: Tom Tromey + +2024-12-04 Tom de Vries + + [gdb/testsuite] Fix failure in gdb.python/py-startup-opt.exp + In commit 922ab963e1c ("[gdb/python] Handle empty PYTHONDONTWRITEBYTECODE") I + added a test in gdb.python/py-startup-opt.exp that checks the + "show python dont-write-bytecode" output. + + Then in commit 348290c7ef4 ("[gdb/python] Warn and ignore ineffective python + settings") I changed the output of "show python dont-write-bytecode" after + python initialization. + + I tested these changes individually, and found no problems but after + committing both the test started failing, which the Linaro CI reported. + + Fix this by updating the expected output. + + While we're at it, make the test a bit more generic by testing + "show python $setting" in all cases. + + Tested on x86_64-linux, using: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + +2024-12-04 Tom Tromey + + Fix "maint print" error messages + While working on an earlier patch, I noticed that all the + register-related "maint print" commands used the wrong command name in + an error message. This fixes them. + + Reviewed-by: Christina Schimpe + Approved-By: Andrew Burgess + +2024-12-04 Tom Tromey + + Use ui-out table in "maint print reggroups" + This changes the "maint print reggroups" command to use a ui-out table + rather than printf. + + It also fixes a typo I noticed in a related test case name; and lets + us finally remove the leading \s from the regexp in completion.exp. + + Reviewed-by: Christina Schimpe + Approved-By: Andrew Burgess + +2024-12-04 Tom Tromey + + Use ui-out tables in some "maint print" commands + This changes various "maint print" register commands to use ui-out + tables rather than the current printf approach. + + Approved-By: Andrew Burgess + +2024-12-04 GDB Administrator + + Automatic date update in version.in + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix DUPLICATE in gdb.arch/pr25124.exp + With test-case gdb.arch/pr25124.exp, I run into: + ... + PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) + PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try) + DUPLICATE: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try) + ... + + Fix this by using a comma instead of parentheses. + + Tested on arm-linux. + + Approved-By: Tom Tromey + +2024-12-03 Tom de Vries + + [gdb/python] Issue warning if python fails to initialize + A common problem is that python may fail to initialize if PYTHONHOME is + set incorrectly, or points to incompatible default libraries. + + Likewise if PYTHONPATH points to incompatible modules. + + For instance, say PYTHONHOME is foo, then we get: + ... + $ gdb -q + Python path configuration: + PYTHONHOME = 'foo' + PYTHONPATH = (not set) + program name = '/usr/bin/python' + isolated = 0 + environment = 1 + user site = 1 + safe_path = 0 + import site = 1 + is in build tree = 0 + stdlib dir = 'foo/lib64/python3.12' + sys._base_executable = '/usr/bin/python' + sys.base_prefix = 'foo' + sys.base_exec_prefix = 'foo' + sys.platlibdir = 'lib64' + sys.executable = '/usr/bin/python' + sys.prefix = 'foo' + sys.exec_prefix = 'foo' + sys.path = [ + 'foo/lib64/python312.zip', + 'foo/lib64/python3.12', + 'foo/lib64/python3.12/lib-dynload', + ] + Python Exception : No module named 'encodings' + Python not initialized + $ + ... + + In this case, it might be easy to figure out what went wrong because of the + obviously incorrect pathnames, but that might not be the case if PYTHONHOME + points to an incompatible python installation. + + Fix this by adding a warning with a description of the possible cause and what + to do about it: + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + gdb: warning: Python failed to initialize with PYTHONHOME set. Maybe because \ + it is set incorrectly? Maybe because it points to incompatible standard \ + libraries? Consider changing or unsetting it, or ignoring it using "set \ + python ignore-environment on" at early initialization. + ... + + Likewise for PYTHONPATH: + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + gdb: warning: Python failed to initialize with PYTHONPATH set. Maybe because \ + it points to incompatible modules? Consider changing or unsetting it, or \ + ignoring it using "set python ignore-environment on" at early \ + initialization. + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32379 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379 + +2024-12-03 Tom de Vries + + [gdb/python] Handle empty PYTHONDONTWRITEBYTECODE + When using PYTHONDONTWRITEBYTECODE with an empty string we get: + ... + $ PYTHONDONTWRITEBYTECODE= gdb -q -batch -ex "show python dont-write-bytecode" + Python's dont-write-bytecode setting is auto (currently on). + ... + + This is incorrect, it should be off. + + The actual setting is correct, that was already fixed in commit 24d2cbc42cc + ("set/show python dont-write-bytecode fixes"), in function + python_write_bytecode. + + Fix this by: + - factoring out new function env_python_dont_write_bytecode out of + python_write_bytecode, and + - using it in show_python_dont_write_bytecode. + + Tested on x86_64-linux, using test-case gdb.python/py-startup-opt.exp and: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + + Approved-By: Tom Tromey + + PR python/32389 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32389 + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-startup-opt.exp with empty PYTHONDONTWRITEBYTECODE + When running test-case gdb.python/py-startup-opt.exp with empty + PYTHONDONTWRITEBYTECODE: + ... + $ cd build/gdb/testsuite + $ PYTHONDONTWRITEBYTECODE= make check \ + RUNTESTFLAGS=gdb.python/py-startup-opt.exp + ... + I get: + ... + end^M + dont_write_bytecode is off^M + (gdb) FAIL: $exp: attr=dont_write_bytecode: testname: input 6: end + ... + + The problem is that the test-case expects dont_write_bytecode to be + on, which is incorrect because PYTHONDONTWRITEBYTECODE only has effect if set + to a non-empty string [1]. + + Fix this by correctly setting expectations in the test-case. + + Tested on x86_64-linux, with: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + + Approved-By: Tom Tromey + + [1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE + +2024-12-03 Tom de Vries + + [gdb/python] Warn and ignore ineffective python settings + Configuration flags "python dont-write-bytecode" and + "python ignore-environment" have effect only at Python initialization. + + For instance, setting "python dont-write-bytecode" here has no effect: + ... + $ gdb -q + (gdb) show python dont-write-bytecode + Python's dont-write-bytecode setting is auto (currently off). + (gdb) python import sys + (gdb) python print (sys.dont_write_bytecode) + False + (gdb) set python dont-write-bytecode on + (gdb) python print (sys.dont_write_bytecode) + False + ... + + This is not clear in the code: we set Py_DontWriteBytecodeFlag and + Py_IgnoreEnvironmentFlag in set_python_ignore_environment and + set_python_dont_write_bytecode. Fix this by moving the setting of those + variables to py_initialization. + + Furthermore, this is not clear to the user: after Python initialization, the + user can still modify the configuration flags, and observe the changed setting: + ... + $ gdb -q + (gdb) show python ignore-environment + Python's ignore-environment setting is off. + (gdb) set python ignore-environment on + (gdb) show python ignore-environment + Python's ignore-environment setting is on. + (gdb) + ... + + Fix this by emitting a warning when trying to set these configuration flags + after Python initialization: + ... + $ gdb -q + (gdb) set python ignore-environment on + warning: Setting python ignore-environment after Python initialization has \ + no effect, try setting this during early initialization + (gdb) set python dont-write-bytecode on + warning: Setting python dont-write-bytecode after Python initialization has \ + no effect, try setting this during early initialization, or try setting \ + sys.dont_write_bytecode + ... + and by keeping the values constant after Python initialization. + + Since the auto setting for python dont-write-bytecode depends on the current + value of environment variable PYTHONDONTWRITEBYTECODE, we simply avoid it + after Python initialization: + ... + $ gdb -q -batch \ + -eiex "show python dont-write-bytecode" \ + -iex "show python dont-write-bytecode" + Python's dont-write-bytecode setting is auto (currently off). + Python's dont-write-bytecode setting is off. + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32388 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32388 + +2024-12-03 Tom de Vries + + [gdb/python] Drop ATTRIBUTE_UNUSED on py_initialize_catch_abort + I added ATTRIBUTE_UNUSED to py_initialize_catch_abort as a quick fix to deal + with it being unused for PY_VERSION_HEX >= 0x030a0000, but forgot to fix this + before committing. + + Fix this now, by removing the attribute and using + '#if PY_VERSION_HEX < 0x030a0000' instead. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-12-03 Tom de Vries + + [gdb/python] Factor out and refactor py_initialize + Function do_start_initialization has a large part dedicated to initializing + the python interpreter, as opposed to the rest of the function where + gdb-specific python support is initialized. + + Factor out this part, as new function py_initialize, and rename the existing + py_initialize to py_initialize_catch_abort. + + Refactor the new function py_initialize by getting rid of the nested: + ... + #ifdef WITH_PYTHON_PATH + #if PY_VERSION_HEX < 0x030a0000 + #else + #endif + #else + #endif + ... + + In particular, this changes behaviour for the "!defined (WITH_PYTHON_PATH)" + case. + + For the "defined (WITH_PYTHON_PATH)" case, we've started using + Py_InitializeFromConfig () for PY_VERSION_HEX >= 0x030a0000 to deal with the + deprecation of Py_SetProgramName in 3.11. + + For the "!defined (WITH_PYTHON_PATH)" case, we don't use Py_SetProgramName so + we stuck with Py_Initialize (). + + However, in 3.12 Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag got + deprecated and also here we need Py_InitializeFromConfig () to deal with this, + but the "!defined (WITH_PYTHON_PATH)" case didn't get updated. + + This should be taken care of, now that we have this behavior: + - for PY_VERSION_HEX < 0x030a0000 we use Py_Initialize + - for PY_VERSION_HEX >= 0x030a0000 we use Py_InitializeFromConfig + + I'm not sure how to test the "!defined (WITH_PYTHON_PATH)" though. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-12-03 Simon Marchi + + gdb: restore nullptr check in compunit_symtab::find_call_site + Commit de2b4ab50de ("Convert dwarf2_cu::call_site_htab to new hash + table") removed this nullptr check for no good reason. This causes a + crash if `m_call_site_htab` is not set, as shown in PR 32410. My guess + is that when doing this change, I tried to make `m_call_site_htab` not a + pointer, removed this check, then realized it wasn't so obvious, and + forgot to re-add the check. + + Change-Id: I455e00cdc0519dfb412dc7826d17a839b77aae69 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32410 + Approved-By: Tom Tromey + Approved-By: Tom de Vries + +2024-12-03 Guinevere Larsen + + gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require avx + The test gdb.reverse/i386-avx-reverse.exp was assuming that if the CPU + was like x86, it would have AVX instructions because I didn't know how + to check for AVX instruction support explicitly. This commit updates + that to use the pre-existing TCL proc have_avx. + + Also update the comment at the top of the test, since it was a copy of a + different test. + + Approved-By: Andrew Burgess + +2024-12-03 Guinevere Larsen + + gdb/dbx: Remove stabsect_build_psymtab as it was unused + The function stabsect_build_psymtabs, defined in the dbxread file, is no + longer used in any parts of GDB, so this commit just removes it. + + Tested by rebuilding. + + Approved-By: Andrew Burgess + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp with --with-expat=no + When building gdb with --with-expat=no and running test-case + gdb.base/reset-catchpoint-cond.exp we get: + ... + (gdb) catch syscall write^M + warning: Can not parse XML syscalls information; \ + XML support was disabled at compile time.^M + Unknown syscall name 'write'.^M + (gdb) FAIL: $exp: mode=syscall: catch syscall write + ... + + Fix this by skipping the test for --with-expat=no. + + Tested on x86_64-linux. + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.python/python.exp with --disable-tui + When building gdb with --disable-tui, we run into: + ... + (gdb) python print(type(gdb.TuiWindow))^M + Python Exception : \ + module 'gdb' has no attribute 'TuiWindow'^M + Error occurred in Python: module 'gdb' has no attribute 'TuiWindow'^M + (gdb) FAIL: gdb.python/python.exp: gdb.TuiWindow is registered + ... + + Fix this by skipping the test for --disable-tui. + + Tested on x86_64-linux. + +2024-12-03 Guinevere Larsen + + gdb: fix crash when GDB can't read an objfile + If a user starts an inferior composed of objfiles that GDB is unable to + read, there is an error thrown in find_sym_fns, printing the famous "I'm + sorry, Dave, I can't do that" and the objfile stops being read. However, + the objfile will already have been linked to the program space, and + future interactions with the objfile will assume that it is readable. + + Relevant to this commit, if GDB tries to find out the section that + contains a PC, and this section happens to land in the unreadable + objfile, GDB will try to create a section mapping, eventually calling + update_section_map. Since that function uses bfd to calculate the + sections, it'll think there are sections to be ordered, but when trying + to access the objfile::section_offsets, it'll be indexing a size 0 + std::vector, which will end up segfaulting. + + Currently, it isn't easy to trigger this crash, but the upcoming + possibility to disable support for some file formats would make the + crash very easy to reproduce, by attempting to debug an unsupported + inferior and using "break *" command, or simply connecting + to a gdbserver loaded with an unsupported inferior. + + The struct objfile_up seems to have been created to catch these kinds of + errors and unlink the partially-read objfile from the program space, as + the objfile isn't useful to GDB anymore, but it seems to have been added + before find_sym_fns would throw errors for unreadable objfiles, as the + instance in syms_from_objfile_1 (that could save GDB from this crash) is + declared well after find_sym_fns, too late to guard us. This commit + moves the declaration up to the top of the function, so it works as + intended. + + Further discussion on the mailing list also agreed that the name + "objfile_up" implies some level of ownership of the pointer, which this + struct doesn't have. So this commit renames the struct to + scoped_objfile_unlinker, which is more descriptive of what the struct is + actually meant to do. + + The final change this commit does is add an assertion to + objfile::section_offset and objfile::set_section_offset, which ensures + that the section_offsets vector is large enough to return the desired + offset. This ensures that we won't misteriously segfault or worse, + continue going with garbage data. + + Reported-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-12-03 Jens Remus + + gas: Re-enable .org test 1 on all targets except kvx + It got erroneously disabled for all targets including kvx instead of + excluding kvx only. + + gas/testsuite/ + * gas/all/org-1.d: Re-enable on all targets except kvx. + + Fixes: 6e712424f5cb ("kvx: New port.") + +2024-12-03 Jens Remus + + s390: Enable .bss/.struct data allocation directives tests + This reduces the number of unsupported tests on s390 by two. + + gas/testsuite/ + * gas/elf/bss.d: Enable for s390*-*-*. + * gas/elf/bad-bss.d: Likewise. + +2024-12-03 Surya Kumari Jangala + + PowerPC: Add support for RFC02680 - PQC Acceleration Instructions + opcodes/ + * ppc-opc.c (powerpc_opcodes): Add xvadduwm, xvadduhm, xvsubuwm, + xvsubuhm, xvmuluwm, xvmuluhm, xvmulhsw, xvmulhsh, xvmulhuw, + xvmulhuh. + gas/ + * testsuite/gas/ppc/future.s: New test. + * testsuite/gas/ppc/future.d: Likewise. + +2024-12-03 Nick Clifton + + Updated Russian translation and new Malay translation for the BFD sub-directory + +2024-12-03 Lulu Cai + + LoongArch: Fix the infinite loop caused by calling undefweak symbol + The undefweak symbol value of non-default visibility is 0 and does + not use plt entry, and will not be relocated in the relocate_secion + function. As a result, an infinite loop is generated because + bl %plt(sym) => bl 0. + + Fix this by converting the call into a jump address 0. + +2024-12-03 Andrew Burgess + + gdb: fix comment for gdbarch_stack_grows_down + The comment for gdbarch_stack_grows_down was wrong. Fixed in this + commit. + + There should be no user visible changes after this commit. + +2024-12-03 Jan Beulich + + gas: partly restore how current_location() had worked + Commit 4a826962e760 changed its behavior without saying why, and without + putting in place any testcase demonstrating the required behavior. + Firmly latch the current position unless deferred-evaluation mode is in + effect. + + MMIX: use current_location() directly + It's no longer a static function, so it can be used without involving a + wrapper function plus an indirect function call. + +2024-12-03 Jan Beulich + + gas: streamline expr_build_dot() + There's no point involving symbol_clone_if_forward_ref(), just for it to + replace dot_symbol by one obtained from symbol_temp_new_now(). For the + abs-section case also produce a slightly more "complete" (as in: all + potentially relevant fields filled) expression by going through + expr_build_uconstant(). + + Move the function next to current_location(), for it to be easier to see + the (dis)similarities. Correct the function's comment while there. + +2024-12-03 Kong Lingling + Haochen Jiang + + Support Intel AVX10.2 BF16 instructions + In this patch, we will support AVX10.2 BF16 instructions. All of them + are new instructions forms. In current documentation, it is still + VSCALEFPBF16, but it will change to VSCALEFNEPBF16 eventually. + + In disassembler part, we added %XB to reduce W table pass since all + of them get evex.w=0. + + gas/Changelog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: New. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto. + + opcodes/ + + * i386-dis-evex-prefix.h: Update PREFIX_EVEX_0F3A08, PREFIX_EVEX_0F3A26, + PREFIX_EVEX_0F3A56, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3AC2, + PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, + PREFIX_EVEX_MAP5_59, PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, + PREFIX_EVEX_MAP5_5E, PREFIX_EVEX_MAP5_5F. + Add PREFIX_EVEX_MAP6_2C, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E, + PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C, + PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA, + PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8, + PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE. + * i386-dis-evex.h (evex_table): Update PREFIX_EVEX_MAP6_2C, + PREFIX_EVEX_MAP6_42, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E, + PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C, + PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA, + PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8, + PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE. + * i386-dis.c (PREFIX_EVEX_MAP6_2C): New enum. + (PREFIX_EVEX_MAP6_42): Ditto. + (PREFIX_EVEX_MAP6_4C): Ditto. + (PREFIX_EVEX_MAP6_4E): Ditto. + (PREFIX_EVEX_MAP6_98): Ditto. + (PREFIX_EVEX_MAP6_9A): Ditto. + (PREFIX_EVEX_MAP6_9C): Ditto. + (PREFIX_EVEX_MAP6_9E): Ditto. + (PREFIX_EVEX_MAP6_A8): Ditto. + (PREFIX_EVEX_MAP6_AA): Ditto. + (PREFIX_EVEX_MAP6_AC): Ditto. + (PREFIX_EVEX_MAP6_AE): Ditto. + (PREFIX_EVEX_MAP6_B8): Ditto. + (PREFIX_EVEX_MAP6_BA): Ditto. + (PREFIX_EVEX_MAP6_BC): Ditto. + (PREFIX_EVEX_MAP6_BE): Ditto. + (putop): Handle %XB. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-03 GDB Administrator + + Automatic date update in version.in + +2024-12-02 Simon Marchi + + gdb/configure.ac: remove elf_hp.h check + The comment says this is for HP/UX, which is no longer supported. There + should be no functional changes with this, since nothing checks + HAVE_ELF_HP_H. + + Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84 + +2024-12-02 Simon Marchi + + gdb, gdbserver, gdbsupport: flatten and sort some list in configure files + This makes the lists easier sort read and modify. There are no changes + in the generated config.h files, so I'm confident this brings no + functional changes. + + Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b + +2024-12-02 Matthieu Longo + + aarch64: add tests for combinations of GCS options and marked/unmarked inputs + + aarch64: add tests to check the correct merge of the GCS feature with others. + +2024-12-02 Srinath Parvathaneni + Matthieu Longo + Yury Khrustalev + + aarch64: GCS feature check in GNU note properties for input objects + This patch adds support for Guarded Control Stack in AArch64 linker. + + This patch implements the following: + 1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in + GNU_PROPERTY_AARCH64_FEATURE_1_AND macro. + + 2) Adds readelf support to read and print the GCS feature in GNU + properties in AArch64. + + Displaying notes found in: .note.gnu.property + [ ]+Owner[ ]+Data size[ ]+Description + GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 + Properties: AArch64 feature: GCS + + 3) Adds support for the "-z gcs" linker option and document all the values + allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is + equivalent to "-z gcs=always". When '-z gcs' option is omitted from the + command line, it defaults to "implicit" and relies on the GCS feature + marking in GNU properties. + + 4) Adds support for the "-z gcs-report" linker option and document all the + values allowed with this option (-z gcs-report[=none|warning|error]) where + "-z gcs-report" is equivalent to "-z gcs-report=warning". When this option + is omitted from the command line, it defaults to "warning". + + The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU + property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and + can be found in [1]. + + [1] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst + +2024-12-02 Matthieu Longo + + aarch64: rename BTI error/warning message + The previous message for missing BTI feature in GNU properties was + not very clear. The new message explains that a missing GNU property + marking is lacking on this specific input. + + aarch64: delete duplicated BTI tests + + aarch64: improve test coverage for combination of BTI options + +2024-12-02 Matthieu Longo + + aarch64: limit number of reported issues on missing GNU properties + This patch attempts to make the linker output more friendly for the + developers by limiting the number of emitted warning/error messages + related to BTI issues. + + Every time an error/warning related to BTI is emitted, the logger + also increments the BTI issues counter. A batch of errors/warnings is + limited to a maximum of 20 explicit errors/warnings. At the end of + the merge, a summary of the total of errors/warning is given if the + number exceeds the limit of 20 invidual messages. + +2024-12-02 Matthieu Longo + + aarch64: bugfix when finding 1st bfd input with GNU property + The current implementation of searching the first input BFD with GNU + properties has a bug. The search was not filtering on object inputs + belonging to the output link unit only, but was also including dynamic + objects, BFD plugins, and linker-created files. + This means that the initial initialization of the output properties + were skewed, and warnings on input files that should have been emitted + were not. + + This patch fixes the filtering to exclude the object input files not + belonging to the output link unit, not having the same ELF class, and + not the same target architecture. + +2024-12-02 Matthieu Longo + + aarch64: remove early exit when setting up GNU properties with partial linking + There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties + that is enabled when the output link unit is relocatable, i.e. ld + generates an output file that can in turn serve as input to ld. (see + ld manual, -r,--relocatable for more details). + + At this stage, the GNU properties have already been merged and errors + or warnings (if any) have already been issued. However, OUTPROP has + not been updated yet. + Not updating OUTPROP means that implicits enablement of BTI PLTs via + the GNU properties will be ignored for final links. Indeed, the + enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries + by looking up at gnu_property_aarch64_feature_1_and (OUTPROP). + Since the final link does not happen in the case of partial linking, + the behaviour with or without the early exit should be the same. + + Given that there is currently no comment for explain why the exit is + there, and that there might in the future be cases were these properties + affect relocatable links, it is preferrable to drop the early exit. + +2024-12-02 Matthieu Longo + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 5) + Use _bfd_aarch64_elf_check_bti_report to report any BTI issue on the + first input object. + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 4) + Move the code related to the creation of the gnu.note section to a + separate function: _bfd_aarch64_elf_create_gnu_property_section + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 3) + Move the code related to the search of the first bfd input with GNU + properties to a separate function: + _bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 2) + Simplify this for-loop with too many "break" instructions inside. + + aarch64: refactoring _bfd_aarch64_elf_check_bti_report + Before this patch, warnings were reported normally, and errors + (introduced by a previous patch adding '-z bti-report' option) + were logged as error but were not provoking a link failure. + The root of the issue was a misuse of _bfd_error_handler to + report the errors. + Replacing _bfd_error_handler by info->callbacks->einfo, with the + addition of the formatter '%X' for errors fixed the issue. + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 1) + Exposing the output GNU property as a parameter of + _bfd_aarch64_elf_link_setup_gnu_properties seems to break the + encapsulation. The output GNU property update should be part of the + function that sets up the GNU properties. + This patch removes the parameter, and perform the update of the GNU + property on the output object inside the function. + + aarch64: rename gnu_and_prop to gnu_property_aarch64_feature_1_and + +2024-12-02 Matthieu Longo + + aarch64: simplify condition in elfNN_aarch64_merge_gnu_properties + The current condition used to check if a GNU feature property is set + on an input object before the merge is a bit confusing. + + (aprop && !) || !aprop + + It seems easier to understand if it is changed as follows: + + (!aprop || !) + +2024-12-02 Matthieu Longo + + aarch64: rename parameter of _bfd_aarch64_elf_merge_gnu_properties + The current naming of the AArch64 feature GNU property of the output bfd + does not reflect what it is. This patch renames it from "prop" to + "outprop". + + aarch64: update ld documentation with bti and pac options + + aarch64: use only one type for feature marking report + + aarch64: group software protection options under a same struct. + - declare a new struc aarch_protection_opts to store all the + configuration options related to software protections (i.e. bti-plt, + pac-plt, bti-report level). + - add a new option "-z bti-report" to configure the log level of reported + issues when BTI PLT is forced. + - encapsulate the BTI report inside _bfd_aarch64_elf_check_bti_report. + + aarch64: adapt BTI tests to use selectable GNU properties + + aarch64: adapt bti-far* tests to use selectable GNU properties + + aarch64: adapt tests for PAC PLT to use selectable GNU properties + + aarch64: delete old tests for PAC & BTI PLT + + aarch64: new tests for BTI & PAC PLT to use selectable GNU properties + + aarch64: adapt bti-plt-so to use selectable GNU properties + + aarch64: delete old tests covering the merge of feature markings + + aarch64: new tests covering the merge of feature markings + + aarch64: move tests for AArch64 protections (BTI, PAC) into a subfolder + - moved all the BTI and PAC tests into a new subfolder: "protections". + bti-far-* + bti-plt-* + bti-pac-plt-* + - move several procedures used only for AArch64 linker tests to a new exp + library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib. + - use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp. + +2024-12-02 Andrew Burgess + + gdb: handle DW_AT_entry_pc pointing at an empty sub-range + The test gdb.cp/step-and-next-inline.exp creates a test binary called + step-and-next-inline-no-header. This test includes a function + `tree_check` which is inlined 3 times. + + When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1) + we see the following DWARF representing one of the inline instances of + tree_check: + + <2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) + <8da> DW_AT_abstract_origin: <0x9ee> + <8de> DW_AT_entry_pc : 0x401165 + <8e6> DW_AT_GNU_entry_view: 0 + <8e7> DW_AT_ranges : 0x30 + <8eb> DW_AT_call_file : 1 + <8ec> DW_AT_call_line : 52 + <8ed> DW_AT_call_column : 10 + <8ee> DW_AT_sibling : <0x92d> + + ... + + <1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram) + <9ef> DW_AT_external : 1 + <9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check + <9f3> DW_AT_decl_file : 1 + <9f4> DW_AT_decl_line : 38 + <9f5> DW_AT_decl_column : 1 + <9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei + <9fa> DW_AT_type : <0x9e8> + <9fe> DW_AT_inline : 3 (declared as inline and inlined) + <9ff> DW_AT_sibling : <0xa22> + + ... + + Contents of the .debug_ranges section: + + Offset Begin End + ... + 00000030 0000000000401165 0000000000401165 (start == end) + 00000030 0000000000401169 0000000000401173 + 00000030 0000000000401040 0000000000401045 + 00000030 + ... + + Notice that one of the sub-ranges of tree-check is empty, this is the + line marked 'start == end'. As the end address is the first address + after the range, this range cover absolutely no code. + + But notice too that the DW_AT_entry_pc for the inline instance points + at this empty range. + + Further, notice that despite the ordering of the sub-ranges, the empty + range is actually in the middle of the region defined by the lowest + address to the highest address. The ordering is not a problem, the + DWARF spec doesn't require that ranges be in any particular order. + + However, this empty range is causing issues with GDB newly acquire + DW_AT_entry_pc support. + + GDB already rejects, and has done for a long time, empty sub-ranges, + after all, the DWARF spec is clear that such a range covers no code. + + The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which + was outside of the low/high bounds of a block. + + But in this case, the entry-pc value is within the bounds of a block, + it's just not within any useful sub-range. As a consequence, GDB is + storing the entry-pc value, and making use of it, but when GDB stops, + and tries to work out which block the inferior is in, it fails to spot + that the inferior is within tree_check, and instead reports the + function into which tree_check was inlined. + + I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with + these versions gcc is still generating the empty sub-range, but now + this empty sub-range is no longer the entry point. Here's the + corresponding ranges table from gcc 14.2.0: + + Contents of the .debug_rnglists section: + + Table at Offset: 0: + Length: 0x56 + DWARF version: 5 + Address size: 8 + Segment size: 0 + Offset entries: 0 + Offset Begin End + ... + 00000021 0000000000401165 000000000040116f + 0000002b 0000000000401040 (base address) + 00000034 0000000000401040 0000000000401040 (start == end) + 00000037 0000000000401041 0000000000401046 + 0000003a + ... + + The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range, + as a result, when GDB stops at the entry-pc, GDB will correctly spot + that the inferior is in the tree_check function. + + The fix I propose here is, instead of rejecting entry-pc values that + are outside the block's low/high range, instead reject entry-pc values + that are not inside any of the block's sub-ranges. + + Now, GDB will ignore the prescribed entry-pc, and will instead select + a suitable default entry-pc based on either the block's low-pc value, + or the first address of the first range. + + I have extended the gdb.cp/step-and-next-inline.exp test to check this + case, but this does depend on the compiler version being used (newer + compilers will always pass, even without the fix). + + So I have also added a DWARF assembler test to cover this case. + + Reviewed-By: Kevin Buettner + +2024-12-02 Jan Beulich + + x86: default to not accepting MPX insns + Gcc9 had MPX support removed. While we don't want to remove support, + require these deprecated insns (and registers) to be enabled explicitly. + +2024-12-02 Jan Beulich + + x86: always set ISA_1_BASELINE property for 64-bit objects + The baseline was, afaik, specifically chosen to align with the baseline + ISA of x86-64. It therefore makes no sense to emit that property only + conditionally; if anything it confuses tools analyzing the difference + between generated object files, which may result from just + added / changed / removed (entirely ISA-independent) code, without any + change to the enabled extensions. Compilers, after all, are free to use + these baseline "extensions" when generating 64-bit code. + + While changing the one testcase that needs adjustment, also correct its + misleading name (to be in sync with the filename). + +2024-12-02 Jan Beulich + + x86/COFF: support section-index relocations in insn operands + On the grounds of the principle put down near the bottom of [1], along + with image and section relative operations, let's also support as insn + operands what .secidx is for on the data side (of course like elsewhere + the reloc operator can then also be used for data generation, albeit a + small tweak to x86_cons() is needed for this to work). + + [1] https://sourceware.org/pipermail/binutils/2024-November/137617.html + +2024-12-02 Jan Beulich + + x86/COFF: support RVA (image-relative) relocations in insn operands + As was pointed out in [1] compilers produce code using such constructs, + and hence we'd better support this. In analogy to the .rva directive + permit @rva to be used for this, and in analogy with other architectures + (plus to not diverge from e.g. Clang's integrated assembler, albeit I + haven't been able myself to confirm it knows this form) also permit + @imgrel. + + While there also adjust the operand type specifier for the adjacent + @secrel32 - 64-bit fields cannot be used with a 32-bit relocation. + + Further while there also deal with *-*-pe* in x86-64.exp, even if (right + now) perhaps only for completeness. + + [1] https://sourceware.org/pipermail/binutils/2024-November/137548.html + +2024-12-02 Rohr, Stephan + + testsuite, threads: add missing return statements + Add missing return statements in + + * gdb.threads/process-exit-status-is-leader-exit-status.c + * gdb.threads/next-fork-exec-other-thread.c + + to fix 'no return statement' compiler warnings, e.g.: + + process-exit-status-is-leader-exit-status.c: In function ‘start’: + process-exit-status-is-leader-exit-status.c:46:1: warning: no return + statement in function returning non-void [-Wreturn-type] + 46 | } + | ^ + + Approved-By: Simon Marchi + +2024-12-02 Dongyan Chen + + RISC-V: Add support for ssdbltrp and smdbltrp extension. + This implements the ssdbltrp extensons, version 1.0[1] and the smdbltrp + extensions, version1.0[2]. + + [1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc + [2] https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltrp.adoc + + bfd/ChangeLog: + + * elfxx-riscv.c: Add 'ssdbltrp' and 'smdbltrp' to the list of konwn + standard extensions. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/imply.d: Ditto. + * testsuite/gas/riscv/imply.s: Ditto. + * testsuite/gas/riscv/march-help.l: Ditto. + +2024-12-02 GDB Administrator + + Automatic date update in version.in + +2024-12-01 Alan Modra + + Correct hpux-core.c thread_section_p signature + Fix fallout from commit 0a1b45a20eaa. + +2024-12-01 Alan Modra + + Re: PR32399, buffer overflow printing core_file_failing_command + Fix more potential buffer overflows, and correct trad-code.c and + cisco-core.c where they should be using bfd_{z}alloc rather than + bfd_{z}malloc. To stop buffer overflows with fuzzed objects that + don't have a terminator on the core_file_failing_command string, this + patch allocates an extra byte at the end of the entire header buffer + rather than poking a NUL at the end of the name array (u_comm[] or + similar) because (a) it's better to not overwrite the file data, and + (b) it is possible that some core files make use of fields in struct + user beyond the end of u_comm to extend the command name. The patch + also changes some unnecessary uses of bfd_zalloc to bfd_alloc. + There's not much point in clearing memeory that will shortly be + completely overwritten. + + PR 32399 + * aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to + ensure the core_file_failing_command string is terminated. + * netbsd-core.c (netbsd_core_file_p): Likewise. + * ptrace-core.c (ptrace_unix_core_file_p): Likewise. + * rs6000-core.c (rs6000coff_core_p): Likewise. + * trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc + tdata rather than bfd_zmalloc. + * cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata. + +2024-12-01 oltolm + + Remove more remnants of old Mach-O workaround + Remove another adjustment for section address, this time for the + offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by + fetch_indexed_string. + +2024-12-01 GDB Administrator + + Automatic date update in version.in + +2024-11-30 GDB Administrator + + Automatic date update in version.in + +2024-11-29 Jens Remus + + s390: Fix linker test TLS -fpic and -fno-pic exec transitions + Commit 36bbf8646c8b ("s390: Treat addressing operand sequence as one in + disassembler") changed how plain "nop" gets disassembled and missed to + update any affected linker tests accordingly. + + ld/testsuite/ + * ld-s390/tlsbin.dd: "nop" disassembles into "nop". + + Fixes: 36bbf8646c8b ("s390: Treat addressing operand sequence as one in disassembler") + +2024-11-29 Jens Remus + + s390: Simplify parsing of omitted index register operand + The index register operand X in D(X,B) can optionally be omitted by + coding D(,B) or D(B). Simplify the parsing logic. + + gas/ + * config/tc-s390.c (md_gather_operands): Rename + omitted_base_or_index to omitted_index and simplify logic. + +2024-11-29 Jens Remus + + s390: Treat addressing operand sequence as one in disassembler + Reuse logic introduced with the preceding commit in the assembler to + treat addressing operand sequences D(X,B), D(B), and D(L,B) as one + with regards to optional last operands (i.e. optparm and optparm2). + + With this "nop" now disassembles into "nop" instead of "nop 0". + + opcodes/ + * s390-dis.c (operand_count): New helper to count the remaining + operands, treating D(X,B), D(B), and D(L,B) as one. + (skip_optargs_p): New helper to test whether remaining operands + are optional. + (skip_optargs_zero_p): New helper to test whether remaining + operands are optional and their values are zero. + (s390_print_insn_with_opcode): Use skip_optargs_zero_p to skip + optional last operands with a value of zero. + + gas/testsuite/ + * gas/s390/zarch-optargs.d (nop): Adjust test case accordingly. + +2024-11-29 Jens Remus + + s390: Treat addressing operand sequence as one in assembler + The assembler erroneously treated any number of operands as optional, + if the instruction was flagged to have one or two optional operands + (i.e. optparm or optparm2). + + Only treat the exact specified number of operands as optional while + treating addressing operand sequences D(X,B), D(B), and D(L,B) as one + operand. + + gas/ + * config/tc-s390.c (operand_count): New helper to count the + remaining operands, treating D(X,B), D(B), and D(L,B) as one. + (skip_optargs_p): Use new helper operand_count to treat + D(X,B), D(B), and D(L,B) as one operand. + (md_gather_operands): Use skip_optargs_p to skip only the + optional last operands. + +2024-11-29 Jens Remus + + s390: Fix disassembly of optional addressing operands + "nop D1(B1)" erroneously disassembled into "nop D1(B1" (missing + closing parenthesis). "nop D1(X1,0)" and "nop D1(X1,)" erroneously + disassembled into "nop D1(X1)" (missing zero base register) instead + of "nop D1(X1,0)". + + Do not skip disassembly of optional operands if they are index (X) + or base (B) registers or length (L) in an addressing operand sequence + "D(X,B)", "D(B)", or "D(L,B). Index and base register operand values + of zero are being handled separately, as they may not be omitted + unconditionally. For instance a base register value of zero must be + printed in above mentioned case, to distinguish the index from the + base register. This also ensures proper formatting of addressing + operand sequences. + + While at it add further test cases for instructions with optional + operands. + + opcodes/ + * s390-dis.c (s390_print_insn_with_opcode): Do not + unconditionally skip disassembly of optional operands with a + value of zero, if within an addressing operand sequence. + + gas/testsuite/ + * gas/s390/zarch-optargs.d: Add further test cases for + instructions with optional operands. + * gas/s390/zarch-optargs.s: Likewise. + + Reported-by: Florian Krohm + +2024-11-29 Jan Beulich + + x86: restrict gas'es recognition of -s to Solaris + When there for Solaris compatibility only, also recognize it only there. + This way the option becomes available for other possible uses. + + While adjusting md_shortopts[], also re-arrange things such that we have + only a single, uniform definition of it. + +2024-11-29 Jan Beulich + + x86/Solaris: support Sun form of CMOVcc + Sun specifies an alternative form for CMOVcc [1], which for some reason + we never cared to support, even if - as per gcc's configure checking for + it - it may have been the only permitted form at some point. + + While documentation doesn't indicate FCMOVcc to have similar alternative + forms, gcc assumes so. Hence cover FCMOVcc as well. + + [1] https://docs.oracle.com/cd/E37838_01/html/E61064/ennbz.html#XALRMeoizm + +2024-11-29 Jan Beulich + + x86: purge most *avx512*ig*-intel tests + Having just one each (AVX512F) ought to be sufficient to cover Intel + syntax disassembly. + + In x86-64.exp also reorder tests some, so that related ones are again + next to each other, rather than being interspersed with APX ones. + +2024-11-29 Jan Beulich + + x86: SETcc doesn't permit W suffix + Accidentally I had removed No_wSuf when cloning the extra template. + +2024-11-29 Surya Kumari Jangala + + MAINTAINERS: Update Peter Bergner's e-mail address + +2024-11-29 Alan Modra + + PR32399, buffer overflow printing core_file_failing_command + Assorted targets do not check, as the ELF targets do, that the program + name in a core file is NUL terminated. Fix some of them. I haven't + attempted to fix all targets because editing host specific code can + easily result in build bugs, which aren't discovered until someone + build binutils for that host. (Of the files edited here, I can't + easily compile hpux-core.c and osf-core.c on a linux system.) + + PR 32399 + * hppabsd-core.c (hppabsd_core_core_file_p): Ensure core_command + string is terminated. + * hpux-core.c (hpux_core_core_file_p): Likewise. + * irix-core.c (irix_core_core_file_p): Likewise. + * lynx-core.c (lynx_core_file_p): Likewise. + * osf-core.c (osf_core_core_file_p): Likewise. + * mach-o.c (bfd_mach_o_core_file_failing_command): Likewise. + +2024-11-29 GDB Administrator + + Automatic date update in version.in + +2024-11-28 Alexandra Hájková + + Sync include/dwarf.h with gcc up to commit c4073a3d154 + Approved-by: Kevin Buettner + +2024-11-28 Tom de Vries + + [gdb/syscalls] Add syscalls {set,get,list,remove}xattrat + In commit 58776901074 ("[gdb/syscalls] Update to linux v6.11") I updated to + linux v6.11, but a recent submission for loongarch [1] used a current trunk + version, so it makes sense to do this as well elsewhere. + + Using linux current trunk with update-linux-from-src.sh gets us 4 more + syscalls: + - setxattrat + - getxattrat + - listxattrat + - removexattrat + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213613.html + +2024-11-28 GDB Administrator + + Automatic date update in version.in + +2024-11-27 Vladimir Mezentsev + + Fix 32392 [2.44 Regression] gprofng fails to build on i686-linux-gnu + gprofng/ChangeLog + 2024-11-26 Vladimir Mezentsev + + PR gprofng/32392 + * libcollector/libcol_util.c (__collector_util_init): Fix warning. + +2024-11-27 Vladimir Mezentsev + + gprofng: skip unrecognized input command + gprofng crashes when the GUI sends an invalid command. + Skip unrecognized commands and return an error status to the GUI. + + gprofng/ChangeLog + 2024-11-26 Vladimir Mezentsev + + * src/ipc.cc (ipc_doWork): Skip unrecognized commands. + * src/ipcio.cc (writeError): New function. + * src/ipcio.h: Add RESPONSE_STATUS_ERROR. + +2024-11-27 Guinevere Larsen + + gdb/testsuite: skip gdb.threads/omp-par-scope.exp with clang + Since 2020 it has been reported to clang[1] that the debug information + around OpenMP is insufficient. The OpenMP section is not declared + within the correct scope, and instead clang marks as if the section was + a function in the global scope. This causes several failures in the + test gdb.threads/omp-par-scope.exp when using clang to test GDB. + + Since this isn't a true failure of GDB, and there is little expectation + that clang will be able to fix this soon, this commit disables the + aforementioned test when clang is being used. + + [1] https://github.com/llvm/llvm-project/issues/44236 + + Approved-by: Kevin Buettner + +2024-11-27 Tom de Vries + + [gdb/symtab] Fix parent map dump + Before the fix for PR symtab/32225, the parent map dump showed a mapping from + section offsets to cooked index entries: + ... + 0x0000000000000035 0x3ba9560 (0x34: sp1::A) + ... + but now that's no longer the case: + ... + 0x00000000406f5405 0x410a04d0 (0x34: sp1::A) + ... + + Fix this by extending the annotation somewhat, such that we get: + ... + map start: + 0x0000000012c52405 0x135fd550 + (section: .debug_info, offset: 0x35) -> (0x34: sp1::A) + ... + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/dw2-tu-dwarf-4-5.exp + Add a regression test for PR symtab/32225. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Author: Tom Tromey + + [gdb/symtab] Fix parent map when handling .debug_info and .debug_types + Consider test-case: + ... + $ cat test.c + namespace sp1 { + class A { + int i; + const int f1 = 1; + ... + const int f29 = 1; + }; + } + sp1::A a; + void _start (void) {} + $ cat test2.c + namespace sp2 { + class B { + float f; + const float f1 = 1; + ... + const float f29 = 1; + }; + } + sp2::B b; + ... + compiled like this: + ... + $ g++ test.c -gdwarf-4 -c -g -fdebug-types-section + $ g++ test2.c -gdwarf-5 -c -g -fdebug-types-section + $ g++ -g test.o test2.o -nostdlib + ... + + Using: + ... + $ gdb -q -batch -iex "maint set worker-threads 0" a.out -ex "maint print objfiles" + ... + we get a cooked index entry with incorrect parent: + ... + [29] ((cooked_index_entry *) 0x3c57d1a0) + name: B + canonical: B + qualified: sp1::A::B + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0x154 + parent: ((cooked_index_entry *) 0x3c57d110) [A] + ... + + The problem is that the parent map assumes that all offsets are in the same + section. + + Fix this by using dwarf2_section_info::buffer-relative addresses instead, + which get us instead: + ... + [29] ((cooked_index_entry *) 0x3f0962b0) + name: B + canonical: B + qualified: sp2::B + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0x154 + parent: ((cooked_index_entry *) 0x3f096280) [sp2] + ... + + Tested on x86_64-linux. + + PR symtab/32225 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Andreas Arnez + + [gdb/tdep] s390: Add arch15 record/replay support + Enable recording of the new "arch15" instructions on z/Architecture + targets. + +2024-11-27 Liu Hao + + PE LD: Merge .CRT .ctors and .dtors into .rdata + PR 32264 + +2024-11-27 Nick Clifton + + Tidy up the default ELF linker script + +2024-11-27 Alan Modra + + Re: nios2: Remove binutils support for Nios II target + Remove a now unused config file, regenerate POTFILES to remove nios2 + refs, and modify config.bfd to report the target is obsolete. + +2024-11-27 GDB Administrator + + Automatic date update in version.in + +2024-11-26 Sandra Loosemore + + nios2: Remove binutils support for Nios II target. + The Nios II architecture has been EOL'ed by the vendor. This patch + removes all binutils, bfd, gas, binutils, and opcodes support for this + target with the exception of the readelf utility. (The ELF EM_* + number remains valid and the relocation definitions from the Nios II + ABI will never change in future, so retaining the readelf support + seems consistent with its purpose as a utility that tries to parse the + headers in any ELF file provided as an argument regardless of target.) + + nios2: Remove all GDB support for Nios II targets. + Intel has EOL'ed the Nios II architecture, and it's time to remove support + from all toolchain components before it gets any more bit-rotten from + lack of maintenance or regular testing. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Update aarch64-linux.xml to linux v6.11 + Use gdb/syscalls/update-linux.sh to update aarch64-linux.xml.in to linux + v6.11, and update aarch64-linux.xml by running make. + + Noteworthy changes are removal of entries: + - arch_specific_syscall + - syscalls + which look like they were added accidentally. + + I modified update-linux.sh to keep the copyright start date. Verified with + shellcheck. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2024-11-26 Alan Modra + + PR32387 ppc64 TLS optimization bug with -fno-plt code + The inline plt code emitted by gcc is incompatible with the + linker/ld.so --tls-get-addr-optimize scheme. This is the runtime + optimisation where the first call to __tls_get_addr results in + __tls_get_addr updating the tls_index pair, then the special linker + stub using that to short-circuit second and subsequent calls for a + given tls symbol. Enabled by default when the linker sees + __tls_get_addr_opt is preseent, and enabled in ld.so when DT_PPC64_OPT + has PPC64_OPT_TLS set. Note that this is distinct from link-time tls + optimisation. + + PR 32387 + * elf64-ppc.c (ppc64_elf_check_relocs): Disable tls_get_addr_opt + on detecting inline plt calls to __tls_get_addr. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Sync with strace v6.12 + I ran gdb/syscalls/update-linux-defaults.sh with strace sources v6.12, and got + one difference in gdb/syscalls/linux-defaults.xml.in: + ... + + + ... + + Rerun make to propagate this change to the xml files. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Use update-linux-from-src.sh for arm-linux + I tried to use arm-linux.py to regenerate arm-linux.xml.in, but it didn't work. + + Fix this by: + - adding handling of arm-linux.xml.in in update-linux-from-src.sh, + - regenerating arm-linux.xml.in using update-linux-from-src.sh and linux 6.11 + sources, + - regenerating arm-linux.xml using make, and + - removing arm-linux.py. + + This changes the name "oldolduname" into "olduname". + + Tested on arm-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Restructure update-linux-from-src.sh + Restructure update-linux-from-src.sh to do the generation of each line + in the script it self rather than in awk. + + Tested on aarch64-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Improve update-linux-from-src.sh + Some improvements in gdb/syscalls/update-linux-from-src.sh: + - use bash instead of sh + - use local to distinguish between local and global vars + (which brings to light that pre uses the global rather than the local + start_date) + - factor out main and parse_args + - factor out regen + - iterate over *.xml.in instead of *.in + + Tested on aarch64-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Update to linux v6.11 + Regenerate some gdb/syscalls/*.xml.in files using + gdb/syscalls/update-linux-from-src.sh and linux v6.11 sources. + + Regenerate the corresponding gdb/syscalls/*.xml using make. + + Tested on aarch64-linux. + +2024-11-26 Simon Marchi + + Convert dwarf2_per_objfile::die_type_hash to new hash table + Convert dwarf2_per_objfile::die_type_hash, which maps debug info + offsets to `type *`, to gdb::unordered_map. + + Change-Id: I5c174af64ee46d38a465008090e812acf03704ec + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf2_cu::call_site_htab to new hash table + Convert one use of htab_t, mapping (unrelocated) pc to call_site + objects, to `gdb::unordered_map`. + + Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641 + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf_cu::die_hash to new hash table + Convert one use of htab_t, mapping offsets to die_info object, to + `gdb::unordered_set`. + + Change-Id: Ic80df22bda551e2d4c2511d167e057f4d6cd2b3e + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert gdb_bfd.c to new hash table + This converts the BFD cache in gdb_bfd.c to use the new hash table. + + Change-Id: Ib6257fe9d4f7f8ef793a2c82d53935a8d2c245a3 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert more DWARF code to new hash table + This converts more code in the DWARF reader to use the new hash table. + + Change-Id: I86f8c0072f0a09642de3d6f033fefd0c8acbc4a3 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert all_bfds to new hash table + This converts gdb_bfd.c to use the new hash table for all_bfds. + + This patch slightly changes the htab_t pretty-printer test, which was + relying on all_bfds. Note that with the new hash table, gdb-specific + printers aren't needed; the libstdc++ printers suffice -- in fact, + they are better, because the true types of the contents are available. + + Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert typedef hash to new hash table + This converts the typedef hash to use the new hash table. + + This patch found a latent bug in the typedef code. Previously, the + hash function looked at the type name, but the hash equality function + used types_equal -- but that strips typedefs, meaning that equality of + types did not imply equality of hashes. This patch fixes the problem + and updates the relevant test. + + Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert abbrevs to new hash table + This converts the DWARF abbrevs themselves to use the new hash table. + + Change-Id: I0320a733ecefe2cffeb25c068f17322dd3ab23e2 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert abbrev cache to new hash table + This converts the DWARF abbrev cache to use the new hash table. + + Change-Id: I5e88cd4030715954db2c43f873b77b6b8e73f5aa + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert gnu-v3-abi.c to new hash table + This converts gnu-v3-abi.c to use the new hash table. + + This change shows how a std::vector can easily be made directly from + the hash table, simplifying the earlier approach of constructing a + vector and a hash table at the same time. + + Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert static links to new hash table + This converts the objfile static link table to the new hash map. + + Change-Id: If978e895679899ca2af4ef01c12842b4184d88e6 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert type copying to new hash table + This converts the type copying code to use the new hash map. + + Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert compile/compile.c to new hash table + This converts compile/compile.c to use the new hash table. + + Change-Id: I7df3b8d791ece731ae0d1d64cdc91a2e372f5d4f + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert disasm.c to new hash table + This converts disasm.c to use the new hash table. + + Change-Id: I2efbe7ecc2964ec49e0b726ad4674e8eafc929f7 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert py-framefilter.c to new hash table + This converts py-framefilter.c to use the new hash table. + + Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert breakpoint.c to new hash table + This converts breakpoint.c to use the new hash table. + + Change-Id: I6d997a6242969586a7f8f9eb22cc8dd8d3ac97ff + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf2/macro.c to new hash table + This converts dwarf2/macro.c to use the new hash table. + + Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert target-descriptions.c to new hash table + This converts target-descriptions.c to use the new hash table. + + Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert linespec.c to new hash table + This converts linespec.c to use the new hash table. + + Note that more simplification could perhaps be done. Currently, the + collectors in this code insert an element into a set and then, if the + element has not been seen before, append it to a vector. If we know + the order does not matter, or if the results can be sorted later, we + could dispense with the vector. This would simplify the code some + more. (This technique is used in the vtable patch, later in this + series.) + + Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert filename-seen-cache.h to new hash table + This converts filename-seen-cache.h to use the new hash table. + filename-seen-cache.c is removed. + + Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert compile-c-symbols.c to new hash table + This converts compile-c-symbols.c to use the new hash table. + + I made it use a set of string_view instead of a set of `symbol *`, to + avoid calling `symbol::natural_name` over and over. This appears safe + to do, since I don't expect the storage behing the natural names to + change during the lifetime of the map. + + Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdbsupport: add unordered_dense.h 4.4.0 + Add a copy of unordered_dense.h from [1]. This file implements an + efficient hash map and hash set with a nice C++ interface (a near + drop-in for std::unordered_map and std::unordered_set). This is + expected to be used to replace uses of `htab_t`, for improved code + readability and type safety. Performance-wise, it is preferred to the + std types (std::unordered_map and std::unordered_set) due to it using + open addressing vs closed addressing for the std types. + + I chose this particular implementation because it is simple to use, it's + a standalone header and it typically performs well in benchmarks I have + seen (e.g. [2]). The license being MIT, my understanding is that it's + not a problem to use it and re-distribute it. + + Add two additional files, gdbsupport/unordered_map.h and + gdbsupport/unordered_set.h, which make the map and set offered by + gdbsupport/unordered_dense.h available as gdb::unordered_map and + gdb::unordered_set. + + [1] https://github.com/martinus/unordered_dense + [2] https://jacksonallan.github.io/c_cpp_hash_tables_benchmark/#conclusion-which-hash-table-to-choose + + Change-Id: I0c7469ccf9a14540465479e58b2a5140a2440a7d + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: make `cooked_index_storage::get_abbrev_table_cache` return a reference + It can never return nullptr, return a reference instead of a pointer. + + Change-Id: Ibc6f16eb74dc16059152982600ca9f426d7f80a4 + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: constification around abbrev_table_cache and abbrev_table + Make `abbrev_table_cache::find` const, make it return a pointer to + `const abbrev_table`, adjust the fallouts. + + Make `cooked_index_storage::get_abbrev_table_cache` const, make itreturn + a pointer to const `abbrev_table_cache`. + + Change-Id: If63b4b3a4c253f3bd640b13bce4a854eb2d75ece + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: rename abbrev_cache to abbrev_table_cache + This cache holds `abbrev_table` objects, so I think it's clearer and + more consistent to name it `abbrev_table_cache`. Rename it and + everything that goes along with it. + + Change-Id: I43448c0aa538dd2c3ae5efd2f7b3e7b827409d8c + Approved-By: Tom Tromey + +2024-11-26 GDB Administrator + + Automatic date update in version.in + +2024-11-25 Andrew Burgess + + gdb: do better in breakpoint_free_objfile + The breakpoint_free_objfile function is called from the objfile + destructor, and has the job of removing references to the soon to be + deleted objfile from all breakpoint locations. + + The current implementation of breakpoint_free_objfile seems to miss + lots of possible objfile references within bp_location. Currently we + only check if bp_location::symtab is associated with the objfile in + question, but there's bp_location::section and bp_location::probe, + both of which might reference the soon to be deleted objfile. + + Additionally bp_location::symbol and bp_location::msymbol if set will + surely be related to the objfile and should also be cleaned up. + + I'm not aware that this causes any problems, but it doesn't seem like + a good idea to retain pointers to deleted state, so I propose that we + improve breakpoint_free_objfile to set these pointers back to nullptr. + + In the future I plan to investigate the possibility of merging the + functionality of breakpoint_free_objfile into + disable_breakpoints_in_freed_objfile which is called via the + gdb::observers::free_objfile event. However, I already have a patch series + in progress which touches this area of GDB, and I'd like to avoid + conflicting with that earlier series: + + https://inbox.sourceware.org/gdb-patches/cover.1724948606.git.aburgess@redhat.com + + Once this patch, and that earlier series have landed then I'll see if + I can merge breakpoint_free_objfile, but I don't think that this needs + to block this patch. + + There should be no user visible changes after this commit. + +2024-11-25 Andrew Burgess + + gdb: remove an unnecessary scope block in update_breakpoint_locations + In update_breakpoint_locations there's a scope block which I don't + think adds any value. There is one local defined within the scope, + the local is currently an 'int' but should be a 'bool', either way + there's no destructor being triggered when we exit the scope. + + This commit changes the local to a 'bool', removes the unnecessary + scope, and re-indents the code. + + Within the (now removed) scope was a `for' loop. Inside the loop I + have converted this: + + for (....) + { + if (CONDITION) + { + /* Body */ + } + } + + to this: + + for (....) + { + if (!CONDITION) + continue; + + /* Body */ + } + + which means that the body doesn't need to be indented as much, making + things easier to read. + + There should be no functional change after this commit. + + Reviewed-By: Klaus Gerlicher + +2024-11-25 Andrew Burgess + + gdb: remove bp_location::objfile + The bp_location::objfile member variable is never used, so lets delete + it. + + There should be no user visible changes after this commit. + +2024-11-25 Alexandra Hájková + + gdbreplay: Calculate the checksum if missing + Recalculate the checksum and replace whatever is at the end + of the packet with the newly calculated checksum. Then + replay the packet with the checksum added. + + The motivation for this change is that I'd like to add a TCL test + which starts a communication with gdbsever setting the remotelog file. + Then, it modifies the remotelog, injects an error message instead of + the expected replay to some packet in order to test GDB reacts to + the error response properly. + + Approved-By: Tom Tromey + +2024-11-25 Nick Clifton + + Updated Bulgarian, Romanian and French translations for various sub-directories. New Georgian translation for the gold sub-directory. + +2024-11-25 Andrew Burgess + + gdb/testsuite: force TERM setting for some filename completion tests + Some of the filename completion tests perform mid-line completion. + That is we enter a partial line, then move the cursor back to the + middle of the line and perform completion. + + The problem is that, emitting characters into the middle of a terminal + line relies on first emitting some control characters. And which + control characters are emitted will depend on the current TERM + setting. + + When I initially added the mid-line completion tests I setup two + regexp that covered two different terminal types, but PR gdb/32338 + identifies additional terminal types that emit different sequences of + control characters. + + Rather than trying to handle all possible terminal types, lets just + force the TERM variable to something simple (i.e. "dumb") and then + just support that one case. The thing being tested for here was that + GDB would complete a filename in the middle of a line, the specific + terminal type was not really important. + + I've simplified the regexp used to match the completion in two places, + and I now force TERM to be "dumb" for the mid-line completion tests. + I've tested this by setting my global environment TERM to 'ansi', + 'xterm', 'xterm-mono', and 'dumb', and I see no failures in any mode + now. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32338 + Tested-By: Tom de Vries + +2024-11-25 Hui Li + + gdb: Add LoongArch process record/replay support in NEWS and doc + At present, process record/replay and reverse debugging has been + implemented on LoongArch. Update the NEWS and doc to record this + new change. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add system call support for process record/replay + The process record and replay function also need record Linux + system call instruction. This patch adds LoongArch system call + number definitions in gdb/arch/loongarch-syscall.h, and adds + loongarch_linux_syscall_record() in gdb/loongarch-linux-tdep.c + to record system call execute log. With this patch, the main + functions of process record/replay and reverse debugging are + implemented. + + The LoongArch system call numbers definitions are obtained from Linux kernel. + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/unistd.h + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/unistd.h + + Approved-By: Guinevere Larsen (record-full) + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add basic process record/replay support + GDB provides a special process record and replay target that can + record a log of the process execution, and replay it later with + both forward and reverse execution commands. This patch adds the + basic support of process record and replay on LoongArch, it allows + users to debug basic LoongArch instructions and provides reverse + debugging support. + + Here is a simple example on LoongArch: + + $ cat test.c + int a = 0; + int main() + { + a = 1; + a = 2; + return 0; + } + $ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:4 + 4 a = 1; + (gdb) record + (gdb) p a + $1 = 0 + (gdb) n + 5 a = 2; + (gdb) n + 6 return 0; + (gdb) p a + $2 = 2 + (gdb) rn + 5 a = 2; + (gdb) rn + + Reached end of recorded history; stopping. + Backward execution from here not possible. + main () at test.c:4 + 4 a = 1; + (gdb) p a + $3 = 0 + (gdb) record stop + Process record is stopped and all execution logs are deleted. + (gdb) c + Continuing. + [Inferior 1 (process 129178) exited normally] + + Approved-By: Guinevere Larsen (record-full) + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add instruction definition for process record + GDB provides a special process record function that can record a log + of the process execution. The core of this feature is need to record + the execution of all instructions. This patch adds opcode definitions + and judgments in gdb/arch/loongarch-insn.h. This is preparation for + later patch on LoongArch, there is no effect for the other archs with + this patch. + + The LoongArch opcode and mask definitions are obtained from + https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/loongarch-opc.c + LoongArch instruction description refer to the LoongArch Reference Manual: + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html + + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-11-25 GDB Administrator + + Automatic date update in version.in + +2024-11-24 Tom de Vries + + opcodes: fix Werror=format build breaker in opcodes/riscv-dis.c + I build gdb on arm-linux and ran into: + ... + CC riscv-dis.lo + opcodes/riscv-dis.c: In function ‘print_insn_args’: + opcodes/riscv-dis.c:743:29: error: format ‘%lu’ expects argument of type \ + ‘long unsigned int’, but argument 4 has type ‘insn_t’ \ + {aka ‘long long unsigned int’} [-Werror=format=] + 743 | "%lu", EXTRACT_ZCMT_INDEX (l)); + | ~~^ + | | + | long unsigned int + | %llu + ... + + Fix this by printing the insn_t value, which is a uint64_t, using PRIu64. + + Tested by finishing the build. + +2024-11-24 GDB Administrator + + Automatic date update in version.in + +2024-11-23 Tom de Vries + + [sim] Run spellcheck.sh in sim (part 2) + Run gdb/contrib/spellcheck.sh on directory sim. + + Fix these todos: + ... + TODO: inbetween -> between, in between, in-between + TODO: behavour -> behavior, behaviour + TODO: firts -> flirts, first + TODO: wich -> which, witch + ... + + Tested by rebuilding on x86_64-linux. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [gdb/contrib] Add two words to common-misspellings.txt + While reviewing changes generated by spellcheck.sh for directory sim, I + noticed two more misspellings: + ... + arrithemetic->arithmetic + electricaly->electrically + ... + + Add them to common-misspellings.txt, and fix them in directory sim. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [sim] Run spellcheck.sh in sim (part 1) + Run gdb/contrib/spellcheck.sh on directory sim. + + Fix auto-corrected typos: + ... + accessable -> accessible + accidently -> accidentally + accomodate -> accommodate + adress -> address + afair -> affair + agains -> against + agressively -> aggressively + annuled -> annulled + arbitary -> arbitrary + arround -> around + auxillary -> auxiliary + availablity -> availability + clasic -> classic + comming -> coming + controled -> controlled + controling -> controlling + destory -> destroy + existance -> existence + explictly -> explicitly + faciliate -> facilitate + fouth -> fourth + fullfilled -> fulfilled + guarentee -> guarantee + hinderance -> hindrance + independant -> independent + inital -> initial + loosing -> losing + occurance -> occurrence + occured -> occurred + occuring -> occurring + omited -> omitted + oportunity -> opportunity + parallely -> parallelly + permissable -> permissible + postive -> positive + powerfull -> powerful + preceed -> precede + preceeding -> preceding + preceeds -> precedes + primative -> primitive + probaly -> probably + programable -> programmable + propogate -> propagate + propper -> proper + recieve -> receive + reconized -> recognized + refered -> referred + refering -> referring + relevent -> relevant + responisble -> responsible + retreive -> retrieve + safty -> safety + specifiying -> specifying + spontanous -> spontaneous + sqaure -> square + successfull -> successful + supress -> suppress + sytem -> system + thru -> through + transfered -> transferred + trigered -> triggered + unfortunatly -> unfortunately + upto -> up to + usefull -> useful + wierd -> weird + writen -> written + doesnt -> doesn't + isnt -> isn't + ... + + Manually undid the "andd -> and" transformation in sim/testsuite/cr16/andd.cgs + and sim/cr16/simops.c. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [sim] Rename local variable in ARMul_NthReg + Rename local variable in ARMul_NthReg from upto to up_to, to avoid being + rewritten by gdb/contrib/spellcheck.sh. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [gdbsupport] Rerun autoreconf -f + Rerun autoreconf -f in gdbsupport, reverting "behaviour" -> "behavior" changes + in generated files aclocal.m4 and configure. + +2024-11-23 Tom de Vries + + [gdb/contrib] Add two rules in common-misspellings.txt + Eli mentioned [1] that given that we use US English spelling in our + documentation, we should use "behavior" instead of "behaviour". + + In wikipedia-common-misspellings.txt there's a rule: + ... + behavour->behavior, behaviour + ... + which leaves this as a choice. + + Add an overriding rule to hardcode the choice to common-misspellings.txt: + ... + behavour->behavior + ... + and add a rule to rewrite behaviour into behavior: + ... + behaviour->behavior + ... + and re-run spellcheck.sh on gdb*. + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html + +2024-11-23 GDB Administrator + + Automatic date update in version.in + +2024-11-22 Sam James + + Sync toplevel configure fixup + Apparently I missed that we needed to sync config/acx.m4. I only + noticed this because our packaging has a grep for certain messages + post-merge. + + ``` + work/binutils/configure: 5814: ACX_PROG_CARGO: not found + ``` + + Fix that by syncing the macro too, which I missed in 987db70acefd0b223a8df2240d4e5ca544cc0a91. + +2024-11-22 Guinevere Larsen + + gdb/record: introduce recoding support for vpor + This commit adds recording support for the AVX instruction vpor, and the + AVX2 extension. Since the encoding of vpor and vpxor are the same, and + their semantics are basically the same, modulo the mathematical + operation, they are handled by the same switch case block. + + This also updates the vpxor function, to test vpor and vpxor, and + updates the name to vpor_xor_test to better reflect what it does. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: Add support for recording vpmovmskb + This commit adds support for recording the AVX instruction vpmovmskb, + and tests to the relevant file. The test didn't really support checking + general purpose registers, so this commit also adds a proc to + gdb.reverse/i386-avx-reverse.exp, which can be used to test them + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: Add support for all vpcmpeq instructions + This commit adds support to recording instructions of the form + VPCMPEQ[B|W|D]. They are all encoded in the same way and only + differentiated by the opcode, so they are all processed together. This + commit also updates the test to (quite exhaustively) test the new + instruction. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: add support for vpxor instruction + This commit adds support for recording the instruction vpxor, + introduced in the AVX extension, and extended in AVX2 to use 256 bit + registers. The test gdb.reverse/i386-avx-reverse.exp has been extended + to test this instruction as well. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb: Introduce RAII signal handler setter + This patch is motivated by the wait function for the record-full target, + that would install a custom signal handler for SIGINT, but could throw + an exception and never reset the SIGINT handler. This is clearly a bad + idea, so this patch introduces the class scoped_signal_handler in a new + .h file. The file is added to gdbsupport, even though only gdb code is + using it, because it feels like an addition that would be useful for + more than just directly gdb. + + The implementation of the RAII class is based on the implementation + on gdb/utils.c. That is, it uses preprocessor ifdefs to probe for + sigaction support, and uses it if possible, defaulting to a raw call to + signal only if sigaction isn't supported. sigaction is preferred based + on the "portability" section of the manual page for the signal function. + + There are 3 places where this class can just be dropped in, + gdb/record-full.c, gdb/utils.c and gdb/extension.c. This third place + already had a specialized RAII signal handler setter, but it is + substituted for the new general purpose one. + + Approved-By: Tom Tromey + +2024-11-22 Vladimir Mezentsev + + gprofng: fix build with -std=gnu23 + Fix function pointer types accordingly. + Remove unused function pointers. + + gprofng/ChangeLog + 2024-11-21 Vladimir Mezentsev + + PR gprofng/32374 + PR gprofng/32373 + * common/cpuid.c: Define ATTRIBUTE_UNUSED if necessary. + * libcollector/libcol_util.c (sysinfo): Remove unused pointer. + * src/collector_module.h: Likewise. + * libcollector/dispatcher.c (setitimer): Fix prototype. + * libcollector/linetrace.c (system, grantpt, ptsname): Likewise. + * testsuite/gprofng.display/mttest/mttest.c (dump_arrays): Likewise. + * testsuite/gprofng.display/synprog/endcases.c (xinline_code, + s_inline_code): Likewise. + * testsuite/gprofng.display/synprog/inc_inline.h (ext_inline_code): + Likewise. + * testsuite/gprofng.display/synprog/synprog.c (doabort): Rename nullptr. + +2024-11-22 Hannes Domani + + Use appropriate context flags for Wow64 processes + When I implemented debugging of Wow64 processes, I missed that there are + extra ContextFlags defines for them. + It's a bit surprising that the wrong ones actually worked, except that + CONTEXT_EXTENDED_REGISTERS is not available for x86_64, and they are + needed for i686, since that's where the xmm registers are stored. + + So this replaces the ContextFlags values with their WOW64_* equivalents. + On gdbserver this also duplicates the fallback logic if the + GetThreadContext call failed with CONTEXT_EXTENDED_REGISTERS. + + Fixes these fails: + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm0 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm0 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm1 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm1 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm2 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm3 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm3 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm4 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm4 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm5 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm5 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm6 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm6 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm7 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm7 + FAIL: gdb.arch/i386-sse.exp: check contents of data[0] + FAIL: gdb.arch/i386-sse.exp: check contents of data[1] + FAIL: gdb.arch/i386-sse.exp: check contents of data[2] + FAIL: gdb.arch/i386-sse.exp: check contents of data[3] + FAIL: gdb.arch/i386-sse.exp: check contents of data[4] + FAIL: gdb.arch/i386-sse.exp: check contents of data[5] + FAIL: gdb.arch/i386-sse.exp: check contents of data[6] + FAIL: gdb.arch/i386-sse.exp: check contents of data[7] + + Approved-By: Tom Tromey + +2024-11-22 Sam James + + Sync toplevel configure with GCC + This syncs us with GCC as of r15-5590-gf34422e06c38eb. + + Some changes will need to be propagated to the GCC side (so I've kept those + and not clobbered them) which I will handle shortly. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Handle failure to initialize without exiting + I tried out making python initialization fail by passing an incorrect + PYTHONHOME, and got: + ... + $ PYTHONHOME=foo ./gdb.sh -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + Python not initialized + $ + ... + + The relevant part of the code is: + ... + static void + gdbpy_initialize (const struct extension_language_defn *extlang) + { + if (!do_start_initialization () && py_isinitialized && PyErr_Occurred ()) + gdbpy_print_stack (); + + gdbpy_enter enter_py; + ... + + What happens is: + - gdbpy_enter::gdbpy_enter () is called, where we run into: + 'if (!gdb_python_initialized) error (_("Python not initialized"));' + - the error propagates to gdb's toplevel + - gdb print the error and exits. + + It seems unnecesssary that we exit gdb. We could continue the + session without python support. + + Fix this by: + - bailing out of gdbpy_initialize if !do_start_initialization + - bailing out of finalize_python if !gdb_python_initialized + + This gets us instead: + ... + $ PYTHONHOME=foo gdb -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + (gdb) python print (1) + Python not initialized + (gdb) + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Fix abort on Py_Initialize + I tried out making python initialization fail by passing an incorrect + PYTHONHOME with python 3.6, and got: + ... + $ PYTHONHOME=foo gdb -q + Fatal Python error: Py_Initialize: Unable to get the locale encoding + ModuleNotFoundError: No module named 'encodings' + + Current thread 0x0000ffff89269c80 (most recent call first): + + Fatal signal: Aborted + ... + Aborted (core dumped) + $ + ... + + This is as per spec: when Py_Initialize () fails, a fatal error is raised + using Py_FatalError. + + This can be worked around using: + ... + $ PYTHONHOME=foo gdb -q -eiex "set python ignore-environment on" + (gdb) + ... + but it would be better if gdb didn't abort. + + I found an article [1] describing two solutions: + - try out Py_Initialize in a separate process, and + - catch the abort using a signal handler. + + This patch implements the latter solution. + + Obviously we cannot call into python anymore after the abort, so we avoid + calling Py_IsInitialized (), and instead use a new variable py_isinitialized. + + This gets us instead: + ... + $ PYTHONHOME=foo gdb -q + Fatal Python error: Py_Initialize: Unable to get the locale encoding + ModuleNotFoundError: No module named 'encodings' + + Current thread 0x0000fffecfd49c80 (most recent call first): + Python not initialized + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32379 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379 + + [1] https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails + +2024-11-22 Tom de Vries + + [gdb/python] Handle !Py_IsInitialized () in gdbpy_initialize + I tried out making python initialization fail by passing an incorrect + PYTHONHOME, and got: + ... + $ PYTHONHOME=foo gdb -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python Exception : No module named 'encodings' + Python not initialized + $ + ... + + The relevant part of the code is: + ... + static void + gdbpy_initialize (const struct extension_language_defn *extlang) + { + if (!do_start_initialization () && PyErr_Occurred ()) + gdbpy_print_stack (); + + gdbpy_enter enter_py; + ... + + What happens is that: + - do_start_initialization returns false because Py_InitializeFromConfig fails, + leaving us in the !Py_IsInitialized () state + - PyErr_Occurred () returns true + - gdbpy_print_stack is called, which prints + "Python Exception : No module named 'encodings" + + The problem is that in the Py_IsInitialized () == false state, very few + functions can be called, and PyErr_Occurred is not one of them [1], and + likewise functions in gdbpy_print_stack. + + Fix this by: + - guarding the PyErr_Occurred / gdbpy_print_stack part with Py_IsInitialized (). + - handling the !Py_IsInitialized () case by printing the failure PyStatus + in do_start_initialization + + This gets us instead: + ... + $ PYTHONHOME=foo ./gdb.sh -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: failed to get the Python codec of the filesystem encoding + Python not initialized + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://docs.python.org/3/c-api/init.html#before-python-initialization + +2024-11-22 Tom de Vries + + [gdbsupport] Handle EINTR in event-pipe.cc + Use gdb syscall wrappers to handle EINTR in event-pipe.cc. + + Tested on aarch64-linux. + +2024-11-22 Tom de Vries + + [gdb] Handle EINTR in ser-event.c + Use gdb syscall wrappers to handle EINTR in ser-event.c. + + Tested on aarch64-linux. + +2024-11-22 Tom de Vries + + [gdb] Add gdb::wait + Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb] Use gdb::waitpid more often + Use gdb::waitpid instead of plain waitpid, making sure that EINTR is handled. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdbsupport] Add gdb::{waitpid,read,write,close} + We have gdb::handle_eintr, which allows us to rewrite: + ... + ssize_t ret; + do + { + errno = 0; + ret = ::write (pipe[1], "+", 1); + } + while (ret == -1 && errno == EINTR); + ... + into: + ... + ssize_t ret = gdb::handle_eintr (-1, ::write, pipe[1], "+", 1); + ... + + However, the call to write got a bit mangled, requiring effort to decode it + back to its original form. + + Instead, add a new function gdb::write that allows us to write: + ... + ssize_t ret = gdb::write (pipe[1], "+", 1); + ... + + Likewise for waitpid, read and close. + + Tested on x86_64-linux. + +2024-11-22 Andrew Burgess + + gdb/disasm: fix demangling when disassembling the current function + When disassembling function symbols in C++ code, if GDB is asked to + disassemble a function by name then the function name in the header + line can be demangled by turning on `set print asm-demangle on`, e.g.: + + (gdb) disassemble foo_type::some_function + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + (gdb) set print asm-demangle on + (gdb) disassemble foo_type::some_function + Dump of assembler code for function foo_type::some_function(my_type): + 0x0000000000401142 <+0>: push %rbp + ... etc ... │ + End of assembler dump. │ + + However, if GDB is disassembling the current function, then this + demangling doesn't work, e.g.: + + (gdb) break foo_type::some_function + Breakpoint 1 at 0x401152: file mangle.cc, line 16. + (gdb) run + Starting program: /tmp/mangle + + Breakpoint 1, foo_type::some_function (this=0x7fffffffa597, obj=...) at mangle.cc:16 + 16 obj.update (); + (gdb) disassemble + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + (gdb) set print asm-demangle on + (gdb) disassemble + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + + This commit fixes this issue, and extends gdb.cp/disasm-func-name.exp, + which was already testing the first case (disassemble by name) to also + cover disassembling the current function. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Ensure locale is restored in do_start_initialization + I noticed in do_start_initialization: + ... + std::string oldloc = setlocale (LC_ALL, NULL); + setlocale (LC_ALL, ""); + ... + if (count == (size_t) -1) + { + fprintf (stderr, "Could not convert python path to string\n"); + return false; + } + setlocale (LC_ALL, oldloc.c_str ()); + ... + that the old locale is not restored if the "return false" is triggered. + + Fix this by using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-11-22 Sam James + + libiberty: sync with gcc again + This imports the following single commit from GCC as of r15-5586-g77f4b1097e6aec: + 961c50410926 Add LTO support + + That change slipped in while I was preparing the previous just-pushed sync. + +2024-11-22 Sam James + + libiberty: sync with gcc + This imports the following commits from GCC as of r15-5375-gbeec291225be9b: + 94bea5dd6c9a libiberity: ANSIfy test-demangle.c + aa84020b2edb libiberty: Fix comment typos + c1b2100e736c libiberty: Restore build with CP_DEMANGLE_DEBUG defined + bb8dd0980b39 libiberty: Fix up > 64K section handling in simple_object_elf_copy_lto_debug_section [PR116614] + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/tdep] Simplify amd64_windows_store_arg_in_reg + Simplify amd64_windows_store_arg_in_reg by: + - replacing memset with value initialization, + - making valbuf a gdb::array_view, allowing us to: + - replace memcpy with std::copy, and + - use valbuf.size () instead of arg->type->size (), and + - dropping the std::min in std::min (type->length (), (ULONGEST) 8), since + we're already asserting that type->length () <= 8. + + Suggested-By: Tom Tromey + + Tested by rebuilding on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb/testsuite] Require local host in gdb.base/bg-exec-sigint-bp-cond.exp + I noticed that gdb.base/bg-exec-sigint-bp-cond.exp fails for remote host + (concretely, host board local-remote-host and target board + remote-gdbserver-on-localhost): + ... + (gdb) c&^M + Continuing.^M + (gdb) bash: line 0: kill: (23834) - Operation not permitted^M + ^M + Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M + 23 return 0;^M + ... + due to getting gdb's pid like this: + ... + set gdb_pid [exp_pid -i [board_info host fileid]] + ... + + For remote host using ssh, this returns the pid of the ssh session on build. + + Fix this by requiring local host. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb/testsuite] Fix gdb.base/bg-exec-sigint-bp-cond.exp for signal merging + The test-case gdb.base/bg-exec-sigint-bp-cond.exp sends 10 SIGINTS to gdb, and + counts whether 10 have arrived. + + Occasionally, less than 10 arrive due to signal merging [1]. + + This is more likely to happen when building gdb with -fsanitize=thread. + + Fix this by instead, sending one SIGINT at a time, and waiting for it to + arrive. + + This still makes the test-case fail if the fix fixing the PR that the + test-case was introduced for is reverted. + + Tested on aarch64-linux and x86_64-linux. + + PR testsuite/32329 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32329 + + [1] https://www.gnu.org/software/libc/manual/html_node/Merged-Signals.html + +2024-11-22 Tom de Vries + + [gdb/build] Workaround tsan select bug + When building gdb with -O0 and -fsanitize-thread, I run into a large number of + timeouts caused by gdb hanging, for instance: + ... + (gdb) continue^M + Continuing.^M + [Inferior 1 (process 378) exited normally]^M + FAIL: gdb.multi/stop-all-on-exit.exp: continue until exit (timeout) + ... + + What happens is the following: + - two inferiors are added, stopped at main + - inferior 1 is setup to exit after 1 second + - inferior 2 is setup to exit after 10 seconds + - the continue command is issued + - because of set schedule-multiple on, both inferiors continue + - the first inferior exits + - gdb sends a SIGSTOP to the second inferior + - the second inferior receives the SIGSTOP, and raises a SIGCHILD + - gdb calls select, and blocks + - the signal arrives, and interrupts select + - ThreadSanitizers signal handler is called, which marks the signal pending + internally + - select returns -1 with errno == EINTR + - gdb calls select again, and blocks + - gdb hangs, waiting for gdb's sigchild_handler to be called + + This is a bug [1] in ThreadSanitizer. When select is called with + timeout == nullptr, it is blocking but ThreadSanitizer doesn't consider it so, + and consequently doesn't see the need to call sigchild_handler. + + Work around this by: + - instead of using the blocking select variant, forcing a small timeout and + - upon timeout calling a function that ThreadSanitizer does consider + blocking: usleep, forcing sigchild_handler to be called. + + Tested on x86_64-linux. + + PR build/32295 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32295 + + [1] https://github.com/google/sanitizers/issues/1813 + +2024-11-22 Tom de Vries + + [gdb] Add gdb_select variant for looping + In interruptible_select we run gdb_select in a loop: + ... + do + { + res = gdb_select (n, readfds, writefds, exceptfds, timeout); + } + while (res == -1 && errno == EINTR); + ... + but man select tells us that: + - if using select() within a loop, the sets (readfds, writefds and + exceptfds) must be reinitialized before each call, and + - timeout should be considered to be undefined after select() returns. + + Add a gdb_select variant: + ... + static int + gdb_select (int n, + const fd_set *req_readfds, fd_set *ret_readfds, + const fd_set *req_writefds, fd_set *ret_writefds, + const fd_set *req_exceptfds, fd_set *ret_exceptfds, + const struct timeval *req_timeout, struct timeval *ret_timeout) + ... + that keeps requested and returned values separate, ensuring that the requested + values stay constant. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-11-22 Martin Storsjö + + ld/PE: Handle MS style import libraries for files named *.exe too + When handling MS style import libraries (also called short import + libraries, or ILF), we need to detect the kind of library. + + So far, this has been done by looking at the member file names + in the import library - in an MS style import library, all the + member files for a specific library have the same member file + name - the name of the runtime module to link against. Usually + this is a DLL - thus we do a case insensitive comparison and + check if the suffix is .dll. + + However, an .exe can also export symbols which can be linked + against in the same way. In particular, if linking against + WDK (Windows Driver Kit) import libraries, e.g. wdmsec.lib, the + import libraries can provide imports for ntoskrnl.exe. + + Instead of specifically checking for *.dll (and *.exe, etc), + invert the condition and skip archive members named *.o and *.obj. + For any remaining archive members, that do contain .idata + sections, apply the renaming. (The renaming is also mostly + harmless if applied where it isn't needed; if archive members + already have unique file names, their relative ordering should + remain intact except for very contrieved cases.) + +2024-11-22 Nelson Chu + Kito Cheng + + RISC-V: Support SiFive extensions: xsfvqmaccdod, xsfvqmaccqoq and xsfvfnrclipxfqf + Those SiFive extensions have been published on the web for a while, and we plan + to implement intrinsics in GCC for those instructions soon. + + NOTE: The original patch was written by Nelson when he was still working at + SiFive, and Kito rebased it to the trunk. Therefore, I kept the author as Nelson + with his SiFive email. + + Document links: + xsfvqmaccdod: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification + xsfvqmaccqoq: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification + xsfvfnrclipxfqf: https://www.sifive.com/document-file/fp32-to-int8-ranged-clip-instructions + +2024-11-22 GDB Administrator + + Automatic date update in version.in + +2024-11-21 Tom Tromey + + Don't put JIT_READER_DIR into help text + The 80-column-help-string self-test can fail if gdb's install + directory is too long, because the help for "jit-reader-load" includes + JIT_READER_DIR. + + This help text is actually somewhat misleading, though. + JIT_READER_DIR is not actually used directly -- instead the relocated + variant is used. + + This patch adds a new "show jit-reader-directory" command and changes + the help text to refer to this instead. I considered adding a "set" + command as well, but since absolute paths are acceptable here, and + since this is a very niche command anyway, I figured there was no need + to bother. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32357 + Reviewed-By: Kévin Le Gouguec + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-11-21 Andrew Burgess + + gdb/build-id: protect against weirdly short build-ids + While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised + that GDB would likely not do what we wanted if a build-id was ever a + single byte. + + Right now, build-ids generated by the GNU linker are 32 bytes, but + there's nothing that forces this to be the case, it's pretty easy to + create a fake, single byte, build-id. Given that the build-id is an + external input (read from the objfile), GDB should protect itself + against these edge cases. + + The problem with build_id_to_bfd_suffix is that this function creates + the path used to lookup either the debug information, or an + executable, based on its build-id. So a 3-byte build-id 0xaabbcc will + look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`. + However, a single byte build-id 0xaa, will look in the file: + `$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right. + + Worse, when looking for an objfile given a build-id GDB will look for + a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing + '/' character. + + I propose that, in build_id_to_bfd_suffix we just return early if the + build-id is 1 byte (or less) with a return value that indicates no + separate file was found. + + For testing I made use of the DWARF assembler. I needed to update the + build-id creation proc, the existing code assumes that the build-id is + a multiple of 4 bytes, so I added some additional padding to ensure + that the generated note was a multiple of 4 bytes, even if the + build-id was not. + + I added a test with a 1 byte build-id, and also for the case where the + build-id has zero length. The zero length case already does what + you'd expect (no debug is loaded) as the bfd library rejects the + build-id when loading it from the objfile, but adding this additional + test is pretty cheap. + + Approved-By: Kevin Buettner + +2024-11-21 Rohr, Stephan + + testsuite: skip confirmation in 'gdb_reinitialize_dir' + Some shells automatically confirm the 'dir' command: + + (gdb) dir + Reinitialize source path to empty? (y or n) + [answered Y; input not from terminal] + Source directories searched: $cdir;$cwd + (gdb) y + dir <...>/gdb/testsuite/gdb.base + Undefined command: "y". Try "help". + + For example, this reprdocues in a MinGW32 environment with + 'TERM=dumb'. Skip sending 'y' if the command is already confirmed. + + Approved-By: Tom Tromey + +2024-11-21 GDB Administrator + + Automatic date update in version.in + +2024-11-20 Peter Bergner + + PowerPC: Add support for RFC02677 - VSX Vector Rotate Left Word + opcodes/ + * ppc-opc.c (powerpc_opcodes): Add xvrlw. + + gas/ + * testsuite/gas/ppc/future.s: Add test for xvrlw. + * testsuite/gas/ppc/future.d: Likewise. + +2024-11-20 Tom Tromey + + Improve choice sorting in ada-lang.c + ada-lang.c has a "sort_choices" function that claims to sort the + symbol choices, but which does not really implement sorting. This + patch changes this code to really sort the result vector, sorting + first by filename, then line number, and finally by the symbol name. + + The filename sorting is done first by comparing basenames. It turns + out that gnatmake and gprbuild invoke the compiler a bit differently, + so depending on which one you use, the results of a naive sort might + be different (due to the use of absolute or relative paths). + +2024-11-20 Andre Vieira + + arm: Support pac_key_* register operand for MRS/MSR in Armv8.1-M Mainline + Add support for pac_key_[pu]_[0-3](_ns)? register operands for the MRS and MSR + instructions when assembling for Armv8.1-M Mainline, as well as adding the + corresponding support for disassembling instructions that use it. + +2024-11-20 Mohamed Bouhaouel + + gdb: add Mohamed Bouhaouel to gdb/MAINTAINERS + +2024-11-20 Nick Clifton + + Remove Debian from SECURITY.txt + +2024-11-20 Andrew Burgess + + gdb/python: fix reference leak in gdb.BreakpointLocation.thread_groups + While reviewing another patch which uses PyList_Append I took a look + at our other uses of PyList_Append in GDB. I spotted something odd + about the use in bplocpy_get_thread_groups. + + We do: + + gdbpy_ref<> num = gdb_py_object_from_ulongest (inf->num); + + At which point `num` will own a reference to the `int` object. But + when we add the object to the result list we do: + + if (PyList_Append (list.get (), num.release ()) != 0) + return nullptr; + + By calling `release` we pass ownership of the reference to + PyList_Append, however, PyList_Append acquires its own reference, it + doesn't take ownership of an existing reference. + + The consequence of this is that we leak the reference held in `num`. + + This mostly isn't a problem though. For small (< 257) integers Python + keeps a single instance of each and just hands out new references. By + leaking the references, these small integers will not be cleaned up as + the Python interpreter shuts down, but that is only done when GDB + exits, so hardly a disaster. As we're dealing with GDB's internal + inferior number here, unless the user has 257+ inferiors, we'll not + actually be leaking memory. + + Still, lets do things right. Switch to using `num.get ()`. Now when + `num` goes out of scope it will decrement the reference count as + needed. + + Approved-By: Tom Tromey + +2024-11-20 Jiawei + + RISC-V: Add Zcmt instructions and csr. + This patch supports Zcmt[1] instruction 'cm.jt' and 'cm.jalt'. + Add new CSR jvt for tablejump using. Since 'cm.jt' and 'cm.jalt' + have the same instructiong encoding, use 'match_cm_jt' and 'match_cm_jalt' + check the 'zcmt_index' field to distinguish them. + + [1] https://github.com/riscvarchive/riscv-code-size-reduction/releases + + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): New extension. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * config/tc-riscv.c (enum riscv_csr_class): New CSR. + (riscv_csr_address): Ditto. + (validate_riscv_insn): New operand. + (riscv_ip): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New CSR. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extension. + * testsuite/gas/riscv/zcmt-fail.d: New test. + * testsuite/gas/riscv/zcmt-fail.l: New test. + * testsuite/gas/riscv/zcmt-fail.s: New test. + * testsuite/gas/riscv/zcmt.d: New test. + * testsuite/gas/riscv/zcmt.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_CM_JT): New opcode. + (MASK_CM_JT): New mask. + (MATCH_CM_JALT): New opcode. + (MASK_CM_JALT): New mask. + (CSR_JVT): New CSR. + (DECLARE_INSN): New declaration. + (DECLARE_CSR): Ditto. + * opcode/riscv.h (EXTRACT_ZCMT_INDEX): New marco. + (ENCODE_ZCMT_INDEX): Ditto. + (enum riscv_insn_class): New class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): New operand. + * riscv-opc.c (match_cm_jt): New function. + (match_cm_jalt): Ditto. + +2024-11-20 GDB Administrator + + Automatic date update in version.in + +2024-11-19 Charles Baylis (tiny change) + + gdb: Remove inappropriate comments + Remove some inappropriate comments in darwin_nat_target::attach, + gnu_nat_target::attach and inf_ptrace_target::attach. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-19 Tom de Vries + + [gdb/contrib] Fix shellcheck warnings in spellcheck.sh + Fix shellcheck warnings in spellcheck.sh, found using shellcheck v0.10.0. + + Ran shellcheck v0.10.0 (on a system with shellcheck version 0.8.0) using this + command from an RFC patch [1]: + ... + $ ./gdb/contrib/pre-commit-shellcheck.sh ./gdb/contrib/spellcheck.sh + ... + + Tested on x86_64-linux + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html + +2024-11-19 Nelson Chu + + RISC-V: Don't report warnings when linking different privileged spec objects. + Since only the abandoned privileged spec v1.9.1 will have conflict csrs, to + keep the compatible we still report warnings when linking privileged spec + v1.9.1 objects with others. But don't report warnings for other compatible + cases because it is actually a bit noisy and useless... + + bfd/ + * elfnn-riscv.c (riscv_merge_attributes): Only report warnings when + linking the abandoned privileged spec v1.9.1 object with others. + ld/ + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Removed. + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + +2024-11-19 Hu, Lin1 + + Support x86 Intel MSR_IMM + gas/ChangeLog: + + * NEWS: Support x86 Intel MSR_IMM. + * config/tc-i386.c (cpu_arch): Add MSR_IMM. + (cpu_flags_match): Add MSR_IMM to APX_F related processing. + (i386_assemble): WRMSRNS's first operand is imm32, so add + MN_wrmsrns like MN_uwrmsr. + * doc/c-i386.texi: Document .msr_imm. + * testsuite/gas/i386/i386.exp: Run MSR_IMM tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/msr_imm-inval.l: New test. + * testsuite/gas/i386/msr_imm-inval.s: Ditto. + * testsuite/gas/i386/x86-64-msr_imm-intel.d: Ditto. + * testsuite/gas/i386/x86-64-msr_imm.d: Ditto. + * testsuite/gas/i386/x86-64-msr_imm.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add REG_VEX_MAP7_F6_L_0_W_0, + PREFIX_VEX_MAP7_F6_L_0_W_0_R_0_X86_64, + X86_64_VEX_MAP7_F6_L_0_W_0_R_0, + VEX_LEN_MAP7_F6, + VEX_W_MAP7_F6_L_0. + (reg_table): New entry for MSR_IMM. + (prefix_table): Ditto. + (x86_64_table): Ditto. + (vex_len_table): Ditto. + (vex_w_table): Ditto. + (map7_f6_opcode): New variable for MAP7. + (get_valid_dis386): Support MAP7. + * i386-gen.c (cpu_flags): Add MSR_IMM. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (i386_cpu_flags): Add cpumsr_imm. + * i386-opc.tbl: Add MSR_IMM instructions. + * i386-tbl.h: Regenerated. + +2024-11-19 Lulu Cai + + LoongArch: Do not relax pcalau12i+ld.d when there is overflow + There is no overflow check for the relaxation of pcalau12i+ld.d => + pcalau12i+addi.d. For instruction sequences that can be relaxed, + they are directly relaxed to pcalau12i+addi.d. However, when the + relative distance between the symbol and the pc exceeds the 32-bit + range, the symbol value cannot be obtained correctly. + + Adds an overflow check for the relaxation of pcalau12i+ld.d. + If it is found that the relaxation will overflow, it will not + be relaxed. + +2024-11-19 GDB Administrator + + Automatic date update in version.in + +2024-11-18 Matthieu Longo + + aarch64: renaming of arm to AArch64 + + aarch64: remove annoying white spaces in bfd/elfnn-aarch64.c + +2024-11-18 Christina Schimpe + + LAM: Enable tagged pointer support for watchpoints. + The Intel (R) linear address masking (LAM) feature modifies the checking + applied to 64-bit linear addresses. With this so-called "modified + canonicality check" the processor masks the metadata bits in a pointer + before using it as a linear address. LAM supports two different modes that + differ regarding which pointer bits are masked and can be used for + metadata: LAM 48 resulting in a LAM width of 15 and LAM 57 resulting in a + LAM width of 6. + + This patch adjusts watchpoint addresses based on the currently enabled + LAM mode using the untag mask provided in the /proc//status file. + As LAM can be enabled at runtime or as the configuration may change + when entering an enclave, GDB checks enablement state each time a watchpoint + is updated. + + In contrast to the patch implemented for ARM's Top Byte Ignore "Clear + non-significant bits of address on memory access", it is not necessary to + adjust addresses before they are passed to the target layer cache, as + for LAM tagged pointers are supported by the system call to read memory. + Additionally, LAM applies only to addresses used for data accesses. + Thus, it is sufficient to mask addresses used for watchpoints. + + The following examples are based on a LAM57 enabled program. + Before this patch tagged pointers were not supported for watchpoints: + ~~~ + (gdb) print pi_tagged + $2 = (int *) 0x10007ffffffffe004 + (gdb) watch *pi_tagged + Hardware watchpoint 2: *pi_tagged + (gdb) c + Continuing. + Couldn't write debug register: Invalid argument. + ~~~~ + + Once LAM 48 or LAM 57 is enabled for the current program, GDB can now + specify watchpoints for tagged addresses with LAM width 15 or 6, + respectively. + + Approved-By: Felix Willgerodt + +2024-11-18 Christina Schimpe + + gdb: Make tagged pointer support configurable. + The gdbarch function gdbarch_remove_non_address_bits adjusts addresses to + enable debugging of programs with tagged pointers on Linux, for instance for + ARM's feature top byte ignore (TBI). + Once the function is implemented for an architecture, it adjusts addresses for + memory access, breakpoints and watchpoints. + + Linear address masking (LAM) is Intel's (R) implementation of tagged + pointer support. It requires certain adaptions to GDB's tagged pointer + support due to the following: + - LAM supports address tagging for data accesses only. Thus, specifying + breakpoints on tagged addresses is not a valid use case. + - In contrast to the implementation for ARM's TBI, the Linux kernel supports + tagged pointers for memory access. + + This patch makes GDB's tagged pointer support configurable such that it is + possible to enable the address adjustment for a specific feature only (e.g + memory access, breakpoints or watchpoints). This way, one can make sure + that addresses are only adjusted when necessary. In case of LAM, this + avoids unnecessary parsing of the /proc//status file to get the + untag mask. + + Reviewed-By: Felix Willgerodt + (AArch64) Tested-By: Luis Machado + Approved-By: Luis Machado + +2024-11-18 Jan Beulich + + x86: rename SPACE_{,E}VEX_MAP + Map7 already has dual purpose for USER-MSR (and is to gain more for + MSR-IMM), while Map5 is about to gain VEX uses for AMX extensions. Drop + the not really meaningful infixes and (in the opcode table) prefixes, + retaining merely EVexMap4 for encoding EVex128 at the same time. + +2024-11-18 Jan Beulich + + x86: VP2INTERSECT{D,Q} have mask register destination group + Much like AVX512-{4FMAPS,4VNNIW} have a constraint on their register + source, there's a constraint (need to be even) on the destination + register here. + + Adjust "good" test cases accordingly, and add a new test case to check + the warning. + +2024-11-18 Jan Beulich + + x86: generalize "implicit quad group" handling + We'll want to re-use it for VP2INTERSECT{D,Q}. + + While there add a testcase for the similarly affected AVX512-4VNNIW + insns. + +2024-11-18 Tom de Vries + + [gdb/contrib] Fix spellcheck.sh for bash < 5.1 + Since commit 5cb0406bb64 ("[gdb/contrib] Handle capitalized words in + spellcheck.sh"), spellcheck.sh uses '${pat@u}' which is available starting + bash 5.1, and consequently the script breaks with bash 4.4. + + Fix this by checking for the bash version, and using an alternative + implementation for bash < 5.1. + + Tested on x86_64-linux. + +2024-11-18 Benjamin Drung + + ld: Support percent-encoded JSON in --package-metadata + Specifying the compiler flag `-Wl,--package-metadata=` will not + work in case the JSON contains a comma, because compiler drivers eat + commas. Example: + + ``` + $ echo "void main() { }" > test.c + $ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c + /usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory + collect2: error: ld returned 1 exit status + ``` + + The quotation marks in the JSON value do not work well with shell nor + make. Specifying the `--package-metadata` linker flag in a `LDFLAGS` + environment variable might loose its quotation marks when it hits the + final compiler call. + + So support percent-encoded and %[string] encoded JSON data in the + `--package-metadata` linker flag. Percent-encoding is used because it is + a standard, simple to implement, and does take too many additional + characters. %[string] encoding is supported for having a more readable + encoding. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32003 + Bug-Ubutru: https://bugs.launchpad.net/bugs/2071468 + +2024-11-18 Jan Beulich + + gas: move had_errors() invocation in finishing of subsegs + Invoking this repeatedly in an inner loop is not only inefficient, but + may lead to inconsistencies in e.g. the listings that the original + comment author cared about. (Accept potential inconsistencies across + distinct sections though, to cover all invocations of the function.) + + ELF: SHF_STRINGS isn't really tied to SHF_MERGE + It's not overly useful without it, but the spec doesn't name any + dependency between the two. People may want to use it for purely + informational purposes, for example. Adjust, in particular, entity size + processing to be engaged if either flag is set, as mandated by the spec. + +2024-11-18 Jan Beulich + + ELF: SHF_MERGE vs SHT_NOBITS + bfd/merge.c puts in quite some effort to track mergable sections. That's + all wasted for sections which don't have contents, as for them + _bfd_write_merged_section() will never be called. + + With the combination not having any useful effect, also warn about this + in gas. + +2024-11-18 Jan Beulich + + gas/ELF: also reject merge entity size being zero + This won't have any useful effect, so is at best marginally less bogus + than a negative value. + + The change actually points out a flawed (for Arm) testcase: @ is a + comment character there. + +2024-11-18 Jens Remus + + s390: Add arch15 Concurrent-Functions Facility insns + opcodes/ + * s390-opc.txt: Add arch15 Concurrent-Functions Facility + instructions. + * s390-opc.c (INSTR_SSF_RRDRD2, MASK_SSF_RRDRD2): New SSF + instruction format variant. + + gas/testsuite/ + * gas/s390/zarch-arch15.d: Tests for arch15 Concurrent-Functions + Facility instructions. + * gas/s390/zarch-arch15.s: Likewise. + +2024-11-18 Jens Remus + + s390: Add arch15 instruction names + opcodes/ + * s390-opc.txt: Add arch15 instruction names. + +2024-11-18 Tom de Vries + + [gdb] Fix some typos + Run gdb/contrib/spellcheck.sh on directories gdb*. + + Fix typo: + ... + unkown -> unknown + ... + + Tested on x86_64-linux. + +2024-11-18 Tom de Vries + + [gdb/contrib] Add spellcheck.sh --print-dictionary + Add an option --print-dictionary to spellcheck.sh that allows us to inspect + the effective dictionary. + + Verified with shellcheck. + +2024-11-18 Tom de Vries + + [gdb/contrib] Allow thru in spellcheck.sh + Eli mentioned that "thru" is a widely-accepted shorthand [1]. + + Skip the "thru->through" rule by adding an overriding identity rule + "thru->thru". + + Verified with shellcheck. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213380.html + +2024-11-18 Sam James + + gprofng: fix -std=gnu23 compatibility wrt unprototyped functions + C23 removes support for unprototyped functions. Fix function pointer types + accordingly. + + This does not fix all instances, there's a few left as I commented on in + PR32374 (e.g. setitimer which I have a local workaround for but it involves + a glibc implementation detail; the Linaro precommit CI tester pointed that + out too, so dropped that). + + ChangeLog: + PR gprofng/32374 + + * libcollector/collector.c (collector_sample): Fix prototype. + * libcollector/envmgmt.c (putenv): Ditto. + (_putenv): Ditto. + (__collector_putenv): Ditto. + (setenv): Ditto. + (_setenv): Ditto. + (__collector_setenv): Ditto. + (unsetenv): Ditto. + (_unsetenv): Ditto. + (__collector_unsetenv): Ditto. + * libcollector/jprofile.c (open_experiment): Ditto. + (__collector_jprofile_enable_synctrace): Ditto. + (jprof_find_asyncgetcalltrace): Ditto. + * libcollector/libcol_util.c (__collector_util_init): Ditto. + (ARCH): Ditto. + * libcollector/mmaptrace.c (collector_func_load): Ditto. + (collector_func_unload): Ditto. + * libcollector/unwind.c (__collector_ext_unwind_init): Ditto. + * src/collector_module.h: Ditto. + +2024-11-18 Sam James + + ld: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * pdb.c (add_stream): Return NULL. + +2024-11-18 Sam James + + binutils: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * prdbg.c (visibility_name): Return NULL. + +2024-11-18 Sam James + + opcodes: fix -std=gnu23 compatibility wrt static_assert + static_assert is declared in C23 so we can't reuse that identifier: + * Define our own static_assert conditionally; + + * Rename "static assert" hacks to _N as we do already in some places + to avoid a conflict. + + ChangeLog: + PR ld/32372 + + * i386-gen.c (static_assert): Define conditionally. + * mips-formats.h (MAPPED_INT): Rename identifier. + (MAPPED_REG): Rename identifier. + (OPTIONAL_MAPPED_REG): Rename identifier. + * s390-opc.c (static_assert): Define conditionally. + +2024-11-18 Sam James + + bfd: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * elf32-ppc.c (ppc_elf_tls_setup): Return NULL. + * elf32-xtensa.c (translate_reloc_bfd_fix): Ditto. + (translate_reloc): Ditto. + * elf64-ppc.c (update_local_sym_info): Ditto. + * mach-o.c (bfd_mach_o_lookup_uuid_command): Ditto. + * xsym.c (bfd_sym_read_name_table): Ditto. + +2024-11-18 GDB Administrator + + Automatic date update in version.in + +2024-11-17 H.J. Lu + + x86-64: Always check IBT PLT before BND PLT + Since BND PLT has been deprecated and the same IBT PLT is used for both + x86-64 and x32, always check IBT PLT before BND PLT when synthesizing + PLT symtab. + + * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Always check + elf_x86_64_lazy_ibt_plt and elf_x86_64_non_lazy_ibt_plt first. + +2024-11-17 Ijaz, Abdul B + + gdb: Update linkage name lookup function to allow mst_file_data/bss types. + From the commit 667ed4b14ddaa9af196481f1757c0e517e80b6ed onward, instead + of normal name GDB looks for the "jit_descriptor" linkage name in the JIT + code initialization. Without this change, the function + "lookup_minimal_symbol_linkage", only matches the non-static data. So in + case jit_debugger is static type then setting up breakpoint in the JIT code + fails. Issue is seen for the intel compilers, where jit_debug_descriptor has + static type i.e. "mst_file_data". Hence lookup_minimal_symbol_linkage returns + nullptr for it. So, in this case breakpoint does not hit in the JIT code. + To resolve this, the commit introduces a new boolean argument to the + lookup_minimal_symbol_linkage function. This argument allows the function to + also match mst_file_data and mst_file_bss types when set to true. The + function is called with this new argument set to true only from JIT code + initialization handling, ensuring that the current behavior remains unchanged + for other cases. Because handling of static types of data symbols for all cases + result in regression for "gdb.base/print-file-var.exp" test. + + Example of minsym for the JIT code emitted by the intel compilers where + lookup_minimal_symbol_linkage fails without this change because jit_debugger + type is "mst_file_data". + + (top-gdb) p *msymbol + $1 = { = + {m_name = 0x7fffcc77dc95 "__jit_debug_descriptor", + m_value = {ivalue = 84325936, block = 0x506b630, + bytes = 0x506b630 , + address = 0x506b630, unrel_addr = (unknown: 0x506b630), + common_block = 0x506b630, chain = 0x506b630}, + language_specific = {obstack = 0x0, demangled_name = 0x0}, + m_language = language_unknown, ada_mangled = 0, m_section = 29}, + m_size = 24, filename = 0x55555a751b70 "JITLoaderGDB.cpp", + m_type = mst_file_data, created_by_gdb = 0, + m_target_flag_1 = 0, m_target_flag_2 = 0, m_has_size = 1, + name_set = 1, hash_next = 0x55555b86e4f0, demangled_hash_next = 0x0} + + Updated the test "jit-elf-so.exp" to test the static type of jit_descriptor + object. + + Approved-By: Tom Tromey + +2024-11-17 H.J. Lu + + x86-64: Drop x32 references in PLT entry variables + e9c11d58b95 x86-64: Remove BND from 64-bit IBT PLT + + removed the BND prefix from 64-bit IBT PLT by using x32 IBT PLT. + + Drop x32 references in PLT entry variables. + + * elf64-x86-64.c (elf_x86_64_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_lazy_bnd_ibt_plt_entry): This. + (elf_x32_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_lazy_ibt_plt_entry): This. + (elf_x86_64_non_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_non_lazy_bnd_ibt_plt_entry): This. + (elf_x32_non_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_non_lazy_ibt_plt_entry): This. + (elf_x86_64_eh_frame_lazy_ibt_plt): Renamed to ... + (elf_x86_64_eh_frame_lazy_bnd_ibt_plt): This. + (elf_x32_eh_frame_lazy_ibt_plt): Renamed to ... + (elf_x86_64_eh_frame_lazy_ibt_plt): This. + (elf_x86_64_lazy_ibt_plt): Renamed to ... + (elf_x86_64_lazy_bnd_ibt_plt): This. Updated. + (elf_x32_lazy_ibt_plt): Renamed to ... + (elf_x86_64_lazy_ibt_plt): This. Updated. + (elf_x86_64_non_lazy_ibt_plt): Renamed to ... + (elf_x86_64_non_lazy_bnd_ibt_plt): This. Updated. + (elf_x32_non_lazy_ibt_plt): Renamed to ... + (elf_x86_64_non_lazy_ibt_plt): This. Updated. + (elf_x86_64_get_synthetic_symtab): Updated. + (elf_x86_64_link_setup_gnu_properties): Likewise. + +2024-11-17 GDB Administrator + + Automatic date update in version.in + +2024-11-16 Tom Tromey + + Use bool for solib::symbols_loaded + This changes solib::symbols_loaded to be of type 'bool'. + + Approved-By: Simon Marchi + +2024-11-16 GDB Administrator + + Automatic date update in version.in + +2024-11-15 Barnabás Pőcze + + PR 32359, --dependency-file: wrong error message if fopen fails + Use of %E in ld error messages requires bfd_error to be set. + +2024-11-15 Tom de Vries + + [gdb/symtab] Fix segfault with dwp file + Consider the following test-case: + ... + $ cat test.c + int main (void) { return 0; } + $ clang -g -gsplit-dwarf test.c -o test + $ llvm-dwp -e test -o test.dwp + ... + + This runs into a segmentation fault: + ... + $ gdb -q -batch test + Fatal signal: Segmentation fault + ... + + The segmentation fault happens because in read_dwo_str_index this line sets p + to nullptr: + ... + const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer; + ... + while the following code expects it to point to some data. + + The section we're trying to read is: + ... + (gdb) p reader->dwo_file->sections.str_offsets + $4 = {s = {section = 0xffffcc00a9d0, containing_section = 0xffffcc00a9d0}, + buffer = 0x0, size = 28, virtual_offset = 0, readin = false, is_virtual = true} + ... + + At first glance, the section is not readin, but actually it is. + + This is a virtual section, meaning part of a containing section: + ... + (gdb) p *reader->dwo_file->sections.str_offsets.s.containing_section + $8 = {s = {section = 0xffffcc00cde8, containing_section = 0xffffcc00cde8}, + buffer = 0xffffcc009650 "\030", size = 28, virtual_offset = 0, readin = true, + is_virtual = false} + ... + which is readin. + + Fix this in create_dwp_v2_or_v5_section by initializing the buffer of the + virtual section using the buffer of the containing section: + ... + result.buffer = section->buffer + offset; + ... + + Unfortunately it's difficult to write a test-case for this. We'll have to + teach the dwarf assembler to generate dwp files. + + Tested on aarch64-linux. + + This is a partial fix for PR symtab/31497. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497 + +2024-11-15 Tom Tromey + + Improvements to gdb.LazyString documentation + I noticed the gdb.LazyString documentation did not mention how to + create one. Then, while adding this, I found a couple other ways that + this documentation could be clarified. + + Approved-By: Eli Zaretskii + +2024-11-15 Andrew Burgess + + gdb/testsuite: skip gdb.opt/inline-entry.exp for gcc 7 and older + It was pointed out that the recently added gdb.opt/inline-entry.exp + test would fail when run using gcc 7 and earlier, on an x86-64 target: + + https://inbox.sourceware.org/gdb-patches/9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de + + Bernd Edlinger points out that, for gcc, the test relies on the + -gstatement-frontiers work which was added in gcc 8.x: + + https://inbox.sourceware.org/gdb-patches/DU2PR08MB10263357597688D9D66EA745CE4242@DU2PR08MB10263.eurprd08.prod.outlook.com + + For gcc 7.x and older, without the -gstatement-frontiers work, the + compiler uses DW_AT_entry_pc differently, which leads to a poorer + debug experience. + + Here is the interesting source line from inline-entry.c: + + if ((global && bar (1)) || bar (2)) + + And here's some of the relevant disassembly output: + + Dump of assembler code for function main: + 0x401020 <+0>: mov 0x3006(%rip),%eax (1) + 0x401026 <+6>: test %eax,%eax (2) + 0x401028 <+8>: mov 0x2ffe(%rip),%eax (3) + 0x40102e <+14>: je 0x401038 (4) + 0x401030 <+16>: sub $0x1,%eax (5) + 0x401033 <+19>: jne 0x40103d (6) + + Lines (1), (2), and (4) represent the check of 'global'. However, + line (3) is actually the first instruction for 'bar' which has been + inlined. Lines (5) and (6) are also part of the first inlined 'bar' + function. + + If the check of 'global' returns false then the first call to 'bar' + should never happen, this is accomplished by the branch at (4) being + taken. + + For gcc 8+, gcc generates a DW_AT_entry_pc with the value 0x401030, + this is where GDB places a breakpoint for 'bar', and this address is + after the branch at line (4), and so, if the call to 'bar' never + happens, the breakpoint is never hit. + + For gcc 7 and older, gcc generates a DW_AT_entry_pc with the value + 0x401028, which is the first address associated with the inline 'bar' + function. Unfortunately, this address is also before the check of + 'global' has completed, this means that GDB hits the 'bar' breakpoint + before the inferior has decided if 'bar' should actually be called or + not. + + I don't think there's really much GDB can do in the older gcc + versions, we are placing the breakpoint at the entry point, and this + is within bar. Given that this test does really depend on the newer + gcc behaviour, I think the only sensible solution is to skip this test + when an older version of gcc is being used. + + I've incorporated the check for -gstatement-frontiers support that + Bernd suggested and now the test will be skipped for older versions of + GCC. + + Approved-By: Tom de Vries + +2024-11-15 GDB Administrator + + Automatic date update in version.in + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in bppy_init + As with the previous two commits, this commit fixes a location where + we called PyObject_IsTrue without including an error check, this time + in bppy_init. + + The 'qualified' argument is supposed to be a bool, the docs say: + + The optional QUALIFIED argument is a boolean that allows + interpreting the function passed in 'spec' as a fully-qualified + name. It is equivalent to 'break''s '-qualified' flag (*note + Linespec Locations:: and *note Explicit Locations::). + + It's not totally clear that the only valid values are True or False, + but I'm choosing to interpret the docs that way, and so I've added a + PyBool_Type check during argument parsing. Now, if a non-bool is + passed the user will get a TypeError during argument parsing. I've + added a test to cover this case. + + This is a potentially breaking change to the Python API, but hopefully + this will not impact too many people. I've added a NEWS entry to + highlight this change. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed + Like the previous commit, I discovered that in micmdpy_set_installed + we were calling PyObject_IsTrue, but not checking for a possible error + value being returned. + + The micmdpy_set_installed function implements the + gdb.MICommand.installed attribute, and the documentation indicates that + this attribute should only be assigned a bool: + + This attribute is read-write, setting this attribute to 'False' + will uninstall the command, removing it from the set of available + commands. Setting this attribute to 'True' will install the + command for use. + + So I propose that instead of using PyObject_IsTrue we use + PyBool_Check, and if the new value fails this check we raise an + error. We can then compare the new value to Py_True directly instead + of calling PyObject_IsTrue. + + This is a potentially breaking change to the Python API, but hopefully + this will not impact too many people, and the fix is pretty + easy (switch to using a bool). I've added a NEWS entry to draw + attention to this change. + + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in py-arch.c + Building on the previous two commits, I was auditing our uses of + PyObject_IsTrue looking for places where we were missing an error + check. + + The gdb.Architecture.integer_type() function takes a 'signed' argument + which should be a 'bool', and the docs do say: + + If SIGNED is not specified, it defaults to 'True'. If SIGNED is + 'False', the returned type will be unsigned. + + Currently we use PyObject_IsTrue, but we are missing an error check. + + To fix this I've tightened the code to enforce the bool requirement at + the point that the arguments are parsed. With that done I can remove + the call to PyObject_IsTrue and instead compare to Py_True directly, + the object in question will always be a PyBool_Type. + + However, we were testing that passing a non-bool argument for 'signed' + is treated as Py_False, this was added with this commit: + + commit 90fe61ced1c9aa4afb263326e336330d15603fbf + Date: Mon Nov 29 13:53:06 2021 +0000 + + gdb/python: don't use the 'p' format for parsing args + + which is when the PyObject_IsTrue call was added. Given that the docs + do seem pretty clear that only True or False are suitable argument + values, my proposal is that we just remove these tests and instead + test that any non-bool argument value for 'signed' gives a TypeError. + + This is a breaking change to the Python API, however, my hope is that + this is such a edge case that it will not cause too many problem. + I've added a NEWS entry to highlight this change though. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: remove some additional PyObject_IsTrue calls + After the previous commit I audited all our uses of PyObject_IsTrue + looking for places where we were missing an error check. I did find + some that are missing error checks in places where we really should + have error checks, and I'll fix those in later commits. + + This commit however, focuses on those locations where PyObject_IsTrue + is called, there is no error check, and the error check isn't really + necessary because we already know that the object we are dealing with + is of type PyBool_Type. + + Inline with the previous commit, in these cases I have removed the + PyObject_IsTrue call, and replaced it with a comparison against + Py_True. In one location where it is not obvious that the object we + have is PyBool_Type I've added an assert, but in the other cases the + comparison to Py_True immediately follows a PyBool_Check call, so an + assert would be redundant. + + I've added a test for the gdb.Value.format_string styling argument + being passed a non-bool value as this wasn't previously being tested, + though this new test will pass before and after this commit. + + There should be no functional change after this commit. + + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: remove PyObject_IsTrue call in gdbpy_handle_missing_debuginfo + In this review: + + https://inbox.sourceware.org/gdb-patches/87wmirfzih.fsf@tromey.com + + Tom pointed out that using PyObject_IsTrue as I was doing, though + technically fine, at least appears to be missing an error check, and + that it would be better to compare to Py_True directly. I made that + change in the patch Tom was commenting on, but I'd actually copied + that code from elsewhere in python/python.c, so this commit updates + the original code inline with Tom's review feedback. + + There should be no functional change after this commit. + + Approved-By: Tom Tromey + +2024-11-14 GDB Administrator + + Automatic date update in version.in + +2024-11-13 Tom de Vries + + [gdb/tdep] Handle syscall clock_gettime64 for arm-linux + When running test-case gdb.reverse/time-reverse.exp on arm-linux, I run into: + ... + (gdb) continue^M + Continuing.^M + Process record and replay target doesn't support syscall number 403^M + Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M + Process record: failed to record execution log.^M + ^M + Program stopped.^M + 0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: $exp: mode=c: continue to breakpoint: marker2 + ... + + Syscall number 403 stands for clock_gettime64 on arm-linux. + + Fix this by handling 403 in arm_canonicalize_syscall, and handling + gdb_sys_clock_gettime64 elsewhere. + + Since i386_canonicalize_syscall is the identity function, enum value + gdb_sys_clock_gettime64 gets a value to match i386, which also happens to be + 403. + + Tested on arm-linux. + + Approved-By: Guinevere Larsen (record-full) + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle capitalized words in spellcheck.sh + The dictionary contains a few entries with capital letters: + ... + $ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l + 143 + ... + but they don't look too interesting in the gdb context (for instance, + Habsbourg->Habsburg), so filter them out. + + That leaves us with entries looking only like "foobat->foobar", so add + handling of capitalized words, such that we also rewrite "Foobat" to "Foobar". + + Tested on aarch64-linux. Verified with shellcheck. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Add "doens't->doesn't" to common-misspellings.txt + Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run + gdb/contrib/spellcheck.sh to fix this in a few files. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle double quotes in spellcheck.sh + Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the + following typos: + ... + inheritence -> inheritance + psuedo -> pseudo + succeded -> succeeded + ... + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle parentheses in spellcheck.sh + Currently, text adjacent to parentheses is not spell-checked: + ... + $ cat tmp.txt + (upto) + $ ./gdb/contrib/spellcheck.sh tmp.txt + $ + ... + + Add handling of parentheses, such that we get: + ... + $ ./gdb/contrib/spellcheck.sh tmp.txt + upto -> up to + $ + ... + + Rerun spellcheck.sh, resulting in a few "thru->through" replacements. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [precommit] Add some documentation in .pre-commit-config.yaml + Add some documention to .pre-commit-config.yaml that explains: + - what the file is, + - how it can be used, and + - how to skip specific hooks in case of trouble. + + Approved-By: Tom Tromey + +2024-11-13 Tom de Vries + + [gdb/tdep] Fix recording of T1 push + When running test-case gdb.reverse/recursion.exp on arm-linux with target + board unix/-mthumb, I run into: + ... + (gdb) PASS: gdb.reverse/recursion.exp: Skipping recursion from inside + reverse-next^M + bar (x=4195569) at /home/linux/gdb/src/gdb/testsuite/gdb.reverse/recursion.c:34^M + 34 int r = foo (x);^M + (gdb) FAIL: gdb.reverse/recursion.exp: print frame when stepping out + ... + + The problem is the recording of the T1 push instruction [1,2], specifically: + ... + 000004d8 : + 4d8: b580 push {r7, lr} + ... + + The current code fails to add a memory record for the memory written with the + value of the lr register. + + Fix this by adding the missing memory record. + + Tested on arm-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Luis Machado + + [1] https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Instruction-Details/Encoding-of-lists-of-ARM-core-registers + [2] https://developer.arm.com/documentation/ddi0597/2024-09/T32-Instructions-by-Encoding/16-bit?lang=en#pushpop16 + +2024-11-13 Tom de Vries + + [gdb/tdep] Handle sycall statx for arm-linux + When running test-case gdb.reverse/fstatat-reverse.exp on arm-linux, I run + into: + ... + (gdb) continue^M + Continuing.^M + Process record and replay target doesn't support syscall number 397^M + Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M + Process record: failed to record execution log.^M + ^M + Program stopped.^M + 0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2 + ... + + Syscall number 397 stands for statx on arm-linux. + + Fix this by handling 397 in arm_canonicalize_syscall. + + Tested on arm-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Luis Machado + +2024-11-13 Bernd Edlinger + + gdb: stepping between inline functions with multiple ranges + I (Andrew) have split this small change from a larger patch which was + posted here: + + https://inbox.sourceware.org/gdb-patches/AS1PR01MB9465608EBD5D62642C51C428E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com + + And I have written the stand alone test for this issue. The original + patch included this paragraph to explain this change (I've fixed one + typo in this text replacing 'program' with 'function'): + + ... it may happen that the infrun machinery steps from one inline + range to another inline range of the same inline function. That can + look like jumping back and forth from the calling function to the + inline function, while really the inline function just jumps from a + hot to a cold section of the code, i.e. error handling. + + The important thing that happens here is that both the outer function + and the inline function must both have multiple ranges. When the + inferior is within the inline function and moves from one range to + another it is critical that the address we stop at is the start of a + range in both the outer function and the inline function. + + The diagram below represents how the functions are split and aligned: + + (A) (B) + bar: |------------| |---| + foo: |------------------| |--------| + + The inferior is stepping through 'bar' and eventually reaches + point (A) at which point control passes to point (B). + + Currently, when the inferior stops, GDB notices that both 'foo' and + 'bar' start at address (B), and so GDB uses the inline frame mechanism + to skip 'bar' and tells the user that the inferior is in 'foo'. + + However, as we were in 'bar' before the step then it makes sense that + we should be in 'bar' after the step, and this is what the patch does. + + There are two tests using the DWARF assembler, the first checks the + above situation and ensures that GDB reports 'bar' after the step. + + The second test is similar, but after the step we enter a new range + where a different inline function starts, something like this: + + (A) (B) + bar: |------------| + baz: |---| + foo: |------------------| |--------| + + In this case as we step at (A) and land at (B) we leave 'bar' and + expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as + that is a completely different inline function. And this is, indeed, + what we see. + + Co-Authored-By: Andrew Burgess + +2024-11-13 Andrew Burgess + + gdb: fix handling of DW_AT_entry_pc of inlined subroutines + The entry PC for a DIE, e.g. an inline function, might not be the base + address of the DIE. Currently though, in block::entry_pc(), GDB + always returns the base address (low-pc or the first address of the + first range) as the entry PC. + + This commit extends the block class to carry the entry PC as a + separate member variable. Then the DWARF reader is extended to read + and set the entry PC for the block. Now in block::entry_pc(), if the + entry PC has been set, this is the value returned. + + If the entry-pc has not been set to a specific value then the old + behaviour of block::entry_pc() remains, GDB will use the block's base + address. Not every DIE will set the entry-pc, but GDB still needs to + have an entry-pc for every block, so the existing logic supplies the + entry-pc for any block where the entry-pc was not set. + + The DWARF-5 spec for reading the entry PC is a super-set of the spec + as found in DWARF-4. For example, if there is no DW_AT_entry_pc then + DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base + address, which is DW_AT_low_pc or the first address in the first range + specified by DW_AT_ranges if there is no DW_AT_low_pc. + + I have taken the approach of just implementing the DWARF-5 spec for + everyone. There doesn't seem to be any benefit to deliberately + ignoring a ranges based entry PC value for DWARF-4. If some naughty + compiler has emitted that, then lets use it. + + Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5 + allows an address or a constant, where the constant is an offset from + the base address. I allow both approaches for all DWARF versions. + There doesn't seem to be any downsides to this approach. + + I ran into an issue when testing this patch where GCC would have the + DW_AT_entry_pc point to an empty range. When GDB parses the ranges + any empty ranges are ignored. As a consequence, the entry-pc appears + to be outside the address range of a block. + + The empty range problem is certainly something that we can, and should + address, but that is not the focus of this patch, so for now I'm + ignoring that problem. What I have done is added a check: if the + DW_AT_entry_pc is outside the range of a block then the entry-pc is + ignored, GDB will then fall-back to its default algorithm for + computing the entry-pc. + + If/when in the future we address the empty range problem, these + DW_AT_entry_pc attributes will suddenly become valid and GDB will + start using them. Until then, GDB continues to operate as it always + has. + + An early version of this patch stored the entry-pc within the block + like this: + + std::optional m_entry_pc; + + However, a concern was raised that this, on a 64-bit host, effectively + increases the size of block by 16-bytes (8-bytes for the CORE_ADDR, + and 8-bytes for the std::optional's bool plus padding). + + If we remove the std::optional part and just use a CORE_ADDR then we + need to have a "special" address to indicate if m_entry_pc is in use + or not. I don't really like using special addresses; different + targets can access different address ranges, even zero is a valid + address on some targets. + + However, Bernd Edlinger suggested storing the entry-pc as an offset, + and I think that will resolve my concerns. So, we store the entry-pc + as a signed offset from the block's base address (the first address of + the first range, or the start() address value if there are now + ranges). Remember, ranges can be out of order, in which case the + first address of the first range might be greater than the entry-pc. + + When GDB needs to read the entry-pc we can add the offset onto the + blocks base address to recalculate it. + + With this done, on a 64-bit host, block only needs to increase by + 8-bytes. + + The inline-entry.exp test was originally contributed by Bernd here: + + https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com + + though I have made some edits, making more use of lib/gdb.exp + functions, making the gdb_test output patterns a little tighter, and + updating the test to run with Clang. I also moved the test to + gdb.opt/ as that seemed like a better home for it. + + Co-Authored-By: Bernd Edlinger + +2024-11-13 Mark Harmstone + + gas: add .cv_ucomp and .cv_scomp pseudo-directives + Add .cv_ucomp and .cv_scomp pseudo-directives for object files for + Windows targets, which encode compressed CodeView integers according to + the algorithm in CVCompressData in + https://github.com/Microsoft/microsoft-pdb/blob/master/include/cvinfo.h. + This is essentially Microsoft's answer to the LEB128, though used in far + fewer places. + + CodeView uses these to encode the "binary annotations" in the + S_INLINESITE symbol, which express the relationship between code offsets + and line numbers in inlined functions. This has to be done in the + assembler as GCC doesn't know how many bytes each instruction takes up. + There's no equivalent for this for MSVC or LLVM, as in both cases the + assembler and compiler are integrated. + + .cv_ucomp represents an unsigned big-endian integer between 0 and 0x1fffffff, + taking up 1, 2, or 4 bytes: + + Value between 0 and 0x7f: + + 0aaaaaaa -> 0aaaaaaa (identity-mapped) + + Value between 0x80 and 0x3fff: + + 00aaaaaa bbbbbbbb -> 10aaaaaa bbbbbbbb + + Value between 0x4000 and 0x1fffffff: + 000aaaaa bbbbbbbb ccccccccc dddddddd -> + 110aaaaa bbbbbbbb ccccccccc dddddddd + + .cv_scomp represents a signed big-endian integer between -0xfffffff and + 0xfffffff, encoded according to EncodeSignedInt32 in cvinfo.h. The + absolute value of the integer is shifted left one bit, the LSB set + for a negative value, and the result expressed as if it were a + .cv_ucomp: cv_scomp(x) = cv_ucomp((abs(x) << 1) | (x < 0 ? 1 : 0)) + +2024-11-13 GDB Administrator + + Automatic date update in version.in + +2024-11-12 Mark Wielaard + + bfd: Add WARN_CFLAGS_FOR_BUILD to doc/chew.c build, fix warnings + doc/chew.c was compiled without any warning flags set. Adding the + common warnings for build showed various issues with non-static + functions missing prototypes and globals with common names (ptr and + idx) that shadowed local arguments or variables. + + * doc/local.mk (doc/chew.stamp): Add WARN_CFLAGS_FOR_BUILD. + * Makefile.in: Regenerate. + * doc/chew.c (idx): Rename to pos_idx. + (ptr): Rename to buf_ptr. + (xmalloc): Make static. + (xrealloc): Likewise. + (xstrdup): Likewise. + (nextword): Likewise. + (newentry): Likewise. + (add_to_definition): Likewise. + (add_intrinsic): Likewise. + (compile): Likewise. + (icopy_past_newline): Rename idx to pos_idx, ptr to buf_ptr. + (get_stuff_in_command): Likewise. + (skip_past_newline): Likewise. + (perform): Likewise. + (main): Likewise. + +2024-11-12 Andrew Burgess + + gdb/testsuite: some cleanups in gdb.base/annota{1,3}.exp tests + Fedora GDB has, for years, carried an out of tree patch for the + gdb.base/annota{1,3}.exp tests. The patch simply adds a call to 'set + breakpoint pending off' near the start of each test. + + Normally GDB tests are written using gdb_test or gdb_test_multiple, + with gdb_test being a wrapper around gdb_test_multiple. Inside + gdb_test_multiple we add a test pattern which detects if GDB offers + the user an interactive yes/no prompt and immediately fails the test. + + What this means is that if something goes wrong with a test like: + + gdb_test "break main" ".*" + + and GDB ends up offering this prompt: + + Make breakpoint pending on future shared library load? (y or [n]) + + then instead of hanging waiting for the test to timeout, DejaGNU will + spot the interactive prompt and immediately fail the test. + + In the gdb.base/annota{1,3}.exp tests we turn on GDB's annotation + mode, and many of the tests in these scripts are written using + send_gdb and gdb_expect or gdb_expect_list. This is done because in + the past, gdb_test_multiple and friends were hard-coded to use the + "normal" GDB prompt, and these tests instead expect the annotated + prompt. Specifically, gdb_test_multiple expects '$gdb_prompt $' as + the full prompt, that is the value of $gdb_prompt followed by a single + white space. The annotation tests do update the value of $gdb_prompt, + but with annotations on there is no trailing whitespace, so + gdb_test_multiple's default behaviour doesn't work, which is why the + test scripts originally avoided using gdb_test_multiple. + + As a result none of the tests in these files would early exit if we + got an interactive yes/no prompt, and instead we'd be relying on each + test to timeout, which could take a while. + + However, gdb_test_multiple now accepts a -prompt argument, so we can + modify the prompt we are looking for, which is neat. + + So, I started off by going through these tests an changing all of the + tests that create a breakpoint to use gdb_test, passing the -prompt + option to change the prompt. + + While doing that I noticed some other things that I could improve in + these tests, I've cleaned up the use of standard_testfile, switched to + use prepare_for_testing, and removed some redundant clean_restart and + 'set height 0' calls (set height 0 is done within clean_restart, which + is called by prepare_for_testing). + + I've updated some comments which said "we can't use gdb_test" to say + "we can use gdb_test with -prompt option", and I've removed some + commented out debug code (e.g. setting 'exp_internal'). + + Finally, I ran these two tests through check-all-boards, and spotted + that annota1.exp failed when using a remote host. This is because one + test checks for a full path to the binary in some output, and with a + remote host the binary ends up being copied and the path is not as + expected. + + I'm assuming that checking the full path is important, so I've + disabled this test on remote host boards. + + After all these changes I checked using 'make check-all-boards' and + there are no unexpected results on either of these tests. + + Tested-By: Tom de Vries + Acked-By: Tom de Vries + +2024-11-12 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.trace/ + After this commit: + + commit 35f09cd5d7fdd1a64f4d1751e73c3495bef1ed99 + Date: Wed Jul 31 15:04:25 2024 +0200 + + [gdb/testsuite] Detect trailing-text-in-parentheses duplicates + + we are now seeing some duplicate test names in gdb.trace/ tests when + using native-gdbserver or native-extended-gdbserver boards. This is + all due to tests that use some text in trailing parenthesis to make + the test name unique. + + I've gone through and edited the test names as best I could to make + them all unique. Hopefully the updated test names should all make + sense. + + On my machine I'm no longer seeing any duplicates with either of the + boards listed above. + + Acked-By: Tom de Vries + +2024-11-12 Andrew Burgess + + gdb/readline: don't get stuck thinking an EOF arrived + It was brought to my attention[1] that if a user makes use of Ctrl+d + to quit from a secondary prompt (e.g. the prompt used to enter lines + for the 'commands' command) then GDB will start displaying some + unexpected blank lines. Here's an example: + + Reading symbols from /tmp/hello.x... + (gdb) break main + Breakpoint 1 at 0x401198: file hello.c, line 18. + (gdb) commands + Type commands for breakpoint(s) 1, one per line. + End with a line saying just "end". + >quit # <----------- Use Ctrl+d to quit here. + (gdb) show architecture + # <----------- This blank line is unexpected. + The target architecture is set to "auto" (currently "i386:x86-64"). + (gdb) + + I've marked up where I press 'Ctrl+d', and also the unexpected blank + line. + + This issue will only happen if bracketed-paste-mode is in use. If + this has been disabled (e.g. in ~/.inputrc) then this issue will not + occur. + + The blank line is not just emitted for the 'show architecture' + command. The blank line is actually caused by an extra '\n' character + emitted by readline after it has gathered a complete line of input, + and so will occur for any command. + + The problem is caused by readline getting "stuck" in a state where it + thinks that an EOF has just been delivered. This state is set when + the 'Ctrl+d' does deliver an EOF, but then this state is never fully + reset. As a result, every time readline completes a line, it thinks + that the line was completed due to an EOF and so adds an extra '\n' + character. + + Obviously the real fix for this issue is to patch readline, and I do + have a patch for that[2], however, version 8.2 of readline has been + released, and contains this issue. As such, if GDB is linked against + the system readline, and that system readline is 8.2, then we can + expect to see this issue. + + There's a pretty simple, and cheap workaround that we can add to GDB + that will mitigate this issue. + + I propose that we add this workaround to GDB. If/when the readline + patch is accepted then I'll back-port this to our local readline copy, + but retaining the workaround will be harmless, and will make GDB play + nicer with system readline libraries (version 8.2). + + [1] https://inbox.sourceware.org/gdb-patches/34ef5438-8644-44cd-8537-5068e0e5e434@redhat.com + [2] https://lists.gnu.org/archive/html/bug-readline/2024-10/msg00014.html + + Reviewed-By: Keith Seitz + +2024-11-12 Andrew Burgess + + gdb/readline: add readline library version to 'show configuration' + When debugging readline issues I'd like an easy way to know (for sure) + what version of readline GDB is using. This could also be useful when + writing readline tests, knowing the precise readline version will + allow us to know if we expect a test to pass or not. + + Add the readline library version to the output of the 'show + configuration' command. Also include a suffix indicating if we are + using the system readline, or the statically linked in readline. + + The information about static readline vs shared readline can be + figured out from the configure command output, but having it repeated + in the readline version line makes it super easy to grok within tests, + and it's super cheap, so I don't see this as a problem. + +2024-11-12 Andrew Burgess + + gdbserver: pass osabi to GDB in more target descriptions + Problem Description + ------------------- + + On a Windows machine I built gdbserver, configured for the target + 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with + support for all target (--enable-targets=all). + + On the Windows machine I start gdbserver with a small test binary: + + $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe + + On the GNU/Linux machine I start GDB without the test binary, and + connect to gdbserver. + + As I have not given GDB the test binary, my expectation is that GDB + would connect to gdbserver and then download the file over the remote + protocol, but instead I was presented with this message: + + (gdb) target remote 192.168.129.25:54321 + Remote debugging using 192.168.129.25:54321 + warning: C:\some\directory\executable.exe: No such file or directory. + 0x00007ffa3e1e1741 in ?? () + (gdb) + + What I found is that if I told GDB where to find the binary, like + this: + + (gdb) file target:C:/some/directory/executable.exe + A program is being debugged already. + Are you sure you want to change the file? (y or n) y + Reading C:/some/directory/executable.exe from remote target... + warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. + Reading C:/some/directory/executable.exe from remote target... + Reading symbols from target:C:/some/directory/executable.exe... + (gdb) + + then GDB would download the executable. + + The Actual Issue + ---------------- + + I tracked the problem down to exec_file_find (solib.c). The remote + target was passing an absolute Windows filename (beginning with "C:/" + in this case), but in exec_file_find GDB was failing the + IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as + relative. + + The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that + the file system kind was "unix", and as the filename didn't start with + a "/" it assumed the filename was not absolute. + + But I'm connecting to a Windows target and 'target-file-system-kind' + was set to "auto", so GDB should be figuring out that the target + file-system is "dos-based". + + Looking in effective_target_file_system_kind (filesystem.c), we find + that the logic of "auto" is delegated to the current gdbarch. However + in windows-tdep.c we see: + + set_gdbarch_has_dos_based_file_system (gdbarch, 1); + + So if we are using a Windows gdbarch we should have "dos-based" + filesystems. What this means is that after connecting to the remote + target GDB has selected the wrong gdbarch. + + What's happening is that the target description sent back by the + remote target only includes the x86-64 registers. There's no + information about which OS we're on. As a consequence, GDB picks the + first x86-64 gdbarch which can handle the provided register set, which + happens to be a GNU/Linux gdbarch. + + And indeed, there doesn't appear to be anywhere in gdbserver that sets + the osabi on the target descriptions. Some target descriptions do have + their osabi set when the description is created, e.g. in: + + gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. + gdb/arch/i386.c - Likewise. + gdb/arch/tic6x.c - Always set GNU/Linux osabi. + + There are also some cases in gdb/features/*.c where the tdesc is set, + but these locations are only called from GDB, not from gdbserver. + + This means that many target descriptions are created without an osabi, + gdbserver does nothing to fix this, and the description is returned to + GDB without an osabi included. This leaves GDB having to guess what + the target osabi is, and in some cases, GDB can get this wrong. + + Proposed Solution + ----------------- + + I propose to change init_target_desc so that it requires an gdb_osabi + to be passed in, this will then be used to set the target_desc osabi + field. + + I believe that within gdbserver init_target_desc is called for every + target_desc, so this should mean that every target_desc has an + opportunity to set the osabi to something sane. + + I did consider passing the osabi into the code which creates the + target_desc objects, but that would require updating far more code, as + each target has its own code for creating target descriptions. + The approach taken here requires minimal changes and forces every + user of init_target_desc to think about what the correct osabi is. + + In some cases, e.g. amd64, where the osabi is already set when the + target_desc is created, the init_target_desc call will override the + current value, however, we should always be replacing it with the same + actual value. i.e. if the target_desc is created with the osabi set + to GNU/Linux, then this should only happen when gdbserver is built for + GNU/Linux, in which case the init_target_desc should also be setting + the osabi to GNU/Linux. + + The Tricky Bits + --------------- + + Some targets, like amd64, use a features based approach for creating + target_desc objects, there's a function in arch/amd64.c which creates + a target_desc, adds features too it, and returns the new target_desc. + This target_desc is then passed to an init_target_desc call within + gdbserver. This is the easy case to handle. + + Then there are other targets which instead have a fixed set of xml + files, each of which is converted into a .dat file, which is then used + to generate a .cc file, which is compiled into gdbserver. The + generated .cc file creates the target_desc object and calls + init_target_desc on it. In this case though the target description + that is sent to GDB isn't generated from the target_desc object, but + is instead the contents of the fixed xml file. For this case the + osabi which we pass to init_target_desc should match the osabi that + exists in the fixed xml file. + + Luckily, in the previous commit I copied the osabi information from + the fixed xml files into the .dat files. So in this commit I have + extended regdat.sh to read the osabi from the .dat file and use it in + the generated init_target_desc call. + + The problem with some of these .dat base targets is that their fixed + xml files don't currently contain any osabi information, and the file + names don't indicate that they are Linux only (despite them currently + only being used from gdbserver for Linux targets), so I don't + currently feel confident adding any osabi information to these files. + An example would be features/rs6000/powerpc-64.xml. For now I've just + ignored these cases. The init_target_desc will use GDB_OSABI_UNKNOWN + which is the default. This means that for these targets nothing + changes from the current behaviour. But many other targets do now + pass the osabi back. Targets that do pass the osabi back are + improved with this commit. + + Conclusion + ---------- + + Now when I connect to the Windows remote the target description + returned includes the osabi name. With this extra information GDB + selects the correct gdbarch object, which means that GDB understands + the target has a "dos-based" file-system. With that correct GDB + understands that the filename it was given is absolute, and so fetches + the file from the remote as we'd like. + + Reviewed-By: Kevin Buettner + +2024-11-12 Andrew Burgess + + gdb/regformats: add osabi information to generated .dat files + Some gdbserver targets generate their target description based on the + gdb/regformats/*.dat files. These .dat files are generated from a + matching xml file in gdb/features/. + + Lets consider a concrete example: + + Take gdb/features/or1k-linux.xml, this file is processed by + gdb/features/Makefile to create gdb/regformats/or1k-linux.dat. + + When gdbserver is built for the or1k target the file + or1k-linux-generated.cc is generated using the + gdb/regformats/regdat.sh script. This .cc file is then compiled and + linked into gdbserver. + + The or1k-linux-generated.cc file contains the function + init_registers_or1k_linux which is called from within gdbserver, this + function creates a target_desc object and sets its xmltarget field to + a fixed string. This fixed string is the xml filename that was + originally used to generate the xml file, in this case or1k-linux.xml. + + Additionally, as part of the gdbserver build the file or1k-linux.xml + is converted to a string and placed in the file + xml-builtin-generated.cc which is then built into gdbserver. + + Now when GDB asks gdbserver for the target description, gdbserver + returns the fixed xmltarget string, which is the name of an xml file. + GDB will then ask gdbserver for that file and gdbserver will return + the contents of that file thanks to the xml-builtin-generated.cc + file's contents. + + This is all rather complicated, but it does work. So what's the + problem that I'm fixing? + + Well or1k-linux.xml does contain the osabi information, so this will + be returned from gdbserver to GDB. That's good. + + However, the target_desc object created in init_registers_or1k_linux + will not have its osabi set correctly. + + Now this doesn't really matter too much except + init_registers_or1k_linux includes a call to init_target_desc. + + In the next commit I want to extend init_target_desc to require an + osabi to be passed in. The motivation for this will be explained in + the next commit, but if we accept for a moment that this is something + that should be done, then the question is what osabi should we use in + init_registers_or1k_linux? + + Ideally we'd use the osabi which is set in or1k-linux.xml. If we do + that then everything will remain consistent, which is a good thing. + + And so, to get the osabi from or1k-linux.xml into + init_registers_or1k_linux, we first need to get the osabi information + into or1k-linux.dat file, and this is what this commit does. + + I've added a new xsl script print-osabi.xsl and updated + gdb/features/Makefile to make use of this script. Then I regenerated + all of the .dat files. Now every .dat file contains either: + + osabi:GNU/Linux + osabi:unknown + + The first is for xml files containing GNU/Linux and the + second is for xml files that don't contain an osabi element. + + This commit doesn't attempt to make use of the osabi information in + the .dat files, that will come in the next commit. There should be no + user visible changes after this commit. + + Approved-By: Kevin Buettner + +2024-11-12 Andrew Burgess + + gdb/features: set osabi in all Linux related features/*.xml files + Some of the top level (i.e. those that contain the element) + xml files in gdb/features/ are clearly Linux only. I conclude this + based on the files names containing the string "linux". + + I think that all of these files should have the element + included with the value "GNU/Linux". + + This commits adds the element where I believe it is + appropriate and regenerates the associated .c files. + + The benefit of this change is that gdbserver, which makes use of these + files, will now send the osabi back in more cases. Sending back more + descriptive target descriptions is a good thing as this makes it + easier for GDB to select the correct gdbarch. + + Approved-By: Kevin Buettner + +2024-11-12 Shahab Vahedi + + gdb/MAINTAINERS: Update my email address + +2024-11-12 Guinevere Larsen + + gdb/testsuite: fix gdb.reverse/i386-avx-reverse.exp with clang + The test gdb.reverse/i386-avx-reverse.exp was changed by the recent + commit: + + commit 5bf288d5a88ab6d3fa9bd7bd070e624afd264dc6 + Author: Guinevere Larsen + Date: Fri Jul 26 17:31:14 2024 -0300 + + gdb/record: support AVX instructions VMOVDQ(U|A) when recording + + In that commit I added a few calls to the instruction vmovdqa to and + from memory addresses. Because my local gcc testing always had aligned + pointers, I thought this would always work, but clang (and maybe other + compilers) might not do the same, which will cause vmovdqa to segfault, + and the test to fail spectacularly. + + This commit fixes that by using the pre-existing precise-aligned-alloc + to allocate the dynamic buffers, forcing them to be aligned to the + required boundary for vmovdqa instruction to work. The code was then + re-shuffled to keep the current clustering of instructions. + + Approved-By: Tom Tromey + +2024-11-12 Tom de Vries + + [gdb/tdep] Use raw_supply_part_zeroed for AArch64 + In gdb/aarch64-linux-tdep.c we find: + ... + gdb::byte_vector za_zeroed (za_bytes, 0); + regcache->raw_supply (tdep->sme_za_regnum, za_zeroed); + ... + + We can't use reg_buffer::raw_supply_zeroed here because only part of the + register is written. + + Add raw_supply_part_zeroed, and use it instead. + + Likewise elsewhere in AArch64 tdep code. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + +2024-11-12 Alan Modra + + Remove redundant section merge hash table field + sec_merge_hash.size duplicates sec_merge_hash.table.count, albeit using + bfd_size_type rather than unsigned int. The only reason to have the + duplicate field is to catch unsigned int overflows, and that can be + done easily enough when and if required. Overflow isn't possible at + the moment. See the needs_resize comment. + + * merge.c (sec_merge_hash): Remove "size" field. + (NEEDS_RESIZE): Delete macro, replacing with.. + (needs_resize): ..this inline function. + (sec_merge_resize): Rename from sec_merge_maybe_resize, + removing redundant check. + (sec_merge_hash_insert, sec_merge_hash_lookup): Adjust to suit. + (sec_merge_init, merge_strings): Likewise. + +2024-11-12 Alan Modra + + Re: ld: Move note sections after .rodata section + Fix csky-linux-gnu FAIL of ld-elf/pr32341, due to that target having + its own .bss directive. + + PR ld/32341 + * testsuite/ld-elf/pr32341.s: Don't use .bss directive. Specify + progbits/nobits on all .section directives. + +2024-11-12 Alan Modra + + Re: tekhex object file output fixes + Commit 8b5a212495 supported *ABS* symbols by allowing "section" to be + bfd_abs_section, but bfd_abs_section needs to be treated specially. + In particular, bfd_get_next_section_by_name (.., bfd_abs_section_ptr) + is invalid. + + PR 32347 + * tekhex.c (first_phase): Guard against modification of + _bfd_std_section[] entries. + +2024-11-12 GDB Administrator + + Automatic date update in version.in + +2024-11-11 Shahab Vahedi + + Handle type-casting in template parameter list when hashing symbols + Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB + may not be able to find a symbol when asked by the user. See the + accompanying test for such demonstration. + + The cp_search_name_hash() cannot correctly handle a (demangled) symbol + that comprises of type-casting for the first parameter in its template + parameter list, e.g.: + + foo<(enum_test)0>(int, int) + + In this example, the processing logic in cp_search_name_hash() considers + the "foo<" string for hashing instead of "foo". This is due to a faulty + logic in the processing loop that tries to _keep_ hashing if a '<' char + with the following property is encountered: + + --------------------------------------------------------------------- + for (const char *string = search_name; *string != '\0'; ++string) + { + ... + + if (*string == '(') + break; + + ... + + /* Ignore template parameter list. */ + if (string[0] == '<' + && string[1] != '(' && string[1] != '<' && string[1] != '=' + && string[1] != ' ' && string[1] = '\0') + break; + + ... + hash = SYMBOL_HASH_NEXT (hash, *string); + } + --------------------------------------------------------------------- + + Ostensibly, this logic strives to bail out of the processing loop as + soon as the beginning of an argument list is encountered, "(int, int)" + in the example, or the beginning of a template parameter list, the + "<(enum_test)0>" in the example. However, when "string" is pointing + at '<', the following incorrect logic takes precedence: + + --------------------------------------------------------------------- + for (const char *string = search_name; *string != '\0'; ++string) + { + if (*string == '(') + break; + ... + if (string[0] == '<' && string[1] != '(' ...) + break; + + hash = SYMBOL_HASH_NEXT (hash, *string); + } + --------------------------------------------------------------------- + + In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after + the '<' char causes the "if" condition at the end of the loop not to + "break". As a result, the '<' is considered for hashing and at the + beginning of the next iteration, the loop is exited because "string" + points to '(' char. + + It's obvious that the intention of the "if" condition at the end of the + loop body is to handle cases where the method name is "operator<", + "operator<<", or "operator<=". While fixing the issue, I've re-written + the logic as such to make that more explicit. Still, the complexity of + the function remains O(n). It is worth mentioning that in the same + file the "find_toplevel_char()" follows the same explicit logic. + + Reviewed-By: Lancelot SIX + Reviewed-By: Pedro Alves + Approved-by: Tom Tromey + Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e + +2024-11-11 Simon Marchi + + gdb/progspace: make program_space::objfiles_list private + This field is only accessed within the program_space class, make it + private. + + Change-Id: I0b53d78d3d11adf0dfadfb3ecace33d2996dd87b + +2024-11-11 Simon Marchi + + gdb/progspace: link objfiles using owning_intrusive_list + This simplifies things a little bit, removing some `find_if` when + inserting or removing objfiles, and the whole + unwrapping_objfile_iterator thing. + + Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba + +2024-11-11 Hannes Domani + + Fix using Page-Up in TUI source window close to the top + Currently, when you're already less than a page from the top in the TUI + source window, and you press Page-Up, nothing happens, while I would + expect that it then scrolls the source up to the first line. + + It's happening because scrolling a full page up would result in a + negative starting line number, which is then checked if it's higher than + the (unsigned) number of available lines, and since this will always be + true, the original starting line number is restored. + Afterwards it would check if the line number is too low, but since the + negative value was already gone, it didn't do much. + + Fixed by moving the low line number check before the maximum line number + check. + + Approved-By: Tom Tromey + +2024-11-11 Andrew Burgess + + gdb/testsuite: fix typo 'unsupport' to 'unsupported' + I noticed that in commit: + + commit 5cabc8098e65ac22d4245232ad20b19fa4729802 + Date: Wed Jul 31 15:55:57 2024 +0100 + + gdb/python: implement Python find_exec_by_build_id hook + + I managed to typo 'unsupported' as 'unsupport'. If you run the test + on a target that doesn't support core file creation then you'll get a + TCL error. + + Fixed in this commit. + +2024-11-11 Andrew Burgess + + gdb/testsuite: fix failure in gdb.base/info_sources.exp + I ran into an unexpected failure in gdb.base/info_sources.exp. The + test in question runs this command: + + (gdb) info sources -d -- -d + + That is, list all the source files whose directory name matches the + regexp '-d'. The expectation is that no source files will be listed. + + Unfortunately, when I ran the test some source files are listed; the + directory I am running in contains the pattern '-d', and so the test + fails. + + As we cannot control where the developer is building and testing GDB, + I propose that instead of just testing with '-d' we should search + through all the letters a-z and find one that isn't present in the + source file directory name. I'm still including the leading '-' + character in the regexp. + + So now, unless GDB is being built in a directory that contains '-a', + '-b', '-c', .... '-z', the test will find one letter which isn't + present, and use that for the test. + + To avoid test names changing between runs in different directories + I've had to tweak the test name to something more generic, but there + should be no change in which parts of GDB are actually being tested. + + Approved-By: Tom Tromey + +2024-11-11 Tom de Vries + + [gdb/testsuite] Reduce quoting in gdb.base/annota1.exp + Reduce quoting in gdb.base/annota1.exp, mostly using string_to_regexp. + + Tested on arm-linux and x86_64-linux. + +2024-11-11 Tom de Vries + + [gdb/testsuite] Fix gdb.base/annota1.exp on arm-linux + On arm-linux, gdb.base/annota1.exp fails: + ... + PASS: gdb.base/annota1.exp: breakpoint info + run^M + ^M + ^Z^Zpost-prompt^M + Starting program: /home/linux/gdb/build/gdb/testsuite/outputs/gdb.base/annota1/annota1 ^M + ^M + ^Z^Zbreakpoints-invalid^M + ^M + ^Z^Zframes-invalid^M + ^M + ^Z^Zstarting^M + ^M + ^Z^Zframes-invalid^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".^M + ^M + ^Z^Zbreakpoints-invalid^M + ^M + ^Z^Zbreakpoint 1^M + ^M + Breakpoint 1, ^M + ^Z^Zframe-begin 0 0x40054a^M + ^M + ^Z^Zframe-function-name^M + main^M + ^Z^Zframe-args^M + ()^M + ^Z^Zframe-source-begin^M + at ^M + ^Z^Zframe-source-file^M + /home/linux/gdb/src/gdb/testsuite/gdb.base/annota1.c^M + ^Z^Zframe-source-file-end^M + :^M + ^Z^Zframe-source-line^M + 15^M + ^Z^Zframe-source-end^M + ^M + ^M + ^Z^Zsource /home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x40054a^M + ^M + ^Z^Zframe-end^M + ^M + ^Z^Zstopped^M + ^M + ^Z^Zpre-prompt^M + (gdb) ^M + ^Z^Zprompt^M + FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) + ... + because the regexp doesn't match the first frames-invalid annotation. + + Fix this by adding an optional frames-invalid annotation in the regexp. + + Tested on arm-linux and x86_64-linux. + +2024-11-11 Tom de Vries + + [gdb/testsuite] Avoid intermittent failures on another debuginfod test + With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran + into: + ... + (gdb) core-file solib-with-soname.core^M + Downloading 197.86 K file libfoo_1.so...^M + [New LWP 997314]^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + Core was generated by `solib-with-soname'.^M + Program terminated with signal SIGABRT, Aborted.^M + (gdb) FAIL: $exp: load core file, use debuginfod: load core file + ... + + The test-case doesn't expect the "197.86 K" part. + + The same problem was fixed for another test-case in commit a723c56efb0 + ("gdb/testsuite: avoid intermittent failures on a debuginfod test"). + + Fix this in the same way: by updating the regexp. + + Tested on aarch64-linux. + + PR testsuite/32354 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354 + +2024-11-11 Tom Tromey + + Use an iterator range for 'using' directives + This patch changes block::get_using to return an iterator range. This + seemed cleaner to me than the current approach of returning a pointer + to the first using directive; all the callers actually use this to + iterate. + + Ensure that help text fits in 80 columns + This patch adds a new unit test that ensures that all help text wraps + at 80 columns. + +2024-11-11 Tom Tromey + + Wrap help options when building help string + When building a help string, it's possible that the resulting options + will go over 80 columns. This patch changes this code to add line + wrapping where needed. + + This can most be seen by looking "help bt" and in particular the + "-frame-info" help text. + +2024-11-11 Tom Tromey + + Shorten internal problem help text + The help text for various "internal problem" settings is longer than + 80 columns. This patch tightens this up a bit. Note that these + commands are all "maint" commands so, IMO, it is sufficient if they + are clear to a gdb developer. + + Reviewed-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Remove the "title" from the remote packet help + The help for remote packet controls includes the "title". However + this is is just the parameter name, and not really useful to see + repeated in the help text. + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Clean up opaque-type-resolution help + The opaque-type-resolution help says "if set before loading symbols", + but I don't think this is accurate. As far as I know, this resolution + can be done at any time. + + This patch cleans up the help, also shortening it to less than 80 + characters. + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Wrap help strings at 80 columns + This patch ensures that all ordinary help strings are wrapped at 80 + columns. For the most part this consists of changing code like this + (note the embedded \n and the trailing backslash without a newline): + + -Manage the space-separated list of debuginfod server URLs that GDB will query \ + -when missing debuginfo, executables or source files.\nThe default value is \ + -copied from the DEBUGINFOD_URLS environment variable."), + + ... to end each line with \n\, like: + + +Manage the space-separated list of debuginfod server URLs that GDB will\n\ + +query when missing debuginfo, executables or source files.\n\ + +The default value is copied from the DEBUGINFOD_URLS environment variable."), + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Call gdbpy_fix_doc_string_indentation for function help + If you invoke "help function _caller_is", you'll see that the help + text is indented strangely. The fix for this is to add a call to + gdbpy_fix_doc_string_indentation in the appropriate spot, as is + already done for Python commands and parameters. + +2024-11-11 Tom Tromey + + Add setting to control frame language mismatch warning + A customer noted that there is no way to prevent the "current language + does not match this frame" warning. This patch adds a new setting to + allow this warning to be suppressed. + + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-11-11 Tom Tromey + + Re-run isort + pre-commit pointed out that one file needed a change to satisfy isort. + This patch is the result. + +2024-11-11 Pedro Silva + + gdb: fix missing operator % on xmethod matcher output + Fixed missing operator % on xmethod matcher registration output and, as + suggested on bug 32532, converted both uses of operator % to str.format. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32352 + Change-Id: Ic471516292c2f1d6d1284aaeaea3ec14421decb8 + +2024-11-11 H.J. Lu + + ld: Move note sections after .rodata section + Move note sections after .rodata section so that note sections are + placed in the same PT_LOAD segment together with .rodata section, + instead of a separate PT_LOAD segment. + + PR ld/32341 + * scripttempl/misc-sections.sc: Move note sections to ... + * scripttempl/elf.sc: Here, after .rodata section. + * testsuite/ld-elf/pr32341.d: New file. + * testsuite/ld-elf/pr32341.s: Likewise. + + Co-Authored-By: Nick Clifton + +2024-11-11 Lancelot SIX + + gdb/dwarf2/read.c: Handle empty CU name + I recently came across a case where a compiler would emit a CU with an + empty name. In such case, the attribute object constructed by GDB will + return nullptr when as_string is called. One place is not checking for + this possibility. As a result, loading such binary results in a GDB + crash: + + $ gdb -q a.out + Reading symbols from a.out... + + Fatal signal: Segmentation fault + ----- Backtrace ----- + [...] + 0x742f4dd8afab __strcmp_avx2 + ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 + 0x58593704a0bc prepare_one_comp_unit + ../../gdb/dwarf2/read.c:21842 + 0x585937053fd9 process_psymtab_comp_unit + ../../gdb/dwarf2/read.c:4633 + 0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_ + ../../gdb/dwarf2/read.c:4943 + [...] + --------------------- + A fatal error internal to GDB has been detected, further + debugging is not possible. GDB will now terminate. + + This is a bug, please report it. For instructions, see: + . + + Segmentation fault (core dumped) + + This seems to be a regression introduced by the following commit: + + commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36 + Date: Tue Sep 24 10:24:22 2024 +0200 + + [gdb/symtab] Don't expand non-Ada CUs for info exceptions + + This patch fixes this issue by checking if attr->as_string returns + nullptr. + + Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c + Approved-By: Andrew Burgess + Approved-By: Tom Tromey + +2024-11-11 Xin Wang + + ld, LoongArch: print error about linking without -fPIC or -fPIE flag in more detail + +2024-11-11 GDB Administrator + + Automatic date update in version.in + +2024-11-10 Andrew Burgess + + gdb/python: implement Python find_exec_by_build_id hook + Implement extension_language_ops::find_objfile_from_buildid within + GDB's Python API. Doing this allows users to write Python extensions + that can help locate missing objfiles when GDB opens a core file. A + handler might perform some project- or site-specific actions to find a + missing objfile. Or might provide some project- or site-specific + advice to the user on how they can obtain the missing objfile. + + The implementation is very similar to the approach taken in: + + commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 + Date: Sun Oct 15 22:48:42 2023 +0100 + + gdb: implement missing debug handler hook for Python + + The following new commands are added as commands implemented in + Python, this is similar to how the Python missing debug and unwinder + commands are implemented: + + info missing-objfile-handlers + enable missing-objfile-handler LOCUS HANDLER + disable missing-objfile-handler LOCUS HANDLER + + To make use of this extension hook a user will create missing objfile + handler objects, and registers these handlers with GDB. When GDB + opens a core file and encounters a missing objfile each handler is + called in turn until one is able to help. Here is a minimal handler + that does nothing useful: + + import gdb + import gdb.missing_objfile + + class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler): + def __init__(self): + super().__init__("my_first_handler") + + def __call__(self, pspace, build_id, filename): + # This handler does nothing useful. + return None + + gdb.missing_objfile.register_handler(None, MyFirstHandler()) + + Returning None from the __call__ method tells GDB that this handler + was unable to find the missing objfile, and GDB should ask any other + registered handlers. + + Possible return values from a handler: + + - None: This means the handler couldn't help. GDB will call other + registered handlers to see if they can help instead. + + - False: The handler has done all it can, but the objfile couldn't + be found. GDB will not call any other handlers, and will + continue without the objfile. + + - True: The handler has installed the objfile into a location where + GDB would normally expect to find it. GDB should repeat its + normal lookup process and the objfile should now be found. + + - A string: The handler can return a filename, which is the missing + objfile. GDB will load this file. + + Handlers can be registered globally, or per program space. GDB checks + the handlers for the current program space first, and then all of the + global handles. The first handler that returns a value that is not + None, has "handled" the missing objfile, at which point GDB continues. + + The implementation of this feature is mostly straight forward. I have + reworked some of the missing debug file related code so that it can be + shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is + mostly content moved from gdb/python/lib/gdb/missing_debug.py, but + updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py + and the new file gdb/python/lib/gdb/missing_objfile.py both call into + the missing_files.py file. + + For gdb/python/lib/gdb/command/missing_files.py this is even more + extreme, gdb/python/lib/gdb/command/missing_debug.py is completely + gone now and gdb/python/lib/gdb/command/missing_files.py provides all + of the new commands in a generic way. + + I have made one change to the existing Python API, I renamed the + attribute Progspace.missing_debug_handlers to + Progspace.missing_file_handlers. I don't see this as too + problematic. This attribute was only used to implement the missing + debug feature and was never documented beyond the fact that it + existed. There was no reason for users to be touching this attribute. + + Reviewed-By: Eli Zaretskii + +2024-11-10 Andrew Burgess + + gdb: add extension hook ext_lang_find_objfile_from_buildid + Add a new ext_lang_find_objfile_from_buildid function which is called + from find_objfile_by_build_id and gives extension languages a chance + to find missing objfiles. + + This commit adds the ext_lang_find_objfile_from_buildid function and + the extension_language_ops::find_objfile_from_buildid() hook, but does + not implement the hook for any extension languages, that will come in + the next commit. + + This commit does rewrite find_objfile_by_build_id (build-id.c) to call + the new hook though. The basic steps of find_objfile_by_build_id are + now this: + + 1. Try to find the missing objfile using the build-id by looking in + the debug-file-directory's .build-id/ sub-directory. If we find the + file then we're done. + + 2. Ask debuginfod to download the missing file for us. If we + download the file successfully then we're done. + + 3. Ask the extension language hook to find the file for us. If the + extension language asks us to try again then we repeat step (1) only + and if we still don't have the file, we move to step (4). If the + extension language told us where the file is then we use that file + and we're done. + + 4. We didn't find the file. Carry on without it. + + Only step (3) is new in this logic, everything else was already done. + + There are no tests added here as we can't currently write an extension + language callback. The next commit will add the tests. + + Approved-By: Tom Tromey + +2024-11-10 Andrew Burgess + + gdb: rename ext_lang_missing_debuginfo_result + In preparation for later commits in this series, rename + ext_lang_missing_debuginfo_result to ext_lang_missing_file_result. + + A later commit will add additional Python APIs to handle different + types of missing files beyond just debuginfo. + + This is just a rename commit, there should be no functional changes + after this commit. + + Approved-By: Tom Tromey + +2024-11-10 Andrew Burgess + + gdb: use mapped file information to improve debuginfod text + When opening a core-file GDB is able to use debuginfod to download the + executable that matches the core-file if GDB can find a build-id for + the executable in the core-file. + + In this case GDB calls debuginfod_exec_query to download the + executable and GDB prints a message like: + + Downloading executable for /path/to/core-file... + + which makes sense in that case. + + For a long time GDB has also had the ability to download memory-mapped + files and shared libraries when opening a core-file. However, recent + commits have made these cases more likely to trigger, which is a good + thing, but the messaging from GDB in these cases is not ideal. When + downloading a memory-mapped file GDB prints: + + Downloading executable for /path/to/memory-mapped-file + + And for a shared library: + + Downloading executable for /path/to/libfoo.so + + These last two messages could, I think, be improved. + + I propose making two changes. First, I suggest instead of using + /path/to/core-file in the first case, we use the name of the + executable that GDB is fetching. This makes the messaging consistent + in that we print the name of the file we're fetching rather than the + name of the file we're fetching something for. + + I further propose that we replace 'executable for' with the more + generic word 'file'. The messages will then become: + + Downloading file /path/to/exec-file... + Downloading file /path/to/memory-mapped-file... + Downloading file /path/to/libfoo.so... + + I think these messages are clearer than what we used to have, and they + are consistent in that we name the thing being downloaded in all + cases. + + There is one tiny problem. The first case relies on GDB knowing the + name of the executable it wants to download. The only place we can + currently get that from is, I think, the memory-mapped file list. + + [ ASIDE: There is `bfd_core_file_failing_command` which reports the + executable and argument list from the core file, but this + information is not ideal for this task. First, the executable and + arguments are merged into a single string, and second, the string is + a relatively short, fixed length string, so the executable name is + often truncated. For these reasons I don't consider fetching the + executable name using this bfd function as a solution. ] + + We do have to consider the case that the core file does not have any + mapped file information. This shouldn't ever be the case for a Linux + target, but it's worth considering. + + [ ASIDE: I mention Linux specifically because this only becomes a + problem if we try to do a lookup via debuginfod, which requires that + we have build-ids available. Linux has special support for + embedding build-ids into the core file, but I'm not sure if other + kernels do this. ] + + For the unlikely edge case of a core-file that has build-ids, but + doesn't have any mapped file information then I propose that we + synthesis a filename like: 'with build-id xxxxxx'. We would then see + a message like: + + Downloading file with build-id xxxxxx... + + Where 'xxxxxx' would be replaced by the actual build-id. + + This isn't ideal, but I think is good enough, and, as I said, I think + this case is not going to be hit very often, or maybe at all. + + We already had some tests that emitted two of the above messages, + which I've updated, these cover the mapped-file and shared library + case. + + The message about downloading the exec for the core-file is actually + really hard to trigger now as usually the exec will also appear in the + memory-mapped file list and GDB will download the file at this stage. + Then when GDB needs the executable for loading the symbols it'll ask + debuginfod, and debuginfod will find the file in its cache, and so no + message will be printed. + + If anyone has any ideas about how to trigger this case then I'm happy + to add additional tests. + + Approved-By: Tom Tromey + +2024-11-10 GDB Administrator + + Automatic date update in version.in + +2024-11-09 GDB Administrator + + Automatic date update in version.in + +2024-11-08 Alexandra Hájková + + Add dw2-aranges.exp + This test checks that GDB is able to load DWARF information when + .debug_aranges has a section address size that is set to 0. + + This test was originally written by Jan Kratochvil to test commit + 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer". + + This test was originally written using a static .S file and has + been present in the Fedora tree for a long time. + + If dwarf2/aranges.c is modified to turn off the address_size check, + GDB will crash with SIGFPE when loading the executable with address + size set to zero. + + I modified the DWARF assembler to make it possible to set the address + size to zero in a .debug_aranges section and used the DWARF assembler + to produce the assembly file. + + Co-Authored-By: Jan Kratochvil + Approved-by: Kevin Buettner + +2024-11-08 Simon Marchi + + gdbserver: remove pidof(process) + This function doesn't seem so useful, use `process_info::pid` directly + instead. + + Change-Id: I55d592f38b32a197957ed4c569993cd23a818cb4 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove pid_of(thread) + This function doesn't seem so useful, use `thread_info::id::pid` + directly instead. + + Change-Id: I7450c4223e5b0bf66788eeb5b070ab6f5287f798 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove lwpid_of(thread) + This function doesn't seem so useful. Use `thread_info::id::lwp` + directly. + + Change-Id: Ib4a86eeeee6c1342bc1c092f083589ce28009be1 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove ptid_of(thread) + This function doesn't seem so useful. Use `thread_info::id` directly. + + Change-Id: I158cd06a752badd30f68424e329aa42d275e43b7 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove current_thread_ptid + This function doesn't seem so useful. Use `thread_info::id` directly. + + Change-Id: I4ae4e7baa44e09704631a1c3a5a66e5b8b5a3594 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove current_ptid macro + I think it just makes things more obscure. Use `thread_info::id` + directly instead. + + Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove get_thread_process + Remove the `get_thread_process` function, use `thread_info::process` + instead. + + In `server.cc`, use `current_process ()` instead of going through the + current thread. + + Change-Id: Ifc61d65852e392d154b854a45d45df584ab3922e + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: make remove_thread a method of process_info + Same idea as the previous patch, but for `remove_thread`. + + Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: make add_thread a method of process_info + Since thread_info objects are now basically children of process_info + objects, I think that makes sense. + + Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: add thread -> process backlink + In a few spots, we need to get to a process from a thread. Having a + backlink from thread to process is cheap and makes the operation + trivial, add it. + + Change-Id: I8a94b2919494b1dcaf954de2246386794308aa82 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove for_each_thread(pid, func) + Remove this overload, prefer to use `process_info::for_each_thread`. In + many instances, the `process_info` is already available, so this saves a + map lookup. In other instances, add the `process_info` lookup at the + call site. + + In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()` + instead of `current_thread->id.pid ()`. I presume that if + `current_process ()` and `current_thread` don't match, it's a bug + orthogonal to this change. + + Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Schimpe, Christina + + gdb: LoongArch: Remove use of gdbarch_remove_non_address_bits hook + LoongArch doesn't implement the hook gdbarch_remove_non_address_bits, so + there is no need to use the hook in gdb/loongarch-linux-nat.c. + + Approved-By: Luis Machado + +2024-11-08 Guinevere Larsen + + gdb: make the error message for unreadable objfiles more informative + When GDB is unable to read an objfile, it prints the error message "I'm + sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a + great reference, an end user won't have much information about the + problem. + + So far this wasn't much of a problem, as it is very uncommon for GDB to + be unable to read an objfile. However, a future patch will allow users + to selectively disable support to some formats, making it somewhat + expected that the message will be seen by end users. + + This commit makes the end message more informative and direct. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299 + Approved-By: Tom Tromey + +2024-11-08 Matthieu Longo + + aarch64: add flag OPD_F_UNSIGNED to distinguish signedness of immediate operands + This patch introduces a new operand flag OPD_F_UNSIGNED to signal that + the immediate value should be treated as an unsigned value. The default + signedness of immediate operands is signed. + + aarch64: testsuite: remove hard-coded instruction addresses + + aarch64: remove redundant register type R_N + The register type R_N is redundant with R_ZR_SP. This patch removes it, + and replaces its usage by R_ZR_SP. + + aarch64: improve debuggability on array of enum + The current space optmization on enum aarch64_opn_qualifier forced its + encoding using an unsigned char. This "hard-coded" optimization has the + bad consequence of making the array of such enums being completely + unreadable when debugging with GDB because the enum type is lost along + the way. + Keeping this space optimization, and the enum type as well, is possible + when the declaration of the enum is tagged with attribute((packed)). + attribute((packed)) is a GNU extension, and is wrapped in the macro + ATTRIBUTE_PACKED (defined in ansidecl.h), and should be used instead. + + aarch64: change returned type to bool to match semantic of functions + + aarch64: constify unchanged char* arguments + + aarch64: make comment clearer about the location + The enum aarch64_opnd_qualifiers in include/opcode/aarch64.h needs to + stay in sync with the array of struct operand_qualifier_data which + defines various properties for the different type of operands. For + instance, for: + - registers: the size of the register, the number of elements. + - immediates: lower and upper bits to determine the range of values. + +2024-11-08 Andrew Burgess + + gdb/testsuite: fix gdb.base/basic-edit-cmd.exp test + In the recent commit: + + commit 31ada87f91b4c5306d81c8a896df9764c32941f3 + Date: Wed Nov 6 22:18:55 2024 +0000 + + gdb: fixes and tests for the 'edit' command + + the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI + highlighted an issue with the test which I failed to address before + pushing the above commit. + + Part of the test loads a file into GDB and then uses the 'edit' + command with no arguments to edit the default location. This default + location is expected to be the 'main' function. + + On my local machine the line reported is the opening '{' of main, and + that is what the test checks for. + + The Linaro CI though appears to see the first code line of main. + + I think either result is fine as far as this test is concerned, so + I've expanded the test regexp to check for either line number. This + should make the CI testing happy again. + +2024-11-08 Andrew Burgess + + gdb: fixes and tests for the 'edit' command + This commit was inspired by this mailing list post: + + https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm + + When reviewing that patch, the first thing I wanted to do was add some + tests for the 'edit' command because, as far as I can tell, there are + no real tests right now. + + The approach I've taken for testing is to override the EDITOR + environment variable, setting this to just 'echo'. Now when the + 'edit' command is run, instead of entering an interactive editor, the + shell instead echos back the arguments that GDB is trying to pass to + the editor. The output might look like this: + + (gdb) edit + +22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c + (gdb) + + We can then test this like any other normal command. I then wrote + some basic tests covering a few situations like, using 'edit' before + the inferior is started. Using 'edit' without any arguments, and + using 'edit' with a line number argument. + + There are plenty of cases that are still not tested, for example, the + test program only has a single source file for example. But we can + always add more tests later. + + I then used these tests to validate the fix proposed in the above + patch. + + The patch above does indeed fix some cases, specifically, when GDB + stops at a location (e.g. a breakpoint location) and then the 'edit' + command without any arguments is fixed. But using the 'list' command + to show some other location, and then 'edit' to edit the just listed + location broken before and after the above patch. + + I am instead proposing this alternative patch which I think fixes more + cases. When GDB stops at a location then 'edit' with no arguments + should correctly edit the current line. And using 'list XX' to list a + specific location, followed by 'edit' should also now edit the just + listed location. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669 + + Co-Authored-By: Lluís Batlle i Rossell + Approved-By: Tom Tromey + +2024-11-08 Mark Wielaard + + bfd: Remove unused static find function from doc/chew.c + After commit 2e60790cf7c27d79f90f2dcb81e1930dc980bc1c "Remove the + paramstuff word" there is no caller left of the static find function + in doc/chew.c, so it should be removed. + + * doc/chew.c (find): Remove. + +2024-11-08 Andre Vieira + + arm, objdump: print obsolote warning when 26-bit set in instructions + Arm has obsoleted the 26-bit addressing mode. Diagnose this when disasembling + these instructions by printing OBSOLETE. + +2024-11-08 Andre Vieira + + arm, objdump: Make objdump use bfd's machine detection to drive disassembly + For any arm elf target, disable an old piece of code that forced disassembly to + disassemble for 'unknown architecture' which once upon a time meant it would + disassemble ANY arm instruction. This is no longer true with the addition of + Armv8.1-M Mainline, as there are conflicting encodings for different thumb + instructions. + + BFD however can detect what architecture the object file was assembled for + using information in the notes section. So if available, we use that, + otherwise we default to the old 'unknown' behaviour. + + With the changes above code, a mode changing 'bx lr' assembled for armv4 with + the option --fix-v4bx will result in an object file that is recognized by bfd + as one for the armv4 architecture. The disassembler now disassembles this + encoding as a BX even for Armv4 architectures, but warns the user when + disassembling for Armv4 that this instruction is only valid from Armv4T + onwards. + + Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and + define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by + -march=armv8-r+crc are disassembled correctly. + + Patch up some of the tests cases, see a brief explanation for each below. + + inst.d: + This test checks the assembly & disassembly of basic instructions in armv3m. I + changed the expected behaviour for teqp, cmnp cmpp and testp instructions to + properly print p when disassembling, whereas before, in the 'unknown' case it + would disassemble these as UNPREDICTABLE as they were changed in later + architectures. + + nops.d: + Was missing an -march, added one to make sure we were testing the right + behavior of NOP instructions. + + unpredictable.d: + Was missing an -march, added armv6 as that reproduced the behaviour being + tested. + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed in i387_supply_xsave + Use reg_buffer::raw_supply_zeroed in i387_supply_xsave. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for NIOS r0 reg + Use reg_buffer::raw_supply_zeroed for NIOS register r0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for Alpha r31 reg + Use reg_buffer::raw_supply_zeroed for Alpha register r31. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for PA-RISC r0 reg + Use reg_buffer::raw_supply_zeroed for PA-RISC register r0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for IA-64 gr0 and fr0 regs + Use reg_buffer::raw_supply_zeroed for IA-64 registers gr0 and fr0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 GDB Administrator + + Automatic date update in version.in + +2024-11-07 Andre Simoes Dias Vieira + + arm: Skip two failing tests for wince & pe targets + We don't seem to support any m-profile assembly/disassembly tests for wince or + pe, so skipping the pacbti one too. + + The pr29494 test needs to be skipped because it uses assembly syntax that is + not supported in wince/pe like for instance eabi_attribute directives. + +2024-11-07 Nick Clifton + + Deprecate the ARM simulator. + The ARM simulator is no longer able to simulator modern ARM cores, so it + is being deprecated. Once this change has been active for a while - and + assuming that no problems have been found - the ARm simulator codebase + will be removed. + +2024-11-07 Stephan Rohr + + gdbserver: add process specific thread list and map + Replace the servers global thread list with a process specific thread + list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on + GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions + to use std::unordered_map::find for faster lookup of threads without + iterating over all processes and threads, if applicable. This becomes + important when debugging applications with a large thread count, e.g., + in the context of GPU debugging. + + Approved-By: Simon Marchi + +2024-11-07 Stephan Rohr + + gdbserver: change 'all_processes' and 'all_threads' list type + This patch replaces the 'std::list' type of 'all_processes' and + 'all_threads' with the more lightweight 'owning_intrusive_list' + type. + + Approved-By: Simon Marchi + +2024-11-07 GDB Administrator + + Automatic date update in version.in + +2024-11-06 Peter Bergner + + PowerPC: Merge rfc2655 and rfc2656 test cases into one future test case + gas/ + * testsuite/gas/ppc/rfc02655.[ds]: Rename from this... + * testsuite/gas/ppc/future.[ds]: ... to this. + * testsuite/gas/ppc/rfc02656.[ds]: Delete. Move tests to future.[ds]. + * testsuite/gas/ppc/ppc.exp: Update for file name changes. + +2024-11-06 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for SPARC g0 reg + Use reg_buffer::raw_supply_zeroed for SPARC register g0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-06 Klaus Gerlicher + + gdb: remove exact_match parameter from find_line_symtab + struct symtab *find_line_symtab (struct symtab *, int, int *, bool *); + + The last parameter is bool* that when set will receive information + if the match was exact. This parameter is never used by any callsite + and can therefore be removed. + + This will become: + + symtab *find_line_symtab (symtab *sym_tab, int line, int *index); + + Approved-By: Tom Tromey + +2024-11-06 GDB Administrator + + Automatic date update in version.in + +2024-11-05 GDB Administrator + + Automatic date update in version.in + +2024-11-04 Tom Tromey + + Turn decode_line_2_compare_items into operator< + This rewrites decode_line_2_compare_items to be an operator< on the + relevant type. This simplifies the code a little. + + Reviewed-by: Keith Seitz + +2024-11-04 Simon Marchi + + gdb: cleanup includes in *-typeprint.[ch] + Remove includes reported as unused by clangd. + + Include "gdb-hashtab.h" in typeprint.h for the use of "htab_up". + + Change-Id: I5b04ec14e71800e2d6ad622838e39b7033e168cf + +2024-11-04 Simon Marchi + + gdb: cleanup includes in gdbtypes.h + Remove some includes reported as unused by clangd. + + Change-Id: Ifc74f782d5aaafd1d719816821860352090c6667 + +2024-11-04 Tom Tromey + + Remove gdb::hash_enum + gdb::hash_enum is a workaround for a small oversight in C++11: + std::hash was not defined for enumeration types. This was rectified + in C++14 and so we can remove the local workaround. + + Approved-By: Simon Marchi + +2024-11-04 Andrew Burgess + + gdb: use option framework for add-inferior and clone-inferior + Convert the add-inferior and clone-inferior commands to make use of + the option framework. This improves the tab completion for these + commands. + + Previously the add-inferior command used a trick to simulate + completion of -exec argument. The command use filename completion for + everything on the command line, thus you could do: + + (gdb) add-inferior /path/to/some/fil + + and GDB would complete the file name, even though add-inferior doesn't + really take a filename as an argument. This helped a little though + because, if the user did this: + + (gdb) add-inferior -exec /path/to/some/fil + + then the file name would be completed. However, GDB didn't really + understand the options, so couldn't offer completion of the options + themselves. + + After this commit, the add-inferior command makes use of the recently + added gdb::option::filename_option_def feature. This means that the + user now has full completion of the option names, and that file names + will still complete for the '-exec' option, but will no longer + complete if the '-exec' option is not used. + + I have also converted the clone-inferior command, though this command + does not use any file name options. This command does now have proper + completion of the command options. + +2024-11-04 Andrew Burgess + + gdb: add filename option support + This commit adds support for filename options to GDB's option + sub-system (see cli/cli-option.{c,h}). + + The new filename options support quoted and escaped filenames, and tab + completion is fully supported. + + This commit adds the new option, and adds these options to the + 'maintenance test-options' command as '-filename', along with some + tests that exercise this new option. + + I've split the -filename testing into two. In gdb.base/options.exp we + use the -filename option with some arbitrary strings. This tests that + GDB can correctly extract the value from a filename option, and that + GDB can complete other options after a filename option. However, + these tests don't actually pass real filenames, nor do they test + filename completion. + + In gdb.base/filename-completion.exp I have added some tests that test + the -filename option with real filenames, and exercise filename tab + completion. + + This commit doesn't include any real uses of the new filename options, + that will come in the next commit. + +2024-11-04 Andrew Burgess + + gdb/testsuite: spring clean the gdb.stabs/gdb11479.exp test + I had reason to look at the gdb.stabs/gdb11479.exp test script and + figured it could do with a small clean up. I've: + + - Made use of standard_testfile and the variables it defines. + + - Made use of with_test_prefix and removed the prefix from the end + of each test name. + + - Avoid overwriting the test binary when we recompile, instead use a + different name for each recompilation. + + - Add '.' at the end of each comment. + + There should be no changes in what is tested with this commit. + + Reviewed-By: Keith Seitz + +2024-11-04 Aditya Vidyadhar Kamath + + Fix AIX core dump while main thread exits. + Consider the test case: + void *thread_main(void *) { + std::cout << getpid() << std::endl; + sleep(20); + return nullptr; + } + + int main(void) { + pthread_t thread; + pthread_create(&thread, nullptr, thread_main, nullptr); + pthread_join(thread, nullptr); + + return 0; + } + + This program creates a thread via main that sleeps for 20 seconds. + + When we debug this with gdb we get, + Reading symbols from ./test... + (gdb) b main + Breakpoint 1 at 0x10000934: file test.c, line 11. + (gdb) r + Starting program: /read_only_gdb/binutils-gdb/gdb/test + + Breakpoint 1, main () at test.c:11 + 11 pthread_create(&thread, nullptr, thread_main, nullptr); + (gdb) c + Continuing. + 15335884 + [New Thread 258 (tid 31130079)] + Thread 2 received signal SIGINT, Interrupt. + [Switching to Thread 258 (tid 31130079)] + 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) thread 1 + [Switching to thread 1 (Thread 1 (tid 25493845))] + (gdb) c + Continuing. + [Thread 1 (tid 25493845) exited] + [Thread 258 (tid 31130079) exited] + inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + + There are two bugs here. One is the core dump. The other is the main thread information + not captured. + + So, while I was debugging the first part the reason, the reason I figured out was + the last for loop in sync_threadlists (). + + Once both my threads exit we delete them as below: + + for (struct thread_info *it : all_threads ()) + { + if (in_queue_threads.count (priv->pdtid) == 0 + && in_thread_list (proc_target, it->ptid) + && pid == it->ptid.pid ()) + { + delete_thread (it); + data->exited_threads.insert (priv->pdtid); + + But once these two threads are deleted, all_threads () + has one more thread whose tid and pid are 0. + + gdb) c + Continuing. + In for loop 8782296 is pid, 19857879 is tid + [Thread 1 (tid 19857879) exited] + In for loop 8782296 is pid, 30933401 is tid + [Thread 258 (tid 30933401) exited] + In for loop 0 is pid, 0 is tid + [Inferior 1 (process 8782296) exited normally] + (gdb) q + + I used a printf in the for loop mentioned above for explaination. + + You see the loop enters the third time with 0 as pid. + + The reason being though the threads are removed but not deleted since they are + not deletable (). + + Hence we use all_threads_safe () iterator instead. + + The second part to the bug is the lack of information of the main thread. + Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html) + Thank you Andrew. + + The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread + failed. This returned EPERM as errno. + + if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL)) + memset (gprs32, 0, sizeof (gprs32)); + + Hence all registers were set to 0 and we did not get the required infromation. + This issue will be fixed within the AIX ptrace call. + + Approved By: Ulrich Weigand . + +2024-11-04 GDB Administrator + + Automatic date update in version.in + +2024-11-03 GDB Administrator + + Automatic date update in version.in + +2024-11-02 GDB Administrator + + Automatic date update in version.in + +2024-11-01 Vladimir Mezentsev + + gprofng: use gprofng- prefix for gprofng binaries + gprofng application names have a gp- prefix (gp-display-text, gp-archive, etc.). + But our man pages use the gprofng- prefix (gprofng-display-text, + gprofng-archive, etc.). + I renamed the gprofng binaries and temporarily created the gp-* links for + compatibility with the old gprofng-gui. + We plan to remove these links in version 2.46. + + gprofng/ChangeLog + 2024-10-31 Vladimir Mezentsev + + * doc/gprofng-archive.texi: Rename gprofng application names. + * doc/gprofng-collect-app.texi: Likewise. + * doc/gprofng-display-html.texi: Likewise. + * doc/gprofng-display-src.texi: Likewise. + * doc/gprofng-display-text.texi: Likewise. + * doc/gprofng.texi: Likewise. + * doc/gprofng_ug.texi: Likewise. + * gp-display-html/Makefile.am: Likewise. + * gp-display-html/gp-display-html.in: Likewise. + * libcollector/collector.c: Likewise. + * src/Application.cc: Likewise. + * src/Experiment.cc: Likewise. + * src/Makefile.am: Likewise. + * src/gp-archive.cc: Likewise. + * src/gp-collect-app.cc: Likewise. + * src/gp-display-src.cc: Likewise. + * src/gp-display-text.cc: Likewise. + * src/gprofng.cc: Likewise. + * src/Makefile.in: Rebuild. + * gp-display-html/Makefile.in: Rebuild. + +2024-11-01 Vladimir Mezentsev + + Fix 32303 ./configure --help: replace --enable-gprofng with --disable-gprofng + ChangeLog + 2024-10-31 Vladimir Mezentsev + + PR 32303 + * configure.ac: Replace --enable-gprofng with --disable-gprofng + * configure: Rebuild. + +2024-11-01 Indu Bhagat + + ld: generate SFrame stack trace info for .plt.got + PR/32298 sframe: no SFrame stack trace info generated for .plt.got + + Add support to generate SFrame stack trace info for .plt.got section. + Enhance the current definition of struct elf_x86_sframe_plt to include + initialized SFrame FDE/FREs applicable for .plt.got section. There are + two variants of .plt.got entries: 16 byte and 8 byte. + + 8 byte: + ff 25 00 00 00 00 jmpq *name@GOTPCREL(%rip) + 66 90 xchg %ax,%ax + + 16 byte: + f3 0f 1e fa endbr64 + ff 25 66 2f 00 00 jmpq *name@GOTPCREL(%rip) + 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) + + For the testcase, define some application symbols such that their PLT + entry is placed in .plt.got and ensure SFrame information is generated + with and without -z ibtplt. + + ChangeLog: + PR/32298 + * bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): + PLT GOT entry size is different for IBT vs non IBT PLTs. + * bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for + SFRAME_PLT_GOT. + (_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT. + (_bfd_x86_elf_write_sframe_plt): Likewise. + (_bfd_x86_elf_late_size_sections): Likewise. + (_bfd_x86_elf_finish_dynamic_sections): Likewise. + * bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members + to keep information about PLT GOT entries. + (struct elf_x86_link_hash_table): Add support for creating + SFrame section for .plt.got. + * ld/testsuite/ld-x86-64/x86-64.exp: Add new tests. + * ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test. + * ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test. + * ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test. + +2024-11-01 Josh Poimboeuf + + ld: fix wrong SFrame info for lazy IBT PLT + Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt + + The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and + .plt.sec entries. It was observed that SFrame information for .plt.sec + section was incorrect. The erroneous assumption was that SFrame stack + trace information for .plt.sec with lazy binding is the same as SFrame + stack trace information for .plt with lazy binding. This is corrected + now by initializing a new SFrame PLT helper object + elf_x86_64_sframe_ibt_plt for lazy PLT with IBT. + + Add a testcase where linking with -z ibtplt generates .plt.sec entries and + ensure correct SFrame information for it. + + Committed by Indu Bhagat. + + ChangeLog: + PR/32296 + * bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New + definition elf_x86_64_sframe_ibt_plt. Use it in + elf_x86_64_sframe_plt. + (elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are + different from lazy PLT. + * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for + SFrame for IBT PLT. + * ld/testsuite/ld-x86-64/x86-64.exp: Add new test. + * ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test. + +2024-11-01 Josh Poimboeuf + + ld: fix PR/32297 + When _creating_ SFrame information for the linker created .plt.sec, the + code correctly checks for presence of .plt.sec. When _writing_ the + SFrame section for the corresponding .plt.sec, however, the conditionals + were wrongly checking for splt. This was causing an assertion at link + time. + + This issue has been known to affect glibc build with SFrame enabled. + + No testcase is added just yet. A later commit ensures correct SFrame + stack trace information is created for .plt.got. A test case (where only + .plt and .plt.got are created) is added then. + + PR/32297 sframe: bfd assertion with empty main on IBT enabled system + + Committed by Indu Bhagat. + + ChangeLog: + PR/32297 + * bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for + plt_second member not for splt. + +2024-11-01 H.J. Lu + + x86-64: Add a test for hidden undefined symbol + Linker should report an error for hidden undefined symbol when building + a shared library without the "recompile with -fPIC" message: + + $ cat x.c + extern int foo __attribute__ ((visibility ("hidden"))); + + int + func (void) + { + return foo; + } + $ gcc -c -fPIC -O2 x.c + $ objdump -dwr x.o + + x.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 : + 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 2: R_X86_64_PC32 foo-0x4 + 6: c3 ret + $ ld -shared -o x.so x.o + ld: x.o: in function `func': + x.c:(.text+0x2): undefined reference to `foo' + ld: x.o: relocation R_X86_64_PC32 against undefined hidden symbol `foo' can not be used when making a shared object + ld: final link failed: bad value + $ + + since -fPIC has been used. + + * testsuite/ld-x86-64/hidden6.d: New file. + * testsuite/ld-x86-64/hidden6.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run hidden6. + +2024-11-01 Andrew Oates + + Fix compile error due to [[noreturn]] with clang + Since commit d9deb60b2e9e94b532f43a7d3ddddf5ddf6dbdd3, I get the + following compiler error when building binutils (cross-compiling) on + macos: + + CXX remote-sim.o + ../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback + *, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)') + gdb_callback.error = gdb_os_error; + ^~~~~~~~~~~~ + 1 error generated. + + This appears to be due to the mismatch between ATTRIBUTE_NORETURN and + [[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error + resolves the issue. Removing ATTTRIBUTE_NORETURN on the + declaration of host_callback::error also works, but deprives the + compiler of data. + + Tested by compiling on macos both with the system clang, as well as with + GCC 14. With clang, remote-sim.c does not compile (per above) without + this patch. With GCC, it compiles with and without the patch (it + doesn't link, but AFAICT that is unrelated). + + The clang bug is reported upstream at + https://github.com/llvm/llvm-project/issues/113511 + + Approved-By: Tom Tromey + +2024-11-01 Tom Tromey + + Add gdb.events.tui_enabled + This adds a new event source so that Python scripts can track whether + or not the TUI is presently enabled. + + v2 of the patch renames "status" -> "enabled". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 + Reviewed-By: Eli Zaretskii + Reviewed-by: Keith Seitz + +2024-11-01 GDB Administrator + + Automatic date update in version.in + +2024-10-31 Domani Johannes + + Prevent use-after-free of bfd filename in gdb_bfd_close_or_warn + On Windows gcore is not implemented, and if you try it, you get an + heap-use-after-free error: + + (gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test + warning: cannot close "================================================================= + ==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140 + READ of size 111 at 0x1259ea503110 thread T0 + #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391 + #1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558 + #2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514 + #3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41 + #4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484 + #5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106 + #6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227 + #7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571 + #8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740 + #9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73 + #10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881 + #11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181 + #12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33 + #13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437 + #14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646 + #15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 + #16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 + #17 0x7ff68094b6f2 in gdb::ref_ptr::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 + #18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 + + 0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0) + freed by thread T0 here: + #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90 + #1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187 + #2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247 + #3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180 + #4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960 + #5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925 + #6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643 + #7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 + #8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 + #9 0x7ff68094b6f2 in gdb::ref_ptr::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 + #10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 + + It happens because gdb_bfd_close_or_warn uses a bfd-internal name for + the failing-close warning, after the close is finished, and the name + already freed: + + static int + gdb_bfd_close_or_warn (struct bfd *abfd) + { + int ret; + const char *name = bfd_get_filename (abfd); + + for (asection *sect : gdb_bfd_sections (abfd)) + free_one_bfd_section (sect); + + ret = bfd_close (abfd); + + if (!ret) + gdb_bfd_close_warning (name, + bfd_errmsg (bfd_get_error ())); + + return ret; + } + + Fixed by making a copy of the name for the warning. + + Approved-By: Andrew Burgess + +2024-10-31 Nelson Chu + + gas/doc/riscv: Fixed misaligned instruction table + gas/ + * doc/c-riscv.texi: Fixed misaligned instruction table. + +2024-10-31 Nelson Chu + + RISC-V: Dump instruction without checking architecture support as usual. + Since QEMU have supported -Max option to to enable all normal extensions, + the dis-assembler should also add an option, -M,max to do the same thing. + For the instruction, which have overlapped encodings like zfinx, will not + be considered by the -M,max option. + + opcodes/ + * riscv-dis.c (all_ext): New static boolean. If set, disassemble + without checking architectire string. + (riscv_disassemble_insn): Likewise. + (parse_riscv_dis_option_without_args): Recognized -M,max option. + binutils/ + * NEWS: Updated. + +2024-10-31 GDB Administrator + + Automatic date update in version.in + +2024-10-30 H.J. Lu + + ld-elf/pr25207.d: Pass --no-rosegment to ld + Pass --no-rosegment to ld to support linker configured with + --enable-rosegment, + + PR ld/25207 + * ld-elf/pr25207.d: Pass --no-rosegment to ld. + +2024-10-30 Guinevere Larsen + + gdb: Update SECURITY.txt to mention extension scripts and internal errors + Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update + the gdb/SECURITY.txt to be more explicit about some details. Specifically, + we now explicitly say that internal errors aren't security + vulnerabilities, and mention that users should review plugins before + running them, and under which conditions a plugin can cause a security + bug. + + Reviewed-By: Tom Tromey + Approved-By: Luis Machado + Approved-By: Andrew Burgess + +2024-10-30 Tom de Vries + + [gdb/tdep] Use std::array in amd64-windows-tdep.c + I noticed commit 84786372e1c ("Fix size of register buffer") fixing a + stack-buffer-overflow found by AddressSanitizer in + amd64_windows_store_arg_in_reg: + ... + - gdb_byte buf[8]; + + gdb_byte buf[16]; + ... + and wondered if we could have found this without AddressSanitizer. + + I realized that the problem is that this: + ... + gdb_byte buf[N]; + ... + regcache->cooked_write (regno, buf); + ... + is using the deprecated variant of cooked_write instead of the one using + gdb::array_view: + ... + /* Transfer of pseudo-registers. */ + void cooked_write (int regnum, gdb::array_view src); + + /* Deprecated overload of the above. */ + void cooked_write (int regnum, const gdb_byte *src); + ... + and consequently cooked_write does not know the size of buf. + + Fix this by using std::array, and likewise in other places in + gdb/amd64-windows-tdep.c. + + In the process I fixed another out of bounds access here: + ... + gdb_byte imm16[2]; + ... + cache->prev_sp = cur_sp + + extract_unsigned_integer (imm16, 4, byte_order); + ... + where we're reading 4 bytes from the 2-byte buffer imm16. + + Tested by rebuilding on x86_64-linux. + + Tested-By: Hannes Domani + +2024-10-30 Jan Beulich + + x86: add a helper to copy insn operand info + We're doing such in fairly many places, and yet more are likely to + appear; centralize the logic, much like we already have + swap_2_operands(). + + While there also correct mis-indentation in adjacent code in + process_operands(). + +2024-10-30 Jan Beulich + + x86/APX: support JMPABS also in assembler + Without this APX support isn't really complete. + + For Intel syntax displacement form is needed, such that symbolic + operands won't need prefixing by "offset". (The other form is actually + not used at all in Intel syntax.) + + For the record: To restrict displacement form to Intel syntax is not + something I actually agree with. + +2024-10-30 Jan Beulich + + x86/APX: squash REX prefix when REX2 is being emitted + We should not (silently) emit a REX prefix ahead of a REX2-encoded insn; + such encodings are illegal. Best we can do is fold the REX bits into the + REX2 prefix, and then zap the REX one from i.prefix[]. + +2024-10-30 GDB Administrator + + Automatic date update in version.in + +2024-10-29 Bernd Edlinger + + Fix signal unsafe call inside a signal + It can easily happen that the signal handler function + `handle_fatal_signal` uses various signal unsafe functions. + The problematic functions are `_` and `strsignal` which + can be pre-computed after the `setlocale` call is done. + + Unfortunately when compiled with --disable-libbacktrace a + different code path is used, that calls the glibc function + `backtrace` which calls `malloc` and `free` and is therefore + also signal unsafe, that is probably unfixable, so there + is no attempt to fix anything in this code path. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9 + +2024-10-29 Tom de Vries + + [gdb/testsuite] Add read1 and readmore to make-check-all.sh + There are two useful ways to run a test-case, that are not represented by a + board file in gdb/testsuite/boards: check-read1 and check-readmore. + + Consequently, they're not run either by make-check-all.sh. + + Fix this by adding check-read1 and check-readmore to make-check-all.sh. + + Tested on x86_64-linux. Verified with shellcheck. + + Approved-By: Andrew Burgess + +2024-10-29 Nick Clifton + + Add a target to src-release.sh to crate a binutils release without Gold + +2024-10-29 Hakan Candar + + ld/ELF: Add --image-base command line option to the ELF linker + LLD has dropped the option -Ttext-segment for specifying image base + addresses, instead forcing the use of the --image-base option for both + ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible, + having two different options for the same functionality. + + This patch enables the use of --image-base on ELF targets, advancing + consistency and compatibility. + + See: https://reviews.llvm.org/D70468 + https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#address-related + https://sourceware.org/bugzilla/show_bug.cgi?id=25207 + + Moreover, a new test has been added to ensure -z separate-code behaviour + when used with -Ttext-segment stays the same. When this combination is + used, -Ttext-segment sets the address of the first segment (R), not the + text segment (RX), and like with -z noseparate-code, no segments lesser + than the specified address are created. If this behaviour was to change, + the first (R) segment of the ELF file would begin in a lesser address + than the specified text (RX) segment, breaking traditional use of this + option for specifying image base address. + +2024-10-29 Tom de Vries + + [gdb/symtab] Handle multiple .debug_info sections + When compiling dw2-multiple-debug-info.c using -gdwarf-5 + -fdebug-types-section, we end with two .debug_info sections in the object + file: + ... + $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ + -gdwarf-5 \ + -fdebug-types-section + $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info + [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 + [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 + ... + + One of them contains the CU for dw2-multiple-debug-info.c, the other contains + the TU for the type of variable a. + + When trying to print the type of variable a, we get: + ... + $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" + 'a' has unknown type; cast it to its declared type + ... + because the TU hasn't been read. + + Fix this by adding support for reading multiple .debug_info sections, similar + to how that is done for multiple .debug_types sections, getting us instead: + ... + $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" + type = class sp1::A { + ... + } + ... + + Tested on x86_64-linux. + + PR symtab/32223 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223 + +2024-10-29 Ijaz, Abdul B + + fortran: Fix arrays of variable length strings for FORTRAN + Before this change resolve_dynamic_array_or_string was called for + all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end, + this function always called create_array_type_with_stride, which + creates a TYPE_CODE_ARRAY type. + + Suppose we have + + subroutine vla_array (arr1, arr2) + character (len=*):: arr1 (:) + character (len=5):: arr2 (:) + + print *, arr1 ! break-here + print *, arr2 + end subroutine vla_array + + The "print arr1" and "print arr2" command at the "break-here" line + gives the following output: + + (gdb) print arr1 + $1 = + (gdb) print arr2 + $2 = ('abcde', 'abcde', 'abcde') + (gdb) ptype arr1 + type = Type + End Type + (gdb) ptype arr2 + type = character*5 (3) + + Dwarf info using Intel® Fortran Compiler for such case contains following: + <1>: Abbrev Number: 12 (DW_TAG_string_type) + DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 + <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8) + + After this change resolve_dynamic_array_or_string now calls + create_array_type_with_stride or create_string_type, so if the + incoming dynamic type is a TYPE_CODE_STRING then we'll get back a + TYPE_CODE_STRING type. Now gdb shows following: + + (gdb) p arr1 + $1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij') + (gdb) p arr2 + $2 = ('abcde', 'abcde', 'abcde') + (gdb) ptype arr1 + type = character*10 (5) + (gdb) ptype arr2 + type = character*5 (3) + + In case of GFortran, compiler emits DW_TAG_structure_type for string type + arguments of the subroutine and it has only DW_AT_declaration tag. This + results in in gdb. So, following issue is raised in gcc + bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826". + + Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp, + i.e. the test forces the language to C/C++ and print a Fortran string value. + The string value is a dynamic type with code TYPE_CODE_STRING. + + Before this commit the dynamic type resolution would always convert this to + a TYPE_CODE_ARRAY of characters, which the C value printing could handle. + + But now after this commit we get a TYPE_CODE_STRING, which + neither the C value printing, or the generic value printing code can + support. And so, I've added support for TYPE_CODE_STRING to the generic + value printing, all characters of strings are printed together till the + first null character. + + Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp + tests it expects type of character array in 'character (3)' format but now + after this change we get 'character*3', so tests are updated accordingly. + + Approved-By: Tom Tromey + +2024-10-29 Lulu Cai + + LoongArch: Corrected to GNU style code + +2024-10-29 Jan Beulich + + x86: use for VFPCLASSP{S,D} + Just like VFPCLASSPH does. While the order of generated table entries + changes this way, the individual entries don't change. + + gas: make fix_new_exp()'s "exp" parameter const + This really should be only an input; in particular it looks bogus that + O_add expressions are even altered. That altering and the recursion are + even pointless: Once expanding what the inner call would do (with + O_symbol) it becomes clear that this is no different than the default + case. Simplify the code accordingly, retaining the comment. + +2024-10-29 Jan Beulich + + gas: constify md_{short,long}opts and md_longopts_size + First of all make the declarations globally visible, such that producer + and consumer actually share them. + + For the latter two simply add const (as PPC already had it,), while for + the former achieve the effect by converting to an array: There's no need + for the extra level of indirection. + +2024-10-29 Kito Cheng + + RISC-V: Update the doc to match ISA manual + ISA manual use funct* rather than func*[1] (e.g. funct7 rather than func7), + and I realized that may something I typo at beginning when I write the patch + for `.insn` support...:P + + [1] https://github.com/riscv/riscv-isa-manual/blob/main/src/rv32.adoc#integer-register-register-operations + +2024-10-29 GDB Administrator + + Automatic date update in version.in + +2024-10-28 Hannes Domani + + Fix size of register buffer + When calling a function with double arguments, I get this asan error: + + ==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40 + READ of size 16 at 0x0053131ece38 thread T0 + #0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814 + #1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845 + #2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840 + #3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view) C:/gdb/src/gdb.git/gdb/regcache.c:874 + #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view) C:/gdb/src/gdb.git/gdb/regcache.c:914 + #5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933 + #6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216 + + Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame + #0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208 + + This frame has 4 object(s): + [32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable + + It's because the first 4 double arguments are passed via XMM registers, + and they need a buffer of 16 bytes, even if we only use 8 bytes of them. + + Approved-By: Tom Tromey + +2024-10-28 Hannes Domani + + Don't copy memory for arguments if there are none + If amd64_windows_push_arguments is called with no arguments, then ARGS + can be NULL, and inside the passed-by-pointer block, memcpy is called + with this NULL, which is undefined behavior. + + So this just disable the passed-by-pointer block if there are no + arguments. + + Fixes the following ubsan error: + C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null + + Approved-By: Tom Tromey + +2024-10-28 Simon Marchi + + gdbserver: remove unused include in gdbthread.h + clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h, + which seems right, so remove it. Add it to two files that need it, but + were relying on the now-removed include. + + Change-Id: I12916a044d0b15f346c4ad0e6527ce99a6d460e4 + +2024-10-28 Simon Marchi + + gdbserver: fix formatting in gdbthread.h + Remove newlines after return type in declarations. + + Change-Id: I00c6f35e063024cf6674d532454b67e6d0d98a19 + +2024-10-28 Guinevere Larsen + + gdb/record: add support to vzeroupper instruction + This commit adds recording support for the AVX instruction vzeroupper, + which zeroes the high bits of ymm registers 0..15. In the programmer's + manual, it is explicitly states that ymm registers 16..31 won't be + affected if present, so we only need to record the first 16 registers. + + We record ymm_h registers since only the higher bits are touched, and + that reduces the memory footprint of the instruction. + + This instruction is tested differently as we want to confirm we're only + saving the relevant registers, and we want to ensure we're saving + all of them, so it makes use of "maint print record-instruction" to see + exactly what was recorded. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: support AVX instructions VMOVDQ(U|A) when recording + This commit adds support for the instructions VMOVDQU and VMOVDQA, used + to move values to/from 256 bit registers. Unfortunately, the + programmer's manual is very incomplete (if not wrong) about these + instructions, so the logic had to be reverse engineered from how gcc + actually encodes the instruction. + + This commit also changes the memory regions from the test to store 256 + bits, so its easier to test the instructions and that we're recording + ymm registers correctly. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: Add recording support to vpbroadcast instructions + This commit adds recording support to all AVX and AVX2 instructions + of the form vpbroadcast. GDB is not yet concerned about AVX512 in + recording mode, so for now we only support the AVX2 registers and + instructions. + + This commit also updates the gdb.reverse/i386-avx-reverse.exp to test + broadcast instructions. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: add support to AVX unpack instructions + This commit adds support to recording instructions to unpack high + or low data from XMM registers, identified by the mnemonics in the + form: VPUNPCK [L|H] [BW|WD|DQ|QDQ]. + All these instructions are encoded the exact same way, and only affect + the destination register, making them trivial to implement together. + + It also updates the test gdb.reverse/i386-avx-reverse.exp to test these + new instructions. The test always uses ymm because the vpunpck + instructions overwrite the high bits, so we have to be able to record + the full ymm register, not just the output size. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: add support to vmovd and vmovq instructions + This commit adds support to the x86_64 AVX instructions vmovd and vmovq. + The programmers manuals for Intel and AMD describe these 2 instructions + as being almost the same, but my local testing, using gcc 13.2 on Fedora + 39, showed several differences and inconsistencies. + + The instruction is supposed to always use the 3-byte VEX prefix, but I + could only find 2-byte versions. The instructions aren't differentiated + by the VEX.w bit, but by opcodes and VEX.pp. + + This patch adds a test with many different uses for both vmovd and + vmovq. It also updates the test gdb.reverse/step-precsave.exp to + reference the generic "missing avx support" bug open in the bug tracker + (17346), instead of pointing to one that specifically calls out to + vmovd instructions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188 + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb: Start supporting AVX instruction + This patch introduces the information needed to properly identify the + VEX prefix, used to signal an AVX and AVX2 instruction, and introduces + a helper function to handle all AVX instruction, instead of adding to + the 3000 line long recording function. + + This new function will temporarily set the current thread as "not + executing" so that it can read from pseudo registers as we record, since + most AVX/AVX2 instructions would benefit from recording ymm registers. + + The new helper also handles unsupported instructions so that the largest + part of the i386_process_record doesn't have to be shifted by 2 spaces, + which made an unreadably big patch file. + + The only expected difference to the end user added by this patch is a + small change to the unsupported message. This patch also updates the + test gdb.reverse/step-precsave.exp, by recognizing the new output. + + As a note for the future, we don't handle xmm16-31 and ymm16-31 because + those require the EVEX prefix, meaning avx512 support. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb: Allow replayed threads to read and write pseudo registers + In an effort to support AVX instructions when recording, we need to + allow replaying threads to access pseudo registers. Currently, if + we try to do that gdb will fail in a call to validate_registers_access, + because the thread is executing so GDB thinks it is unsafe to read + pseudo registers. + + When replaying, the thread is really executing for all intents and + purposes, but the execution is just having GDB change values on + registers, so it will always be safe to read and write pseudo registers. + This commit changes functions that check for register access to allow + access when we are replaying. The check to whether we are replaying must + not happen when writing a core file, as record_full_list could be nullptr, + so we only check it if the thread is executing. + + As of this commit, I don't know of a way to trigger this commit without + AVX support on record, so a test isn't provided. However, as soon as + record-full supports saving ymm registers, the AVX tests will test this + as well. + + Approved-By: Tom Tromey + +2024-10-28 Jim Lin + + RISC-V: Fix typo in gas/testsuite/gas/riscv/mapping.s + gas/ + * gas/riscv/mapping.s: Fix typo. + * gas/riscv/mapping-dis.d: Fix typo. + * gas/riscv/mapping-symbols.d. Fix typo. + +2024-10-28 GDB Administrator + + Automatic date update in version.in + +2024-10-27 Andrew Burgess + + gdb/testsuite: avoid intermittent failures on a debuginfod test + I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which + I could only produce one time. + + Normally the test output looks like this: + + file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... + (gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war + + But one time I saw this: + + file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... + (gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings + + The difference is the "Downloading separate debug info for ..." line + has gained an extra '6.77 K' component. When I got the FAIL the + machine was under heavy load, so I suspect everything was running + pretty slow. I think the size is only added when the debuginfod + download is taking its time. + + Anyway, the test in question is not expecting to see a size, which is + why it failed. + + Every other debuginfod test does allow for an optional size being + printed, so lets update this test to also accept an optional size, + this should prevent failures like this in the future. + +2024-10-27 GDB Administrator + + Automatic date update in version.in + +2024-10-26 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp + There are two test-cases that only run when the target board produces .dwp + files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. + + When running those test-cases with target board fission-dwp, I run into: + ... + (gdb) ptype main^M + warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ + referenced by CU at offset 0xa6 [in module dwp-symlink]^M + type = ()^M + (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink + ... + coming from: + ... + # This case cannot work. + gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" + ... + + I had a bit of difficulty understanding what the test-case does/tries to do, + so to build some understanding I reproduced the behaviour outside of the + test-case: + ... + $ cat start.c + void _start (void) {} + $ gcc -gsplit-dwarf start.c -nostdlib + $ gdb -q -batch a.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ dwp -e a.out + $ rm start.dwo + $ gdb -q -batch a.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ ln -s a.out b.out + $ gdb -q -batch b.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ mv a.out.dwp b.out.dwp + $ gdb -q -batch b.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ gdb -q -batch a.out -ex "print _start" + During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ + referenced by CU at offset 0x0 [in module a.out] + warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ + referenced by CU at offset 0x0 [in module a.out] + $1 = {} 0x400144 <_start> + ... + and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, + and there's no way to find b.out.dwp starting from a.out. + + The fact that a FAIL is produced is incorrect, gdb does nothing wrong. + + Fix this by checking for the warning text instead. + + While we're at it, fix this PATH as well: + ... + (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M + Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M + (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ + /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink + PATH: gdb.dwarf2/dwp-symlink.exp: cd \ + /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink + ... + + While we're at it, use string_to_regexp to simplify the test-case. + + Tested on x86_64-linux, with target board fission-dwp. + +2024-10-26 Andrew Burgess + + gdb/testsuite: fix test pattern after switch to -lbl matching + After commit: + + commit a1ccc78ea7ba8cad3ff37cbde9b5d3bba0194796 + Date: Fri Oct 25 06:14:03 2024 +0200 + + [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) + + I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem + is that by switching to line by line matching we now need to ensure + that the gdb_test_multiple patterns match up to the end of the line, + but don't actually include the trailing \r\n (yeah, our line by line + matching is weird). We need to be especially careful anywhere '.*' is + used as this can potentially match content on a subsequent line. + + I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up + to the end of the line, but not the end of line itself, and I've made + use of '(?=\r\n)' in a couple of other places to ensure we match up to + the end of the line, but don't match the line terminator itself. + +2024-10-26 Tom de Vries + + [gdb] Don't create registry keys in destructor + Creating a registry key using emplace calls new: + ... + DATA *result = new DATA (std::forward (args)...); + ... + which can throw a bad alloc, which will terminate gdb if called from a + destructor. + + Fix this in a few places. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-26 Alan Modra + + tekhex.c tidy writesym + Simplifies the code a little. No functional changes. + + PR32300, --dependency-file: link dependencies are not all collected + PR 32300 + PR 31904 + Revert patch accidentally committed with 057a2b4c4b + +2024-10-25 Tom de Vries + + [gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexcept + Say we simulate a bad alloc in exceptions_state_mc_init: + ... + jmp_buf * + exceptions_state_mc_init () + { + + { + + static bool throw_bad_alloc = true; + + if (throw_bad_alloc) + + { + + throw_bad_alloc = false; + + + + va_list dummy; + + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + + } + + } + catchers.emplace_front (); + return &catchers.front ().buf; + } + ... + + After starting gdb and typing "q", gdb terminates: + ... + $ gdb -q + (gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc' + what(): std::bad_alloc + ... + because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on + gdb_rl_callback_read_char_wrapper_noexcept: + ... + static struct gdb_exception + gdb_rl_callback_read_char_wrapper_noexcept () noexcept + { + struct gdb_exception gdb_expt; + + /* C++ exceptions can't normally be thrown across readline (unless + it is built with -fexceptions, but it won't by default on many + ABIs). So we instead wrap the readline call with a sjlj-based + TRY/CATCH, and rethrow the GDB exception once back in GDB. */ + TRY_SJLJ + ... + + Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to + gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function + that catches the bad alloc expection: + ... + static struct gdb_exception + gdb_rl_callback_read_char_wrapper_noexcept () noexcept + { + try + { + return gdb_rl_callback_read_char_wrapper_sjlj (); + } + catch (gdb_exception &ex) + { + return std::move (ex); + } + } + ... + getting us instead: + ... + $ gdb -q + (gdb) bad alloc + (gdb) q + ... + + Tested on aarch64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1 + Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting + the output of skip_libstdcxx_probe_tests_prompt by making the used command + more precise: using "info probes stap libstdcxx" instead of "info probes". + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1 + Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by + using a custom line-by-line exp_continue clause: + ... + -re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" { + exp_continue + } + ... + which drops a line each time it finds two lines in the buffer. + + This allows the other clauses to use two-line patterns. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using -lbl. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (pipe/grep) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using pipe / grep to filter out unnecessary output. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (gdb_test_lines) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using gdb_test_lines, as well as related gdb_get_lines. + + Tested on x86_64-linux. + +2024-10-25 GDB Administrator + + Automatic date update in version.in + +2024-10-24 Tom Tromey + + Add locking when reading BFD sections + This adds some per-BFD locking to gdb_bfd_map_section and + gdb_bfd_get_full_section_contents. + + It turned out that the background DWARF reader could race with the + auto-load code, because the reader might try to mmap a section when + the main thread was trying to read in .debug_gdb_scripts. + + The current BFD threading model is that only BFD globals will be + locked, so any multi-threaded use of a BFD has to be handled specially + by the application. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 + Reviewed-by: Kevin Buettner + +2024-10-24 Tom Tromey + + Use gdb_bfd_get_full_section_contents in auto-load.c + This changes auto-load.c ot use gdb_bfd_get_full_section_contents. + This shouldn't change any behavior, but makes it easier to add locking + in a subsequent patch. + + Reviewed-by: Kevin Buettner + +2024-10-24 Alan Modra + + Replace uses of asprintf with xasprintf + xasprintf has a nicer interface and behaves like xmalloc as far as + memory is concerned, ie. no need to check a return status and the + program exits with an error on OOM. + + binutils/ + * dwarf.c (load_debug_sup_file): Replace asprintf with xasprintf. + * nm.c (get_elf_symbol_type, get_coff_symbol_type): Likewise. + * objdump.c (dump_ctf_indent_lines): Likewise. + * readelf.c (display_lto_symtab, dump_ctf_indent_lines): Likewise. + * windres.c (main): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + gas/ + * config/tc-kvx.c (kvx_emit_single_noop): Simplify. + * config/tc-riscv.c (md_assemblef): Replace asprintf with xasprintf. + * read.c (s_nop, do_s_func): Likewise. + * stabs.c (stabs_generate_asm_func): Likewise. + (stabs_generate_asm_endfunc): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + ld/ + * ldlang.c (lang_leave_overlay_section): Replace xmalloc+sprintf + with xasprintf. Localise vars. + * lexsup.c (parse_args): Replace asprintf with xasprintf. + * pe-dll.c (make_head, make_tail, make_one): Likewise. + (make_singleton_name_thunk, make_import_fixup_entry): Likewise. + (make_runtime_pseudo_reloc): Likewise. + (pe_create_runtime_relocator_reference): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + +2024-10-24 Alan Modra + + tekhex object file output fixes + writevalue didn't handle 64-bit values, dropping the high 32 bits, + and also wrote any value in the range [0,15] as 0. + + * tekhex.c (first_phase): Handle *ABS* symbols. + (writevalue): Rewrite. + +2024-10-24 GDB Administrator + + Automatic date update in version.in + +2024-10-23 Guinevere Larsen + + gdb/testsuite: introduce dwarf5 option to gdb_compile + A few tests on the testsuite require dwarf5 to work. Up until now, the + way to do this was to explicitly add the command line flag -gdwarf-5. + This isn't very portable, in case a compiler requires a different flag + to emit dwarf5. + + This commit adds a new option to gdb_compile that would be able to add + the correct flag (if known) or error out in case we are unable to tell + which flag to use. It also changes the existing tests to use this + general option instead of hard coding -gdwarf-5. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-10-23 GDB Administrator + + Automatic date update in version.in + +2024-10-22 Tom Tromey + + Implement 'Object_Size + This patch started as an attempt to allow the 'Size attribute to be + applied to types, and not just objects. + + However, that turns out to be difficult due to the Ada semantcs of + 'Size. In particular, Ada requires 'Size to denote the size of the + representation of the value, so for example Boolean'Size must be 1. + Implementing this properly requires information not readily available + to gdb... and while we could synthesize this information in many + cases, it also seemed to me that this wasn't strictly very useful when + debugging. + + So instead, this patch adds support for the 'Object_Size attribute, + which is somewhat closer to 'sizeof'. + + Note also that while 'Object_Size is defined for some dynamic types, I + chose not to implement this here, as again this information is not + readily available -- and I think it's preferable to error than to + print something that might be incorrect. + + Reviewed-By: Eli Zaretskii + +2024-10-22 Michael Matz + + stringmerge: don't presize hash table + originally the reason for pre-sizing was that that's easier + for a multi-threaded use of the hash table. That hasn't materialized + yet, so there's not much sense in using the very very conservative + estimates for pre-sizing. Doing the resize on-demand, whenever we + actually need to add a new entry doesn't change performance. + + bfd/ + merge.c (sec_merge_hash_insert): Resize as needed from here ... + (record_section): ... not from here. Don't calculate estimates, + return bool instead of three-state, regard all errors as soft + errors. + (_bfd_merge_sections): Adjust. + +2024-10-22 Stephan Rohr + + gdbserver: use 'gdb::function_view' in 'find_*' and 'for_each_*' + Remove the templated versions of 'find_thread', 'for_each_thread' and + 'find_thread_in_random' and replace the template function argument with + 'gdb::function_view'. The usage of 'gdb::function_view' produces less + cryptic messages on errors and documents well the types of the + parameters taken by the callback and its return type. + + Approved-By: Simon Marchi + +2024-10-22 Tom de Vries + + [gdb/testsuite] Handle maint set dwarf synchronous off default + I ran the testsuite with a patch setting dwarf_synchronous to false by + default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp + and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did + not show up as a result of the file command. + + Fix this by forcing "maint set dwarf synchronous on". + + Add the same in gdb.base/index-cache.exp, where this is also required. + + Tested on aarch64-linux. + +2024-10-22 Tom de Vries + + [gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.exp + I ran into: + ... + (gdb) pipe maint print objfiles self-spec | grep c1^M + name: c1^M + canonical: c1^M + qualified: c1^M + [3] ((addrmap *) 0xfffedfc1f010)^M + (gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index + ... + + Fix this by renaming the class from c1 to class1. + + Tested on aarch64-linux. + +2024-10-22 Tom de Vries + + [gdb] Handle EINTR in run_under_shell + When building gdb with -O2 -fsanitize=thread and running test-case + gdb.base/bg-exec-sigint-bp-cond.exp, I run into: + ... + (gdb) c&^M + Continuing.^M + (gdb) Quit^M + (gdb) quit_count=1 + ^M + Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M + 23 return 0;^M + FAIL: $exp: no force memory write: \ + SIGINT does not interrupt background execution + ... + + What happens is that: + - the breakpoint hits + - while evaluating the condition of the breakpoint, + $_shell("kill -INT ") is called, handled by run_under_shell + - in run_under_shell, a vfork is issued + - in the vfork child, execl executes the kill command + - in the vfork parent, waitpid is called to wait for the result of the kill + command + - waitpid returns -1 with errno set to EINTR + - run_under_shell doesn't check the result of waitpid, and returns the + value of local variable status. Since waitpid returned -1, status was + not assigned a value, so it's uninitialized, and happens to be + non-zero + - the breakpoint condition evaluates to true, because + $_shell("kill -INT ") != 0 + - the breakpoint triggers a stop, which the test-case doesn't expect. + + Fix this by using gdb::handle_eintr to call waitpid in run_under_shell. + + Also handle the case that waitpid returns an error other than EINTR, using + perror_with_name. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR gdb/30695 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695 + +2024-10-22 Lulu Cai + + LoongArch: Force relocation for every reference to the global offset table + Local absolute symbols are resolved at assembly stage and the symbol + value is placed in the relocation addend. But non-zero addend will + cause an assertion failure during linking. + + Forces emission of relocations to defer resolution of local abs symbols + until link time. + + bfd/ + + * elfnn-loongarch.c (loongarch_elf_relax_section): Determine + absolute symbols in advance to avoid ld crash. + + gas/ + + * config/tc-loongarch.c (loongarch_force_relocation): New + function to force relocation. + * config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros + to force relocation. + (loongarch_force_relocation): Function declaration. + * testsuite/gas/loongarch/localpic.d: New test. + * testsuite/gas/loongarch/localpic.s: New test. + +2024-10-22 GDB Administrator + + Automatic date update in version.in + +2024-10-21 Tom de Vries + + [gdb/symtab] Fix incorrect filenames with inter-CU refs + With target board unix we get: + ... + $ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \ + -ex "info function operator\*" + All functions matching regular expression "operator\*": + + File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc: + 72: void foo::operator*(foo&); + 85: void foo::operator*=(foo&); + ... + but with target board cc-with-dwz-m: + ... + All functions matching regular expression "operator\*": + + File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h: + 72: void foo::operator*(foo&); + 85: void foo::operator*=(foo&); + ... + + The first operator: + ... + $ c++filt _ZN3foomlERS_ + foo::operator*(foo&) + ... + matches address 0x410250 which is defined here in the CU in the exec: + ... + <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram) + <10f2> DW_AT_specification: + <10f6> DW_AT_decl_line : 72 + <10f7> DW_AT_decl_column : 7 + <10f7> DW_AT_object_pointer: <0x1106> + <10f9> DW_AT_low_pc : 0x410250 + <1101> DW_AT_high_pc : 32 + <1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) + <1104> DW_AT_call_all_calls: 1 + ... + and declared here in the PU in the .dwz file: + ... + <2><93>: Abbrev Number: 20 (DW_TAG_subprogram) + <94> DW_AT_external : 1 + <94> DW_AT_name : operator* + <98> DW_AT_decl_file : 2 + <98> DW_AT_decl_line : 10 + <99> DW_AT_decl_column : 9 + <9a> DW_AT_linkage_name: _ZN3foomlERS_ + <9e> DW_AT_accessibility: 1 (public) + <9e> DW_AT_declaration : 1 + <9e> DW_AT_object_pointer: <0xa2> + ... + + When creating a new symbol for the operator, the DW_AT_decl_file attribute is + looked up, and found to be 2. + + The 2 is supposed to be mapped using the PU, which has this file name table: + ... + The File Name Table (offset 0x78, lines 3, columns 2): + Entry Dir Name + 0 0 + 1 1 stddef.h + 2 2 cplusfuncs.cc + ... + + Instead, it's mapped using the CU, which has this file name table: + ... + The File Name Table (offset 0x34, lines 3, columns 2): + Entry Dir Name + 0 1 cplusfuncs.cc + 1 1 cplusfuncs.cc + 2 2 stddef.h + ... + + This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where + the same problem happens for two CUs. + + Fix this by using the correct file name table. + + Add a dwarf assembly test-case for PR25771. + + Tested on aarch64-linux. + + Reviewed-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814 + +2024-10-21 Alexandra Hájková + + gdbreplay: Add --debug-logging option + As gdbreplay communicates with GDB, it outputs all the remote + protocol communication it reads from the remotelogfile to stderr. + This patch disables this behavior by default but adds the new + --debug-logging option which turns printing the packets + to stderr on again. + + The motivation for this change is to make it possible to use + gdbreplay with TCL tests. Printing the whole remotelog file out + seems to overflow the expect cache wich causes gdbreplay to not + to get the packet its expects and results in going out of sync + with GDB. Other motivation is making communication between GDB + and gdbreplay faster as printing bigger remotelogfile takes + considerable amount of time. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-10-21 Alexandra Hájková + + gdbreplay: Use getopt_long to parse command line arguments + Approved-By: Tom Tromey + +2024-10-21 Tom de Vries + + [gdb/contrib] Handle dot in spellcheck.sh + Add handling of '.' in gdb/contrib/spellcheck.sh. + + While we're at, simplify the sed invocation by using a single s command + instead of 3 s commands. + + Also introduce sed_join and grep_join. + + Fix the following common misspellings: + ... + bandwith -> bandwidth + emmitted -> emitted + immediatly -> immediately + suprize -> surprise + thru -> through + transfered -> transferred + ... + + Verified with shellcheck. + +2024-10-21 Tom de Vries + + [gdb/contrib] Speed up spellcheck.sh --check + Speed up gdb/contrib/shellcheck.sh by caching the grep pattern. + + Without cached grep pattern: + ... + $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c + + real 0m2,750s + user 0m0,013s + sys 0m0,032s + ... + and with cached grep pattern: + ... + $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c + + real 0m0,192s + user 0m0,022s + sys 0m0,024s + ... + + Tested on aarch64-linux. + +2024-10-21 Tom de Vries + + [gdb/contrib] Add spellcheck.sh --check + Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell + check and bail out ASAP with an exit code of 1 if misspelled words were + found, or 0 otherwise. + + Verified with shellcheck. + +2024-10-21 Andrew Burgess + + gdb/guile: add get-basic-type + A question was asked on stackoverflow.com about the guile function + get-basic-type[1] which is mentioned in the docs along with an example + of its use. + + The problem is, the function was apparently never actually added to + GDB. But it turns out that it's pretty easy to implement, so lets add + it now. Better late than never. + + The implementation mirrors the Python get_basic_type function. I've + added a test which is a copy of the documentation example. + + One issue is that the docs suggest that the type will be returned as + just "int", however, I'm not sure what this actually means. It makes + more sense that the function return a gdb:type object which would be + represented as "#", so I've updated the docs to show + this output. + + [1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session + + Reviewed-By: Kevin Buettner + +2024-10-21 Tom de Vries + + [gdb/build, c++20] Fix more deprecated implicit capture of this + When building gdb with -std=c++20 I run into: + ... + gdb/dwarf2/cooked-index.c: In lambda function: + gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \ + ‘[=]’ is deprecated in C++20 [-Werror=deprecated] + 471 | gdb::thread_pool::g_thread_pool->post_task ([=] () + | ^ + gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture + ... + + Fix this and two more spots by removing the capture default, and explicitly + listing all captures. + + Tested on x86_64-linux. + +2024-10-21 GDB Administrator + + Automatic date update in version.in + +2024-10-20 Andrew Burgess + + gdb: fix 'maint info inline-frames' after 'stepi' + There is an invalid assumption within 'maint info inline-frames' which + triggers an assert: + + (gdb) stepi + 0x000000000040119d 18 printf ("Hello World\n"); + (gdb) maintenance info inline-frames + ../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + ... etc ... + + The problem is this assert: + + /* Stopped threads always have cached inline_state information. */ + gdb_assert (it != inline_states.end ()); + + If you check out infrun.c and look in handle_signal_stop for the call + to skip_inline_frames then you'll find a rather large comment that + explains that we don't always compute the inline state information for + performance reasons. So the assertion is not valid. + + I've updated the code so that if there is cached information we use + that, but if there is not then we just create our own information for + the current $pc of the current thread. + + This means that, if there is cached information, GDB still correctly + shows which frame the inferior is in (it might not be in the inner + most frame). + + If there is no cached information we will always display the inferior + as being in the inner most frame, but that's OK, because if + skip_inline_frames has not been called then GDB will have told the + user they are in the inner most frame, so everything lines up. + + I've extended the test to check 'maint info inline-frames' after a + stepi which would previously have triggered the assertion. + +2024-10-20 Tom Tromey + + Use std::make_unique in more places + I searched for spots using ".reset (new ...)" and replaced most of + these with std::make_unique. I think this is a bit cleaner and more + idiomatic. + + Regression tested on x86-64 Fedora 40. + + Reviewed-By: Klaus Gerlicher + +2024-10-20 Alan Modra + + Report bfd_merge_sections error + PR 32260 + bfd/ + * elfxx-target.h (bfd_elfNN_bfd_merge_sections): Default to + bfd_generic_merge_sections when using the generic linker. + * elflink.c (_bfd_elf_merge_sections): Return error from + _bfd_merge_sections. Abort on wrong hash table. + ld/ + * ldlang.c (lang_process): Report bfd_merge_sections error. + +2024-10-20 GDB Administrator + + Automatic date update in version.in + +2024-10-19 Tom Tromey + + Capture the current directory and debug directory in DWARF reader + This changes the DWARF reader to capture the current working directory + and the current debug directory. This avoids races when the DWARF + reader is working in the background. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom Tromey + + Add cwd paramter to openp + This patch adds a cwd paramter to openp, so that the current directory + can be passed in by the caller. This is useful when background + threads call this function -- they can then avoid using the global and + thus avoid races with the user using "cd". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom Tromey + + Pass current directory to gdb_abspath + Currently, gdb_abspath uses the current_directory global. However, + background threads need to capture this global to avoid races with the + user using "cd". + + This patch changes this function to accept a cwd parameter, in + prepration for this. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom de Vries + + [gdbsupport] Add gdb::array_view::{iterator,const_iterator} + While trying to substitute some std::vector type A in the code with a + gdb::array_view: + ... + - using A = std::vector + + using A = gdb::array_view + .... + I ran into the problem that the code was using A::iterator while + gdb::array_view doesn't define such a type. + + Fix this by: + - adding types gdb::array_view::iterator and gdb::array_view::const_iterator, + - using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is + usual, and + - using them explicitly in a unit test. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-19 Tom de Vries + + [gdbsupport] Use std::span-style iterators for gdb::array_view + There's a plan to replace gdb::array_view with std::span (PR31422), and making + gdb::array_view more like std::span helps with that. + + One difference is that std::span has: + ... + constexpr iterator begin() const noexcept; + constexpr const_iterator cbegin() const noexcept; + ... + while gdb::array_view has: + ... + constexpr T *begin () noexcept; + constexpr const T *begin () const noexcept; + ... + + Fix this by renaming the second variant to cbegin, and making the first + variant const. + + Likewise for gdb::array_view::end. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-19 Tom de Vries + + [gdb/guile, c++20] Work around Werror=volatile in libguile.h + When building gdb with -std=c++20, I run into: + ... + In file included from /usr/include/guile/2.0/libguile/__scm.h:479, + from /usr/include/guile/2.0/libguile.h:31, + from /data/vries/gdb/src/gdb/guile/guile-internal.h:30, + from /data/vries/gdb/src/gdb/guile/guile.c:37: + /usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \ + scm_cell(scm_t_bits, scm_t_bits)’: + /usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \ + assignment with ‘volatile’-qualified left operand is deprecated \ + [-Werror=volatile] + 98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x)) + | ~~~~~~~~~~~~~~~~~~~^~~~~ + ... + + This was reported upstream [1]. + + Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the + default SCM_DEBUG_TYPING_STRICTNESS == 1. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR guile/30767 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767 + + [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333 + +2024-10-19 Tom de Vries + + [gdb/symtab] Skip local variables in cooked index + Consider test-case gdb.dwarf2/local-var.exp. The corresponding source + contains a function with a local variable: + ... + program test + logical :: local_var + local_var = .TRUE. + end + ... + + Currently, the local variable shows up in the cooked index: + ... + [2] ((cooked_index_entry *) 0xfffec40063b0) + name: local_var + canonical: local_var + qualified: local_var + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0xa3 + parent: ((cooked_index_entry *) 0xfffec4006380) [test] + ... + making the cooked index larger than necessary. + + Fix this by skipping it in cooked_indexer::index_dies. + + Tested on aarch64-linux. + + PR symtab/32276 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276 + +2024-10-19 GDB Administrator + + Automatic date update in version.in + +2024-10-18 Tom Tromey + + Require a command argument in gdb.execute_mi + Hannes pointed out that gdb.execute_mi() will crash. + This patch fixes the bug. + + Reviewed-By: Guinevere Larsen + +2024-10-18 MayShao-oc + + x86: Regenerate missing table files + As soon as I committed Zhaoxin's patch, I realized that I did not + include the regen file. Regenerate them and commit as obvious. + + opcodes/ChangeLog: + + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2024-10-18 MayShao-oc + + x86: Support x86 ZHAOXIN GMI instructions + gas/ChangeLog: + + * NEWS: Support ZHAOXIN GMI instructions. + * config/tc-i386.c: Add gmi. + * doc/c-i386.texi: Document gmi. + * testsuite/gas/i386/i386.exp: Add gmi test. + * testsuite/gas/i386/gmi.d: Ditto. + * testsuite/gas/i386/gmi.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: New comment. + * i386-gen.c: Add gmi. + * i386-opc.h (CpuGMI): New. + * i386-opc.tbl: Add Zhaoxin GMI instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2024-10-18 Ruud van der Pas + + gprofng: fix a memory leak in the mxv-pthreads example + Fix a bug where the main program does not free the rows of + the matrix. The memory for thread_data_arguments is also + not released. In function check_results, the memory for the + marker vector is not released. + The usage of the verbose veriable has been extended to + print more messages. + + gprofng/ChangeLog + 2024-10-16 Ruud van der Pas + + PR 32273 + PR 32274 + * mxv-pthreads/src/main.c: add calls to free() to + release the memory allocated for array A and vector + marker. Improve the usage of the verbose variable. + * mxv-pthreads/src/manage_data.c: add a diagnostic + printf statement. + * mxv-pthreads/src/mydefs.h: adapt prototype to + match the changes in main.c. + +2024-10-18 GDB Administrator + + Automatic date update in version.in + +2024-10-17 Tom de Vries + + [gdb] Handle bad alloc handling in gdb_bfd_open + Say we simulate a bad alloc in gdb_bfd_init_data: + ... + + { + + static bool throw_bad_alloc = true; + + if (throw_bad_alloc) + + { + + throw_bad_alloc = false; + + + + va_list dummy; + + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + + } + + } + gdata = new gdb_bfd_data (abfd, st); + ... + + That works out fine for doing "file a.out" once: + ... + $ gdb -q -batch -ex "file a.out" + bad alloc + $ + ... + but doing so twice get us: + ... + $ gdb -q -batch -ex "file a.out" -ex "file a.out" + bad alloc + + Fatal signal: Segmentation fault + ----- Backtrace ----- + 0x5183f7 gdb_internal_backtrace_1 + /home/vries/gdb/src/gdb/bt-utils.c:121 + 0x5183f7 _Z22gdb_internal_backtracev + /home/vries/gdb/src/gdb/bt-utils.c:167 + 0x62329b handle_fatal_signal + /home/vries/gdb/src/gdb/event-top.c:917 + 0x6233ef handle_sigsegv + /home/vries/gdb/src/gdb/event-top.c:990 + 0xfffeffba483f ??? + 0x65554c eq_bfd + /home/vries/gdb/src/gdb/gdb_bfd.c:231 + 0xeaca77 htab_find_with_hash + /home/vries/gdb/src/libiberty/hashtab.c:597 + 0x657487 _Z12gdb_bfd_openPKcS0_ib + /home/vries/gdb/src/gdb/gdb_bfd.c:580 + 0x6272d7 _Z16exec_file_attachPKci + /home/vries/gdb/src/gdb/exec.c:451 + 0x627e67 exec_file_command + /home/vries/gdb/src/gdb/exec.c:550 + 0x627f23 file_command + /home/vries/gdb/src/gdb/exec.c:565 + Segmentation fault (core dumped) + $ + ... + + The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache: + ... + if (bfd_sharing) + { + slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT); + gdb_assert (!*slot); + *slot = abfd; + } + + gdb_bfd_init_data (abfd, &st); + ... + while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is + not properly initialized. + + Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after + a successful call to gdb_bfd_init_data, such that we get: + ... + $ gdb -q -batch -ex "file a.out" -ex "file a.out" + bad alloc + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-17 Tom de Vries + + [gdb/build] Use -fno-hoist-adjacent-loads for gcc <= 13 + When building gdb with gcc 12 and -fsanitize=threads while renabling + background dwarf reading by setting dwarf_synchronous to false, I run into: + ... + (gdb) file amd64-watchpoint-downgrade + Reading symbols from amd64-watchpoint-downgrade... + (gdb) watch global_var + ================== + WARNING: ThreadSanitizer: data race (pid=20124) + Read of size 8 at 0x7b80000500d8 by main thread: + #0 cooked_index_entry::full_name(obstack*, bool) const cooked-index.c:220 + #1 cooked_index::get_main_name(obstack*, language*) const cooked-index.c:735 + #2 cooked_index_worker::wait(cooked_state, bool) cooked-index.c:559 + #3 cooked_index::wait(cooked_state, bool) cooked-index.c:631 + #4 cooked_index_functions::wait(objfile*, bool) cooked-index.h:729 + #5 cooked_index_functions::compute_main_name(objfile*) cooked-index.h:806 + #6 objfile::compute_main_name() symfile-debug.c:461 + #7 find_main_name symtab.c:6503 + #8 main_language() symtab.c:6608 + #9 set_initial_language_callback symfile.c:1634 + #10 get_current_language() language.c:96 + ... + + Previous write of size 8 at 0x7b80000500d8 by thread T1: + #0 cooked_index_shard::finalize(parent_map_map const*) \ + dwarf2/cooked-index.c:409 + #1 operator() cooked-index.c:663 + ... + + ... + + SUMMARY: ThreadSanitizer: data race cooked-index.c:220 in \ + cooked_index_entry::full_name(obstack*, bool) const + ================== + Hardware watchpoint 1: global_var + (gdb) PASS: gdb.arch/amd64-watchpoint-downgrade.exp: watch global_var + ... + + This was also reported in PR31715. + + This is due do gcc PR110799 [1], generating wrong code with + -fhoist-adjacent-loads, and causing a false positive for + -fsanitize=threads. + + Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13 + and -fsanitize=threads. + + Tested in that same configuration on x86_64-linux. Remaining ThreadSanitizer + problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and + PR32247 (gdb.trace/basic-libipa.exp). + + PR gdb/31715 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31715 + + Tested-By: Bernd Edlinger + Approved-By: Tom Tromey + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799 + +2024-10-17 Tom de Vries + + [gdb/symtab] Fix qualified name for cooked index dump + While looking at the cooked index entry for local variable l4 of function test + in test-case gdb.fortran/logical.exp: + ... + $ gdb -q -batch outputs/gdb.fortran/logical/logical \ + -ex "maint print objfiles" + ... + [9] ((cooked_index_entry *) 0x7fc6e0003010) + name: l4 + canonical: l4 + qualified: l4 + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0x17c + parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test] + ... + I noticed that while the entry does have a parent, that's not reflected in the + qualified name. + + This makes it harder to write test-cases that check the parent of a cooked + index entry. + + This is due to the implementation of full_name, which skips printing + parents if the language does not specify an appropriate separator. + + Fix this by using "::" as default separator, getting us instead: + ... + [9] ((cooked_index_entry *) 0x7f94ec0040c0) + name: l4 + canonical: l4 + qualified: test::l4 + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0x17c + parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test] + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-10-17 Vladimir Mezentsev + + gprofng: fix regression in man page installation + gprofng/ChangeLog + 2024-10-14 Vladimir Mezentsev + + * doc/Makefile.am: Use install-data-local to install gprofng examples. + * doc/Makefile.in: Rebuild. + +2024-10-17 Michael Matz + + Fix for -Wstringop-overflow false positive + the way the overflow check was written wasn't understood by some + GCC versions and produced false positives for the memset call being + called potentially with object sizes that are larger than half + address-space. + +2024-10-17 Michael Matz + + PR32260: Improve error handling on string merging + if the input sections are near the max supported size (4G) + we might fail to enlarge the hash table. The error handling + for this case didn't quite work. When this happens we can + gracefully fall back to just not deduplicate this section + (and continue with further mergable sections). We were mixing + that with the case of not being able to even allocate a small + structure (in which case we can as well error out completely), + this disentables both cases. + + bfd/ + + PR ld/32260 + * merge.c (sec_merge_maybe_resize): Check overflow in ultimate + target type. + (record_section): Return three-state, use new state when unable + to enlarge hash table. + (_bfd_merge_sections): Remove current section from merging + consideration when hashtable can't be enlarged. + +2024-10-17 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/fixed_points.exp for gcc < 10 + When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run + into: + ... + (gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1 + get_compiler_info: gcc-7-5-0 + p Float(Another_Fixed) = Float(Another_Delta * 5)^M + No definition of "another_delta" in current context.^M + (gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed + ... + + This is a regression since commit 1411185a57e ("Introduce and use + gnat_version_compare"), which did: + ... + # This failed before GCC 10. + - if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} { + + if {$scenario == "all" && [gnat_version_compare < 10]} { + gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \ + "value of another_fixed" + } + ... + + Fix this by using gnat_version_compare >= 10 instead. + + Tested on x86_64-linux, with gcc 7 - 13. + +2024-10-17 Lulu Cai + + LoongArch: Check PC-relative relocations for shared libraries + Building shared libraries should not be allowed for PC-relative + relocations against external symbols. + Currently LoongArch has no corresponding checks and silently + generates wrong shared libraries. + + However, In the first version of the medium cmodel, pcalau12i+jirl was + used for function calls, in which case PC-relative relocations were + allowed. + +2024-10-17 kamathforaix + + Add myself to gdb/MAINTAINERS + +2024-10-17 GDB Administrator + + Automatic date update in version.in + +2024-10-16 Andreas Schwab + + gprofng: use xmalloc/xrealloc/xcalloc/xstrdup/xstrndup from libiberty + PR gprofng/32241 + * src/Makefile.am (CSOURCES): Remove dbe_memmgr.c + * src/Makefile.in: Regenerate. + * src/dbe_memmgr.c: Remove. + * src/gprofng.cc (main): Call xmalloc_set_program_name. + * src/gp-archive.cc (main): Likewise. + * src/gp-collect-app.cc (main): Likewise. + * src/gp-display-src.cc (main): Likewise. + * src/gp-display-text.cc (main): Likewise. + * src/Application.cc: Use xmalloc, xrealloc, xcalloc, xstrdup, + xstrndup instead of malloc, realloc, calloc, strdup, strndup. + * src/BaseMetric.cc: Likewise. + * src/CallStack.cc: Likewise. + * src/ClassFile.cc: Likewise. + * src/Data_window.cc: Likewise. + * src/Dbe.cc: Likewise. + * src/DbeJarFile.cc: Likewise. + * src/DbeSession.cc: Likewise. + * src/DbeView.cc: Likewise. + * src/DerivedMetrics.cc: Likewise. + * src/DwarfLib.cc: Likewise. + * src/Elf.cc: Likewise. + * src/Emsg.cc: Likewise. + * src/Experiment.cc: Likewise. + * src/Function.cc: Likewise. + * src/Module.cc: Likewise. + * src/Print.cc: Likewise. + * src/QLParser.yy: Likewise. + * src/SAXParserFactory.cc: Likewise. + * src/Settings.cc: Likewise. + * src/SourceFile.cc: Likewise. + * src/StringBuilder.cc: Likewise. + * src/StringMap.h: Likewise. + * src/Table.cc: Likewise. + * src/checks.cc: Likewise. + * src/collctrl.cc: Likewise. + * src/comp_com.c: Likewise. + * src/count.cc: Likewise. + * src/envsets.cc: Likewise. + * src/gp-archive.cc: Likewise. + * src/gp-display-src.cc: Likewise. + * src/gp-display-text.cc: Likewise. + * src/gprofng.cc: Likewise. + * src/ipc.cc: Likewise. + * src/ipcio.cc: Likewise. + * src/vec.h: Likewise. + * src/util.cc: Likewise. + (get_prog_name): Remove. + * src/util.h: Likewise. + * src/dbe_hwc.h (malloc, realloc, calloc, strdup): Define. + +2024-10-16 Alan Modra + + Assertion fail at peicode.h:607 + This is the assertion that vars->string_ptr < vars->end_string_ptr, + ie. when it fails we've overflowed the string buffer area. Caused by + allocating space for import_name but writing symbol_name, and they can + be different. + + * peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change. + +2024-10-16 Alan Modra + + Add noxfail option to run_dump_test + The noxfail option is useful in situations like pr23658-1e which + fails on all microblaze ELF targets except microblaze-linux. This was + possible to handle by writing a small proc and use that as an xfail + predicate, or painstakingly listing all microblaze ELF targets, but + this is simpler. The patch also fixes some other FAILs and XPASSes of + the pr23658 tests. + + binutils/ + * testsuite/lib/binutils-common.exp (run_dump_test): Support + noxfail. + ld/ + * testsuite/ld-elf/pr23658-1a.d: Don't xfail m68hc12. + * testsuite/ld-elf/pr23658-1e.d: Likewise. xfail xstormy16 + and correct microblaze xfails. + +2024-10-16 Alan Modra + + PR32266, segv when linking libclang_rt.asan-powerpc64.so + Change the mmap support added with commit 9ba56acee518 to always mmap + memory with PROT_READ | PROT_WRITE. Prior to that commit most file + contents were read into a buffer allocated with bfd_alloc or + bfd_malloc and thus the memory was read/write. Even after that commit + any section contents with relocations must be read/write to apply the + relocs. Making them all read/write is not a major change, and it + should not introduce any measurable linker slowdown for contents that + are not modified. More importantly, it removes a BFD behaviour + difference that only triggers when large files are involved. + + PR 32266 + PR 32109 + * libbfd.c (bfd_mmap_local): Remove prot param. Always mmap + with PROT_READ | PROT_WRITE. Adjust all calls. + (_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary. + (_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary. + _bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent. + (_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE + regardless of relocs. + * libbfd-in.h: Update decls to suit. Make non-USE_MMAP variants + static inline functions. + * elflink.c: Update all uses of _bfd_mmap functions. + * elf.c: Likewise. + (bfd_elf_get_str_section): Revert commit 656f8fbaae. + * libbfd.h: Regenerate. + +2024-10-16 Liwei Xu + Kong Lingling + Haochen Jiang + + Support Intel AVX10.2 convert instructions + In this patch, we will support AVX10.2 convert instructions. All + of them are new instruction forms. + + Among all the instructions, vcvtbiasph2[b,h]f8[,s] needs extra care. + Since Operand 2 could indicate memory size, we do not need suffix + under ATTmode. However, we could not fold all three templates but only + XMM/YMM since the dst operand size are the same for them. Also, a new + iterator is added to reduce redundancy. + + gas/ + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt-intel.d: New. + * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto. + + opcodes/ + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F3874, + PREFIX_EVEX_MAP5_18, PREFIX_EVEX_MAP5_1B, + PREFIX_EVEX_MAP5_1E and PREFIX_EVEX_MAP5_74. + * i386-dis-evex.h: Add table pass for AVX10.2 + instructions. + * i386-dis.c (MOD_EVEX_0F38B1): New. + (PREFIX_EVEX_0F3874): Ditto. + (PREFIX_EVEX_MAP5_18): Ditto. + (PREFIX_EVEX_MAP5_1B): Ditto. + (PREFIX_EVEX_MAP5_1E): Ditto. + (PREFIX_EVEX_MAP5_74): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-10-16 GDB Administrator + + Automatic date update in version.in + +2024-10-15 Tom Tromey + + Introduce and use gnat_version_compare + While testing a modified GNAT, I found that this test in + fun_renaming.exp was returning 0 for GCC 13: + + if {[test_compiler_info {gcc-6*}]} + + This patch introduces a new, more robust way to check the GNAT + compiler version, and changes the gda.ada tests to use it. A small + update to version_compare was also needed. + + Note that, in its current form, this new code won't really interact + well with non-GCC compilers (specifically gnat-llvm). This doesn't + seem like a major issue at this point, though, because gnat-llvm + doesn't properly emit debuginfo yet, and when it does, more changes + will be needed in these tests anyway. + + Reviewed-by: Keith Seitz + +2024-10-15 mengqinggang + + LoongArch: Add more relaxation support for call36 + Add relaxation support for call36 that jump to PLT entry. + + Add relaxation support for call36 with IFUNC symbol. + + Add relaxation support for call36 that jump to undefweak symbol. + For undefweak symbol, it can always be relaxed if it have no PLT entry. + Because we set the address of undefweak symbol without PLT entry to PC + like relocate_section. + +2024-10-15 mengqinggang + + LoongArch: Optimize the relaxation process + The symbol value is only calculated when the relocation can be relaxed. + +2024-10-15 Cui, Lili + + x86: Refine instruction check in x86_check_tls_relocation + gas/ChangeLog: + + * config/tc-i386.c + (x86_check_tls_relocation): Refine instruction check. + +2024-10-15 Haochen Jiang + + x86/testsuite: Rename AVX10.2 media testcases + Change these testcase name to make them clearer. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-1-intel.d: Renamed to... + * testsuite/gas/i386/avx10_2-256-media-intel.d: ...this. + * testsuite/gas/i386/avx10_2-256-1.d: Renamed to... + * testsuite/gas/i386/avx10_2-256-media.d: ...this. + * testsuite/gas/i386/avx10_2-256-1.s: Renamed to... + * testsuite/gas/i386/avx10_2-256-media.s: ...this. + * testsuite/gas/i386/avx10_2-512-1-intel.d: Renamed to... + * testsuite/gas/i386/avx10_2-512-media-intel.d: ...this. + * testsuite/gas/i386/avx10_2-512-1.d: Renamed to... + * testsuite/gas/i386/avx10_2-512-media.d: ...this. + * testsuite/gas/i386/avx10_2-512-1.s: Renamed to... + * testsuite/gas/i386/avx10_2-512-media.s: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media-intel.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1.s: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media.s: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media-intel.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1.s: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media.s: ...this. + * testsuite/gas/i386/i386.exp: Change testcase name. + * testsuite/gas/i386/x86-64.exp: Ditto. + +2024-10-15 GDB Administrator + + Automatic date update in version.in + +2024-10-14 Guinevere Larsen + + gdb/testsuite: fix gdb.multi/inferior-specific-bp.exp + A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations + calls in update_breakpoint_locations", started checking if GDB correctly + relocates a breakpoint from inferior 1's declaration of the function + "bar" to inferior 2's declaration. + + Unfortunately, inferior 2 never calls bar in its regular execution, and + because of that, clang would optimize that whole function away, making + it so there is no location for the breakpoint to be relocated to. + + This commit changes the .c file so that the function is not optimized + away and the test fully passes with clang. It is important to actually + call bar instead of using __attribute__((used)) because the latter + causes the breakpoint locations to be inverted, 3.1 belongs to inferior + 2 and 3.2 belongs to inferior 1, which will cause an unrelated failure. + + Approved-By: Andrew Burgess + +2024-10-14 Jan Beulich + + ia64/ELF: fix HPUX testsuite fallout + ... from 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object + files"), as noticed / reported by Alan. + + x86: also template-expand trailing mnemonic part + So far template expansion was limited to fields other than the insn + mnemonic. In order to be able to use also for AVX10.2 we want the + trailing mnemonic part to also be expanded. Split out the respective + piece of code into a helper function, which is then invoked twice. + + gas: drop SKIP_WHITESPACE_AFTER_NAME() + Exclusively all users should use restore_line_pointer() instead, at + which point SKIP_WHITESPACE() suffices as a check afterwards. + +2024-10-14 Guinevere Larsen + + gdb: make frame_unwind_try_unwinder return bool + Before this commit, the function frame_unwind_try_unwinder would return + an int, where 1 meant the unwinder works, and 0 it doesn't. This is just + a boolean with extra steps, so this commit updates the function to + return bool instead. + +2024-10-14 Lulu Cai + + LoongArch: Fixed R_LARCH_[32/64]_PCREL generation bug + The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead + of the relocation in fixp. This can cause the second relocation + of a pair to be deleted when -mthin-add-sub is enabled. Apply the + correct macro to fix this. + + Also sets the initial value of -mthin-add-sub. + +2024-10-14 GDB Administrator + + Automatic date update in version.in + +2024-10-13 Vladimir Mezentsev + + Fix 32110 gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary + gprofng does not handle DW_FORM_strx1* forms correctly. + + gprofng/ChangeLog + 2024-10-10 Vladimir Mezentsev + + PR 32110 + * src/DwarfLib.cc: Handle DW_FORM_strx* forms. + +2024-10-13 GDB Administrator + + Automatic date update in version.in + +2024-10-12 Robert Guthrie (tiny change) + + Add to GDB manual information about building index with 'gold' + * gdb/doc/gdb.texinfo (Index Files): New subsection about building + the index using 'gold'. + +2024-10-12 GDB Administrator + + Automatic date update in version.in + +2024-10-11 Andrew Burgess + + gdbserver: remove declaration of init_registers_arm_with_neon + The last use of init_registers_arm_with_neon was removed in this + commit: + + commit 7cc17433020a62935e4d91053251fe900d83c7f0 + Date: Fri Jul 19 15:04:48 2019 +0100 + + Arm: Use read_description funcs in gdbserver + + But the declaration was left around. Remove the declaration now. + +2024-10-11 Andrew Burgess + + Revert "gdbserver: pass osabi to GDB in target description" + This reverts commit 98bcde5e268ea7cd54186c5f2c27c65103218fc3. This + commit was causing build problems on at least sparc, ppc, and s390, + though I suspect some other targets might be impacted too. + +2024-10-11 Jan Beulich + + x86: bring 64-bit-only cmdline option handling in sync + --64 and --x32 are already suppressed in --help output when BFD64 is not + defined. Also avoid recognizing these options in such configurations. + + bfd/ELF: drop align_file_position() + Switch the sole user to BFD_ALIGN() instead. (It's comment was partly + wrong [stale?] anyway, talking of some maximum that was nowhere in + sight.) + + bfd/ELF: restrict file alignment for object files + While for executables properly aligning sections within the file can be + quite relevant, the same is of pretty little importance for relocatable + object files. Avoid passing "true" into + _bfd_elf_assign_file_position_for_section() when dealing with object + files, but compensate minimally by applying log_file_align in such + cases as a cap to the alignment put in place. + +2024-10-11 Haochen Jiang + Lili Cui + + Support Intel AVX10.2 media instructions + In disassembler part, for vnni instructions, we extended previous + VEX part using %XE in disassembler to promote them to EVEX by reusing + the original VEX table. For vmpsadbw, we will also use %XE. However, + it is hard to reuse the VEX table, so we are using new ones. + + In assmbler part, we put the vnni table entries with previous vnni + instructions since they are just promotion from AVX-VNNI-INT{8,16}. + Since we will prefer VEX encoding, we need to use the different table + order in template , which prefers EVEX due to earlier introduction + for AVX512_VNNI than AVX_VNNI. This means a new . For vdpphps + and vmpsadbw, we put them at the end of the table, with future AVX10.2 + instructions. + + Nit: I will remove the arch requirement for avx_vnni_int{8,16} in + evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}. + + gas/Changelog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-1-intel.d: New. + * testsuite/gas/i386/avx10_2-256-1.d: Ditto. + * testsuite/gas/i386/avx10_2-256-1.s: Ditto. + * testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-1.d: Ditto. + * testsuite/gas/i386/avx10_2-512-1.s: Ditto. + * testsuite/gas/i386/avx10_2-promote.d: Ditto. + * testsuite/gas/i386/avx10_2-promote.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto. + + opcodes/Changelog: + + * i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852. + Add PREFIX_EVEX_0F3A42_W_0. + * i386-dis-evex-w.h: Adjust EVEX_W_0F3A42. + * i386-dis-evex.h: Add table pass for AVX10.2 + instructions. + * i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0, + PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-10-11 GDB Administrator + + Automatic date update in version.in + +2024-10-10 H.J. Lu + + gprofng: Use $(DESTDIR) in install-examples + Use $(DESTDIR) in install-examples to fix + + mkdir -p -- /usr/share/doc//gprofng + mkdir: cannot create directory ‘/usr/share/doc//gprofng’: Permission denied + + for "make install DESTDIR=...". + + * doc/Makefile.am (install-examples): Use $(DESTDIR). + * doc/Makefile.in: Regenerated. + +2024-10-10 Vladimir Mezentsev + + gprofng: install examples to $(docdir)/gprofng + gprofng/ChangeLog + 2024-10-09 Vladimir Mezentsev + + * doc/Makefile.am: Install gprofng examples. + * doc/Makefile.in: Rebuild. + +2024-10-10 Andrew Burgess + + gdbserver: pass osabi to GDB in target description + On a Windows machine I built gdbserver, configured for the target + 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with + support for all target (--enable-targets=all). + + On the Windows machine I start gdbserver with a small test binary: + + $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe + + On the GNU/Linux machine I start GDB without the test binary, and + connect to gdbserver. + + As I have not given GDB the test binary, my expectation is that GDB + would connect to gdbserver and then download the file over the remote + protocol, but instead I was presented with this message: + + (gdb) target remote 192.168.129.25:54321 + Remote debugging using 192.168.129.25:54321 + warning: C:\some\directory\executable.exe: No such file or directory. + 0x00007ffa3e1e1741 in ?? () + (gdb) + + What I found is that if I told GDB where to find the binary, like + this: + + (gdb) file target:C:/some/directory/executable.exe + A program is being debugged already. + Are you sure you want to change the file? (y or n) y + Reading C:/some/directory/executable.exe from remote target... + warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. + Reading C:/some/directory/executable.exe from remote target... + Reading symbols from target:C:/some/directory/executable.exe... + (gdb) + + then GDB would download the executable. + + I eventually tracked the problem down to exec_file_find (solib.c). + The remote target was passing an absolute Windows filename (beginning + with "C:/" in this case), but in exec_file_find GDB was failing the + IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as + relative. + + The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that + the file system kind was "unix", and as the filename didn't start with + a "/" it assumed the filename was not absolute. + + But I'm connecting to a Windows target, my 'target-file-system-kind' + was set to "auto", so should be figuring out that my file-system is + "dos-based". + + Looking in effective_target_file_system_kind (filesystem.c), we find + that the logic of "auto" is delegated to the current gdbarch. However + in windows-tdep.c we see: + + set_gdbarch_has_dos_based_file_system (gdbarch, 1); + + So if we are using a Windows gdbarch we should have "dos-based" + filesystems. What this means is that after connecting to the remote + target GDB has selected the wrong gdbarch. + + What's happening is that the target description sent back by the + remote target only includes the x86-64 registers. There's no + information about which OS we're on. As a consequence, GDB picks the + first x86-64 gdbarch which can handle the provided register set, which + happens to be a GNU/Linux gdbarch. + + And indeed, there doesn't appear to be anywhere in gdbserver that sets + the osabi on the target descriptions, though some target descriptions + do have their osabi set when the description is created, e.g. in: + + gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. + gdb/arch/i386.c - Likewise. + gdb/arch/tic6x.c - Always set GNU/Linux osabi. + + Most target descriptions are created without an osabi, gdbserver does + nothing to fix this, and the description is returned to GDB without an + osabi included. + + I propose that we always set the osabi name on the target descriptions + returned from gdbserver. We could try to do this when the description + is first created, but that would mean passing extra flags into the + tdesc creation code (or just passing the osabi string in), and I don't + think that's really necessary. If we consider the tdesc creation as + being about figuring out which registers are on the target, then it + makes sense that the osabi information is injected later. + + So what I've done is require the osabi name to be passed to the + init_target_desc function. This is called, I believe, for all + targets, in the gdbserver code. + + Now when I connect to the Windows remote the target description + returned includes the osabi name. With this extra information GDB + selects the correct gdbarch object, which means that GDB understands + the target has a "dos-based" file-system. With that correct GDB + understands that the filename it was given is absolute, and so fetches + the file from the remote as we'd like. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb/gdbserver: change shared set_tdesc_osabi to take gdb_osabi + There is a single declaration of set_tdesc_osabi that is shared + between gdbserver/ and gdb/, this declaration takes a 'const char *' + argument which is the string representing an osabi. + + Then in gdb/ we have an overload of set_tdesc_osabi which takes an + 'enum gdb_osabi'. + + In this commit I change the shared set_tdesc_osabi to be the version + which takes an 'enum gdb_osabi', and I remove the version which takes + a 'const char *'. All users of set_tdesc_osabi are updated to pass an + 'enum gdb_osabi'. + + The features/ code, which is generated from the xml files, requires a + new function to be added to osabi.{c,h} which can return a string + representation of an 'enum gdb_osabi'. With that new function in + place the features/ code is regenerated. + + This change is being made to support the next commit. In the next + commit gdbserver will be updated to call set_tdesc_osabi in more + cases. The problem is that gdbserver stores the osabi as a string. + The issue here is that a typo in the gdbserver/ code might go + unnoticed and result in gdbserver sending back an invalid osabi + string. + + To fix this we want gdbserver to pass an 'enum gdb_osabi' to the + set_tdesc_osabi function. With that requirement in place it seems to + make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'. + + There should be no user visible changes after this commit. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb: split osabi support between gdb/ and gdbsupport/ directories + In future commits I want to call set_tdesc_osabi from gdbserver/ + code. Currently the only version of set_tdesc_osabi available to + gdbserver takes a string representing the osabi. + + The problem with this is that, having lots of calls to set_tdesc_osabi + which all take a string is an invite for a typo to slip in. This typo + could potentially go unnoticed until someone tries to debug the wrong + combination of GDB and gdbserver, at which point GDB will fail to find + the correct gdbarch because it doesn't understand the osabi string. + + It would be better if the set_tdesc_osabi calls in gdbserver could + take an 'enum gdb_osabi' value and then convert this to the "correct" + string internally. In this way we are guaranteed to always have a + valid, known, osabi string. + + This commit splits the osabi related code, which currently lives + entirely on the GDB side, between gdb/ and gdbsupport/. I've moved + the enum definition along with the array of osabi names into + gdbsupport/. Then all the functions that access the names list, and + which convert between names and enum values are also moved. + + I've taken the opportunity of this move to add a '.def' file which + contains all the enum names along with the name strings. This '.def' + file is then used to create 'enum gdb_osabi' as well as the array of + osabi name strings. By using a '.def' file we know that the enum + order will always match the name string array. + + This commit is just a refactor, there are no user visible changes + after this commit. This commit doesn't change how gdbserver sets the + target description osabi string, that will come in the next commit. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb: make use of set_tdesc_osabi overload in features/ files + There are two versions of the set_tdesc_osabi function in GDB: + + void + set_tdesc_osabi (struct target_desc *target_desc, const char *name) + { + set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name)); + } + + void + set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi) + { + target_desc->osabi = osabi; + } + + In the gdb/features/ files we call the second of these functions, like + this: + + set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux")); + + This can be replaced with a call to the first set_tdesc_osabi + function, so lets do that. I think that this makes the features/ code + slightly simpler and easier to understand. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr + Convert target_desc::arch and target_desc::osabi from 'const char*' to + gdb::unique_xmalloc_ptr. This also allows us to remove the user + defined ~target_desc destructor. + + I doubt it ever actually occurred, but in theory at least, there was a + memory leak in set_tdesc_architecture and set_tdesc_osabi where the + member variables were assigned without freeing any previous + value... but I suspect that usually these fields are only set once. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + Approved-By: Simon Marchi + +2024-10-10 Tom de Vries + + [gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linux + On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into: + ... + (gdb) awatch a^M + Can't set read/access watchpoint when hardware watchpoints are disabled.^M + (gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint + rwatch b^M + Can't set read/access watchpoint when hardware watchpoints are disabled.^M + (gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint + continue^M + Continuing.^M + ^M + Program received signal SIGSEGV, Segmentation fault.^M + 0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: $exp: continue until exit + ... + + Using "maint info break", we can see that the two failed attempts to set a + watchpoint each left behind a stale "watchpoint scope" breakpoint: + ... + -5 watchpoint scope del y 0xf7ec569a inf 1 + -5.1 y 0xf7ec569a inf 1 + stop only in stack frame at 0xfffef4f8 + -6 watchpoint scope del y 0xf7ec569a inf 1 + -6.1 y 0xf7ec569a inf 1 + stop only in stack frame at 0xfffef4f8 + ... + + The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the + same happens if we: + - have can-use-hw-watchpoints == 1, + - set one of the watchpoints, and + - continue to exit. + The problem is missing symbol info on libc which is supposed to tell which + code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV + disappears. + + Extend the test-case to check the "maint info break" command before and after + the two failed attempts, to make sure that we catch the stale + "watchpoint scope" breakpoints also on x86_64-linux. + + Fix this in watch_command_1 by moving creation of the "watchpoint scope" + breakpoint after the call to update_watchpoint. + + Tested on x86_64-linux. + + PR breakpoints/31860 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860 + +2024-10-10 Andreas Krebbel + + s390: Add arch15 instructions + opcodes/ + * s390-mkopc.c (main) Accept arch15 as CPU string. + * s390-opc.txt: Add arch15 instructions. + + include/ + * opcode/s390.h (enum s390_opcode_cpu_val): Add + S390_OPCODE_ARCH15. + + gas/ + * config/tc-s390.c (s390_parse_cpu): New entry for arch15. + * doc/c-s390.texi: Document arch15 march option. + * doc/as.texi: Likewise. + * testsuite/gas/s390/s390.exp: Run the arch15 related tests. + * testsuite/gas/s390/zarch-arch15.d: Tests for arch15 + instructions. + * testsuite/gas/s390/zarch-arch15.s: Likewise. + + Reviewed-by: Jens Remus + +2024-10-10 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clang + When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: + ... + FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 + FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent + FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 + ... + + The problem is that the debug info produced by clang does not contain any + references to enumerators val1 and val2, or the corresponding enumeration + types. + + Instead, the variables u1 and u2 are considered to be simply of type int: + ... + <1>: Abbrev Number: 2 (DW_TAG_variable) + DW_AT_name : u1 + DW_AT_type : <0x106> + <101> DW_AT_external : 1 + <103> DW_AT_location : (DW_OP_addrx <0>) + <1><106>: Abbrev Number: 3 (DW_TAG_base_type) + <107> DW_AT_name : int + <108> DW_AT_encoding : 5 (signed) + <109> DW_AT_byte_size : 4 + <1><10a>: Abbrev Number: 2 (DW_TAG_variable) + <10b> DW_AT_name : u2 + <10c> DW_AT_type : <0x106> + <110> DW_AT_external : 1 + <112> DW_AT_location : (DW_OP_addrx <0x1>) + ... + + Fix this by checking whether val1 and val2 are present in the cooked index + before checking whether they have the correct parent. + + This cannot be expressed efficiently with gdb_test_lines, so factor out + gdb_get_lines and use that instead. + + The test-case still calls "maint print objfiles" twice, but the first time is + for have_index. We should probably use a gdb_caching_proc for this. + + Tested on aarch64-linux. + + Reported-By: Guinevere Larsen + Reviewed-By: Keith Seitz + Tested-By: Guinevere Larsen + +2024-10-10 Tom de Vries + + [gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1 + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. + + Tested on x86_64-linux. + +2024-10-10 GDB Administrator + + Automatic date update in version.in + +2024-10-09 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1 + On aarch64-linux, with make target check-read1, I run into: + ... + (gdb) info reg vector^M + ... + d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout) + 0, u = 0, s = 0}^M + ... + + The problem is that while (as documented) the corresponding gdb_test_multiple + doesn't work for vector registers, it doesn't skip them either. This causes + the timeout, and it also causes the registers after a vector register not to + be found. + + Fix this by using -lbl style matching. + + Make which reggroups and registers are found more explicit using verbose -log, + which makes us notice that regnames with underscores are skipped, so fix that + as well. + + While we're at it, this: + ... + set invalid_register_re "Invalid register .*" + ... + and this: + ... + -re $invalid_register_re { + fail "$test (unexpected invalid register response)" + } + ... + means that the prompt may or may not be consumed. Fix this by limiting the + regexp to one line, and using exp_continue. + + While we're at it, improve readability of the complex regexp matching a single + register by factoring out regexps. + + Tested on aarch64-linux and x86_64-linux. + +2024-10-09 Alan Modra + + PR32243, NAME_MAX does not exist on mingw-w64 without _POSIX_ + PR 32243 + * dlltool.c: Move forward decls. Delete unnecessary ones. + (bfd_errmsg): Delete macro, define as inline function. + (PATHMAX): Delete. + (NAME_MAX): Define. + +2024-10-09 GDB Administrator + + Automatic date update in version.in + +2024-10-09 Tom Tromey + + Use ui-out tables in "maint print user-regs" + This changes "maint print user-regs" to use ui-out tables rather than + printfs. + + Approved-By: Andrew Burgess + +2024-10-09 Tom Tromey + + Use ui-out tables for info proc mappings + This changes a few implementations of "info proc mappings" to use + ui-out tables rather than printf. + + Note that NetBSD and FreeBSD also use printfs here, but since I can't + test these, I didn't update them. + + Approved-By: Andrew Burgess + +2024-10-08 Tom de Vries + + [gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1 + When running test-case gdb.base/break-interp.exp with check-read1, I run into: + ... + (gdb) info files^M + ... + 0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout) + pieNO.d/libc.so.6^M + ... + + The code has two adaptations to deal with the large output: + - nested gdb_test_multiple, and + - an exp_continue in the inner gdb_test_multiple. + + The former seems unnecessary, and the latter doesn't trigger often enough + because of an incomplete hex number regexp, causing the timeout. + + Get rid of both of these, and use -lbl instead. + + Tested on x86_64-linux. + +2024-10-08 Andrew Burgess + + gdb: include --enable-targets in 'show configuration' output + Include the value of configuration flag --enable-targets in the output + of GDB command 'show configuration' and also in the output printed for + 'gdb --configuration'. This will make it easier to see how GDB was + built. + + No tests added or updated as we can't really check for a specific flag + appearing or not appearing on the configuration output. But we do + print the configuration within lib/gdb.exp to check which features are + built into GDB, so if this change broke configuration printing then + plenty of tests should stop working (they don't). + + Approved-By: Tom Tromey + +2024-10-08 Andrew Burgess + + gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations + The commit: + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + added a couple of calls to breakpoint::clear_locations() inside + update_breakpoint_locations(). + + The intention of these calls was to avoid leaving redundant locations + around when a thread- or inferior-specific breakpoint was switched + from one thread or inferior to another. + + Without the clear_locations() calls the tests gdb.multi/tids.exp and + gdb.multi/pending-bp.exp have some failures. A b/p is changed such + that the program space it is associated with changes. This triggers a + call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be + the new program space. As a result GDB correctly calculates the new + locations and adds these to the breakpoint, but the old locations, in + the old program space, are incorrectly retained. The call to + clear_locations() solves this by deleting the old locations. + + However, while working on another patch I realised that the approach + taken here is not correct. The FILTER_PSPACE argument passed to + breakpoint_re_set_one() and then on to update_breakpoint_locations() + might not be the program space to which the breakpoint is associated. + Consider this example: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) start + Temporary breakpoint 1 at 0x401198: file hello.c, line 18. + Starting program: /tmp/hello.x + + Temporary breakpoint 1, main () at hello.c:18 + 18 printf ("Hello World\n"); + (gdb) break main thread 1 + Breakpoint 2 at 0x401198: file hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 breakpoint keep y 0x0000000000401198 in main at hello.c:18 + stop only in thread 1 + (gdb) add-inferior -exec /tmp/hello.x + [New inferior 2] + Added inferior 2 on connection 1 (native) + Reading symbols from /tmp/hello.x... + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 breakpoint keep y main + stop only in thread 1.1 + + Notice that after creating the second inferior and loading a file the + thread-specific breakpoint was incorrectly made pending. Loading the + exec file in the second inferior triggered a call to + breakpoint_re_set() with the new, second, program space as the + current_program_space. + + This program space ends up being passed to + update_breakpoint_locations(). + + In update_breakpoint_locations this condition is true: + + if (all_locations_are_pending (b, filter_pspace) && sals.empty ()) + + and so we end up discarding all of the locations for this breakpoint, + making the breakpoint pending. + + What we really want to do in update_breakpoint_locations() is, for + thread- or inferior- specific breakpoints, delete any locations which + are associated with a program space that this breakpoint is NOT + associated with. + + But then I realised the answer was easier than that. + + The ONLY time that a b/p can have locations associated with the + "wrong" program space like this is at the moment we change the thread + or inferior the b/p is associated with by calling + breakpoint_set_thread() or breakpoint_set_inferior(). + + And so, I think the correct solution is to hoist the call to + clear_locations() out of update_breakpoint_locations() and place a + call in each of the breakpoint_set_{thread,inferior} functions. + + I've done this, and added a couple of new tests. All of which are + now passing. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnow + When running test-case gdb.ada/tagged-lookup.exp with target board readnow and + make target check-read1: + ... + $ ( cd build/gdb; \ + make check-read1 \ + RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" ) + ... + I run into: + ... + (gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1 + print *the_local_var^M + $1 = (n => 2)^M + (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded + ... + + The problem is that the corresponding gdb_test_multiple uses line-by-line + matching (using -lbl) which doesn't work well with the multiline pattern + matching both the prompt and the line before it: + ... + -re -wrap ".* = \\\(n => $decimal\\\)" { + ... + + Fix this by making it a one-line pattern: + ... + -re -wrap "" { + ... + + While we're at it, replace an if-then-pass-else-fail with a gdb_assert. + + Tested on aarch64-linux. + +2024-10-08 Tom de Vries + + [gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-types + When running test-case gdb.dwarf2/enum-type-c++.exp with target board + cc-with-debug-types, we run into: + ... + (gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + ... + because val1 has no parent: + ... + [31] ((cooked_index_entry *) 0x7efedc002e90) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xef + parent: ((cooked_index_entry *) 0) + + ... + + [37] ((cooked_index_entry *) 0x38ffd280) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xef + parent: ((cooked_index_entry *) 0) + ... + + There are two entries, which seems to be an inefficiency, but for now let's + focus on the correctness issue. + + The debug info for val1 looks like this: + ... + <1>: Abbrev Number: 2 (DW_TAG_namespace) + DW_AT_name : ns + DW_AT_declaration : 1 + <2>: Abbrev Number: 12 (DW_TAG_class_type) + DW_AT_name : A + DW_AT_declaration : 1 + <3>: Abbrev Number: 13 (DW_TAG_enumeration_type) + DW_AT_declaration : 1 + <1>

: Abbrev Number: 14 (DW_TAG_enumeration_type) + DW_AT_specification: <0xd6> + <2>: Abbrev Number: 5 (DW_TAG_enumerator) + DW_AT_name : val1 + DW_AT_const_value : 1 + ... + + Fix this by: + - adding a cooked index entry for DIE 0xcb (and consequently for child DIE + 0xd3), by marking it interesting, + - making sure that the entry for DIE 0xcb has a name, and + - using the entry for DIE 0xd3 as parent entry for DIE 0xdd. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/symtab] Fix parent of enumerator + As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of + DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in + test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent: + ... + [27] ((cooked_index_entry *) 0x7fbbb4002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x124 + parent: ((cooked_index_entry *) 0) + ... + + This happens here in cooked_indexer::index_dies: + ... + info_ptr = recurse (reader, info_ptr, + is_enum_class ? this_entry : parent_entry, + fully); + ... + when we're passing down a nullptr parent_entry, while the parent of this_entry + is deferred. + + Fix this in cooked_indexer::index_dies by passing down a deffered parent + instead, such that we get: + ... + [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M + name: val1^M + canonical: val1^M + qualified: ns::val1^M + DWARF tag: DW_TAG_enumerator^M + flags: 0x0 []^M + DIE offset: 0x124^M + parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/contrib] Fix "sofar->so far" misspelling + I forgot to follow up on a review comment and fix the "sofar->so far" + misspelling [1]. + + Fix this by adding it to gdb/contrib/common-misspellings.txt. + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-September/211894.html + +2024-10-08 Tom de Vries + + [gdb/contrib] Add more separators in spellcheck.sh + Add two more separators in spellcheck.sh: colon and comma. + + Doing so triggers the "inbetween->between" rule, which gives an incorrect + result. Override this with "inbetween->between, in between, in-between" [1], + in a new file gdb/contrib/common-misspellings.txt. + + Fix the following common misspellings: + ... + everytime -> every time + sucess -> success + thru -> through + transfered -> transferred + inbetween -> between, in between, in-between + ... + + Verified with spellcheck.sh. Tested on x86_64-linux. + + [1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/ + +2024-10-08 Tom de Vries + + [gdb/contrib] Factor out grep_or and sed_or in spellcheck.sh + While trying to add more separators here: + ... + # Separators: space, slash, tab. + grep_separator=" |/| " + sed_separator=" \|/\|\t" + ... + I mistakingly used "|" instead of "\|" in sed_separator. + + Factor out new variables grep_or and sed_or, and construct the grep_separator + and sed_separator variables by joining the elements of a list using grep_or + and sed_or. + + Verified with shellcheck, and tested by rerunning on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-10-08 Alan Modra + + Revised "Don't return (null) from bfd_elf_sym_name" + Commit 68bbe1183379 results in a lot of follow up work, much of which + likely is still to be done. (And yes, since this is all for corrupted + or fuzzed object files, a whole lot of work doesn't much benefit + anyone. It was a bad idea to put NULL in asymbol->name.) So I'm + changing the approach to instead put a unique empty string for symbols + with a corrupted st_name. An empty string won't require much work to + ensure nm, objcopy, objdump etc. won't crash, since these tools + already must work with unnamed local symbols. + + The unique empty string is called bfd_symbol_error_name. This patch + uses that name string for corrupted symbols in the ELF and COFF + backends. Such symbols are displayed by nm and objdump as the + translated string "", which is what the COFF backend used to + put directly into corrupted symbols. + + ie. it's the way I should have written the original patch, plus a few + tides and cleanups I retained from the reverted patches. + +2024-10-08 Alan Modra + + Revert "Don't return "(null)" from bfd_elf_sym_name" + This reverts commit 68bbe118337939aa0b52e007a7415c8a157579a1. + + Revert "bfd_elf_sym_name_raw" + This reverts commit 265757dc6e4d011a1b33ef1b3bfcd7f100f12f64. + + Revert "get_synthetic_symtab fixes for commit 68bbe1183379" + This reverts commit 0c13ac533e59589793ee6c8045cff98663f3ea85. + + Revert "is_target_special_symbol fixes for commit 68bbe1183379" + This reverts commit 6e40f9bb31be2f3656df97a1fcba4d6a30081e24. + + Revert "dlltool fixes for commit 68bbe1183379" + This reverts commit 06116013f80e474800cfb122924bc2a6f060606a. + + Revert "elf.c and elflink.c fixes for commit 68bbe1183379" + This reverts commit 389fdfbe0d2aca0af1431ddf34704534dacc48c8. + + Revert "objcopy fixes for commit 68bbe1183379" + This reverts commit ef166f451fbc2c7b251a251ab23cd35b36c5ee23. + +2024-10-08 Xiao Zeng + + RISC-V: Fix implicit dependency of Zabha and Zacas + 1 Zabha depends on Zaamo: + + + 2 Zacas depends on Zaamo: + + + bfd/ChangeLog: + + * elfxx-riscv.c: Zabha and Zacas implicitly depend on Zaamo. + + gas/ChangeLog: + + * testsuite/gas/riscv/imply.d: Updated. + +2024-10-08 Vladimir Mezentsev + + gprofng: add hardware counters for Neoverse-N1 and Ampere-1 processors + gprofng/ChangeLog + 2024-10-03 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Neoverse-N1 and Ampere-1. + * common/hwctable.c: Add the hwc table for Neoverse-N1 and Ampere-1. + * src/hwc_arm_ampere_1.h: New file with hwc table for Ampere-1. + * src/hwc_arm_neoverse_n1.h: New file with hwc table for Neoverse-N1. + +2024-10-08 GDB Administrator + + Automatic date update in version.in + +2024-10-07 Andreas Schwab + + m68k: Support for jump visualization in disassembly + opcodes/ + * m68k-dis.c (m68k_opcode_to_insn_type): Define. + (match_insn_m68k): Call it to set insn_type. + (print_insn_arg) [case 'B']: Set branch target address. + (print_insn_m68k): Set insn_info_valid. + +2024-10-07 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-inferior.exp with -fsanitize=thread + With a gdb build with -fsanitize=thread, and test-case + gdb.python/py-inferior.exp I run into: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M + ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \ + maximum supported size of 0x10000000000^M + ... + + There's already a workaround for this using ASAN_OPTIONS, and apparently the + same is needed for TSAN_OPTIONS. + + Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS. + + Likewise in gdb.dap/memory.exp. + + Tested on x86_64-linux. + +2024-10-07 GDB Administrator + + Automatic date update in version.in + +2024-10-06 Gaius Mulley + + gdb/m2: add builtin procedure function ADR + This patch introduces ADR to the Modula-2 language interface. + It return the address of the parameter supplied. + The patch also contains a dejagnu test for ADR. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2024-10-06 Gaius Mulley + + gdb/MAINTAINERS: update my email address + Sync the maintainers file with my new email address. + +2024-10-06 Tom de Vries + + [gdb] Rerun spellcheck.sh + Fix the following common misspellings: + ... + completetion -> completion + inital -> initial + ... + +2024-10-06 Tom de Vries + + [gdb] Fix more common misspellings + Fix the following common misspellings: + ... + addres -> address, adders + behavour -> behavior, behaviour + intented -> intended, indented + ther -> there, their, the + throught -> thought, through, throughout + ... + + Tested on x86_64-linux. + +2024-10-06 Tom de Vries + + [gdb] Fix common misspellings + Fix the following common misspellings: + ... + accidently -> accidentally + additonal -> additional + addresing -> addressing + adress -> address + agaisnt -> against + albiet -> albeit + arbitary -> arbitrary + artifical -> artificial + auxillary -> auxiliary + auxilliary -> auxiliary + bcak -> back + begining -> beginning + cannonical -> canonical + compatiblity -> compatibility + completetion -> completion + diferent -> different + emited -> emitted + emiting -> emitting + emmitted -> emitted + everytime -> every time + excercise -> exercise + existance -> existence + fucntion -> function + funtion -> function + guarentee -> guarantee + htis -> this + immediatly -> immediately + layed -> laid + noone -> no one + occurances -> occurrences + occured -> occurred + originaly -> originally + preceeded -> preceded + preceeds -> precedes + propogate -> propagate + publically -> publicly + refering -> referring + substract -> subtract + substracting -> subtracting + substraction -> subtraction + taht -> that + targetting -> targeting + teh -> the + thier -> their + thru -> through + transfered -> transferred + transfering -> transferring + upto -> up to + vincinity -> vicinity + whcih -> which + whereever -> wherever + wierd -> weird + withing -> within + writen -> written + wtih -> with + doesnt -> doesn't + ... + + Tested on x86_64-linux. + +2024-10-06 Tom de Vries + + [gdb/contrib] Add spellcheck.sh + I came across a table containing common misspellings [1], and wrote a script to + detect and correct these misspellings. + + The table also contains entries that have alternatives, like this: + ... + addres->address, adders + ... + and for those the script prints a TODO instead. + + The script downloads the webpage containing the table, extracts the table and + caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it + over and over again. + + Example usage: + ... + $ gdb/contrib/spellcheck.sh gdb* + ... + + ChangeLog files are silently skipped. + + Checked with shellcheck. + + Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and + test run. + + The results of running it are in the two following patches. + + Reviewed-By: Andrew Burgess + Approved-By: Tom Tromey + + [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines + +2024-10-06 GDB Administrator + + Automatic date update in version.in + +2024-10-05 Alan Modra + + objcopy fixes for commit 68bbe1183379 + * objcopy.c (is_specified_symbol): Handle NULL name. + (filter_symbols): Drop syms with a NULL name. + +2024-10-05 Alan Modra + + elf.c and elflink.c fixes for commit 68bbe1183379 + Plus some tidies to swap_out_syms. + + * elf.c (swap_out_syms): Handle NULL sym name. Use correct type + for return of _bfd_elf_strtab_add. Simplify. + * elflink.c (bfd_elf_match_symbols_in_sections): Handle NULL + sym name. + +2024-10-05 GDB Administrator + + Automatic date update in version.in + +2024-10-04 Alan Modra + + gdb segv in elfread.c:elf_rel_plt_read + After commit 68bbe1183379, ELF symbols read via bfd_canonicalize_symtab + and similar functions which have bad st_name fields will have NULL in + the name rather than "(null)". gdb.base/bfd-errors.exp deliberately + creates a faulty shared library with st_name pointing outside of + .dynsym for some symbols, and thus now results in NULL symbol names. + This triggers a segv on string_buffer.assign(name). Fix that. + +2024-10-04 Alan Modra + + dlltool fixes for commit 68bbe1183379 + For some reason, dlltool supports mcore-elf input files. + + * dlltool.c (filter_symbols): Drop symbols with NULL names. + (identify_member_contains_symname): Don't consider symbols + with NULL names. + +2024-10-04 Alan Modra + + is_target_special_symbol fixes for commit 68bbe1183379 + * elf.c (_bfd_elf_is_local_label_name): Don't segv on NULL name. + * elf32-v850.c (v850_elf_is_local_label_name): Likewise. + * elfnn-riscv.c (riscv_elf_is_target_special_symbol): Likewise. + +2024-10-04 Alan Modra + + get_synthetic_symtab fixes for commit 68bbe1183379 + Given that relocation symbol name can now be NULL for ELF, adjust + various get_synthetic_symtab routines so they don't segfault. + + * elf.c (_bfd_elf_get_synthetic_symtab): Cope with sym->name + possibly being NULL. + * elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise. + * elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise. + * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise. + * elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise. + * elfxx-x86.c (_bfd_x86_elf_get_synthetic_symtab): Likewise. + +2024-10-04 Alan Modra + + bfd_elf_sym_name_raw + Many uses of bfd_elf_sym_name report errors. They ought to not return + a NULL, as was the case prior to commit 68bbe1183379. Introduce a new + function for cases where we'd like to know there is a problem with a + symbol st_name. + + * elf-bfd.h (bfd_elf_sym_name_raw): Declare. + * elf.c (bfd_elf_sym_name_raw): New function. + (bfd_elf_sym_name): Revert to behaviour prior to 68bbe1183379, + but returning "" rather than "(null)" for st_name errors. + (group_signature): Use bfd_elf_sym_name_raw. + * elfcode.h (elf_slurp_symbol_table): Likewise. + * elf32-i386.c (elf_i386_scan_relocs): Whitespace. + +2024-10-04 Jan Beulich + + gas: hide emulation struct format_ops instances when not needed + Most targets don't even support emulations, so this data (and certain + functions) are entirely dead code for them. + +2024-10-04 Jan Beulich + + x86: prune OBJ_MAYBE_... uses + With the removal of emulations, OBJ_MAYBE_... can no longer be defined. + Tidy code wherever they're used, which also includes the dropping of + most IS_ELF and uses and checks of OUTPUT_FLAVOR. + + Where touching such constructs anyway, also drop TE_PEP checks when used + together with TE_PE ones (the former implies the latter). + +2024-10-04 Jan Beulich + + x86: drop largely defunct gas emulations + Both ELF and COFF have various sub-flavors, each of which would then + require its own emulation: Right now when configuring a COFF/PE + secondary target (with perhaps an ELF primary one), one gets plain COFF + emulation rather than COFF/PE one. + + As such a multitude of emulations would be unwieldy (and likely fragile) + drop gas emulations altogether instead. + +2024-10-04 Jan Beulich + + include: de-duplicate i386.h and x86_64.h + Move common definitions to a new x86.h, thus allowing gas'es obj-coff.h + to include just that, getting rid of a TE_PEP compile-time dependency. + + gas: drop generate_asm_lineno emulation hook + It's not wired up, so can't be used. + + gas: don't use COFF-specific SF_SET_LOCAL() directly from read.c + Make this a proper obj-format hook instead. + +2024-10-04 Jan Beulich + + gas/dw2gencfi: correct .sframe section conditional + While originally this was in preparation of a subsequent change making + SUPPORT_FRAME_LINKONCE potentially dependent on a global variable, the + construct appears unlikely to have been correct in the first place: The + variable would have been passed reliably uninitialized when + SUPPORT_FRAME_LINKONCE is build-time true. + + While there correct indentation of the parameters passed to + get_cfi_seg(). + +2024-10-04 Jan Beulich + + gas: put emul decls in emul.h + The individual struct emulation instances shouldn't be declared in a .c + file; it and the producers of the symbols want to both see the + declarations, so declarations and definitions don't go out of sync. Move + these declarations to emul.h. + + While there also adjust the conditional around this_format: That symbol + is never #define-d anywhere, and it's needed only when USE_EMULATIONS is + defined. (Really, when obj-multi isn't in use, it also is effectively + only ever written to.) + +2024-10-04 Jan Beulich + + gas: drop unused fields from struct emulation + Neither .match not .bfd_name appear to ever have been used in the last + about 25 years. Purge them. + + MAINTAINERS: move M R Swami Reddy to Past Maintainers + He/she cannot be reached at the given address anymore, and the name is + apparently too common to identify the person to attempt to establish + another contact. Sadly this orphans the CR16 and CRx ports. + +2024-10-04 Jan Beulich + + MAINTAINERS: move Matt Thomas to Past Maintainers + Matt cannot be reached at the @netbsd.org address anymore, and I was + unable to find another one, even with the help of the NetBSD community + (where his resigning was announced over 4 years ago [1]). + + [1] http://mail-index.netbsd.org/netbsd-announce/2020/05/07/msg000314.html + +2024-10-04 GDB Administrator + + Automatic date update in version.in + +2024-10-03 oltolm + + gdb-dap: disable events when deleting breakpoints + when I disable a breakpoint in VS Code the breakpoint is removed + instead. I compared the behavior to lldb-dap and disabled events when + removing a breakpoint. Now it is possible to disable and enable + breakpoints in VS Code. + +2024-10-03 Alexey Izbyshev + + bfd: fix unnecessary bfd.info regen + When building from an unmodified release tarball, a REGEN_TEXI + invocation is supposed to create a symlink to the .texi file + in the source directory and discard the newly generated .tmp file. + However, after commit bd32be01c997 ("bfd: merge doc subdir up a level") + it creates the symlink at the wrong level, and then a .texi with + a fresh timestamp, which in turn forces bfd.info regeneration. + This breaks builds in environments without makeinfo program. + + Fix this by creating the symlink at the level of the target stamp. + + Fixes: bd32be01c997 ("bfd: merge doc subdir up a level") + +2024-10-03 Alan Modra + + peicode.h formatting + Fix some overlong line, comment block style, whitespace issues. + +2024-10-03 Alan Modra + + Enable dlltool --leading-underscore for targets other than x86 + This also makes the dlltool tests run more PE targets, finding that + sh-pe dlltool reports "Machine 'sh' not supported". I guess no one + cares about that. + + PR19459 + * dlltool.c (asm_prefix): Remove "mach" parameter. Return + leading_underscore independent of machine. + (ASM_PREFIX): Adjust. + * testsuite/binutils-all/dlltool.exp: Run on any target + satisfying is_pecoff_format for which dlltool is built. + Revert commit 0398b8d6c86a. Remove target_xfail. + +2024-10-03 Alan Modra + + dlltool leading_underscore + This patch tidies dlltool code dealing with adding a leading + underscore to generated symbol names. There should be no functional + change here, but there could be if we ever have a bfd target with + symbol_leading_char something other than '_' or 0. + + * dlltool.c (leading_underscore): Change from an int to a + char*. Update all uses. If neither --leading-underscore or + --no=leading-underscore is given, set leading_underscore to a + string with first char returned by bfd_get_target_info as the + target's symbol underscoring. + +2024-10-03 Alan Modra + + nm: don't try to print line numbers for symbols without names + It doesn't make much sense trying to print line numbers for what are + usually broken symbols, and there is a possibility of a segfault if + we pass strcmp a NULL. + +2024-10-03 Alan Modra + + Don't return "(null)" from bfd_elf_sym_name + A NULL return from bfd_elf_string_from_elf_section indicates an error. + That shouldn't be masked by bfd_elf_sym_name but rather passed up to + callers such as group_signature. If we want to print "(null)" then + that should be done at a higher level. That's what this patch does, + except that I chose to print "" instead, like readelf. If we + see "(null)" we're probably passing a NULL to printf. I haven't + changed aoutx.h or pdp11.c print_symbol functions because they already + handle NULL names by omitting the name. I also haven't changed + mach-o.c, mmo.c, som.c, srec.c, tekhex.c, vms-alpha.c and + wasm-module.c print_symbol function because it looks like they will + never have NULL symbol names. + + bfd/ + * elf.c (bfd_elf_sym_name): Don't turn a NULL name into a + pointer to "(null)". + (bfd_elf_print_symbol): Print "" for NULL symbol names. + * coffgen.c (coff_print_symbol): Likewise. + * ecoff.c (_bfd_ecoff_print_symbol): Likewise. + * pef.c (bfd_pef_print_symbol): Likewise. + * syms.c (bfd_symbol_info): Return "" in symbol_info.name + if symbol name is NULL. + ld/ + * ldlang.c (ld_is_local_symbol): Don't check for "(null)" + symbol name. + +2024-10-03 GDB Administrator + + Automatic date update in version.in + +2024-10-02 Ruud van der Pas + + gprofng: fix a problem with hardware event counters + Fix a bug where an experiment with hardware event counter data + causes the source and disassembly files not to be generated. + No longer suppress zero valued metrics and change the name + of the man page in a warning message. Adapt line lengths to + not exceed 79. + + gprofng/ChangeLog + 2024-09-24 Ruud van der Pas + + PR 32193 + PR 32199 + PR 32201 + * gp-display-html/gp-display-html.in: Implement all + the above changes. + +2024-10-02 Andrew Burgess + + gdb: more file name styling + While looking at the recent line number styling commit I noticed a few + places where we could add more file name styling. So lets do that. + + Approved-By: Tom Tromey + +2024-10-02 Martin Storsjö + + Add support for IMPORT_NAME_EXPORTAS in ILF (MSVC style) import libraries + This import name type is formally yet undocumented, but MSVC + produces/supports it, primarily for ARM64EC import libraries. + + LLVM/LLD also supports this import name type. Since recently, + llvm-dlltool also uses this type for certain kinds of renamed imports + (that are easy to do in the long style import libraries produced by + GNU dlltool, but require this name type in short import libraries). + + This name type contains a third string, in addition to the symbol + name and the DLL name, indicating the actual imported name to + reference in the import tables - which now can be distinct different + from the symbol name on the object file level. + + https://github.com/llvm/llvm-project/commit/8f23464a5d957242c89ca6f33d4379c42519cd81 + and + https://github.com/llvm/llvm-project/commit/7b275aa2438c22604505d618dd37ee60052f2800 + show how this import name type was added in LLVM. + +2024-10-02 GDB Administrator + + Automatic date update in version.in + +2024-10-01 Tom Tromey + + Introduce and use operation::type_p + There's currently code in gdb that checks if an expression evaluates + to a type. In some spots this is done by comparing the opcode against + OP_TYPE, but other spots more correctly also compare with OP_TYPEOF + and OP_DECLTYPE. + + This patch cleans up this area, replacing opcode-checking with a new + method on 'operation'. + + Generally, checking the opcode should be considered deprecated, + although it's unfortunately difficult to get rid of opcodes entirely. + + I also took advantage of this change to turn eval_op_type into a + method, removing a bit of indirection. + + Reviewed-by: Keith Seitz + +2024-10-01 GDB Administrator + + Automatic date update in version.in + +2024-10-01 Alan Modra + + Re: dlltool: file name too long + Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy + TMP_STUB handling by overwriting a prior nnnnn.o string rather than + copying the entire name. + + * dlltool.c (TMP_STUB): Add "nnnnn.o" to format. + (make_one_lib_file): Localise variables. Don't copy TMP_STUB, + overwrite suffix instead. + (gen_lib_file): Similarly. + (main): Allow for max suffix when testing against NAME_MAX. + +2024-10-01 Alan Modra + + segv in read_a_source_file + On some paths through read_a_source file, "s" may not be set. + + * read.c (read_a_source_file): Correct code ignoring comment. + +2024-09-30 Alan Modra + + segv in bfd_elf_get_str_section + Attempting to write a termination NUL to PROT_READ mmap'd memory was + a silly idea. + + PR 32109 + * elf.c (bfd_elf_get_str_section): Don't write terminating NUL + if missing. + * libbfd.c (_bfd_munmap_readonly_temporary): Correct comment. + +2024-09-30 Tom Tromey + + Add line-number styling + This patch adds separate styling for line numbers. That is, whenever + gdb prints a source line number, it uses this style. + + v2 includes a change to ensure that %ps works in query. + + Reviewed-By: Eli Zaretskii + Reviewed-by: Keith Seitz + +2024-09-30 Nick Clifton + + Improve the placement of orphan note sections. + PR 32219 + +2024-09-30 Andrew Burgess + + gdb: fix filename completion in the middle of a line + I noticed that filename completion in the middle of a line doesn't + work as I would expect it too. For example, assuming '/tmp/filename' + exists, and is the only file in '/tmp/' then when I do the following: + + (gdb) file "/tmp/filen + + GDB completes to: + + (gdb) file "/tmp/filename" + + But, if I type this: + + (gdb) file "/tmp/filen "xxx" + + Then move the cursor to the end of '/tmp/filen' and press , GDB + will complete the line to: + + (gdb) file "/tmp/filename "xxx" + + But GDB will not insert the trailing double quote character. + + The reason for this is found in readline/readline/complete.c in the + function append_to_match. This is the function that appends the + trailing closing quote character, however, the closing quote is only + inserted if the cursor (rl_point) is at the end (rl_end) of the line + being completed. + + In this patch, what I do instead is add the closing quote in the + function gdb_completer_file_name_quote, which is called from readline + through the rl_filename_quoting_function hook. The docs for + rl_filename_quoting_function say (see 'info readline'): + + "... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one + completion match, or 'MULT_MATCH'. Some functions use this to + decide whether or not to insert a closing quote character. ..." + + This is exactly what I'm doing in this patch, and clearly this is not + an unusual choice. Now after completing a filename that is not at the + end of the line GDB will add the closing quote character if + appropriate. + + I have managed to write some tests for this. I send a line of text to + GDB which includes a partial filename followed by a trailing string, I + then send the escape sequence to move the cursor left, and finally I + send the tab character. + + Obviously, expect doesn't actually see the complete output with the + extra text "in place", instead expect sees the original line followed + by some escape sequences to reflect the cursor movement, then an + escape sequence to indicate that text is being inserted in the middle + of a line, followed by the new characters ... it's a bit messy, but I + think it holds together. + + Reviewed-By: Tom Tromey + +2024-09-30 Andrew Burgess + + gdb: fix for completing a second filename for a command + After the recent filename completion changes I noticed that the + following didn't work as expected: + + (gdb) file "/path/to/some/file" /path/to/so + + Now, I know that the 'file' command doesn't actually take multiple + filenames, but currently (and this was true before the recent filename + completion changes too) the completion function doesn't know that the + command only expects a single filename, and should complete any number + of filenames. And indeed, this works: + + (gdb) file "/path/to/some/file" "/path/to/so + + In this case I quoted the second path, and now GDB is happy to offer + completions. + + It turns out that the problem in the first case is an off-by-one bug + in gdb_completer_file_name_char_is_quoted. This function tells GDB if + a character within the line being completed is escaped or not. An + escaped character cannot be a word separator. + + The algorithm in gdb_completer_file_name_char_is_quoted is to scan + forward through the line keeping track of whether we are inside double + or single quotes, or if a character follows a backslash. When we find + an opening quote we skip forward to the closing quote and then check + to see if we skipped over the character we are looking for, if we did + then the character is within the quoted string. + + The problem is that this "is character inside quoted string" check + used '>=' instead if '>'. As a consequence a character immediately + after a quoted string would be thought of as inside the quoted string. + + In our first example this means that the single white space character + after the quoted string was thought to be quoted, and was not + considered a word breaking character. As such, GDB would not try to + complete the second path. And indeed, if we tried this: + + (gdb) file "/path/to/some/file" /path/to/so + + That is, place multiple spaces after the first path, then GDB would + consider the first space as quoted, but the second space is NOT + quoted, and would be a word break. Now GDB does complete the second + path. + + By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this + bug is resolved, now the original example works and GDB will correctly + complete the second path. + + For testing I've factored out the core of one testing proc, and I now + run those tests multiple times, once with no initial path, once with + an initial path in double quotes, once with an initial path in + single quotes, and finally, with an unquoted initial path. + + Reviewed-By: Tom Tromey + +2024-09-30 Gerlicher, Klaus + + gdb/MAINTAINERS: add myself to maintainers + +2024-09-30 Felix Willgerodt + + gdb: Remove myself as x86 maintainer and update my email + +2024-09-30 Gerlicher, Klaus + + gdb, testsuite: clean duplicate header includes + Some of the gdb and testsuite files double include some headers. While + all headers use include guards, it helps a bit keeping the code base + tidy. + + No functional change. + + Approved-by: Kevin Buettner + +2024-09-30 GDB Administrator + + Automatic date update in version.in + +2024-09-29 GDB Administrator + + Automatic date update in version.in + +2024-09-28 Tom de Vries + + [gdb/symtab] Dump m_all_parents_map for verbose debug dwarf-read + [ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ] + + When building the cooked index, gdb builds up a parent map. + + This map is currently only visible at user level through the effect of using + it, but it's useful to be able to inspect it as well. + + Add dumping of this parent map for "set debug dwarf-read 2". + + As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board + debug-types. + + The parent map looks like: + ... + $ gdb -q -batch \ + -iex "maint set worker-threads 0" \ + -iex "set debug dwarf-read 2" \ + outputs/gdb.dwarf2/enum-type-c++/enum-type-c++ + ... + [dwarf-read] print_stats: Final m_all_parents_map: + map start: + 0x0000000000000000 0x0 + 0x0000000000000037 0x20f27d30 (0x36: ec) + 0x0000000000000051 0x0 + 0x000000000000008b 0x20f27dc0 (0x8a: A) + 0x00000000000000a6 0x0 + ... + + There's no parent entry at address 0xd6, which is part of what causes this: + ... + (gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + ... + + With the series containing the proposed fix applied [2], we get instead: + ... + [dwarf-read] print_stats: Final m_all_parents_map: + map start: + 0x0000000000000000 0x0 + 0x0000000000000026 0x7e0bdc0 (0x25: ns) + 0x0000000000000036 0x0 + 0x0000000000000037 0x7e0bdf0 (0x36: ns::ec) + 0x0000000000000051 0x0 + 0x000000000000007f 0x7e0be80 (0x7e: ns) + 0x000000000000008a 0x0 + 0x000000000000008b 0x7e0beb0 (0x8a: ns::A) + 0x00000000000000a6 0x0 + 0x00000000000000cc 0x7e0bf10 (0xcb: ns) + 0x00000000000000d4 0x7e0bf40 (0xd3: ns::A) + 0x00000000000000dc 0x7e0bf10 (0xcb: ns) + 0x00000000000000dd 0x7e0bf40 (0xd3: ns::A) + 0x00000000000000f6 0x0 + ... + and find at 0xd6 parent ns::A. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html + [2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html + +2024-09-28 Alan Modra + + gas buffer overflow with --listing-rhs-width + With listings enabled, gas keeps a small cache of source lines. They + are stored in buffers of size LISTING_RHS_WIDTH, ie. 100. Given + listing-rhs-width larger than 100 it is of course possible to overflow + the buffer. Fix that by allocating as needed. We could allocate all + buffers on the first call to print_source using listing_rhs_width, but + I chose not to do that in case some future assembly directive allows + changes to listing_rhs_width similarly to the way paper_width can + change during assembly. + +2024-09-28 Alan Modra + + Move uses_elf_em to ld-lib.exp + and add a missing entry from uses_genelf. + + binutils/ + * testsuite/lib/binutils-common.exp (uses_elf_em): Delete. + ld/ + * testsuite/lib/ld-lib.exp (uses_genelf): Add moxie-*-moxiebox. + (uses_elf_em): New. + +2024-09-28 GDB Administrator + + Automatic date update in version.in + +2024-09-27 Tom Tromey + + Re-run 'isort' on gdb tests + Re-running 'isort' (via pre-commit) showed that the file + py-read-memory-leak.py (from the gdb test suite) needed a small patch. + +2024-09-27 Simon Marchi + + gdb/symtab: pass program space to lookup_symtab and iterate_over_symtabs + Make the current program space references bubble up. + + In collect_symtabs_from_filename, remove the calls to + set_current_program_space and just pass the relevant pspaces. + This appears safe to do, because nothing in the `collector` callback + cares about the current pspace. + + Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb + Reviewed-by: Keith Seitz + +2024-09-27 Jan Beulich + + x86: fix Solaris gas testsuite run + Commits 8015b1b0c1a1 ("x86-64: Never make R_X86_64_GOT64 section + relative"), d774bf9b3623 ("x86: Add tls check in gas"), and + 1b714c14e40f ("x86: Turn PLT32 to PC32 only for PC-relative + relocations") all should have adjusted the Solaris counterpart of the + reloc64 test as well. + + RISC-V: odd data padding vs mapping symbols + Odd data padding has a $d label inserted at its beginning. When a $x... + label is removed instead, a replacement is inserted after the padding. + The same, however, needs to also happen when there's no $x to replace. + +2024-09-27 Jan Beulich + + RISC-V: correct alignment directive handling for text sections + .insn or data emitted inside text sections can lead to positions not + being at insn granularity. In such situations using alignment + directives should reliably enforce the requested alignment. + Specifically requests to align back to insn granularity may not be + ignored (where, as a subcase thereof, the ordering of ".option norvc" + and e.g. ".p2align 2" should not matter; so far the alignment directive + needs to come first to have any effect). Similarly ahead of emitting + NOPs alignment first needs to be forced back to insn granularity. + + The new testcases actually point out a corner case issue in the + disassembler as well, which is being corrected at the same time: We + don't want to print "0x" without any subsequent digits. + +2024-09-27 Jan Beulich + + x86: optimize {,V}INSERTPS with certain immediates + They are equivalent to simple moves or xors, which are up to 3 bytes + shorter to encode (and maybe/likely also cheaper to execute). + + x86: optimize {,V}EXTRACT{F,I}{128,32x{4,8},64x{2,4}} with immediate 0 + They, too, are equivalent to simple moves, which are up to 3 bytes + shorter to encode (and maybe also cheaper to execute). + + x86: optimize {,V}EXTRACTPS with immediate 0 + They are equivalent to simple moves, which are up to 2 bytes shorter to + encode (and maybe also cheaper to execute). + + x86: correct {,V}PEXTR{D,Q} optimization + A possible relocation associated with a memory operand also needs + moving. + +2024-09-27 Alan Modra + + Enable -z separate-code, -z common and -z text for more targets + Fix a mis-placed "fi". + +2024-09-27 GDB Administrator + + Automatic date update in version.in + +2024-09-27 Tom Tromey + + Add 'const' to symmisc.c + I noticed a few spots in symmisc.c that could use a 'const'. + +2024-09-26 Vladimir Mezentsev + + Fix 32207 [gprofng collect app] Error in parsing the -O option + gprofng/ChangeLog + 2024-09-25 Vladimir Mezentsev + + PR 32207 + * src/collctrl.cc (preprocess_names): Fix the size in strndup. + +2024-09-26 Nick Clifton + + Updated Brazilian Portuguese translation for the gprof directory. + +2024-09-26 Andreas Schwab + + Fix -Wstringop-overflow warning in ecoff_link_hash_newfunc + * ecoff.c (ecoff_link_hash_newfunc): Don't call memset if ret is + NULL. + +2024-09-26 H.J. Lu + + ld: Ignore .note.gnu.build-id when placing orphaned notes + The commits: + + e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. + bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map + + place .note.gnu.build-id before text sections when --rosegment is used. + Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and + -z separate-code are used together to avoid putting any note sections + between .note.gnu.build-id and text sections in the same PT_LOAD segment. + + PR ld/32191 + * ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when + placing orphaned notes. + * testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld. + * testsuite/ld-elf/pr23658-1c.d: Likewise. + * testsuite/ld-elf/pr23658-1e.d: New file. + * testsuite/ld-elf/pr23658-1f.d: Likewise. + * testsuite/ld-i386/i386.exp: Run PR ld/32191 test. + * testsuite/ld-i386/pr32191.d: New file. + * testsuite/ld-x86-64/lam-u48.rd: Updated. + * testsuite/ld-x86-64/lam-u57.rd: Likewise. + * testsuite/ld-x86-64/pr32191-x32.d: New file. + * testsuite/ld-x86-64/pr32191.d: Likewise. + * testsuite/ld-x86-64/pr32191.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests. + +2024-09-26 Jan Beulich + + x86: templatize SIMD narrowing-move templates + Once again to reduce redundancy. + + x86: templatize SIMD sign-/zero-extension templates + Yet again to reduce redundancy. + + x86: templatize SIMD FP binary-logic templates + Once more to reduce redundancy. + + x86: further templatize FMA templates + Further reduce redundancy, in preparation of the addition of + counterparts for AVX10.2. + + x86: templatize SIMD FP arithmetic templates + Reduce redundancy, in preparation of the addition of further counterparts + for AVX10.2. Provide the "ne" parameter needed there right away, even if + unused for now. + +2024-09-26 Andrew Burgess + + gdb/testsuite: test for memory leaks in gdb.Inferior.read_memory() + For a long time Fedora GDB has carried an out of tree patch which + checks for memory leaks in gdb.Inferior.read_memory(). At one point + in the distant past GDB did have a memory leak in this code, but this + was first fixed in commit: + + commit 655e820cf9a039ee55325d9e1f8423796d592b4b + Date: Wed Mar 28 17:38:07 2012 +0000 + + * python/py-inferior.c (infpy_read_memory): Remove cleanups and + explicitly free 'buffer' on exit paths. Decref 'membuf_object' + before returning. + + And the code has changed a lot since then, but the leak is still + fixed. Unfortunately, this commit didn't have any associated tests. + + The original Fedora test wasn't really suitable for upstream, it was + reading /proc/PID/... to figure out if there was a leak or not. + + However, we already have gdb.python/py-inferior-leak.exp in upstream + GDB, which makes use of the Python tracemalloc module to check for + memory leaks in a corner of the Python API, so I figured it wouldn't + hurt to rewrite the test in the same style. + + And so here is a test for a bug which was closed 12 years ago. This + detects if the gdb.Inferior.read_memory() call leaks any memory. + + I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last + line which currently looks like this: + + return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ()); + + and instead doing: + + return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ()); + + The use of "release" here will mean we no longer decrement the + reference count on membuf_obj before returning from the function. As + a consequence the membuf_obj will not be garbage collected. With this + hack in place the new test will fail. + + The Python script in the new test is mostly a copy&paste from + py-inferior-leak.py with the core changed to do a memory read instead + of inferior creation. I did consider rewriting both tests into a + single file, maybe, py-memory-leak.py, which would make it easier to + add additional similar tests in the future. For now I've held off + doing that, but if this gets merged then I _might_ revisit this idea. + + If folk feel that this new test should only be accepted if I do this + rewrite then let me know and I can get that done. + + On copyright date ranges: The .exp and .py scripts are new enough for + this commit that I've dated them 2024. The .c source script is lifted + directly from the old Fedora patch, so I've retained the original 2014 + start date for that file only. + + Approved-By: Tom Tromey + +2024-09-26 Haochen Jiang + + x86/testsuite: Refine AVX10.2 rounding testcases + Using hard byte code is not a good idea in dump file. Add a label + for intel syntax test check to avoid that. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-rounding-intel.d: Use label for + test split. + * testsuite/gas/i386/avx10_2-rounding.s: Add label to avoid + hard coding in dump file. + +2024-09-26 GDB Administrator + + Automatic date update in version.in + +2024-09-25 Alan Modra + + x86 TLS relocation checks + Some configurations (eg. i386-bsd, i386-msdos) broke with the addition + of the TLS relocation checking. The "x86_elf_abi undeclared" error + has been fixed, but "gotrel defined but not used" remains. Fix that. + Also invert the preprocessor test around lex_got to make it positive + logic and remove the LEX_AT condition which is no longer necessary. + (The only x86 config files defining LEX_AT also define TE_PE.) + +2024-09-25 Sam James + + ltmain.sh: allow more flags at link-time + libtool defaults to filtering flags passed at link-time. + + This brings the filtering in GCC's 'fork' of libtool into sync with + upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. + + In particular, this now allows some harmless diagnostic flags (especially + useful for things like -Werror=odr), more optimization flags, and some + Clang-specific options. + + GCC's -flto documentation mentions: + > To use the link-time optimizer, -flto and optimization options should be + > specified at compile time and during the final link. It is recommended + > that you compile all the files participating in the same link with the + > same options and also specify those options at link time. + + This allows compliance with that. + + * ltmain.sh (func_mode_link): Allow various flags through filter. + +2024-09-25 Tom de Vries + + [gdb/python] Make sure python sys.exit makes gdb exit + With gdb 15.1, python sys.exit no longer makes gdb exit: + ... + $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? + Python Exception : 2 + Error occurred in Python: 2 + $1 = 123 + 0 + ... + + This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python" + command exception handling"), first available in gdb 15.1. + + This patch reverts to the old behaviour by handling PyExc_SystemExit in + gdbpy_handle_exception, such what we have instead: + ... + $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? + 2 + ... + + Tested on x86_64-linux, with python 3.6 and 3.13. + + Tested-By: Guinevere Larsen + Approved-By: Tom Tromey + + PR python/31946 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946 + +2024-09-25 Simon Marchi + + gdb/testsuite: format some Python files + Format with black. + + Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2 + +2024-09-25 Schimpe, Christina + + gdb, gdbserver, python, testsuite: Remove MPX. + GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel + listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019. + MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6) + and glibc (since v2.35). Let's now remove MPX support in GDB completely. + + This includes the removal of: + - MPX functionality including register support + - deprecated mpx commands + - i386 and amd64 implementation of the hooks report_signal_info and + get_siginfo_type + - tests + - and pretty printer. + + We keep MPX register numbers to not break compatibility with old gdbservers. + + Approved-By: Felix Willgerodt + +2024-09-25 Schimpe, Christina + + gdb, testsuite, python: Add missing imports. + Removing the pretty printer (bound_registers.py) in the next commit + leads to failures due to a missing import of 'gdb.printing': + + "AttributeError: module 'gdb' has no attribute 'printing'". + + Add this import to each file requiring it, as it's not imported by the + pretty-printer anymore. + + Approved-By: Andrew Burgess + +2024-09-25 Frank Ch. Eigler + + binutils testsuite: canonicalize subtest names in libctf + Previous code included the full $srcdir pathnames in the individual + subtest PASS/FAIL names, which makes it difficult to compute + comparisons or regressions between test runs on different machines. + This version switches to the basename only, which are common. + + binutils testsuite: canonicalize subtest names in debuginfod.exp + Previous code included the full $srcdir pathnames in the individual + subtest PASS/FAIL names, which makes it difficult to compute + comparisons or regressions between test runs on different machines. + This version switches to the basename only, which are common. + +2024-09-25 Jiawei + + RISC-V: Add Smrnmi extension csrs. + This patch support Smrnmi extension[1], + The csrs address can be find in[2]. + + [1] https://github.com/riscv/riscv-isa-manual/commit/35eb3948bf0b87c83fab5a7238bd68b6211faf62 + [2] https://github.com/riscv/riscv-isa-manual/blob/smrnmi-1.0/src/priv-csrs.adoc + + bfd/ChangeLog: + + * elfxx-riscv.c: New extension. + + gas/ChangeLog: + + * NEWS: Add Smrnmi extension support. + * config/tc-riscv.c (enum riscv_csr_class): New extension class. + (riscv_csr_address): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New csrs. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extension. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MNSCRATCH): New csr. + (CSR_MNEPC): Ditto. + (CSR_MNCAUSE): Ditto. + (CSR_MNSTATUS): Ditto. + (DECLARE_CSR): New csr declarations. + +2024-09-25 GDB Administrator + + Automatic date update in version.in + +2024-09-24 Tom Tromey + + Fix typo in gdb.ada/complete.exp test + I noticed that two tests in gdb.ada/complete.exp are testing the same + thing: the completion of "p pck.inne". The second such test has this + comment: + + # A fully qualified package name + + I believe the intent here was to test "p pck.inner" (note the trailing + "r"). This patch makes this change. + +2024-09-24 Thiago Jung Bauermann + + gdb: testsuite: Test whether PC register is expedited in gdb.server/server-run.exp + One thing GDB always does when the inferior stops is finding out where + it's stopped at, by way of querying the value of the program counter + register. + + To save a packet round trip, the remote target can send the PC + value (often alongside other frequently consulted registers such as the + stack pointer) in the stop reply packet as an "expedited register". + + Test that this is actually done for the targets where gdbserver is + supposed to. + + Extend the "maintenance print remote-registers" command output with an + "Expedited" column which says "yes" if the register was seen by GDB in + the last stop reply packet it received, and is left blank otherwise. + + Tested for regressions on aarch64-linux-gnu native-extended-remote. + + The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and + x86_64-linux-gnu native-remote and native-extended-remote targets. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-09-24 Simon Marchi + + ld: re-generate configure + Looks like configure has been generated with a non-upstream autoconf, + re-generate it. + + ld/ChangeLog: + + * configure: Re-generate. + + Change-Id: I6774381ad411a190fb93ff260234dd79d8791680 + +2024-09-24 Simon Marchi + + gdb/elfread.c: remove unused includes + Remove some includes reported as unused by clangd. + + Change-Id: If7c4729975bd90b9cc2c22bcf84d333bd0002a52 + +2024-09-24 Tom de Vries + + [gdb] Handle SIGTERM in run_events + While reviewing "catch (...)" uses I came across: + ... + for (auto &item : local) + { + try + { + item (); + } + catch (...) + { + /* Ignore exceptions in the callback. */ + } + } + ... + + This means that when an item throws a gdb_exception_forced_quit, + the exception is ignored and following items are executed. + + Fix this by handling gdb_exception_forced_quit explicity, and immediately + rethrowing it. + + I wondered about ^C, and couldn't decide whether current behaviour is ok, so + I left this alone, but I made the issue explicit in the source code. + + As for the "catch (...)", I think that it should let a non-gdb_exception + propagate, so I've narrowed it to "catch (const gdb_exception &)". + + My rationale for this is as follows. + + There seem to be a few ways that "catch (...)" is allowed in gdb: + - clean-up and rethrow (basically the SCOPE_EXIT pattern) + - catch and handle an exception from a call into an external c++ library + + Since we're dealing with neither of those here, we remove the "catch (...)". + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Frank Ch. Eigler + + ld: support --build-id=xx mode + The is patch adds a new ld build-id computation mode, "xx", using + xxhash in its 128-bit mode. The patch prereqs the xxhash-devel + headers being installed, and uses the "all-inlined" model, so no + run-time or link-time library dependence exists. + + The xxhash mode performs well, saving roughly 20% of total userspace + run time from an ld job over a 800MB shared library relative to sha1. + 128 bits of good hash should be collision-resistant to a number of + distinct binaries that numbers in the 2**32 - 2**64 range, even if not + "crypto" level hash. Confirmations of this are in progress. + + ld/configury: add --with-xxhash mode, different from gdb case + because only using it in inline mode + + ld/ldbuildid.c: add "xx" mode, #if WITH_XXHASH + + ld/NEWS, ld.texi: mention new option + + ld/lexsup.c: add enumeration of --build-id STYLES to --help + + ld/testsuite/ld-elf/build-id.exp: add test case for 0xHEX case + and conditional for xx case; + also, simply tcl list syntax + + https://inbox.sourceware.org/binutils/20240917201509.GB26396@redhat.com/ + +2024-09-24 Tom de Vries + + [gdb] Handle ^C in ~scoped_remote_fd + While reviewing "catch (...)" uses I came across: + ... + try + { + fileio_error remote_errno; + m_remote->remote_hostio_close (m_fd, &remote_errno); + } + catch (...) + { + /* Swallow exception before it escapes the dtor. If + something goes wrong, likely the connection is gone, + and there's nothing else that can be done. */ + } + ... + + This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't + know whether these can actually happen here, but if not it's better to + accommodate for the possibility anyway. + + Fix this by handling gdb_exception_quit and gdb_exception_forced_quit + explicitly. + + It could be that "catch (...)" should be replaced by + "catch (const gdb_exception &)" but that depends on what kind of exception + remote_hostio_close is expected to throw, and I don't know that, so I'm + leaving it as is. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Felix Willgerodt + + btrace: Add support for further events. + This is similar to the previous events that we added, and adds support for + SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET. + Though since these are mainly mechanical and not really possible to test, + they are bundled in one commit. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add support for IRET events. + This is similar to the previous events that we added. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add support for interrupt events. + Newer Intel CPUs support recording asynchronous events in the PT trace. + Libipt also recently added support for decoding these. + + This patch adds support for interrupt events, based on the existing aux + infrastructure. GDB can now display such events during the record + instruction-history and function-call-history commands. + + Subsequent patches will add the rest of the events currently supported. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Enable event tracing on Linux for Intel PT. + Event tracing allows GDB to show information about interesting asynchronous + events when tracing with Intel PT. Subsequent patches will add support for + displaying each type of event. + + Enabling event-tracing unconditionally would result in rather noisy output, as + breakpoints themselves result in interrupt events. Which is why this patch adds + a set/show command to allow the user to enable/disable event-tracing before + starting a recording. The event-tracing setting has no effect on an already + active recording. The default setting is off. As event tracing will use the + auxiliary infrastructure added by ptwrite, the user can still disable printing + events, even when event-tracing was enabled, by using the /a switch for the + record instruction-history/function-call-history commands. + + Reviewed-By: Eli Zaretskii + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add printing support for cfe and evd packets. + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Print "non-contiguous" for gaps. + So far we printed "disabled" for gaps, when we saw a ptev_enabled event that + doesn't have the resumed flag set. This is wrong, as the actual disabling + happens with ptev_disabled. So far this didn't matter, but once we have event + tracing, there can be events between a ptev_disabled and a ptev_enabled. + This patch is in preparation for that, and removes the disabled reason in + favour of a more accurate non-contiguous reason, and adjusts the string we + print accordingly. + + Approved-By: Markus Metzger + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in pipe_command + Remove duplicate code in pipe_command using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in target_wait + Remove duplicate code in target_wait using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in execute_fn_to_string + Remove duplicate code in execute_fn_to_string using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Make scope_exit constructor throw + While reviewing "catch (...)" uses I came across: + ... + scope_exit (EFP &&f) + try : m_exit_function ((!std::is_lvalue_reference::value + && std::is_nothrow_constructible::value) + ? std::move (f) + : f) + { + } + catch (...) + { + /* "If the initialization of exit_function throws an exception, + calls f()." */ + f (); + } + + ... + and while looking up the origin of the comment here [1] I saw right after: + ... + throws: Nothing, unless the initialization of exit_function throws + ... + + I think that means that the exception should be rethrown, so fix this by doing + so. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf + +2024-09-24 Tom de Vries + + [gdb] Handle ^C in gnu_source_highlight_test + In gnu_source_highlight_test we have: + ... + try + { + res = try_source_highlight (styled_prog, language_c, fullname); + } + catch (...) + { + saw_exception = true; + } + ... + + This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't + know whether these can actually happen here, but if not it's better to + accommodate for the possibility anyway. + + Fix this by handling gdb_exception explicitly, and rethrowing + gdb_exception_quit and gdb_exception_forced_quit. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/cli] Show readline wrapping mode for maint info screen + With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC + as used in commit 250f1bbaf33 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with + wrapping disabled"), we can easily reproduce a failure in + gdb.tui/wrap-line.exp mentioned in PR testsuite/31201: + ... + (gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678 ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout) + ... + + The test-case expects wrapping, but that's disabled by horizontal-scroll-mode. + + Add a new line to "maint info screen", that describes the current readline + wrapping mode, and use it in the test-case to handle the different cases. + + The reported values for the wrapping mode are as follows. + + Unsupported because of running in batch mode: + ... + $ gdb -q -batch -ex "maint info screen" + Readline wrapping mode: unsupported (gdb batch mode). + ... + + Unsupported because the terminal is not capable to move the cursor up: + ... + $ TERM=dumb gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: unsupported (terminal is not Cursor Up capable). + ... + + Disabled by horizontal-scroll-mode: + ... + $ grep horizontal-scroll-mode ~/.inputrc + set horizontal-scroll-mode on + $ gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: disabled (horizontal-scroll-mode). + ... + + Wrap done by readline because terminal is not auto wrap capable: + ... + $ TERM=ansi gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved). + ... + + Wrap done by terminal autowrap: + ... + $ TERM=xterm gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: terminal (terminal is auto wrap capable). + ... + + Tested on x86_64-linux. + + Co-Authored-By: Bernd Edlinger + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201 + +2024-09-24 Tom de Vries + + [gdb/python] Use gdbpy_handle_gdb_exception in valpy_assign_core + In valpy_assign_core we have: + ... + catch (const gdb_exception &except) + { + gdbpy_convert_exception (except); + return false; + } + ... + + Use instead: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (false, except); + } + ... + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Eliminate GDB_PY_SET_HANDLE_EXCEPTION + Result of: + ... + $ search="GDB_PY_SET_HANDLE_EXCEPTION (" + $ replace="return gdbpy_handle_gdb_exception (-1, " + $ sed -i \ + "s/$search/$replace/" \ + gdb/python/*.c + ... + + Also remove the now unused GDB_PY_SET_HANDLE_EXCEPTION. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Eliminate GDB_PY_HANDLE_EXCEPTION + Result of: + ... + $ search="GDB_PY_HANDLE_EXCEPTION (" + $ replace="return gdbpy_handle_gdb_exception (nullptr, " + $ sed -i \ + "s/$search/$replace/" \ + gdb/python/*.c + ... + + Also remove the now unused GDB_PY_HANDLE_EXCEPTION. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Add gdbpy_handle_gdb_exception + I've recently committed two patches: + - commit 2f8cd40c37a ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often") + - commit fbf8e4c35c2 ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often") + which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION + more often, with the goal of making things more consistent. + + Having done that, I wondered if a better approach could be possible. + + Consider GDB_PY_HANDLE_EXCEPTION: + ... + /* Use this in a 'catch' block to convert the exception to a Python + exception and return nullptr. */ + #define GDB_PY_HANDLE_EXCEPTION(Exception) \ + do { \ + gdbpy_convert_exception (Exception); \ + return nullptr; \ + } while (0) + ... + + The macro nicely codifies how python handles exceptions: + - setting an error condition using some PyErr_Set* variant, and + - returning a value implying that something went wrong + presumably with the goal that using the macro will mean not accidentally: + - forgetting to return on error, or + - returning the wrong value on error. + + The problems are that: + - the macro hides control flow, specifically the return statement, and + - the macro hides the return value. + + For example, when reading somewhere: + ... + catch (const gdb_exception &except) + { + GDB_PY_HANDLE_EXCEPTION (except); + } + ... + in order to understand what this does, you have to know that the macro + returns, and that it returns nullptr. + + Add a template gdbpy_handle_gdb_exception: + ... + template + [[nodiscard]] T + gdbpy_handle_gdb_exception (T val, const gdb_exception &e) + { + gdbpy_convert_exception (e); + return val; + } + ... + which can be used instead: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (nullptr, except); + } + ... + + [ Initially I tried this: + ... + template + [[nodiscard]] auto + gdbpy_handle_gdb_exception (const gdb_exception &e) + { + gdbpy_convert_exception (e); + return val; + } + ... + with which the usage is slightly better looking: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (except); + } + ... + but I ran into trouble with older gcc compilers. ] + + While still a single statement, we now have it clear: + - that the statement returns, + - what value the statement returns. + + [ FWIW, this could also be handled by say: + ... + - GDB_PY_HANDLE_EXCEPTION (except); + + GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr); + ... + but I still didn't find the fact that it returns easy to spot. + + Alternatively, this is the simplest form we could use: + ... + return gdbpy_convert_exception (e), nullptr; + ... + but the pairing would not necessarily survive a copy/paste/edit cycle. ] + + Also note how making the value explicit makes it easier to check for + consistency: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (-1, except); + } + + if (PyErr_Occurred ()) + return -1; + ... + given that we do use the explicit constants almost everywhere else. + + Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify + the return value, but I assume that this will be generally copy-pasted and + therefore present no problem. + + Also, there's no longer a guarantee that there's an immediate return, but I + assume that nodiscard making sure that the return value is not silently + ignored is sufficient mitigation. + + For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION + in terms of gdbpy_handle_gdb_exception. + + Follow-up patches will eliminate the macros. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/symtab] Fix segfault on invalid debug info + While looking at PR symtab/31478 (a problem in the cooked indexer with invalid + dwarf) it occurred to me that I could trigger a similar problem using: + ... + Compilation Unit @ offset 0xb2: + Length: 0x1f (32-bit) + Version: 4 + Abbrev Offset: 0x6c + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_low_pc : 0x4004a7 + DW_AT_high_pc : 0x4004b2 + DW_AT_specification: <0xd5> + <1>: Abbrev Number: 0 + Compilation Unit @ offset 0xd5: + Length: 0x7 (32-bit) + Version: 4 + Abbrev Offset: 0x7f + Pointer Size: 8 + ... + and indeed I get: + ... + $ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2 + + Fatal signal: Segmentation fault + ... + + The problem is that we're calling prepare_one_comp_unit with cu == nullptr and + comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists: + ... + cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false, + m_index_storage->get_abbrev_cache ()); + + prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die, + language_minimal); + ... + + Fix this by bailing out for various types of dummy CUs: + ... + if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr + || !new_reader.comp_unit_die->has_children) + return nullptr; + ... + + Also make sure in scan_attributes that this triggers a dwarf error: + ... + $ gdb -q -batch dw2-inter-cu-error-2 + DWARF Error: cannot follow reference to DIE at 0xd5 \ + [in module dw2-inter-cu-error-2] + ... + + With target board readnow, the test-case triggers an assertion failure in + follow_die_offset, so fix this by throwing the same dwarf error. + + While we're at it, make the other check for dummy CUs in + cooked_indexer::ensure_cu_exists more robust by adding an intermediate test + for comp_unit_die: + ... + - if (result->dummy_p || !result->comp_unit_die->has_children) + + if (result->dummy_p || result->comp_unit_die == nullptr + + || !result->comp_unit_die->has_children) + return nullptr; + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/symtab] Use expand_all_symtabs in maint expand-symtabs + When issuing a command "maint expand-symtabs", maintenance_expand_symtabs is + called with regexp == nullptr, and calls expand_symtabs_matching like so: + ... + objfile->expand_symtabs_matching + ([&] (const char *filename, bool basenames) + { + /* KISS: Only apply the regexp to the complete file name. */ + return (!basenames + && (regexp == NULL || re_exec (filename))); + }, + ... + + To expand all symtabs gdb usually uses expand_all_symtabs (used for -readnow), + but here we try to handle it in the filename_matcher argument. + + Make this more similar to how gdb usually works by using expand_all_symtabs. + + A previous version of the patch instead used a nullptr filename_matcher for + the regexp == nullptr case. That approach regressed test-cases + gdb.dwarf2/dwz-unused-pu.exp and gdb.dwarf2/dw2-dummy.exp. + + Tested on x86_64-linux. + +2024-09-24 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.exp + Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol + from an unused PU is not accessible. + + Passes with the relevant target boards: + - unix (using the cooked index), + - readnow (using no index at all), + - cc-with-gdb-index (using .gdb_index), and + - cc-with-debug-names (using .debug_names). + + Tested on x86_64-linux. + +2024-09-24 Tom de Vries + + [gdb/symtab] Don't expand non-Ada CUs for info exceptions + I noticed when running test-case gdb.ada/info_exc.exp with glibc debug info + installed, that the "info exceptions" command that lists all Ada exceptions + also expands non-Ada CUs, which includes CUs in + /lib64/ld-linux-x86-64.so.2 and /lib64/libc.so.6. + + Fix this by: + - adding a new lang_matcher parameter to the expand_symtabs_matching + function, and + - using that new parameter in the expand_symtabs_matching call in + ada_add_global_exceptions. + + The new parameter is a hint, meaning implementations are free to ignore it and + expand CUs with any language. This is the case for partial symtabs, I'm not + sure whether it makes sense to implement support for this there. + + Conversely, when processing a CU with language C and name "" + (as produced by GCC LTO), the CU may not really have a single language and we + should ignore the lang_matcher. See also commit d2f67711730 + ("Fix 'catch exception' with -flto"). + + Now that we have lang_matcher available, also use it to limit name splitting + styles and symbol matchers to those applicable to the matched languages. + + Without this patch we have (with a gdb build with -O0): + ... + $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null + real 0m1.866s + user 0m2.089s + sys 0m0.120s + ... + and with this patch we have: + ... + $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null + real 0m0.469s + user 0m0.777s + sys 0m0.051s + ... + + Or, to put it in terms of number of CUs, we have 1853 CUs: + ... + $ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \ + -ex start \ + -ex "maint info symtabs" \ + | grep -c " name " + 1853 + ... + + Without this patch, we have: + ... + $ gdb -q -batch outputs/gdb.ada/info_exc/foo \ + -ex start \ + -ex "info exceptions" \ + -ex "maint info symtabs" \ + | grep -c " name " + 1393 + ... + so ~75% of the CUs is expanded, and with this patch we have: + ... + $ gdb + 20 + ... + so ~1% of the CUs is expanded. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR symtab/32182 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182 + +2024-09-24 Rohr, Stephan + + testsuite, threads: fix LD_LIBRARY_PATH in 'tls-sepdebug.exp' + Some compilers (e.g. the Intel compiler) may dynamically link against + dependencies. The test uses the 'set env' command to set the + LD_LIBRARY_PATH to a test specific value. Update the 'set env' command + to also provide the users LD_LIBARY_PATH to gdb. + + Approved-By: Tom Tromey + +2024-09-24 Mark Harmstone + + ld/pdb: Handle DEBUG_S_INLINEELINES data + The DEBUG_S_INLINEELINES block in the .debug$S section records the line + numbers in a source file covered by inlined functions. It's similar to + the DEBUG_S_LINES block, but as it references LF_FUNC_ID types we also + need to parse it to remap the type numbers. + +2024-09-24 GDB Administrator + + Automatic date update in version.in + +2024-09-23 H.J. Lu + + x86: Enable TLS relocation check only for ELF + Since TLS relocation check is ELF specific, enable it only for ELF. + + PR gas/32022 + * config/tc-i386.c (x86_tls_error_type): Define only if + OBJ_MAYBE_ELF or OBJ_ELF is defined. + (x86_check_tls_relocation): Likewise. + (x86_report_tls_error): Likewise. + (i386_assemble): Check TLS relocations only if OBJ_MAYBE_ELF or + OBJ_ELF is defined. + (md_show_usage): Output -mtls-check= only if OBJ_MAYBE_ELF or + OBJ_ELF is defined. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Avoid large timeout in gdb.base/checkpoint.exp + I ran the testsuite in an environment simulating a stressed system, and the + only test-cases that timed out in gdb.base were gdb.base/checkpoint.exp and + gdb.base/checkpoint-ns.exp (which includes gdb.base/checkpoints.exp). + + In test-case gdb.base/checkpoint.exp there's a part where the timeout is + increased with 120 seconds (in the default case that's from 10 to 130), to + accommodate for a single command creating 600+ checkpoints. + + Instead, rewrite the test to present a gdb prompt each time a checkpoint is + created, for which the default timeout is sufficient. + + Also ensure that the amount of checkpoints added is exactly 600 rather than + 600+. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-23 Tom Tromey + + Automatically add types to Python modules + PR python/32163 points out that various types provided by gdb are not + added to the gdb module, so they aren't available for interactive + inspection. I think this is just an oversight. + + This patch fixes the problem by introducing a new helper function that + both readies the type and then adds it to the appropriate module. The + patch also poisons PyType_Ready, the idea being to avoid this bug in + the future. + + v2: + * Fixed a bug in original patch in gdb.Architecture registration + * Added regression test for the types mentioned in the bug + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163 + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.fortran/info-types.exp + When running the testsuite in an enviroment that simulates a stressed system, + I ran into a timeout in test-case gdb.fortran/info-types.exp: + ... + (gdb) info types^M + FAIL: gdb.fortran/info-types.exp: info types (timeout) + ... + + This is mainly due the presence of glibc debug info. + + With it installed, I get: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m35.969s + user 0m38.231s + sys 0m1.007s + ... + and without: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m4.782s + user 0m5.014s + sys 0m0.304s + ... + + Fix this by not running to main, which gets us: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m0.808s + user 0m0.789s + sys 0m0.137s + ... + + Likewise in gdb.mi/mi-sym-info.exp and gdb.mi/mi-complete.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-23 Andrew Burgess + + gdb: update comment in code_breakpoint::re_set_default + Spotted a comment in code_breakpoint::re_set_default that was added in + commit: + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + that was incorrect. The comment was not updated to take inferior + specific breakpoints into account. + + This commit just updates the comment, there's no user visible changes + after this commit. + +2024-09-23 Jan Beulich + + ld/PE: enable secrel testcases also for 64-bit Cygwin + Plus the others that are grouped there. + +2024-09-23 Jan Beulich + + ld/PE: no base relocs for section (relative) ones + Even more so than image relative (RVA) relocations, section relative + ones as well as section ones should not have base relocations created in + the final PE image. Reportedly section relative relocations will want + using for TLS support in the (Windows) compiler. + + While there also correct the names for two of the "image base" relocs. + +2024-09-23 Nick Clifton + + LD: Document use of SOURCE_DATE_EPOCH in Environment section + + Fix compile time error introduced by d774bf9b3623239a1cfa729afcf048a15da657d3 for non-ELF x86 targets + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix failure in gdb.threads/signal-sigtrap.exp + The test-case gdb.threads/signal-sigtrap.exp: + - installs a signal handler called sigtrap_handler for SIGTRAP, + - sets a breakpoint on sigtrap_handler, and + - expects the breakpoint to trigger after issuing "signal SIGTRAP". + + Usually, that happens indeed: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + ^M + Thread 1 "signal-sigtrap" hit Breakpoint 2, sigtrap_handler (sig=5)^M + 28 }^M + (gdb) PASS: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + Occasionally, I run into this failure on openSUSE Tumbleweed: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + ^M + Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M + __pthread_create_2_1 () at pthread_create.c:843^M + (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + AFAIU, the problem is in the situation that is setup before issuing that + command, by running to a breakpoint in thread_function: + ... + void *thread_function (void *arg) { + return NULL; + } + int main (void) { + pthread_t child_thread; + signal (SIGTRAP, sigtrap_handler); + pthread_create (&child_thread, NULL, thread_function, NULL); + pthread_join (child_thread, NULL); + return 0; + } + ... + + In the passing case, thread 2 is stopped in thread_function, and thread 1 is + stopped somewhere in pthread_join: + ... + (gdb) info threads^M + Id Target Id Frame ^M + 1 Thread ... (LWP ...) "signal-sigtrap" __futex_abstimed_wait_common64 () + * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () + ... + + In the failing case, thread 2 is stopped in thread_function, but thread 1 is + stopped somewhere in pthread_create: + ... + (gdb) info threads^M + Id Target Id Frame ^M + 1 Thread ... (LWP ...) "signal-sigtrap" __GI___clone3 () + * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () + ... + + What I think happens is that pthread_create blocks SIGTRAP at some point, and + if the "signal SIGTRAP" command is issued while that is the case, the signal + becomes pending and consequently there's no longer a guarantee that the signal + will be delivered to the inferior. + + Instead the signal will be handled by gdb like this: + ... + (gdb) info signals SIGTRAP + Signal Stop Print Pass to program Description + SIGTRAP Yes Yes No Trace/breakpoint trap + ... + + Fix this by adding a barrier that ensures that pthread_create is done before + we issue the "signal SIGTRAP" command. + + Likewise in test-case gdb.threads/signal-command-handle-nopass.exp. + + Using the fixed test-case, I tested my theory by explicitly blocking SIGTRAP: + ... + + sigset_t old_ss, new_ss; + + sigemptyset (&new_ss); + + sigaddset (&new_ss, SIGTRAP); + + sigprocmask (SIG_BLOCK, &new_ss, &old_ss); + + + /* Make sure that pthread_create is done once the breakpoint on + thread_function triggers. */ + pthread_barrier_wait (&barrier); + + pthread_join (child_thread, NULL); + + sigprocmask (SIG_SETMASK, &old_ss, NULL); + ... + and managed to reproduce the same failure: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + [Thread 0x7ffff7c00700 (LWP 13254) exited]^M + ^M + Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M + 0x00007ffff7c80056 in __GI___sigprocmask () sigprocmask.c:39^M + (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + Tested on x86_64-linux. + + PR testsuite/26867 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26867 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/return.exp on arm-linux + After doing pre-commit testing of some patch on arm-linux, the Linaro CI + reported: + ... + FAIL: 1 regressions: 1 improvements + + regressions.sum: + === gdb tests === + + Running gdb:gdb.base/return.exp ... + ERROR: no fileid for ccd235fdc9bf + + improvements.sum: + === gdb tests === + + Running gdb:gdb.base/return.exp ... + ERROR: no fileid for 017e9b314c5a + ... + + The problem is the call to allow_float_test. It calls gdb_exit (for arm-linux + only), and consequently kills the gdb instance setup by prepare_for_testing: + ... + if { [prepare_for_testing "failed to prepare" "return"] } { + return -1 + } + + set allow_float_test [allow_float_test] + ... + + Fix this by moving the call to allow_float_test to before prepare_for_testing. + + Tested on arm-linux and x86_64-linux. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Make parse_args error out on remaining args + I noticed that introducing a typo here in gdb.mi/mi-breakpoint-changed.exp: + ... + set bp_re [mi_make_breakpoint \ + - -number $bp_nr \ + + -nunber $bp_nr \ + -type dprintf \ + -func marker \ + -script [string_to_regexp {["printf \"arg\" \""]}]] + ... + didn't make the test fail. + + Proc mi_make_breakpoint uses parse_args, but does not check the remaining args + as parse_args suggests: + ... + proc parse_args { argset } { + parse_list 2 args $argset "-" false + + # The remaining args should be checked to see that they match the + # number of items expected to be passed into the procedure + } + ... + + We could add the missing check in mi_make_breakpoint, but I think the problem + is likely to occur again because the name parse_args does not suggest that + further action is required. + + Fix this instead by: + - copying proc parse_args to new proc parse_some_args, + - adding new proc check_no_args_left, and + - calling check_no_args_left in parse_args. + + Also be more strict in a few places where we do lassign for remaining args: + ... + lassign $args a b + ... + + There may be more arguments left in $args, so check that that's not the case + using check_no_args_left: + ... + set args [lassign $args a b] + check_no_args_left + ... + + Fix a few test-cases that trigger on the stricter checking. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + PR testsuite/32129 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/empty-host-env-vars.exp + On aarch64-linux (debian testing) with test-case + gdb.base/empty-host-env-vars.exp I ran into: + ... + (gdb) show index-cache directory^M + The directory of the index cache is "/home/linux/.cache/gdb".^M + (gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory + ... + + Without changing any environment variables, the value of the index-cache dir + is: + ... + $ gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + and the expectation of the test-case is that setting HOME to empty will + produce an empty dir, but what it actually produces is: + ... + $ HOME= gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + + There's nothing wrong with that behaviour, the dir is simply constructed using + XDG_CACHE_HOME which happens to be explictly set to its default value + $HOME/.cache [1]: + ... + $ echo $XDG_CACHE_HOME + /home/linux/.cache + ... + and indeed also setting that variable to empty gets us the expected empty dir: + ... + $ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory" + gdb: warning: Couldn't determine a path for the index cache directory. + The directory of the index cache is "". + ... + + Furthermore, the test-case assumption that setting variables to empty either + produces the original dir or an empty dir is incorrect. + + Say that XDG_CACHE_HOME has a non-default value: + ... + $ echo $XDG_CACHE_HOME + /home/linux/my-xdg-cache-home + $ gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb". + ... + then setting that variable to empty: + ... + $ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + does change the value of the dir. + + Fix this by making the test-case less specific. + + While we're at it, factor out regexps re_pre and re_post to make regexps more + readable, and use string_to_regexp to reduce quoting. + + Tested on aarch64-linux. + + PR testsuite/32132 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132 + + [1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/attach-deleted-exec.exp with NFS + With test-case gdb.base/attach-deleted-exec.exp I ran into: + ... + (gdb) attach 121552^M + Attaching to process 121552^M + Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^M + Reading symbols from /lib64/libm.so.6...^M + (No debugging symbols found in /lib64/libm.so.6)^M + Reading symbols from /lib64/libc.so.6...^M + (No debugging symbols found in /lib64/libc.so.6)^M + Reading symbols from /lib64/ld64.so.2...^M + (No debugging symbols found in /lib64/ld64.so.2)^M + 0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M + (gdb) FAIL: $exp: attach to process with deleted executable + .... + + The .nfs file indicates: + - that the file has been removed on the NFS server, and + - that the file is still open on the NFS client. + + Fix this by detecting this situation, and declaring the test for filename + /proc/PID/exe unsupported. + + Tested on: + - x86_64-linux (setup without NFS) + - ppc64le-linux (setup with NFS) + + PR testsuite/32130 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.trace/entry-values.exp on riscv64-linux + On riscv64-linux, with test-case gdb.trace/entry-values.exp I run into: + ... + (gdb) disassemble bar^M + Dump of assembler code for function bar:^M + 0x0000000000000646 <+0>: addi sp,sp,-48^M + 0x0000000000000648 <+2>: sd ra,40(sp)^M + 0x000000000000064a <+4>: sd s0,32(sp)^M + 0x000000000000064c <+6>: addi s0,sp,48^M + 0x000000000000064e <+8>: mv a5,a0^M + 0x0000000000000650 <+10>: sw a5,-36(s0)^M + 0x0000000000000654 <+14>: li a5,2^M + 0x0000000000000656 <+16>: sw a5,-20(s0)^M + 0x000000000000065a <+20>: lw a4,-20(s0)^M + 0x000000000000065e <+24>: lw a5,-36(s0)^M + 0x0000000000000662 <+28>: mv a1,a4^M + 0x0000000000000664 <+30>: mv a0,a5^M + 0x0000000000000666 <+32>: jal 0x628 ^M + 0x000000000000066a <+36>: mv a5,a0^M + 0x000000000000066c <+38>: mv a0,a5^M + 0x000000000000066e <+40>: ld ra,40(sp)^M + 0x0000000000000670 <+42>: ld s0,32(sp)^M + 0x0000000000000672 <+44>: addi sp,sp,48^M + 0x0000000000000674 <+46>: ret^M + End of assembler dump.^M + (gdb) FAIL: gdb.trace/entry-values.exp: disassemble bar + FAIL: gdb.trace/entry-values.exp: find the call or branch instruction offset in bar + ... + + Fix this by setting call_insn to jal for riscv64. + + Tested on riscv64-linux and x86_64-linux. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp + On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while + I run into (edited for readability): + ... + (gdb) ^M + -data-evaluate-expression $a^M + -data-evaluate-^done,value="\"FIRST COMMAND\""^M + expression $b(gdb) ^M + ^M + ^done,value="\"TEST COMPLETE\""^M + (gdb) ^M + PASS: $exp: args=: look for first command output, command length 236 + FAIL: $exp: args=: look for second command output, command length 236 (timeout) + ... + + This is more likely to trigger when running the test-case using + taskset -c (where in a big.little setup we pick a little cpu). + + The setup here is that the test-case issues these two commands at once: + ... + -data-evaluate-expression $a + -data-evaluate-expression $b + ... + where the length of the first command is artificially increased by prefixing + it with spaces, show as above. + + What happens is that gdb, after parsing the first command, executes it. + Then the output of the first command intermixes with the echoing of the second + command, which produces this line containing the first prompt: + ... + expression $b(gdb) ^M + ... + which doesn't match the \r\n prefix of the regexp supposed to consume the + first prompt: + ... + -re "\r\n$mi_gdb_prompt" { + ... + + Fix this by dropping the \r\n prefix. + + Tested on aarch64-linux. + + PR testsuite/29781 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781 + +2024-09-23 GDB Administrator + + Automatic date update in version.in + +2024-09-22 H.J. Lu + + x86: Turn PLT32 to PC32 only for PC-relative relocations + commit 292676c15a615b5a95bede9ee91004d3f7ee7dfd + Author: H.J. Lu + Date: Thu Feb 13 13:44:17 2020 -0800 + + x86: Resolve PLT32 reloc aganst local symbol to section + + resolved PLT32 relocation against local symbol to section and + + commit 2585b7a5ce5830e60a089aa2316a329558902f0c + Author: H.J. Lu + Date: Sun Jul 19 06:51:19 2020 -0700 + + x86: Change PLT32 reloc against section to PC32 + + turned PLT32 relocation against section into PC32 relocation. But these + transformations are valid only for PC-relative relocations. Add fx_pcrel + check for PC-relative relocations when performing these transformations + to keep PLT32 relocation in `movq $foo@PLT, %rax`. + + gas/ + + PR gas/32196 + * config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel + for PLT32 relocations. + (i386_validate_fix): Turn PLT32 relocation into PC32 relocation + only if fixp->fx_pcrel is set. + * testsuite/gas/i386/reloc32.d: Updated. + * testsuite/gas/i386/reloc64.d: Likewise. + * testsuite/gas/i386/reloc32.s: Add PR gas/32196 test. + * testsuite/gas/i386/reloc64.s: Likewise. + + ld/ + + PR gas/32196 + * testsuite/ld-x86-64/plt3.s: New file. + * testsuite/ld-x86-64/x86-64.exp: Run plt3. + +2024-09-22 GDB Administrator + + Automatic date update in version.in + +2024-09-21 Tom de Vries + + [gdb/testsuite] Limit xfail in gdb.ada/call_pn.exp + Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only + necessary for gcc 8 and 9. + + Fix this by limiting the xfail to those releases. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-21 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.ada/call_pn.exp + With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into + this timeout: + ... + (gdb) maint expand-symtabs^M + FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout) + ... + + The timeout was related to running the cpu at base frequency of 400Mhz instead + of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core). + + But when investigating the test-case I realized that the maint expand-symtabs + could be limited to the source files, so use that to speed up the test-case. + + Tested on x86_64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR testsuite/32177 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177 + +2024-09-21 Tom de Vries + + [gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-cases + When running the testsuite in an enviroment simulating a stressed system, I + ran into timeouts in three test-cases in gdb.dwarf2: + - gdb.dwarf2/count.exp, + - gdb.dwarf2/implptrconst.exp, and + - gdb.dwarf2/implptrpiece.exp. + + In all three cases, -readnow is used which results in symtabs being expanded for + the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2. + + We could address this by limiting the scope of -readnow to the executable, but + after reviewing the test-cases there doesn't seem to be a clear reason to use + -readnow. + + Fix this by dropping the -readnow. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-21 GDB Administrator + + Automatic date update in version.in + +2024-09-20 Cui, Lili + + x86: Add tls check in gas + Assembler shouldn't accept invalid TLS instructions, TLS relocations + can only be used with specific instructions as specified in TLS psABI + and linker issues an error when TLS relocations are used with wrong + instructions or format. Since it is inconvenient for gcc to rely on + linker to report errors, adding TLS check in the assembler stage so + that gcc can know TLS errors earlier. + + gas/ChangeLog: + + PR gas/32022 + * config.in: Regenerate. + * config/tc-i386.c + *(enum x86_tls_error_type): New. + *(struct _i386_insn): Added has_gotrel to indicate whether TLS + relocations need to be checked. + (x86_check_tls_relocation): Added a new function to check TLS + relocation. + (x86_report_tls_error): Created a new function to report TLS error. + (i386_assemble): Handle x86_check_tls_relocation. + (lex_got): Set i.has_gotrel. + (OPTION_MTLS_CHECK): Added a new option to contrl TLS check. + (struct option): Ditto. + (md_parse_option): Ditto. + (md_show_usage): Ditto. + * configure.ac: Added a new option to check TLS relocation by + default. + * configure: Regenerated. + * doc/c-i386.texi: Document -mtls-check=. + * testsuite/gas/i386/i386.exp: Added new tests. + * testsuite/gas/i386/ilp32/ilp32.exp: Ditto. + * testsuite/gas/i386/ilp32/reloc64.d: Disable TLS check for it. + * testsuite/gas/i386/ilp32/x32-tls.d: Ditto. + * testsuite/gas/i386/inval-tls.l: Added more test cases. + * testsuite/gas/i386/inval-tls.s: Ditto. + * testsuite/gas/i386/reloc32.d: Disable TLS check for it. + * testsuite/gas/i386/reloc64.d: Ditto. + * testsuite/gas/i386/x86-64-inval-tls.l: Added more test cases. + * testsuite/gas/i386/x86-64-inval-tls.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Added new tests. + * testsuite/gas/i386/ilp32/x32-inval-tls.l: New test. + * testsuite/gas/i386/ilp32/x32-inval-tls.s: Ditto. + * testsuite/gas/i386/ilp32/x86-64-tls.d: Ditto. + * testsuite/gas/i386/tls.d: Ditto. + * testsuite/gas/i386/tls.s: Ditto. + * testsuite/gas/i386/x86-64-tls.d: Ditto. + * testsuite/gas/i386/x86-64-tls.s: Ditto. + + ld/ChangeLog: + + PR gas/32022 + * testsuite/ld-i386/tlsgdesc1.d: Disable TLS check for it. + * testsuite/ld-i386/tlsgdesc2.d: Ditto. + * testsuite/ld-i386/tlsie2.d: Ditto. + * testsuite/ld-i386/tlsie3.d: Ditto. + * testsuite/ld-i386/tlsie4.d: Ditto. + * testsuite/ld-i386/tlsie5.d: Ditto. + * testsuite/ld-i386/tlsgdesc3.d: Ditto. + * testsuite/ld-x86-64/tlsdesc3.d: Ditto. + * testsuite/ld-x86-64/tlsdesc4.d: Ditto. + * testsuite/ld-x86-64/tlsie2.d: Ditto. + * testsuite/ld-x86-64/tlsie3.d: Ditto. + * testsuite/ld-x86-64/tlsie5.d: Ditto. + * testsuite/ld-x86-64/tlsdesc5.d: Ditto. + +2024-09-20 H.J. Lu + + ld: Use --no-rosegment to ld for PR ld/22393 tests + The commit + + bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map + + moves the .note.build-id section before text sections. When --rosegment + and -z separate-code are used together, the .note.gnu.property section + is placed between the .note.build-id section and text sections in the + same PT_LOAD segment by orphan placement. Pass --no-rosegment to ld for + PR ld/22393 tests to avoid linker test failures. + + PR ld/32190 + * testsuite/ld-elf/pr22393-2a.rd: Pass --no-rosegment to ld. + * testsuite/ld-elf/pr22393-2b.rd: Likewise. + * testsuite/ld-elf/shared.exp: Pass --no-rosegment to ld when + building pr22393-2 tests. + * testsuite/ld-x86-64/pr22393-3a.rd: Pass --no-rosegment to ld. + * testsuite/ld-x86-64/pr22393-3b.rd: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Pass --no-rosegment to ld when + building pr22393-3 tests. + +2024-09-20 Guinevere Larsen + + gdb: fully separate coff and elf reading from dbx + With the previous commits, the only thing entangling elf and coff file + reading with dbx file reading is the functions + {elf|coff}stab_build_psymtabs, defined in dbxread.c. These functions + depend on dbx_symfile_read. + + To solve this, I renamed read_stabs_symtab to read_stabs_symtab_1, and + created a function with the original name that does what + dbx_symfile_read used to do. + + This way, dbx_symfile_read can just call read_stabs_symtab, and the elf + and coff psymtab builders can also call it directly, fully disentangling + the readers, which would allow us to selectively not compile dbxread in + the future. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move read_dbx_symtab to stabsread, and rename to read_stabs_symtab + Despite the name, read_dbx_symtab is not only used for the dbx file + format (also called the aout format). It is used by elf and coff + implicitly as well. So I think it makes more sense to have this function + in the generic stabsread file, so that reading elf files or coff files + depends less on GDB's ability to read dbx files. + + There were 11 static functions in dbxread that were onlyl helper + functions, they were moved and kept as static in stabsread.c. Notably, + dbx_read_symtab - which is installed as a callback on legacy_psymtab + for aout, elf and coff at least - has been moved to stabsread.c and + renamed as well; the function that is specific to aout is + dbx_symfile_read, and that hasn't been moved. + + Some macros had to be moved as well, but since they are still used + in dbxread, they were moved to the .h file that the struct symloc + is declared, so anyone can properly use the struct. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move dbx_end_psymtab to stabsread, and rename to stabs_end_psymtab + This function is used by multiple stabs readers (even if not all), and + the comment in stabsread.h even acknowledges it. I believe that the + comment is incorrect in saying that the function should be in dbxread + because not everyone uses it. If any one reader other than dbx uses + it, the function should be in stabsread, in my opinion. + + This commit makes also renames the function to stabs_end_psymtab since, + again, this is not specific to dbx/aout format. + + struct symloc had to be moved because stabs_end_psymtab dereferences + symloc objects, so stabsread.c must be aware of the full struct. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move process_one_symbol to stabsread.c + The function process_one_symbol was defined in the file dbxread.c, but + this function is used by all file formats that handle stabs debug + information. It makes much more sense for it to be in the stabsread.c + file instead. + + To move that function, many other static functions had to be moved from + dbxread. A few were only used by process_one_symbol, so they're still + static, but most were used by other functions still in dbxread, so they + are being exported by stabsread.h + + Finally, the registry entry has been moved as well, seeing as it was + already exported by gdb-stabs.h, and stabsread.c will need it to + properly use the newly added function. + + With this change, reading mdebug files is totally independent of reading + dbx. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Make dbxread rely less on global variables + The file dbxread.c, which is responsible for reading stabs information + for multiple file formats, relies heavily on setting and using global + variables over the course of reading symbols. + + Future patches aim to make stabs reading more file format independent, + and this patch starts that change by introducing a stabs_context struct, + that will hold all the relevant variables. This context struct is saved + on the registry key inside the objfile being read. Some of those global + variables have been deemed irrelevant: + * dbxread_objfile - Since we're saving in an objfile, this is redundant + * symfile_bfd - It is trivial to get the bfd pointer from the objfile, + so also unnecessary + * string_table_offset - was never initialized, just used to set a value. + That usage was substituted by a hardcoded 0 + * next_file_string_table_offset - was only used by read_dbx_symtab, so + it was turned into a local variable there. + + As I was moving variables, I also couldn't think of a good reason for + the bincl_list to be a pointer, so it was changed to just be an + std::vector. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb/testsuite: rework bp-cond-failure to not depend on inlining + The test gdb.base/bp-cond-failure is implicitly expecting that the + function foo will be inlined twice and gdb will be able to find 2 + locations to place a breakpoint. When clang is used, gdb only finds + one location which causes the test to fail. Since the test is not + worried about handling breakpoints on inlined functions, but rather on + the format of the message on a breakpoint condition fail, this seems + like a false fail report. + + This commit reworks the test to be in c++, and uses function overloading + to ensure that 2 locations will always be found. Empirical testing + showed that, for clang, we will land on location 2 with the currest exp + commands, no matter the order of the functions declared, whereas for gcc + it depends on the order that functions were declared, so they are + ordered to always land on the second location, this way we are able to + hardcode it and check for it. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-09-20 H.J. Lu + + ld: Change -z one-rosegment to --rosegment in comments + There is no such linker command-line option, -z one-rosegment. Replace + it with --rosegment in comments. + + * genscripts.sh: Change -z one-rosegment to --rosegment in + comments. + +2024-09-20 GDB Administrator + + Automatic date update in version.in + +2024-09-20 H.J. Lu + + x86-64: Disable PIE on PR gas/32189 test + Disable PIE on PR gas/32189 test, which contains the non-PIE assembly + source, to support GCC defaulted to PIE. + + PR gas/32189 + * testsuite/ld-x86-64/x86-64.exp: Pass $NOPIE_LDFLAGS to linker + on PR gas/32189 test. + +2024-09-19 H.J. Lu + + x86-64: Never make R_X86_64_GOT64 section relative + R_X86_64_GOT64 relocation should never be made section relative. Change + tc_i386_fix_adjustable to return 0 for BFD_RELOC_X86_64_GOT64. + + gas/ + + PR gas/32189 + * config/tc-i386.c (tc_i386_fix_adjustable): Return 0 for + BFD_RELOC_X86_64_GOT64. + * testsuite/gas/i386/reloc64.d: Updated. + * testsuite/gas/i386/reloc64.s: Add more tests for R_X86_64_GOT64 + and R_X86_64_GOTOFF64. + + ld/ + + PR gas/32189 + * testsuite/ld-x86-64/x86-64.exp: Run PR gas/32189 test. + * testsuite/ld-x86-64/pr32189.s: New file. + +2024-09-19 Guinevere Larsen + + gdb/MAINTAINERS: update my email address + Sync the maintainers file with my new email address + +2024-09-19 Nick Clifton + + ld: Move the .note.build-id section to near the start of the memory map. + This helps GDB to locate the debug information associated with a core dump. + Core dumps include the first page of an executable's image, and if this + page include the .note.build-id section then GDB can find it and then track + down a debug info file for that build-id. + +2024-09-19 Vladimir Mezentsev + + Fix 32096 UBSAN issues in gprofng + Fixed UBSAN runtime errors such as: + - member call on address which does not point to an object of type 'Vector' + - load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte alignment + + gprofng/ChangeLog + 2024-09-17 Vladimir Mezentsev . + + PR gprofng/32096 + * libcollector/unwind.c: Fix UBSAN runtime errors. + * src/CallStack.cc (add_stack_java, add_stack_java_epilogue): + Change argument type to Vector*. + * src/Experiment.cc (update_ts_in_maps): Change variable type. + * src/Experiment.h: Change field type to Vector*. + +2024-09-19 GDB Administrator + + Automatic date update in version.in + +2024-09-18 Xin Wang + + LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata + LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata. + +2024-09-18 H.J. Lu + + x86/APX: Don't promote AVX/AVX2 instructions out of APX spec + V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted + to support EGPR in APX spec. Don't promote them out of APX spec. This + commit effectively reverted: + + ec3babb8c10 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed + 5a635f1f59a x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} + eea4357967b x86/APX: VROUND{P,S}{S,D} can generally be encoded + + gas/ + + PR gas/32171 + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add + V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove + V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests + with EGPR. + * testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. + + opcodes/ + + PR gas/32171 + * i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and + VROUND{P,S}{S,D} entries with EGPR. + * i386-tbl.h: Regenerated. + +2024-09-18 GDB Administrator + + Automatic date update in version.in + +2024-09-17 Guinevere Larsen + + gdb/testsuite: skip gdb.mi/dw2-ref-missing-frame.exp with clang + The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set + debug information by hand, using a .S file and assembly labels to get + addresses. Unfortunately, clang will always re-arrange the global labels + to be side by side, making high and low PC for CUs and functions be the + same, and thus they will all be empty ranges. This makes the test fail, + since we never technically enter the functions that we want to check. + + This commit skips that test when using clang. If we ever port this test + to use the dwarf assembler, we can reenable it with clang. + + Approved-By: Tom Tromey + +2024-09-17 Guinevere Larsen + + gdb/testsuite: fix gdb.mi/mi-var-cp.exp with clang + The inline tests in gdb.mi/mi-var-cp.cc were failing when using clang to + run the test. This happened because inline tests want to step past the C + statements and then run the TCL tests, but in mi-var-cp.cc the statement + to be stepped past is "return s2.i;". Since clang links the epilogue + information to the return statement, not the closing brace, + single-stepping past return had us exiting the function - which made the + expressions invalid. + + This commit fixes this by making the function have 2 C statements, and + the return one be after all inline tests, so we know GDB won't leave the + function before running the create_varobj tests. + + Approved-By: Tom Tromey + +2024-09-17 Guinevere Larsen + + gdb/testsuite: fix gdb.mi/mi-catch-cpp-exceptions.exp with clang + Clang adds line table information for a try/catch block differently to + gcc. Instead of linking the instructions related to __cxa_begin_catch to + the line containing the "catch" statement in the source code, it links + to the closing brace of the try block. + + This was causing gdb.mi/mi-catch-cpp-exceptions.exp to fail when tested + with clang. The test was updated to have the catch in the same line as + the closing brace so it passes with no additional modifications with + clang. + + Approved-By: Tom Tromey + +2024-09-17 GDB Administrator + + Automatic date update in version.in + +2024-09-16 Tom Tromey + + Fix typo in py-arch.exp + I found a typo in a test name in py-arch.exp. + +2024-09-16 GDB Administrator + + Automatic date update in version.in + +2024-09-15 Maciej W. Rozycki + + MIPS/GAS: Discard redundant instruction from DDIV/DREM macros + A sequence such as: + + li at,-1 + bne xx,at,0f + li at,1 + dsll32 at,at,0x1f + + is produced in the expansion of the DDIV and DREM assembly macros, where + a redundant `li at,1' instruction is used to load an intermediate value + of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f' + yielding 0x8000000000000000. However this value likewise results from + left-shifting the value of -1, already present in $at at this point. + + Remove the extraneous instruction then, shortening the sequence emitted. + Adjust dumps in the testsuite accordingly. + +2024-09-15 Maciej W. Rozycki + + MIPS/GAS/testsuite: Print instructions in hex in division tests + Add `--show-raw-insn' to division tests so as to verify branch offsets + without the need to know actual offsets into the text section individual + instructions have been assembled at. Add `-z' where applicable to make + interlock NOP instructions appear in output so as to verify them without + the need to know the offsets too. Replace individual offsets to match + against with generic patterns so that a change in the expansion of an + assembly macro does not affect code that follows. + + MIPS/opcodes: Rework documentation for instruction args + Rewrite the inline documentation for the characters used in the `args' + member of `struct mips_opcode' to make it consistent in terms of style + and formatting. Discard references to inexistent macros. + +2024-09-15 Simon Marchi + + gdb: fix amd_dbgapi_target_breakpoint::re_set's signature + Following + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + ... when building amd-dbgapi-target.c: + + CXX amd-dbgapi-target.o + /home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override + 486 | void re_set () override; + | ^~~~~~ + + Update the signature to match the base. + + Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692 + +2024-09-15 GDB Administrator + + Automatic date update in version.in + +2024-09-14 Tom de Vries + + [gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner" + After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds + this debug info: + ... + <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type) + <120> DW_AT_specification: <0x130> + <2><124>: Abbrev Number: 4 (DW_TAG_enumerator) + <125> DW_AT_name : val1 + <12a> DW_AT_const_value : 1 + <2><12b>: Abbrev Number: 0 + <1><12c>: Abbrev Number: 5 (DW_TAG_namespace) + <12d> DW_AT_name : ns + <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type) + <131> DW_AT_name : e + <133> DW_AT_type : <0x118> + <137> DW_AT_declaration : 1 + ... + I run into an assertion failure: + ... + (gdb) file enum-type^M + Reading symbols from enum-type...^M + cooked-index.h:214: internal-error: get_parent: \ + Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M + ... + + This was reported in PR32160 comment 1. + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Fix this by reverting the commit. + + [ Also drop the kfails for PR31900 and PR32158, which are regressions by that + same commit. ] + + That allows us to look at the output of "maint print objfiles", and for val1 + we get an entry without parent: + ... + [27] ((cooked_index_entry *) 0x7fbbb4002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x124 + parent: ((cooked_index_entry *) 0) + ... + which is incorrect, as noted in that same comment, but an improvement over the + assertion failure, and I don't think that ever worked. This is to be + addressed in a follow-up patch. + + Reverting the commit begs the question: what was it trying to fix in the first + place, and do we need a different fix? I've investigated this and filed + PR32160 to track this. + + My guess is that the commit was based on a misunderstand of what we track + in cooked_indexer::m_die_range_map. + + Each DIE has two types of parent DIEs: + - a DIE that is the parent as indicated by the tree structure in which DIEs + occur, and + - a DIE that represent the parent scope. + + In most cases, these two are the same, but some times they're not. + + The debug info above demonstrates such a case. The DIE at 0x11f: + - has a tree-parent: the DIE representing the CU, and + - has a scope-parent: DIE 0x12c representing namespace ns. + + In cooked_indexer::m_die_range_map, we track scope-parents, and the commit + tried to add a tree-parent instead. + + So, I don't think we need a different fix, and propose we backport the reversal + for gdb 15.2. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160 + +2024-09-14 Tom de Vries + + [gdb/testsuite] Add regression test for PR32158 + Consider test-case: + ... + namespace ns { + enum class ec { + val2 = 2 + }; + } + + int main () { + return (int)ns::ec::val2; + } + ... + compiled with debug info: + ... + $ g++ test.c -g + ... + + When looking at the cooked index entry for val2 using "maint print objfiles", + we get: + ... + [7] ((cooked_index_entry *) 0x7f8ecc002ef0) + name: val2 + canonical: val2 + qualified: ns::val2 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xe9 + parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns] + ... + which is wrong, there is no source level entity ns::val2. + + This is PR symtab/32158. + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Reverting the commit on current trunk fixes the problem, and gets us instead: + ... + [7] ((cooked_index_entry *) 0x7fba70002ef0) + name: val2 + canonical: val2 + qualified: ns::ec::val2 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xe9 + parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec] + ... + + Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158 + +2024-09-14 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900. + Consider the following test-case: + ... + $ cat a.h + namespace ns { + + class A { + public: + enum { + val1 = 1 + }; + }; + + } + $ cat main.c + + ns::A a; + + int + main (void) + { + return 0; + } + $ cat val1.c + + int u1 = ns::A::val1; + ... + compiled with debug info: + ... + $ g++ main.c val1.c -g + ... + + When trying to print ns::A::val with current trunk and gdb 15.1 we get: + ... + $ gdb -q -batch a.out -ex "print ns::A::val1" + There is no field named val1 + ... + + This PR c++/31900. + + With gdb 14.2 we get the expected: + ... + $ gdb -q -batch a.out -ex "print ns::A::val1" + $1 = ns::A::val1 + ... + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Reverting the commit on current trunk fixes the problem. + + So how does this problem happen? + + First, let's consider the current trunk, with the commit reverted. + + Gdb looks for the entry ns::A::val1, and find this entry: + ... + [29] ((cooked_index_entry *) 0x7f7830002ef0) + name: val1 + canonical: val1 + qualified: ns::A::val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x15a + parent: ((cooked_index_entry *) 0x7f7830002ec0) [A] + ... + and expands the corresponding CU val1.c containing this debug info: + ... + <2><14a>: Abbrev Number: 3 (DW_TAG_class_type) + <14b> DW_AT_name : A + <14d> DW_AT_byte_size : 1 + <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type) + <151> DW_AT_encoding : 7 (unsigned) + <152> DW_AT_byte_size : 4 + <153> DW_AT_type : <0x163> + <159> DW_AT_accessibility: 1 (public) + <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator) + <15b> DW_AT_name : val1 + <15f> DW_AT_const_value : 1 + <4><160>: Abbrev Number: 0 + <3><161>: Abbrev Number: 0 + <2><162>: Abbrev Number: 0 + ... + after which it finds ns::A::val1 in the expanded symtabs. + + Now let's consider the current trunk as is (so, with the commit present). + + Gdb looks for the entry ns::A::val1, but doesn't find it because the val1 + entry is missing its parent: + ... + [29] ((cooked_index_entry *) 0x7f5240002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x15a + parent: ((cooked_index_entry *) 0) + ... + + Then gdb looks for the entry ns::A, and finds this entry: + ... + [3] ((cooked_index_entry *) 0x7f5248002ec0) + name: A + canonical: A + qualified: ns::A + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0xdd + parent: ((cooked_index_entry *) 0x7f5248002e90) [ns] + ... + which corresponds to this debug info, which doesn't contain val1 + due to -fno-eliminate-unused-debug-types: + ... + <2>
: Abbrev Number: 3 (DW_TAG_class_type) + DW_AT_name : A + DW_AT_byte_size : 1 + <2>: Abbrev Number: 0 + ... + + Gdb expands the corresponding CU main.c, after which it doesn't find + ns::A::val1 in the expanded symtabs. + + The root cause of the problem is the missing parent on the val1 + cooked_index_entry, but this only becomes user-visible through the + elaborate scenario above. + + Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test + for this problem that doesn't rely on expansion state or + -feliminate-unused-debug-types, but simply tests for the root cause by + grepping for ns::A::val1 in the output of "maint print objfile". + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900 + +2024-09-14 GDB Administrator + + Automatic date update in version.in + +2024-09-13 oltolm + + gdb dap: introduce stopOnEntry option + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2024-09-13 Tom Tromey + + Update more types for section index change + Commit f89276a2f3e ("change type of `general_symbol_info::m_section` + to int") did what it says in the title -- changed the type of the + section index from short to int. However, it seems incomplete, in + that there are uses of the section index that use the type 'short'. + + This patch fixes the ones I found, first by searching for + "short.*sect" and then by looking at all the callers of section_index + (and then functions called with the resulting value) just to try to be + more sure. + + Approved-by: Kevin Buettner + Approved-By: Simon Marchi + +2024-09-13 Tom Tromey + + Fix quoting in gdb-add-index.sh + When the filename quoting change was merged into the AdaCore tree, we + saw a regression in a test setup that uses the DWARF 5 index (that is + running gdb-add-index), and a filename with a space in it. + + Initially I thought this was a change in the 'file' command -- but + looking again, I found out that 'file' has worked this way for a + while, and our immediate error was caused by the (documented) change + to "save gdb-index". + + While I'm not sure why this test was working previously, it seems to + me that gdb-add-index.sh requires a change to quote the arguments to + "file" and "save gdb-index". + + While working on this, though, it seemed to me that multiple other + spots needed quoting for the script to work correctly. And, I was + unable to get quoting working correctly in the objcopy calls, so I + split it into multiple different invocations. + + Approved-by: Kevin Buettner + +2024-09-13 Tom Tromey + + Add quoting to 'file' invocations in DAP + Oleg Tolmatcev noticed that DAP launch and attach requests don't + properly handle Windows filenames, because "file" doesn't handle the + backslash characters correctly. This patch adds quoting to the + command in an attempt to fix this. + +2024-09-13 Simon Marchi + + gdb/solib: use owning_intrusive_list for solib list + Functions implementing `solib_ops::current_sos` return a list of solib + object, transferring the ownership to their callers. However, the + return type, `intrusive_list`, does not reflect that. + + Also, some of these functions build these lists incrementally, reading + this from the target for each solib. If a target read were to throw, + for instance, the already created solibs would just be leaked. + + Change `solib_ops::current_sos` to return an owning_intrusive_list to + address that. Change `program_space::so_list` to be an + owning_intrusive_list as well. This also saves us doing a few manual + deletes. + + Change-Id: I6e4071d49744874491625075136c59cce8e608d4 + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: add owning_intrusive_list + It occured to me that `intrusive_list`, as returned by + `solib_ops::current_sos`, for instance, is not very safe. The + current_sos method returns the ownership of the solib objects + (heap-allocated) to its caller, but the `intrusive_list` type + does not convey it. If a function is building an + `intrusive_list` and something throws, the solibs won't + automatically be deleted. Introduce owning_intrusive_list to fill this + gap. + + Interface + --------- + + The interface of owning_intrusive_list is mostly equivalent to + intrusive_list, with the following differences: + + - When destroyed, owning_intrusive_list deletes all element objects. + The clear method does so as well. + + - The erase method destroys the removed object. + + - The push_front, push_back and insert methods accept a `unique_ptr` + (compared to `T &` for intrusive_list), taking ownership of the + object. + + - owning_intrusive_list has emplace_front, emplace_back and emplace + methods, allowing to allocate and construct an object directly in the + list. This is really just a shorthand over std::make_unique and + insert (or push_back / push_front if you don't care about the return + value), but I think it is nicer to read: + + list.emplace (pos, "hello", 2); + + rather than + + list.insert (pos, std::make_unique ("hello", 2)); + + These methods are not `noexcept`, since the allocation or the + constructor could throw. + + - owning_intrusive_list has a release method, allowing to remove an + element without destroying it. The release method returns a + pair-like struct with an iterator to the next element in the list + (like the erase method) and a unique pointer transferring the + ownership of the released element to the caller. + + - owning_intrusive_list does not have a clear_and_dispose method, since + that is typically used to manually free items. + + Implementation + -------------- + + owning_intrusive_list privately inherits from intrusive_list, in order + to re-use the linked list machinery. It adds ownership semantics around + it. + + Testing + ------- + + Because of the subtle differences in the behavior in behavior and what + we want to test for each type of intrusive list, I didn't see how to + share the tests for the two implementations. I chose to copy the + intrusive_list tests and adjust them for owning_intrusive_list. + + The verify_items function was made common though, and it tries to + dereference the items in the list, to make sure they have not been + deleted by mistake (which would be caught by Valgrind / ASan). + + Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760 + Co-Authored-By: Pedro Alves + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: make insert return an iterator + Make the insert method return an iterator to the inserted element. This + mimics what boost does [1] and what the standard library insert methods + generally do [2]. + + [1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33771-bb + [2] https://en.cppreference.com/w/cpp/container/vector/insert + + Change-Id: I59082883492c60ee95e8bb29a18c9376283dd660 + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: sprinkle noexcept + Some methods of intrusive_list are marked noexcept. But really, + everything in that file could be noexcept. Add it everywhere. + + The only one I had a doubt about is clear_and_dispose: what if the + disposer throws? The boost equivalent [1] is noexcept and requires the + disposer not to throw. The rationale is probably the same as for + destructors. What if the disposer throws for an element in the middle + of the list? Do you skip the remaining elements? Do you swallow the + exception and keep calling the disposer for the remaining elements? + It's simpler to say no exceptions allowed. + + [1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33710-bb + + Change-Id: I402646cb12c6b7906f4bdc2ad85203d8c8cdf2cc + Reviewed-by: Keith Seitz + +2024-09-13 Stephan Rohr + + testsuite, trace: add guards if In-Process Agent library is not found + Several tests in gdb.trace trigger TCL errors if the In-Process Agent + library is not found, e.g.: + + Running gdb/testsuite/gdb.trace/change-loc.exp ... + ERROR: tcl error sourcing gdb/testsuite/gdb.trace/change-loc.exp. + ERROR: error copying "gdb/gdb/testsuite/../../gdbserver/libinproctrace.so": + no such file or directory + while executing + "file copy -force $fromfile $tofile" + (procedure "gdb_remote_download" line 29) + invoked from within + "gdb_remote_download target $target_file" + (procedure "gdb_download_shlib" line 6) + invoked from within + "gdb_download_shlib $file" + (procedure "gdb_load_shlib" line 2) + invoked from within + "gdb_load_shlib $libipa" + (file "gdb/testsuite/gdb.trace/change-loc.exp" line 354) + invoked from within + "source gdb/testsuite/gdb.trace/change-loc.exp" + ("uplevel" body line 1) + invoked from within + "uplevel #0 source gdb/testsuite/gdb.trace/change-loc.exp" + invoked from within + "catch "uplevel #0 source $test_file_name"" + + Protect against this error by checking if the library is available. + +2024-09-13 GDB Administrator + + Automatic date update in version.in + +2024-09-12 Sam James + + gprofng: avoid use of non-portable which [PR32166] + Distributions like Debian [0] and Gentoo are phasing out the use of + the non-portable `which` utility. Use POSIX's `command -v` instead. + + [0] https://lwn.net/Articles/874049/ + + gprofng/ChangeLog + PR gprofng/32166 + * testsuite/lib/Makefile.skel (JAVABIN): Replace use of which. + +2024-09-12 Simon Marchi + + gdb: change type of `general_symbol_info::m_section` to int + The binary provided with bug 32165 [1] has 36139 ELF sections. GDB + crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1: + + $ ./gdb -nx -q --data-directory=data-directory ./vmlinux + Reading symbols from ./vmlinux... + (No debugging symbols found in ./vmlinux) + (gdb) info func + /usr/include/c++/14.2.1/debug/vector:508: + In function: + std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp, + _Allocator>::operator[](size_type) [with _Tp = long unsigned int; + _Allocator = std::allocator; reference = long + unsigned int&; size_type = long unsigned int] + + Error: attempt to subscript container with out-of-bounds index -29445, but + container only holds 36110 elements. + + Objects involved in the operation: + sequence "this" @ 0x514000007340 { + type = std::debug::vector >; + } + + The crash occurs here: + + #3 0x00007ffff5e334c3 in __GI_abort () at abort.c:79 + #4 0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320 + #5 0x0000555561119a16 in std::__debug::vector >::operator[] (this=0x514000007340, __n=18446744073709522171) + at /usr/include/c++/14.2.1/debug/vector:508 + #6 0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517 + #7 0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value]) + at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983 + #8 0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189 + #9 0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1) + at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361 + #10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525 + + That is, at this line of `minimal_symbol::value_address`, where + `objfile->section_offsets` is an `std::vector`: + + return (CORE_ADDR (this->unrelocated_address ()) + + objfile->section_offsets[this->section_index ()]); + + A section index of -29445 is suspicious. The minimal_symbol at play + here is: + + (top-gdb) p m_name + $1 = 0x521001de10af "_sinittext" + + So I restarted debugging, breaking on: + + (top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name) + + And I see that weird -29445 value: + + (top-gdb) frame + #0 general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611 + 611 { m_section = idx; } + + But going up one frame, the section index is 36091: + + (top-gdb) frame + #1 0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false, + address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228 + 1228 msymbol->set_section_index (section); + + It seems like the problem is just that the type used for the section + index (short) is not big enough. Change from short to int. If somebody + insists, we could even go long long / int64_t, but I doubt it's + necessary. + + With that fixed, I get: + + (gdb) info func + All defined functions: + + Non-debugging symbols: + 0xffffffff81000000 _stext + 0xffffffff82257000 _sinittext + 0xffffffff822b4ebb _einittext + + [1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165 + + Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04 + Reviewed-By: Tom de Vries + Reviewed-by: Keith Seitz + +2024-09-12 Jens Remus + + s390: Relax risbg[n]z, risb{h|l}gz, {rns|ros|rxs}bgt operand constraints + This leverages commit ("s390: Simplify (dis)assembly of insn operands + with const bits") to relax the operand constraints of the immediate + operand that contains the constant Z- or T-bit of the following extended + mnemonics: + risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt + + Previously those instructions were the only ones where the assembler + on s390 restricted the specification of the subject I3/I4 operand values + exactly according to their specification to an unsigned 6- or 5-bit + unsigned integer. For any other instructions the assembler allows to + specify any operand value allowed by the instruction format, regardless + of whether the instruction specification is more restrictive. + + Allow to specify the subject I3/I4 operand as unsigned 8-bit integer + with the constant operand bits being ORed during assembly. + Relax the instructions subject significant operand bit masks to only + consider the Z/T-bit as significant, so that the instructions get + disassembled as their *z or *t flavor regardless of whether any reserved + bits are set in addition to the Z/T-bit. + Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set + the T-bit in operand I3, as they otherwise get disassembled as their + rnsbgt, rosbgt, and rxsbgt counterpart. + + This aligns GNU Assembler to LLVM Assembler. + + opcodes/ + * s390-opc.c (U6_18, U5_27, U6_26): Remove. + (INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define + as INSTR_RIE_RRUUU while retaining insn fmt mask. + (MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only + Z/T-bit of I3/I4 operand as significant. + + gas/testsuite/ + * gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit. + + Reported-by: Dominik Steenken + Suggested-by: Ulrich Weigand + +2024-09-12 Jens Remus + + s390: Simplify (dis)assembly of insn operands with const bits + Simplify assembly and disassembly of extended mnemonics with operands + with constant ORed bits: + Their instruction template already contains the respective constant + operand bits, as they are significant to distinguish the extended from + their base mnemonic. Operands are ORed into the instruction template. + Therefore it is not necessary to OR the constant bits into the operand + value during assembly in s390_insert_operand. + Additionally the constant operand bits from the instruction template + can be used to mask them from the operand value during disassembly in + s390_print_insn_with_opcode. For now do so for non-length unsigned + integer operands only. + + The separate instruction formats need to be retained, as their masks + differ, which is relevant during disassembly to distinguish the base + and extended mnemonics from each other. + + This affects the following extended mnemonics: + - vfaebs, vfaehs, vfaefs + - vfaezb, vfaezh, vfaezf + - vfaezbs, vfaezhs, vfaezfs + - vstrcbs, vstrchs, vstrcfs + - vstrczb, vstrczh, vstrczf + - vstrczbs, vstrczhs, vstrczfs + - wcefb, wcdgb + - wcelfb, wcdlgb + - wcfeb, wcgdb + - wclfeb, wclgdb + - wfisb, wfidb, wfixb + - wledb, wflrd, wflrx + + include/ + * opcode/s390.h (S390_OPERAND_OR1, S390_OPERAND_OR2, + S390_OPERAND_OR8): Remove. + + opcodes/ + * s390-opc.c (U4_OR1_24, U4_OR2_24, U4_OR8_28): Remove. + (INSTR_VRR_VVV0U1, INSTR_VRR_VVV0U2, INSTR_VRR_VVV0U3): Define + as INSTR_VRR_VVV0U0 while retaining respective insn fmt mask. + (INSTR_VRR_VV0UU8): Define as INSTR_VRR_VV0UU while retaining + respective insn fmt mask. + (INSTR_VRR_VVVU0VB1, INSTR_VRR_VVVU0VB2, INSTR_VRR_VVVU0VB3): + Define as INSTR_VRR_VVVU0VB while retaining respective insn fmt + mask. + * s390-dis.c (s390_print_insn_with_opcode): Mask constant + operand bits set in insn template of non-length unsigned + integer operands. + + gas/ + * config/tc-s390.c (s390_insert_operand): Do not OR constant + operand value bits. + +2024-09-12 GDB Administrator + + Automatic date update in version.in + +2024-09-11 Vladimir Mezentsev + + Fix 32096 UBSAN issues in gprofng + Fixed UBSAN runtime errors such as: + - load of value 4294967295, which is not a valid value for type 'Cmsg_warn' + - null pointer passed as argument 2, which is declared to never be null + - load of value 4294967295, which is not a valid value for type 'ProfData_type' + - reference binding to misaligned address 0x00000357583c for type 'long unsigned int', which requires 8 byte alignment + + gprofng/ChangeLog + 2024-09-09 Vladimir Mezentsev . + + PR gprofng/32096 + * src/BaseMetric.cc: Fix UBSAN runtime errors. + * src/BaseMetric.h: Likewise. + * src/Emsg.h: Likewise. + * src/Experiment.cc: Likewise. + * src/Table.h: Likewise. + +2024-09-11 Tom de Vries + + [gdb/testsuite] Simplify gdb.dwarf2/forward-spec.exp + Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple + to parse this cooked_index_entry: + ... + [5] ((cooked_index_entry *) 0x7f01f0004040)^M + name: v^M + canonical: v^M + qualified: ns::v^M + DWARF tag: DW_TAG_variable^M + flags: 0x2 [IS_STATIC]^M + DIE offset: 0xcb^M + parent: ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M + ... + which allows us to verify that the entry has a parent. + + After commit 8f258a6c979 ("[gdb/symtab] Dump qualified name of + cooked_index_entry") that's no longer necessary. + + Simplify this by checking for ns::v instead. + + While we're at it, also fix the test-case for target boards readnow, + cc-with-gdb-index and cc-with-debug-names. + + Tested on x86_64-linux. + +2024-09-11 Christophe Lyon + + arm: Handle undefweak with ST_BRANCH_UNKNOWN + A previous patch made ld fail early on Thumb-only where branch_type is + ST_BRANCH_UNKNOWN. + + However, this fails erroneously when the target is undefweak: in that + case the branch should be replaced by a branch to the next instruction + (or nop.w on thumb2). This patch accepts this case and restores the + previous behaviour in such cases. + + This was reported by failures in the GCC testsuite, where we fail to + link executables because __deregister_frame_info is undefweak: + + (__deregister_frame_info): Unknown destination type (ARM/Thumb) in ...crtbegin.o + crtbegin.o: in function `__do_global_dtors_aux': + crtstuff.c:(.text+0x52): dangerous relocation: unsupported relocation + +2024-09-11 Kyle Huey + + gdb: Support DW_OP_constx (the standardized version of DW_OP_GNU_const_index). + Approved-By: Tom Tromey + +2024-09-11 Tom Tromey + + Fix typo in Python TUI window text + I noticed a typo in the Python TUI window documentation. + +2024-09-11 Jan Beulich + + gas: avoid (scrubber) diagnostics for stuff past .end + What's past an active .end directive (when that has its default purpose) + is supposed to be entirely ignored. That should be true not just for + regular processing, but also for "pre-processing" (aka scrubbing). A + complication is that such a directive may of course occur inside a + (false) conditional or a macro definition. To deal with that make sure + we can continue as usual if called another time. + + Note however that .end inside a macro will still have the full macro + body expanded; dealing with that would require further (perhaps + intrusive) adjustments in sb_scrub_and_add_sb() and/or callers thereof. + However, at least some of the warnings issued by do_scrub_chars() are + unlikely to occur when expanding a macro. (If we needed to go that far, + presumably .exitm would also want recognizing.) + +2024-09-11 Jan Beulich + + gas: restrict scrubber mri_{state,last_ch} vars + They're needed with TC_M68K only. Group them accordingly, just like is + the case for Arm's symver vars. + + arm: don't engage symver scrubber hack in CCS mode + In that mode the comment char is ; while @ has no special meaning. + Engaging the special logic in that case results in comments not being + respected on .symver lines. + + x86/APX: correct disassembly for EVEX.B4 + EVEX.B4 is used only for GPR (or addressing of memory) operands. SIMD + registers encoded via ModR/M.rm (when ModR/M.mod == 3) have their top + bit in EVEX.X3. Supposedly (doc version 004) EVEX.B4 is ignored when + unused, hence also don't flag such encodings as invalid. + +2024-09-11 Jan Beulich + + x86: error handling in set_cpu_arch() + Error messages there would better not be followed by further "junk at + end of line" diagnostics. Arrange for this to be the case uniformly. + + While there also replace a somewhat unhelpful open-coding of + restore_line_pointer(). + +2024-09-11 Mark Harmstone + + ld/testsuite: exclude relocs from section contributions PDB test + A bug in ld meant that we were erroneously generating image relocations + for .secrel32 ops, which we then reflected in our PDB section + contributions because the linker was adding a .reloc section. + + This was incidental to what we were testing for, so pass + --disable-reloc-section to ld in order to ensure a consistent output. + +2024-09-11 GDB Administrator + + Automatic date update in version.in + +2024-09-10 Andrew Burgess + + gdb/testsuite: fix argument order in example code within a comment + Small typo in some example code inside a comment; the arguments were + in the wrong order. + + There's no functional change after this commit. + +2024-09-10 Andrew Burgess + + gdb/testsuite: add return after a call to 'untested' + In gdb.base/corefile-buildid.exp, in the function + do_corefile_buildid_tests, if we fail to find the build-id for the + test binary then we call 'untested', but then push on with the test, + which inevitably fails as the rest of the test depends on having found + the build-id. + + I think we're missing a 'return' after the call to 'untested' which + I've now added. + + Also I noticed that we call build_id_debug_filename_get and then + manually remove '.debug' from the end. This is no longer necessary, + we can just ask build_id_debug_filename_get to not add the suffix. + +2024-09-10 Andrew Burgess + + Revert "[gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp" + This reverts commit 29c70787112e01cd52b53bf14bdcacb0a11e0725. + + After the previous commit 29c70787112e01cd52 should no longer be + needed as the curses dependency has been removed. + +2024-09-10 Andrew Burgess + + gdb/python: avoid depending on the curses library + The commit: + + commit 29c70787112e01cd52b53bf14bdcacb0a11e0725 + Date: Sun Sep 8 07:46:09 2024 +0200 + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + + Highlighted that in some cases we might be running on a system with an + older version of Python (earlier than 3.7), and on a system for which + the curses library has not been installed. + + In these circumstances the gdb.missing_debug module will not load as + it uses curses to provide isalnum() and isascii() functions. + + To avoid this problem I propose that we copy the isalnum() and + isascii() from the Python curses library. These functions are + basically trivial and removing the curses dependency means GDB will + work in more cases without increasing its dependencies. + + I did consider keeping the uses of curses and only having the function + definitions be a fallback for when the curses library failed to load, + but this felt like overkill. The function definitions are both tiny + and I think "obvious" given their specifications, so I figure we might + as well just use our own definitions if they are not available as + builtin methods on the str class. + + For testing I changed this line: + + if sys.version_info >= (3, 7): + + to + + if sys.version_info >= (3, 7) and False: + + then reran gdb.python/py-missing-debug.exp, there were no failures. + + Approved-By: Tom de Vries + +2024-09-10 Tom de Vries + + [gdb/testsuite] Fix gdb.xml/tdesc-regs.exp on riscv64 + When running test-case gdb.xml/tdesc-regs.exp on riscv64-linux, I get: + ... + (gdb) set tdesc file single-reg.xml^M + warning: Architecture rejected target-supplied description^M + (gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml + UNSUPPORTED: gdb.xml/tdesc-regs.exp: register tests + ... + + The FAIL and UNSUPPORTED are produced here: + ... + # If no core registers were specified, assume this target does not + # support target-defined registers. Verify that we get a warning if + # we try to use them. This not only tests the warning, but also + # reminds maintainers to add test support when they add the feature. + + if {[string equal ${core-regs} ""]} { + gdb_test "set tdesc file $single_reg_xml" \ + "warning: Target-supplied registers are not supported.*" \ + "set tdesc file single-reg.xml" + unsupported "register tests" + return 0 + } + ... + + The test-case contains target-specific setting of the core-regs variable, and + adding this for riscv64 bypasses this code and makes the test-case pass. + + However, without that change, the test-case shouldn't produce a FAIL since + gdb isn't doing anything wrong. + + Fix this by producing instead: + ... + PASS: $exp: set tdesc file single-reg.xml + UNSUPPORTED: $exp: register tests (missing architecture-specific core-regs setting) + ... + + Tested on riscv64-linux. + +2024-09-10 Tom de Vries + + [gdb/build] Fix unused var in corelow.c + On x86_64-linux, with gcc 7.5.0 and CFLAGS/CXXFLAGS="-O0 -g -Wall" I ran into + a build breaker: + ... + gdb/corelow.c: In member function ‘void mapped_file_info::add(const char*, const char*, const char*, std::vector&&, const bfd_build_id*)’: + gdb/corelow.c:1822:27: error: unused variable ‘it’ [-Werror=unused-variable] + const auto [it, inserted] + ^ + ... + + Fix this by dropping the variable it. + + Tested on x86_64-linux. + + Reviewed-By: Lancelot Six + +2024-09-10 H.J. Lu + + bfd: Pass true to ld_plugin_object_p + Since linker calls bfd_plugin_object_p, which calls ld_plugin_object_p, + only for command-line input objects, pass true to ld_plugin_object_p so + that the same input IR file won't be included twice if the new LTO hook, + LDPT_REGISTER_CLAIM_FILE_HOOK_V2 isn't used. + + PR ld/32153 + * plugin.c (bfd_plugin_object_p): Pass true to ld_plugin_object_p. + +2024-09-10 GDB Administrator + + Automatic date update in version.in + +2024-09-09 Tom Tromey + + Move enum size check into ada_identical_enum_types_p + Currently, the callers of ada_identical_enum_types_p must check that + both enum types have the same number of members. In another series + I'm working on, it was convenient to move this check into the callee + instead; and I broke this patch out to make that series a little + simpler. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Minor cleanup to ada_identical_enum_types_p + This moves the declaration of 'i' into the 'for' loops in + ada_identical_enum_types_p. This is just a trivial cleanup. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Boolify ada_identical_enum_types_p + This changes ada_identical_enum_types_p to return bool rather than + int. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Fix some comments in dwarf2/cooked-index.h + This fixes a couple of comments in dwarf2/cooked-index.h. + + The comment by cooked_index_entry::canonical mentions C++, but this + field can also be different from 'name' in other situations. Rather + than enumerate the cases here (which doesn't seem important), make the + text a little less specific. + + Also, cooked_index_entry::write_scope doesn't document its "for_main" + parameter -- and it is misnamed in the prototype as well. + + Reviewed-By: Tom de Vries + +2024-09-09 Tom Tromey + + Refactor cooked_index_shard::handle_gnat_encoded_entry + This changes cooked_index_shard::handle_gnat_encoded_entry to modify + the incoming entry itself, and to return void rather than a new name. + this simplifies the caller a little, which is convenient for a + different series I am working on. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Ignore DW_TAG_padding in tag_is_type + DW_TAG_padding isn't a real tag -- it doesn't appear in the DWARF + standard, only in include/dwarf2.def as a placeholder. So, remove it + from dwarf2/tag.h:tag_is_type. + + Reviewed-By: Tom de Vries + +2024-09-09 Jens Remus + + s390: Align opcodes to lower-case + opcodes/ + * s390-opc.txt (rdp): Change opcode to lower-case. + +2024-09-09 Jens Remus + + s390: Document syntax to omit base register operand + Document the s390-specific assembler syntax introduced by commit + aacf780bca29 ("s390: Allow to explicitly omit base register operand in + assembly") to omit the base register operand B in D(X,B) and D(L,B) by + coding D(X,) and D(L,). + + While at it document the alternative syntax to omit the index register + operand X in D(X,B) by coding D(,B) instead of D(B). + + gas/ + * doc/c-s390.texi (s390 Operands): Document syntax to omit base + register operand. + + Fixes: aacf780bca29 ("s390: Allow to explicitly omit base register operand in assembly") + +2024-09-09 Andrew Burgess + + gdb/NEWS: group general news items together + I noticed that the list of general NEWS items seemed to have gotten + mixed up a bit in the NEWS file. This commit just moves things around + so that the general items all appear at the start of the 'Changes + since GDB 15' section. I've not changed any of the actual content. + +2024-09-09 Lulu Cai + + LoongArch: Fixed precedence of expression operators in instructions + The precedence of the operators "+" and "-" in the current loongarch + instruction expression is higher than "<<" and ">>", which is different + from the explanation in the user guide. + + We modified the precedence of "<<" and ">>" to be higher than "+" and "-". + +2024-09-09 GDB Administrator + + Automatic date update in version.in + +2024-09-08 Andrew Burgess + + gdb: fix use of out of scope temporary variable in break-cond-parse.c + The commit: + + commit c6b486755e020095710c7494d029577ca967a13a + Date: Thu Mar 30 19:21:22 2023 +0100 + + gdb: parse pending breakpoint thread/task immediately + + Introduce a use bug where the value of a temporary variable was being + used after it had gone out of scope. This was picked up by the + address sanitizer and would result in this error: + + (gdb) maintenance selftest create_breakpoint_parse_arg_string + Running selftest create_breakpoint_parse_arg_string. + ================================================================= + ==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768 + READ of size 1 at 0x7fbb08046511 thread T0 + #0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr >*, int*, int*, int*, std::unique_ptr >*, bool*) ../../src/gdb/break-cond-parse.c:496 + #1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582 + #2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649 + #3 0x12cfebc in void std::__invoke_impl(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61 + #4 0x12cc8ee in std::enable_if, void>::type std::__invoke_r(void (*&)()) /usr/include/c++/13/bits/invoke.h:111 + #5 0x12c81e5 in std::_Function_handler::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290 + #6 0x18bb51d in std::function::operator()() const /usr/include/c++/13/bits/std_function.h:591 + #7 0x4193ef9 in selftests::run_tests(gdb::array_view, bool) ../../src/gdbsupport/selftest.cc:100 + #8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172 + ... etc ... + + The problem was caused by three lines like this one: + + thread_info *thr + = parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok); + + After parsing the thread-id TMPTOK would be left pointing into the + temporary string which had been created on this line. When on the + next line we did this: + + gdb_assert (*tmptok == '\0'); + + The value of *TMPTOK is undefined. + + Fix this by creating the std::string earlier in the scope. Now the + contents of the string will remain valid when we check *TMPTOK. The + address sanitizer issue is now resolved. + +2024-09-08 Tom de Vries + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + On a system with python 3.6, module gdb.missing_debug imports module curses, + so when running test-case gdb.python/py-missing-debug.exp on a system without + that module installed, we run into: + ... + (gdb) source py-missing-debug.py^M + Python Exception : Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + Error occurred in Python: Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + (gdb) FAIL: gdb.python/py-missing-debug.exp: source python script + ... + + Fix this by issuing UNSUPPORTED instead, and bailing out. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31576 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31576 + +2024-09-08 GDB Administrator + + Automatic date update in version.in + +2024-09-07 Andrew Burgess + + gdb: only insert thread-specific breakpoints in the relevant inferior + This commit updates GDB so that thread or inferior specific + breakpoints are only inserted into the program space in which the + specific thread or inferior is running. + + In terms of implementation, getting this basically working is easy + enough, now that a breakpoint's thread or inferior field is setup + prior to GDB looking for locations, we can easily use this information + to find a suitable program_space and pass this to as a filter when + creating the sals. + + Or we could if breakpoint_ops::create_sals_from_location_spec allowed + us to pass in a filter program_space. + + So, this commit extends breakpoint_ops::create_sals_from_location_spec + to take a program_space argument, and uses this to filter the set of + returned sals. This accounts for about half the change in this patch. + + The second set of changes starts from breakpoint_set_thread and + breakpoint_set_inferior, this is called when the thread or inferior + for a breakpoint changes, e.g. from the Python API. + + Previously this call would never result in the locations of a + breakpoint changing, after all, locations were inserted in every + program space, and we just use the thread or inferior variable to + decide when we should stop. Now though, changing a breakpoint's + thread or inferior can mean we need to figure out a new set of + breakpoint locations. + + To support this I've added a new breakpoint_re_set_one function, which + is like breakpoint_re_set, but takes a single breakpoint, and just + updates the locations for that one breakpoint. We only need to call + this function if the program_space in which a breakpoint's thread (or + inferior) is running actually changes. If the program_space does + change then we call the new breakpoint_re_set_one function passing in + the program_space which should be used to filter the new locations (or + nullptr to indicate we should set locations in all program spaces). + This filter program_space needs to propagate down to all the re_set + methods, this accounts for the remaining half of the changes in this + patch. + + There were a couple of existing tests that created thread or inferior + specific breakpoints and then checked the 'info breakpoints' output, + these needed updating. These were: + + gdb.mi/user-selected-context-sync.exp + gdb.multi/bp-thread-specific.exp + gdb.multi/multi-target-continue.exp + gdb.multi/multi-target-ping-pong-next.exp + gdb.multi/tids.exp + gdb.mi/new-ui-bp-deleted.exp + gdb.multi/inferior-specific-bp.exp + gdb.multi/pending-bp-del-inferior.exp + + I've also added some additional tests to: + + gdb.multi/pending-bp.exp + + I've updated the documentation and added a NEWS entry. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: don't set breakpoint::pspace in create_breakpoint + I spotted this code within create_breakpoint: + + if ((type_wanted != bp_breakpoint + && type_wanted != bp_hardware_breakpoint) || thread != -1) + b->pspace = current_program_space; + + this code is only executed when creating a pending breakpoint, and + sets the breakpoint::pspace member variable. + + The above code gained the 'thread != -1' clause with this commit: + + commit cc72b2a2da6d6372cbdb1d14639a5fce84e1a325 + Date: Fri Dec 23 17:06:16 2011 +0000 + + Introduce gdb.FinishBreakpoint in Python + + While the type_wanted checks were added with this commit: + + commit f8eba3c61629b3c03ac1f33853eab4d8507adb9c + Date: Tue Dec 6 18:54:43 2011 +0000 + + the "ambiguous linespec" series + + Before this breakpoint::pspace was set unconditionally. + + If we look at how breakpoint::pspace is used today, some breakpoint + types specifically set this field, either in their constructors, or in + a wrapper function that calls the constructor. So, the watchpoint + type and its sub-class set this variable, as does the catchpoint type, + and all it's sub-classes. + + However, code_breakpoint doesn't specifically set this field within + its constructor, though some sub-classes of + code_breakpoint (ada_catchpoint, exception_catchpoint, + internal_breakpoint, and momentary_breakpoint) do set this field. + + When I examine all the places that breakpoint::pspace is used, I + believe that in every place where it is expected that this field is + set, the breakpoint type will be one that specifically sets this + field. + + Next, I observe two problems with the existing code. + + First, the above code is only hit for pending breakpoints, there's no + equivalent code for non-pending breakpoints. This opens up the + possibility of GDB entering non-consistent states; if a breakpoint is + first created pending and then later gets a location, the pspace field + will be set, while if the breakpoint is immediately non-pending, then + the pspace field will never be set. + + Second, if we look at how breakpoint::pspace is used in the function + breakpoint_program_space_exit, we see that when a program space is + removed, any breakpoint with breakpoint::pspace set to the removed + program space, will be deleted. This makes sense, but does mean we + need to ensure breakpoint::pspace is only set for breakpoints that + apply to a single program space. + + So, if I create a pending dprintf breakpoint (type bp_dprintf) then + the breakpoint::pspace variable will be set even though the dprintf is + not really tied to that one program space. As a result, when the + matching program space is removed the dprintf is incorrectly removed. + + Also, if I create a thread specific breakpoint, then, thanks to the + 'thread != -1' clause the wrong program space will be stored in + breakpoint::pspace (the current program space is always used, which + might not be the program space that corresponds to the selected + thread), as a result, the thread specific breakpoint will be deleted + when the matching program space is removed. + + If we look at commit cc72b2a2da6d which added the 'thread != -1' + clause, we can see this change was entirely redundant, the + breakpoint::pspace is also set in bpfinishpy_init after + create_breakpoint has been called. As such, I think we can safely + drop the 'thread != -1' clause. + + For the other problems, I'm proposing to be pretty aggressive - I'd + like to drop the breakpoint::pspace assignment completely from + create_breakpoint. Having looked at how this variable is used, I + believe that it is already set elsewhere in all the cases that it is + needed. Maybe this code was needed at one time, but I can't see how + it's needed any more. + + There's tests to expose the issues I've spotted with this code, and + there's no regressions in testing. + +2024-09-07 Andrew Burgess + + gdb: parse pending breakpoint thread/task immediately + The initial motivation for this commit was to allow thread or inferior + specific breakpoints to only be inserted within the appropriate + inferior's program-space. The benefit of this is that inferiors for + which the breakpoint does not apply will no longer need to stop, and + then resume, for such breakpoints. This commit does not make this + change, but is a refactor to allow this to happen in a later commit. + + The problem we currently have is that when a thread-specific (or + inferior-specific) breakpoint is created, the thread (or inferior) + number is only parsed by calling find_condition_and_thread_for_sals. + This function is only called for non-pending breakpoints, and requires + that we know the locations at which the breakpoint will be placed (for + expression checking in case the breakpoint is also conditional). + + A consequence of this is that by the time we figure out the breakpoint + is thread-specific we have already looked up locations in all program + spaces. This feels wasteful -- if we knew the thread-id earlier then + we could reduce the work GDB does by only looking up locations within + the program space for which the breakpoint applies. + + Another consequence of how find_condition_and_thread_for_sals is + called is that pending breakpoints don't currently know they are + thread-specific, nor even that they are conditional! Additionally, by + delaying parsing the thread-id, pending breakpoints can be created for + non-existent threads, this is different to how non-pending + breakpoints are handled, so I can do this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break foo thread 99 + Function "foo" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (foo thread 99) pending. + (gdb) r + Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + Error in re-setting breakpoint 1: Unknown thread 99. + [Inferior 1 (process 3329749) exited normally] + (gdb) + + GDB only checked the validity of 'thread 99' at the point the 'foo' + location became non-pending. In contrast, if I try this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break main thread 99 + Unknown thread 99. + (gdb) + + GDB immediately checks if 'thread 99' exists. I think inconsistencies + like this are confusing, and should be fixed if possible. + + In this commit the create_breakpoint function is updated so that the + extra_string, which contains the thread, inferior, task, and/or + condition information, is parsed immediately, even for pending + breakpoints. + + Obviously, the condition still can't be validated until the breakpoint + becomes non-pending, but the thread, inferior, and task information + can be pulled from the extra-string, and can be validated early on, + even for pending breakpoints. The -force-condition flag is also + parsed as part of this early parsing change. + + There are a couple of benefits to doing this: + + 1. Printing of breakpoints is more consistent now. Consider creating + a conditional breakpoint before this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc if (0)) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18 + stop only if (0) + (gdb) + + And after this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc + stop only if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18 + stop only if (0) + (gdb) + + Notice that the display of the condition is now the same for the + pending and non-pending breakpoints. + + The same is true for the thread, inferior, or task information in + thread, inferior, or task specific breakpoints; this information is + displayed on its own line rather than being part of the 'What' + field. + + 2. We can check that the thread exists as soon as the pending + breakpoint is created. Currently there is a weird difference + between pending and non-pending breakpoints when creating a + thread-specific breakpoint. + + A pending thread-specific breakpoint only checks its thread when it + becomes non-pending, at which point the thread the breakpoint was + intended for might have exited. Here's the behaviour before this + commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo thread 2) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2948835) exited] + Error in re-setting breakpoint 2: Unknown thread 2. + [Inferior 1 (process 2948832) exited normally] + (gdb) + + Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.' + line, this was triggered when GDB tried to make the breakpoint + non-pending, and GDB discovers that the thread no longer exists. + + Compare that to the behaviour after this commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2949243) exited] + Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list. + [Inferior 1 (process 2949240) exited normally] + (gdb) + + Now the behaviour for pending breakpoints is identical to + non-pending breakpoints, the thread specific breakpoint is removed + as soon as the thread the breakpoint is associated with exits. + + There is an additional change; when the pending breakpoint is + created prior to this patch we see this line: + + Breakpoint 2 (foo thread 2) pending. + + While after this patch we get this line: + + Breakpoint 2 (foo) pending. + + Notice that 'thread 2' has disappeared. This might look like a + regression, but I don't think it is. That we said 'thread 2' + before was just a consequence of the lazy parsing of the breakpoint + specification, while with this patch GDB understands, and has + parsed away the 'thread 2' bit of the spec. If folk think the old + information was useful then this would be trivial to add back in + code_breakpoint::say_where. + + As a result of this commit the breakpoints 'extra_string' field is now + only used by bp_dprintf type breakpoints to hold the printf format and + arguments. This string should always be empty for other breakpoint + types. This allows some cleanup in print_breakpoint_location. + + In code_breakpoint::code_breakpoint I've changed an error case into an + assert. This is because the error is now handled earlier in + create_breakpoint. As a result we know that by this point, the + extra_string will always be nullptr for anything other than a + bp_dprintf style breakpoint. + + The find_condition_and_thread_for_sals function is now no longer + needed, this was previously doing the delayed splitting of the extra + string into thread, task, and condition, but this is now all done in + create_breakpoint, so find_condition_and_thread_for_sals can be + deleted, and the code that calls this in + code_breakpoint::location_spec_to_sals can be removed. With this + update this code would only ever be reached for bp_dprintf style + breakpoints, and in these cases the extra_string should not contain + anything other than format and args. + + The most interesting changes are all in create_breakpoint and in the + new file break-cond-parse.c. We have a new block of code early on in + create_breakpoint that is responsible for splitting the extra_string + into its component parts by calling create_breakpoint_parse_arg_string + a function in the new break-cond-parse.c file. This means that some + of the later code can be simplified a little. + + The new break-cond-parse.c file implements the splitting up the + extra_string and finding all the parts, as well as some self-tests for + the new function. + + Finally, now we know all the breakpoint details, these can be stored + within the breakpoint object if we end up creating a deferred + breakpoint. Additionally, if we are creating a deferred bp_dprintf we + can parse the extra_string to build the printf command. + + The implementation here aims to maintain backwards compatibility as + much as possible, this means that: + + 1. We support abbreviations of 'thread', 'task', and 'inferior' in + some places on the breakpoint line. The handling of abbreviations + has (before this patch) been a little weird, so this works: + + (gdb) break *main th 1 + + And creates a breakpoint at '*main' for thread 1 only, while this + does not work: + + (gdb) break main th 1 + + In this case GDB will try to find the symbol 'main th 1'. This + weirdness exists before and after this patch. + + 2. The handling of '-force-condition' is odd, if this flag appears + immediately after a condition then it will be treated as part of the + condition, e.g.: + + (gdb) break main if 0 -force-condition + No symbol "force" in current context. + + But we are fine with these alternatives: + + (gdb) break main if 0 thread 1 -force-condition + (gdb) break main -force-condition if 0 + + Again, this is just a quirk of how the breakpoint line used to be + parsed, but I've maintained this for backward compatibility. During + review it was suggested that -force-condition should become an + actual breakpoint flag (i.e. only valid after the 'break' command + but before the function name), and I don't think that would be a + terrible idea, however, that's not currently a trivial change, and I + think should be done as a separate piece of work. For now, this + patch just maintains the current behaviour. + + The implementation works by first splitting the breakpoint condition + string (everything after the location specification) into a list of + tokens, each token has a type and a value. (e.g. we have a THREAD + token where the value is the thread-id string). The list of tokens is + validated, and in some cases, tokens are merged. Then the values are + extracted from the remaining token list. + + Consider this breakpoint command: + + (gdb) break main thread 1 if argc == 2 + + The condition string passed to create_breakpoint_parse_arg_string is + going to be 'thread 1 if argc == 2', which is then split into the + tokens: + + { THREAD: "1" } { CONDITION: "argc == 2" } + + The thread-id (1) and the condition string 'argc == 2' are extracted + from these tokens and returns back to create_breakpoint. + + Now consider this breakpoint command: + + (gdb) break some_function if ( some_var == thread ) + + Here the user wants a breakpoint if 'some_var' is equal to the + variable 'thread'. However, when this is initially parsed we will + find these tokens: + + { CONDITION: "( some_var == " } { THREAD: ")" } + + This is a consequence of how we have to try and figure out the + contents of the 'if' condition without actually parsing the + expression; parsing the expression requires that we know the location + in order to lookup the variables by name, and this can't be done for + pending breakpoints (their location isn't known yet), and one of the + points of this work is that we extract things like thread-id for + pending breakpoints. + + And so, it is in this case that token merging takes place. We check + if the value of a token appearing immediately after the CONDITION + token looks valid. In this case, does ')' look like a valid + thread-id. Clearly, in this case ')' does not, and so me merge the + THREAD token into the condition token, giving: + + { CONDITION: "( some_var == thread )" } + + Which is what we want. + + I'm sure that we might still be able to come up with some edge cases + where the parser makes the wrong choice. I think long term the best + way to work around these would be to move the thread, inferior, task, + and -force-condition flags to be "real" command options for the break + command. I am looking into doing this, but can't guarantee if/when + that work would be completed, so this patch should be reviewed assume + that the work will never arrive (though I hope it will). + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: create new is_thread_id helper function + This is a refactoring commit that splits the existing parse_thread_id + function into two parts, and then adds a new is_thread_id function. + + The core of parse_thread_id is split into parse_thread_id_1, which is + responsible for actually parsing a thread-id. Then parse_thread_id is + responsible for taking a parsed thread-id and validating that it + references an actually existing inferior thread. + + The new is_thread_id function also uses parse_thread_id_1, but doesn't + actually check that the inferior thread exists, instead, this new + function simply checks that a string looks like a thread-id. + + This commit does not add a use for is_thread_id, this will be added in + the next commit. + + This is a refactoring commit, there should be no user visible changes + after this commit. + +2024-09-07 Andrew Burgess + + gdb: add another overload of startswith + We already have one overload of the startswith function that takes a + std::string_view for both arguments. A later patch in this series is + going to be improved by having an overload that takes one argument as + a std::string_view and the other argument as a plain 'char *'. + + This commit adds the new overload, but doesn't make use of it (yet). + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: make breakpoint_debug_printf global + This commit makes breakpoint_debug_printf available outside of + breakpoint.c. In a later commit I'll want to use this macro from + another file. + + This is just a refactor, there should be no user visible changes after + this commit. + +2024-09-07 Tom Tromey + + Remove tui_refresh_cmd_win + tui_refresh_cmd_win is no longer needed and can be replaced with a + call to the refresh_window method. + + Remove tui_wrefresh + This removes tui_wrefresh, moving the code into refresh_window. We + remove tui_norefresh_window as well, because now the command window's + refresh_window has to do what tui_wrefresh previously did. + +2024-09-07 Tom Tromey + + Rename tui_suppress_output + This patch renames tui_suppress_output to the more descriptive + tui_batch_rendering. This code was never really correct, and was + based on a misunderstanding of the curses API. The updated comments + describe the intended use of this class. + + This also removes the erroneous tui_win_info::no_refresh. + wnoutrefresh does not prevent any output; rather, it copies from one + curses buffer to another but (unlike woutrefresh) without then + flushing to the screen. + + tui_batch_rendering now works in the correct way: calling doupdate in + the destructor of the outermost instance, thus batching all screen + output until that point. + + The patch adds instantiations of tui_batch_rendering to various spots, + to make sure it is active when refreshing. + +2024-09-07 Tom Tromey + + Clean up refreshing in TUI register window + This patch rearranges the TUI register window code a bit, removing a + call to tui_wrefresh and hoisting the calls to refresh_window to "more + outer" spots. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-07 Andrew Burgess + + gdb: 'target ...' commands now expect quoted/escaped filenames + This commit changes the 'target ...' commands that accept a filename + to take a quoted or escaped filename rather than a literal filename. + + What this means in practice is that if you are specifying a filename + that contains no white space or quote characters, then nothing should + change, e.g.: + + target exec /path/to/some/file + + works both before and after this commit. + + However, if a user wishes to specify a file containing white space + then either the entire filename needs to be quoted, or the special + white space needs to be escaped. Before this patch a user could + write: + + target exec /path/to a file/containing spaces + + But after this commit the user would have to choose one of: + + target exec "/path/to a file/containing spaces" + + or + + target exec /path/to\ a\ file/containing\ spaces + + Obviously this is a potentially breaking change. The benefit of + making this change is consistency. Commands that take multiple + arguments (one of which is a filename) or in the future, commands that + take filename options, will always need to use quoted/escaped + filenames, so converting all unquoted filename commands to use quoting + or escaping makes the UI more consistent. + + Additionally (though this is probably not a common problem), GDB + strips trailing white space from commands that the user enters. As + such it is not possible to reference any file that ends in white space + unless the quoting / escaping style is used. Though I suspect very + few users run into this problem! + + The downside obviously is that this is a UI breaking change. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: allow quoted filenames for commands that have custom completion + This commit changes how GDB processes command arguments for the + following commands: + + compile file + maint print c-tdesc + save gdb-index + + After this commit these commands will now expect their single filename + argument to be (optionally) quoted if it contains any special + characters (e.g. whit space or quotes). + + If the filename does not contain any special characters then nothing + changes. As an example: + + (gdb) save gdb-index /path/to/some/directory/ + + will work before and after this patch. However, if the directory + name contains a white space then before this patch a user would write: + + (gdb) save gdb-index /path/to some/directory/ + + But this will now fail as GDB will consider this as two arguments, + '/path/to' and 'some/directory/'. To pass this single directory name + a user must now do one of these: + + (gdb) save gdb-index "/path/to some/directory/" + (gdb) save gdb-index '/path/to some/directory/' + (gdb) save gdb-index /path/to\ some/directory/ + + This brings these commands into line with commands like 'file' and + 'symbol-file', which have supported quoted filenames for a while. + + The motivation for this change is to make handling of filename + arguments consistent throughout GDB. We can't move to all commands + taking non-quoted filenames as the non-quoted style only allows for a + single argument. Additionally, the non-quoted style doesn't allow for + filenames that end in white space (though this is probably pretty + rare). So, if we want to have consistency the only choice is to move + towards supporting quote filenames. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: add remove-symbol-file command completion + The 'remove-symbol-file' command doesn't currently offer command + completion. This commit addresses this. + + The 'remove-symbol-file' uses gdb_argv to split its command arguments, + this means that the filename the command expects can be quoted. + + However, the 'remove-symbol-file' command is a little weird in that it + also has a '-a' option, if this option is passed then the command + expects not a filename, but an address. + + Currently the remove_symbol_file_command function splits the command + args using gdb_argv, checks for a '-a' flag by looking at the first + argument value, and then expects the filename or address to occupy a + single entry in the gdb_argv array. + + The first thing I do is handle the '-a' flag using GDB's option + system. I model this option as a flag_option_def (a boolean option). + + I've dropped the use of gdb_argv and instead use the new(ish) function + extract_single_filename_arg, which was added a couple of commits back, + to parse the filename argument (when '-a' is not given). + + If '-a' is given the the remove-symbol-file command expects an address + rather than a filename. As we previously split the arguments using + gdb_argv this meant the address needed to appear as a single + argument. So a user could write: + + (gdb) remove-symbol-file 0x1234 + + Or they could write: + + (gdb) remove-symbol-file some_function + + Both of these would work fine. But a user could not write: + + (gdb) remove-symbol-file some_function + 0x1000 + + As only the 'some_function' part would be processed. Now the user + could do this: + + (gdb) remove-symbol-file "some_function + 0x1000" + + By enclosing the address expression in quotes this would be handled as + a single argument. However, this is a little weird, that's not how + commands like 'print' or 'x' work. Also this functionality was + neither documented, or tested. + + And so, in this commit, by removing the use of gdb_argv I bring the + 'remove-symbol-file' command inline with GDB's other commands that + take an expression, the quotes are no longer needed. + + Usually in a completer we call 'complete_options', but don't actually + capture the option values. But for remove-symbol-file I do. This + allows me to spot when the '-a' option has been given, I can then + complete the rest of the command line as either a filename or an + expression. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: extend completion of quoted filenames to work in brkchars phase + Up to this point filename completion for possibly quoted filenames has + always been handled during the second (non-brkchars) phase of + completion. This works fine for commands that only want to complete + on a single filename argument. + + In a later commit though I need to perform completion of a quoted + filename argument during the first (brkchars) phase of completion. + This will allow me to add a custom completer that completes both + command options and arguments for a command (remove-symbol-file) that + takes a possibly quoted filename argument. + + This commit doesn't add the remove-symbol-file completer, this commit + is just about putting support for that in place. + + To achieve this I've added the new function + advance_to_filename_maybe_quoted_complete_word_point, which is unused + in this commit. I've then had to extend some other functions in order + to extract the quoting state during the brkchars phase. + + As this commit doesn't use the new functionality, the important thing + at this point is that I've not regressed the existing filename + completion (or any of the other completion). The next commit in this + series will make use of the new functionality, and will include + tests. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: new extract_single_filename_arg helper function + This commit is in preparation for the next few commits, this commit + adds a new function extract_single_filename_arg. + + This new function will be used to convert GDB commands that expect a + single filename argument to have these commands take a possibly quoted + or escaped string. + + There's no use of the new function in this commit, for that see the + following commits. + +2024-09-07 Andrew Burgess + + gdb: implement readline rl_directory_rewrite_hook callback + Implement the readline rl_directory_rewrite_hook callback function, + this is used when readline needs to offer completions from within a + directory. The important thing is that this function should remove + any escaping, this allows GDB to correctly offer completions in + situations like this: + + (gdb) file /tmp/directory\ with\ spaces/ + + Note the escaping in 'directory\ with\ spaces'. Without the + rl_directory_rewrite_hook callback readline will try to open a + directory literally called '/tmp/directory\ with\ spaces' which + obviously doesn't exist. + + There are tests added to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: improve gdb_rl_find_completion_word for quoted words + The function gdb_rl_find_completion_word is very similar to the + readline function _rl_find_completion_word, but was either an older + version of that function, or was trimmed when copying to remove code + which was considered unnecessary. + + We maintain this copy because the _rl_find_completion_word function is + not part of the public readline API, and we need to replicate the + functionality of that function as part of the 'complete' command. + + Within gdb_rl_find_completion_word when looking for the completion + word, if we don't find a unclosed quoted string (which would become + the completion word) then we scan backwards looking for a word break + character. For example, given: + + (gdb) complete file /tmp/foo + + There is no unclosed quoted string so we end up scanning backwards + from the end looking for a word break character. In this case the + space after 'file' and before '/tmp/foo' is found, so '/tmp/foo' + becomes the completion word. + + However, given this: + + (gdb) complete file /tmp/foo\" + + There is still no unclosed quoted string, however, when we can + backwards the '"' (double quotes) are treated as a word break + character, and so we end up using the empty string as the completion + word. + + The readline function _rl_find_completion_word avoids this mistake by + using the rl_char_is_quoted_p hook. This function will return true + for the double quote character as it is preceded by a backslash. An + earlier commit in this series supplied a rl_char_is_quoted_p function + for the filename completion case, however, gdb_rl_find_completion_word + doesn't call rl_char_is_quoted_p so this doesn't help for the + 'complete' case. + + In this commit I've copied the code to call rl_char_is_quoted_p from + _rl_find_completion_word into gdb_rl_find_completion_word. + + This half solves the problem. In the case: + + (gdb) complete file /tmp/foo\" + + We do now try to complete on the string '/tmp/foo\"', however, when we + reach filename_completer we call back into readline to actually + perform filename completion. However, at this point the WORD variable + points to a string that still contains the backslash. The backslash + isn't part of the actual filename, that's just an escape character. + + Our expectation is that readline will remove the backslash when + looking for matching filenames. However, readline contains an + optimisation to avoid unnecessary work trying to remove escape + characters. + + The readline variable rl_completion_found_quote is set in the readline + function gen_completion_matches before the generation of completion + matches. This variable is set to true (non-zero) if there is (or + might be) escape characters within the completion word. + + The function rl_filename_completion_function, which generates the + filename matches, only removes escape characters when + rl_completion_found_quote is true. When GDB generates completions + through readline (e.g. tab completion) then rl_completion_found_quote + is set correctly. + + But when we use the 'complete' command we don't pass through readline, + and so gen_completion_matches is never called and + rl_completion_found_quote is not set. In this case when we call + rl_filename_completion_function readline doesn't remove the escapes + from the completion word, and so in our case above, readline looks for + completions of the exact filename '/tmp/foo\"', that is, the filename + including the backslash. + + To work around this problem I've added a new flag to our function + gdb_rl_find_completion_word which is set true when we find any quoting + or escaping. This matches what readline does. + + Then in the 'complete' function we can set rl_completion_found_quote + prior to generating completion matches. + + With this done the 'complete' command now works correctly when trying + to complete filenames that contain escaped word break characters. The + tests have been updated accordingly. + +2024-09-07 Andrew Burgess + + gdb: apply escaping to filenames in 'complete' results + Building on the mechanism added in the previous commit(s), this commit + applies escaping to filenames in the 'complete' command output. + Consider a file: /tmp/xxx/aa"bb -- that is a filename that contains a + double quote, currently the 'complete' command output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa"bb + + Notice that the double quote in the output is not escaped. If we + passed this same output back to GDB then the double quote will be + treated as the start of a string. + + After this commit then the output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa\"bb + + The double quote is now escaped. If we feed this output back to GDB + then GDB will treat this as a single filename that contains a double + quote, exactly what we want. + + To achieve this I've done a little refactoring, splitting out the core + of gdb_completer_file_name_quote, and then added a new call from the + filename_match_formatter function. + + There are updates to the tests to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: add match formatter mechanism for 'complete' command output + This commit solves a problem that existed prior to the previous + commit, but the previous commit made more common. + + When completing a filename with the 'complete' command GDB will always + add a trailing quote character, even if the completion is a directory + name, in which case it would be better if the trailing quote was not + added. Consider: + + (gdb) complete file '/tmp/xx + file '/tmp/xxx/' + + The completion offered here is really only a partial completion, we've + completed up to the end of the next directory name, but, until we have + a filename then the completion is not finished and the trailing quote + should not be added. + + This would match the readline behaviour, e.g.: + + (gdb) file '/tmp/xx + (gdb) file '/tmp/xxx/ + + In this case readline completes the directory name, but doesn't add + the trailing quote character. + + Remember that the 'complete' command is intended for tools like + e.g. emacs in order that they can emulate GDB's standard readline + completion when implementing a CLI of their own. As such, not adding + the trailing quote in this case matches the readline behaviour, and + seems like the right way to go. + + To achieve this, I've added a new function pointer member variable + completion_result::m_match_formatter. This contains a pointer to a + callback function which is used by the 'complete' command to format + each result. + + The default behaviour of this callback function is to just append the + quote character (the character from before the completion string) to + the end of the completion result. This matches the current behaviour. + + However, for filename completion we override the default value of + m_match_formatter, this new function checks if the completion result + is a directory or not. If the completion result is a directory then + the closing quote is not added, instead we add a trailing '/' + character. + + The code to add a trailing '/' character already exists within the + filename_completer function. This is no longer needed in this + location, instead this code is moved into the formatter callback. + + Tests are updated to handle the changes in functionality, this removes + an xfail added in the previous commit. + +2024-09-07 Andrew Burgess + + gdb: simplify completion_result::print_matches + Simplify completion_result::print_matches by removing one of the code + paths. Now, every time we call ::print_matches we always add the + trailing quote. + + Previously, when using the 'complete' command, if there was only one + result then trailing quote was added in ::build_completion_result, but + when we had multiple results the trailing quote was added in + ::print_matches. As a consequence, ::print_matches had to understand + not to add the trailing quote for the single result case. + + After this commit we don't add the trailing quote in + ::build_completion_result, instead ::print_matches always adds the + trailing quote, which makes ::print_matches simpler. + + However, there is a slight problem. When completion is being driven + by readline, and not by the 'complete' command, we still need to + manually add the trailing quote in the single result case, and as the + printing is done by readline we can't add the quote at the time of + printing, and so, in ::build_completion_result, we still add the + trailing quote, but only when completion is being done for readline. + + And this does cause a small problem. When completing a filename, if + the completion results in a directory name then, when using the + 'complete' command, GDB should not be adding a trailing quote. For + example, if we have the file /tmp/xxx/foo.c, then what we should see + is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/ + + But what we actually see after this commit is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/' + + Previously we didn't get the trailing quote in this case, as when + there is only a single result, the quote was added in + ::build_completion_result, and for filename completion, GDB didn't + know what the quote character was in ::build_completion_result, so no + quote was added. Now that the trailing quote is always added in + ::print_matches, and GDB does know the quote character at this point, + so we are now getting the trailing quote, which is not correct. + + This is a regression, but really, GDB is now broken in a consistent + way, if we create the file /tmp/xxa/bar.c, then previously if we did + this: + + (gdb) complete file '/tmp/xx + file '/tmp/xxa/' + file '/tmp/xxx/' + + Notice how we get the trailing quote in this case, this is the before + patch behaviour, and is also wrong. + + A later commit will fix things so that the trailing quote is not added + in this filename completion case, but for now I'm going to accept this + small regression. + + This change in behaviour caused some failures in one of the completion + tests, I've tweaked the test case to expect the trailing quote as part + of this commit, but will revert this in a later commit in this series. + + I've also added an extra test for when the 'complete' command does + complete to a single complete filename, in which case the trailing + quote is expected. + +2024-09-07 Andrew Burgess + + gdb: move display of completion results into completion_result class + This commit moves the printing of the 'complete' command results out + of the 'complete_command' function. The printing is now done in a new + member function 'completion_result::print_matches'. At this point, + this is entirely a refactor. + + The motivation for this refactor is how 'complete' should print the + completion of filename arguments. In some cases the filename results + need to have escaping added to the output. This escaping needs to be + done immediately prior to printing the result as adding too early will + result in multiple 'complete' results potentially being sorted + incorrectly. See the subsequent commits for more details. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-09-07 Andrew Burgess + + gdb: improve escaping when completing filenames + This improves quoting and escaping when completing filenames for + commands that allow filenames to be quoted and escaped. + + I've struggled a bit trying to split this series into chunks. There's + a lot of dependencies between different parts of the completion + system, and trying to get this working correctly is pretty messy. + + This first step is really about implementing 3 readline hooks: + + rl_char_is_quoted_p + - Is a particular character quoted within readline's input buffer? + rl_filename_dequoting_function + - Remove quoting characters from a filename. + rl_filename_quoting_function + - Add quoting characters to a filename. + + See 'info readline' for full details, but with these hooks connected + up, readline (on behalf of GDB) should do a better job inserting + backslash escapes when completing filenames. + + There's still a bunch of stuff that doesn't work after this commit, + mostly around the 'complete' command which of course doesn't go + through readline, so doesn't benefit from all of these new functions + yet, I'll add some of this in a later commit. + + Tab completion is now slightly improved though, it is possible to + tab-complete a filename that includes a double or single quote, either + in an unquoted string or within a string surrounded by single or + double quotes, backslash escaping is used when necessary. + + There are some additional tests to cover the new functionality. + +2024-09-07 Andrew Burgess + + gdb: deprecated filename_completer and associated functions + Following on from the previous commit, this commit marks the old + unquoted filename completion related functions as deprecated. + + The aim of doing this is to make it more obvious to someone adding a + new command that they should not be using the older unquoted style + filename argument handling. + + I split this change from the previous to make for an easier review. + This commit touches more files, but is _just_ function renaming. + Check out gdb/completer.{c,h} for what has been renamed. All the + other files have just been updated to use the new names. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: split apart two different types of filename completion + Unfortunately we have two different types of filename completion in + GDB. + + The majority of commands have what I call unquoted filename + completion, this is for commands like 'set logging file ...', 'target + core ...', and 'add-auto-load-safe-path ...'. For these commands + everything after the command name (that is not a command option) is + treated as a single filename. If the filename contains white space + then this does not need to be escaped, nor does the filename need to + be quoted. In fact, the filename argument is not de-quoted, and does + not have any escaping removed, so if a user does try to add such + things, they will be treated as part of the filename. As an example: + + (gdb) target core "/path/that contains/some white space" + + Will look for a directory calls '"' (double quotes) in the local + directory. + + A small number of commands do de-quote and remove escapes from + filename arguments. These command accept what I call quoted and + escaped filenames. Right now these are the commands that specify the + file for GDB to debug, so: + + file + exec-file + symbol-file + add-symbol-file + remove-symbol-file + + As an example of this in action: + + (gdb) file "/path/that contains/some white space" + + In this case GDB would load the file: + + /path/that contains/some white space + + Current filename completion always assumes that filenames can be + quoted, though escaping doesn't work in completion right now. But the + assumption that quoting is allowed is clearly wrong. + + This commit splits filename completion into two. The existing + filename_completer is retained, and is used for unquoted filenames. A + second filename_maybe_quoted_completer is added which can be used for + completing quoted filenames. + + The filename completion test has been extended to cover more cases. + As part of the extended testing I need to know the character that + should be used to separate filenames within a path. For this TCL 8.6+ + has $::tcl_platform(pathSeparator). To support older versions of TCL + I've added some code to testsuite/lib/gdb.exp. + + You might notice that after this commit the completion for unquoted + files is all done in the brkchars phase, that is the function + filename_completer_handle_brkchars calculates the completions and + marks the completion_tracker as using a custom word point. The reason + for this is that we don't want to break on white space for this + completion, but if we rely on readline to find the completion word, + readline will consider the entire command line, and with no white + space in the word break character set, readline will end up using the + entire command line as the word to complete. + + For now at least, the completer for quoted filenames does generate its + completions during the completion phase, though this is going to + change in a later commit. + +2024-09-07 Andrew Burgess + + gdb: unify build-id to objfile lookup code + There are 3 places where we currently call debuginfod_exec_query to + lookup an objfile for a given build-id. + + In one of these places we first call build_id_to_exec_bfd which also + looks up an objfile given a build-id, but this function looks on disk + for a symlink in the .build-id/ sub-directory (within the + debug-file-directory). + + I can't think of any reason why we shouldn't call build_id_to_exec_bfd + before every call to debuginfod_exec_query. + + So, in this commit I have added a new function in build-id.c, + find_objfile_by_build_id, this function calls build_id_to_exec_bfd, + and if that fails, then calls debuginfod_exec_query. + + Everywhere we call debuginfod_exec_query is updated to call the new + function, and in locate_exec_from_corefile_build_id, the existing call + to build_id_to_exec_bfd is removed as calling find_objfile_by_build_id + does this for us. + + One slight weird thing is in core_target::build_file_mappings, here we + call find_objfile_by_build_id which returns a gdb_bfd_ref_ptr for the + opened file, however we immediately reopen the file as "binary". The + reason for this is that all the bfds opened in ::build_file_mappings + need to be opened as "binary" (see the function comments for why). + + I did consider passing a target type into find_objfile_by_build_id, + which could then be forwarded to build_id_to_exec_bfd and used to open + the BFD as "binary", however, if you follow the call chain you'll end + up in build_id_to_debug_bfd_1, where we actually open the bfd. Notice + in here that we call build_id_verify to double check the build-id of + the file we found, this requires that the bfd not be opened as + "binary". + + What this means is that we always have to first open the bfd using the + gnutarget target type (for the build-id check), and then we would have + to reopen it as "binary". There seems little point pushing the reopen + logic into find_objfile_by_build_id, so we just do this in the + ::build_file_mappings function. + + I've extended the tests to cover the two cases which actually changed + in this commit. + +2024-09-07 Andrew Burgess + + gdb: improve shared library build-id check for core-files + When GDB opens a core file, in 'core_target::build_file_mappings ()', + we collection information about the files that are mapped into the + core file, specifically, the build-id and the DT_SONAME attribute for + the file, which will be set for some shared libraries. + + We then cache the DT_SONAME to build-id information on the core file + bfd object in the function set_cbfd_soname_build_id. + + Later, when we are loading the shared libraries for the core file, we + can use the library's file name to look in the DT_SONAME to build-id + map, and, if we find a matching entry, we can use the build-id to + validate that we are loading the correct shared library. + + This works OK, but has some limitations: not every shared library will + have a DT_SONAME attribute. Though it is good practice to add such an + attribute, it's not required. A library without this attribute will + not have its build-id checked, which can lead to GDB loading the wrong + shared library. + + What I want to do in this commit is to improve GDB's ability to use + the build-ids extracted in core_target::build_file_mappings to both + validate the shared libraries being loaded, and then to use these + build-ids to potentially find (via debuginfod) the shared library. + + To do this I propose making the following changes to GDB: + + (1) Rather than just recording the DT_SONAME to build-id mapping in + set_cbfd_soname_build_id, we should also record, the full filename to + build-id mapping, and also the memory ranges to build-id mapping for + every memory range covered by every mapped file. + + (2) Add a new callback solib_ops::find_solib_addr. This callback + takes a solib object and returns an (optional) address within the + inferior that is part of this library. We can use this address to + find a mapped file using the stored memory ranges which will increase + the cases in which a match can be found. + + (3) Move the mapped file record keeping out of solib.c and into + corelow.c. Future commits will make use of this information from + other parts of GDB. This information was never solib specific, it + lived in the solib.c file because that was the only user of the data, + but really, the data is all about the core file, and should be stored + in core_target, other parts of GDB can then query this data as needed. + + Now, when we load a shared library for a core file, we do the + following lookups: + + 1. Is the exact filename of the shared library found in the filename + to build-id map? If so then use this build-id for validation. + + 2. Find an address within the shared library using ::find_solib_addr + and then look for an entry in the mapped address to build-id map. + If an entry is found then use this build-id. + + 3. Finally, look in the soname to build-id map. If an entry is + found then use this build-id. + + The addition of step #2 here means that GDB is now far more likely to + find a suitable build-id for a shared library. Having acquired a + build-id the existing code for using debuginfod to lookup a shared + library object can trigger more often. + + On top of this, we also create a build-id to filename map. This is + useful as often a shared library is implemented as a symbolic link to + the actual shared library file. The mapped file information is stored + based on the actual, real file name, while the shared library + information holds the original symbolic link file name. + + If when loading the shared library, we find the symbolic link has + disappeared, we can use the build-id to file name map to check if the + actual file is still around, if it is (and if the build-id matches) + then we can fall back to use that file. This is another way in which + we can slightly increase the chances that GDB will find the required + files when loading a core file. + + Adding all of the above required pretty much a full rewrite of the + existing set_cbfd_soname_build_id function and the corresponding + get_cbfd_soname_build_id function, so I have taken the opportunity to + move the information caching out of solib.c and into corelow.c where + it is now accessed through the function core_target_find_mapped_file. + + At this point the benefit of this move is not entirely obvious, though + I don't think the new location is significantly worse than where it + was originally. The benefit though is that the cached information is + no longer tied to the shared library loading code. + + I already have a second set of patches (not in this series) that make + use of this caching from elsewhere in GDB. I've not included those + patches in this series as this series is already pretty big, but even + if those follow up patches don't arrive, I think the new location is + just as good as the original location. + + Rather that caching the information within the core file BFD via the + registry mechanism, the information used for the mapped file lookup is + now stored within the core_file target directly. + +2024-09-07 Andrew Burgess + + gdb/corefile: improve file backed mapping handling + This commit improves how GDB handles file backed mappings within a + core file, specifically, this is a restructuring of the function + core_target::build_file_mapping. + + The primary motivation for this commit was to put in place the + infrastructure to support the next commit in this series, but this + commit does itself make some improvements. + + Currently in core_target::build_file_mapping we use + gdbarch_read_core_file_mappings to iterate over the mapped regions + within a core file. + + For each region a callback is invoked which is passed details of the + mapping; the file the mapping is from, the offset into the file, and + the address range at which the mapping exists. We are also passed the + build-id for the mapped file in some cases. + + We are only told the build-id for the mapped region which actually + contains the ELF header of the mapped file. Other regions of the same + mapped ELF will not have the build-id passed to the callback. + + Within core_target::build_file_mapping, in the per-region callback, we + try to find the mapped file based on its filename. If the file can't + be found, and if we have a build-id then we'll ask debuginfod to + download the file. + + However we find the file, we cache the opened bfd object, which is + good. Subsequent mappings from the same file will not have a build-id + set, but by that point we already have a cached open bfd object, so + the lack of build-id is irrelevant. + + The problem with the above is that if we find a matching file based on + the filename, then we accept that file, even if we have a build-id, + and the build-id doesn't match. + + Currently, the mapped region processing is done in a single pass, we + call gdbarch_read_core_file_mappings, and for each mapping, as we see + it, we create the data structures needed to represent that mapping. + + In this commit, I will change this to a two phase process. In the + first phase the mappings are grouped together based on the name of the + mapped file. At the end of phase one we have a 'struct mapped_file', + a new struct, for each mapped file. This struct associates an + optional build-id with a list of mapped regions. + + In the second phase we try to find the file using its filename. If + the file is found, and the 'struct mapped_file' has a build-id, then + we'll compare the build-id with the file we found. This allows us to + reject on-disk files which have changed since the core file was + created. + + If no suitable file was found (either no file found, or a build-id + mismatch) then we can use debuginfod to potentially download a + suitable file. + + NOTE: In the future we could potentially add additional sanity + checks here, for example, if a data-file is mapped, and has no + build-id, we can estimate a minimum file size based on the expected + mappings. If the file we find is not big enough then we can reject + the on-disk file. But I don't know how useful this would actually + be, so I've not done that for now. + + Having found (or not) a suitable file then we can create the data + structures for each mapped region just as we did before. + + The new functionality here is the extra build-id check, and the + possibility of rejecting an on-disk file if the build-id doesn't + match. + + This change could have been done within the existing single phase + approach I think, however, in the next approach I need to have all the + mapped regions associated with the expected build-id, and the new two + phase structure allows me to do that, this is the reason for such an + extensive rewrite in this commit. + + There's a new test that exercises GDB's ability to find mapped files + via the build-id, and this downloading from debuginfod. + +2024-09-07 Andrew Burgess + + gdb/corefile: don't pretend unavailable sections are readable + When GDB opens a core file the bfd library processes the core file and + creates sections within the bfd object to represent each of the + segments within the core file. + + GDB then creates two target_section lists, m_core_section_table and + m_core_file_mappings, these, along with m_core_unavailable_mappings, + are used by GDB to implement core_target::xfer_partial; this is the + function used when GDB tries to read memory from a core file inferior. + + The m_core_section_table list represents sections within the core file + itself. The sections in this list can be split into two groups based + on whether the section has the SEC_HAS_CONTENTS flag set or not. + + Sections (from the core file) that have the SEC_HAS_CONTENTS flag had + their contents copied into the core file when the core file was + created. These correspond to writable sections within the original + inferior (the inferior for which the core file was created). + + Sections (from the core file) that do not have the SEC_HAS_CONTENTS + flag will not have had their contents copied into the core file when + it was created. These sections correspond to read-only sections + mapped from a file (possibly the initial executable, or possibly some + other file) in the original inferior. The expectation is that the + contents of these sections can still be found by looking in the file + that was originally mapped. + + The m_core_file_mappings list is created when GDB parses the mapped + file list in the core file. Every mapped region will be covered by + entries in the m_core_section_table list (see above), but for + read-only mappings the entry in m_core_section_table will not have the + SEC_HAS_CONTENTS flag set. As GDB parses the mapped file list, if the + file that was originally mapped can be found, then GDB creates an + entry in the m_core_file_mappings list which represents the region + of the file that was mapped into the original inferior. + + However, GDB only creates entries in m_core_file_mappings if it is + able to find the correct on-disk file to open. If the file can't be + found then an entry is added to m_core_unavailable_mappings instead. + + If is the handling m_core_unavailable_mappings which I think is + currently not completely correct. + + When a read lands within an m_core_unavailable_mappings region we + currently forward the read to the exec file stratum. The reason for + this is this: when GDB read the mapped file list, if the executable + file could not be found at the expected path then mappings within the + executable will end up in the m_core_unavailable_mappings list. + + However, the user might provide the executable to GDB from a different + location. If this happens then forwarding the read to the exec file + stratum might give a result. + + But, if the exec file stratum does not resolve the access then + currently we continue through ::xfer_partial, the next step of which + is to handle m_core_section_table entries that don't have the + SEC_HAS_CONTENTS flag set. Every m_core_unavailable_mappings entry + will naturally have an m_core_section_table without the + SEC_HAS_CONTENTS flag set, and so we treat the unavailable mapping as + zero initialised memory and return all zeros. + + It is this fall through behaviour that I think is wrong. If a read + falls in an unavailable region, and the exec file stratum cannot help, + then I think the access should fail. + + To achieve this goal I have removed the xfer_memory_via_mappings + helper function and moved its content inline into ::xfer_partial. + Now, if an access is within an m_core_unavailable_mappings region, and + the exec file stratum doesn't help, we immediately return with an + error. + + The reset of ::xfer_partial is unchanged, I've extended some comments + in the area that I have changed to (I hope) explain better what's + going on. + + There's a new test that covers the new functionality, an inferior maps + a file and generates a core file. We then remove the mapped file, + load the core file and try to read from the mapped region. The + expectation is that GDB should give an error rather than claiming that + the region is full of zeros. + +2024-09-07 Xin Wang + + Not append rela for absolute symbol + LoongArch: Not append rela for absolute symbol + + Use la.global to get absolute symbol like la.abs. + la.global put address of a global symbol into a got + entry and append a rela for it, which will be used + to relocate by dynamic linker. Dynamic linker should + not relocate for got entry of absolute symbol as it + stores symval not symbol's address. + +2024-09-07 Xin Wang + + Add macros to get opcode of instructions approriately + LoongArch: Add macros to get opcode and register of instructions appropriately + + Currently, we get opcode of an instruction by manipulate the binary with + it's mask, it's a bit of a pain. Now a macro is defined to do this and a + macro to get the RD and RJ registers which is applicable to most instructions + of LoongArch are added. + +2024-09-07 GDB Administrator + + Automatic date update in version.in + +2024-09-06 Vladimir Mezentsev + + Rename gp-* man pages to gprofng-* man pages + gprofng/ChangeLog + 2024-09-05 Vladimir Mezentsev . + + * doc/gp-archive.texi: Rename to doc/gprofng-archive.texi. + * doc/gp-collect-app.texi: Rename to doc/gprofng-collect-app.texi. + * doc/gp-display-html.texi: Rename to doc/gprofng-display-html.texi. + * doc/gp-display-src.texi: Rename to doc/gprofng-display-src.texi. + * doc/gp-display-text.texi: Rename to doc/gprofng-display-text.texi. + * doc/gp-macros.texi: Add new macros. + * doc/gprofng.texi: Rename man pages. + * doc/gprofng_ug.texi: Likewise. + * doc/Makefile.am: Likewise. + * doc/Makefile.in: Rebuild. + +2024-09-06 Tom Tromey + + Fix 'catch exception' with -flto + A user noticed that when an Ada program (including the runtime) is + compiled with -flto, then "catch exception" does not work -- even + though setting the equivalent breakpoint by hand does work. + + Looking into this, it turns out that GCC puts the exception functions + from the Ada runtime into a CU that uses the C language, not Ada. + Then, when trying to look up the relevant symbol, + lookup_name_info::search_name_hash uses the "verbatim" form of the + symbol name (like "<__gnat_debug_raise_exception>") rather than the + "<>"-less form, causing the symbol not to be found. + + This patch fixes the problem in two steps. + + First, lookup_name_info::search_name_hash is changed to use the same + hack that language_defn::get_symbol_name_matcher uses. That is, when + the current language is Ada, verbatim-mode lookups are special-cased. + (This is a bit unfortunate; perhaps a better long term approach would + be to promote verbatim mode to a fundamental mode of + lookup_name_info.) + + Second, although the above fixes the problem in the Ada language mode, + the code still fails in other languages. However, due to the way + these lookups are coded in ada-lang.c, I think it makes sense to + temporarily set the current language to Ada in + create_ada_exception_catchpoint. + + Tested on x86-64 Fedora 38. + + A new test case that mimics the -flto scenario is included. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-06 Tom Tromey + + Clear Ada symbol cache + This patch changes "maint flush symbol-cache" to also flush the + Ada-specific symbol cache. This can be helpful when working on the + Ada code. + + Approved-By: Tom de Vries + +2024-09-06 Tom Tromey + + Test -fgnat-encodings=all in tagged_access.exp + While working on a longer series, I needed to make sure this + particular test kept working with -fgnat-encodings=all, so this patch + adds it to the test. + + Introduce and use foreach_gnat_encoding + gnat-llvm does not support the -fgnat-encodings flag. This patch + prepares gdb's Ada tests to handle this situation by introducing a new + foreach_gnat_encoding. A subsequent patch may change this to support + gnat-llvm; meanwhile this is a little cleaner anyway. + +2024-09-06 Bernd Edlinger + + Fix the build-id option for GCC default configuration + It is possible that the compiler is configured to do + so automatically, but at least for GCC the configure option + --enable-linker-build-id is not enabled by default. + So the option -Wl,--build-id should be used regardless + of which compiler is used. + + Approved-By: Tom de Vries + +2024-09-06 Shahab Vahedi + + bfd: Fix GCC warning when CFLAGS="-Og" is used + This patch initializes the "op" variable in skip_cfa_op() function + of bfd/elf-eh-frame.c to "0" at its declaration point to avoid the + "maybe-uninitialized" warning. + + Building binutils on a system with GCC version 13.2.0 and a configure + command that sets the optimization level to "-Og" leads to a build + failure because of a warning being treated as an error: + --------------------------------------------------------------------- + $ ./configure CFLAGS="-Og" + $ make + ... + CC elf-eh-frame.lo + /src/gdb/bfd/elf-eh-frame.c: In function 'skip_cfa_op': + /src/gdb/bfd/elf-eh-frame.c:354:33: error: 'op' may be used + uninitialized [-Werror=maybe-uninitialized] + 354 | switch (op & 0xc0 ? op & 0xc0 : op) + | ~~~~~~~~~~~~~~~~~~~~~~^~~~ + /src/gdb/bfd/elf-eh-frame.c:348:12: note: 'op' was declared here + 348 | bfd_byte op; + | ^~ + cc1: all warnings being treated as errors + ... + --------------------------------------------------------------------- + + The relevant code snippet related to this warning looks like: + --------------------------------------------------------------------- + static inline bool + read_byte (bfd_byte **iter, bfd_byte *end, unsigned char *result) + { + if (*iter >= end) + return false; + *result = *((*iter)++); + return true; + } + + static bool + skip_cfa_op (bfd_byte **iter, bfd_byte *end,...) + { + bfd_byte op; + + if (!read_byte (iter, end, &op)) + return false; + + switch (op & 0xc0 ? op & 0xc0 : op) + ... + } + --------------------------------------------------------------------- + + This warning probably happens because "-Og" results in GCC not + inlining the "read_byte()" function. Therefore, GCC treats its + invocation inside "skip_cfa_op()" like a black box and that ends + in the aforementioned warning. + + Acknowledgement: + Lancelot Six -- for coming with the idea behind this fix. + Jan Beulich -- for reviewing. + + bfd/ChangeLog: + * elf-eh-frame.c (skip_cfa_op): Initialize the "op" variable. + +2024-09-06 Jan Beulich + + x86/APX: use D for 2-operand CFCMOVcc + There's no need to have 30 redundant templates when we can easily take + care of the operand swapping like we do for various other insns. + + x86/APX: optimize certain reg-only CFCMOVcc forms + Along the lines of 2513312930b2 ("x86/APX: apply NDD-to-legacy + transformation to further CMOVcc forms") these can similarly be + converted to the shorter legacy-encoded CMOVcc. + + bfd/PE: correct SizeOfImage calculation + We don't really want to align the last section's size to object + alignment (when that section may itself not be aligned as much), we want + image size to be a multiple thereof. + + x86: templatize VNNI templates + Reduce redundancy, in preparation of the addition of further counterparts + for AVX10.2. + +2024-09-06 GDB Administrator + + Automatic date update in version.in + +2024-09-05 Mark Harmstone + + bfd/pdb: fix -Wmaybe-uninitialized warning + Initialize stream0_start to fix spurious -Wmaybe-uninitialized warning + on some versions of gcc. + +2024-09-05 Alan Modra + + PR32136, Use-of-uninitialized-memory in evax_bfd_print_image + PR 32136 + * vms-alpha.c (evax_bfd_print_image): Sanity check various string + lengths. + +2024-09-05 Thiago Jung Bauermann + + gdbserver: aarch64: Fix expedited registers list + Since this commit: + + commit a8651ef51822f91ec86d0d5caffbf2e50b174c23 + CommitDate: Fri Jun 14 14:47:38 2024 +0100 + + gdb/aarch64: prevent crash from in process agent + + gdbserver isn't sending expedited registers with its stop reply packets + anymore. The problem is with how the constructor of the + expedited_registers std::vector is called: + + The intent of the expedited_registers initialization in + aarch64_linux_read_description is to create a vector with capacity for 6 + elements, but that's not how the std::vector constructor works. + + Instead it creates a vector pre-populated with 6 elements initialized + with the default value for the type of the elements, and thus the first + 6 elements are null pointers. The actual expedited registers are added + starting at the 7th element. + + This causes init_target_desc to consider that the expedite_regs list is + empty, since it stops checking at the first nullptr element. The end + result is that gdbserver doesn't send any expedited registers to GDB in + its stop replies. + + Fix by not specifying an element count when declaring the vector. + + Tested for regressions on aarch64-linux-gnu native-extended-remote. + + Approved-By: Andrew Burgess + +2024-09-05 Lulu Cai + + LoongArch: Fixed ABI v1.00 TLS dynamic relocation generation bug + Commit "b67a17aa7c0c478a" modified the logic of allocating dynamic + relocation space for TLS GD/IE, but only modified the logic of + generation dynamic relocations for TLS GD/IE in ABI v2.00. When + linking an object file of ABI v1.00 with bfd ld of ABI v2.00, it + will cause an assertion failure. + + Modified the dynamic relocation generation logic of TLS GD/IE + in ABI v1.00 to be consistent with ABI v2.00. + +2024-09-05 GDB Administrator + + Automatic date update in version.in + +2024-09-04 Vladimir Mezentsev + + Fix 32097 Warnings when building gprofng with Clang + gprofng/ChangeLog + 2024-09-03 Vladimir Mezentsev . + + PR gprofng/32097 + * common/hwcdrv.c: Fix -Wempty-body warnings. + * common/hwcentry.h: Fix -Wdeprecated-non-prototype warnings. + * common/hwctable.c: Fix -Wdeprecated-non-prototype warnings. + * libcollector/collector.c: Likewise. + * libcollector/collector.h: Likewise. + * libcollector/collectorAPI.c: Likewise. + * libcollector/dispatcher.c: Likewise. + * libcollector/iotrace.c: Likewise. + * libcollector/libcol_util.c: Fix -Wunused-but-set-variable warnings. + * libcollector/libcol_util.h: Remove unused declarations. + * libcollector/linetrace.c: Fix -Wdeprecated-non-prototype warnings. + * src/BaseMetricTreeNode.h: Fix -Wunused-private-field warnings. + * src/Dbe.cc: Fix -Wself-assign warnings. + * src/DbeSession.cc: Fix -Wunused-but-set-variable warnings. + * src/Disasm.cc: Fix -Wunused-const-variable warnings. + * src/Experiment.cc: Fix -Wunused-private-field warnings. + * src/HashMap.h: Fix -Wself-assign warnings. + * src/IOActivity.h: Fix -Wunused-private-field warnings. + * src/collctrl.cc: Fix -Wself-assign, -Wparentheses-equality warnings. + * src/collctrl.h: Fix -Wunused-private-field warnings. + * src/collector_module.h: Fix -Wdeprecated-non-prototype warnings. + * src/gp-display-src.cc: Fix -Wunused-private-field warnings. + * src/gp-print.h: Fix -Wheader-guard warnings. + * src/hwc_intel_icelake.h: Fix -Winitializer-overrides warnings. + * src/util.cc: Fix -Wunused-but-set-variable warnings. + +2024-09-04 Tom Tromey + + Improve comments in dwarf2/parent-map.h + I noticed that the comments for class parent_map aren't very clear. + This patch attempts to fix this, and also clarifies a point on + parent_map_map::add_map. + + Approved-By: Simon Marchi + +2024-09-04 Andrew Burgess + + gdb: reformat Python file with black + Fix formatting of a Python file added in commit: + + commit a92e943014f5e8d6a2eaccaf8a725941ac47a121 + Date: Wed Aug 14 15:16:46 2024 +0100 + + gdb: implement ::re_set method for catchpoint class + + No functional change after this commit. + +2024-09-04 Andrew Burgess + + libiberty: sync with gcc + This syncs binutils-gdb/libiberty with gcc/libiberty up to GCC commit + 64028d626a50410dbf29. This picks up the follow 3 GCC commits: + + ea238096883 (gcc-delete-unused-func) libiberty/argv.c: remove only_whitespace + 5e1d530da87 (gcc-buildargv) libiberty/buildargv: handle input consisting of only white space + a87954610f5 libiberty/buildargv: POSIX behaviour for backslash handling + +2024-09-04 Andrew Burgess + + gdb: implement ::re_set method for catchpoint class + It is possible to attach a condition to a catchpoint. This can't be + done when the catchpoint is created, but can be done with the + 'condition' command, this is documented in the GDB manual: + + You can also use the 'if' keyword with the 'watch' command. The + 'catch' command does not recognize the 'if' keyword; 'condition' is the + only way to impose a further condition on a catchpoint. + + A GDB crash was reported against Fedora GDB where a user had attached + a condition to a catchpoint and then restarted the inferior. When the + catchpoint was hit GDB would immediately segfault. I was able to + reproduce the failure on upstream GDB: + + (gdb) file ./some/binary + (gdb) catch syscall write + (gdb) run + ... + Catchpoint 1 (returned from syscall write), 0x00007ffff7b594a7 in write () from /lib64/libc.so.6 + (gdb) condition 1 $_streq((char *) $rsi, "foobar") == 0 + (gdb) run + ... + Fatal signal: Segmentation fault + ... + + What happened here is that on the system in question we had debug + information available for both the main application and also for + libc. + + When the condition was attached GDB was stopped inside libc and as the + debug information was available GDB found a reference to the 'char' + type (for the cast) inside libc's debug information. + + When the inferior is restarted GDB discards all of the objfiles + associated with shared libraries, and this includes libc. As such the + 'char' type, which is objfile owned, is discarded and the reference to + it from the catchpoint's condition expression becomes invalid. + + Now, if it were a breakpoint instead of a catchpoint, what would + happen is that after the shared library objfiles had been discarded + we'd call the virtual breakpoint::re_set method on the breakpoint, and + this would update the breakpoint's condition expression. This is + because user breakpoints are actually instances of the code_breakpoint + class and the code_breakpoint::re_set method contains the code to + recompute the breakpoint's condition expression. + + However, catchpoints are instances of the catchpoint class which + inherits from the base breakpoint class. The catchpoint class does + not override breakpoint::re_set, and breakpoint::re_set is empty! + + The consequence of this is that catchpoint condition expressions are + never recomputed, and the dangling pointer to the now deleted, objfile + owned type 'char' is left around, and, when the catchpoint is hit, the + invalid pointer is used when GDB tries to evaluate the condition + expression. + + In this commit I have implemented catchpoint::re_set. This is pretty + simple and just recomputes the condition expression as you'd expect. + If the condition doesn't evaluate then the catchpoint is marked as + disabled_by_cond. + + I have also made breakpoint::re_set pure virtual. With the addition + of catchpoint::re_set every sub-class of breakpoint now implements the + ::re_set method, and if new sub-classes are added in the future I + think that they _must_ implement ::re_set in order to avoid this + problem. As such falling back to an empty breakpoint::re_set doesn't + seem helpful. + + For testing I have not relied on stopping in libc and having libc + debug information available, this doesn't seem like a good idea for + the GDB testsuite. Instead I create a (rather pointless) condition + check that uses a type defined only within a shared library. When the + inferior is restarted the catchpoint will temporarily be marked as + disabled_by_cond (due to the type not being available), but once the + shared library is loaded again the catchpoint will be re-enabled. + Without the fixes above then the same crashing behaviour can be + observed. + + One point of note: the dangling pointer of course exposes undefined + behaviour, with no guarantee of a crash. Though a crash is what I + usually see I have see GDB throw random errors from the expression + evaluation code, and once, I saw no problem at all! If you recompile + GDB with the address sanitizer, or run under valgrind, then the bug + will be exposed every time. + + After fixing this bug I checked bugzilla and found PR gdb/29960 which + is the same bug. I was able to reproduce the bug before this commit, + and after this commit GDB is no longer crashing. + + Before: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + [Inferior 1 (process 1101855) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) run + Starting program: /tmp/hello.x + + Fatal signal: Segmentation fault + ... + + And after: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + Args: ( 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 ) + [Inferior 1 (process 1102373) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) r + Starting program: /tmp/hello.x + Error in testing condition for breakpoint 1: + Attempt to extract a component of a value that is not a structure. + + Catchpoint 1 (call to syscall write), 0x00007ffff7eb94a7 in write () + from /lib64/libc.so.6 + (gdb) ptype write + type = () + (gdb) + + Notice we get the error now when the condition fails to evaluate. + This seems reasonable given that 'write' will be a function, and + indeed the final 'ptype' shows that it's a function, not a struct. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29960 + + Reviewed-By: Tom de Vries + +2024-09-04 Christophe Lyon + + Revert "contrib: Add autoregen.py" + This reverts commit e1ad04ad6cd43fb5a876d787da5ac29f72a9c7e5. + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/riscv-tdesc-regs.exp + On riscv64-linux, with test-case gdb.arch/riscv-tdesc-regs.exp I get: + ... + (gdb) info registers fflags^M + fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers fflags + info registers frm^M + frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers frm + ... + + The FAILs are produced by: + ... + foreach reg {fflags frm} { + gdb_test_multiple "info registers $reg" "" { + -re "^info registers $reg\r\n" { + exp_continue + } + + -wrap -re "^Invalid register `$reg`" { + fail $gdb_test_name + } + + -wrap -re "^$reg\\s+\[^\r\n\]+" { + pass $gdb_test_name + } + } + } + ... + + The first clause is meant to consume the command. + + The '^' char was updated to mean "consume command", so that clause no longer + works since it now attempts to consume the command twice. + + Also, it's unnecessary because the following clauses start with ^. + + Then, the second clause is unnecessary because there's a default clause + producing the FAIL. + + Fix this by simplifying to: + ... + foreach reg {fflags frm} { + gdb_test "info registers $reg" "^$reg\\s+\[^\r\n\]+" + } + ... + + Tested on riscv64-linux. + + Approved-By: Andrew Burgess + +2024-09-04 Christophe Lyon + + arm: Do not insert stubs needing Arm code on Thumb-only cores. + We recently fixed a bug in libgcc + (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360) + where a symbol was missing a %function .type decoration. + + This meant the linker would silently pick the wrong type of 'farcall + stub', involving Arm-mode instructions on Thumb-only CPUs. + + This patch emits an error instead, and warns in some other cases, to + encourage users to add the missing '.type foo,%function' directive. + + In practice: in arm_type_of_stub() we no longer try to infer which + stub to use if the destination is of unknown type and the CPU is + Thumb-only; so we won't lie to elf32_arm_size_stubs() which does not + check branch_type. + + If branch_type is ST_BRANCH_TO_ARM but the CPU is Thumb-only, we now + convert it to ST_BRANCH_TO_THUMB only if the destination is of + absolute type. This is to support the case where the destination of + the branch is defined by the linker script (see thumb-b-lks-sym.s and + thumb-bl-lks-sym.s testcases for instance). + + The motivating case is covered by the new farcall-missing-type + testcase, where we now emit an error message. We do not emit an error + when branch_type is ST_BRANCH_UNKNOWN and the CPU supports Arm-mode: a + lot of legacy code (e.g. newlib's crt0.S) lacks the corresponding + '.type foo, %function' directives and even a (too verbose) warning + could be perceived as a nuisance. + + Existing testcases where such a warning would trigger: + arm-static-app.s (app_func, app_func2) + arm-rel32.s (foo) + arm-app.s (app_func) + rel32-reject.s () main) + fix-arm1176.s (func_to_branch_to) + but this list is not exhaustive. + + For the sake of clarity, the patch replaces occurrences of + sym.st_target_internal = 0; with + sym.st_target_internal = ST_BRANCH_TO_ARM; + + enum arm_st_branch_type is defined in include/elf/arm.h, and relies on + ST_BRANCH_TO_ARM==0, as sym.st_target_internal is also initialized to + 0 in other target-independent parts of BFD code. (For instance, + swapping the ST_BRANCH_TO_ARM and ST_BRANCH_TO_THUMB entries in the + enum definition leads to 'interesting' results...) + + Regarding the testsuite: + * new expected warning for thumb-b-lks-sym and thumb-bl-lks-sym + * new testcase farcall-missing-type to check the new error case + * attr-merge-arch-2b.s, branch-futures (and bfs-1.s) updated to avoid + a diagnostic + + Tested on arm-eabi and arm-pe with no regression. + +2024-09-04 Christophe Lyon + + contrib: Add autoregen.py + This script is a copy of the current script used by Sourceware's + autoregen buildbots. + + It is intended as a helper to regenerate files managed by autotools + (autoconf, automake, aclocal, ....), as well as the toplevel + Makefile.in which is created by autogen. + + Other files can be updated when using maintainer-mode, but this is not + covered by this script. + + 2024-04-19 Christophe Lyon + + contrib/ + * autoregen.py: New script. + +2024-09-04 Shahab Vahedi + + MAINTAINERS: Update my email address + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linux + With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into: + ... + (gdb) break bar_label^M + Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M + (gdb) continue^M + Continuing.^M + ^M + Breakpoint 2, bar () at dw2-lines.c:29^M + 29 foo (2);^M + (gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\) + ... + + The pass is incorrect because the continue lands at line 29 with "foo (2)" + instead of line line 27 with "foo (1)". + + A minimal version is: + ... + $ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label" + Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29. + ... + where: + ... + 000004ec : + 4ec: b580 push {r7, lr} + 4ee: af00 add r7, sp, #0 + + 000004f0 : + 4f0: 2001 movs r0, #1 + 4f2: f7ff fff1 bl 4d8 + + 000004f6 : + 4f6: 2002 movs r0, #2 + 4f8: f7ff ffee bl 4d8 + ... + + So, how does this happen? In short: + - skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec, + - thumb_analyze_prologue returns 0x4f2 + (overshooting by 1 insn, PR tdep/31981), and + - skip_prologue_sal decides that we're mid-line, and updates to 0x4f6. + + However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue + use the line info to skip the prologue? + + The answer is that the line info starts at bar_label, not at bar. + + Fixing that allows us to work around PR tdep/31981. + + Likewise in gdb.dwarf2/dw2-line-number-zero.exp. + + Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to + checking quality of architecture-specific prologue analysis, without being + written in an architecture-specific way. + + If fails on arm-linux for both marm and mthumb: + ... + FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much) + FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much) + ... + and passes for: + - x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie} + - aarch64-linux. + + Tested on arm-linux. + +2024-09-04 Mark Harmstone + + bfd/pdb: fix bitmap generation in pdb_write_bitmap + MSVC 2022 is more pedantic than MSVC 2019 when it comes to loading PDB + files in readonly mode, and was rejecting PDB files generated by binutils + because of their invalid free-space bitmaps. It's unknown what would + have happened if you tried to use MS tools to modify a PDB created by + binutils, but it probably would have led to a corrupted file. + + This patch fixes pdb_write_bitmap so we generate files that MSVC will accept. + + Specifically there were three things we were doing wrong: + + - We weren't including the superblock (block 0) + + - We were setting bits in bytes backwards (MSB to LSB, rather than LSB to MSB) + + - We should have been marking the contents of stream 0 as free. This is + because, as the comment says, it's intended to be used for the + directory for the previous write, to allow atomic updates. + +2024-09-04 GDB Administrator + + Automatic date update in version.in + +2024-09-03 Tom de Vries + + [gdb] Fix typos + Fix a few typos. + + unconditionaly -> unconditionally + gratuitiously -> gratuitously + configureable -> configurable + represention -> representation + distiguished -> distinguished + breakpointer -> breakpoint + asssignments -> assignments + architectual -> architectural + compatibity -> compatibility + adjustement -> adjustment + unexcepted -> unexpected + propogated -> propagated + consistant -> consistent + succeding -> succeeding + higlight -> highlight + detachs -> detach + + Tested by rebuilding on x86_64-linux. + + Approved-By: Simon Marchi + +2024-09-03 Mary Bennett + + RISC-V: Add support for XCVsimd extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvsimd` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): Add custom operands. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVsimd as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvsimd. + * testsuite/gas/riscv/x-cv-simd.d: New test. + * testsuite/gas/riscv/x-cv-simd.s: New test. + * testsuite/gas/riscv/x-cv-simd-fail.d: New test. + * testsuite/gas/riscv/x-cv-simd-fail.l: New test. + * testsuite/gas/riscv/x-cv-simd-fail.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVsimd. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVsimd. + (enum riscv_insn_class): Add the XCVsimd instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add custom operands. + * riscv-opc.c: Add XCVsimd instructions. + +2024-09-03 GDB Administrator + + Automatic date update in version.in + +2024-09-02 Haochen Jiang + + Support ymm rounding control for Intel AVX10.2 + In the patch, in order to support ymm rounding for AVX10.2, we derive + evex attribute for all cases instead of only for rc_none to encode U bit. + Also changed some bad_opcode return due to the share of U bit with APX_F. + + gas/ChangeLog: + + * config/tc-i386.c + (cpu_flags_match): Handle AVX10_2. + (build_evex_prefix): Handle U bit. Derive evex attribute + for all cases. + (check_VecOperands): Handle AVX10.2 and ymm roundings. + * doc/c-i386.texi: Document .avx10.2. + * testsuite/gas/i386/i386.exp: Run AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-rounding-intel.d: New test. + * testsuite/gas/i386/avx10_2-rounding-inval.l: Ditto. + * testsuite/gas/i386/avx10_2-rounding-inval.s: Ditto. + * testsuite/gas/i386/avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/avx10_2-rounding.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (struct instr_info): Add U bit. + (get_valid_dis386): Handle U bit. + * i386-gen.c (isa_dependencies): Add AVX10.2. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-opc.h (CpuAVX10_2): New. + (i386_cpu_flags): Add cpuavx10_2. + * i386-opc.tbl: Add rounding to old entries which do not + permit rounding previously. Also eliminate the redundant + RegXMM for vcvtps2uqq. + * i386-tbl.h: Regenerated. + +2024-09-02 GDB Administrator + + Automatic date update in version.in + +2024-09-01 GDB Administrator + + Automatic date update in version.in + +2024-08-31 H.J. Lu + + x86: Fix comment typos in TLS relocation check + R_386_TLS_IE is used only in + + movl foo@indntpoff, %eax + movl foo@indntpoff, %reg + addl foo@indntpoff, %reg + + R_386_TLS_DESC_CALL and R_X86_64_TLSDESC_CALL are used only in + + call *x@tlscall(%[er]ax) + + * elf32-i386.c (elf_i386_check_tls_transition): Use foo@indntpoff + in comments for R_386_TLS_IE check. + (elf_i386_tls_transition): Use @tlscall in comments for + R_386_TLS_DESC_CALL check. + * elf64-x86-64.c (elf_x86_64_tls_transition): Use @tlscall in + comments for R_X86_64_TLSDESC_CALL check. + +2024-08-31 H.J. Lu + + gold: Always resolve non-default weak undefined to 0 + Non-default weak undefined symbols in executable and shared library are + always resolved to 0 at runtime and don't need dynamic relocation. + + Tested on i686, x86-64, powerpc64le and aarch64. + + PR gold/32071 + * symtab.cc (Symbol::final_value_is_known): Always resolve + non-default weak undefined symbol in executable and shared library + to 0 at runtime. + * symtab.h (Symbol::needs_dynamic_reloc): Return false for + non-default weak undefined symbol in executable and shared library. + * testsuite/Makefile.am: Add weak_undef_test_3 and + weak_undef_test_4 tests. + * testsuite/Makefile.in: Regenerated. + * testsuite/weak_undef_lib_4.c: New file. + * testsuite/weak_undef_test_3.c: Likewise. + * testsuite/weak_undef_test_4.c: Likewise. + +2024-08-31 Tom de Vries + + [gdb/testsuite] Handle unsupported catch syscall + On riscv64-linux, I run into: + ... + Expecting: ^(catch syscall[^M + ]+)?((&.*)*.*~"Catchpoint 5 .*\\n".*=breakpoint-created,bkpt=\{number="5",type="catchpoint".*\}.*\n\^done[^M + ]+[(]gdb[)] ^M + [ ]*) + catch syscall^M + &"catch syscall\n"^M + &"The feature 'catch syscall' is not supported on this architecture yet.\n"^M + ^error,msg="The feature 'catch syscall' is not supported on this architecture yet."^M + (gdb) ^M + FAIL: gdb.mi/mi-breakpoint-changed.exp: test_insert_delete_modify: catch syscall (unexpected output) + ... + + Fix this by: + - factoring out proc supports_catch_syscall out of gdb.base/catch-syscall.exp, + and + - using it in gdb.mi/mi-breakpoint-changed.exp. + + Tested on x86_64-linux and riscv64-linux. + + Approved-By: Andrew Burgess + +2024-08-31 GDB Administrator + + Automatic date update in version.in + +2024-08-30 Andrew Burgess + + gdb: remove duplicate check in disable_breakpoints_in_freed_objfile + I spotted that we have a duplicate condition check in the function + disable_breakpoints_in_freed_objfile. + + Lets remove it. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-08-30 Simon Marchi + + gdb/dwarf2: cleanup includes + Cleanup includes in dwarf2/*. + + 1. Add the necessary includes so that clangd reports no errors when + opening header files. This ensures that header files include what + they use. + + 2. Remove all includes reported as unused by clangd (except + gdb-safe-ctype.h, which I think does some magic that affects what + follows). + + Built-tested --enable-threading at "yes" and "no", since there are some + portions of code gated by `#ifdef CXX_STD_THREAD`. + + Change-Id: I21debffcd7c2caf90f08e1e0fbba3ce30422d042 + Approved-By: Tom Tromey + +2024-08-30 Tom Tromey + + Minor formatting fix in breakpoint.c + I noticed a spot in breakpoint.c that doesn't follow gdb's formatting + rules: the return type is on the same line as the method name. + +2024-08-30 Tom Tromey + + Fix regexp quoting in gdb.ada test cases + I noticed that some gdb.ada tests used regular expressions like: + + "Continuing\..*$inferior_exited_re.*" \ + + Here, the "\." should either be "." or "\\." -- "\." is not really + meaningful. + + This patch fixes all the cases of this I could find in gdb.ada. In + one test (fun_renaming.exp), using "\\." would result in failures, and + here I rewrote the tests to use -wrap. + + Approved-By: Andrew Burgess + +2024-08-30 H.J. Lu + + x86: Check invalid TLS descriptor call + TLS descriptor call, + + call *x@tlsdesc(%rax) + + or + + call *x@tlsdesc(%eax) + + calls _dl_tlsdesc_return which expects that RAX/EAX points to the TLS + descriptor. Update x86 linker to issue an error with or without TLS + transition. + + bfd/ + + PR ld/32123 + * elf32-i386.c (elf_i386_check_tls_transition): Move + R_386_TLS_DESC_CALL to ... + (elf_i386_tls_transition): Here. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Move. + R_X86_64_TLSDESC_CALL check to ... + (elf_x86_64_tls_transition): Here. + + ld/ + + PR ld/32123 + * testsuite/ld-i386/i386.exp: Run tlsgdesc3. + * testsuite/ld-i386/tlsgdesc3.d: New file. + * testsuite/ld-x86-64/tlsdesc5.d: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsdesc5. + +2024-08-30 Jan Beulich + + x86: replace conditional operators used to calculate booleans + The boolean expressions themselves are fine to use there. + + x86/APX: drop %SW disassembler macro again + Not the least due to its extremely rare use I didn't really like that + macro's introduction. Adjust swap_operand() accordingly instead. + +2024-08-30 Jan Beulich + + x86: limit RegRex64 use + The special property really only applies to the "extended" byte regs + having legacy word/dword counterparts. + + While touching involved code also drop redundant byte checks from a + conditional in establish_rex(): The other remaining RegRex64 uses only + exist on registers which can't be used as register operands anyway. + Hence RegRex64 as an attribute of a (valid) register operand implies + that it's a byte reg. + +2024-08-30 Jan Beulich + + gas: properly check for ELF in LISTING_NODEBUG handling + While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h + including obj-elf.h for obscure reasons), there still need to be IS_ELF + checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code + checking for ->debugging being true doesn't need such extra checks, as + the field can only ever be true when IS_ELF. + + On the same basis reduce #ifdef-ary in debugging_pseudo(). + + Also move the field (into what on 64-bit architectures is a 32-bit gap) + and put it inside an OBJ_ELF conditional, too. + + While there further switch int to bool in related code. + +2024-08-30 Jan Beulich + + gas: generated code/data listing output vs .endr and alike + These ending directives are swallowed by buffer_and_nest() and hence + aren't seen by read_a_source_file(). Thus they also weren't announced to + the listing subsystem. That was, when macro expansions are included, + thus misguided to associate possible output resulting from the first + line of the construct being expanded with both the .endr and that first + line (i.e. showing it twice). + +2024-08-30 Nicolás Ortega Froysa + + gdb/doc: fix typo in 'watch' command + * gdb/breakpoint.c (watch_option_defs): Fix typo. + +2024-08-30 Lulu Cai + + LoongArch: LoongArch64 allows relocations to use 64-bit addends + Relocations using 64-bit addends allow larger constant offset address + calculations to be fused. + +2024-08-30 GDB Administrator + + Automatic date update in version.in + +2024-08-29 Andrew Burgess + + gdb: reject inserting breakpoints between functions + When debugging ROCm code, you might have something like this: + + __global__ void kernel () + { + ... + // break here + ... + } + + int main () + { + // Code to call `kernel` + } + + ... where kernel is a function compiled to execute on the GPU. It does + not exist in the host x86-64 program that runs the main function, and + GDB doesn't know about that function until it is called, at which point + the runtime loads the corresponding code object and GDB learns about the + code of the "kernel" function. Before the GPU code object is loaded, + from the point of view of GDB, you might as well have blank lines + instead of the "kernel" function. The DWARF in the host program doesn't + describe anything at these lines. + + So, a common problem that users face is: + + - Start GDB with the host binary + - Place a breakpoint by line number at the "break here" line + - At this point, GDB only knows about the host code, the lines of the + `kernel` function are a big void. + - GDB finds no code mapped to the "break here" line and searches for + the first following line that has code mapped to it. + - GDB finds that the line with the opening bracket of the `main` + function (or around there) has code mapped to it, places breakpoint + there. + - User runs the program. + - The programs hits the breakpoint at the start of main. + - User is confused, because they didn't ask for a breakpoint in main. + + If they continue, the code object eventually gets loaded, GDB reads the + debug info from it, re-evaluates the breakpoint locations, and at this + point the breakpoint is placed at the expected location. + + The goal of this patch is to get rid of this annoyance. + + A case similar to the one shown above can actually be simulated without + GPU-specific code: using a single source file to generate a library and + an executable loading that library (see the new test + gdb.linespec/line-breakpoint-outside-function.c for an example). Before + the library is loaded, trying to place a breakpoint in the library code + results in the breakpoint "drifting" down to the main function. + + To address this problem, make it so that when a user requests a + breakpoint outside a function, GDB makes a pending breakpoint, rather + than placing a breakpoint at the next line with code, which happens to + be in the next function. When the GPU kernel or shared library gets + loaded, the breakpoint resolves to a location in the kernel or library. + + Note that we still want breakpoints placed inside a function to + "drift" down to the next line with code. For example, here: + + 9 + 10 void foo() + 11 { + 12 int x; + 13 + 14 x++; + + There is probably no code associated to lines 10, 12 and 13, but the + user can still reasonably expect to be able to put a breakpoint there. + In my experience, GCC maps the function prologue to the line with the + opening curly bracket, so the user will be able to place a breakpoint + there anyway (line 11 in the example). But I don't really see a use + case to put a breakpoint above line 10 and expect to get a breakpoint in + foo. So I think that is a reasonable behavior change for GDB. + + This is implemented using the following heuristic: + + - If a breakpoint is requested at line L but there is no code mapped to + L, search for a following line with associated code (this already + exists today). + - However, if: + + 1. the found location falls in a function symbol's block + 2. the found location's address is equal the entry PC of that + function + 3. the found location's line is greater that the requested line + + ... then we don't place a breakpoint at the found location, we will + end up with a pending breakpoint. + + Change the message "No line X in file..." to "No compiled code for line + X in file...". There is clearly a line 9 in the example above, so it + would be weird to say "No line 9 in file...". What we mean is that + there is no code associated to line 9. + + All the regressions that I found this patch to cause were: + + 1. tests specifically this behavior where placing a breakpoint before + a function results in a breakpoint on that function, in which case I + removed the tests or changed them to expect a pending breakpoint + 2. linespec tests expecting things like "break -line N garbage" to + error out because of the following garbage, but we now got a + different error because line N now doesn't resolve to something + anymore. For example, before: + + (gdb) break -line 3 if foofoofoo == 1 + No symbol "foofoofoo" in current context. + + became + + (gdb) break -line 3 if foofoofoo == 1 + No line 3 in the current file. + + These tests were modified to refer to a valid line with code, so + that we can still test what we intended to test. + + Notes: + + - The CUDA compiler "solves" this problem by adding dummy function + symbols between functions, that are never called. So when you try to + insert a breakpoint in the not-yet-loaded kernel, the breakpoint + still drifts, but is placed on some dummy symbol. For reasons that + would be too long to explain here, the ROCm compiler does not do + that, and it is not a desirable option. + + - You can have constructs like this: + + void host_function() + { + struct foo + { + static void __global__ kernel () + { + // Place breakpoint here + } + }; + + // Host code that calls `kernel` + } + + The heuristic won't work then, as the breakpoint will drift somewhere + inside the enclosing function, but won't be at the start of that + function. So a bogus breakpoint location will be created on the host + side. I don't think that people are going to use this kind of + construct often though, so we can probably ignore it (or at least it + shouldn't prevent making the more common case better). + + ROCm doesn't support passing a lambda kernel function to + hipLaunchKernelGGL (the function used to launch kernels on the + device), but if it eventually does, there will be the same + problem. + + I think that to properly support this, we will need some DWARF + improvements to be able to say "there is really nothing at these + lines" in the line table. + + Co-Authored-By: Simon Marchi + Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6 + +2024-08-29 Andrew Burgess + + gdb/doc: move NEWS entry to the correct place + In commit: + + commit 3055e3d2f13bb84db90b9c19d427c362053775d2 + Date: Tue May 21 15:58:02 2024 +0100 + + gdb: add GDB side target_ops::fileio_stat implementation + + I managed to place a NEWS entry in the wrong place. I put the entry + in 'Changes in GDB 15' rather than 'Changes since GDB 15'. This + commit moves the entry to the correct place. + +2024-08-29 Simon Marchi + + gdb: include gdbsupport/gdb_obstack.h in addrmap.h + This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h. + This fixes an error shown when editing addrmap.h with clangd, and makes + it so addrmap.h includes what it uses. + + Change-Id: I0b0c8d26638e2150fcb65c601098ed9df5a8945a + +2024-08-29 Simon Marchi + + gdb: remove unused includes in linespec.c + Remove some includes reported as unused by clangd. + + Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df + +2024-08-29 Alan Modra + + get_type_abbrev_from_form tidy + * dwarf.c (get_type_abbrev_from_form): Make uvalue param a + uint64_t. Localise variables. Don't bother clearing *data_return + and *addrev_num_return for a NULL return value. + +2024-08-29 Alan Modra + + ld testsuite output files + In many cases the output of one run_cc_link_tests test is used as + input for another test. I hit a case where some system change caused + errors when compiling object files, but the old .so output from a + previous test run was still there, and then was used in following + tests. + + * testsuite/lib/ld-lib.exp (run_ld_link_tests): Delete output + file before building. + (run_ld_link_exec_tests, run_cc_link_tests): Likewise. + +2024-08-29 Alan Modra + + PR32093, -Walloc-size warning in ctf-hash.c + PR 32093 + * ctf-hash.c (ctf_dynhash_create_sized, ctf_hashtab_insert): Avoid + -Walloc-size warning. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix another regexp in gdb.threads/stepi-over-clone.exp + On openSUSE Tumbleweed, I run into: + ... + (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls + continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), __clone3 () at clone3.S:62^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating another (see commit 8fbf220321d) regexp to also recognize + __clone3. + + Tested on x86_64-linux. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.arch/i386-disp-step-self-call.exp + Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get: + ... + (gdb) x/1wx 0xffffc4f8^M + 0xffffc4f8: 0x08048472^M + (gdb) PASS: $exp: check return address was updated correctly + ... + but sometimes I run into: + ... + (gdb) x/1wx 0xffffc5c8^M + 0xffffc5c8: 0x0804917e^M + (gdb) FAIL: $exp: check return address was updated correctly + ... + + The problem is that here: + ... + set next_insn_addr 0x[format %08X $next_insn_addr] + gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \ + "check return address was updated correctly" + ... + we're trying to match string 0x0804917e against regexp 0x0804917E due to using + "%08X" as format string. + + We only run into this problem if the address contains letters, which apparently + usually isn't the case. + + Fix this by using "%08x" instead as format string. + + Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp. + + Tested on x86_64-linux. + + PR testsuite/32121 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32121 + +2024-08-29 GDB Administrator + + Automatic date update in version.in + +2024-08-28 Tom Tromey + + Don't check dwarf2_name in process_enumeration_scope + I noticed that process_enumeration_scope checks the result of + dwarf2_name. However, this isn't needed, because new_symbol does the + same check. This patch removes the unnecessary code. + + Reviewed-by: Keith Seitz + +2024-08-28 Jiaying Song + + dlltool: file name too long + During the execution of the command: i686-w64-mingw32-dlltool + --input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe + An error occurred: + i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s + + Due to the path length exceeding the Linux system's file name length + limit (NAME_MAX=255), the temporary file name generated by the + i686-w64-mingw32-dlltool command becomes too long to open. To address + this, a new temporary file name prefix is generated using tmp_prefix = + prefix_encode ("d", getpid()), ensuring that the file name does not + exceed the system's length limit. + + Reviewed-by: Alan Modra + +2024-08-28 H.J. Lu + + x86: Report expected register for elf_x86_tls_error_indirect_call + Since R_386_TLS_DESC_CALL can only be used with + + call *variable@TLSCALL(%eax) + + and R_X86_64_TLSDESC_CALL can only be used with + + call *variable@TLSCALL(%rax) + + update TLS transition error report to display the expected register in + indirect CALL. + + bfd/ + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize + the ax_register field. + (_bfd_x86_elf_link_report_tls_transition_error): Report the + expected register in elf_x86_tls_error_indirect_call error. + * elfxx-x86.h (elf_x86_link_hash_table): Add ax_register. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/tlsgdesc2.d: Updated. + * testsuite/ld-i386/tlsgdesc2.s: Change jmp to call via ECX. + * testsuite/ld-x86-64/tlsdesc4.d: Updated. + * testsuite/ld-x86-64/tlsdesc4.s: Change jmp to call via RCX. + +2024-08-28 H.J. Lu + + gold: Force a PC-relative reference to .LC0 + Force a PC-relative reference to .LC0 with: + + __asm__ (".dc.a .LC0 - ."); + + for all targets. + + Tested on x86, powerpc64le and aarch64. + + * testsuite/discard_locals_relocatable_test.c: Force a PC-relative + reference to .LC0. + +2024-08-28 H.J. Lu + + gold: Disable &no_such_symbol_ != NULL check when GOT in use + Since this test: + + if (&no_such_symbol_ != NULL) + { + fprintf(stderr, "FAILED weak undef test 4: %s\n", + "&no_such_symbol_ is not NULL"); + status = 1; + } + + always fails when GOT is used and aarch64 always uses GOT, disable it + for aarch64 and PIC. + + PR gold/32112 + * testsuite/weak_undef_test.cc (main): Disable the + &no_such_symbol_ != NULL check for aarch64 and PIC. + +2024-08-28 Alan Modra + + dlltool.c formatting + Mostly whitespace fixes, some removal of excess parens. + + Re: x86: Allow R_386_TLS_LE_32 with KMOVD + Adjust the new test to pass on i686-pc-elf where it failed due to not + matching the _start address. + +2024-08-28 H.J. Lu + + gold: Use asm for GCC 9 and older in PR gold/31830 tests + Since GCC 9 and older fail to compile PR gold/31830 tests: + + $ gcc -S testsuite/ver_test_pr31830_b.c -o /tmp/x.s + testsuite/ver_test_pr31830_b.c:3:1: warning: ‘__symver__’ attribute directive ignored [-Wattributes] + void __collector_foo_2_2(void) {} + ^~~~ + + use asm statement, instead of symver attribute, for GCC 9 and older. + + PR gold/31830 + * testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm + statement, instead of symver attribute, for GCC 9 and older. + symver attribute with __asm__. + * testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise. + +2024-08-28 H.J. Lu + + gold: Remove duplicated rules for ifuncmain[12457]picstatic + When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports: + + Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic' + Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic' + Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic' + Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic' + Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic' + Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic' + Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic' + Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic' + Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic' + Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic' + + due to duplicated rules for ifuncmain[12457]picstatic: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@HAVE_STATIC_TRUE@@IFUNC_STATIC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + Make rules for ifuncmain[12457]picstatic independent of HAVE_STATIC and + IFUNC_STATIC: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + PR gold/32116 + * testsuite/Makefile.am (ifuncmain1picstatic): Make it independent + of HAVE_STATIC and IFUNC_STATIC. + (ifuncmain2picstatic): Likewise. + (ifuncmain4picstatic): Likewise. + (ifuncmain5picstatic): Likewise. + (ifuncmain7picstatic): Likewise. + * testsuite/Makefile.in: Regenerated. + +2024-08-28 H.J. Lu + + x86: Report invalid TLS operator + Report invalid TLS operator, instead of relocation. + + PR gas/28595 + * config/tc-i386.c (gotrel): Replace int with unsigned int. + (i386_assemble): Report invalid TLS operator. + * testsuite/gas/i386/inval-tls.l: updated. + * testsuite/gas/i386/x86-64-inval-tls.l: Likewise. + +2024-08-28 Guinevere Larsen + + gdb/testsuite: fix gdb.btrace/non-stop.exp end of history check + The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the + warnings when GDB reaches the end of the recorded history, and updated + tests to expect the new messages. The pattern used for + gdb.btrace/non-stop.exp, however, was too broad and could cause the + following test result: + + ... + (gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0 + FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout) + ... + + This happens because the pattern looks like one of these 2: + "Reached end of recorded.*Backwards execution.*" + "Reached end of recorded.*Following forward.*" + + What seems to have happened is that all the output came at once, and + most of it was consumed by the first '.*' pattern when checking for + thread 0, so there was no output left for checking thread 1. This commit + fixes that by making the expected outputs more exact. + + I also fixed the whitespace errors in gdb_cont_to_no_history_backwards + that pre-dated the commit above, since I was already touching that proc. + + Approved-By: Tom de Vries + +2024-08-28 Andrew Burgess + + gdb/testsuite: add no-delete-breakpoints option to 'runto' proc + New 'no-delete-breakpoints' option for the 'runto' proc. This option + disables the delete_breakpoints call early on in this proc. + + There are a couple of places in the testsuite where I have used: + + proc no_delete_breakpoints {} {} + + with_override delete_breakpoints no_delete_breakpoints { + if {![runto_main]} { + return + } + } + + In order to avoid the deleting all breakpoints when I call + runto_main. I was about to add yet another instance of this pattern + and I figured that it's time to do this properly. + + This commit adds the new option to 'runto' which causes the + delete_breakpoints call to be skipped. + + And, we now forward any arguments from 'runto_main' through to + 'runto', this means I can now just do: + + if {![runto_main no-delete-breakpoints]} { + return + } + + which I think is cleaner and easier to understand. + + I've updated the two tests I found that use the old with_override + approach. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-08-28 Andrew Burgess + + gdb: add 'maint info blocks' command + While reviewing a patch I wanted to understand which blocks existed at + a given address. + + The 'maint print symbols' command does provide some of this + information, but that command displays all blocks within a given + symtab. If I want to know which blocks are at a given address I have + to figure that out for myself based on the output of 'maint print + symbols' ... and I'm too lazy for that! + + So this command lists just those blocks at a given address, along with + information about the blocks type. This new command doesn't list the + symbols within each block, for that my expectation is that you'd cross + reference the output with that of 'maint print symbols'. + + The new command format is: + + maintenance info blocks + maintenance info blocks ADDRESS + + This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is + not given. Blocks are listed starting at the global block, then the + static block, and then the progressively narrower scoped blocks. + + For each block we list the internal block pointer (which allows easy + cross referencing with 'maint print symbols'), the inferior address + range, along with other useful information. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: Add 'maint info inline-frames' command + While reviewing a patch I wanted to view GDB's inline frame state. I + don't believe there's currently a maintenance command to view this + information, so in this commit I've added one. + + The new command is: + + maintenance info inline-frames + maintenance info inline-frames ADDRESS + + The command lists the inline frames that start at ADDRESS, or at the + current $pc if no ADDRESS is given. The command also displays the + "outer" function in which the inline functions are present. + + An example of the command output: + + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 1 + bar + > foo + main + (gdb) + + This tells us that function 'main' called 'foo' which called 'bar'. + The functions 'foo' and 'bar' are both inline and both start at the + address 0x401137. Currently GDB considers the inferior to be stopped + in frame 'foo' (note the '>' marker), this means that there is 1 + skipped frame (function 'bar'). + + The function 'main' is the outer function. The outer function might + not start at 0x401137, it is simply the function that contains the + inline functions. + + If the user does a 'step' then GDB will not actually move the inferior + forward, but will instead simply tell the user that the inferior + entered 'bar'. The output of 'maint info inline-frames' will change + like this: + + (gdb) step + bar () at inline.c:6 + 6 ++global_counter; + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 0 + > bar + foo + main + (gdb) + + Now GDB is in function 'bar' and there are no skipped frames. + + I have renamed skipped_symbols to function symbols within the + inline_state class. We are now going to carry the "outer" + function (the function that contains all the inlined functions) within + this list (as the last entry), so the old name didn't really make + sense. As a consequence of this rename I've updated some comments. + + I've changed stopped_by_user_bp_inline_frame to take a symbol rather + than a block. Previously we just used the block to access the + associated function symbol. After this commit we can just pass in the + function symbol directly, so lets do that. + + New function gather_inline_frames contains some of the logic pulled + from skip_inline_frames. This new function builds the list of all + symbols of inlined functions that start at a given $pc value and also + the "outer" function that contains all of the inlined functions. + + In skip_inline_frames I've split the loop logic into two. The loop to + build the function symbol list has moved to gather_inline_frames. The + loop to figure out how many of the inlined functions we are skipping + remains in skip_inline_frames and uses the result of calling + gather_inline_frames. + + In inline_skipped_symbol there are some minor updates to the comment, + and I've tweaked one of the asserts now that the function symbols list + also contains the "outer" function (a <= becomes <). + + The maintenance_info_inline_frames function is now and implements the + new maintenance command. + + And _initialize_inline_frame is updated to register the new command. + + I've added a basic test for the new command. Please excuse the file + name for the new test, in the next commit I'll be adding additional + tests and at that point the file name will make sense. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: make symbols const in struct inline_state + Make the inline_state::skipped_symbols a vector of 'const symbol *', + adding the const qualifier. + + There's only a couple of places this leaks into the rest of GDB and in + both places its fine for the symbol to become const. + + There should be no functional change after this commit. + + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + Revert "gdb: remove inline_frame::skipped_frames" + This reverts commit 713e89012e43c83a6c1bb957c43ff58e5433336c. + + Having inline_state::skipped_frames back will make a later patch in + this series easier. + +2024-08-28 GDB Administrator + + Automatic date update in version.in + +2024-08-27 H.J. Lu + + x86: Report invalid TLS relocation name + Get TLS relocation name from its lex_got entry when reporting invalid + instructions with TLS relocations. + + PR gas/28595 + * config/tc-i386.c (gotrel): Moved from ... + (lex_got): There. + (i386_assemble): Get invalid TLS relocation name from its lex_got + entry when reporting TLS relocation error. + +2024-08-27 H.J. Lu + + x86: Allow R_386_TLS_LE_32 with KMOVD + Since there is no TLS IE transition, allow R_386_TLS_LE_32 with KMOVD. + + gas/ + + PR gas/28595 + * config/tc-i386.c (i386_assemble): Remove BFD_RELOC_386_TLS_LE_32 + from TLS code check. + * testsuite/gas/i386/inval-tls.s: Remove foo@tpoff(%eax). + * testsuite/gas/i386/inval-tls.l: Updated. + + ld/ + + PR gas/28595 + * testsuite/ld-i386/i386.exp: Run tlsle1. + * testsuite/ld-i386/tlsle1.d: New file. + * testsuite/ld-i386/tlsle1.s: Likewise. + +2024-08-27 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.exp + In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to + DWARF Error") I changed the dwarf error prefix, but failed to update test-case + gdb.dwarf2/dw2-inter-cu-error.exp. + + Fix this by updating the corresponding regexp in the test-case. + + Tested on x86_64-linux. + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_SET_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error + It was suggested here [1] that the canonical prefix for dwarf errors + should not be "Dwarf Error: ", given that the canonical spelling is DWARF + instead of Dwarf. + + Fix this by using "DWARF Error: " instead. + + Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single + location. + + Tested on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html + +2024-08-27 Tom de Vries + + [gdb/symtab] Use DWARF_ERROR_PREFIX + Result of: + ... + $ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/* + ... + and manually fixing indentation. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Add gdb/dwarf2/error.h + Add a new header file gdb/dwarf2/error.h, containing macros: + - DWARF_ERROR, and + - DWARF_ERROR_PREFIX. + + The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Use [in module %s] notation more consistently in dwarf errors + In gdb/dwarf2/read.c, I found a few strings "in module %s": + ... + $ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '[' + "DIE at %s in module %s"), + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + error (_("Dwarf Error: DIE at %s referenced in module %s " + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + ... + that are not using the commonly used "[in module %s]" notation. Fix these. + + In one case, the string was also used in the middle rather than at the end of + the message, so fix that as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Jiawei + + RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions. + This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'. + All disassemble instructions use the sreg format. + + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + gas/ChangeLog: + PR 32036 + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/zcmp-mv.d: New test. + * testsuite/gas/riscv/zcmp-mv.s: New test. + + include/ChangeLog: + PR 32036 + * opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode. + (MASK_CM_MVA01S): New mask. + (MATCH_CM_MVSA01): New opcode. + (MASK_CM_MVSA01): New mask. + (DECLARE_INSN): New declarations. + * opcode/riscv.h (OP_MASK_SREG1): New mask. + (OP_SH_SREG1): New operand code. + (OP_MASK_SREG2): New mask. + (OP_SH_SREG2): New operand code. + (X_A0): New reg number. + (X_A1): Ditto. + (X_S7): Ditto. + (RISCV_SREG_0_7): New macro function. + + opcodes/ChangeLog: + PR 32036 + * riscv-dis.c (riscv_zcmp_get_sregno): New function. + (print_insn_args): New operators. + * riscv-opc.c (match_sreg1_not_eq_sreg2): New match function. + +2024-08-27 GDB Administrator + + Automatic date update in version.in + +2024-08-26 Vladimir Mezentsev + + Disable gprofng build for *musl* + I disable gprofng until gprofng is ported to musl. + + gprofng/ChangeLog + 2024-08-22 Vladimir Mezentsev . + + PR gprofng/30779 + PR gprofng/29593 + PR gprofng/29477 + * configure.ac: Disable gprofng build for *musl*. + * configure: Rebuild. + +2024-08-26 Tom Tromey + + Simplify ada_identical_enum_types_p + This patch changes ada_identical_enum_types_p to reuse the field names + that are computed earlier in the loop. This is a simple cleanup, but + also is useful for a larger change that I'm working on. + + Tested on x86-64 Fedora 38. + +2024-08-26 Mark Harmstone + + ld/PDB: handle pointers to members + If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an + LF_POINTER entry's attributes, there's a few extra bytes on the end that + we weren't accounting for. + + Change handle_type so that we remap the containing_class field if it's + present, and add a test for this. + +2024-08-26 William Ferreira + + gdb: imply --once if connecting via stdio + Currently, gdbserver hangs after stdin is closed while it tries to + write: "Remote side has terminated connection. GDBserver will reopen + the connection." This hang disappears if --once is also given. Since + the stdin connection won't ever reopen if it's closed, it's safe to + assume --once is desired. + + The gdb.server/server-pipe.exp test was also updated to reflect this + change. There is now a second disconnect at the end of the proc, + with a tighter-than-normal timeout to catch if the command hangs as + it used to. + + Co-Authored-By: Guinevere Larsen + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796 + + Approved-By: Andrew Burgess + +2024-08-26 Guinevere Larsen + + Change message when reaching end of reverse history. + In a record session, when we move backward, GDB switches from normal + execution to simulation. Moving forward again, the emulation continues + until the end of the reverse history. When the end is reached, the + execution stops, and a warning message is shown. This message has been + modified to indicate that the forward emulation has reached the end, but + the execution can continue as normal, and the recording will also continue. + + Before this patch, the warning message shown in that case was the same as + in the reverse case. This meant that when the end of history was reached in + either backward or forward emulation, the same message was displayed: + + "No more reverse-execution history." + + This message has changed for these two cases. Backward emulation: + + "Reached end of recorded history; stopping. + Backward execution from here not possible." + + Forward emulation: + + "Reached end of recorded history; stopping. + Following forward execution will be added to history." + + The reason for this change is that the initial message was deceiving, for + the forward case, making the user believe that forward debugging could not + continue. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224 + Reviewed-By: Markus T. Metzger (btrace) + Approved-By: Guinevere Larsen + +2024-08-26 Lulu Cai + + LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE + If the symbol defined by PROVIDE in the link script is not in SECTION, + the symbol is placed in the ABS section. The linker considers that + symbols in the ABS section do not need to calculate PC relative offsets. + + Symbols in ABS sections should calculate PC relative offsets normally + based on relocations. + +2024-08-26 Felix Willgerodt + + gdb, btrace: Fix clang build + Simon pointed out to me that there are some failures when building with clang, + that were caused by my commit + + commit d894edfcc40e63be9b6efa0950c1752f249f16e5 + Author: Felix Willgerodt + Date: Mon Feb 18 13:49:25 2019 +0100 + + btrace: Introduce auxiliary instructions. + + The errors are: + + CXX btrace.o + gdb/btrace.c:1203:11: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1203 | return {(CORE_ADDR) insn.ip, (gdb_byte) insn.size, + | ^~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1218:21: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1218 | btrace_insn insn {btinfo->aux_data.size () - 1, 0, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1323:34: error: variable 'bfun' is uninitialized when used here [-Werror,-Wuninitialized] + 1323 | handle_pt_aux_insn (btinfo, bfun, *ptw_string, pc); + | ^~~~ + gdb/btrace.c:1236:35: note: initialize the variable 'bfun' to silence this warning + 1236 | struct btrace_function *bfun; + | ^ + | = nullptr + 3 errors generated. + make[1]: *** [Makefile:1961: btrace.o] Error 1 + + This fixes those errors and switches two casts to C++ casts while we + are at it. + + Approved-By: Simon Marchi + +2024-08-26 Alan Modra + + PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt + Since bfd_section for .strtab isn't set, print the section index + instead. Also, don't return NULL on this error as that results in + multiple mmap/read of the string table. (We could return NULL if we + arranged to set sh_size zero first, but just what we do with fuzzed + object files is of no concern, and terminating the table might make a + faulty object file usable.) + + PR 32109 + * elf.c (bfd_elf_get_str_section): Remove outdated comment, and + tweak shstrtabsize test to suit. Don't use string tab bfd_section + in error message, use index instead. Don't return NULL on + unterminated string section, terminate it. + (_bfd_elf_get_dynamic_symbols): Similarly terminate string table + section. + +2024-08-26 GDB Administrator + + Automatic date update in version.in + +2024-08-25 Dmitry Neverov + + Recognize -2 as a tombstone value in .debug_line + Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone + value -1 used by lld (https://reviews.llvm.org/D81784). The + referenced lld commit also uses the tombstone value -2 for + pre-DWARF-v5 + (https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7). + + If not handled, -2 breaks the pc step range calculation and triggers + the assertion: + + gdb/infrun.c:2794: internal-error: resume_1: Assertion + `pc_in_thread_step_range (pc, tp)' failed. + + This commit adds -2 tombstone value and handles it in the same way as -1. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727 + Approved-By: Tom Tromey + +2024-08-25 GDB Administrator + + Automatic date update in version.in + +2024-08-24 GDB Administrator + + Automatic date update in version.in + +2024-08-23 Aaron Merey + Tom de Vries + + gdb/dwarf2: Check for null abbrev_info ptr + A corrupt debuginfo file can result in a null abbrev_info pointer + being passed to cooked_indexer::scan_attributes. This pointer + is set to nullptr by peek_die_abbrev when an abbrev of 0 is found. + + There is no check for whether the abbrev pointer is null and + SIGSEGV occurs when attempting to dereference the pointer. + + An abbrev of 0 normally indicates that the corresponding DIE is a + null entry, but scan_attributes expects a non-null DIE. + + Fix this by throwing an error in cooked_indexer::scan_attributes + when peek_die_abbrev returns a nullptr in order to avoid + scan_attributes calling itself with a null abbrev. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 + Approved-By: Tom Tromey + +2024-08-23 Jan Beulich + + x86: simplify SAE checking + To determine whether SAE (with or without StaticRounding) is permitted + there's no need to iterate over all operands. Even less so starting at + the front (thus needlessly inspecting immediate operands as well). + Leverage the pattern across all relevant templates and check only the + last two operands, and also only for non-512 ones (besides the non-LIG + case that was already checked for). + + gas: update lex_type[] also for .mri directives + Doing this just from read_begin(), i.e. merely based on command line + options, can't be sufficient (assuming it's really relevant). + +2024-08-23 Jan Beulich + + RISC-V: process rs_align_code also when relaxing + riscv_handle_align() runs after all input was processed. Whether + relaxation is enabled for any particular piece of code is not recorded + anywhere. (This issue was even "worked around" in a gas testcase, which + is adjusted accordingly.) Furthermore, as demonstrated by an ld + testcase, tail padding in an object file's executable sections depended + on whether relaxation was enabled at the end of assembly: NOPs were + emitted only when relaxation was off; zeroes were emitted with + relaxation enabled. (It could probably be either way, but it should be + independent of relaxation state at the end of assembly. Except of course + write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(), + explicitly says "proper nop-filling".) + + While re-indenting, drop the "odd_padding" variable. It's used exactly + once, and having the actual expression right in the if() is imo helping + readers to understand what the intentions are. + + While touching the ld testcase, also tighten the expectations for the + addresses of the two symbols: The last two digits have to have fixed + values. + +2024-08-23 GDB Administrator + + Automatic date update in version.in + +2024-08-22 H.J. Lu + + lto: Add a test for PR ld/32083 + Add a test for PR ld/32083 and xfail the test for GCC without the fix: + + commit a98dd536b1017c2b814a3465206c6c01b2890998 + Author: H.J. Lu + Date: Wed Aug 21 07:25:25 2024 -0700 + + Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook + + PR ld/32083 + * testsuite/ld-plugin/common-2a.c: New file. + * testsuite/ld-plugin/common-2b.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run PR ld/32083 test. + +2024-08-22 Tom de Vries + + [gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists + With the test-case included in this patch, we run into: + ... + $ gdb -q -batch $exec + Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \ + [in module $exec] + ... + + The debug info consists of two CUs: + ... + Compilation Unit @ offset 0xb2: + Length: 0x25 (32-bit) + Version: 4 + Abbrev Offset: 0x6c + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_low_pc : 0x4004a7 + DW_AT_high_pc : 0x4004b2 + DW_AT_specification: <0xe8> + <1>: Abbrev Number: 3 (DW_TAG_subprogram) + DW_AT_name : main + <1>: Abbrev Number: 0 + Compilation Unit @ offset 0xdb: + Length: 0xf (32-bit) + Version: 4 + Abbrev Offset: 0x86 + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_specification: <0xd4> + <1>: Abbrev Number: 0 + ... + where: + - DIE 0xbf in CU@0xb2 contains an inter-CU reference to + - DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to + - DIE 0xd4 back in CU@0xb2. + + The dwarf error is caused by this bit of code in + cooked_indexer::ensure_cu_exists: + ... + if (per_cu == m_per_cu) + return reader; + ... + + The dwarf error happens as follows: + - a cutu_reader A is created for CU@0xb2 + - using cutu_reader A, the cooked index reader starts indexing dies, with + m_per_cu set to CU@0xb2 + - while indexing it scans the attributes of DIE 0xbf and encounters the + inter-CU reference to DIE 0xe8 + - it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for + CU@0xdb and returns it + - using cutu_reader B, it continues scanning attributes of DIE 0xe8 and + encounters the inter-CU reference to DIE 0xd4 + - it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered + and cutu_reader B is returned + - using cutu_reader B, it continues scanning attributes of DIE 0xd4 + - this goes wrong because: + - the attributes of the DIE are encoded using the abbreviation table at + offset 0x6c, while + - the decoding is done using cutu_reader B which uses the abbreviation table + at offset 0x86. + + Fix this by removing the problematic if clause. + + Since cutu_reader A is not preserved in m_index_storage, + cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate + cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving + the cutu_reader A as well in m_index_storage. + + Tested on x86_64-linux and aarch64-linux. + + PR symtab/32081 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081 + + Approved-By: Tom Tromey + Reported-By: Andreas Schwab + +2024-08-22 Tom de Vries + + [gdb] Add const to catch gdb_exception + I did a review of lines containing "catch (gdb_exception" and found a few + where we can add const. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb/python] Eliminate catch(...) in type_to_type_object + In type_to_type_object we have: + ... + try + { + if (type->is_stub ()) + type = check_typedef (type); + } + catch (...) + { + /* Just ignore failures in check_typedef. */ + } + ... + + The catch is supposed to ignore gdb_exception_error, but it ignores any + exception. + + Fix that by only ignoring gdb_exception_error, and handling + gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Add & in catch in svr4_handle_solib_event + In svr4_handle_solib_event I noticed: + ... + catch (const gdb_exception_error) + ... + + This seems to be the only place were we do this, elsewhere we have: + ... + catch (const gdb_exception_error &) + ... + + I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's + necessary given that it's an unnamed const parameter, but I suppose it can't + hurt either. + + Add the '&' here as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Eliminate catch(...) in get_test_insn + In get_test_insn in gdb/disasm-selftests.c, we find this code: + ... + try + { + kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc); + insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen); + } + catch (...) + { + continue; + } + ... + + The catch is there to catch memory errors, but it swallows all exceptions, including + gdb_exception_quit and gdb_exception_forced_quit. + + Fix this by limiting the catch to gdb_exception_error. + + Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp. + + Approved-By: Tom Tromey + +2024-08-22 Sam James + + gprofng: testsuite: fix 'wrapper' typo + gprofng/ChangeLog + * testsuite/config/default.exp: Fix 'wrapper' typo. + +2024-08-22 GDB Administrator + + Automatic date update in version.in + +2024-08-21 Simon Marchi + + gdb: some global_block improvements + Some refactors around struct global_block, all in one patch because they + all tie in together and are relatively trivial. + + - Make block::global_block() and blockvector::global_block() return + `global_block *`, instead of `block *`. There is no cost in doing + so, and it's a bit more precise. Callers of these methods that need + a `global_block *` won't need to cast themselves. + + - Add some block::as_global_block methods, as a way to get a + `global_block *` from a `block *` when you know it's a global block. + This is basically a static cast with an assert. + + - Move set_compunit_symtab to global_block, since it requires the + block to be a global block anyway. Rename to just `set_compunit` (I + think that compunit_symtab should just be renamed compunit...). + + - Move the get_block_compunit_symtab free function to be a method of + global_block. + + - Make global_block::compunit_symtab private and rename. + + - Simplify initialize_block_iterator. + + Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d + Approved-By: Tom Tromey + +2024-08-21 Tom Tromey + + Do not assume ELF in dwarf2/read.c + dwarf2/read.c has this code: + + else if (elf_section_data (sectp)->this_hdr.sh_size + > bfd_get_file_size (abfd)) + + This assumes that the BFD is an ELF, which is an invalid assumption. + A user noticed that this can sometimes cause a crash. + + This patch fixes the problem by changing this code to use + bfd_section_size_insane. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104 + Reviewed-By: Tom de Vries + Reviewed-by: Keith Seitz + +2024-08-21 GDB Administrator + + Automatic date update in version.in + +2024-08-20 Andrew Burgess + + gdb/testsuite: track nested caching proc calls + It was pointed out in this email: + + https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com + + that this commit: + + commit 0726729d344fecf98f8d138e688e77201cc3cece + Date: Mon Jun 3 13:56:54 2024 +0100 + + gdb/testsuite: track if a caching proc calls gdb_exit or not + + had broken some AArch64 tests. + + What is going on is that there are two caching procs: + + allow_aarch64_sme_tests + aarch64_initialize_sme_information + + the allow_aarch64_sme_tests proc makes a call to + aarch64_initialize_sme_information, but + aarch64_initialize_sme_information is also called from other + non-caching procs, like aarch64_supports_sme_svl. + + Both of the caching procs mentioned above compile and run a helper + program, and both of them call gdb_exit. + + After the above commit, the first call to any caching proc, the body + of which calls gdb_exit, will result in a gdb_exit call even if the + body is not executed and the result is fetched from the cache. + + What was observed is that in the first test script + allow_aarch64_sme_tests is called, the body of this caching proc is + run which calls gdb_exit. Then allow_aarch64_sme_tests calls + aarch64_initialize_sme_information, the body of which is run and + gdb_exit is called again. The results from both procs are added to + the cache. + + In the next test script allow_aarch64_sme_tests is called. This + results in a cache hit, but gdb_exit is also called as this is the + first call in this second test script. + + Later in the test script aarch64_supports_sme_svl is called which + calls aarch64_initialize_sme_information. As this is the first call + to aarch64_initialize_sme_information in this second test + script (remember the body of allow_aarch64_sme_tests was never run) + then gdb_exit is called. This call to gdb_exit is new after the above + commit and is unexpected. + + I think the idea behind the above commit is still sound. If the call + to allow_aarch64_sme_tests was removed from the second test script + then we would want the extra gdb_exit call as this would expose a real + bug in the test. The problem is that after the above commit the + nested nature of the caching proc calls becomes important: a call to + allow_aarch64_sme_tests should mean that we've also called + aarch64_initialize_sme_information, and that relationship isn't + currently captured. + + So in this commit I'm adding another field to the global + gdb_data_cache (in lib/cache.exp). This new field is 'also_called'. + For every caching proc we populate this field with a list of names, + these are the names of any nested caching procs that are called when + the body of a caching proc is executed. + + Now when we get a cache hit in gdb_data_cache we mark every proc in + the 'also_called' list as having been called. This means that further + calls to these procs will no longer trigger a gdb_exit call. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-08-20 Tom Tromey + + Fix Windows regression + commit cb9f919f ("gdb: add program_space parameter to + lookup_minimal_symbol_text") caused a crash on Windows. In this + function, section can be nullptr, but it is unconditionally + dereferenced by the change introduced by the patch. + + I tested this using the AdaCore internal test suite. + + v2: always use current_program_space, reverting to be behavior before + cb9f919f. + + Approved-By: Simon Marchi + +2024-08-20 Tom Tromey + + Use SEARCH_FUNCTION_DOMAIN when looking for Ada exception symbols + While working on another bug, I noticed that the Ada code to find + exception symbols uses SEARCH_VFT. This will find variables and types + -- but only functions are needed here. This patch changes the code to + use SEARCH_FUNCTION_DOMAIN. + + Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo + installed, to ensure the exception-related tests work. + + Reviewed-by: Keith Seitz + +2024-08-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13 + When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output) + ... + + In contrast, with python 3.12 I have: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n"^M + &" raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + PASS: gdb.python/py-mi-cmd.exp: -pycmd exp + ... + + To make it easier to understand what we're looking at, let's take this out of + the mi interpreter context and use the cli interpreter: + ... + $ gdb -q -batch -ex "set trace-commands on" -x gdb.in + +set python print-stack full + +source py-mi-cmd.py + +python pycmd1('-pycmd') + +python pycmd1.invoke (pycmd1, ["exp"]) + Traceback (most recent call last): + File "", line 1, in + File "py-mi-cmd.py", line 76, in invoke + raise gdb.GdbError() + gdb.GdbError + gdb.in:4: Error in sourced command file: + Error occurred in Python. + ... + + Interestingly, this is what we're seeing with both python 3.12 and 3.13. + + The difference between the python versions is that: + - with python 3.12 each line is printed by itself, and + - with python 3.13 two particular lines are printed toghether. + + With the cli interpreter, that makes no difference, because the '\n' is + interpreted. + + But with the mi interpreter, that causes a difference in output because the + '\n' is not interpreted, but rather printed literally. + + Fix this by accepting the new output in addition to the old one. + + Tested on aarch64-linux. + + Reviewed-by: Thiago Jung Bauermann + + PR testsuite/31913 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913 + +2024-08-20 Vladimir Mezentsev + + gprofng: add hardware counters for Appliedmicro processor + gprofng/ChangeLog + 2024-08-15 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Appliedmicro processor. + * common/hwctable.c: Add the hwc table for Appliedmicro processor. + * src/hhwc_arm64_amcc.h: New file. + * src/collctrl.cc (read_int): Use strtol instead of atoi. + +2024-08-20 GDB Administrator + + Automatic date update in version.in + +2024-08-19 Indu Bhagat + + gas: ginsn: x86: pacify Wmaybe-uininitialized compiler warning + Fix PR binutils/32091 + + After commit d56083b5047b8e7cc9eda2f867bd2b75724920a1, some gcc versions + may warn about unintialized usage of ginsn_func. Albeit false positive, + adapt the code to escape the warning. + + gas/config/ + * tc-i386-ginsn.c (x86_ginsn_indirect_branch): Early exit if + unexpected args. + +2024-08-19 Andreas Schwab + + Fix m68k OS ABI sniffer + Do not override the generic OS ABI sniffer. + + Fixes: 3eba3a011a8 ("Various m68k fixes for gdb") + +2024-08-19 Tom Tromey + + Ensure gdb.ada/multiarray.exp runs in both modes + gdb.ada/multiarray.exp has a loop that looks like it should run the + test in both 'all' and 'minimal' encodings mode. However, the body of + the loop doesn't actually use the 'flags' variable. This was an + oversight in the original commit. + +2024-08-19 Nick Clifton + + Remove Walter Lee as maintainer for Tile Gx and Tile Pro + +2024-08-19 Andrew Burgess + + gdb: fix a target: prefix issue in find_separate_debug_file + Following on from the previous commit, this commit fixes the two KFAIL + in gdb.base/sysroot-debug-lookup.exp when not using the + native-extended-gdbserver board. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What I think we need to do is this: if the sysroot has a target: + prefix, and the target filesystem is local to GDB, then we should + strip the target: prefix from the sysroot, just as we do when opening + a file (see gdb_bfd_open in gdb_bfd.c). + + Now, when we make the child_path() call neither the sysroot nor + CANON_DIR will have a target: prefix, the child_path() call will + succeed, and GDB will correctly find the debug information. + + There is just one remaining issue, the last path we look in when + searching for debug information is built by starting with the sysroot, + then adding the debug directory, see this line: + + debugfile = path_join (target_prefix_str, root.c_str (), + debugdir.get (), base_path, debuglink); + + The target_prefix_str is set to target: if DIR has a target: prefix, + and DIR should have a target: prefix if the file we're looking for was + opened with a target: prefix. However, in our case the file was in a + local filesystem so GDB stripped the prefix off. + + The sysroot however, does have the target: prefix, and the test is + expecting to see GDB look within a file with the target: prefix. + + Given that the above line is about looking within a sub-directory of + the sysroot, I think we should not be stripping the target: prefix off + the sysroot path (as we do when building ROOT), instead, we should, in + this case, not use TARGET_PREFIX_STR, and instead just use GDB's + sysroot as it is (in this case with the target: prefix). + + With these fixes in place I now see no failures when using the 'unix', + 'native-gdbserver', or 'native-extended-gdbserver' boards with this + test, and the KFAILs can be removed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + +2024-08-19 Andrew Burgess + + gdb: avoid '//' in filenames when searching for debuginfo + I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added + recently actually had a KPASS when run with the + native-extended-gdbserver board. This was an oversight when adding + the test. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What happens in the native-extended-gdbserver case is that GDB doesn't + see the target filesystem as local. Now the filename retains the + target: prefix, which means that in the child_path() call both the + sysroot and the CANON_DIR have a target: prefix, and so the + child_path() call succeeds. This allows GDB to progress, try some + additional paths, and then find the debug information. + + So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect + the test to succeed when using the native-extended-gdbserver protocol. + + This leaves one KFAIL when using the native-extended-gdbserver board, + we find the debug information but (apparently) find it in the wrong + file. What's happening is that when GDB builds the filename for the + debug information we end up with a '//' string as a directory + separator, the test regexp only expects a single separator. + + Instead of just fixing the test regexp, I've updated the path_join + function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to + appear in the argument list after the first argument. This means it's + now possible to do this: + + auto result = path_join ("/a/b/c", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + Additionally I've changed path_join so that it avoids adding + unnecessary directory separators. In the above case when the two + paths were joined GDB only added a single separator between 'c' and + 'd'. But additionally, if we did this: + + auto result = path_join ("/a/b/c/", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + We'd still only get a single separator. + + With these changes to path_join I can now make use of this function in + find_separate_debug_file. With this done I now have no KFAIL when + using the native-extended-gdbserver board. + + After this commit we still have 2 KFAIL when not using the + native-gdbserver and unix boards, these will be addressed in the next + commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Reviewed-By: Keith Seitz + +2024-08-19 Guinevere Larsen + + gdb: Fix printing frame when reversing out of a recursive call with clang + Commit bf2813aff8f2988ad3d53e819a0415abf295c91f introduced some logic to + not refresh the step frame id if it detects that the inferior is reverse + stepping out of a recursive call, so that we would still print frame + information once the inferior stops. + + However, that logic was overly specific, and wouldn't be hit for + inferiors compiled with clang because clang adds line table entries that + aren't statements, making process_event_stop_test go through a different + branch on the relevant if statement. + + Fix this by not making the code that detects "reversing out of a + recursion" an else clause to the previous if, but a standalone if block. + + Approved-by: Kevin Buettner + +2024-08-19 GDB Administrator + + Automatic date update in version.in + +2024-08-18 Tom de Vries + + [gdb] Prune inferior after switching inferior + Usually with test-case gdb.python/py-progspace-events.exp I get: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 4116] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M + 28 { /* Nothing. */ }^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + step^M + FreeProgspaceEvent: ^M + do_parent_stuff () at py-progspace-events.c:41^M + 41 ++global_var;^M + (gdb) PASS: gdb.python/py-progspace-events.exp: step + ... + + But occasionally I run into the following FAIL: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + (gdb) FreeProgspaceEvent: ^M + FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout) + ... + + This is caused by a race between the handling of an event, and the + "inferior 1" command. + + In the passing case, the event is handled first. During which prune_inferiors + is called, but it can't remove inferior 2, because it's still the current one. + + In the failing case, the "inferior 1" command is handled first. Then during + handling of the event, prune_inferiors is called, and it can remove inferior 2 + because it's no longer the current one. + + This looks like a test-case issue to me, but ISTM that we can do better: by + calling prune_inferiors asap, at the end of the "inferior 1" command, we + stabilize the moment when the inferior is removed: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + FreeProgspaceEvent: ^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + ... + + This also allows us to simplify the test-case by removing the step command, + which is no longer required to trigger the pruning of the inferior. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR gdb/31440 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440 + +2024-08-18 GDB Administrator + + Automatic date update in version.in + +2024-08-17 Nick Clifton + + Update release readme after making 2.43.1 release + +2024-08-17 GDB Administrator + + Automatic date update in version.in + +2024-08-16 Tom Tromey + + Fix DAP failure when fetching global variables + The relatively new "globals" scope code in DAP has a fairly obvious + bug -- the fetch_one_child method should return a tuple with two + elements, but instead just returns the variable's value. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029 + Reviewed-By: Tom de Vries + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linux + With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into: + ... + (gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada + print pck.fp1_var^M + $1 = 0.3125^M + (gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var + ... + + The problem is that the thumb prologue analyzer overshoot, setting the + breakpoint for main after line 49: + ... + 46 int + 47 main (void) + 48 { + 49 pck__fp1_var++; + ... + and consequently we see the value of pck.fp1_var after line 49 instead of + before line 49. This is PR tdep/31981. + + Work around this by removing line 49 and all similar subsequent lines, which + turn out to be dead code. + + Approved-By: Luis Machado + + Tested on arm-linux. + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-single-step-kernel-helper.exp + On arm-linux I run into: + ... + (gdb) p *kernel_user_helper_version^M + Cannot access memory at address 0xffff0ffc^M + (gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version + ... + + What the test-case is trying to do, is to access a special address in the arm + linux kernel [1] using ptrace, which doesn't seem to work. + + This is with kernel version 6.1.55. Perhaps this used to work, but the kernel + was modified to be more strict with respect to access to this special address. + + Fix this by making the inferior access that special address instead. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR testsuite/32070 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070 + + [1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt + +2024-08-16 Felix Willgerodt + + gdb: Fix gdb.python/py-record-btrace.exp test + My previous patch + + commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD) + Author: Felix Willgerodt + Date: Mon Feb 25 15:30:29 2019 +0100 + + python: Add clear() to gdb.Record. + + exposed a clear function for btrace data in python and added some tests + for it. That caused a regression (PR 32086) when recording with bts. + + This is reproducible even without my patch, when adding + "maintenance btrace clear" to the test. + + When comparing the instructions that get recorded in both cases, the traces + are almost identical, just that the first 3 instructions are missing. + + Before clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555163 : movl $0x0,-0x4(%rbp) + 2 0x000055555555516a : movl $0x0,-0x8(%rbp) + 3 0x0000555555555171 : jmp 0x555555555184 + 4 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 5 0x0000555555555188 : jle 0x555555555173 + 6 0x0000555555555173 : mov -0x8(%rbp),%eax + 7 0x0000555555555176 : mov %eax,%edi + ... + + After clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 2 0x0000555555555188 : jle 0x555555555173 + 3 0x0000555555555173 : mov -0x8(%rbp),%eax + 4 0x0000555555555176 : mov %eax,%edi + ... + + The GDB manual describes this behaviour already: + + maint btrace clear + Discard the branch trace data. The data will be fetched anew and + the branch trace will be recomputed when needed. + + This implicitly truncates the branch trace to a single branch trace + buffer. When updating branch trace incrementally, the branch trace + available to GDB may be bigger than a single branch trace buffer. + + The test with BTS is updating the recorded trace incrementally. After the + clear, the buffer of raw trace data available is not enough to recompute the + whole trace as it was before the clear(), and the first 3 instructions are + missing. + + As increasing the buffer size for BTS didn't help, I propose to fix the test + by moving the testing of clear to the end of the test. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086 + +2024-08-16 Jan Beulich + + gas: don't open-code LEX_*NAME + ... except in read.c's definition of lex_type[], where readbility would + otherwise suffer. + + opcodes/cgen: drop trailing whitespace also for cris + While 919b75f7e289 ("Trailing space in opcodes/ generated files") took + care of permanently zapping trailing whitespace, 547112801156 + ("opcodes: cris: move desc & opc files from sim/") then didn't enhance + the newly added code accordingly. + +2024-08-16 GDB Administrator + + Automatic date update in version.in + +2024-08-15 H.J. Lu + + Revert "Arm: correct macro use in gas testsuite" + This reverts commit cfa18744d435b55bbbbc5ef1ae1df67e84aa1777. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "bfin: correct macro use in gas testsuite" + This reverts commit a1b7023447d19d70bc36d71b7627f457dbfae5ce. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "ia64: correct macro use in gas testsuite" + This reverts commit 2231ac9b9e88191178001d0ae5845e292acb2a56. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "MIPS: correct macro use in gas and ld testsuites" + This reverts commit c0e9aca554e33e900efbd6425c1830f0a20012f5. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 Tom Tromey + + Add another constructor to scoped_restore_current_language + While working on something else, I noticed that this is relatively + common: + + scoped_restore_current_language save; + set_language (something); + + This patch adds a second constructor to + scoped_restore_current_language to simplify this idiom. + + Reviewed-By: Tom de Vries + +2024-08-15 Dimitar Dimitrov + + gas: pru: Fix trailing whitespace handling + With commit 6ae8a30d44f016cafb46a75843b5109316eb1996, arguments followed + by a C-style comment ended up with a trailing space. That extra space + character confused the PRU register name matching, leading to spurious + errors about unrecognized registers. This affected existing code like + newlib's setjmp.s for pru. + + Fix by stripping the trailing whitespace for any argument. + + Even with 6ae8a30d44f016cafb46a75843b5109316eb1996 reverted, this patch + is safe to be applied. + + Successfully regression-tested with GCC and newlib testsuites for pru-unknown-elf. + +2024-08-15 H.J. Lu + + lto: Don't include unused LTO archive members in output + When plugin_object_p is called by elf_link_is_defined_archive_symbol to + check if a symbol in archive is a real definition, set archive member + plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO + archive members in linker output. When plugin_object_p is called as + known used, call plugin claim_file if plugin_format is bfd_plugin_unknown + or bfd_plugin_yes_unused. + + To get the proper support for archives with LTO common symbols with GCC, + the GCC fix for + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 + + is needed. + + bfd/ + + PR ld/32083 + * archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused + the same as bfd_plugin_yes. + * elflink.c (elf_link_is_defined_archive_symbol): Likewise. + * bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused. + * plugin.c (try_claim): Try claim_file_v2 first. + * bfd-in2.h: Regenerated. + + ld/ + + PR ld/32083 + * plugin.c (plugin_call_claim_file): Add an argument to return + if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used. + (plugin_object_p): When KNOWN_USED is false, we call plugin + claim_file if plugin_format is bfd_plugin_unknown and set + plugin_format to bfd_plugin_yes_unused on LTO object. When + KNOWN_USED is true, we call plugin claim_file if plugin_format + is bfd_plugin_unknown or bfd_plugin_yes_unused. + +2024-08-15 Vladimir Mezentsev + + gprofng: fix typo in src/collctrl.cc + gprofng/ChangeLog + 2024-08-13 Vladimir Mezentsev + + * src/collctrl.cc (read_cpuinfo): Fix typo. + +2024-08-15 GDB Administrator + + Automatic date update in version.in + +2024-08-14 Tom Tromey + + Log gdb version and configuration in DAP + I think it would be useful for gdb's DAP logs to come with the version + and configuration information. This might make debugging some bug + reports a little simpler. + +2024-08-14 Tom Tromey + + Notify Python when breakpoint symbol changes + A DAP user noticed that breakpoints set by address were never updated + to show their location after the DAP launch request. It turns out + that gdb does not emit the breakpoint-modified event when this sort of + breakpoint is updated. + + This patch changes gdb to notify the breakpoint-modified observer when + a breakpoint location's symbol changes. This in turn causes the DAP + event to be emitted. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Fix failure with C++ exceptions in DAP + While working on earlier patches, I noticed that the DAP C++ exception + test had some strange results in the log. Digging into this, I found + that while the Ada catchpoints emit a "bkptno" field in the MI result, + the C++ ones do not -- but the DAP code was relying on this. + + This patch fixes the problem by changing which field is examined, and + then updates the tests to verify this. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Make DAP instruction breakpoints unverified + Currently, when a DAP client uses setInstructionBreakpoints, the + resulting breakpoints are created as "verified", even though there is + no symbol file and thus the breakpoint can't possibly have a source + location. + + This patch changes the DAP code to assume that all breakpoints are + unverified before launch. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Introduce exec_mi_and_log for DAP + This adds a new exec_mi_and_log function that wraps gdb.execute_mi and + logs the command. This can be handy when debugging DAP. + + Reviewed-by: Keith Seitz + +2024-08-14 H.J. Lu + + ld: Add an LTO test for common symbol override + Linker checks if a symbol in an archive member is a real definition, not + common, before including the archive member in the link output so that + only a real definition in archive will override the common symbol in + object file. Add an LTO test to verify that a real definition in archive + overrides the common symbol in object file. + + * testsuite/ld-plugin/common-1.c: New file. + * testsuite/ld-plugin/definition-1.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run common tests. + +2024-08-14 Tom Tromey + + Remove unnecessary default argument from initialize_block_iterator + I noticed that initialize_block_iterator has a default value for one + of its arguments, but this is not needed as this function has a single + caller that always passes all arguments. This patch removes the + default. Tested by rebuilding. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix DT_RELR and relaxation interaction + Due to the way BFD implements DT_RELR as a part of relaxation, if in a + relax trip size_relative_relocs has changed the layout, when + relax_section runs only the vma of the section being relaxed is + guaranteed to be updated. Then bad thing can happen. For example, when + linking an auxilary program _freeze_module in the Python 3.12.4 building + system (with PGO + LTO), before sizing the .relr.dyn section, the vma of + .text is 30560 and the vma of .rodata is 2350944; in the final + executable the vma of .text is 36704 and the vma of .rodata is 2357024. + The vma increase is expected because .relr.dyn is squashed somewhere + before .text. But size_relative_relocs may see the state in which .text + is at 36704 but .rodata "is" still at 2350944. Thus the distance + between .text and .rodata can be under-estimated and overflowing + R_LARCH_PCREL20_S2 reloc can be created. + + To avoid this issue, if size_relative_relocs is updating the size of + .relr.dyn, just supress the normal relaxation in this relax trip. In + this situation size_relative_relocs should have been demending the next + relax trip, so the normal relaxation can happen in the next trip. + + I tried to make a reduced test case but failed. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix assertion failure with DT_RELR + In the DT_RELR implementation I missed a code path emiting relative + reloc entries. Then the already packed relative reloc entries will be + (unnecessarily) pushed into .rela.dyn but we've not allocated the space + for them, triggering an assertion failure. + + Unfortunately I failed to notice the issue until profiled bootstrapping + GCC with LTO and -Wl,-z,pack-relative-relocs. The failure can be easily + triggered by linking a "hello world" program with -fprofile-generate and + LTO: + + $ PATH=$HOME/ld-test:$PATH gcc hw.c -fprofile-generate -Wl,-z,pack-relative-relocs -flto + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + collect2: error: ld returned 1 exit status + + And the reduced test case is just incredibly simple (included in the + patch) so it seems I'm just stupid enough to fail to detect it before. + Let's fix it now anyway. + +2024-08-14 Jan Beulich + + gas: correct .irpc handling with empty string + Following 69cab370cf66 ("gas: adjust handling of quotes for .irpc") the + closing quote was mistakenly treated as the first quoted character. + +2024-08-14 Jan Beulich + + x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding + When VexVVVV handling was re-worked, .insn broke: When an opcode + extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is + already occupied, matching what c8866e3ec5e2 ("x86: Drop using + extension_opcode to encode vvvv register") did. + + While adding (bad) POP2 forms, also slightly adjust existing ones: + No need to use XMM registers, and no need to specify %r8 when really + %rax is meant twice (EVEX.vvvv not really being the culprit there, or + else EVEX.V' would also have needed mentioning). + +2024-08-14 Felix Willgerodt + + btrace: Extend ptwrite event decoding. + Call the ptwrite filter function whenever a ptwrite event is decoded. + The returned string is written to the aux_data string table and a + corresponding auxiliary instruction is appended to the function segment. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace, python: Enable ptwrite filter registration. + By default GDB will be printing the hex payload of the ptwrite package as + auxiliary information. To customize this, the user can register a ptwrite + filter function in python, that takes the payload and the PC as arguments and + returns a string which will be printed instead. Registering the filter + function is done using a factory pattern to make per-thread filtering easier. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, linux: Enable ptwrite packets. + Enable ptwrite in the PT config, if it is supported by the kernel. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, gdbserver: Add ptwrite to btrace_config_pt. + This enables gdb and gdbserver to communicate about ptwrite support. If + ptwrite support would be enabled unconditionally, GDBs with older libipt + versions would break. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + python: Add clear() to gdb.Record. + This function allows to clear the trace data from python, forcing to + re-decode the trace for successive commands. + This will be used in future ptwrite patches, to trigger re-decoding when + the ptwrite filter changes. + + Reviewed-By: Eli Zaretskii + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + python: Introduce gdb.RecordAuxiliary class. + Auxiliary instructions are no real instructions and get their own object + class, similar to gaps. gdb.Record.instruction_history is now possibly a + list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary + objects. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Handle stepping and goto for auxiliary instructions. + Print the auxiliary data when stepping. Don't allow to goto an auxiliary + instruction. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record function-call-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the function-call-history. Printing is + active by default, it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record instruction-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the instruction-history. Printing is active by default, + it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Introduce auxiliary instructions. + Auxiliary instructions are pseudo instructions pointing to auxiliary data. + This auxiliary data can be printed in all commands displaying (record + function-call-history, record instruction-history) or stepping through + (stepi etc.) the execution history, which will be introduced in the next + commits. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Andrew Burgess + + gdb: remove unnecessary code relating to limited-length arrays + While reviewing this commit: + + commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528 + Date: Tue Aug 6 19:34:18 2024 +0200 + + Mark unavailable bytes of limited-length arrays when allocating contents + + I spotted that there was some code in value::record_latest relating to + limited-length arrays which appeared redundant. The code was added + with the first introduction on limited-length arrays in commit: + + commit a0c07915778486a950952139d27c01d4285b02b4 + Date: Fri Feb 10 23:49:19 2023 +0000 + + GDB: Introduce limited array lengths while printing values + + The code in question is in value::record_latest. When the value being + recorded is lazy we need to fetch its value before adding it to the + history list. The code I spotted checks to see if the value is lazy, + if we currently have array limiting in effect, and if we do sets + m_limited_length to max_value_size before finally calling fetch_lazy. + + The first thing fetch_lazy does is call allocate_contents to setup the + value's buffer, and in allocate_contents we perform the same set of + checks: if the value is an array, and array length limiting is in + effect then only allocate max_value_size buffer for the contents. + + In ::allocate_contents the `if` condition check is spread out between + ::allocate_contents and ::set_limited_array_length, but I'm certain + it's checking the same condition. + + As such the checks and m_limited_length adjustment in ::record_latest + is redundant and can be removed. + + Out of curiosity I went back to the original a0c07915778486a commit + and removed the same block of code from record_latest_value (as + value::record_latest was called back then) and non of the tests added + by commit a0c07915778486a failed. I think this block of code was + never needed. + + Anyway, I removed the unnecessary code and retested and there are no + regressions. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-08-14 GDB Administrator + + Automatic date update in version.in + +2024-08-13 H.J. Lu + + elf: Never set non_ir_ref_regular for debug reference + Never set non_ir_ref_regular for debug reference since references in + debug sections shouldn't impact LTO output. + + * elflink.c (elf_link_add_object_symbols): Don't check strip for + references in debug sections when setting non_ir_ref_regular. + +2024-08-13 Gerlicher, Klaus + + gdb/gdbarch: fix a dot-space-space in generated files + This is a very small patch to straighten out dot-space-space in these + comments in the gdbarch generated files: + + - /* Skip verify of short_bit, invalid_p == 0 */ + + /* Skip verify of short_bit, invalid_p == 0. */ + + There is no functional change after this commit. + + Approved-By: Andrew Burgess + +2024-08-13 Alan Modra + + gas macro arg1 test + A number of targets pad out the data section, and there are targets + that have 2 or 4 octets per byte. And some even that don't have '#' + as a line comment char. tic6x-elf fails the test with "Error: too + many positional arguments". + + * testsuite/gas/macros/arg1.s: Pad out data section. Use C style + comments. + * testsuite/gas/macros/arg1.d: Adjust to suit. Don't run on + multi-octet per byte targes. xfail tic6x. + +2024-08-13 Alan Modra + + PR32072 dlltool.c initializer-string is too long + PR 32072 + * dlltool.c: Delete unneeded forward function declaraions. + Make buffers used by dlltmp static. + (prefix_encode): Avoid warning. Use stpcpy. + +2024-08-13 GDB Administrator + + Automatic date update in version.in + +2024-08-12 Vladimir Mezentsev + + gprofng: specify the heap data collection range + Extend the -H option: + -H {off|on|N1[-N2]} disable , or enable heap tracing, or + specify the heap data collection range. + The default is "-H off". + + gprofng/ChangeLog + 2024-08-08 Vladimir Mezentsev + + * libcollector/heaptrace.c: Read the range in the -H option. + Do not collect data if the allocated memory is out of range. + * src/collctrl.h (heaptrace_mode): Define as char * value. + * src/envsets.cc: Updated since heaptrace_mode is changed. + * src/collctrl.cc: Accept the extended -H option. + * src/gp-collect-app.cc: Accept the extended -H option. + Remove unused code. + +2024-08-12 Dimitar Dimitrov + + sim: pru: Fix test case assembly with latest GAS + After the recent change in GAS [1], macro arguments must be quoted or + grouped with parenthesis. Add the necessary parenthesis in order to fix + assembly errors like: + mul.s:31: Error: too many positional arguments + + [1] https://sourceware.org/pipermail/binutils/2024-July/136053.html + +2024-08-12 Tom Tromey + + Simplify typename_concat + This patch simplifies typename_concat, changing the return type and + removing the obstack allocation code. The latter is possible because + the only caller using this mode uses the name when creating a new + type, and 'new_type' copies the string to the appropriate obstack + anyway. It also changes typename_concat to use 'concat'. This change + lets us remove a mildly fragile macro as well. + + Approved-By: Simon Marchi + +2024-08-12 H.J. Lu + + gas: Add macro tests for PR gas/32073 + 1. Add a macro test for expression argument with inner white spaces and + a white space before argument added by C preprocessor. + 2. Add a x86-64 specific macro test. + + PR gas/32073 + * testsuite/gas/i386/x86-64-macro-1.d: New file. + * testsuite/gas/i386/x86-64-macro-1.s: Likewise. + * testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1. + * testsuite/gas/macros/arg1.d: New file. + * testsuite/gas/macros/arg1.s: Likewise. + * testsuite/gas/macros/macros.exp: Run arg1. + +2024-08-12 H.J. Lu + + Revert "gas: have scrubber retain more whitespace" + This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996. + + This fixes PR gas/32073. + +2024-08-12 H.J. Lu + + Revert "gas: drop scrubber states 14 and 15" + This reverts commit 7dd0dfbde7ee31167a3b2e192a575493d26b7b0a. + + This is a prerequisite for the PR gas/32073 fix. + +2024-08-12 Simon Marchi + + pre-commit: autoupdate + Run `pre-commit autoupdate`. + + Change-Id: I6623a61b7d1e827360854e825d84c5608a68e07b + +2024-08-12 Bernd Edlinger + + [gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled + There are a couple of ways that readline wrapping can be disabled: + - using "set horizontal-scroll-mode on" in INPUTRC, + - using a TERM setting like TERM=dumb, and + - building gdb with stub-termcap. + + Using a trigger patch in default_gdb_init that adds + "set horizontal-scroll-mode on" to INPUTRC: + ... + - setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"] + + setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"] + ... + we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in + PR testsuite/31201 (which was reported for the stub-termcap case): + ... + WARNING: timeout in accept_gdb_output + Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1): + 0 Quit + 1 <89012345678901234567890123456789W + 2 + ... + 23 + FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap + ... + + Fix this by accepting the horizontal-scroll-mode style output. We do + this only when in CLI mode though, when in TUI wrapping works as before + because it doesn't rely on readline. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201 + +2024-08-12 Simon Marchi + + gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0 + amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards + incompatible changes. Adjust the amd-dbgapi target code accordingly. + Given that the AMD GPU port in upstream GDB today is of limited use + (it's still missing important pieces), we don't really care about + supporting amd-dbgapi versions other than the latest stable one, so no + effort is made to keep compatibility with versions 6.1.2 and older. + + The changes are: + + - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to + AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists + but is deprecated), use the latter. + + - In the callbacks structure, the get_os_pid callback was replaced with + client_process_get_info, which is more general and extensible. + Convert our get_os_pid to a new, equivalent, client_process_get_info + callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE + query, but just return "not available". + + - The xfer_global_memory callback was added to the callbacks structure, + add that new callback. + + - Update configure.ac to check for amd-dbgapi >= 0.75.0. + + Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 + Approved-By: Lancelot Six + Reviewed-By: Alexandra Petlanova Hajkova + +2024-08-12 Simon Marchi + + gdb: pass inferior to gdbarch_update_p + Make the current inferior reference bubble up one level. I think this + makes it clearer what gdbarch_update_p, which is update the passed + inferior's architecture (although the function name could probably be + better). + + When gdbarch_find_by_info, it is possible for the new architecture's + init callback to be called. I have not audited all of them (there are + just too many), it's possible that some of them do care about the + current inferior, for some reason (for instance, if one of them makes a + target call). If so, they should be changed too. + + Change-Id: I89f012188d7fdca395a830f4b013743565f26847 + +2024-08-12 Simon Marchi + + gdb: pass inferior to target_current_description + Make the current inferior reference bubble up one level. + + Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd + +2024-08-12 Simon Marchi + + gdb: change names of enumerations in enum flags selftest + When reading this test (in the context of PR 31331), I had trouble + understanding the tests, because of the abbreviated names. I would + prefer if the names were a bit more explicit, like this. + + Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf + +2024-08-12 Simon Marchi + + gdb, gdbsupport: use `using` in enum flags code + I think that `using` is easier to read than `typedef`, and it's the + modern C++ thing anyway. + + Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2 + +2024-08-12 Simon Marchi + + gdbsupport: remove C enum flags fallback + This might have been useful during the C -> C++ conversion (not sure), + but it doesn't appear useful today. I don't see when enum-flags.h would + be used in a C context. + + Change-Id: I6c7ed655757248a62a1bf6615995f42e8aa2b4bd + +2024-08-12 Simon Marchi + + gdb/NEWS: announce removal of QNX Neutrino support + QNX Neutrino support was removed here [1], but I forgot to mention in in + NEWS. + + [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=36fb20fa93484b104d91e42e38930ee8629192ab + + Change-Id: I8db7957acdd0be3c1e0b751c7c245870c4cd7101 + Approved-By: Eli Zaretskii + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_text + Make the current program space reference bubble up one level. Use a + program space from the context whenever that makes sense. + + Change-Id: Id3b0bf4490178d71a9aecdbf404b9287c22b30f5 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_linkage + Make the current_program_space reference bubble up one level. + + Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to get_symbol_leading_char + Make the current_program_space references bubble up one level. In this + case, I think it makes sense to use m_objfile's program space. + + Change-Id: Ibecb89b5e8a0363328240f1675d0fb95ff99c99a + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol + >From what I can see, lookup_minimal_symbol doesn't have any dependencies + on the global current state other than the single reference to + current_program_space. Add a program_space parameter and make that + current_program_space reference bubble up one level. + + Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove lookup_bound_minimal_symbol + Now that lookup_minimal_symbol has default values for sfile and objf, + calling lookup_bound_minimal_symbol is identical to calling + lookup_minimal_symbol without sfile and objf. Remove + lookup_bound_minimal_symbol, replace call sites with + lookup_minimal_symbol. + + Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: make lookup_minimal_symbol objf and sfile parameters optional + Most calls to lookup_minimal_symbol don't pass a value for sfile and + objf. Make these parameters optional (have a default value of + nullptr). And since passing a value to `objf` is much more common than + passing a value to `sfile`, swap the order so `objf` comes first, to + avoid having to pass a nullptr value to `sfile` when wanting to pass a + value to `objf`. + + Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: drop struct keyword when using bound_minimal_symbol + This is a simple find / replace from "struct bound_minimal_symbol" to + "bound_minimal_symbol", to make things shorter and more consisten + througout. In some cases, move variable declarations where first used. + + Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove find_and_open_solib so_list method + Now that the nto port is removed, this is unused. + + Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8 + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdbsupport: remove #ifndef REALTIME_LO in signals.cc + REALTIME_LO was only possibly previously defined in config/nm-nto.h, + which is now removed. So we can remove the #ifndef protecting against a + redefinition of REALTIME_LO in gdbsupport/signals.cc. + + Change-Id: I021b9518ceaa6223bd480ff1e07e9a978b0b241e + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: remove QNX Neutrino support + Remove the support for the QNX Neutrino OS (tdep and native bits). This + has been unmaintained for years, and we don't have a way to see if it + works (or even builds, for the native parts). Without somebody actively + maintaining it, this is just a burden for developers, especially that + this port does a few weird unique things that require reasoning about + when doing big change. + + Support for GDBserver was removed in 2020, commit 613f149a90d6 + ("gdbserver: remove support for Neutrino"). + + Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: rename target-delegates.c to target-delegates-gen.c + Following this suggestion: + + https://inbox.sourceware.org/gdb-patches/2a0520ec-ccfe-4fc3-b051-7b8c60294de5@efficios.com/T/#md537792a1871addf153f3e406224f9baf025414a + + Change-Id: I30988c46505f130ca16155891958f92621cada97 + Approved-By: John Baldwin + Approved-By: Andrew Burgess + +2024-08-12 GDB Administrator + + Automatic date update in version.in + +2024-08-11 GDB Administrator + + Automatic date update in version.in + +2024-08-10 H.J. Lu + + ld: Add PR ld/32067 tests + Add PR ld/32067 tests with the compiler driver since the -plugin option + is needed to trigger this --oformat binary bug. + + PR ld/32067 + * testsuite/ld-i386/i386.exp: Run PR ld/32067 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/start.s: Add .note.GNU-stack section. + * testsuite/ld-x86-64/pr32067.s: New file. + +2024-08-10 Alan Modra + + PR32067, ld -Wl,--oformat,binary crash in _bfd_elf_link_keep_memory + The direct fix for this segfault is to test for a non-NULL bed in + _bfd_elf_link_keep_memory, but also there isn't much point in running + code for LTO if the output is binary. + + PR 32067 + * elflink.c (_bfd_elf_link_keep_memory): Test for non-NULL bed. + (elf_link_add_object_symbols): Don't run the loop setting + non_ir_ref_regular if the output hash table is not ELF. + +2024-08-10 GDB Administrator + + Automatic date update in version.in + +2024-08-09 Bernd Edlinger + + Fix test failure when TUI is not enabled + This adds a missing allow_tui_tests guard. + + When tui is not enabled this test case does + typically fail: + + FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui + + Approved-By: Tom de Vries + +2024-08-09 Stephan Rohr + + gdb: adjust the default place of 'list' to main's prologue + The 'list' command prints around the 'main' function if the current + source location is not set. The prologue of 'main' is skipped and the + first real line of 'main' is offset by 'lines_to_print - 1'. This is + incorrect, the location should be defaulted to main's prologue without + applying offsets (similar to 'list main'). Printing around the selected + line is then done in 'list_around_line'. + + The patch also fixes an issue if the list command is used before the + program is started. For example, with the following code: + + 26 static void attribute ((used)) ambiguous_fun (void) {} + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + GDB offsets the relevant line by 'lines_to_print - 1' and then by another + 'lines_to_print / 2' and prints: + + (gdb) list + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + + With this patch, GDB correctly prints: + + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + Approved-By: Andrew Burgess + +2024-08-09 Jan Beulich + + gas: drop scrubber states 14 and 15 + While sadly 5262831592fb doesn't say anything on why these would have + been needed, the latest with the removal of most of the opcode vs + operands distinction in the scrubber these shouldn't be needed anymore. + The implementation was a little questionable anyway, in moving back to + states expecting labels, when clearly labels shouldn't really be + following predicates (in practice, due to another bug, at least ia64 + permits such). + +2024-08-09 Jan Beulich + + gas: have scrubber retain more whitespace + According to the description of the state machine, the expectation + appears to be that (leaving aside labels) any insn mnemonic or + directive would be followed by a comma separated list of operands. That + may have been true very long ago, but the latest with the advent of more + elaborate macros this isn't rhe case anymore. Neither macro parameters + in macro definitions nor macro arguments in macro invocations are + required to be separated by commas. Hence whitespace serves a crucial + role there. Plus even without "real" macros issues exist, in e.g. + + .irp n, ... + insn\n\(suffix) operand1, operand2 + .endr + + Whitespace following the closing parenthesis would have been removed + (ahead of even processing the .irp), as the "opcode" was deemed to have + ended earlier already. + + Therefore, squash the distinction between "opcode" and operands, i.e. + fold state 10 back into state 3. Also drop most of the distinction + between "symbol chars" and "relatively normal" ones. Not entirely + unexpectedly this results in the need to skip whitespace in a few more + places in arch-specific code (and quite likely more changes are needed + for insn forms not covered by the testsuite). + + As a result the D10V special case is no longer necessary. + + In config/tc-sparc.c also move a comment to be next to the code being + commented. + + In opcodes/cgen-asm.in some further cleanup is done, following the local + var adjustments. + +2024-08-09 Jan Beulich + + MIPS: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + aarch64: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + Arm: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + m32r: move scrubber override to target header + Other than LEX_IS_* settings, such #define-s don't belong into the + common source file. + + Arm: respect line separators for .symver scrubber special case + Directives end at "line" (really: statement) separators, not just at + new-line chars. + + gas: respect CR_EOL also for scrubbing + While apparently intended to be only externally controlled (e.g. via + specifying CFLAGS at make invocation), we should still keep scrubber and + lexer in sync in this regard. There's one place which imo was previously + wrong already, but would go further wrong and hence is being adjusted + right here: An .mri directive can be terminated by any kind of "line" + (really: statement) separators. + + gas: have scrubber also respect quoted labels + For the handling of ':' elsewhere in the scrubber to be correct with + regard to labels, the state after parsing a string found at the start of + a line must match that after finding a symbol character at the start of + a line. (Things are largely okay when there's whitespace ahead of the + label: Whitespace after the colon then is retained rather than dropped + for typical targets like x86, but read.c will know to deal with that.) + +2024-08-09 Nelson Chu + + RISC-V: PR32014, .option directives shuoldn't affect elf attribute. + The .option arch/rvc/norvc/push/pop directives can only take effect for a + small/large specific code region, so they are not file-level architecture + setting. They should only affect the mapping symbols only rather than the + file-level elf architecture attribute. Otherwise, the elf architecture + attribute will appear to missing some extensions when -flto merges files + with different .option architecture settings. + + gas/ + PR 32014 + * config/tc-riscv.c (file_arch_str): New const char *, rather than the + arch_str in the riscv_rps_as.subset_list, it's file-level so only be + affected by .attribute arch directive. + (riscv_reset_subsets_list_arch_str): Renamed to riscv_set_arch_str, and + also can handle both file_arch_str and arch_str in subset_list, just + give the pointer address as the input. + (riscv_set_arch): Called by -march and .attribute arch, so set both + file_arch_str and arch_str in subset_list. + (s_riscv_option): Updated .option arch/rvc/norvc/push/pop that only + set the arch_str in subset_list. + (riscv_write_out_attrs): Output elf architecture attribute according to + file_arch_str. Freed file_arch_str. + * doc/c-riscv.texi: Added destrbution that .option directives shouldn't + affect the elf attribute settings. + * testsuite/gas/riscv/option-arch.s: From option-arch-01/02/03 merged. + * testsuite/gas/riscv/option-arch-dis.d: Likewise, for dis-assembler. + * testsuite/gas/riscv/option-arch-attr.d: Likewise, to check readelf -A. + +2024-08-09 GDB Administrator + + Automatic date update in version.in + +2024-08-08 Richard Henderson + + gas: sparc: Fix faligndatai assembly and disassembly + The first operand is a general register, not an fp register; + the third operand is encoded into RS2, not RS3; + the second operand must match the destination operand. + +2024-08-08 Tom de Vries + + [gdb/python] Fix handling of ^C during disassembly + Inspired by the trigger patch I used here [1], I tried this in + gdbpy_print_insn: + ... + /* Call into the registered disassembler to (possibly) perform the + disassembly. */ + + set_quit_flag (); + PyObject *insn_disas_obj = (PyObject *) disasm_info; + gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (), + insn_disas_obj, + ... + and with test-case gdb.python/py-disasm-exec.exp ran into: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: Python Exception : ^M + ^M + unknown disassembler error (error = -1)^M + (gdb) + ... + + This is incorrect, the KeyboardInterrupt should propagate and interrupt the + command. + + Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in + gdbpy_print_insn, giving us instead: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: ^M + Quit^M + (gdb) + ... + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + [1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html + +2024-08-08 Tom de Vries + + [gdb] Handle ^C during disassembly + In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while + disassembling. + + I managed to reproduce this on aarch64-linux in a Leap 15.5 container using + this trigger patch: + ... + gdb_disassembler_memory_reader::dis_asm_read_memory + (bfd_vma memaddr, gdb_byte *myaddr, unsigned int len, + struct disassemble_info *info) noexcept + { + + set_quit_flag (); + return target_read_code (memaddr, myaddr, len); + } + ... + and a simple gdb command line calling the disassemble command: + ... + $ gdb -q -batch a.out -ex "disassemble main" + ... + + The following scenario leads to the fatal error: + - the disassemble command is executed, + - set_quit_flag is called in + gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a + user pressed ^C, + - target_read_code calls QUIT, which throws a + gdb_exception_quit, + - the exception propagation mechanism reaches c code in libopcodes and a fatal + error triggers because the c code is not compiled with -fexception. + + Fix this by: + - wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in + catch_exceptions (which consequently needs moving to a header file), and + - reraising the caught exception in default_print_insn using QUIT. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025 + +2024-08-08 GDB Administrator + + Automatic date update in version.in + +2024-08-07 Jan Beulich + + score: drop TC_ALPHA code + I can't see how that could ever have come into play. + +2024-08-07 Jan Beulich + + gas: drop dead VMS code from command line handling + The only time 'v' was overridden, allowing for an optional value, was + when OBJ_VMS support still existed (until a little less than 20 years + ago). Drop the respective leftovers. + + With that OPTION_VERBOSE also becomes redundant and hence is being + dropped. + +2024-08-07 Jan Beulich + + VAX: drop OBJ_VMS leftovers + OBJ_VMS support was dropped almost 20 years ago (e330299ed5ee). Drop + respective code from tc-vax.c as well. + + While there, make adjustments for OBJ_ELF as well: -K was dropped over + 20 years ago (530556a951f5), yet left in md_shortopts. OPTION_PIC isn't + really necessary either; 'k' can be used instead. And then the ELF + options available weren't displayed by md_show_usage(). + +2024-08-07 Jan Beulich + + gas: improve unrecognized command line option diagnostic + Printing optc with %c makes sense only when optc is actually a + character. Add logic to also deal with unrecognized long options, + rejected by md_parse_option() rather than get_opt_long_only(). Also + quote the reproduced strings, such that possible included whitespace + can be recognized. + +2024-08-07 Nelson Chu + + gas/NEWS: Moved RISC-V Zimop/Zcmop changes into 2.43 section due to backport. + +2024-08-07 Alan Modra + + loongarch ld testsuite xpasses + Some tests started passing with commit 3a83f0342e54. However, + supporting a changed ld output format is not so simple, and the change + to the loongarch_elf_hash_table macro needs further changes to the + rest of the code. It is true that some uses of + loongarch_elf_hash_table do not need to check the type of the hash + table, but others like loongarch_elf_relax_section do need to check. + bfd_relax_section is called in lang_size_sections using the input bfd, + not the output bfd. If the input bfd may be of different type to the + output, then the hash table type must be checked before accessing + elements of the hash table. This patch corrects + loongarch_elf_relax_section. I haven't checked all the uses of the + hash table throughout the loongarch backend. + + bfd/ + * elfnn-loongarch.c (loongarch_elf_relax_section): Don't relax + unless the hash table is loongarch_elf_link_hash_table. + Move variable declarations. Formatting. + ld/ + * testsuite/ld-elf/pr21884.d: Don't xfail loongarach. + * testsuite/ld-unique/pr21529.d: Likewise. + +2024-08-07 GDB Administrator + + Automatic date update in version.in + +2024-08-06 Hannes Domani + + Mark unavailable bytes of limited-length arrays when allocating contents + Using 'output' to print arrays larger than max-value-size, with only + repeating elements, can cause gdb to crash: + ``` + $ cat a.c: + char a[1000000]; + + int main() + { + return a[0]; + } + $ gdb -q a + (gdb) print a + $1 = {0 '\000' , } + (gdb) output a + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + Using 'print' works, because value::record_latest sets the unavailable + bytes of the value when it's added to the value history. + But 'outout' doesn't do that, so the printing tries to access more bytes + than are available. + + The original problem in PR32015 was about using 'print' of a dynamic + array in a D program. + Here the crash happens because for 'print' the value was a struct with + length/ptr fields, which is converted in d-valprint.c into an array. + So value::record_latest didn't have a chance to mark the unavailable + bytes in this case. + + To make sure the unavailable bytes always match the contents, this fixes + it by marking the unavailable bytes immediately after the contents are + allocated. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015 + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-08-06 Indu Bhagat + + gas: scfi: replace verbose expressions with local vars + Replace the scattered and repeated uses of verbose expressions with + variables. E.g., + ginsn_get_src_reg (src1) -> src1_reg + ginsn_get_src_type (src1) -> src1_type + etc. + + This hopefully makes the logic bit more maintainable. While at it, + include minor adjustments to make few checks in gen_scfi_ops () more + precise: + - When getting imm value from src operand, ensure the src type is + GINSN_SRC_IMM, + - When getting reg from src operand, ensure the src type is checked + too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate). + + On the other hand, the changes in verify_heuristic_traceable_reg_fp () + and verify_heuristic_traceable_stack_manipulation () are purely + mechanical. + + gas/ + * scfi.c (verify_heuristic_traceable_reg_fp): Add new local + vars and reuse them. + (verify_heuristic_traceable_stack_manipulation): Likewise. + (gen_scfi_ops): Likewise. Additionally, make some conditionals + more precise. + +2024-08-06 Hau Hsu + + RISC-V: map zext.h to pack/packw if Zbkb is enabled + The `zext.h` is zero-extend halfword instruction that belongs to Zbb. + Currently `zext.h` falls back to 2 shifts if Zbb is not enabled. However, the + encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which + belongs to Zbkb. The instructions pack the low halves of rs1 and rs2 into rd. + When rs2 is zero (x0), they behave like zero-extend instruction, and the + encoding are exactly the same as zext.h. + + Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled, + instead of 2 shifts. This reduces one instruction. + + This patch does this by making `zext.h` also available for Zbkb. + + opcodes/ + * riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use + `ZBB_OR_ZBKB` instruction class. + + gas/ + * testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to + pack/packw encoding. + * testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise. + * testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise. + +2024-08-06 Mary Bennett + + RISC-V: Add support for XCvBitmanip extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvbitmanip` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvbitmanip. + * testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.s: New Test. + + include/opcode/ChangeLog: + * riscv-opc.h: Add corresponding MATCH and MASK macros for + XCVbitmanip. + * riscv.h: Add corresponding EXTRACT and ENCODE macros for + XCVbitmanip. + (enum riscv_insn_class): Add the XCVbitmanip instruction class. + + opcodes/ChangeLog: + * riscv-dis.c (print_insn_args): Add custom operands `Xc6` and `Xc7`. + * riscv-opc.c: Add XCvBitmanip instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zcmop extension + This implements the Zcmop (Compressed Zimop) extension, as of version 1.0. + + View detailed information in: + + + The Zcmop extension requires the Zca extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zcmop. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zcmop.d: New test. + * testsuite/gas/riscv/zcmop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zcmop. + (MATCH_C_MOP_1, MATCH_C_MOP_3, MATCH_C_MOP_5, MATCH_C_MOP_7, + MATCH_C_MOP_9, MATCH_C_MOP_11, MATCH_C_MOP_13, MATCH_C_MOP_15): Define. + (MASK_C_MOP_1, MASK_C_MOP_3, MASK_C_MOP_5, MASK_C_MOP_7, + MASK_C_MOP_9, MASK_C_MOP_11, MASK_C_MOP_13, MASK_C_MOP_15): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZCMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zcmop instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zimop extension + This implements the Zimop (May-Be-Operations) extension, as of version 1.0. + + View detailed information in: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zimop + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zimop.d: New test. + * testsuite/gas/riscv/zimop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zimop. + (MATCH_MOP_R_0, MATCH_MOP_R_1, MATCH_MOP_R_2, MATCH_MOP_R_3, + MATCH_MOP_R_4, MATCH_MOP_R_5, MATCH_MOP_R_6, MATCH_MOP_R_7, + MATCH_MOP_R_8, MATCH_MOP_R_9, MATCH_MOP_R_10, MATCH_MOP_R_11, + MATCH_MOP_R_12, MATCH_MOP_R_13, MATCH_MOP_R_14, MATCH_MOP_R_15, + MATCH_MOP_R_16, MATCH_MOP_R_17, MATCH_MOP_R_18, MATCH_MOP_R_19, + MATCH_MOP_R_20, MATCH_MOP_R_21, MATCH_MOP_R_22, MATCH_MOP_R_23, + MATCH_MOP_R_24, MATCH_MOP_R_25, MATCH_MOP_R_26, MATCH_MOP_R_27, + MATCH_MOP_R_28, MATCH_MOP_R_29, MATCH_MOP_R_30, MATCH_MOP_R_31, + MATCH_MOP_RR_0, MATCH_MOP_RR_1, MATCH_MOP_RR_2, MATCH_MOP_RR_3, + MATCH_MOP_RR_4, MATCH_MOP_RR_5, MATCH_MOP_RR_6, MATCH_MOP_RR_7): Define. + (MASK_MOP_R_0, MASK_MOP_R_1, MASK_MOP_R_2, MASK_MOP_R_3, MASK_MOP_R_4, + MASK_MOP_R_5, MASK_MOP_R_6, MASK_MOP_R_7, MASK_MOP_R_8, MASK_MOP_R_9, + MASK_MOP_R_10, MASK_MOP_R_11, MASK_MOP_R_12, MASK_MOP_R_13, + MASK_MOP_R_14, MASK_MOP_R_15, MASK_MOP_R_16, MASK_MOP_R_17, + MASK_MOP_R_18, MASK_MOP_R_19, MASK_MOP_R_20, MASK_MOP_R_21, + MASK_MOP_R_22, MASK_MOP_R_23, MASK_MOP_R_24, MASK_MOP_R_25, + MASK_MOP_R_26, MASK_MOP_R_27, MASK_MOP_R_28, MASK_MOP_R_29, + MASK_MOP_R_30, MASK_MOP_R_31, MASK_MOP_RR_0, MASK_MOP_RR_1, + MASK_MOP_RR_2, MASK_MOP_RR_3, MASK_MOP_RR_4, MASK_MOP_RR_5, + MASK_MOP_RR_6, MASK_MOP_RR_7): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZIMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zimop instructions. + +2024-08-06 GDB Administrator + + Automatic date update in version.in + +2024-08-05 Simon Marchi + + gdb: rename gdbarch.c to gdbarch-gen.c + For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind + if all generated files had the `-gen` suffix. + + Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428 + Approved-By: John Baldwin + +2024-08-05 Jan Beulich + + gas: maintain line numbers correctly after #APP / #NO_APP + Maintaining line numbers correctly both inside the region and past it + requires special care. The SB produced there is somewhat different from + that produced for e.g. macro expansions, and hence also needs treating + differently: In particular we aren't doing anything resembling macro + expansion here. + + The new testcase may be a little misplaced in macros/, but that's where + all the other #APP / #NO_APP ones are. + +2024-08-05 Jan Beulich + + gas: generalize / tighten #APP / #NO_APP recognition + For one '#' may not be in line_comment_chars[] in the first place. Look + for just it when it is (these "directives" are akin to C preprocessor + directives after all), but accept any other line comment character + otherwise (in read.c further requiring a match on the counterpart + "directive"). + + Then, when in the middle of a file, the constructs should be all on + their own on a line. There needs to be a newline ahead of them and + after them. + + Finally '\n' may not be the only end-of-line character. Accept any (but + not end-of-statement ones) in read.c, while making sure in input-file.c + there is one in the first place - merely any kind of whitespace isn't + good enough. + +2024-08-05 Jan Beulich + + gas: recognize #APP at start-of-physical-line only + It's not valid to recognize it after mere line separators (often + semicolon) or after labels, let alone after tc_unrecognized_line() + perhaps having parsed off parts of a line. It shouldn't even be + preceded by whitespace, aiui. + + However, keep ignoring line comments as before, for backwards + compatibility. + +2024-08-05 Tom de Vries + + [gdb] Notice when stepping into different file + Consider the following test-case: + ... + $ cat -n test.c + 1 int var; + 2 + 3 int + 4 foo (void) + 5 { + 6 var = 1; + 7 #include "test.h" + 8 } + 9 + 10 int + 11 main () + 12 { + 13 return foo (); + 14 } + $ cat -n test.h + 1 return 1; + $ gcc test.c -g + ... + + When stepping through the test-case, gdb doesn't make it explicit that line 1 + is not in test.c: + ... + Temporary breakpoint 1, main () at test.c:13 + 13 return foo (); + (gdb) step + foo () at test.c:6 + 6 var = 1; + (gdb) n + 1 return 1; + (gdb) + 8 } + (gdb) + ... + which makes it easy to misinterpret the output. + + This is with the default "print frame-info" == auto, with documented + behaviour [1]: + ... + stepi will switch between source-line and source-and-location depending on the + program counter. + ... + + What is actually implemented is that source-line is used unless stepping into + or out of a function. + + The problem can be worked around by using + "set print frame-info source-and-location", but that's a bit verbose. + + Instead, change the behaviour of "print frame-info" == auto to also use + source-and-location when stepping into another file, which gets us: + ... + (gdb) n + foo () at test.h:1 + 1 return 1; + ... + + Tested on x86_64-linux. + + Reviewed-By: Kevin Buettner + Reviewed-By: Kévin Le Gouguec + + PR gdb/32011 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo + +2024-08-05 mengqinggang + + LoongArch: Add support for OUTPUT_FORMAT("binary") + In binary output format, loongarch_elf_hash_table return NULL and result + in segment fault. + + When ld output binary file, it seems that elf related functions should + not be called. But loongarch_elf_relax_section be called and + loongarch_elf_hash_table cause segment fault. + + Just redefined loongarch_elf_hash_table and always return + link_info->hash. + + The tests of binutils, glibc and gcc is ok. + + 0 loongarch_elf_relax_section () + 1 0x000055555557ab28 in lang_size_sections_1 () + 2 0x000055555557a16c in lang_size_sections_1 () + 3 0x000055555557b0a8 in one_lang_size_sections_pass () + 4 0x000055555557b478 in lang_size_sections () + 5 0x000055555557e65c in lang_relax_sections () + 6 0x000055555559f9c8 in ldelf_map_segments () + 7 0x000055555559783c in gldelf64loongarch_after_allocation () + 8 0x000055555558dac0 in ldemul_after_allocation () + 9 0x000055555557f6c0 in lang_process () + 10 0x0000555555585314 in main () + +2024-08-05 GDB Administrator + + Automatic date update in version.in + +2024-08-04 Nick Clifton + + Update release-README after completing the 2.43 release. + +2024-08-04 GDB Administrator + + Automatic date update in version.in + +2024-08-03 H.J. Lu + + LTO: Restore the wrapper symbol check for standard function + Call unwrap_hash_lookup to restore the wrapper symbol check for standard + function since reference to standard function may not show up in LTO + symbol table: + + [hjl@gnu-tgl-3 pr31956-3]$ nm foo.o + 00000000 T main + U __real_malloc + 00000000 T __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ lto-dump -list foo.o + Type Visibility Size Name + function default 0 malloc + function default 0 __real_malloc + function default 3 main + function default 5 __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ make + gcc -O2 -flto -Wall -c -o foo.o foo.c + gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o + /usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main': + :(.text.startup+0xa): undefined reference to `__wrap_malloc' + collect2: error: ld returned 1 exit status + make: *** [Makefile:22: x] Error 1 + [hjl@gnu-tgl-3 pr31956-3]$ + + Also add a test to verify that the unused wrapper is removed. + + PR ld/31956 + * plugin.c (get_symbols): Restore the wrapper symbol check for + standard function. + * testsuite/ld-plugin/lto.exp: Run the malloc test and the + unused test. + * testsuite/ld-plugin/pr31956c.c: New file. + * testsuite/ld-plugin/pr31956d.c: New file. + * testsuite/ld-plugin/pr31956d.d: New file. + +2024-08-03 GDB Administrator + + Automatic date update in version.in + +2024-08-02 Simon Marchi + + gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extension + Now that all known uses of VLAs within GDB are removed, remove the + `-Wno-vla-cxx-extension` (which was used to silence clang warnings) and + add `-Wvla`, such that any use of a VLA will trigger a warning. + + Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 + Reviewed-By: Keith Seitz + +2024-08-02 Simon Marchi + + gdb: remove uses of VLA + Remove uses of VLAs, replace with gdb::byte_vector. There might be more + in files that I can't compile, but it's difficult to tell without + actually compiling on all platforms. + + Many thanks to the Linaro pre-commit CI for helping find some problems + with an earlier iteration of this patch. + + Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e + Reviewed-by: Keith Seitz + +2024-08-02 Guinevere Larsen + + gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robust + Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not + actually compiling the test with some debuginfo in the relevant part, + and while fixing I noticed that the base assumption of the "some" case + was wrong, GDB would select some symtab as a default location and the + test would always fail. This fix makes printing the default location + only be tested when there is no debuginfo. + + When testing with no debuginfo, if a system had static libc debuginfo, + the test would also fail. To add an extra layer of robustness to the + test, this rewrite also strips any stray debuginfo from the executable. + The test would only fail now if it runs in a system that can't handle + stripped debuginfo and has static debuginfo pre-installed. + + Reported-By: Tom de Vries + Reported-By: Thiago Jung Bauermann + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721 + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2024-08-02 Simon Marchi + + gdb: remove inline_frame::skipped_frames + While reviewing [1], it occurred to me that having both the + skipped_frames counter and the skipped_syms vector is redundant. When + stepping into an inline frame, we can just pop the last element. + + [1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a + + Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198 + Approved-By: Andrew Burgess + +2024-08-02 Nick Clifton + + Updated Bulgarian translation for the binutils/ directory + +2024-08-02 Aapo Rantalainen + + Fix typo in --help output of the strings program. + PR 31940 + +2024-08-02 Guinevere Larsen + + gdb/testsuite: fix gdb.python/py-framefilter-invalidarg.exp with clang + The final test of gdb.python/py-framefilter-invalidarg.exp expected that + the the backtrace only printed the source file name. However, when using + clang, gdb will always print the full path to the file, which would + cause the test to fail. This commit introduces a regexp that optionally + matches paths, preprended to the file name, which fixes the clang + failure without introducing gcc failures. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: extend XFAIL to gdb.fortran/entry-point.exp to clang too + The test gdb.fortran/entry-point.exp already has an XFAIL when trying to + set a breakpoint in mod::mod_foo because gcc puts that subprogram in the + wrong scope in the debug information. Clang's debug information looks + the same as gcc's, so the test to setup the xfail has been extended to + also include clang. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: add build-id compile flag to tests that expect it + Clang doesn't add build-id information by default, unlike gcc. This + means that tests that rely on build-id being available and don't + explicitly add it to the compilation options will fail with clang. + This commit fixes the fails in gdb.python/py-missing-debug.exp, + gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp + and gdb.server/solib-list.exp + + Approved-By: Andrew Burgess + +2024-08-02 Jan Beulich + + gas: drop unnecessary use of tc_comment_chars + The override is necessary only when a target needs other than an array + of const char. + + For cris drop redundant sibling declarations at the same time. + +2024-08-02 Jan Beulich + + gas: correctly deal with line comments when not preprocessing + Internal naming of functions / data as well as commentary mixes lines + and statements. It is presumably this confusion which has led to the + wrong use of ignore_rest_of_line() when dealing with line comments in + read_a_source_file(). We shall not (silently) produce different output + depending on whether -f is passed (for suitable input). + + Introduce two new helper macros, intended to be used in favor of open- + coded accesses to is_end_of_line[]. To emphasize the difference, convert + ignore_rest_of_line() right away, including adjustments to its comments. + + Since most targets have # in line_comment_chars[], add a target- + independent test for that, plus an x86-only one also checking for non-# + to work as intended. + +2024-08-02 GDB Administrator + + Automatic date update in version.in + +2024-08-01 Indu Bhagat + + gas: ginsn: minor improvements in ginsn_dst_print and ginsn_src_print + Keep the two symmetrical looking. Makes sense to perform the sanity + checks similarly too. + + gas/ + * ginsn.c (ginsn_src_print): Buffer up result of snprintf and + add sanity checks on the value. + (ginsn_dst_print): Use switch case instead. + +2024-08-01 Indu Bhagat + + gas: ginsn: do not emit an unnecessary trailing comma in textual dump + For ginsns with less than 2 source operands or no destination operands, + the current textual dump contains a superfluous comma, like the relevant + testcases show. + + Adjust the code a bit to not emit the lone trailing comma. Also, adjust + the aarch64 and x86_64 testcases. + + gas/ + * ginsn.c (ginsn_src_print): Do not use a trailing comma when + printing the src of ginsn. + (ginsn_print): Check the strlen and prefix a comma before the + src string. + + gas/testsuite/ + * gas/scfi/aarch64/ginsn-cofi-1.l: Adjust the expected textual + dump of the ginsn. + * gas/scfi/x86_64/ginsn-cofi-1.l: Likewise. + +2024-08-01 Indu Bhagat + + gas: x86: ginsn: handle previously missed indirect call and jmp ops + Some flavors of indirect call and jmp instructions were not being + handled earlier, leading to a GAS error (#1): + (#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI" + + Not handling jmp/call (direct or indirect) ops is an error (as shown + above) because SCFI needs an accurate CFG to synthesize CFI correctly. + Recall that the presence of indirect jmp/call, however, does make the + CFG ineligible for SCFI. In other words, generating the ginsns for them + now, will eventually cause SCFI to bail out later with an error (#2) + anyway: + (#2) "Error: untraceable control flow for func 'XXX'" + + The first error (#1) gives the impression of missing functionality in + GAS. So, it seems cleaner to synthesize a GINSN_TYPE_JUMP / + GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with + the error as expected. + + The handling for these indirect jmp/call instructions is similar, so + reuse the code by carving out a function for the same. + + Adjust the testcase to include the now handled jmp/call instructions as + well. + + gas/ + * config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New + function. + (x86_ginsn_new): Refactor out functionality to above. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output. + * gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of + jmp/call opcodes. + +2024-08-01 Hui Li + + gdb: LoongArch: Add show-debug-regs maintenance command + This patch register the command "maint set show-debug-regs on/off" + and make it settable by the user. If show-debug-regs is enabled, + the debug register values are shown when GDB inserts or removes a + hardware breakpoint or watchpoint. This is helpful for the use and + development of hardware watchpoints. + + With this patch, the effect of this maintenance command as follows: + + lihui@bogon:~$ cat test.c + int a = 0; + int main() + { + a = 1; + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + lihui@bogon:~$ gdb test + ... + (gdb) watch a + Hardware watchpoint 1: a + (gdb) maint set show-debug-regs on + (gdb) r + Starting program: /home/lihui/test + ... + ... + + prepare_to_resume thread 41525 + ... + insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1 + ... + remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x0, ctrl=0x00000000, ref.count=0 + + Hardware watchpoint 1: a + + Old value = 0 + New value = 1 + main () at test.c:5 + 5 return 0; + (gdb) + +2024-08-01 Alan Modra + + skip_attr_bytes assertion (data) <= (end) fail + get_type_abbrev_from_form is lax in not limiting data for a uleb to + the current CU, because DW_FORM_ref_addr allows access to other CU's + data. This can lead to an assertion fail when skipping or reading + attributes in get_type_signedness. + + * dwarf.c (get_type_abbrev_from_form): Limit uleb data to map end + for ref_addr, cu_end otherwise. + +2024-08-01 Gustavo Romero + + gdb: AArch64: Support MTE on baremetal + This commit moves aarch64_linux_memtag_matches_p, + aarch64_linux_set_memtags, aarch64_linux_get_memtag, and + aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag + function used by them), along with the setting of the memtag granule + size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available + on baremetal targets. Since the aarch64-linux-tdep.c layer inherits + these hooks from aarch64-tdep.c, there is no effective change for + aarch64-linux targets. + + Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were + moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h} + files. + + Tested-By: Luis Machado + Approved-By: Luis Machado + Reviewed-By: Eli Zaretskii + +2024-08-01 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13 + On fedora rawhide, with python 3.13, I run into: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + this function got an unexpected keyword argument 'invalid'^M + Error occurred in Python: \ + this function got an unexpected keyword argument 'invalid'^M + (gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + A passing version with an older python version looks like: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + 'invalid' is an invalid keyword argument for this function^M + Error occurred in Python: \ + 'invalid' is an invalid keyword argument for this function^M + (gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + Fix this by accepting the updated error message. + + Tested on aarch64-linux. + + PR testsuite/31912 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912 + +2024-08-01 Lulu Cai + + LoongArch: Fix ld FAIL test cases + To avoid differences in C library paths on different systems + use gcc instead of ld to perform the test. + + Problems caused by adding options to different distributions + will not be fixed. + +2024-08-01 Mark Harmstone + + ld/PDB: handle empty LF_FIELDLIST types + Empty structs in C++ lead to empty LF_FIELDLIST types in the .debug$T + section, but we were mistakenly rejecting these as invalid. Allow + CodeView types of two bytes, and add a test for this. + +2024-08-01 GDB Administrator + + Automatic date update in version.in + +2024-07-31 Nick Alcock + + libctf: fix ctf_archive_count return value on big-endian + This failed to properly byteswap its return value. + + The ctf_archive format predates the idea of "just write natively and + flip on open", and byteswaps all over the place. It's too easy to + forget one. The next revision of the archive format (not versioned, + so we just tweak the magic number instead) should be native-endianned + like the dicts inside it are. + + libctf/ + * ctf-archive.c (ctf_archive_count): Byteswap return value. + +2024-07-31 Nick Alcock + + libctf: dump: fix small leak + If you asprintf something and then use it only as input to another asprintf, + it helps to free it afterwards. + + libctf/ + * ctf-dump.c (ctf_dump_header): Free the flagstr after use. + (ctf_dump): Make a NULL return slightly clearer. + +2024-07-31 Nick Alcock + + libctf: fix ref leak of names of newly-inserted non-root-visible types + A bug in ctf_dtd_delete led to refs in the string table to the + names of non-root-visible types not being removed when the DTD + was. This seems harmless, but actually it would lead to a write + down a pointer into freed memory if such a type was ctf_rollback()ed + over and then the dict was serialized (updating all the refs as the + strtab was serialized in turn). + + Bug introduced in commit fe4c2d55634c700ba527ac4183e05c66e9f93c62 + ("libctf: create: non-root-visible types should not appear in name tables") + which is included in binutils 2.35. + + libctf/ + * ctf-create.c (ctf_dtd_delete): Remove refs for all types + with names, not just root-visible ones. + +2024-07-31 Nick Alcock + + libctf: clean up hashtab error handling mess + The dict and archive opening code in libctf is somewhat unusual, because + unlike everything else, it cannot report errors by setting an error on the + dict, because in case of error there isn't one. They get passed an error + integer pointer that is set on error instead. + + Inside ctf_bufopen this is implemented by calling ctf_set_open_errno and + passing it a positive error value. In turn this means that most things it + calls (including init_static_types) return zero on success and a *positive* + ECTF_* or errno value on error. + + This trickles down to ctf_dynhash_insert_type, which is used by + init_static_types to add newly-detected types to the name tables. This was + returning the error value it received from a variety of functions without + alteration. ctf_dynhash_insert conformed to this contract by returning a + positive value on error (usually OOM), which is unfortunate for multiple + reasons: + + - ctf_dynset_insert returns a *negative* value + - ctf_dynhash_insert and ctf_dynset_insert don't take an fp, so the value + they return is turned into the errno, so it had better be right, callers + don't just check for != 0 here + - more or less every single caller of ctf_dyn*_insert in libctf other than + ctf_dynhash_insert_type (and there are a *lot*, mostly in the + deduplicator) assumes that ctf_dynhash_insert returns a negative value + on error, even though it doesn't. In practice the only possible error is + OOM, but if OOM does happen we end up with a nonsense error value. + + The simplest fix for this seems to be to make ctf_dynhash_insert and + ctf_dynset_insert conform to the usual interface contract: negative + values are errors. This in turn means that ctf_dynhash_insert_type + needs to change: let's make it consistent too, returning a negative + value on error, putting the error on the fp in non-negated form. + + init_static_types_internal adapts to this by negating the error return from + ctf_dynhash_insert_type, so the value handed back to ctf_bufopen is still + positive: the new call site in ctf_track_enumerator does not need to change. + + (The existing tests for this reliably detect when I get it wrong. + I know, because they did.) + + libctf/ + * ctf-hash.c (ctf_dynhash_insert): Negate return value. + (ctf_dynhash_insert_type): Set de-negated error on the dict: + return negated error. + * ctf-open.c (init_static_types_internal): Adapt to this change. + +2024-07-31 Nick Alcock + + libctf, include: add ctf_dict_set_flag: less enum dup checking by default + The recent change to detect duplicate enum values and return ECTF_DUPLICATE + when found turns out to perturb a great many callers. In particular, the + pahole-created kernel BTF has the same problem we historically did, and + gleefully emits duplicated enum constants in profusion. Handling the + resulting duplicate errors from BTF -> CTF converters reasonably is + unreasonably difficult (it amounts to forcing them to skip some types or + reimplement the deduplicator). + + So let's step back a bit. What we care about mostly is that the + deduplicator treat enums with conflicting enumeration constants as + conflicting types: programs that want to look up enumeration constant -> + value mappings using the new APIs to do so might well want the same checks + to apply to any ctf_add_* operations they carry out (and since they're + *using* the new APIs, added at the same time as this restriction was + imposed, there is likely to be no negative consequence of this). + + So we want some way to allow processes that know about duplicate detection + to opt into it, while allowing everyone else to stay clear of it: but we + want ctf_link to get this behaviour even if its caller has opted out. + + So add a new concept to the API: dict-wide CTF flags, set via + ctf_dict_set_flag, obtained via ctf_dict_get_flag. They are not bitflags + but simple arbitrary integers and an on/off value, stored in an unspecified + manner (the one current flag, we translate into an LCTF_* flag value in the + internal ctf_dict ctf_flags word). If you pass in an invalid flag or value + you get a new ECTF_BADFLAG error, so the caller can easily tell whether + flags added in future are valid with a particular libctf or not. + + We check this flag in ctf_add_enumerator, and set it around the link + (including on child per-CU dicts). The newish enumerator-iteration test is + souped up to check the semantics of the flag as well. + + The fact that the flag can be set and unset at any time has curious + consequences. You can unset the flag, insert a pile of duplicates, then set + it and expect the new duplicates to be detected, not only by + ctf_add_enumerator but also by ctf_lookup_enumerator. This means we now + have to maintain the ctf_names and conflicting_enums enum-duplication + tracking as new enums are added, not purely as the dict is opened. + Move that code out of init_static_types_internal and into a new + ctf_track_enumerator function that addition can also call. + + (None of this affects the file format or serialization machinery, which has + to be able to handle duplicate enumeration constants no matter what.) + + include/ + * ctf-api.h (CTF_ERRORS) [ECTF_BADFLAG]: New. + (ECTF_NERR): Update. + (CTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): Likewise. + + libctf/ + * ctf-impl.h (LCTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_track_enumerator): Declare. + * ctf-dedup.c (ctf_dedup_emit_type): Set it. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link): Likewise. + (ctf_link_write): Likewise. + * ctf-subr.c (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): New function. + * ctf-open.c (init_static_types_internal): Move enum tracking to... + * ctf-create.c (ctf_track_enumerator): ... this new function. + (ctf_add_enumerator): Call it. + * libctf.ver: Add the new functions. + * testsuite/libctf-lookup/enumerator-iteration.c: Test them. + +2024-07-31 Nick Alcock + + include, libctf: improve ECTF_DUPLICATE error message + It applies to enums now, so it should mention them. + + include/ + * ctf-api.h (_CTF_ERRORS) ECTF_DUPLICATE]: Mention enums. + +2024-07-31 Nick Alcock + + libctf: link: remember to turn off the LCTF_LINKING flag after ctf_link_write + We set this flag at the top of ctf_link_write (to tell ctf_serialize, way + down under the archive file writing functions, to do the various link- time + serialization things like symbol filtering and the like), but we never + remember to clear it except on error. This is probably bad if you want to + serialize the dict yourself directly in the future after linking it (which + is... definitely a *possible* use of the API, if rather strange). + + libctf/ + * ctf-link.c (ctf_link_write): Clear LCTF_LINKING before exit. + +2024-07-31 Nick Alcock + + libctf: link: fix error handling + We were calling the wrong error function if opening failed, causing leaks. + + libctf/ + * ctf-link.c (ctf_link_deduplicating_per_cu): Fix error handling. + +2024-07-31 Nick Alcock + + libctf, open: Fix enum error handling path + This new error-handling path was not properly initializing the + fp's errno. + + libctf/ + * ctf-open.c (init_static_types_internal): Set errno properly. + +2024-07-31 Nick Alcock + + libctf, subr: don't mix up errors and warnings + ctf_err_warn() was debug-logging warnings as if they were errors and vice + versa. + + libctf/ + * ctf-subr.c (ctf_err_warn): Fix debugging thinko. + +2024-07-31 Nick Alcock + + libctf: fix dynset insertion + libctf's dynsets are a straight wrapper around libiberty hashtab, storing + the key directly in the hashtab slot. However, we'd often like to be able + to store 0 and 1 (HTAB_EMPTY_ENTRY and HTAB_DELETED_ENTRY) in there, so we + move them out of the way and replace them with huge unlikely values + instead. Unfortunately we failed to do this replacement in one place, so + insertion of 0 or 1 ended up misinforming the hashtab machinery that an + entry was empty or deleted when it wasn't. + + libctf/ + * ctf-hash.c (ctf_dynset_insert): Call key_to_internal properly. + +2024-07-31 Nick Alcock + + libctf: dedup: tiny tweaks + Drop an unnecessary variable, and fix a buggy comment. + + No effect on generated code. + + libctf/ + * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Drop unnecessary + variable. + (ctf_dedup_rwalk_output_mapping): Fix comment. + +2024-07-31 Nick Alcock + + libctf: improve ECTF_NOPARENT error message + This erorr doesn't just indicate that there is no parent dictionary + (that's routine, and true of all dicts that are parents themselves) + but that a parent is *needed* but wasn't found. + + include/ + * ctf-api.h (_CTF_ERRORS) [ECTF_NOPARENT]: Improve error message. + + ld/ + * testsuite/ld-ctf/diag-parname.d: Adjust. + +2024-07-31 Nick Alcock + + libctf: fix CTF dict compression + Commit 483546ce4f3 ("libctf: make ctf_serialize() actually serialize") + accidentally broke dict compression. There were two bugs: + + - ctf_arc_write_one_ctf was still making its own decision about + whether to compress the dict via direct ctf_size comparison, which is + unfortunate because now that it no longer calls ctf_serialize itself, + ctf_size is always zero when it does this: it should let the writing + functions decide on the threshold, which they contain code to do which is + simply not used for lack of one trivial wrapper to write to an fd and + also provide a compression threshold + + - ctf_write_mem, the function underlying all writing as of the commit + above, was calling zlib's compressBound and avoiding compression if this + returned a value larger than the input. Unfortunately compressBound does + not do a trial compression and determine whether the result is + compressible: it just adds zlib header sizes to the value passed in, so + our test would *always* have concluded that the value was incompressible! + Avoid by simply always compressing if the raw size is larger than the + threshold: zlib is quite clever enough to avoid actually compressing + if the data is incompressible. + + Add a testcase for this. + + libctf/ + * ctf-impl.h (ctf_write_thresholded): New... + * ctf-serialize.c (ctf_write_thresholded): ... defined here, + a wrapper around... + (ctf_write_mem): ... this. Don't check compressibility. + (ctf_compress_write): Reimplement as a ctf_write_thresholded + wrapper. + (ctf_write): Likewise. + * ctf-archive.c (arc_write_one_ctf): Just call + ctf_write_thresholded rather than trying to work out whether + to compress. + * testsuite/libctf-writable/ctf-compressed.*: New test. + +2024-07-31 Nick Alcock + + libctf: fix linking of non-root-visible types + If you deduplicate non-root-visible types, the resulting type should still + be non-root-visible! We were promoting all such types to root-visible, and + re-demoting them only if their names collided (which might happen on + cu-mapped links if multiple compilation units with conflicting types are + fused into one child dict). + + This "worked" before now, in that linking at least didn't fail (if you don't + mind having your non-root flag value destroyed if you're adding + non-root-visible types), but now that conflicting enumerators cause their + containing enums to become conflicted (enums which might have *different + names*), this caused the linker to crash when it hit two enumerators with + conflicting values. + + Not testable in ld because cu-mapped links are not exposed to ld, but can be + tested via direct creation of libraries and calls to ctf_link directly. + (This also tests the ctf_dump non-root type printout, which before now + was untested.) + + libctf/ + * ctf-dedup.c (ctf_dedup_emit_type): Non-root-visible input types + should be emitted as non-root-visible output types. + * testsuite/libctf-writable/ctf-nonroot-linking.c: New test. + * testsuite/libctf-writable/ctf-nonroot-linking.lk: New test. + +2024-07-31 Nick Alcock + + libctf, dump: correctly dump non-root-visible types + The flag test when dumping non-root-visible tyeps was doubly wrong: the + flags word is a *bitfield* containing CTF_ADD_ROOT as one possible + value, so needs | and & testing, not just ==, and CTF_ADD_NONROOT is 0, + so cannot be tested for this way: one must check for the non-presence of + CTF_ADD_ROOT. + + libctf/ + * ctf-dump.c (ctf_dump_format_type): Fix non-root flag test. + +2024-07-31 Nick Alcock + + libctf, string: split the movable refs out of the ref list + In commit 149ce5c263616e65 we introduced the concept of "movable" refs, + which are refs that can be moved in batches, to let us maintain valid ref + lists even when adding refs to blocks of memory that can be realloced (which + is any type containing a vlen which can expand, like names contained within + enum or struct members). Movable refs need a backpointer to the movable + refs dynhash for this dict; since non-movable refs are very common, we tried + to save memory by having a slightly bigger struct for moveable refs with a + backpointer in it, and casting appropriately, indicating which sort of ref + we were dealing with via a flag on the atom. + + Unfortunately this doesn't work reliably, because you can perfectly well + have a string ("foo", say) which has both non-movable refs (say, an external + symbol and a variable name) and movable refs (say, a structure member name) + to the same atom. Indicate which struct we're dealing with with an atom + flag and suddenly you're casting a ctf_str_atom_ref to a + ctf_str_atom_ref_movable (which is bigger) and dereferencing random memory + off the end of it and interpreting it as a backpointer to the movable refs + dynhash. This is unlikely to work well. + + So bite the bullet and split refs into two separate lists, one for movable + refs, one for immovable refs. It means some annoying code duplication, but + there's not very much of it, and it means we can keep the movable refs + hashtab (which in turn means we don't have to do linear searches to find all + relevant refs when moving refs, which in turn means that + structure/union/enum member additions remain amortized O(n) time, not + O(n^2). + + Callers can now purge movable and non-movable refs independently of each + other. We don't use this yet, but a use is coming. + + libctf/ + * ctf-impl.h (CTF_STR_ATOM_MOVABLE): Delete. + (struct ctf_str_atom) [csa_movable_refs]: New. + (struct ctf_dict): Adjust comment. + (ctf_str_purge_refs): Add MOVABLE arg. + * ctf-string.c (ctf_str_purge_movable_atom_refs): Split out of... + (ctf_str_purge_atom_refs): ... this. + (ctf_str_free_atom): Call it. + (ctf_str_purge_one_atom_refs): Likewise. + (aref_create): Adjust accordingly. + (ctf_str_move_refs): Likewise. + (ctf_str_remove_ref): Remove movable refs too, including + deleting the ref from ctf_str_movable_refs. + (ctf_str_purge_refs): Add MOVABLE arg. + (ctf_str_update_refs): Update movable refs. + (ctf_str_write_strtab): Check, and purge, movable refs. + +2024-07-31 Nick Alcock + + libctf, dedup: drop unnecessary arg from ctf_dedup() + The PARENTS arg is carefully passed down through all the layers of hash + functions and then never used for anything. (In the distant past it was + used for cycle detection, but the algorithm eventually committed doesn't + need to do cycle detection...) + + The PARENTS arg is still used by ctf_dedup_emit(), but even there we can + loosen the requirements and state that you can just leave entries + corresponding to dicts with no parents at zero (which will be useful + in an upcoming commit). + + libctf/ + * ctf-dedup.c (ctf_dedup_hash_type): Drop PARENTS arg. + (ctf_dedup_rhash_type): Likewise. + (ctf_dedup): Likewise. + (ctf_dedup_emit_struct_members): Mention what you can do to + PARENTS entries for parent dicts. + * ctf-impl.h (ctf_dedup): Adjust accordingly. + * ctf-link.c (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link_deduplicating): Likewise. + +2024-07-31 Nick Alcock + + libctf: we do in fact support foreign-endian old versions + The worry that caused this to not be supported was because we don't + bother endian-flipping version-related fields before checking them. + But they're all unsigned chars anyway, and don't need any flipping at + all. + + This should be supported and should already work. Enable it. + + libctf/ + * ctf-open.c (ctf_bufopen): Don't prohibit foreign-endian + upgrades. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Fix trailing-text-in-parentheses duplicates + Fix all trailing-text-in-parentheses duplicates exposed by previous patch. + + Tested on x86_64-linux and aarch64-linux. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Detect trailing-text-in-parentheses duplicates + When using a duplicate test name: + ... + fail foo + fail foo + ... + we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo + DUPLICATE: $exp: foo + ... + + But when we do: + ... + fail foo + fail "foo (timeout)" + ... + we get only: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + ... + + Trailing text between parentheses prefixed with a space is interpreted as + extra information, and not as part of the test name [1]. + + Consequently, "foo" and "foo (timeout)" do count as duplicate test names, + which should have been detected. This is PR testsuite/29772. + + Fix this in CheckTestNames::_check_duplicates, such that we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + DUPLICATE: $exp: foo (timeout) + ... + + [ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't + know whether that covers all required cases, due to the fact that those are + not unambiguousely specified. It might be possible to reverse-engineer that + information by reading or running the "regression analysis tools" mentioned on + the wiki page [1], but I haven't been able to. Regardless, the current regexp + covers a large amount of cases, which IMO should be sufficient to be + acceptable. ] + + Doing so shows many new duplicates in the testsuite. + + A significant number of those is due to using a message which is a copy of the + command: + ... + gdb_test "print (1)" + ... + + Fix this by handling those cases using test names "gdb-command" and + "gdb-command. + + Fix the remaining duplicates manually (split off as follow-up patch for + readability of this patch). + + Tested on x86_64-linux and aarch64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772 + + [1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages + +2024-07-31 Tom de Vries + + [gdb/testsuite] Add gdb.python/py-disasm-{exec,obj}.exp + I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a + s390x machine, but when running with target board unix/-m31 I saw that the + required libraries were missing, so I couldn't generate an executable. + + However, I realized that I did have an object file, and the test-case should + mostly also work with an object file. + + I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and + included it from two new minimal test-case wrappers: + - gdb.python/py-disasm-exec.exp, and + - gdb.python/py-disasm-obj.exp + where the former uses an executable as before, and the latter uses an object + file. + + Using an object file required changing the info.read_memory calls in + gdb.python/py-disasm.py: + ... + - info.read_memory(1, -info.address + 2) + + info.read_memory(1, -info.address - 1) + ... + because reading from address 2 succeeds. Using address -1 instead does + generate the expected gdb.MemoryError. + + Tested on x86_64-linux. + +2024-07-31 Tom de Vries + + [gdb/exp] Fix gdb.fortran/intrinsics.exp fail on arm + When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get: + ... + (gdb) p cmplx (4,4,16)^M + /home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \ + Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error) + ... + + The problem is that 16-byte floats are unsupported: + ... + $ gfortran test.f90 + test.f90:2:17: + + 2 | REAL(kind=16) :: foo = 1 + | 1 + Error: Kind 16 not supported for type REAL at (1) + ... + and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with + code TYPE_CODE_ERROR. + + Fix this by bailing out asap when encountering such a type. + + Without this patch we're able to do the rather useless: + ... + (gdb) ptype real*16 + type = real*16 + (gdb) ptype real_16 + type = real*16 + ... + but with this patch we get: + ... + (gdb) ptype real*16 + unsupported kind 16 for type real*4 + (gdb) ptype real_16 + unsupported type real*16 + ... + + Tested on arm-linux. + + PR fortran/30537 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537 + +2024-07-31 Jan Beulich + + x86: move ginsn stuff + This had been badly inserted between md_assemble() and its helpers + anyway. Follow what was done for Arm64 and move the code to its own + file, #include-d as appropriate. + + gas/doc: adjust an @xref + Old doc tools warn about there not being a . or , following; satisfy + those tools by shortening the line and adding a full stop. + +2024-07-31 Alan Modra + + fix the framework error + Running the testsuite for an x86_64-w64-mingw32 target using the + Ubuntu package gcc-mingw-w64-x86-64 version 13.2.0-6ubuntu1+26.1 + results in a number of messages: + ERROR: can't decipher gcc version number, fix the framework! + + Someone in their wisdom decided this compiler should advertise itself + with a version of 13-win32, breaking the ld testsuite version checks. + (It is also configured using --with-as=/usr/bin/x86_64-w64-mingw32-as + --with-ld=/usr/bin/x86_64-w64-mingw32-ld which renders the -B flag + inoperative for testing the newly built gas and ld. You'd need to + install binutils over the top of the Ubuntu versions before testing, a + rather unsatisfactory process.) + + * testsuite/lib/ld-lib.exp (at_least_gcc_version): Use + preprocessor test of __GNUC__ and __GNUC_MINOR__ rather than + output of gcc --version. Correct removal of -Wl options. + +2024-07-31 GDB Administrator + + Automatic date update in version.in + +2024-07-30 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some more + When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie), + I run into: + ... + Expecting: ^(-var-create A_String_Access \* A_String_Access[ + ]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[ + ]+[(]gdb[)] + [ ]*) + -var-create A_String_Access * A_String_Access + ^error,msg="Cannot access memory at address 0x4" + (gdb) + FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) + ... + + This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite] + Fix regexp in gdb.ada/mi_var_access.exp"). + + The problem in both cases is that we're printing an uninitialized variable, + and consequently we can run into various error messages during printing. + + Fix this as in the other commit, by accepting the error message. + + Tested on arm-linux. + +2024-07-30 Simon Marchi + + gdb: don't call macro_bcache with nullptr + Since commit b1da98a74656 ("gdb: remove use of alloca in + new_macro_definition"), if cached_argv is empty, we call macro_bcache + with a nullptr data. This ends up caught by UBSan deep down in the + bcache code: + + $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow + Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + /home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null + + The backtrace: + + #1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750 + #2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195 + #3 0x0000555564b49222 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158 + #4 0x0000555564b481fa in macro_bcache (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117 + #5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573 + #6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777 + #7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816 + #8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203 + + This can be reproduced by running gdb.base/macscp.exp. Avoid calling + macro_bcache if the macro doesn't have any arguments. + + Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d + +2024-07-30 Vladimir Mezentsev + + gprofng: 32018 Compilation of binutils 2.43 failed on CentOS 6 + strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7. + In this case, we may not use our CALL_UTIL macro for strchr. + Use __collector_strchr instead of "CALL_UTIL (strchr)". + + gprofng/ChangeLog + 2024-07-28 Vladimir Mezentsev + + PR 32018 + * libcollector/hwprofile.c (open_experiment): Use __collector_strchr. + +2024-07-30 Tom de Vries + + [gdb/symtab] Emit malformed macro definition complaint once + Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the + .debug_macro section. + + For one malformed macro definition, I get two identical complaints: + ... + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + ... + + Fix this by bailing out after the first one. + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-07-30 Simon Marchi + + gdb: remove use of alloca in new_macro_definition + Replace alloca with std::vector. + + Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c + Approved-By: Tom de Vries + +2024-07-30 Simon Marchi + + gdb: use std::string vector for macro definition + Use std::vector when defining macros, to avoid the manual + memory management. + + With the use of std::vector, the separate `int argc` parameter is no + longer needed, we can use the size of the vector instead. However, for + some functions, this parameter had a dual function. For object-like + macros, it was interpreted as a `macro_special_kind` enum. For these + functions, remove `argc`, but add a new `special_kind` parameter. + + Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5 + Approved-By: Tom de Vries + +2024-07-30 Andrew Burgess + + gdb/doc: move @anchor off @item line + When building the GDB info manual I see this warning: + + gdb.texinfo:41447: warning: @anchor should not appear on @item line + + And indeed line 41447 looks like this: + + @item @anchor{maint info breakpoints}maint info breakpoints + + I propose moving the @anchor{...} part to the previous line which + silences the warning. + + Approved-By: Eli Zaretskii + +2024-07-30 Lulu Cai + + gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.43 + +2024-07-30 GDB Administrator + + Automatic date update in version.in + +2024-07-29 Alexandra Hájková + + Add a test for the gcore script + It also tests the gcore script being run without its accessible + terminal. + + This test was written by Jan Kratochvil a long time ago. I modernized + the test making it use various procs from lib/gdb.exp, reorganizing it + and added some comments. + + Modify the gcore script to make it possible to pass the --data-directory to + it. This prevents a lot of these warnings: + + Python Exception : module 'gdb' has no attribute + '_handle_missing_debuginfo' + + Tested by using make check-all-boards. + + Co-Authored-By: Jan Kratochvil + + Reviewed-By: Eli Zaretskii + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0 + When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we + run into: + ... + (gdb) save gdb-index index_1^M + Error while writing index for `xgdb': No debugging symbols^M + (gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file + ... + + Fix this by instead emitting an unsupported, and bailing out. + + Tested on aarch64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.exp + When running test-case gdb.threads/leader-exit-attach.exp with target board + native-extended-gdbserver I run into: + ... + (gdb) KFAIL: $exp: attach (PRMS: gdb/31555) + print $_inferior_thread_count^M + $1 = 0^M + (gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554) + ... + + The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc + ("Fix "attach" failure handling with GDBserver"), and consequently the PR is + closed. + + Fix this by removing the corresponding kfail. + + Tested on x86_64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1 + With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into: + ... + (gdb) attach 18591^M + Attaching to program: leader-exit-attach, process 18591^M + warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555) + ^M + ptrace: Operation not permitted.^M + (gdb) FAIL: $exp: get valueof "$_inferior_thread_count" + ... + + The problem is that the gdb_test_multiple in the test-case doesn't consume the + prompt in all clauses: + ... + gdb_test_multiple "attach $testpid" "attach" { + -re "Attaching to process $testpid failed.*" { + # GNU/Linux gdbserver. Linux ptrace does not let you attach + # to zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "warning: process $testpid is a zombie - the process has already terminated.*" { + # Native GNU/Linux. Linux ptrace does not let you attach to + # zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" { + pass $gdb_test_name + set attached 1 + } + } + ... + + Fix this by using -wrap in the first two clauses. + + While we're at it, also use -wrap in the third clause. + + Tested on x86_64-linux. + +2024-07-29 Nick Clifton + + Updated translations for the bfd, binutils, gas, ld and opcodes directories + +2024-07-29 Alan Modra + + Fixes to "PR 31728 testcases" + This brings us down to just these fails for the set of targets I + usually test when making testsuite changes. + aarch64-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-ld + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool + + The aarch64 one is likely due to the target missing support somewhere. + It is fairly new, I haven't investigated. The arm-pe fails are due to + arm-pe being a target that adds underscores to symbol names (see + config.bfd) whereas dlltool thinks it does not (see + dlltool.c:asm_prefix). arm-wince-pe on the other hand doesn't add + underscores. I would guess the right fix for dlltool is to get this + symbol info from bfd using bfd_get_target_info. + + Note I'm not very happy about the creative use of ld_after_inputfile + in symbols-ordinals-hints-imports-ld.d, which is likely to break with + some future run_dump_test change. + +2024-07-29 Pali Rohár + + PR 31728 testcases + +2024-07-29 Alan Modra + + PR32032 dwp segfaults on hello world binary + Fixing the segfault is easy with this bandaid, but further work is + needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header. + At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id. + + PR 32032 + * dwp.cc (Dwp_output_file::finalize): Return immediately on + no output file. + +2024-07-29 GDB Administrator + + Automatic date update in version.in + +2024-07-28 Andrew Burgess + + gdb/testsuite: track if a caching proc calls gdb_exit or not + After a recent patch review I asked myself why can_spawn_for_attach + exists. This proc currently does some checks, and then calls + can_spawn_for_attach_1 which is an actual caching proc. + + The answer is that can_spawn_for_attach exists in order to call + gdb_exit the first time can_spawn_for_attach is called within any test + script. + + The reason this is useful is that can_spawn_for_attach_1 calls + gdb_exit. If the user calls can_spawn_for_attach_1 directly then a + problem might exist. Imagine a test written like this: + + gdb_start + + if { [can_spawn_for_attach_1] } { + ... do stuff that assumes GDB is running ... + } + + If this test is NOT the first test run, and if an earlier test calls + can_spawn_for_attach_1, then when the above test is run the + can_spawn_for_attach_1 call will return the cached value and gdb_exit + will not be called. + + But, if the above test IS the first test run then + can_spawn_for_attach_1 will not return the cached value, but will + instead compute the cached value, a process that ends up calling + gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited + and the test might fail if it is written assuming that GDB is + running. + + So can_spawn_for_attach was added which ensures that we _always_ call + gdb_exit the first time can_spawn_for_attach is called within a single + test script, this ensures that in the above case, even if the above is + not the first test script run, gdb_exit will still be called. This + ensures consistent behaviour and avoids some hidden bugs in the + testsuite. + + The split between can_spawn_for_attach and can_spawn_for_attach_1 was + introduced in this commit: + + commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f + Date: Mon May 6 14:27:09 2024 +0200 + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + + However, I observe that can_spawn_for_attach is not the only caching + proc that calls gdb_exit. Why does can_spawn_for_attach get special + treatment when surely the same issue exists for any other caching proc + that calls gdb_exit? + + I think a better solution is to move the logic from + can_spawn_for_attach into cache.exp and generalise it so that it + applies to all caching procs. + + This commit does this by: + + 1. When the underlying caching proc is executed we track calls to + gdb_exit. If a caching proc calls gdb_exit then this information + is stored in gdb_data_cache (using a ',exit' suffix), and also + written to the cache file if appropriate. + + 2. When a cached value is returned from gdb_do_cache, if the + underlying proc would have called gdb_exit, and if this is the + first use of the caching proc in this test script, then we call + gdb_exit. + + When storing the ',exit' value into the on-disk cache file, the flag + value is stored on a second line. Currently every cached value only + occupies a single line, and a check is added to ensure this remains + true in the future. + + To track calls to gdb_exit I eventually settled on using TCL's trace + mechanism. We already make use of this in lib/gdb.exp so I figure + this is OK to use. This should be fine, so long as non of the caching + procs use 'with_override' to replace gdb_exit, or do any other proc + replacement to change gdb_exit, however, I think that is pretty + unlikely. + + One issue did come up in testing, a FAIL in gdb.base/break-interp.exp, + prior to this commit can_spawn_for_attach would call gdb_exit before + calling the underlying caching proc. After this call we call gdb_exit + after calling the caching proc. + + The underlying caching proc relies on gdb_exit having been called. To + resolve this issue I just added a call to gdb_exit into + can_spawn_for_attach. + + With this done can_spawn_for_attach_1 can be renamed to + can_spawn_for_attach, and the existing can_spawn_for_attach can be + deleted. + +2024-07-28 Andrew Burgess + + gdb/testsuite: restructure gdb_data_cache (lib/cache.exp) + In the next commit I want to add more information to + gdb_data_cache (see lib/cache.exp). Specifically I want to track if + the underlying function of a caching proc calls gdb_exit or not. + + Currently gdb_data_cache is an associative array, the keys of which + are the name of the caching proc. + + In this commit I add a ',value' suffix to the gdb_data_cache keys. In + the next commit I'll add additional entries with a different suffix. + + There should be no noticable changes after this commit, this is just a + restructuring. + +2024-07-28 GDB Administrator + + Automatic date update in version.in + +2024-07-27 Tom de Vries + + [gdb/tdep] Fix arm thumb2 hw breakpoint + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + This may or may not be a kernel bug. + + Work around this by first using an inoffensive address bpts[i].address & ~0x7. + + Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on + target board native-gdbserver/mthumb. + + While we're at it: + - use arm_hwbp_control_is_initialized in + arm_linux_nat_target::low_prepare_to_resume, + - handle the !arm_hwbp_control_is_initialized case explicitly, + - add missing '_()' in arm_target::low_prepare_to_resume, + - make error messages identical between arm_target::low_prepare_to_resume and + arm_linux_nat_target::low_prepare_to_resume, + - factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to + make the implementation more readable. + + Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in + gdb.base/hbreak.exp") by simply reverting the commit. + + Tested on arm-linux. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-07-27 GDB Administrator + + Automatic date update in version.in + +2024-07-26 YunQiang Su + + microMIPS: Add MT ASE instruction set support + Add the MT ASE instruction operand types and encodings to the microMIPS + opcode table and enable the assembly of these instructions in GAS from + MIPSr2 onwards. Update the binutils and GAS testsuites accordingly. + + References: + + "MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for + the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number: + MD00768, Revision 1.12, July 16, 2013 + + Co-Authored-By: Maciej W. Rozycki + +2024-07-26 Nick Clifton + + Fix "Untranslated plural in readelf.c" + PR 32002 + +2024-07-26 Andrew Burgess + + gdb/testsuite: fix build-id compile option when used with clang + It was pointed out in this message: + + https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com + + That the test gdb.base/build-id-seqno.exp I added recently was FAILing + when using Clang as the compiler. + + The problem was that I had failed to add 'build-id' as a compile + option in the call to build_executable within the test script. For + GCC this is fine as build-ids are included by default. For Clang + though this meant the build-id was not included and the test would + fail. + + So I added build-id to the compiler options.... and the test still + didn't pass! Now the test fails to compile and I see this error from + the compiler: + + gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \ + input unused [-Wunused-command-line-argument] + + It turns out that the build-id compile option causes our gdb.exp to + add the '-Wl,--build-id' option into the compiler flags, which means + its used when building the object file AND during the final link. + However this option is unnecessary when creating the object file and + Clang warns about this, which causes the build to fail. + + The solution is to change gdb.exp, instead of adding the build-id + flags like this: + + lappend new_options "additional_flags=-Wl,--build-id" + + we should instead add them like: + + lappend new_options "ldflags=-Wl,--build-id" + + Now the flag is only appended during the link phase and Clang is + happy. The gdb.base/build-id-seqno.exp test now passes with Clang. + + The same problem (adding to additional_flags instead of ldflags) + exists for the no-build-id compile option, so I've fixed that too. + + While investigating this I also spotted two test scripts, + gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were + setting ldflag directly rather than using the build-id compile option + so I've updated these two tests to use the compile option which I + think is neater. + + I've checked that all these tests still pass with both GCC and Clang. + + There should be no changes in what is actually tested after this + commit. + + Approved-By: Simon Marchi + +2024-07-26 Jan Beulich + + gas: correct sb_add_char() 2nd parameter type + It's entirely unclear why size_t was used there; my only guess is copy- + and-paste from another of the functions. + +2024-07-26 Jan Beulich + + gas: drop scrubber state -2 + Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring + that we wouldn't get bogus state transitions: For example, when we're in + states 0 or 1, a comment should be no different from whitespace + encountered in those states. Plus for e.g. x86 this results in such + comments now truly being converted to a blank, as mandated by + documentation. Both aspects apparently were a result of blindly (and + wrongly) moving to state 3 _before_ consuming the "ungot" blank. + + Also amend a related comment elsewhere. + + In the new testcase the .irp is to make visible in the listing all the + whitespace that the scrubber inserts / leaves in place. + +2024-07-26 Jan Beulich + + x86: accept whitespace around prefix separator + ... and prediction suffix comma. Other than documented /**/ comments + currently aren't really converted to a single space, at least not for + x86 in its most common configurations. That'll be fixed subsequently, at + which point blanks may appear where so far none were expected. + Furthermore not permitting blanks around these separators wasn't quite + logical anyway - such constructs are composite ones, and hence + components ought to have been permitted to be separated by whitespace + from the very beginning. Furthermore note how, due to the scrubber being + overly aggressive in removing whitespace, some similar construct with a + prefix were already accepted. + + Note how certain other checks in parse_insn() can be simplified as a + result. + + While there for the prediction suffix also make checks case-insensitive + and check for a proper trailing separator. + +2024-07-26 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to BMI2 ones + ..., as those leave EFLAGS untouched anyway. That's a shorter encoding, + available as long as no eGPR is in use anywhere. + +2024-07-26 Alan Modra + + Remove srcdir from x86 testcase "source:" lines + It's wrong to have ${srcdir} in run_dump_test "source:" lines, as + run_dump_test adds $srcdir/$subdir/ to the line passed to the shell + except when the source path starts with "./". The tests work + currently because the shell expands ${srcdir} to an empty string. + + PR 31728 + * testsuite/ld-i386/code16.d: Correct "source:". + * testsuite/ld-x86-64/code16.d: Likewise. + * testsuite/ld-x86-64/rela.d: Likewise. + +2024-07-26 Alan Modra + + ARM print_insn_mve assertion + This corrects objdump -d -m armv8.1-m.main output for a testcase found + by oss-fuzz, .inst 0xee2fee79, which hits an assertion. + + Obviously the switch case constants should be binary, not hex. + Correcting that is enough to cure this assertion, but I don't see any + point in singling out the invalid case 0b10. In fact, it is just plain + wrong to print "undefined instruction: size equals zero undefined + instruction: size equals two". + + I also don't see the need for defensive programming here as is done + elsewhere in checking that "value" is in range before indexing + mve_vec_sizename. There is exactly one MVE_VSHLL_T2 entry in + mve_opcodes. It is easy to verify that "value" is only two bits. + +2024-07-26 GDB Administrator + + Automatic date update in version.in + +2024-07-25 Simon Marchi + + gdb/amdgpu: remove unused includes + Remove two includes reported as unused by clangd. + + Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e + +2024-07-25 H.J. Lu + + x86: Add missing newlines in TLS transition error messages + Change TLS transition error messages from + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV onlyld: final link failed: bad value + + to + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV only + ld: final link failed: bad value + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): + Add missing newlines. + +2024-07-25 H.J. Lu + + x86: Improve TLS transition error check + Provide detailed TLS transition errors when unsupported instructions are + used. Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF when performing TLS transition. + + bfd/ + + PR ld/32017 + * elf32-i386.c (elf_i386_check_tls_transition): Return different + enums for different errors. + (elf_i386_tls_transition): Change argument from r_symndx to sym. + Call _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_i386_scan_relocs): Pass isym instead of r_symndx to + elf_i386_tls_transition. + (elf_i386_relocate_section): Pass sym instead of r_symndx to + elf_i386_tls_transition. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Return + different enums for different errors. + (elf_x86_64_tls_transition): Change argument from r_symndx to sym. + Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF. Call + _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_x86_64_scan_relocs): Pass isym instead of r_symndx to + elf_x86_64_tls_transition. + (elf_x86_64_relocate_section): Pass sym instead of r_symndx to + elf_x86_64_tls_transition. + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): New. + * elfxx-x86.h (elf_x86_tls_error_type): Likewise. + (_bfd_x86_elf_link_report_tls_transition_error): Likewise. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/i386.exp: Run tlsgdesc1 and tlsgdesc2. + * testsuite/ld-i386/tlsie2.d: Updated. + * testsuite/ld-i386/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsie4.d: Likewise. + * testsuite/ld-i386/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie2.d: Likewise. + * testsuite/ld-x86-64/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsgdesc1.d: New file. + * testsuite/ld-i386/tlsgdesc1.s: Likewise. + * testsuite/ld-i386/tlsgdesc2.d: Likewise. + * testsuite/ld-i386/tlsgdesc2.s: Likewise. + * testsuite/ld-x86-64/tlsdesc3.d: Likewise. + * testsuite/ld-x86-64/tlsdesc3.s: Likewise. + * testsuite/ld-x86-64/tlsdesc4.d: Likewise. + * testsuite/ld-x86-64/tlsdesc4.s: Likewise. + * testsuite/ld-x86-64/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie5.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsie5, tlsdesc3 and + tlsdesc4. + +2024-07-25 Nick Clifton + + Add /usr/lib32 to the native search paths for FreeBSD systems. + PR 31395 + +2024-07-25 GDB Administrator + + Automatic date update in version.in + +2024-07-24 Tom Tromey + + Remove redundant macro definitions from remote.c + I happened to notice that a few macros are defined twice in remote.c. + This patch removes one copy. Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-07-24 Tom de Vries + + [gdb/exp] Fix ptype $_creal/$_cimag + Consider test.c, compiled with -g: + ... + __complex__ float cf = 1 + 2i; + int main (void) { return 0; } + ... + + The values of cf and its components are: + ... + $ gdb -q a.out + Reading symbols from a.out... + (gdb) p cf + $1 = 1 + 2i + (gdb) p $_creal(cf) + $2 = 1 + (gdb) p $_cimag(cf) + $3 = 2 + ... + and their respective types are: + ... + (gdb) ptype $1 + type = complex float + (gdb) ptype $2 + type = float + (gdb) ptype $3 + type = float + ... + + Now let's try that again, using ptype directly: + ... + (gdb) ptype cf + type = complex float + (gdb) ptype $_creal(cf) + type = int + (gdb) ptype $_cimag(cf) + type = int + ... + + The last two types should have been float, not int. + + Fix this by extending the internal function handlers creal_internal_fn and + cimag_internal_fn with the noside parameter, such that we get instead: + ... + (gdb) ptype $_creal(cf) + type = float + (gdb) ptype $_cimag(cf) + type = float + ... + + Tested on x86_64-linux. + + Reviewed-By: Keith Seitz + + PR exp/31816 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816 + +2024-07-24 Tom de Vries + + [gdb/exp] Allow internal function to indicate return type + Currently an internal function handler has this prototype: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, + void *cookie, int argc, struct value **argv); + ... + + Also allow an internal function with a handler with an additional + "enum noside noside" parameter: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, void *cookie, + int argc, struct value **argv, enum noside noside); + ... + + In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's + expected to return some value with the correct return type. + + At least, provided it can do so without side effects, otherwise it should + throw an error. + + No functional changes. + + Tested on x86_64-linux and aarch64-linux. + + Reviewed-By: Keith Seitz + +2024-07-24 Nick Clifton + + BFD: Add .relro_padding to list of special sections + +2024-07-24 Andrew Burgess + + gdb/testsuite: ensure gdb_get_worker_threads succeeds + Sometimes, if I'm testing on a loaded machine, the + gdb.gdb/index-file.exp test will timeout during some early steps, + which then cases a TCL error to be thrown later in the test script. + + Dejagnu then reports this error once the test run has completed, which + can be pretty noisy, and isn't really very helpful. + + The underlying problem is that if GDB takes too long to load the + executable (which is GDB itself in this test) then GDB will still be + busy loading the executable when dejagnu moves on and call + gdb_get_worker_threads. The gdb_get_worker_threads call itself times + out as GDB is _still_ busy loading the executable, and so + gdb_get_worker_threads returns the string "UNKNOWN". + + Later we try to perform arithmetic on the worker thread count, which + results in errors when we try to do 'UNKNOWN / 2'. + + I propose that after calling gdb_get_worker_threads, we check if the + result was UNKNOWN. If it was then we should report an UNRESOLVED and + abandon the test, this avoids the later TCL errors. + +2024-07-24 Andrew Burgess + + opcodes/x86: fix minor missed styling case + I noticed that the x86 instruction: + + sar $1,%rsi + + would fail to style the '$0x1' as an immediate. This commit fixes + that case. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Handle address class annotation for s390x in some test-cases + On s390x-linux, I ran into: + ... + (gdb) ptype crash^M + type = class crash {^M + ^M + public:^M + crash(int (class {...}::*)(class {...} * const @mode32));^M + }^M + (gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash + ... + + The problem is that the test-case doesn't expect the address class annotation + @mode32. + + The test-case uses a .S file, with the address size hard-coded to 4 bytes, and + that's something that is annotated with @mode32 on s390x (which uses 8 byte + addresses). + + Fix this by allowing the annotation in the regexp. + + Likewise in two other test-cases. + + Tested on s390-linux and x86_64-linux. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/m-static.exp on arm + With test-case gdb.cp/m-static.exp on arm-linux, I get: + ... + (gdb) ptype test5.single_constructor^M + type = class single_constructor {^M + ^M + public:^M + single_constructor(void);^M + ~single_constructor(void);^M + } *(single_constructor * const)^M + (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor + ... + + The test-case expects: + - no empty line before "public:", and + - no "~single_constructor(void)", but "~single_constructor()" + + The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same + for gcc and clang"). + + The failing test is in a part only enabled for is_aarch32_target == 1, so it + looks like it was left behind. + + I'm assuming the same happened for the other difference. + + Fix this by updating the regexps to match the observed output. + + Tested on arm-linux. + + Approved-By: Andrew Burgess + +2024-07-24 Nelson Chu + + RISC-V: PR32001, Untranslated "internal:" prefix for error message. + bfd/ + PR 32001 + * elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated + "internal:" prefix for error message. + +2024-07-24 GDB Administrator + + Automatic date update in version.in + +2024-07-23 Tom Tromey + + Add returnValue scope to DAP + The DAP spec recently changed to add a new scope for the return value + from a "stepOut" request. This new scope uses the "returnValue" + presentation hint. See: + + https://github.com/microsoft/debug-adapter-protocol/issues/458 + + This patch implements this for gdb. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945 + Reviewed-By: Eli Zaretskii + +2024-07-23 Tom Tromey + + Refine the 'define' documentation + A while ago, an AdaCore user reported some difficulties with the + 'define' command. While some of these difficulties are intrinsic, or + at least difficult to change, it seemed sensible to document a couple + of the typical problems -- and to make the text describing argument + substitution a bit more prominent. + + Approved-By: Eli Zaretskii + +2024-07-23 Simon Marchi + + gdb/solib-frv: move lm_info object to solib + I noticed that the lm_info_frv objects created in frv_current_sos are + never moved to the solib object. This bug was introduced in 8971d2788e + ("gdb: link so_list using intrusive_list"), which mistakenly removed the + line + + sop->lm_info = std::move (li); + + ... probably due so a bad merge conflict resolution. + + Re-add this line. + + If merged in master, I would cherry-pick this to gdb-15-branch. + + Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005 + Approved-By: Andrew Burgess + +2024-07-23 Tom de Vries + + [gdb/testsuite] Add xfail in gdb.base/hbreak.exp + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + I'm not sure if this is simply unsupported or if there's a kernel bug of some + sort, but I don't see what gdb can do about this. + + Tentatively mark this as xfail. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + +2024-07-23 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linux + On arm-linux, I run into: + ... + PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me + Expecting: ^(-stack-list-arguments 1[^M + ]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|)"})?\]},.*[^M + ]+[(]gdb[)] ^M + [ ]*) + -stack-list-arguments 1^M + ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M + (gdb) ^M + FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) + ... + + The problem is that the test-case expects a level 3 frame, but there is none. + + This can be reproduced using cli bt: + ... + $ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \ + -ex "b task_switch.break_me" \ + -ex run \ + -ex bt + Breakpoint 1 at 0x34b4: file task_switch.adb, line 57. + + Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \ + at task_switch.adb:57 + 57 null; + #0 task_switch.break_me () at task_switch.adb:57 + #1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51 + #2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + ... + + The purpose of the test-case is printing the frame at level 1, so I don't + think we should bother about the presence of the frame at level 3. + + Fix this by allowing the backtrace to stop at level 2. + + Tested on arm-linux. + + Approved-By: Luis Machado + Approved-By: Andrew Burgess + +2024-07-23 Pali Roh?r + + Improve objdump's display of PE header information. + PR 31953 + +2024-07-23 GDB Administrator + + Automatic date update in version.in + +2024-07-22 Simon Marchi + + gdb/unittests/intrusive-list: remove unnecessary local objects + These objects are not used. + + Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f + +2024-07-22 Simon Marchi + + gdb/solib: pass program space to solib_used + Make the current program space reference bubble up one level. + + Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123 + +2024-07-22 Andrew Burgess + + gdb/remote: remove an out of date comment + A comment above an `if` check was accidentally left in place after + this commit: + + commit ddb3f3d89cf62df6be3cb9e110504def19625160 + Date: Tue Mar 19 12:34:34 2024 +0100 + + Add "error_message+" feature to qSupported + + The comment relates to how 'E.msg' style remote replies are not + supported by every packet, but after the above commit they are + supported in all cases (that call packet_check_result), and the + comment should have been removed. + +2024-07-22 Andrew Burgess + + gdb/testsuite: fix minor typo in a comment + Fix 'text' to 'test' in a test comment. + +2024-07-22 GDB Administrator + + Automatic date update in version.in + +2024-07-21 Alan Modra + + Don't trim trailing newline in run_host_cmd + Testcases like ld-elf/pr19719a.c that + printf ("PASS\n"); + on success ought to see the whole output for "string match". + Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last + newline to match. For most of the testsuite it doesn't matter whether + the trailing newline is present or not, and there are only a few cases + where we need to remove it. + + * testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away + output trailing newline. Do string trim for gcc/ld version checks. + * testsuite/config/default.exp (plug_so): Do string trim output of + run_host_cmd. + * testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust + string match to include trailing newline. + * testsuite/ld-i386/i386.exp (undefined_weak): Likewise. + * testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise. + * testsuite/ld-plugin/libdep.exp (run_test): Likewise. + * testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise. + * testsuite/ld-pe/pdb-strings.d, + * testsuite/ld-pe/pdb-syms1-globals.d, + * testsuite/ld-pe/pdb-syms1-records.d, + * testsuite/ld-pe/pdb-syms1-symbols1.d, + * testsuite/ld-pe/pdb-syms1-symbols2.d, + * testsuite/ld-pe/pdb-syms2-symbols1.d, + * testsuite/ld-pe/pdb-types1-hashlist.d, + * testsuite/ld-pe/pdb-types1-skiplist.d, + * testsuite/ld-pe/pdb-types1-typelist.d, + * testsuite/ld-pe/pdb-types2-hashlist.d, + * testsuite/ld-pe/pdb-types2-skiplist.d, + * testsuite/ld-pe/pdb-types2-typelist.d, + * testsuite/ld-pe/pdb-types3-hashlist.d, + * testsuite/ld-pe/pdb-types3-skiplist.d, + * testsuite/ld-pe/pdb-types3-typelist.d, + * testsuite/ld-pe/pdb1-publics.d, + * testsuite/ld-pe/pdb1-sym-record.d, + * testsuite/ld-pe/pdb2-section-contrib.d, + * testsuite/ld-pe/pdb3-c13-info1.d, + * testsuite/ld-pe/pdb3-c13-info2.d, + * testsuite/ld-pe/pdb3-source-info.d: Add trailing newline. + +2024-07-21 Andrew Burgess + + gdb/testsuite: Add missing 'require allow_gdbserver_tests' + The commit: + + commit 22836ca88591ac7efacf06d5b6db191763fd8aba + Date: Tue May 21 09:57:49 2024 +0100 + + gdb: check for multiple matching build-id files + + Was missing a 'require allow_gdbserver_tests' in a gdbserver test. + Add it now. + +2024-07-21 Tom de Vries + + [gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.exp + When running test-case gdb.dap/rust-slices.exp on aarch64-linux + (debian 12/bookworm), I run into: + ... + {"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success + FAIL: gdb.dap/rust-slices.exp: three scopes + PASS: gdb.dap/rust-slices.exp: scope is locals + PASS: gdb.dap/rust-slices.exp: locals presentation hint + PASS: gdb.dap/rust-slices.exp: three vars in scope + ... + + The test-case expects three scopes due to a rust compiler issue: + ... + # There are three scopes because an artificial symbol ends up in the + # DWARF. See https://github.com/rust-lang/rust/issues/125126. + gdb_assert {[llength $scopes] == 3} "three scopes" + ... + but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't + have this issue. + + Fix this by allowing two or three scopes, and changing the test name to + "two scopes". + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31983 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983 + +2024-07-21 GDB Administrator + + Automatic date update in version.in + +2024-07-20 Mark Harmstone + + ld/testsuite: add missing definition to PDB test + The file pdb-syms1a.s was missing a definition for T_VOID, which was + causing some types not to be deduplicated. It also meant that the test + couldn't be run against LLVM's lld, which throws an error for this. + + This particular test only tests the symbols stream, not the types + stream, which is why the deduplication doesn't result in a change in the + file size. + +2024-07-20 Mark Harmstone + + ld/PDB: use correct hashing algorithm in add_globals_ref + add_globals_ref was hashing using CRC32 rather than the hashing + algorithm used for symbols, which meant that windbg was unable to put + breakpoints against unmangled names. + +2024-07-20 H.J. Lu + + Correct version for binutils 2.43 NEWS entries. + Change 2.42 to 2.43 for binutils 2.43 NEWS entries. + + binutils/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + + ld/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + +2024-07-20 Andrew Burgess + + gdb: remove tracepoint_probe_create_sals_from_location_spec + The tracepoint_probe_create_sals_from_location_spec function just + forwards all its arguments to + bkpt_probe_create_sals_from_location_spec, and is only used in one + place. + + Lets delete tracepoint_probe_create_sals_from_location_spec and + replace it with bkpt_probe_create_sals_from_location_spec. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: remove breakpoint_re_set_one + During a later patch I wanted to reset a single breakpoint, so I + called breakpoint_re_set_one. However, this is not the right thing to + do. If we look at breakpoint_re_set then we see that there's a whole + bunch of state that needs to be preserved prior to calling + breakpoint_re_set_one, and after calling breakpoint_re_set_one we + still need to call update_global_location_list. + + I could just update the comment on breakpoint_re_set_one to make it + clearer how the function should be used -- or more likely to warn that + the function should only be used as a helper from breakpoint_re_set. + + However, breakpoint_re_set_one is only 3 lines long. So I figure it + might actually be easier to just fold breakpoint_re_set_one into + breakpoint_re_set, then there's no risk of accidentally calling + breakpoint_re_set_one when we shouldn't. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: don't display inferior list for pending breakpoints + I noticed that in the 'info breakpoints' output, GDB sometimes prints + the inferior list for pending breakpoints, this doesn't seem right to + me. A pending breakpoint has no locations (at least, as far as we + display things in the 'info breakpoints' output), so including an + inferior list seems odd. + + Here's what I see right now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo inf 1 + (gdb) + + It's the 'inf 1' at the end of the line that I'm objecting too. + + To trigger this behaviour we need to be in a multi-inferior debug + session. The breakpoint must have been non-pending at some point in + the past, and so have a location assigned to it. + + The breakpoint becomes pending again as a result of a shared library + being unloaded. When this happens the location itself is marked + pending (via bp_location::shlib_disabled). + + In print_one_breakpoint_location, in order to print the inferior list + we check that the breakpoint has a location, and that we have multiple + inferiors, but we don't check if the location itself is pending. + + This commit adds that check, which means the output is now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo + (gdb) + + Which I think makes more sense -- indeed, the format without the + inferior list is what we display for a pending breakpoint that has + never had any locations assigned, so I think this change in behaviour + makes GDB more consistent. + +2024-07-20 Nick Clifton + + Update after creating 2.43 branch + + Change version to 2.43.50 + + Add markers for 2.43 branch/release + +2024-07-20 Alan Modra + + Re: binutils: Add a test for strip with build notes + The new test wasn't being run, and failed due to relocations against + .gnu.build.attributes being stripped by default strip behaviour. + We probably should be keeping these relocations, but I haven't made + that change here. + BTW, the new test fails on ia64-hpux but that's just a repeat of the + existing note-5 fail. + + PR 31999 + * testsuite/binutils-all/strip-16.d: strip with --strip-unneeded + and --merge-notes. + * testsuite/binutils-all/objcopy.exp: Run the new test. Sort + other strip tests. + +2024-07-20 H.J. Lu + + binutils: Add a test for strip with build notes + Add a test for strip with build notes. + + PR binutils/31999 + * testsuite/binutils-all/strip-16.d: New. + +2024-07-20 Alan Modra + + PR31999 strip [.gnu.build.attributes]: failed + PR 31999 + * objcopy.c (merge_gnu_build_notes): Always set *new_size. + +2024-07-20 GDB Administrator + + Automatic date update in version.in + +2024-07-19 Simon Marchi + + gdb-gdb.py: strip typedefs in intrusive_list printer assertion + When debugging gdb itself and trying to print a intrusive_list that has + more than one element, I get: + + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator + node_ptr = self._as_node_ptr(elem_ptr) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr + assert elem_ptr.type.code == gdb.TYPE_CODE_PTR + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + AssertionError + + This is because node_ptr is a typedef + (intrusive_list_base_iterator::pointer). Add a call to strip_typedefs + to get to the real type. + + Enhance gdb.gdb/python-helper.exp with a test that would have caught + this bug. + + Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700 + Approved-By: Andrew Burgess + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Replace "y" microMIPS operand code with "x" + Replace the "y" microMIPS operand code, used with ALNV.PS only, with "x" + so as to make "y" available for microMIPS MT use. + + MIPS/opcodes: Mark MT thread context move assembly idioms as aliases + A number of instructions in the regular MIPS opcode table are assembly + idioms for the MT thread context move MFTR and MTTR instructions, so + mark them as aliases accordingly. Add suitable test cases, which also + cover the PAUSE assembly idiom. + + MIPS/opcodes: Mark PAUSE as an alias + PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in + the regular MIPS opcode table, matching the microMIPS opcode table. A + test case will be supplied separately. + + MIPS/GAS/testsuite: Run the MT ASE test across architectures + Verify that MT ASE instructions assemble and disassemble correctly + across the compatible architectures. + + MIPS/opcodes: Reorder coprocessor moves alphabetically + A number of coprocessor move encodings have been randomly sprinkled over + the regular MIPS and microMIPS opcode tables rather than where they'd be + expected following the alphabetic order. Fix the ordering, taking into + account precedence where it has to be observed for correct disassembly. + No functional change. + + MIPS/opcodes: Make AL a shorthand for INSN2_ALIAS + Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS + opcode tables, just as with the MIPS16 opcode table, and use it + throughout. No functional change. + + MIPS/opcodes: Rename the AL membership shorthand to ALX + Make room for AL as a shorthand for INSN2_ALIAS with the regular MIPS + opcode table, just as with the MIPS16 opcode table. No functional + change. + +2024-07-19 YunQiang Su + + MIPS/opcodes: Remove the regular MIPS "+t" operand code + The semantics of the regular MIPS "+t" operand code is exactly the same + as that of the "E" operand code, so replace the former with the latter + in the single MFTC0 instruction with implicit 'sel' == 0 encoding where + it's used, matching the encoding with explicit 'sel' as well as other + instructions. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Output thread context registers numerically with MFTR/MTTR + We print MFTR and MTTR instructions' thread context register operand in + disassembly using the ABI name the register number would correspond to + should the targeted register be a general-purpose register. + + However in most cases it is wrong, because general-purpose registers are + only referred when the 'u' and 'sel' operands are 1 and 0 respectively. + And even in these cases the MFGPR and MTGPR aliases take precedence over + the corresponding generic instruction encodings, so you won't see the + valid case to normally trigger. + + Conversely decoding the thread context register operand numerically is + always valid, so switch to using it. Adjust test coverage accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros + As from commit ab90248154ba ("Add structures to describe MIPS + operands"), , + the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros + has been removed. + + Similarly as from commit c3c0747817f4 ("Use operand structures for + MIPS16"), , + the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed. + + And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"), + , none of the + OP_OP macros are used anymore. + + Discard all the unused macros then and only keep the small subset that + is still referred. This simplifies maintenance and removes the need to + keep the artificial arrangement where some regular MIPS and microMIPS + macros expand to 0 and are kept for compatibility with the opposite ISA + mode only, as it used to be required before the commit referred. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Correct documentation for R6 operand types + The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which + is the target register rather than the source register. Additionally + the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand + of the BOVC/BNVC and the BEQC/BNEC instructions respectively. Also the + "-x" operand type does not permit 'rs' to be the same as 'rt'. + + Correct inline documentation in opcode/mips.h accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Exclude $0 from "-x" R6 operand type + The "-x" operand type is used for the reverse encoding of the BOVC and + BNVC instructions, where 'rs' and 'rt' have been supplied as the second + and the first operand respectively rather than the order the instruction + expects. + + In this case we require the register associated with the "-x" operand to + have a higher number than the register associated with the preceding "t" + operand, which precludes the use of $0. The case where 'rs' and 'rt' + both refer to the same register is handled by the straight encoding of + the BOVC and BNVC instructions, which come in the opcode table ahead of + the corresponding reverse encoding. + + Therefore clear the ZERO_OK flag for the "-x" operand. No need for an + extra test case as the encodings involved are already covered by "r6" + and its associated GAS tests. + +2024-07-19 Jan Beulich + + Sparc: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + TilePro: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate (and far less intrusive) here. + + MIPS: correct macro use in gas and ld testsuites + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + former appears more appropriate here, as the macro parameters already + have ":req". + + ia64: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate here. + + bfin: drop _ASSIGN_BANG + A few testcases demonstrate that "=!" isn't supposed to be an + individual token, since "= !" is used in a number of places. So far + lexing that to a single token worked because of the scrubber being + overly aggressive in removing whitespace. As that's going to change, + replace uses by separate ASSIGN and BANG. + + bfin: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter really isn't an option here. + + Arm: correct macro use in gas testsuite + The way the inner macro invocations are written doesn't quite work as + expected (and would actually break subsequently): Due to overly + aggressive removal of whitespace by the scrubber, the incoming \sym and + \offset arguments actually get concatenated; an empty 3rd argument is + being passed to ldrtest2. That just so happened to work as intended; any + use of \offset alone would have exposed the problem. Quote the 3rd + argument, thus retaining enough whitespace to be independent of scrubber + internals. + + gas: adjust impossible/bogus M68K/MRI special case when scrubbing + State 1 is uniformly handled further up. And it is highly questionable + that in state 10 (i.e. after having seen not only a possible label, but + also an opcode), which is about to go away anyway, a line comment char + could still be meant to take effect. With the state checking dropped, + the immediately preceding logic can then also be simplified. + +2024-07-19 Jan Beulich + + gas: consistently drop trailing whitespace when scrubbing + From especially the checks for the two separator forms it appears to + follow that the construct being touched is about trailing whitespace. In + such a case, considering that for many targets ordinary and line comment + chars overlap, take into account that line comment chars override + ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually + depends on that ordering, and also accounts for this overriding). + + Plus of course IS_NEWLINE() would better also be consulted. Note also + that the DOUBLESLASH_LINE_COMMENTS change should generally have no + effect just yet; it's a prereq for a later change but better fits here. + + Leave respective comments as well, and update documentation to correct + which comment form is actually replaced by a single blank (i.e. neither + the ones starting with what {,tc_}comment_chars[] has nor the ones + starting with what line_comment_chars[] has). + +2024-07-19 Jan Beulich + + gas: drop tic6x scrubber special case + Two successive PUT() without a state change in between can't be right: + The first PUT() may take the "goto tofull" path, leading to the + subsequent character being processed later in the previously set state + (1 in this case), rather than the state we were in upon entry to the + switch() (13 in this case). + + However, the original purpose of that logic appears to be to not mistake + "|| ^" for "||^". This effect, sadly, looks to not have been achieved. + Therefore drop the special case altogether; something that actually + achieves the (presumably) intended effect may then be introduced down + the road. + +2024-07-19 Jan Beulich + + gas: pre-init the scrubber's lex[] + While we can't - unlike an old comment suggests - do this fully, we can + certainly do part of this at compile time. + + Since it's adjacent, also drop the unnecessary forward declaration of + process_escape(). + +2024-07-19 Jan Beulich + + x86: accept whitespace inside curly braces + Other than documented /**/ comments currently aren't really converted to + a single space, at least not for x86 in its most common configurations. + That'll be fixed subsequently, at which point blanks may appear where so + far none were expected. Furthermore not permitting blanks immediately + inside curly braces wasn't quite logical anyway - such constructs are + composite ones, and hence components ought to have been permitted to be + separated by whitespace from the very beginning. + + With this we also don't care anymore whether the scrubber would remove + whitespace around curly braces, so move them from extra_symbol_chars[] + to operand_special_chars[]. + + Note: The new testcase doesn't actually exercise much (if any) of the + added code. It is being put in place to ensure that subsequently, when + that code actually comes into play, behavior remains the same. + +2024-07-19 Jan Beulich + + x86: undo '{' being a symbol-start character + Having it that way has undue side effects, in permitting not only + pseudo-prefixes to be parsed correctly, but also permitting odd symbol + names which ought to be possible only when quoted. Borrow what other + architectures do: Put in place an "unrecognized line" hook to parse off + any pseudo prefixes, while using the "start of line" hook to reject ones + not actually followed by an insn. For that parsing re-use parse_insn() + in yet a slightly different mode (dealing with only pseudo-prefixes). + + With that, pp may no longer be cleared from init_globals(), but instead + needs clearing after a line was fully processed. Since md_assemble() has + pretty many return paths, convert that into a local helper, with a + trivial wrapper around it. + + Similarly pp may no longer be updated (by check_register()) when + processing anything other than insn operands. To be able to (easily) + recognize the case, clear current_templates.start when done with an insn + (or with .insn). + +2024-07-19 Jan Beulich + + x86: split pseudo-prefix state from i386_insn + Subsequently we will want to update that ahead of md_assemble(), with + that function needing to take into account such earlier updating. + Therefore it'll want resetting separately from i. + +2024-07-19 Jan Beulich + + x86/APX: add CMPcc/CTESTcc cases to noreg64 tests + This was missed when support for the insns was added. Just like for + DATA16, in + + rex64 neg (%rax) + rex64 neg (%r16) + rex64 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the prefix. + +2024-07-19 zhangxianting + + bfin: free the allocated memory + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of multiplication macros + Provide 'mul' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split mul test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit multiplication macro verification, by + splitting the 'mul' test into two parts respectively, and run them + across all the compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the mul macro test across architectures + The multiplication macros expand differently based on the ISA chosen, so + run the 'mul' macro test across compatible architectures, adopting the + 'mul-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of division macros + Provide 'div' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split div test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit division macro verification, by splitting + the 'div' test into two parts respectively, and run them across all the + compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the div macro test across architectures + The division macros expand differently depending on the ISA selected, so + run the 'div' macro test across compatible architectures, adopting the + 'div-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS: Handle --trap command-line option dynamically + We have an ISA check for the '--trap' command-line option that reports + its incompatibility with the MIPS I architecture. It doesn't prevent + trap instructions from being enabled though, so when attempt is made to + emit one in an expansion of one of the division or multiplication macros + an assertion failure triggers: + + .../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages: + .../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1 + .../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero + .../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064. + Please report this bug. + + The same assertion failure triggers without an earlier error message + when the initial ISA is compatible with the '--trap', however at the + time an attempt is made to emit a trap instruction from a division or + multiplication macro the ISA has been changed by a '.set' pseudo-op to + an incompatible one. + + With the way the situations are mishandled it seems unlikely that anyone + relies on the current semantics and a sane approach is to decide on the + fly according to the currently selected ISA as to whether to emit trap + or breakpoint instructions in the case where '--trap' has been used. + + Change our code to do so then and clarify that in the manual, which is + not explicit about how '--trap' is handled with a changing ISA. Mention + the change in NEWS too since it's a applies to a user option. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Add R10000 CPU architecture + Add a fully interlocked MIPS IV CPU so that we can have coverage for + MIPS IV instruction sequences with and without instruction separation + required for a HI/LO data anti-dependency. + + MIPS/GAS/testsuite: Reorder R5900 CPU architecture definition + The R5900 CPU architecture is based on MIPS III, so move it ahead of + MIPS IV CPU architecture definitions. No functional change. + +2024-07-19 Indu Bhagat + + gas: aarch64: testsuite: add new tests for SCFI + Similar to the x86_64 testcases, some .s files contain the corresponding + CFI directives. This helps in validating the synthesized CFI by running + those tests with and without the --scfi=experimental command line + option. + + GAS issues some diagnostics, enabled by default, with + --scfi=experimental. The diagnostics have been added with an intent to + help user correct inadvertent errors in their hand-written asm. An + error is issued when GAS finds that input asm is not amenable to + accurate CFI synthesis. The existing scfi-diag-*.s tests in the + gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics + already: + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + - (#4) "Error: untraceable control flow for func 'XXX'" + + In the newly added aarch64 testsuite, further tests for additional + diagnostics have been added: + - scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic: + (#5) "Warning: SCFI: ignored probable save/restore op with reg offset" + + Additionally, some testcases are added to showcase the (currently) + unsupported patterns, e.g., scfi-unsupported-1.s + mov x16, 4384 + sub sp, sp, x16 + + gas/testsuite/: + * gas/scfi/README: Update comment to include aarch64. + * gas/scfi/aarch64/scfi-aarch64.exp: New file. + * gas/scfi/aarch64/ginsn-arith-1.l: New test. + * gas/scfi/aarch64/ginsn-arith-1.s: New test. + * gas/scfi/aarch64/ginsn-cofi-1.l: New test. + * gas/scfi/aarch64/ginsn-cofi-1.s: New test. + * gas/scfi/aarch64/ginsn-ldst-1.l: New test. + * gas/scfi/aarch64/ginsn-ldst-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test. + * gas/scfi/aarch64/scfi-cb-1.d: New test. + * gas/scfi/aarch64/scfi-cb-1.l: New test. + * gas/scfi/aarch64/scfi-cb-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-1.d: New test. + * gas/scfi/aarch64/scfi-cfg-1.l: New test. + * gas/scfi/aarch64/scfi-cfg-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-2.d: New test. + * gas/scfi/aarch64/scfi-cfg-2.l: New test. + * gas/scfi/aarch64/scfi-cfg-2.s: New test. + * gas/scfi/aarch64/scfi-cfg-3.d: New test. + * gas/scfi/aarch64/scfi-cfg-3.l: New test. + * gas/scfi/aarch64/scfi-cfg-3.s: New test. + * gas/scfi/aarch64/scfi-cfg-4.l: New test. + * gas/scfi/aarch64/scfi-cfg-4.s: New test. + * gas/scfi/aarch64/scfi-cond-br-1.d: New test. + * gas/scfi/aarch64/scfi-cond-br-1.l: New test. + * gas/scfi/aarch64/scfi-cond-br-1.s: New test. + * gas/scfi/aarch64/scfi-diag-1.l: New test. + * gas/scfi/aarch64/scfi-diag-1.s: New test. + * gas/scfi/aarch64/scfi-diag-2.l: New test. + * gas/scfi/aarch64/scfi-diag-2.s: New test. + * gas/scfi/aarch64/scfi-diag-3.l: New test. + * gas/scfi/aarch64/scfi-diag-3.s: New test. + * gas/scfi/aarch64/scfi-ldrp-1.d: New test. + * gas/scfi/aarch64/scfi-ldrp-1.l: New test. + * gas/scfi/aarch64/scfi-ldrp-1.s: New test. + * gas/scfi/aarch64/scfi-ldrp-2.d: New test. + * gas/scfi/aarch64/scfi-ldrp-2.l: New test. + * gas/scfi/aarch64/scfi-ldrp-2.s: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.d: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.l: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.s: New test. + * gas/scfi/aarch64/scfi-strp-1.d: New test. + * gas/scfi/aarch64/scfi-strp-1.l: New test. + * gas/scfi/aarch64/scfi-strp-1.s: New test. + * gas/scfi/aarch64/scfi-strp-2.d: New test. + * gas/scfi/aarch64/scfi-strp-2.l: New test. + * gas/scfi/aarch64/scfi-strp-2.s: New test. + * gas/scfi/aarch64/scfi-unsupported-1.l: New test. + * gas/scfi/aarch64/scfi-unsupported-1.s: New test. + * gas/scfi/aarch64/scfi-unsupported-2.l: New test. + * gas/scfi/aarch64/scfi-unsupported-2.s: New test. + +2024-07-19 Indu Bhagat + + gas: aarch64: add experimental support for SCFI + For synthesizing CFI (SCFI) for hand-written asm, the SCFI machinery in + GAS works on the generic GAS insns (ginsns). This patch adds support in + the aarch64 backend to create ginsns for a subset of the supported + machine instructions. The subset includes the minimal necessary + instructions to ensure SCFI correctness: + + - Any potential register saves and unsaves. Hence, process instructions + belonging to a variety of iclasses involving str, ldr, stp, ldp. + - Any change of flow instructions. This includes all conditional and + unconditional branches, call (bl, blr, etc.) and return. + - Most importantly, any instruction that could affect the two registers + of interest: REG_SP, REG_FP. This set includes all pre-indexed and + post-indexed memory operations, with writeback, on the stack. This + set must also include other instructions (e.g., arithmetic insns) + where the destination register is one of the afore-mentioned registers. + + With respect to callee-saved registers in Aarch64, FP/Advanced SIMD + registers D8-D15 are included along with the relevant GPRs. Calculating + offsets for loads and stores especially for Q registers needs special + attention here. + + As an example, + str q8, [sp, #16] + On big-endian: + STR Qn stores as a 128-bit integer (MSB first), hence, should record + D8 as being saved at sp+24 rather than sp+16. + On little-endian: + should record D8 as being saved at sp+16 + + D8-D15 are the low 64 bits of Q8-Q15, and of Z8-Z15 if SVE is used; + hence, they remain "interesting" for SCFI purposes in such cases. A CFI + save slot always represents the low 64 bits, regardless of whether a + save occurs on D, Q or Z registers. Currently, the ginsn creation + machinery can handle D and Q registers on little-endian and big-endian. + + Apart from creating ginsn, another key responsibility of the backend is + to make sure there are safeguards in place to detect and alert if an + instruction of interest may have been skipped. This is done via + aarch64_ginsn_unhandled () (similar to the x86 backend). This function + , hence, is also intended to alert when future ISA changes may otherwise + render SCFI results incorrect, because of missing ginsns for the newly + added machine instructions. + + At this time, becuase of the complexities wrt endianness in handling Z + register usage, skip sve_misc opclass altogether for now. The SCFI + machinery will error out (using the aarch64_ginsn_unhandled () code + path) though if Z register usage affects correctness. + + The current SCFI machinery does not currently synthesize the + PAC-related, aarch64-specific CFI directives: .cfi_b_key_frame. The + support for this is planned for near future. + + SCFI is enabled for ELF targets only. + + gas/ + * config/tc-aarch64-ginsn.c: New file. + * config/tc-aarch64.c (md_assemble): Include tc-aarch64-ginsn.c + file. Invoke aarch64_ginsn_new. + * config/tc-aarch64.h (TARGET_USE_GINSN): Define for SCFI + enablement. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): New definition. + (REG_FP): Likewise. + (REG_LR): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (aarch64_scfi_callee_saved_p): New declaration. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: enforce checks on subclass flags in aarch64-gen.c + Enforce some checks on the newly added subclass flags: + - If a subclass is set of one insn of an iclass, every insn of that + iclass must have non-zero subclass field. + - For all other iclasses, the subclass bits are zero for all insns. + + include/ + * opcode/aarch64.h (enum aarch64_insn_class): Identify the + maximum iclass enum value. + + opcodes/ + * aarch64-gen.c (iclass_has_subclasses_p): New array of bool. + (read_table): Enforce checks on subclass flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: denote subclasses for insns of iclass dp_2src + For detecting irg, add a subclass to identify it in the set of + instructions of iclass dp_2src. + + opcodes/ + * aarch64-tbl.h: Add subclass flag F_DP_TAG_ONLY for irg insn. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of uncond branches + Use the two new subclass flags: F_BRANCH_CALL, F_BRANCH_RET, to indicate + call to and return from subroutine respectively. + + opcodes/ + * aarch64-tbl.h: Use the new F_BRANCH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of arithmetic insns + Use the three new subclass flags: F_ARITH_ADD, F_ARITH_SUB, + F_ARITH_MOV, to indicate add, sub and mov ops respectively. + + These flags for subclasses will later be used for SCFI purposes to + create appropriate ginsns. At this time, only those iclasses relevant + to SCFI have the new subclass flags specified. + + For addg and subg insns, F_SUBCLASS_OTHER is more suitable because these + operations do more than just simple add or sub. + + opcodes/ + * aarch64-tbl.h: Use the new F_ARITH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of ldst insns + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass + of ldst_* is a load or a store. + + At the moment, specify subclasses for only those iclasses relevant to + SCFI: ldst_imm9, ldst_pos, ldstpair_indexed, ldstpair_off and + ldstnapair_offs. + + Some insns are best tagged with F_SUBCLASS_OTHER rather than F_LDST_LOAD + or F_LDST_STORE: + - stg* ops (as they store tag only), + - prfm, + - ldpsw, ldrsw (32-bit loads with signed extended value. Not useful + for restore operations in context of SCFI.) + - Use F_SUBCLASS_OTHER for all QL_LDST_R8 and QL_LDST_R16 operands. + Also use F_SUBLASS_OTHER for strb/ldrb, strh/ldrh opcodes. + These are not full loads and stores and cannot be allowed for + register save / restore for the purpose of SCFI. + + opcodes/ + * aarch64-tbl.h: Use the new F_LDST_* flags. + +2024-07-19 Indu Bhagat + + include: opcodes: aarch64: define new subclasses + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass of + ldst_* is a load or a store. Similarly, whether a particular arithmetic + insn is an add or sub or mov, etc. + + This patch defines new flags to demarcate the insns. Also provide an + access function for subclass lookup. + + Later, we will enforce (in aarch64-gen.c) that if an iclass has at least + one instruction with a non-zero subclass, all instructions of the iclass + must have a non-zero subclass information. If none of the defined + subclasses are applicable (or not required for SCFI purposes), + F_SUBCLASS_OTHER can be used for such instructions. + + include/ + * opcode/aarch64.h (F_SUBCLASS): New flag. + (F_SUBCLASS_OTHER): Likewise. + (F_LDST_LOAD): Likewise. + (F_LDST_STORE): Likewise. + (F_ARITH_ADD): Likewise. + (F_ARITH_SUB): Likewise. + (F_ARITH_MOV): Likewise. + (F_BRANCH_CALL): Likewise. + (F_BRANCH_RET): Likewise. + (F_DP_TAG_ONLY): Likewise. + (aarch64_opcode_subclass_p): New definition. + +2024-07-19 Indu Bhagat + + gas: scfi: make scfi_state_restore_reg function more precise + When the SCFI machinery detects that a register has been restored from + stack, it makes some state changes in the SCFI state object. + + Prior to the patch, scfi_state_restore_reg () was setting a value of + (reg, CFI_IN_REG) for (base, state) respectively. This was causing + issues in the cmp_scfi_state () function: + - The default state of all (callee-saved) regs at the beginning of + function is set to (0, CFI_UNDEFINED). + - If a register is saved and restored on some control path, the state + of reg is (reg, CFI_IN_REG) on that path. + - On another control path where the register was perhaps not + used (or saved/restored on stack) remains (0, CFI_UNDEFINED). + - The two states should be treated equal, however, at the point in + program after the register has been restored. + + Fix this by resetting the state to (0, CFI_UNDEFINED) in + scfi_state_restore_reg (). + + A testcase (scfi-cfg-4.s) for this is added in a subsequent commit. + + gas/ + * scfi.c (scfi_state_restore_reg): Reset to 0, CFI_UNDEFINED + for base, state. + +2024-07-19 GDB Administrator + + Automatic date update in version.in + +2024-07-18 Matthieu Longo + + gas: minor reformatting in command line help and doc + - help message: add a comma between the short and long option + - as doc: + - brief summary of how to invoke gas: separate [-w] [-x] on a new line as those + two options have nothing to do with the warning options. + - reordering of the warning options to have the same order as the listing. + - no-warn option description: change an "and" to a "or", as it is either the short + or long option to use, but not both at the same time. + - remove trailing whitespaces. + +2024-07-18 Andrew Burgess + + gdb: check for multiple matching build-id files + Within the debug-file-directory GDB looks for the existence of a + .build-id directory. + + Within the .build-id directory GDB looks for files with the form: + + .build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug + + which contain the debug information for the objfile with the build-id + ff4b4142d62b399499844924d53e33d4028380db. + + There appear to be two strategies for populating the .build-id + directory. Ubuntu takes the approach of placing the actual debug + information in this directory, so + 4b4142d62b399499844924d53e33d4028380db.debug is an actual file + containing the debug information. + + Fedora, RHEL, and SUSE take a slightly different approach, placing the + debug information elsewhere, and then creating symlinks in the + .build-id directory back to the original debug information file. The + actual debug information is arranged in a mirror of the filesystem + within the debug directory, as an example, if the debug-file-directory + is /usr/lib/debug, then the debug information for /bin/foo can be + found in /usr/lib/debug/bin/foo.debug. + + Where this gets interesting is that in some cases a package will + install a single binary with multiple names, in this case a single + binary will be install with either hard-links, or symlinks providing + the alternative names. + + The debug information for these multiple binaries will then be placed + into the /usr/lib/debug/ tree, and again, links are created so a + single file can provide debug information for each of the names that + binary presents as. An example file system might look like this (the + [link] could be symlinks, but are more likely hard-links): + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + + In the .build-id tree though we have a problem. Do we have a single + entry that links to one of the .debug files? This would work; a user + debugging any of the binaries will find the debug information based on + the build-id, and will get the correct information, after all the + .debug files are identical (same file linked together). But there is + one problem with this approach. + + Sometimes, for *reasons* it's possible that one or more the linked + binaries might get removed, along with its associated debug + information. I'm honestly not 100% certain under what circumstances + this can happen, but what I observe is that sometime a single name for + a binary, and its corresponding .debug entry, can be missing. If this + happens to be the entry that the .build-id link is pointing at, then + we have a problem. The user can no longer find the debug information + based on the .build-id link. + + The solution that Fedora, RHEL, & SUSE have adopted is to add multiple + entries in the .build-id tree, with each entry pointing to a different + name within the debug/ tree, a sequence number is added to the + build-id to distinguish the multiple entries. Thus, we might end up + with a layout like this: + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + .build-id/ + a3/ + 4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ] + + With current master GDB, debug information will only ever be looked up + via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if + 'foo' and its corresponding 'foo.debug' are ever removed, then master + GDB will fail to find the debug information. + + Ubuntu seems to have a much better approach for debug information + handling; they place the debug information directly into the .build-id + tree, so there only ever needs to be a single entry for any one + build-id. I wonder if/how they handle the case where multiple names + might share a single .debug file, if one of those names is then + uninstalled, how do they know the .debug file should be retained or + not ... but I assume that problem either doesn't exist or has been + solved. + + Anyway, for a while Fedora has carried a patch that handles the + build-id sequence number logic. What's presented here is inspired by + the Fedora patch, but has some changes to fix some issues. + + I'm aware that this is a patch that applies to only some (probably a + minority) of distros. However, the logic is contained to only a + single function in build-id.c, and isn't too complex, so I'm hoping + that there wont be too many objections. + + For distros that don't have build-id sequence numbers there should be + no impact. The sequence number approach still leaves the first file + without a sequence number, and this is the first file that GDB (after + this patch) checks for. The new logic only kicks in if the + non-sequence numbered first file exists, but is a symlink to a non + existent file; in this case GDB checks for the sequence numbered files + instead. + + Tests are included. + + There is a small fix needed for gdb.base/sysroot-debug-lookup.exp, + after this commit GDB now treats a target: sysroot where the target + file system is local to GDB the same as if the sysroot had no target: + prefix. The consequence of this is that GDB now resolves a symlink + back to the real filename in the sysroot-debug-lookup.exp test where + it didn't previously. As this behaviour is inline with the case where + there is no target: prefix I think this is fine. + +2024-07-18 Andrew Burgess + + gdbserver: add gdbserver support for vFile::stat packet + After the previous two commits, this commit adds support for the + vFile::stat packet to gdbserver. This is pretty similar to the + handling for vFile::fstat, but instead calls 'lstat'. + + There's still no users of target_fileio_stat in GDB, that will come in + a later commit. + +2024-07-18 Andrew Burgess + + gdb: add GDB side target_ops::fileio_stat implementation + This commit adds the GDB side of target_ops::fileio_stat. There's an + implementation for inf_child_target, which just calls 'lstat', and + there's an implementation for remote_target, which sends a new + vFile:stat packet. + + The new packet is documented. + + There's still no users of target_fileio_stat as I have not yet added + support for vFile::stat to gdbserver. If these packets are currently + sent to gdbserver then they will be reported as not supported and the + ENOSYS error code will be returned. + + Reviewed-By: Eli Zaretskii + +2024-07-18 Andrew Burgess + + gdb: add target_fileio_stat, but no implementations yet + In a later commit I want target_fileio_stat, that is a call that + operates on a filename rather than an open file descriptor as + target_fileio_fstat does. + + This commit adds the initial framework for target_fileio_stat, I've + added the top level target function and the virtual target_ops methods + in the target_ops base class. + + At this point no actual targets override target_ops::fileio_stat, so + any attempts to call this function will return ENOSYS error code. + +2024-07-18 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Added "APX_F is fully supportted" to gas/NEWS. + +2024-07-18 GDB Administrator + + Automatic date update in version.in + +2024-07-17 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-pseudo-unwind.exp with unix/mthumb + When running test-case gdb.arch/arm-pseudo-unwind.exp with target board + unix/mthumb, we run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Program received signal SIGILL, Illegal instruction.^M + 0x00400f38 in ?? ()^M + (gdb) FAIL: $exp: continue to breakpoint: continue to callee + ... + + The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode + using additional_flags=-marm, but that's overridden by using target board + unix/mthumb. + + This causes function main to be in thumb mode, and consequently function + caller (which is called from main) is is executed as if it's in thumb mode, + while it's actually in arm mode. + + Fix this by adding an intermediate function caller_trampoline in + arm-pseudo-unwind.c, and hardcoding it to arm mode using + __attribute__((target("arm"))). + + Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp. + + Tested on arm-linux. + + Approved-By: Luis Machado + +2024-07-17 Indu Bhagat + + gas: scfi: testsuite: refresh the README + Update some stale text in the README. Add few more notes to guide + future maintenance of the testsuite. + + gas/testsuite/ + * gas/scfi/README: Update text. + +2024-07-17 GDB Administrator + + Automatic date update in version.in + +2024-07-16 Simon Marchi + + gdb, gdbserver, gdbsupport: use [[noreturn]] instead of ATTRIBUTE_NORETURN + C++ 11 has a built-in attribute for this, no need to use a compat macro. + + Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875 + Reviewed-by: Lancelot Six + +2024-07-16 Simon Marchi + + gdb: fix indentation in remote.c + Change-Id: If344acdf703fdd3892f73f75fc891d5473808b79 + +2024-07-16 Simon Marchi + + gdb: add ATTRIBUTE_NORETURN to remote_unpush_target + My IDE (well, clangd) suggested this. It doesn't hurt to have it. + + Change-Id: If6001983c17dbed3dceebac3078c8deb12c04d6b + +2024-07-16 Tom de Vries + + [gdb/testsuite] Simplify gdb.base/complex-parts.exp + I noticed a lot of escaping in test-case gdb.base/complex-parts.exp. + + Make the test-case more readable by using: + - string_to_regexp, and + - {} instead of "". + + Tested on x86_64-linux and aarch64-linux. + +2024-07-16 GDB Administrator + + Automatic date update in version.in + +2024-07-15 Simon Marchi + + gdb: pass program space to overlay_invalidate_all + Make the current program space bubble up one level. + + Change-Id: I5ac1e3290ad266730465cd60aa3672d45ffa6475 + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::make + Make the current program space reference bubble up one level. + + Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::objfile + Make the current program space reference bubble up one level. + + Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address + Make the current program space reference bubble up one level. + + Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address_query + Make the current program space bubble up one level. + + Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfiles_changed + Make the current program space reference bubble up one level. + + Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to get_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to have_{full,partial}_symbols + Make the current program space reference bubble up one level. + + Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: bool-ify a few functions in objfiles.{c,h} + Change return types to bool, and make a few stylistic adjustments. + + Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to clear_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: make `program_space::free_all_objfiles` use `this` + Use `this` instead of `current_program_space`. Presumably, the method + wants to check the solibs of "this" program space, not the current + global program space (although they are likely always the same at the + moment). + + Change-Id: Iaf0534f36bfd47c04c53ed0657da332bdb8fb906 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to no_shared_libraries + Make the current program space reference bubble up one level. Pass + `current_program_space` everywhere, except in some cases where we can + get the pspace another way, and it's relatively obvious that it's the + same as the current program space. + + Change-Id: Id86b79f1e44f92a398f49d137d57457174dfa96d + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: split no_shared_libraries, command vs implementation + The `no_shared_libraries` function is currently used to implement the + `nosharedlibrary` command, but it also used internally by other + functions. This does not make a very good internal API. + + Add the `no_shared_libraries_command` function to implement the CLI + command. Remove the unused parameters from `no_shared_libraries`. + + Remove the `from_tty` parameter of `target_pre_inferior`, since it's now + unused. + + Change-Id: I4fcba5ee1e0f7d250aab1a7b62b9ea16265fe962 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile_purge_solibs + Make the current program space reference bubble up one level. + + Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: use objfile::pspace in objfile::unlink + I think it would make sense to use objfile::pspace instead of the + current program space here. It reduces the risks of calling this + method with the wrong current program space set. + + Change-Id: Id4f3644719f232640c83a1c7f4aa92eaa6af6c5c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: remove some trivial uses of current_program_space + It is obvious that pspace is the same as current_program_space in these + cases, due to the set_current_program_space call just above. The rest + of the functions probably care about the current program space though, + so leave the set_cset_current_program_space calls there. + + Change-Id: I3c300decbf2c2fe5f25aa7f697ebcb524432394f + +2024-07-15 Hannes Domani + + Fix loading a saved recording + Currently you get this assertion failure if you try to execute the + inferior after loading a saved recording, when no recording was done + earlier in the same gdb session: + ``` + $ gdb -q c -ex "record restore test.rec" + Reading symbols from c... + [New LWP 26428] + Core was generated by `/tmp/c'. + Restored records from core file /tmp/test.rec. + (gdb) c + Continuing. + ../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ``` + + The change in step-precsave.exp triggers this bug, since now the + recording is loaded in a new gdb session, where + record_full_resume_ptid was never set. + + The fix is to simply set record_full_resume_ptid when resuming a loaded + recording. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971 + Approved-By: Guinevere Larsen + +2024-07-15 Simon Marchi + + gdb: make objfile::pspace private + Rename to m_pspace, add getter. An objfile's pspace never changes, so + no setter is necessary. + + Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626 + +2024-07-15 Szabolcs Nagy + + aarch64: Fix --no-apply-dynamic-relocs for RELR + The option only makes sense for RELA relative relocs where the + addend is present, not for RELR relative relocs. + + Fixes bug 31924. + +2024-07-15 Nick Clifton + + Synchronize config.[sub|guess] with the latest versions from the config project. + +2024-07-15 GDB Administrator + + Automatic date update in version.in + +2024-07-14 John David Anglin + + hppa: Fix handling of relocations that apply to data + Commit d125f9675372b1ae01ceb1893c06ccb27bc7bf22 introduced a bug + in handling relocations for data. The R_PARISC_DIR32 relocation + operates on 32-bit data and not instructions. The HOWTO table + needs to be used to determine the format of relocations that apply + to data. The R_PARISC_SEGBASE relocation is another special case + as it only changes segment base. + + This was noticed in Debian cmor package build. + + 2024-07-14 John David Anglin + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Use HOWTO table to + determine reload format for relocations that apply to data. + +2024-07-14 GDB Administrator + + Automatic date update in version.in + +2024-07-13 Maciej W. Rozycki + + Revert "MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64" + This reverts commit d49f2dd78b08efa4e1ee51f5df5058846c2eb4fa. It was + applied unapproved. + + Revert "MIPS/GAS: Omit LI 0 for condition trap" + This reverts commit bfa257b407270d1c808b31fbd97da779e0fd20d2. It was + applied unapproved. + +2024-07-13 Lulu Cai + + LoongArch: Fix dwarf3 test cases from XPASS to PASS + In the past, the .align directive generated a label that did not match + the regular expression, and we set it to XFAIL. + But now it matches fine so it becomes XPASS. We fix it with PASS. + +2024-07-13 GDB Administrator + + Automatic date update in version.in + +2024-07-12 Sam James + + libiberty: sync with gcc + This imports the following commits from GCC as of r15-1722-g7682d115402743: + ca2f7c84927f libiberty: Invoke D demangler when --format=auto + 94792057ad4a Fix up duplicated words mostly in comments, part 1 + 20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957]. + 52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen + 53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size + 65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal + +2024-07-12 Jens Remus + + s390: Avoid reloc overflows on undefined weak symbols (cont) + This complements and reuses logic from Andreas Krebbel's commit + 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols"). + + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0 or a + a trapping insn. + + This prevents the PLT32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative + addressing to avoid relocation overflows. + + ld/ + * testsuite/ld-s390/s390.exp: Add new test. + * testsuite/ld-s390/weakundef-2.s: New test. + * testsuite/ld-s390/weakundef-2.dd: Likewise. + + Reported-by: Alexander Gordeev + Suggested-by: Ilya Leoshkevich + Suggested-by: Andreas Krebbel + +2024-07-12 Jens Remus + + s390: Do not replace brcth referencing undefined weak symbol + Branch Relative on Count High (brcth) is a conditional branch relative + instruction. It is not guaranteed that it only appears within loops + that sooner or later will take the branch. It may very well be used to + check a condition that will prevent the branch from ever being taken. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Do not replace brcth + referencing undefined weak symbol with a trap. + + ld/ + * testsuite/ld-s390/weakundef-1.s: Update test case accordingly. + * testsuite/ld-s390/weakundef-1.dd: Likewise. + + Fixes: 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols") + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 zero instructions. + This patch adds support for following sme2.1 zero instructions and + the spec is available here [1]. + + 1. ZERO (single-vector). + 2. ZERO (double-vector). + 3. ZERO (quad-vector). + + The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler + for most of the sme and sve instructions. But for few of the sme2.1 + zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory. + To address this a bit "F_VG_REQ" is introduced in this patch, on setting + F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept + instruction operand only having VECTOR GROUP symbols. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 movaz instructions. + This patch adds support for following sme2.1 movaz instructions and + the spec is available here [1]. + + 1. MOVAZ (array to vector, two registers). + 2. MOVAZ (array to vector, four registers). + 3. MOVAZ (tile to vector, single). + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 luti2 and luti4 instructions. + This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is + available here [1] + + 1. LUTI2 (two registers) strided. + 2. LUTI2 (four registers) strided. + 3. LUTI4 (two registers) strided. + 4. LUTI4 (four registers) strided. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Jan Beulich + + x86: drop unnecessary \() from bundle tests + ':' isn't permitted in macro parameter names, hence this separator + construct isn't necessary at the end of labels. Drop its use in such + cases, for being potentially confusing (and hampering readability, even + if only a little). + +2024-07-12 Jan Beulich + + x86/APX: remove two inconsistencies + As indicated in earlier discussion, permitting GOTTPOFF uniformly for + all legacy non-SIMD insns while at the same time restricting to just + certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns + "equal" to their legacy original ones. Doing that adjustment prevents + another inconsistency, too: In + + data16 neg (%rax) + data16 neg (%r16) + data16 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the data size prefix. + + While there also add the missing CMP and TEST cases to the test case + being modified. + +2024-07-12 Jan Beulich + + x86/APX: correct TEST/CTESTcc with 1st operand being a memory one + While they properly inherited D and C, code processing the reversal of + operands wasn't updated accordingly (and "reversed" operands also + weren't tested anywhere). + +2024-07-12 YunQiang Su + + MIPS/GAS: Omit LI 0 for condition trap + MIPSr6 removes condition trap instructions with imm, so we expand + the instruction like "tne $2,IMM" to + li $at,IMM + tne $2,$at + While if IMM is 0, we can use + tne $2,$zero + only. + +2024-07-12 YunQiang Su + + MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64 + the ABI section of the triple explicitly asks for N64, + and in fact GCC also does so. + + It can fix the test failure: + FAIL: libdep test: did not get expected output from the linker + with Debian's mipsisa64r6el-linux-gnuabi64 toolchain. + +2024-07-12 Matthieu Longo + + aarch64: disable feature b16b16 + Feature b16b16 is currently incomplete and requires re-work. + + Disable the command line option for b16b16, and mark the associated + tests as XFAIL. + +2024-07-12 Vladimir Mezentsev + + gprofng: add release notes for 2.43 + ChangeLog + 2024-07-10 Vladimir Mezentsev . + + * binutils/NEWS (gprofng): Add release notes for 2.43 + +2024-07-12 Alan Modra + + Re: base64: Add support for targets with byte size > octet size. + Three extra octets are now expected with the latest change to base64.s. + They happened to be covered by patterns allowing for zero padding at + the end of the section, but we don't want to allow fewer octets than + expected. + + PR 31964 + * testsuite/gas/all/base64.d: Adjust. + +2024-07-12 GDB Administrator + + Automatic date update in version.in + +2024-07-11 Nick Clifton + + base64: Add support for targets with byte size > octet size. + PR 31964 + +2024-07-11 Jan Beulich + + gas: don't open-code IS_WHITESPACE() / IS_NEWLINE() + Better be consistent in use of the wrapper macros, which imo also helps + readability. + +2024-07-11 Jan Beulich + + gas: multi-byte warning adjustments + First input_scrub_next_buffer()'s invocation was wrong, leading to input + only being checked from the last newline till the end of the current + buffer. Correcting the invocation, however, leads to duplicate checking + unless -f (or the #NO_APP equivalent thereof) is in effect. Move the + invocation to input_file_give_next_buffer(), to restrict it accordingly. + + Then, when macros contain multi-byte characters, warning about them + again in every expansion isn't useful. Suppress such warnings from + sb_scrub_and_add_sb(). + +2024-07-11 Jan Beulich + + gas: there's no scrubber state 12 + Apparently (beyond what's [easily] visible in git history) when this was + added there was confusion about scrubber states vs lex[] contents. For + the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve + to 12) alone is sufficient. "state" is never set to 12, and it being 12 + also isn't handled anywhere. + +2024-07-11 Kévin Le Gouguec + + gdb: add testcase for invalid record display + More of a DWARF-generation non-regression test; fixed on the GCC side + with 2024-06-03 "Implement wrap-around arithmetics in DWARF + expressions" (f3d6d60d2ae). + + Approved-By: Tom Tromey + +2024-07-11 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Update gas/NEWS for Intel APX. + +2024-07-11 Tsukasa OI + + RISC-V: Add platform property/capability extensions + RISC-V Profiles document defines number of "extensions" that indicate + certain platform properties/capabilities just like 'Zkt' extension from the + RISC-V cryptography extensions. + + This commit defines 20 platform property/capability extensions as defined + in the RISC-V Profiles documentation. + + The only exception: 'Ssstateen' extension is defined separately because it + defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension. + + This is based on the ratified version of RISC-V Profiles: + + + [Definition] + + "Main memory regions": + Main memory regions (in contrast to I/O or vacant memory regions) with + both the cacheability and coherence PMAs. + + [New Unprivileged Extensions] + + 1. 'Ziccif' + "Main memory regions" support instruction fetch and any instruction + fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN) + are atomic. + 2. 'Ziccrse' + "Main memory regions" provide the eventual success guarantee for + LR/SC sequence (RsrvEventual). + 3. 'Ziccamoa' + "Main memory regions" support all currently-defined AMO operations + including swap, logical and arithmetic operations (AMOArithmetic). + 4. 'Za64rs' + For LR/SC instructions, reservation sets are contiguous, naturally + aligned and at most 64-bytes in size. + 5. 'Za128rs' + Likewise, but reservation sets are at most 128-bytes in size. + 6. 'Zicclsm' + Misaligned loads / stores to "main memory regions" are supported. + Those include both regular scalar and vector accesses but does not + include AMOs and other specialized forms of memory accesses. + 7. 'Zic64b' + Cache blocks are (exactly) 64-bytes in size and naturally aligned. + + [New Privileged Extensions] + + 1. 'Svbare' + "satp" mode Bare is supported. + 2. 'Svade' + Page-fault exceptions are raised when a page is accessed when A bit is + clear, or written when D bit is clear. + 3. 'Ssccptr' + "Main memory regions" support hardware page-table reads. + 4. 'Sstvecd' + "stvec" mode Direct is supported. When "stvec" mode is Direct, + "stvec.BASE" is capable of holding any valid 4-byte aligned address. + 5. 'Sstvala' + "stval" is always written with a nonzero value whenever possible as + specified in the Privileged Architecture documentation + (version 20211203: see section 4.1.9). + 6. 'Sscounterenw' + For any "hpmcounter" that is not read-only zero, the corresponding bit + in "scounteren" is writable. + 7. 'Ssu64xl' + "sstatus.UXL" is capable of holding the value 0b10 + (UXLEN==64 is supported). + 8. 'Shcounterenw' + Similar to 'Sscounterenw' but the same rule applies to "hcounteren". + 9. 'Shvstvala' + Similar to 'Sstvala' but the same rule applies to "vstval". + 10. 'Shtvala' + "htval" is written with the faulting guest physical address as long as + permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala'). + 11. 'Shvstvecd' + Similar to 'Sstvecd' but the same rule applies to "vstvec". + 12. 'Shvsatpa' + All translation modes supported in "satp" are also supported in "vsatp". + 13. 'Shgatpa' + For each supported virtual memory scheme SvNN supported in "satp", the + corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare + is also supported. + + [Implications] + + (Due to reservation set size constraints) + - 'Za64rs' -> 'Za128rs' + + (Due to the fact that a privileged "extension" directly refers a CSR) + - 'Svbare' -> 'Zicsr' + - 'Sstvecd' -> 'Zicsr' + - 'Sstvala' -> 'Zicsr' + - 'Sscounterenw' -> 'Zicsr' + - 'Ssu64xl' -> 'Zicsr' + + (Due to the fact that a privileged "extension" indirectly depends on CSRs) + - 'Svade' -> 'Zicsr' + + (Due to the fact that a privileged "extension" is a hypervisor property) + - 'Shcounterenw' -> 'H' + - 'Shvstvala' -> 'H' + - 'Shtvala' -> 'H' + - 'Shvstvecd' -> 'H' + - 'Shvsatpa' -> 'H' + - 'Shgatpa' -> 'H' + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Updated for property + and capability extensions. + (riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm, + ziccrse, za64rs and za128rs extensions. + (riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala, + shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala, + sstvecd, ssu64xlm svade and svbare extensions. + gas/ + * testsuite/gas/riscv/imply.d: Updated for property and capability + extensions. + * testsuite/gas/riscv/imply.s: Likewise. + * testsuite/gas/riscv/march-help.l: Likewse. + +2024-07-11 Alan Modra + + Re: Add support for a .base64 pseudo-op to gas + Fixes a failure on rx-elf where the standard data section isn't .data. + run_dump_test has machinery to translate .data in both options and + expected results for objdump, but not for readelf -x. + + PR 31964 + * testsuite/gas/all/base64.d: Dump .data with objdump. Run on + all targets. + +2024-07-11 Jinyang He + + LoongArch: Not alloc dynamic relocs if symbol is absolute + The absolute symbol should be resolved to const when link to dso or exe. + Alloc dynamic relocs will cause extra space and R_LARCH_NONE finally. + +2024-07-11 GDB Administrator + + Automatic date update in version.in + +2024-07-11 H.J. Lu + + x86-64: Skip -z mark-plt tests on MUSL + Skip -z mark-plt tests, which are specific to glibc, on MUSL. + + PR ld/31970 + * ld/testsuite/ld-x86-64/x86-64.exp: Skip -z mark-plt tests on + MUSL. + +2024-07-10 Yixuan Chen + + RISC-V:[gprofng] Minimal support gprofng for riscv. + ChangeLog: Add target riscv to --enable-gprofng. + + 2024-07-04 Yixuan Chen + + * configure: Add riscv. + * configure.ac: Add riscv. + + gprofng/ChangeLog: Minimal support gprofng for riscv. + + 2024-07-04 Yixuan Chen + + * gprofng/common/core_pcbe.c (core_pcbe_init): Add RISC-V vendor conditon. + (defined): Add riscv. + * gprofng/common/cpuid.c (defined): Add risc-v hwprobe. + * gprofng/common/gp-defs.h (TOK_A_RISCV): Add riscv. + (defined): Add riscv. + (ARCH_RISCV): Add riscv. + * gprofng/common/hwc_cpus.h: Add RISC-V vendor. + * gprofng/common/hwcfuncs.h (HW_INTERVAL_TYPE): Remove useless defination. + * gprofng/configure: Add riscv. + * gprofng/configure.ac: Add riscv. + * gprofng/libcollector/hwprofile.h (ARCH): Add RISC-V register. + (CONTEXT_PC): Add RISC-V register. + (CONTEXT_FP): Add RISC-V register. + (CONTEXT_SP): Add RISC-V register. + (SETFUNCTIONCONTEXT): + * gprofng/libcollector/libcol_util.c (__collector_util_init): Fix libc open condition. + * gprofng/libcollector/libcol_util.h (ARCH): Add RISC-V. + * gprofng/libcollector/unwind.c (ARCH): Add RISC-V register. + (GET_PC): Add RISC-V register. + (GET_SP): Add RISC-V register. + (GET_FP): Add RISC-V register. + (FILL_CONTEXT): + * gprofng/src/DbeSession.cc (ARCH): Add RISC-V. + * gprofng/src/Disasm.cc (Disasm::disasm_open): Add RISC-V. + * gprofng/src/Experiment.cc (Experiment::ExperimentHandler::startElement): Add RISC-V. + * gprofng/src/checks.cc (ARCH): Add RISC-V. + * gprofng/src/collctrl.cc (defined): Set risc-v cpu frequency to 1000MHz as default for now, will fix when I find a better method to get cpu frequency. + (read_cpuinfo): Add "mvendorid" condition according to risc-v /proc/cpuinfo file content. + * gprofng/src/dbe_types.h (enum Platform_t): Add RISC-V. + +2024-07-10 Nick Clifton + + Add support for a .base64 pseudo-op to gas + PR 31964 + +2024-07-10 Clément Chigot + + libsframe: remove runstatedir in Makefile.in + The regeneration was made with Ubuntu automake which has this runstatedir + additional variable, compared to the usual automake. + + libsframe: accept --target configure option + Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was + ignored. This could prevent libsframe.a to be installed in some cases, + the host fetching its canonical value while the target isn't. Both + having a different value, INSTALL_LIBBFD would be false. + +2024-07-10 GDB Administrator + + Automatic date update in version.in + +2024-07-09 H.J. Lu + + elf: Add glibc version dependency only if needed + There is no need to add a needed glibc version if the glibc base version + includes the needed glibc version. + + PR ld/31966 + * elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base. + Skip if the glibc base version includes the needed glibc version. + (_bfd_elf_link_add_glibc_version_dependency): Initialize + glibc_minor_base to INT_MAX and pass it to + elf_link_add_glibc_verneed. + +2024-07-09 Vladimir Mezentsev + + gprofng: add hardware counters for Intel Ice Lake processor + gprofng/ChangeLog + 2024-07-07 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Intel Ice Lake processor. + * common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel. + Set config1 in perf_event_attr. Remove the use of memset. + * common/core_pcbe.c (core_pcbe_get_eventnum): Return 0. + * common/hwcentry.h: Add config1. + * src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1. + * common/hwcfuncs.c (process_data_descriptor): Set config1. + * common/hwctable.c: Add the hwc table for Intel Ice Lake processor. + * src/hwc_intel_icelake.h: New file. + +2024-07-09 Indu Bhagat + + doc: sframe: add appendix for generating stack traces + Add an appendix to provide a rough outline to show how to generate stack + traces using the SFrame format. Such content should hopefully aid the + reader assimmilate the information in the specification. + + libsframe/ + * doc/sframe-spec.texi: Add new appendix. + +2024-07-09 Indu Bhagat + + include: sframe: update code comments around SFrame FRE stack offsets + This also amends the incorrect comment: + offset3 (intrepreted as FP = CFA + offset2) + + If RA tracking is enabled, the offset to recover FP is at the third + index. The SFrame format (V2) has assumption that if FP is saved on + stack, RA must have been saved as well. This is true for the currently + supported arch Aarch64. For AMD64, RA tracking per SFrame FRE is not + necessary. + + In future, when extending support for more architectures, this will + likely need to be revisited. + + include/ + * sframe.h: Make the comments clearer by enumerating what + happens per-ABI. + +2024-07-09 Indu Bhagat + + doc: sframe: segregate the ABI/arch-specific components + The recipe to interpret the SFrame FRE stack offsets is + ABI/arch-specific. + + Although, there is other information in the specification that is + ABI-specific (like pauth_key usage in AArch64), those pieces of + information are now assimmilated in the SFrame specification in a way + that it is fairly difficult to carve then out into a ABI/arch-specific + section without confusing the readers. + + For future though, the specification must strive to keep the generic + parts and ABI/arch-specific parts clearly laid out in separate sections. + + libsframe/ + * doc/sframe-spec.texi: Reorder and adapt the contents. + +2024-07-09 H.J. Lu + + LTO: Properly check wrapper symbol + Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper + symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO. + + Note: Calling unwrap_hash_lookup to check for the wrapper symbol works + only when there is a definition for the wrapped symbol since references + to the wrapped symbol have been redirected to the wrapper symbol. + + bfd/ + + PR ld/31956 + * linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol + for wrapper symbol. + + include/ + + PR ld/31956 + * bfdlink.h (bfd_link_hash_entry): Add wrapper_symbol. + + ld/ + + PR ld/31956 + * plugin.c (get_symbols): Set wrap_status to wrapper if + wrapper_symbol is set. + * testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests. + * testsuite/ld-plugin/pr31956a.c: New file. + * testsuite/ld-plugin/pr31956b.c: Likewise. + +2024-07-09 GDB Administrator + + Automatic date update in version.in + +2024-07-08 srinath + + aarch64: Add support for sve2p1 pmov instruction. + This patch adds support for followign SVE2p1 instruction, spec is available here [1]. + + 1. PMOV (to vector) + 2. PMOV (to predicate) + + Both pmov (to vector) and pmov (to predicate) have destination scalable vector + register and source scalable vector register respectively as an operand with no + suffix and optional index. To handle this case we have added 8 new operands in + this patch. + + AARCH64_OPND_SVE_Zn0_INDEX, /* Zn[index], bits [9:5]. */ + AARCH64_OPND_SVE_Zn1_17_INDEX, /* Zn[index], bits [9:5,17]. */ + AARCH64_OPND_SVE_Zn2_18_INDEX, /* Zn[index], bits [9:5,18:17]. */ + AARCH64_OPND_SVE_Zn3_22_INDEX, /* Zn[index], bits [9:5,18:17,22]. */ + AARCH64_OPND_SVE_Zd0_INDEX, /* Zn[index], bits [4:0]. */ + AARCH64_OPND_SVE_Zd1_17_INDEX, /* Zn[index], bits [4:0,17]. */ + AARCH64_OPND_SVE_Zd2_18_INDEX, /* Zn[index], bits [4:0,18:17]. */ + AARCH64_OPND_SVE_Zd3_22_INDEX, /* Zn[index], bits [4:0,18:17,22]. */ + + Since the index of the operand is optional, the index part is + dropped in disassembly in both the cases of "no index" or "zero index". + + As per spec: PMOV {[]}, .D + PMOV .D, {[]} + + Example1: + Assembly: pmov z5[0], p6.d + Disassembly: pmov z5, p6.d + + Assembly: pmov z5, p6.d + Disassembly: pmov z5, p6.d + + Example2: + Assembly: pmov p4.b, z5[0] + Disassembly: pmov p4.b, z5 + + Assembly: pmov p4.b, z5 + Disassembly: pmov p4.b, z5 + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 Srinath Parvathaneni + + aarch64: Add support for sve2p1 tbxq instruction. + This patch adds support for SVE2p1 "tbxq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 zipq[1-2] instructions. + This patch adds support for SVE2p1 "zipq1" and "zipq2" instructions, spec is + available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 uzpq[1-2] instructions. + This patch adds support for SVE2p1 "uzpq1" and "uzpq2" instructions, spec is + available here [1] + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 tblq instruction. + This patch adds support for SVE2p1 "tblq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 orqv instruction. + This patch adds support for SVE2p1 "orqv" instruction, spec available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 GDB Administrator + + Automatic date update in version.in + +2024-07-07 GDB Administrator + + Automatic date update in version.in + +2024-07-06 Alan Modra + + Re: LoongArch: Add DT_RELR support + Fix commit d89ecf33ab testsuite breakage. + + * testsuite/lib/binutils-common.exp (supports_dt_relr): Correct. + +2024-07-06 Alan Modra + + objcopy bfd_map_over_sections and global status + This patch started life as a relatively simple change to fix some + unimportant objcopy memory leaks, but expanded into a larger patch + when I was annoyed by the awkwardness of passing data when using + bfd_map_over_sections. A simple loop over sections is much more + convenient, and we really don't need the abstraction layer. Sections + in a list isn't going to disappear any time soon. + + The patch also removes use of the global "status" variable by all but + the top-level functions called from main. + + * objcopy.c (filter_symbols): Return success as a bool. Pass + symcount as a pointer, updated on return. + (merge_gnu_build_notes): Similarly return a bool and add newsize + param with updated smaller section size. + (setup_bfd_headers): Return bool success rather than setting + "status" on failure. + (setup_section): Likewise. + (copy_relocations_in_section, copy_section): Likewise, and adjust + params. + (mark_symbols_used_in_relocations): Likewise, and free memory + on failure path. Don't call bfd_fatal. + (get_sections): Delete function. + (copy_object): Don't use bfd_map_over_sections, instead use a + loop allowing easy detection of failure status. Free memory on + error paths. + (copy_archive): Return bool success rather than setting "status" + on failure. + (copy_file): Set "status" here. + * testsuite/binutils-all/strip-13.d: Adjust to suit. + +2024-07-06 GDB Administrator + + Automatic date update in version.in + +2024-07-05 Matthieu Longo + + aarch64: add Debug Feature Register 2 (ID_AA64DFR2_EL1) + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add STEP2 feature and its associated registers + AArch64 defines new registers for the feature step2 (Enhanced Software Step + Extension). step2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add SPMU2 feature and its associated registers + AArch64 defines new registers for the feature spmu2 (System Performance + Monitors Extension version 2). spmu2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add E3DSE feature and its associated registers + AArch64 defines new registers for the feature e3dse (Delegated SError + exceptions for EL3): vdisr_el3 and vdisr_el3. e3dse is an Armv9.5-A + feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Lingling Kong + + x86-64: Fix support for APX NF TLS IE with 2 operands + Added the restriction in assemble for APX TLS IE that the destination + can only be a register. + + gas/ + + * config/tc-i386.c (md_assemble): Added stricter restrictions + for APX TLS IE. + +2024-07-05 Jan Beulich + + RISC-V: avoid use of match_opcode() in riscv_insn_types[] + As of 27b33966b18e ("RISC-V: disallow x0 with certain macro-insns") the + .match_func field may be NULL for entries used for assembly only, which + is the case for the entire table. With .match and .mask both zero the + function would only ever succeed anyway. Save almost a hundred base + relocations in the final executable by using NULL instead. + + aarch64: fix build with old glibc + As was pointed out several times before, old glibc declares index(), + resulting in warnings from -Wshadow, in turn failing the build due to + -Werror. + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR tests + Most tests are ported from AArch64. + + The relr-addend test is added to make sure the addend (link-time address) + is correctly written into the relocated section. Doing so is not + strictly needed for RELA, but strictly needed for RELR). + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR support + The logic is same as a71d87680110 ("aarch64: Add DT_RELR support"). + + As LoongArch does not have -z dynamic-undefined-weak, we don't need to + consider UNDEFWEAK_NO_DYNAMIC_RELOC. + + The linker relaxation adds another layer of complexity. When we delete + bytes in a section during relaxation, we need to fix up the offset in + the to-be-packed relative relocations against this section. + +2024-07-05 Xi Ruoyao + + LoongArch: Make protected function symbols local for -shared + On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols + as preemptible. See the comment above LARCH_REF_LOCAL for detailed + explanation. + +2024-07-05 Xi Ruoyao + + LoongArch: Fix bad reloc with mixed visibility ifunc symbols in shared libraries + With a simple test case: + + .globl ifunc + .globl ifunc_hidden + .hidden ifunc_hidden + .type ifunc, %gnu_indirect_function + .type ifunc_hidden, %gnu_indirect_function + + .text + .align 2 + ifunc: ret + ifunc_hidden: ret + + test: + bl ifunc + bl ifunc_hidden + + "ld -shared" produces a shared object with one R_LARCH_NONE (instead of + R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc". + It's because the indices in .plt and .rela.plt mismatches for + STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a + STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of + loongarch_elf_finish_dynamic_symbol. Fix the issue by reordering .plt + so the indices no longer mismatch. + +2024-07-05 Xi Ruoyao + + LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64 + We were converting R_LARCH_32 to R_LARCH_RELATIVE for ELFCLASS64: + + $ cat t.s + .data + x: + .4byte x + .4byte 0xdeadbeef + $ as/as-new t.s -o t.o + $ ld/ld-new -shared t.o + $ objdump -R + a.out: file format elf64-loongarch + + DYNAMIC RELOCATION RECORDS + OFFSET TYPE VALUE + 00000000000001a8 R_LARCH_RELATIVE *ABS*+0x00000000000001a8 + + But this is just wrong: at runtime the dynamic linker will run + *(uintptr *)&x += load_address, clobbering the next 4 bytes of data + ("0xdeadbeef" in the example). + + If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected + by the Glibc dynamic linker anyway. And it does not make too much sense + to modify Glibc to support it. So we can just reject it like x86_64: + + relocation R_X86_64_32 against `.data' can not be used when making a + shared object; recompile with -fPIC + + or RISC-V: + + relocation R_RISCV_32 against non-absolute symbol `a local symbol' + can not be used in RV64 when making a shared object + +2024-07-05 Cui, Lili + + x86: Correct position of ".s" for CCMPcc in disassembler + Added new macro %SW to CCMPcc to print ".s" after the mnemonic. + + Before: + ccmpbl {dfv=}.s %edx,%eax + + After: + ccmpbl.s {dfv=} %edx,%eax + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-pseudos-apx.d: Add tests for CCMPcc. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %SW for CCMPcc swap operands. + * i386-dis.c (struct dis386): Added %SW. + (putop): Handle %SW. + +2024-07-05 Cui, Lili + + x86: Add {load}/{store} tests for apx instructions. + gas/ChangeLog: + + * testsuite/gas/i386/x86-64.exp: Add {load}/{store} tests for apx + instructions. + * testsuite/gas/i386/x86-64-pseudos-apx.d: New test. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + +2024-07-05 GDB Administrator + + Automatic date update in version.in + +2024-07-04 Sun Sunny + + RISC-V: Fix BFD_RELOC_RISCV_PCREL_LO12_S patch issue + In commit dff565fcca8137954d6ad571ef39f6aec5c0429c, the fixups + for PCREL_LO12_I and PCREL_LO12_S were mixed, so the "IMM" + field were applied to incorrect position, this caused incorrect + src registers to be encoded. + + gas/ + * config/tc-riscv.c (md_apply_fix): Fix PCREL_LO12_S issue. + * testsuite/gas/riscv/ixup-local.s: Updated for PCREL_LO12_S cases. + * testsuite/gas/riscv/fixup-local-relax.d: Likewise. + * testsuite/gas/riscv/fixup-local-norelax.d: Likewise. + +2024-07-04 Lifang Xia + + RISC-V: hash with segment id and pcrel_hi address while recording pcrel_hi + When the same address across different segments (sections) needs to be + recorded, it will overwrite the slot, leading to a memory leak. To ensure + uniqueness, the segment (section) ID needs to be included in the hash key + calculation. + + gas/ + * config/tc-riscv.c (riscv_pcrel_hi_fixup): New "const asection *sec". + (riscv_pcrel_fixup_hash): make sec->id and e->adrsess as the + hash key. + (riscv_pcrel_fixup_eq): Check sec->id at first. + (riscv_record_pcrel_fixup): New member "sec". + (md_apply_fix) : Likewise. + (md_apply_fix) : Likewise. + +2024-07-04 Andre Vieira + + mve: Fix encoding for vcvt[bt] single-half float conversion instructions + The encoding was previously not taking into account that the Quad vector + registers were being encoded using their Q-register numbers rather than their + D-register equivalent (multiply by 2). + + gas/ + + * config/tc-arm.c (do_neon_cvttb_1): Use Q-register vector number + rather than their D-register equivalent. + + gas/testsuite/ + + * gas/arm/mve-vcvt-3.d: Correct expected values in test. + +2024-07-04 Jens Remus + + gas: Validate SFrame RA tracking and fixed RA offset + Verify all architectures participating in SFrame generation do define + the mandatory SFrame return address (RA) tracking predicate function + sframe_ra_tracking_p. Do so by explicitly not testing for the macro + SFRAME_FRE_RA_TRACKING as otherwise required. + + Verify that architectures not using SFrame RA tracking specify a valid + fixed RA offset. + + gas/ + * gen-sframe.c (output_sframe_internal): Validate SFrame + RA tracking and fixed RA offset. + +2024-07-04 Jens Remus + + gas: Test predicate whether SFrame RA tracking is used + The existence of the macro SFRAME_FRE_RA_TRACKING only ensures the + existence of the macro SFRAME_CFA_RA_REG and the predicate function + sframe_ra_tracking_p. It does not indicate whether SFrame RA tracking + is actually used. + + Test the return value of the SFrame RA tracking predicate function + sframe_ra_tracking_p to determine whether RA tracking is used. + + This aligns the logic in functions get_fre_num_offsets and + output_sframe_row_entry to the one used in all other places. + + gas/ + * gen-sframe.c (get_fre_num_offsets, output_sframe_row_entry): + Test predicate to determine whether SFrame RA tracking is used. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies SP register + Neither ".cfi_offset SP, ", ".cfi_register SP, ", nor + ".cfi_val_offset SP, " alter the tracking information to recover + the stack pointer (SP). Doing so would need an explicit .cfi_def_cfa, + which SFrame tracks. + + The stack pointer (SP) register contents on entry can be reconstructed + from the SFrame CFA tracking information using information from the + current and initial SFrame FREs of the SFrame FDE: + + 1. Compute CFA from the current CFA base register (SP or FP) and CFA + offset from the SFrame CFA tracking information from the SFrame FRE + for the current instruction address: + + CFA = + + + 2. Compute SP from the current CFA and the CFA offset from the SFrame + CFA tracking information from the initial SFrame FRE of the FDE: + + SP = CFA - + + While at it add comments to the processing of .cfi_offset and + .cfi_val_offset that the SP can be reconstructed from the CFA tracking + information. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies SP register. + (sframe_xlate_do_offset,sframe_xlate_do_val_offset): Add comment + that this is likewise. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking + Do not skip SFrame FDE if .cfi_register specifies RA register without + RA tracking being actually used. Without RA tracking the register + contents can always be restored from the stack using the fixed + RA offset from CFA. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies RA register without RA tracking + being used. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if .cfi_window_save + CFI opcode DW_CFA_AARCH64_negate_ra_state is multiplexed with + DW_CFA_GNU_window_save. Process DW_CFA_AARCH64_negate_ra_state on + AArch64. Skip generation of SFrame FDE otherwise with the following + warning message: + + skipping SFrame FDE; .cfi_window_save + + gas/ + * gen-sframe.c: Skip SFrame FDE if .cfi_window_save. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if FP without RA on stack + The SFrame format cannot represent the frame pointer (FP) being saved + on the stack without the return address (RA) also being saved on the + stack, if RA tracking is used. + + A SFrame FDE is followed by 1-3 offsets with the following information: + + Without RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the frame pointer (FP) + + With RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the return address (RA) + 3. Optional: Offset to CFA to restore the frame pointer (FP) + + When RA tracking is used and a FDE is followed by two offsets the + SFrame format does not provide any information to distinguish whether + the second offset is the RA or FP offset. SFrame assumes the offset to + be the RA offset, which may be wrong. + + Therefore skip generation of SFrame FDE information and print the + following warning, if RA tracking is used and the FP is saved on the + stack without the RA being saved as well: + + skipping SFrame FDE; FP without RA on stack + + gas/ + * gen-sframe.c (sframe_do_fde): Skip SFrame FDE if FP without RA + on stack, as the SFrame format cannot represent this case. + +2024-07-04 Jens Remus + + gas: User readable warnings if SFrame FDE is not generated + The following generic warning message, which is printed whenever the + assembler skips generation of SFrame FDE, is not very helpful for the + user: + + skipping SFrame FDE; CFI insn (0x) + + Whenever possible print meaningful warning messages, when the assembler + skips generation of SFrame FDE: + + - skipping SFrame FDE; non-SP/FP register in .cfi_def_cfa + - skipping SFrame FDE; non-SP/FP register in + .cfi_def_cfa_register + - skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register + in effect + - skipping SFrame FDE; {FP|RA} register in .cfi_val_offset + - skipping SFrame FDE; {SP|FP|RA} register in in .cfi_register + - skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE + state + - skipping SFrame FDE; non-default RA register + + gas/ + * gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): New macro for + invalid SFrame FRE CFA base register value of -1. + * gen-sframe.c: User readable warnings if SFrame FDE is not + generated. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update generic SFrame test + case to updated warning message texts. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + +2024-07-04 Jens Remus + + gas: Refactor SFrame CFI opcode DW_CFA_register processing + Refactor SFrame processing of CFI opcode DW_CFA_register into a separate + function. This harmonizes the CFI opcode processing. + + While at it reword the comment on CFI opcodes that are not processed. + + This is a purely mechanical change. + + gas/ + * gen-sframe.c (sframe_do_cfi_insn, sframe_xlate_do_register): + Refactor SFrame CFI opcode DW_CFA_register processing. + +2024-07-04 Jens Remus + + gas: Warn if SFrame FDE is skipped due to non-default return column + Print a warning message if SFrame FDE is skipped due to a non-default + DWARF return column (i.e. return address (RA) register number). This + may be caused by the use of CFI directive .cfi_return_column with a + non-default return address (RA) register number in the processed + assembler source code. + + Warning: skipping SFrame FDE due to non-default DWARF return column + + gas/ + * gen-sframe.c: Warn if SFrame FDE is skipped due to non-default + DWARF return column. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-3.d: Update test case to expect + for new warning message when SFrame FDE is skipped due to + a non-default DWARF return column. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if CFI specifies non-FP/SP base register + Do not generate SFrame FDE if DWARF CFI directives .cfi_def_cfa or + .cfi_def_cfa_register specify a CFA base register number other than + the architecture-specific stack-pointer (SP) or frame-pointer (FP) + register numbers. + + This also causes the assembler to print a warning message, so that + skipping of the SFrame FDE does not occur silently. + + Update the generic ld SFrame test case to be architecture independent. + Do not use CFI directive .cfi_def_cfa, as the specified CFA base + register number is not a valid SP/FP register number on all + architectures. An invalid SP/FP register number will now cause the + assembler to print a warning message and skip SFrame FDE generation. + Remove the offending CFI directive, that cannot be coded architecture- + independent, as the test case requires SFrame information to be + generated. This was reported by the Linaro-TCWG-CI for AArch64. + + gas/ + * gen-sframe.c: Skip SFrame generation if CFI specifies + non-FP/SP base register. + + ld/testsuite/ + * ld-sframe/discard.s: Update generic SFrame test case to be + architecture independent. + +2024-07-04 Jens Remus + + gas: Print DWARF call frame insn name in SFrame warning message + SFrame generation prints the DWARF call frame instruction opcode in + hexadecimal. Leverage get_DW_CFA_name to additionally print the + DWARF call frame instruction name in human readable form, while also + respecting fake CFI types. Use "(unknown)", if the DWARF call frame + instruction name is not known. + + While at it use the terminology "instruction" for these DW_CFA_*, as + suggested by Indu. + + This changes the following assembler SFrame generation warning message + as follows: + + Old: + Warning: skipping SFrame FDE due to DWARF CFI op 0x + + New: + Warning: skipping SFrame FDE; CFI insn (0x) + + gas/ + * gen-sframe.c (sframe_get_cfi_name): New function to get the + DWARF call frame instruction name for a DWARF call frame + instruction opcode. + (sframe_do_cfi_insn): Use sframe_get_cfi_name to print the + DWARF call frame instruction name for the DWARF call frame + instruction opcode in the warning message. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update expected SFrame + warning message text for DWARF call frame insn name. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Display SFrame fixed RA offset as 'f' in dump + For the SFrame FRE frame-pointer (FP) offset from CFA a 'u' is displayed + if it is unavailable. + + For the SFrame FRE return-address (RA) offset from CFA a 'u' was + displayed if the ABI uses a fixed RA offset from CFA. By chance a + 'u' was also displayed if the RA offset is unavailable, as the string + buffer was not initialized after formatting the FP offset. Note that it + could not occur that the FP offset was erroneously displayed as RA + offset, as the SFrame format cannot have a FRE with FP offset without + RA offset. + + For the FRE RA offset display 'f' if the ABI uses a fixed RA offset + from CFA. Display a 'u' if it is unavailable. + + libsframe/ + * sframe-dump.c: Display SFrame fixed RA offset as 'f' in dump. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-4.d: Test for RA displayed + either as 'u' (if RA tracking) or as 'f' (fixed RA offset if no + RA tracking). + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for RA displayed + as 'f' (fixed RA offset), as x86-64 does not use RA tracking. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for RA displayed as 'f' (fixed + RA offset), as x86-64 does not use RA tracking. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Dump SFrame CFA fixed FP and RA offsets + The SFrame format allows architectures to specify fixed offsets from the + CFA, if any, from which the frame pointer (FP) and/or return address + (RA) may be recovered. These offsets are stored in the SFrame header. + + For instance the SFrame generation in the assembler for x86 AMD64 + specifies a fixed offset from the CFA, from which the return address + (RA) may be recovered. + + When dumping the SFrame header, for instance in readelf/objdump with + option --sframe, do also dump the specified fixed offsets from the CFA, + if any, from which the frame pointer (FP) and return address (RA) may + be recovered. + + Update the common SFrame test case verification patterns to allow for + the optional dumping of the CFA fixed FP/RA offsets. Update the x86- + specific SFrame and SCFI test case verification patterns to require a + CFA fixed RA offset of -8. + + libsframe/ + * sframe-dump.c: Dump CFA fixed FP and RA offsets. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for fixed + RA offset. + * gas/cfi-sframe/common-empty-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Test for SFrame fixed + RA offset. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for SFrame fixed RA offset. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + gas: Enhance arch-specific SFrame configuration descriptions + Explicitly mention "SFrame" in the descriptions for the architecture- + specific SFrame configuration macros, variables, and functions. + + Use the term "frame pointer" (FP) instead of "base pointer". This aligns + with the terminology used in the SFrame specification. Additionally it + helps not to confuse "base-pointer register" with the term "BASE_REG" + used in the specification to denote either the SP or FP register. + + Specify what the SFRAME_CFA_*_REG register numbers are used for: + - SP (stack pointer): CFA tracking + - FP (frame pointer): CFA and FP tracking + - RA (return address): RA tracking + + Align the descriptions for definitions in the source files to the + declarations in the header files. + + gas/ + * config/tc-aarch64.h: Enhance architecture-specific SFrame + configuration descriptions. + * config/tc-aarch64.c: Likewise. + * config/tc-i386.h: Likewise. + * config/tc-i386.c: Likewise. + +2024-07-04 Jens Remus + + x86: Remove unused SFrame CFI RA register variable + gas/ + * config/tc-i386.c (x86_sframe_cfa_ra_reg): Remove. + +2024-07-04 Cui, Lili + + Support APX CFCMOV + The CMOVcc instruction proposed by EVEX has four different forms, + corresponding to the four possible combinations of EVEX.ND and EVEX.NF + values. + + In the encoder part, when the CFCMOV template supports EVEX_NF, it means that + it requires EVEX.NF to be 1. + + In the decoder part, CFCMOV_Fixup is used to reverse source and destination + operands in the 2-operand case. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Set NF bit for cfcmov + when the insn template supports EVEX_NF. + * testsuite/gas/i386/x86-64-apx-inval.l: Add invalid tests for cfcmov. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add tests for cfcmov and cmov. + * testsuite/gas/i386/x86-64-apx-cfcmov-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add cfcmov instructions. + * i386-dis.c (CFCMOV_Fixup): Special handling of cfcmov. + (putop): Print 'cf' for cfcmov instructions. + * i386-opc.h (EVEX_NF): New. + * i386-opc.tbl: Add cfcmov instructions. + * i386-mnem.h: Regerated. + * i386-tbl.h: Regerated. + +2024-07-04 GDB Administrator + + Automatic date update in version.in + +2024-07-03 Nelson Chu + + RISC-V: Tidy and complete testing of all architecture imply rules. + gas/ + * testsuite/gas/riscv/imply.s: New testcase for all imply cases. + * testsuite/gas/riscv/imply.d: Likewise. + * testsuite/gas/riscv/march-imply-i.s: Renamed to + imply-zicsr-zifencei.s. + * testsuite/gas/riscv/march-imply-i2p0-02.d: Renamed to + imply-zicsr-zifencei-i2p0-misa-spec-2p2.d. + * testsuite/gas/riscv/march-imply-i2p1-01.d/l: Renamed to + imply-zicsr-zifencei-i2p1-misa-spec-20191213.d. + * testsuite/gas/riscv/march-imply-i2p0-01.d: Removed. + Combined into new imply testcase. + * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise. + * testsuite/gas/riscv/march-imply-a.d: Likewise. + * testsuite/gas/riscv/march-imply-b.d: Likewise. + * testsuite/gas/riscv/march-imply-f.d: Likewise. + * testsuite/gas/riscv/march-imply-g.d: Likewise. + * testsuite/gas/riscv/march-imply-h.d: Likewise. + * testsuite/gas/riscv/march-imply-q.d: Likewise. + * testsuite/gas/riscv/march-imply-smcsrind.d: Likewise. + * testsuite/gas/riscv/march-imply-smstateen.d: Likewise. + * testsuite/gas/riscv/march-imply-unsupported.d: Likewise. + * testsuite/gas/riscv/march-imply-v.d: Likewise. + * testsuite/gas/riscv/march-imply-zcd.d: Likewise. + * testsuite/gas/riscv/march-imply-zcf.d: Likewise. + +2024-07-03 Alan Modra + + Avoid possible signed overflow in decode_local_label_name + Matches what both fb_label_name and dollar_label_name use. + + * symbols.c (decode_local_label_name): Use unsigned variables. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed typo of `.insn cj' format + gas/ + * doc/c-riscv.texi: Fixed typo of `.insn cj' format. + +2024-07-03 Lingling Kong + + x86-64: Support APX NF TLS IE with 2 operands + Support APX NF TLS IE with 2 operands.Verify it with ld and gold. + + gas/ + + * config/tc-i386.c (md_assemble): Allow APX NF TLS IE with + 2 operands. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add APX NF TLS IE + tests with 2 operands. + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add APX NF TLS IE tests with + 2 operands. + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add APX NF TLS IE tests + with 2 operands. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed syntax of `.option arch' when reseting whole architecture + gas/ + * doc/c-riscv.texi: Fixed syntax of `.option arc'h when reseting whole + architecture. Don't need the `=' before ISA. + +2024-07-03 GDB Administrator + + Automatic date update in version.in + +2024-07-02 Tom Tromey + + Accept unnamed array in gdb.ada/limited-length.exp + Some compiler changes I'm working on cause a regression in + gdb.ada/limited-length.exp -- with the changes, the array type is + nameless and so is not mentioned in the max-value-size error message. + + Because the array type is nameless in the source code, this seems like + an improvement to me, and so this patch changes the test to accept + either form. + +2024-07-02 Aditya Vidyadhar Kamath + + Use lwp field in ptid for AIX. + Currently in AIX, the private data is used to maintain the kernel thread ID. + + This is a patch to trim the need to have another field in the private data of a thread in AIX. + + We want to use the lwp field to represent the kernel thread ID to match or + make things similar to the Linux targets. + +2024-07-02 konglin1 + + x86-64: Verify that TLS IE works with APX NF + Verify that + + {nf} add %reg1, foo@gottpoff(%rip), %reg2 + {nf} add foo@gottpoff(%rip), %reg, %reg2 + + work correctly with ld and gold. + + gas/ + + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + for APX NF tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + + Co-Authored-By: H.J. Lu + +2024-07-02 GDB Administrator + + Automatic date update in version.in + +2024-07-01 H.J. Lu + + ld: Move foo before delete in dl5.cc + * testsuite/ld-elf/dl5.cc (main): Move foo before delete. + +2024-07-01 Claudiu Zissulescu + + MAINTAINERS: Update my e-mail address + +2024-07-01 Xi Ruoyao + + LoongArch: Remove unused code in ld test suite + These seems some left over from MIPS code and they do not make any + sense for LoongArch. + +2024-07-01 Alan Modra + + PR31941 objcopy --globalize-symbol + I think FILE symbols are special, and I can't see why anyone would + want them to be made global. The fact that no one has reported this + bug since commit 7b4a0685e80a in 2005 supports that claim. + + PR 31941 + * objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to + be made global. + +2024-07-01 GDB Administrator + + Automatic date update in version.in + +2024-06-30 H.J. Lu + + ld: Avoid folding new and delete pairs + GCC 15 may fold new and delete pairs, like + + A *bb = new A[10]; + delete [] bb; + bb = new (std::nothrow) A [10]; + delete [] bb; + + as shown in + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712 + + Avoid folding new and delete pairs by adding a function call between new + and delete. + + * testsuite/ld-elf/dl5.cc: Include "dl5.h". + (A): Removed. + Call foo between new and delete. + * testsuite/ld-elf/dl5.h: New file. + * testsuite/ld-elf/new.cc: Include "dl5.h". + (foo): New function. + +2024-06-30 Marcus Nilsson + + objcopy: Allow making symbol global and weak on same invocation + Previously objcopy had to be run twice in order to make a local symbol + weak, first once to globalize it, and once again to mark it as weak. + + * objcopy.c (filter_symbols): Weaken symbols after making + local/global changes. + * testsuite/binutils-all/symbols-5.d, + * testsuite/binutils-all/symbols-5.s: New test. + +2024-06-30 Alan Modra + + tweak latest vms-alpha.c change + It's that tiny bit nicer to have the "len" expression in order of + the components in the buffer. + + Assertion `(data) <= (end)' failed in read_bases + * dwarf.c (skip_attribute): Don't increment data past end. + Use SKIP_{S,U}LEB rather than READ_{S,U}LEB. + +2024-06-30 Alan Modra + + Re: Rewrite SHT_GROUP handling + Some more error tweaks. Report a zero entry as "invalid entry.." + rather than "unknown type..", and allow a section to be mentioned + twice in a group. + + * elf.c (process_sht_group_entries): Tweak error messages, and + allow a duplicate index in a group without reporting an error. + +2024-06-30 GDB Administrator + + Automatic date update in version.in + +2024-06-29 Sam James + + ld: pass -g for ld-elf tests + The "DWARF parse during linker error" and "Build warn libbar.so" tests + require debug information. + + configure defaults to "-O2 -g" but if overriding *FLAGS when building + tests, this might be lost. Explicitly pass -g given these tests require + it. + + Originally reported downstream in Gentoo at https://bugs.gentoo.org/934149. + + ld/ + * testsuite/ld-elf/dwarf.exp: Pass -g for "DWARF parse during linker error". + * testsuite/ld-elf/shared.exp: Ditto for "Build warn libbar.so". + +2024-06-29 GDB Administrator + + Automatic date update in version.in + +2024-06-28 Claudio Bantaloukas + + aarch64: Add support for Armv9.5-A architecture + The new -march=armv9.5-a flag enables access to the + mandatory cpa, lut and faminmax extensions. + Existing test cases for features are extended to verify they + work without additional flags. + +2024-06-28 Jan Beulich + + ld/doc: drop stray blank + Old enough tools demand no blank between @option and the opening figure + brace. Re-wrap the paragraph as well while at it. + +2024-06-28 Lulu Cai + + LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files + R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38. + We do not check this relocation to prevent broken links with old object + files. + +2024-06-28 Jan Beulich + + x86/APX: apply NDD-to-legacy transformation to further CMOVcc forms + With both sources being registers, these insns are almost commutative; + the only extra adjustment needed is inversion of the encoded condition. + + x86/APX: extend TEST-by-imm7 optimization to CTESTcc + The same properties apply there. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL + ..., for differing only in the resulting EFLAGS, which are left + untouched anyway. That's a shorter encoding, available as long as + certain constraints on operands are met; see code comments. (SHL-by-1 + forms may then be subject to further optimization that was introduced + earlier.) + + Note that kind of as a side effect this also converts multiplication by + 1 to shift by 0, which is a plain move or even no-op anyway. That could + be further shrunk (as could be presence of shifts/rotates by 0 in the + original code as well as a fair set of other {nf}-form insns), yet the + expectation (for now) is that people won't write such code in the first + place. + +2024-06-28 Jan Beulich + + x86-64: restrict by-imm31 optimization + Avoid changing the encoding when there's no size gain: If there's a REX + or REX2 prefix anyway and the base opcode wouldn't be changed, dropping + just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case + in the same big conditional.) + + While there also pull out the .qword check: For the 2-register-operands + case whether that's done on the 1st or 2nd operand doesn't matter. Due + to reduction in necessary parentheses this improves readability a tiny + bit. + +2024-06-28 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to LEA + ..., as that leaves EFLAGS untouched anyway. That's a shorter encoding, + available as long as certain constraints on operand size and registers + are met; see code comments. + + Note that this requires deferring to derive encoding_evex from {nf} + presence, as in optimize_encoding() we want to avoid touching the insns + when {evex} was also used. + + Note further that this requires want_disp32() to now also consider the + opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still + report the original mnemonic (or else things can get confusing). While + there, correct adjacent mis-indentation. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form rotate-by-width-less-1 + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS.CF, for the NF variants the immediate can be got rid of in that + case by switching to a 1-bit rotate in the opposite direction. + + x86/APX: optimize {nf} forms of ADD/SUB with specific immediates + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS, for the NF variants we can safely replace ones using 0x80 by the + respectively other insn while negating the immediate, saving 3 immediate + bytes (just 1 though for 16-bit operand size). Similarly we can replace + ones using 1 / -1 by INC/DEC (eliminating the immediate). + + gas: .irp/.irpc are macro-like + ... for the purposes of get_line_sb() and _find_end_of_line(): They + support \@ just like macros do, and hence the special casing there also + needs applying. + +2024-06-28 Nelson Chu + + RISC-V: Shrink the riscv_implicit_subsets table. + Allow to add implicit extensions by using the syntax of `.option arch, +-', so + that the table is shrinked and more readable. + + bfd/ + * elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT + parameter. + (check_implicit_for_i): Likewise. + (riscv_implicit_subsets): Shrink the table by allowing the syntax of + `.option arch, +-' for implicit extensions. + (riscv_update_subset1): New function, called from riscv_update_subset + or riscv_parse_add_implicit_subsets. It basically does the same thing + as riscv_update_subset function before. + (riscv_parse_add_implicit_subsets): Updated. + (riscv_update_subset): Updated. + +2024-06-28 Nelson Chu + + RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc. + When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel + relocation to absolutly access if possible at the relocate stage. We used to + encode the target address into r_sym of R_RISCV_HI20 if it is converted from + R_RISCV_PCREL_HI20. But that may cause segfault if --emit-relocs is set, + since r_sym becomes an address rather than a symbol index. Although the + relocate result is correct, it does not meet the definition, so may cause + unexpected behaviors. + + This patch encodes the target address into r_addend, rather than r_sym, if + riscv_zero_pcrel_hi_reloc converts the relocation. Besdies, since the + corresponding pcrel_lo relocation are also changed to absolutly access, + we should also update them to R_RISCV_LO12_I/S. + + bfd/ + PR 27180 + * elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to + inform corresponding pcrel_lo that the pcrel_hi relocation was already + converted to hi20 relocation. + (riscv_record_pcrel_hi_reloc): Likewise, record `absolute'. + (riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc, + since we may need to convert it from pcrel_lo to lo relocation. + (riscv_record_pcrel_lo_reloc): Likewise. Convert pcrel_lo to lo + relocation if corresponding pcrel_hi was converted to hi relocation. + (riscv_zero_pcrel_hi_reloc): Encode target absolute address into + r_addend rather than r_sym. Clear the `addr' to avoid duplicate + relocate in the perform_relocation. + (riscv_elf_relocate_section): Updated. + ld/ + PR 27180 + * testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase. + Segfault without applying this patch. + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + +2024-06-28 Jiawei + + RISC-V: Add Zabha extension CAS instructions. + This patch update the cas instruction in Zabha extension [1], + when both Zabha and Zacas extension enabled. + + [1] https://github.com/riscv/riscv-zabha/tags + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): New extension case. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New instructions. + * testsuite/gas/riscv/zabha.d: Ditto. + * testsuite/gas/riscv/zabha.s: Ditto. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOCAS_B): New opcodes. + (MASK_AMOCAS_B): Ditto. + (MATCH_AMOCAS_H): Ditto. + (MASK_AMOCAS_H): Ditto. + (DECLARE_INSN): New instructions. + * opcode/riscv.h (enum riscv_insn_class): New class case. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-06-28 GDB Administrator + + Automatic date update in version.in + +2024-06-27 H.J. Lu + + Set BFD_DECOMPRESS when reading build-id debuglink + We should set BFD_DECOMPRESS to decompress sections unless dumping the + section contents when reading build-id debuglink. + + PR binutils/31925 + * objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress + sections unless dumping the section contents. + * testsuite/binutils-all/objdump.exp (test_build_id_debuglink): + Add a compress option. + Run test_build_id_debuglink with none and zlib. + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_tilde_expand + Like the previous commit, add two overloads of gdb_tilde_expand, one + takes std::string and other takes gdb::unique_xmalloc_ptr. Make + use of these overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_abspath + Add two overloads of gdb_abspath, one which takes std::string and one + which takes gdb::unique_xmalloc_ptr, then make use of these + overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Pali Roh?r + + Improve comments describing the Import Directory Table + PR 31728 + +2024-06-27 Nick Clifton + + Fix new libdep test so that if the plugin cannot be located the test fails gracefully. + +2024-06-27 Alan Modra + + Re: Rewrite SHT_GROUP handling + There is no need to loop over the headers twice. Remove that leftover + from the previous scheme. Also, the previous scheme silently ignored + a section being mentioned in two or more SHT_GROUP sections. + + * elf.c (process_sht_group_entries): Prevent sections from + belonging to two groups. + (_bfd_elf_setup_sections): Process groups in a single loop + over headers. + +2024-06-27 GDB Administrator + + Automatic date update in version.in + +2024-06-27 Alan Modra + + Rewrite SHT_GROUP handling + This patch delays setting up elf_next_in_group, elf_sec_group and + elf_group_name when reading ELF object files until after all ELF + sections have been processed by bfd_section_from_shdr. This is simpler + and more robust than the current scheme of driving the whole process + on detecting a section with SHF_GROUP set. + + * elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr, + num_group and group_search_offset. + * elf.c (Elf_Internal_Group): Delete. + (setup_group): Delete function. + (IS_VALID_GROUP_SECTION_HEADER): Delete macro. + (is_valid_group_section_header), + (process_sht_group_entries): New functions. + (_bfd_elf_setup_sections): Handle group sections here.. + (_bfd_elf_make_section_from_shdr): ..rather than here. + (bfd_section_from_shdr): Don't check SHT_GROUP validity here. + +2024-06-26 Nick Clifton + + Revert: 35fd2ddeb1d90f1750401cfb6d01fe055656b88d + PR 20814 + +2024-06-26 Tom de Vries + + [gdb/testsuite] Minor cleanup in gdb.base/bg-execution-repeat.exp + Simplify a gdb_test_multiple in test-case gdb.base/bg-execution-repeat.exp + using "gdb_test -no-prompt-anchor". + + Suggested-By: Guinevere Larsen + + Tested on x86_64-linux. + +2024-06-26 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp + I ran into the following test failure with test-case + gdb.base/bg-execution-repeat.exp: + ... + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command + ^M + Breakpoint 2, foo () at bg-execution-repeat.c:23^M + 23 return 0; /* set break here */^M + print 1^M + $1 = 1^M + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted + FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout) + ... + + The failure can be easily reproduced by adding a sleep 5 here: + ... + + sleep 5 + gdb_test "print 1" " = 1" "input still accepted" + ... + + There's a race in the test-case, between: + - the command handled in the foreground: the "print 1" command, and + - the command handled in the background: the continue command. + + The current way of dealing with this is by putting the inferior to sleep for 5 + seconds: + ... + foo (); + sleep (5); + foo (); + ... + with the aim that the "print 1" command will win the race. + + This method is both slow and unreliable. + + Fix this by making the inferior wait till the "print 1" command is done. + + This reduces running time from ~11s to ~1s. + + I also verified that the test-case still triggers on the original problem by + applying this gdb/infcmd.c patch: + ... + -strip_bg_char (const char *args, int *bg_char_p) + +strip_bg_char (const char *_args, int *bg_char_p) + { + - const char *p; + + char *args = const_cast(_args); + + char *p; + + if (args == nullptr || *args == '\0') + { + @@ -210,6 +211,7 @@ strip_bg_char (const char *args, int *bg_char_p) + p--; + while (p > args && isspace (p[-1])) + p--; + + *p = '\0'; + ... + + Tested on x86_64-linux, with make-check-all.sh. + + PR testsuite/31794 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31794 + + Reviewed-By: Guinevere Larsen + +2024-06-26 Indu Bhagat + + doc: sframe: small improvements for readability + Update some of the content to make the specification document hopefully + clearer: + - Fix some typos. + - Use Title case consistently for headings. + - Update text around detection of foreign endianness. + - Split the structure field "Name" in each table to two separate + colunms for additional attention: "Type" and "Name". + - Rename "SFrame endianness" section to "SFrame magic number and + endianness" + - Update text around provisions for extending SFrame for future + ABIs/architectures. Make it clear by tagging all provisions with an + explicit index item "Provisions for future ABIs". + - Add a paragraph on sort order of SFrame FDEs. + - Add a statement for SFRAME_F_FRAME_POINTER flag. + - Add a statement to assert that SFrame version 1 is now obsolete and + should not be used. + + libsframe/ + * doc/sframe-spec.texi: Small improvements for readability. + +2024-06-26 GDB Administrator + + Automatic date update in version.in + +2024-06-26 Victor Do Nascimento + + aarch64: FP8 scale and convert - Implement minor improvements + Following feedback received shortly after the initial commit of the + aarch64 instructions for scaling and converting fp8 instructions, this + patch addresses the issues raised in the relevant feedback. + + This includes the following changes: + + * Standardize all FP8 qualifier-set names. This has resulted in the + renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B + to QL_V2_HB_FULL. + + * Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new + standardized qualifier-set names mentioned above and, in the case of + the "fcvtn" entries, also add a leading 0 to their opcode values so + they are given as 8 hexadecimal digits in length to ensure + consistency in formatting relative to other entries in the table. + + * Revise the added test-cases so that when checking operand fields in + the disassembled binaries, all bits for these fields get tested to + ensure they can be toggled on/off by the relevant operand arguments. + +2024-06-25 Flavio Cruz + + Hurd port: update interface to match upstream and fix warnings. + We have recently updated the interface for raising exceptions to use + long [1] and updated mach_port_t to be "unsigned int". This patches fixes + those problems and will help us port GDB to Hurd x86_64. + + Tested on Hurd i686 and x86_64. + + [1] https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/mach/exc.defs + + Approved-By: Simon Marchi + +2024-06-25 Jens Remus + + aarch64: Treat operand ADDR_SIMPLE as address with base register + The AArch64 instruction table (aarch64-tbl.h) defines the operand + ADDR_SIMPLE as "address with base register (no offset)". During assembly + it is correctly encoded as address with base register (addr.base_regno) + in parse_operands. In warn_unpredictable_ldst it is erroneously treated + as register number (reg.regno). + + This resolves the assembler test case "Diagnostics Quality" to + erroneously fail when changing the union in struct aarch64_opnd_info + from union to struct for debugging purposes. + + gas/ + * config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with + base register. + +2024-06-25 Jens Remus + + aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + Rt_IN_SYS_ALIASES as register number. During assembly it is correctly + encoded as register number (reg.regno) in parse_operands. During + disassembly it is first correctly decoded as register number (reg.regno) + in aarch64_ext_regno called by aarch64_extract_operand, but then + erroneously treated as immediate value (imm.value) in + aarch64_print_operand. + + This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31919 + * aarch64-opc.c: Treat operand Rt_IN_SYS_ALIASES as register + number. + + Bug: https://sourceware.org/PR31919 + Fixes: 72476aca8f58 ("aarch64: add Branch Record Buffer extension instructions") + +2024-06-25 Andrew Burgess + + gdb/doc: the all-doc build target should build .... all docs + I noticed that the 'all-doc' build target doesn't build all the doc + formats, 'man' and 'html' are missing. + + This commit updates 'all-doc' so that all formats are built. + + This doesn't change the default 'all' target, which is the default + target used when building GDB itself, the 'all' target continues to + just build the 'info' docs. + + There should be no difference in the actual generated output after + this commit, I'm just changing what gets built. + + Approved-By: Tom Tromey + +2024-06-25 Andrew Burgess + + gdb/doc: fix cannot create directory error when building dvi/pdf + After this commit: + + commit 0700386f142f0b0d3d0021995970a1b41c36cc92 (gdb-tmp-c) + Date: Wed May 8 19:12:57 2024 +0100 + + gdb/doc: fix parallel build of pdf and dvi files + + When building the dvi or pdf targets you'd get errors like this: + + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory + + fixed by ensuring the directory is created before calling texi2dvi. + +2024-06-25 Nick Clifton + + Updated Russian translation for the bfd/ sub-directory + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix FEAT_B16B16 sve2 instruction constraints. + This patch adds missing contraints to FEAT_B16B16 sve2 instructions + bfclamp, bfmla and bfmls and add negative tests for all the bfloat + instructions. + + The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.* + to maintain consistency in the testsuite. + + The bfloat16-1-invalid.* tests are modified so that "selected + processor does not support" is generated by the assembler, since + +b16b16 is not passed in the command line. + + The bfloat16-2-invalid.* testcase includes the wrong operands + bfloat16 tests. + +2024-06-25 Srinath Parvathaneni + + aarch64: Add extra tests for sve2p1 min max instructions. + This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv, + sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and + fminqv" instructions. + + The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase + without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands + for sve2p1 instructions. + +2024-06-25 Srinath Parvathaneni + + arch64: Fix the wrong constraint used for sve2p1 instructions. + The current implementation for the following SVE2p1 instructions add a + constraint in aarch64_opcode_table[] array, so that these instruction + might be immediately preceded in program order by a MOVPRFX instruction. + + As per the spec these instruction does not immediately preceded in + program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC + macro is replaced with SVE2p1_INSN macro for the entries of these + instructions in aarch64_opcode_table[] array. + + List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv, + eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 ld[1-4]/st[1-4]q instruction operands. + This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q + as mentioned below, for the issues reported here. + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + 1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as + predicated instructions and this issue is fixed in this patch by replacing + "SVE2p1_INSNC" with "SVE2p1_INSN" macro. + 2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed + by replacing "SVE_Zt" with "SVE_ZtxN". + 3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in + this patch. + 4) In ld1q/st1q the index in the second argument is optional and if index + is xzr and is skipped in the assembly, the index field is ignored by the + disassembler. + + Fixing above mentioned issues helps with following: + 1) ld1q and st1q first register operand accepts enclosed figure braces. + 2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping + sequence of vector registers. + + For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector + registers are added along with short-form of operands for non-wrapping sequence. + + I have added test using following logic: + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #0, MUL VL] //raw insn encoding (all zeroes) + ld2q {Z31.Q, Z0.Q}, p0/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of (low value) + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of (high value) + ld2q {Z31.Q, Z0.Q}, p7/Z, [x30, #-16, MUL VL] // encoding of all fields (all ones) + ld2q {Z30.Q, Z31.Q}, p1/Z, [x3, #-2, MUL VL] // random encoding. + + For all the above form of instructions the hyphenated form is preferred for + disassembly if there are more than two registers in the list, and the register + numbers are monotonically increasing in increments of one. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 extq instruction operands. + This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands + count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th + argument an 4-bit unsigned immediate of extq instruction. The instruction encoding + is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately + precede in program order by a MOVPRFX instruction. Also removed the unused operand + AARCH64_OPND_SVE_Zm_imm4. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 dupq instruction operands. + This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way + 2nd operand does the encoding and decoding using the [] value. + + dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index + inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter) + and aarch64_ext_sve_index_imm (extractor) is removed in this patch. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Enable mandatory feature bits for v9.4-A. + This patch fixes the mandatory feature bits in v9.4-a architectures, + by enabling FEAT_SVE2p1 for Armv9.4-A architecture by default. + +2024-06-25 Nick Clifton + + Revert 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c + PR 20880 + + Fix calculation of space remaining in buffer when printing the contents of a DST__K_RECBEG type debug symbol for the VMS Alpha port. + PR 31873 + +2024-06-25 Schimpe, Christina + + gdb: use alternative for demangled name for non-demangeable linkage names + In case a DIE contains a linkage name which cannot be demangled and + a source language name (DW_AT_NAME) exists then we want to display this name + instead of the non-demangeable linkage name. + + dwarf2_physname returns the linkage name in case the linkage name + cannot be demangled. Before this patch we always set the returned physname + as demangled name. This patch changes this by comparing the value + of physname with the linkage name. Now after this change in case it is equals + to the linkage name and if DW_AT_NAME exists then this is set as the demangled + name otherwise like before still linkage name is used. + + For the reproducer, using the test source file added in this change: + "gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c" + + Here is an example of the DWARF where wrong linkage name is emitted by the + compiler for the "func_demangled_test" function: + + subprogram { + {MACRO_AT_range {func_demangled_test}} + {linkage_name "_FUNC_WRONG_MANGLED__"} + {name "func_demangled_test"} + {external 1 flag} + } + subprogram { + {MACRO_AT_range {main}} + {external 1 flag} + {name main} + {main_subprogram 1 flag} + } + + Before this change for a function having both DIEs DW_AT_name and + DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace + command shows following: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + (gdb) backtrace + \#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + \#1 0x000055555555514a in main () + + After the change now GDB shows the name emitted by DW_AT_NAME: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in func_demangled_test () + (gdb) backtrace + \#0 0x0000555555555131 in func_demangled_test () + \#1 0x000055555555514a in main () + + A new test is added to verify this change. + + Approved-By: Tom Tromey + +2024-06-25 Szabolcs Nagy + + aarch64: Add DT_RELR tests for ILP32 ABI + + aarch64: Add DT_RELR support for ILP32 ABI + Extend the 64bit DT_RELR support to work on 32bit ELF too. For this + only a few changes were needed in the sizing and creation of the + relr relocations. + +2024-06-25 Tom de Vries + + [gdb/symtab] Remove dead code in parse_macro_definition + In parse_macro_definition, there's a loop: + ... + for (p = body; *p; p++) + if (*p == ' ' || *p == '(') + break; + ... + whose post-condition is: + ... + gdb_assert (*p == ' ' || *p == '(' || *p == '\0'); + ... + + Consequently, in the following: + ... + if (*p == ' ' || *p == '\0') + + else if (*p == '(') + + else + + ... + BODY3 is dead code. + + Remove it, and get rid of unnecessary indentation by using an early-exit: + .... + if (*p == ' ' || *p == '\0') + { + + return; + } + + gdb_assert (*p == '('); + + ... + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-06-25 GDB Administrator + + Automatic date update in version.in + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware breakpoint + LoongArch defines hardware watchpoint functions for fetch operations. + After the software configures the watchpoints for fetch, the processor + hardware will monitor the access addresses of the fetch operations and + trigger a watchpoint exception when the watchpoint setting conditions + are met. + + Hardware watchpoints for fetch operations is used to implement hardware + breakpoint function on LoongArch. Refer to the following document for + hardware breakpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + No hardware breakpoint support in the target. + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8. + (gdb) c + Continuing. + start test + a = 1 + + Breakpoint 2, main () at test.c:8 + 8 printf("end test\n"); + (gdb) c + Continuing. + end test + [Inferior 1 (process 25378) exited normally] + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware watchpoint + LoongArch defines hardware watchpoint functions for load/store + operations. After the software configures the watchpoints for + load/store, the processor hardware will monitor the access + addresses of the load/store operations and trigger watchpoint + exception when the watchpoint setting conditions are met. + + After this patch, watch/rwatch/awatch command are supported. Refer to the + following document for hardware watchpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Target does not support this type of hardware watchpoint. + ... + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Hardware access (read/write) watchpoint 2: a + (gdb) c + Continuing. + start test + + Hardware access (read/write) watchpoint 2: a + + Old value = 0 + New value = 1 + main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + + Hardware access (read/write) watchpoint 2: a + + Value = 1 + 0x00000001200006e0 in main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + a = 1 + end test + [Inferior 1 (process 22250) exited normally] + +2024-06-24 Hannes Domani + + Fix gdb.lookup_type for function-local types + Looking for a type defined locally in a function doesn't work + any more since the introduction of TYPE_DOMAIN: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Python Exception : No type named main()::Local. + Error occurred in Python: No type named main()::Local. + ``` + + cp_search_static_and_baseclasses was simply missing a check for + SEARCH_TYPE_DOMAIN, now it works again: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Local + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922 + Approved-By: Tom Tromey + +2024-06-24 Andrew Carlotti + + aarch64: Add SME FP8 multiplication instructions + This includes: + - FEAT_SME_F8F32 (+sme-f8f32) + - FEAT_SME_F8F16 (+sme-f8f16) + + The FP16 addition/subtraction instructions originally added by + FEAT_SME_F16F16 haven't been added to Binutils yet. They are also + required to be enabled if FEAT_SME_F8F16 is present, so they are + included in this patch. + +2024-06-24 Andrew Carlotti + + aarch64: Add FP8 Neon and SVE multiplication instructions + This includes all the instructions under the following features: + - FEAT_FP8FMA (+fp8fma) + - FEAT_FP8DOT4 (+fp8dot4) + - FEAT_FP8DOT2 (+fp8dot2) + - FEAT_SSVE_FP8FMA (+ssve-fp8fma) + - FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4) + - FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2) + +2024-06-24 Andrew Carlotti + + aarch64: Add support for virtual features + These features will be used to gate instructions that can be enabled by + either of two (or more) different sets of command line feature flags. + + This patch add a postprocessing step to the feature parsing code to + set the value of the virtual bits. + +2024-06-24 Andrew Carlotti + + aarch64: Move struct definition towards its usage + +2024-06-24 Tom Tromey + + Prefer htab_traverse_noresize + A few spots in gdb were using htab_traverse. IMO this is almost never + useful and htab_traverse_noresize should be preferred. + +2024-06-24 Tom Tromey + + Remove hashtab_obstack_allocate + I think that hashtabs should never be obstack-allocated. In the past + this was convenient sometimes, because any new data structure needed a + corresponding cleanup. However, with the switch to C++, resource + management has become much simpler; for example, a local variable can + simply be of type htab_up rather than hashtab_t, and the problem is + solved. + + This patch removes hashtab_obstack_allocate to try to prevent this + anti-pattern from being used again. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the call site hash table + The call site hash table is the last hash table using obstack + allocation. In one large (non-public) test case, these hash tables + take a substiantial amount of memory. Some of this memory is wasted + -- whenever the hash table is resized, the old table is not freed. + + This patch fixes the problem by changing this hash table to be + heap-allocated. This means that resizing will no longer "leak" + memory. + +2024-06-24 Tom Tromey + + Add compunit_symtab::forget_cached_source_info + It seemed cleaner to me for compunit_symtab to have a + forget_cached_source_info method, then for the objfile to know how to + do this. + + Make symtab members private + This rearranges symtab so that the private members appear at the end, + and then adds the "private" keyword. + + Rename symtab::fullname + This renames symtab::fullname to m_fullname and adds new accessor + methods. + + Don't obstack-allocate the CU dependency hash table + The CU dependency hash table is obstack-allocated, but there's no need + to do this. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the DIE hash + The DIE hash table is currently allocated on an obstack. There's no + need to do this, and I think it's better to simply heap-allocate the + hash table. + + This patch implements this. I also removed store_in_ref_table as + well, inlining it into its sole caller, as I think this is clearer. + +2024-06-24 Harmen Stoppels + + libdep plugin: fix bugs in parser and drop escaping + PR ld/31906 + * libdep_plugin.c (str2vec): Fix bug where null byte was not copied on memmove during quote handling and escaping, causing repeat of the last character in the last argument. + Fix buffer overflow in **res when arguments were separated by `\t` instead of ` `. + Remove handling of the escape character `\`, as it made it impossible to specify paths containing `\` + -- the implementation merely dropped `\`, and was affected by the memmove bug, so this should not be breaking; just single and double quotes are sufficient to deal with white space and quote characters, there is no need for escaping. + Handle syntax errors on unterminated quotes. + Make the parser linear time instead of quadratic. + +2024-06-24 Nick Clifton + + Updated Spanish translations for the bfd and binutils sub-directories + + ld: Improve the documentation describing the -o option. + PR 31761 + +2024-06-24 saurabh.jha@arm.com + + gas, aarch64: Add SME2 lutv2 extension + Introduces instructions for the SME2 lutv2 extension for AArch64. They + are documented in the following document: + + * ARM DDI0602 + + For both luti4 instructions, we introduced an operand called + SME_Znx2_BIT_INDEX. We use the existing function parse_vector_reg_list + for parsing but modified that function so that it can accept operands + without qualifiers and rejects instructions that have operands with + qualifiers but are not supposed to have operands with qualifiers. + For disassembly, we modified print_register_list so that it could + accept register lists without qualifiers. + + For one luti4 instruction, we introduced a SME_Zdnx4_STRIDED. It is + similar to SME_Ztx4_STRIDED and we could use existing code for parsing, + encoding, and disassembly. + + For movt instruction, we introduced an operand called SME_ZT0_INDEX2_12. + This is a ZT0 register with a bit index encoded in [13:12]. It is + similar to SME_ZT0_INDEX. + + We also introduced an iclass named sme_size_12_b so that we can encode + size bits [13:12] correctly when only 'b' is allowed as qualifier. + +2024-06-24 Martin Simmons + + Include needed unordered_map header + Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level + configure options --with-python=/usr/local/bin/python3.9 gives this error: + + CXX ada-exp.o + ./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std' + std::unordered_map> + ~~~~~^ + 1 error generated. + + This change fixes it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918 + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of pdf and dvi files + When building with 'make -j20 -C gdb/doc all-doc' I often see problems + caused from trying to build some dvi files in parallel with some pdf + files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and + stabs.pdf; and annotate.dvi and annotate.pdf. + + The problem is that building these files create temporary files in the + local directory. There's already a race here that two make threads + might try to create these files at the same time. + + But it gets worse, to avoid issues where a failed build could leave + these temporary files in a corrupted state, and so prevent the next + build from succeeding, the recipe for each of these files deletes all + the temporary files first, this obviously causes problems if some + other thread has already started the build and is relying on these + temporary files. + + To work around this problem I propose we start using the --build and + --build-dir options for texi2dvi (which is the same tool used to + create the pdf files). These options were added in texinfo 4.9 which + was released in June 2007. We already require using a version of + texinfo after 4.9 (I tried to build with 4.13 and the doc build failed + as some of the texinfo constructs were not understood), so this patch + has not changed the minimum required version at all. + + The --build flag allows the temporary files to be placed into a + sub-directory, and the --build-dir option allows us to control the + name of that sub-directory. + + What we do is create a unique sub-directory for each target that + invokes texi2dvi, all of the unique sub-directories are created within + a single directory texi2dvi_tmpdir, and so after a complete doc build, + we are left with a build tree like this: + + build/gdb/doc/ + '-- texi2dvi_tmpdir/ + |-- annotate_dvi/ + |-- annotate_pdf/ + |-- gdb_dvi/ + |-- gdb_pdf/ + |-- stabs_dvi/ + '-- stabs_pdf/ + + I've left out all the individual files that live within these + directories for simplicity. + + To avoid corrupted temporary files preventing a future build to + complete, each recipe deletes its associated sub-directory from within + texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh + start each time. + + And the mostlyclean target deletes texi2dvi_tmpdir/ and all its + sub-directories, ensuring that everything is cleaned up. + + For me, with this fix in place, I can now run 'make -j20 -C gdb/doc + all-doc' without seeing any build problems. + + Approved-By: Pedro Alves + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of refcard related targets + There are two problems we encounter when trying to build the refcard + related target in parallel, i.e.: + + $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf + + These problems are: + + (1) The refcard.dvi and refcard.pdf targets both try and generate the + tmp.sed and sedref.tex files. If two make threads end up trying + to create these files at the same time then the result is these + files become corrupted. + + I've fixed this by creating a new rule that creates sedref.tex, + both refcard.dvi and refcard.pdf now depend on this, and make will + build sedref.tex just once. The tmp.sed file is now generated as + refcard.sed, this is generated and deleted as a temporary file + within the sedref.tex recipe. + + (2) Having created sedref.tex the recipes for refcard.dvi and + refcard.pdf both run various LaTeX based tools with sedref.tex as + the input file. The problem with this is that these tools all + rely on creating temporary files calls sedref.*. + + If the refcard.dvi and refcard.pdf rules run at the same time then + these temporary files clash and overwrite each other causing the + build to fail. + + We already copy the result file in order to rename it, our input + file is sedref.tex which results in an output file named + sedref.dvi or sedref.pdf, but we actually want refcard.dvi or + refcard.pdf. So within the recipe for refcard.dvi I copy the + input file from sedref.tex to sedref_dvi.tex. Now all the temp + files are named sedref_dvi.* and the output is sedref_dvi.dvi, I + then rename this new output file to refcard.dvi. + + I've done the same thing for refcard.pdf, but I copy the input + to sedref_pdf.tex. + + In this way the temp files no longer clash, and both recipes can + safely run in parallel. + + After this commit I was able to reliably build all of the refcard + targets in parallel. There should be no change in the final file. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: also look in srcdir when running TEXI2POD + In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke + texi2pod.pl, which process the .texinfo files. This also handles the + 'include' directives within the .texinfo files. + + Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag + to add search directories for resolving 'include' directives within + .texinfo files. + + When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes + GDBvn.texi. + + When building from a git checkout the gdb-cfg.texi files and + GDBvn.texi files will be created in the build directory, which is + where texi2pod.pl is invoked, so the files will be found just fine. + + However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the + source tree, along with the generated manual (.1 and .5) files. + + So when building a release, what normally happens is that we spot that + the .1 and .5 man files are up to date, and don't run the recipe to + regenerate these files. + + However, if we deliberately touch the *.texinfo files in a release + source tree, and then try to rebuild the man files, we'll get an error + like this: + + make: Entering directory '/tmp/release-build/build/gdb/doc' + TEXI2POD gdb.1 + cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make: *** [Makefile:664: gdb.1] Error 2 + make: Leaving directory '/tmp/release-build/build/gdb/doc' + + The problem is that texi2pod.pl doesn't know to look in the source + tree for the GDBvn.texi file. + + If we compare this to the recipe for creating (for example) gdb.dvi, + which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi + command line, which allows texi2dvi to find GDBvn.texi in the source + tree. + + In this commit I add a similar -I option to the texi2pod.pl command + line. After this, given a GDB release, it is possible to edit (or + just touch) the gdb.texinfo file and rebuild the man pages, the + GDBvn.texi will be picked up from the source tree. + + If however a dependency for GDBvn.texi is changed in a release tree + then GDBvn.texi will be regenerated into the build directory and this + will be picked up in preference to the GDBvn.texi in the source tree, + just as you would want. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: allow for version.subst in the source tree + In a git checkout of the source code we don't have a version.subst + file in the gdb/doc directory. When building the GDB docs the + version.subst file is generated on demand (we have a recipe for that). + + However, in a release tar file we do include a copy of the + version.subst file in the source tree, as a result the version.subst + recipe will not be run. + + If, in a release build, we force the running of any recipe that + depends on version.subst then we run into a problem. For example, + slightly confusingly, if we 'touch gdb/doc/version.subst' within the + unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' + in the build tree, we'll see: + + make: Entering directory '/tmp/build/build/gdb/doc' + GEN GDBvn.texi + sed: can't read version.subst: No such file or directory + make: Leaving directory '/tmp/build/build/gdb/doc' + + The problem is that every reference to version.subst in GDB's Makefile + assumes that the version.subst file will always be in the build + directory. + + Handily version.subst is always the first dependency in every recipe + that uses that file. As such we can replace references to + version.subst with $<, make will expand this to the location where the + dependency was found. + + In the case of the man page generation, the reference to version.subst + is hidden inside POD2MAN. It seemed a little confusing adding a use + of $< within POD2MAN, so I've moved the use into the recipe, which I + think is clearer. + + I've also added comments for the two rules that I've modified to + explain our use of $<. + + After this change it is possible to rebuild the man pages even when + version.subst is located in the source tree. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: merge rules for building .1 and .5 man pages + We have two rules, one each for building the .1 and .5 man pages. The + only actual difference is that one rule passes --section=1 and the + other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5 + respectively. + + I figure by using the suffix from the target of the rule we can + combine these two rules into one. + + I use: + + $(subst .,,$(suffix $@)) + + This gets the suffix from the target, either '.1' or '.5', and the + 'subst' removes the '.' leaving '1' or '5'. + + Now that I'm not using a static pattern rule for building the man + pages, the advice in the 'make' documentation is to not use $*, so + I've moved away from that to instead use $(basename $@), e.g. for + 'gdbinit.5' this gives 'gdbinit', which is what we want. + + There should be no difference in what is created after this change. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: don't try to copy GDBvn.texi from the source tree + The build recipe for gdb.dvi and gdb.pdf contains instructions for + copying the GDBvn.texi file from the source tree into the build + directory if the GDBvn.texi file doesn't already exist in the build + directory. + + The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi, + and we have a recipe for building GDBvn.texi. + + What's happening here is this: + + - In a git checkout of the source tree there is no GDBvn.texi in the + source tree, the GDBvn.texi dependency will trigger a rebuild of + GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf. + + - In a release tar file we do include a copy of GDBvn.texi. This + file will appear to be up to date, and so no copy of GDBvn.texi is + created within the build directory. Now when building gdb.dvi + and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from + the source tree into the build directory. + + However, copying GDBvn.texi from the source directory is completely + unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and + pass '-I $(srcdir)' as an argument, this means that texi2dvi will look + in the $(srcdir) to find included files, including GDBvn.texi. + + As such I believe we can remove the code that copies GDBvn.texi from + the source tree into the build tree. + + I've tested with a release build; creating a release with: + + ./src-release gdb + + Then in an empty directory, unpacking the resulting .tar file, + creating a parallel build directory and doing the usual configure, + make, and 'make install'. + + Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked + source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf + and dvi files, this works fine without having to either build or copy + GDBvn.texi into the build directory. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/i386: fix tdesc rejection issue for targets without PTRACE_GETREGSET + After the x86 target description changes that I committed recently, + the first commit in the series being: + + commit 8a29222b85f28a2201db50a34ac4144f961311db + Date: Sat Jan 27 10:40:35 2024 +0000 + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + + and the last commit in the series being: + + commit 646d754d14c2fe70a492a893506a74b0463b6ae8 + Author: Andrew Burgess + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + The sourceware buildbot highlighted a regression on i386. On the GDB + side we'd see this: + + Remote debugging using :54321 + warning: Architecture rejected target-supplied description + Remote connection closed + (gdb) + + while on the gdbserver side we'd see this: + + $ ./gdbserver/gdbserver --once :54321 ~/empty + Process /srv/aburgess/empty created; pid = 31406 + Listening on port 54321 + Remote debugging from host ::1, port 39488 + ../../src/gdbserver/regcache.cc:272: A problem internal to GDBserver has been detected. + Unknown register st0 requested + Aborted (core dumped) + + When I tried to reproduce this regression on my local i386 VM the + issue would not reproduce. + + I eventually tracked the problem down to x86_linux_tdesc_for_tid in + gdb/nat/x86-linux-tdesc.c. In this function we have this line: + + /* Check if PTRACE_GETREGSET works. */ + if (ptrace (PTRACE_GETREGSET, tid, + (unsigned int) NT_X86_XSTATE, &iov) < 0) + { + ... handle failure ... + } + else + { + ... handle success ... + } + + The problem is that on my VM the PTRACE_GETREGSET feature is + supported, while on sourceware's buildbot machine this feature is not + supported. + + I did a quick search and it seems like the 'xsave' feature in + /proc/cpuinfo might be the indicator for whether PTRACE_GETREGSET is + supported or not, and indeed my machine has the 'xsave' feature while + the sourceware machine does not. + + The point of divergence then is this ptrace call, on my machine the + call succeeds and we extract the xcr0 value from the iov vector, while + on the sourceware machine the ptrace call fails and we use a default + xcr0 value of 0. + + This xcr0 value is then passed to i386_linux_read_description at the + end of x86_linux_tdesc_for_tid. + + In gdb/arch/i386-linux-tdesc.c we find i386_linux_read_description + which does some caching but calls i386_create_target_description to + actually create the target descriptions when needed. The xcr0 value + is masked to only the bits that are interesting, but given a value of + 0 we'll just pass 0 through to i386_create_target_description. + + In gdb/arch/i386.c we find i386_create_target_description which checks + the xcr0 bits and builds the target description. What we can see is + that if no bits are set in the xcr0 value then no features will be + added to the created target description. This featureless target + description is then transmitted back to GDB, which is then rejected + due to lack of essential core registers. + + So, how did things work prior to the above commit series? There are + three places of interest, on the GDB side there is + x86_linux_nat_target::read_description and + i386_linux_core_read_description. Then on the gdbserver side there is + x86_linux_read_description. + + All of these locations have a call to i386_linux_read_description + followed by a check if the return value was nullptr. If we do get + back nullptr then we perform another call to + i386_linux_read_description with a default xcr0 value. + + Looking in i386_linux_read_description we see a specific check for + xcr0 being 0 in which case we return nullptr. + + And so, prior to the above series, if xcr0 was 0 due to + PTRACE_GETREGSET being unavailable we'd use a default xcr0 value. + + After the above series this is no longer the case, the 'xcr0 == 0' + check has been removed from i386_linux_read_description and the + calling code is streamlined to remove the use of default xcr0 values. + + The fix I propose here is to setup the default xcr0 value at the point + where we find that PTRACE_GETREGSET is unavailable. The default value + used is X86_XSTATE_SSE_MASK. This is the default used in + x86_linux_nat_target::read_description (for GDB) and in + x86_linux_read_description (for gdbserver). The above commit series + already fixed i386_linux_core_read_description to ensure that the + correct default xcr0 value was used, this case is a little special in + that it uses different defaults depending on which sections are + present in the core file, so that case always needed to be handled + differently. + + The choice of X86_XSTATE_SSE_MASK corresponds to the default used for + i386 before the above series was committed. This mask includes the + X87 and SSE bits only, neither of these bits are checked for on amd64 + or x32, so this default doesn't change the behaviour on these targets. + + By setting the default xcr0 value at this early stage we ensure that + the cached xcr0 value on the gdbserver side is correct. This is + critical as this cached xcr0 value is passed through to the in process + agent (IPA). If we leave the cached xcr0 value as 0 and apply the + defaults later in the series we also have to encode the knowledge of + the default into the IPA, this just means we have the default encoded + in multiple locations, which seems like a bad idea. The approach used + in this patch means the default is present in just one location. + + This commit should fix the i386 regressions seen on the sourceware + buildbot. + + In addition to the fix in nat/x86-linux-tdesc.c I've also fixed the + layout of the declaration of x86_linux_tdesc_for_tid in the header + file. + + Approved-By: Felix Willgerodt + +2024-06-24 GDB Administrator + + Automatic date update in version.in + +2024-06-23 Andrew Carlotti + + aarch64: Enable +cssc for armv8.9-a + FEAT_CSSC is mandatory in the architecture from Armv8.9. + +2024-06-23 GDB Administrator + + Automatic date update in version.in + +2024-06-22 Simon Marchi + + gdb/testsuite: analyze-racy-logs.py cleanup + - Add type annotations + - Use a raw string in one spot (where we call re.sub), to avoid an + "invalid escape sequence" warning. + - Remove unused "os" import. + + Change-Id: I0149cbb73ad2b05431f032fa9d9530282cb01e90 + Reviewed-By: Guinevere Larsen + +2024-06-22 GDB Administrator + + Automatic date update in version.in + +2024-06-21 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.threads/stepi-over-clone.exp + On fedora rawhide, I ran into: + ... + (gdb) continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), 0x000000000042097d in __clone3 ()^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating a regexp to also recognize __clone3. + + Tested on x86_64-linux. + + Tested-By: Guinevere Larsen + +2024-06-21 Pedro Alves + + [gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux + When running test-case gdb.base/watchpoint-running on ppc64le-linux (and + similar on arm-linux), we get: + ... + (gdb) watch global_var^M + warning: Error when detecting the debug register interface. \ + Debug registers will be unavailable.^M + Watchpoint 2: global_var^M + (gdb) FAIL: $exp: all-stop: hardware: watch global_var + FAIL: $exp: all-stop: hardware: watchpoint hit (timeout) + ... + + The problem is that ppc_linux_dreg_interface::detect fails to detect the + hardware watchpoint interface, because the calls to ptrace return with errno + set to ESRCH. + + This is a feature of ptrace: if a call is done while the tracee is not + ptrace-stopped, it returns ESRCH. + + Indeed, in the test-case "watch global_var" is executed while the inferior is + running, and that triggers the first call to ppc_linux_dreg_interface::detect. + + And because the detection failure is cached, subsequent attempts at setting + hardware watchpoints will also fail, even if the tracee is ptrace-stopped. + + The way to fix this is to make sure that ppc_linux_dreg_interface::detect is + called when we know that the thread is ptrace-stopped, which in the current + setup is best addressed by using target-specific post_attach and + post_startup_inferior overrides. However, as we can see in + aarch64_linux_nat_target, that causes code duplication. + + Fix this by: + - defining a new target hook low_init_process, called from + linux_init_ptrace_procfs, which is called from both + linux_nat_target::post_attach and linux_nat_target::post_startup_inferior, + - adding implementations for ppc_linux_nat_target and arm_linux_nat_target + that detect the hardware watchpoint interface, + - replacing the aarch64_linux_nat_target implementations of post_attach and + post_startup_inferior with a low_init_process implementation. + + Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Luis Machado + + PR tdep/31834 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834 + PR tdep/31705 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705 + +2024-06-21 Jan Beulich + + x86: optimize {,V}PEXTR{D,Q} with immediate of 0 + Such are equivalent to simple moves, which are up to 3 bytes shorter to + encode (and perhaps also cheaper to execute). + +2024-06-21 Jan Beulich + + x86: optimize left-shift-by-1 + These can be replaced by adds when acting on a register operand. + + While for the scalar forms there's no gain in encoding size, ADD + generally has higher throughput than SHL. EFLAGS set by ADD are a + superset of those set by SHL (AF in particular is undefined there). + + For the SIMD cases the transformation also reduced code size, by + eliminating the 1-byte immediate from the resulting encoding. Note + that this transformation is not applied by gcc13 (according to my + observations), so would - as of now - even improve compiler generated + code. + +2024-06-21 Jan Beulich + + x86/APX: fix disassembly of byte register operands + Like for REX/REX2, EVEX-prefixed insns access the low bytes of all + registers; %ah...%bh are inaccessible. Reflect this correctly in output, + by leveraging REX machinery we already have to this effect. + + x86: %riz, %rip, and %eip don't require REX + While these can't be used as register operands, they can be used for + memory operand addressing. Such uses do not prevent conversion: The + RegRex64 checks in check_Rex_required() for base and index registers + were simply wrong. They specifically also aren't needed for byte + registers, as those won't pass i386_index_check() anyway. + + x86: don't suppress errors when optimizing + Blindly ignoring any mnemonic suffix can't be quite right: Bad suffix / + operand combinations still want flagging. Simply avoid optimizing in + such situations. + +2024-06-21 Jan Beulich + + gas: terminate buffer SB in do_repeat() + PR gas/31903 + + While elsewhere having realized that "one" doesn't point to a nul- + terminated string, it somehow didn't occur to me that the pre-existing + strstr() could have been wrong, and hence I blindly added a new use of + the function. Add the (already prior to 1e3c814459d8 ["gas: extend \+ + support to .rept"]) missing call to sb_terminate(), leveraging that to + simplify the other two places where the lack of nul termination was + previously worked around. + +2024-06-21 Feng Wang + + RISC-V: Remove implicit enablement of Zvknha from Zvkn. + Accroding to the Crypto spec, the Zvkned,Zvknhb,Zvkb and Zvkt are + included in the Zvkn. So the Zvknha should be removed from Zvkn. + + bfd/ChangeLog: + + * elfxx-riscv.c: Remove zvknha from zvkn. + +2024-06-21 GDB Administrator + + Automatic date update in version.in + +2024-06-20 Tom Tromey + + Handle "info symbol" in Rust language mode + When I changed the Rust parser to handle 128-bit ints, this + inadvertently broke some other gdb commands. For example, "info + symbol 0xffffffffffffffff" now fails, because the resulting value is + 128 bits, but this is rejected by extract_integer. + + This patch fixes the problem by changing extract_integer to allow + over-long integers as long as the high bytes are either 0, or (for + signed types) 0xff. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565 + Approved-By: Andrew Burgess + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-address.exp on arm + When running test-case gdb.python/py-format-address.exp on arm-linux, I get: + ... + (gdb) python print("Got: " + gdb.format_address(0x103dd))^M + Got: 0x103dd
^M + (gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \ + result should have an offset + ... + + What is expected here is: + ... + Got: 0x103dd ^M + ... + + Main starts at main_addr: + ... + (gdb) print /x &main^M + $1 = 0x103dc^M + ... + and we obtained next_addr 0x103dd by adding 1 to it: + ... + set next_addr [format 0x%x [expr $main_addr + 1]] + ... + + Adding 1 to $main_addr results in an address for a thumb function starting at + address 0x103dc, which is incorrect because main is an arm function (because + I'm running with target board unix/-marm). + + At some point during the call to format_addr, arm_addr_bits_remove removes + the thumb bit, which causes the +1 offset to be dropped, causing the FAIL. + + Fix this by using the address of the breakpoint on main, provided it's not at + the very start of main. + + Tested on arm-linux. + + PR testsuite/31452 + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31452 + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.base/watchpoint-unaligned.exp + When running test-case gdb.base/watchpoint-unaligned.exp on ppc64le-linux, we + get: + ... + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(4) + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(7) + ... + + Fix this by using foreach_with_prefix. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.opt/inline-cmds.exp + With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into: + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker + ... + + Fix this by issuing less passes. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/huge.exp + With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I + ran into a number of duplicates: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + DUPLICATE: gdb.fortran/huge.exp: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Fix this by wrapping the compile in a with_test_prefix, getting us instead: + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Tested on x86_64-linux. + +2024-06-20 Alan Modra + + Revert "Remove LIBINTL_DEP" + This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. + The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext. + +2024-06-20 Alan Modra + + Remove LIBINTL_DEP + The intl directory in the source no longer exists. LIBINTL_DEP is + thus always empty. Remove references to it. + + config/ + * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. + bfd/ + * Makefile.in: Regenerate. + * configure: Regenerate. + binutils/ + * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gas/ + * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gdb/ + * Makefile.in (INTL_DEPS): Don't set or reference. + * configure: Regenerate. + gdbserver/ + * Makefile.in (INTL_DEPS): Don't set or reference. + gdbsupport/ + * Makefile.in: Regenerate. + * configure: Regenerate. + gold/ + * Makefile.am (deps_var): Remove LIBINTL_DEP. + (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. + * Makefile.in: Regenerate. + * configure: Regenerate. + * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. + * testsuite/Makefile.in: Regenerate. + gprof/ + * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + ld/ + * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + libctf/ + * Makefile.in: Regenerate. + * configure: Regenerate. + opcodes/ + * configure.ac (BUILD_LIBS): Remove LIBINTL. + (BUILD_LIB_DEPS): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + +2024-06-20 Xi Ruoyao + + LoongArch: TLS IE needs only one dynamic reloc + As the comment in the code says, TLS_IE needs only one dynamic reloc. + But commit b67a17aa7c0c ("LoongArch: Fix the issue of excessive + relocation generated by GD and IE") has incorrectly allocated the space + for two dynamic relocs, causing libc.so to contain 8 R_LARCH_NONE. + + Adjust tlsdesc-dso.d for the offset changes and add two tests to ensure + there are no R_LARCH_NONE with TLS. + +2024-06-20 GDB Administrator + + Automatic date update in version.in + +2024-06-20 H.J. Lu + + ld: Remove JANSSON_LIBS from ld_new_DEPENDENCIES + Remove JANSSON_LIBS from ld_new_DEPENDENCIES since ld_new_DEPENDENCIES + should only contain binutils dependencies. + + PR ld/31909 + * Makefile.am (ld_new_DEPENDENCIES): Remove JANSSON_LIBS. + * Makefile.in: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/build] Redo poisoning of PyObject_CallMethod + In commit 764af878259 ("[gdb/python] Add typesafe wrapper around + PyObject_CallMethod") I added poisoning of PyObject_CallMethod: + ... + /* Poison PyObject_CallMethod. The typesafe wrapper gdbpy_call_method should be + used instead. */ + template + PyObject * + PyObject_CallMethod (Args...); + ... + + The idea was that subsequent code would be forced to use gdbpy_call_method + instead of PyObject_CallMethod. + + However, that caused build issues with gcc 14 and python 3.13: + ... + /usr/bin/ld: python/py-disasm.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, unsigned int, long long)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x384f): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, unsigned int, long long>(_object*, char*, char*, unsigned int, long long)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x1235): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int>(_object*, char*, char*, int)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int, int, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x12b0): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int, int, int>(_object*, char*, char*, int, int, int)' + collect2: error: ld returned 1 exit status + ... + + Fix this by poisoning without using templates. + + Tested on x86_64-linux. + +2024-06-19 Tom de Vries + + [gdb/symtab] Fix target type of complex long double on arm + When running test-case gdb.base/complex-parts.exp on arm-linux, I get: + ... + (gdb) p $_cimag (z3)^M + $6 = 6.5^M + (gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3) + ptype $^M + type = double^M + (gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $ + ... + + Given that z3 is a complex long double, the test-case expects the type of the + imaginary part of z3 to be long double, but it's double instead. + + This is due to the fact that the dwarf info doesn't specify an explicit target + type: + ... + <5b> DW_AT_name : z3 + <60> DW_AT_type : <0xa4> + ... + <1>: Abbrev Number: 2 (DW_TAG_base_type) + DW_AT_byte_size : 16 + DW_AT_encoding : 3 (complex float) + DW_AT_name : complex long double + ... + and consequently we're guessing in dwarf2_init_complex_target_type based on + the size: + ... + case 64: + tt = builtin_type (gdbarch)->builtin_double; + break; + case 96: /* The x86-32 ABI specifies 96-bit long double. */ + case 128: + tt = builtin_type (gdbarch)->builtin_long_double; + break; + ... + + For arm-linux, complex long double is 16 bytes, so the target type is assumed + to be 8 bytes, which is handled by the "case 64", which gets us double + instead of long double. + + Fix this by searching for "long" in the name_hint parameter, and using long + double instead. + + Note that base types in dwarf are not allowed to contain references to other + types, and the complex types are base types, so the missing explicit target + type is standard-conformant. + + A gcc PR was filed to add this as a dwarf extension ( + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ). + + Tested on arm-linux. + +2024-06-19 Nick Alcock + + libctf: fix testsuite bugs revealed by -Wall + Most of these are harmless, but some of the type confusions and especially + a missing ctf_strerror() on an error path were actual bugs that could + have resulted in test failures crashing rather than printing an error + message. + + libctf/ + * testsuite/libctf-lookup/enumerator-iteration.c: Fix type + confusion, signedness confusion and a missing ctf_errmsg(). + * testsuite/libctf-regression/libctf-repeat-cu-main.c: Return 0 from + the test function. + * testsuite/libctf-regression/open-error-free.c: Fix signedness + confusion. + * testsuite/libctf-regression/zrewrite.c: Remove unused label. + +2024-06-19 Lancelot SIX + + gdb/python/python-internal.h: avoid uninitialized constexpr + The following recent change introduced a regression when building using + clang++: + + commit 764af878259768bb70c65bdf3f3285c2d6409bbd + Date: Wed Jun 12 18:58:49 2024 +0200 + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + + The error message is: + + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + CXX python/py-block.o + 1 error generated. + make[2]: *** [Makefile:1959: python/py-arch.o] Error 1 + make[2]: *** Waiting for unfinished jobs.... + In file included from ../../gdb/python/py-auto-load.c:25: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + make[2]: *** [Makefile:1959: python/py-auto-load.o] Error 1 + In file included from ../../gdb/python/py-block.c:23: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + + This patch fixes this by changing gdbpy_method_format to be a templated + struct, and only have its specializations define the static constexpr + member "format". This way, we avoid having an uninitialized constexpr + expression, regardless of it being instantiated or not. + + Reviewed-By: Tom de Vries + Change-Id: I5bec241144f13500ef78daea30f00d01e373692d + +2024-06-19 Cui, Lili + + x86: Remove the secondary encoding for ctest. + There are two encodings for each opcode F6/F7 in ctest, but the second one + is never used, so remove it to reduce the size of opcode_tbl.h. + + opcodes/ChangeLog: + + * i386-opc.tbl: Removed the secondary insn template for ctest. + * i386-tbl.h: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x + On s390x-linux, I run into: + ... + (gdb) p (short []) s1^M + $3 = {0, 1, 0, }^M + (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + while this is expected: + ... + (gdb) p (short []) s1^M + $3 = {1, 0, 0, }^M + (gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + + The type of s1 is: + ... + (gdb) ptype s1 + type = struct S { + myint a; + myushort b; + } + ... + so the difference is due the fact that viewing an int as two shorts gives + different results depending on the endianness. + + Fix this by allowing both results. + + Tested on x86_64-linux and s390x-linux. + + Approved-By: Tom Tromey + +2024-06-19 Tom de Vries + + [gdb/testsuite] Add string cat for tcl version < 8.6.2 + I noticed that we started using "string cat", which has been available since + tcl version 8.6.2. + + Add a local implementation for use with older tcl versions. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-06-19 Tom de Vries + + [gdb/tdep] Simplify ARM_LINUX_JB_PC_EABI + In commit 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI"), in absense of + osabi settings for newlib and uclibc for arm, I chose a best-effort approach + using ifdefs. + + Post-commit review [1] pointed out that this may be causing more problems than + it's worth. + + Fix this by removing the ifdefs and simply defining ARM_LINUX_JB_PC_EABI to 1. + + Rebuild on x86_64-linux with --enable-targets=all. + + Fixes: 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI") + + [1] https://sourceware.org/pipermail/gdb-patches/2024-June/209779.html + +2024-06-19 GDB Administrator + + Automatic date update in version.in + +2024-06-18 Tom de Vries + + [gdb/build] Add GPL header comment to gdb/features/feature_to_c.awk + Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh") + factored out new file gdb/features/feature_to_c.awk out of + gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add + this now. + + Tested on x86_64-linux. + +2024-06-18 Nick Alcock + + libctf, include: new functions for looking up enumerators + Three new functions for looking up the enum type containing a given + enumeration constant, and optionally that constant's value. + + The simplest, ctf_lookup_enumerator, looks up a root-visible enumerator by + name in one dict: if the dict contains multiple such constants (which is + possible for dicts created by older versions of the libctf deduplicator), + ECTF_DUPLICATE is returned. + + The next simplest, ctf_lookup_enumerator_next, is an iterator which returns + all enumerators with a given name in a given dict, whether root-visible or + not. + + The most elaborate, ctf_arc_lookup_enumerator_next, finds all + enumerators with a given name across all dicts in an entire CTF archive, + whether root-visible or not, starting looking in the shared parent dict; + opened dicts are cached (as with all other ctf_arc_*lookup functions) so + that repeated use does not incur repeated opening costs. + + All three of these return enumerator values as int64_t: unfortunately, API + compatibility concerns prevent us from doing the same with the other older + enum-related functions, which all return enumerator constant values as ints. + We may be forced to add symbol-versioning compatibility aliases that fix the + other functions in due course, bumping the soname for platforms that do not + support such things. + + ctf_arc_lookup_enumerator_next is implemented as a nested ctf_archive_next + iterator, and inside that, a nested ctf_lookup_enumerator_next iterator + within each dict. To aid in this, add support to ctf_next_t iterators for + iterators that are implemented in terms of two simultaneous nested iterators + at once. (It has always been possible for callers to use as many nested or + semi-overlapping ctf_next_t iterators as they need, which is one of the + advantages of this style over the _iter style that calls a function for each + thing iterated over: the iterator change here permits *ctf_next_t iterators + themselves* to be implemented by iterating using multiple other iterators as + part of their internal operation, transparently to the caller.) + + Also add a testcase that tests all these functions (which is fairly easy + because ctf_arc_lookup_enumerator_next is implemented in terms of + ctf_lookup_enumerator_next) in addition to enumeration addition in + ctf_open()ed dicts, ctf_add_enumerator duplicate enumerator addition, and + conflicting enumerator constant deduplication. + + include/ + * ctf-api.h (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): Likewise. + (ctf_arc_lookup_enumerator_next): Likewise. + + libctf/ + * libctf.ver: Add them. + * ctf-impl.h (ctf_next_t) : New. + * ctf-util.c (ctf_next_copy): Copy it. + (ctf_next_destroy): Destroy it. + * ctf-lookup.c (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): New. + * ctf-archive.c (ctf_arc_lookup_enumerator_next): New. + * testsuite/libctf-lookup/enumerator-iteration.*: New test. + * testsuite/libctf-lookup/enum-ctf-2.c: New test CTF, used by the + above. + +2024-06-18 Nick Alcock + + include: libctf: comment improvements + Describe a bit more clearly what effects a type being non-root- + visible has. More consistently use the term non-root-visible + rather than hidden. Document ctf_enum_iter. + + include/ + * ctf-api.h (ctf_enum_iter): Document. + (ctf_type_iter): Hidden, not non-root. Mention that + parent dictionaries are not traversed. + +2024-06-18 Nick Alcock + + libctf: make the ctf_next ctn_fp non-const + This was always an error, because the ctn_fp routinely has errors set on it, + which is not something you can (or should) do to a const object. + + libctf/ + * ctf-impl.h (ctf_next_) : Make non-const. + +2024-06-18 Nick Alcock + + libctf: prohibit addition of enums with overlapping enumerator constants + libctf has long prohibited addition of enums with overlapping constants in a + single enum, but now that we are properly considering enums with overlapping + constants to be conflciting types, we can go further and prohibit addition + of enumeration constants to a dict if they already exist in any enum in that + dict: the same rules as C itself. + + We do this in a fashion vaguely similar to what we just did in the + deduplicator, by considering enumeration constants as identifiers and adding + them to the core type/identifier namespace, ctf_dict_t.ctf_names. This is a + little fiddly, because we do not want to prohibit opening of existing dicts + into which the deduplicator has stuffed enums with overlapping constants! + We just want to prohibit the addition of *new* enumerators that violate that + rule. Even then, it's fine to add overlapping enumerator constants as long + as at least one of them is in a non-root type. (This is essential for + proper deduplicator operation in cu-mapped mode, where multiple compilation + units can be smashed into one dict, with conflicting types marked as + hidden: these types may well contain overlapping enumerators.) + + So, at open time, keep track of all enums observed, then do a third pass + through the enums alone, adding each enumerator either to the ctf_names + table as a mapping from the enumerator name to the enum it is part of (if + not already present), or to a new ctf_conflicting_enums hashtable that + tracks observed duplicates. (The latter is not used yet, but will be soon.) + + (We need to do a third pass because it's quite possible to have an enum + containing an enumerator FOO followed by a type FOO: since they're processed + in order, the enumerator would be processed before the type, and at that + stage it seems nonconflicting. The easiest fix is to run through the + enumerators after all type names are interned.) + + At ctf_add_enumerator time, if the enumerator to which we are adding a type + is root-visible, check for an already-present name and error out if found, + then intern the new name in the ctf_names table as is done at open time. + + (We retain the existing code which scans the enum itself for duplicates + because it is still an error to add an enumerator twice to a + non-root-visible enum type; but we only need to do this if the enum is + non-root-visible, so the cost of enum addition is reduced.) + + Tested in an upcoming commit. + + libctf/ + * ctf-impl.h (ctf_dict_t) : Augment comment. + : New. + (ctf_dynset_elements): New. + * ctf-hash.c (ctf_dynset_elements): Implement it. + * ctf-open.c (init_static_types): Split body into... + (init_static_types_internal): ... here. Count enumerators; + keep track of observed enums in pass 2; populate ctf_names and + ctf_conflicting_enums with enumerators in a third pass. + (ctf_dict_close): Free ctf_conflicting_enums. + * ctf-create.c (ctf_add_enumerator): Prohibit addition of duplicate + enumerators in root-visible enum types. + + include/ + * ctf-api.h (CTF_ADD_NONROOT): Describe what non-rootness + means for enumeration constants. + (ctf_add_enumerator): The name is not a misnomer. + We now require that enumerators have unique names. + Document the non-rootness of enumerators. + +2024-06-18 Nick Alcock + + libctf: suppress spurious failure of malloc-counting tests under valgrind + The libctf-regression/open-error-free.c test works by interposing malloc + and counting mallocs and frees across libctf operations. This only + works under suitably-interposable mallocs on systems supporting + dlsym (RTLD_NEXT, ...), so its operation is restricted to glibc + systems for now, but also it interacts badly with valgrind, which + interposes malloc itself. Detect a running valgrind and skip the test. + + Add new facilities allowing libctf lookup tests to declare themselves + unsupported, by printing "UNSUPPORTED: " and then some meaningful + message instead of their normal output. + + libctf/ + * configure.ac: Check for . + * config.h.in: Regenerate. + * configure: Likewise. + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add support for + UNSUPPORTED tests. + * testsuite/libctf-regression/open-error-free.c: When running + under valgrind, this test is unsupported. + +2024-06-18 Nick Alcock + + libctf: fix dict leak on archive-wide symbol lookup error path + If a lookup fails for a reason unrelated to a lack of type data for this + symbol, we return with an error; but we fail to close the dict we opened + most recently, which is leaked. + + libctf/ + * ctf-archive.c (ctf_arc_lookup_sym_or_name): Close dict. + +2024-06-18 Nick Alcock + + libctf: don't leak enums if ctf_add_type fails + If ctf_add_type failed in the middle of enumerator addition, the + destination would end up containing the source enum type and some + but not all of its enumerator constants. + + Use snapshots to roll back the enum addition as a whole if this happens. + Before now, it's been pretty unlikely, but in an upcoming commit we will ban + addition of enumerators that already exist in a given dict, making failure + of ctf_add_enumerator and thus of this part of ctf_add_type much more + likely. + + libctf/ + * ctf-create.c (ctf_add_type_internal): Roll back if enum or + enumerator addition fails. + +2024-06-18 Nick Alcock + + libctf: dedup: enums with overlapping enumerators are conflicting + The CTF deduplicator was not considering enumerators inside enum types to be + things that caused type conflicts, so if the following two TUs were linked + together, you would end up with the following in the resulting dict: + + 1.c: + enum foo { A, B }; + + 2.c: + enum bar { A, B }; + + linked: + + enum foo { A, B }; + enum bar { A, B }; + + This does work -- but it's not something that's valid C, and the general + point of the shared dict is that it is something that you could potentially + get from any valid C TU. + + So consider such types to be conflicting, but obviously don't consider + actually identical enums to be conflicting, even though they too have (all) + their identifiers in common. This involves surprisingly little code. The + deduplicator detects conflicting types by counting types in a hash table of + hash tables: + + decorated identifier -> (type hash -> count) + + where the COUNT is the number of times a given hash has been observed: any + name with more than one hash associated with it is considered conflicting + (the count is used to identify the most common such name for promotion to + the shared dict). + + Before now, those identifiers were all the identifiers of types (possibly + decorated with their namespace on the front for enumerator identifiers), but + we can equally well put *enumeration constant names* in there, undecorated + like the identifiers of types in the global namespace, with the type hash + being the hash of each enum containing that enumerator. The existing + conflicting-type-detection code will then accurately identify distinct enums + with enumeration constants in common. The enum that contains the most + commonly-appearing enumerators will be promoted to the shared dict. + + libctf/ + * ctf-impl.h (ctf_dedup_t) : Extend comment. + * ctf-dedup.c (ctf_dedup_count_name): New, split out of... + (ctf_dedup_populate_mappings): ... here. Call it for all + * enumeration constants in an enum as well as types. + + ld/ + * testsuite/ld-ctf/enum-3.c: New test CTF. + * testsuite/ld-ctf/enum-4.c: Likewise. + * testsuite/ld-ctf/overlapping-enums.d: New test. + * testsuite/ld-ctf/overlapping-enums-2.d: Likewise. + +2024-06-18 Nick Alcock + + libctf: doc: fix ctf_stype_t typedef string in spec + +2024-06-18 Nick Alcock + + include: fix libctf ECTF_NOENUMNAM error message + ECTF_NOENUMNAM is emitted when enumerator constant names don't exist. + Call them that, not 'enum elements'. + + include/ + * ctf-api.h (ECTF_NOENUMNAM): fix error message. + +2024-06-18 Nick Alcock + + libctf: strtab corruption when strings are added to ctf_open()ed dicts + ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed + to return a strtab offset. These offsets are "provisional": the ref + mechanism records the address of the location in which the ref is stored and + modifies it when the strtab is finally written out. Provisional refs in new + dicts start at 0 and go up via strlen() as new refs are added: this is fine, + because the strtab is empty and none of these values will overlap any + existing string offsets (since there are none). Unfortunately, when a dict + is ctf_open()ed, we fail to set the initial provisional strtab offset to a + higher value than any existing string offset: it starts at zero again! + It's a shame that we already *have* strings at those offsets... + + This is all fixed up once the string is reserialized, but if you look up + newly-added strings before serialization, you get corrupted partial string + results from the existing ctf_open()ed dict. + + Observed (and thus regtested) by an upcoming test (in this patch series). + + Exposed by the recently-introduced series that permits modification of + ctf_open()ed dicts, which has not been released anywhere. Before that, + any attempt to do such things would fail with ECTF_RDONLY. + + libctf/ + * ctf-string.c (ctf_str_create_atoms): Initialize + ctf_str_prov_offset. + +2024-06-18 Jan Beulich + + readelf: rename recently added testsuite files + Files named *.0 are somewhat odd for testsuite expectations. Rename the + one such file to *.r with a suitable base name suffix, and have its + sibling follow suit in this latter regard. + +2024-06-18 Nelson Chu + + RISC-V: Fixed typo from smscrind to smcsrind in riscv_implicit_subsets. + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Fixed type from smscrind to + smcsrind. + gas/ + * testsuite/gas/riscv/march-imply-smcsrind.d: New testcase. It fails + without applying this patch. + +2024-06-18 Nick Clifton + + Ensure that the text segment is aligned on disk when using --rosegment. + +2024-06-18 Felix Willgerodt + Nils-Christian Kempke + + gdb: rename offset to high bits in ymm registers + The xsave_ymm_avx512_offset data structure contains the xsave + offset to the upper 128 bits of a ymm register. Similarly, for zmm this + offset is described by xsave_avx512_zmm_h_offset, h indicating the + high bits. This commit renames the xsave_ymm_avx512_offset to + xsave_ymm_h_avx512_offset - as well as the associated define from + XSAVE_YMM_AVX512_ADDR to XSAVE_YMM_H_AVX512_ADDR - to make this + more consistent. + + Note, that the regnum defines already included the 'h' for ymm, like + I387_YMM16H_REGNUM and I387_YMMH_AVX512_END_REGNUM. + + Approved-By: Andrew Burgess + +2024-06-18 Nelson Chu + + RISC-V: Updated gas/NEWS and gas/doc/c-riscv.texi for vendor extensions. + gas/ + * NEWS: Updated for XCvMem, XCvBi, XCvElw, XSfCease. + * doc/c-riscv.texi: Minor typo for XCv* extensions. + +2024-06-18 Hau Hsu + + RISC-V: Add SiFive cease extension v1.0 + Add SiFive cease extension, + https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf + + This aligns LLVM: + * https://llvm.org/docs/RISCVUsage.html + * https://github.com/llvm/llvm-project/pull/83896 + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_supported_vendor_x_ext): Add support for + 'xsfcease'. + (riscv_multi_subset_supports): Handle INSN_CLASS_XSFCEASE. + (riscv_multi_subset_supports_ext): Handle INSN_CLASS_XSFCEASE. + + gas/ChangeLog: + + * doc/c-riscv.texi: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/sifive-insns.d: Add test case for 'sf.cease'. + * testsuite/gas/riscv/sifive-insns.s: Likewise. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_SF_CEASE, MASK_SF_CEASE): Define match and + mask encoding for 'sf.cease'. + * opcode/riscv.h (INSN_CLASS_XSFCEASE): Add new instruction class for + 'xsfcease'. + + opcodes/ChangeLog: + + * riscv-opc.c (riscv_opcodes): Add opcode entry for 'sf.cease'. + +2024-06-18 Gianluca Guida + + RISC-V: Support Zacas extension. + https://github.com/riscvarchive/riscv-zacas/releases/tag/v1.0 + + The Zacas extension introduce compare-and-swap instructions to operate + on 32-bit, 64-bit and 128-bit (RV64 only) data values. + + It introduces three new instructions: + - amocas.w (32-bit CAS) + - amocas.d (64-bit CAS) + - amocas.q (128-bit CAS, RV64 only) + + Like other AMOs in the A extension, Zacas instructions have '.aq', + '.rl' and '.aqrl' variations. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): 'A' implied by 'Zacas'. + (riscv_supported_std_z_ext): Add 'Zacas' extension. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): + Handle INSN_CLASS_ZACAS case. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zacas-32.d: New test (RV32). + * testsuite/gas/riscv/zacas-fail-32.d: Likewise. + * testsuite/gas/riscv/zacas-64.d: New test (RV64). + * testsuite/gas/riscv/zacas-fail-64.d: Likewise. + * testsuite/gas/riscv/zacas.s: New test source. + * testsuite/gas/riscv/zacas-fail.s: Likewise. + * testsuite/gas/riscv/zacas-fail-32.l: New file. + * testsuite/gas/riscv/zacas-fail-64.l: Likewise. + + include/ChangeLog: + + * include/opcode/riscv.h (INSN_CLASS_ZACAS): New definition. + * include/opcode/riscv-opc.h (MATCH_AMOCAS_W, MASK_AMOCAS_W) + (MATCH_AMOCAS_D, MASK_AMOCAS_D, MATCH_AMOCAS_Q, MASK_AMOCAS_Q): + Likewise. + (amocas_w, amocas_d, amocas_q): Declare instructions. + + opcodes/ChangeLog: + + * riscv-opc.c (match_rs2_rd_even): New function. + (amocas_w, amocas_d, amocas_q, amocas_w.aq) + (amocas_d.aq, amocas_q.aq, amocas_w.rl, amocas_d.rl, amocas_q.rl) + (amocas_w.aqrl, amocas_d.aqrl, amocas_q.aqrl): Add instructions. + +2024-06-18 Cui, Lili + + x86: Fix typo in i386-dis-evex-mod.h + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Used MOD_EVEX_MAP4_F8_P_1/MOD_EVEX_MAP4_F8_P_3 + instead of MOD_EVEX_MAP4_F8_P1/MOD_EVEX_MAP4_F8_P3. + +2024-06-18 Cui, Lili + + Remove %ME and used %NE for movbe. + %ME is added specifically for movbe. Now with %NE, we can use + MOD table + %NE to indicate whether a {evex} prefix is needed. + + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Added movbe. + * i386-dis-evex.h: Let movbe go through the mod table. + * i386-dis.c (struct dis386): Removed %ME. + (putop): Removed case ME. + +2024-06-18 Cui, Lili + + Support APX CCMP and CTEST + CCMP and CTEST are two new sets of instructions for conditional CMP + and TEST, SCC and OSZC flags are given as suffixes of CCMP or CTEST + in the instruction mnemonic, e.g.: + + ccmp { dfv=sf , cf , of } %eax, %ecx + + also add + + {evex} cmp/test %eax, %ecx + + as an alias for ccmpt. + + For the encoder part, add function check_Scc_OszcOperation to parse + '{ dfv=of , sf, sf, cf}', store scc in the lower 4 bits of base_opcode, + and adjust base_opcode to its normal meaning in install_template. + + For the decoder part, add 'SC' and 'DF' macros to add scc and oszc flags + suffixes. + + gas/ChangeLog: + + * config/tc-i386.c (OSZC_CF): New. + (OSZC_ZF): Ditto. + (OSZC_SF): Ditto. + (OSZC_OF): Ditto. + (set_oszc_flags): Set oszc flags and report error for using the same oszc flags twice. + (check_Scc_OszcOperations): Handle SCC OSZC flags. + (install_template): Add scc and oszc_flags. + (build_apx_evex_prefix): Encode SCC and oszc flags bits. + (parse_insn): Handle check_Scc_OszcOperations. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add ivalid test case. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add test for ccmp and ctest. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.d: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-reg.h: Add ccmp and ctest. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct instr_info): add scc. + (struct dis386): Add new micro 'NE','SC' and'DF'. + (get_valid_dis386): Get scc value and move MAP4 invalid check to print_insn. + (putop): Handle %NE, %SC and %DF. + * i386-opc.h (SCC): New. + * i386-opc.tbl: Add ccmp/ctest and evex format for cmp/test. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-06-18 Lulu Cai + + LoongArch: add .option directive + In some cases we may want to use different options only for certain + assembly, so the .option directive is added to control the assembler + options. + + .option can accept 4 parameters: + + push + pop + Pushes or pops the current option stack. They limit the scope of + option changes so that they do not affect other parts of the assembly + file. + + relax + norelax + Enables or disables relaxation. + +2024-06-18 GDB Administrator + + Automatic date update in version.in + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Make a copy of none.s before operating on it as output + The "Output file must be distinct from input" test in gas/all/gas.exp + operates on none.s as output. Should the test fail it may happen that + GAS will delete the output file requested in which case none.s will be + removed. Since the test operates directly on the source tree it will be + clobbered as a result. It has actually been observed in the field in + the form of intermittent: + + FAIL: gas/all/none + + regressions in a parallel run of many configurations. + + Prevent this from happening by copying none.s first to the test object + directory and operating on it instead. It does not prevent the file + from being removed should the test fail, but the source tree won't be + clobbered in that case. + + A nice side effect is that syntactically different paths will now be + used in this test for the input and the output file each, so coverage + will extend to verifying that a file is checked against itself even if + referred to via different paths. Previously "$srcdir/$subdir/none.s" + was used for both paths and now "tmpdir/none.s" is referred to directly + and via a relative path from "$srcdir/$subdir" respectively. + + I note that we have no previous use of the UNRESOLVED test result in the + GAS testsuite, but it seems the correct one should copying none.s fail, + as this is an unexpected situation that requires a human intervention + and the test proper has not been evaluated. + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Add a helper for paths outside the source dir + Implement a helper to construct a relative path from $srcdir/$subdir, + where `gas_run' operates, to an arbitrary place in the filesystem, for + example a file in the test object directory. + +2024-06-17 Maciej W. Rozycki + + binutils/testsuite: Add a helper for relative path construction + Implement a helper to construct a relative path between two locations in + the filesystem, for example to make a path from the source to the object + directory for the case where a tool has been set up to look at a given + path and there is a need to point it elsewhere, but an absolute path + will not work. The helper works on normalized paths internally, so the + result is correct even in the presence of symlinks as intermediate path + components. + + So given "/path/to/src/gas/testsuite/gas/all" as the FROM argument and + then "/path/to/obj/gas/testsuite/tmpdir/none.s" as the TO argument the + helper will return "../../../../../obj/gas/testsuite/tmpdir/none.s" in + the absence of symlinks. + +2024-06-17 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/array-{indices,repeat}.exp + When running test-case gdb.fortran/array-indices.exp on a system without + fortran compiler, I run into a duplicate: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp + ... + + Fix this by adding a with_test_prefix at the toplevel. + + Likewise in gdb.fortran/array-repeat.exp. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-17 Alan Modra + + PR31898 bug in processing DW_RLE_startx_endx + PR 31898 + * dwarf.c (display_debug_rnglists_list): Correct fetch of "end" + indexed address. Remove excess parens. + +2024-06-17 Alan Modra + + Error messages emitted during bfd_check_format_matches + Error/warning messages are only printed for the target that + successfully matched, which makes sense for warnings, but not so much + for errors where the errors cause no target to match. I noticed this + when looking at the pr20520 testcase again with objdump, which just + reports "file format not recognized" omitting the five "SHT_GROUP + section [index n] has no SHF_GROUP sections" messages. They are + omitted because multiple ELF targets match the object file. This is + going to be true for all ELF objects due to at least the proper ELF + target and the generic ELF target matching. + + * format.c (print_and_clear_messages): Print messages if all + targets with messages have exactly the same set of messages. + +2024-06-17 GDB Administrator + + Automatic date update in version.in + +2024-06-16 Tom Tromey + + Make tui_register_info::highlight private + This changes tui_register_info::highlight to be private, renaming it + to m_highlight. + +2024-06-16 GDB Administrator + + Automatic date update in version.in + +2024-06-15 Tom Tromey + + Remove a call to fflush + This TUI code calls fflush on stdout, but I don't believe this is + useful in gdb. + +2024-06-15 Tom de Vries + + [gdb/build] Cleanup gdb/features/feature_to_c.sh + Clean up script gdb/features/feature_to_c.sh by: + - fixing shellcheck warnings, + - moving an embedded awk script out of the file, reducing the amount of + escaping in the awk script, making it more readable and maintainable, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up lib/dg-add-core-file-count.sh + Fix shellcheck warnings in script lib/dg-add-core-file-count.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up formatting in gdb/contrib/cc-with-tweaks.sh + In emacs, on gdb/contrib/cc-with-tweaks.sh, do: + - M-x whitespace-cleanup, + - M-x mark-whole-buffer and M-x indent-region, and + - and undo the unwanted changes in the header comment. + + Only whitespace changes. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/cc-with-tweaks.sh + Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/expect-read1.sh + Clean up script gdb/contrib/expect-read1.sh by: + - fixing shellcheck warnings, + - using mktemp (which takes TMPDIR into account) instead of a hardcoded + "/tmp/expect-read1.$$.so", + - adding comments, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 GDB Administrator + + Automatic date update in version.in + +2024-06-14 H.J. Lu + + x86: Add -z isa-level-report=[none|all|needed|used] + Add -z isa-level-report=[none|all|needed|used] to the x86 ELF linker to + report needed and used x86-64 ISA levels. + + bfd/ + + PR ld/31868 + * elf-linker-x86.h (elf_x86_isa_level_report): New. + (elf_linker_x86_params): Add isa_level_report. + * elfxx-x86.c (report_isa_level): New. + (_bfd_x86_elf_link_setup_gnu_properties): Check + -z isa-level-report=[none|all|needed|used] to report needed and + used x86-64 ISA level. + + ld/ + + PR ld/31868 + * NEWS: Mention -z isa-level-report=[none|all|needed|used]. + * ld.texi: Document -z isa-level-report=[none|all|needed|used]. + * emulparams/elf32_x86_64.sh: Source x86-64-level-report.sh. + * emulparams/elf_i386.sh: Likewise. + * emulparams/elf_x86_64.sh: Likewise. + * emulparams/x86-64-level-report.sh: New file. + * testsuite/ld-i386/pr31868a.d: Likewise. + * testsuite/ld-i386/pr31868b.d: Likewise. + * testsuite/ld-i386/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868a-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868a.d: Likewise. + * testsuite/ld-x86-64/pr31868a.l: Likewise. + * testsuite/ld-x86-64/pr31868a.s: Likewise. + * testsuite/ld-x86-64/pr31868b-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868b.d: Likewise. + * testsuite/ld-x86-64/pr31868b.l: Likewise. + * testsuite/ld-x86-64/pr31868b.s: Likewise. + * testsuite/ld-x86-64/pr31868c-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868c.l: Likewise. + * testsuite/ld-i386/i386.exp: Run PR ld/31868 tests. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + +2024-06-14 H.J. Lu + + ld: Align --no-error-execstack help output + * lexsup.c (elf_static_list_options): Align --no-error-execstack + help output. + +2024-06-14 Tom Tromey + + Simplify ada_lookup_encoded_symbol + This patch simplifies ada_lookup_encoded_symbol by having it return + its result, rather than returning void and having an out parameter. + + Introduce language_defn::lookup_symbol_local + This introduces the new method language_defn::lookup_symbol_local, and + then changes lookup_symbol_local to use it. This removes an explicit + language check from this function, and makes it easier for other + languages to hook into this code. + + Remove an unnecessary null check from lookup_local_symbol + lookup_local_symbol checks whether 'function' is null before calling + block::inlined_p, but this is not necessary. + + Simplify lookup_local_symbol + This simplifies lookup_local_symbol a little, by having it check + whether the current block is the static or global block, instead of + first searching for the static block. + +2024-06-14 Tom Tromey + + Examine template symbols in lookup_local_symbol + This changes lookup_local_symbol to directly examine any attached + template symbols, rather than gating this lookup on the use of C++ or + Fortran. As mentioned in an earlier patch, these objects are not + necessarily C++-specific, and doing the search generically seems + better. + + This also renames cp_lookup_symbol_imports_or_template now that the + "template" part has been removed. + +2024-06-14 Tom Tromey + + Move search_symbol_list to symtab.c + This moves search_symbol_list to symtab.c and exports it. It will be + useful in a later patch. + + Rename is_cplus_template_function + This patch renames is_cplus_template_function to is_template_function. + There is nothing C++-specific about this code, and the code in the + DWARF reader that creates these objects is not C++-specific. In fact + this may already be used by Rust (though I didn't check). + +2024-06-14 Matthieu Longo + + aarch64: add SPMU system registers missed in f01ae0392ed + +2024-06-14 Andrew Burgess + + gdb/aarch64: prevent crash from in process agent + Since this commit: + + commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d + Date: Wed May 18 13:32:04 2022 -0700 + + Use aarch64_features to describe register features in target descriptions. + + There has been an issue with how aarch64 target descriptions are + cached within gdbserver, and specifically, how this caching impacts + the in process agent (IPA). + + The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is + part of the IPA, this function is a constructor function, i.e. is + called as part of the global initialisation process. We can't + guarantee the ordering of when this function is called vs when other + global state is initialised. + + Now initialize_tracepoint_ftlib calls initialize_tracepoint, which + calls initialize_low_tracepoint, which for aarch64 calls + aarch64_linux_read_description. + + The aarch64_linux_read_description function lives in + linux-aarch64-tdesc.cc and after the above commit, depends on a + std::unordered_map having been initialized. + + Prior to the above commit aarch64_linux_read_description used a global + C style array, which obviously requires no runtime initialization. + + The consequence of the above is that any inferior linked with the IPA + (for aarch64) will experience undefined behaviour (access to an + uninitialized std::unordered_map) during startup, which for me + manifests as a segfault. + + I propose fixing this by moving the std::unordered_map into the + function body, but leaving it static. The map will now be initialized + the first time the function is called, which removes the undefiend + behaviour. + + The same problem exists for the expedited_registers global, however + this global can just be made into a function local instead. The + expedited_registers variable is used to build a pointer list which is + then passed to init_target_desc, however init_target_desc copies the + values it is given so expedited_registers does not need to live longer + than its containing function. + + On most of the AArch64 machines I have access too tracing is not + supported, and so the gdb.trace/*.exp tests that use the IPA just exit + early reporting unsupported. I've added a test which links an + inferior with the IPA and just starts the inferior. No tracing is + performed. This exposes the current issue even on hosts that don't + support tracing. After this patch the test passes. + +2024-06-14 Nick Clifton + + Regenerate configure files in ld sub-directory + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into the + gdb/arch/ directory and combine them so we have just a single copy of + each. Then GDB, gdbserver, and the in-process-agent (IPA) will link + against these shared functions. + + One curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, there is some + additional configuration that is performed as each target description + is created, to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + An alternative approach that avoids adding x86_linux_post_init_tdesc + would be to have x86_linux_tdesc_for_tid return a non-const target + description, then in x86_target::low_arch_setup we could inspect the + target description to figure out if it is 64-bit or not, and modify + the target description as needed. In the end I think that adding the + x86_linux_post_init_tdesc function is the simpler solution. + + The contents of gdbserver/linux-x86-low.cc have moved to + gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h + has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to + some updates in the #includes in the gdbserver/ directory. + + This commit also changes how target descriptions are cached. + Previously both GDB and gdbserver used static C-style arrays to act as + the tdesc cache. This was fine, except for two problems. Either the + C-style arrays would need to be placed in x86-linux-tdesc-features.c, + which would allow us to use the x86_linux_*_tdesc_count_1() functions + to size the arrays for us, or we'd need to hard code the array sizes + using separate #defines, which we'd then have to keep in sync with the + rest of the code in x86-linux-tdesc-features.c. + + Given both of these problems I decided a better solution would be to + just switch to using a std::unordered_map to act as the cache. This + will resize automatically, and we can use the xcr0 value as the key. + + At first inspection, using xcr0 might seem to be a problem; after all + the {i386,amd64}_create_target_description functions take more than + just the xcr0 value. However, this patch is only for x86/Linux + targets, and for x86/Linux all of the other flags passed to the tdesc + creation functions have constant values and so are irrelevant when we + consider tdesc caching. + + For testing I've done the following: + + - Built on x86-64 GNU/Linux for all targets, and just for the native + target, + + - Build on i386 GNU/Linux for all targets, and just for the native + target, + + - Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the + native target, and for targets x86_64-*-linux and i386-*-linux. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring earlier in this series the shared + x86_linux_tdesc_for_tid function was added into nat/x86-linux-tdesc.c. + However, this function still relies on amd64_linux_read_description + and i386_linux_read_description which are implemented separately for + both gdbserver and GDB. Given that at their core, all these functions + do is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + Despite using the same {amd64,i386}_create_target_description + functions in both GDB and gdbserver to create the target descriptions, + on the gdbserver side we cache target descriptions based on a reduced + set of xcr0 feature bits. + + What this means is that, in theory, different xcr0 values can map to + the same cache entry, which could result in the wrong target + description being used. + + However, I'm not sure if this can actually happen in reality. Within + gdbserver we already split the target description cache based on i386, + amd64, and x32. I suspect within a given gdbserver session we'll only + see at most one target description for each of these. + + The cache conflicting problem is caused by xcr0_to_tdesc_idx, which + maps an xcr0 value to a enum x86_linux_tdesc value, and there are only + 7 usable values in enum x86_linux_tdesc. + + In contrast, on the GDB side there are 64, 32, and 16 cache slots for + i386, amd64, and x32 respectively. + + On the GDB side it is much more important to cache things correctly as + a single GDB session might connect to multiple different remote + targets, each of which might have slightly different x86 + architectures. + + And so, if we want to merge the target description caching between GDB + and gdbserver, then we need to first update gdbserver so that it + caches in the same way as GDB, that is, it needs to adopt a mechanism + that allows for the same number of cache slots of each of i386, amd64, + and x32. In this way, when the caching is shared, GDB's behaviour + will not change. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use, the IPA having first generated every possible target + description. + + Interestingly, there is certainly a bug here which results from only + having 7 values in enum x86_linux_tdesc. As multiple possible target + descriptions in gdbserver map to the same enum x86_linux_tdesc value, + then, when the enum x86_linux_tdesc value is sent to the IPA there is + no way for gdbserver to know that the IPA will select the correct + target description. This bug will get fixed by this commit. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach of sending a target + description index made perfect sense. However since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think that passing an index was probably a bad idea. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use, the target description was + not generated until the index arrived. + + However, the above commit fixed an issue where we can't call malloc() + within (certain parts of) the IPA (apparently), so instead we now + pre-compute _every_ possible target description within the IPA. The + index is only used to lookup which of the (many) pre-computed target + descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + I did look at how a process might derive its own xcr0 value, but I + don't believe this is actually that simple, so for now I've just + doubled down on the index passing approach. + + While reviewing earlier iterations of this patch there has been + discussion about the possibility of removing the IPA from GDB. That + would certainly make all of the code touched in this patch much + simpler, but I don't really want to do that as part of this series. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so, and that's what I've + assumed in this commit. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of xcr0 features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + choose the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they cache target descriptions + using the same set of xcr0 features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series have done. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit(s) can merge the GDB and + gdbserver versions of these functions. + + Notes On The Implementation + --------------------------- + + Previously, within gdbserver, target descriptions were cached within + arrays. These arrays were sized based on enum x86_linux_tdesc and + xcr0_to_tdesc_idx returned the array (cache) index. + + Now we need different array lengths for each of i386, amd64, and x32. + And the index to use within each array is calculated based on which + xcr0 bits are set and valid for a particular target type. + + I really wanted to avoid having fixed array sizes, or having the set + of relevant xcr0 bits encoded in multiple places. + + The solution I came up with was to create a single data structure + which would contain a list of xcr0 bits along with flags to indicate + which of the i386, amd64, and x32 targets the bit is relevant for. By + making the table constexpr, and adding some constexpr helper + functions, it is possible to calculate the sizes for the cache arrays + at compile time, as well as the bit masks needed to each target type. + + During review it was pointed out[1] that possibly the failure to check + the SSE and X87 bits for amd64/x32 targets might be an error, however, + if this is the case then this is an issue that existed long before + this patch. I'd really like to keep this patch focused on reworking + the existing code and try to avoid changing how target descriptions + are actually created, mostly out of fear that I'll break something. + + [1] https://inbox.sourceware.org/gdb-patches/MN2PR11MB4566070607318EE7E669A5E28E1B2@MN2PR11MB4566.namprd11.prod.outlook.com + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things mostly the GDB way, some changes are + needed to allow for the sharing; we now take some pointers for where + the shared code can cache the xcr0 and xsave layout values. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are + left where they are. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Reviewed-By: Felix Willgerodt + Acked-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb: move xcr0 == 0 check into i386_linux_core_read_description + Currently, in i386_linux_core_read_description, if GDB fails to + extract an xcr0 value from the core file, then we will have a default + zero value for the xcr0 variable, we still call the + i386_linux_read_description function, which checks for this zero value + and returns nullptr. + + Back in i386_linux_core_read_description we spot the nullptr return + value from i386_linux_read_description and call + i386_linux_read_description again, but this time passing a default + value for xcr0. + + In the next commit I plan to rework i386_linux_read_description, and + in so doing I will remove the check for xcr0 == 0, this is inline with + how the amd64 code is written. + + However, this means that the 'xcr0 == 0' check needs to move up the + stack to i386_linux_core_read_description, again, this brings the i386 + code into line with the amd64 code. + + This is just a refactor in preparation for the next commit, there + should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim sharing the x86 Linux + target description creation code between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes (gdbserver relies on reading the file being debugged, and + extracting similar information from the file headers). + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code can be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb: move have_ptrace_getregset declaration into gdb/nat directory + In a later commit I want to access have_ptrace_getregset from a .c + file in the nat/ directory. To achieve this I need access to the + declaration of have_ptrace_getregset. + + Currently have_ptrace_getregset is declared (and defined) twice, once + in GDB and once in gdbserver. + + This commit moves the declaration into nat/linux-nat.h, but leaves the + two definitions where they are. Now, in my later commit, I can pull + in the declaration from nat/linux-nat.h. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory + The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is + running on a kernel that supports the GETFPXREGS ptrace request. + + Currently this global is declared twice (once in GDB and once in + gdbserver), I think it makes sense to move this global into the nat/ + directory, and have a single declaration and definition. + + While moving this variable I have converted it to a tribool, as that + was what it really was, if even used the same numbering as the tribool + enum (-1, 0, 1). Where have_ptrace_getfpxregs was used I have updated + in the obvious way. + + However, while making this change I noticed what I think is a bug in + x86_linux_nat_target::read_description and x86_linux_read_description, + both of these functions can be called multiple times, but in both + cases we only end up calling i386_linux_read_description the first + time through in the event that PTRACE_GETFPXREGS is not supported. + This is because initially have_ptrace_getfpxregs will be + TRIBOOL_UNKNOWN, but after the ptrace call fails we set + have_ptrace_getfpxregs to TRIBOOL_FALSE. The next time we attempt to + read the target description we'll skip the ptrace call, and so skip + the call to i386_linux_read_description. + + I've not tried to address this preexisting bug in this commit, this is + purely a refactor, there should be no user visible changes after this + commit. In later commits I'll merge the gdbserver and GDB code + together into the nat/ directory, and after that I'll try to address + this bug. + + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit moves the definition into gdbsupport/x86-xstate.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 GDB Administrator + + Automatic date update in version.in + +2024-06-13 Tom Tromey + + Add gdbpy_call_method overloads for gdbpy_ref<> + This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>. + This is just a small convenience. + + Reviewed-By: Tom de Vries + +2024-06-13 Tom Tromey + + Return gdbpy_ref<> from gdbpy_call_method + This changes gdbpy_call_method to return a gdbpy_ref<>. This is + slightly safer because it makes it simpler to correctly handle + reference counts. + + Reviewed-By: Tom de Vries + +2024-06-13 Nick Clifton + + Adjust linker tests that are sensitive to --rosegment + +2024-06-13 Tom de Vries + + [gdb/testsuite] Add gdb.base/fission-macro.exp + Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT + macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc + produces a usable dwarf-5 32-bit .debug_macro.dwo section. + + Add a test-case excercising this. + + Tested on x86_64-linux. + + Tested test-case using a current gcc trunk build, and gcc 14. + +2024-06-13 Tom de Vries + + [gdb/testsuite] Fix kfail number in gdb.base/watchpoint-running.exp + Test-case gdb.base/watchpoint-running.exp reports the following kfail: + ... + KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111) + ... + but the referenced gdb PR doesn't exist. + + Fix this by using an actual PR. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833 + +2024-06-13 Nick Clifton + + Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. + PR 30907 + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Rework INSN_* flags into a consistent block + For historic reasons we have ended up with a random set of discontiguous + bit assignments for INSN_* flags within `membership' and `exclusions' + members of `mips_opcode'. Some of the bits were previously used for ASE + assignments and have been reused in a disorganised fashion since `ase' + has been split off as a member on its own. It makes them hard to track + and maintain, and to see how many we still have available for future + assignments. + + Therefore reorder the flags using consecutive bits and matching the + order used with the switch statement in `cpu_is_member'. + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Update INSN_CHIP_MASK for INSN_ALLEGREX + An update has been missed with commit df18f71b565c ("Add MIPS Allegrex + CPU as a MIPS2-based CPU") for INSN_CHIP_MASK to include INSN_ALLEGREX. + Fix it. + +2024-06-13 GDB Administrator + + Automatic date update in version.in + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_STOKEN macro + This removes the LS_TOKEN_STOKEN macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_KEYWORD macro + This removes the LS_TOKEN_KEYWORD macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STREAM macro + This removes the PARSER_STREAM macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_EXPLICIT macro + This removes the PARSER_EXPLICIT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_RESULT macro + This removes the PARSER_RESULT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STATE macro + This removes the PARSER_STATE macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom de Vries + + [gdb/testsuite] Fix error in gdb.server/server-kill-python.exp + With test-case gdb.server/server-kill-python.exp, I sometimes run into: + ... + builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \ + -data-directory data-directory^M + kill^M + (gdb) kill^M + file server-kill-python^M + The program is not being run.^M + (gdb) ERROR: Couldn't load server-kill-python into GDB. + ... + + The problem is that the spawn produces a prompt, but it's not explicitly + consumed. + + This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify + gdb.server/server-kill-python.exp"). + + Fix this by consuming the initial prompt. + + PR testsuite/31819 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819 + Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp" + +2024-06-12 Tom Tromey + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + In gdb/python/py-tui.c we have code like this: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll", + "i", num_to_scroll, nullptr)); + ... + + The nullptr is superfluous, the format string already indicates that there's + only one method argument. + + OTOH, passing no method args does use a nullptr: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render", + nullptr)); + ... + + Furthermore, choosing the right format string chars can be tricky. + + Add a typesafe wrapper around PyObject_CallMethod that hides these + details, such that we can use the more intuitive: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll", + num_to_scroll)); + ... + and: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render")); + ... + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Tom Tromey + +2024-06-12 Claudio Bantaloukas + + aarch64: add Branch Record Buffer extension instructions + The FEAT_BRBE extension provides two aliases of sys: + - brb iall (Invalidates all Branch records in the Branch Record Buffer) + - brb inj (Injects the Branch Record held in BRBINFINJ_EL1, + BRBSRCINJ_EL1, and BRBTGTINJ_EL1 into the Branch Record Buffer) + + This patch adds: + - the feature option "brbe" that must be added for the aliases to be available + - a new operand flag AARCH64_OPND_Rt_IN_SYS_ALIASES that warns in a comment + when Rt is set to the non default value 0b11111 (it is constrained + unpredictable whether the instruction is undefined or behaves as if the Rt + field is set to 0b11111). + - a new operand flag AARCH64_OPND_BRBOP that encodes and decodes Op2 values + from bit 5 + - support for the two brb aliases above + + See: + - https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/BRB--Branch-Record-Buffer--an-alias-of-SYS-?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-INJ--Branch-Record-Injection-into-the-Branch-Record-Buffer?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-IALL--Invalidate-the-Branch-Record-Buffer?lang=en + +2024-06-12 Hannes Domani + + Allow calling of user-defined function call operators + Currently it's not possible to call user-defined function call + operators, at least not without specifying operator() directly: + ``` + (gdb) l 1 + 1 struct S { + 2 int operator() (int x) { return x + 5; } + 3 }; + 4 + 5 int main () { + 6 S s; + 7 + 8 return s(23); + 9 } + (gdb) p s(10) + Invalid data type for function to be called. + (gdb) p s.operator()(10) + $1 = 15 + ``` + + This now looks if an user-defined call operator is available when + trying to 'call' a struct value, and calls it instead, making this + possible: + ``` + (gdb) p s(10) + $1 = 15 + ``` + + The change in operation::evaluate_funcall is to make sure the type + fields are only used for function types, only they use them as the + argument types. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213 + Approved-By: Tom Tromey + +2024-06-12 Alexandra Hájková + + Add "error_message+" feature to qSupported + Add a new 'error_message' feature to the qSupported packet. When GDB + supports this feature then gdbserver is able to send + errors in the E.errtext format for the qRcmd and m packets. + + Update qRcmd packet and m packets documentation as qRcmd newly + accepts errors in a E.errtext format. + Previously these two packets didn't support E.errtext style errors. + + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2024-06-12 A. Wilcox + + PR 31882 libctf: test suite incorrect format specifiers + +2024-06-12 Jiawei + + RISC-V: Support S[sm]csrind extension csrs. + This patch supports RISC-V Smcsrind/Sscsrind privilege extension csrs. + Reuse csr 'smselect/siselect', 'mireg/sireg' and 'vsiselect,vsireg' csrs + in Smaia/Ssaia extension. + + bfd/ChangeLog: + + * elfxx-riscv.c: New extensions. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (enum riscv_csr_class): New extensions. + (riscv_csr_address): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New csrs. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extensions. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MIREG2): New csr. + (CSR_MIREG3): Ditto. + (CSR_MIREG4): Ditto. + (CSR_MIREG5): Ditto. + (CSR_MIREG6): Ditto. + (CSR_SIREG2): Ditto. + (CSR_SIREG3): Ditto. + (CSR_SIREG4): Ditto. + (CSR_SIREG5): Ditto. + (CSR_SIREG6): Ditto. + (CSR_VSIREG2): Ditto. + (CSR_VSIREG3): Ditto. + (CSR_VSIREG4): Ditto. + (CSR_VSIREG5): Ditto. + (CSR_VSIREG6): Ditto. + (DECLARE_CSR): Ditto. + +2024-06-12 GDB Administrator + + Automatic date update in version.in + +2024-06-11 Andrew Burgess + + gdb: convert separate-debug-file to new(ish) debug scheme + Convert 'set/show debug separate-debug-file' to the new debug scheme. + Though I'm not sure if we can really call it "new" any more! + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: warn of slow remote file reading only after a successful open + While working on a later patch in this series, I noticed that GDB + would print the message: + + Reading /path/to/file from remote target... + + Even when /path/to/file doesn't exist on the remote target. + + GDB does indeed try to open /path/to/file, but I'm not sure we really + need to tell the user unless we actually manage to open the file, and + plan to read content from it. + + If we consider how GDB probes for separate debug files, we can attempt + to open multiple possible files, most of them will not exist. When we + are native debugging we don't bother telling the user about each file + we're checking for, we just announce any file we finally use. + + I think it makes sense to do a similar thing for remote files. + + So, in remote_target::remote_hostio_open(), I'd like to move the block + of code that prints the above message to after the open call has been + made, and we should only print the message if the open succeeds. + + Now GDB only tells the user about files that we actually open and read + from the remote. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: avoid duplicate search in build_id_to_bfd_suffix + In build_id_to_bfd_suffix we look in each debug-file-directory for a + file matching the required build-id. + + If we don't find one then we add the sysroot and perform the search + again. + + However, the default sysroot is 'target:', and for a native target + this just means to search on the local machine. So by default, if the + debug information is not present, then we end up searching each + location twice. + + I think we only need to perform the "with sysroot" check if either: + + 1. The sysroot is something other than 'target:'. If the user has + set it to '/some/directory' then we should check this sysroot. Or if + the user has set it to 'target:/some/other_directory', this is also + worth checking. + + 2. If the sysroot is 'target:', but the target's filesystem is not + local (i.e. the user is connected to a remote target), then we should + check using the sysroot as this will be looking on the remote + machine. + + There's no tests for this as the whole point here is that I'm removing + duplicate work. No test regressions were seen though. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb/fileio: fix errno for packets where an attachment is expected + In remote.c lives remote_target::remote_hostio_send_command(), which + is used to handle sending a fileio packet to the remote, and for + parsing the reply packet. + + Some commands, e.g. open, pwrite, close, send some arguments to the + remote, and then get back a single integer return value. + + Other commands though, e.g. pread, readlink, fstat, send some + arguments and get back an integer return value and some additional + data. This additional data is called the attachment. + + Except, we only get the attachment if the command completes + successfully. For example, calling readlink with a non existent path + will result in a return packet: 'F-1,2' with no attachment. This is + as expected. + + Within remote_hostio_send_command we call remote_hostio_parse_result, + this parses the status code (-1 in our example above) and + then parses the errno value (2 in our example above). + + Back in remote_hostio_parse_result we then hit this block: + + /* Make sure we saw an attachment if and only if we expected one. */ + if ((attachment_tmp == NULL && attachment != NULL) + || (attachment_tmp != NULL && attachment == NULL)) + { + *remote_errno = FILEIO_EINVAL; + return -1; + } + + Which ensures that commands that expect an attachment, got an + attachment. + + The problem is, we'll only get an attachment if the command + succeeded. If it didn't, then there is no attachment, and that is as + expected. + + As remote_hostio_parse_result always sets the returned error number to + FILEIO_SUCCESS unless the packet contained an actual error + number (e.g. 2 in our example above), I suggest we should return early + if remote_hostio_parse_result indicates an error packet. + + I ran into this issue while working on another patch. In that patch I + was checking the error code returned by a remote readlink call and + spotted that when I passed an invalid path I got EINVAL instead of + ENOENT. This patch fixes this issue. + + Unfortunately the patch I was working on evolved, and my need to check + the error code went away, and so, right now, I have no way to reveal + this bug. But I think this is an obviously correct fix, and worth + merging even without a test. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix cast types for opencl + The bitshift tests for opencl have these failures: + + print /x (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8 + print (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8 + + Apparently opencl doesn't have the 'signed' modifier for types, only + the 'unsigned' modifier. + Even 'char' is guaranteed to be signed if no modifier is used, so + this changes the casts to match this logic. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix 64-bit shifts where long only has 32-bit size + On systems where long has 32-bit size you get these failures: + + print 1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff + print 1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff + print -1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff + print -1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff + + Fixed by changing the number-of-bits variable to ULONGEST. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix too-large or negative right shift of negative numbers + As seen in these test failures: + + print -1 >> -1 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1 + print -4 >> -2 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2 + + Fixed by restoring the logic from before the switch to gmp. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix right shift of negative numbers + PR31590 shows that right shift of negative numbers doesn't work + correctly since GDB 14: + + (gdb) p (-3) >> 1 + $1 = -1 + + GDB 13 and earlier returned the correct value -2. + And there actually is one test that shows the failure: + + print -1 >> 1 + $84 = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1 + + The problem was introduced with the change to gmp functions in + commit 303a881f87. + It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which + always rounds toward zero, and the gmp docu says this: + + For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple + bitwise right shifts. + For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift + treating n as two's complement the same as the bitwise logical functions + do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude. + + So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it + does right shifts for both positive and negative numbers. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590 + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Restore bitshift.exp tests + Commit cdd4206647 unintentionally disabled all tests of bitshift.exp, + so it actually just does this: + + Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ... + PASS: gdb.base/bitshift.exp: complete set language + + === gdb Summary === + + # of expected passes 1 + + It changed the 'continue' of unsupported languages to 'return', and + since ada is the first language and is unsupported, no tests were run. + + This changes it back to 'continue', and the following patches fix + the regressions that were introduced since then unnoticed. + + Approved-By: Tom Tromey + +2024-06-11 Kilian Kilger + + fix division by zero in target_read_string() + Under certain circumstances, a floating point exception in + target_read_string() can happen when the type has been obtained + by a call to stpy_lazy_string_elt_type(). In the latter function, + a call to check_typedef() has been forgotten. This makes + type->length = 0 in this case. + +2024-06-11 Tom Tromey + + Remove useless call to wnoutrefresh + This call to wnoutrefresh is not useful. It's based on the + misunderstanding that wnoutrefresh somehow prevents display, whereas + actually what it does is copy from one curses buffer to another. + + I'm working on a larger patch to clean up this area, but this + particular call can be removed immediately without consequence. + + Approved-By: Andrew Burgess + +2024-06-11 Tom Tromey + + Remove extract_long_unsigned_integer + The function extract_long_unsigned_integer is unused, so remove it. + Tested by rebuilding. + + Approved-By: Andrew Burgess + +2024-06-11 Alan Modra + + support_dt_relr aarch64 + Tweak commit db335d7e0a so that support_dt_relr returns false for + aarch64*-*-*ilp32. + +2024-06-11 Ciaran Woodward + + Fix printing strings on macOS Sonoma + On macOS sonoma, printing a string would only print the first + character. For instance, if there was a 'const char *s = "foobar"', + then the 'print s' command would print '$1 = "f"' rather than the + expected '$1 = "foobar"'. + + It seems that this is due to Apple silently replacing the version + of libiconv they ship with the OS to one which silently fails to + handle the 'outbytesleft' parameter correctly when using 'wchar_t' + as a target encoding. + + This specifically causes issues when using iterating through a + string as wchar_iterator does. + + This bug is visible even if you build for an old version of macOS, + but then run on Sonoma. Therefore this fix in the code applies + generally to macOS, and not specific to building on Sonoma. Building + for an older version and expecting forwards compatibility is a + common situation on macOS. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853 + +2024-06-11 David Guillen Fandos + + MIPS/opcodes: Add MIPS Allegrex DBREAK instruction + This complements the debug instruction set and uses the same encoding as + the VR5400/VR5500 devices. + + MIPS/opcodes: Exclude trap instructions for MIPS Allegrex + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-11 Alan Modra + + PR31872, Segfault in objdump (elf_slurp_reloc_table_from_section) + This one was triggered by trying to dump an AMDGPU object. + elf64-amdgcn.c lacks support for objdump relocation handling. + + PR 31872 + * elfcode.h (elf_slurp_reloc_table_from_section): Don't segfault + on NULL elf_info_to_howto_rel. + +2024-06-11 GDB Administrator + + Automatic date update in version.in + +2024-06-10 Ilya Leoshkevich + + IBM zSystems: Rewrite l(g)rl @GOTENT to larl for --no-pie + Regtested on s390x-redhat-linux. + + Rewriting l(g)rl @GOTENT to larl is unnecessarily guarded by + bfd_link_pic(). There were no use cases for this in the past, but + since recently the Linux Kernel on s390x is compiled with -fPIE + and linked with --no-pie. Remove the unnecessary bfd_link_pic() + check. + + bfd/ChangeLog: + + * elf32-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + * elf64-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lgrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + + ld/ChangeLog: + + * testsuite/ld-s390/s390.exp: Hook up the new tests. + * testsuite/ld-s390/gotreloc_31-no-pie-1.dd: New test. + * testsuite/ld-s390/gotreloc_64-no-pie-1.dd: New test. + +2024-06-10 Tom Tromey + + Make global_symbol_searcher::filenames private + This patch renames global_symbol_searcher::filenames and makes it + private, adding a new method to append a filename to the vector. This + also cleans up memory management here, removing an alloca from rbreak, + and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor + of having global_symbol_searcher manage the memory itself. + + Regression tested on x86-64 Fedora 38. + +2024-06-10 Tom de Vries + + [gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long long + If in gdb/python/python-internal.h, we pretend to have a platform that doesn't + support long long: + ... + -#ifdef HAVE_LONG_LONG + +#if 0 + ... + I get on arm-linux: + ... + (gdb) placement_candidate() + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: Python Exception : \ + Buffer returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: memory source api: second disassembler pass + ... + + The problem is that gdb_py_longest is typedef-ed to long, but the + corresponding format character GDB_PY_LL_ARG is defined to "L", meaning + "long long" [1]. + + Fix this by using "l", meaning long instead. Likewise for GDB_PY_LLU_ARG. + + Tested on arm-linux. + + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Tom de Vries + + [gdb/python] Fix gdb.python/py-disasm.exp on arm-linux + After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop: + ... + nop {0} + ... + we run into: + ... + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: add r11, sp, #0^M + 0x004004e0 <+8>: nop {0}^M + => 0x004004e4 <+12>: Python Exception : Buffer \ + returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test + ... + + This is caused by this code in gdbpy_disassembler::read_memory_func: + ... + gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj, + "read_memory", + "KL", len, offset)); + ... + where len has type "unsigned int", while "K" means "unsigned long long" [1]. + + Fix this by using "I" instead, meaning "unsigned int". + + Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means + "long long". + + Fix this by using type gdb_py_longest for offset, in combination with format + character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory. + + Tested on arm-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Matthieu Longo + + aarch64: warn on unpredictable results for new rcpc3 instructions + The previous patch for the feature rcpc3 introduced 4 new operations + (ldiapp, stilp, ldapr, stlr). + The specification mentions some cases of inputs causing unpredictable + results. gas currently fails to diagnose them, and does not emit + warnings. Even if the instruction encoding is valid, the developer + probably wants to know for those cases that the instruction won't have + the expected effect. + - ldiapp & stilp: + * unpredictable load pair transfer with register overlap + * unpredictable transfer with writeback + - ldapr & stlr: + * unpredictable transfer with writeback + + This patch also completes the existing relevant tests. + +2024-06-10 Maciej W. Rozycki + + Revert "MIPS/Allegrex: Exclude trap instructions" + This reverts commit a2e71b281a9365872451a157767e03a2e89ddaad. + + Revert "MIPS/Allegrex: Enable dbreak instruction" + This reverts commit c41020942b94ea7c5a58de4fed644826e8f0b509. + +2024-06-10 Tom de Vries + + [gdb/python] Note that python 3.6 assumes long long support + Starting with python 3.6, support for platforms without long long support + has been removed [1]. + + HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility, + so stop relying on them. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://github.com/python/cpython/issues/72148 + +2024-06-10 Alan Modra + + PR31873, buffer overflow in evax_bfd_print_dst + PR 31873 + * vms-alpha.c (evax_bfd_print_dst): Sanity check len against + dst_size. + +2024-06-10 Rostislav Krasny + + src-release.sh: don't take untracked files into account in the uncommitted changes check + +2024-06-10 David Guillen Fandos + + MIPS/Allegrex: Enable dbreak instruction + + MIPS/Allegrex: Exclude trap instructions + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-10 Jan Beulich + + x86/APX: convert ZU to operand constraint + Extremely rarely used attributes are inefficient when represented by a + separate attribute. Convert it to an operand constraint, as already + suggested during review. The collision with RegKludge is pretty simple + to resolve. + +2024-06-10 Jan Beulich + + x86: disassembler macro for condition code + Both CMPccXADD and APX'es {,CF}CMOVcc have almost identical entries + replicated 16 times each. Fold those to just one each by introducing a + %CC macro. (Note that the recording of ->condition_code in print_insn() + is merely for completeness for now; it's not used as long as only + VEX/EVEX encodings would consume it.) + + This then also renders condition codes printed consistent across all + respective insns; CMPxxXADD had a number of outliers so far. + +2024-06-10 Jan Beulich + + x86/APX: support extended SETcc form + As indicated during review, spelling/readability-wise + + setz %eax + + is easier than + + setzuz %al + + _and_ properly specifies the full register that's being modified. Permit + that form to be used, even if the spec writers are unwilling to formally + mention it. + + While there also correct the non-ZU EVEX form: That ought to also permit + memory operands. + +2024-06-10 Simon Marchi + + gdb: re-add necessary includes in tui/tui-win.c + Commit 9102a6c15c75 ("gdb/tui: cleanup includes") broke + gdb.python/tui-window.exp on Linux: + + Running /data/vries/gdb/src/gdb/testsuite/gdb.python/tui-window.exp ... + WARNING: timeout in accept_gdb_output + WARNING: timeout in accept_gdb_output + FAIL: gdb.python/tui-window.exp: Window was updated + + and caused a build failure on AIX: + + CXX tui/tui-win.o + tui/tui-win.c: In function 'void tui_sigwinch_handler(int)': + tui/tui-win.c:532:3: error: 'mark_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 532 | mark_async_signal_handler (tui_sigwinch_token); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + tui/tui-win.c: At global scope: + tui/tui-win.c:538:1: error: variable or field 'tui_async_resize_screen' declared void + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:538:26: error: 'gdb_client_data' was not declared in this scope + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~ + tui/tui-win.c: In function 'void tui_initialize_win()': + tui/tui-win.c:579:36: error: 'tui_async_resize_screen' was not declared in this scope + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:579:7: error: 'create_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + gmake: *** [Makefile:1947: tui/tui-win.o] Error 1 + + On Linux, the removal of the signal.h include causes the `#ifdef + SIGWINCH` sections to become inactive. The code builds, but then the + TUI fails to react to terminal size changes. When we add back the + inclusion of signal.h, then we see the same build error as on AIX. + + On AIX, I suppose that the SIGWINCH define is still seen by some other + transitive include. + + When I go back to before 9102a6c15c75, I don't see async-event.h and + signal.h being marked as unneeded by clangd, so I'm not sure why I + removed them in the first place... I'll be more careful in the future + (files with #ifdef/#ifndef can be tricky w.r.t. determining necessary + includes). + + So, re-add the inclusion of signal.h and async-event.h + + Change-Id: I3ed385c2dc1726ade2118a5186ea7cccffd12635 + Reported-By: Aditya Kamath1 + Reported-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865 + +2024-06-10 Tom de Vries + + [gdb/testsuite] Don't use set auto-solib-add off + In test-case gdb.mi/mi-var-child-f.exp, we have: + ... + mi_gdb_test "-gdb-set auto-solib-add off" "\\^done" + mi_runto prog_array + mi_gdb_test "nosharedlibrary" ".*\\^done" + ... + + This was added to avoid a name clash between the array variable as defined in + gdb.mi/array.f90 and debug info in shared libraries, and used in other places + in the testsuite. + + The same workaround is also used to ignore symbols from shared libraries when + excercising for instance a command that prints all symbols. + + However, this approach can cause problems for targets like arm that require + symbol info for some libraries like ld.so and libc to fully function. + + While absense of debug info for shared libraries should be handled gracefully + (which does need fixing, see PR31817), failure to do so should not result + in failures in unrelated test-cases. + + Fix this by removing "set auto-solib-add off". + + This ensures that we don't run into PR31817, while the presence of + nosharedlibrary still ensures that in the rest of the test-case we're not + bothered by shared library symbols. + + Likewise in other test-cases. + + Approved-by: Kevin Buettner + + Tested on arm-linux. + +2024-06-10 Jan Beulich + + gas: extend \+ support to .rept + PR gas/31752 + + While not quite as macro-like as .irp / .irpc, this perhaps benefits from + supporting \+ even more than those: It allows, where desired, to get away + without maintaining an explicit count variable in source code. + + Keep .rep (and custom per-arch uses of s_rept() / do_repeat()) behavior + unaltered. + +2024-06-10 Jan Beulich + + x86/APX: add missing CPU requirement to imm+rm forms of insns + This was overlooked when the form was added by dd74a603376e ("Support + APX NF"). + +2024-06-10 Clément Chigot + + ld-aarch64: check support before launching dt_relr tests + Not all aarch64 targets supports dt_relr as this requires some + mechanisms on the OS side. + + Adjust support_dt_relr helper and use it in aarch64-elf.exp. + +2024-06-10 GDB Administrator + + Automatic date update in version.in + +2024-06-09 Alan Modra + + regen sim/frv files for copyright update + +2024-06-09 Matthieu Longo + + autoupdate: regen after replacing obsolete macros + +2024-06-09 Matthieu Longo + + autoconf: delete obsolete unused m4 file + config/uintmax_t.m4 contains only one function: jm_AC_TYPE_UINTMAX_T. + After a grep, I could not find any usage of it. + + jm_AC_TYPE_UINTMAX_T seems to be an old implementation of the officially + suppported AC_TYPE_UINTMAX_T. + Doc: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/ + autoconf-2.72/autoconf.html#index-AC_005fTYPE_005fUINTMAX_005fT-1 + + config/stdint.m4 seems to have taken over. The usage of + AC_REQUIRE([AC_TYPE_UINTMAX_T]) is not garded or inside a function, so it + will also automatically be run for the configure.ac files using + AC_CONFIG_MACRO_DIRS([../config]) instead of m4_include([../config/stdint.m4]). + + It seems that people replaced jm_AC_TYPE_UINTMAX_T occurences by + AC_TYPE_UINTMAX_T, and forgot to delete uintmax_t.m4. + Deleting the file and regenerating the build scripts results in no diff, + so it looks safe to delete it from the repository. + +2024-06-09 Matthieu Longo + + autoupdate: add square brackets around arguments of AC_INIT + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2 + + autoupdate: add square brackets around argument of AC_PREREQ + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fPREREQ-1 + + autoupdate: replace old version of AC_INIT by the new one + - old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3 + + autoupdate: replace obsolete macros AC_CONFIG_HEADER + - AC_CONFIG_HEADER by AC_CONFIG_HEADERS + https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER + + autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM + - AC_CANONICAL_SYSTEM by: + * AC_CANONICAL_HOST where host, and host_alias are needed + * AC_CANONICAL_TARGET where target_alias is needed + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1 + + autoupdate: replace obsolete macros AC_PROG_LIBTOOL + - AC_PROG_LIBTOOL by LT_INIT + https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#index-LT_005fINIT + + autoupdate: replace obsolete macros AC_AIX, AC_MINIX, and AC_GNU_SOURCE + - AC_AIX, AC_MINIX, and AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fAIX + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fMINIX-1 + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fGNU_005fSOURCE-1 + + autoupdate: replace obsolete macros AC_HELP_STRING + - AC_HELP_STRING by AS_HELP_STRING + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fHELP_005fSTRING-1 + Except for the ifdef in lib-prefix.m4, make the defun of AC_LIB_ARG_WITH + unconditional. + +2024-06-09 H.J. Lu + + gold: Properly remove the versioned symbol + When the versioned symbol foo is removed from the shared library, the + ".symver foo,foo@VER" directive provides binary compatibility for foo@VER. + In this case, the unversioned symbol foo should be hidden and shouldn't + generate a multiple definition error. + + PR gold/31830 + * resolve.cc (Symbol_table::resolve): Move symbol version handling + to ... + * symtab.cc (Symbol_table::add_from_object): Here. If the hidden + version from .symver is the same as the default version from the + unversioned symbol, don't make the unversioned symbol the default + versioned + symbol. + * testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr31830.sh. + (check_DATA): ver_test_pr31830_a.syms and ver_test_pr31830_b.syms. + (ver_test_pr31830_a.syms): New. + (ver_test_pr31830_b.syms): Likewise. + (ver_test_pr31830_a.so): Likewise. + (ver_test_pr31830_b.so): Likewise. + * testsuite/Makefile.in: Regenerated. + * testsuite/ver_test_pr31830.script: New file. + * testsuite/ver_test_pr31830.sh: Likewise. + * testsuite/ver_test_pr31830_a.c: Likewise. + * testsuite/ver_test_pr31830_b.c: Likewise. + * testsuite/ver_test_pr31830_lto.c: Likewise. + * testsuite/ver_test_pr31830_lto.sh: Likewise. + +2024-06-09 GDB Administrator + + Automatic date update in version.in + +2024-06-08 Tom Tromey + + Fix typo in warning in gdb/configure + Eli pointed out that "babeltrace" is misspelled in a warning in + gdb/configure. This patch fixes the typo. + +2024-06-08 Eli Zaretskii + + gdb: Avoid compilation warning in gcore.c. + See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html + for the details. + + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove get_exec_file + I believe that the get_exec_file function is unnecessary, and the code + can be simplified if we remove it. + + Consider for instance when you "run" a program on Linux with native + debugging. + + 1. run_command_1 obtains the executable file from + `current_program_space->exec_filename ()` + 2. it passes it to `run_target->create_inferior()`, which is + `inf_ptrace_target::create_inferior()` in this case, which then + passes it to `fork_inferior()` + 3. `fork_inferior()` then has a fallback, where if the passed exec file + is nullptr, it gets its from `get_exec_file()`. + 4. `get_exec_file()` returns `current_program_space->exec_filename ()` + - just like the things we started with - or errors out if the + current program space doesn't have a specified executable. + + If there's no exec filename passed in step 1, there's not going to be + any in step 4, so it seems pointless to call `get_exec_file()`, we could + just error out when `exec_file` is nullptr. But we can't error out + directly in `fork_inferior()`, since the error is GDB-specific, and that + function is shared with GDBserver. + + Speaking of GDBserver, all code paths that lead to `fork_inferior()` + provide a non-nullptr exec file. + + Therefore, to simplify things: + + - Make `fork_inferior()` assume that the passed exec file is not + nullptr, don't call `get_exec_file()` + - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace, + nto-procfs, procfs) to error out when the exec file passed to their + create_inferior method is nullptr. Some targets are fine with a + nullptr exec file, so we can't check that in `run_command_1()`. + - Add the `no_executable_specified_error()` function, which re-uses the + error message that `get_exec_file()` had. + - Change some targets (go32-nat, nto-procfs) to not call + `get_exec_file()`, since it's pointless for the same reason as in the + example above, if it returns, it's going the be the same value as the + `exec_file` parameter. Just rely on `exec_file`. + - Remove the final use of `get_exec_file()`, in `load_command()`. + - Remove the `get_exec_file()` implementations in GDB and GDBserver and + remove the shared declaration. + + Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove dead code in nto-procfs.c + `get_exec_file()` never returns nullptr, so remove some dead code that + check for a nullptr return. + + Change-Id: I9eff2a013d602588aaf4477a22cf45f2bc417c6a + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: replace `get_exec_file (0)` calls with `current_program_space->exec_filename ()` + Calls of `get_exec_file (0)` are equivalent to just getting the exec + filename from the current program space. I'm looking to remove + `get_exec_file`, so replace these uses with + `current_program_space->exec_filename ()`. + + Remove the `err` parameter of `get_exec_wrapper` since all the calls + that remain pass 1, meaning to error out if no executable is specified. + + Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: make progspace::exec_filename private, add getter / setter + Just like the title says... I think this makes things a bit clearer, for + instance where the exec filename is set. It also makes the read call + sites a bit nicer, avoiding the `.get ()`. + + Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: cleanup includes + Remove includes reported as unused by clangd. Then, add any includes + necessary to get rid of errors (includes possibly relying on previous + includes).. + + I didn't remove the includes of gdb-safe-ctypes.h, because it appears to + do some some preprocessor magic, redefining standard macros. I'm afraid + that removing these includes could change the behavior unintentionally. + + Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: add IWYU export pragams to gdb_curses.h + It seems like gdb_curses.h is included whenever we want to access + ncurses functionality, instead of including directly ncurses.h. As a + result, clangd often erroneously shows that gdb_curses.h inclusions are + unused. + + By adding those pragmas, clangd (and the include-what-you-use tool) + understands that gdb_curses.h is a valid provider for whatever these + ncurses.h files provide. + + Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: change some macros to functions + Change the `TUI_*` macros to access known windows to functions. Define + them in their respective files, because trying to define them in + tui-data.h would end up causing include cycles. + + This makes static analysis (detection of unused include files in this + case) more accurate, and I think in general we should avoid hiding + code behind macros if not necessary. + + Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af + Approved-By: Tom Tromey + +2024-06-08 GDB Administrator + + Automatic date update in version.in + +2024-06-07 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp + Test behaviour of watchpoints triggered by MOPS instructions. This test + is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS + instructions rather than whatever instructions are used in the libc's + implementation of memset/memcpy/memmove. + + There's a separate watched variable for each set of instructions so that + the testcase can test whether GDB correctly identified the watchpoint + that triggered in each case. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Add record support for MOPS instructions. + There are two kinds of MOPS instructions: set instructions and copy + instructions. Within each group there are variants with minor + differences in how they read or write to memory — e.g., non-temporal + read and/or write, unprivileged read and/or write and permutations of + those — but they work in the same way in terms of the registers and + regions of memory that they modify. + + The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS + instructions are recorded and correctly reversed. Not all variants of the + copy and set instructions are tested, since there are many and the record + and replay target processes them in the same way. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Disable displaced single-step for MOPS instructions + The AArch64 MOPS (Memory Operation) instructions provide a standardised + instruction sequence to perform a memset, memcpy or memmove. A sequence is + always composed of three instructions: a prologue instruction, a main + instruction and an epilogue instruction. As an illustration, here are the + implementations of these memory operations in glibc 2.39: + + (gdb) disassemble/r + Dump of assembler code for function __memset_mops: + => 0x0000fffff7e8d780 <+0>: d503201f nop + 0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1 + 0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1 + 0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1 + 0x0000fffff7e8d794 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memcpy_mops: + => 0x0000fffff7e8c580 <+0>: d503201f nop + 0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2! + 0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2! + 0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2! + 0x0000fffff7e8c594 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memmove_mops: + => 0x0000fffff7e8d180 <+0>: d503201f nop + 0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2! + 0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2! + 0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2! + 0x0000fffff7e8d194 <+20>: d65f03c0 ret + End of assembler dump. + + The Arm Architecture Reference Manual says that "the prologue, main, and + epilogue instructions are expected to be run in succession and to appear + consecutively in memory". Therefore this patch disables displaced stepping + on them. + + The testcase verifies that MOPS sequences are correctly single-stepped. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Tom de Vries + + [gdb/tdep] Fix ARM_LINUX_JB_PC_EABI + In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1 + since glibc 2.20. + + See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and + setjmp."). + + Update it, allowing us to run into the gdb/26967 kfail. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR arm/tdep + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089 + +2024-06-07 Alan Modra + + Re: Yet another ecoff fuzzed object fix + In commit 6fc018e9e593 I replaced the fdr_ptr csym check against the + header isymMax count with a check against bfd symcount. In fact, both + checks are needed. The isymMax check sanity checks accesses against + the external sym array, the symcount one against the internal array. + + * ecoff.c (_bfd_ecoff_slurp_symbol_table): Reinstate fdr_ptr + csym check against isymMax. + +2024-06-07 Szabolcs Nagy + + aarch64: Test DT_RELR with discarded sections + +2024-06-07 Szabolcs Nagy + + aarch64: Fix DT_RELR support with discarded sections + In case of discarded sections, via /DISCARD/ or .gnu.linkonce, + relr relocation accounting was wrong. This broke building linux. + + The issue was that the *_relocate_section logic was copied to + record_relr_non_got_relocs to find the relative relocs that can + be packed, however *_relocate_section is not called on sections + that are discarded, while record_relr_non_got_relocs is called + for all input sections. The fix is to filter out the discarded + sections with the same logic that is used to count non-GOT + relocs in *_late_size_sections for local symbols earlier. + Use the discarded_section helper in both cases to clarify the + intent and handle all corner-cases consistently. + + GOT relocations are affected too if all sections are discarded + that reference the GOT entry of a particular symbol, however + this can cause unused GOT entries independently of DT_RELR, and + the only difference with DT_RELR is that a relative reloc may be + emitted instead of a R_AARCH64_NONE for the unused GOT entry + which is acceptable. A proper fix would require redoing the GOT + refcounting after we know the discarded sections, see bug 31850. + +2024-06-07 Tom de Vries + + [gdb/testsuite] Fix gdb.fortran/array-bounds.exp on arm + When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into: + ... + (gdb) print &foo^M + $1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo + print &bar^M + $2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar + ... + + This is due to gcc PR debug/54934. + + The test-case contains a kfail for this, which is only activated for + x86_64/i386. + + Fix this by enabling the kfail for all ilp32 targets. + + Also: + - change the kfail into an xfail, because gdb is not at fault here, and + - limit the xfail to the gfortran compiler. + + Tested on arm-linux. + +2024-06-07 GDB Administrator + + Automatic date update in version.in + +2024-06-06 Andrew Burgess + + gdb/doc: use POD2MAN5 when appropriate + In commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + I rewrote the rules for building the man pages. While doing this I + accidentally switched from using MAN2POD5 to MAN2POD1 for generating + the file gdbinit.5. + + Restore use of MAN2POD5 where appropriate. + +2024-06-06 Johan Sternerup + + DAP: Handle "stepOut" request in outermost frame + Previously a "stepOut" request when in the outermost frame would result + in a sucessful response even though gdb internally would reject the + associated "finish" request, which means no stoppedEvent would ever be + sent back to the client. Thus the client would believe the inferior was + still running and as a consequence reject subsequent "next" and "stepIn" + requests from the user. + + The solution is to execute the underlying finish command as a background + command, i.e. `finish &`. If we're in the outermost frame an exception + will be raised immediately, which we can now capture and report back to + the client as success=False so then the absence of a `stopped` event is + no longer a problem. + + We also make use of the `defer_stop_event` option to prevent a stop + event from reaching the client until the response has been sent. + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow gdb exception in exec_and_log to propagate + This allows a request to specify that any gdb exception raised in + exec_and_log within the gdb thread to be propagated back to the DAP + thread (using the Canceller object as the orchestrator). + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow for deferring stop events from gdb thread + The existing `send_event_later()` method allows commands processed on + the DAP thread to queue an event for execution until after the response + has been sent to the client. + + We now introduce a corresponding method for use by the gdb thread. This + method `send_event_maybe_later()` will queue the event just like + `send_event_later()`, but only if it has been configured to do so by a + new @request option `defer_stop_events`. As the name implies the + functionality is currently only used for handling stop events. + + Approved-By: Tom Tromey + +2024-06-06 Richard Earnshaw + + arm: fix testsuite fallout on arm-elf and arm-nto from FPA removal + Removing FPA means that in some cases we default to 'no-fpu' in the + assembler when previously we would have picked FPA-format floating + numbers. This patch fixes the testsuite fallout on a couple of + targets that are affected by this change. Where possible we do this + by adding an option to set the floating-point format, but for bad-bss + we just skip the test. + +2024-06-06 Nick Clifton + + Updated Spanish translation for the bfd/ directory + +2024-06-06 Andrew Burgess + + opcodes/riscv: prevent future use of disassemble_info::fprintf_func + The previous commit removed a use of disassemble_info::fprintf_func + which had been added to the RISC-V disassembler after the disassembler + had been switched to use ::fprintf_styled_func, for styled output. + + To prevent future mistakes, I propose adding a #define to rename + fprintf_func to something which does not exist. If this had been in + place then the before the previous commit libopcodes would have failed + to compile, like this: + + ../../src/opcodes/riscv-dis.c: In function ‘print_reg_list’: + ../../src/opcodes/riscv-dis.c:229:7: error: ‘disassemble_info’ {aka ‘struct disassemble_info’} has no member named ‘please_use_fprintf_styled_func_instead’ + 229 | info->fprintf_func (info->stream, "%s", riscv_gpr_names[X_RA]); + | ^~ + + If this commit is accepted then I'll follow up with another commit + that adds the same #define to every disassembler that has been + converted to use styled output. + + As the RISC-V disassembler is now fully styled, this commit should + make no difference at all. + +2024-06-06 Andrew Burgess + + opcodes/riscv: add styling support to print_reg_list + I noticed that some unstyled output had crept into the risc-v + disassembler in this commit: + + commit 9132c8152b899a1683bc886f8ba76bedadb48aa1 + Date: Tue Feb 27 11:48:11 2024 +0800 + + RISC-V: Support Zcmp push/pop instructions. + + this commit adds styling support. The risc-v disassembler is now once + again, fully styled. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfwma extension + This implements the Zvfbfwma extension, as of version 1.0. + View detailed information in: + + + 1 In spec: "Zvfbfwma requires the Zvfbfmin extension and the Zfbfmin extension." + 1.1 In Embedded Processor: Zvfbfwma -> Zvfbfmin -> Zve32f + 1.2 In Application Processor: Zvfbfwma -> Zvfbfmin -> V + 1.3 In both scenarios, there are: Zvfbfwma -> Zfbfmin + + 2 Depending on different usage scenarios, the Zvfbfwma extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies in + scenario of Embedded Processor. This is consistent with the processing + strategy in Zvfbfmin. In scenario of Application Processor, it is + necessary to explicitly indicate the dependent 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfwma. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfwma.d: New test. + * testsuite/gas/riscv/zvfbfwma.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFWMACCBF16_VF): Define. + (MASK_VFWMACCBF16_VF): Ditto. + (MATCH_VFWMACCBF16_VV): Ditto. + (MASK_VFWMACCBF16_VV): Ditto. + (DECLARE_INSN): New declarations for Zvfbfwma. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFWMA + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfwma instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfmin extension + This implements the Zvfbfmin extension, as of version 1.0. + View detailed information in: + + + Depending on different usage scenarios, the Zvfbfmin extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies + in scenario of Embedded Processor. In scenario of Application + Processor, it is necessary to explicitly indicate the dependent + 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfmin.d: New test. + * testsuite/gas/riscv/zvfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFNCVTBF16_F_F_W): Define. + (MASK_VFNCVTBF16_F_F_W): Ditto. + (MATCH_VFWCVTBF16_F_F_V): Ditto. + (MASK_VFWCVTBF16_F_F_V): Ditto. + (DECLARE_INSN): New declarations for Zvfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFMIN + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfmin instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zfbfmin extension + This implements the Zfbfmin extension, as of version 1.0. + + View detailed information in: + + + 1 The Zfbfmin extension depend on 'F', and the FLH, FSH, FMV.X.H, and + FMV.H.X instructions as defined in the Zfh extension. + + 2 The Zfhmin extension includes the following instructions from the Zfh + extension: FLH, FSH, FMV.X.H, FMV.H.X... View detailed information in: + + + 3 Zfhmin extension depend on 'F'. + + 4 Simply put, just make Zfbfmin dependent on Zfhmin. + + Perhaps in the future, we could propose making the FLH, FSH, FMV.X.H, and + FMV.H.X instructions an independent extension to achieve precise dependency + relationships for the Zfbfmin. + + 5 For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zfbfmin.d: New test. + * testsuite/gas/riscv/zfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_FCVT_BF16_S): Define. + (MASK_FCVT_BF16_S): Ditto. + (MATCH_FCVT_S_BF16): Ditto. + (MASK_FCVT_S_BF16): Ditto. + (DECLARE_INSN): New declarations for Zfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZFBFMIN. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zfbfmin instructions. + +2024-06-06 Alan Modra + + Re: aarch64: Add some DT_RELR ld tests + aarch64-elf fails these tests due to .rela.dyn being at a different + address to that expected, and due to the symbol table being different. + Unexpected symbol numbering results in a mismatch of reloc r_info + field, but these are shown decoded so the raw field doesn't really add + anything to the test. + + * testsuite/ld-aarch64/relr-align.d: Accept any address for + .relr.dyn section. Don't match raw r_info field. + * testsuite/ld-aarch64/relr-data-shared.d: Likewise. + * testsuite/ld-aarch64/relr-got-shared.d: Likewise. + * testsuite/ld-aarch64/relr-text-shared.d: Likewise. + +2024-06-06 GDB Administrator + + Automatic date update in version.in + +2024-06-05 Richard Earnshaw + + NEWS: arm: note that FPA support has been removed + + arm: minor documentation cleanup given removal of FPA + The use in the documentation of .save for an FPA instruction is no-longer + relevant, so remove it. + + arm: remove disassembly support for the FPA co-processor + Remove the FPA support from the disassembler. This entails a couple + of testsuite fixes where we were (probably incorrectly) disassembling + a generic co-processor instruction using the legacy FPA opcodes. + + arm: remove FPA instructions from assembler + These can no-longer be generated as the options to reach them have now + gone. So remove the parsing support for FPA instructions. + + arm: remove options to select the FPA + Remove the command-line options to choose the FPA (or FPE - an + emulated FPA). From this point on it should be impossible to assemble + the old FPA instructions. + + arm: change default FPUs from FPA to none + Change the cases where the default FPU was FPA to none. This should + ensure that any code that used settings to pick the floating-point + order will not silently produce a different output. The options that + explicitly set the FPA remain for the moment. + +2024-06-05 Richard Earnshaw + + arm: redirect fp constant data directives through a wrapper + Assembler directives such as .float, or .double are handled by generic + code, but on Arm, their output can vary depeding on the type of FPU + begin targetted. When we remove FPA support we don't want to silently + generate different code for processors that previously defaulted to + the FPA, so redirect these directives through a wrapper function that + checks the FPU is enabled; we use the legacy -mno-fpu in the test to + catch this. + + Also fix a few tests so that they won't start to fail on targets (eg + arm-wince-pe) where there is no default format for the FPU and we pick + this from the default processor type. + +2024-06-05 Richard Earnshaw + + arm: adjust FPU selection logic + The logic here seems to be overly complex, so simplify it a bit. One + particular problem was that using the legacy -mno-fpu option was not + working properly, as this has all the feature bits set to zero causing + the code to then pick a different FPU as the default. Fix this by + only selecting an FPU as a fallback if the code has not otherwise + selected one: there was only one route by which this could happen. + + This patch is really a pre-cursor to the following one where we want + to make no-fpu internally a fall-back position for some legacy + processors where previously we would have dropped back to the FPA. + +2024-06-05 Richard Earnshaw + + arm: default to softvfp on armv6 or later cores + From armv6 onwards a lot of cores started to come with a physical VFP + implementation; but many still did not and in some cases there are + both variants. For the cores that lacked a physical VFP we would fall + back to FPU_NONE if the platform/ABI did not mandate something else. + To make matters worse, FPU_NONE is internal state used to imply + soft-fpa (ie a mixed-endian double format), so any use of .double in + hand-written assembly is almost certainly generating incorrect output. + + That's undesirable, all these cores should really default to a softvfp + model. + +2024-06-05 Richard Earnshaw + + arm: rename FPU_ARCH_VFP to FPU_ARCH_SOFTVFP + FPU_ARCH_VFP has always meant VFP floating-point format (natural FP + word order) but without any VFP instructions. But the name + FPU_ARCH_VFP is potentially confusing. This patch just changes the + name to make the meaning clearer. + + arm: remove FPA related tests + Remove various tests of the FPA instruction set and relocation support. + +2024-06-05 Nick Clifton + + Fix illegal memory access when bfd_get_section_contents is called with a NULL section pointer. + PR 31843 + +2024-06-05 Nelson Chu + + RISC-V: Tidy vendor core-v extension gas testcases + 1. Combined testcases into one if they use same extention name. + 2. Likewise for the fail testcases. + 3. Renamed with x-cv prefix, just like what other vendors did. + + gas/ + * testsuite/gas/riscv/cv-alu-*: Combined and renamed to + x-cv-alu. Likewise for fail testcases, to x-cv-alu-fail*. + * testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to + x-cv-bi and x-cv-bi-fail. + * testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to + x-cv-elw and x-cv-elw-fail. + * testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to + x-cv-mac and x-cv-mac-fail. + * testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to + x-cv-mem and x-cv-mem-fail. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVmem extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * doc/c-riscv.texi: Note XCVmem as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-mem-fail-march.d: New test. + * testsuite/gas/riscv/cv-mem-fail-march.l: New test. + * testsuite/gas/riscv/cv-mem-fail-march.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test. + * testsuite/gas/riscv/cv-mem-lbpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbrr.d: New test. + * testsuite/gas/riscv/cv-mem-lbrr.s: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbupost.d: New test. + * testsuite/gas/riscv/cv-mem-lbupost.s: New test. + * testsuite/gas/riscv/cv-mem-lburr.d: New test. + * testsuite/gas/riscv/cv-mem-lburr.s: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhrr.d: New test. + * testsuite/gas/riscv/cv-mem-lhrr.s: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhupost.d: New test. + * testsuite/gas/riscv/cv-mem-lhupost.s: New test. + * testsuite/gas/riscv/cv-mem-lhurr.d: New test. + * testsuite/gas/riscv/cv-mem-lhurr.s: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwrr.d: New test. + * testsuite/gas/riscv/cv-mem-lwrr.s: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbrr.d: New test. + * testsuite/gas/riscv/cv-mem-sbrr.s: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-shpost.d: New test. + * testsuite/gas/riscv/cv-mem-shpost.s: New test. + * testsuite/gas/riscv/cv-mem-shrr.d: New test. + * testsuite/gas/riscv/cv-mem-shrr.s: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-swpost.d: New test. + * testsuite/gas/riscv/cv-mem-swpost.s: New test. + * testsuite/gas/riscv/cv-mem-swrr.d: New test. + * testsuite/gas/riscv/cv-mem-swrr.s: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvmem string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVmem. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVmem. + (enum riscv_insn_class): Add the XCVmem instruction class. + + opcodes/ChangeLog: + + * riscv-opc.c: Add XCVmem instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVbi extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + Nazareno Bruschi + Lin Sinan + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + gas/ChangeLog: + + * config/tc-riscv.c (validate_riscv_insn): Add the necessary + operands for the extension. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbi as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-bi-beqimm.d: New test. + * testsuite/gas/riscv/cv-bi-beqimm.s: New test. + * testsuite/gas/riscv/cv-bi-bneimm.d: New test. + * testsuite/gas/riscv/cv-bi-bneimm.s: New test. + * testsuite/gas/riscv/cv-bi-fail-march.d: New test. + * testsuite/gas/riscv/cv-bi-fail-march.l: New test. + * testsuite/gas/riscv/cv-bi-fail-march.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvbi string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add disassembly for new operand. + * riscv-opc.c: Add XCVbi instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVelw extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvelw` instruction + class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + + * doc/c-riscv.texi: Note XCVelw as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-elw-fail.d: New test. + * testsuite/gas/riscv/cv-elw-fail.l: New test. + * testsuite/gas/riscv/cv-elw-fail.s: New test. + * testsuite/gas/riscv/cv-elw-fail-march.d: New test. + * testsuite/gas/riscv/cv-elw-fail-march.l: New test. + * testsuite/gas/riscv/cv-elw-fail-march.s: New test. + * testsuite/gas/riscv/cv-elw-pass.d: New test. + * testsuite/gas/riscv/cv-elw-pass.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvelw string. + + opcodes/ChangeLog: + + * riscv-opc.c: (riscv_opcode) Add event load instructions. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + instruction opcode macros. + * opcode/riscv.h (riscv_insn_class): Add INSN_CLASS_XCVELW. + +2024-06-05 Andrew Burgess + + gdb/testsuite: remove trailing \r from rust_llvm_version result + I noticed that the value returned by rust_llvm_version had a trailing + carriage return. I don't think this is causing any problems right + now, but looking at the code I don't think this was the desired + behaviour. + + The current code runs 'rustc --version --verbose', splits the output + at each '\n' and then loops over every line looking for the line that + contains the LLVM version. + + There are two problems here. First, at the end of each captured line + we have '\r\n', so when we split the lines on '\n', each of the lines + will still end with a '\r' character. + + Second, though we loop over the lines, when we try to compare the line + contents we actually compare the unsplit full output. Luckily this + still finds the match, but this renders the loop over lines redundant. + + This commit makes two fixes: + + 1. I use regsub to convert all '\r\n' sequences to '\n'; now when we + split on '\n' the lines will not end in '\r'. + + 2. Within the loop over lines block I now check the line contents + rather than the unsplit full output; now we capture a value + without a trailing '\r'. + + There's only one test (gdb.rust/simple.exp) that uses + rust_llvm_version, and it doesn't care if there's a trailing '\r' or + not, so this change should make no difference there. + + Approved-By: Tom Tromey + +2024-06-05 Andrew Burgess + + gdb: more filename styling in remote.c and target.c + I spotted a few more places where we could apply filename styling in + remote.c and target.c. Other than the styling, there should be no + user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-05 GDB Administrator + + Automatic date update in version.in + +2024-06-04 Tom Tromey + + Return global scope from DAP scopes request + A co-worker requested that the DAP code emit a scope for global + variables. It's not really practical to do this for all globals, but + it seemed reasonable to do this for globals coming from the frame's + compilation unit. For Ada in particular, this is convenient as it + exposes package-scoped variables. + + Reviewed-By: Eli Zaretskii + +2024-06-04 Tom Tromey + + Convert DAP disassemble code to use Block hashing + This changes the DAP disassemble code to use the new Block hashing, + storing the already-visited blocks in a set rather than a list. + +2024-06-04 Tom Tromey + + Memoize gdb.Block and make them hashable + In subsequent patches, it's handy if gdb.Block is hashable, so it can + be stored in a set or a dictionary. However, doing this in a + straightforward way is not really possible, because a block isn't + truly immutable -- it can be invalidated. And, while this isn't a + real problem for my use case (in DAP the maps are only used during a + single stop), it seemed error-prone. + + This patch instead takes the approach of using the gdb.Block's own + object identity to allow hashing. This seems fine because the + contents don't affect the hashing. In order for this to work, though, + the blocks have to be memoized -- two requests for the same block must + return the same object. + + This also allows (actually, requires) the simplification of the + rich-compare method for blocks. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-04 Tom Tromey + + Put "source" into DAP scope + I noticed a FIXME comment in the DAP code about adding a "source" + field to a scope. This is easy to implement; I don't know why I + didn't do this originally. + + Remove a couple unnecessary casts + After the previous bcache change, a couple of casts in objfiles.h are + now redundant. + +2024-06-04 Tom Tromey + + Make bcache more type-safe + The bcache uses memcpy to make copies of the data passed to it. In + C++, this is only safe for trivially-copyable types. + + This patch changes bcache to require this property, and slightly + changes the API to make it easier to use when copying a single object. + It also makes the new 'insert' template methods return the correct + type. + +2024-06-04 Tom Tromey + + Some constification in psymtab + This patch changes some spots in psymtab.[ch] to use 'const'. This is + just preparation for a subsequent patch. Note that psymbols are + conceptually const, and since they were changed to be + objfile-indepdendent, they are truly never modified -- which is what + makes this patch reasonably short. + + Rely on std::uncaught_exceptions + std::uncaught_exceptions is a C++17 feature, so I think we can remove + this conditional code from inferior.h. + +2024-06-04 Dmitry Neverov + + Add myself to gdb/MAINTAINERS + +2024-06-04 Rostislav Krasny + + src-release.sh: fix adjusting files permissions and cleaning + PR 31800 + +2024-06-04 Andrew Burgess + + gdb/testsuite: tests for debug lookup within the sysroot + Add tests for looking up debug information within the sysroot via both + build-id and gnu_debuglink. + + I wanted to ensure that the gnu_debuglink test couldn't make use of + build-ids, so I added the 'no-build-id' flag to gdb_compile. + + As these tests rely on setting the sysroot, if I'm running a + dynamically linked executable, GDB will try to find all shared + libraries within the sysroot. This would mean I'd have to figure out + and copy all shared libraries the executable uses, certainly possible, + but a bit of a pain. + + So instead, I've just compiled the test executable as a static binary. + Now there are no shared library dependencies. + + I can now split the debug information out from the test binary, and + place it within the sysroot. When GDB is started and the executable + loaded, we can check that GDB is finding the debug information within + the sysroot. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Approved-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/testsuite: make gdb_gnu_strip_debug consistent + While writing a test I realised that the default behaviour of + gdb_gnu_strip_debug doesn't match its comment. + + The comment says that the function takes a FILENAME, and splits the + file into FILENAME.stripped and FILENAME.debug, leaving FILENAME + unchanged. The comment says that a .gnu_debuglink will be added to + FILENAME.stripped. + + However, this is not true, FILENAME.stripped is created, with no debug + information. FILENAME.debug is created containing the debug + information. + + But, when adding the .gnu_debuglink we take FILENAME.stripped as the + input, and then overwrite FILENAME with the output. As a result, + FILENAME.stripped does not include a .gnu_debuglink, while FILENAME + contains the .gnu_debuglink and no debug information! + + The users of gdb_gnu_strip_debug can be split into two groups, those + who are using the .gnu_debuglink, these tests are all written assuming + that FILENAME is updated. + + Then there are some tests that only rely on gdb_gnu_strip_debug's + ability to split out the debug information, these tests are then going + to do a lookup based on the build-id, these tests don't require the + .gnu_debuglink. These tests use the FILENAME.stripped output file. + + This all seems too confused to me. + + As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I + propose that we just make that the actual, advertised behaviour of + this proc. + + So now, gdb_gnu_strip_debug will take FILENAME, and will split the + debug information out into FILENAME.debug. The debug information will + then be stripped from FILENAME, and by default a .gnu_debuglink will + be added to FILENAME pointing to FILENAME.debug. + + I've updated the two tests that actually relied on FILENAME.stripped + to instead just use FILENAME. + + One of the tests was doing a build-id based lookup, but was still + allowing the .gnu_debuglink to be added to FILENAME, I've updated this + test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops + the .gnu_debuglink from being added. + + All of the tests that call gdb_gnu_strip_debug still pass for me. + + Acked-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/Makefile.in: silence recipe for creating .deps/ directories + When building in a fresh directory we'll see some output like this: + + /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps + mkdir -p -- arch/.deps + /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps + mkdir -p -- cli/.deps + /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps + mkdir -p -- dwarf2/.deps + ... etc ... + + this commit uses silent-rules.mk to silence this output, now we'll + see: + + GEN arch/.deps + GEN cli/.deps + GEN dwarf2/.deps + ... etc ... + + The recipe that currently generates these directories uses + mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs + is deprecated and 'install-sh -d' should be used instead. This + silences the 'mkdir -p -- ...' part of the output. + + There should be no change in what is actually built after this commit. + + Approved-By: Tom Tromey + +2024-06-04 mengqinggang + + LoongArch: Disable linker relaxation if set the address of section or segment + If set the address of section or segment, the offset from pc to symbol + may become bigger and cause overflow. + +2024-06-04 mengqinggang + Jinyang He + + LoongArch: Make align symbol be in same section with alignment directive + R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only + created at the first time to handle alignment directive. This means that + all other sections may use this symbol. If the section of this symbol is + discarded, there may be problems. Search it in its own section. + + Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c. + + Reported-by: WANG Xuerui + Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t + +2024-06-04 Richard Earnshaw + + arm: testsuite: fix msdos line endings in tests + A couple of the tests in the testsuite were at some point in the past + committed with DOS-style CRLF line endings. This potentially causes + email problems if the tests are touched in the middle of a large patch + series so convert them to standard Un*x line endings. + +2024-06-04 GDB Administrator + + Automatic date update in version.in + +2024-06-03 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen4 + ChangeLog + 2024-06-01 Vladimir Mezentsev + + * common/hwctable.c: Add the hwc table for AMD Zen4. + * src/hwc_amd_zen4.h: New file. + * src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H. + +2024-06-03 Tom Tromey + + Remove one call to can_box from TUI + This removes a call to can_box from + tui_source_window_base::show_source_content. can_box will always + return true here. + + Approved-By: Andrew Burgess + +2024-06-03 Tom Tromey + + Fix deprecation text + I noticed one spot where deprecate_cmd is called with a second + argument that is not a command name. This patch fixes the problem. + + Regression tested on x86-64 Fedora 38. + +2024-06-03 Hannes Domani + + Enable call of overloaded subscript operator from python + If you try to use the overloaded subscript operator of a class + in python, it fails like this: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Cannot subscript requested type. + Error while executing Python code. + + This simply checks if such an operator exists, and calls it + instead, making this possible: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + 102 'f' + + Approved-By: Tom Tromey + +2024-06-03 Hannes Domani + + Allow calling of convenience functions with python + As mentioned in PR13326, currently when you try to call a + convenience function with python, you get this error: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). + Error while executing Python code. + + So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as + well, making this possible: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + 0 + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-06-03 Mark Wielaard + + src-release.sh: Use -T0 for xz compression + Use parallel compression to create the xz archive. + + On my machine (using 4 cores) this reduces the time to create + binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds. + + xz has supported -T0 since version 5.2.0 (released 2014-12-21). + +2024-06-03 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.tui/resize-2.exp + When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run + into: + ... + tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable + ^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout) + ... + + The test-case does "Term::resize 24 80 0" while having the settings of an + earlier "Term::resize 40 90", so both dimensions change. + + When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc: + - calls stty to change one dimension, + - waits for the message (enabled by "maint set tui-resize-message on") + confirming the resize has happened, + - calls stty to change the other dimension, and again + - waits for the message confirming the resize has happened. + + Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the + message is not printed, so stty is called twice, and afterwards we check for + the results of the two resizes, which is the test that is failing. + + The problem is that not waiting for a response after each stty call opens up + the possibility of the responses being merged. + + Fix this by calling Term::resize twice, changing one dimension at a time, and + waiting for a single prompt redisplay after each one. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + PR testsuite/31822 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822 + +2024-06-03 GDB Administrator + + Automatic date update in version.in + +2024-06-02 Tom Tromey + + Fix typo in tui-data.h + I noticed a typo in a comment in tui-data.h. + +2024-06-02 GDB Administrator + + Automatic date update in version.in + +2024-06-01 GDB Administrator + + Automatic date update in version.in + +2024-05-31 Kevin Buettner + + [gdb/testsuite] New test: gdb.base/errno.exp + Printing the value of 'errno' from GDB is sometimes problematic. The + situation has improved in recent years, though there are still + scenarios for which "print errno" doesn't work. + + The test, gdb.base/errno.exp, introduced by this commit, tests whether + or not GDB can print errno using a binary compiled in the following + different ways: + + - default: no switches aside from -g (and whatever else is added by the + testing framework) + - macros: macro info is included in the debuginfo; this is enabled by + using -g3 when using gcc or clang + - static: statically linked binary + - static-macros: statically linked binary w/ macro definitions included + in debuginfo + - pthreads: libpthread linked binary + - pthreads-macros: libpthread linked binary w/ macro definitions included + in debuginfo + - pthreads-static: Statically linked against libpthread + - pthreads-static-macros: Statically linked against libpthread w/ macro + definitions + + For each of these, the test also creates a corefile, then loads the + corefile and attempts to print errno again. + + Additionally, the test checks that a "masking" errno declared as a + local variable will print correctly. + + On Linux, if the machine is missing glibc debuginfo (or you have + debuginfod disabled), it's likely you'll see: + + (gdb) print errno + 'errno' has unknown type; cast it to its declared type + + But if you add a cast, the value of errno is often available: + + (gdb) print (int) errno + $1 = 42 + + The test detects this situation along with several others and does + 'setup_xfail' for tests that will almost certainly fail. It could be + argued that some of these ought to be KFAILs due to deficiencies in + GDB, but I'm not entirely certain which, if any, are fixable yet. + + On Fedora 39, without glibc debuginfo, there are no failures, but + I do see the following XFAILS: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Fedora 39, with glibc debug info, but without libc.a (for static + linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED + tests. + + So, even when testing in less than ideal conditions, either due to lack + of glibc debuginfo or lack of a libc to link against to make a static + binary, there are no failures. + + With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40, + Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs: + + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On FreeBSD 13.1, the total number of XFAILs are fewer, and could be + even better still if it had debug info for glibc: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + Starting with glibc-2.34, most of the pthreads library has been + incorporated into libc, so finding thread-local variables using + libthread_db is possible for several scenarios in which it previously + wasn't. But, prior to this, accessing errno for the default scenario + was a problem. This is borne out by running this new test on Fedora + 34, which uses glibc-2.33: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + In the v3 version of this test, Tom de Vries tested on openSUSE Leap + 15.5 and found a number of cases which showed a FAIL instead of an + XFAIL. The v4 version of this test fixed those problems. On Leap + 15.5, which uses glibc-2.31, with glibc debug info, I now see: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Leap 15.5, with glibc debuginfo missing, the results are a little + worse: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + The v5 version of this test fixed failures when testing with + check-read1. (Thanks to Linaro CI for finding these.) I revised the + regular expressions being used so that the failures were eliminated, + but the results mentioned above have not changed. + + The v6 version of this test fixes some nits pointed out by both Tom + de Vries and Pedro Alves. One of Pedro's suggestions was to rename the + test from check-errno.exp to errno.exp, so in v5, the name has + changed. Tom also noticed that there were failures when using + --target_board=native-extended-gdbserver. For v6, I've tested on 10 + different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o + static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o + glibc debuginfo, and Fedora 34) using "make check" and "make check-read1" + using target boards "unix", "native-extended-gdbserver", and + "native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for + a total of 12 distinct test runs on each machine. I've also tested the + native-only cases on FreeBSD. (Attempting to test against gdbserver + on FreeBSD resulted in hangs while running the test suite.) + + The v7 version of this test simplifies the REs used in the uses of + gdb_test_multiple by adding -wrap and removing parts of the REs which + match the GDB prompt. In cases where there was a leading '.*', those + were removed too. Thanks to Pedro for explaining how to use -wrap. + + So, bottom line, this test does not introduce any new failures on the + platforms on which I've tested, but the XFAILs are certainly unfortunate. + Some aren't fixable - e.g. when attempting to make a function call while + debugging a core file - but I think that some of them are. I'm using + this new test case as a starting point for investigating problems with + printing errno. + + Co-Authored-By: Jan Kratochvil + Approved-By: Tom de Vries + +2024-05-31 Claudio Bantaloukas + + aarch64, testsuite: avoid regexes in opcode field + Some dejagnu files use regexes rather than specific encodings. This + change replaces them with the explicit encodings we expect. + + Tested against aarch64-unknown-linux-gnu and aarch64-none-elf. + +2024-05-31 saurabh.jha@arm.com + + gas, aarch64: Fixes in texi and tests following faminmax and lut changes + Making two cleanups that came out of the comments from my previous + patches: + 1. Fixing `c-aarch64.texi` file so that the AArch64 architecture + extensions are ordered alphabetically. + 2. Fixing faminmax test cases so that they follow the existing test + conventions. + +2024-05-31 Tom Tromey + + Move dwarf2_per_bfd::index_addrmap to mapped_gdb_index + dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader, + so this field can be moved to mapped_gdb_index instead. Then, + cooked_index_functions::find_per_cu can be removed in favor of a + method on the index object. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821 + Approved-By: Simon Marchi + +2024-05-31 Szabolcs Nagy + + aarch64: Add some DT_RELR ld tests + +2024-05-31 Szabolcs Nagy + + aarch64: Add DT_RELR support + The logic to decide if an input relocation for a symbol becomes a + particular kind of output relocation is one of the hard to maintain + parts of the bfd ld backend, since it is partially repeated across + + elfNN_aarch64_check_relocs (where dynamic relocations are counted per + symbol and input section), + + elfNN_aarch64_late_size_sections (where relocation sections are sized + and GOT offsets assigned), + + elfNN_aarch64_relocate_section (where most relocations are applied and + output to a relocation section), + + elfNN_aarch64_finish_dynamic_symbol (where some of the GOT + relocations are applied and output). + + The DT_RELR support adds another layer to this complexity: after the + output relocation sections are sized, so all dynamic relocations are + accounted (in elfNN_aarch64_late_size_sections), we scan the symbols + and input relocations again to decide which ones become relative + relocations that can be packed. The sizes of the relocation sections + are updated accordingly. This logic must be consistent with the code + that applies the relocs later so each relative relocation is emitted + exactly once: either in .rela.* or packed in .relr.dyn. + + Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that + may be called repeatedly whenever the layout changes since an address + change can affect the size of the packed format. Then the final content + is emitted in elfNN_aarch64_finish_relative_relocs, that is called + after the layout is final and before relocations are applied and + emitted. These hooks are only called if DT_RELR is enabled. + + We only pack relative relocs that are known to be aligned in the output + during .relr.dyn sizing, the potentially unaligned relative relocs are + emitted normally (in .rela.*, not packed), because the format requires + aligned addresses. + +2024-05-31 Jan Beulich + + x86: reduce check_{byte,word,long,qword}_reg() overhead + These run after template matching. Therefore it is quite pointless for + them to check all operands, when operand sizes matching across operands + is already known. Exit the loops early in such cases. + + In check_byte_reg() also drop a long-stale part of a comment. + +2024-05-31 Felix Willgerodt + Nils-Christian Kempke + + gdb, amd64: remove unused forward declarations + These structs are not referenced anywhere anymore and seemed to have been + missed at some point when their usage was removed. + + Approved-By: Tom Tromey + +2024-05-31 Felix Willgerodt + + gdb, doc: Fix AVX-512 documentation. + org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the + docs yet. Fix that. + + In addition the documentation describes xmm registers with an `h` + (e.g. xmm16h). I am assuming that we follow the register xml files here, + which don't have the h suffix. So this removes that as well. + + Approved-By: Eli Zaretskii + +2024-05-31 Simon Marchi + + gdb: remove unused includes in utils.h + Remove some includes reported as unused by clangd. Add some includes in + other files that were previously relying on the transitive include. + + Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e + +2024-05-31 GDB Administrator + + Automatic date update in version.in + +2024-05-30 Simon Marchi + + gdb: remove unused includes in symfile.c + Remove some includes reported as unused by clangd. + + Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6 + +2024-05-30 Simon Marchi + + gdb: remove unused includes in breakpoint.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d + +2024-05-30 Nick Clifton + + Update binutils release documentation to include using the -z option when invoking src-release.sh + +2024-05-30 Mark Wielaard + + src-release.sh: Support zstd compression + +2024-05-30 Simon Marchi + + .gitignore: ignore .vscode + +2024-05-30 GDB Administrator + + Automatic date update in version.in + +2024-05-29 Andrew Burgess + + gdb/doc: don't have .pod targets separate to man page targets + While preparing the new release it was discovered that commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + was causing problems. Given a release tar file, an attempt to build + and install GDB would give an error like this: + + [...] + TEXI2POD gdb.pod + cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make[5]: *** [Makefile:663: gdb.pod] Error 2 + + The problem here is how the man pages are built, and how they are + distributed within a release. + + Within the development (git) tree, the man page files are not part of + the source tree, these files are built as needed. Within a release + tar file though, the man pages are included. The idea being that a + user can build and install GDB, including getting the man pages, + without having to install the tools needed to generate the man pages. + + The man pages are generated in a two step process. First the .texi + file is processed with texi2pod to create a .pod file, then this .pod + file is processed to create the .1 or .5 man file. + + Prior to the above commit these two steps were combined into a single + recipe, this meant that when a user performed a build/install from a + release tree all of the dependencies, as well as the final result, + were all present in the source tree, and so nothing needed to be + rebuilt. + + However, the above commit split the two steps apart. Now we had a + separate rule for building the .pod files, and the .1/.5 man page + files depended on the relevant .pod file. + + As the .pod files are not shipped in a GDB release, this meant that + one of the dependencies of the man page files was now missing. As a + result if a user tried to install from a release tree a rebuild of the + .pod files would be attempted, and if that succeeded then building the + man pages would follow that. + + Unfortunately, building the .pod files would fail as the GDBvn.texi + file, though present in the source tree, was not present in the build + tree, which is where it is needed for the .pod file generation to + work. + + To fix this, I propose merging the .pod creation and the .1/.5 man + page creation back into a single recipe. Having these two steps split + is probably the "cleaner" solution, but makes it harder for us to + achieve our goal of shipping the prebuilt man page files. I've added + a comment explaining what's going on (such a comment would have + prevented this mistake having been made in the first place). + + One possibly weird thing here is that I have left both an + ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S) + recipes. This is 100% not going to break anything, these just print + two different progress messages while executing the recipes, but I'm + not sure if this is considered poor style or not. Maybe we're only + supposed to have a single ECHO_* per recipe? + + Anyway, even if this is poor style, I figure it really is just a style + thing. We can tweak this later as needed. Otherwise, this commit + should fix the current issue blocking the next GDB release. + + Approved-By: Tom Tromey + +2024-05-29 Szabolcs Nagy + + readelf: Use section names for displaying RELR relocs + In some cases using section names instead of symbol names for + displaying an address is more useful. + + If the symbol falls outside the section where the address is + then likely it is not useful to display the address relative to. + + And if symbols are stripped from a binary then printing the + section that contains the address is more useful than printing + . + +2024-05-29 Szabolcs Nagy + + readelf: Fix symbol display for RELR relocs + Filter symbols before binary searching for the right symbol to display + for a given address, such that only displayable symbols are present and + at most one per address. + + The current logic does not handle multiple symbols for the same address + well if some of them are empty, the selected symbol is not stable with + respect to an unrelated symbol table change and on aarch64 often mapping + symbols are displayed which is not useful. + + Filtering solves these problems at the cost of a linear scan of the + sorted symbol table. + + The heuristic to select the best symbol likely could be improved, this + patch aims to improve symbol display for RELR without complex logic + such that the output is useful and stable for ld tests. + +2024-05-29 Jan Beulich + + x86/Intel: warn about undue mnemonic suffixes + Except for very few insns mnemonic suffixes aren't permitted in Intel + syntax. Warn about such for now, indicating that they will be outright + refused down the road. + + While fiddling with testcases to address fallout, drop a few things + which should never have been tested as valid Intel syntax. + + Also add a previously missing line to simd-suffix.d. + +2024-05-29 Jan Beulich + + x86/Intel: SHLD/SHRD have dual meaning + Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode + an L suffix may be used, we need to be consistent with this. + + Take the easy route, despite that still leading to an anomaly which is + also visible from the new testcase: + + shld eax, ecx, 1 + shld eax, ecx, cl + + can mean two things with APX: SHL with a D suffix in NDD EVEX encoding, + or the traditional SHLD in legacy encoding. + +2024-05-29 Alan Modra + + PR31796, Internal error in write_function_pdata at obj-coff-seh + PR31796 is the result of lack of aarch64 support in obj-coff-seh.c. + Nick fixed this with commit 73c8603c3f. Make the seh support + consistently warn in future if some archictecture is missing, rather + than giving internal errors. + + PR 31796 + * config/obj-coff-seh.c (verify_target): New function. + (obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc), + (obj_coff_seh_endprologue): Use it. + +2024-05-29 GDB Administrator + + Automatic date update in version.in + +2024-05-28 Dimitar Dimitrov + + ld: pru: Increase the default memory region sizes + The default memory region sizes for PRU were set somewhat arbitrarily to + the sizes of the most popular BeagleBone board with AM33x SoC. But the + PRU toolchain documentation has always instructed to use SoC-specific + spec files to override the defaults and set the correct memory sizes [1]. + + The small default memory sizes can cause IMEM memory region overflow + even for simple printf("Hello world") programs, as usually done by + Autotools checks. The stdio is simply too big to fit in 8K + instruction memory. This can confuse the check and lead to wrong + feature selection during configure [2]. + + Fix by bumping the default DMEM and IMEM memory sizes. + + There is no need to backport this patch. Issue was caught with a + feature-rich newlib build used for daily CI. The release builds of the + PRU toolchain use stripped newlib configuration, which does not overflow + the IMEM region, even for 8K. + + [1] https://github.com/dinuxbg/gnuprumcu + [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 + +2024-05-28 Tom Tromey + + Make tui_win_info::make_window non-virtual + Nothing overrides tui_win_info::make_window, so remove the "virtual". + Tested by rebuilding. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add SVE2 lut extension + Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions use new SVE2 vector operands. They are called + SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have + 1 bit, 2 bit, and 3 bit indices respectively. + + The lsb and width of these new operands are the same as many existing + operands but the convention is to give different names to fields that + serve different purpose so we introduced new fields in aarch64-opc.c + and aarch64-opc.h. + + We made a design choice for the second operand of the halfword variant of + luti4 with two register tables. We could have either defined a new operand, + like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With + the new operand, we would need to implement constraints on register + lists based on either operand or opcode flag. With existing operand, we + could just existing constraint checks using opcode flag. We chose + the second approach and went with SVE_ZnxN and added opcode flag to + enforce lengths of vector register list operands. This way, we can reuse + the existing constraint check logic. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add AdvSIMD lut extension + Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions needed definition of some new operands. We will first + discuss operands for the third operand of the instructions and then + discuss a vector register list operand needed for the second operand. + + The third operands are vectors with bit indices and without type + qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12 + and they have 1 bit, 2 bit, and 3 bit indices respectively. For these + new operands, we defined new parsing case branch. The lsb and width of + these operands are the same as many existing but the convention is to + give different names to fields that serve different purpose so we + introduced new fields in aarch64-opc.c and aarch64-opc.h for these new + operands. + + For the second operand of these instructions, we introduced a new + operand called LVn_LUT. This represents a vector register list with + stride 1. We defined new inserter and extractor for this new operand and + it is encoded in FLD_Rn. We are enforcing the number of registers in the + reglist using opcode flag rather than operand flag as this is what other + SIMD vector register list operands are doing. The disassembly also uses + opcode flag to print the correct number of registers. + +2024-05-28 Tom Tromey + + Use bool in thread_events + This changes target_ops::thread_events and target_thread_events to use + 'bool'. The callers were already doing this. + + Tested by rebuilding. + + Approved-By: Simon Marchi + +2024-05-28 Nick Clifton + + Fix typo in assembler documentation + + Fix: internal error in write_function_pdata at obj-coff-seh + PR 31796 + + Updated Spanish translation for the BFD sub-directory. + +2024-05-28 Richard Earnshaw + + opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions + The autogenerated files in opcodes use spaces for indentation. + Changing that would be a lot of work to little benefit, so add a local + override to the white-space rules, so patches apply cleanly. + +2024-05-28 Nick Clifton + + Add new ELF section and segment types to readelf. + +2024-05-28 Javier Mora + + RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi + The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the + bit arrangement of the simm20 immediate that belongs to the J type; + It should be just `simm20[19:0]`. The current behavior of `gas` matches + the proposed documentation change. + + Additionally, the opcode is called `opcode6` despite of having 7 bits. + Rename it to `opcode7`. + + gas/ + * doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7. + +2024-05-28 GDB Administrator + + Automatic date update in version.in + +2024-05-27 Tom Tromey + + Re-run make-target-delegates.py + I re-ran make-target-delegates.py and discovered that the tree was out + of sync. This patch corrects the problem. + +2024-05-27 Nelson Chu + + RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc. + This was originally reported by Hau Hsu . + + Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d + + We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt + in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64. + This just like what did in the riscv_elf_finish_dynamic_symbol. + + bfd/ + * elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use + riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the + riscv_elf_relocate_section when handling ifunc data reloc. + ld/ + * testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed. + * testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed. + +2024-05-27 Nelson Chu + + RISC-V: Segment fault for kernel purgatory when linking. + This was originally reported by Ard Biesheuvel . + + The followings are reproduce steps, + https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u + + The segment fault happens in the riscv_elf_finish_dynamic_sections when the + output got section is an ABS. Refer to MIPS code, they added an extra + bfd_is_abs_section check to avoid ABS got, so this seems the right and easier + way to go in the short-term. + + bfd/ + * elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize + and fill the got entries only when the got isn't an ABS section, and + the size of got is larger than zero. The similar goes for gotplt, + except we already reported error when the gotplt is an ABS. + +2024-05-27 mengqinggang + + LoongArch: Fix relaxation overflow caused by ld -z separate-code + ld -z separate-code let .text and .rodata in two different but read only + segment. If the symbol and pc in two segment, the offset from pc to + symbol need to consider segment alignment. + + Add a function 'loongarch_two_sections_in_same_segment' to determine + whether two sections are in the same segment. + +2024-05-27 GDB Administrator + + Automatic date update in version.in + +2024-05-26 Joel Brobecker + + Update gdb/NEWS after GDB 15 branch creation. + This commit a new section for the next release branch, and renames + the section of the current branch, now that it has been cut. + +2024-05-26 Joel Brobecker + + Bump version to 16.0.50.DATE-git. + Now that the GDB 15 branch has been created, + this commit bumps the version number in gdb/version.in to + 16.0.50.DATE-git + + For the record, the GDB 15 branch was created + from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd. + + Also, as a result of the version bump, the following changes + have been made in gdb/testsuite: + + * gdb.base/default.exp: Change $_gdb_major to 16. + +2024-05-26 GDB Administrator + + Automatic date update in version.in + +2024-05-25 H.J. Lu + + ld: Document -pie -Ttext-segment=ORG generates ET_EXEC + This is the v2 patch I am checking in. + + H.J. + +2024-05-25 GDB Administrator + + Automatic date update in version.in + +2024-05-24 Alan Modra + + Re: LoongArch: gas: Adjust DWARF CIE alignment factors + Adjust the gas testsuite to suit commit de203ed568f6. + + * testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d: + Expect data alignment of -8. Tidy. + +2024-05-24 Jan Beulich + + gas: extend \+ support to .irp / .irpc + PR gas/31752 + + These are effectively macro-like, without any separate macro definition. + They already support \@, so they would better also support \+. This + allows, where desired, to get away without maintaining an explicit count + variable in source code. + + With this the recently introduced testcase doesn't need any xfails + anymore. + +2024-05-24 Jan Beulich + + gas: adjust handling of quotes for .irpc + The present handling of inner double quotes can lead to very strange + diagnostics. Follow one of the two possible interpretations of the doc: + @dots{} referring to possibly multiple white space separated + @var{values}, each of which may be quoted. The original implementation, + prior to 465e5617233f ("PR gas/3856"), hints at the other possible + interpretation: When quoted there's only a single @var{values}, with + inner quotes taken as ordinary characters. That, however, seems overall + less useful to me. + + While touching the documentation, mirror the (inverse) spelling + correction (@section line inconsistent with actual description) to .irp + as well. + +2024-05-24 Jan Beulich + + x86: simplify VexVVVV_SRC2 handling for the XOP case + As already suggested during review, rather than having an extra + conditional in build_modrm_byte() (a code path used for quite a few + more insns, including even certain GPR ones), adjust the attribute in + the installed template to properly describe things with operands + swapped. + +2024-05-24 Jan Beulich + + x86: simplify / consolidate check_{word,long,qword}_reg() + These run after template matching. Therefore operands are already known + to match the template in use. With the loop bodies skipping anything not + a GPR in the actual operands, there's therefore no need to check the + template's operand type for permitting Reg or Accum. + + At the same time bring the three functions in sync for the "byte" part + of the logic, as far as checking the template for other sizes (qword + specifically) goes. Plus drop a stale comment from check_qword_reg(), + when all three are now behaving the same in this regard. + +2024-05-24 Jan Beulich + + x86: correct VCVT{,U}SI2SD + Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly + omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]), + to avoid emitting bad or arbitrarily guessed instructions. Interestingly + check_{long,qword}_suffix() don't help here, which perhaps is another + indication that the way they work right now isn't quite appropriate. + + Sadly correcting just the templates breaks operand ambiguity detection, + since so far that worked from a single template permitting more than one + suffix. Here we have ambiguity though which can now be noticed only when + taking all (matching) templates together. Therefore we need to determine + further matching templates (see code comments for constraints), to then + accumulate permitted suffixes across all of them. + +2024-05-24 Tom de Vries + + [gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp + When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run + regularly into PR26286: + ... + (gdb) continue^M + Continuing.^M + [LWP ... exited]^M + ... + [LWP ... exited]^M + ^M + Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M + The program no longer exists.^M + (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 + ... + + Add a kfail for this, such that we have: + ... + (gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 (PRMS: threads/26286) + ... + + Reviewed-By: Thiago Jung Bauermann + + Tested on x86_64-linux. + +2024-05-24 GDB Administrator + + Automatic date update in version.in + +2024-05-23 Felix Willgerodt + + gdb, testsuite: Fix return value in gdb.base/foll-fork.exp + In a remote testing setup, I saw this error: + + ~~~ + (gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main + ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp. + ERROR: expected boolean value but got "" + while executing + "if { ![check_fork_catchpoints] } { + untested "follow-fork not supported" + return + }" + (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434) + invoked from within + "source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + ("uplevel" body line 1) + invoked from within + "uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + invoked from within + "catch "uplevel #0 source $test_file_name"" + Remote debugging from host 172.0.1.3, port 37766 + Killing process(es): 1171 + Quit + ~~~ + + The actual reason for this were some connection problems. Though the + function check_fork_catchpoints shouldn't return an empty string, especially + as it promises to always return 0 or 1. Fix that. + + Approved-By: Tom Tromey + +2024-05-23 Thiago Jung Bauermann + + gdb/testsuite: Restore libc_has_debug_info's less strict behaviour + The code that was factored out from gdb.base/relativedebug.exp assumed that + libc has debug info and only determined that it doesn't if it saw a specific + message from GDB to that effect. In the process of factoring it into a + require predicate, I made it stricter by trying to make a specific + determination of whether or not debug info is available. + + Pedro noticed that "It'll disable the testcase on systems that link with + their libc statically (even if has debug info), or systems that name their + libc something else." Which is something I hadn't considered. + + This patch returns libc_has_debug_info to the original behaviour. + + Also, remove a verbose message that is redundant with the $message + variable. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700 + Approved-By: Tom Tromey + +2024-05-23 GDB Administrator + + Automatic date update in version.in + +2024-05-22 Alan Modra + + libctf testsuite compilation failure + * testsuite/libctf-regression/open-error-free.c (main): Correct + format length modifier. + +2024-05-22 Tom Tromey + + Default dwarf_synchronous to true + Unfortunately the background DWARF reading series introduced a number + of races, as repored by thread sanitizer. This patch changes gdb to + disable this feature for the time being -- in particular for the gdb + 15 release. + + I've filed a bug and linked all the known races to it. Once those are + fixed we can re-enable this feature by default. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751 + +2024-05-22 Indu Bhagat + + restore build with --enable-maintainer-mode + A build with --enable-maintainer-mode is currently failing with: + + make[4]: *** No rule to make target '/gas/config/te-ia64aix.h', + needed by '/gas/po/gas.pot'. Stop. + make[4]: Leaving directory '<$OBJ>/gas/po' + make[3]: *** [Makefile:1695: all-recursive] Error 1 + ... + + As config/te-ia64aix.h is now removed, remove the corresponding fragment + from the makefile. + + gas/ + * Makefile.am: Remove config/te-ia64aix.h. + * Makefile.in: Regenerate. + * po/POTFILES.in: Regenerate. + +2024-05-22 Matthieu Longo + + aarch64: fix incorrect encoding for system register pmsdsfr_el1 + This patch fixes a mistake in the encoding of the system register + pmsdsfr_el1. + + Reference: + https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en + +2024-05-22 Cui, Lili + + Support APX zero-upper + This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc. + Since the spec only recommends one form of setzu, I won't be adding + setreg32/reg64 support in this patch. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Handle ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.d: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~ + PREFIX_EVEX_MAP4_4F. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct dis386): Add new micro 'ZU'. + (putop): Handle %ZU. + * i386-gen.c: Added ZU. + * i386-opc.h: Ditto. + * i386-opc.tbl: Added new templates to support ZU. + +2024-05-22 Cui, Lili + + X86: Remove "i.rex" to eliminate extra conditional branch + Resulting code will do better without the extra conditional branch. + Remove "i.rex" to eliminate extra conditional branch. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Remove i.rex. + +2024-05-22 Vladimir Mezentsev + + gprofng: use StringBuilder to create long messages + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * src/collctrl.cc: Use StringBuilder to create messages. + Remove unused variables and arrays. + * src/collctrl.h: Remove unused variables. + +2024-05-22 Vladimir Mezentsev + + gprofng: Remove hardware counter tables for unsupported hardware (Sparc) + ChangeLog + 2024-05-20 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwctable.c: Remove hardware counter tables for Sparc machines. + +2024-05-22 Vladimir Mezentsev + + gprofng: remove memset() in libcollector + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * libcollector/collector.c: Use static initialization instead of memset. + * libcollector/dispatcher.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/synctrace.c: Likewise. + +2024-05-22 Cui, Lili + + Add check for 8-bit old registers in EVEX format + Since APX supports EVEX from legacy instructions, we need to check + the 8-bit old registers in EVEX format. And add test cases for it. + + gas/ChangeLog: + + * config/tc-i386.c (md_assemble): Add invalid check for old byte + registers in EVEX format. + * testsuite/gas/i386/x86-64-apx-inval.l: Add new test. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + +2024-05-22 Cui, Lili + + x86: Split REX/REX2 old registers judgment. + Split "REX/REX2 old register checking" and "add empty rex prefix" + into two separate branches. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Split the judgments. + +2024-05-22 GDB Administrator + + Automatic date update in version.in + +2024-05-21 Indu Bhagat + + gas: ginsn: remove unnecessary buffer allocation and free + A previous commit 80ec235 fixed the memory leaks, but brought to light + that the code should ideally make consistent use of snprintf and not + allocate/free more buffers than necessary. + + gas/ + * ginsn.c (ginsn_dst_print): Use snprintf consistently. + +2024-05-21 Srinath Parvathaneni + + aarch64: Fix the hyphenated disassembly comment. + This patch fixes the following comment. + + - /* The hyphenated form is preferred for disassembly if there are + - more than two registers in the list, and the register numbers + are monotonically increasing in increments of one. */ + + + /* The hyphenated form is preferred for disassembly if there is + + more than one register in the list, and the register numbers + are monotonically increasing in increments of one. */ + +2024-05-21 Tom Tromey + + Clarify documentation for pretty_printer.child + An Ada pretty-printer had a bug where its 'child' method returned a + gdb.Value rather than a tuple. Kévin suggested that the documentation + for this method could be improved to clarify this. + + Reviewed-By: Kévin Le Gouguec + Approved-By: Eli Zaretskii + +2024-05-21 Jan Beulich + + gas: drop remnants of ia64-*-aix* + With BFD not supporting that target anymore, GAS can't possibly support + it either. + + ld: silence makeinfo warnings + Older tool versions (4.12 in my case) demand . or , after @xref{}; + arrange for this to be the case. + +2024-05-21 Nick Alcock + + include, libctf: improve documentation + Some review comments came in after I pushed the last lot of ctf-api.h + comment improvements. They were good, so I've incorporated them. + Mostly: better _next iterator usage info, better info on ctf_*open + functions, and better info on ctf_type_aname and ctf_type_name_raw. + + include/ + * ctf-api.h: improve documentation. + +2024-05-21 GDB Administrator + + Automatic date update in version.in + +2024-05-20 Kévin Le Gouguec + + gdb: Fix Windows build after #include shuffle + Without this patch, the build chokes on: + + ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic' + 384 | std::atomic m_debug_event_pending { false }; + | ^~~~~~~~~~~~~~~~~~~~~ + In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33, + from […gcc tree…]/include/c++/13.2.1/memory:81, + from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23, + from ../../src/gdb/../gdbsupport/common-utils.h:26, + from ../../src/gdb/../gdbsupport/common-defs.h:199, + from ./../../src/gdb/defs.h:26, + from : + […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic' + 174 | struct atomic; + | ^~~~~~ + make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1 + + Presumably windows-nat.c relied on objfiles.h including , + which was undone in 2024-05-16 "gdb: remove unused includes in + objfiles.{c,h}" (f617661c110). + +2024-05-20 Luca Boccassi + + readelf: add pretty printing for FDO Dlopen Metadata note + +2024-05-20 Nick Clifton + + Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh + PR 31726 + +2024-05-20 Tom de Vries + + [gdb/testsuite] Fix can_spawn_for_attach_1 consistency check + When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with + target board native-gdbserver, we run into: + ... + (gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp. + ERROR: gdbserver does not support attach 4827 without extended-remote + while executing + "error "gdbserver does not support $command without extended-remote"" + (procedure "gdb_test_multiple" line 51) + invoked from within + "gdb_test_multiple "attach $test_pid" "can spawn for attach" { + -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." { + # Not permitte..." + (procedure "gdb_real__can_spawn_for_attach_1" line 27) + invoked from within + "gdb_real__can_spawn_for_attach_1" + ... + + The problem is that: + - can_spawn_for_attach_1 is a helper function for can_spawn_for_attach, + designed to be called only from that function, and + - can_spawn_for_attach_1 is a gdb_caching_proc, and consequently + test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls + can_spawn_for_attach_1 directly. + + Fix this by copying the early-outs from can_spawn_for_attach to + can_spawn_for_attach_1. + + Tested on x86_64-linux. + + Reported-By: Simon Marchi + Reviewed-By: Alexandra Petlanova Hajkova + +2024-05-20 Claudio Bantaloukas + + aarch64: Add support for the fpmr system register + +2024-05-20 Georg-Johann Lay + + Include .rodata size in avr-objdump -P mem-usage. + PR 31687 + + Let avr-objdump show .note.gnu.avr.deviceinfo + PR 31704 + +2024-05-20 Sung-hun Kim + + RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa + The DWARF specification (especially, DWARF4 and 5 [1,2]) states that + DW_CFA_def_cfa_register cannot be used as the first CFI operation. + It said DW_CFA_def_cfa_register as follows: + + ... This operation is valid only if the current CFA rule is defined + to use a register and offset. + + So, DW_CFA_def_cfa_register can be used after that other definition + operation such as DW_CFA_def_cfa is called. However, the current gas + code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV. + + In the libgcc, the unwinding function does not care about it, so it can + unwind the call stack. However, on the third party library such as + libunwindstack in Android, it causes a fatal error. + + This patch changes the initial CFI operation to DW_CFA_def_cfa with + offset 0. It works as same as the previous one, but it does not have + any limitation so it satisfies the DWARF spec. This change resolves + the compatibility issue while preserving the original behaviour. + + [1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf + [2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf + + Reviewed-By: Andrew Burgess + Approved-By: Nelson Chu + + gas/ + PR 31733 + config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use + DW_CFA_def_cfa rather than DW_CFA_def_cfa_register. + +2024-05-20 GDB Administrator + + Automatic date update in version.in + +2024-05-19 GDB Administrator + + Automatic date update in version.in + +2024-05-18 Tom Tromey + + Remove unnecessary block from execute_fn_to_ui_file + I noticed that execute_fn_to_ui_file has an extra, unnecessary block. + This patch removes it. + +2024-05-18 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen3 + Historically, we have used several APIs (perfctr, libcpc, perf_event_open) for profiling. + For each hardware we have several tables of hardware counters. + Some information is duplicated in these tables. + Some of the information is no longer used. + I did not touch the existing hwc tables. + I added a new hwc table for an AMD Zen3 machine. + + ChangeLog + 2024-05-16 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c (core_pcbe_get_events): Add new argument. + * common/hwc_cpus.h: New constants for AMD hardware. + * common/hwcdrv.c: Add new argument to hwcdrv_get_descriptions. + Clean up the code. + * common/hwcdrv.h: Likewise. + * common/hwcfuncs.c (hwcdrv_get_descriptions): Add new argument. + * common/hwctable.c: Add the hwc table for AMD Zen3. + * src/hwc_amd_zen3.h: New file. + * common/opteron_pcbe.c: Add new argument to opt_pcbe_get_events. + * src/collctrl.cc: Remove unused variable. + * src/collctrl.h: Likewise. + +2024-05-18 Vladimir Mezentsev + + gprofng: remove old interface with libcpc + interface with libcpc was used on Solaris. + gprofng doesn't support profiling on Solaris. + I removed this old code and other unused macros and variables. + + gprofng/ChangeLog + 2024-04-29 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwcdrv.c: remove old interface with libcpc. + * common/hwcdrv.h: Likewise. + * common/hwcentry.h: Likewise. + * common/hwcfuncs.c: Likewise. + * common/hwcfuncs.h: Likewise. + * common/hwctable.c: Likewise. + * src/Dbe.cc: Likewise. + * src/collctrl.cc: Likewise. + +2024-05-18 GDB Administrator + + Automatic date update in version.in + +2024-05-17 Indu Bhagat + + bfd: sframe: minor code adjustments and fix typos + bfd/ + * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use local + variable. + (_bfd_x86_elf_size_dynamic_sections): Fix typos. + +2024-05-17 Tom Tromey + + Remove gdb_stdtargerr + This patch removes gdb_stdtargerr. There doesn't seem to be a need + for this -- it is always the same as stdtarg, and (I believe) has been + for many years. + + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Don't allow new-ui to start the TUI + The TUI can't really work properly with new-ui, at least not as + currently written. This patch changes new-ui to reject an attempt. + Attempting to make a DAP ui this way is also now rejected. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Inline some ui_out methods + I noticed a few ui_out methods that are just trivial wrappers. This + patch moves these to ui-out.h, as it seems like they should be + inlineable. + + Approved-By: Andrew Burgess + +2024-05-17 Dmitry Neverov + + gdb/symtab: use symbol name matcher for all segments in a qualified name + +2024-05-17 Dmitry Neverov + + gdb/symtab: compute match_type outside the loop + It will be used for all segments in a qualified name, + not only the last one. + + Approved-By: Tom Tromey + +2024-05-17 Dmitry Neverov + + gdb/symtab: reuse last segment lookup name info by creating it outside the loop + +2024-05-17 Dmitry.Neverov + + gdb/symtab: check name matches before expanding a CU + The added check fixes the case when an unqualified lookup + name without template arguments causes expansion of many CUs + which contain the name with template arguments. + + This is similar to what dw2_expand_symtabs_matching_symbol does + before expanding the CU. + + In the referenced issue the lookup name was wxObjectDataPtr and many + CUs had names like wxObjectDataPtr. This caused + their expansion and the lookup took around a minute. The added check + helps to avoid the expansion and makes the symbol lookup to return in + a second or so. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520 + +2024-05-17 Nick Alcock + + include, libctf: add a bunch of documentation to ctf-api.h + Hopefully this library is no longer quite so much a "you have to look + in the source to understand anything" library. + + No semantic changes, though some functions have been moved around for + clarity. + + include/ + ctf-api.h: Add comments. + +2024-05-17 Nick Alcock + + libctf: fix leak of entire dict when dict opening fails + Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount + loops") ctf_dict_close has only freed anything if the refcount on entry + to the function is precisely 1. >1 obviously just decrements the + refcount, but the linker machinery can sometimes cause freeing to recurse + from a dict to another dict and then back to the first dict again, so + we interpret a refcount of 0 as an indication that this is a recursive call + and we should just return, because a caller is already freeing this dict. + + Unfortunately there is one situation in which this is not true: the bad: + codepath in ctf_bufopen entered when opening fails. Because the refcount is + bumped only at the very end of ctf_bufopen, any failure causes + ctf_dict_close to be entered with a refcount of zero, and it frees nothing + and we leak the entire dict. + + The solution is to bump the refcount to 1 right before freeing... but this + codepath is clearly delicate enough that we need to properly validate it, + so we add a test that uses malloc interposition to count allocations and + frees, creates a dict, writes it out, intentionally corrupts it (by setting + a bunch of bytes after the header to a value high enough that it is + definitely not a valid CTF type kind), then tries to open it again and + counts the malloc/free pairs to make sure they're matched. (Test run only + on *-linux-gnu, because malloc interposition is not a thing you can rely + upon working everywhere, and this test is not arch-dependent so if it + passes on one arch it can be assumed to pass on all of them.) + + libctf/ + * ctf-open.c (ctf_bufopen): Bump the refcount on failure. + * testsuite/libctf-regression/open-error-free.*: New test. + +2024-05-17 Nick Alcock + + libctf: test: add wrapper + This .lk option lets you run the lookup program via a wrapper executable. + For example, to run under valgrind and check for leaks (albeit noisily + because of the libtool shell script wrapper): + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add wrapper. + +2024-05-17 Nick Alcock + + libctf: test: add host + This .lk option lets you execute particular tests only on specific host + architectures. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add host. + +2024-05-17 Nick Alcock + + libctf: test: add lookup_link + This .lk option lets you link the lookup program with extra libraries + in addition to -lctf. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add lookup_link. + +2024-05-17 Nick Alcock + + libctf: ctf_archive_iter: fix tiny leak + If iteration fails because opening a dict has failed, ctf_archive_next does + not destroy the iterator, so the caller can keep going and try to open other + dicts further into the archive. ctf_archive_iter just returns, though, so + it should free the iterator rather than leaking it. + + libctf/ + * ctf-archive.c (ctf_archive_iter): Don't leak the iterator on + failure. + +2024-05-17 Nick Alcock + + libctf: failure to open parent dicts that exist should be an error + CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et + al) attempts to be helpful and auto-open and import any needed parent dict + in the same archive. But if this fails, the error is not reported but + simply discarded, and you silently get back a dict with no parent, that + *you* suddenly have to remember to import. + + This is not helpful behaviour: if the parent is corrupted or we run out of + memory or something, the caller is going to want to know! Split it in two: + if the dict cites a parent that doesn't exist at all (a lot of historic + dicts name "PARENT" as their parent, even when they're not even children, or + perhaps the parent dict is stored separately and you plan to manually + associate it), we skip it as now, but if the import fails with an actual + error other than ECTF_ARNNAME, return the error and fail the open. + + libctf/ + * ctf-archive.c (ctf_arc_import_parent): Return failure if + parent opening fails for reasons other thnn nonexistence. + (ctf_dict_open_sections): Adjust. + +2024-05-17 Nick Alcock + + libctf: typos + Some functions were renamed without the comments catching up. + + libctf/ + * ctf-open.c (upgrade_types_v1): Fix comment typos. + +2024-05-17 Jan Beulich + + aarch64: correct SVE2.1 ld2q (scalar plus scalar) + It's opcode was wrong, as was e.g. easily visible from the inappropriate + testcase expectation. + + aarch64: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) + Like their byte, half, word, and doubleword counterparts their + immediates are multiples of 3 / 4 respectively. + +2024-05-17 mengqinggang + + LoongArch: gas: Adjust DWARF CIE alignment factors + Set DWARF2_CIE_DATA_ALIGNMENT (data alignment factors) to -8. + It helps to save space. + + Data Alignment Factor + A signed LEB128 encoded value that is factored out of all offset + instructions that are associated with this CIE or its FDEs. This value + shall be multiplied by the register offset argument of an offset + instruction to obtain the new offset value. + +2024-05-17 GDB Administrator + + Automatic date update in version.in + +2024-05-16 Indu Bhagat + + gas: sframe: fix typo to use FP instead of BP + gas/ + * gen-sframe.c (output_sframe_internal): Use BP instead of FP. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Add missing terminator in Dwarf::_macro_unit + When printing complaints with one of the execs from test-case + gdb.dwarf2/macro-source-path.exp, we run into: + ... + $ gdb -q -batch \ + -iex "set complaints 100" \ + macro-source-path-clang14-dw4-absolute-cwd-32 \ + -ex "p main" + During symbol reading: debug info runs off end of .debug_macro section \ + [in module macro-source-path-clang14-dw4-absolute-cwd-32] + $1 = {int ()} 0x4004b7
+ ... + and readelf complains more specifically: + ... + Contents of the .debug_macro section: + + Offset: 0 + Version: 5 + Offset size: 4 + Offset into .debug_line: 0xe3 + + DW_MACRO_define - lineno : 0 macro : ONE 1 + DW_MACRO_define_strp - lineno : 0 macro : THREE 3 + DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c + DW_MACRO_define - lineno : 1 macro : TWO 2 + DW_MACRO_end_file + readelf: Error: .debug_macro section not zero terminated + ... + + Fix this by adding the missing terminator in Dwarf::_macro_unit. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused includes in objfiles.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a + +2024-05-16 Ijaz, Abdul B + + gdb, testsuite: Handle unused compiler option fdiagnostics-color=never. + The 'univeral_compile_options' in gdb.exp file only verifies the support + of '-fdiagnostics-color=never' for the "C" source file. So while running + tests with assembly source file (.s), many of them are not able to run + on icx/clang compilers because '-fdiagnostics-color=never' option is not + supported. This problem is not seen for the ".S" assembly source files so + these files are not handled separately. After this change, this function + is split into multiple functions to check the support for different type + of sources individually. + + Before this change, in the case of clang and ICX compiler, this error is + shown for assembly source files (.s): + + ''' + icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o + amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300) + + icx: warning: argument unused during compilation: '-fdiagnostics-color=never' + [-Wunused-command-line-argument] + + gdb compile failed, icx: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + + UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare + ''' + + Similarly this error is shown for the clang compiler: + + ''' + clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 + -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s + + clang: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + ''' + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: define type aliases for `fork_inferior()` callbacks + The `fork_inferior()` function accepts multiple callbacks, making its + signature a bit hard to read. Define some type aliases to make it a bit + clearer. Use function view for all, while at it. + + Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: initialize packet_result::m_textual_err_msg + When building GDB with -O2 and --enable-ubsan, I get some random errors + in the packet_result self test: + + /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool' + + This happens because packet_result::m_textual_err_msg is uninitialized + when using the second constructor. When such a packet_result object + gets copied, an invalid value for m_textual_err_msg (a bool field) is + loaded, which triggers ubsan. + + Avoid this by initializing m_textual_err_msg. + + Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused include in infcmd.c + clangd reports this header as unused. + + Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b + +2024-05-16 Simon Marchi + + gdb: remove unused includes from progspace.{c,h} + Remove some include files reported as unused by clangd. + + Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a + +2024-05-16 Simon Marchi + + gdb: bump black version to 24.4.2 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I79c221af1b2192f866a344ab17d6199b137371cb + +2024-05-16 Simon Marchi + + gdb: move lm_info to solib in dsbt_current_sos + Commit 8971d2788e79 ("gdb: link so_list using intrusive_list") + mistakenly removed the line that moves the lm_info unique pointer to + sop->lm_info, probably due to a bad conflict resolution. Restore that + line. + + Unfortunately, this code is only used for TI C66, which is not widely + tested (if used at all). + + Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb + Approved-By: Tom Tromey + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sme2 insn variants + Add the SME2 variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+sme2+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + Multi-vector floating-point convert from FP8 to + BFloat16 (in-order): + ----------------------------------------------- + + - bf1cvt { .H-.H }, .B + - bf2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved BFloat16: + ----------------------------------------------- + + - bf1cvtl { .H-.H }, .B + - bf2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from BFloat16 + to packed FP8 format: + ------------------------------------------------- + + - bfcvt .B, { .H-.H } + + Multi-vector floating-point convert from FP8 to + half-precision (in-order): + ----------------------------------------------- + + - f1cvt { .H-.H }, .B + - f2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved half-precision: + ----------------------------------------------- + + - f1cvtl { .H-.H }, .B + - f2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from half-precision + to packed FP8 format: + ------------------------------------------------------- + + fcvt_2h + + Multi-vector floating-point convert from single-precision + to packed FP8 format: + --------------------------------------------------------- + fcvt_4s + + Multi-vector floating-point convert from single-precision + to interleaved FP8 format: + --------------------------------------------------------- + + - fcvtn .B, { .S-.S } + + Multi-vector floating-point adjust exponent by vector: + ------------------------------------------------------ + + - fscale { .H-.H }, { .H-.H }, + .H + - fscale { .S-.S }, { .S-.S }, + .S + - fscale { .D-.D }, { .D-.D }, + .D + + Multi-vector floating-point adjust exponent: + -------------------------------------------- + + - fscale { .H-.H }, { .H-.H }, + { .H - .H } + - fscale { .S-.S }, { .S-.S }, + { .S - .S } + - fscale { .D-.D }, { .D-.D }, + { .D - .D } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sve2 insn variants + Add the SVE2 variant of the FP8 convert and scale instructions, + enabled at assembly-time using the `+sve2+fp8' architectural + extension flag. More specifically, support is added for the + following instructions: + + FP8 convert to BFloat16 (bottom/top): + ------------------------------------- + + - bf1cvt Z.H, Z.B + - bf2cvt Z.H, Z.B + - bf1cvtlt Z.H, Z.B + - bf2cvtlt Z.H, Z.B + + FP8 convert to half-precision (bottom/top): + ------------------------------------------- + + - f1cvt Z.H, Z.B + - f2cvt Z.H, Z.B + - f1cvtlt Z.H, Z.B + - f2cvtlt Z.H, Z.B + + BFloat16/half-precision convert, narrow and + interleave to FP8: + ------------------------------------------- + + - bfcvtn Z.B, { Z1.H - Z2.H } + - fcvtn Z.B, { Z1.H - Z2.H } + + Single-precision convert, narrow and interleave + to FP8 (bottom/top): + ----------------------------------------------- + + - fcvtnb Z.B, { Z1.S - Z2.S } + - fcvtnt Z.B, { Z1.S - Z2.S } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - Add advsimd insn variants + Add the advanced SIMD variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + FP8 convert to BFloat16 (vector): + --------------------------------- + + - bf1cvtl V.8H, V.8B + - bf2cvtl V.8H, V.8B + - bf1cvtl2 V.8H, V.16B + - bf2cvtl2 V.8H, V.16B + + FP8 convert to half-precision (vector): + --------------------------------------- + + - f1cvtl V.8H, V.8B + - f2cvtl V.8H, V.8B + - f1cvtl2 V.8H, V.16B + - f2cvtl2 V.8H, V.16B + + Single-precision to FP8 convert and narrow (vector): + ---------------------------------------------------- + + - fcvtn V.8B, V.4S, V.4S + - fcvtn2 V.16B, V.4S, V.4S + + Half-precision to FP8 convert and narrow (vector): + -------------------------------------------------- + + - fcvtn V.8B, V.4H, V.4H + - fcvtn V.16B, V.8H, V.8H + + Floating-point adjust exponent by vector: + ----------------------------------------- + + - fscale V.4H, V.4H, V.4H + - fscale V.8H, V.8H, V.8H + - fscale V.2S, V.2S, V.2S + - fscale V.4S, V.4S, V.4S + - fscale V.2d, V.2d, V.2d + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add feature flags and related structures + +2024-05-16 Pedro Alves + + Stop 'configure --enable-threading' if std::thread doesn't work + Currently, if you configure gdb with explicit --enable-threading, but + then configure detects std::thread does not work, configure silently + disables threading support and continues configuring. + + This patch makes that scenario cause a configuration error, like so: + + $ /home/pedro/gdb/src/configure --enable-threading && make + ... + configure: error: std::thread does not work; disable threading + make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 + make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' + make: *** [Makefile:1041: all] Error 2 + $ + + Additionally, if you don't explicitly pass --enable-threading, and + std::thread does not work, we will now get a warning (and the build + continues): + + $ /home/pedro/gdb/src/configure && make + ... + configure: WARNING: std::thread does not work; disabling threading + ... + + This is similar to how we handle --enable-tui and missing curses. The + code and error/warning messages were borrowed from there. + + Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 + Approved-By: Tom Tromey + +2024-05-16 Matthieu Longo + + aarch64: add SPMU feature and its associated registers + +2024-05-16 Nick Clifton + + Move assembler "IRP \+" test into a separate file. Add XFAILs for targets that do not support it. + +2024-05-16 Richard Earnshaw + + arm: remove incorrect handling of FP bignums in move_or_literal_pool + This hunk of code in move_or_literal_pool just looks wrong, but I + can't find a testcase that will tickle it to prove it. It looks a bit + like it was intended to catch cases where a bignum contained a + floating-point value, but there were a number of problems with it. + + - It tested X_add_number == -1, but an FP bignum is indicated by any + value <= 0. + - It converted the floating-point value to extended precision, but + that's not used on Arm beyond the legacy FPA code. No attempt was + made to match the FP value to the intended memory/mov operation. + + Since I can't construct a viable testcase, I've just removed the existing + code and made the function error out in this case: this seems more sensible + than generating wrong code or trying to write something more complex that + can't be tested anyway. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assembly + Add support for DW_MACRO_define_strp in dwarf assembly, and use it in + test-case gdb.dwarf2/macro-source-path.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Alan Modra + + Fix FAIL: macros altmacro + spu-elf and z80-coff fail this test due to "def" being a pseudo-op. + tic30-unknown-coff fails it due to '#' not starting comments. + + * testsuite/gas/macros/altmacro.s: Use /* */ comments. Rename + DEF to EDF. + +2024-05-16 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Fangrui Song + + gas: Fix \+ expansion for .irp and .irpc + .irp and .irpc receive a null macro_entry. \+ causes a crash after the + recent \+ support. Restore the previous behavior. + +2024-05-15 Andrew Carlotti + + aarch64: Add sysreg features to +d128 dependencies + We should revisit sysreg feature enablement and dependencies in future, but + this change should help until then. + + OK for master? + +2024-05-15 Andrew Carlotti + + aarch64: Add simd dependency to +sha2 + This matches the existing behaviour in GCC and LLVM, and also the current + documentation. + + OK for master? + +2024-05-15 Matthieu Longo + + aarch64: testsuite: share test utils macros and use them + This patch rewrites assembly tests to use utils macros declared in + sysreg-test-utils.inc. Some tests were adapted to use the new macro + rw_sys_reg. + + aarch64: testsuite: reorder write and read to match macro order + This patch aims at grouping write and read for a same system register + one after another so that the diff for the macro replacement does not + generate too much noise. + + aarch64: testsuite: use same regs for read and write tests + This patch aims at making easier to replacement of read and write + instructions to system registers by a macro that will use the same + registers for read and write. + + aarch64: testsuite: replace instruction addresses by regex + This patch removes the instruction addresses from the objdump's expected + output (.d files). The intended benefit from this clean-up is to allow to + swap lines around more easilly, and removes the noise of patches that add, + remove or reorder instructions. + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix handling of DW_MACRO_define_strx in dwo file + When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we + run into: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by passing the correct dwo argument to a + fetch_indexed_string call. + + That works fine for readelf -w, with with readelf -wm we have: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by doing load_debug_section_with_follow for + str_dwo / str_index_dwo sections instead of str / str_index sections when + handling .debug_macro.dwo. + + PR 31735 + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix printing of dwarf4 .debug_str_offsets.dwo + When compiling a hello world with dwarf4 split dwarf: + ... + $ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA + ... + we have in a-hello.s these three initial entries in .debug_str_offsets: + ... + .section .debug_str_offsets.dwo,"e",@progbits + .4byte 0 // indexed string 0x0: short int + .4byte 0xa // indexed string 0x1: /home/vries/binutils + .4byte 0x1f // indexed string 0x2: main + ... + but "readelf -ws a.out" starts at the third entry: + ... + Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo): + + Length: 0x30 + Index Offset [String] + 0 00000000 main + ... + + This is a regression since commit 407115429b3 ("Modified changes for + split-dwarf and dwarf-5."), which introduced a variable + debug_str_offsets_hdr_len in display_debug_str_offsets. + + Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case. + + PR 31734 + +2024-05-15 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Joseph Faulls + + RISC-V: Search for mapping symbols from the last one found + With previous behaviour, multiple mapping symbols within the same + function would result in all the mapping symbols being searched. + This could slow down disassembly dramatically. + + Multiple mapping symbols within a function can be a result of encoding + instructions as data, like sometimes seen in random instruction + generators. + + opcodes/ChangeLog: + + * riscv-dis.c (riscv_search_mapping_symbol): Use last mapping + symbol if it exists. + +2024-05-14 Tom Tromey + + Add spaceship operator to cp-name-parser.y + While debugging gdb, I saw this: + + During symbol reading: unexpected demangled name 'operator<=>, std::chrono::duration >' + + This happens because cp-name-parser.y does not handle the spaceship + operator. This patch implements this. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow function types as template parameters in name canonicalizer + This adds function types as template parameters in the C++ name + canonicalizer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Implement C++14 numeric separators + C++14 allows the use of the apostrophe as a numeric separator; that + is, "23000" and "23'000" represent the same number. This patch + implements this for gdb's C++ parser and the C++ name canonicalizer. + + I did this unconditionally for all C variants because I think it's + unambiguous. + + For the name canonicalizer, there's at least one compiler that can + emit constants with this form, see bug 30845. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ canonicalization of hex literals + Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to + different things. I think it's nicer for them to be the same. + Differences between types can be done using suffixes like "ll" and "u" + -- it's not really possible to implement C++ rules in the + canoncalizer, because no gdbarch is available. Possibly gdb should + even drop the type here and just represent all integers the same way + in names. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Remove some unnecessary allocations from cpname_state::parse_number + cpname_state::parse_number allocates nodes for various types and then + only uses one of them. This patch reduces the number of allocations + by not performing the unnecessary ones. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ name canonicalizations of character literals + The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should + canonicalize to the same string, but currently they do not -- the + former remains unchanged and the latter is transformed to + "void C<(char)'\001'>::m()". + + This patch fixes the bug and also adds some unit tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Change storage of demangle_component + This changes demangle_component objects to be stored on the obstack + that is part of demangle_info. It also arranges for a demangle_info + object to be kept alive by cp_merge_demangle_parse_infos. This way, + other data on the obstack can be kept while an "outer" demangle_info + needs it. + + Acked-By: John Baldwin + +2024-05-14 Tom Tromey + + Clean up demangle_parse_info + This changes demangle_parse_info to use inline initializers and to + remove some manual memory management. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow initialization functions in .y files + If you add an initialization function to a .y file, it will not show + up in init.c, because if the yacc output is in the build tree, it + won't be found. + + This patch changes the Makefile to be more robust in this situation. + +2024-05-14 Tom Tromey + + Remove test code from cp-name-parser.y + This removes the current test 'main' from cp-name-parser.y. There + aren't any tests using this, and nowadays it would be better as a unit + test. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Disallow trailing whitespace in docstrings + This patch changes the docstring self-test to verify that there is no + trailing whitespace at the end of lines. A few existing docstrings + had to be updated. + +2024-05-14 Tom Tromey + + Remove fflush call from tui_refresh_cmd_win + tui_refresh_cmd_win calls fflush, but there's a comment explaining + that the reason for the call is unknown. This patch removes the call. + I don't think it can be useful, since gdb doesn't generally use stdout + in this way -- only through ui_file. + +2024-05-14 Andrew Burgess + + gdb/doc: don't delete *.pod files too early + When doing 'make -C gdb/doc man' to build the man pages, I noticed + that the outputs were being rebuilt each time the make command was + rerun, even when the input files hadn't changed. + + This was caused by this commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + Which split the generation of the .pod file from the actual creation + of the man page file. Prior to this split it was OK to delete the + .pod file at the end of the recipe, the rule depending on the .texi + input file, and output was the .1 or .5 man page file. + + Now however, with the split, the man page creation depends on the .pod + file, if we delete this after creating the .1 or .5 man page file then + the next time we run 'make' the .pod file is missing and is + regenerated, which in turn triggers the regeneration of the man page + file. + + Fix this by leaving the .pod file around, and only cleaning up these + files in the 'mostlyclean' target. + + Which leads to a second problem, the POD_FILE_TMPS is not created + correctly, so we don't actually clean up the .pod files! This too is + fixed in this commit. + + After this commit running 'make -C gdb/doc man' will build the manual + pages the first time, and each subsequent run will do nothing. + + Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. + + Approved-By: Tom Tromey + +2024-05-14 Andrew Burgess + + gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flags + While working on another patch I needed to pass -Wl,-soname,NAME as a + compiler flag. I initially looked for other tests that did this, and + found a few examples, so I copied what they did. + + But when I checked the gdb.log file I noticed that we were actually + getting -Wl,-soname passed twice. + + I tracked the repeated option to 'proc gdb_compile_shlib_1' in + lib/gdb.exp. It turns out that we always add -Wl,-soname when + compiling a shared library. + + Here's an example of a build command from gdb.base/prelink.exp: + + builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ + /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \ + -fdiagnostics-color=never -shared -g \ + -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \ + -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so + + Notice that '-Wl,-soname,prelink.so' is repeated. + + I believe that all of the places where tests add '-Wl,-soname,NAME' as + a build option, are unnecessary. + + In this commit I propose we remove them all. + + As part of this change I've switched from calling gdb_compile_shlib + directly, to instead call build_executable and adding the 'shlib' + flag. + + I've tested with gcc and clang and see no changes in the test results + after this commit. All the compile commands still have -Wl,-soname + added, but now it's only added once, from within lib/gdb.exp. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-05-14 Pali Roh?r + + Improve objdump -p output of PE Import and Export Tables + PR 31738 + +2024-05-14 Jason Merrill + + Adjust C++ destructor type tests + In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge" + parameter from destructors of classes with no virtual bases; Linaro's CI + informed me that the gdb testsuite needs to be adjusted to match. + + Teested against GCC 13.2 and GCC 15 trunk. + + Approved-by: Kevin Buettner + +2024-05-14 Nick Clifton + + Fix gas's 'macro count' test for various targets + +2024-05-14 Aditya Vidyadhar Kamath + + Fix Segmentation Fault in AIX during multi process debugging. + Due to the recent commit in aix-thread.c, we see a segmentation fault + in AIX while debugging multiple process involving multiple threads. + + One example is a thread that can fork. The GDB output in AIX for the same is + + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 67110997)] + [New Thread 515 (tid 127404289)] + [New inferior 2 (process 16580940)] + Hello from Parent! + [process 16580940 exited] + [New inferior 3 (process 14549318)] + Hello from Parent! + [process 14549318 exited] + Fatal signal: Segmentation fault + ----- Backtrace ----- + + This is because in sync_threadlists () in aix-thread.c there when we + delete threads in unknown state we iterate through all the threads. + + When we have one or more threads with the same user thread ID but of different + process then we delete a wrong thread. Since we just check only the pdtid + in in_queue_threads.count (priv->pdtid) == 0 this happened. + + This patch is a fix for the same. + + The output after we apply this patch is: + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 75565441)] + [New Thread 515 (tid 63244397)] + [New inferior 2 (process 10813892)] + Hello from Parent! + [New inferior 3 (process 19005888)] + Hello from Parent! + + Thread 1.1 received signal SIGINT, Interrupt. + 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) info threads + Id Target Id Frame + * 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + 1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + 3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) q + A debugging session is active. + +2024-05-14 Richard Earnshaw + + arm: update documentation for removal of the Maverick extension + Finally, update the documentation and add a NEWS item. + + arm: remove Maverick support from BFD. + Remove the handling of Maverick from BFD. Where appropriate we handle + legacy code by mapping ep9312 onto Armv4t. + +2024-05-14 Richard Earnshaw + + arm: opcodes: remove Maverick disassembly. + Remove the patterns to match Maverick co-processor instructions from + the disassembly tables. + + This required fixing a couple of tests in the assembler testsuite + where we, probably incorrectly, disassembled generic co-processor + instructions as a Maverick instruction (it particularly made no sense + to do this for Armv6t2 in Thumb state). + +2024-05-14 Richard Earnshaw + + arm: binutils: drop Maverick support. + Remove the decoding of the Maverick flag from readelf. + + arm: remove Maverick support from the assembler. + Delete all the Maverick instructions and register handling from the + assembler. We continue to recognize -mcpu=ep9312, but treat it as an + alias for arm920t. We no-longer recognize -mfpu=maverick. + + arm: remove tests for Maverick FPU extensions + Before removing the code itself, remove the tests that will no-longer + apply. + +2024-05-14 GDB Administrator + + Automatic date update in version.in + +2024-05-13 Nick Clifton + + Add new assembler macro pseudo-variable \+ which counts the number of times a macro has been invoked. + +2024-05-13 GDB Administrator + + Automatic date update in version.in + +2024-05-12 GDB Administrator + + Automatic date update in version.in + +2024-05-11 Tom de Vries + + [gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp + When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide + container, I run into: + ... + temp/$pid/static-libc.c: In function 'main': + temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function + returning void [-Wreturn-mismatch] + 2 | void main (void) { return 0; } + | ^ + ... + UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link + ... + + Fix this by changing the return type to int. + + Tested on x86_64-linux. + +2024-05-11 GDB Administrator + + Automatic date update in version.in + +2024-05-10 Tom Tromey + + Change gdbarch_inner_than to return bool + A recent patch from Andrew pointed out that gdbarch_inner_than returns + 'int', while it should really return 'bool'. + + Approved-By: Pedro Alves + +2024-05-10 Tom Tromey + + Remove tui_refresh_all + This removes tui_refresh_all. There is only a single caller, + tui_refresh_all_win, so inlining the code there simplifies gdb at no + cost. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-05-10 Tom Tromey + + Add symbol, line, and location to DAP disassemble result + The DAP spec allows a number of attributes on the resulting + instructions that gdb currently does not emit. A user requested some + of these, so this patch adds the 'symbol', 'line', and 'location' + attributes. While the spec lets the implementation omit 'location' in + some cases, it was simpler in the code to just always emit it, as then + no extra tracking was needed. + + Implement tp_richcompare for gdb.Block + I noticed that two gdb.Block objects will never compare as equal with + '=='. This patch fixes the problem by implementing tp_richcompare, as + was done for gdb.Frame. + + Simplify DAP make_source callers + A couple callers of make_source call basename by hand. Rather than + add another caller like this, I thought it would be better to put this + ability into make_source itself. + + Remove FIXME from DAP + This patch removes one of the few DAP "FIXME" comments. This + particular comment is already covered by PR dap/31036. + +2024-05-10 Tom Tromey + + Pass stream to remote_console_output + I noticed that remote_target::rcmd did not pass its ui_file argument + down to remote_console_output. This patch fixes this oversight. + + Tested-By: Ciaran Woodward + Approved-By: Andrew Burgess + +2024-05-10 Nick Clifton + + Add --section-ordering command line option to the bfd linker. + +2024-05-10 Alan Modra + + Re: PR31692, objdump fails .debug_info size check + The fuzzers found a hole. bfd_section_size_insane doesn't check + !SEC_HAS_CONTENTS sections against file size for obvious reasons, + which allows fuzzed debug sections to be stupidly large. Real debug + sections of course always have contents. + + PR 31692 + * objdump.c (load_specific_debug_section): Don't allow sections + without contents. + +2024-05-10 Andrew Burgess + + gdb: add gdbarch_stack_grows_down function + In another patch I'm working on I needed to ask: does the stack grow + down, or grow up? + + Looking around I found in infcall.c some code where we needed to ask + the same question, what we do there is ask: + + gdbarch_inner_than (gdbarch, 1, 2) + + which should do the job. However, I don't particularly like copying + this, it feels like we're asking something slightly different that + just happens to align with the question we're actually asking. + + I propose adding a new function `gdbarch_stack_grows_down`. This is + not going to be a gdbarch method that can be overridden, instead, this + will just call the gdbarch_inner_than function. We already have some + gdbarch methods like this, checkout arch-utils.c for examples. + + I think it's now clearer what we're actually doing. + + A new self-test ensures that all architectures have a stack that + either grows down, or grows up. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-10 Nick Clifton + + Add missing \n to the end of warning messages in dwarf.c. + PR 31722 + +2024-05-10 Pedro Alves + + gdb sim testing, set gdb_protocol to "sim" + Bernd reported that when testing with riscv-unknown-elf target using + the simulator, before commit c7a2ee649115 ("gdb_is_target_native -> + gdb_protocol_is_native"), he had: + + PASS: gdb.base/load-command.exp: probe for target native + PASS: gdb.base/load-command.exp: check initial value of the_variable + PASS: gdb.base/load-command.exp: manually change the_variable + PASS: gdb.base/load-command.exp: check manually changed value of the_variable + PASS: gdb.base/load-command.exp: reload: re-load binary + PASS: gdb.base/load-command.exp: reload: check initial value of the_variable + + and now: + + UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command + + The problem is that the sim board/config isn't setting gdb_protocol + anywhere, so gdb_protocol_is_native returns true. + + This commit fixes it by making gdb/testsuite/config/sim.exp set + gdb_protocol to "sim". + + Reported-by: Bernd Edlinger + Tested-by: Bernd Edlinger + Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a + +2024-05-10 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup) + In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register + more robust") I added this code in unwind_infopy_add_saved_register: + ... + if (value->optimized_out () || !value->entirely_available ()) + ... + which may throw c++ exceptions. + + This needs to be caught and transformed into a python exception. + + Fix this by using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") + +2024-05-10 GDB Administrator + + Automatic date update in version.in + +2024-05-09 Bernd Edlinger + + sim: riscv: Fix build issue due to recent binutils commit + The commit c144f6383379 removed INSN_CLASS_A and + added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead, + which broke the build of the sim for riscv targets. + + Fix that by using the new INSN_CLASS types. + + Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.") + + Approved-By: Tom Tromey + +2024-05-09 Eli Zaretskii + + Fix typo in gdb/README. + Patch from Tiezhu Yang . + +2024-05-09 Andrew Burgess + + gdb: convert address_in_mem_range to mem_range::contains + Replace the global function address_in_mem_range with the member + function mem_range::contains. The implementation of the function + doesn't change. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Andrew Burgess + + gdb: add a new build_id_equal function + Add two versions of a new function build_id_equal which can be used to + compare build-ids, then make use of these functions in GDB. It seems + better to have a specific function for the task of comparing build-ids + rather than having a length check followed by a memcmp call. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Vladimir Mezentsev + + Fix hard-coded bash path in gprofng + When running 'make check', the default gprofng test suite creates a + shell script for which it used a hardcoded shebang of '/usr/bin/bash' + this script would not run if bash is in a different location, like + /bin/bash + + This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the + installation path of bash is detected at configuration time. The + configuration is propagated to the runtest command line where it is + needed. + +2024-05-09 GDB Administrator + + Automatic date update in version.in + +2024-05-08 Andrew Burgess + + gdb/doc: use silent-rules.mk in the Makefile + Make use of silent-rules.mk when building the GDB docs. + + During review it was requested that there be more specific rules than + just reusing the general 'GEN' rule everywhere in the doc/ directory, + so I've added: + + ECHO_DVIPS = @echo " DVIPS $@"; + ECHO_TEX = @echo " TEX $@"; + ECHO_PDFTEX = @echo " PDFTEX $@"; + ECHO_TEXI2DVI = @echo " TEXI2DVI $@"; + ECHO_MAKEHTML = @echo " MAKEHTML $@"; + ECHO_TEXI2POD = @echo " TEXI2POD $@"; + ECHO_TEXI2MAN = @echo " TEXI2MAN $@"; + ECHO_MAKEINFO = @echo " MAKEINFO $@"; + + Then I've made use of these new silent rules and added lots of uses of + SILENT to reduce additional clutter. + + As the man page generation is done in two phases, first the creation + of a .pod file, then the creation of the final man page file, I've + restructured the man page rules. Previously we had one rule for each + of the 5 man pages. I now have one general rule that will generate + all of the 5 .pod files, then I have two rules that convert the .pod + files into the final man pages. + + I needed two rules for the man page generation as some man pages match + %.1 and some match %.5. I could combine these by using the GNU Make + .SECONDARYEXPANSION extension, but I think having two rules like this + is probably clearer, and the duplication is minimal. + + Cleaning up the temporary .pod files is now moved into the + 'mostlyclean' target rather than being done as soon as the man page is + created. + + I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like + SILENT_FLAG, but is set to '-q' when in silent mode, this can be used + with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to + mean: only report errors. + + As with the rest of the GDB makefiles, I've only converted the + "generation" rules to use silent-rules.mk, the install / uninstall + rules are left unchanged. + + When looking at the 'diststuff' target, which generates the info and + man pages, I noticed the recipe for this rule just deleted a temporary + file. As that temporary file is already cleaned up as part of the + 'clean' rule I've removed the deletion from the 'diststuff' target. + + There are still a few "generation" targets that produce output, there + seems to be no flag to silence the 'tex' and 'pdftex' commands which + some recipes use, I've not worried about these for now, e.g. the + refcard.dvi and refcard.pdf targets still produce some output. + + Luckily, when doing a 'make all' in the gdb/ directory, we only build + the info docs by default, and those rules are now nice and silent, so + a complete GDB build is now looking nice and quiet by default. + + While working on this patch I noticed that 'make -j all-doc' doesn't + work (reliably), this is a preexisting bug in the way that dvi/pdf + targets are generated. For example gdb.dvi and gdb.pdf both use the + texi2dvi tool, which relies on temporary files to hold state. If both + these rules run in parallel then one (or both) of the recipes will + fail. + + Luckily, the default docs target (all), which is what gets run when we + do 'make all' in the gdb/ directory, doesn't build the dvi and pdf + targets, so we're OK in that case. + + I've not tried to fix this problem in this commit as it already + existed, and I don't want to do too much in one commit. I mention it + only because I ran into this issue while testing this commit. + +2024-05-08 Guinevere Larsen + + gdb: Change "list ." command's error when no debuginfo is available + Currently, when a user tries to list the current location, there are 2 + different error messages that can happen, either: + + (gdb) list . + No symbol table is loaded. Use the "file" command. + or + (gdb) list . + No debug information available to print source lines. + + The difference here is if gdb can find any symtabs at all or not, which + is not something too important for end-users - and isn't informative at + all. This commit changes it so that the error always says that there + isn't debug information available, with these two variants: + + (gdb) list . + Insufficient debug info for showing source lines at current PC (0x55555555511d). + or + (gdb) list . + Insufficient debug info for showing source lines at default location. + + The difference now is if the inferior has started already, which is + controlled by the user and may be useful. + + Unfortunately, it isn't as easy to differentiate if the symtab found for + other list parameters is correct, so other invocations, such as "list +" + still retain their original error message. + + Co-Authored-By: Simon Marchi + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-05-08 Andrew Burgess + + gdb: more filename styling + I spotted a few places in solib.c and build-id.c where we could apply + file name styling. + + Other than the extra styling, there should be no user visible changes + after this commit. + + Approved-By: Tom Tromey + +2024-05-08 Tom de Vries + + [gdb/testsuite] Add gdb.tui/reread.exp + Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because + all_objfiles_removed triggers tui_display_main"). + + When building with address sanitizer, and reverting the commit it triggers the + heap-use-after-free. + + Tested on aarch64-linux. + + PR symtab/31697 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + +2024-05-08 Aditya Vidyadhar Kamath + + Fix AIX thread exit events not being reported and UI to show kernel thread ID. + In AIX when a thread exits we were not showing that a thread exit event happened + and GDB continued to keep the terminated threads. + + If we have terminated threads then the UI on info threads command will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o) + 2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.) + + If we see the frame is not getting displayed correctly. + + The reason for the same is that in AIX we were not managing thread states. In particular we do not know + when a thread terminates. + + The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit. + + This patch is a fix to the same. + + Also certain UI is changed. + + On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information. + + [New Thread 258 (tid 32178533)] + [New Thread 515 (tid 30343651)] + [New Thread 772 (tid 33554909)] + [New Thread 1029 (tid 24969489)] + [New Thread 1286 (tid 18153945)] + [New Thread 1543 (tid 30736739)] + [Thread 258 (tid 32178533) exited] + [Thread 515 (tid 30343651) exited] + [Thread 772 (tid 33554909) exited] + [Thread 1029 (tid 24969489) exited] + [Thread 1286 (tid 18153945) exited] + [Thread 1543 (tid 30736739) exited] + + and info threads will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + + Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well. + +2024-05-08 Tom Tromey + + Fix typo in binutils manual + I happened to notice that the binutils manual has a typo in the name + of a command-line option. + +2024-05-08 H.J. Lu + + ld: Add PR ld/31710 tests + PR ld/31710 + * testsuite/ld-elf/wrap.exp: Run ld/31710 tests. + * testsuite/ld-elf/wrap2.h: New file. + * testsuite/ld-elf/wrap2a.c: Likewise. + * testsuite/ld-elf/wrap2b.c: Likewise. + +2024-05-08 H.J. Lu + + ld: Run --wrap tests only if supported + Run --wrap tests with shared library only if -shared is supported. + + * testsuite/ld-elf/wrap.exp: Run --wrap tests with shared library + only if -shared is supported. + +2024-05-08 Nick Clifton + + Fix RELOC_FOR_GLOBAL_SYMBOLS macro so that it can cope with user defined symbols that start with __wrap_. + PR 31710 + +2024-05-08 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust + On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register + from non-FreeBSD target descriptions") I ran into: + ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \ + backtrace when the unwind is broken at frame 5 + ... + + What happens is the following: + - the TestUnwinder from inline-frame-cycle-unwind.py calls + gdb.UnwindInfo.add_saved_register with reg == tpidruro and value + "", + - pyuw_sniffer calls value->contents ().data () to access the value of the + register, which throws an UNAVAILABLE_ERROR, + - this causes the TestUnwinder unwinder to fail, after which another unwinder + succeeds and returns the correct frame, and + - the test-case fails because it's counting on the TestUnwinder to succeed and + return an incorrect frame. + + Fix this by checking for !value::entirely_available as well as + valued::optimized_out in unwind_infopy_add_saved_register. + + Tested on x86_64-linux and arm-linux. + + Approved-By: Andrew Burgess + + PR python/31437 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437 + +2024-05-08 Nelson Chu + + RISC-V: Support B, Zaamo and Zalrsc extensions. + * https://github.com/riscv/riscv-b/tags + Added standard B extension back, which implies Zba, Zbb and Zbs extensions. + + * https://github.com/riscv/riscv-zaamo-zalrsc/tags + Splited standard A extension into two new extensions, Zaamo and Zalrsc. + The A extension implies Zaamo and Zalrsc extensions. + + Not sure if we need to do the similar check as i and zicsr/zifencei. + + Passed riscv[32|64]-[elf/linux] binutils testcases. + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules + for A and B extensions. The A implies Zaamo and Zalrsc, the + B implies Zba, Zbb and Zbs. + (riscv_supported_std_ext): Supported B extension with v1.0. + (riscv_supported_std_z_ext): Supported Zaamo and Zalrsc with v1.0. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): Updated. + include/ + * opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_A, Added + INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC. + opcodes/ + * riscv-opc.c (riscv_opcodes): Splited standard A extension into two + new extensions, Zaamo and Zalrsc. + gas/ + * testsuite/gas/riscv/march-imply-a.d: New testcase. + * testsuite/gas/riscv/march-imply-b.d: New testcase. + * testsuite/gas/riscv/attribute-01.d: Updated. + * testsuite/gas/riscv/attribute-02.d: Updated. + * testsuite/gas/riscv/attribute-03.d: Updated. + * testsuite/gas/riscv/attribute-04.d: Updated. + * testsuite/gas/riscv/attribute-05.d: Updated. + * testsuite/gas/riscv/attribute-10.d: Updated. + * testsuite/gas/riscv/mapping-symbols.d: Updated. + * testsuite/gas/riscv/march-imply-g.d: Updated. + * testsuite/gas/riscv/march-imply-unsupported.d: Updated. + * testsuite/gas/riscv/march-ok-reorder.d: Updated. + ld/ + * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Updated. + +2024-05-08 GDB Administrator + + Automatic date update in version.in + +2024-05-07 Hannes Domani + + Fix heap-use-after-free because all_objfiles_removed triggers tui_display_main + Since gdb-10 there is a heap-use-after free happening if starting the + target in TUI triggers a re-reading of symbols. + + It can be reproduced with: + + $ gdb -q -batch a.out -ex "tui enable" -ex "shell touch a.out" -ex start + + ==28392== Invalid read of size 1 + ==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503) + ==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641) + ==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473) + ==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150) + ==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958) + ==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970) + ==28392== by 0x77120F: select_source_symtab() (source.c:319) + ==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401) + ==28392== by 0x807558: tui_display_main() (tui-winsource.c:55) + ==28392== by 0x7937B5: clear_symtab_users(enum_flags) (functional:2464) + ==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd + ==28392== at 0x4A0A430: free (vg_replace_malloc.c:446) + ==28392== by 0x936B63: _obstack_free (obstack.c:280) + ==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735) + ==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575) + ==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552) + ==28392== by 0x5D3A50: command_line_handler(std::unique_ptr >&&) (event-top.c:788) + ==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259) + ==28392== by 0x857B3F: rl_callback_read_char (callback.c:290) + ==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195) + ==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234) + + The problem is that tui_display_main is called by the all_objfiles_removed + hook, which tries to access the symbol cache. + This symbol cache is actually stale at this point, and would have been + flushed immediately afterwards by that same all_objfiles_removed hook. + + It's not possible to tell the hook to call the observers in a specific + order, but in this case the tui_all_objfiles_removed observer is actually + not needed, since it only calls tui_display_main, and a 'main' can only + be found if objfiles are added, not removed. + + So the fix is to simply remove the tui_all_objfiles_removed observer. + + The clearing of the source window (if symbols were removed by e.g. 'file' + without arguments) still works, since this is done by the + tui_before_prompt observer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + Approved-By: Tom Tromey + +2024-05-07 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While rebasing this series[1] past this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + I worried that there could be other paths that might result in an xcr0 + value which has X86_XSTATE_MPX set in x32 mode. As everyone + eventually calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this will uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this, but the author of commit 4bb20a6244b7091 did test this + series with that assert in place and didn't see any problems. + + [1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + + Approved-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver/ipa/x86: remove unneeded declarations + Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no + longer needed. These are: + + 1. 'init_registers_amd64_linux' - the comment claims this function + is auto generated, but I don't believe that this is still the case. + Also the function is not used in this file, + + 2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any + more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but + neither are used in this file, so lets remove the declaration. + + The amd64 in-process-agent still builds fine after this commit. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-05-07 Pedro Alves + + gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch + The code in gdb.base/watchpoint-running.exp that is trying to skip + testing with hardware watchpoints also skips testing with software + watchpoints if hardware watchpoints aren't supported by the target. + This fixes it. + + Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba + +2024-05-07 Pedro Alves + + Remove gdb.base/watchpoint-running.exp leftover + Remove accidentally leftover commented-out line from + gdb.base/watchpoint-running.exp. + + Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697 + +2024-05-07 Lancelot SIX + + gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lock + A recent commit refactored with_rocm_gpu_lock: + + commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e + Date: Sat May 4 10:41:09 2024 +0200 + + [gdb/testsuite] Factor out proc with_lock + + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + This causes regressions in gdb.rocm/*.exp (as well as in downstream + rocgdb). The issue can be reproduced in the following minimal test: + + load_lib rocm.exp + set foo hello + with_rocm_gpu_lock { + verbose -logs $foo + } + + The issue is that the body to execute under the lock is executed in the + context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of + in the context of the "original" caller. + + This patch adjusted with_rocm_gpu_lock to account for the new extra + frame in the call stack between the caller of with_rocm_gpu_lock and + where the code execution is triggered. + + Approved-By: Tom de Vries + + Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe + +2024-05-07 Lulu Cai + + LoongArch: Fix ld test failures caused by using instruction aliases + Different versions of objdump may take different forms of output + for instructions. Use -M no-aliases to avoid the failure of ld + test cases caused by objdump using aliases. + +2024-05-07 GDB Administrator + + Automatic date update in version.in + +2024-05-06 Bernd Edlinger + + Fix build issues with mingw toolchain + With a x86_64-pc-mingw32 toolchain there is a build issue + whether or not the --disable-threading option is used. + The problem happens because _WIN32_WINNT is defined to 0x501 + before #include which makes the compilation abort + due to missing support for __gthread_cond_t in std_mutex.h, + which is conditional on _WIN32_WINNT >= 0x600. + + Fix the case when --disable-threading is used, by only + including in gdb/complaints.c when STD_CXX_THREAD + is defined. + + Additionally make the configure script try to #include + to automatically select --disable-threading when the header file + is not able to compile. + + Approved-By: Tom Tromey + +2024-05-06 Tom de Vries + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + When running the testsuite on a system with kernel.yama.ptrace_scope set to 1, + we run into attach failures. + + Fix this by recognizing "ptrace: Operation not permitted" in + can_spawn_for_attach. + + Tested on aarch64-linux and x86_64-linux. + + Approved-By: Pedro Alves + +2024-05-06 Tom de Vries + + [gdb/exp] Redo cast handling for indirection + In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I + introduced the behaviour that even though we have: + ... + (gdb) p *a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + we get: + ... + (gdb) p (char)*a_loc () + $1 = 97 'a' + ... + + In other words, the unknown return type of a_loc is inferred from the cast, + effectually evaluating: + ... + (gdb) p (char)*(char *)a_loc () + ... + + This is convient for the case that errno is defined as: + ... + #define errno (*__errno_location ()) + ... + and the return type of __errno_location is unknown but the macro definition is + known, such that we can use: + ... + (gdb) p (int)errno + ... + instead of + ... + (gdb) p *(int *)__errno_location () + ... + + However, as Pedro has pointed out in post-commit review [1], this makes it + harder to reason about the semantics of an expression. + + For instance, this: + ... + (gdb) p (long long)*a_loc ()" + ... + would be evaluated without debug info as: + ... + (gdb) p (long long)*(long long *)a_loc ()" + ... + but with debug info as: + ... + (gdb) p (long long)*(char *)a_loc ()" + ... + + Fix this by instead simply erroring out for this case: + ... + (gdb) p (char)*a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + + Tested on x86_64-linux. + + Approved-By: Pedro Alves + + [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html + +2024-05-06 Cui, Lili + + x86: Drop using extension_opcode to encode vvvv register + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + extension_opcode to encode the vvvv register. + * testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases. + * testsuite/gas/i386/x86-64-sse2avx.s: Diito. + + opcodes/ChangeLog: + + * i386-opc.tbl: Added DstVVVV to some extension_opcode instructions. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Drop SwapSources + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + SWAP_SOURCES to encode the vvvv register. + + opcodes/ChangeLog: + + * i386-opc.h (SWAP_SOURCES): Dropped. + (NO_DEFAULT_MASK): Adjusted the value. + (ADDR_PREFIX_OP_REG): Ditto. + (DISTINCT_DEST): Ditto. + (IMPLICIT_STACK_OP): Ditto. + (VexVVVV_SRC2): New. + * i386-opc.tbl: Dropped SwapSources and replaced its VexVVVV + with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Use vexvvvv as the switch state to encode the vvvv register + Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV. + Src1VVVV means using VEX.vvvv encodes the first source register + operand. The old logic did not check vexvvvv first, which made the + logic here very complicated. + + gas/ChangeLog: + + * config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV. + (build_modrm_byte): Used vexvvvv to encode the vvvv register. + (s_insn): Replaced 1 with Src1VVVV. + + opcodes/ChangeLog: + + * i386-opc.h (VexVVVV_DST): Adjusted the value. + (Src1VVVV): New. + * i386-opc.tbl: Replaced part VexVVVV with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 GDB Administrator + + Automatic date update in version.in + +2024-05-05 GDB Administrator + + Automatic date update in version.in + +2024-05-04 Hannes Domani + + Fix heap-use-after-free in index-cached with --disable-threading + If threads are disabled, either by --disable-threading explicitely, or by + missing std::thread support, you get the following ASAN error when + loading symbols: + + ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 + READ of size 1 at 0x614000002128 thread T0 + #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 + #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 + #2 0x1705e39 in std::function::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 + #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 + + 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) + freed by thread T0 here: + #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 + #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 + #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 + #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 + + It's happening because cooked_index_worker::wait always returns true in + this case, which tells cooked_index::wait it can delete the m_state + cooked_index_worker member, but cooked_index_worker::write_to_cache tries + to access it immediately afterwards. + + Fixed by making cooked_index_worker::wait only return true if desired_state + is CACHE_DONE, same as if threading was enabled, so m_state will not be + prematurely deleted. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 + Approved-By: Tom Tromey + +2024-05-04 Tom Tromey + + Remove dwarf2_per_objfile::adjust + All the calls to dwarf2_per_objfile::adjust have been removed, so we + can remove this function entirely. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261 + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_attribute_value + Currently, read_attribute_value calls dwarf2_per_objfile::adjust on + any address. This seems wrong, because the address may not even be in + the text section. + + Luckily, this call is also not needed, because read_func_scope calls + 'relocate', which does the same work. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_call_site_scope + read_call_site_scope does not need to call 'adjust', because in + general the call site is not a symbol address, but rather just the + address of some particular call. + +2024-05-04 Tom Tromey + + Remove more calls to dwarf2_per_objfile::adjust + As with the previous patch, this patch removes some calls to + dwarf2_per_objfile::adjust. These calls are not needed by the cooked + indexer, as it does not create symbols or look up symbols by address. + + The call in dwarf2_ranges_read is similarly not needed, as it is only + used to update an addrmap; and in any case I believe this particular + call is only reached by the indexer. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from ranges readers + dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an + address, leaving the result unrelocated. However, this adjustment is + only needed for text-section symbols -- it isn't needed for any sort + of address mapping. Therefore, these calls can be removed from + read_addrmap_from_aranges and create_addrmap_from_gdb_index. + + Approved-By: Andrew Burgess + +2024-05-04 Alan Modra + + bus error with fuzzed archive element + * libbfd.c (bfd_mmap_local): Sanity check rsize against actual + file offset and size, not an archive element offset and size. + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing (check//% case) + Make target check//% is the gdb variant of a similar gcc make target [1]. + + When running tests using check//%: + ... + $ cd build/gdb + $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp + ... + we get: + ... + $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum + 2427 + $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum + 2423 + ... + + The problem is that there are two portnum files used in parallel. + + Fix this by: + - creating a common lockdir build/gdb/testsuite.lockdir for make target + check//%, + - passing this down to the runtests invocations using variable GDB_LOCK_DIR, + and + - using GDB_LOCK_DIR in lock_dir. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31632 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 + + [1] https://gcc.gnu.org/install/test.html + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check-parallel -j2 TESTS=gdb.server/*.exp + ... + we run into: + ... + Running gdb.server/abspath.exp ... + PORTNUM: 2345 + ... + and: + ... + Running gdb.server/bkpt-other-inferior.exp ... + PORTNUM: 2345 + ... + + This is because the test-cases are run in independent runtest invocations. + + Fix this by handling the parallel case in get_portnum using: + - a file $objdir/cache/portnum to keep the portnum variable, and + - a file $objdir/cache/portnum.lock to serialize access to it. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Move gpu-parallel.lock to cache dir + The lock directory returned by lock_dir is currently $objdir. + + It seems possible to leave a stale lock file that blocks progress in a + following run. + + Fix this by using a directory that is guaranteed to be initially empty when + using GDB_PARALLEL, like temp or cache. + + In gdb/testsuite/README I found: + ... + cache in particular is used to share data across invocations of runtest + ... + which seems appropriate, so let's use cache for this. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc lock_dir + In lib/rocm.exp we have: + ... + set gpu_lock_filename $objdir/gpu-parallel.lock + ... + + This decides both the lock file name and directory. + + Factor out a new proc lock_dir that decides on the directory, leaving just: + ... + set gpu_lock_filename gpu-parallel.lock + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc with_lock + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Make portnum a persistent global + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check TESTS=gdb.server/*.exp + ... + we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2345 + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + ... + + So, while get_portnum does return increasing numbers in a single test-case, it + restarts at each test-case. + + This is a regression since the introduction of persistent globals. + + Fix this by using "gdb_persistent_global portnum", such that we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + PORTNUM: 2351 + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc get_portnum + In gdbserver_start, we have some code that determines what port number to use: + ... + # Port id -- either specified in baseboard file, or managed here. + if [target_info exists gdb,socketport] { + set portnum [target_info gdb,socketport] + } else { + # Bump the port number to avoid conflicts with hung ports. + incr portnum + } + ... + + Factor this out into a new proc get_portnum. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 GDB Administrator + + Automatic date update in version.in + +2024-05-03 Pedro Alves + + Adjust gdb_continue_to_end for Windows + On Cygwin, supposely single-threaded programs are always + multi-threaded, due to the extra threads spawned by the Cygwin + runtime. Because of that, any gdb_continue_to_end call that doesn't + specify "allow_extra" fails, like so: + + (gdb) PASS: gdb.base/langs.exp: show language at main + continue + Continuing. + [Thread 16140.0x1fbc exited with code 0] + [Thread 16140.0x2458 exited with code 0] + [Thread 16140.0x3494 exited with code 0] + [Inferior 1 (process 16140) exited normally] + (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited) + + Similarly, with this simple program compiled with MinGW: + + $ cat ~/sleeper.c + #include + + int main () + { + Sleep (2000); + return 0; + } + + and with a MinGW GDB, I see: + + (gdb) start + ... + (gdb) info threads + Id Target Id Frame + * 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5 + 2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll + (gdb) c + Continuing. + [Thread 15292.0x3850 exited with code 0] + [Inferior 1 (process 15292) exited normally] + (gdb) + + This commit adjusts gdb_continue_to_end to expect the thread exited + messages, on Cygwin and MinGW. + + Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 + Approved-By: Andrew Burgess + +2024-05-03 Mark Wielaard + + [gdb/build] Fix gdbserver/linux-aarch64-low.cc build + Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + removed the last use of i in gdbserver/linux-aarch64-low.cc + (aarch64_target::low_stopped_data_address). Breaking the build on + aarch64 with: + + gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?: + gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable] + 557 | int pid, i; + | ^ + cc1plus: all warnings being treated as errors + + Fix this by removing the variable i completely. + + Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + +2024-05-03 Tom de Vries + + [gdb/testsuite] Use save_vars to restore GDBFLAGS + There's a pattern of using: + ... + set saved_gdbflags $GDBFLAGS + set GDBFLAGS "$GDBFLAGS ..." + + set GDBFLAGS $saved_gdbflags + ... + + Simplify this by using save_vars: + ... + save_vars { GDBFLAGS } { + set GDBFLAGS "$GDBFLAGS ..." + + } + ... + + Tested on x86_64-linux. + +2024-05-03 Tom de Vries + + [gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0 + INTERNAL_GDBFLAGS contains: + - -quiet + - -iex "set width 0" + - -iex "set height 0" + + There are test-cases that add these once more. + + Clean this up. + + Tested on x86_64-linux. + + PR testsuite/31649 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649 + +2024-05-03 Tom de Vries + + [gdb/testsuite] Update INTERNAL_GDBFLAGS example + In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added + -q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS + example in gdb/testsuite/README. + + Fix this by adding the -q there as well. + +2024-05-03 Tom de Vries + + [gdb/exp] Fix cast handling for indirection + Consider a test-case compiled without debug info, containing: + ... + char a = 'a'; + + char * + a_loc (void) + { + return &a; + } + ... + + We get: + ... + (gdb) p (char)*a_loc () + Cannot access memory at address 0x10 + ... + + There's a bug in unop_ind_base_operation::evaluate that evaluates + "(char)*a_loc ()" the same as: + ... + (gdb) p (char)*(char)a_loc () + Cannot access memory at address 0x10 + ... + + Fix this by instead evaluating it the same as: + ... + (gdb) p (char)*(char *)a_loc () + $1 = 97 'a' + ... + + Tested on x86_64-linux. + + PR exp/31693 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693 + +2024-05-03 Jan Beulich + + x86: tidy templates + Some of them no longer need a separate vvvv attribute, thus allowing + them to be simplified. For the situation is slightly different: + None of the remaining uses make use of vvvv anymore. + + x86/APX: further extend SSE2AVX coverage + Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is + in use, {evex} should be respected, too. So far this is the case only + for insns where eGPR-s can come into play. Extend coverage to insns with + only %xmm register and possibly immediate operands. + +2024-05-03 Jan Beulich + + x86/APX: extend SSE2AVX coverage + Legacy encoded SIMD insns are converted to AVX ones in that mode. When + eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where + available; there are quite a few which can't be converted). + + Note that LDDQU is represented as VMOVDQU32 (and the prior use of the + sse3 template there needs dropping, to get the order right). + + Note further that in a few cases, due to the use of templates, AVX512VL + is used when AVX512F would suffice. Since AVX10 is the main reference, + this shouldn't be too much of a problem. + +2024-05-03 Jan Beulich + + x86: zap value-less Disp8MemShift from non-EVEX templates + In order to allow to continue to use templatized SSE2AVX templates when + enhancing those to also cover eGPR usage, Disp8MemShift wants using to + deviate from what general template attributes supply. That requires + using Disp8MemShift in a way also affecting non-EVEX templates, yet + having this attribute set would so far implicitly mean EVEX encoding. + Recognize the case and instead zap the attribute if no other attribute + indicates EVEX encoding. + + No change in generated tables. + +2024-05-03 GDB Administrator + + Automatic date update in version.in + +2024-05-02 Tom Tromey + + Fix regression on aarch64-linux gdbserver + Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64") + fixed a watchpoint bug in gdb -- but did not touch the corresponding + code in gdbserver. + + This patch moves the gdb code into gdb/nat, so that it can be shared + with gdbserver, and then changes gdbserver to use it, fixing the bug. + + This is yet another case where having a single back end would prevent + bugs. + + I tested this using the AdaCore internal gdb testsuite. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + Approved-By: Luis Machado + +2024-05-02 Alan Modra + + PR31692, objdump fails .debug_info size check + PR 31692 + * objdump.c (load_specific_debug_section): Replace bfd_get_size + check with bfd_section_size_insane. Call free_debug_section + after printing error messages. Set section->start NULL when + freeing. + +2024-05-02 Tom de Vries + + [gdb/symtab] Work around PR gas/29517, dwarf2 case + In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a + workaround for PR gas/29517. + + The problem is present in gas version 2.39, and fixed in 2.40, so the + workaround is only active for gas version == 2.39. + + However, the problem in gas is only fixed for dwarf version >= 3, which + supports DW_TAG_unspecified_type. + + Fix this by also activating the workaround for dwarf version == 2. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR symtab/31689 + https://sourceware.org/bugzilla/show_bug.cgi?id=31689 + +2024-05-02 GDB Administrator + + Automatic date update in version.in + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in get_compiler_info + When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board + local-remote-host and target board remote-gdbserver-on-localhost, I get: + ... + $ ls build/gdb/testsuite + cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile + outputs site.bak site.exp temp + ... + + The file compiler.i is there because get_compiler_info uses: + ... + set ppout "$outdir/compiler.i" + ... + + The file is a temporary, and as such belongs in a temp dir. Fix this by using + standard_temp_file, moving the file to build/gdb/testsuite/temp//compiler.i. + + Tested on x86_64-linux. + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.exp + After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have: + ... + $ ls build/gdb/testsuite + cache config.status gdb.log lib outputs site.exp + config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp + ... + + The file gdb-index-nodebug.gdb-index doesn't belong there. + + It happens to be there because we do: + ... + set index_file ${testfile}.gdb-index + set cmd "save gdb-index [file dirname ${index_file}]" + ... + which results in: + ... + (gdb) save gdb-index . + ... + + The intention was possibly to use $binfile instead of $testfile, but using + that wouldn't work for remote host. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-05-01 GDB Administrator + + Automatic date update in version.in + +2024-04-30 Nelson Chu + + RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown. + bfd/ + PR 29823 + * elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function. + (elf_backend_obj_attrs_handle_unknown): Defined to + riscv_elf_obj_attrs_handle_unknown. + +2024-04-30 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.base/memops-watchpoint.exp + Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove. + These functions are frequently optimized with specialized instructions + that favor larger memory access operations, so make sure GDB behaves + correctly in their presence. + + There's a separate watched variable for each function so that the testcase + can test whether GDB correctly identified the watchpoint that triggered. + + Also, the watchpoint is 28 bytes away from the beginning of the buffer + being modified, so that large memory accesses (if present) are exercised. + + PR testsuite/31484 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484 + + Approved-by: Kevin Buettner + +2024-04-30 Thiago Jung Bauermann + + gdb/nat/linux: Fix attaching to process when it has zombie threads + When GDB attaches to a multi-threaded process, it calls + linux_proc_attach_tgid_threads () to go through all threads found in + /proc/PID/task/ and call attach_proc_task_lwp_callback () on each of + them. If it does that twice without the callback reporting that a new + thread was found, then it considers that all inferior threads have been + found and returns. + + The problem is that the callback considers any thread that it hasn't + attached to yet as new. This causes problems if the process has one or + more zombie threads, because GDB can't attach to it and the loop will + always "find" a new thread (the zombie one), and get stuck in an + infinite loop. + + This is easy to trigger (at least on aarch64-linux and powerpc64le-linux) + with the gdb.threads/attach-many-short-lived-threads.exp testcase, because + its test program constantly creates and finishes joinable threads so the + chance of having zombie threads is high. + + This problem causes the following failures: + + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted on (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the inferior (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted off (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout) + ERROR: breakpoints not deleted + + The iteration number is random, and all tests in the subsequent iterations + fail too, because GDB is stuck in the attach command at the beginning of + the iteration. + + The solution is to make linux_proc_attach_tgid_threads () remember when it + has already processed a given LWP and skip it in the subsequent iterations. + + PR testsuite/31312 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312 + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Factor linux_proc_get_stat_field out of linux_common_core_of_thread + The new function will be used in a subsequent patch to read a different + stat field. + + The new code is believed to be equivalent to the old code, so there + should be no change in GDB behaviour. The only material change was to + use std::string and string_printf rather than a fixed char array to + build the path to the stat file. + + Also, take the opportunity to move the function's documentation comment to + the header file, to conform with GDB practice. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread + The code and comment reference stat fields by made-up indexes. The + procfs(5) man page, which describes the /proc/PID/stat file, has a numbered + list of these fields so it's more convenient to use those numbers instead. + + This is currently an implementation detail inside the function so it's + not really relevant with the code as-is, but a future patch will do some + refactoring which will make the index more prominent. + + Therefore, make this change in a separate patch so that it's simpler to + review. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 GDB Administrator + + Automatic date update in version.in + +2024-04-29 Pedro Alves + + gdb/Cygwin: Fix attach pid error message + On Cygwin, with "attach PID": + + - GDB first tries to interpret PID as a Windows native PID, and tries + to attach to that. + + - if the attach fails, GDB then tries to interpret the PID as a + Cygwin PID, and attach to that. + + If converting the user-provided PID from a Cygwin PID to a Windows PID + fails, you get this: + + (gdb) attach 12345 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + + Note "process 0". + + With the fix in this commit, we'll now get: + + (gdb) attach 12345 + Can't attach to process 12345 (error 2: The system cannot find the file specified.) + + I noticed this while looking at gdb.log after running + gdb.base/attach.exp on Cygwin. + + Change-Id: I05b9dc1f3a634a822ea49bb5c61719f5e62c8514 + Approved-By: Luis Machado + +2024-04-29 Andrew Burgess + + gdb/doc: document how filename arguments are formatted + In the following commits I intend to improve GDB's filename + completion. However, how filenames should be completed is a little + complex because GDB is not consistent with how it expects filename + arguments to be formatted. + + This commit documents the current state of GDB when it comes to + formatting filename arguments. + + Currently GDB will not correctly complete filenames inline with this + documentation; GDB will either fail to complete, or complete + incorrectly (i.e. the result of completion will not then be accepted + by GDB). However, later commits in this series will fix completion. + + Approved-By: Eli Zaretskii + +2024-04-29 Nick Clifton + + Fix initiali state of DWARF v5 line number table in BFD library + PR 30783 + +2024-04-29 Andrew Burgess + + gdb/remote: fix qRcmd error handling + This commit: + + commit 3623271997a5c0d79609aa6a1f35ef61b4469054 + Date: Tue Jan 30 15:55:47 2024 +0100 + + remote.c: Use packet_check_result + + Introduced a bug in the error handling of the qRcmd packet. Prior to + this commit if a packet had status PACKET_OK then, if the packet + contained the text "OK" we considered the packet handled. But, if the + packet contained any other content (that was not an error message) + then the content was printed to the user. + + After the above commit this was no longer the case, any non-error + packet that didn't contain "OK" would be treated as an error. + + Currently, gdbserver doesn't exercise this path so it's not possible + to write a simple test for this case. When gdbserver wishes to print + output it sends back an 'O' string output packet, these packets are + handled earlier in the process. Then once gdbserver has finished + sending output an 'OK' packet is sent. + + Approved-By: Tom Tromey + +2024-04-29 Nick Clifton + + Fix building Loongarch BFD with a 32-bit compiler + +2024-04-29 GDB Administrator + + Automatic date update in version.in + +2024-04-28 GDB Administrator + + Automatic date update in version.in + +2024-04-27 Tom Tromey + + Fix typo in TUI comment + tui_win_info::make_visible has a mildly misleading comment -- it says + "visible" where "invisible" is meant. This patch fixes it. + + Remove two unneeded forward declarations + I noticed a couple of forward declarations in the TUI that aren't + needed -- the declarations aren't used in the header files in which + they appear. This patch removes these. + +2024-04-27 Tom de Vries + + [gdb/remote] Fix abort on REMOTE_CLOSE_ERROR + When running test-case gdb.server/connect-with-no-symbol-file.exp on + aarch64-linux (specifically, an opensuse leap 15.5 container on a + fedora asahi 39 system), I run into: + ... + (gdb) detach^M + Detaching from program: target:connect-with-no-symbol-file, process 185104^M + Ending remote debugging.^M + terminate called after throwing an instance of 'gdb_exception_error'^M + ... + + The detailed backtrace of the corefile is: + ... + (gdb) bt + #0 0x0000ffff75504f54 in raise () from /lib64/libpthread.so.0 + #1 0x00000000007a86b4 in handle_fatal_signal (sig=6) + at gdb/event-top.c:926 + #2 + #3 0x0000ffff74b977b4 in raise () from /lib64/libc.so.6 + #4 0x0000ffff74b98c18 in abort () from /lib64/libc.so.6 + #5 0x0000ffff74ea26f4 in __gnu_cxx::__verbose_terminate_handler() () + from /usr/lib64/libstdc++.so.6 + #6 0x0000ffff74ea011c in ?? () from /usr/lib64/libstdc++.so.6 + #7 0x0000ffff74ea0180 in std::terminate() () from /usr/lib64/libstdc++.so.6 + #8 0x0000ffff74ea0464 in __cxa_throw () from /usr/lib64/libstdc++.so.6 + #9 0x0000000001548870 in throw_it (reason=RETURN_ERROR, + error=TARGET_CLOSE_ERROR, fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:203 + #10 0x0000000001548920 in throw_verror (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:211 + #11 0x0000000001548a00 in throw_error (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed") + at gdbsupport/common-exceptions.cc:226 + #12 0x0000000000ac8f2c in remote_target::readchar (this=0x233d3d90, timeout=2) + at gdb/remote.c:9856 + #13 0x0000000000ac9f04 in remote_target::getpkt (this=0x233d3d90, + buf=0x233d40a8, forever=false, is_notif=0x0) at gdb/remote.c:10326 + #14 0x0000000000acf3d0 in remote_target::remote_hostio_send_command + (this=0x233d3d90, command_bytes=13, which_packet=17, + remote_errno=0xfffff1a3cf38, attachment=0xfffff1a3ce88, + attachment_len=0xfffff1a3ce90) at gdb/remote.c:12567 + #15 0x0000000000ad03bc in remote_target::fileio_fstat (this=0x233d3d90, fd=3, + st=0xfffff1a3d020, remote_errno=0xfffff1a3cf38) + at gdb/remote.c:12979 + #16 0x0000000000c39878 in target_fileio_fstat (fd=0, sb=0xfffff1a3d020, + target_errno=0xfffff1a3cf38) at gdb/target.c:3315 + #17 0x00000000007eee5c in target_fileio_stream::stat (this=0x233d4400, + abfd=0x2323fc40, sb=0xfffff1a3d020) at gdb/gdb_bfd.c:467 + #18 0x00000000007f012c in ::operator()(bfd *, + void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400, + sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955 + #19 0x00000000007f015c in ::_FUN(bfd *, void *, + stat *) () at gdb/gdb_bfd.c:956 + #20 0x0000000000f9b838 in opncls_bstat (abfd=0x2323fc40, sb=0xfffff1a3d020) + at bfd/opncls.c:665 + #21 0x0000000000f90adc in bfd_stat (abfd=0x2323fc40, statbuf=0xfffff1a3d020) + at bfd/bfdio.c:431 + #22 0x000000000065fe20 in reopen_exec_file () at gdb/corefile.c:52 + #23 0x0000000000c3a3e8 in generic_mourn_inferior () + at gdb/target.c:3642 + #24 0x0000000000abf3f0 in remote_unpush_target (target=0x233d3d90) + at gdb/remote.c:6067 + #25 0x0000000000aca8b0 in remote_target::mourn_inferior (this=0x233d3d90) + at gdb/remote.c:10587 + #26 0x0000000000c387cc in target_mourn_inferior ( + ptid=) + at gdb/target.c:2738 + #27 0x0000000000abfff0 in remote_target::remote_detach_1 (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6421 + #28 0x0000000000ac0094 in remote_target::detach (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6436 + #29 0x0000000000c37c3c in target_detach (inf=0x22fce540, from_tty=1) + at gdb/target.c:2526 + #30 0x0000000000860424 in detach_command (args=0x0, from_tty=1) + at gdb/infcmd.c:2817 + #31 0x000000000060b594 in do_simple_func (args=0x0, from_tty=1, c=0x231431a0) + at gdb/cli/cli-decode.c:94 + #32 0x00000000006108c8 in cmd_func (cmd=0x231431a0, args=0x0, from_tty=1) + at gdb/cli/cli-decode.c:2741 + #33 0x0000000000c65a94 in execute_command (p=0x232e52f6 "", from_tty=1) + at gdb/top.c:570 + #34 0x00000000007a7d2c in command_handler (command=0x232e52f0 "") + at gdb/event-top.c:566 + #35 0x00000000007a8290 in command_line_handler (rl=...) + at gdb/event-top.c:802 + #36 0x0000000000c9092c in tui_command_line_handler (rl=...) + at gdb/tui/tui-interp.c:103 + #37 0x00000000007a750c in gdb_rl_callback_handler (rl=0x23385330 "detach") + at gdb/event-top.c:258 + #38 0x0000000000d910f4 in rl_callback_read_char () + at readline/readline/callback.c:290 + #39 0x00000000007a7338 in gdb_rl_callback_read_char_wrapper_noexcept () + at gdb/event-top.c:194 + #40 0x00000000007a73f0 in gdb_rl_callback_read_char_wrapper + (client_data=0x22fbf640) at gdb/event-top.c:233 + #41 0x0000000000cbee1c in stdin_event_handler (error=0, client_data=0x22fbf640) + at gdb/ui.c:154 + #42 0x000000000154ed60 in handle_file_event (file_ptr=0x232be730, ready_mask=1) + at gdbsupport/event-loop.cc:572 + #43 0x000000000154f21c in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:693 + #44 0x000000000154dec4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:263 + #45 0x0000000000910f98 in start_event_loop () at gdb/main.c:400 + #46 0x0000000000911130 in captured_command_loop () at gdb/main.c:464 + #47 0x0000000000912b5c in captured_main (data=0xfffff1a3db58) + at gdb/main.c:1338 + #48 0x0000000000912bf4 in gdb_main (args=0xfffff1a3db58) + at gdb/main.c:1357 + #49 0x00000000004170f4 in main (argc=10, argv=0xfffff1a3dcc8) + at gdb/gdb.c:38 + (gdb) + ... + + The abort happens because a c++ exception escapes to c code, specifically + opncls_bstat in bfd/opncls.c. Compiling with -fexceptions works around this. + + Fix this by catching the exception just before it escapes, in stat_trampoline + and likewise in few similar spot. + + Add a new template catch_exceptions to do so in a consistent way. + + Tested on aarch64-linux. + + Approved-by: Pedro Alves + + PR remote/31577 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577 + +2024-04-27 GDB Administrator + + Automatic date update in version.in + +2024-04-26 Pedro Alves + + Improve target.h & target_ops & xfer_partial descriptions + Working backwards in terms of motivation for the patch: + + - When accessing memory via the xfer_partial interface, the process + that we're accessing is indicated by inferior_ptid. This can be + either the same process as current inferior, or a fork child which + does not exist in the inferior list. This is not documented + currently. This commit fixes that. + + - For target delegation to work, we must always make the inferior we + want to call the target method on, the current inferior. This + wasn't documented, AFAICT, so this commit fixes that too. I put + that in the intro comment to target_ops. + + - I actually started writing a larger intro comment to target_ops, as + there was seemingly none, which I did find odd. However, I then + noticed the description closer to the top of the file. I missed it + the first time, because for some reason, that intro comment is no + longer at the top of the file, as #includes etc. have been added + above it over the years. This commit fixes that too, by moving that + intro comment to the top. + + Change-Id: Id21f5462947f2a0f6f3ac0c42532df62ba355914 + Approved-By: Simon Marchi + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579) + Old RHEL systems have a kernel that does not support writing memory + via /proc/pid/mem. On such systems, we fallback to accessing memory + via ptrace. That has a few downsides described in the "Accessing + inferior memory" section at the top of linux-nat.c. + + The target_xfer interface for memory access uses inferior_ptid as + sideband argument to indicate which process to access. Memory access + is process-wide, it is not thread-specific, so inferior_ptid is + sometimes pointed at a process-wide ptid_t for the memory access + (i.e., a ptid that looks like {pid, 0, 0}). That is the case for any + code that uses scoped_restore_current_inferior_for_memory, for + example. + + That is what causes the issue described in PR 31579, where thread_db + calls into the debugger to read memory, which reaches our + ps_xfer_memory function, which does: + + static ps_err_e + ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr, + gdb_byte *buf, size_t len, int write) + { + scoped_restore_current_inferior_for_memory save_inferior (ph->thread->inf); + + ... + ret = target_read_memory (core_addr, buf, len); + ... + } + + If linux_nat_target::xfer_partial falls back to inf_ptrace_target with + a pid-ptid, then the ptrace code will do the ptrace call targeting + pid, the leader LWP. That may fail with ESRCH if the leader is + currently running, or zombie. That is the case in the scenario in + question, because thread_db is consulted for an event of a non-leader + thread, before we've stopped the whole process. + + Fix this by having the ptrace fallback code try to find a stopped LWP + to use with ptrace. + + I chose to handle this in the linux-nat target instead of in common + code because (global) memory is a process-wide property, and this + avoids having to teach all the code paths that use + scoped_restore_current_inferior_for_memory to find some stopped thread + to access memory through, which is a ptrace quirk. That is + effectively what we used to do before we started relying on writable + /proc/pid/mem. I'd rather not go back there. + + To trigger this on modern kernels you have to hack linux-nat.c to + force the ptrace fallback code, like so: + + --- a/gdb/linux-nat.c + +++ b/gdb/linux-nat.c + @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object, + poke would incorrectly write memory to the post-exec address + space, while the core was trying to write to the pre-exec + address space. */ + - if (proc_mem_file_is_writable ()) + + if (0 && proc_mem_file_is_writable ()) + + With that hack, I was able to confirm that the fix fixes hundreds of + testsuite failures. Compared to a test run with pristine master, the + hack above + this commit's fix shows that some non-stop-related tests + fail, but that is expected, because those are tests that need to + access memory while the program is running. (I made no effort to + temporarily pause an lwp if no ptrace-stopped lwp is found.) + + Change-Id: I24a4f558e248aff7bc7c514a88c698f379f23180 + Tested-By: Hannes Domani + Approved-By: Andrew Burgess + +2024-04-26 Pedro Alves + + Fix gdb.base/attach.exp --pid test skipping on native-extended-gdbserver + When testing with the native-extended-gdbserver board, + gdb.base/attach.exp shows a couple failures, like so: + + Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ... + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread) + + From gdb.log: + + builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build + /gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260 + Don't know how to attach. Try "help target". + (gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + + There is a check for [isnative] to skip the test on anything but + target native, but that is the wrong check. native-extended-gdbserver + is "isnative". Fix it by using a gdb_protocol check instead. + + Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Eliminate gdb_is_target_remote / gdb_is_target_native & friends + After the previous patches, gdb_is_target_remote, + gdb_is_target_native, and mi_is_target_remote aren't used anywhere. + This commit eliminates them, along with now unnecessary helpers. + + Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_remote -> gdb_protocol_is_remote + This is similar to the previous patch, but for gdb_protocol_is_remote. + + gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint + print target-stack", which is unnecessary when checking whether + gdb_protocol is "remote" or "extended-remote" would do. Checking + gdb_protocol is more efficient, and can be done before starting GDB + and running to main, unlike gdb_is_target_remote/mi_is_target_remote. + + This adds a new gdb_protocol_is_remote procedure, and uses it in place + of gdb_is_target_remote/mi_is_target_remote throughout. + + There are no uses of gdb_is_target_remote/mi_is_target_remote left + after this. Those will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_native -> gdb_protocol_is_native + gdb_is_target_native uses "maint print target-stack", which is + unnecessary when checking whether gdb_protocol is empty would do. + Checking gdb_protocol is more efficient, and can be done before + starting GDB and running to main, unlike gdb_is_target_native. + + This adds a new gdb_protocol_is_native procedure, and uses it in place + of gdb_is_target_native. + + At first, I thought that we'd end up with a few testcases needing to + use gdb_is_target_native still, especially multi-target tests that + connect to targets different from the default board target, but no, + actually all uses of gdb_is_target_native could be converted. + gdb_is_target_native will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdbserver: Fix vAttach response when attaching is not supported + handle_v_attach calls attach_inferior, which says: + + "return -1 if attaching is unsupported, 0 if it succeeded, and call + error() otherwise." + + So if attach_inferior return != 0, we have the unsupported case, + meaning we should return the empty packet instead of an error. + + In practice, this shouldn't trigger, as vAttach support is supposed to + be reported via qSupported. But it doesn't hurt to be pedantic here. + + Change-Id: I99cce6fa678f2370571e6bca0657451300956127 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "attach" failure handling with GDBserver + This fixes the same issue as the previous patch, but for "attach" + instead of "run". + + If attaching to a process with "attach" (vAttach packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + Here's an example: + + On the GDB side: + + ... + (gdb) tar extended-remote :9999 + ... + Remote debugging using :9999 + (gdb) attach 1 + Attaching to process 1 + Attaching to process 1 failed + (gdb) + + On the GDBserver side: + + $ gdbserver --once --multi :9999 + Listening on port 9999 + Remote debugging from host 127.0.0.1, port 37464 + gdbserver: Cannot attach to process 1: Operation not permitted (1) + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vAttach, and continue + connected to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_attach. + + Note we now let pid == 0 pass down to attach_inferior. That is so we + get a useful textual error message to report to GDB. + + This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought + it would be useful to add a new testcase specifically for this + scenario, in case gdb.base/attach.exp is ever split and stops trying + to attach again after a failed attach, with the same GDB session. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + + Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Improve vRun error reporting + After the previous commit, if starting the inferior process with "run" + (vRun packet) fails, GDBserver reports an error using the "E." textual + error packet. On the GDB side, however, GDB doesn't yet do anything + with the textual error string. This commit improves that. + + This makes remote debugging output the same as native output, when + possible, another small step in the "local/remote parity" project. + + E.g., before, against GNU/Linux GDBserver: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + + After, against GNU/Linux GDBserver (same as native): + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + During startup program exited with code 126. + + To know whether we have a textual error message, extend packet_result + to carry that information. While at it, convert packet_result to use + factory methods, and change its std::string parameter to a plain const + char *, as that it always what we have handy to pass to it. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "run" failure handling with GDBserver + If starting the inferior process with "run" (vRun packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + E.g., with the testcase program added by this commit, we see: + + On GDB side: + + ... + (gdb) tar extended-remote :999 + ... + Remote debugging using :9999 + (gdb) r + Starting program: + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + (gdb) + + On GDBserver side: + + $ gdbserver --once --multi :9999 + Remote debugging from host 127.0.0.1, port 34344 + bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied + bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied + gdbserver: During startup program exited with code 126. + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vCont, and continue connected + to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_run. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Windows: Fix run/attach hang after bad run/attach + On Cygwin, gdb.base/attach.exp exposes that an "attach" after a + previously failed "attach" hangs: + + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited + attach 0 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited + attach 10644 + FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout) + + The problem is that windows_nat_target::attach always returns success + even if the attach fails. When we return success, the helper thread + begins waiting for events (which will never come), and thus the next + attach deadlocks on the do_synchronously call within + windows_nat_target::attach. + + "run" has the same problem, which is exposed by the new + gdb.base/run-fail-twice.exp testcase added in a following patch: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.) + (gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1 + run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout) + + The problem here is the same, except that this time it is + windows_nat_target::create_inferior that returns the incorrect result. + + This commit fixes both the "attach" and "run" paths, and the latter + both the Cygwin and MinGW paths. The tests mentioned above now pass + on Cygwin. Confirmed the fixes manually for MinGW GDB. + + Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Document "E.MESSAGE" RSP errors + For many years, GDB has accepted a "E.MESSAGE" error reponse, in + addition to "E NN". For many packets, GDB strips the "E." before + giving the error message to the user. For others, GDB does not strip + the "E.", but still understands that it is an error, as it starts with + "E", and either prints the whole string, or ignores it and just + mentions an error occured (same as for "E NN"). + + This has been the case for as long as I remember. Now that I check, I + see that it's been there since 2006 (commit a76d924dffcb, also here: + https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html). + All along, I actually thought it was documented. Turns out it wasn't. + + This commit documents it, in the new "Standard Replies" section, near + where we document "E NN". + + The original version of this 3-patch documentation series was a single + CodeSourcery patch that documented the textual error as + "E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded. But I + think the ship has sailed for that. GDBserver has been sending error + messages with more than one "." for a long while, and with no binary + encoding. Still, I've preserved the "Co-Authored-By" list of the + original larger patch. + + The 'qRcmd' and 'm' commands are exceptions and do not accept this + reply format. The top of the "Standard Replies" section already says: + + "All commands support these, except as noted in the individual + command descriptions." + + So this adds a note to the description of 'qRcmd' and 'm', explicitly + stating that they do not support this error reply format. + + Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Centralize documentation of error and empty RSP responses + Currently, for each packet, we document the "E NN" response (error), + and the empty response (unsupported). This patch centralizes that in + a new "Standard Replies" section. + + In the "Packets", "General Query Packets", "Tracepoint Packets" + sections, Remove explicit mention of empty and error replies, except + when they provide detail not covered in Standard Replies. + + Note this hunk: + + -@item E @var{NN} + -@var{NN} is errno + + and this one: + + -@item E00 + -The request was malformed, or @var{annex} was invalid. + - + -@item E @var{nn} + -The offset was invalid, or there was an error encountered reading the data. + -The @var{nn} part is a hex-encoded @code{errno} value. + + were really documenting things that don't really work that way. + + The first is the documentation of the "m" packet. GDB does _not_ + interpret the NN as an errno. It can't, in fact, because the + remote/target errno numbers have nothing to do with GDB/host errno + numbers in a cross debugging scenario. + + The second hunk above is from the documentation of qXfer. Again, GDB + does not give any interpretation to the NN error code at all. Nor + does GDBserver. And again, an errno number can't be interpreted in a + cross debugging scenario. + + Change-Id: I973695c80809cdb5a5e8d5be8b78ba4d1ecdb513 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Document conventions for describing packet syntax + This comment documents conventions for describing packet syntax in the + Overview section. + + Change-Id: I96198592601b24c983da563d143666137e4d0a4e + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Bernd Edlinger + + Remove unnecessary get_current_frame calls from infrun.c + Since the frame variable is now a frame_info_ptr, the issue + with the dangling frame pointer is apparently no longer there. + + So remove the re-fetch code and the corresponding meanwhile + misleading comments. + + Approved-By: Tom Tromey + +2024-04-26 Andrew Burgess + + gdb: Add a SECURITY.txt document for GDB + This commit adds a SECURITY document to GDB. The idea behind this + document is to define what security expectations a user can reasonably + have when using GDB. In addition the document specifies which bugs + GDB developers consider a security bug, and which are just "normal" + bugs. + + Discussion for the creation of this initial version can be found here: + + https://inbox.sourceware.org/gdb-patches/877cmvui64.fsf@redhat.com/ + + Like any part of GDB, this is not intended as the absolute final + version, instead this is a living document, and this is just a + reasonable starting point from which we can iterate. + + For now I've added this document as a text file but I am considering + merging this document into the manual at a later date, and having the + SECURITY.txt file just say "Read the manual" + + Approved-By: Tom Tromey + +2024-04-26 Sébastien Michelland + + gdb: specify sh pointer register types + This patch fixes a pretty funny issue on sh targets that occurred + because $pc (and similar registers) were typed as int. When $pc is in + the upper half of the address space (i.e. kernel code on sh), `x/i $pc' + would resolve to a negative value. At least in the case of a remote + target with an Xfer memory map, this leads to a spurious "cannot access + memory" error as negative addresses are out of bounds. + + (gdb) x/i $pc + 0x8c202c04: Cannot access memory at address 0x8c202c04 + (gdb) x/i 0x8c202c04 + => 0x8c202c04 : mov.l @r1,r10 + + The issue is fixed by specifying pointer types for pc and other pointer + registers. Code pointer registers on sh include pc, pr (return address + of a call), vbr (interrupt handler) and spc (return address after + interrupt). Data pointers include r15 (stack pointer) and gbr (base + register for a few specific addressing modes). + + Change-Id: I043a058f7cbc6494f380dc0461616a9f3e0d87e0 + Approved-By: Simon Marchi + +2024-04-26 Jan Beulich + + objcopy: check input flavor before setting PE/COFF section alignment + coff_section_data() and elf_section_data() use the same underlying + field. The pointer being non-NULL therefore isn't sufficient to know + that pei_section_data() can validly be used on the incoming object. + Apparently in 64-bit-host builds the resulting memory corruption is + benign, whereas in 32-bit-host builds a segmentation fault occurs upon + de-referencing pei_section_data()'s return value. + +2024-04-26 GDB Administrator + + Automatic date update in version.in + +2024-04-25 Carl Love + + Fix end_sequence addresses for dw2-lines.exp + The patch: + + From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001 + From: Tom de Vries + Date: Wed, 17 Apr 2024 12:55:00 +0200 + Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses + + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + + + + The regression failure on PowerPC is due to the change in file + dw2-lines.exp, + + - DW_LNE_set_address bar_label_5 + + DW_LNE_set_address "$main_start + $main_len" + + The label bar_label_5 is in function bar, not function main. The new + set address should have been $bar_start + $bar_len. + +2024-04-25 David Faust + + bpf: fix calculation when deciding to relax branch + In certain cases we were calculating the jump displacement incorrectly + when deciding whether to relax a branch. This meant for some branches, + such as a very long backwards conditional branch, relaxation was not + done when it should have been. The result was to error later, because + the actual jump displacement was too large to fit in the original + instruction. + + This patch fixes up the displacement calculation so that those branches + are correctly relaxed and no longer result in an error. In addition, it + changes md_convert_frag to install fixups for the JAL instructions in + the resulting relaxations rather than encoding the displacement value + directly. + + gas/ + * config/tc-bpf.c (relaxed_branch_length): Correct displacement + calculation when relaxing. + (md_convert_frag): Likewise. Install fixups for JAL + instructions resulting from relaxation. + * testsuite/gas/bpf/jump-relax-ja-be.d: Correct and expand test. + * testsuite/gas/bpf/jump-relax-ja.d: Likewise. + * testsuite/gas/bpf/jump-relax-ja.s: Likewise. + * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.s: Likewise. + +2024-04-25 Simon Marchi + + gdb: add type annotations to ada-unicode.py + Add type annotations to ada-unicode.py, just enough to make pyright + happy: + + $ pyright --version + pyright 1.1.359 + $ pyright ada-unicode.py + 0 errors, 0 warnings, 0 informations + + Introduce a `Range` class instead of using separate variables and + tuples, to make the code and type annotations a bit cleaner. + + When running ada-unicode.py, I get a diff for ada-casefold.h, but I get + the same diff before and after this patch, so that is a separate issue. + + Change-Id: I0d8975a57f9fb115703178ae197dc6b6b8b4eb7a + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove gdbcmd.h + Most files including gdbcmd.h currently rely on it to access things + actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make + things easy, replace all includes of gdbcmd.h with includes of + cli/cli-cmds.h. This might lead to some unused includes of + cli/cli-cmds.h, but it's harmless, and much faster than going through + the 170 or so files by hand. + + Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move style_set_list/style_show_list declarations to cli/cli-style.h + They are defined in cli/cli-style.c. + + Change-Id: Ic478a3985ff0fd773bd7ba85bb144c6e914d0be6 + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove unused print_command_line and print_command_lines declarations + There is no corresponding definition for print_command_line. + + There is already a declaration for print_command_lines in + cli/cli-script.h (the implementation is in cli/cli-script.c). + + Change-Id: Ic9e67ed04703306d614383ead14e2b2b059b2a8e + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move execute function declarations from gdbcmd.h to top.h + These functions are implemented in top.c, move their declarations to + top.h. + + Change-Id: I8893ef91d955156a6530734fefe8002d78c3e5fc + Approved-By: Tom Tromey + +2024-04-25 Jinyang He + + LoongArch: gas: Simplify relocations in sections without code flag + Gas should not emit ADD/SUB relocation pairs for label differences + if they are in the same section without code flag even relax enabled. + Because the real value is not be affected by relaxation and it can be + compute out in assembly stage. Thus, correct the `TC_FORCE_RELOCATION + _SUB_SAME` and the label differences in same section without code + flag can be resolved in fixup_segment(). + +2024-04-25 Lulu Cai + + LoongArch: Add bad static relocation check and output more information to user + Absolute address symbols cannot be used with -shared. + We output more information to the user than just BFD_ASSETR. + + LoongArch: The symbol got type can only be obtained after initialization + When scanning relocations and determining whether TLS type transition is + possible, it will try to obtain the symbol got type. If the symbol got + type record has not yet been allocated space and initialized, it will + cause ld to crash. So when uninitialized, the symbol is set to GOT_UNKNOWN. + +2024-04-25 GDB Administrator + + Automatic date update in version.in + +2024-04-24 Thiago Jung Bauermann + + gdb/testsuite: Add libc_has_debug_info require helper + Factor the test for libc debug info out of gdb.base/relativedebug.exp to + a new procedure. + + Also, change the "info sharedlibrary" test to explicitly detect when + libc has debug info. + + Approved-by: Kevin Buettner + +2024-04-24 Ciaran Woodward + + gdb/doc: Fix incorrect information in RSP doc + The 'PacketSize' attribute of the qSupported packet was + documented to be the maximum size of the packet including + the frame and checksum bytes, however this is not how it + was treated in the code. In reality, PacketSize is the + maximum size of the data in the RSP packets, not including + the framing or checksum bytes. + + For instance, GDB's remote.c treats it as the maximum + number of data bytes. See remote_read_bytes_1, where the + size of the request is capped at PacketSize/2 (for + hex-encoding). + + Also see gdbserver's server.cc, where the internal buffer + is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize. + In gdbserver's case, the buffer is not used for any of the + framing or checksum characters. (I am not certain where the -1 + comes from. I think it comes from back when there were no + binary packets, so packets were treated as strings with + null terminators). + + It also seems like gdbservers in the wild treat it in + this way: + + Embocosm doc: + https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#id3078000 + + A quick glance over openocd's gdb_server.c gdb_put_packet_inner() + function shows that the internal buffer also excludes the framing + and checksum. + + Likewise, qEmu's gdbstub.c allocates PacketSize bytes for + the internal packet contents, and PacketSize+4 for the + full frame. + + Reviewed-By: Eli Zaretskii + Approved-By: Pedro Alves + +2024-04-24 Bernd Edlinger + + Handle two-linetable function in find_epilogue_using_linetable + Consider the following test-case: + ... + $ cat hello.c + int main() + { + printf("hello "); + #include "world.inc" + $ cat world.inc + printf("world\n"); + return 0; + } + $ gcc -g hello.c + ... + + The line table for the compilation unit, consisting just of + function main, is translated into these two gdb line tables, one for hello.c + and one for world.inc: + ... + compunit_symtab: hello.c + symtab: hello.c + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 3 0x400557 0x400557 Y + 1 4 0x40055b 0x40055b Y + 2 END 0x40056a 0x40056a Y + + compunit_symtab: hello.c + symtab: world.inc + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 1 0x40056a 0x40056a Y + 1 2 0x400574 0x400574 Y + 2 3 0x400579 0x400579 Y + 3 END 0x40057b 0x40057b Y + ... + + The epilogue of main starts at 0x400579: + ... + 400579: 5d pop %rbp + 40057a: c3 ret + ... + + Now, say we have an epilogue_begin marker in the line table at 0x400579. + + We won't find it using find_epilogue_using_linetable, because it does: + ... + const struct symtab_and_line sal = find_pc_line (start_pc, 0); + ... + which gets us the line table for hello.c. + + Fix this by using "find_pc_line (end_pc - 1, 0)" instead. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + PR symtab/31622 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622 + +2024-04-24 Bernd Edlinger + + Fix an out of bounds array access in find_epilogue_using_linetable + An out of bounds array access in find_epilogue_using_linetable causes random + test failures like these: + + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $fn_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: check frame-id matches + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: bt 2 + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: up + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $sp_value == $::main_sp + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $::main_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: [string equal $fid $::main_fid] + + Here the read happens below the first element of the line + table, and the test failure depends on the value that is + read from there. + + It also happens that std::lower_bound returns a pointer exactly at the upper + bound of the line table, also here the read value is undefined, that happens + in this test: + + FAIL: gdb.dwarf2/dw2-epilogue-begin.exp: confirm watchpoint doesn't trigger + + Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table") + + Co-Authored-By: Tom de Vries + + PR symtab/31268 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268 + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp for remote host + With test-case gdb.threads/threadcrash.exp using host board local-remote-host + and target board remote-gdbserver-on-localhost I run into: + ... + (gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash + gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M + Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M + (gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore + UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file + ... + + The problem is that the gcore command tries to save a file on a remote host, + but the filename is a location on build. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp with glibc debuginfo + After installing glibc debuginfo, I ran into: + ... + FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \ + $thread_count == [llength $test_list] + ... + + This happens because the clause: + ... + -re "^\r\n${hs}main$hs$eol" { + ... + which is intended to match only: + ... + #1 in main () at threadcrash.c:423^M + ... + also matches "remaining" in: + ... + #1 in __GI___nanosleep (requested_time=, remaining=) at \ + nanosleep.c:27^M + ... + + Fix this by checking for "in main" instead. + + Tested on x86_64-linux. + +2024-04-24 Nick Clifton + + Update readelf's display of RELR sections to include the number of locations relocated + +2024-04-24 Simon Marchi + + gdb: include extract-store-integer.h in charset.c when PHONY_ICONV + When building on a system where "phony iconv" is used (NetBSD in this + case, not sure why), I get: + + CXX charset.o + /home/smarchi/src/binutils-gdb/gdb/charset.c: In function 'size_t phony_iconv(int, const char**, size_t*, char**, size_t*)': + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: error: 'extract_unsigned_integer' was not declared in this scope + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: note: suggested alternative: 'btrace_insn_number' + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + btrace_insn_number + + Add the necessary include. + + Change-Id: I10b967584645961c86167a8395d88929a42bef03 + +2024-04-24 Alan Modra + + PPC maintainers + I'm retiring from IBM, and Geoff hasn't been active for a very long + time. + + * MAINTAINERS (ppc): Remove myself and Geoff Keating. Add + Geoff to past maintainers. + +2024-04-24 Alan Modra + + buffer overflow in libctf tests + * testsuite/libctf-regression/gzrewrite.c (main): Don't overflow + "a" buffer in "after adding types" check. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-24 GDB Administrator + + Automatic date update in version.in + +2024-04-23 Simon Marchi + + gdb: adjust copyright years of extract-store-integer.{c,h} + The contents of these files was copied from defs.h and findvar. Copy + over the copyright years (1986-2024). + + Change-Id: Idfb0f255fbcfda7e107e9a82804cece3d81ed5fc + +2024-04-23 Claudio Bantaloukas + + arm: Fix MVE vmla encoding + +2024-04-23 Olivier Hainque + + bfd: Remove duplicate word in elf-vxworks.c + PR ld/31652 + * elf-vxworks.c (elf_vxworks_emit_relocs): Drop duplicate word. + +2024-04-23 H.J. Lu + + objcopy.c: Fix bfd_copy_private_symbol_data on 32-bit hosts + Use long with bfd_copy_private_symbol_data to fix + + .../binutils/objcopy.c: In + function ‘copy_object’: + .../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare] + 3383 | for (i = 0; i < symcount; i++) + | ^ + + on 32-bit hosts. + + PR binutils/14493 + * objcopy.c (copy_object): Use long with + bfd_copy_private_symbol_data. + +2024-04-23 Simon Marchi + + gdb: move symbol_file_command declaration to symfile.h + Move it out of defs.h, the corresponding definition is in symfile.c. + + Change-Id: I984666c3bcd213f8574e9ec91462e1d61f77f16b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove enum precision_type + It is unused. + + Change-Id: Ic49a3ef03c21b209594cd567ae80b5441606bef6 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move annotation_level declaration/definition to annotate.{h,c} + The declaration of annotation_level is currently in defs.h, while the + definition is in stack.c. I don't really understand why that variable + would live in stack.c, it seems completely unrelated. Move it to + annotate.c, and move the declaration to annotate.h. + + Change-Id: I6cf8e9bd20e83959bdf5ad58dd008b6e1187d7d8 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move a bunch of quit-related things to event-top.{c,h} + Move some declarations related to the "quit" machinery from defs.h to + event-top.h. Most of the definitions associated to these declarations + are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, + that are defined in utils.c. For consistency, move these two + definitions to event-top.c. + + Include "event-top.h" in many files that use these things. + + Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change type of quit_flag to bool + Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change return type of check_quit_flag to bool + Change the return type of the check_quit_flag function to bool. Update + a few related spots. + + Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move declarations of check_quit_flag and set_quit_flag to extension.h + Move them out of defs.h, to extension.h, since the implementations are + in extension.c. + + Change-Id: Ie7321468bd7fecc684d70b09f72c3ee8ac75d8f4 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove unused include in infrun.c + Remove the gdbcmd.h, which is reported as unused by clangd. Add + cli/cli-cmds.h instead, to get access to `cmdlist` and friends. + + Change-Id: Ic0c60d2f6d3618f1bd9fd80b95ffd7c33c692a04 + +2024-04-23 Waqar Hameed + + objdump: Round ASCII art lines in jump visualization + +2024-04-23 Simon Marchi + + gdb/dwarf2/read.c: remove pessimizing std::move + When building with this clang: + + $ c++ --version + FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) + + I see: + + $ gmake + CXX dwarf2/read.o + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] + std::move (thread_storage.release_parent_map ())); + ^ + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: note: remove std::move call here + std::move (thread_storage.release_parent_map ())); + ^~~~~~~~~~~ ~ + + The compiler seems right, there is not need to std::move the result of + `release_parent_map ()`, it's already going to be an rvalue. Remove the + std::move. + + The issue isn't FreeBSD-specific, I see it on Linux as well when + building hwith clang, I just noticed it on a FreeBSD build first. + + Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: bump black version to 24.4.0 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I977781fa6cc924c398cc3b9d9954dc0fbb95d082 + +2024-04-23 Alan Modra + + PR31667, objcopy/strip corrupts solaris binaries + Using want_p_paddr_set_to_zero in commit 45d92439aebd was wrong. Even + solaris targets don't have want_p_paddr_set_to_zero, but we should + handle them at least somewhat reasonably. + + PR 31667 + * elf.c (IS_SECTION_IN_INPUT_SEGMENT): Remove bed arg, add + paddr_valid. Don't use bed->want_p_paddr_set_to_zero. + (INCLUDE_SECTION_IN_SEGMENT): Likewise. + (rewrite_elf_program_header): Adjust to suit. + +2024-04-23 Alan Modra + + ignore some symbols in elf.c:swap_out_syms + The reason behind this patch was noticing that generic ELF targets + fail to remove "bar" in the recently committed ld-elf/undefweak-1 + test. (Despite that, those targets pass the test due to it being too + strict when matching symbols. "bar" gets turned into a local weak + defined absolute symbol.) + + swap_out_syms currently drops local section syms that are defined in + discarded sections. Extend that to also drop other symbols in + discarded sections too, even global symbols. The linker goes to quite + a lot of effort to ensure globals in discarded section take a + definition from the kept linkonce or comdat group section. So the + global sym change should only affect cases where something is quite + wrong about the set of linkonce or comdat group sections. However + that change to elf_map_symbols meant we dropped _DYNAMIC_LINK / + _DYNAMIC_LINKING for mips, a global absolute symbol given STT_SECTION + type for some reason. That problem is fixed by reverting the pr14493 + change which is no longer needed due to a) BSF_SECTION_SYM_USED on + x86, and b) fixing objcopy to use copy_private_symbol_data. + + bfd/ + PR 14493 + * elf.c (ignore_sym): Rename from ignore_section_sym. Return + true for any symbol without a section or in a discarded section. + Revert pr14493 change. + (elf_map_symbols): Tidy. Use ignore_sym on all symbols. + (swap_out_syms): Tidy. + ld/ + * testsuite/ld-elf/undefweak-1.rd: Match any "bar". + +2024-04-23 Alan Modra + + xfail undefweak-1 test for alpha + ".set" has a different meaning on alpha. Changing it to ".equ" runs + into ".equ" having a different meaning on hppa, and changing it to "=" + runs into trouble on bfin. + + * testsuite/ld-elf/elf.exp (undefweak-1): xfail on alpha, + don't xfail for genelf. + +2024-04-23 Alan Modra + + use copy_private_symbol_data in objcopy + osympp appearing twice here is not a bug. + + PR 14493 + * objcopy.c (copy_object): Run the symbols through + bfd_copy_private_symbol_data. + +2024-04-23 Alan Modra + + copy_private_symbol_data + bfd_copy_private_symbol_data is a bfd function that appeared in + commit 89665c8562da a long time ago, but seemingly wasn't used + anywhere until Jan added it to gas/symbols.c in commit 6a2b6326c21e. + + The function is used to modify ELF symbol st_shndx for symbols defined + in odd sections like .symtab, so that they get the corresponding + section st_shndx in an output file. This patch fixes some bitrot in + the function. After commit c03551323c04 which introduced + output_elf_obj_tdata, elf_strtab_sec and elf_shstrtab_sec will + segfault if used on an input bfd. + + PR 14493 + * elf.c (_bfd_elf_copy_private_symbol_data): Don't use + elf_strtab_sec and elf_shstrtab_sec. + +2024-04-23 Simon Marchi + + gdb: don't include gdbsupport/array-view.h in defs.h + Nothing in defs.h actually uses this. Everything that I (and the + buildbot) can compile still compiles, so I guess that all users of + array_view already include it one way or another. Worst case, if this + causes some build failure, the fix will be one #include away. + + Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: don't include hashtab.h in defs.h + Nothing in defs.h actually uses this. + + Add some includes for some spots using things from hashtab.h. Note that + if the GDB build doesn't use libxxhash, hashtab.h is included by + gdbsupport/common-utils.h, so all files still see hashtab.h. It puzzled + me for some time why I didn't see build failures in my build (which + didn't use libxxhash) but the buildbot gave build failures (it uses + libxxhash). + + Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move RequireLongest to gdbsupport/traits.h + Move it out of defs.h. + + Change-Id: Ie1743d41a57f81667650048563e66073c72230cf + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move store/extract integer functions to extract-store-integer.{c,h} + Move the declarations out of defs.h, and the implementations out of + findvar.c. + + I opted for a new file, because this functionality of converting + integers to bytes and vice-versa seems a bit to generic to live in + findvar.c. + + Change-Id: I524858fca33901ee2150c582bac16042148d2251 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: remove extract_long_unsigned_integer + It is unused. + + Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move `enum compile_i_scope_types` to compile/compile.h + Move it out of defs.h, adjust the includes here and there. + + Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move two declarations out of defs.h + Move declarations of initialize_progspace and initialize_inferiors to + progspace.h and inferior.h, respectively. + + Change-Id: I62292ffda429861b9f27d8c836a56d161dfa548d + Approved-By: John Baldwin + +2024-04-23 GDB Administrator + + Automatic date update in version.in + +2024-04-22 Thiago Jung Bauermann + + gdb/testsuite: Use default gdb_expect timeout in runto + runto uses a hard-coded timeout of 30s in its invocation of gdb_expect. + This is normally fine, but for very a slow system (e.g., an emulator) it + may not be enough time for GDB to reach the intended breakpoint. + + gdb_expect can obtain a timeout value from user-configurable variables + when it's not given one explicitly, so use that mechanism instead since + the user will have already adjusted the timeout variable to account for + the slow system. + + Approved-By: Tom Tromey + +2024-04-22 Andrew Burgess + + gdb: fix unknown variable typo in c-exp.y + Fix 'val' -> 'value' typo in c-exp.y which was breaking the build. + Introduced in commit: + + commit e6375bc8ebbbc177c79f08e9616eb0b131229f65 + Date: Wed Apr 17 16:17:33 2024 -0600 + + Remove some alloca uses + +2024-04-22 Victor Do Nascimento + + aarch64: Fix coding style issue in `aarch64-dis.c' + Fix integer value being returned from boolean function, as introduced + in `aarch64: Remove asserts from operand qualifier decoders [PR31595]'. + +2024-04-22 Tom Tromey + + Use std::vector in event-loop.cc + In my occasional and continuing campaign against realloc, this patch + changes event-loop.cc to use std::vector to keep track of pollfd + objects. Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + Approved-By: John Baldwin + +2024-04-22 Cui, Lili + + x86/APX: Add invalid check for APX EVEX.X4. + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Added invalid check for APX + X4. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added invalid + testcase. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (get_valid_dis386): Added invalid check for APX X4. + +2024-04-22 GDB Administrator + + Automatic date update in version.in + +2024-04-21 Tom Tromey + + Remove a couple of VLAs + I found a couple of spots where VLAs are in use but where they can + easily be removed. + + In one spot, adding 'const' is enough -- and is already done in + similar code elsewhere in the file. + + In another spot, one of two arrays will be used, so making the buffer + large enough for both works. + + Approved-By: John Baldwin + +2024-04-21 Tom Tromey + + Remove some alloca uses + A few spots (mostly in the parsers) use alloca to ensure that a string + is terminated before passing it to a printf-like function (mostly + 'error'). However, this isn't needed as the "%.*s" format can be used + instead. + + This patch makes this change. + + In one spot the alloca is dead code and is simply removed. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-04-21 GDB Administrator + + Automatic date update in version.in + +2024-04-20 mengqinggang + + LoongArch: Add -mignore-start-align option + Ignore .align at the start of a section may result in misalignment when + partial linking. Manually add -mignore-start-align option without partial + linking. + + Gcc -falign-functions add .align 5 to the start of a section, it causes some + error message mismatch. Set these testcases to xfail on LoongArch target. + +2024-04-20 Alan Modra + + Error compiling libctf-regression test + Seen on 64-bit targets. + ERROR: compilation of lookup program .../libctf-regression/gzrewrite.c failed + + * testsuite/libctf-regression/gzrewrite.c (main): Use %zu to + print size_t values. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-20 GDB Administrator + + Automatic date update in version.in + +2024-04-19 Simon Marchi + + gdb: add target_debug_printf and target_debug_printf_nofunc + Add the `target_debug_printf` and `target_debug_printf_nofunc` macros + and use them when outputting debug messages depending on `targetdebug`. + I opted for `target_debug_printf_nofunc` to follow the current style + where the function name is already printed, along with the arguments. + + Modify the debug printfs in the `debug_target` methods (generated by + `make-target-delegates.py`) to use `target_debug_printf_nofunc` as well. + + This makes the "target" debug prints integrate nicely with the other + debug prints that use the "new" debug print system: + + [infrun] proceed: enter + [infrun] follow_fork: enter + [target] -> multi-thread->record_will_replay (...) + [target] <- multi-thread->record_will_replay (-1, 0) = false + [target] -> multi-thread->supports_multi_process (...) + [target] <- multi-thread->supports_multi_process () = true + [infrun] follow_fork: exit + ... + + Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make regcache::debug_print_register return a string + Rename the method to `register_debug_string`. + + This makes it easier to introduce `target_debug_printf` in a subsequent + patch. + + Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make debug_target use one-liners + Turn the debug prints in debug_target's method to be one liners. For + instance, change this: + + gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ()); + gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog); + gdb_puts (") = ", gdb_stdlog); + target_debug_print_ptid_t (result); + gdb_puts ("\n", gdb_stdlog); + + into this: + + gdb_printf (gdb_stdlog, + "<- %s->wait (%s, %s, %s) = %s\n", + this->beneath ()->shortname (), + target_debug_print_ptid_t (arg0).c_str (), + target_debug_print_target_waitstatus_p (arg1).c_str (), + target_debug_print_target_wait_flags (arg2).c_str (), + target_debug_print_ptid_t (result).c_str ()); + + This makes it possible for a subsequent patch to turn this gdb_printf + call into a `target_debug_printf` call. + + Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make target debug functions return std::string + Change the functions in target-debug.h to return string representations + in an std::string, such that they don't need to know how the printing + part is done. This also helps the following patch that makes the debug + prints in debug_target one-liners. + + Update target-delegates.c (through make-target-delegates.py) to do the + printing. + + Add an overload of gdb_puts to avoid using `.c_str ()`. + + Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: fix include for gdb_signal in target/waitstatus.h + clangd tells me that the gdb_signals.h include in target/waitstatus.h is + unused. This include was probably to give access to `enum gdb_signal`, + but this is in fact defined in gdb/signals.h. Change the include to + gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were + relying on the transitive include. + + Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6 + +2024-04-19 Simon Marchi + + gdb: convert target debug macros to functions + Convert all the macros to static functions. Some macros were unused, + and now that they are functions, got flagged by the compiler, so I + omitted them. + + No behavior change expected. + + Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: add includes in target-debug.h + Editing target-debug.h with clangd shows a bunch of errors. Add some + includes to fix that (make target-debug.h include what it uses). + + Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376 + +2024-04-19 Nick Alcock + + libctf: do not include undefined functions in libctf.ver + libctf's version script is applied to two libraries: libctf.so, + and libctf-nobfd.so. The latter library is a subset of the former + which does not link to libbfd and does not include a few public + entry points that use it (found in libctf-open-bfd.c). This means + that some of the symbols in this version script only exist in one + of the libraries it's applied to. + + A number of linkers dislike this: before now, only Solaris's linker + caused serious problems, introducing NOTYPE-typed symbols when such + things were found, but now LLD has started to complain as well: + + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined + + Rather than adding more and more whack-a-mole fixes for every + linker we encounter that does this, simply exclude such symbols + unconditionally, using the same trick we used to use for Solaris. + (Well, unconditionally if we can use version scripts with this + linker at all, which is not always the case.) + + Thanks to Nicholas Vinson for the original report and a fix very + similar to this one (but not quite identical). + + libctf/ + + * configure.ac: Always exclude libctf symbols from + libctf-nobfd's version script. + * configure: Regenerated. + +2024-04-19 Nicholas Vinson + + libctf: Remove undefined functions from ver. map + Starting with ld.lld-17, ld.lld is invoked with the option + --no-undefined-version enabled by default. Furthermore, The functions + ctf_label_set() and ctf_label_get() are not defined. Their inclusion in + libctf/libctf.ver causes ld.lld-17 to fail emitting the following error + messages: + + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined + + This patch fixes the issue by removing the symbol names from + libctf/libctf.ver. + + [nca: fused in later commit that marked ctf_arc_open as libctf + only as well. Added ChangeLog entry.] + + + libctf/ + * libctf.ver: drop nonexistent label functions: mark + ctf_arc_open as libctf-only. + +2024-04-19 Nick Alcock + + libctf: don't pass errno into ctf_err_warn so often + The libctf-internal warning function ctf_err_warn() can be passed a libctf + errno as a parameter, and will add its textual errmsg form to the passed-in + error message. But if there is an error on the fp already, and this is + specifically an error and not a warning, ctf_err_warn() will print the error + out regardless: there's no need to pass in anything but 0. + + There are still a lot of places where we do + + ctf_err_warn (fp, 0, EFOO, ...); + return ctf_set_errno (fp, 0, EFOO); + + I've left all of those alone, because fixing it makes the code a bit longer: + but fixing the cases where no return is involved and the error has just been + set on the fp itself costs nothing and reduces redundancy a bit. + + libctf/ + + * ctf-dedup.c (ctf_dedup_walk_output_mapping): Drop the errno arg. + (ctf_dedup_emit): Likewise. + (ctf_dedup_type_mapping): Likewise. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_close_inputs): Likewise. + (ctf_link_deduplicating_one_symtypetab): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + * ctf-lookup.c (ctf_lookup_symbol_idx): Likewise. + * ctf-subr.c (ctf_assert_fail_internal): Likewise. + +2024-04-19 Nick Alcock + + libctf: fix leak in test + This purely serves to make it easier to interpret valgrind output. + No functional effect. + + libctf/ + * testsuite/libctf-lookup/conflicting-type-syms.c: Free everything. + +2024-04-19 Nick Alcock + + libctf: add rewriting tests + Now there's a chance of it actually working, we can add more tests for + the long-broken dict read-and-rewrite cases. This is the first ever + test for the (rarely-used, unpleasant, and until recently completely + broken) ctf_gzwrite function. + + libctf/ + + * testsuite/libctf-regression/gzrewrite*: New test. + * testsuite/libctf-regression/zrewrite*: Likewise. + +2024-04-19 Nick Alcock + + libctf: fix a debugging typo + libctf/ + + * ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo. + +2024-04-19 Nick Alcock + + libctf: make ctf_lookup of symbols by name work in more cases + In particular, we don't need a symbol table if we're looking up a + symbol by name and that type of symbol has an indexed symtypetab, + since in that case we get the name from the symtypetab index, not + from the symbol table. + + This lets you do symbol lookups in unlinked object files and unlinked + dicts written out via libctf's writeout functions. + + libctf/ + + * ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups + by index even when there is no symtab. + +2024-04-19 Nick Alcock + + libctf: improve handling of type dumping errors + When dumping a type fails with an error, we want to emit a warning noting + this: a warning because it's not fatal and we can continue. But warnings + don't automatically print out the ctf_errno (because not all cases causing + warnings set the errno at all), so we must do it at warning-emission time or + lose track of what's gone wrong. + + libctf/ + + * ctf-dump.c (ctf_dump_format_type): Dump the underlying error on + type dump failure. + +2024-04-19 Nick Alcock + + libctf: fix tiny dumping error + Without this, you might get things like this in the output: + + Flags: 0xa (CTF_F_NEWFUNCINFO, , CTF_F_DYNSTR) + + Note the spurious comma. + + libctf/ + * ctf-dump.c (ctf_dump_header): Fix comma emission. + +2024-04-19 Nick Alcock + + libctf: make ctf_serialize() actually serialize + ctf_serialize() evolved from the old ctf_update(), which mutated the + in-memory CTF dict to make all the dynamic in-memory types into static, + unchanging written-to-the-dict types (by deserializing and reserializing + it): back in the days when you could only do type lookups on static types, + this meant you could see all the types you added recently, at the small, + small cost of making it impossible to change those older types ever again + and inducing an amortized O(n^2) cost if you actually wanted to add + references to types you added at arbitrary times to later types. + + It also reset things so that ctf_discard() would throw away only types you + added after the most recent ctf_update() call. + + Some time ago this was all changed so that you could look up dynamic types + just as easily as static types: ctf_update() changed so that only its + visible side-effect of affecting ctf_discard() remained: the old + ctf_update() was renamed to ctf_serialize(), made internal to libctf, and + called from the various functions that wrote files out. + + ... but it was still working by serializing and deserializing the entire + dict, swapping out its guts with the newly-serialized copy in an invasive + and horrible fashion that coupled ctf_serialize() to almost every field in + the ctf_dict_t. This is totally useless, and fixing it is easy: just rip + all that code out and have ctf_serialize return a serialized representation, + and let everything use that directly. This simplifies most of its callers + significantly. + + (It also points up another bug: ctf_gzwrite() failed to call ctf_serialize() + at all, so it would only ever work for a dict you just ctf_write_mem()ed + yourself, just for its invisible side-effect of serializing the dict!) + + This lets us simplify away a bunch of internal-only open-side functionality + for overriding the syn_ext_strtab and some just-added functionality for + forcing in an existing atoms table, without loss of functionality, and lets + us lift the restriction on reserializing a dict that was ctf_open()ed rather + than being ctf_create()d: it's now perfectly OK to open a dict, modify it + (except for adding members to existing structs, unions, or enums, which + fails with -ECTF_RDONLY), and write it out again, just as one would expect. + + libctf/ + + * ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos. + (ctf_type_sect_size): Add static type sizes too. + (ctf_serialize): Return the new dict rather than updating the + existing dict. No longer fail for dicts with static types; + copy them onto the start of the new types table. + (ctf_gzwrite): Actually serialize before gzwriting. + (ctf_write_mem): Improve forced (test-mode) endian-flipping: + flip dicts even if they are too small to be compressed. + Improve confusing variable naming. + * ctf-archive.c (arc_write_one_ctf): Don't bother to call + ctf_serialize: both the functions we call do so. + * ctf-string.c (ctf_str_create_atoms): Drop serializing case + (atoms arg). + * ctf-open.c (ctf_simple_open): Call ctf_bufopen directly. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Delete/rename to ctf_bufopen: no + longer bother with syn_ext_strtab or forced atoms table, + serialization no longer needs them. + * ctf-create.c (ctf_create): Call ctf_bufopen directly. + * ctf-impl.h (ctf_str_create_atoms): Drop atoms arg. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Likewise. + (ctf_serialize): Adjust. + * testsuite/libctf-lookup/add-to-opened.c: Adjust now that + this is supposed to work. + +2024-04-19 Nick Alcock + + libctf: rethink strtab writeout + This commit finally adjusts strtab writeout so that repeated writeouts, or + writeouts of a dict that was read in earlier, only sorts the portion of the + strtab that was newly added. + + There are three intertwined changes here: + + - pull the contents of strtabs from newly ctf_bufopened dicts into the + atoms table, so that future additions will reuse the existing offset etc + rather than adding new identical strings + - allow the internal ctf_bufopen done by serialization to contribute its + existing atoms table, so that existing atoms can be used for the + remainder of the open process (like name table construction): this atoms + table currente gets thrown away in the mass reassignment done later in + ctf_serialize in any case, but it needs to be there during the open. + - rewrite ctf_str_write_strtab so that a) it uses iterators rather than + ctf_*_iter, reducing pointless structures which serve no other purpose + than to implement ordinary variable scope, but more clunkily, and b) + retains the existing strtab on the front of the new one, with its sort + retained, rather than resorting, so all existing already-written strtab + offsets remain valid across the call. + + This latter change finally permits repeated serializations, and + reserializations of ctf_open()ed dicts, to work, but for now we keep the + code that prevents that because serialization is about to change again in a + way that will make it more obvious that doing such things is safe, and we + can take it out then. + + (There are also some smaller changes like moving the purge of the refs table + into ctf_str_write_strtab(), since that's where the changes happen that + invalidate it, rather than doing it in ctf_serialize(). We also prohibit + something that has never worked, opening a dict and then reporting symbols + to it via ctf_link_add_strtab() et al: you must do that to newly-created + dicts which have had stuff ctf_link()ed into them. This is very unlikely + ever to be a problem in practice: linkers just don't do that sort of thing.) + + libctf/ + + * ctf-create.c (ctf_create): Add (temporary) atoms arg. + * ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New. + (ctf_str_create_atoms): Adjust. + (ctf_str_write_strtab): Likewise. + (ctf_simple_open_internal): Likewise. + * ctf-open.c (ctf_simple_open_internal): Add atoms arg. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Initialize just enough of an + atoms table: pre-init from the atoms arg if supplied. + (ctf_simple_open): Adjust. + * ctf-serialize.c (ctf_serialize): Constify the strtab. + Move ref list purging into ctf_str_write_strtab. + Initialize the new dict with the old dict's atoms table. + Accept the new strtab from ctf_str_write_strtab. + Adjust for addition of ctf_dynstrtab. + * ctf-string.c (ctf_strraw_explicit): Improve comments. + (ctf_str_create_atoms): Prepopulate from an existing atoms table, + or alternatively pull in all strings from the strtab and turn + them into atoms. + (ctf_str_free_atoms): Free the dynstrtab and its strtab. + (struct ctf_strtab_write_state): Remove. + (ctf_str_count_strtab): Fold this... + (ctf_str_populate_sorttab): ... and this... + (ctf_str_write_strtab): ... into this. Prepend existing strings + to the strtab rather than resorting them (and wrecking their + offsets). Keep the dynstrtab updated. Update refs for all + atoms with refs, whether or not they are strings newly added + to the strtab. + +2024-04-19 Nick Alcock + + libctf: replace 'pending refs' abstraction + A few years ago we introduced a 'pending refs' abstraction to fix one + problem: serializing a dict, then changing it would tend to corrupt the dict + because the strtab sort we do on strtab writeout (to improve compression + efficiency) would modify the offset of any strings that sorted + lexicographically earlier in the strtab: so we added a new restriction that + all strings are added only at serialization time, and maintained a set of + 'pending' refs that were added earlier, whose offsets we could update (like + other refs) at writeout time. + + This was in hindsight seriously problematic for maintenance (because + serialization has to traverse all strings in all datatypes in the entire + dict), and has become impossible to sustain now that we can read in existing + dicts, modify them, and reserialize them again. We really don't want to + have to dig through the entire dict we jut read in just in order to dig out + all its strtab offsets, then *change* it, just for the sake of a sort that + adds a frankly trivial amount of compression efficiency. + + Sorting *is* still worthwhile -- but it sacrifices very little to only sort + newly-added portions of the strtab, reusing older portions as necessary. + As a first stage in this, discard the whole "pending refs" abstraction and + replace it with "movable" refs, which are exactly like all other refs + (addresses containing the strtab offset of some string, which are updated + wiht the final strtab offset on serialization) except that we track them in + a reverse dict so that we can move the refs around (which we do whenever we + realloc() a buffer containing a bunch of structure members or something when + we add members to the structure). + + libctf/ + + * ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add + a movable ref. + (ctf_add_member_offset): Likewise. + * ctf-util.c (ctf_realloc): Delete. + * ctf-serialize.c (ctf_serialize): No longer use it. Adjust to + new fields. + * ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs. + (ctf_str_free_atom): Free freeable atoms' strings. + (ctf_str_create_atoms): Create the movable refs dynhash if needed. + (ctf_str_free_atoms): Destroy it. + (CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous + reversion). Add new flag. + (aref_create): New, populate movable refs if need be. + (ctf_str_add_ref_internal): Switch back to flags, update refs + directly for nonprovisional strings (with already-known fixed offsets); + create refs via aref_create. Allocate strings only if not within an + mmapped strtab. + (ctf_str_add_movable_ref): New. + (ctf_str_add): Adjust to CTF_STR_* reintroduction. + (ctf_str_add_external): LIkewise. + (ctf_str_move_refs): New, move refs via ctf_str_movable_refs + backpointer. + (ctf_str_purge_refs): Drop ctf_str_num_refs. + (ctf_str_update_refs): Fix indentation. + * ctf-impl.h (struct ctf_str_atom_movable): New. + (struct ctf_dict.ctf_str_num_refs): Drop. + (struct ctf_dict.ctf_str_movable_refs): New. + (ctf_str_add_movable_ref): Declare. + (ctf_str_move_refs): Likewise. + (ctf_realloc): Drop. + +2024-04-19 Nick Alcock + + Revert "libctf: do not corrupt strings across ctf_serialize" + This reverts commit 986e9e3aa03f854bedacef7fac38fe8f009a416c. + + (We do not revert the testcase -- it remains valid -- but we are + taking a different, less complex and more robust approach.) + + This also deletes the pending refs abstraction without (yet) + replacing it, so some tests will fail for a commit or two. + +2024-04-19 Nick Alcock + + libctf: rename ctf_dict.ctf_{symtab,strtab} + These two fields are constantly confusing because CTF dicts contain both + a symtypetab and strtab, but these fields are not that: they are the + symtab and strtab from the ELF file. We have enough string tables now + (internal, external, synthetic external, dynamic) that we need to at + least name them better than this to avoid getting totally confused. + Rename them to ctf_ext_symtab and ctf_ext_strtab. + + libctf/ + + * ctf-dump.c (ctf_dump_objts): Rename ctf_symtab -> ctf_ext_symtab. + * ctf-impl.h (struct ctf_dict.ctf_symtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + (struct ctf_dict.ctf_strtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + * ctf-lookup.c (ctf_lookup_symbol_name): Adapt. + (ctf_lookup_symbol_idx): Adapt. + (ctf_lookup_by_sym_or_name): Adapt. + * ctf-open.c (ctf_bufopen_internal): Adapt. + (ctf_dict_close): Adapt. + (ctf_getsymsect): Adapt. + (ctf_getstrsect): Adapt. + (ctf_symsect_endianness): Adapt. + +2024-04-19 Nick Alcock + + libctf: fix a comment typo + ctf_update has been called ctf_serialize for years now. + + libctf/ + + * ctf-impl.h: Fix comment typo. + +2024-04-19 Nick Alcock + + libctf: delete LCTF_DIRTY + This flag was meant as an optimization to avoid reserializing dicts + unnecessarily. It was critically necessary back when serialization was + done by ctf_update() and you had to call that every time you wanted any + new modifications to the type table to be usable by other types, but + that has been unnecessary for years now, and serialization is only done + once when writing out, which one would naturally assume would always + serialize the dict. Worse, it never really worked: it only tracked + newly-added types, not things like added symbols which might equally + well require reserialization, and it gets in the way of an upcoming + change. Delete entirely. + + libctf/ + + * ctf-create.c (ctf_create): Drop LCTF_DIRTY. + (ctf_discard): Likewise. + (ctf_rollback): Likewise. + (ctf_add_generic): Likewise. + (ctf_set_array): Likewise. + (ctf_add_enumerator): Likewise. + (ctf_add_member_offset): Likewise. + (ctf_add_variable_forced): Likewise. + * ctf-link.c (ctf_link_intern_extern_string): Likewise. + (ctf_link_add_strtab): Likewise. + * ctf-serialize.c (ctf_serialize): Likewise. + * ctf-impl.h (LCTF_DIRTY): Likewise. + (LCTF_LINKING): Renumber. + +2024-04-19 Nick Alcock + + libctf: fix a comment + A mistaken "not" in ctf_err_warn made it seem like we only extracted + error messages if this was not an error. + + libctf/ + + * ctf-subr.c (ctf_err_warn): Fix comment. + +2024-04-19 Nick Alcock + + libctf: support addition of types to dicts read via ctf_open() + libctf has long declared deserialized dictionaries (out of files or ELF + sections or memory buffers or whatever) to be read-only: back in the + furthest prehistory this was not the case, in that you could add a + few sorts of type to such dicts, but attempting to do so often caused + horrible memory corruption, so I banned the lot. + + But it turns out real consumers want it (notably DTrace, which + synthesises pointers to types that don't have them and adds them to the + ctf_open()ed dicts if it needs them). Let's bring it back again, but + without the memory corruption and without the massive code duplication + required in days of yore to distinguish between static and dynamic + types: the representation of both types has been identical for a few + years, with the only difference being that types as a whole are stored in + a big buffer for types read in via ctf_open and per-type hashtables for + newly-added types. + + So we discard the internally-visible concept of "readonly dictionaries" + in favour of declaring the *range of types* that were already present + when the dict was read in to be read-only: you can't modify them (say, + by adding members to them if they're structs, or calling ctf_set_array + on them), but you can add more types and point to them. (The API + remains the same, with calls sometimes returning ECTF_RDONLY, but now + they do so less often.) + + This is a fairly invasive change, mostly because code written since the + ban was introduced didn't take the possibility of a static/dynamic split + into account. Some of these irregularities were hard to define as + anything but bugs. + + Notably: + + - The symbol handling was assuming that symbols only needed to be + looked for in dynamic hashtabs or static linker-laid-out indexed/ + nonindexed layouts, but now we want to check both in case people + added more symbols to a dict they opened. + + - The code that handles type additions wasn't checking to see if types + with the same name existed *at all* (so you could do + ctf_add_typedef (fp, "foo", bar) repeatedly without error). This + seems reasonable for types you just added, but we probably *do* want + to ban addition of types with names that override names we already + used in the ctf_open()ed portion, since that would probably corrupt + existing type relationships. (Doing things this way also avoids + causing new errors for any existing code that was doing this sort of + thing.) + + - ctf_lookup_variable entirely failed to work for variables just added + by ctf_add_variable: you had to write the dict out and read it back + in again before they appeared. + + - The symbol handling remembered what symbols you looked up but didn't + remember their types, so you could look up an object symbol and then + find it popping up when you asked for function symbols, which seems + less than ideal. Since we had to rejig things enough to be able to + distinguish function and object symbols internally anyway (in order + to give suitable errors if you try to add a symbol with a name that + already existed in the ctf_open()ed dict), this bug suddenly became + more visible and was easily fixed. + + We do not (yet) support writing out dicts that have been previously read + in via ctf_open() or other deserializer (you can look things up in them, + but not write them out a second time). This never worked, so there is + no incompatibility; if it is needed at a later date, the serializer is a + little bit closer to having it work now (the only table we don't deal + with is the types table, and that's because the upcoming CTFv4 changes + are likely to make major changes to the way that table is represented + internally, so adding more code that depends on its current form seems + like a bad idea). + + There is a new testcase that tests much of this, in particular that + modification of existing types is still banned and that you can add new + ones and chase them without error. + + libctf/ + + * ctf-impl.h (struct ctf_dict.ctf_symhash): Split into... + (ctf_dict.ctf_symhash_func): ... this and... + (ctf_dict.ctf_symhash_objt): ... this. + (ctf_dict.ctf_stypes): New, counts static types. + (LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR. + (LCTF_RDWR): Deleted. + (LCTF_DIRTY): Renumbered. + (LCTF_LINKING): Likewise. + (ctf_lookup_variable_here): New. + (ctf_lookup_by_sym_or_name): Likewise. + (ctf_symbol_next_static): Likewise. + (ctf_add_variable_forced): Likewise. + (ctf_add_funcobjt_sym_forced): Likewise. + (ctf_simple_open_internal): Adjust. + (ctf_bufopen_internal): Likewise. + * ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with. + (ctf_create): Migrate a bunch of initializations into bufopen. + Force recreation of name tables. Do not forcibly override the + model, let ctf_bufopen do it. + (ctf_static_type): New. + (ctf_update): Drop LCTF_RDWR check. + (ctf_dynamic_type): Likewise. + (ctf_add_function): Likewise. + (ctf_add_type_internal): Likewise. + (ctf_rollback): Check ctf_stypes, not LCTF_RDWR. + (ctf_set_array): Likewise. + (ctf_add_struct_sized): Likewise. + (ctf_add_union_sized): Likewise. + (ctf_add_enum): Likewise. + (ctf_add_enumerator): Likewise (only on the target dict). + (ctf_add_member_offset): Likewise. + (ctf_add_generic): Drop LCTF_RDWR check. Ban addition of types + with colliding names. + (ctf_add_forward): Note safety under the new rules. + (ctf_add_variable): Split all but the existence check into... + (ctf_add_variable_forced): ... this new function. + (ctf_add_funcobjt_sym): Likewise... + (ctf_add_funcobjt_sym_forced): ... for this new function. + * ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts + with any stypes. + (ctf_link_add_strtab): Likewise. + (ctf_link_shuffle_syms): Likewise. + (ctf_link_intern_extern_string): Note pre-existing prohibition. + * ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check. + (ctf_lookup_variable): Split out looking in a dict but not + its parent into... + (ctf_lookup_variable_here): ... this new function. + (ctf_lookup_symbol_idx): Track whether looking up a function or + object: cache them separately. + (ctf_symbol_next): Split out looking in non-dynamic symtypetab + entries to... + (ctf_symbol_next_static): ... this new function. Don't get confused + by the simultaneous presence of static and dynamic symtypetab entries. + (ctf_try_lookup_indexed): Don't waste time looking up symbols by + index before there can be any idea how symbols are numbered. + (ctf_lookup_by_sym_or_name): Distinguish between function and + data object lookups. Drop LCTF_RDWR. + (ctf_lookup_by_symbol): Adjust. + (ctf_lookup_by_symbol_name): Likewise. + * ctf-open.c (init_types): Rename to... + (init_static_types): ... this. Drop LCTF_RDWR. Populate ctf_stypes. + (ctf_simple_open): Drop writable arg. + (ctf_simple_open_internal): Likewise. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Populate fields only used for writable dicts. + Drop LCTF_RDWR. + (ctf_dict_close): Cater for symhash cache split. + * ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR. + * ctf-types.c (ctf_variable_next): Drop LCTF_RDWR. + * testsuite/libctf-lookup/add-to-opened*: New test. + +2024-04-19 Nick Alcock + + libctf: fix name lookup in dicts containing base-type bitfields + The intent of the name lookup code was for lookups to yield non-bitfield + basic types except if none existed with a given name, and only then + return bitfield types with that name. Unfortunately, the code as + written only does this if the base type has a type ID higher than all + bitfield types, which is most unlikely (the opposite is almost always + the case). + + Adjust it so that what ends up in the name table is the highest-width + zero-offset type with a given name, if any such exist, and failing that + the first type with that name we see, no matter its offset. (We don't + define *which* bitfield type you get, after all, so we might as well + just stuff in the first we find.) + + Reported by Stephen Brennan . + + libctf/ + + * ctf-open.c (init_types): Modify to allow some lookups during open; + detect bitfield name reuse and prefer less bitfieldy types. + * testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test. + +2024-04-19 Nick Alcock + + libctf: remove static/dynamic name lookup distinction + libctf internally maintains a set of hash tables for type name lookups, + one for each valid C type namespace (struct, union, enum, and everything + else). + + Or, rather, it maintains *two* sets of hash tables: one, a ctf_hash *, + is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the + other, a ctf_dynhash *, is meant for lookups in ctf_create()d dicts. + + This distinction was somewhat valuable in the far pre-binutils past when + two different hashtable implementations were used (one expanding, the + other fixed-size), but those days are long gone: the hash table + implementations are almost identical, both wrappers around the libiberty + hashtab. The ctf_dynhash has many more capabilities than the ctf_hash + (iteration, deletion, etc etc) and has no downsides other than starting + at a fixed, arbitrary small size. + + That limitation is easy to lift (via a new ctf_dynhash_create_sized()), + following which we can throw away nearly all the ctf_hash + implementation, and all the code to choose between readable and writable + hashtabs; the few convenience functions that are still useful (for + insertion of name -> type mappings) can also be generalized a bit so + that the extra string verification they do is potentially available to + other string lookups as well. + + (libctf still has two hashtable implementations, ctf_dynhash, above, + and ctf_dynset, which is a key-only hashtab that can avoid a great many + malloc()s, used for high-volume applications in the deduplicator.) + + libctf/ + + * ctf-create.c (ctf_create): Eliminate ctn_writable. + (ctf_dtd_insert): Likewise. + (ctf_dtd_delete): Likewise. + (ctf_rollback): Likewise. + (ctf_name_table): Eliminate ctf_names_t. + * ctf-hash.c (ctf_dynhash_create): Comment update. + Reimplement in terms of... + (ctf_dynhash_create_sized): ... this new function. + (ctf_hash_create): Remove. + (ctf_hash_size): Remove. + (ctf_hash_define_type): Remove. + (ctf_hash_destroy): Remove. + (ctf_hash_lookup_type): Rename to... + (ctf_dynhash_lookup_type): ... this. + (ctf_hash_insert_type): Rename to... + (ctf_dynhash_insert_type): ... this, moving validation to... + * ctf-string.c (ctf_strptr_validate): ... this new function. + * ctf-impl.h (struct ctf_names): Extirpate. + (struct ctf_lookup.ctl_hash): Now a ctf_dynhash_t. + (struct ctf_dict): All ctf_names_t fields are now ctf_dynhash_t. + (ctf_name_table): Now returns a ctf_dynhash_t. + (ctf_lookup_by_rawhash): Remove. + (ctf_hash_create): Likewise. + (ctf_hash_insert_type): Likewise. + (ctf_hash_define_type): Likewise. + (ctf_hash_lookup_type): Likewise. + (ctf_hash_size): Likewise. + (ctf_hash_destroy): Likewise. + (ctf_dynhash_create_sized): New. + (ctf_dynhash_insert_type): New. + (ctf_dynhash_lookup_type): New. + (ctf_strptr_validate): New. + * ctf-lookup.c (ctf_lookup_by_name_internal): Adapt. + * ctf-open.c (init_types): Adapt. + (ctf_set_ctl_hashes): Adapt. + (ctf_dict_close): Adapt. + * ctf-serialize.c (ctf_serialize): Adapt. + * ctf-types.c (ctf_lookup_by_rawhash): Remove. + +2024-04-19 Nick Alcock + + libctf: don't leak the symbol name in the name->type cache + This cache replaced a cache of symbol index->ctf_id_t. That cache was + just an array, so it could get away with just being free()d, but the + ctfi_symnamedicts cache that replaced it is a full dynhash with a + dynamically-allocated string as the key. As such, it needs freeing with + ctf_dynhash_destroy(), not just free(), or we leak parts of the + underlying hashtab, and all the keys. + + libctf/ChangeLog: + + * ctf-archive.c (ctf_arc_flush_caches): Fix leak. + +2024-04-19 Nick Alcock + + binutils, objdump: Add --ctf-parent-section + This lets you examine CTF where the parent and child dicts are in entirely + different sections, rather than in a CTF archive with members with different + names. The linker doesn't emit ELF objects structured like this, but some + third-party linkers may; it's also useful for objcopy-constructed files + in some cases. + + (This is what the objdump --ctf-parent option used to do before commit + 80b56fad5c99a8c9 in 2021. The new semantics of that option are much more + useful, but that doesn't mean the old ones are never useful at all, so let's + bring them back.) + + (I was specifically driven to add this by DTrace's obscure "ctypes" and + "dtypes" options, which dump its internal, dynamically-generated dicts out + to files for debugging purposes: there are two, one the parent of the other. + Since they're in two separate files rather than a CTF archive and we have no + tools that paste files together into archives, objdump wouldn't show them -- + and even pasting them together into an ELF executable with objcopy didn't + help, since objdump had no options that could be used to look in specific + sections for the parent dict. With --ctf-parent-section, this sort of + obscure use case becomes possible again. You'll never need it for the + output of the normal linker.) + + binutils/ + + * doc/ctf.options.texi: Add --ctf-parent-section=. + * objdump.c (dump_ctf): Implement it. + (dump_bfd): Likewise. + (main): Likewise. + +2024-04-19 Gustavo Romero + + gdb: Document qIsAddressTagged packet + This commit documents the qIsAddressTagged packet. + + Reviewed-by: Eli Zaretskii + Approved-By: Eli Zaretskii + +2024-04-19 Gustavo Romero + + gdb/testsuite: Add unit tests for qIsAddressTagged packet + Add unit tests for testing qIsAddressTagged packet request creation and + reply checks. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Add qIsAddressTagged packet + This commit adds a new packet, qIsAddressTagged, allowing GDB remote + targets to use it to query the stub if a given address is tagged. + + Currently, the memory tagging address check is done via a read query, + where the contents of /proc//smaps is read and the flags are + inspected for memory tagging-related flags that indicate the address is + in a memory tagged region. + + This is not ideal, for example, for QEMU stub and other cases, such as + on bare-metal, where there is no notion of an OS file like 'smaps.' + Hence, the introduction of qIsAddressTagged packet allows checking + if an address is tagged in an agnostic way. + + The is_address_tagged target hook in remote.c attempts to use the + qIsAddressTagged packet first for checking if an address is tagged and + if the stub does not support such a packet (reply is empty) it falls + back to using the current mechanism that reads the contents of + /proc//smaps via vFile requests. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Introduce is_address_tagged target hook + This commit introduces a new target hook, target_is_address_tagged, + which is used instead of the gdbarch_tagged_address_p gdbarch hook in + the upper layer (printcmd.c). + + This change enables easy specialization of memory tagging address + check per target in the future. As target_is_address_tagged continues + to utilize the gdbarch_tagged_address_p hook, there is no change in + behavior for all the targets that use the new target hook (i.e., the + remote.c, aarch64-linux-nat.c, and corelow.c targets). + + Just the gdbarch_tagged_address_p signature is changed for convenience, + since target_is_address_tagged takes the address to be checked as a + CORE_ADDR type. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Use passed gdbarch instead of calling current_inferior + In do_examine function, use passed gdbarch when checking if an address + is tagged instead of calling current_inferior()->arch() to make the code + more localized and help modularity by not calling a current_* function, + which disguises the use of a global state/variable. There is no change + in the code behavior. + + Suggested-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from memtag_matches_p + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if + an address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_memtag_matches_p is always + called from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that + already points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, gdbarch_memtag_matches_p is called only after + should_validate_memtags is called, which checks the address at its end; + + b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only + after gdbarch_tagged_address_p is called directly. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Move MTE address check out of set_memtag + Remove check in parse_set_allocation_tag_input as it is redundant: + currently the check happens at the end of parse_set_allocation_tag_input + and also in set_memtag (called after parse_set_allocation_tag_input). + + After it, move MTE address check out of set_memtag and add this check to + the upper layer, before set_memtag is called. + + This is a preparation for using a target hook instead of a gdbarch hook + on MTE address checks. + + Approved-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from get_memtag + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an + address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_get_memtag is always called + from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already + points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag + hook) is called but only after should_validate_memtags, which calls + gdbarch_tagged_address_p; + + b) in do_examine, aarch64_linux_get_memtag is also called only after + gdbarch_tagged_address_p is directly called; + + c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags + matching or not -- after the initial check via direct call to + gdbarch_tagged_address_p; + + d) in memory_tag_print_tag_command, address is checked directly via + gdbarch_tagged_address_p before gdbarch_get_memtag is called. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Alan Modra + + Re: elf: Strip unreferenced weak undefined symbols + PR ld/31652 + * elflink.c (_bfd_elf_link_output_relocs): Don't segfault + on NULL rel_hash. + +2024-04-19 H.J. Lu + + elf: Strip unreferenced weak undefined symbols + Linker will resolve an undefined symbol only if it is referenced by + relocation. Unreferenced weak undefined symbols serve no purpose. + Weak undefined symbols appear in the dynamic symbol table only when they + are referenced by dynamic relocation. Mark symbols with relocation and + strip undefined weak symbols if they don't have relocation and aren't + in the dynamic symbol table. + + bfd/ + + PR ld/31652 + * elf-bfd.h (elf_link_hash_entry): Add has_reloc. + * elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc. + * elflink.c (_bfd_elf_link_output_relocs): Likewise. + (elf_link_output_extsym): Strip undefined weak symbols if they + don't have relocation and aren't in the dynamic symbol table. + + ld/ + + PR ld/31652 + * testsuite/ld-elf/elf.exp: Run undefweak tests. + * testsuite/ld-elf/undefweak-1.rd: New file. + * testsuite/ld-elf/undefweak-1a.s: Likewise. + * testsuite/ld-elf/undefweak-1b.s: Likewise. + * testsuite/ld-x86-64/weakundef-1.nd: Likewise. + * testsuite/ld-x86-64/weakundef-1a.s: Likewise. + * testsuite/ld-x86-64/weakundef-1b.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run undefweak tests. + +2024-04-19 Alan Modra + + memory leak in bfd/dwarf2.c + * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free + dwarf_addr_buffer and dwarf_str_offsets_buffer. + +2024-04-19 Alan Modra + + mmix disassemble memory leak + It's a once-off and of no consequence, but fix it anyway. The mmix + caonoicalize_syms array is an array of pointers. Freeing it won't + lose symbol names. + + * mmix-dis.c (initialize_mmix_dis_info): Free syms. + +2024-04-19 GDB Administrator + + Automatic date update in version.in + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake + On SLE-11, with an older dejagnu version, I ran into: + ... + Running gdb.ada/mi_prot.exp ... + UNRESOLVED: gdb.ada/mi_prot.exp: \ + testcase aborted due to invalid command name: gdb_find_gnatmake + ERROR: tcl error sourcing gdb.ada/mi_prot.exp. + ERROR: invalid command name "gdb_find_gnatmake" + while executing + "::gdb_tcl_unknown gdb_find_gnatmake" + ("uplevel" body line 1) + invoked from within + "uplevel 1 ::gdb_tcl_unknown $args" + (procedure "::unknown" line 5) + invoked from within + "gdb_find_gnatmake" + (procedure "gnatmake_version_at_least" line 2) + invoked from within + ... + + Proc gdb_find_gnatmake is actually a backup for find_gnatmake: + ... + if {[info procs find_gnatmake] == ""} { + rename gdb_find_gnatmake find_gnatmake + ... + so gnatmake_version_at_least should use find_gnatmake instead. + + For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we + don't run into this error. + + For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to + find_gnatmake, and we do run into the error. + + It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it + seems something legitimate to use. Maybe we should use future_ or gdb_future_ + prefix instead to make this more clear, but I've left that alone for now. + + Fix this by: + - triggering the same error with a recent dejagnu by removing + gdb_find_gnatmake unless used (and likewise for other procs in future.exp), + and + - using find_gnatmake in gnatmake_version_at_least. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31647 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647 + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use allocator_may_return_null=1 in two test-cases + Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw + MemoryError in inferior.read_memory if malloc fails") introduced + AddressSanitizer allocation-size-too-big errors in the two test-cases + affected by this commit. + + Fix this by suppressing the error in the two test-cases using + allocator_may_return_null=1. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html + +2024-04-18 Simon Marchi + + gdbsupport: constify some return values in print-utils.{h,cc} + There is no reason the callers of these functions need to change the + returned string, so change the `char *` return types to `const char *`. + + Update a few callers to also use `const char *`. + + Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 + Approved-By: Tom Tromey + +2024-04-18 Nick Clifton + + HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets. + PR 30743 + +2024-04-18 Will Hawkins + + Add DW_TAG_compile_unit DIE to Dummy CUs + Dummy CUs help detect errors and are very helpful. However, the DWARF + spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to + the header. This patch adds that. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650 + + Approved-By: Tom de Vries + Tested-By: Tom de Vries + +2024-04-18 Alan Modra + + Re: Fix address violations when reading corrupt VMS records + Fixes error reports about the length of EEOM records produced by gas. + + PR 21618 + * vms-alpha.c (evax_bfd_print_emh): Don't read subtyp if short + record. Consolidate error messages. + (evax_bfd_print_eeom): Allow length 10 record. + +2024-04-18 Alan Modra + + alpha_vms_get_section_contents vs. fuzzed files + This patch is in response to an oss-fuzz report regarding + use-of-uninitialized-value in bfd_is_section_compressed_info from + section contents provided by alpha_vms_get_section_contents. That + hole is covered by using bfd_zalloc rather than bfd_alloc. + + The rest of the patch is mostly a tidy. In a function returning + section contents, I tend to prefer a test on the section properties + over a test on file properties. That's why I've changed the file + flags test to one on section filepos and flags before calling + _bfd_generic_get_section_contents. Also, fuzzed objects can easily + have sections with file backing in relocatable objects, or sections + without file backing in images. Possible confusion is avoided by + testing each section. + + Note that we are always going to run into out-of-memory with fuzzed + alpha-vms object files due to sections with contents via ETIR records. + eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a + 32-bit repeat count. So section contents can be very large from a + relatively small file. I'm inclined to think that an out-of-memory + error is fine for such files. + + * vms-alpha.c (alpha_vms_get_section_contents): Handle sections + with non-zero filepos or without SEC_HAS_CONTENTS via + _bfd_generic_get_section_contents. Zero memory allocated for + sections filled by ETIR records. + +2024-04-18 Alan Modra + + Tidy objdump opb expressions + I don't think any of these can overflow, but since all of the + expressions I'm editing here are inside a while loop with condition + addr_offset < stop_offset, this change makes it more obvious that they + can't overflow. + + * objdump.c (disassemble_bytes): Calculate octet expressions + involving both addr_offset and stop_offset by first + subtracting addr_offset from stop_offset. + +2024-04-18 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Tom Tromey + + Remove a copy from c-exp.y:parse_number + parse_number copies its input string, but there is no need to do this. + This patch removes the copy. + + Regression tested on x86-64 Fedora 38. + + Reviewed-by: Keith Seitz + +2024-04-17 Pedro Alves + + gdb/Windows: Fix detach while running + While testing a WIP Cygwin GDB that supports non-stop, I noticed that + gdb.threads/attach-non-stop.exp exposes that this: + + (gdb) attach PID& + ... + (gdb) detach + + ... hangs. + + And it turns out that it hangs in all-stop as well. This commits + fixes that. + + After "attach &", the target is set running, we've called + ContinueDebugEvent and the process_thread thread is waiting for + WaitForDebugEvent events. It is the equivalent of "attach; c&". + + In windows_nat_target::detach, the first thing we do is + unconditionally call windows_continue (for ContinueDebugEvent), which + blocks in do_synchronously, until the process_thread sees an event out + of WaitForDebugEvent. Unless the inferior happens to run into a + breakpoint, etc., then this hangs indefinitely. + + If we've already called ContinueDebugEvent earlier, then we shouldn't + be calling it again in ::detach. + + Still in windows_nat_target::detach, we have an interesting issue that + ends up being the bulk of the patch -- only the process_thread thread + can call DebugActiveProcessStop, but if it is blocked in + WaitForDebugEvent, we need to somehow force it to break out of it. + The only way to do that, is to force the inferior to do something that + causes WaitForDebugEvent to return some event. + + This patch uses CreateRemoteThread to do it, which results in + WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT. We then + terminate the injected thread before it has a chance to run any + userspace code. + + Note that Win32 functions like DebugBreakProcess and + GenerateConsoleCtrlEvent would also inject a new thread in the + inferior. I first used DebugBreakProcess, but that is actually more + complicated to use, because we'd have to be sure to consume the + breakpoint event before detaching, otherwise the inferior would likely + die due a breakpoint exception being raised with no debugger around to + intercept it. + + See the new break_out_process_thread method. + + So the fix has two parts: + + - Keep track of whether we've called ContinueDebugEvent and the + process_thread thread is waiting for events, or whether + WaitForDebugEvent already returned an event. + + - In windows_nat_target::detach, if the process_thread thread is + waiting for events, unblock out of its WaitForDebugEvent, before + proceeding with the actual detach. + + New test included. Passes cleanly on GNU/Linux native and gdbserver, + and also passes cleanly on Cygwin and MinGW, with the fix. Before the + fix, it would hang and fail with a timeout. + + Tested-By: Hannes Domani + Reviewed-By: Tom Tromey + Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905 + +2024-04-17 Pedro Alves + + gdb+gdbserver/Linux: Remove USE_SIGTRAP_SIGINFO fallback + It's been over 9 years (since commit faf09f0119da) since Linux GDB and + GDBserver started relying on SIGTRAP si_code to tell whether a + breakpoint triggered, which is important for non-stop mode. When that + then-new code was added, I had left the then-old code as fallback, in + case some architectured still needed it. Given AFAIK there haven't + been complaints since, this commit finally removes the fallback code, + along with USE_SIGTRAP_SIGINFO. + + Change-Id: I140a5333a9fe70e90dbd186aca1f081549b2e63d + +2024-04-17 Tom Tromey + + Use section name in DWARF error message + A bug points out that a certain error message in read_str_index uses a + hard-coded section name. This patch changes it to use + dwarf2_section_info::get_name instead, like the other errors in the + function. + + No test because it didn't seem worthwhile. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31639 + Approved-By: Simon Marchi + +2024-04-17 Simon Marchi + + gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extension + When building with clang 18, I see: + + CXX aarch64-linux-tdep.o + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] + 1299 | gdb_byte za_zeroed[za_bytes]; + | ^~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here + 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); + | ^ + + Since we are using VLAs right now, that warning doesn't make sense for + us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to + enable. If we ever choose to disallow VLAs, we can remove that flag. + + Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c + +2024-04-17 Matt Wozniski + + Fix include guard typo + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645 + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: minor clean, remove some unneeded arguments + I spotted that the two functions: + + record_full_open_1 + record_full_core_open_1 + + both took two arguments, neither of which are used. + + I stumbled onto this while reviewing how filename_completer is used. + The 'record full restore' command uses filename_completer and invokes + the cmd_record_full_restore function. + + The cmd_record_full_restore function calls core_file_command and then + record_full_open, which then calls one of the above functions. + + As 'record full restore' takes a filename, this is passed to + cmd_record_full_restore, which forwards the filename to both + core_file_command and record_full_open. However, record_full_open + never actually uses the filename that is passed in. + + The record_full_open function is also used for 'target record-full'. + + I propose that record_full_open should no longer expect to see any + user supplied arguments passed in (it doesn't use any). In fact, I've + added a check that if we do get any user supplied arguments we'll + throw an error. + + Now that we know record_full_open isn't being passed any user + arguments we can stop passing the arguments to record_full_open_1 and + record_full_core_open_1, this will make no user visible difference as + these arguments were not used. + + It is possible that a user was previously doing: + + (gdb) target record-full blah blah blah + + And this previously would work fine, the 'blah blah blah' was + ignored. Now this will give an error. Other than this case there + should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: add an assert in cmd_record_start + The 'record' command is both a prefix command AND an alias for 'target + record-full'. As it is a prefix command, if a user types: + + (gdb) record blah + + Then GDB will look for, and try to invoke the 'blah' sub-command. + This will either succeed (if blah is found) or throw an error (if blah + is not found). + + As such, the only way to invoke the 'record' command is like: + + (gdb) record + + It is impossible to pass arguments to the 'record' command. As we + know this is true then we can assert this in cmd_record_start. + + I added this assert because initially I was going to try forwarding + ARGS from cmd_record_start to the 'target record-full' command, but + then I realised passing arguments to 'record' was impossible. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: remove unnecessary use of filename_completer + Spotted that the 'record' command has its completer set to + filename_completer. The problem is that 'record' is a prefix command, + as such, its completer is hard-coded to complete on sub-commands. The + attempt to use filename_completer is irrelevant. + + The 'record' command is itself a command though, that is, a user can + do this: + + (gdb) record + + which is really just an alias for: + + (gdb) target record-full + + Nowhere does cmd_record_start (which is called when 'record' is used) + expect a filename, and 'target record-full' doesn't expect a filename + either. + + So lets just drop the line which sets filename_completer as the + completer for 'record'. + + Approved-By: Tom Tromey + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require DW_LNE_end_sequence + The dwarf standard requires that every line number program sequence ends + with a DW_LNE_end_sequence instruction. + + Enforce this in the dwarf assembler for the last sequence in a line number + program (we have no means to enforce this for earlier sequences), and fix a + few test-case that don't have it. + + Tested on aarch64-linux. + + PR testsuite/31618 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix end_sequence addresses + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + File name Line number Starting address View Stmt + ... + map-to-same-line.c 54 0x4102ac x + map-to-same-line.c - 0x4102c4 + ... + + Fix this by ending the line table at $main_end. + + Likewise in a few other test-cases, found using: + ... + $ find gdb/testsuite/ -type f \ + | xargs grep -B1 DW_LNE_end_sequence \ + | grep set_address \ + | egrep -v "_end|_len" + ... + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNS_copy + No address update before a DW_LNS_copy might mean an incorrect dwarf + assembly test-case. + + Try to catch such incorrect dwarf assembly test-cases by: + - requiring an explicit address update for each DW_LNS_copy, and + - handling the cases where an update is indeed not needed, by adding + "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNE_end_sequence + With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence + entry with the same address as the line entry before it: + ... + File name Line number Starting address View Stmt + + dw2-epilogue-begin.c 44 0x4101e8 x + dw2-epilogue-begin.c 47 0x4101ec x + dw2-epilogue-begin.c - 0x4101ec + ... + and consequently the line entry is removed by gdb: + ... + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PRO EPI + 0 20 0x00000000004101a8 0x00000000004101a8 Y Y Y + 1 27 0x00000000004101b0 0x00000000004101b0 Y + 2 32 0x00000000004101b8 0x00000000004101b8 Y Y + 3 34 0x00000000004101c0 0x00000000004101c0 Y Y + 4 35 0x00000000004101c8 0x00000000004101c8 Y + 5 40 0x00000000004101d4 0x00000000004101d4 Y Y + 6 44 0x00000000004101e8 0x00000000004101e8 Y + 7 END 0x00000000004101ec 0x00000000004101ec Y + ... + + This is a common mistake in dwarf assembly test-cases. + + Fix this by: + - requiring an address update for each DW_LNE_end_sequence, and + - fixing the test-cases where that triggers an error. + + I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in + this case I worked around it using "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + + PR testsuite/31592 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592 + +2024-04-17 Aditya Vidyadhar Kamath + + Fix max-depth test case for AIX. + In AIX, if in the main program the global variables are unused then the linker optimises + these variables and the dwarf will not have proper address to the same. Hence we cannot access these + variables. + + This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well. + +2024-04-17 Victor Do Nascimento + + aarch64: Remove asserts from operand qualifier decoders [PR31595] + Given that the disassembler should never abort when decoding + (potentially random) data, assertion statements in the + `get_*reg_qualifier_from_value' function family prove problematic. + + Consider the random 32-bit word W, encoded in a data segment and + encountered on execution of `objdump -D '. + + If: + + (W & ~opcode_mask) == valid instruction + + Then before `print_insn_aarch64_word' has a chance to report the + instruction as potentially undefined, an attempt will be made to have + the qualifiers for the instruction's register operands (if any) + decoded. If the relevant bits do not map onto a valid qualifier for + the matched instruction-like word, an abort will be triggered and the + execution of objdump aborted. + + As this scenario is perfectly feasible and, in light of the fact that + objdump must successfully decode all sections of a given object file, + it is not appropriate to assert in this family of functions. + + Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for + handling invalid qualifier-associated values and re-purpose the + assertion conditions in qualifier-retrieving functions to be the + predicate guarding the returning of the calculated qualifier type. + If the predicate fails, we return this new qualifier and allow the + caller to handle the error as appropriate. + + As these functions are called either from within + `aarch64_extract_operand' or `do_special_decoding', both of which are + expected to return non-zero values, it suffices that callers return + zero upon encountering `AARCH64_OPND_QLF_ERR'. + + Ar present the error presented in the hypothetical scenario has been + encountered in `get_sreg_qualifier_from_value', but the change is made + to the whole family to keep the interface consistent. + + Bug: https://sourceware.org/PR31595 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix gdbserver pid in gdb.server/server-kill-python.exp + The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for + remote target") intended to addresss the problem that this command: + ... + set gdbserver_pid [exp_pid -i $server_spawn_id] + ... + does not return the pid of the gdbserver for remote target, but rather the one + of the ssh client session. + + To fix this, it added another way of getting the gdbserver_pid. + + For the trivial case of non-remote target, the PID found by either method + should be identical, but if we compare those by adding + "puts [exec ps -p $gdbserver_pid]" we get: + ... + PID TTY TIME CMD + 31711 pts/8 00:00:00 gdbserver + PID TTY TIME CMD + 31718 pts/8 00:00:00 server-kill-pyt + ... + + The problem is that while the gdbserver PID is supposed to be read from the + result of "gdb.execute ('p server_pid')" in the python script, instead it's + taken from: + ... + Process server-kill-python created; pid = 31718^M + ... + + Fix this by moving the printing of the gdbserver PID out of the python script. + + Also double-check the two methods against each other, in the cases that they + should match. + + Tested on x86_64-linux. + + PR testsuite/31633 + https://sourceware.org/bugzilla/show_bug.cgi?id=31633 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Simplify gdb.server/server-kill-python.exp + In test-case gdb.server/server-kill-python.exp we have: + ... + if {[gdb_spawn_with_cmdline_opts \ + "-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} { + fail "spawn" + return + } + ... + + I reproduced the problem by reverting the fix at the commit adding both the + fix and the test-case, and the reproduced the same problem using: + ... + (gdb) source $host_file1 + ... + so there doesn't seem to be a specific need to source the python file using + "-ex". + + Simplify the test-case by sourcing the python file using send_gdb. + + This also allow us to simplify the python script. + + Tested on x86_64-linux. + +2024-04-17 Hu, Lin1 + + Add W table for USER_MSR under MAP4. + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Modify MOD_EVEX_MAP4_F8_P1, + MOD_EVEX_MAP4_F8_P3. + * i386-dis-evex-w.h (EVEX_W_MAP4_F8_P1_M_1): New. + (EVEX_W_MAP4_F8_P3_M_1): Ditto. + * i386-dis.c (vex_w_table): Add EVEX_W_MAP4_F8_P1_M_1, + EVEX_W_MAP4_F8_P3_M_1. + * i386-opc.tbl: Remove redundant '|'. + +2024-04-17 H.J. Lu + + elf: Skip the archive if the symbol isn't referenced + Also skip the archive if the symbol isn't referenced by a regular object. + + bfd/ + + PR ld/31644 + * elflink.c (elf_link_add_archive_symbols): Also skip the archive + if the symbol isn't referenced by a regular object. + + ld/ + + PR ld/31644 + * testsuite/ld-plugin/lto.exp: Run PR ld/31644 tests. + * testsuite/ld-plugin/pr31644a.c: New test. + * testsuite/ld-plugin/pr31644b.c: Likewise. + * testsuite/ld-plugin/pr31644c.c: Likewise. + +2024-04-17 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Alan Modra + + ARC e_flags vs. objcopy + While the patch that Nick reverted in commit 3f6a060c7543 was in the + source, "FAIL: objcopy executable (pr25662)" was seen on ARC. The + failure was triggered by the .ARC.attributes section being removed by + the linker script. When a file lacking this section is copied by + objcopy, e_flags from the input is copied to the output (in this case + the value 0x406), but arc_elf_final_write_processing then logical-ors + in 0x300 when Tag_ARC_ABI_osver is not found. + + * elf32-arc.c (arc_elf_final_write_processing): Don't ignore + existing e_flags for objcopy. + +2024-04-17 Alan Modra + + libctf warnings + Seen with every compiler I have if using -fno-inline: + home/alan/src/binutils-gdb/libctf/ctf-create.c: In function ‘ctf_add_encoded’: + /home/alan/src/binutils-gdb/libctf/ctf-create.c:555:3: warning: ‘encoding’ may be used uninitialized [-Wmaybe-uninitialized] + 555 | memcpy (dtd->dtd_vlen, &encoding, sizeof (encoding)); + + Seen with gcc-4.9 and probably others at lower optimisation levels: + home/alan/src/binutils-gdb/libctf/ctf-serialize.c: In function 'symtypetab_density': + /home/alan/src/binutils-gdb/libctf/ctf-serialize.c:211:18: warning: 'sym' may be used uninitialized in this function [-Wmaybe-uninitialized] + if (*max < sym->st_symidx) + + Seen with gcc-4.5 and probably others at lower optimisation levels: + /home/alan/src/binutils-gdb/libctf/ctf-types.c:1649:21: warning: 'tp' may be used uninitialized in this function + /home/alan/src/binutils-gdb/libctf/ctf-link.c:765:16: warning: 'parent_i' may be used uninitialized in this function + + Also with gcc-4.5: + In file included from /home/alan/src/binutils-gdb/libctf/ctf-endian.h:25:0, + from /home/alan/src/binutils-gdb/libctf/ctf-archive.c:24: + /home/alan/src/binutils-gdb/libctf/swap.h:70:0: warning: "_Static_assert" redefined + /usr/include/sys/cdefs.h:568:0: note: this is the location of the previous definition + + * swap.h (_Static_assert): Don't define if already defined. + * ctf-serialize.c (symtypetab_density): Merge two + CTF_SYMTYPETAB_FORCE_INDEXED blocks. + * ctf-create.c (ctf_add_encoded): Avoid "encoding" may be used + uninitialized warning. + * ctf-link.c (ctf_link_deduplicating_open_inputs): Avoid + "parent_i" may be used uninitialized warning. + * ctf-types.c (ctf_type_rvisit): Avoid "tp" may be used + uninitialized warning. + +2024-04-16 Tom Tromey + + Avoid cache race in bfd_check_format_matches + Running the gdb test suite with the thread sanitizer enabled shows a + race when bfd_check_format_matches and bfd_cache_close_all are called + simultaneously on different threads. + + This patch fixes this race by having bfd_check_format_matches + temporarily remove the BFD from the file descriptor cache -- leaving + it open while format-checking proceeds. + + In this setup, the BFD client is responsible for closing the BFD again + on the "checking" thread, should that be desired. gdb does this by + calling bfd_cache_close in the relevant worker thread. + + An earlier version of this patch omitted the "possibly_cached" helper + function. However, this ran into crashes in the binutils test suite + involving the archive-checking abort in bfd_cache_lookup_worker. I do + not understand the purpose of this check, so I've simply had the new + function work around it. I couldn't find any comments explaining this + situation, either. I suspect that there may still be races related to + this case, but I don't think I have access to the platforms where gdb + deals with archives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + +2024-04-16 Tom Tromey + + Thread-safety improvements for bfd_check_format_matches + A gdb bug found that bfd_check_format_matches has some data races when + called from multiple threads. + + In particular, it changes the BFD error handler, which is a global. + It also has a local static variable ("in_check_format") that is used + for recursion detection. And, finally, it may emit warnings to the + per-xvec warning array, which is a global. + + This patch removes all the races here. + + The first part of patch is to change _bfd_error_handler to directly + handle the needs of bfd_check_format_matches. This way, the error + handler does not need to be changed. + + This change lets us use the new per-thread global + (error_handler_messages, replacing error_handler_bfd) to also remove + the need for in_check_format -- a single variable suffices. + + Finally, the global per-xvec array is replaced with a new type that + holds the error messages. The outermost such type is stack-allocated + in bfd_check_format_matches. + + I tested this using the binutils test suite. I also built gdb with + thread sanitizer and ran the test case that was noted as failing. + Finally, Alan sent me the test file that caused the addition of the + xvec warning code in the first place, and I confirmed that "nm-new" + has the same behavior on this file both before and after this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + Co-Authored-By: Alan Modra + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/backward-spec-inter-cu.exp + Add another regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/forward-spec-inter-cu.exp + Add a regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Correctly handle DIE parent computations + Tom de Vries pointed out that the combination of sharding, + multi-threading, and per-CU "racing" means that sometimes a cross-CU + DIE reference might not be correctly resolved. However, it's + important to handle this correctly, due to some unfortunate aspects of + DWARF. + + This patch implements this by arranging to preserve each worker's DIE + map through the end of index finalization. The extra data is + discarded when finalization is done. This approach also allows the + parent name resolution to be sharded, by integrating it into the + existing entry finalization loop. + + In an earlier review, I remarked that addrmap couldn't be used here. + However, I was mistaken. A *mutable* addrmap cannot be used, as those + are based on splay trees and restructure the tree even during lookups + (and thus aren't thread-safe). A fixed addrmap, on the other hand, is + just a vector and is thread-safe. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Introduce class parent_map for DIE range map + This changes the DIE range map from a raw addrmap to a custom class. + A new type is used to represent the ranges, in an attempt to gain a + little type safety as well. + + Note that the new code includes a map-of-maps type. This is not used + yet, but will be used in the next patch. + + Co-Authored-By: Tom de Vries + +2024-04-16 Tom Tromey + + Add move operators for addrmap + A subsequent patch needs to move an addrmap. This patch adds the + necessary support. It also changes addrmap_fixed to take a 'const' + addrmap_mutable. This is fine according to the contract of + addrmap_mutable; but it did require a compensating const_cast in the + implementation. + +2024-04-16 Tom Tromey + + Change handling of DW_TAG_enumeration_type in DWARF scanner + Currently the DWARF scanner will enter enumeration constants into the + same namespace as the DW_TAG_enumeration_type itself. This is the + right thing to do, but the implementation may result in strange + entries being added to the addrmap that maps DIE ranges to entries. + + This came up when debugging an earlier version of this series; and + while I don't think this should impact the current series, it seems + better to clean this up anyway. + + In the new code, rather than pass the "wrong" scope down through + recursive calls to the scanner, the correct scope is always passed, + and then the parent handling is done when creating the enumerator + entry. + +2024-04-16 Tom de Vries + + [gdb/symtab] Refactor condition in scan_attributes + In scan_attributes there's code: + ... + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr + && *parent_entry == nullptr) + ... + else if (*parent_entry == nullptr) + ... + ... + that uses the "*parent_entry == nullptr" condition twice. + + Make this somewhat more readable by factoring out the condition: + ... + if (*parent_entry == nullptr) + { + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr) + ... + else + ... + } + ... + + This also allows us to factor out "form_addr (origin_offset, origin_is_dwz)". + + Tested on x86_64-linux. + +2024-04-16 Nick Clifton + + Fix test for sections with different VMA<->LMA relationships so that it only applies to allocated sections, and only sections in the same segment are checked. + PR 31450 + +2024-04-16 Simon Marchi + + gdb/make-target-delegates.py: don't handle "void" in parse_argtypes + I suppose this was needed when we had `void` in declarations of methods + with no parameters. If so, we no longer need it. There are no changes + in the generated file. + + Change-Id: I0a2b398408aa129634e2d73097a038f7f80db4b4 + Approved-By: John Baldwin + +2024-04-16 Eli Zaretskii + + Remove excess whitespace from doc strings of some commands + I've noticed that doc strings of some commands, like "set cwd" + and "set inferior-tty", have some excess whitespace, which + makes them display with unexpected indentation, at least in a + Windows command prompt window. This patch fixes that. + + * gdb/linux-nat.c (_initialize_linux_nat): + * gdb/riscv-tdep.c (riscv_insn): + * gdb/top.c (quit_force): + * gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace. + +2024-04-16 Nick Clifton + + Remove accidental commit of an experimental change + +2024-04-16 Tom de Vries + + [gdb/python] Throw MemoryError in inferior.read_memory if malloc fails + PR python/31631 reports a gdb internal error when doing: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + utils.c:709: internal-error: virtual memory exhausted. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ... + + Fix this by throwing a python MemoryError, such that we have instead: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + Python Exception : + Error occurred in Python. + (gdb) + ... + + Likewise for DAP. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631 + +2024-04-16 H.J. Lu + + x86: Fix a memory leak in md_assemble + Fix a memory leak in md_assemble where copy may be cleared and may be + the same as copy: + + if (copy && !mnem_suffix) + { + line = copy; + copy = NULL; + no_match: + + * config/tc-i386.c (md_assemble): Properly free the xstrdup + memory. + +2024-04-16 H.J. Lu + + gas: Free unused memory in scfi_ops_cleanup + * scfi.c (scfi_ops_cleanup): Free op->op_data and head. + +2024-04-16 Fangrui Song + + Simplify readelf's RELR relocation display. + +2024-04-16 Nick Clifton + + Gas Doc: Update example of how .altmacro affects the interpretation of macro arguments. + PR 31255 + +2024-04-16 Simon Cook + + Remove debug printout from 9dd918142787246ea7ed53494d9cbc6b51486133 + +2024-04-16 GDB Administrator + + Automatic date update in version.in + +2024-04-15 Tom Tromey + + Fix crash in gdb_rl_callback_handler + commit bdcd50f9 ("Strip trailing newlines from input string") + introduced a crash in eof-exit.exp. This patch fixes the problem by + adding a NULL check in the appropriate spot. + + Regression tested on x86-64 Fedora 38. I'm checking this in. + +2024-04-15 Tom Tromey + + Remove 'copy_names' parameter from add_using_directive + I noticed that add_using_directive's 'copy_names' parameter is only + used by a single caller. This patch removes the parameter and changes + that caller to copy the names itself. I chose to use intern here + since I suspect the names may well be repeated in a given objfile. + + Approved-By: John Baldwin + +2024-04-15 John Baldwin + + gdb: Add Felix Willgerodt as the x86 architecture maintainer + This includes both the i386 and x86-64 architectures. + +2024-04-15 Nick Clifton + + Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments. + PR 31527 + +2024-04-15 Tom Tromey + + Change printf attribute to fix clang build + commit e8cd90f0 ("Rewrite gdb_bfd_error_handler") broke the clang + build. + + The problem here is that print_error_callback isn't marked as being + printf-like, but it calls string_file::vprintf, triggering: + + ../../binutils-gdb/gdb/gdb_bfd.c:1202:18: error: format string is not a string literal [-Werror,-Wformat-nonliteral] + + This patch applies the attribute to this function. + + It also removes the attribute from gdb_bfd_error_handler, because that + function is no longer really printf-like. + +2024-04-15 Vijay Shankar + + When mapping sections to segments ensure that we do not add sections whose VMA->LMA relationship does not match the relationship of earlier sections in the segment. + PR 31540 + +2024-04-15 Tom Tromey + + Avoid complaint warning on mingw + The mingw build currently issues a warning: + + ./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes] + + This patch fixes the problem as suggested by Simon: + + https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html + + ...that is, by changing the warning interceptor to a class with a + single 'warn' method. + + Approved-By: Simon Marchi + +2024-04-15 Tom Tromey + + Strip trailing newlines from input string + A co-worker noticed a strange situation where "target remote" would + fail due to a trailing newline in the address part of the command. + Eventually he tracked this down to the fact that he was pasting the + command into the terminal, and due to bracketed paste mode, the + newline was being preserved by readline. + + It seems to me that we basically never want a trailing newline on a + gdb command, so this patch removes it when handling the readline + result. + + Co-Authored-By: Kévin Le Gouguec + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-15 Christophe Lyon + + gprofng: Fix dvi documentation build rule + This patch fixes 'install-dvi'. + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix confusion with c.jal vs. c.addiw + There was apparently a confusion which cpu model uses + compressed JAL and which ADDIW. Fixed that in execute_c, + case MATCH_C_JAL | MATCH_C_ADDIW. + + Fixes 3224e32fb84f ("sim: riscv: Add support for compressed integer instructions") + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Make stack 16-byte aligned + Various gcc test cases fail due to the stack + alignment of 16 bytes is expected by gcc, + causing issues mostly with vararg functions, + e.g. + + FAIL: gcc.c-torture/execute/nest-align-1.c -O0 execution test + FAIL: gcc.c-torture/execute/nest-stdar-1.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-12.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-15.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-16.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-17.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-20.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-26.c -O0 execution test + ... + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix PC at gdb breakpoints + The uncompressed EBREAK instruction does not work + correctly this way, and the comment saying that + GDB expects us to step over EBREAK is just wrong. + The PC was always 4 bytes too high, which skips one + instruction at break and step over commands, and + causes complete chaos. The compressed EBREAK was + already implemented correctly. + + Tested by using gdb's "target sim" and single-stepping. + + Approved-By: Andrew Burgess + +2024-04-15 Lulu Cai + + LoongArch: ld:Report an error when seeing an unrecognized relocation + If we generate an object file using an assembler with the new + relocations added, and then linking those files with an older + linker, the link will still complete and the linked file will + be generated. + In this case we should report an error instead of continuing + the linking process. + +2024-04-15 GDB Administrator + + Automatic date update in version.in + +2024-04-14 GDB Administrator + + Automatic date update in version.in + +2024-04-13 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Pedro Alves + + Fix setting watchpoints when current thread is running + Currently, when the current thread is running, you can print global + variables. However, if you try to set a watchpoint on the same + globals, GDB errors out, complaining that the selected thread is + running. Like so: + + (gdb) c& + Continuing. + (gdb) p global + $1 = 1098377287 + (gdb) watch global + Selected thread is running. + + This patch makes setting the watchpoint work. You'll now get: + + (gdb) c& + Continuing. + (gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)] + [New Thread 0x7ffff756d640 (LWP 434994)] + p global + $1 = 88168 + (gdb) watch global + Hardware watchpoint 2: global + (gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)] + + Thread 2 "function0" hit Hardware watchpoint 2: global + + Old value = 185420 + New value = 185423 + int_return () at threads.c:39 + 39 } + + The problem is that update_watchpoint calls get_selected_frame + unconditionally. We can skip it if the watchpoint expression is only + watching globals. + + This adds a testcase that exercises both all-stop and non-stop, and + also software and hardware watchpoints. It is kfailed for software + watchpoints, as those require another fix not handled by this patch + (the sw watchpoint doesn't fire because GDB doesn't force the + running-free thread to switch to single-stepping). + + Change-Id: I68ca948541aea3edd4f70741f272f543187abe40 + +2024-04-12 Pedro Alves + + New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) + Add a new testcase for exercising attaching to a process after its + main thread has exited. + + This is not possible on Linux, the kernel does not allow attaching to + a zombie task, so the test is kfailed there. It is possible however + on Windows at least, and was the scenario addressed by the Windows + backend fix in + https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html, + nowadays PR threads/8153, back in 2003. + + Passes cleanly on Cygwin. + KFAILed on GNU/Linux native and gdbserver. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555 + Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b + +2024-04-12 Pedro Alves + + Cygwin/testsuite: Avoid infinite hang + On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp + testcase hits a sequence of cascading FAILs: + + (gdb) run + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 12672.0x318c] + [New Thread 12672.0x2844] + [New Thread 12672.0x714] + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout) + frame + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout) + list + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout) + + And the test program never makes progress. + + ... and at this point, Cygwin is completely stuck. I can't run any + other Cygwin program. + + However, if we run the test program outside DejaGnu, we see something + different: + + (gdb) b add + Function "add" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (add) pending. + (gdb) r + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 10968.0x834] + [New Thread 10968.0x29a4] + [New Thread 10968.0x16b8] + [New Thread 10968.0xf9c] + [Switching to Thread 10968.0x16b8] + + Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 ) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304 + 1304 se = sigs + pack.si.si_signo; + (gdb) + + Ah, the test wanted to run to a global "add" function, but managed to + stop at an internal Cygwin method called "add". And stopping there + deadlocks everything Cygwin in the system. (I believe some + cygwin1.dll mechanisms use cross-process synchronization or + communication, we're probably blocking something like that.) + + Fix this by using "break -q". The tests FAIL because we don't support + follow-fork for Cygwin, but at least we no longer deadlock the + machine. + + Approved-by: Kevin Buettner + Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9 + +2024-04-12 Andrew Burgess + + gdb/data-directory: silence output from mkinstalldirs script + After my recent changes the data-directory build now uses + silent-rules.mk to reduce the output. + + One problem that remains was the use of mkinstalldirs by stamp-python + and stamp-guile for creating some directories, the mkinstalldirs + prints some messages, so we're left with output like this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I was looking at adding a --silent option to the mkinstalldirs script, + however, when I took a look at the automake package (which is where + mkinstalldirs comes from) it turns out that mkinstalldirs is + deprecated, at the advice is to use 'install-sh -d' instead. + + Just like we carry mkinstalldirs in the top-level directory, we also + carry install-sh, and a version of install-sh which supports the -d + flag. + + And best of all, 'install-sh -d' doesn't appear to print any of the + information messages to stdout that mkinstalldirs does, so if we + switch to use that, we get a quieter build. + + There should be no changes in what is built after this commit + + Approved-By: Tom Tromey + +2024-04-12 Nick Clifton + + Update description of macro keyword argument assignment in assembler documentation. + PR 31255 + +2024-04-12 H.J. Lu + + gas: Fix memory leaks in gen-sframe.c + * gen-sframe.c (sframe_xlate_ctx_cleanup): Call XDELETE on + xlate_ctx->cur_fre. + (create_sframe_all): Call XDELETE on xlate_ctx after use. + +2024-04-12 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Alan Modra + + Re: Fix null pointer dereference in process_debug_info() + read_bases has a potential null-pointer deref too, and without a + debug_info_p there isn't any point in calling read_bases. + + * dwarf.c (process_debug_info): Don't call read_bases when + debug_info_p is NULL. + +2024-04-11 Nick Clifton + + Improve readelf's display of RELR relocs. + + Add -j/--display-section option to readelf. + +2024-04-11 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang + When running test-case gdb.threads/access-mem-running-thread-exit.exp with + clang, we run into: + ... + (gdb) print global_var = 555^M + No symbol "global_var" in current context.^M + (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \ + access mem (write to global_var, inf=2, iter=1) + ... + + The problem is that clang removes the unused variable. + + Fix this in the same way as done in commit b4f767131f7 + ("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the + variable. + + Tested on x86_64-linux with gcc and clang. + +2024-04-11 H.J. Lu + + gas: Fix a CFI label name memory leak in scfi.c + CFI label name can be freed only after use. + + * scfi.c (handle_scfi_dot_cfi): Free CFI label name after use. + * scfidw2gen.c (scfi_process_cfi_label): Add a comment. Remove + TODO on freeing CFI label name. + +2024-04-11 H.J. Lu + + gas: Fix memory leaks in ginsn.c + Free buffer memory after use in ginsn.c. + + * ginsn.c (ginsn_dst_print): Free buffer after use. + (ginsn_print): Likewise. + +2024-04-11 Tankut Baris Aktemur + + gdb: fix format in remote.c + Fix space-before-parenthesis format at three spots in remote.c. + +2024-04-11 Alan Modra + + Remove bfdwin.c + In commit b86d3af60ffc and 0ab0435fe672 I fixed SIGBUS errors found by + oss-fuzz now that --with-mmap defaults to enabled. It turns out there + are further problems with the aout mmap code: aout_read_minisymbols + returns the external symbol array, which is later freed by nm.c. If + the array is mmaped you can't free it. Now this could be fixed by + making aout minisymbols an array of pointers, but I figure there's not + much point in expending effort on that. So delete the aout mmap + support along with bfdwin.c and get_section_contents_in_window. + +2024-04-11 Alan Modra + + asan: heap buffer overflow elf_link_add_to_first_hash + Seen on mmix. + mmix +FAIL: ld-misc/defsym1 + mmix +FAIL: sysroot-prefix common plain -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path, quoted + mmix +FAIL: sysroot-prefix common full-path, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, unquoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, unquoted + + ==3746597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070000007a0 at pc 0x56d87b0d1a40 bp 0x7fffb1629bf0 sp 0x7fffb1629be0 + READ of size 8 at 0x6070000007a0 thread T0 + #0 0x56d87b0d1a3f in elf_link_add_to_first_hash /home/alan/src/binutils-gdb/bfd/elflink.c:4312 + + mmix uses bfd_link_generic_hash_table. + + * elflink.c (_bfd_elf_archive_symbol_lookup): Dont use first_hash + unless the hash table is bfd_link_elf_hash_table. + (elf_link_add_archive_symbols): Likewise. + +2024-04-11 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: shift exponent 255 is too large for 64-bit type + + I should have known oss-fuzz wouldn't be satisfied so easily. The pef + format allows quite silly section alignments in object files. + + * objcopy.c (setup_section): Limit shift exponent when checking + vma and lma for alignment. + +2024-04-11 H.J. Lu + + x86-64: Use long NOPs for Intel Core processors + Use long NOPs for Intel Core processors since they are faster than + multiple NOPs. Don't use them for 64-bit processors by default since + Intel Atom processors can only decode 4 prefixes in 1 cycle. + + * config/tc-i386.c (alt64_9): New. + (alt64_10): Likewise. + (alt64_11): Likewise. + (alt64_12): Likewise. + (alt64_13): Likewise. + (alt64_14): Likewise. + (alt64_15): Likewise. + (alt64_patt): Likewise. + (i386_generate_nops): Use alt64_patt for Intel Core processors + in 64-bit mode. + * testsuite/gas/i386/x86-64-nops-1-core2.d: Expect long NOPs. + * testsuite/gas/i386/x86-64-nops-4-core2.d: Likewise. + * testsuite/gas/i386/ilp32/x86-64-nops-1-core2.d: Replace + ../x86-64-nops-1.d with ../x86-64-nops-1-core2.d. + * testsuite/gas/i386/ilp32/x86-64-nops-4-core2.d: Replace + ../x86-64-nops-4.d with ../x86-64-nops-4-core2.d. + +2024-04-11 H.J. Lu + + mmap: Fix a memory leak in _bfd_mmap_read_temporary + Return malloced memory in *mmap_base so that _bfd_munmap_readonly_temporary + will free it. + + * libbfd.c (_bfd_mmap_read_temporary): Return malloced memory + in *mmap_base. + +2024-04-11 H.J. Lu + + elf: Fix a memory leak in _bfd_elf_add_dynamic_entry + Normally, the section contents is allocated by bfd_alloc which is freed + when the object is closed. But the .dynamic section contents is allocated + by bfd_realloc, which should be freed by calling free. Add a dynamic + field to elf_link_hash_table for the .dynamic section and free its + contents in _bfd_elf_link_hash_table_free. + + * elf-bfd.h (elf_link_hash_table): Add dynamic. + * elflink.c (_bfd_elf_link_create_dynamic_sections): Set the + dynamic field in elf_link_hash_table. + (_bfd_elf_add_dynamic_entry): Use hash_table->dynamic. + (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise. + (bfd_elf_add_dt_needed_tag): Likewise. + (elf_finalize_dynstr): Likewise. + (_bfd_elf_link_hash_table_free): Free htab->dynamic->contents. + (bfd_elf_final_link): Use htab->dynamic. + * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use + htab->elf.dynamic. + +2024-04-11 Alan Modra + + Segfault in _bfd_delete_bfd with USE_MMAP + Any of the calls to _bfd_delete_bfd in bfd_fopen will hit this. + + * opncls.c (_bfd_delete_bfd): Check for non-NULL xvec before + accessing flavour. + +2024-04-11 GDB Administrator + + Automatic date update in version.in + +2024-04-10 Indu Bhagat + + gas: scfi: bugfixes for SCFI state propagation + There are two state propagation functions in SCFI machinery - forward + and backward flow. The patch addresses two issues: + - In forward_flow_scfi_state (), the state being compared in forward flow + must be that at the exit of a prev bb and that at the entry of the + next bb. The variable holding the state to be compared was + previously (erroneously) stale. + - In cmp_scfi_state (), the assumption that two different control + flows, leading to the same basic block, cannot have a mismatched + notion of CFA base register, is not true. Remove the assertion and + instead return err if mismatch. + + Fixing these issues helps correctly synthesize CFI, when previously + SCFI was erroring out for an otherwise valid input asm. + + gas/ + * scfi.c (cmp_scfi_state): Remove assertion and return mismatch + in return value as applicable. + (forward_flow_scfi_state): Update state object to be the same as + the exit state of the prev bb before comparing. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-5.d: New test. + * gas/scfi/x86_64/scfi-cfg-5.l: New test. + * gas/scfi/x86_64/scfi-cfg-5.s: New test. + +2024-04-10 Indu Bhagat + + gas: gcfg: add_bb_at_ginsn must return root_bb + A GCFG (ginsn control flow graph) is created for SCFI purposes in GAS. + The existing GCFG creation process was ignoring some paths. + + add_bb_at_ginsn () is a recursive function which should return the root + of the added basic blocks. This property was being violated in some + traversals, e.g., where a taken path involving a sequence of a few basic + blocks eventually culminated in a GINSN_TYPE_RETURN instruction. This + patch fixes the issue by keeping an explicit variable root_bb to + memorize the bb to be returned. + + Next, find_or_make_bb () must either create or find the bb with the + first ginsn as the provided ginsn. Add a few assertions to ensure + health of the cfg creation process. + + Note that the testcase, in its current shape, is not fit for catching + regressions for the issue at hand. Although the testcase does exercise + the updated code path, the testcase passes even without the current fix, + because the added edge in this specific testcase does not alter the + synthesized CFI. (The missing edge is the fallthrough edge of the + conditional branch "jne .L13" in the testcase.) + + Using a manual gcfg_print (), one can see the missing edge without the + fix. Lets keep the testcase for now, until there is a better way to + test the GCFG for this issue (e.g., either by dumping the GCFG in + textual format, or a case when the missing edge does cause wrong + synthesized CFI). + + gas/ + * ginsn.c (bb_add_edge): Fix a code comment. + (find_bb): Likewise. + (find_or_make_bb): Add new assertions to ensure health of cfg + creation process. + (add_bb_at_ginsn): Keep reference to the root_bb and return it. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-4.d: New test. + * gas/scfi/x86_64/scfi-cfg-4.l: New test. + * gas/scfi/x86_64/scfi-cfg-4.s: New test. + +2024-04-10 Christophe Lyon + + gdb, gdbserver: Add missing install-dvi Makefile target + For some reason install-dvi is missing although other targets of the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + + Fix what looks like another oversight: include 'pdf' in 'all-doc' in + gdb/doc/Makefile.in. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-10 Nick Clifton + + readelf: Add -j/--display-section command line option. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP to avoid the sanitizer + configure check failure. + + bfd/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + binutils/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + ld/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libctf/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libsframe/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid + the sanitizer configure check failure. + + config/ + + * mmap.m4 (GCC_AC_FUNC_MMAP): New. + * no-executables.m4 (AC_FUNC_MMAP): Renamed to GCC_AC_FUNC_MMAP. + Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + + libiberty/ + + * Makefile.in (aclocal_deps): Add $(srcdir)/../config/mmap.m4. + * acinclude.m4: Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + * aclocal.m4: Regenerated. + * configure: Likewise. + + zlib/ + + * acinclude.m4: Include ../config/mmap.m4. + * Makefile.in: Regenerated. + * configure: Likewise. + +2024-04-10 Alan Modra + + Re: ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + Don't use CC_FOR_TARGET in the bootstrap test, a silly idea aiming at + consistency that made things worse. The objects being linked were + built using $CC, so $CC should be used to link. + + * testsuite/ld-bootstrap/bootstrap.exp: Revert last change. + +2024-04-10 GDB Administrator + + Automatic date update in version.in + +2024-04-09 Tom Tromey + + Rewrite gdb_bfd_error_handler + This patch rewrites gdb_bfd_error_handler to use 'bfd_print_error' to + generate the text of the warning, and then emits it using 'warning'. + The current code in the tree is a bit wrong because it may do the + wrong thing when BFD uses ones of its printf extensions. + + This also adds locking to increment_bfd_error_count. This is + important now that some BFD operations can be done on worker threads. + + This approach makes it simpler for worker threads to intercept any + messages. + + Regression tested on x86-64 Fedora 38. + +2024-04-09 Jens Remus + + aarch64: Treat operand "SME list of ZA tiles" as immediate (PR 31561) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + "SME list of ZA tiles" (SME_list_of_64bit_tiles) as immediate. During + assembly it is correctly encoded as immediate value (imm.value) in + parse_operands. During disassembly it is first correctly decoded as + immediate value (imm.value) in aarch64_ext_imm called by + aarch64_extract_operand, but then erroneously treated as register + number (reg.regno) in aarch64_print_operand. + + This resolves the assembler test case "SME extension (ZERO)" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31561 + * aarch64-opc.c: Treat operand "SME list of ZA tiles" as + immediate. + + Bug: https://sourceware.org/PR31561 + Acked-by: Nick Clifton + +2024-04-09 Jens Remus + + s390: Flag conditional branch relative insns as condjump + Flag conditional branch relative (extended) mnemonics clij* and clgij* + as "condjump" for jump visualization in disassembly. They were missed + to be flagged as such in commit c5306fed7d40 ("s390: Support for jump + visualization in disassembly"). + + opcodes/ + * s390-opc.txt: Flag conditional branch relative instructions + clij* and clgij* as condjump for jump visualization in + disassembly. + + Acked-by: Nick Clifton + +2024-04-09 H.J. Lu + + bfd: Define pagesize variables only for mmap + Define _bfd_pagesize, _bfd_pagesize_m1 and _bfd_minimum_mmap_size only + if HAVE_MMAP is defined. + + * libbfd-in.h (_bfd_pagesize): Declare only if HAVE_MMAP is + defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + * libbfd.c (_bfd_pagesize): Define only if HAVE_MMAP is defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Replace _bfd_pagesize with + getpagesize. + +2024-04-09 Alex Coplan + + arm: Fix disassembly of MVE vq[r]shr[u]n + This patch fixes the disassembly of vq[r]shr[u]n insns so that the + shift immediate is properly decoded. See the description of the + previous patch for an example of the incorrect disassembly. + + As part of this patch we also fix the mve-vqrshrn.d test which was + testing for the incorrect disassembly of the immediates. The + disassembly now matches the assembled instructions in that test. + + Finally we add an mve-vqshrn test which tests the non-rounding variants + of those insns, whose encoding we fixed with the previous patch in this + series. + +2024-04-09 Alex Coplan + + arm: Fix encoding of MVE vqshr[u]n + As it stands, these insns are incorrectly encoded as vqrshr[u]n. + Concretely, the problem can be seen as follows: + + $ cat t.s + vqrshrnb.s16 q0,q0,#8 + vqshrnb.s16 q0,q0,#8 + $ gas/as-new t.s -march=armv8.1-m.main+mve -o t.o + $ binutils/objdump -d t.o -m armv8.1-m.main + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <.text>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + + Here we assemble these two instructions to the same opcode. The + encoding of the first is the correct, while the encoding of the second + is incorrect, and the bottom bit should be clear, see the Armv8-M ARM: + https://developer.arm.com/documentation/ddi0553/latest/ + + There is an additional problem here in that the disassembly of the + immediate is incorrect. llvm-objdump shows the correct disassembly + here: + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <$t>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + + Note that we defer adding a test for the correct encoding of these insns + until the next patch which fixes the disassembly issue. + +2024-04-09 Alex Coplan + + arm: Refactor condition for print_mve_shift_n + This is intended to have no functional change, but refactors the + condition guarding the call to print_mve_shift_n in arm-dis.c ahead of a + later patch which adds additional insns to the set of those whose + shift immediate is disassembled using print_mve_shift_n. + +2024-04-09 Jiawei + + RISC-V: Support Zcmp push/pop instructions. + Support zcmp extension push/pop/popret and popret zero instructions. + The `reg_list' is a list containing 1 to 13 registers, we can use: + "{ra}, {ra, s0}, {ra, s0-s1}, {ra, s0-s2} ... {ra, s0-sN}" + to present this feature. + + Passed gcc/binutils regressions of riscv-gnu-toolchain. + + Most of work was finished by Sinan Lin. + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subset): Imply zca for zcmp. + (riscv_supported_std_z_ext): Added zcmp with version 1.0. + (riscv_parse_check_conflicts): Zcmp conflicts with d/zcd. + (riscv_multi_subset_supports): Handle zcmp. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (regno_to_reg_list): New function, used to map + register to reg_list number. + (reglist_lookup): Called reglist_lookup_internal. Return false if + reg_list number is zero, which is an invalid value. + (reglist_lookup_internal): Parse register list, and return the last + register by regno_to_reg_list. + (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zcmp-push-pop-fail.d: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.l: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.s: New test. + * testsuite/gas/riscv/zcmp-push-pop.d: New test. + * testsuite/gas/riscv/zcmp-push-pop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH/MASK_CM_PUSH): New macros for zcmp. + (MATCH/MASK_CM_POP): Ditto. + (MATCH/MASK_CM_POPRET): Ditto. + (MATCH/MASK_CM_POPRETZ): Ditto. + (DECLARE_INSN): New declarations for zcmp. + * opcode/riscv.h (EXTRACT/ENCODE/VALID_ZCMP_SPIMM): Handle spimm + operand for zcmp. + (OP_MASK_REG_LIST): Handle operand for zcmp register list. + (OP_SH_REG_LIST): Ditto. + (ZCMP_SP_ALIGNMENT): New argument, used in riscv_get_sp_base. + (X_S0, X_S1, X_S2, X_S10, X_S11): New register numbers. + (enum riscv_insn_class): Added INSN_CLASS_ZCMP. + (extern riscv_get_sp_base): Added. + + opcodes/ChangeLog: + + * riscv-dis.c (print_reg_list): New function, used to get zcmp + reg_list field. + (riscv_get_spimm): New function, used to get zcmp sp adjustment + immediate. + (print_insn_args): Handle new operands for zcmp. + * riscv-opc.c (riscv_get_sp_base): New function, used by gas and + objdump. Get sp base adjustment. + (riscv_opcodes): Added zcmp instructions. + +2024-04-09 mengqinggang + + LoongArch: ld: Move .got .got.plt before .data and protect .got with relro + Move .got .got.plt before .data so .got can be protected with -zrelro. + And the first two entries of .got.plt (_dl_runtime_resolve and link map) + are placed within the relro region. + +2024-04-09 Hu, Lin1 + + Support {evex} pseudo prefix for decode evex promoted insns without egpr32. + This patch is based on APX NF patch and also adds test cases for Checking 64-bit insns not sizeable through + register operands with evex. + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Added no-egpr testcases for movbe. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Added tests. + * testsuite/gas/i386/noreg64-evex.d: New test. + * testsuite/gas/i386/noreg64-evex.e: Ditto. + * testsuite/gas/i386/noreg64-evex.s: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.d: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %ME to movbe. + * i386-dis.c : Added %XE to evex_from_vex instructions to output {evex}. + (struct dis386): New %ME. + (putop): Handle %ME and output {evex} for evex_from_legacy instructions. + * Return early when the instruction name is (bad). + +2024-04-09 Alan Modra + + Remove dead code in bfdwin.c + All of bfdwin.c is wrapped in USE_MMAP. There isn't any point in + HAVE_MMAP tests inside USE_MMAP. + + * bfdwin.c (bfd_free_window, bfd_get_file_window): Delete + HAVE_MMAP conditionals. + +2024-04-09 Alan Modra + + ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + The idea here is build tests without sanitizer flags, so they don't + fail due to many not using the compiler to link and thus result in + undefined symbols, since libasan is not supplied. We definitely do not + want a compiler to perform linking in most cases, and it's complicated + to supply libasan (and would possibly disturb testcase output). + + * testsuite/config/default.exp (CFLAGS_FOR_TARGET), + (CXXFLAGS_FOR_TARGET): Append NOSANITIZE_CFLAGS. + * testsuite/ld-bootstrap/bootstrap.exp: Use CC_FOR_TARGET and + CFLAGS_FOR_TARGET throughout. + +2024-04-09 GDB Administrator + + Automatic date update in version.in + +2024-04-08 H.J. Lu + + ld: Add PR ld/31615 tests + PR ld/31615 + * testsuite/ld-plugin/lto.exp: Run ld/31615 tests. + * testsuite/ld-plugin/pr31615.ver: New file. + * testsuite/ld-plugin/pr31615a.c: Likewise. + * testsuite/ld-plugin/pr31615b.c: Likewise. + * testsuite/ld-plugin/pr31615c.c: Likewise. + * testsuite/ld-plugin/pr31615d.c: Likewise. + +2024-04-08 Alexandra Hájková + + remote.c: Make packet_ok return struct packet_result + This allows the error message stored in a packet_result to be easily + printed in the calling function. + + Approved-By: Andrew Burgess + +2024-04-08 Alexandra Hájková + + remote.c: Use packet_check_result + when processing the GDBserver reply to qRcmd packet. + Print error message or the error code. + Currently, when qRcmd request returns an error, + GDB just prints: + + Protocol error with Rcmd + + After this change, GDB will also print the error code: + + Protocol error with Rcmd: 01. + + Add an accept_msg argument to packet_check result. qRcmd + request (such as many other packets) does not recognise + "E.msg" form as an error right now. We want to recognise + "E.msg" as an error response only for the packets where + it's documented. + + Also use packet_check result in remote_read_bytes_1. + + Approved-By: Andrew Burgess + +2024-04-08 Andrew Burgess + + gdb/configure: realign the AC_ARG_ENABLE(sim, ....) block + Following the suggestion in this review comment: + + https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca + + this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added + additional [...] quoting in a couple of places, which is inline with + how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac + file. + + There should be no change in how GDB configures or builds after this + commit. + +2024-04-08 Andrew Burgess + + gdb/build: apply silent-rules.mk to the data-directory Makefile.in + This commit makes use of gdb/silent-rules.mk in the data-directory + Makefile.in. I've only updated the rules that actually generate + things, I've not touched the install or uninstall rules, this matches + gdb/Makefile.in. + + I've not managed to completely silence all of the recipe output, the + mkinstalldirs command outputs some diagnostic text which looks like + this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I have a patch for mkinstalldirs that fixes this (by adding a new + --silent command line flag), but that patch needs to be submitted to + automake, then an updated mkinstalldirs sync'd to the gcc repository, + and then copied into the binutils-gdb repository... so I'm leaving + that for a future project. + + Then the guild compiler also emits some diagnostic output, which looks + like this: + + GEN stamp-guile + mkdir -p -- ./guile/. + mkdir -p -- ./guile/gdb + wrote `./gdb.go' + wrote `gdb/experimental.go' + wrote `gdb/iterator.go' + wrote `gdb/printing.go' + wrote `gdb/support.go' + wrote `gdb/types.go' + + The 'wrote' lines are from the guild compiler. The only way to + silence these would be to redirect stdout to /dev/null I think. I did + prototype this, but wasn't 100% convinced about that part of the + patch, so I've decided to leave that for another day. + + I did need to add a new SILENT_ECHO variable to silent-rules.mk, this + is set to a suitable 'echo' command to use within recipes. When we + are in silent mode then I use the 'true' command, while in verbose + mode we actually use 'echo'. + + So, other than the issues outlined above, the output when building the + data-directory is now greatly reduced, and more inline with the output + when building in the gdb/ directory. + + There should be no change in what is actually built after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/configure: use AC_MSG_NOTICE not a direct echo call + After the recent commits, I noticed that GDB's configure script would + still emit two lines even when run in silent mode. If you touch + gdb/Makefile.in and then run 'make all' in the gdb/ build directory + you'll see this: + + GEN config.status + enable_sim = no + enableval = no + + Obviously the 'no' might be 'yes' depending on how you actually + configured GDB. + + This is caused by two direct invocations of 'echo' in GDB's + configure.ac script. + + In this commit I replace these calls with use of AC_MSG_NOTICE + instead. Now when configure is run with the --silent command line + option these lines will not be printed. + + There should be no changes in the built GDB after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: Print 'GEN' message, and pass SILENT_FLAG more + The targets that use config.status to regenerate themselves don't + currently follow the silent rules that the rest of GDB's Makefile + does. For example, touch the gdb/gcore.in file and then 'make all' in + the gdb/ directory prints: + + /bin/sh config.status gcore + config.status: creating gcore + + In this commit I make use of the silent-rules.mk mechanism for these + targets, now we get: + + GEN gcore + + Which matches the rest of our Makefile. Obviously, if you pass 'V=1' + to the build then you'll get the old output back. + + There's no change in what is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add some missing config.status dependencies + I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py, + and gdb-gdb.gdb the rules all use the config.status script, but don't + have a dependency on the config.status target. This means we might + fail to regenerate these targets in a case where config.status, or one + of its dependencies changes. + + Two other targets that use config.status do correctly have a + dependency on config.status. + + Fixed in this commit by adding the missing dependencies. + + There should be no changes in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: rewrite dependencies for config.status target + I noticed something weird, the rule for the config.status target looks + like this: + + config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh + $(SHELL) config.status --recheck + + What bothered me is that 'configure' is specified as being in + $(srcdir), while all of the other files are not, even though those + files are in the same $(srcdir) as the configure script. + + However, I tried touching one of those files, and the config.status + rule does trigger! + + This is thanks to the VPATH variable, which is set to $(srcdir), so + make looks in $(srcdir) for any dependencies. + + However, this inconsistency bothers me. Better, I think, to add the + $(srcdir) prefix to each of these files. + + I also spotted that the configure script also includes the files + ../bfd/config.bfd, yet that is missing from the include list, so in + this commit I plan to add this as a dependency. + + The configure script also pulls in two TCL and TK related files: + + . ${TCL_BIN_DIR}/tclConfig.sh + . ${TK_BIN_DIR}/tkConfig.sh + + However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently + visible in GDB's Makefile, so I'm not planning to add these + dependencies at this time. + + In this commit I add a new variable config_status_deps which holds the + list of all the dependencies for config.status, with the $(srcdir) + prefix included, and then I use this in the config.status rule. + + After this commit config.status will regenerate if config.bfd changes, + which it wouldn't before, but nothing else changes. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add gcore to the 'all' target dependency list + The gcore script is initially generated by the configure process, just + like gdb-gdb.gdb and gdb-gdb.py. However if the gdb/gcore.in input + source is modified then 'make all' in the gdb/ directory does not + regenerate the gcore script. + + This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their + input is updated then 'make all' will regenerate these files. + + The difference is that for gdb-gdb.* there is an explicit dependency + between the 'all' target and the generated file, this dependency is + missing for gcore. + + This commit adds the dependency. Now, if gcore.in is changed, running + 'make all' will regenerate the gcore script. + + There is no change in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Simon Marchi + + gdb: ignore -Wregister instead of -Wdeprecated-register + When building GDB on Centos 7 (which has flex 2.5.37) and Clang, I get: + + $ make ada-exp.o + YACC ada-exp.c + LEX ada-lex.c + CXX ada-exp.o + In file included from /home/smarchi/src/binutils-gdb/gdb/ada-exp.y:1179: + :1106:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] + 1106 | register yy_state_type yy_current_state; + | ^~~~~~~~ + + In ada-lex.l, we already use `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER`, + which for Clang translates to ignoring `-Wdeprecated-register` [1]. I think + that was produced when compiling as C++11, but now that we always compile as + C++17, Clang produces a `-Wregister` error [2]. + + For GCC, `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` already translates to + ignoring `-Wregister`. So, rename + `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` to `DIAGNOSTIC_IGNORE_REGISTER` + and ignore `-Wregister` for Clang too. + + [1] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wdeprecated-register + [2] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wregister + + include/ChangeLog: + + * diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Rename + to... + (DIAGNOSTIC_IGNORE_REGISTER): ... this. Ignore `-Wregister` + instead of `-Wdeprecated-register`. + + Change-Id: I8a4a51c7222c68577fa22ecacdddfcba32d9dbc5 + +2024-04-08 Alan Modra + + Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 + Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be + created, resulting in _bfd_generic_link_add_one_symbol never + returning. Fix that. Note that the MIND case handles two types of + redefinition. For a new indirect symbol we'll have string non-NULL. + For a new def, string will be NULL. So moving the string comparison + earlier would work. However, we've already looked up inh in the first + case so can dispense with name comparisons. Either way, for a new def + we'll get to the defweak test and possibly cycle. Which is what we + want here. + + PR 31615 + PR 26978 + * linker.c (_bfd_generic_link_add_one_symbol ): Test for + exactly matching indirect symbols before cycling on a defweak. + +2024-04-08 GDB Administrator + + Automatic date update in version.in + +2024-04-07 Cui, Lili + + Support APX NF + For the case when NDD and NF are both 0 in evex-promoted format, + we will fully support and test it in another patch. + + gas/ChangeLog: + + * NEWS: Support Intel APX NF. + * config/tc-i386.c (enum i386_error): Add unsupported_nf. + (struct _i386_insn): Add has_nf. + (is_apx_evex_encoding): Ditto. + (build_apx_evex_prefix): Encode the NF bit. + (md_assemble): Handle unsupported_nf. + (parse_insn): Handle Prefix_NF and report bad for illegal combination. + (can_convert_NDD_to_legacy): Replace i.tm.opcode_modifier.nf with i.has_nf. + (match_template): Support D for APX_F insns and check NF support. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add bad test for NF bit. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add apx nf tests. + * testsuite/gas/i386/x86-64-apx-nf-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-nf.d: Ditto. + * testsuite/gas/i386/x86-64-apx-nf.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Add %NF to the instructions that support APX NF and + add new instruction imul, popcnt, tzcnt and lzcnt to EVEX table. + * i386-dis-evex-reg.h: Ditto. + * i386-dis.c (struct instr_info): Add nf. + (struct dis386): Add "NF" for EVEX.NF. + (get_valid_dis386): Set ins->vex.nf and report bad-nf for illegal case. + (print_insn): Handle ins.vex.nf. + (putop): Handle "%NF". + * i386-opc.h (Prefix_NF): New. + * i386-opc.tbl: Added new entries to support full APX NF instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Regenerated. + +2024-04-07 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Call bfd_malloc instead xmalloc + * elflink.c (elf_link_add_object_symbols): Call bfd_malloc + instead of xmalloc. + +2024-04-06 H.J. Lu + + Revert "x86: Restore APX shift-double instructions with omitted shift count" + This reverts commit c2d698fe03a6092d58a07de96068b87836daced0. + + GCC 14 has been changed to use explicit shift count in shift-double + instructions by the commit: + + 06a7e7514af x86: Use explicit shift count in double-precision shifts + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Remove tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Remove APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-06 Alan Modra + + Don't have first_hash entries of strings that can be freed. + Seen running "LTO 1" under valgrind. + ==1443263== Invalid read of size 1 + ==1443263== at 0x484CFE4: strcmp (vg_replace_strmem.c:939) + ==1443263== by 0x56E16C: bfd_hash_lookup (hash.c:564) + ==1443263== by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316) + ==1443263== by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + ==1443263== Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd + ==1443263== at 0x484810F: free (vg_replace_malloc.c:974) + ==1443263== by 0x8D4D87: objalloc_free_block (objalloc.c:248) + ==1443263== by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + + PR ld/31482 + PR ld/31489 + * elflink.c (elf_link_add_to_first_hash): Add "copy" param. + (elf_link_add_object_symbols): Flag that name must be copied + when appending version string to symbol name. + +2024-04-06 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Use elf_link_first_hash_entry for first_hash + Add elf_link_first_hash_entry and use it for first_hash. Free first_hash + before freeing the main hash table. + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Change first_hash to + bfd_hash_table. + * elflink.c (elf_link_first_hash_entry): New. + (elf_link_first_hash_newfunc): Likewise. + (elf_link_add_to_first_hash): Updated. + (elf_link_add_object_symbols): Initialize first_hash with + elf_link_first_hash_newfunc. + (elf_link_add_object_symbols): Updated. + (elf_link_add_archive_symbols): Likewise. + (_bfd_elf_link_hash_table_free): Free first_hash before freeing + the main hash table. + +2024-04-05 H.J. Lu + + elf: Always honor the first definition in shared object and archive + GCC doesn't put builtin function symbol references, which are defined in + the shared C library, in the IR symbol table. When linker rescans shared + objects and archives for newly added symbol references generated from the + IR inputs, it skips definitions of the builtin functions in shared + objects and archives. + + Add first_hash to elf_link_hash_table to track unreferenced definitions + defined first in shared objects and archives. Always use them to resolve + any references. + + bfd/ + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Add first_hash. + * elflink.c (elf_link_add_to_first_hash): New function. + (elf_link_add_object_symbols): Initialize first_hash for an IR + input. Always use the first definition in shared object. Add + the first unreferenced dynamic definition to first_hash. + (_bfd_elf_archive_symbol_lookup): Add the first unreferenced + definition to first_hash.. + (elf_link_add_archive_symbols): Use the symbol definition in + archive if symbol is defined first in this archive. + (_bfd_elf_link_hash_table_free): Also free first_hash. + + ld/ + + PR ld/31482 + PR ld/31489 + * testsuite/ld-plugin/lto.exp: Add PR ld/31482 and PR ld/31489 + tests. + * testsuite/ld-elf/pr31482a-no-lto.c: New file. + * testsuite/ld-elf/pr31482b-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482c-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482d-no-lto.c: Likewise. + * testsuite/ld-plugin/pass1.out: Likewise. + * testsuite/ld-plugin/pr31482a.c: Likewise. + * testsuite/ld-plugin/pr31482b.c: Likewise. + * testsuite/ld-plugin/pr31482c.c: Likewise. + +2024-04-05 Zhiqing Xiong + + Add support for Windows network paths to the UNC support in _bfd_real_open(). + PR 31527 + +2024-04-05 Christophe Lyon + + Add missing install-dvi and install-ps Makefie targets. + For some reason, these targets are missing although others from the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + +2024-04-05 H.J. Lu + + bfd: Munmap readonly memory after bfd_free_cached_info + Munmap readonly memory after bfd_free_cached_info which may use munmapped + readonly memory. + + PR ld/31608 + * opncls.c (_bfd_delete_bfd): Munmap readonly memory after + bfd_free_cached_info. + +2024-04-05 GDB Administrator + + Automatic date update in version.in + +2024-04-04 H.J. Lu + + bfd_mmap_local: Check offset and size + Update bfd_mmap_local to return NULL if filesize < offset or filesize - + offset < rsize. + + * libbfd.c (bfd_mmap_local): Validate offset and size against + the file size. + +2024-04-04 H.J. Lu + + bfd: Handle bmmap failure in _bfd_mmap_read_temporary + iovec->bmmap may return MAP_FAILED, which happens in GDB on objects with + iovec == opncls_iovec. Update _bfd_mmap_read_temporary to handle + iovec->bmmap failure. + + * libbfd.c (_bfd_mmap_read_temporary): Handle iovec->bmmap + failure. + +2024-04-04 H.J. Lu + + x86: Restore APX shift-double instructions with omitted shift count + Restore APX shift-double instructions with omitted shift count since + they are generated by GCC as shown in: + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Add tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Restore APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-04 Tom Tromey + + Add flake8 and isort to .pre-commit-config.yaml + This adds flake8 and isort to .pre-commit-config.yaml. This way, they + will automatically be run on commit. + + I chose the most recent available versions after verifying that they + don't cause any reports or changes in the current tree. + + Internally at AdaCore, we also use a few flake8 plugins as well, so + perhaps that's another avenue for investigation. + + v2: Also update the various file-selection clauses to pick up + gdb-gdb.py.in; include the isort change made to this file; and finally + add a comment about the exclusions from flake8. + + Approved-By: Simon Marchi + +2024-04-04 Bernd Edlinger + + Fix a test failure in gdb.threads/stepi-over-clone.exp + When the XML support was disabled at compile time, + the test case gdb.threads/stepi-over-clone.exp fails + with lots of time-outs, which can be annoying. + This makes the test case unsupported instead. + + Approved-By: Tom Tromey + +2024-04-04 Alan Modra + + MIPS HI16 and LO16 reloc howtos + All the HI16 reloc howtos should have a rightshift of 16, and all the + LO16 relocs shouldn't complain on overflow. This was correct for + R_MIPS_LO16 and R_MIPS_LO16 (at least on the howto_table_rel entries), + and corresponding MIPS16, MICROMIPS and MIPS64 relocs, but not on many + other HI16 and LO16 relocs. + + While we're at it, fix the HIGHER and HIGHEST rightshift too. + + These changes are necessary to support addends outside the range + [0,32767] when those addends are stored in section contents. Note + that some of the reloc howtos changed here will always have zero + addends (GOT_HI16, CALL_HI16). Those don't really need changing, but + use what is clearly correct for hi16 relocs anyway. + + PR 19977 + * elf32-mips.c: Correct rightshift for HI16, HIGHER and HIGHEST + reloc howtos. Correct complain_on_overflow for LO16 relocs. + * elf64-mips.c: Likewise. + * elfn32-mips.c: Likewise. + +2024-04-04 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: left shift of 1 by 31 places cannot be represented in type 'int' + + * objcopy.c (setup_section): Avoid undefined behaviour when + checking vma and lma for alignment. + +2024-04-04 Nandakumar Edamana + + dlltool: replace unchecked malloc with xmalloc + +2024-04-04 Alan Modra + + Memory corruption with USE_MMAP + mips64-linux-gnuabi64 +FAIL: GOT page 4 (two files) + mipsel-linux-gnu +FAIL: GOT page 4 (two files) + mipsisa32el-linux-gnu +FAIL: GOT page 4 (two files) + mips-linux-gnu +FAIL: GOT page 4 (two files) + powerpc64-freebsd +FAIL: relocatable relaxing large + powerpc64le-linux-gnu +FAIL: relocatable relaxing large + powerpc64-linux-gnu +FAIL: relocatable relaxing large + powerpc-eabisim +FAIL: relocatable relaxing large + powerpc-eabivle +FAIL: relocatable relaxing large + powerpc-freebsd +FAIL: relocatable relaxing large + powerpcle-elf +FAIL: relocatable relaxing large + powerpc-linux-gnu +FAIL: relocatable relaxing large + + * elflink.c (bfd_elf_final_link): Heed bed->use_mmap when + sizing buffers, not just USE_MMAP. + +2024-04-04 Alan Modra + + Re: USE_MMAP fuzzed object file attacks + I committed a broken patch. + + * aoutx.h (aout_get_external_symbols): Remove wrong #else and + unneeded casts. + * pdp11.c (aout_get_external_symbols): Likewise. + +2024-04-04 Alan Modra + + Fix uninitialised variable errors + Commit c6291d749aec introduced a number of errors, found by clang. + + elf.c:456:7: error: variable 'alloc_ext_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (_bfd_mul_overflow (symcount, extsym_size, &amt)) + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elf.c:464:7: error: variable 'alloc_extshndx_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (bfd_seek (ibfd, pos, SEEK_SET) != 0 + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:2837:11: error: variable 'alloc1_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (internal_relocs == NULL) + ^~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:12595:16: error: variable 'ext_size' set but not used [-Werror,-Wunused-but-set-variable] + size_t ext_size = 0; + + * elf.c (bfd_elf_get_elf_syms): Fix use of uninitialised variables. + * elflink.c (_bfd_elf_link_info_read_relocs): Likewise. + (bfd_elf_final_link): Fix set but not used warning. + +2024-04-04 Alan Modra + + USE_MMAP fuzzed object file attacks + If mmap is used without sanity checking, then we'll get a SIGBUS if + an access is done to the mmap'd memory corresponding to a page past + end of file. + + * aoutx.h (aout_get_external_symbols): Check that mmap regions + are within file contents. Catch stringsize overflow. + (some_aout_object_p): Don't clear already zeroed fields. Tidy. + * pdp11.c: As for aoutx.h. Copy some fixes too. + +2024-04-04 GDB Administrator + + Automatic date update in version.in + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_link_m[un]map_section_contents + To copy input section contents, add _bfd_elf_link_mmap_section_contents + and _bfd_elf_link_munmap_section_contents to mmap in the input sections. + + * elf-bfd.h (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elf.c (elf_mmap_section_contents): New. + (_bfd_elf_mmap_section_contents): Use it. + (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elflink.c (elf_link_input_bfd): Call + _bfd_elf_link_mmap_section_contents instead of + bfd_get_full_section_contents. Call + _bfd_elf_link_munmap_section_contents to munmap the section + contents. + (bfd_elf_final_link): When mmap is used, initialize + max_contents_size to _bfd_minimum_mmap_size and increase it + for compressed or linker created sections or sections whose + rawsize != size. + +2024-04-03 H.J. Lu + + elf: Always keep symbol table and relocation info for eh_frame + When --no-keep-memory is used, the symbol table and relocation info for + eh_frame are freed after they are retrieved for each text section in the + input object. If an input object has many text sections, the same data + is retrieved and freed many times which can take a very long time. + Update _bfd_elf_gc_mark to keep the symbol table and relocation info for + eh_frame to avoid it. Data to link the 3.5GB clang executable in LLVM + 17 debug build on Linux/x86-64 with 32GB RAM is: + + before after improvement + user 86.31 86.44 -0.2% + system 8.77 8.63 1.6% + total 95.58 96.81 -1.3% + maximum set(GB) 13.1 13.1 0% + page faults 3024752 3028699 -1.3% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.49 5.46 -0.5% + system 0.73 0.73 0% + total 6.26 6.25 0.3% + maximum set(MB) 964 964 0% + page faults 235173 235796 -0.3% + + The memory usage impact is minimum and the link time of the Rust binary + in + + https://sourceware.org/bugzilla/show_bug.cgi?id=31466 + + is reduced from 500+ seconds to 1.44 seconds, a 300x speedup. + + PR ld/31466 + * elflink.c (init_reloc_cookie): Add a bool argument, keep_memory, + for keeping memory. Always keep memory if keep_memory is true. + (init_reloc_cookie_rels): Likewise + (init_reloc_cookie_for_section): Add a bool argument for keeping + memory and pass it to init_reloc_cookie and + init_reloc_cookie_rels. + (_bfd_elf_gc_mark_reloc): Pass false to _bfd_elf_gc_mark. + (_bfd_elf_gc_mark): Pass true to init_reloc_cookie_for_section + for the eh_frame section. Pass false to + init_reloc_cookie_for_section for other sections. + (_bfd_elf_gc_mark_extra_sections): Add Add a bool argument for + keeping memory and pass it to _bfd_elf_gc_mark. + (bfd_elf_parse_eh_frame_entries): Pass false to init_reloc_cookie + and init_reloc_cookie_rels. + (bfd_elf_gc_sections): Pass false to init_reloc_cookie_for_section + and _bfd_elf_gc_mark. + (bfd_elf_discard_info): Pass false to + init_reloc_cookie_for_section and init_reloc_cookie. + +2024-04-03 H.J. Lu + + elf: Don't cache symbol nor relocation tables with mmap + During a "-j 8" LLVM 17 debug build on a machine with 32GB RAM and 16GB + swap, ld was killed by kernel because of out of memory: + + [79437.949336] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-9.scope,task=ld,pid=797431,uid=1000 + [79437.949349] Out of memory: Killed process 797431 (ld) total-vm:9219600kB, anon-rss:6558156kB, file-rss:1792kB, shmem-rss:0kB, UID:1000 pgtables:17552kB oom_score_adj:0 + + Don't cache symbol nor relocation tables if they are mapped in. Data to + link the 3.5GB clang executable in LLVM 17 debug build on Linux/x86-64 + with 32GB RAM is: + + stdio mmap improvement + user 86.73 87.02 -0.3% + system 9.55 9.21 3.6% + total 100.40 97.66 0.7% + maximum set(GB) 17.34 13.14 24% + page faults 4047667 3042877 25% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.41 5.44 -0.5% + system 0.80 0.76 5% + total 6.25 6.26 -0.2% + maximum set(MB) 1323 968 27% + page faults 323451 236371 27% + + These improve the overall system performance for parallel build by + reducing memory usage and page faults. + + Also rename _bfd_link_keep_memory to _bfd_elf_link_keep_memory. Since + the --no-keep-memory linker option causes: + + https://sourceware.org/bugzilla/show_bug.cgi?id=31458 + + this is opt-in by each backend. + + bfd/ + + * elf32-i386.c (elf_i386_scan_relocs): Remove + _bfd_link_keep_memory. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + * elflink.c (_bfd_elf_link_keep_memory): New. + (_bfd_elf_link_iterate_on_relocs): Replace _bfd_link_keep_memory + with _bfd_elf_link_keep_memory. + (elf_link_add_object_symbols): Likewise. + (init_reloc_cookie): Likewise. + (init_reloc_cookie_rels): Likewise. + * libbfd-in.h (_bfd_link_keep_memory): Removed. + * linker.c (_bfd_link_keep_memory): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in symbol and relocation tables + Add _bfd_mmap_read_temporary to mmap in symbol tables and relocations + whose sizes >= 4 * page size. For the final link, allocate an external + relocation buffer of 4 * page size to avoid using mmap and munmap on + smaller relocation sections. Since _bfd_mmap_read_temporary allocates + buffer as needed, its callers don't need to. + + When mmap is used to map in all ELF sections, data to link the 3.5GB + clang executable in LLVM 17 debug build on Linux/x86-64 with 32GB RAM + is: + + stdio mmap improvement + user 84.79 85.27 -0.5% + system 10.95 9.09 17% + total 97.91 94.90 3% + page faults 4837944 4033778 17% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build + is: + + user 5.31 5.33 -0.4% + system 0.86 0.76 12% + total 6.19 6.13 1% + page faults 361273 322491 11% + + * elf.c (bfd_elf_get_elf_syms): Don't allocate buffer for external + symbol table. Replace bfd_read with _bfd_mmap_read_temporary. + * elflink.c (elf_link_read_relocs_from_section): Add 2 arguments + to return mmap memory address and size. + (_bfd_elf_link_info_read_relocs): Don't allocate buffer for + external relocation information. Replace bfd_read with + _bfd_mmap_read_temporary. + (bfd_elf_final_link): Cache external relocations up to + _bfd_minimum_mmap_size bytes when mmap is used. + * libbfd.c (_bfd_mmap_read_temporary): New. + * libbfd-in.h (_bfd_mmap_read_temporary): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_m[un]map_section_contents + Add _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents. + A backend must opt-in to use mmap. It should replace + + bfd_malloc_and_get_section -> _bfd_elf_mmap_section_contents + free -> _bfd_elf_munmap_section_contents + + on section contents. + + * compress.c (bfd_get_full_section_contents): Don't allocate + buffer if mmapped_p is true. + * elf-bfd.h (elf_backend_data): Add use_mmap. + (bfd_elf_section_data): Add contents_addr and contents_size. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. + * elf.c (_bfd_elf_make_section_from_shdr): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_elf_print_private_bfd_data): Likewise. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf32-i386.c (elf_i386_scan_relocs): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + (elf_x86_64_get_synthetic_symtab): Likewise. + * elfcode.h (elf_checksum_contents): Likewise. + * elflink.c (elf_link_add_object_symbols): Likewise. + (bfd_elf_get_bfd_needed_list): Likewise. + * elfxx-target.h (elf_backend_use_mmap): New. + (elfNN_bed): Add elf_backend_use_mmap. + * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_x86_elf_get_synthetic_symtab): Replace free with + _bfd_elf_munmap_section_contents. + * elfxx-x86.h (elf_backend_use_mmap): New. + * libbfd.c: Include "elf-bfd.h". + (_bfd_generic_get_section_contents): Call bfd_mmap_local for + mmapped_p. + * opncls.c (_bfd_delete_bfd): Also munmap ELF section contents. + * section.c (asection): Add mmapped_p. + (BFD_FAKE_SECTION): Updated. + (bfd_malloc_and_get_section): Add a sanity check for not + mmapped_p. + * bfd-in2.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in read-only sections + There are many linker input files in LLVM debug build with huge string + sections. All these string sections can be treated as read-only. But + linker copies all of them into memory which consumes huge amount of + memory and slows down linker significantly. + + Add _bfd_mmap_readonly_persistent and _bfd_mmap_readonly_temporary to + mmap in reado-only sections with size >= 4 * page size. + + NB: All string sections in valid ELF inputs must be null terminated. + There is no need to terminate it again and string sections are mmapped + as read-only. + + * bfd.c (bfd_mmapped_entry): New. + (bfd_mmapped): Likewise. + (bfd): Add mmapped. + * bfdwin.c (bfd_get_file_window): Use _bfd_pagesize. + * cache.c (cache_bmmap): Remove pagesize_m1 and use pagesize_m1 + instead. + * elf.c (bfd_elf_get_str_section): Call + _bfd_mmap_readonly_persistent instead of _bfd_alloc_and_read. + Don't terminate the string section again. + (get_hash_table_data): Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_get_dynamic_symbols): Call _bfd_mmap_readonly_persistent + instead of _bfd_alloc_and_read. Don't terminate the string + section again. Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_slurp_version_tables): Call _bfd_mmap_readonly_temporary + and _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + * elflink.c (bfd_elf_link_record_dynamic_symbol): Use bfd_malloc + to get the unversioned symbol. + * libbfd-in.h (_bfd_pagesize): New. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + * libbfd.c + (bfd_allocate_mmapped_page): New. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_pagesize): Likewise. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Use _bfd_pagesize. + * opncls.c (_bfd_delete_bfd): Munmap tracked mmapped memories. + * sysdep.h (MAP_ANONYMOUS): New. Define if undefined. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-04-03 Lancelot SIX + + Revert "gdb/compile: Use std::filesystem::remove_all in cleanup" + This reverts commit 7bba0ad08576309763e3f41193eaa93025e10b8b. + + Tom de Vries reported that 7bba0ad0857 (gdb/compile: Use + std::filesystem::remove_all in cleanup) broke builds with gcc-7.5.0 + which mostly supports c++17, but not std::filesystem[1]. As this change + is not critical, revert it to maintain compatibility. + + [1] https://inbox.sourceware.org/gdb-patches/a06e6483-aa2e-4b8a-854f-e369a1e961ea@suse.de/ + + Change-Id: I58150bd27600c95052bdf1bbbd6b44718a5a0bbf + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Approved-By: Tom Tromey + +2024-04-03 Tankut Baris Aktemur + + doc: add the missing 'handle' attribute in xml + The XML response to the "qXfer:threads:read" packet may include + a "handle" attribute. The attribute is mentioned in the document + but not shown in the sample XML structure. Add it. + + Reviewed-By: Eli Zaretskii + +2024-04-03 Lancelot SIX + + gdb/compile: Use std::filesystem::remove_all in cleanup + In a previous review, I noticed that some code in gdb/compile/compile.c + could use c++17's `std::filesystem::remove_all` instead of using some + `system ("rm -rf ...");`. + + This patch implements this. + + Note that I use the noexcept overload of std::filesystem::remove_all and + explicitly check for an error code. This means that this code called + during the cleanup procedure cannot throw, and does not risk preventing + other cleanup functions to be called. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Change-Id: If5668bf3e15e66c020e5c3b4fa999f861690e4cf + Approved-By: Tom Tromey + +2024-04-03 Lancelot SIX + + gdb: ensure has dwarf info before reading DWZ file + I recent change (e9b738dfbdc "Avoid race when reading dwz file") moved + the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to + dwarf2_has_info. + + Before that patch, dwarf2_initialize_objfile was only called when + dwarf2_has_info returned true, and since that patch it is always called. + + When reading a file that has no debug info (.debug_info/.debug_abbrev + sections), but has a .gnu_debugaltlink section, GDB’s behavior is + different. I can observe this when loading + /lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging + any program dynamically loading this library). + + Before e9b738dfbdc, we had: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + while after we have: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + + warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3 + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + This patch restores the previous behavior of only trying to load the + DWZ file for objfiles when the main part of the debuginfo is present + (i.e. when dwarf2_has_info returns true). We still make sure that + dwarf2_read_dwz_file is called at most once per objfile. + + A consequence of this change is that the per_bfd->dwz_file optional + object can now remain empty (instead of containing a nullptr), so also + this patch also adjusts dwarf2_get_dwz_file to account for this + possibility. This effectively reverts the changes to + dwarf2_get_dwz_file done by e9b738dfbdc. + + Regression tested on x86_64-linux-gnu Ubuntu 22.04. + + Approved-By: Tom Tromey + +2024-04-03 Nick Clifton + + Fix null pointer dereference in process_debug_info() + + Extend objdump's --show-all-symbols option so that it also shows the extra symbols referenced by an instruction. + +2024-04-03 Jan Beulich + + Arm64: check tied operand specifier in aarch64-gen + Make sure that field actually matches the specified operands. Don't + follow existing F_PSEUDO checking in using assertions, though. Print + meaningful error messages, thus - while not having a line number + available - at least providing some indication of where things are + wrong. + + Fix SVE2.1's extq accordingly, but don't extend the testsuite there: + There are further issues with its operands (SVE_Zm_imm4 doesn't look to + be correct to use there, as that describes an indexed vector register, + while here a separate vector register and immediate operand are to be + specified). + +2024-04-03 Jan Beulich + + x86: add missing No_qSuf to non-64-bit PTWRITE + While largely benign, it still should have been put there when the + original single template was split (commit a04973848dc5). + + x86: drop stray Size64 from WRSSQ + Like for WRUSSQ it's not needed here. The legacy insn had gained it in + the course of zapping Rex64, but that attribute wasn't needed here + either. The APX insn then simply gained it by copy-and-paste, I suppose. + +2024-04-03 Cui, Lili + + x86/APX: Remove KEYLOCKER and SHA promotions from EVEX MAP4 + APX spec removed KEYLOCKER and SHA promotions from EVEX MAP4. + https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html + + gas/ChangeLog: + + * NEWS: Mention that remove KEYLOCKER and SHA promotions from EVEX + * MAP4. + * config/tc-i386.c (process_operands): Removed special handling of + * KEYLOCKER and SHA. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Removed KEYLOCKER + * and SHA instructions. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Removed KEYLOCKER and SHA instructions. + * i386-dis-evex.h: Ditto. + * i386-opc.tbl: Ditto. + * i386-dis.c (print_vector_reg): Removed special handling of KEYLOCKER + * and SHA. + +2024-04-03 GDB Administrator + + Automatic date update in version.in + +2024-04-02 Tom Tromey + + libiberty: Invoke D demangler when --format=auto + Investigating GDB PR d/31580 showed that the libiberty demangler + doesn't automatically demangle D mangled names. However, I think it + should -- like C++ and Rust (new-style), D mangled names are readily + distinguished by the leading "_D", and so the likelihood of confusion + is low. The other non-"auto" cases in this code are Ada (where the + encoded form could more easily be confused by ordinary programs) and + Java (which is long gone, but which also shared the C++ mangling and + thus was just an output style preference). + + This patch also fixed another GDB bug, though of course that part + won't apply to the GCC repository. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276 + + libiberty + * cplus-dem.c (cplus_demangle): Try the D demangler with + "auto" format. + * testsuite/d-demangle-expected: Add --format=auto test. + +2024-04-02 Tom Tromey + + Print type name when printing Rust slice + The recent change to how unsized Rust values are printed included a + small regression from past behavior. Previously, a slice's type would + be printed, like: + + (gdb) print slice + $80 = &[i32] [3] + + The patch changed this to just + + (gdb) print slice + $80 = [3] + + This patch restores the previous behavior. + + Reviewed-By: Simon Marchi + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517 + +2024-04-02 Tom Tromey + + Constify ada-lex.l:attributes + While examining the Ada parser globals with 'nm', I noticed that the + lexer's "attributes" array should be const. This change moves it into + read-only storage. + + Remove "numbuf" global + The lexer has a "numbuf" global that is only used for temporary + storage. This patch removes the global and redeclares it at the + points of use. + + Move "returned_complete" into ada_parse_state + This moves the "returned_complete" global into ada_parse_state. + + Move "paren_depth" into ada_parse_state + This moves the "paren_depth" global into ada_parse_state. + + Move "temp_parse_space" into ada_parse_state + This patch moves the "temp_parse_space" global into ada_parse_state. + It is also renamed to remove the redundant "parse". Finally, it is + changed to an auto_obstack to avoid the need for any manual + management. + + Move "iterated_associations" into ada_parse_state + This patch moves the "iterated_associations" global into + ada_parse_state. + + Move "assignments" global into ada_parse_state + This patch moves the "assignments" global into ada_parse_state. + + Move "components" and "associations" into ada_parse_state + This patch moves the "components" and "associations" globals into + ada_parse_state. + + Move "int_storage" global into ada_parse_state + This patch moves the "int_storage" global into ada_parse_state. + +2024-04-02 Tom Tromey + + Introduce ada_parse_state + This patch introduces the ada_parse_state class and the ada_parser + global. It also changes find_completion_bounds to be a method of this + new type. + + Note that find_completion_bounds never used its parameter; and because + it is generally fine to use the 'pstate' global throughout the parser, + this patch removes the parameter entirely. + +2024-04-02 Tom Tromey + + Implement Ada 2022 iterated assignment + Ada 2022 includes iterated assignment for array initialization. This + patch implements a subset of this for gdb. In particular, only arrays + with integer index types really work -- currently there's no decent + way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during + parsing. Fixing this probably requires the Ada parser to take a + somewhat more sophisticated approach to type resolution; and while + this would help fix another bug in this area, this patch is already + useful without it. + + Introduce and use aggregate_assigner type + This patch is a refactoring to add a new aggregate_assigner type. + This type is passed to Ada aggregate assignment operations in place of + passing a number of separate arguments. This new approach makes it + simpler to change some aspects of aggregate assignment behavior. + +2024-04-02 Tom Tromey + + Run isort + This patch is the result of running 'isort .' in the gdb directory. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Prepare gdb for isort + This patch prepares gdb for isort: it adds a couple of isort marker + comments where needed, and it adds an isort clause to setup.cfg. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Do not use bare "except" + flake8 warns about a bare "except". The docs point out that this will + also catch KeyboardInterrupt and SystemExit exceptions, which is + normally undesirable. Using "except Exception" catches everything + reasonable, so this patch makes this change. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress some "undefined" warnings from flake8 + flake8 warns about some identifiers in __init__.py, because it does + not realize these come from the star-imported _gdb module. This patch + suppresses these warnings. + +2024-04-02 Tom Tromey + + Specify ImportError in styling.py + styling.py has a long try/except surrounding most of the body. flake8 + warns about the final bare "except". However, this except is really + only there to catch the situation where the host doesn't have Pygments + installed. This patch changes this to only catch ImportError. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress star import errors + flake8 warns about the "from _gdb.disassembler import *" line in + disassembler.py, and a similar line from __init__.py. These line are + needed to re-export names from the corresponding C++ module, so this + patch applies the appropriate "noqa" flags. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove bare "except" from disassembler.py + flake8 complains about a bare "except" in disassembler.py. In this + case, the code purports to guard against some kind of user error + involving data structure corruption. I think it's better here to just + let the error occur -- py-disasm.c will show a stack trace in this + case. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove unused import from gdb/__init__.py + flake8 points out that the import of _gdb in gdb/__init__.py is + unused. Remove it. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Ignore unsed import in dap/__init__.py + flake8 warns about dap/__init__.py because it has a number of unused + imports. Most of these are intentional: the import is done to ensure + that the a DAP request is registered with the server object. + + This patch applies a "noqa" comment to these imports, and also removes + one import that is truly unnecessary. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Fix flake8 errors in dap/server.py + Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel") + introduced some errors into dap/server.py. A function is called but + not imported, and the wrong variable name is used. This patch + corrects both errors. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove .flake8 + I re-ran flake8 today and was puzzled to see W503 warnings. + Eventually I found out that the setup.cfg config overrides .flake8. + This patch merges the two and removes .flake8, to avoid future + confusion. + + Approved-By: Simon Marchi + +2024-04-02 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/ctf-ptype.c + On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get: + ... + gdb compile failed, ctf-ptype.c: In function 'main': + ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 242 | v_char_pointer = (char *) malloc (1); + | ^~~~~~ + ctf-ptype.c:1:1: note: include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This test program is part of GDB, the GNU debugger. + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + +2024-04-02 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit target + In an aarch32-linux chroot on an aarch64-linux system, I run into: + ... + (gdb) print x^M + $1 = 9223372036854775807^M + (gdb) FAIL: gdb.ada/verylong.exp: print x + ... + + A passing version on aarch64-linux looks like: + ... + (gdb) print x^M + $1 = 170141183460469231731687303715884105727^M + (gdb) PASS: gdb.ada/verylong.exp: print x + ... + + The difference is caused by the size of the type Long_Long_Long_Integer, which + is: + - a 128-bit signed on 64-bit targets, and + - a 64-bit signed on 32-bit target. + + Fix this by detecting the size of the Long_Long_Long_Integer type, and + handling it. + + Tested on aarch64-linux and aarch32-linux. + + Approved-By: Tom Tromey + + PR testsuite/31574 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574 + + [1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html + +2024-04-02 Nick Clifton + + Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections. Add a check for aligned sections not matching their VMAs. + +2024-04-02 Tom de Vries + + [gdb/tui] Fix centering and highlighting of current line + After starting TUI like this with a hello world a.out: + ... + $ gdb -q a.out -ex start -ex "tui enable" + ... + we get: + ... + ┌─hello.c──────────────────────────────┐ + │ 5 { │ + │ 6 printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + │ │ + └──────────────────────────────────────┘ + ... + + This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main + after resizing"), before which we had instead: + ... + ┌─hello.c──────────────────────────────┐ + │ 4 main (void) │ + │ 5 { │ + │ > 6  printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + └──────────────────────────────────────┘ + ... + + In other words, the problems are: + - the active line (source line 6) is no longer highlighted, and + - the active line is not vertically centered (screen line 2 out 6 instead of + screen line 3 out of 6). + + Fix these problems respectively by: + - in tui_enable, instead of "tui_show_frame_info (0)" using + 'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and + - in tui_source_window_base::rerender, adding centering functionality. + + Tested on aarch64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR tui/31522 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522 + +2024-04-02 H.J. Lu + + PR31458, FAIL: MIPS eh-frame 3 with --no-keep-memory + PR 31458 + bfd/ + * elf-bfd.h (_bfd_elf_link_read_relocs), + (_bfd_elf_link_info_read_relocs): Constify section. + * elflink.c: Likewise. + * elfxx-mips.c (_bfd_mips_elf_eh_frame_address_size): Read + relocs again in case --no-keep-memory. + ld/ + * testsuite/ld-mips-elf/mips-elf.exp: Run --no-keep-memory + version of eh-frame3 test. + +2024-04-02 Alan Modra + + PR 30569, delete _bfd_mips_elf_early_size_sections + PR30569 was triggered by a patch of mine 6540edd52cc0 moving the call + to always_size_sections in bfd_elf_size_dynamic_sections earlier, made + to support the x86 DT_RELR implementation. This broke mips16 code + handling stubs when --export-dynamic is passed to the linker, because + numerous symbols then became dynamic after always_size_sections. The + mips backend fiddles with symbols in its always_size_sections. Maciej + in 902e9fc76a0e had moved the call to always_size_sections to after + the export-dynamic code. Prior to that, Nathan in 04c3a75556c0 moved + it before the exec stack code, back to the start of + bfd_elf_size_dynamic_sections which was where Ian put it originally + in ff12f303355b. So the call has moved around a little. I'm leaving + it where it is, and instead calling mips_elf_check_symbols from + late_size_sections (the old size_dynamic_sections) which is now always + called. In fact, the whole of _bfd_mips_elf_early_size_sections can + be merged into _bfd_mips_elf_late_size_sections. + +2024-04-02 Alan Modra + + PR 30569, always call elf_backend_size_dynamic_sections + This largely mechanical patch is preparation for a followup patch. + + For quite some time I've thought that it would be useful to call + elf_backend_size_dynamic_sections even when no dynamic objects are + seen by the linker. That's what this patch does, with some renaming. + There are no functional changes to the linker, just a move of the + dynobj test in bfd_elf_size_dynamic_sections to target backend + functions, replacing the asserts/aborts already there. No doubt some + of the current always_size_sections functions could be moved to + size_dynamic_sections but I haven't made that change. + + Because both hooks are now always called, I have renamed + always_size_sections to early_size_sections and size_dynamic_sections + to late_size_sections. I condisdered calling late_size_sections plain + size_sections, since this is the usual target dynamic section sizing + hook, but decided that searching the sources for "size_sections" would + then hit early_size_sections and other functions. + +2024-04-02 Alan Modra + + objdump --disassemble=sym peculiarities + Given this testcase: + .text + mov $x1,%eax + f1: + mov $f1,%eax + .type f1,@function + .size f1,.-f1 + + mov $x2,%eax + f2: + mov $f2,%eax + .type f2,@function + .size f2,.-f2+0x1000 #bad size + + objdump --reloc --disassemble=f1 prints + 00000000 : + 0: b8 00 00 00 00 mov $0x0,%eax + + and objdump --reloc --disassemble=f2 prints + 0000000f : + f: b8 0f 00 00 00 mov $0xf,%eax + 10: R_386_32 .text + + It seems for f1 we get the insn before f1 and no reloc whereas, post + 159daa36fa, f2 is disassembled correctly. Some analysis says that + find_symbol_for_address may return a symbol past the current address, + and reloc skipping is broken. Fix both of these problems. + + * objdump.c (disassemble_jumps, disassemble_bytes): Replace + relppp with relpp, ie. don't update caller's rel_pp. Adjust + calls. + (disassemble_section): Skip over relocs inside loop rather + than before loop. Revert 7e538762c2c1. If given a symbol, + don't start disassembling until its address is reached. + Correct end of function calculation. + +2024-04-02 GDB Administrator + + Automatic date update in version.in + +2024-04-02 John David Anglin + + hppa: Implement PA 2.0 symbolic relocations for long displacements + The PA 2.0 architecture introduced several new load and store + instructions with long displacements. These include floating + point loads and stores for word mode, and integer and floating + point loads and stores for double words. Currently, ld does + not correctly support symbolic relocations for these instructions. + + If these are used, ld applies the standard R_PARISC_DPREL14R + relocation and corrupts the instruction. This change uses + bfd_hppa_insn2fmt to determine the correct relocation format. + + We need to check the computed displacement as the immediate + value used in these instruction must be a multiple of 4 or 8 + depending on whether the access is for a word or double word. + + A misaligned offset can potentially occur if the symbol is not + properly aligned or if $global$ (the global pointer) is not + double word aligned. $global$ is provided as a .data section + start symbol. The patch adjusts elf.sc and hppalinux.sh to + align .data to a 8-byte boundary in non-shared and non-pie + links. + + 2024-04-01 John David Anglin + + PR ld/31503 + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Output + + ld/ChangeLog: + + * emulparams/hppalinux.sh (DATA_SECTION_ALIGNMENT): Define. + * scripttempl/elf.sc: Align .data section to DATA_SECTION_ALIGNMENT + when relocating. + +2024-04-01 Alan Modra + + asan: heap-buffer-overflow objdump.c:3299 in disassemble_bytes + Fix yet another crash, this one with a fuzzed function symbol size. + The patch also corrects objdump behaviour when both --disassemble=sym + and --stop-address=value are given. Previously --disassemble=sym + overrode --stop-address, now we take the lower of the stop-address + value and the end of function. + + * objdump.c (disassemble_section): Sanity check ELF st_size. + +2024-04-01 Lulu Cai + + LoongArch: Fix the issue of excessive relocation generated by GD and IE + Currently, whether GD and IE generate dynamic relocation is + determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable. + This results in dynamic relocations still being generated in some + situations where dynamic relocations are not necessary (such as + the undefined weak symbol in static links). + + We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether + GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation, + set need_reloc to true and indx to be a dynamic index. + + At the same time, some test cases were modified to use regular + expression matching instead of complete disassembly matching. + +2024-04-01 mengqinggang + + LoongArch: gas: Ignore .align if it is at the start of a section + Ignore .align if it is at the start of a section and the alignment + can be divided by the section alignment, the section alignment + can ensure this .align has a correct alignment. + +2024-04-01 GDB Administrator + + Automatic date update in version.in + +2024-03-31 Andrew Burgess + + gdb: build dprintf commands just once in code_breakpoint constructor + I noticed in code_breakpoint::code_breakpoint that we are calling + update_dprintf_command_list once for each breakpoint location, when we + really only need to call this once per breakpoint -- the data updated + by this function, the breakpoint command list -- is per breakpoint, + not per breakpoint location. Calling update_dprintf_command_list + multiple times is just wasted effort, there's no per location error + checking, we don't even pass the current location to the function. + + This commit moves the update_dprintf_command_list call outside of the + per-location loop. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: the extra_string in a dprintf breakpoint is never nullptr + Given the changes in the previous couple of commits, this commit + cleans up some of the asserts and 'if' checks related to the + extra_string within a dprintf breakpoint. + + This commit: + + 1. Adds some asserts to update_dprintf_command_list about the + breakpoint type, and that the extra_string is not nullptr, + + 2. Given that we know extra_string is not nullptr (this is enforced + when the breakpoint is created), we can simplify + code_breakpoint::code_breakpoint -- it no longer needs to check for + the extra_string is nullptr case, + + 3. In dprintf_breakpoint::re_set we can remove the assert (this will + be checked within update_dprintf_command_list, we can also remove + the redundant 'if' check. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: change 'if' to gdb_assert in update_dprintf_command_list + I noticed in update_dprintf_command_list that we handle the case where + the bp_dprintf style breakpoint doesn't have a format and args string. + + However, I don't believe such a situation is possible. The obvious + approach certainly already catches this case: + + (gdb) dprintf main + Format string required + + If it is possible to create a dprintf breakpoint without a format and + args string then I think we should be catching this case and handling + it at creation time, rather than having GDB just ignore the situation + later on. + + And so, I propose that we change the 'if' that ignores the case where + the format/args string is empty, and instead assert that we do always + have a format/args string. The original code, that handled an empty + format/args string has existed since commit e7e0cddfb0d4, which is + when dprintf support was added to GDB. + + If I'm correct and this situation can't ever happen then there should + be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: asserts relating to extra_string/parse_extra + The goal of this commit is to better define the API for + create_breakpoint especially around the use of extra_string and + parse_extra. This will be useful in the next commit when I plan to + make some changes to create_breakpoint. + + This commit makes one possibly breaking change: until this commit it + was possible to create thread-specific dprintf breakpoint like this: + + (gdb) dprintf call_me, thread 1 "%s", "hello" + Dprintf 2 at 0x401152: file /tmp/hello.c, line 8. + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 dprintf keep y 0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1 + stop only in thread 1 + printf "%s", "hello" + (gdb) + + This feature of dprintf was not documented, was not tested, and is + slightly different in syntax to how we create thread specific + breakpoints and/or watchpoints -- the thread condition appears after + the first ','. + + I believe that this worked at all was simply by luck. We happen to + pass the parse_extra flag as true from dprintf_command to + create_breakpoint. + + So in this commit I made the choice to change this. We now pass + parse_extra as false from dprintf_command to create_breakpoint. With + this done it is assumed that the only thing in the extra_string is the + dprintf format and arguments. + + Beyond this change I've updated the comment on create_breakpoint in + breakpoint.h, and I've then added some asserts into + create_breakpoint as well as moving around some of the error + handling. + + - We now assert on the incoming argument values, + + - I've moved an error check to sit after the call to + find_condition_and_thread_for_sals, this ensures the extra_string + was parsed correctly, + + In dprintf_command: + + - We now throw an error if there is no format string after the + dprintf location. This error was already being thrown, but was + being caught later in the process. With this change we catch the + missing string earlier, + + - And, as mentioned earlier, we pass parse_extra as false when + calling create_breakpoint, + + In create_tracepoint_from_upload: + + - We now throw an error if the parsed location doesn't completely + consume the addr_str variable. This error has now effectively + moved out of create_breakpoint. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: add asserts and additional comments + This commit extends the asserts on create_breakpoint (in the header + file), and adds some additional assertions into the definition. + + The new assert confirms that when the thread and inferior information + is going to be parsed from the extra_string, then the thread and + inferior arguments should be -1. That is, the caller of + create_breakpoint should not try to create a thread/inferior specific + breakpoint by *both* specifying thread/inferior *and* asking to parse + the extra_string, it's one or the other. + + There should be no user visible changes after this commit. + +2024-03-31 mengqinggang + + BFD: Fix the bug of R_LARCH_AGLIN caused by discard section + To represent the first and third expression of .align, R_LARCH_ALIGN need to + associate with a symbol. We define a local symbol for R_LARCH_AGLIN. + But if the section of the local symbol is discarded, it may result in + a undefined symbol error. + + Instead, we use the section name symbols, and this does not need to + add extra symbols. + + During partial linking (ld -r), if the symbol associated with a relocation is + STT_SECTION type, the addend of relocation needs to add the section output + offset. We prevent it for R_LARCH_ALIGN. + + The elf_backend_data.rela_normal only can set all relocations of a target to + rela_normal. Add a new function is_rela_normal to elf_backend_data, it can + set part of relocations to rela_normal. + +2024-03-31 GDB Administrator + + Automatic date update in version.in + +2024-03-30 Tom Tromey + + Lower variable definitions in tui_redisplay_readline + I noticed a redundant assignment to 'prev_col' in + tui_redisplay_readline, and then went ahead and lowered most of the + variable definitions in that function to their initialization point. + +2024-03-30 GDB Administrator + + Automatic date update in version.in + +2024-03-29 Andrew Burgess + + gdb/testsuite: don't include port numbers in test names + The gdb.python/py-cmd-prompt.exp script includes a test that has a + gdbserver port number within a test name. As port numbers can change + from one test run to the next (depending on what else is running on + the machine at the time), this can make it hard to compare test + results between runs. + + Give the test a specific name to avoid including the port number. + + There is no change in what is tested after this commit. + +2024-03-29 Andrew Burgess + + gdb/testsuite: avoid $pc/$sp values in test names + Provide an explicit name for a test in gdb.base/pc-not-saved.exp to + avoid printing $pc and $sp values in the test name -- these values + might change between different test runs, which makes it harder to + compare test results. + + There is no change in what is actually being tested with this commit. + +2024-03-29 Tom de Vries + + [gdb/testsuite] Add missing includes in gdb.trace/collection.c + On fedora rawhide, with test-case gdb.trace/collection.exp, I get: + ... + gdb compile failed, collection.c: In function 'strings_test_func': + collection.c:227:13: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 227 | longloc = malloc(500); + | ^~~~~~ + collection.c:1:1: note: \ + include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + + collection.c:228:3: error: implicit declaration of function 'strcpy' \ + [-Wimplicit-function-declaration] + 228 | strcpy(longloc, ... ); + | ^~~~~~ + collection.c:1:1: note: include '' or provide a declaration of \ + 'strcpy' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + collection.c:230:8: error: implicit declaration of function 'strlen' \ + [-Wimplicit-function-declaration] + 230 | i += strlen (locstr); + | ^~~~~~ + collection.c:230:8: note: include '' or provide a declaration of \ + 'strlen' + ... + + Fix this by adding the missing includes. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 Tom de Vries + + [gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.c + On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I + get: + ... + gdb compile failed, break-asm-file.c:21:8: error: \ + return type defaults to 'int' [-Wimplicit-int] + 21 | static func() + | ^~~~ + ... + + Fix this by adding the missing return type. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 GDB Administrator + + Automatic date update in version.in + +2024-03-28 Tom Tromey + + Make pascal_language::print_type handle varstring==nullptr + PR gdb/31524 points out a crash when pascal_language::print_type is + called with varstring==nullptr. This crash is a regression arising + from the printf/pager rewrite -- that indirectly removed a NULL check + from gdb's "puts". + + This patch instead fixes the problem by adding a check to print_type. + Passing nullptr here seems to be expected in other places (e.g., there + is a call to type_print like this in expprint.c), and other + implementations of this method (or related helpers) explicitly check + for NULL. + + I didn't write a test case for this because it seemed like overkill + for a Pascal bug that only occurs with -i=mi. However, if you want + one, let me know and I will do it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 + Approved-By: John Baldwin + +2024-03-28 Indu Bhagat + + gas: gcfg: fix handling of non-local direct jmps in gcfg + The ginsn infrastructure in GAS includes the ability to create a GCFG + (ginsn CFG). A GCFG is currently used for SCFI passes. + + This patch fixes the following invalid assumptions / code blocks: + - The function ginsn_direct_local_jump_p () was erroneously _not_ + checking whether the symbol is locally defined (i.e., within the + scope of the code block for which GCFG is desired). Fix the code + to do so. + - Similarly, the GCFG creation code, in gcfg_build () itself had an + assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be + seen. The latter can indeed be seen, and in fact, needs to be treated + the same way as an exit from the function in terms of control-flow. + + gas/ + * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol + is local to the code block or function being assembled. + (add_bb_at_ginsn): Remove buggy assumption. + (frch_ginsn_data_append): Direct jmps do not disqualify a stream + of ginsns from GCFG creation. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cfg-3.d: New test. + * gas/scfi/x86_64/scfi-cfg-3.l: New test. + * gas/scfi/x86_64/scfi-cfg-3.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: move checking + It has always been looking a little odd to me that this was done deep + in cpu_flags_match(). Move it to match_template() itself - there's no + need to do anything complex when encountering such a template while it + cannot possibly be used. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: respect prefixes + 1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to + also do so with -msse2avx, converting to VEX.W. + + 2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2} + shouldn't either. + +2024-03-28 Jan Beulich + + gas: drop integer_constant()'s maxdig + Once properly set, it's only ever holding the same value as "radix". + Even if there was some plan with it, that plan hasn't made it anywhere + in over 20 years. + + gas: drop dead check for double quote + FB and dollar label definitions can't be enclosed in double quotes. In + fact at that point nul_char is the same as next_char, which we know is a + digit. + +2024-03-28 Jan Beulich + + gas: sanitize FB- and dollar-label uses + I don't view it as sensible to be more lax when it comes to references + to (uses of) such labels compared to their definition: The latter has + been limited to decimal numerics, while the former permitted any radix. + Beyond that leading zeroes on such labels aren't helpful either. Imo + labels and their use sites would better match literally, to avoid + confusion. + + As it turns out, one z80 testcase actually had such an odd use of labels + where definition and use don't match in spelling. That testcase is being + adjusted accordingly. + + While there also adjust a comment on a local variable in + integer_constant(). + +2024-03-28 Jan Beulich + + x86: templatize RAO-INT insns + It's only four of them, but still better to reduce redundancy. + + x86: templatize ADX insns + It's only two of them, but still better to reduce redundancy. + +2024-03-28 Jan Beulich + + x86: templatize shift-double insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the shift-double ones. + + While there also drop the APX form with ShiftCount omitted. Other shift + and rotate insns were deliberately left without this form as well. Note + that there's also no testsuite adjustment needed for this, indicating + that the form wasn't tested either. + +2024-03-28 Jan Beulich + + x86: templatize shift/rotate insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the "ordinary" shift and rotate ones. + + While there also drop the APX form of RCL/RCR with Imm1 omitted. Other + shift insns as well as ROR/ROL were deliberately left without this form + as well. Note that there's also no testsuite adjustment needed for this, + indicating that the form wasn't tested either. + + Furthermore since RCL/RCR already had non-NDD APX forms, those end up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize binary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a the more complex binary (two source) cases. + + Note how this adds a missing CheckOperandSize to one of the APX sub + forms. + + Furthermore since SBB already had a non-NDD APX form, one ends up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize unary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a few simple unary (single source) cases. + +2024-03-28 Jan Beulich + + x86: templatize INC/DEC + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Start with the simplest case, accompanied by a necessary adjustment to + i386-gen (such that template uses can also be at the start of a line). + + While there also drop a bogus (meaningless / unreachable) "break" as + well as a unused variable (which I'm surprised compilers didn't warn + about). + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux + On aarch64-linux, using the manjaro linux distro, I run into: + ... + (gdb) next^M + 32 }^M + (gdb) next^M + 0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M + (gdb) FAIL: gdb.base/ending-run.exp: step out of main + ... + + What happens here is described in detail in this clause: + ... + -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" { + # This case occurs on Powerpc when gdb steps out of main and the + # needed debug info files are not loaded on the system, preventing + # GDB to determine which function it reached (__libc_start_call_main). + # Ideally, the target system would have the necessary debugging + # information, but in its absence, GDB's behavior is as expected. + ... + } + ... + but the clause only matches for powerpc. + + Fix this by: + - making the regexp generic enough to also match /usr/lib/libc.so.6, and + - updating the comment to not mention powerpc. + + Tested on aarch64-linux. + + PR testsuite/31450 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux + When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using + the manjaro linux distro, I get: + ... + (gdb) thread apply all bt^M + ^M + Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M + #0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M + #2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M + #3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M + #4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M + #5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M + ^M + Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M + #0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M + #2 0x0000aaaade37086c in main () at attach-stopped.c:45^M + (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt + ... + + The problem is that the test-case expects to see start_thread: + ... + gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \ + "$threadtype: attach2 to stopped bt" + ... + but lack of symbols makes that impossible. + + Fix this by allowing " in ?? () from " as well. + + Tested on aarch64-linux. + + PR testsuite/31451 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/rtld-step.exp + On fedora rawhide, with test-case gdb.base/rtld-step.exp I get: + ... + static-pie-static-libc.c: In function '_start':^M + static-pie-static-libc.c:1:22: error: \ + implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M + 1 | void _start (void) { _exit (0); }^M + | ^~~~~^M + compiler exited with status 1 + ... + UNTESTED: gdb.base/rtld-step.exp: failed to compile \ + (-static-pie not supported or static libc missing) + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + +2024-03-28 Nelson Chu + + RISC-V: Removed privileged spec 1.9.1 support in assembler. + Removed since it's may have lots of conflicts with the newer extensions, but + still keep linker recognizes it in case of linking old objects. + + gas/ + * NEWS: Updated. + * config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as + an unknown version. + (md_show_usage): Removed privileged spec 1.9.1 information. + * testsuite/gas/riscv/attribute-05.s: Updated since privileged spec + 1.9.1 is unsupported. + * testsuite/gas/riscv/attribute-05.d: Likewise. + * testsuite/gas/riscv/attribute-12.d: Likewise. + * testsuite/gas/riscv/attribute-13.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. + * testsuite/gas/riscv/csr.s: Likewise. + * testsuite/gas/riscv/csr-version-1p10.d: Likewise. + * testsuite/gas/riscv/csr-version-1p10.l: Likewise. + * testsuite/gas/riscv/csr-version-1p11.d: Likewise. + * testsuite/gas/riscv/csr-version-1p11.l: Likewise. + * testsuite/gas/riscv/csr-version-1p12.d: Likewise. + * testsuite/gas/riscv/csr-version-1p12.l: Likewise. + * testsuite/gas/riscv/csr-version-1p9p1.d: Removed. + * testsuite/gas/riscv/csr-version-1p9p1.l: Removed. + include/ + * opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is + unsupported. + ld/ + * testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since + privileged spec 1.9.1 is unsupported. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise. + +2024-03-28 GDB Administrator + + Automatic date update in version.in + +2024-03-27 Tom Tromey + + Fix clang build + Simon pointed out that commit 818ef5f4 ("Capture warnings when writing + to the index cache") broke the build with clang. This patch fixes the + breakage. + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: remove includes of early headers + Now that defs.h, server.h and common-defs.h are included via the + `-include` option, it is no longer necessary for source files to include + them. Remove all the inclusions of these files I could find. Update + the generation scripts where relevant. + + Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: include early header files with `-include` + The motivation for this change is for analysis tools and IDEs to be + better at analyzing header files on their own. + + There are some definitions and includes we want to occur at the very + beginning of all translation units. The way we currently do that is by + requiring all source files (.c and .cc files) to include one of defs.h + (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and + shared source files). These special header files define and include + everything that needs to be included at the very beginning. Other + header files are written in a way that assume that these special + "prologue" header files have already been included. + + My problem with that is that my editor (clangd-based) provides a very + bad experience when editing header files. Since clangd doesn't know + that one of defs.h/server.h/common-defs.h was included already, a lot of + things are flagged as errors. For instance, CORE_ADDR is not known. + It's possible to edit the files in this state, but a lot of the power of + the editor is unavailable. + + My proposal to help with this is to include those things we always want + to be there using the compilers' `-include` option. Tom Tromey said + that the current approach might exist because not all compilers used to + have an option like this. But I believe that it's safe to assume they + do today. + + With this change, clangd picks up the -include option from the compile + command, and is able to analyze the header file correctly, as it sees + all that stuff included or defined by that -include option. That works + because when editing a header file, clangd tries to get the compilation + flags from a source file that includes said header file. + + This change is a bit self-serving, because it addresses one of my + frustrations when editing header files, but it might help others too. + I'd be curious to know if others encounter the same kinds of problems + when editing header files. Also, even if the change is not necessary by + any means, I think the solution of using -include for stuff we always + want to be there is more elegant than the current solution. + + Even with this -include flag, many header files currently don't include + what they use, but rather depend on files included before them. This + will still cause errors when editing them, but it should be easily + fixable by adding the appropriate include. There's no rush to do so, as + long as the code still compiles, it's just a convenience thing. + + The changes are: + + - Add the appropriate `-include` option to the various Makefiles. + + - There is one particularity for gdbserver's Makefile: we do not want + to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` + doesn't include it. So we can't simply put the `-include` in + `INTERNAL_CFLAGS`. Add the `-include server.h` option to the + `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule + to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. + + - Remove the `-include` option from the `check-headers` rule in + gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. + + Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + {gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables + Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their + contents in `INTERNAL_CFLAGS`. Not functional changes expected. + + Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line + Reformat some variables definitions. I think it makes them easier to + read, and it also makes diffs clearer. + + Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb: make gdbarch_types.py non-executable + I noticed that gdbarch_types.py is executable. It's not needed, since + it's only imported from gdbarch.py. + + Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e + +2024-03-27 GDB Administrator + + Automatic date update in version.in + +2024-03-26 Andrew Burgess + + Revert "gdbserver: convert have_ptrace_getregset to a tribool" + This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c. + + Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory" + This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354. + + Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description" + This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e. + + Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition" + This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54. + + Revert "gdb/gdbserver: share some code relating to target description creation" + This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd. + + Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32" + This reverts commit efba976d9713a92b4507ccfef2257e4589da2798. + + Revert "gdbserver: update target description creation for x86/linux" + This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a. + + Revert "gdb/gdbserver: share x86/linux tdesc caching" + This reverts commit 198ff6ff819c240545f9fc68b39636fd376d4ba9. + + Revert "gdbserver/Makefile.in: add missing `-x c++`" + This reverts commit c7c9820071f8b81a64221f5cfafb3cbfeafe7916. + + Revert "gdb: fix possible uninitialised variable use" + This reverts commit 24df37a10f8773ad5db07dc000f694d6405e3a36. + + Revert "gdb/gdbserver: fix some defined but unused function warnings" + This reverts commit f4c19f89ef43dbce8065532c808e1aeb05d08994. + +2024-03-26 Tom Tromey + + Remove redundant check from parse_number.exp + A user on irc pointed out that parse_number.exp has a redundant check. + This patch removes the duplicate. + +2024-03-26 Tom de Vries + + [gdb/testsuite] Fix valgrind tests on debian + On debian 12, I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + relaying data between gdb and process 618591^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + (No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M + 0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The problem is that we're expecting to match either of these regexps: + ... + set start_re1 " in \\.?_start " + set start_re2 "\\.?_start \\(\\) at " + ... + but there are no dwarf or elf symbols present. + + Fix this by also allowing: + ... + set start_re3 "$::hex in \\?\\? \\(\\) from " + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-26 Tom Tromey + + Capture warnings when writing to the index cache + PR symtab/30837 points out a race that can occur when writing to the + index cache: a call to ada_encode can cause a warning, which is + forbidden on a worker thread. + + This patch fixes the problem by arranging to capture any such + warnings. + + This is v2 of the patch. It is rebased on top of some other changes + in the same area. v1 was here: + + https://sourceware.org/pipermail/gdb-patches/2024-February/206595.html + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30837 + +2024-03-26 H.J. Lu + + Don't claim a fat IR object if no IR object should be claimed + When the linker sees an input object containing nothing but IR during + rescan, it should ignore it (LTO phase is over). But if the input object + is a fat IR object, which has non-IR code as well, it should be used to + resolve references as if it did not contain any IR at all. This patch + adds lto_type to bfd and linker avoids claiming a fat IR object if no IR + object should be claimed. + + bfd/ + + PR ld/23935 + * archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type + instead of lto_slim_object. + * elflink.c (elf_link_add_object_symbols): Likewise. + * bfd.c (bfd_lto_object_type): New. + (bfd): Remove lto_slim_object and add lto_type. + (bfd_get_lto_type): New function. + * elf.c (lto_section): Removed. + (_bfd_elf_make_section_from_shdr): Don't set lto_slim_object. + * format.c: (lto_section): New. + (bfd_set_lto_type): New function. + (bfd_check_format_matches): Call bfd_set_lto_type. + * bfd-in2.h: Regenerated. + + binutils/ + + PR ld/23935 + * nm.c (display_rel_file): Check bfd_get_lto_type instead of + lto_slim_object. + + ld/ + + PR ld/23935 + * ldmain.c (add_archive_element): Don't claim a fat IR object if + no IR object should be claimed. + * testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test. + Add PR ld/23935 test. + * testsuite/ld-plugin/pr23935a.c: New file. + * testsuite/ld-plugin/pr23935b.c: Likewise. + +2024-03-26 Andrew Burgess + + gdb/gdbserver: fix some defined but unused function warnings + This commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + added some functions which are always defined, but their use is + guarded within various #ifdef blocks. As a result we were seeing + errors about defined, but unused, functions. + + I've fixed this problem in this commit by wrapping the function + definitions within #ifdef blocks. + + I'm a little worried that there might be too many #ifdef blocks within + this file, however, I'm going to commit this fix for now as this will + fix the build, then I'll think about if there's a better way to split + this file so we might avoid some of these #ifdef blocks. + +2024-03-26 Andrew Burgess + + gdb: fix possible uninitialised variable use + After this commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + a possible use of an uninitialised variable was introduced, the + 'tdesc' variable in i386_linux_core_read_description might be read + without being written too if 'xcr0' was 0. + + This is fixed in this commit. I've updated the function to follow the + same pattern as amd64_linux_core_read_description, if xcr0 is 0 then + we select a default xcr0 value and use that to select a tdesc. + +2024-03-26 Simon Marchi + + gdbserver/Makefile.in: add missing `-x c++` + When building with Clang, I get: + + CXX nat/x86-linux-tdesc-ipa.o + clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated] + + Fix that by adding the missing `-x c++` in the rule building + `gdb/nat/*.c` files for the in-process agent. + + Change-Id: Ie53e4b9a8b57bef9669397fdfaf21617107c7180 + Approved-By: Tom Tromey + +2024-03-26 Simon Marchi + + gdb: mark addrmap classes `final` + When building GDB with clang, I see: + + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non + -abstract-non-virtual-dtor] + 95 | delete __ptr; + | ^ + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete::operator()' requested here + 396 | get_deleter()(std::move(__ptr)); + | ^ + /home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr::~unique_ptr' requested here + 422 | auto map = std::make_unique (); + | ^ + + Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too + while at it. + + Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526 + Approved-By: Tom Tromey + +2024-03-26 GDB Administrator + + Automatic date update in version.in + +2024-03-25 Vladimir Mezentsev + + gprofng: fix infinite recursion on calloc with multi-threaded applications + libcollector uses pthread_getspecific() and pthread_setspecific() to access + thread local memory. libcollector uses this memory to check that + interposed functions (like malloc, calloc or free) don't have recursion. + The first time we call calloc(), we call pthread_setspecific() to create + a thread-specific value. + On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept + such recursion. + gcc supports thread-local storage. For example, + static __thread int reentrance = 0; + I rewrote code using this instead of pthread_setspecific(). + + gprofng/ChangeLog + 2024-03-23 Vladimir Mezentsev + + PR gprofng/31460 + * libcollector/heaptrace.c: Use the __thread variable to check for + * reentry. Clean up code. + +2024-03-25 Pedro Alves + + gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode + Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all + test programs. When running the testsuite in parallel mode, on + Cygwin, I noticed errors like: + + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied + + (Absolute paths elided above.) + + The problem is that gdb_compile's unbuffered_mode_obj cache isn't + parallel safe. This is fixed in this commit. + + Reviewed-by: Kevin Buettner + Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2 + +2024-03-25 Pedro Alves + + Fix windows_nat_target::fake_create_process ptid + While working on Windows non-stop mode, I managed to introduce a bug + that led to fake_create_process being called. That then resulted in + GDB crashes later on, because fake_create_process added a thread with + an incorrect ptid for this target. It is putting dwThreadId in the + tid field of the ptid instead of on the lwp field. This is fixed by + this patch. + + Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215 + +2024-03-25 Andrew Burgess + + bfd: make _bfd_section_size_insane part of the public API + If a BFD user is making use of a function like + bfd_get_section_contents to read a section into a pre-allocated + buffer, then that BFD user might also want to make use of + _bfd_section_size_insane prior to allocating the buffer they intend to + use in order to validate that the buffer size that plan to allocate is + sane. + + This commit makes _bfd_section_size_insane public, by renaming it to + bfd_section_size_insane. + + I've updated the existing uses within bfd/, I don't believe this + function is used outside of bfd/ currently. + + One place that I plan to make use of this function is in + gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents. + This change isn't included in this commit, but will come later if/when + this has been merged into bfd. + + There should be no change in behaviour after this commit. + + bfd/ + + * bfd-in2.h (bfd_section_size_insane): Add declaration. + * compress.c (bfd_get_full_section_contents): Update for new name + of _bfd_section_size_insane. + (bfd_init_section_compress_status): Likewise. + * dwarf2.c (read_section): Likewise. + (_bfd_dwarf2_slurp_debug_info): Likewise. + * libbfd.h (_bfd_section_size_insane): Remove declaration. + * section.c (_bfd_section_size_insane): Rename to ... + (bfd_section_size_insane): ... this. + + binutils/ + + * readelf.c (uncompress_section_contents): Update comment to + account for new name of _bfd_section_size_insane. + +2024-03-25 Andrew Burgess + + gdb: move more completion setup into completer.c + Move more setup of the readline global state relating to tab + completion into completer.c out of top.c. + + Lots of the readline setup is done in init_main (top.c). This commit + moves those bits of initialisation that relate to completion, and + which are only set the one time, into completer.c. This does mean + that readline initialisation is now done in multiple locations, some + in init_main (top.c) and some in completer.c, but I think this is OK. + The work done in init_main is the general readline setup. + + I think making static what can be made static, and having it all in + one file, makes things easier to reason about. So I'm OK with having + this split initialisation. + + The only completion related thing which is still setup in top.c is + rl_completion_display_matches_hook. I've left this where it is for + now as rl_completion_display_matches_hook is also updated in the tui + code, and the display hook functions are not in completer.c anyway, so + moving this initialisation to completer.c would not allow anything + else to be made static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb/completion: make completion_find_completion_word static + I noticed that completion_find_completion_word is only used within + completer.c, so lets make it static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove special case completion word handling for filenames + This commit removes some code which is special casing the filename + completion logic. The code in question relates to finding the + beginning of the completion word and was first introduced, or modified + into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001). + + The code being removed moved the start of the completion word backward + until a character in gdb_completer_file_name_break_characters was + found, or until we reached the end of the actual command. + + However, I doubt that this is needed any more. The filename completer + has a corresponding filename_completer_handle_brkchars function which + provides gdb_completer_file_name_break_characters as the word break + characters to readline, and also sets rl_completer_quote_characters. + As such, I would expect readline to be able to correctly find the + start of the completion word. + + There is one change which I've needed to make as a consequence of + removing the above code, and I think this is a bug fix. + + In complete_line_internal_normal_command we initialised temporary + variable P to the CMD_ARGS; this is the complete text after the + command name. Meanwhile, complete_line_internal_normal_command also + accepts an argument WORD, which is the completion word that readline + found for us. + + In the code I removed P was updated, it was first set to WORD, and + then moved backwards to the "new" start of the completion word. + + But notice, the default for P is the complete command argument text, + and only if we are performing filename completion do we modify P to be + the completion word. + + We then passed P through to the actual commands completion function. + + If we are doing anything other than filename completion then the value + of P passed is the complete argument text. + + If we are doing filename completion then the value of P passed is the + completion word. + + In filename_completer we get two arguments TEXT and WORD, the TEXT + argument is the value of P which is the "new" completion word, while + WORD is the completion word that readline calculated. + + After simplifying complete_line_internal_normal_command, and the + temporary P is removed, we always pass the complete argument text into + TEXT, while WORD remains the completion word that readline found. + + Previously in filename_completer we actually tried to generate + completions based on TEXT, which worked fine as TEXT actually + contained the completion word that we found in + complete_line_internal_normal_command. But I believe that we should + be fine to use the completion word that readline found, so I have + updated filename_completer to generate completions based on WORD. + + If I'm correct, then I don't expect to see any user visible changes + after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove some dead code from completer.c + In completer.c there is some code that is surrounded with '#if 0', + this code: + + #if 0 + /* There is no way to do this just long enough to affect quote + inserting without also affecting the next completion. This + should be fixed in readline. FIXME. */ + /* Ensure that readline does the right thing + with respect to inserting quotes. */ + rl_completer_word_break_characters = ""; + #endif + + This code, in some form, and always defined out, has been around since + the original import of GDB. Though the comment hints at what the + problem might be, it's not really clear what the issue is. And + completion within GDB has moved on a long way since this code was + written ... but not used. + + I'm proposing that we just remove this code. + + If/when a problem comes up then we can look at how to solve it. Maybe + this code would be the answer ... but also, I suspect, given all the + changes ... maybe not. I'm not sure carrying around this code for + another 20+ years adds much value. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: allow double quotes for quoting filenames + Currently GDB only supports using single quotes for quoting things, + the reason for this, as explained in completer.c (next to the variable + gdb_completer_expression_quote_characters) is that double quoted + strings need to be treated differently by the C expression parser. + + But for filenames I don't believe this restriction holds. The file + names as passed to things like the 'file' command are not passing + through the C expression parser, so it seems like we should be fine to + allow double quotes for quoting in this case. + + And so, this commit extends GDB to allow double quotes for quoting + filenames. Maybe in future we might be able to allow double quote + quoting in additional places, but this seems enough for now. + + The testing has been extended to cover double quotes in addition to + the existing single quote testing. + + This change does a number of things: + + 1. Set rl_completer_quote_characters in filename_completer and + filename_completer_handle_brkchars, this overrides the default which + is set in complete_line_internal_1, + + 2. In advance_to_completion_word we now take a set of quote + characters as a parameter, the two callers + advance_to_expression_complete_word_point and + advance_to_filename_complete_word_point now pass in the required set + of quote characters, + + 3. In completion_find_completion_word we now use the currently active + set of quote characters, this means we'll use + gdb_completer_expression_quote_characters or + gdb_completer_file_name_quote_characters depending on what type of + things we are completing. + +2024-03-25 Andrew Burgess + + gdb: fix bug where quote characters would become nullptr + In gdb_completion_word_break_characters_throw, after calling + complete_line_internal, if the completion function chose to use a + custom word point then we set rl_completer_quote_characters to NULL. + + However, nowhere do we set rl_completer_quote_characters back to its + default value, which is setup in init_main (top.c). + + An example of something that uses a custom word point for its + completion is 'thread apply all ...'. + + An example of something that relies on rl_completer_quote_characters + would be completion of a quoted filename that contains white space. + + Consider this shell and GDB session. The markers indicate where + I've used tab to trigger completion: + + $ mkdir /tmp/aaa\ bbb + $ touch /tmp/aaa\ bbb/xx\ 11 + $ touch /tmp/aaa\ bbb/xx\ 22 + $ gdb -q + (gdb) file '/tmp/aaa bbb/xx + xx 11 xx 22 + (gdb) thread apply all hel + (gdb) thread apply all help + (gdb) file '/tmp/aaa bbb/xx + + First I create a directory structure which uses white space within + file and directory names. Then within GDB I use the 'file' command + and use a single quote to quote the filename. When I tab complete GDB + correctly offers the two files within the directory '/tmp/aaa bbb/'. + + This works because rl_completer_quote_characters contains the single + quote, and so readline knows that it is trying to complete the string + that starts after the single quote: /tmp/aaa bbb/xx + + Next I invoke the completer for the 'thread apply all' command, to do + this I type 'thread apply all hel' and hit tab, this expands to the + one completion 'thread apply all help'. We can run this command or + not, it doesn't matter (there are no threads, so we'll get no output). + + Now I repeat the original 'file' completion. This time though I don't + get offered any completions. + + The reason is that the 'thread apply all' completer set + rl_completer_quote_characters to nullptr. Now, when readline tries to + figure out the word to complete it doesn't see the single quote as the + start of a quoted word, so instead readline falls back to the word + break characters, and in this case spots the white space. As a result + readline tries to complete the string 'bbb/xx' which obviously doesn't + have any completions. + + By setting rl_completer_quote_characters each time completion is + invoked this problem is resolved and the second 'file' command + completes as expected. + + I've extended gdb.base/filename-completion.exp to also test with + quoted filenames, and added a 'thread apply all' completion at the + start to expose this bug. + + As setting of rl_completer_quote_characters is now all done in the + completer.c file the function get_gdb_completer_quote_characters() + could be made static. However, as this function is only used one time + to initialise rl_completer_quote_characters, I've instead just deleted + get_gdb_completer_quote_characters() and used + gdb_completer_quote_characters directly. + +2024-03-25 Andrew Burgess + + gdb: remove skip_quoted and skip_quoted_chars + The function skip_quoted_chars (completer.c) is only used by + skip_quoted (also completer.c), so could be made static. The function + skip_quoted just calls directly to skip_quoted_chars but fills in some + default arguments. + + The function skip_quoted is only used by the Pascal expression parser, + and is only used in one place. + + The skip_quoted_chars function skips a single string; it either looks + for a string between matching quotes, or for a string up to a word + break character. + + However, given how the Pascal expression parser calls this function, + we know that the first character will always be a single quote, in + which case skip_quoted_chars will looks for a string between matching + single quotes. + + The skip_quoted_chars doesn't do any escaped character handling, it + will just stop at the next single quote character. + + In this commit I propose to remove skip_quoted and skip_quoted_chars, + and replace these with a smaller function pascal_skip_string which + I've placed in p-exp.y. This new function only skips a string between + matching single quotes, which is exactly the use case that we need. + + The benefit of this change is to remove (some) code duplication. It + feels like skip_quoted is similar in some ways to + extract_string_maybe_quoted, however, there are some differences; + skip_quoted uses the quotes and word break characters from the + completion engine which extract_string_maybe_quoted does not. + + However, I'm currently working on improving filename completion, one + part of this is that I'm looking at allowing filenames to be quoted + with single or double quotes, while the default string quoting in + GDB (for expressions) can only use single quotes. If I do end up + allowing single and double quotes in some cases, but we retain the + single quotes only for expressions then skip_quoted starts to become a + problem, should it accept both quote types, or only one? + + But given how skip_quoted is used, I can avoid worrying about this by + simply removing skip_quoted. + + The Pascal tests do still pass. The code that called skip_quoted is + called at least once in the Pascal tests (adding an abort() call + causes gdb.pascal/types.exp to fail), but I doubt the testing is + extensive. Not sure how widely used GDB for Pascal actually is + though. + +2024-03-25 Andrew Burgess + + gdb: rename unwindonsignal to unwind-on-signal + We now have unwind-on-timeout and unwind-on-terminating-exception, and + then the odd one out unwindonsignal. + + I'm not a great fan of these squashed together command names, so in + this commit I propose renaming this to unwind-on-signal. + + Obviously I've added the hidden alias unwindonsignal so any existing + GDB scripts will keep working. + + There's one test that I've extended to test the alias works, but in + most of the other test scripts I've changed over to use the new name. + + The docs are updated to reference the new name. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: introduce unwind-on-timeout setting + Now that inferior function calls can timeout (see the recent + introduction of direct-call-timeout and indirect-call-timeout), this + commit adds a new setting unwind-on-timeout. + + This new setting is just like the existing unwindonsignal and + unwind-on-terminating-exception, but the new setting will cause GDB to + unwind the stack if an inferior function call times out. + + The existing inferior function call timeout tests have been updated to + cover the new setting. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: add timeouts for inferior function calls + In the previous commits I have been working on improving inferior + function call support. One thing that worries me about using inferior + function calls from a conditional breakpoint is: what happens if the + inferior function call fails? + + If the failure is obvious, e.g. the thread performing the call + crashes, or hits a breakpoint, then this case is already well handled, + and the error is reported to the user. + + But what if the thread performing the inferior call just deadlocks? + If the user made the call from a 'print' or 'call' command, then the + user might have some expectation of when the function call should + complete, and, when this time limit is exceeded, the user + will (hopefully) interrupt GDB and regain control of the debug + session. + + But, when the inferior function call is from a breakpoint condition it + is much harder to understand that GDB is deadlocked within an inferior + call. Maybe the breakpoint hasn't been hit yet? Or maybe the + condition was always false? Or maybe GDB is deadlocked in an inferior + call? The only way to know for sure is for the user to periodically + interrupt the inferior, check on the state of all the threads, and + then continue. + + Additionally, the focus of the previous commit was inferior function + calls, from a conditional breakpoint, in a multi-threaded inferior. + This opens up a whole new set of potential failure conditions. For + example, what if the function called relies on interaction with some + other thread, and the other thread crashes? Or hits a breakpoint? + Given how inferior function calls work (in a synchronous manner), a + stop event in some other thread is going to be ignored while the + inferior function call is being executed as part of a breakpoint + condition, and this means that GDB could get stuck waiting for the + original condition thread, which will now never complete. + + In this commit I propose a solution to this problem. A timeout. For + targets that support async-mode we can install an event-loop timer + before starting the inferior function call. When the timer expires we + will stop the thread performing the inferior function call. With this + mechanism in place a user can be sure that any inferior call they make + will either complete, or timeout eventually. + + Adding a timer like this is obviously a change in behaviour for the + more common 'call' and 'print' uses of inferior function calls, so, in + this patch, I propose having two different timers. One I call the + 'direct-call-timeout', which is used for 'call' and 'print' commands. + This timeout is by default set to unlimited, which, not surprisingly, + means there is no timeout in place. + + A second timer, which I've called 'indirect-call-timeout', is used for + inferior function calls from breakpoint conditions. This timeout has + a default value of 30 seconds. This is a reasonably long time to + wait, and hopefully should be enough in most cases to allow the + inferior call to complete. An inferior call that takes more than 30 + seconds, which is installed on a breakpoint condition is really going + to slow down the debug session, so hopefully this is not a common use + case. + + The user is, of course, free to reduce, or increase the timeout value, + and can always use Ctrl-c to interrupt an inferior function call, but + this timeout will ensure that GDB will stop at some point. + + The new commands added by this commit are: + + set direct-call-timeout SECONDS + show direct-call-timeout + set indirect-call-timeout SECONDS + show indirect-call-timeout + + These new timeouts do depend on async-mode, so, if async-mode is + disabled (maint set target-async off), or not supported (e.g. target + sim), then the timeout is treated as unlimited (that is, no timeout is + set). + + For targets that "fake" non-async mode, e.g. Linux native, where + non-async mode is really just async mode, but then we park the target + in a sissuspend, we could easily fix things so that the timeouts still + work, however, for targets that really are not async aware, like the + simulator, fixing things so that timeouts work correctly would be a + much bigger task - that effort would be better spent just making the + target async-aware. And so, I'm happy for now that this feature will + only work on async targets. + + The two new show commands will display slightly different text if the + current target is a non-async target, which should allow users to + understand what's going on. + + There's a somewhat random test adjustment needed in gdb.base/help.exp, + the test uses a regexp with the apropos command, and expects to find a + single result. Turns out the new settings I added also matched the + regexp, which broke the test. I've updated the regexp a little to + exclude my new settings. + + Reviewed-By: Tankut Baris Aktemur + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + Natalia Saiapova + Tankut Baris Aktemur + + gdb: fix b/p conditions with infcalls in multi-threaded inferiors + This commit fixes bug PR 28942, that is, creating a conditional + breakpoint in a multi-threaded inferior, where the breakpoint + condition includes an inferior function call. + + Currently, when a user tries to create such a breakpoint, then GDB + will fail with: + + (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ()) + Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2460150)] + [New Thread 0x7ffff745c700 (LWP 2460151)] + [New Thread 0x7ffff6c5b700 (LWP 2460152)] + [New Thread 0x7ffff645a700 (LWP 2460153)] + [New Thread 0x7ffff5c59700 (LWP 2460154)] + Error in testing breakpoint condition: + Couldn't get registers: No such process. + An error occurred while in a function called from GDB. + Evaluation of the expression containing the function + (return_true) will be abandoned. + When the function is done executing, GDB will silently stop. + Selected thread is running. + (gdb) + + Or, in some cases, like this: + + (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1)) + Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2461106)] + [New Thread 0x7ffff745c700 (LWP 2461107)] + ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + + The precise error depends on the exact thread state; so there's race + conditions depending on which threads have fully started, and which + have not. But the underlying problem is always the same; when GDB + tries to execute the inferior function call from within the breakpoint + condition, GDB will, incorrectly, try to resume threads that are + already running - GDB doesn't realise that some threads might already + be running. + + The solution proposed in this patch requires an additional member + variable thread_info::in_cond_eval. This flag is set to true (in + breakpoint.c) when GDB is evaluating a breakpoint condition. + + In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is + true, then GDB will only try to resume the current thread, that is, + the thread for which the breakpoint condition is being evaluated. + This solves the problem of GDB trying to resume threads that are + already running. + + The next problem is that inferior function calls are assumed to be + synchronous, that is, GDB doesn't expect to start an inferior function + call in thread #1, then receive a stop from thread #2 for some other, + unrelated reason. To prevent GDB responding to an event from another + thread, we update fetch_inferior_event and do_target_wait in infrun.c, + so that, when an inferior function call (on behalf of a breakpoint + condition) is in progress, we only wait for events from the current + thread (the one evaluating the condition). + + In do_target_wait I had to change the inferior_matches lambda + function, which is used to select which inferior to wait on. + Previously the logic was this: + + auto inferior_matches = [&wait_ptid] (inferior *inf) + { + return (inf->process_target () != nullptr + && ptid_t (inf->pid).matches (wait_ptid)); + }; + + This compares the pid of the inferior against the complete ptid we + want to wait on. Before this commit wait_ptid was only ever + minus_one_ptid (which is special, and means any process), and so every + inferior would match. + + After this commit though wait_ptid might represent a specific thread + in a specific inferior. If we compare the pid of the inferior to a + specific ptid then these will not match. The fix is to compare + against the pid extracted from the wait_ptid, not against the complete + wait_ptid itself. + + In fetch_inferior_event, after receiving the event, we only want to + stop all the other threads, and call inferior_event_handler with + INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint. + If we are, then all the other threads should be left doing whatever + they were before. The inferior_event_handler call will be performed + once the breakpoint condition has finished being evaluated, and GDB + decides to stop or not. + + The final problem that needs solving relates to GDB's commit-resume + mechanism, which allows GDB to collect resume requests into a single + packet in order to reduce traffic to a remote target. + + The problem is that the commit-resume mechanism will not send any + resume requests for an inferior if there are already events pending on + the GDB side. + + Imagine an inferior with two threads. Both threads hit a breakpoint, + maybe the same conditional breakpoint. At this point there are two + pending events, one for each thread. + + GDB selects one of the events and spots that this is a conditional + breakpoint, GDB evaluates the condition. + + The condition includes an inferior function call, so GDB sets up for + the call and resumes the one thread, the resume request is added to + the commit-resume queue. + + When the commit-resume queue is committed GDB sees that there is a + pending event from another thread, and so doesn't send any resume + requests to the actual target, GDB is assuming that when we wait we + will select the event from the other thread. + + However, as this is an inferior function call for a condition + evaluation, we will not select the event from the other thread, we + only care about events from the thread that is evaluating the + condition - and the resume for this thread was never sent to the + target. + + And so, GDB hangs, waiting for an event from a thread that was never + fully resumed. + + To fix this issue I have added the concept of "forcing" the + commit-resume queue. When enabling commit resume, if the force flag + is true, then any resumes will be committed to the target, even if + there are other threads with pending events. + + A note on authorship: this patch was based on some work done by + Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made + some changes to their work in this version. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942 + + [1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + Revert "gdb: remove unnecessary parameter wait_ptid from do_target_wait" + This reverts commit ac0d67ed1dcf470bad6a3bc4800c2ddc9bedecca. + + There was nothing wrong with the commit which I'm reverting here, but + it removed some functionality that will be needed for a later commit; + that is, the ability for GDB to ask for events from a specific ptid_t + via the do_target_wait function. + + In a follow up commit, this functionality will be used to implement + inferior function calls in multi-threaded inferiors. + + This is not a straight revert of the above commit. Reverting the + above commit replaces a 'nullptr' with 'NULL', I've gone in and + changed that, preserving the 'nullptr'. + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into + gdb/nat/x86-linux-tdesc.c and combine them so we have just a single + copy of each. Then both GDB and gdbserver will link against these + shared functions. + + It is worth reading the description of the previous commit to see why + this merging is not as simple as it seems: on the gdbserver side we + actually have two users of these functions, gdbserver itself, and the + in process agent (IPA). + + However, the previous commit streamlined the gdbserver code, and so + now it is simple to move the two functions along with all their + support functions from the gdbserver directory into the gdb/nat/ + directory, and then GDB is fine to call these functions. + + One small curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, that is some + additional configuration that is performed as each target description + is created to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + This does mean adding back some non-shared code when this whole series + has been about sharing code, but now the only non-shared bit is the + single line that is actually different between GDB and gdbserver, all + the rest, which is identical, is now shared. + + I did need to add a new rule to the gdbserver Makefile, this is to + allow the nat/x86-linux-tdesc.c file to be compiled for the IPA. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring, the previous commit actually started to share + some code, we added the shared x86_linux_tdesc_for_tid function into + nat/x86-linux-tdesc.c. However, this function still relies on + amd64_linux_read_description and i386_linux_read_description which are + implemented separately for both gdbserver and GDB. Given that at + their core, all these functions to is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + On the GDB side we create target descriptions using a different set of + cpu features than on the gdbserver side! This means that for the + exact same target, we might get a different target description when + using native GDB vs using gdbserver. This surely feels like a + mistake, I would expect to get the same target description on each. + + The table below shows the number of possible different target + descriptions that we can create on the GDB side vs on the gdbserver + side for each target type: + + | GDB | gdbserver + ------|-----|---------- + i386 | 64 | 7 + amd64 | 32 | 7 + x32 | 16 | 7 + + So in theory, all I want to do is move the GDB version + of *_read_description into the nat/ directory and have gdbserver use + that, then both GDB and gdbserver would be able to create any of the + possible target descriptions. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach made perfect sense. However + since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think passing the index is now more trouble than its worth. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use. However, the above commit + fixed an issue where we can't call malloc() within (certain parts of) + the IPA (apparently), so instead we now pre-compute _every_ possible + target description within the IPA. The index is now only used to + lookup which of the (many) pre-computed target descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of cpu features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + create the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they create target descriptions + using the same set of cpu features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series does. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit can merge the GDB and gdbserver + versions of these functions. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While trying to merge this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + With this patch series of mine: + + https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com + + I worried that there could be other paths that could result in an xcr0 + value that has X86_XSTATE_MPX set in x32 mode. As everyone eventually + calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this should uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things the GDB way, the only changes are to + allow for the sharing; we now have a callback function to call the + first time that the xcr0 state is read, this allows for GDB and + gdbserver to perform their own initialisation as needed, and + additionally, the new function takes a pointer for where to cache the + xcr0 value, this isn't needed for this commit, but will be useful in a + later commit where gdbserver will want to read this cached xcr0 + value. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/nat/x86-linux-tdesc.h, but the implementations are left as + separate. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit is part of a series that aims to share more of the x86 + target description creation code between GDB and gdbserver. The + I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target + description creation, and I noticed that this constant is defined + separately for GDB and gdbserver. + + This commit moves the definition into gdb/nat/x86-linux.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim of making the code + that, for x86, reads the target description for a native process + shared between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes. + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code could be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12 + With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc + 12, I get: + ... + (gdb) set debug symtab-create 1^M + (gdb) print *the_local_var^M + ... + $1 = (n => 2)^M + (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded + ... + + The problem is that this fails: + ... + -re -wrap ".* = \\\(n => $decimal\\\)" { + if {$found_pck + $found_pck2 == 1} { + pass $gdb_test_name + } else { + fail $gdb_test_name + } + ... + because $found_pck == 0 and $found_pck2 == 0. + + Indeed, with gcc 13 we have: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + pck2.adb + pck2.adb + pck2.ads + pck2.adb + pck2.ads + ... + and with gcc 12: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + ... + + Fix this by checking for "$found_pck + $found_pck2 <= 1" instead. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31514 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514 + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix tdlabel_re references + Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs + from info threads") introduces a new global variable tdlabel_re, but fails to + indicate it's global when used in procs in four test-cases. + + Fix this by adding "global tdlabel_re". + + Tested on aarch64-linux. + +2024-03-25 GDB Administrator + + Automatic date update in version.in + +2024-03-24 GDB Administrator + + Automatic date update in version.in + +2024-03-23 John Baldwin + + gdb tests: Allow for "LWP" or "process" in thread IDs from info threads + Several tests assume that the first word after a thread ID in 'info + threads' output is "Thread". However, several targets use "LWP" + instead such as the FreeBSD and NetBSD native targets. The Linux + native target also uses "LWP" if libthread_db is not being used. + Targets that do not support threads use "process" as the first word + via normal_pid_to_str. + + Add a tdlabel_re global variable as a regular-expression for a thread + label in `info threads' that matches either "process", "Thread", or + "LWP". + + Some other tests in the tree don't require a specific word, and + some targets may use other first words (e.g. OpenBSD uses "thread" + and Ravenscar threads use "Ravenscar Thread"). + +2024-03-23 GDB Administrator + + Automatic date update in version.in + +2024-03-22 Pedro Alves + + windows-nat: Use gdb_realpath + Use gdb_realpath instead of realpath in windows-nat.c:windows_make_so, + so that we don't have to manually call free. + + Approved-By: John Baldwin + Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff + +2024-03-22 Pedro Alves + + windows-nat: Remove SO_NAME_MAX_PATH_SIZE limit + There is no need to limit shared library path sizes to + SO_NAME_MAX_PATH_SIZE nowadays. windows_solib::name and + windows_solib::original_name are std::strings nowadays, and so are + solib::so_name and solib::so_original_name in the core solib code. + + This commit reworks the code to remove that limit. This also fixes a + leak where we were not releasing 'rname' in the realpath branch if the + 'rname' string was larger than SO_NAME_MAX_PATH_SIZE. + + Note: I tested the cygwin_conv_path with a manual hack to force that + path, and then stepping through the code. You only get to that path + if Windows doesn't report an absolute path for ntdll.dll, and on my + machine (running Windows 10), it always does. + + Approved-By: John Baldwin + Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5 + +2024-03-22 Pedro Alves + + Simplify windows-nat.c:windows_make_so #ifdefery + There are two separate #ifndef __CYGWIN__/#else/#endif sections in the + windows_make_so function with 3 lines of shared code separating them. + I find this makes the code harder to understand than necessary. + AFAICS, there is no reason those three shared lines need to be after + the first #ifdef block. There is no early return, nor are 'load_addr' + nor 'name' modified. + + This commit moves that shared code to the top of the function, and + then combines the two #ifndef sections. + + Approved-By: John Baldwin + Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc + +2024-03-22 Pedro Alves + + Remove SO_NAME_MAX_PATH_SIZE limit from core solib code + solib_map_sections errors out if the library file name is longer than + SO_NAME_MAX_PATH_SIZE. + + solib::so_name and solib::so_original_name used to be arrays of + SO_NAME_MAX_PATH_SIZE size, so that check made sense then. + + However, since commit 98107b0b17ac ("gdb: make + so_list::{so_original_name,so_name} std::strings") those fields are of + std::string type, so there's really no need for the limit. + + This commit simply removes the length limit check. + + Approved-By: John Baldwin + Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6 + +2024-03-22 Tom Tromey + + Use std::string for disassembler options + I noticed that the disassembler_options code uses manual memory + management. It seemed simpler to replace this with std::string. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Remove some unnecessary casts + I found a few unnecessary casts when calling + set_gdbarch_disassembler_options_implicit. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Constify get_disassembler_options + This changes get_disassembler_options to return a const char *. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Revert "Pass GUILE down to subdirectories" + This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. + + This patch caused problems for some users when building gdb, because + it would cause 'guild' to be invoked with the wrong versin of guile. + On the whole it seems simpler to just back this out. + + I'm checking this in to the binutils-gdb repository in the interest of + fixing the build for Andrew. No one has responded to the identical + patch sent to gcc-patches, but I will ping it there. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Remove GUILE. + (GUILE): Remove. + * Makefile.def (flags_to_pass): Remove GUILE. + +2024-03-22 Tiezhu Yang + + gdb: LoongArch: Clean up loongarch_iterate_over_regset_sections() + Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET + to replace the related code in the first cb(), and also make use of + tabs and spaces in indentation to force the proper alignment of code, + then remove the empty line at the end of the function. + +2024-03-22 Pedro Alves + + Teach GDB to generate sparse core files (PR corefiles/31494) + This commit teaches GDB's gcore command to generate sparse core files + (if supported by the filesystem). + + To create a sparse file, all you have to do is skip writing zeros to + the file, instead lseek'ing-ahead over them. + + The sparse logic is applied when writing the memory sections, as + that's where the bulk of the data and the zeros are. + + The commit also tweaks gdb.base/bigcore.exp to make it exercise + gdb-generated cores in addition to kernel-generated cores. We + couldn't do that before, because GDB's gcore on that test's program + would generate a multi-GB non-sparse core (16GB on my system). + + After this commit, gdb.base/bigcore.exp generates, when testing with + GDB's gcore, a much smaller core file, roughly in line with what the + kernel produces: + + real sizes: + + $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + apparent sizes: + + $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + Time to generate the core also goes down significantly. On my machine, I get: + + when writing to an SSD, from 21.0s, down to 8.0s + when writing to an HDD, from 31.0s, down to 8.5s + + The changes to gdb.base/bigcore.exp are smaller than they look at + first sight. It's basically mostly refactoring -- moving most of the + code to a new procedure which takes as argument who should dump the + core, and then calling the procedure twice. I purposely did not + modernize any of the refactored code in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494 + Reviewed-By: Lancelot Six + Reviewed-By: Eli Zaretskii + Reviewed-By: John Baldwin + Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1 + +2024-03-22 Jan Beulich + + x86: fix Solaris testsuite failures + For one 0afc614c9938 ("x86: Warn .insn instruction with length > 15 + bytes") introduced a .insn use involving a slash; such tests need to + have --divide passed to gas. + + And then 5bc71c2a6b8e ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke + BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by + adding respective code in a section guarded by + generate_relax_relocations (the case of that not being required there + was limited to 32-bit object files). Re-arrange that block of code to + check generate_relax_relocations later. + +2024-03-22 GDB Administrator + + Automatic date update in version.in + +2024-03-21 H.J. Lu + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits + on x32. + + PR server/31511 + * linux-x86-low.cc (x86_linux_read_description): Clear + X86_XSTATE_MPX bits in xcr0 on x32. + Reviewed-by: Felix Willgerodt + +2024-03-21 Tom Tromey + + Implement Ada 2022 delta aggregates + Ada 2022 includes a "delta aggregates" feature that can sometimes + simplify aggregate creation. This patch implements this feature for + GDB. + +2024-03-21 Tom Tromey + + Require trivial destructor in allocate_on_obstack + This patch makes allocate_on_obstack a little bit safer, by enforcing + the rule that objects allocated on an obstack must have a trivial + destructor. + + The static assert is done in a method -- doing it inside the class + itself won't work because the class is incomplete at that point. + +2024-03-21 Tom Tromey + + Don't use virtual destructor in addrmap + The addrmap polymorphism is sort of "phony" in that there isn't really + code in the tree that can be presented with either type. I haven't + tried to fix this (though perhaps I may); but meanwhile it's handy for + the next patch if addrmap_fixed has a trivial destructor. This patch + achieves this by making the addrmap destructor non-virtual, and also + making it protected so that objects of any of these types cannot be + destroyed when only the base class is known. + + Use addrmap_fixed in a few spots + There are a few spots in the tree that use 'addrmap' where only an + addrmap_fixed will ever really be seen. This patch changes this code + to use the more specific type. + +2024-03-21 Orgad Shaneh + + sim/erc32: Rename EVENT_MAX -> MAX_EVENTS + EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when + building on Windows, the value is overridden and compilation fails + because the array size of evbuf is too large. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476 + Approved-By: Tom Tromey + +2024-03-21 Tiezhu Yang + + gdb: syscalls: Add some tips for LoongArch xml files + In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in), + it needs special handling when generating xml file. This should at + least be mentioned in the file comment rather than git log to help + the next person who regenerates this file understand what needs to + be done, suggested by Pedro Alves, thank you. + + At the beginning, I only added the tips in loongarch-linux.xml.in, + after executing the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in, it generates the same tips in the file + loongarch-linux.xml automatically, so update loongarch-linux.xml.in + and loongarch-linux.xml together. + + Approved-by: Pedro Alves + +2024-03-21 Hui Li + + gdb: LoongArch: Silence warning about core file of lsx and lasx + In loongarch_iterate_over_regset_sections(), the second and third arguments + of the iterate_over_regset_sections_cb callback function should be the regset + size which is regsize * regnum. Otherwise when execute: + + make check-gdb TESTS="gdb.base/corefile.exp" + + there exists the following failed log: + + (gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core + [New LWP 531099] + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'. + Program terminated with signal SIGABRT, Aborted. + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + #0 0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6 + (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free + +2024-03-21 Nick Clifton + + New Romanian translation for gas sub-directory + +2024-03-21 GDB Administrator + + Automatic date update in version.in + +2024-03-20 Simon Marchi + + .pre-commit-config.yaml: bump black hook to 24.3.0 + Running `pre-commit autoupdate` showed that there is a new version of + the black hook for v24.3.0. Update it. + + ChangeLog: + + * .pre-commit-config.yaml: Bump black hook to 24.3.0 + + Change-Id: I5ec7d2edf99cd15f6525281a43aed9ff481ee9ee + +2024-03-20 Tom de Vries + + [gdb/testsuite] Fix gdb.server/server-connect.exp for missing ipv6 + On a system without ipv6 support enabled, when running test-case + gdb.server/server-connect.exp, it takes about 4 minutes, and I get: + ... + builtin_spawn gdbserver --once ::1:2347 server-connect^M + Can't open socket: Address family not supported by protocol.^M + Exiting^M + PASS: gdb.server/server-connect.exp: tcp6: start gdbserver + target remote tcp6:::1:2347^M + A program is being debugged already. Kill it? (y or n) y^M + could not connect: Address family not supported by protocol.^M + (gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1 + ... + + Fix this by: + - recognizing the error message in gdbserver_start, and returning an empty list + to signal unsupported, and + - handling the unsupported response in the test-case. + + This brings testing time down to 2 seconds, and gets me: + ... + UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31502 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502 + +2024-03-20 Tom de Vries + + [gdb/testsuite] Handle core without build-id in gdb.base/corefile-buildid.exp + On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get: + ... + expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163" + info files^M + Local core dump file:^M + `build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M + 0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M + ... + 0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M + (gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files + ... + + The problem is that the test-case expect the build-id to be available in the + core file, while it isn't. + + Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in + gdb.base/coredump-filter-build-id.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Tom de Vries + + [gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases + On aarch64-linux (debian 12), when running test-case + gdb.base/longjmp-until-in-main.exp, I run into: + ... + (gdb) until 33^M + warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M + Warning:^M + Cannot insert breakpoint 0.^M + Cannot access memory at address 0xfff727c678928489^M + ^M + 0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M + (gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main + ... + + This is PR gdb/26967: no longjmp probe is available: + ... + (gdb) info probes stap libc ^longjmp$^M + No probes matched.^M + ... + and glibc applies pointer mangling which makes it fairly difficult for gdb to + get the longjmp target. + + There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit + b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp"). + + Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in + this and one more test-case. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix casting in-memory values of primitive types to const reference + It's currently not possible to cast an in-memory value of a primitive + type to const reference: + ``` + (gdb) p Q.id + $1 = 42 + (gdb) p (int&)Q.id + $2 = (int &) @0x22fd0c: 42 + (gdb) p (const int&)Q.id + Attempt to take address of value not located in memory. + ``` + + And if in a function call an argument needs the same kind of casting, + it also doesn't work: + ``` + (gdb) l f3 + 39 int f3(const int &i) + 40 { + 41 return i; + 42 } + (gdb) p f3(Q.id) + Attempt to take address of value not located in memory. + ``` + + It's because when the constness of the type changes in a call to + value_cast, a new not_lval value is allocated, which doesn't exist + in the target memory. + + Fixed by ignoring const/volatile/restrict qualifications in + value_cast when comparing cast type to original type, so the new + value will point to the same location as the original value: + ``` + (gdb) p (int&)i + $2 = (int &) @0x39f72c: 1 + (gdb) p (const int&)i + $3 = (const int &) @0x39f72c: 1 + (gdb) p f3(Q.id) + $4 = 42 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423 + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix reinterpret_cast for classes with multiple inheritance + Currently a reinterpret_cast may change the pointer value if + multiple inheritance is involved: + ``` + (gdb) p r + $1 = (Right *) 0x22f75c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x22f758 + ``` + + It's because value_cast is called in this case, which automatically + does up- and downcasting. + + Fixed by simply using the target pointer type in a copy of the + original value: + ``` + (gdb) p r + $1 = (Right *) 0x3bf87c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x3bf87c + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861 + Approved-By: Tom Tromey + +2024-03-20 Simon Marchi + + Add .pre-commit-config.yaml + Add a pre-commit [1] config file, with a single hook to run black on the + gdb directory whenever a Python file is modified. We can always add + more hooks if we find some that are useful. + + Using pre-commit to run hooks is opt-in, as in it's not mandatory at all + for development, but it can be useful to run some checks that are easy + to forget (like running black). The hooks run locally on the + developer's machine when doing `git commit` (although they can also be + configured to run at other stages of the git workflow). + + Follow these instructions to install the hooks in your local development + git repository: + + - Install pre-commit the way you prefer. It can be using your OS + package manager if it has a recent enough version, or using `pip + install pre-commit`. + - Go to the binutils-gdb repository and run `pre-commit install`. + + This installs a git hook at `.git/hooks/pre-commit`. + + Now, whenever you modify and try to commit a Python file, pre-commit + will run black on it. For instance, if I try to insert something + misformatted, I get this when doing `git commit`: + + $ git commit + black....................................................................Failed + - hook id: black + - files were modified by this hook + + reformatted gdb/python/lib/gdb/dap/breakpoint.py + + All done! ✨ 🍰 ✨ + 1 file reformatted. + + At this point, black has already reformatted the files in place, so the + changes that fix the formatting are ready to add and commit. black is + only ran on files modified in the commit. + + The hook defines a black version, which is downloaded at `pre-commit + install` time. pre-commit manages its own env at + `$HOME/.cache/pre-commit/`, so it won't use the version of + black you have installed already. This may help ensure that + contributors use the right black version. + + The procedure when there is a new version of black (or a new version of + any hook we might be using in the future) is: + + - Modify .pre-commit-config.yaml to change the version number, push to + the upstream repo. + - Have contributors run `pre-commit autoupdate` to make their local + pre-commit installation update the hooks. + + It is possible to have pre-commit skip some hooks if needed [2]. + + I will add these instructions to the wiki if this patch gets merged, so + they are easy to find. We could perhaps think of having a + gdb/CONTRIBUTING document of some sort checked in the repo with that + kind of information. + + I have not used pre-commit in a real project before, but have heard good + things from it. If we want to give it a try before pushing it to the + repo, some volunteers can copy the .pre-commit-config.yaml file locally + and try it for some time. However, pushing the file upstream is not + going to impact anybody who doesn't care about it, so I'd say it's + relatively low-risk to push it right now. + + [1] https://pre-commit.com + [2] https://pre-commit.com/#temporarily-disabling-hooks + + Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099 + Acked-By: Tom Tromey + Acked-By: Guinevere Larsen + Acked-By: Andrew Burgess + +2024-03-20 Hannes Domani + + Fix comparison of array types + Currently it's not possible to call functions if an argument is a + pointer to an array: + ``` + (gdb) l f + 1 int f (int (*x)[2]) + 2 { + 3 return x[0][1]; + 4 } + 5 + 6 int main() + 7 { + 8 int a[2][2] = {{0, 1}, {2, 3}}; + 9 return f (a); + 10 } + (gdb) p f(a) + Cannot resolve function f to any overloaded instance + ``` + + This happens because types_equal doesn't handle array types, so the + function is never even considered as a possibility. + + With array type handling added, by comparing element types and array + bounds, the same works: + ``` + (gdb) p f(a) + $1 = 1 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398 + Co-Authored-By: Keith Seitz + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-03-20 Tiezhu Yang + + gdb: LoongArch: Set the correct XML syscall filename + Now, there exists syscalls/loongarch-linux.xml, let us set the correct + XML syscall filename for LoongArch, otherwise GDB won't be able to find + the correct XML file to open and get the syscalls definitions. + + It should install the package expat-devel (a library for XML parsing) + and configure --with-expat (done by default if libexpat is installed + and found at configure time) for compiling gdb in this case. + + Without this patch: + + (gdb) catch syscall + warning: There is no XML file to open. + warning: GDB will not be able to display syscall names nor to verify if + any provided syscall numbers are valid. + Catchpoint 1 (any syscall) + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch case in update-linux-from-src.sh + It shows that "Don't know how to generate loongarch-linux.xml.in" + when using the script update-linux-from-src.sh to regenerate the + syscall group info against Linux kernel, just add loongarch case. + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Generate loongarch-linux.xml + Make use of the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch-linux.xml.in + There is no syscall.tbl for LoongArch because it uses generic syscalls, + so it can not generate loongarch-linux.xml.in automatically through the + script update-linux-from-src.sh, make use of the script update-linux.sh + to generate loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ touch loongarch-linux.xml.in + $ ./update-linux.sh loongarch-linux.xml.in + + Note that the system header file /usr/include/asm-generic/unistd.h + may be different with the latest upstream Linux kernel uapi header + file include/uapi/asm-generic/unistd.h, it is better to copy the + upstream header file into the system header file when generating + loongarch-linux.xml.in. + + There exist some __NR3264_ prefixed syscall numbers, replace them + with digital numbers according to /usr/include/asm-generic/unistd.h + and sort them by syscall number manually, maybe we can modify the + script to do it automatically in the future. + + + + + + + + + + + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml files for some archs + Make use of the command "make" to regenerate .xml files from .xml.in files. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml.in files for some archs + Make use of the script update-linux-from-src.sh to regenerate the Linux + syscall group info against Linux git commit d206a76d7d27 which will be + released in v6.8. + + Like this: + + $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-from-src.sh ~/linux.git/ + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update linux-defaults.xml.in + Make use of the script update-linux-defaults.sh to regenerate the Linux + syscall group info against strace git commit 8c480270653d which will be + released in v6.8. + + Like this: + + $ git clone https://github.com/strace/strace.git strace.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-defaults.sh ~/strace.git/ + + Approved-By: John Baldwin + +2024-03-20 Tom de Vries + + [gdb/symtab] Workaround PR gas/31115 + On arm-linux, with gas 2.40, I run into: + ... + (gdb) x /i main+8^M + 0x4e1 : vrhadd.u16 d14, d14, d31^M + (gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) + ... + + This is a regression due to PR gas/31115, which makes gas produce a low_pc + with the thumb bit set (0x4d8 & 0x1): + ... + <1><24>: Abbrev Number: 2 (DW_TAG_subprogram) + <25> DW_AT_name : main + <29> DW_AT_external : 1 + <29> DW_AT_type : <0x2f> + <2a> DW_AT_low_pc : 0x4d9 + <2e> DW_AT_high_pc : 12 + ... + + The regression was introduced in 2.39, and is also present in 2.40 and 2.41, + and hasn't been fixed yet. + + Work around this in read_func_scope, by using gdbarch_addr_bits_remove on + low_pc and high_pc. + + Tested on arm-linux and x86_64-linux. + + PR tdep/31453 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453 + +2024-03-20 GDB Administrator + + Automatic date update in version.in + +2024-03-19 Tom Tromey + + Speed up lookup of "type_specific_data" + I noticed that "info locals" on a certain large Ada program was very + slow. I tracked this down to ada_get_tsd_type expanding nearly every + CU in the program. + + This patch fixes the problem by changing this code to use the more + efficient lookup_transparent_type which, unlike the Ada-specific + lookup functions, does not try to find all matching instances. + + Note that I first tried fixing this by changing ada_find_any_type, but + this did not work -- I may revisit this approach at some later date. + + Also note that the copyright dates on the test files are set that way + because I copied them from another test. + + New in v2: the new test failed on the Linaro regression tester. + Looking at the logs, it seems that gdb was picking up a 'value' from + libgnat: + + $1 = {} 0xf7e227a4 + + This version renames the local variable in an attempt to work around + this. + + v3: In v2, while trying to reproduce the problem locally, I + accidentally forgot to commit one of the changes. + +2024-03-19 Tom Tromey + + Fix two serious flake8 reports + flake8 points out that some code in frame_filters.py is referring to + undefined variables. + + In the first hunk, I've changed the code to match what other + 'complete' methods do in this file. + + In the second hunk, I've simply removed the try/except -- if + get_filter_priority fails, it will raise GdbError, which is already + handled properly by gdb. + +2024-03-19 Andrew Burgess + + gdb/python: test exception case for gdb.solib_name + The gdb.solib_name() and Progspace.solib_name() functions can throw an + exception if the address argument is not a valid address, but this is + not currently tested. + + This commit adds a couple of tests to check that exceptions are thrown + correctly. + + An early version of this commit updated the documentation, but it was + pointed out that lots of functions throw an exception if passed an + argument of the wrong type, and we don't document all of these, it's + kind-of assumed that passing an object of the incorrect type might + result in an exception, so this updated version leaves the docs alone, + but I do think adding the extra tests has value. + + There's no changes to GDB itself in this commit. + + Approved-By: Tom Tromey + +2024-03-19 Saurabh Jha + + gas, aarch64: Add faminmax extension + +2024-03-19 Nick Clifton + + Remove redunant test of ELF size in core note decoder. + PR 31469 + +2024-03-19 Andrew Burgess + + gdbsupport: rename include guard in gdb-checked-static-cast.h + I noticed in passing that the include guard in the file + gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word + DYNAMIC when STATIC would be better, fixed in this commit. + + There should be no user visible changes after this commit. + +2024-03-19 Andrew Burgess + + gdb: use static_cast in gdb::checked_static_cast + This commit: + + commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf + Date: Sat Feb 24 11:00:20 2024 +0100 + + [gdb/build] Fix static cast of virtual base + + addressed an issue where GDB would not compile in production mode due + to a use of gdb::checked_static_cast. The problem was that we were + asking GDB to cast from a virtual base class to a sub-class, this + works fine when using dynamic_cast, but does not work with + static_cast. + + The gdb::checked_static_cast actually uses dynamic_cast under the hood + in development mode in order to ensure that the cast is valid, while + in a production build we use static_cast as this is more efficient. + + What this meant however, was that when gdb::checked_static_cast was + used to cast from a virtual base class, the dynamic_cast of a + non-production build worked fine, while the production build's + static_cast caused a build failure. + + However, the gdb::checked_static_cast function already contains some + static_assert calls that are intended to catch any issues with invalid + type casting, the goal of these asserts was to prevent issues like + this: the build only failing in production mode. Clearly the current + asserts are not enough. + + I don't think there is a std::is_virtual_base type trait check, so + what I propose instead is that in non-production mode we also make use + of static_cast. This will ensure that any errors that crop up in + production mode should also be revealed in non-production mode, and + should catch issues like this in the future. + + There should be no user visible changes after this commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + + Co-Authored-By: Simon Marchi + +2024-03-19 Nick Clifton + + Fix seg-fault in the DWARF reader code when accessing an abbreviatuin table with a corrupt entry offset. + PR 31456 + +2024-03-19 H.J. Lu + + ld: Support LD_UNDER_TEST environment variable + Support LD_UNDER_TEST environment variable to test a different linker. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + + * testsuite/config/default.exp: If LD_UNDER_TEST environment + variable exists, set ld and LD to it and set up tmpdir/ld/ld. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + +2024-03-19 Nick Clifton + + Fix free of unallocated memory in the BFD library's compression code. + PR 31455 + + Fix typo in previous patch to ld.texi + +2024-03-19 Toby Lloyd Davies + + gdb/python: Fix segfault when iterating over empty linetable + symtab-> linetable () is set to null in + buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab + has no linetable. Attempting to iterate over this linetable using the + Python API caused GDB to segfault. + + Approved-By: Tom Tromey + +2024-03-19 Toby Lloyd Davies + + Add myself to gdb/MAINTAINERS + +2024-03-19 Tom de Vries + + [gdb] Further fix "value is not available" with debug frame + In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame") + I fixed a case in frame_unwind_register_value where using "set debug frame on" + caused an "info frame" command to abort, reporting a "value is not available" + error, due to the tpidruro register being unavailable. + + Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from + non-FreeBSD target descriptions") removed the unavailable register, which + caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp. + + While investigating the progression (see PR python/31437), I found that the + "debug frame" output of the test-case (when reverting commit bbb12eb9c84) + showed a smilar problem: + ... + Python Exception : value is not available^M + ... + that was absent without "debug frame". + + Fix this likewise in fetch_lazy_register, and update the test-case to check + for the exception. + + Furthermore, I realized that there's both value::entirely_available and + value::entirely_unavailable, and that commit 2aaba744467 handled the case + of !entirely_available by printing unavailable. + + Instead, print: + - "unavailable" for entirely_unavailable, and + - "partly unavailable" for !entirely_unavailable && !entirely_available. + + Tested on x86_64-linux and arm-linux. + +2024-03-19 mengqinggang + + LoongArch: Add relaxation for R_LARCH_CALL36 + This relaxation is effective for both macro instructions (call36, tail36) + and explicit relocation instructions (pcaddu18i + jirl). + + call36 f -> bl f + R_LARCH_CALL36 -> R_LARCH_B26 + + tail36 $t0, f -> b f + R_LARCH_CALL36 -> R_LARCH_B26 + +2024-03-19 GDB Administrator + + Automatic date update in version.in + +2024-03-18 Nick Clifton + + Regenerate AArch64 opcodes files + +2024-03-18 Yury Khrustalev + + aarch64: Add support for SVE ADDPT, SUBPT, MADPT, MLAPT instructions + The following instructions are added in this patch: + + - ADDPT (predicated): Add checked pointer vectors (predicated). + - ADDPT (unpredicated): Add checked pointer vectors (unpredicated). + - SUBPT (predicated): Subtract checked pointer vectors (predicated). + - SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated). + - MADPT: Multiply-add checked pointer vectors, writing multiplicand + - MLAPT: Multiply-add checked pointer vectors, writing addend + + These instructions are part of Checked Pointer Arithmetic extension + and are enabled when both CPA and SVE are enabled. To achieve this, + both flag "+sve" and "+cpa" should be active. + + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Yury Khrustalev + + aarch64: Add support for (M)ADDPT and (M)SUBPT instructions + The following instructions are added in this patch: + + - ADDPT and SUBPT - Add/Subtract checked pointer + - MADDPT and MSUBPT - Multiply Add/Subtract checked pointer + + These instructions are part of Checked Pointer Arithmetic extension. + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + A new flag "+cpa" added to documentation. This flag enables CPA extension. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Nick Clifton + + [PATCH] ld: Improve documentation of -rpath-link search paths + +2024-03-18 Tom Tromey + + Remove some unnecessary Ada expression code + ada_bitwise_operation differs from the "usual" bitwise operations only + in that it calls value_cast at the end. However, because gdb is + generally fairly lax about integer types, and because (perhaps oddly) + C-style binary promotion is done here anyway, it seems to me that this + code isn't needed. + +2024-03-18 Tom Tromey + + Fix Ada 'ptype' of access to array + ptype is a bit funny, in that it accepts both expressions and type + names. It also evaluates the resulting expression using + EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would + you expect ptype to possibly cause inferior execution?), but is also a + historical artifact of how expressions are implemented (there's no + EVAL_FOR_TYPE). + + In Ada, calling a function with an array will sometimes result in a + "thick pointer" array descriptor being made. This is essentially a + structure holding a pointer and bounds information. + + Currently, in such a callee, printing the type of the array will yield + funny results: + + (gdb) print str.all + $1 = "Hello World" + (gdb) ptype str + type = array (<>) of character + (gdb) ptype str.all + type = array (1 .. 0) of character + + That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch + trying to do "something" with an array descriptor, without doing too + much. + + I tried briefly to make this code really dereference the array + descriptor and get the correct runtime type. However, that proved to + be tricky; it certainly can't be done for all access types, because + that will cause dynamic type resolution and end up printing just the + runtime type -- which with variants may be pretty far from what the + user may expect. + + Instead, this patch arranges to just leave such types alone in this + situation. I don't think this should have an extra effects, because + things like array subscripting still work on thick pointers. + + This patch also touches arrayptr.exp, because in that case the access + type is a "thin pointer", and this ensures that the output does not + change in that scenario. + +2024-03-18 Tom Tromey + + Use string_view in quirk_rust_enum + quirk_rust_enum makes string copies to store in an unordered_map. + However, the original strings have an appropriate lifetime, and so no + copying is needed. With C++17, we can rely on string_view having a + std::hash specialization, so this patch changes this code to use + string_view rather than string. + +2024-03-18 Tom Tromey + + Set __file__ when source'ing a Python script + This patch arranges to set __file__ when source'ing a Python script. + This fixes a problem that was introduced by the "source" rewrite, and + then pointed out by Lancelot Six. + + Reviewed-by: Lancelot Six + Approved-By: Andrew Burgess + +2024-03-18 Tom Tromey + + Clear board_info entry after waiting for process + When certain DAP tests are run in a certain order, dejagnu will throw + an exception during shutdown. After adding many logging statements, I + tracked this down to kill_wait_spawned_process not clearing the + 'fileid' board_info entry, causing dejagnu to try to wait for the + process a second time -- and fail. + + Tom de Vries then pointed out a second instance of this, which I + tracked down to the same problem occurring when spawning gdbserver. + + This version of the patch fixes this by adding a new proc that can be + used to clean up board_info after waiting for a process to exit. I'm + not sure why this problem hasn't affected the test suite in the past. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435 + Approved-By: Andrew Burgess + +2024-03-18 Clément Chigot + + bfd: add missing include + bdfio.c is defining bfd_get_current_time which is returning a time_t. + This type is defined in time.h and thus, must be included in bfd main + header to avoid undefined type when include bfd.h. + + Note that most of the time, is pulled by already + included in bfd.h. That's why it went unnoticed. + +2024-03-18 Nick Clifton + + Fix compiling bfd/vms-lib.c for a 32-bit host. + +2024-03-18 Andrew Burgess + + gdb/testsuite: attach to i386 process stopped in vDSO + Fedora GDB has carried around a patch for a while which tested + attaching to an i386 process which is stopped within the vDSO library + region. Apparently, at some point in the distant past there was an + issue finding symbol information for this region in this situation. + + I'm struggling to track down the precise details of what the original + bug was, however, acquiring symbol information for the vDSO region is + different than for "normal" shared libraries -- the vDSO information + is synthesised within GDB during the attach / inferior creation + process -- so it's not unreasonable to imagine that there could be a + bug specifically in this area of GDB which wouldn't impact "normal" + shared libraries. + + I looked for references to vDSO in our testsuite and couldn't find + any tests that looked like they did the same sort of thing, so I'd + like to propose adding this test to our testsuite. + + It's a pretty simple test, and doesn't take long to run, so the cost + of adding this is not huge. + + Approved-By: Tom Tromey + +2024-03-18 Jan Beulich + + Arm64: check matching operands for predicated B16B16 insns + Except for bfml{a,s} their 1st and 3rd operands need to match - pass + the TIED macro argument accordingly. While doing that also slightly + re-arrange table entries, such that all predicated insns are close + together. + + At the same time change the existing test source to actually use non- + matching operands for the respective bfml{a,s} forms. + +2024-03-18 Jan Beulich + + Arm64: correct B16B16 indexed bf{mla,mls,mul} + Their index is in bits 19, 20, and 22. Bit 11 in particular is already + set in the base opcode. Note also how disassembler output didn't match + assembler input in the respective testcase. + +2024-03-18 Nelson Chu + + RISC-V: Tidy smstateen and ssstateen testcases. + gas/ + * testsuite/gas/riscv/march-imply-smstateen.d: Added. + * testsuite/gas/riscv/smstateen-csr-s.d: Removed. + * testsuite/gas/riscv/ssstateen-csr.d: Likewise. + * testsuite/gas/riscv/ssstateen-csr.s: Likewise. + +2024-03-18 GDB Administrator + + Automatic date update in version.in + +2024-03-17 Tom de Vries + + [gdb/testsuite] Fix gdb.base/list-no-debug.exp on debian + On debian 12, aarch64-linux I run into: + ... + (gdb) list .^M + No symbol table is loaded. Use the "file" command.^M + (gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .' + ... + + The test-case expects some debug info, but none for main. Instead, there's no + debug info at all. + + Fix this by adding another source file to the test-case, and compiling it with + debug info. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + PR testsuite/31290 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290 + +2024-03-17 GDB Administrator + + Automatic date update in version.in + +2024-03-16 GDB Administrator + + Automatic date update in version.in + +2024-03-15 Tom Tromey + + Use size_t in gdb_bfd_section_data + BFD recently changed bfd_mmap to use size_t, not bfd_size_type. This + patch updates gdb_bfd_section_data to follow. Without this patch, if + the two types ever differ, gdb would fail to build. + + Approved-By: Simon Marchi + +2024-03-15 Andrew Carlotti + + gas/NEWS: Remove mention of AArch64 B16B16 extension + This aligns the 2.42 NEWS with the update backported to the 2.42 release + branch. + +2024-03-15 Jan Beulich + + x86/APX: legacy promoted insns can't access %xmm16-%xmm31 + Irrespective of the encoding being EVEX, the usable SIMD register range + continues to be limited to %xmm0-%xmm15. Enforce this in gas (but + continue to generate code, as in principle we know how to encode + things) and recognize/flag the case in the disassembler. + + Oddly enough wrong forms were actually used in the testsuite (register- + only forms are then really meaningless to test here, and are hence + dropped instead of adjusted). + + Convert the POP2 test that needs touching anyway (due to a bad ModR/M + byte having been chosen) to .insn. + +2024-03-15 GDB Administrator + + Automatic date update in version.in + +2024-03-14 Tom de Vries + + [gdb/build] Fix build on postmarketos + I tried building gdbserver on postmarketos (which is based on alpine linux, + which uses musl libc), and ran into: + ... + gdbserver/linux-low.cc: In lambda function: + gdbserver/linux-low.cc:1907:41: error: \ + 'W_EXITCODE' was not declared in this scope + 1907 | mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true); + | ^~~~~~~~~~ + ... + + The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h. + + OTOH, WSETEXIT is defined there, but unused: + ... + /* These are not defined in POSIX, but are used by our programs. */ + + #ifndef WSETEXIT + # ifdef W_EXITCODE + #define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0)) + # else + #define WSETEXIT(w,status) ((w) = (0 | ((status) << 8))) + # endif + #endif + ... + + Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE. + + Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make + sure the definition is exercised. + + Approved-By: Tom Tromey + + PR build/31483 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483 + +2024-03-14 Simon Marchi + + gdbserver/linux: probe for libiconv in configure + Make gdbserver's build system locate libiconv when building for Linux. + + Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names") + make libiconv madantory for building gdbserver on Linux. + + While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a + toolchain generated with crosstool-ng), I got: + + /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory + 48 | #include + | ^~~~~~~~~ + + I downloaded GNU libiconv, built it for that host, and installed it in + an arbitrary directory. I had to modify the gdbserver build system to + locate libiconv and use it, the result is this patch. + + I eventually found that crosstool-ng has a config option to make uclibc + provide an implementation of iconv, which is of course much easier. But + given that this patch is now written, I think it would be worth merging + it, it could help some people who do not have iconv built-in their libc + in the future (and may not have the luxury of rebuilding their libc like + I do). + + Using AM_ICONV in configure.ac adds these options for configure (the + same we have for gdb): + + --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib + --without-libiconv-prefix don't search for libiconv in includedir and libdir + --with-libiconv-type=TYPE type of library to search for (auto/static/shared) + + It sets the `LIBICONV` variable with whatever is needed to link with + libiconv, and adds the necessary `-I` flag to `CPPFLAGS`. + + To avoid unnecessarily linking against libiconv on hosts that don't need + it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the + host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`. + + Since libiconv is a hard requirement for Linux hosts, error out if it is + not found. + + The bits in acinclude.m4 are similar to what we have in + gdb/acinclude.m4. + + Update the top-level build system to support building against an in-tree + libiconv (I did not test this part though). Something tells me that the + all-gdbserver dependency on all-libiconv is unnecessary, since there is + already a dependency of configure-gdbserver on all-libiconv (and + all-gdbserver surely depends on configure-gdbserver). I just copied + what's done for GDB though. + + ChangeLog: + + * Makefile.def: Add configure-gdbserver and all-gdbserver + dependencies on all-libiconv. + * Makefile.in: Re-generate. + + Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4 + Approved-By: Tom Tromey + +2024-03-14 Tom Tromey + + Pass alignment when using GCC_C_FE_VERSION_2 + When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can + use the new 'finish_record_with_alignment' method. This lets gdb pass + alignment information to the compiler, which in turn fixes the test + case included in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-03-14 Tom Tromey + + Remove 'if' from GDB_PY_HANDLE_EXCEPTION + This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and + GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with + the old gdb try/catch macros, but it no longer is: these should only + ever be called from a 'catch' block, where it's already known that an + exception was thrown. + + Simon pointed out, though, that in a few spots, these were in facts + called outside of 'catch' blocks. This patch cleans up these spots. + I also found one spot where a redundant 'return nullptr' could be + removed. + +2024-03-14 Tom de Vries + + [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into: + ... + (gdb) watch data.u.size8twice[1]^M + Hardware watchpoint 241: data.u.size8twice[1]^M + (gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1] + continue^M + Continuing.^M + FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) + FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write + ... + + This happens as follows. + + We start the exec and set an 8-byte hardware watchpoint on + data.u.size8twice[1] at address 0x440048: + ... + (gdb) p sizeof (data.u.size8twice[1]) + $1 = 8 + (gdb) p &data.u.size8twice[1] + $2 = (uint64_t *) 0x440048 + ... + + We continue execution, and a 16-byte write at address 0x440040 triggers the + hardware watchpoint: + ... + 4101c8: a9000801 stp x1, x2, [x0] + ... + + When checking whether a watchpoint has triggered in + aarch64_stopped_data_address, we check against address 0x440040 (passed in + parameter addr_trap). This behaviour is documented: + ... + /* ADDR_TRAP reports the first address of the memory range + accessed by the CPU, regardless of what was the memory + range watched. ... */ + ... + and consequently the matching logic compares against an addr_watch_aligned: + ... + && addr_trap >= addr_watch_aligned + && addr_trap < addr_watch + len) + ... + + However, the comparison fails: + ... + (gdb) p /x addr_watch_aligned + $3 = 0x440048 + (gdb) p addr_trap >= addr_watch_aligned + $4 = false + ... + + Consequently, aarch64_stopped_data_address returns false, and + stopped_by_watchpoint returns false, and watchpoints_triggered returns 0, + which make infrun think it's looking at a delayed hardware + breakpoint/watchpoint trap: + ... + [infrun] handle_signal_stop: stop_pc=0x4101c8 + [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring + ... + Infrun then ignores the trap and continues, but runs into the same situation + again and again, causing a hang which then causes the test timeout. + + Fix this by allowing a match 8 bytes below addr_watch_aligned. This + introduces the possibility for false positives, so we only do this for regular + "value changed" watchpoints. + + An earlier version of this patch worked by aligning addr_watch_aligned to 16 + instead of 8: + ... + - const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8); + + const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16); + ... + but while that fixed the test-case, it didn't fix the problem completely, so + extend the test-case to check more scenarios. + + Tested on aarch64-linux. + + Tested-By: Luis Machado + Approved-By: Luis Machado + + PR tdep/29423 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + +2024-03-14 GDB Administrator + + Automatic date update in version.in + +2024-03-13 Tom Tromey + + Remove extraneous word from manual + I noticed that the manual has an extra "either", which makes a + sentence ungrammatical. This patch removes it. + +2024-03-13 Christophe Lyon + + opcodes: Fix build verbosity + Add $(AM_V_xxx) in a few places where they were missing. + +2024-03-13 H.J. Lu + + bfd: Use size_t in the BFD mmap interface + Change the size type in the BFD mmap interface from bfd_size_type to + size_t to be consistent with the size type of the host mmap interface. + + * bfdio.c (bfd_iovec): Change the bmmap size type to size_t. + (bfd_mmap): Likewise. + (memory_bmmap): Likewise. + * cache.c (cache_bmmap): Change the bmmap size type to size_t. + * opncls.c (opncls_bmmap): Change the bmmap size type to size_t. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-03-13 H.J. Lu + + bfd: Use MAP_FAILED for mmap failure + Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use + ((void *) -1) only if MAP_FAILED is undefined. + + * bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * bfdwin.c: Don't include . + (MAP_FILE): Removed. + (bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * cache.c: Don't include . + (cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap + failure. + * opncls.c (opncls_bmmap): Likewise. + * sysdep.h: Include if HAVE_MMAP is define. + (MAP_FILE): New. Defined as 0 if undefined. + (MAP_FAILED): New. Defined as ((void *) -1) if undefined. + +2024-03-13 H.J. Lu + + bfd: Don't call bfd_write with 0 size + There is no need to call bfd_write with 0 size. + + * elf-strtab.c (_bfd_elf_strtab_emit): Don't call bfd_write with + 0 size. + +2024-03-13 Hau Hsu + + RISC-V: Add -march=help for gas + Use -march=help for gas to print all supported extensions and versions. + + Here is part of the output of `as -march=help`: + All available -march extensions for RISC-V: + e 1.9 + i 2.1, 2.0 + m 2.0 + a 2.1, 2.0 + f 2.2, 2.0 + d 2.2, 2.0 + q 2.2, 2.0 + c 2.0 + v 1.0 + h 1.0 + zicbom 1.0 + zicbop 1.0 + ... + + This patch assumes that the supported extensions with the same versions + are listed together. For example: + static struct riscv_supported_ext riscv_supported_std_ext[] = + { + ... + {"i", ISA_SPEC_CLASS_20191213, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_20190608, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_2P2, 2, 0, 0 }, + ... + }; + + For the "i" extension, 2.1.0 with different spec class are listed together. + This patch records the previous printed extension and version. If the + current extension and version are the same as the previous one, skip + printing. + + bfd/ + * elfxx-riscv.c (riscv_print_extensions): New function. Print + available extensions and versions. + * elfxx-riscv.h (riscv_print_extensions): New declaration. + gas/ + * gas/config/tc-riscv.c (md_parse_option): Parse 'help' keyword in + -march option to print available extensions and versions. + * testsuite/gas/riscv/march-help.l: New testcase for -march=help. + * testsuite/gas/riscv/riscv.exp: Updated. + +2024-03-13 GDB Administrator + + Automatic date update in version.in + +2024-03-12 Tom de Vries + + [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Hardware watchpoint 2: -location q.a^M + ^M + Old value = 1^M + New value = 0^M + main () at watch-bitfields.c:42^M + 42 q.h--;^M + (gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue + ... + + In a minimal form, if we step past line 37 which sets q.e, and we have a + watchpoint set on q.e, it triggers: + ... + $ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step + Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37. + + Breakpoint 1, main () at watch-bitfields.c:37 + 37 q.e = 5; + Hardware watchpoint 2: q.e + + Hardware watchpoint 2: q.e + + Old value = 0 + New value = 5 + main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38 + 38 q.f = 6; + ... + + However, if we set in addition a watchpoint on q.a, the watchpoint on q.e + doesn't trigger. + + How does this happen? + + Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1 + and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should + watch bytes 1 and 2. + + Using "maint set show-debug-regs on" (and some more detailed debug prints) we + get: + ... + WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1 + ctrl: enabled=1, offset=1, len=2 + WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1 + ctrl: enabled=1, offset=0, len=1 + ... + which matches that. + + When executing line 37, a hardware watchpoint trap triggers and we hit + aarch64_stopped_data_address with addr_trap == 0x440028: + ... + (gdb) p /x addr_trap + $1 = 0x440028 + .... + and since the loop in aarch64_stopped_data_address walks backward, we check + WP3 first, which matches, and consequently target_stopped_by_watchpoint + returns true in watchpoints_triggered. + + Likewise for target_stopped_data_address, which also returns addr == 0x440028. + Watchpoints_triggered matches watchpoint q.a to that address, and sets + watch_triggered_yes. + + However, subsequently the value of q.a is checked, and it's the same value as + before (becase the insn in line 37 didn't change q.a), so the watchpoint + hardware trap is not reported to the user. + + The problem originates from that fact that aarch64_stopped_data_address picked + WP3 instead of WP2. + + There's something we can do about this. In the example above, both + target_stopped_by_watchpoint and target_stopped_data_address returned true. + Instead we can return true in target_stopped_by_watchpoint but false in + target_stopped_data_address. This lets watchpoints_triggered known that a + watchpoint was triggered, but we don't know where, and both watchpoints + get set to watch_triggered_unknown. + + Subsequently, the values of both q.a and q.e are checked, and since q.e is not + the same value as before, the watchpoint hardware trap is reported to the user. + + Note that this works well for regular (write) watchpoints (watch command), but + not for read watchpoints (rwatch command), because for those no value is + checked. Likewise for access watchpoints (awatch command). + + So, fix this by: + - passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and + aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not + interested in the stop address, + - introducing a two-phase approach in aarch64_stopped_data_address, where: + - phase one handles access and read watchpoints, as before, and + - phase two handles write watchpoints, where multiple matches cause: + - return true if addr_p == null, and + - return false if addr_p != null. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + + PR tdep/31214 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214 + +2024-03-12 Sam James + + contrib: sync dg-extract-results.sh with GCC + This syncs dg-extract-results.sh with GCC. + + It contains two commits: r14-4333-g346f5991569fae and r14-9393-g64273a7e6bd8ba. + + contrib/ChangeLog: + * dg-extract-results.sh: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Sam James + + contrib: sync dg-extract-results.py with GCC + This syncs dg-extract-results.py with GCC. + + It contains only one commit: r14-7145-g8f67953d0198fe. + + contrib/ChangeLog: + * dg-extract-results.py: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Schimpe, Christina + + gdb: Deprecate MPX commands. + This patch deprecates the MPX commands "show/set mpx bound". + Intel listed Intel(R) Memory Protection Extensions (MPX) as removed + in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35, + deprecate MPX in GDB. + +2024-03-12 Lulu Cai + + LoongArch: Scan all illegal operand instructions without interruption + Currently, gas will exit immediately and report an error when + it sees illegal operands, and will not process the remaining + instructions. Replace as_fatal with as_bad to check for all + illegal operands. + + Add test cases for illegal operands of some instructions. + +2024-03-12 Lulu Cai + + LoongArch: Fix gas and ld test cases + * After adding the old LE relax, all old LE relocations will have + an R_LARCH_RELAX relocation. Fix the gas test case failure caused + by the implementation of the old LE relax. + + * loongarch64-elf does not support pie and -z norelro options, + removed in test files. + +2024-03-12 Simon Marchi + + gnulib: re-generate build files + I see some changes in the generated files when running update-gnulib.sh. + The changes appeared with commit 35b38b0182d0 ("Finalized intl-update + patches (trois)"). This is most likely due to how the autotools were + ran in that commit, possibly with some different -I arguments. + + Change-Id: Idaad8084b0e91e22d066f573775e21d0c7a039cb + +2024-03-12 GDB Administrator + + Automatic date update in version.in + +2024-03-11 Sam James + + Sync libbacktrace from gcc [PR31327] + Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which + landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC. + + This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk. + + Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b + which would've required an autoreconf, as it should be handled separately. + + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Remove tui-out.[ch] + The other day on irc, we were discussing the "m_line" hack in + tui-out.c, and I mentioned that it would be nice to replace this with + a new ui_out_flag. + + Later, I looked at ui_out_flag and found: + + ui_source_list = (1 << 0), + + ... and sure enough, this is tested already. + + This patch removes tui-out.[ch] and changes the TUI to use an ordinary + cli-out object without this flag set. + + As far as I can tell, this doesn't affect behavior at all -- the TUI + tests all pass, and interactively I tried switching stack frames, + "list", etc, and it all seems to work. + + New in v2: fixed the problem pointed out by Keith, and added a test + case for that scenario. + + Reviewed-By: Andrew Burgess + +2024-03-11 Simon Marchi + + gdb/Makefile.in: remove ACLOCAL_AMFLAGS + aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in + configure.ac, so there's no need to pass `-I ../config` here. + + Passing `-I ../config` is actually annoying, because it makes the output + different between when the update is triggered by the maintainer mode + and when aclocal or autoreconf is ran with no special flags. The + difference in the output is due to the order of include paths being + different. + + Change-Id: I2c963876516570842f20b4a6a470867e7a941006 + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Special case NULL pointers in dynamic type resolution + commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically") + caused a regression on a test case in the AdaCore internal test suite. + + The issue here is that gdb would try to resolve the type of a dynamic + pointer that happened to be NULL. In this case, the "Location address + is not set." error would end up being thrown from the DWARF expression + evaluator. + + I think it makes more sense to special-case NULL pointers and not try + to resolve their target type, as that type can't really be accessed + anyway. + + This patch implements this idea, and also adds the missing Ada test + case. + +2024-03-11 Andrew Burgess + + gdb/testsuite: reformat file with a more recent version of black + A Python file in my previous commit (5eb2254a1d1) was formatted with + an older version of black, which gives slightly different results. + + Reformat with a newer version of black. This should make our + post-commit testing happy again. + + No functional changes in this commit. + +2024-03-11 Nick Alcock + + libctf: fix uninitialized variables in testsuite + Just because a path is an error path doesn't mean the program terminates + there if you don't ask it to. And we don't want to -- but that means + we need to initialize the variables that are missed if an error happens to + *something*. Type ID 0 (unimplemented) will do: it'll induce further + ECTF_BADID errors, but that's no bad thing. + + libctf/ChangeLog: + + * testsuite/libctf-writable/libctf-errors.c: Initialize variables. + +2024-03-11 Simon Marchi + + gdb: re-generate aclocal.m4 + I get some changes when running `autoreconf -vf` in the gdb directory, + fix that. + + I did a bisect, it appears to have been introduced in this commit, not + sure why we haven't spotted that before. + + commit 862776f26a59516467c98091994c3dac90383159 + Author: Arsen Arsenovi? + AuthorDate: Wed Nov 15 12:53:04 2023 +0000 + Commit: Nick Clifton + CommitDate: Wed Nov 15 12:53:04 2023 +0000 + + Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9 + +2024-03-11 Markus Metzger + + gdb, btrace: fix error diagnostics + When we improved error messages in + + cd393cec3ab gdb, btrace: improve error messages + + we cleared the original errno. When the error reason can not be explained + in a more detailed error message, and we fall back to the default error + message, it now gives Success as error. + + Restore the original errno to fix that. + +2024-03-11 Andrew Burgess + + gdb/unwinders: better support for $pc not saved + This started with a Red Hat bug report which can be seen here: + + https://bugzilla.redhat.com/show_bug.cgi?id=1850710 + + The problem reported here was using GDB on GNU/Linux for S390, the + user stepped into JIT generated code. As they enter the JIT code GDB + would report 'PC not saved', and this same message would be reported + after each step/stepi. + + Additionally, the user had 'set disassemble-next-line on', and once + they entered the JIT code this output was not displayed, nor were any + 'display' directives displayed. + + The user is not making use of the JIT plugin API to provide debug + information. But that's OK, they aren't expecting any source level + debug here, they are happy to use 'stepi', but the missing 'display' + directives are a problem, as is the constant 'PC not saved' (error) + message. + + What is happening here is that as GDB is failing to find any debug + information for the JIT generated code, it is falling back on to the + S390 prologue unwinder to try and unwind frame #0. Unfortunately, + without being able to identify the function boundaries, the S390 + prologue scanner can't help much, in fact, it doesn't even suggest an + arbitrary previous $pc value (some targets that use a link-register + will, by default, assume the link-register contains the previous $pc), + instead the S390 will just say, "sorry, I have no previous $pc value". + + The result of this is that when GDB tries to find frame #1 we end + throwing an error from frame_unwind_pc (the 'PC not saved' error). + This error is not caught anywhere except at the top-level interpreter + loop, and so we end up skipping all the 'display' directive handling. + + While thinking about this, I wondered, could I trigger the same error + using the Python Unwinder API? What happens if a Python unwinder + claims a frame, but then fails to provide a previous $pc value? + + Turns out that exactly the same thing happens, which is great, as that + means we now have a way to reproduce this bug on any target. And so + the test included with this patch does just this. I have a Python + unwinder that claims a frame, but doesn't provide any previous + register values. + + I then do two tests, first I stop in the claimed frame (i.e. frame #0 + is the frame that can't be unwound), I perform a few steps, and check + the backtrace. And second, I stop in a child of the problem + frame (i.e. frame #1 is the frame that can't be unwound), and from + here I check the backtrace. + + While all this is going on I have a 'display' directive in place, and + each time GDB stops I check that the display directive triggers. + + Additionally, when checking the backtrace, I am checking that the + backtrace finishes with the message 'Backtrace stopped: frame did not + save the PC'. + + As for the fix I chose to add a call to frame_unwind_pc directly to + get_prev_frame_always_1. Calling frame_unwind_pc will cache the + unwound $pc value, so this doesn't add much additional work as + immediately after the new frame_unwind_pc call, we call + get_prev_frame_maybe_check_cycle, which actually generates the + previous frame, which will always (I think) require a call to + frame_unwind_pc anyway. + + The reason for adding the frame_unwind_pc call into + get_prev_frame_always_1, is that if the frame_unwind_pc call fails we + want to set the frames 'stop_reason', and get_prev_frame_always_1 + seems to be the place where this is done, so I wanted to keep the new + stop_reason setting code next to all the existing stop_reason setting + code. + + Additionally, once we enter get_prev_frame_maybe_check_cycle we + actually create the previous frame, then, if it turns out that the + previous frame can't be created we need to remove the frame .. this + seemed more complex than just making the check in + get_prev_frame_always_1. + + With this fix in place the original S390 bug is fixed, and also the + test added in this commit, that uses the Python API, is also fixed. + + Reviewed-By: Kevin Buettner + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Reduce gdb.threads/threadcrash.exp reliance on libc symbols + The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and + print the names of all functions. However, some of the functions are + from the libc library, and so the test implicitly demanded libc symbols + to be available, and would fail otherwise, as was raised in PR + gdb/31293. + + This commit changes it so we only explicitly check for functions that + are not provided by threadcrash.c if they are indeed available. + + Tested on arm-linux and x86_64-linux. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293 + +2024-03-11 Tom de Vries + + gdb/testsuite: Simplify gdb.threads/threadcrash.exp + I noticed in gdb.threads/threadcrash.exp that the usage of test_list is + somewhat convoluted. + + Simplify the test-case by storing a classification instead of a pattern in + test_list. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Use _inferior_thread_count in gdb.threads/threadcrash.exp + A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails + to cout the number of threads in the inferior: + ... + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7 + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list] + ... + + Fix this by getting the convenience variable _inferior_thread_count as opposed + to calculating it based on the output of "info threads". + + Tested on arm-linux and x86_64-linux. + + Reviewed-By: Lancelot Six + Approved-By: Tom de Vries + + [1] https://linaro.atlassian.net/browse/GNU-1120 + +2024-03-11 Tom de Vries + + gdb/testsuite: Fix gdb.threads/threadcrash.exp with check-readmore + With check-readmore, I run into: + ... + FAIL: gdb.threads/threadcrash.exp: test_corefile: \ + $thread_count == [llength $test_list] + ... + + The problem is that the clauses in the gdb_test_multiple for + "thread apply all backtrace" intent to match one line, but actually can + match more than one line, and consequently a match for one type of thread can + consume a line that was supposed to match another thread. + + For instance, there's this regexp: + ... + -re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" { + ... + + It's limited at the end by \[^\n\]*, meaning the match stops at the end of the + line. + + But it doesn't start with a ^, and consequently can match more than one line. + The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at + the start of each pattern, unless it's anchored using a ^. + + Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where: + - hs is: \[^\n\]* (horizontal space), and + - eol is (?=\r\n) (look-ahead end-of-line). + + It also turned out to be necessary to drop the -lbl switch, and introduce a + corresponding explicit clause. The -lbl clause is placed ALAP, and + consequently allowed the default fail clause to trigger. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Tom de Vries + + gdb/testsuite: Reduce indentation in gdb.threads/threadcrash.exp + In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented + gdb_test_multiple: + ... + gdb_test_multiple "thread apply all backtrace" \ + "Get thread information" -lbl { + -re "#\[0-9\]+\\\?\\\?\[^\n\]*" { + ... + + Fix this by moving the command into a variable, allowing the + "gdb_test_multiple ... {" to fit on a single 80 chars line. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Jan Beulich + + x86: KeyLocker insn interaction with -msse-check / .sse_check + Some of these have no explicit %xmm operand(s), yet they still act SSE- + like (in leaveing bits 128 and up untouched). Hence they want similarly + diagnosing, if that was asked for. + + x86/APX: permit wider than 4-bit immediates with V{EXTRACT,INSERT}{F,I}128 + These aren't useful, but can be encoded for their AVX forms and hence + should also be permitted for the APX surrogates. Extend the respective + conditional by a base opcode check, to restrict it to VROUND{P,S}{S,D}. + + x86: don't open-code REG_{SP,FP} + Since we have the #define-s, we should also use them. + +2024-03-11 Stephen Kitt + + tests: force non-deterministic mode in non-deterministic tests + Since ar can be built defaulting to deterministic mode, tests which + expect non-deterministic behaviour need to explicitly set the U flag. + + The non-deterministic member test expects SOURCE_DATE_EPOCH to not be + set; this documents that. Unconditionally unsetting the variable + causes issues in test infrastructure (which expects unsetenv to only + be called on variables which are already set). + +2024-03-11 GDB Administrator + + Automatic date update in version.in + +2024-03-10 GDB Administrator + + Automatic date update in version.in + +2024-03-09 Tom de Vries + + [gdb/python] Handle deprecation of PyErr_{Fetch,Restore} in 3.12 + Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated. + + Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for + python >= 3.12. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Normalize exceptions in gdbpy_err_fetch + With python 3.12, I run into: + ... + (gdb) PASS: gdb.python/py-block.exp: check variable access + python print (block['nonexistent'])^M + Python Exception : 'nonexistent'^M + Error occurred in Python: 'nonexistent'^M + (gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable + ... + + The problem is that that PyErr_Fetch returns a normalized exception, while the + test-case matches the output for an unnormalized exception. + + With python 3.6, PyErr_Fetch returns an unnormalized exception, and the + test passes. + + Fix this by: + - updating the test-case to match the output for a normalized exception, and + - lazily forcing normalized exceptions using PyErr_NormalizeException. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Use gdbpy_err_fetch::{type,value} as getters + Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use + both consistently to get gdbpy_err_fetch members m_error_value and + m_error_type. + + Tested on aarch64-linux. + +2024-03-09 Alan Modra + + Reinstate bfd_print_error as an extern function + * bfd.c (_bfd_print): Renamed from bfd_print_error. + (bfd_print_error): Reinstate previous code but using the above. + (error_handler_fprintf, error_handler_sprintf): Adjust. + * bfd-in2.h: Regenerate. + +2024-03-09 Alan Modra + + Re: Move bfd_init to bfd.c + Commit b1c95bc4dd73 cleared some bfd static variables, with bad + results since bfd_set_error_program_name is often called before + bfd_init. + + * bfd.c (bfd_init): Don't clear _bfd_error_program_name. + +2024-03-09 Alan Modra + + print cached error messages using _bfd_error_handler + * bfd.c (bfd_print_error): Make static. Don't print program name. + (error_handler_fprintf): Print program name here. + * format.c (print_warnmsg): Use _bfd_error_handler to print + cached messages. + * bfd-in2.h: Regenerate. + +2024-03-09 Tom Tromey + + Avoid race when writing to index cache + The background DWARF reader changes introduced a race when writing to + the index cache. The problem here is that constructing the + index_cache_store_context object should only happen on the main + thread, to ensure that the various value captures do not race. + + This patch adds an assert to the construct to that effect, and then + arranges for this object to be constructed by the cooked_index_worker + constructor -- which is only invoked on the main thread. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262 + +2024-03-09 Tom Tromey + + Move the 'store' method to index_cache_store_context + I think it is cleaner for 'store' to be a method on + index_cache_store_context rather than on the global index cache + itself. This patch makes this change. + + Capture the per-BFD object in index_cache_store_context + This changes index_cache_store_context to also capture the per-BFD + object when it is constructed. This is used when storing to the + cache, and this approach makes the code a little simpler. + + Capture directory in index_cache_store_context + I noticed that index_cache_store_context captures the 'enabled' + setting, but not the index cache directory. This patch makes this + change, which avoids a possible race -- with background reading, the + user could possibly change this directory at the exact moment the + writer examines the variable. + + Rename members of index_cache_store_context + This renames the private members of index_cache_store_context to start + with "m_". + +2024-03-09 GDB Administrator + + Automatic date update in version.in + +2024-03-08 Tom Tromey + + Add return value to DAP scope + A bug report in the DAP specification repository pointed out that it + is typical for DAP implementations to put a function's return value + into the outermost scope. + + This patch changes gdb to follow this convention. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341 + Reviewed-By: Kévin Le Gouguec + +2024-03-08 Tom Tromey + + Export "finish" return value to Python + This patch changes the Python "stop" event emission code to also add + the function return value, if it is known. This happens when the stop + comes from a "finish" command and when the value can be fetched. + + The test is in the next patch. + + Reviewed-By: Eli Zaretskii + +2024-03-08 H.J. Lu + + gas: Fix x86 build with GCC 6.4 + Add "()" to silence GCC 6.4: + + .../gas/config/tc-i386.c: In function ‘x86_ginsn_lea’: + .../gas/config/tc-i386.c:5738:19: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses] + if (!i.base_reg != (!i.index_reg || i.index_reg->reg_num == RegIZ)) + ^~ + cc1: all warnings being treated as errors + + PR gas/31464 + * config/tc-i386.c (x86_ginsn_lea): Add "()" to silence GCC 6.4. + +2024-03-08 Tom Tromey + + Avoid race when reading dwz file + PR gdb/31260 points out a race introduced by the background reading + changes. If a given objfile is re-opened when it is already being + read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again, + causing the 'dwz_file' to be reset. + + This patch fixes the problem by arranging to open the dwz just once: + when the dwarf2_per_bfd object is created. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31260 + +2024-03-08 H.J. Lu + + bfd: Change the --with-mmap default to true + Change the configure default to using mmap. + + * configure.ac: Change the --with-mmap default to true. + * configure: Regenerated. + +2024-03-08 H.J. Lu + + bfd: Don't hard-code BFD_JUMP_TABLE_COPY + In BFD_JUMP_TABLE_COPY, replace _bfd_generic_init_private_section_data + with NAME##_init_private_section_data so that ELF targets can properly + replace it with _bfd_elf_init_private_section_data. + + * aout-target.h (MY_init_private_section_data): New. + * coff-rs6000.c (_bfd_xcoff_init_private_section_data): New. + * coffcode.h (coff_init_private_section_data): New. + * elfxx-target.h (bfd_elfNN_init_private_section_data): New. + * libecoff.h (_bfd_ecoff_init_private_section_data): New. + * mach-o-target.c (bfd_mach_o_init_private_section_data): New. + * mmo.c (mmo_init_private_section_data): New. + * plugin.c (bfd_plugin_init_private_section_data): New. + * ppcboot.c (ppcboot_init_private_section_data): New. + * som.c (som_init_private_section_data): New. + * targets.c (BFD_JUMP_TABLE_COPY): Replace + _bfd_generic_init_private_section_data with + NAME##_init_private_section_data. + * vms-alpha.c (vms_init_private_section_data): New. + * elf-bfd.h (_bfd_generic_init_private_section_data): Removed. + * bfd-in2.h: Regenerated. + +2024-03-08 Jiawei + + RISC-V: Support Zabha extension. + The Zabha extension[1] supports for byte and halfword + atomic memory operations. This patch add all instructions + include in Zabha. Further work is waiting Zacas[2] merge. + + [1] https://github.com/riscv/riscv-zabha/tags + [2] https://sourceware.org/pipermail/binutils/2023-May/127700.html + + Version log: + Add new imply relation that Zabha extension implies A extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): New imply. + (riscv_multi_subset_supports): New extension. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New test. + * testsuite/gas/riscv/zabha.d: New test. + * testsuite/gas/riscv/zabha.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOADD_B): New opcodes. + (MASK_AMOADD_B): Ditto. + (MATCH_AMOXOR_B): Ditto. + (MASK_AMOXOR_B): Ditto. + (MATCH_AMOOR_B): Ditto. + (MASK_AMOOR_B): Ditto. + (MATCH_AMOAND_B): Ditto. + (MASK_AMOAND_B): Ditto. + (MATCH_AMOMIN_B): Ditto. + (MASK_AMOMIN_B): Ditto. + (MATCH_AMOMAX_B): Ditto. + (MASK_AMOMAX_B): Ditto. + (MATCH_AMOMINU_B): Ditto. + (MASK_AMOMINU_B): Ditto. + (MATCH_AMOMAXU_B): Ditto. + (MASK_AMOMAXU_B): Ditto. + (MATCH_AMOSWAP_B): Ditto. + (MASK_AMOSWAP_B): Ditto. + (MATCH_AMOADD_H): Ditto. + (MASK_AMOADD_H): Ditto. + (MATCH_AMOXOR_H): Ditto. + (MASK_AMOXOR_H): Ditto. + (MATCH_AMOOR_H): Ditto. + (MASK_AMOOR_H): Ditto. + (MATCH_AMOAND_H): Ditto. + (MASK_AMOAND_H): Ditto. + (MATCH_AMOMIN_H): Ditto. + (MASK_AMOMIN_H): Ditto. + (MATCH_AMOMAX_H): Ditto. + (MASK_AMOMAX_H): Ditto. + (MATCH_AMOMINU_H): Ditto. + (MASK_AMOMINU_H): Ditto. + (MATCH_AMOMAXU_H): Ditto. + (MASK_AMOMAXU_H): Ditto. + (MATCH_AMOSWAP_H): Ditto. + (MASK_AMOSWAP_H): Ditto. + (DECLARE_INSN): New declare. + * opcode/riscv.h (enum riscv_insn_class): New class. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-03-08 GDB Administrator + + Automatic date update in version.in + +2024-03-07 GDB Administrator + + Automatic date update in version.in + +2024-03-06 Nick Clifton + + Add "-j1" to make command lines in the create-a-release README. + +2024-03-06 Lulu Cai + + LoongArch: Fix some test cases for TLS transition and relax + + LoongArch: Add dtpoff calculation function + When tls_sec is NULL, we should not access the virtual address + of tls_sec. + +2024-03-06 Lulu Cai + + LoongArch: Delete extra instructions when TLS type transition + This modification mainly changes the timing of type transition, + adds relaxation to the old LE instruction sequence, and fixes + bugs in extreme code models. + + We strictly distinguish between type transition and relaxation. + Type transition is from one type to another, while relaxation + is the removal of instructions under the same TLS type. Detailed + instructions are as follows: + + 1. For type transition, only the normal code model of DESC/IE + does type transition, and each relocation is accompanied by a + RELAX relocation. Neither abs nor extreme will do type transition, + and no RELAX relocation will be generated. + The extra instructions when DESC transitions to other TLS types + will be deleted during the type transition. + + 2. Implemented relaxation for the old LE instruction sequence. + The first two instructions of LE's 32-bit and 64-bit models + use the same relocations and cannot be distinguished based on + relocations. Therefore, for LE's instruction sequence, any code + model will try to relax. + + 3. Some function names have been adjusted to facilitate understanding, + parameters have been adjusted, and unused macros have been deleted. + +2024-03-06 Alan Modra + + Don't use bfd_error_handler in bfd_abort + We don't want to lose an abort message when bfd_set_error_handler has + been called to ignore or cache errors. + + PR ld/31444 + * bfd.c (_bfd_abort): Don't use _bfd_error_handler. + +2024-03-06 GDB Administrator + + Automatic date update in version.in + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.trace/circ.exp + This fixes some duplicate test names in gdb.trace/circ.exp when using + native-gdbserver and native-extended-gdbserver boards. + + In this test we set the trace buffer size twice. The same test name + was used each time the size was adjusted. + + I've fixed this issue by: + + 1. Creating a new proc, set_trace_buffer_size, which factors out the + code to change the buffer size, and uses test names based on the + size we're setting the buffer too, + + 2. Calling the new proc each time we want to adjust the buffer size. + + After this the duplicate test names are resolved. There should be no + change in what is tested after this commit. + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix some more duplicate test names in gdb.trace/ + This commit fixes some duplicate test names in the gdb.trace/ + directory when run with the native-gdbserver and + native-extended-gdbserver boards. In this case the duplicates relate + to the calls to gdb_compile_pthreads which emits a fixed PASS message, + as there are two calls to gdb_compile_pthreads we get a duplicate PASS + message. + + In both cases the problem is fixed by adding a with_test_prefix around + one of the compilations, however, I've made additional changes to + clean up the tests a little while I was working on them: + + 1. Switch to use prepare_for_testing instead of + gdb_compile_pthreads. By passing the 'pthreads' option this does + call gdb_compile_pthreads under the hood, but using the standard + compile function is cleaner, + + 2. Using prepare_for_testing removes the need to call clean_restart + immediately afterwards, so those calls are removed, + + 3. I removed the unneeded $executable and $expfile globals, where + the $executable global was used I've replaced this with $binfile, + + 4. When we compile two executables I've now given these different + names so that both exist at the end of the test run, + + 5. Removed a gdb_reinitialize_dir call, this is covered by + clean_restart, + + 6. Use gdb_test_no_output where it makes sense. + + I now see no duplicate test names when running these test scripts. + There should be no change in what is being tested after this commit. + +2024-03-05 Lulu Cai + + LoongArch: Add gas testsuit for LA32 relocations + Test the relocation of the LA32 instruction set. + + LoongArch: Add gas testsuit for LA64 relocations + Test the relocation of the LA64 instruction set. + + LoongArch: Add gas testsuit for LA32 int/float instructions + Test the int/float instructions of LA32. + + LoongArch: Add gas testsuit for LA64 int/float instructions + Test the int/float instructions of LA64. + + LoongArch: Add gas testsuit for lsx/lasx instructions + Test the LSX/LASX instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for lbt/lvz instructions + Test the LBT/LVZ instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for alias instructions + Test the alias instructions. + +2024-03-05 GDB Administrator + + Automatic date update in version.in + +2024-03-04 GDB Administrator + + Automatic date update in version.in + +2024-03-03 GDB Administrator + + Automatic date update in version.in + +2024-03-02 Hui Li + + gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35 + There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())" + in find_register_by_number() when gdb connects to gdbserver, this + is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains + 10 reserved regs) is different with the number of regs (35, which not + contains 10 reserved regs) in file gdb/features/loongarch/base64.xml. + Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to + keep consistent with the gdb/features/loongarch/base64.xml, and then + define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that + all the reg numbers in regcache are consistent with tdesc reg numbers. + + without this patch: + + Execute on the target machine: + + $ gdbserver 192.168.1.123:5678 ./test + + Execute on the host machine: + + $ gdb ./test + (gdb) target remote 192.168.1.123:5678 + + Output on the target machine: + + Process ./test created; pid = 67683 + Listening on port 5678 + Remote debugging from host 192.168.1.136, port 6789 + gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected. + find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed. + + Output on the host machine: + + Remote debugging using 192.168.1.123:5678 + Remote connection closed + + Approved-By: John Baldwin + +2024-03-02 Tom Tromey + + Fix TUI text centering + In a couple of spots, the TUI tries to center some text in the window. + Andrew noticed that the calculation is done strangely and the text + ends up somewhat to the left of center. + + This patch fixes the problem. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31355 + +2024-03-02 GDB Administrator + + Automatic date update in version.in + +2024-03-01 Will Hawkins + + gdb/jit: Fix missing word in comment + ChangeLog: + + * gdb/jit.c: Fix missing word in code comment. + +2024-03-01 Jens Remus + + s390: Be more verbose about missing operand type + Provide expected operand type in s390-specific assembler operand parsing + error message: + + "error: operand : missing operand" + + With being one of: + - base register + - displacement + - [vector] index register + - length + - access register + - control register + - floating-point register + - general-purpose register + - vector register + - [un]signed number + + gas/ + * config/tc-s390.c: Provide missing operand type in error + message. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + result validation patterns to operand number in operand syntax + error messages. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Provide operand number in assembler warning and error messages + Prepend the operand number "operand %d:" to the s390-specific assembler + operand parsing warning and error messages. + + While at it reword the custom operand out of range error message text to + be closer to the one used by as_bad_value_out_of_range(). Additionally + reword the invalid FPR pair warning message to make it nicer. + + gas/ + * config/tc-s390.c: Print operand number in error messages. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + verification patterns to accept syntax error messages now + containing the operand number. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + * testsuite/gas/s390/zarch-z900-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Allow to explicitly omit base register operand in assembly + The base register operand B may be omitted in D(B) by coding D and in + D(L,B) by coding D(L). The index register operand X may be omitted in + D(X,B) by coding D(B) or explicitly omitted by coding D(,B). In both + cases the omitted base register operand value defaults to zero. + + Allow to explicitly omit the base register operand B in D(X,B) and + D(L,B) by coding D(X,) and D(L,). Default the omitted base register + operand value to zero. + + gas/ + * config/tc-s390.c: Allow to explicitly omit the base register + operand in assembly. + * NEWS: Mention that the base register now may be omitted on + s390. + * gas/testsuite/gas/s390/zarch-base-index-0.s: Update test cases + for change to allow to explicitly omit the base register + operand in assembly. + * gas/testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.s: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.l: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.s: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.l: + Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Print base register 0 as "0" in disassembly + Base and index register 0 have no effect in address computation: + + "A value of zero in the B [base] or X [index] field specifies that no + base or index is to be applied, and, thus, general register 0 cannot be + designated as containing a base address or index." + IBM z/Architecture Principles of Operation [1], chapter "Organization", + section "General Registers". + + Index register 0 is omitted in the s390 disassembly. Base register 0 is + omitted in D(B), D(L,B) and D(X,B) - the latter only if the index + register is zero. + + To make it more apparent print base register 0 as "0" instead of "%r0", + whenever it would still be printed in the disassembly. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + opcodes/ + * s390-dis.c: Print base register 0 as "0" in disassembly. + + binutils/ + * NEWS: Mention base register 0 now being printed as "0" in s390 + disassembly. + + gas/ + * testsuite/gas/s390/zarch-base-index-0.d: Update test case + output verification patterns to accept "0" as base base + register due to disassembler output format change. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Warn when register name type does not match operand + Print a warning message when the register type of a specified register + name does not match with the operand's register type: + + operand {#}: expected {access|control|floating-point|general|vector} + register name [as {base|index} register] + + Introduce a s390-specific assembler option "warn-regtype-mismatch" + with the values "strict", "relaxed", and "no" as well as an option + "no-warn-regtype-mismatch" which control whether the assembler + performs register name type checks and generates above warning messages. + + warn-regtype-mismatch=strict: + Perform strict register name type checks. + + warn-regtype-mismatch=relaxed: + Perform relaxed register name type checks, which allow floating-point + register (FPR) names %f0 to %f15 to be specified as argument to vector + register (VR) operands and vector register (VR) names %v0 to %v15 to + be specified as argument to floating-point register (FPR) operands. + This is acceptable as the FPRs are embedded into the lower halves of + the VRs. Make "relaxed" the default, as GCC generates assembler code + using FPR and VR interchangeably, which would cause assembler warnings + to be generated with "strict". + + warn-regtype-mismatch=no: + no-warn-regtype-mismatch: + Disable any register name type checks. + + Tag .insn pseudo mnemonics as such, to skip register name type checks + on those. They need to be skipped, as there do not exist .insn pseudo + mnemonics for every possible operand register type combination. Keep + track of the currently parsed operand number to provide it as reference + in warning messages. + + To verify that the introduction of this change does not unnecessarily + affect the compilation of existing code the GNU Binutils, GNU C Library, + and Linux Kernel have been build with the new assembler, verifying that + the assembler did not generate any of the new warning messages. + + gas/ + * config/tc-s390.c: Handle new assembler options + "[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate + parsed register expressions with register type. Keep track of + operand number being parsed. Print warning message in case of + register type mismatch between instruction operand and parsed + register expression. + * doc/as.texi: Document new s390-specific assembler options + "[no-]warn-regtype-mismatch[=strict|relaxed|no]". + * NEWS: Mention new s390-specific register name type checks and + related assembler option "warn-regtype-mismatch=strict| + relaxed|no". + * testsuite/gas/s390/s390.exp: Add test cases for new assembler + option "warn-regtype-mismatch={strict|relaxed}". + * testsuite/gas/s390/esa-g5.s: Fix register types in tests for + didbr, diebr, tbdr, and tbedr. + * testsuite/gas/s390/zarch-z13.s: Fix register types in tests + for vgef, vgeg, vscef, and vsceg. + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s: + Tests for assembler option "warn-regtype-mismatch=strict". + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l: + Likewise. + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s: + Tests for assembler option "warn-regtype-mismatch=relaxed". + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update + test cases for assembler option "warn-regtype-mismatch" + defaulting to "relaxed". + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + include/ + * opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add + instruction flag to tag .insn pseudo-mnemonics. + + opcodes/ + * s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as + such. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Revise s390-specific assembler option descriptions + Reorder, reword, and complete the s390-specific option descriptions. + Align the formatting of s390-specific assembler options to that of the + general assembler options in "as --help". + + While at it change a warning message to use the term "z/Architecture" + instead of the deprecated "esame" (ESA Modal Extensions or ESAME) one. + + gas/ + * config/tc-s390.c: Revise s390-specific assembler option + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test case for disassembler option warn-areg-zero + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for s390-specific + assembler option "warn-areg-zero". + * testsuite/gas/s390/zarch-warn-areg-zero.s: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test cases for base/index register 0 + While at it add comments to logic to omit base and/or index register 0 + in s390 disassembly. + + opcodes/ + * s390-dis.c: Add comments related to omitting base and/or index + register 0 in disassembly. + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for base and/or + index register 0. + * testsuite/gas/s390/zarch-base-index-0.s: Add test cases for + base and/or index register 0. + * testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * testsuite/gas/s390/zarch-base-index-0-err.s: Add error test + cases for base and/or index register 0. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add comments to assembler operand parsing logic + gas/ + * config/tc-s390.c: Add comments to assembler operand parsing + logic. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Assemble processor specific test cases for their processor + Assemble the esa-g5 test case with -march=g5. + Assemble the zarch-z900 test case with -march=z900. + + gas/ + * testsuite/gas/s390/s390.exp: Assemble processor specific test + cases for their respective processor (-march=). + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Correct setting of highgprs flag in ELF output + The combination of an architecture size of 32 bits and z/Architecture + mode requires the highgprs flag to be set in the ELF output. It causes + the high-halves of the general purpose registers (GPRs) to be preserved + at run-time, so that the code can use 64-bit GPRs. + + The architecture size of 32 bits can either be the default in case of + a default architecture name of "s390" or due to specification of the + option -m31 (to generate the 31-bit file format). + The z/Architecture mode can either be the default or due to + specification of the option -mzarch (to assemble for z/Architecture + mode). It can also be selected using the pseudo commands + ".machinemode zarch" and ".machinemode zarch_nohighgprs". The latter + not causing the highgprs flag to be set. + + The highgprs flag was only set when the following s390-specific + assembler options were given in the following specific order: + "-m31 -mzarch". + + The highgprs flag was erroneously not set when: + - the order of above options was inverse (i.e. "-mzarch -m31"), + - the architecture mode defaulted to z/Architecture mode and + option "-m31" was specified, + - the architecture size defaulted to 32 bits due to a default + architecture name of "s390" and option -mzarch was specified, + - the architecture size defaulted to 32 bits and the architecture + mode defaulted to z/Architecture due to the specified processor + (e.g. "-march=z900" or follow-on processor). + + Determine whether to set the highgprs flag in init_default_arch() after + having processed all assembler options in md_parse_option(). This + ensures the flag is set in all of the above cases it was erroneously not + set. Add test cases for highgprs flag, including ones that use + .machinemode to switch the architecture mode. + + gas/ + * config/tc-s390.c: Correct setting of highgprs flag in ELF + output. + * testsuite/gas/s390/s390.exp: Add test cases for highgprs + flag. + * testsuite/gas/s390/blank.s: Empty assembler source used in + test cases for "highgprs" flag. + * testsuite/gas/s390/esa-highgprs-0.d: Add test case for + highgprs flag. + * testsuite/gas/s390/zarch-highgprs-0.d: Likewise. + * testsuite/gas/s390/zarch-highgprs-1.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-0.s: Add test case + for highgprs flag when using .machinemode to switch + architecture mode. + * testsuite/gas/s390/esa-highgprs-machinemode-0.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.s: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Do not erroneously use base operand value for length operand + The base register operand B may optionally be omitted in D(B) by coding + D and in D(L,B) by coding D(L). The index register operand X may + optionally be omitted in D(X,B) by coding D(,B) or D(B). Both base and + index register operands may optionally be omitted in D(X,B) by coding D. + In any case the omitted base and/or index register operand value + defaults to zero. + + When parsing an erroneously omitted length L operand in D(L,B) by coding + D(,B) the base register operand B was erroneously consumed as length + operand. When using a register name for the base register operand this + was detected and reported as error. But when not using a register name + the base register operand value was erroneously used as length operand + value. + + Correct the parsing of an omitted optional base or index register to not + erroneously use the base register operand value as length, when + erroneously omitting the length operand. + + While at it rename the variable used to remember whether the base or + index register operand was omitted to enhance code readability. + Additionally add test cases for the optional omission of base and/or + index register operands. + + Example assembler source: + mvc 16(1,%r1),32(%r2) + mvc 16(1),32(%r2) + mvc 16(,1),32(%r2) # undetected syntax error + + Disassembly of bad assembly without commit shows the base register + operand value was erroneously used as length operand value: + 0: d2 00 10 10 20 20 mvc 16(1,%r1),32(%r2) + 6: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + c: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + + Assembler messages with commit: + 3: Error: operand 1: missing operand + + gas/ + * config/tc-s390.c: Correct parsing of omitted base register. + * testsuite/gas/s390/s390.exp: Add test cases for omitted base + and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index.s: Test cases for + omitted optional base or index register. + * testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * testsuite/gas/s390/zarch-omitted-base-index-err.s: Test cases + for omitted base and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Enhance handling of syntax errors in assembler + Do not consume any unexpected character including newline ('\n') when + detecting a syntax error when parsing an operand block with parenthesis. + This resolves the unfavorable assembler messages from the example below, + including consuming the newline at the end of the current statement and + reporting the next statement as junk. + + While at it change the only pre-increment of the current instruction + string pointer into a post-increment to align with the other instances. + + Example assembler source: + mvi 16(),32 # syntax error + a %r1,16(%r2 # syntax error + a %r1,16(%r2) + mvc 16(1,),32(%r2) # syntax error + mvc 16(1,%r1,32(%r2 # syntax error + + Assembler messages without commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 1: Error: syntax error; expected ',' + 1: Error: junk at end of line: `32' + 2: Error: syntax error; missing ')' after base register + 2: Error: junk at end of line: `a %r1,16(%r2)' + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 4: Error: syntax error; expected ',' + 4: Error: operand out of range (32 is not between 0 and 15) + 4: Error: syntax error; missing ')' after base register + 4: Error: junk at end of line: `%r2)' + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; expected ',' + 5: Error: operand out of range (32 is not between 0 and 15) + 5: Error: syntax error; missing ')' after base register + 5: Error: junk at end of line: `%r2' + + Assembler messages with commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 2: Error: syntax error; missing ')' after base register + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + + gas/ + * config/tc-s390.c: Do not erroneously consume newline when + parsing an addressing operand with parentheses. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Lower severity of assembler syntax errors from fatal to error + Report s390 assembler syntax errors as error instead of fatal error. + This allows the assembler to continue and potentially report further + syntax errors in the source. This should not cause syntax errors to + be erroneously accepted, as both error and fatal error cause the + assembler to return with a non-zero return code. + + The following syntax errors are changed from fatal to error: + - invalid length field specified + - odd numbered general purpose register specified as register pair + - invalid floating point register pair. Valid fp register pair operands + are 0, 1, 4, 5, 8, 9, 12 or 13. + + gas/ + * config/tc-s390.c: Lower severity of assembler syntax errors + from fatal to error. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Use proper string lengths when parsing opcode table flags + opcodes/ + * s390-mkopc.c: Use proper string lengths when parsing opcode + table flags. + + Fixes: c5306fed7d4 ("s390: Support for jump visualization in disassembly") + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Whitespace fixes in conditional branch flavor descriptions + opcodes/ + * s390-mkopc.c: Whitespace fixes in conditional branch flavor + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jan Beulich + + x86: adjust which Dwarf2 register numbers to use + Consumers can't know which execution mode is in effect for a certain + piece of code; they can only go from object file properties. Hence which + register numbers to encode ought to depend solely on object file type. + + In tc_x86_frame_initial_instructions() do away with parsing a register + name: We have a symbolic constant already for the 64-bit case, and the + 32-bit number isn't going to change either. Said constant's definition + needs moving, though, to be available also for non-ELF. While moving + also adjust the comment to clarify that it's applicable to 64-bit mode + only. + +2024-03-01 Jan Beulich + + gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 + ... plus the SME part of B16B16. As per + + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + SVE2.1 support is both incomplete and buggy. SME2.1 "support" goes as + far as a single instruction (a subset of movaz forms) only. The SME part + of B16B16 is entirely missing. + +2024-03-01 Jan Beulich + + x86/APX: honor -mevexwig= for byte-size insns + These uniformly ignore EVEX.W, and hence what we emit ought to be + controllable by the command line option. + + x86/APX: optimize certain XOR and SUB forms + While most logic in optimize_encoding() is already covering APX by way + of the earlier NDD->REX2 conversion, there's a remaining set of cases + which wants handling separately. + + x86/APX: correct .insn opcode space determination when REX2 is needed + In this case spaces 0f38 and 0f3a may not be put in place. To achieve + the intended effect, operand parsing (but not operand processing) needs + pulling ahead, so we know whether eGRP-s are in use. + +2024-03-01 Jan Beulich + + x86/APX: respect {vex}/{vex3} + Even when an EVEX encoding is available, use of such a prefix ought to + be respected (resulting in an error) rather than ignored. As requested + during review already, introduce a new encoding enumerator to record use + of eGPR-s, and update state transitions accordingly. + + The optimize_encoding() change also addresses an internal assembler + error that was previously raised when respective memory operands used + eGPR-s for addressing. + + While this results in a change of diagnostic issued for VEX-encoded + insns, the new one is at least no worse than the prior one. + +2024-03-01 Tom Tromey + + Use DW_FORM_ref_addr for DIE offset in .debug_names + Today I realized that while the .debug_names writer uses DW_FORM_udata + for the DIE offset, DW_FORM_ref_addr would be more appropriate here. + This patch makes this change. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31361 + +2024-03-01 GDB Administrator + + Automatic date update in version.in + +2024-02-29 Alan Modra + + PR19871, description of --pie + Say why we even mention shared libraries here (ET_DYN), and clarify + symbol resolution. There are of course many other ways that PIEs + resemble PDEs more closely than shared libraries. + + PR 19871 + * ld.texi (-pie): Clarify. + +2024-02-29 Tom Tromey + + Synchronize GCC compile plugin headers + This patch copies some changes to the compile headers from GCC's + include/ directory. It is the gdb equivalent of the GCC commit + bc0e18a9 -- however, while that commit also necessarily touched + libcc1, this one of course does not. + + Tested by rebuilding and also running the gdb.compile tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-02-29 Srinath Parvathaneni + + aarch64: Fix the 2nd operand in gcsstr and gcssttr instructions. + The assembler wrongly expects plain register name instead of + memory-form 2nd operand for gcsstr and gcssttr instructions. + This patch fixes the issue. + +2024-02-29 Tom de Vries + + [gdb/dap] Fix stray KeyboardInterrupt after cancel + When running test-case gdb.dap/pause.exp 100 times in a loop, it passes + 100/100. + + But if we remove the two "sleep 0.2" from the test-case, we run into + (copied from dap.log and edited for readability): + ... + Traceback (most recent call last): + File "startup.py", line 251, in message + def message(): + + KeyboardInterrupt + Quit + ... + + This happens as follows. + + CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight. + + The idea is that this interrupt triggers while in fn here in message (a nested + function of send_gdb_with_response): + ... + def message(): + try: + val = fn() + result_q.put(val) + except (Exception, KeyboardInterrupt) as e: + result_q.put(e) + ... + but instead it triggers outside the try/except. + + Fix this by: + - in CancellationHandler, renaming variable in_flight to in_flight_dap_thread, + and adding a variable in_flight_gdb_thread to be able to distinguish when + a request is in flight in the dap thread or the gdb thread. + - adding a wrapper Cancellable to to deal with cancelling the wrapped + event + - using Cancellable in send_gdb and send_gdb_with_response to wrap the posted + event + - in CancellationHandler.cancel, only call gdb.interrupt if + req == self.in_flight_gdb_thread. + + This makes the test-case pass 100/100, also when adding the extra stressor of + "taskset -c 0", which makes the fail more likely without the patch. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31275 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275 + +2024-02-29 Tom de Vries + + [gdb/dap] Move send_gdb and send_gdb_with_response to server module + Move functions send_gdb and send_gdb_with_response, as well as class Invoker + to server module. + + Separated out to make the following patch easier to read. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-29 Thiago Jung Bauermann + + gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions + Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro + register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which + adds the tpidruro register, and unconditionally enabled it in + aarch32_create_target_description. + + In Linux, the tpidruro register isn't available via ptrace in the 32-bit + kernel but it is available for an aarch32 program running under an arm64 + kernel via the ptrace compat interface. This isn't currently implemented + however, which causes GDB on arm-linux with 64-bit kernel to list the + register but show it as unavailable, as reported by Tom de Vries: + + $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' + Temporary breakpoint 1 at 0x512 + + Temporary breakpoint 1, 0xaaaaa512 in main () + $1 = + + Simon Marchi then clarified: + + > The only time we should be seeing some "unavailable" registers or memory + > is in the context of tracepoints, for things that are not collected. + > Seeing an unavailable register here is a sign that something is not + > right. + + Therefore, disable the TLS feature in aarch32 target descriptions for Linux + and NetBSD targets (the latter also doesn't seem to support accessing + tpidruro either, based on a quick look at arm-netbsd-nat.c). + + This patch fixes the following tests: + + Running gdb.base/inline-frame-cycle-unwind.exp ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 + + Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native, + native-gdbserver and native-extended-gdbserver targets with no regressions. + + PR tdep/31418 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418 + + Approved-By: John Baldwin + +2024-02-29 H.J. Lu + + bfd: Add ATTRIBUTE_HIDDEN to x86 internal functions + * elfxx-x86.h: Add ATTRIBUTE_HIDDEN to internal functions. + * libbfd-in.h (_bfd_get_link_info): Add ATTRIBUTE_HIDDEN. + * libbfd.h: Regenerated. + +2024-02-29 Alan Modra + + PR21739, Inconsistent diagnostics + PR 21739 + cpu/ + * mep.opc (parse_lo16, parse_unsigned7): Mark %function + message as no-c-format. + opcodes/ + * mep-asm.c: Regenerate. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Initial ld.bfd support for TLSDESC. + Only relocation handling for now; relaxation is not implemented yet. + + bfd/ + * elfnn-riscv.c (riscv_elf_check_relocs): Record GOT reference and + paired relocation for TLSDESC_HI20. + (riscv_elf_adjust_dynamic_symbol): Allocate GOT and reloc slots for + TLSDESC symbols. + (riscv_elf_size_dynamic_sections): Likewise but for local symbols. + (tlsdescoff): New helper to determine static addend for R_TLSDESC. + (riscv_elf_relocate_section): Ignore TLSDESC_CALL reloc for now (it is + relaxation only). + Handle TLSDESC_{LOAD,ADD}_LO12 as paired pcrel relocs. + For TLS GOT slot generation, generalize the logic to handle any + combination of (GD, IE, TLSDESC). + Add TLSDESC Rela generation. + * ld/testsuite/ld-riscv-elf/tls*: Add TLSDESC instruction sequences + next to the existing GD and IE sequences. Update expectations. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Define and use GOT entry size constants for TLS. + As the size calculation is split by global and local symbols, using a + shared constant definition for its size improves clarity. + + bfd/ + * elfnn-riscv.c: Add macros for sizes of a normal GOT entry, TLS GD and + TLS IE entry. + (allocate_dynrelocs): Replace GOT size expressions with the new + constants. + (riscv_elf_size_dynamic_sections): Likewise. + (riscv_elf_relocate_section): Likewise. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Add assembly support for TLSDESC. + gas/ + * tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi, + %tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype + renamed to percent_op_relax_only as this matcher is extended to handle + jalr as well which is not R-type. + (riscv_ip): Apply the percent_op_relax_only rename and update comment. + (md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to + TLS relocation check list. + * testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation + generation. + opcodes/ + * riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with + %tlsdesc_call annotations. + + RISC-V: Add TLSDESC reloc definitions. + bfd/ + * elfxx-riscv.c: Add 5 TLSDESC reloc descriptions. + * reloc.c: Likewise. + * libbfd.h: Regenerate. + * bfd-in2.h: Regenerate. + include/ + * elf/riscv.h: Add 5 TLSDESC reloc descriptions. + +2024-02-29 Ruud van der Pas + + gprofng: change use of bignum to use of bigint + Change the statement "use bignum" to "use bigint". This is sufficient + for gp-display-html to work and removes the dependency on bignum. + + gprofng/ChangeLog + 2024-02-27 Ruud van der Pas + + PR 31390 + * gprofng/gp-display-html: One line change to "use bigint". + +2024-02-29 John Baldwin + + aarch64: Use aarch64_debug_printf in a few more places + No functional change + + Approved-By: Simon Marchi + +2024-02-29 GDB Administrator + + Automatic date update in version.in + +2024-02-28 Alan Modra + + PR23877, bad value (n32r5900) for default CPU + Catching this at configure time would be nicer, but we'd need to exactly + match mips_parse_cpu in configure.ac and keep it all in sync. + + PR 23877 + * config/tc-mips.c (mips_after_parse_args): Don't assert that + mips_parse_cpu returns non-NULL, call as_fatal with an informative + message instead. + +2024-02-28 Vladislav Belov + + Fix implementation of SUBALIGN. + +2024-02-28 Tom Tromey + + Fix gdb.interrupt race + gdb.interrupt was introduced to implement DAP request cancellation. + However, because it can be run from another thread, and because I + didn't look deeply enough at the implementation, it turns out to be + racy. + + The fix here is to lock accesses to certain globals in extension.c. + + Note that this won't work in the case where configure detects that the + C++ compiler doesn't provide thread support. This version of the + patch disables DAP entirely in this situation. + + Regression tested on x86-64 Fedora 38. I also ran gdb.dap/pause.exp + in a thread-sanitizer build tree to make sure the reported race is + gone. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31263 + +2024-02-28 Alan Modra + + PR23881, pdp11 binutils fails if too much debug data + The PR testcase overflows one of the exec header fields, e_syms (the + size of the symbol table), leading to the string table offset being + wrong. Things go downhill from there. Fixed by checking for + overflow. This happens to trigger in the ld testsuite, so xfail that + test. + + PR 23881 + bfd/ + * libaout.h (swap_exec_header_out): Return a bool. + * aoutx.h (swap_exec_header_out): Check for overflow in exec + header. + * pdp11.c (swap_exec_header_out): Likewise. + * i386lynx.c (WRITE_HEADERS): Adjust. + ld/ + * testsuite/ld-scripts/map-address.exp: xfail pdp11. + +2024-02-28 GDB Administrator + + Automatic date update in version.in + +2024-02-27 Tom Tromey + + Two minor addrmap cleanups + While working on a different patch, I found a couple of simple addrmap + cleanups. + + In one case, a forward declaration is no longer needed, as the header + now includes addrmap.h. + + In the other, an include of addrmap.h is no longer needed. + + Tested by rebuilding. + +2024-02-27 Tom Tromey + + Explicitly quit gdb from DAP server thread + This changes the DAP code to explicitly request that gdb exit. + Previously this could cause crashes, but with the previous cleanups, + this should no longer happen. + + This also adds a tests that ensures that gdb exits with status 0. + +2024-02-27 Tom Tromey + + Add final cleanup for runnables + This changes run-on-main-thread.c to clear 'runnables' in a final + cleanup. This avoids an issue where a pending runnable could require + Python, but be run after the Python interpreter was finalized. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31172 + +2024-02-27 Tom Tromey + + Change finalize_values into a final cleanup + This removes finalize_values in favor of adding a new final cleanup. + This is safe now that extension languages are explicitly shut down. + + Add extension_language_ops::shutdown + Right now, Python is shut down via a final cleanup. However, it seems + to me that it is better for extension languages to be shut down + explicitly, after all the ordinary final cleanups are run. The main + reason for this is that a subsequent patch adds another case like + finalize_values; and rather than add a series of workarounds for + Python shutdown, it seemed better to let these be done via final + cleanups, and then have Python shutdown itself be the special case. + + Rewrite final cleanups + This patch rewrites final cleanups to use std::function and otherwise + be more C++-ish. + +2024-02-27 Tom Tromey + + Use the .py file in gdb.dap/pause.exp + Tom de Vries pointed out that the gdb.dap/pause.exp test writes a + Python file but then does not use it. This patch corrects the + oversight. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Rewrite "python" command exception handling + The "python" command (and the Python implementation of the gdb + "source" command) does not handle Python exceptions in the same way as + other gdb-facing Python code. In particular, exceptions are turned + into a generic error rather than being routed through + gdbpy_handle_exception, which takes care of converting to 'quit' as + appropriate. + + I think this was done this way because PyRun_SimpleFile and friends do + not propagate the Python exception -- they simply indicate that one + occurred. + + This patch reimplements these functions to respect the general gdb + convention here. As a bonus, some Windows-specific code can be + removed, as can the _execute_file function. + + The bulk of this change is tweaking the test suite to match the new + way that exceptions are displayed. These changes are largely + uninteresting. However, it's worth pointing out the py-error.exp + change. Here, the failure changes because the test changes the host + charset to something that isn't supported by Python. This then + results in a weird error in the new setup. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Acked-By: Tom de Vries + Reviewed-By: Eli Zaretskii + +2024-02-27 Tom Tromey + + Fix formatting buglet in python.c + python.c has a split string that is missing a space. There's also a + stray backslash in this code. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Introduce read_remainder_of_file + This patch adds a new function, read_remainder_of_file. This is like + read_text_file_to_string, but reads from an existing 'FILE *'. This + will be used in a subsequent patch. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom de Vries + + [gdb/testsuite] Reset errcnt and warncnt in default_gdb_init + Say we do: + ... + $ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp" + ... + and add a perror at the end of pause.exp: + ... + dap_shutdown + + + +perror "foo" + ... + + We run into: + ... + UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb + ... + + This happens because the perror increases the errcnt, which is not reset at + the end of the test-case, and consequently the first pass in the following + test-case is changed into an unresolved. + + Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the + end of the test-case, which does reset the errcnt, but this is with version + 1.6.1. + + Furthermore, we reset the errcnt in clean_restart, but the pass is produced + before, so that doesn't help either. + + Fix this by resetting errcnt and warncnt in default_gdb_init. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31351 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Remove KFAIL for PR ada/30908 + PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by + commit d56fdf1b976 ("Refine Ada overload matching"). + + Remove the KFAILs for PR ada/30908. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp + With test-case gdb.python/py-finish-breakpoint.exp, we run into: + ... + (gdb) python print (finishbp_default.hit_count) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Breakpoint 3 is invalid. + Error while executing Python code. + (gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \ + check finishBP on default frame has been hit + ... + + The test producing the pass is: + ... + gdb_test "python print (finishbp_default.hit_count)" "1.*" \ + "check finishBP on default frame has been hit" + ... + so the pass is produced because the 1 in "line 1" matches "1.*". + + Temporary breakpoints are removed when hit, and consequently accessing the + hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is + not possible, and as per spec we get a RuntimeError. + + So the RuntimeError is correct, and not specific to finish breakpoints. + + The test presumably attempts to match: + ... + (gdb) python print (finishbp_default.hit_count) + 1 + ... + but most likely this output was never produced by any gdb version. + + Fix this by checking whether the finishbp_default breakpoint has hit by + checking that finishbp_default.is_valid() is False. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31391 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391 + +2024-02-27 Pedro Alves + + Cygwin: Fix putting inferior in foreground (fix input) + gdb.base/interrupt.exp reveals that inferior input is + broken on Cygwin: + + (gdb) continue + Continuing. + talk to me baby + Input/output error <<< BAD + PASS: gdb.base/interrupt.exp: process is alive + a + [Thread 10688.0x2590 exited with code 1] + [Thread 10688.0x248c exited with code 1] + [Thread 10688.0x930 exited with code 1] + [Thread 10688.0x2c98 exited with code 1] + + Program terminated with signal SIGHUP, Hangup. + The program no longer exists. + (gdb) FAIL: gdb.base/interrupt.exp: child process ate our char + a + Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior... + (gdb) ERROR: "" is not a unique command name. + + The problem is that inflow.c:child_terminal_inferior is failing to put + the inferior in the foreground, because we're passing down the + inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp. + + That is fixed by this commit. Afterwards we will get: + + (gdb) continue + Continuing. + talk to me baby + PASS: gdb.base/interrupt.exp: process is alive + a + a <<< GOOD + PASS: gdb.base/interrupt.exp: child process ate our char + [New Thread 7236.0x1c58] + + Thread 6 received signal SIGINT, Interrupt. <<< new thread spawned for SIGINT + [Switching to Thread 7236.0x1c58] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C + + We still have the FAIL seen above because this change has another + consequence. By failing to put the inferior in the foreground + correctly, Ctrl-C was always reaching GDB first. Now that the + inferior is put in the foreground properly, Ctrl-C reaches the + inferior first, which results in a Windows Ctrl-C event, which results + in Windows injecting a new thread in the inferior to report the Ctrl-C + exception => SIGINT. That is, running the test manually: + + Before patch: + + (gdb) c + Continuing. + [New Thread 2352.0x1f5c] + [New Thread 2352.0x1988] + [New Thread 2352.0x18cc] + <<< Ctrl-C pressed. + Thread 7 received signal SIGTRAP, Trace/breakpoint trap. + [Switching to Thread 2352.0x18cc] + 0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll + (gdb) + + Above, GDB got the SIGINT, and it manually passes it down the + inferior, which reaches windows_nat_target::interrupt(), which + interrupts the inferior with DebugBreakProcess (which injects a new + thread in the inferior that executes an int3 instruction). + + After this patch, we have (with "set debugexceptions on" so + DBG_CONTROL_C is visible): + + (gdb) c + Continuing. + [New Thread 9940.0x1168] + [New Thread 9940.0x5f8] + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + [New Thread 9940.0x3d8] + gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b <<< Ctrl-C + + Thread 7 received signal SIGINT, Interrupt. <<< new injected thread + [Switching to Thread 9940.0x3d8] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) + + This new behavior is exactly the same as what you see with a MinGW GDB + build. Also, SIGINT reaching inferior first is what you get on Linux + as well currently. + + I wrote an initial fix for this before I discovered that Cygwin + downstream had a similar change, so I then combined the patches. I am + adding a Co-Authored-By for that reason. + + Co-Authored-By: Takashi Yano + Approved-By: Tom Tromey + Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f + +2024-02-27 Andreas Krebbel + + s390: Add r_offset check to the weak undef change + Since we are accessing up to 2 bytes before the relocation target we + should better make sure there are actually 2 bytes before it. + + ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Make sure + rel->r_offset is large enough. + +2024-02-27 Yuriy Kolerov + + arc: Don't build arc-analyze-prologue.S with -g + arc-analyze-prologue.S test does not contain debug information thus + it must be compiled without -g option. Otherwise GDB will try to + unwind frames using debug information (which does not exist for .S + code!) instead of analyzing frames manually. + + Approved-By: Shahab Vahedi + +2024-02-27 Andreas Krebbel + + s390: Avoid reloc overflows on undefined weak symbols + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0, a + NOP, or a trapping insn. + + This prevents the PC32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative addressing + to avoid relocation overflows. + + ld/ChangeLog: + * ld/testsuite/ld-s390/s390.exp: + * ld/testsuite/ld-s390/8GB.ld: New test. + * ld/testsuite/ld-s390/weakundef-1.dd: New test. + * ld/testsuite/ld-s390/weakundef-1.s: New test. + +2024-02-27 Matthieu Longo + + aarch64: rename internals related to PAuth feature to use pauth in their naming for coherency + Hi, + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion. + + Regression tested on aarch64-none-elf, and no regression found. + + Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf. + + Regards, + Matthieu. + From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001 + From: Matthieu Longo + Date: Fri, 23 Feb 2024 11:30:40 +0000 + Subject: [PATCH] aarch64: rename internals related to PAuth feature to use + pauth in their naming for coherency + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature + with internal names that don't match the actual feature name pauth. The new + feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature + of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" + would create confusion. + +2024-02-27 mengqinggang + + LoongArch: Run overflow testcases only on LoongArch target + +2024-02-27 ticat_fp + + LoongArch: Modify inconsistent behavior of ld with --unresolved-symbols=ignore-all + Remove duplicated check when producing executable files that reference external symbols + defined in other files. RELOC_FOR_GLOBAL_SYMBOL will check it. + + Testcase is: + resolv.c: + int main(int argc, char *argv[]) { + return argc; + } + + t.c: + + extern const struct my_struct ms1; + static const struct my_struct *ms = &ms1; + + t.h: + typedef struct my_struct { + char *str; + int i; + } my_struct; + + Compiling and linking command with: + gcc t.c -c ; gcc resolv.c -c + gcc resolv.o t.o -o resolv -Wl,--unresolved-symbols=ignore-all + + Got error as: + ~/install/usr/bin/ld: t.o:(.data.rel+0x0): undefined reference to `ms1' + collect2: error: ld returned 1 exit status + +2024-02-27 Jinyang He + + Avoid unused space in .rela.dyn if sec was discarded + The relsec size is still increased although sec is discarded, which + cause a lot of unused space allocated. Avoid size increased if sec + was discarded. + + bfd/ChangeLog: + + * bfd/elfnn-loongarch.c: (allocate_dynrelocs): Do not increase + sreloc size when discarded_section. + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test. + * ld/testsuite/ld-loongarch-elf/pie_discard.d: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.s: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.t: New test. + +2024-02-27 Jinyang He + + LoongArch: ld: Fix other pop relocs overflow check and add tests + Add reloc_unsign_bits() to fix others sop_pop relocs overflow check. + Then add over/underflow tests for relocs B*, SOP_POP* and PCREL20_S2. + + bfd/ChangeLog: + + * bfd/elfxx-loongarch.c: Add reloc_unsign_bits(). + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add tests. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.dd: New test. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi1_sops.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_overflows.s: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_5_20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_5_20.d: New test. + +2024-02-27 mengqinggang + + LoongArch: bfd: Fix some bugs of howto table + R_LARCH_IRELATIVE: For dynamic relocation that does not distinguish between + 32/64 bits, size and bitsize set to 8 and 64. + R_LARCH_TLS_DESC64: Change size to 8. + R_LARCH_SOP_POP_32_S_0_5_10_16_S2: Change src_mask to 0, dst_mask to + 0x03fffc1f. + +2024-02-27 GDB Administrator + + Automatic date update in version.in + +2024-02-26 Simon Marchi + + gdb/amd-dbgapi: fix indentation + Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0 + +2024-02-26 Tom Tromey + + Remove two unnecessary casts + I noticed a spot in ada-lang.c where the return value of + value_as_address was cast to CORE_ADDR -- a no-op cast. I searched + and found another. This patch fixes both. + +2024-02-26 Pedro Alves + + [gdb] Fix heap-use-after-free in select_event_lwp + PR gdb/31259 reveals one scenario where we run into a + heap-use-after-free reported by thread sanitizer, while running + gdb.base/vfork-follow-parent.exp. + + The heap-use-after-free happens during the following scenario: + + - linux_nat_wait_1 is about to return an event for T2. It stops all + other threads, and while doing so, stop_wait_callback -> wait_lwp + sees T1 exit, and decides to leave the exit event pending. It + should have set the lp->stopped flag too, but does not -- this is + the bug. + + - The event for T2 is reported, is processed by infrun, and we're + back at linux_nat_wait_1. + + - linux_nat_wait_1 selects LWP T1 with the pending exit status to + report. + + - it sets variable lp to point to the corresponding lwp_info. + + - it calls stop_callback and stop_wait_callback for all threads + (because !target_is_non_stop_p ()). + + - it calls select_event_lwp to maybe pick another thread than T1, to + prevent starvation. + + The problem is the following: + + - while calling stop_wait_callback for all threads, it also does this + for T1. While doing so, the corresponding lwp_info is deleted + (callstack stop_wait_callback -> wait_lwp -> exit_lwp -> + delete_lwp), leaving variable lp as a dangling pointer. + + - variable lp is passed to select_event_lwp, which derefences it, + which causes the heap-use-after-free. + + Note that the comment here mentions "all other LWP's": + ... + /* Now stop all other LWP's ... */ + iterate_over_lwps (minus_one_ptid, stop_callback); + /* ... and wait until all of them have reported back that + they're no longer running. */ + iterate_over_lwps (minus_one_ptid, stop_wait_callback); + ... + + The reason the comments say "all other LWP's", and doesn't bother + filtering out LP is that lp->stopped should be true at this point, and + the callbacks (both stop_callback and stop_wait_callback) check that + flag, and do nothing if set. I.e., they skip already-stopped threads, + so they should skip LP. + + In this particular scenario, though, we missed setting the stopped + flag right in the first step described above, so LP was iterated over + incorrectly. + + The fix is to make wait_lwp set the lp->stopped flag when it decides + to leave the exit event pending. However, going a bit further, + gdbserver has a mark_lwp_dead function to centralize setting up + various lwp flags such that the rest of the code doesn't mishandle + them, and it seems like a good idea to do a similar thing in gdb as + well. That is what this patch does. + + PR gdb/31259 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31259 + Co-Authored-By: Tom de Vries + Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9 + +2024-02-26 Tom de Vries + + [gdb/testsuite] Dump dap.log.$n to gdb.log when exceptions found + For a patch I submitted, the Linaro CI reported a failure: + ... + FAIL: gdb.dap/attach.exp: exceptions in log file + ... + + I ran the test-case locally, and observed the same FAIL in the gdb.sum file. + + I then wanted to confirm that I reproduced the exact same problem, but + realized that I couldn't because there's no way for me to know what exception + occurred, and where, because that information is logged in the dap.log.$n + file, and the Linaro CI only saves the gdb.sum and gdb.log files. + + This issue is even worse if only the CI can reproduce a FAIL. + + Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when + exceptions are found. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-26 Tom de Vries + + [gdb/testsuite] Further handle long filenames in gdb.base/startup-with-shell.exp + In commit 52498004a34 ("gdb/testsuite: handle long filenames in + gdb.base/startup-with-shell.exp") we fixed a FAIL reported by the Linaro CI: + ... + (gdb) print argv[1] + $1 = 0xfffed978 "/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; \ + run_args = *.unique-extension: first argument expanded + ... + + PR testsuite/31410 reports a similar failure: + ... + (gdb) print argv[1] + $1 = 0xfffeda96 "/startup-with-shell/*.unique-extens"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = off; \ + run_args = *.unique-extension: first argument not expanded + ... + + Fix this in the same way, using "set print characters unlimited". + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410 + +2024-02-26 Tom de Vries + + [gdb] Fix "value is not available" with debug frame + On arm-linux, with a started hello world, running "info frame" works fine, but + when I set debug frame to on, I run into: + ... + (gdb) info frame + ... + [frame] frame_unwind_register_value: exit + value is not available + (gdb) + ... + + The problem is here in frame_unwind_register_value: + ... + if (value->lazy ()) + gdb_printf (&debug_file, " lazy"); + else + { + int i; + gdb::array_view buf = value->contents (); + ... + where we call value->contents () while !value->entirely_available (). + + Fix this by checking value->entirely_available () and printing: + ... + [frame] frame_unwind_register_value: -> register=91 unavailable + ... + + Tested on arm-linux. + + PR gdb/31369 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31369 + +2024-02-26 Tiezhu Yang + + gdb: Modify the output of "info breakpoints" and "delete breakpoints" + The output of "info breakpoints" includes breakpoint, watchpoint, + tracepoint, and catchpoint if they are created, so it should show + all the four types are deleted in the output of "info breakpoints" + to report empty list after "delete breakpoints". + + It should also change the output of "delete breakpoints" to make it + clear that watchpoints, tracepoints, and catchpoints are also being + deleted. This is suggested by Guinevere Larsen, thank you. + + $ make check-gdb TESTS="gdb.base/access-mem-running.exp" + $ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running + [...] + (gdb) break main + Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32. + (gdb) watch global_counter + Hardware watchpoint 2: global_counter + (gdb) trace maybe_stop_here + Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27. + (gdb) catch fork + Catchpoint 4 (fork) + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32 + 2 hw watchpoint keep y global_counter + 3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27 + not installed on target + 4 catchpoint keep y fork + + Without this patch: + + (gdb) delete breakpoints + Delete all breakpoints? (y or n) y + (gdb) info breakpoints + No breakpoints or watchpoints. + (gdb) info breakpoints 3 + No breakpoint or watchpoint matching '3'. + + With this patch: + + (gdb) delete breakpoints + Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y + (gdb) info breakpoints + No breakpoints, watchpoints, tracepoints, or catchpoints. + (gdb) info breakpoints 3 + No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'. + + Approved-by: Kevin Buettner + Reviewed-By: Eli Zaretskii + +2024-02-26 Andreas Arnez + + gdb: s390: Add arch14 record/replay support + Enable recording of the new "arch14" instructions on z/Architecture + targets, except for the specialized-function-assist instruction NNPA. + +2024-02-26 Vladimir Mezentsev + + gprofng: Add hardware counter profiling for the Ampere system + gprofng should recognize Ampere and other ARM systems. + + gprofng/ChangeLog + 2024-02-22 Vladimir Mezentsev + + * common/hwc_cpus.h: Declare the enum values ARM_CPU_IMP_*. + * common/core_pcbe.c (core_pcbe_init): Accept new systems ARM_CPU_IMP_*. + +2024-02-26 Jinyang He + + LoongArch: bfd: Correct the name of R_LARCH_SOP_POP_32_U in howto_table + +2024-02-26 GDB Administrator + + Automatic date update in version.in + +2024-02-25 GDB Administrator + + Automatic date update in version.in + +2024-02-24 Tom de Vries + + [gdb/build] Fix static cast of virtual base + With this change in bfd/development.sh: + ... + -development=true + +development=false + ... + we run into: + ... + In file included from tui-data.h:28:0, + from tui-command.c:24: + gdb-checked-static-cast.h: In instantiation of \ + ‘T gdb::checked_static_cast(V*) [with T = tui_cmd_window*; V = tui_win_info]’: + tui-command.c:65:15: required from here + gdb-checked-static-cast.h:63:14: error: cannot convert from pointer to base \ + class ‘tui_win_info’ to pointer to derived class ‘tui_cmd_window’ because \ + the base is virtual + T result = static_cast (v); + ^~~~~~~~~~~~~~~~~~ + ... + + Fix this by using dynamic_cast instead of gdb::checked_static_cast in + TUI_CMD_WIN and TUI_STATUS_WIN. + + Tested on x86_64-linux, with development set to false. + + Reported-By: Robert Xiao + Reported-By: Simon Marchi + Approved-By: Tom Tromey + + PR build/31399 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + +2024-02-24 Alan Modra + + PR25333, GAS is slow processing -fdebug-types-sections + gas needs to build lists of sections for each group. This arranges to + build the lists earlier, so they can be used when looking for sections + that belong to a group. Using the section hash table to find sections + by name, then by group isn't efficient when there are numerous groups + with the same section names. Using a hash table to quickly find a + group, then searching by section name on a list for the group results + in a 100-fold speed improvement assembling the testcase in this PR. + + To reduce the number of times we traverse the section list, the patch + also moves some processing done in elf_adjust_symtab for linked-to + section, to elf_frob_file. This requires a testsuite change because + processing will stop before elf_frob_file if there is a parse error in + section21.s, ie. you'll only get the "junk at end of line" error, not + the "undefined linked-to symbol" errors. + + PR 25333 + * config/obj-elf.c (struct group_list, groups): Move earlier. + (match_section): New function, extracted from.. + (get_section_by_match): ..here. + (free_section_idx): Move earlier. + (group_section_find, group_section_insert): New functions. + (change_section): Use the above. + (elf_set_group_name): New function. + (obj_elf_attach_to_group): Use elf_set_group_name. + (set_additional_section_info): Handle linked_to_symbol_name and + stabs code, extracted from.. + (adjust_stab_sections): ..here,.. + (build_additional_section_info): ..and here. + (elf_adjust_symtab): Don't call build_additional_section_info. + (elf_frob_file): Adjust. + * config/obj-elf.h (elf_set_group_name): Declare. + * config/tc-xtensa.c (cache_literal_section): Use elf_set_group_name. + (xtensa_make_property_section): Likewise. + * testsuite/gas/elf/attach-1.d: Stricter group section matching, + and changed group section ordering. + * testsuite/gas/elf/attach-2.d: Stricter group section matching. + * testsuite/gas/elf/attach-2.s: Provide section bar type. + * testsuite/gas/elf/elf.exp: Run attach-2. + * testsuite/gas/elf/section21.l: Update. + * testsuite/gas/elf/section21.s: Don't check for a parse error. + +2024-02-24 Alan Modra + + xtensa: move xtensa_make_property_section from bfd to gas + This function is only used by gas, so move it there. Necessary for + gas to keep track of group sections as they are created. + + PR 25333 + bfd/ + * elf32-xtensa.c (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Make public. + include/ + * elf/xtensa.h (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Declare + gas/ + * config/tc-xtensa.c (xtensa_make_property_section): New, + moved from elf32-xtensa.c. + +2024-02-24 Alan Modra + + Make is_relocatable_executable only affect dynamic section syms + I believe the only elflink.c specialties for is_relocatable_executable + needed by tic6x are those directly related to dynamic section symbols. + I might be wrong, the code in record_dynamic_symbol and + record_link_assignment predated the tic6x port, but I think these were + symbian specific hacks. + + The shlib-app-1* testsuite changes aren't needed for this patch. I + started making them when trying to remove is_relocatable_executable + completely, but figure it is worth keeping the more permissive address + matching for some future generic linker change. The static-app-1* + changes also adjust to the fact that an unneeded "c" no longer appears + in the dynamic symbol table. + + bfd/ + * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't do anything + special for is_relocatable_executable. + (bfd_elf_record_link_assignment): Likewise. + ld/ + * testsuite/ld-tic6x/shlib-app-1.rd: Make some address matching + more permissive. + * testsuite/ld-tic6x/shlib-app-1b.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1r.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise. + * testsuite/ld-tic6x/static-app-1.rd: Likewise, and adjust expected + dynamic symbol table. + * testsuite/ld-tic6x/static-app-1b.rd: Likewise. + * testsuite/ld-tic6x/static-app-1r.rd: Likewise. + * testsuite/ld-tic6x/static-app-1rb.rd: Likewise. + +2024-02-24 Alan Modra + + sim: no rule to make sim/ppc/Makefile.in + Seen with --enable-maintainer-mode. + make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed + by 'ppc/stamp-pk'. Stop. + + * sim/ppc/local.mk (stamp-pk): Depend on local.mk not + Makefile.in. + * Makefile.in: Regenerate. + + Approved-By: Tom Tromey + +2024-02-24 GDB Administrator + + Automatic date update in version.in + +2024-02-23 Simon Marchi + + gdb: disable formatting-related flake8 warnings + Tom Tromey pointed out that flake8 gives some warnings related to + formatting, such as: + + python/lib/gdb/prompt.py:149:43: E203 whitespace before ':' + + We don't care about those, since all our formatting is handled + automatically by black, so ignore these warnings. + + The list of warnings I put comes from: + + https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8 + + Note that since the setup.cfg file is under the gdb directory, it will + be picked up if you run flake8 from the gdb directory like this: + + binutils-gdb/gdb $ flake8 python + + but not if you do: + + binutils-gdb $ flake8 gdb/python + + Change-Id: I1e42aefd388b9c3b6c9d52b4f635ac881db4bbc1 + Approved-By: Tom Tromey + +2024-02-23 Tom Tromey + + Remove unused import + flake8 points out that dap/io.py does not use send_gdb. This patch + removes the unused import. + +2024-02-23 Pedro Alves + + Fix throw_winerror_with_name build error on x86-64 Cygwin + The GDB build currently fails on x86-64 Cygwin, with: + + src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’: + src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=] + 152 | error (_("%s (error %d): %s"), string, err, strwinerror (err)); + | ^ + + Fix this by adding a cast. While at it, the error codes are really a + DWORD that results from a GetLastError() call, so I think unsigned is + more appropriate. That is also what strwinerror already does: + + sprintf (buf, "unknown win32 error (%u)", (unsigned) error); + + The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned + long long, but for some reason, I don't get a warning there. + + Approved-By: Tom Tromey + Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17 + +2024-02-23 Pedro Alves + + gdb/linux-nat.c: Add "Accessing inferior memory" section + This commit adds a new "Accessing inferior memory" comment section to + gdb/linux-nat.c that explains why we prefer /proc/pid/mem over + alternatives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30453 + + Change-Id: I575b21ed697a85f3ff4c0ec58c04812db5005b76 + +2024-02-23 Jon Turney + + Drop special way of getting inferior context after a Cygwin signal + Simplify Cygwin signal handling by dropping the special way of getting + inferior context after a Cygwin signal. + + I think the reason this existed was because previously we were not + able to unwind through the alternate stack used by _sigfe frames, so + without the hint of the "user" code IP, the backtrace from a signal + was unusable. + + Now we can unwind through _sigfe frames, drop all this complexity. + + (Restoring this specially obtained context to the inferior (as the + code currently does) skips over the actual signal delivery and + handling. Cygwin has carried for a long time a patch which clears the + ContextFlags in the signal context, so we never attempt to restore it + to the inferior, but that interfers with gdb's ability to modify that + context e.g. if it decides it wants to turn on FLAG_TRACE_BIT.) + + Change-Id: I214edd5a99fd17c1a31ad18138d4a6cc420225e3 + +2024-02-23 Jon Turney + + Teach gdb how to unwind cygwin _sigbe and sigdelayed frames + The majority of functions in the cygwin DLL are wrapped by routines + which use an an alternate stack to return via a signal handler if a + signal occured while inside the function. (See [1],[2]) + + At present, these frames cannot be correctly unwound by gdb. There + doesn't seem to currently be a way to correctly describe these frames + using DWARF CFI. + + So instead, write a custom unwinder for _sigbe and sigdelayed frames, + which gets the return address from the alternate stack. + + The offset of tls::stackptr from TIB.stacktop is determined by analyzing + the code in _sigbe or sigdelayed. + + This can backtrace from _sigbe and from a sighandler through sigdelayed. + + Implemented for amd64 and i386 + + Issues: + + 1. We should detect if we are in the wrapper after the return address + has been popped off the alternate stack, and if so, fetch the return + address from the register it's been popped into. + + 2. If there are multiple _sigbe or sigdelayed stack frames to be + unwound, this only unwinds the first one correctly, because we don't + unwind the value of the alternate stack pointer itself. + + This is no worse than currently, when we can't even unwind one of + these frame correctly, but isn't quite correct. + + I guess this could be handled by defining a pseudo-register to track + its value as we unwind the stack. + + [1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/gendef + [2] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/how-signals-work.txt + + Co-Authored-By: Pedro Alves + Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc + +2024-02-23 Jan Beulich + + x86: rename vec_encoding and vex_encoding_* + Even with just VEX these weren't limited to vector insns. With APX the + set of non-vector ones covered has greatly increased. Drop the vec_ + prefix. Also drop the vex_ ones off of the enumerators, as they weren't + appropriate anyway: Should have been vec_ then, too. + + x86: document -moperand-check= + PR gas/31388 + Like other command line options this should be mentioned in + documentation as well, not just in "as --help" output. + +2024-02-23 Jan Beulich + + x86: also permit YMM/ZMM use in CFI directives + Next to code using %ymm or %zmm it is more natural to have .cfi_* + directives also reference those, not the corresponding %xmm. Accept + their names as kind of aliases, i.e. resolving to the same numbers. + + While extending the respective 64-bit testcase, also add %bnd there + (should have happened right with 633789901c83 ["x86-64: Dwarf2 register + numbers for %bnd"], sorry), requiring binutils/dwarf.c to be adjusted + accordingly as well. + +2024-02-23 Jan Beulich + + x86/APX: INV{EPT,PCID,VPID} are WIG + While various other entries in version 003 of the spec aren't quite as + explicit (due to simply leaving the respective field blank), all three + have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0 + by default (and respect -mevexwig=). + +2024-02-23 mengqinggang + + LoongArch: gas: Try to avoid R_LARCH_ALIGN associate with a symbol + The R_LARCH_ALIGN need to associated with a symbol if .align has the first + and third expressions. If R_LARCH_ALIGN associate with a symbol, the addend can + represent the first and third expression of .align. + + For '.align 3', the addend of R_LARCH_ALIGN only need to represent the alignment + and R_LARCH_ALIGN not need to associate with a symbol. + + For '.align x, , y', R_LARCH_ALIGN need to associate with a symbol if 0 < y < + 2^x - 4. + +2024-02-23 H.J. Lu + + gdb: Add XMM16-XMM31 and K0-K1 DWARF register number mapping + Add XMM16-XMM31 and K0-K1 DWARF register number mapping to + amd64_dwarf_regmap. + + Reviewed-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-02-23 GDB Administrator + + Automatic date update in version.in + +2024-02-22 Tom Tromey + + Use bool in dynamic type code + This changes some of the dynamic-type-related code to use bool rather + than int. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-02-22 Tom de Vries + + [gdb/testsuite] Fix license text in gdb.reverse/map-to-same-line.{c,exp} + I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are + using some kind of indirection via urldefense.proofpoint.com. + + Fix this by removing this indirection. + + Tested on x86_64-linux. + + PR testsuite/31358 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap exit and gdb exit + When DAP shuts down due to an EOF event, there's a race between: + - gdb's main thread handling a SIGHUP, and + - the DAP main thread exiting. + + Fix this by waiting for DAP's main thread exit during the gdb_exiting event. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap startup and dap log file + In dap_gdb_start we do: + ... + append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap" + ... + + While the dap log file setting comes before the dap interpreter setting, + the order is the other way around: + - first, the dap interpreter is started + - second, the -iex commands are executed and the log file is initialized. + + Consequently, there's a race between dap interpreter startup and dap log file + initialization. + + This cannot be fixed by using -eiex instead. Before the interpreter is + started, the "set debug dap-log-file" command is not yet registered. + + Fix this by postponing the start of the DAP server until GDB has processed all + command files. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31386 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386 + +2024-02-22 Tom de Vries + + [gdb/dap] Factor out thread_log + In thread_wrapper I used a style where a message is prefixed with the thread + name. + + Factor this out into a new function thread_log. + + Also treat the GDB main thread special, because it's usual name is MainThread: + ... + MainThread: + ... + which is the default name assigned by python, so instead use the more + explicit: + ... + GDB main: + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-22 GDB Administrator + + Automatic date update in version.in + +2024-02-21 Tom Tromey + + Don't allow multiple request registrations in DAP + This changes the DAP code to check that a given request or capability + is only registered a single time. This is just a precaution against + accidentally introducing a second definition of a request somewhere. + +2024-02-21 Alan Modra + + Leak in i386_elf_section_change_hook + notes_alloc is perfect for assorted memory you can't free easily + and/or would rather leave freeing until just before exit. + + * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc. + +2024-02-21 Simon Marchi + + gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable} + This code was there to support g++ 4, which didn't support + std::is_trivially_constructible and std::is_trivially_copyable. Since + we now require g++ >= 9, I think it's fair to assume that GDB will + always be compiled with a compiler that supports those. + + Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1 + +2024-02-21 Simon Marchi + + gdb: remove some GCC version checks + Since we now require C++17, and therefore gcc >= 9, it's no longer + useful to have gcc version checks for older gcc version. + + Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 + Reviewed-by: Kevin Buettner + Approved-By: Pedro Alves + +2024-02-21 Tom de Vries + + [gdb/testsuite] Fix error handling in _dap_read_json + In _dap_read_json we have a gdb_expect with clauses that generate errors: + ... + timeout { + error "timeout reading json header" + } + eof { + error "eof reading json header" + } + ... + + Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar + semantics related to errors: + ... + # remote_expect works basically the same as standard expect, but it + # also takes care of getting the file descriptor from the specified + # host and also calling the timeout/eof/default section if there is an + # error on the expect call. + ..... + + When a timeout triggers, it generates a timeout error, which is reported by + gdb_expect, after which it runs the timeout/eof/default clauses, which + generates an eof error, which is reported by runtest. + + I think the intention here is to generate just a one error, a timeout error. + + Fix this by postponing generating the error until after gdb_expect. + + Tested on x86_64-linux, by: + - running all the DAP test-cases and observing no regressions, and + - modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and + observing only a timeout error. + + PR testsuite/31382 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382 + +2024-02-21 Yuriy Kolerov + + arc: Determine a branch target of DBNZ correctly + DBNZ instruction was moved from BRANCH class to a separate one - DBNZ. + Thus, it must be processed separately in arc_insn_get_branch_target + to correctly determine an offset for a possible branch. + + The testsuite for DBNZ instruction verifies these cases: + + 1. Check that dbnz does not branch and falls through if its source + register is 0 after decrementing. GDB must successfully break + on the following instruction after stepping over. + 2. Check that dbnz branches to the target correctly if its source register + is not 0 after decrementing - GDB must successfully break on the target + instruction if a forward branch is performed after stepping over. + 3. The same as point 2 but for a backward branching case. + +2024-02-21 Alan Modra + + Re: PR29785, memory bloat after b43771b045fb + Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift + exponent 64 is too large". This is on the bucket_high_pc calculation + which was moved to the top of insert_arange_in_trie where previously + it was later, at a point where the overflow could not occur. Move it + back and arrange for a duplicate calculation of bucket_high_pc which + is also protected from overflow. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Split bucket_high_pc. + Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help. + +2024-02-21 Alan Modra + + Remove is_relocatable_executable from backend code + With the removal of symbian support, most targets no longer or never + did set is_relocatable_executable. Remove the backend support that is + no longer relevant. + + * elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub), + (elf32_arm_final_link_relocate, elf32_arm_check_relocs), + (elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol), + (elf32_arm_output_arch_local_syms): Remove is_relocatable_executable + code and comments. + * elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise. + * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise. + * elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise. + * elfxx-mips.c (count_section_dynsyms): Likewise. + +2024-02-21 Matthieu Longo + + aarch64: testsuite: move sysreg tests into sysreg sub-directory + This patch moves the existing sysreg tests for AArch64 into a subdirectory + (sysreg). The number of test files related to system registers grew + relatively big with time and makes the browsing of those files difficult. + Moreover, the difference of naming for the failure, working, and + feature-specific scenarios causes the tests not to appear next to one + another in the exploration tree when it is ordered alphabetically. + +2024-02-21 Tom de Vries + + [gdb/dap] Join JSON writer thread with DAP thread + The DAP interpreter runs in its own thread, and starts a few threads: + - the JSON reader thread, + - the JSON writer thread, and + - the inferior output reader thread. + + As part of the DAP shutdown, both the JSON reader thread and the JSON writer + thread, as well as the DAP main thread run to exit, but these exits are not + ordered in any way. + + Wait in the main DAP thread for the exit of the JSON writer thread. + + This makes sure that the responses are flushed to the DAP client before DAP + shutdown. + + An earlier version of this patch used Queue.task_done() to accomplish the + same, but that didn't guarantee writing the ": terminating" + log entry from thread_wrapper before DAP shutdown. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-21 Tom de Vries + + [gdb/dap] Make dap log printing thread-safe + I read that printing from different python threads is thread-unsafe, and I + noticed that the dap log printing is used from different threads, but doesn't + take care to make the printing thread-safe. + + Fix this by using a lock to access LoggingParam.log_file. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/dap] Flush after printing in log_stack + I noticed that function log flushes the dap log file after printing, but + that function log_stack doesn't. + + Fix this by also flushing the dap log file in log_stack. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp + While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP + patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap + log file. + + This is normally set up by dap_gdb_start, but the test-case doesn't use it. + + Fix this by doing "set debug dap-log-file $logfile" in the test-case. + + To make it easy to do so, I've factored out a new proc new_dap_log_file, and + while at likewise a new proc current_dap_log_file. + + Note that the log file is currently empty. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Felix Willgerodt + + gdb: Document C++17 build requirement. + We require C++17 to build for a while now: + https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1 + + Reviewed-By: Lancelot Six + +2024-02-21 Tatsuyuki Ishi + + RISC-V: Fix local GOT and reloc size calculation for TLS. + The previous code did not account correctly for two cases: + * A TLS symbol can be referenced with multiple TLS types (although rare), + in which case it only allocated the maximum slot size among the types, + instead of the sum. + * TLS relocations are only needed for DLLs, unlike normal symbols which + requires relocations for all PIE code. + + Modify the logic to account for the two cases, so this fixes the redundant + dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + bfd/ + * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation + sizing for TLS and non-TLS symbols differently, with the former + requiring relocs on DLL while the latter requiring on PIE. + Allocate GOT slots and relocation slots for each TLS type separately, + accounting for the possibility of a TLS variable getting referenced by + multiple symbols. + ld/ + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with + symbols referred by both types and global and local symbols. + +2024-02-21 Nelson Chu + + RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax. + Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c. Theoretically, + assembler don't need to generate the pc-relative relocation and the refered + local .L symbol when relaxation is disabled. The above commit improved the + pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump + relocations. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + gas/ + * config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all + branch and jump relocations when -mno-relax. + +2024-02-21 GDB Administrator + + Automatic date update in version.in + +2024-02-20 Tom Tromey + + Rewrite Rust slice type handling + This patch rewrites the handling of slice types in Rust. + + More recent versions of the Rust compiler changed how unsized types + were emitted, letting gdb inspect them more nicely. However, gdb did + not do this, and in fact treated all such types as if they were slices + of arrays, which is incorrect. + + This patch rewrites this handling and removes the restriction that + unsized types must be array slices. I've added a comment explaining + how unsized types are represented to rust-lang.c as well. + + I looked into a different approach, namely changing the DWARF reader + to fix up slice types to have a dynamic type. However, the approach + taken here turned out to be simpler. + + Tested on x86-64 Fedora 38 with a variety of Rust compiler versions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + +2024-02-20 Tom Tromey + + Add obj_section::contains method + I noticed a number of spots checking whether an address is in an + obj_section. This patch introduces a new method for this and changes + some code to use it. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Andrew Burgess + +2024-02-20 Simon Marchi + + gdb: pass frames as `const frame_info_ptr &` + We currently pass frames to function by value, as `frame_info_ptr`. + This is somewhat expensive: + + - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass + by value + - the constructors and destructor link/unlink the object in the global + `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so + it's not so bad: it's just assigning a few points, there's no memory + allocation as if it was `std::list`, but still it's useless to do + that over and over. + + As suggested by Tom Tromey, change many function signatures to accept + `const frame_info_ptr &` instead of `frame_info_ptr`. + + Some functions reassign their `frame_info_ptr` parameter, like: + + void + the_func (frame_info_ptr frame) + { + for (; frame != nullptr; frame = get_prev_frame (frame)) + { + ... + } + } + + I wondered what to do about them, do I leave them as-is or change them + (and need to introduce a separate local variable that can be + re-assigned). I opted for the later for consistency. It might not be + clear why some functions take `const frame_info_ptr &` while others take + `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because + it did re-assign its parameter, I doubt that we would think to change it + to `const frame_info_ptr &` should the implementation change such that + it doesn't need to take `frame_info_ptr` anymore. It seems better to + have a simple rule and apply it everywhere. + + Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 + Approved-By: Andrew Burgess + +2024-02-20 Tom de Vries + + [gdb] Don't init history in batch mode + I noticed in captured_main_1 that init_history is called just before bailing + out if batch_flag is true. + + The history is used only in an interactive session, so there's no need to + initialize it in batch mode. + + Fix this by moving init_history to after the batch mode check. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-02-20 Paul Iannetta + + kvx: gas: missing aliases for $r14r15 in assembler. + Most registers from a register-pair suffixed by .lo and .hi suffixes. + This was not the case of $r14 and $r15 since they are defined by the + ABI: $r14 is the frame pointer, and $r15 is used to return aggregates + from functions. We do not add aliases for $r12 (the stack pointer) and + $r13 (the tls register). + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: enable magic immediates for integer multiply-accumulate and CMOVE* + Affected instructions: + - alu unit: + cmovewp cmovehq + - mau unit: + maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp + msbfsuwdp mms mulwdp muluwdp mulsuwdp mm + + opcodes/ChangeLog: + + * kvx-opc.c (struct kvxopc): Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: rename: or -> ior, xor -> eor + TCA instructions start with an X, this introduces ambiguities when it + comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this + reason, we rename OR to IOR and XOR to EOR. + + OR and XOR variants are still valid on KV3-1 and KV3-2. However, they + have been completely removed from KV4-1. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: move the splat modifier to the immediate + The position of the splat modifier is now after the operand it + modifies and not attached directly to the opcode. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: fix leak + gas/ChangeLog: + + * config/tc-kvx.c (md_apply_fix): Free memory at this end. + +2024-02-20 Paul Iannetta + + kvx: Improve lexing & parsing + Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates, + however this candidate can be directly extracted from the array (in + kvx-parse.h) registering all the immediates. + + During lexing, we ignored trailing characters after a number, this is + not good enough since now number can be followed by a modifier. The + function READ_TOKEN and GET_TOKEN_CLASS have been update to take this + into account. + + gas/ChangeLog: + + * config/kvx-parse.c (promote_token): Do not rely on + env.promote_immediate anymore. + (get_token_class): Do not ignore trailing characters after a + number. + (read_token): Likewise. + (print_token_list): THIS SHOULD NOT BE HERE. + +2024-02-20 Paul Iannetta + + kvx: gas: fix the detection of negative powers of 2 + The detection of negative powers of 2 was wrong and could lead to + well-formed bundles ending up taking more syllables than necessary. + + gas/ChangeLog: + + * config/kvx-parse.c (get_token_class): Use the signed value. + * testsuite/gas/kvx/np2-detection.d: New test. + * testsuite/gas/kvx/np2-detection.s: New test. + +2024-02-20 Jose E. Marchesi + + bpf: gas: add missing indcall-badoperand.* test files + This adds teh following files that were missing in the previous + commit ecd16ae4e47118f66447641d93a6aa1334e550d4 + + testsuite/gas/bpf/indcall-badoperand.d + testsuite/gas/bpf/indcall-badoperand.l + testsuite/gas/bpf/indcall-badoperand.s + +2024-02-20 GDB Administrator + + Automatic date update in version.in + +2024-02-19 Will Hawkins + + bpf: fix bpf expression parsing regression in GAS + As a result of a switch instead of an if, as would issue non-specific + error messages when it encountered an operand it could not parse in bpf. + This patch fixes that regression and adds a test to prevent it from + reoccurring. + + Tested for bpf-unknown-none on x86_64-redhat-linux. + + gas/ChangeLog: + + * config/tc-bpf.c (parse_expression): Change switch to if so that error + * condition is handled. + * testsuite/gas/bpf/bpf.exp: Invoke new test. + * testsuite/gas/bpf/indcall-badoperand.d: New test. + * testsuite/gas/bpf/indcall-badoperand.l: New test. + * testsuite/gas/bpf/indcall-badoperand.s: New test. + +2024-02-19 Jose E. Marchesi + + bpf: gas: avoid UB in pointer subtraction + The PARSE_ERROR macro in md_assemble performs pointer subtraction. If + parse_expression returns NULL then the later will be part of the + subtraction and therefore UB will be incurred. + + This patch changes md_assemble to: + 1. Accommodate all invocations to parse_expression to the fact it will + return NULL when a parse error occurs. + 2. Avoid UB in PARSE_ERROR. + + Tested in bpf-unknown-none target / x86_64-linux-gnu host. + + gas/ChangeLog: + + * config/tc-bpf.c (md_assemble): Fix to take into account that + parse_expression can return NULL. + (PARSE_ERROR): Avoid passing invalid length to parse_error. + +2024-02-19 Claudio Bantaloukas + + arm: Add support for Armv9.5-A + +2024-02-19 Yury Khrustalev + + aarch64: Add support for the id_aa64isar3_el1 system register + Hi, + + [PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + + Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf? + + Thanks, + Yury Khrustalev + + From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001 + From: Yury Khrustalev + Date: Tue, 6 Feb 2024 11:05:39 +0000 + Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the + id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + +2024-02-19 Tankut Baris Aktemur + + testsuite, python: reformat python files using black + In the recent patch titled "gdb, python: selectively omit enabling + stdin in gdb.execute", the black tool found formatting issues. Fix + them. + +2024-02-19 Zac Walker + + aarch64: Add new relocations and limit COFF AArch64 relocation offsets + The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation + type. This is needed for 32-bit relative address. + + It also adds a check for relocation offsets over 21 bits. Offsets + inside coff files are stored in instruction code. In the case of ADRP + the actual value is stored, not a downshifted page offset. This means + values over 21 bits would otherwise be truncated. + + Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped. + + ChangeLog: + + * bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add + BFD_RELOC_AARCH64_ADR_GOT_PAGE, + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32 + relocations. + (coff_pe_aarch64_relocate_section): Likewise. + * gas/write.c (adjust_reloc_syms): COFF AArch64 relocation + offsets need to be limited to 21bits + (defined): Likewise. + +2024-02-19 Tankut Baris Aktemur + + gdb, python: selectively omit enabling stdin in gdb.execute + From the Python API, we can execute GDB commands via gdb.execute. If + the command gives an exception, however, we need to recover the GDB + prompt and enable stdin, because the exception does not reach + top-level GDB or normal_stop. This was done in commit + + commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a + Author: Andrew Burgess + Date: Tue Nov 19 11:17:20 2019 +0000 + + gdb: Enable stdin on exception in execute_gdb_command + + with the following code: + + catch (const gdb_exception &except) + { + /* If an exception occurred then we won't hit normal_stop (), or have + an exception reach the top level of the event loop, which are the + two usual places in which stdin would be re-enabled. So, before we + convert the exception and continue back in Python, we should + re-enable stdin here. */ + async_enable_stdin (); + GDB_PY_HANDLE_EXCEPTION (except); + } + + In this patch, we explain what happens when we run a GDB command in + the context of a synchronous command, e.g. via Python observer + notifications. + + As an example, suppose we have the following objfile event listener, + specified in a file named file.py: + + ~~~ + import gdb + + class MyListener: + def __init__(self): + gdb.events.new_objfile.connect(self.handle_new_objfile_event) + self.processed_objfile = False + + def handle_new_objfile_event(self, event): + if self.processed_objfile: + return + + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('add-inferior -no-connection') + gdb.execute('inferior 2') + gdb.execute('target remote | gdbserver - /tmp/a.out') + gdb.execute('inferior 1') + + the_listener = MyListener() + ~~~ + + Using this Python file, we see the behavior below: + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3075406 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3075400] (/tmp/a.out)] + [Switching to thread 1.1 (process 3075400)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + (gdb) [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3075400) exited normally] + + Note how the GDB prompt comes in-between the debugger output. We have this + obscure behavior, because the executed command, "target remote", triggers + an invocation of `normal_stop` that enables stdin. After that, however, + the Python notification context completes and GDB continues with its normal + flow of executing the 'run' command. This can be seen in the call stack + below: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801 + #3 0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225 + #4 0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316 + #5 0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175 + #6 0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338 + #7 0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280) at src/gdb/target.c:824 + #8 0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735 + #9 0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575 + #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529 + #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701 + #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411 + #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700 + #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52 + #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195 + #24 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #25 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #26 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290 + #27 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590 + #28 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166 + #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416 + #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The use of the "target remote" command here is just an example. In + principle, we would reproduce the problem with any command that + triggers an invocation of `normal_stop`. + + To omit enabling the stdin in `normal_stop`, we would have to check the + context we are in. Since we cannot do that, we add a new field to + `struct ui` to track whether the prompt was already blocked, and set + the tracker flag in the Python context before executing a GDB command. + + After applying this patch, the output becomes + + ... + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3032261 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3032255] (/tmp/a.out)] + [Switching to thread 1.1 (process 3032255)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3032255) exited normally] + (gdb) + + Let's now consider a secondary scenario, where the command executed from + the Python raises an error. As an example, suppose we have the Python + file below: + + def handle_new_objfile_event(self, event): + ... + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('print a') + + The executed command, "print a", gives an error because "a" is not + defined. Without this patch, we see the behavior below, where the + prompt is again placed incorrectly: + + ... + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + (gdb) [Inferior 1 (process 3980401) exited normally] + + This time, `async_enable_stdin` is called from the 'catch' block in + `execute_gdb_command`: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713 + #2 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #3 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #4 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #5 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #6 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #7 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #8 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #9 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52 + #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195 + #12 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #13 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #14 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290 + #15 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590 + #16 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166 + #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416 + #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + Again, after we enable stdin, GDB continues with its normal flow + of the 'run' command and receives the inferior's exit event, where + it would have enabled stdin, if we had not done it prematurely. + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700 + #3 0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42 + #4 0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316 + #5 0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573 + #6 0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694 + #7 0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217 + #8 0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407 + #9 0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471 + #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324 + #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The solution implemented by this patch addresses the problem. After + applying the patch, the output becomes + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + [Inferior 1 (process 3984511) exited normally] + (gdb) + + Regression-tested on X86_64 Linux using the default board file (i.e. unix). + + Co-Authored-By: Oguzhan Karakaya + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-02-19 Tom de Vries + + [gdb/exp] Fix printing of out of bounds struct members + When building gdb with -O0 -fsanitize=address, and running test-case + gdb.ada/uninitialized_vars.exp, I run into: + ... + (gdb) info locals + a = 0 + z = (a => 1, b => false, c => 2.0) + ================================================================= + ==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80 + READ of size 4 at 0x602000097f58 thread T0 + #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18) + #1 0xbcab24 in unsigned char* std::__copy_move_backward::__copy_move_b(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748 + #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769 + #3 0xbc898c in unsigned char* std::__copy_move_backward_a1(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778 + #4 0xbc715c in unsigned char* std::__copy_move_backward_a(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807 + #5 0xbc4e6c in unsigned char* std::copy_backward(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867 + #6 0xbc2934 in void gdb::copy(gdb::array_view, gdb::array_view) gdb/../gdbsupport/array-view.h:223 + #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239 + #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078 + #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095 + #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658 + #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857 + #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042 + #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04) + #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092 + #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184 + #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #18 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #19 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #20 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #29 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694 + #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264 + #39 0x1768080 in start_event_loop gdb/main.c:408 + #40 0x17684c4 in captured_command_loop gdb/main.c:472 + #41 0x176cfc8 in captured_main gdb/main.c:1342 + #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361 + #43 0xb73edc in main gdb/gdb.c:39 + #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8) + #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac) + #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c) + + 0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58) + allocated by thread T0 here: + #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218) + #1 0xcbc278 in xcalloc gdb/alloc.c:97 + #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29 + #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937 + #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033 + #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector > const&) gdb/value.c:229 + #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560 + #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133 + #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182 + #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #11 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #12 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #13 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #22 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + + SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove + ... + + The error happens when trying to print either variable y or y2: + ... + type Variable_Record (A : Boolean := True) is record + case A is + when True => + B : Integer; + when False => + C : Float; + D : Integer; + end case; + end record; + Y : Variable_Record := (A => True, B => 1); + Y2 : Variable_Record := (A => False, C => 1.0, D => 2); + ... + when the variables are uninitialized. + + The error happens only when printing the entire variable: + ... + (gdb) p y.a + $2 = 216 + (gdb) p y.b + There is no member named b. + (gdb) p y.c + $3 = 9.18340949e-41 + (gdb) p y.d + $4 = 1 + (gdb) p y + + ... + + The error happens as follows: + - field a functions as discriminant, choosing either the b, or c+d variant. + - when y.a happens to be set to 216, as above, gdb interprets this as the + variable having the c+d variant (which is why trying to print y.b fails). + - when printing y, gdb allocates a value, copies the bytes into it from the + target, and then prints the value. + - gdb allocates the value using the type size, which is 8. It's 8 because + that's what the DW_AT_byte_size indicates. Note that for valid values of a, + it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1 + (b variant), size is 8. + - gdb tries to print field d, which is at an 8 byte offset, and that results + in a out-of-bounds access for the allocated 8-byte value. + + Fix this by handling this case in value::contents_copy_raw, such that we have: + ... + (gdb) p y + $1 = (a => 24, c => 9.18340949e-41, + d => ) + ... + + An alternative (additional) fix could be this: in compute_variant_fields_inner + gdb reads the discriminant y.a to decide which variant is active. It would be + nice to detect that the value (y.a == 24) is not a valid Boolean, and give up + on choosing a variant altoghether. However, the situation regarding the + internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not + possible to reliably decide what valid values are. + + The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is + a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the + copyright years. + + Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc + versions. [ So, it would be nice to rewrite it into a dwarf assembly + test-case. ] + + The test-case loops over all languages. This is inherited from an earlier + attempt to fix this, which had language-specific fixes (in print_field_values, + cp_print_value_fields, pascal_object_print_value_fields and + f_language::value_print_inner). I've left this in, but I suppose it's not + strictly necessary anymore. + + Tested on x86_64-linux. + + PR exp/31258 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258 + +2024-02-19 GDB Administrator + + Automatic date update in version.in + +2024-02-18 GDB Administrator + + Automatic date update in version.in + +2024-02-17 GDB Administrator + + Automatic date update in version.in + +2024-02-16 H.J. Lu + + ld: Add -plugin-save-temps + Add -plugin-save-temps to store plugin intermediate files permanently. + It can be used to exam the final input object files generated from IR + inputs. + + * NEWS: Mention -plugin-save-temps. + * ld.h (ld_config_type): Add plugin_save_temps. + * ld.texi: Document -plugin-save-temps. + * ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS. + * lexsup.c (ld_options): Add -plugin-save-temps. + (parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS. + * plugin.c (plugin_call_cleanup): Don't call plugin + cleanup_handler for -plugin-save-temps. + +2024-02-16 Alan Modra + + PR27597, nios: assertion fail in nios2_elf32_install_imm16 + The assertion in nios2_elf32_install_imm16 triggers when the PLT is + twice the maximum allowable size for a branch from PLTn to reach + .PLTresolve, and on no other call to nios2_elf32_install_imm16. That + makes the assertion completely useless. We can handle a PIC PLT + exceeding 0x8000 in size by bouncing branches that won't reach through + previous branches. + + PR 27597 + * elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT. + (nios2_build_one_stub): Don't bother masking value passed to + nios2_elf32_install_imm16. + (nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow + of PLTn branch to .PLTresolve by bouncing through prior branches. + +2024-02-16 Nick Clifton + + Update how-to-make-a-release document to reference new git repository for the documentation + +2024-02-16 Jan Beulich + + x86/APX: drop stray IgnoreSize + While necessary on the legacy encodings, the EVEX ones don't need it. + Even more so when they're available for 64-bit mode only, when the + legacy encodings have the attribute only for correctly handling things + in 16-bit mode. + + x86: don't use VexWIG in SSE2AVX templates + Several years ago it was decided that SSE2AVX templates should not be + sensitive to -mvexwig= (upon my suggestion to consistently make all + sensitive as long as they don't require a specific setting of VEX.W). + Adjust the four that still are, switching to use of Vex128 at the same + time. + + x86: drop redundant Xmmword + While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from + insn templates") did so for Byte/Word/Dword/Qword, the same kind of + redundancy was left in place for a few 128-bit SIMD operands. + + SCFI: correct test names + Having multiple tests with the same name is confusing. + +2024-02-16 GDB Administrator + + Automatic date update in version.in + +2024-02-15 H.J. Lu + + x86: Display -msse-check= default as none + Display -msse-check= default as none for "as --help" since its default + is none, not warning. + + PR gas/31389 + * config/tc-i386.c (md_show_usage): Change -msse-check= default + to none. + +2024-02-15 Alan Modra + + S/390: 32-bit PIE undef weak failures + Like 10e7c0457cb7 but for elf32-s390.c + + * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use + UNDEFWEAK_NO_DYNAMIC_RELOC. + (allocate_dynrelocs): Likewise. + (elf_s390_relocate_section): Check resolved_to_zero. + (elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if + UNDEFWEAK_NO_DYNAMIC_RELOC. + +2024-02-15 Tom Tromey + + Move lookup_name_info creation into basic_lookup_transparent_type + I noticed that basic_lookup_transparent_type calls two different + functions that both proceed to create a lookup_name_info. It's more + efficient to create this object in the outermost layer possible. + Making this change required a few related changes, resulting in this + patch. + + There are still more changes of this sort that could be made. + + Regression tested on x86-64 Fedora 38. + +2024-02-15 Will Hawkins + + objdump, as: add callx support for BPF CPU v1 + Albeit not being a currently valid BPF instruction, callx is generated + by both clang and GCC when BPF programs are compiled unoptimized. + Until now, GCC would emit it only whe using the experimental + compiler-testing cpu version xbpf, whereas clang would emit it from + v1. This patch makes GAS to accept callx also starting with cpu v1. + + opcodes/ChangeLog + + * bpf-opc.c: Move callx into the v1 BPF CPU variant. + + gas/ChangeLog + + * testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu + version. + * testsuite/gas/bpf/indcall-1.d: Likewise. + +2024-02-15 Alan Modra + + Make various gas symbol predicates and accessors take const args + * symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK), + (S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED), + (S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD), + (symbol_previous, symbol_next, symbol_X_add_number), + (symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p), + (symbol_mri_common_p, symbol_written_p, symbol_removed_p), + (symbol_resolved_p, symbol_resolving_p, symbol_section_p), + (symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p), + (symbol_shadow_p, symbol_same_p): Constify sym args. + * symbols.h: Update prototypes. + + Re: elf_backend_finish_dynamic_symbol returning false + Making a bfd_final_link failure noisy requires testsuite changes. + + PR28448, Memory leak in function add_symbols(plugin.c) + PR 28448 + * plugin.c (add_symbols): bfd_alloc memory for symptrs. Check + bfd_make_empty_symbol return. + + Re: elf_backend_finish_dynamic_symbol returning false + I didn't examine ld testsuite logs properly after cf95b909e2c2. + Replacing one of the "return false" with BFD_ASSERT in + finish_dynamic_symbol was wrong as it causes segmentation faults on + testcases expected to fail. Revert those changes and instead make + a bfd_final_link failure noisy. + +2024-02-15 Samuel Tardieu (tiny change) + + gdb/doc: Fix several typos in GDB documentation + Approved-by: Eli Zaretskii + +2024-02-15 Steinar H. Gunderson + + PR29785, memory bloat after b43771b045fb + Pathological cases of dwarf info with overlapping duplicate memory + ranges can cause splitting of trie leaf nodes, which in the worst case + will cause memory to increase without bounds. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Don't split leaf nodes + unless that reduces number of elements in at least one node. + +2024-02-15 Alan Modra + + PR30308, infinite recursion in i386_intel_simplify + This patch exposes the symbol "resolving" flag for use in + i386_intel_simplify, not only preventing infinite recursion on the + testcase in the PR but also more complicated cases like: + + .intel_syntax + b = a + a = b + mov eax, [a] + + PR 30308 + * symbols.c (symbol_mark_resolving, symbol_clear_resolving), + (symbol_resolving_p): New functions. + * symbols.h: Declare them. + * config/tc-i386-intel.c (i386_intel_simplify): Delete forward + declaration. Formatting. + (i386_intel_simplify_symbol): Use resolving flag to prevent + infinite recursion. + +2024-02-15 Alan Modra + + elf_backend_finish_dynamic_symbol returning false + Returning false from elf_backend_finish_dynamic_symbol will not result + in an error being printed unless bfd_error is set but will result in + the linker exiting with a non-zero status. If just bfd_error is set + then a generic "final link failed" will result, which doesn't help a + user much. So elf_backend_finish_dynamic_symbol should print its own + error message whenever returning false, or use BFD_ASSERT or abort to + print assertion failures for conditions that shouldn't occur. + + This patch does that, and removes unnecessary "htab != NULL" tests in + elf_backend_finish_dynamic_symbol. Such tests aren't needed in a + function only called via elf_backend_data. + +2024-02-15 GDB Administrator + + Automatic date update in version.in + +2024-02-14 Tom de Vries + + [gdb/dap] Fix exit race + When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to + a segfault in new_threadstate. + + At the point of the core dump, the gdb main thread looks like: + ... + (gdb) bt + #0 0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0 + #6 0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0 + #7 0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738) + at gdb/python/python-internal.h:787 + #8 0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0, + __in_chrg=) at gdb/python/python.c:1051 + #9 0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy + (__victim=...) at /usr/include/c++/13/bits/std_function.h:175 + #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager + (__dest=..., __source=..., __op=std::__destroy_functor) + at /usr/include/c++/13/bits/std_function.h:203 + #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...) + at /usr/include/c++/13/bits/std_function.h:282 + #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:244 + #13 0x000000000042e654 in std::function::~function() (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:334 + #14 0x0000000000b68e60 in std::_Destroy >(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:151 + #15 0x0000000000b68cd0 in std::_Destroy_aux::__destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:163 + #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:196 + #17 0x0000000000b68414 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/alloc_traits.h:948 + #18 std::vector<...>::~vector() (this=0x2a183c8 ) + at /usr/include/c++/13/bits/stl_vector.h:732 + #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6 + #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6 + #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0) + at gdb/top.c:1822 + #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0) + at gdb/cli/cli-cmds.c:508 + #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300 + #24 0x00000000007b09d4 in async_disconnect (arg=0x0) + at gdb/event-top.c:1230 + #25 0x0000000000548acc in invoke_async_signal_handlers () + at gdb/async-event.c:234 + #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:199 + #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #29 0x000000000094567c in captured_main (data=0xffffcb279d08) + at gdb/main.c:1335 + #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08) + at gdb/main.c:1354 + #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98) + at gdb/gdb.c:39 + ... + + The direct cause of the segfault is calling PyGILState_Ensure after + calling Py_Finalize. + + AFAICT the problem is a race between the gdb main thread and DAP's JSON writer + thread. + + On one side, we have the following events: + - DAP's JSON reader thread reads an EOF, and lets DAP's main thread known + by writing None into read_queue + - DAP's main thread lets DAP's JSON writer thread known by writing None into + write_queue + - DAP's JSON writer thread sees the None in its queue, and calls + send_gdb("quit") + - a corresponding gdbpy_event is deposited in the runnables vector, to be + run by the gdb main thread + + On the other side, we have the following events: + - the gdb main thread receives a SIGHUP + - the corresponding handler calls quit_force, which calls do_final_cleanups + - one of the final cleanups is finalize_python, which calls Py_Finalize + - quit_force calls exit, which triggers the exit handlers + - one of the exit handlers is the destructor of the runnables vector + - destruction of the vector triggers destruction of the remaining element + - the remaining element is a gdbpy_event, and the destructor (indirectly) + calls PyGILState_Ensure + + It's good to note that both events (EOF and SIGHUP) are caused by this line in + the test-case: + ... + catch "close -i $gdb_spawn_id" + ... + where "expect close" closes the stdin and stdout file descriptors, which + causes the SIGHUP to be send. + + So, for the system I'm running this on, the send_gdb("quit") is actually not + needed. + + I'm not sure if we support any systems where it's actually needed. + + Fix this by removing the send_gdb("quit"). + + Tested on aarch64-linux. + + PR dap/31306 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306 + +2024-02-14 H.J. Lu + + gdb: Reformat amd64_dwarf_reg_to_regnum + Reformat amd64_dwarf_reg_to_regnum: + + @@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg) + if (reg >= 0 && reg < amd64_dwarf_regmap_len) + regnum = amd64_dwarf_regmap[reg]; + + - if (ymm0_regnum >= 0 + - && i386_xmm_regnum_p (gdbarch, regnum)) + + if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum)) + regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep); + + to remove the misaligned line. + +2024-02-14 Tom Tromey + + Use typedef in definition of warning_hook + This changes the global 'warning_hook' to use the warning_hook_handler + typedef in its definition. This makes it a little easier to change + the type, should that be needed. + +2024-02-14 Yuriy Kolerov + + arc: Put DBNZ instruction to a separate class + DBNZ instruction decrements its source register operand, and if + the result is non-zero it branches to the location defined by a signed + half-word displacement operand. + + DBNZ instruction is in BRANCH class as other branch instrucitons + like B, Bcc, etc. However, DBNZ is the only branch instruction + that stores a branch offset in the second operand. Thus it must + be placed in a distinct class and treated differently. + + For example, current logic of arc_insn_get_branch_target in GDB + assumes that a branch offset is always stored in the first operand + for BRANCH class and it's wrong for DBNZ. + + include/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * opcode/arc.h (enum insn_class_t): Add DBNZ class. + + opcodes/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * arc-tbl.h (dbnz): Use "DBNZ" class. + * arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class. + + gas/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ". + +2024-02-14 Tom de Vries + + [gdb/testsuite] Fix another fail and tcl error in gdb.dap/sources.exp + With gdb.dap/sources.exp on aarch64-linux, I'm running into: + ... + {"request_seq": 3, "type": "response", "command": "loadedSources", \ + "success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M + ^M + {"type": "event", "event": "thread", \ + "body": {"reason": "started", "threadId": 1}, \ + "seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: tcl error code TCL LOOKUP DICT body + ERROR: key "body" not known in dictionary + while executing + "dict get [lindex $obj 0] body sources" + ... + + These are the same type of tcl error and FAIL I just fixed for a later + request in the same test-case. + + Fix this by: + - moving the wait-for-stop to before the loadedSources request to fix the + FAIL, and + - checking for $obj == "" to fix the tcl error. + + Also make the code a bit less indented and more readable by wrapping the tests + in a proc, allowing the use of return to bail out, while still running + dap_shutdown afterwards. + + Approved-By: Tom Tromey + + Tested on aarch64-linux. + +2024-02-14 GDB Administrator + + Automatic date update in version.in + +2024-02-13 Yuriy Kolerov + + arc: Don't use multiline in arc-disassembler-options.exp test + Breaking a TCL string to several lines leads to adding of extra + symbols to the resulting expect string. In turn, this leads to + failing of all test cases in gdb.arch/arc-disassembler-options.exp + testsuite. It's necessary to use multi_line function in such + cases. + + Approved-By: Tom Tromey + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix fail in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ... + + The fail happens because the request races with the stopping at main as + requested by: + ... + if {[dap_launch $testfile stop_at_main 1] == ""} { + ... + + Fix this by waiting for the stop, in the same way that is done in other + test-cases that use stop_at_main. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31374 + https://sourceware.org/bugzilla/show_bug.cgi?id=31374 + +2024-02-13 Jaydeep Patil + + sim: riscv: Add support for compressed integer instructions + Added support for simulation of compressed integer instruction set ("c"). + Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions. + The compressed instructions are available for models implementing C extension. + Such as RV32IC, RV64IC, RV32GC, RV64GC etc. + + Approved-By: Andrew Burgess + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix tcl error in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: key "body" not known in dictionary + ... + + The FAIL has been filed as PR dap/31374. + + The ERROR happens because after the FAIL, dap_check_request_and_response + returns "", and the test-case doesn't check for that. + + Fix this by checking for $obj != "" in the test-case. + + Tested on x86_64-linux. + +2024-02-13 Tom de Vries + + [gdb/tdep] Fix reverse execution of LDR(immediate) T4 + When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with + target board unix/-mthumb, we run into: + ... + (gdb) reverse-step + func2 () at func-map-to-same-line.c:26 + 26 { + (gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \ + column_info_flag=column-info: step-test: reverse-step into func2 + ... + + The FAIL is caused by incorrect recording of this insn: + ... + 4f6: f85d 7b04 ldr.w r7, [sp], #4 + ... + + The insn updates the sp, but we don't record this: + ... + $ gdb -q -batch func-map-to-same-line \ + -ex "b *func2+8" \ + -ex run \ + -ex record \ + -ex "set debug record 2" \ + -ex stepi + Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27. + + Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27 + 27 } /* END FUNC2 */ + Process record: arm_process_record addr = 0xaaaaa4f6 + Process record: add register num = 15 to record list. + Process record: record_full_arch_list_add 0xabc6c460. + Process record: add register num = 7 to record list. + Process record: record_full_arch_list_add 0xabc3b868. + Process record: add register num = 25 to record list. + ... + [ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ] + + The problem is that the specific insn, an LDR(immediate) T4, is not handled in + thumb2_record_ld_word. + + Fix this by detecting the insn in thumb2_record_ld_word, and recording the + updated base register. + + Tested on arm-linux. + + Reported-By: Thiago Jung Bauermann + Approved-By: Luis Machado + + PR tdep/31278 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278 + +2024-02-13 GDB Administrator + + Automatic date update in version.in + +2024-02-12 Tom Tromey + + Introduce bfd_print_error function + gdb likes to control its own output; for example, this is important + for gdb's pager, and for logging. While BFD provides a way to + intercept error output, via bfd_set_error_handler, it turns out to be + difficult for this function to truly generate the desired output in a + gdb-friendly way -- the error handler is expected to implement some + BFD printf format extensions. + + This patch introduces a new function that an error handler can use to + format the text. This way, gdb can set the error handler and arrange + for the output to be displayed as it likes. + + * bfd.c (bfd_print_callback): Rename from print_func. Move into + comment. + (_bfd_doprnt): Update. + (bfd_print_error): New function. + (error_handler_fprintf, error_handler_sprintf): Use + bfd_print_error. + * bfd-in2.h: Rebuild. + +2024-02-12 Tom Tromey + + Do not call fputc from _bfd_doprnt + I noticed that _bfd_doprnt can unconditionally call fputc. However, + when called from error_handler_sprintf, this will likely result in a + crash, as the stream argument does not actually point to a FILE. + + * bfd.c (_bfd_doprnt): Do not call fputc. + +2024-02-12 Tom de Vries + + [gdb] Re-format dap/startup.py with black + Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made + some changes to gdb/python/lib/gdb/dap/startup.py. + + Re-format it with black. + +2024-02-12 Tom de Vries + + [gdb/dap] Catch and log exceptions in dap threads + When running test-case gdb.dap/eof.exp, it occasionally coredumps. + + The thread triggering the coredump is: + ... + #0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232 + #6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s") at gdb/ui-out.c:584 + #7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=..., + format=0x16f93ea "", args=...) at gdb/ui-out.c:621 + #8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...) + at gdb/ui-file.c:74 + #9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s", + args=...) at gdb/utils.c:1898 + #10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s") + at gdb/utils.c:1913 + #11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0) + at gdb/python/python.c:1464 + #12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0 + #17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0 + #18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0 + #19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0 + #20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O () + from /lib64/libpython3.12.so.1.0 + #21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0 + #22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0 + #25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0 + #26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6 + #27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6 + ... + + The direct cause for the coredump seems to be that cli_ui_out::do_message + is trying to write to a stream variable which does not look sound: + ... + (gdb) p *stream + $8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, { + m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}}, + m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377', + m_green = 255 '\377', m_blue = 0 '\000'}}}, + m_intensity = (unknown: 0x438fe710), m_reverse = 255}} + ... + + The string that is being printed is: + ... + (gdb) p str + $9 = "Exception in thread " + ... + so AFAICT this is a DAP thread running into an exception and trying to print + it. + + If we look at the state of gdb's main thread, we have: + ... + #0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6 + #1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 () + from /lib64/libc.so.6 + #2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0 + #3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread () + from /lib64/libpython3.12.so.1.0 + #4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads ( + this=0xfffffbea1cf8, __in_chrg=) + at gdb/python/python-internal.h:769 + #5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60, + kw=0x34553d20) at gdb/python/python.c:681 + #6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 () + from /lib64/libpython3.12.so.1.0 + #10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900) + at gdb/python/python.c:1061 + #11 0x0000000000ab93e8 in std::__invoke_impl (__f=...) + at /usr/include/c++/13/bits/invoke.h:61 + #12 0x0000000000ab9204 in std::__invoke_r (__fn=...) + at /usr/include/c++/13/bits/invoke.h:111 + #13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...) + at /usr/include/c++/13/bits/std_function.h:290 + #14 0x000000000062e0d0 in std::function::operator()() const ( + this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591 + #15 0x0000000000b67f14 in run_events (error=0, client_data=0x0) + at gdb/run-on-main-thread.c:76 + #16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1) + at gdbsupport/event-loop.cc:573 + #17 0x000000000157e760 in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:694 + #18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:264 + #19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #21 0x000000000094567c in captured_main (data=0xfffffbea23e8) + at gdb/main.c:1335 + #22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8) + at gdb/main.c:1354 + #23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578) + at gdb/gdb.c:39 + ... + + AFAIU, there's a race between the two threads on gdb_stderr: + - the DAP thread samples the gdb_stderr value, and uses it a bit later to + print to + - the gdb main thread changes the gdb_stderr value forth and back, + using a temporary value for string capture purposes + + The non-sound stream value is caused by gdb_stderr being sampled while + pointing to a str_file object, and used once the str_file object is already + destroyed. + + The error here is that the DAP thread attempts to print to gdb_stderr. + + Fix this by adding a thread_wrapper that: + - catches all exceptions and logs them to dap.log, and + - while we're at it, logs when exiting + and using the thread_wrapper for each DAP thread. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-12 Tom Tromey + + Fix DAP launch and configurationDone requests + Co-workers at AdaCore pointed out that gdb incorrectly implements the + DAP launch and configurationDone requests. It's somewhat strange to + me, but the spec does in fact say that configuration requests should + occur before the executable is known to gdb. This was clarified in + this bug report against the spec: + + https://github.com/microsoft/debug-adapter-protocol/issues/452 + + Fixing 'launch' to start the inferior was straightforward, but this + then required some changes to how breakpoints are handled. In + particular, now gdb will emit the "pending" reason on a breakpoint, + and will suppress breakpoint events during breakpoint setting. + +2024-02-12 Tom Tromey + + Clean up suppress_new_breakpoint_event + Kévin pointed out that suppress_new_breakpoint_event would do the + wrong thing if it happened to be used reentrantly. While I don't + think this can happen, it's also easy and clearly better to make it + robust. + + Export dap_initialize + This changes the test suite to export dap_initialize. + +2024-02-12 Simon Marchi + + gdb: re-format Python files with black 24.1.1 + New year, new black version. + + Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d + +2024-02-12 Frederic Cambus + + Add support to readelf for the PT_OPENBSD_SYSCALLS segment type. + binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type. + include * elf/common.h (PT_OPENBSD_SYSCALLS): Define. + +2024-02-12 Carl Love + + rs6000, unwind-on-each-instruction fix. + The function rs6000_epilogue_frame_cache assumes the LR and gprs have been + restored. In fact register r31 and the link register, lr, may not have + been restored yet. This patch adds support to store the lr and gpr + register unrolling rules in the cache. The LR and GPR values can now be + unrolled correctly. + + Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp. + +2024-02-12 Alexandra Hájková + + remote.c: Make packet_check_result return a structure + packet_check_result currently returns an packet_result enum. + If GDB will recieve an error in a format E.errtext, which + is possible for some q packets, such errtext is lost if + treated by packet_check_result. + Introduce a new structure which bundles enum packet_result + with possible error message or error code returned by + the GDBserver. + I plan to make more GDBserver response checking functions to use + packet_check_result to make remote.c code more consistent. + This will also allow to use E.errtext more in the future. + + Beside adding the unit test, I tested this by modifying + store_registers_using_G function to get an error message: + + [remote] Sending packet: $GG00000000 ... + + gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793) + gdbserver: Invalid hex digit 71 + Killing process(es): 1104002 + [remote] Packet received: E01 + Could not write registers; remote failure reply '01' + + Reviewed-by: Thiago Jung Bauermann + +2024-02-12 GDB Administrator + + Automatic date update in version.in + +2024-02-11 Hannes Domani + + Fix crash when calling Frame.static_link + If you try to call Frame.static_link for a frame without debug info, + gdb crashes: + ``` + Temporary breakpoint 1, 0x000000013f821650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + The problem was a missing check if get_frame_block returns nullptr + inside frame_follow_static_link. + + With this, it works: + ``` + Temporary breakpoint 1, 0x000000013f941650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + None + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366 + Approved-By: Tom Tromey + +2024-02-11 GDB Administrator + + Automatic date update in version.in + +2024-02-10 Andrew Burgess + + gdb/python: fix 'set python ignore-environment' white space + I noticed that the help text for set/show python ignore-environment + was messed up, some lines had unwanted leading white space, like this: + + (gdb) help set python ignore-environment + Set whether the Python interpreter should ignore environment variables. + When enabled GDB's Python interpreter will ignore any Python related + flags in the environment. This is equivalent to passing `-E' to a + python executable. + (gdb) + + This has been present since the ignore-environment setting was added + in commit: + + commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9 + Date: Thu Aug 27 16:53:13 2020 +0100 + + gdb: startup commands to control Python extension language + + Fixed in this commit. + +2024-02-10 GDB Administrator + + Automatic date update in version.in + +2024-02-09 Hannes Domani + + Allow value repeat operator on references + Currently it's not possible to use the value repeat operator on references: + ``` + print ((int &) v_int_array_init[0])@2 + Only values in memory can be extended with '@'. + ``` + + This seems like an unnecessary restriction, since it also prevents + its use on iterators (which was the original reported problem): + ``` + (gdb) p *it@2 + Only values in memory can be extended with '@'. + ``` + + So this converts any references to the referenced value in value_repeat, + making this possible: + ``` + print ((int &) v_int_array_init[0])@2 + $1 = {10, 20} + (gdb) p *it@2 + $2 = {1, 2} + ``` + + Approved-by: Kevin Buettner + +2024-02-09 Peter Bergner + + PowerPC: Add support for Power11 options + binutils/ + * doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11. + + gas/ + * config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11. + * doc/c-ppc.texi: Likewise. + + opcodes/ + * ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries. + (powerpc_init_dialect): Default to "power11". + +2024-02-09 Simon Marchi + + gdb: remove unnecessary nullptr check in remove_user_added_objfile + Since commit 74daa597e74 ("gdb: add all_objfiles_removed observer"), the + objfile passed to the free_objfile observable can't be nullptr. + + Change-Id: If215aa051ab43c068b11746938022c7efca09caa + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to clear_solib + Make the current_program_space reference bubble up one level. + + Remove one unnecessary declaration of clear_solib. + + Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to disable_breakpoints_in_shlibs + Make the current_program_space reference bubble up one level. + + Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add inferior parameter to breakpoint_init_inferior + By inspection, I believe that breakpoint_init_inferior doesn't call + anything that relies on the current program space or inferior. So, + add an inferior parameter, to make the current inferior / program space + references bubble up one level. + + Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7 + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to mark_breakpoints_out + Make the current_program_space reference bubble up one level. + + Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29 + Approved-By: Andrew Burgess + +2024-02-09 Pedro Alves + + Fix crash in aarch64-linux gdbserver + Since commit 393a6b5947d0 ("Thread options & clone events (Linux + GDBserver)"), aarch64-linux gdbserver crashes when the inferior + vforks. This happens in aarch64_get_debug_reg_state: + + struct process_info *proc = find_process_pid (pid); + + return &proc->priv->arch_private->debug_reg_state; + + Here, find_process_pid returns nullptr -- the new inferior hasn't yet + been created in linux_process_target::handle_extended_wait. + + This patch fixes the problem by having + linux_process_target::handle_extended_wait create the child process + earlier, before the child LWP is created. This is what the function + did before it was reorganized by the commit referred above. + + Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50 + Co-Authored-By: Tom Tromey + +2024-02-09 Jan Beulich + + x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3 + Don't wander into three_byte_table[] when REX2 is present. + + While there also eliminate related confusion when accessing + dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping + the odd variable gets things better in sync with 1-byte handling as + well. + +2024-02-09 Jan Beulich + + x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed + Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't + even present in the x86-64-apx-egpr-inval testcase, hence why I + overlooked that these can actually be encoded, (again) using suitable + AVX512 counterparts. + + While there also "modernize" the adjacent AVX/AVX2 entries. + +2024-02-09 Jan Beulich + + x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} + In eea4357967b6 ("x86/APX: VROUND{P,S}{S,D} can generally be encoded") I + failed to add the AVX512* ISA dependency of the two new entries. + + x86: change type of Dwarf2 register numbers in register table + Already the %bnd registers used numbers beyond 127, and eGPR ones are + all out of reach for "signed char", at least when CHAR_BITS=8. Switch to + "unsigned char", covering appropriately in places where the value + returned for "none" actually matters (in tc_x86_parse_to_dw2regnum() + this is actually achieved by altering how X_op is set). + +2024-02-09 Indu Bhagat + + gas: scfi: fix failing test on Solaris2 + It has been observed that the run of scfi-unsupported-1 test with --x32 + arg on a Solaris2 x86_64 system fails: + + Executing on host: sh -c {../as-new --x32 --scfi=experimental \ + <...>/scfi-unsupported-1.s 2>&1} /dev/null dump.out (timeout = 300) + Assembler messages: + Fatal error: no compiled in support for 32bit x86_64 + regexp_diff match failure + regexp "^Fatal error: SCFI is not supported for this ABI$" + line "Fatal error: no compiled in support for 32bit x86_64" + FAIL: x86_64 scfi-unsupported-1 + + Fix the above by adding a check for --x32 support before running the + test. While at it, also include a similar check for --32 support. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and + gas_32_check. Conditionalize the execution of affected + testcases. + +2024-02-09 Alan Modra + + PR 14962 testcase xcoff failure + Like https://sourceware.org/pipermail/binutils/2002-August/021279.html + but for symbols defined in an xcoff object but then made absolute by a + linker script. + + * xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly + for symbols made absolute by a linker script. + +2024-02-09 GDB Administrator + + Automatic date update in version.in + +2024-02-08 Thiago Jung Bauermann + + gdb/testsuite: Fix testing of "info copying" + gdb.base/default.exp has an incomplete test for the "info copying" command, + as poetically pointed out by the FIXME removed by this patch. + + The test omits the pattern argument to gdb_test, which causes it to just + check for a GDB prompt at the end of the command output. + + The problem is that the command output is the whole GPLv3 license, which + due to its size causes the test to fail sometimes, making the testcase to + be out of sync with GDB's output and failing the tests that follow + it. E.g., + + FAIL: gdb.base/default.exp: info copying (timeout) + FAIL: gdb.base/default.exp: info display + FAIL: gdb.base/default.exp: info frame "f" abbreviation + PASS: gdb.base/default.exp: info frame + FAIL: gdb.base/default.exp: info files + FAIL: gdb.base/default.exp: info float + FAIL: gdb.base/default.exp: info functions + FAIL: gdb.base/default.exp: info locals + FAIL: gdb.base/default.exp: info program + FAIL: gdb.base/default.exp: info registers + FAIL: gdb.base/default.exp: info stack "s" abbreviation + + Fix by by checking for a few excerpts at the beginning, middle and end of + the license text. This makes the test consume the command's output in + smallish chunks. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-02-08 Alan Modra + + PR31208, strip can break ELF alignment requirements + In https://sourceware.org/pipermail/binutils/2007-August/053261.html + (git commit 3dea8fca8b86) I disabled a then new linker feature that + removed empty PT_LOAD headers in cases where a user specified program + headers, and for objcopy. This can be a problem for objcopy/strip and + since objcopy operates on sections, any part of a PT_LOAD loading file + contents not covered by a section will be omitted anyway. + + PR 31208 + * elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load + as true to elf_modify_segment_map for objcopy/strip. + +2024-02-08 Tom Tromey + + Update TUI register window when the inferior exits + When the inferior exits, the TUI register window should clear. + + Fixing this was mostly a matter of sticking an assignment into + tui_inferior_exit. However, some changes to the register window + itself were also needed. + + While working on this, I realized that the TUI register window would + not work correctly when moving between frames of different + architectures. This patch attempts to fix this as well, though I have + no way to test it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600 + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename show_registers -> set_register_group + This renames a method on the TUI register window to reflect its real + purpose. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Return void from tui_show_frame_info + Nothing uses the tui_show_frame_info result any more, so change it to + return void. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove redundant check from tui_refresh_frame_and_register_information + tui_refresh_frame_and_register_information checks 'from_stack' in a + block that's already guarded by a 'from_stack' check. This patch + removes the redundant check. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove tui_refreshing_registers + The comment by tui_refreshing_registers mentions a hook that no longer + exists. However, maybe the comment is wrong. + + The code paths touching tui_refreshing_registers can only be called in two places: + + 1. From the before_prompt observer. This is only called when a prompt + is about to be displayed. + + 2. From the register_changed observer. This is only called when + value_assign changes a register value. + + From this it seems clear that the recursion case here cannot in fact + occur. This patch removes the variable. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_win::erase_data_content + There's only a single call to tui_data_win::erase_data_content now, so + remove the parameter and make it just render the "empty window" text. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove the TUI register window rerender overload + After these restructurings, it should be clear that the rerender + overload can be removed from the TUI register window. This is done by + moving a bit more logic from show_registers into update_register_data. + After this, update_register_data simply updates the internal state, + and rerender will write to the screen. All the actual rendering work + is done, ultimately, by display_registers_from. This split between + updating the model and rendering makes it clear that the recursive + case can't happen any longer. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify update_register_data + This changes update_register_data to always update the register data. + The idea here is that this is really only called when either the + desired register group changes, or when gdb transitions from not + having a frame to having a frame. + + show_registers is also simplified slightly to account for this. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Move scrollok call in register window + The register window calls scrollok each time a register is written to + the window. However, we only need to call this once, at the start of + display. (We could actually call it just once when the window is + made, but that would involve making another method virtual or adding a + new member -- both which I think are worse than this approach.) + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Change tui_register_info::visible to a method + tui_register_info::visible is redundant with the fact that y==0 means + that the register is not visible. This patch changes this member in + favor of having a single indication of the register's visibility -- a + method with the same name. This change makes it clear that + delete_data_content_windows is not needed, so this is removed as well. + + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename tui_data_item_window -> tui_register_info + tui_data_item_window used to hold a curses window, but we removed that + ages ago. Now it just holds information about a single register. + This patch renames the class to make it more clearly reflect its + meaning. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_window::show_register_group + This simplifies tui_data_window::show_register_group, renaming it as + well. The old method had two loops to iterate over all the registers + for the arch, but in the new scheme, the vector is set up when + switching groups, and then updates simply iterate over the vector. + + tui_data_item_window is made self-updating, which also clarifies the + code somewhat. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Minor C++ cleanups in tui-regs.c + This changes a couple of spots to use nullptr rather than 0, and + changes an int to a bool. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Use pop_back in tui_register_format + tui_register_format can use string::pop_back now. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Hannes Domani + + Allow calling of C++ methods from python + Currently it's not possible to call C++ methods from python. + Using this example: + ``` + class B + { + static int static_func (); + int arg0_func (); + int arg1_func (int arg1); + int arg2_func (int arg1, int arg2); + }; + + B *b_obj = new B; + ``` + + Trying to call B::static_func gives this error: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC). + Error while executing Python code. + ``` + + TYPE_CODE_METHOD was simply missing as a possible type in + valpy_call, now the same is possible: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + 1111 + ``` + + Note that it's necessary to explicitely add the this pointer + as the first argument in a call of non-static methods: + ``` + (gdb) py print(b_obj['arg0_func']()) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Too few arguments in function call. + Error while executing Python code. + (gdb) py print(b_obj['arg0_func'](b_obj)) + 198 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-02-08 Jens Remus + + gdb: Fix building with clang + This resolves the following clang++ error message: + + ../../gdb/symtab.c:4892:33: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses] + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ../../gdb/symtab.c:4892:33: note: add parentheses after the '!' to evaluate the comparison first + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + ../../gdb/symtab.c:4892:33: note: add parentheses around left hand side expression to silence this warning + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + + Bug: https://sourceware.org/PR31328 + +2024-02-08 H.J. Lu + + x86-64: Add R_X86_64_CODE_6_GOTTPOFF + For + + add %reg1, name@gottpoff(%rip), %reg2 + + and + + add name@gottpoff(%rip), %reg1, %reg2 + + add + + #define R_X86_64_CODE_6_GOTTPOFF 50 + + if the instruction starts at 6 bytes before the relocation offset. + They are similar to R_X86_64_GOTTPOFF. Linker can covert GOTTPOFF to + + add $name@tpoff, %reg1, %reg2 + + Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate + R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX, + R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and + R_X86_64_CODE_6_GOTTPOFF. + + NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in + md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this + stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF + or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix. + + 5 relocations: + + #define R_X86_64_CODE_5_GOTPCRELX 46 + #define R_X86_64_CODE_5_GOTTPOFF 47 + #define R_X86_64_CODE_5_GOTPC32_TLSDESC 48 + #define R_X86_64_CODE_6_GOTPCRELX 49 + #define R_X86_64_CODE_6_GOTPC32_TLSDESC 51 + + are added for completeness and they are unused. + + bfd/ + + * elf64-x86-64.c (x86_64_elf_howto_table): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (R_X86_64_standard): Updated. + (x86_64_reloc_map): Add R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and + R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_check_tls_transition): Handle + R_X86_64_CODE_6_GOTTPOFF. + (elf_x86_64_tls_transition): Likewise. + (elf_x86_64_scan_relocs): Handle R_X86_64_CODE_6_GOTTPOFF. + Issue an error for R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_relocate_section): Handle R_X86_64_CODE_6_GOTTPOFF. + * reloc.c (bfd_reloc_code_real): Add + BFD_RELOC_X86_64_CODE_5_GOTPCRELX, + BFD_RELOC_X86_64_CODE_5_GOTTPOFF, + BFD_RELOC_X86_64_CODE_5_GOTPC32_TLSDESC, + BFD_RELOC_X86_64_CODE_6_GOTPCRELX, + BFD_RELOC_X86_64_CODE_6_GOTTPOFF and + BFD_RELOC_X86_64_CODE_6_GOTPC32_TLSDESC. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + + elfcpp/ + + * x86_64.h (R_X86_64_CODE_5_GOTPCRELX): New. + (R_X86_64_CODE_5_GOTTPOFF): Likewise. + (R_X86_64_CODE_5_GOTPC32_TLSDESC): Likewise. + (R_X86_64_CODE_6_GOTPCRELX): Likewise. + (R_X86_64_CODE_6_GOTTPOFF): Likewise. + (R_X86_64_CODE_6_GOTPC32_TLSDESC): Likewise. + + gas/ + + * config/tc-i386.c (tc_i386_fix_adjustable): Handle + BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (md_assemble): Don't check BFD_RELOC_X86_64_CODE_4_GOTTPOFF. + Allow "add %reg1, foo@gottpoff(%rip), %reg2". + (output_disp): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. Rewrite + setting fx_tcbitX bits for BFD_RELOC_X86_64_GOTTPOFF, + BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL. + (md_apply_fix): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (i386_validate_fix): Rewrite fx_tcbitX bit checking for + BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and + BFD_RELOC_32_PCREL. + (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle + R_X86_64_CODE_6_GOTTPOFF. + (Target_x86_64::Scan::get_reference_flags): Likewise. + (Target_x86_64::Scan::local): Likewise. + (Target_x86_64::Scan::global): Likewise. + (Target_x86_64::Relocate::relocate): Likewise. + (Target_x86_64::Relocate::relocate_tls): Likewise. + (Target_x86_64::Relocate::tls_ie_to_le): Handle. + R_X86_64_CODE_6_GOTTPOFF. + * testsuite/x86_64_ie_to_le.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + include/ + + * elf/x86-64.h (elf_x86_64_reloc_type): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-02-08 Richard W.M. Jones + + PR 31283 windmc: Parse input correctly on big endian hosts + On big endian hosts (eg. s390x) the windmc tool fails to parse even + trivial files: + + $ cat test.mc + ; + $ ./binutils/windmc ./test.mc + In test.mc at line 1: parser: syntax error. + In test.mc at line 1: fatal: syntax error. + + The tool starts by reading the input as Windows CP1252 and then + converting it internally into an array of UTF-16LE, which it then + processes as an array of unsigned short (typedef unichar). + + There are lots of ways this is wrong, but in the specific case of big + endian machines the little endian pairs of bytes are byte-swapped. + + For example, the ';' character in the input above is first converted + to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to + unsigned short. On a big endian machine the first unichar appears to + be 0x3b00. The lexer is unable to recognize this as the comment + character ((unichar)';') and so parsing fails. + + The simple fix is to convert the input to UTF-16BE on big endian + machines (and do the reverse conversion when writing the output). + + Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283 + +2024-02-08 GDB Administrator + + Automatic date update in version.in + +2024-02-07 Hannes Domani + + Raise exception if ambiguous name is used in gdb.parameter + Currently gdb.parameter doesn't raise an exception if an + ambiguous name is used, it instead returns the value of the + last partly matching parameter: + ``` + (gdb) show print sym + Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading. + (gdb) show print symbol-loading + Printing of symbol loading messages is "full". + (gdb) py print(gdb.parameter("print sym")) + full + ``` + + It's because lookup_cmd_composition_1 tries to detect + ambigous names by checking the return value of find_cmd + for CMD_LIST_AMBIGUOUS, which never happens, since only + lookup_cmd_1 returns CMD_LIST_AMBIGUOUS. + Instead the nfound argument contains the number of found + matches. + + By using it instead, and by setting *CMD to the special value + CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show + the appropriate error message: + ``` + (gdb) py print(gdb.parameter("print sym")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print sym' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol")) + True + (gdb) py print(gdb.parameter("print symbol-")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print symbol-' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol-load")) + full + ``` + + Since the document command also uses lookup_cmd_composition, it needed + to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an + "Ambiguous command" error message in this case. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639 + Approved-By: Tom Tromey + +2024-02-07 Hannes Domani + + Fix raw-frame-arguments in combination with frame-filters + Currently, if frame-filters are active, raw-values is used instead of + raw-frame-arguments to decide if a pretty-printer should be invoked for + frame arguments in a backtrace. + + In this example, "super struct" is the output of the pretty-printer: + + (gdb) disable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + If no frame-filter is active, then the raw-values print option does not + affect the backtrace output: + + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + + Instead, the raw-frame-arguments option disables the pretty-printer in the + backtrace: + + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + But if a frame-filter is active, the same rules don't apply. + The option raw-frame-arguments is ignored, but raw-values decides if the + pretty-printer is used: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which + is then used in the frame-filter to override the raw flag in enumerate_args. + + Then the output is the same if a frame-filter is active, the pretty-printer + for backtraces is only disabled with the raw-frame-arguments option: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + Co-Authored-By: Andrew Burgess + Approved-By: Tom Tromey + +2024-02-07 Ciaran Woodward + + Remove use of scoped_restore_tmpl from scoped_restore_warning_hook + The warning_hook_handler function pointer takes va_list as + an argument, which on some platforms (mingw64) includes some + attributes. Attributes get ignored in template arguments. + This led to the compiler warning: + + error: ignoring attributes on template argument 'warning_hook_handler' {aka 'void (*)(const char*, char*)'} [-Werror=ignored-attributes] + 387 | scoped_restore_tmpl m_save; + | ^ + + By manually implementing the save/restore behaviour, rather + than using the helper template, this warning is fixed. + + Approved-By: Tom Tromey + +2024-02-07 Alan Modra + + asan: NULL dereference in _bfd_mips_final_write_processing + Fuzzed object files can easily have unexpected section names. We + don't want to segfault on objcopy of any file accepted by the mips + object_p functions. For objcopy, an assertion that "sec" is non-NULL + followed by deferencing "sec" is wrong. So too is asserting that the + section name string starts with a particular prefix, and then blithely + accessing past the assumed prefix. + + * elfxx-mips.c (_bfd_mips_final_write_processing): Replace + assertions with conditionals. Don't bother testing for name + non-NULL. + +2024-02-07 Alan Modra + + memory leak in objdump disassemble_section + * objdump.c (disassemble_section): Free rel_ppstart on error path. + +2024-02-07 Indu Bhagat + + gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly + PR gas/31326 + SCFI must handle non QWORD ALU with imm and MOV ops correctly + + As per the x86 ISA manual: + - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit + result in the destination general-purpose register. + - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The + upper 56 bits or 48 bits (respectively) of the destination + general-purpose register are not modified by the operation. + + Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have + implications on SCFI. SCFI/ginsn machinery does not track operation size + in the ginsn representation. But given that these sub-QWORD ops update + only a portion of a 64-bit destination register, for SCFI purposes, this + needs to be deemed as an untraceable update (when the destination is + REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected + for stack management, but the SCFI machinery must behave correctly, when + such ops are indeed present. + + As mentioned earlier, ginsn representation does not carry operation size + information. To resolve the issue raised in PR gas/31326, an option is + to force the generation of GINSN_TYPE_OTHER for all cases when there is + a 8/16/32 bit op. But this may dilute the utility of ginsn for other + use-cases, when they pop up in future. + + The current approach is less disruptive than above in that it generates + GINSN_TYPE_OTHER for all cases only when: + - there is a 8/16/32 bit op, and + - the 64-bit op is otherwise traceable. + + In other words this means: + - For add/sub ops where dest is reg and src is reg/mem: these always + make dest reg untraceable; So, the current handling is unchanged. We + simply skip detecting 8/16/32-bit ops. + - An x86 pop instruction is translated to a load ginsn followed by a stack + increment add op. A load op always makes dest reg untraceable. + Hence, if the pop instruction is sub-QWORD, we continue to (skip + detecting 8/16/32-bit op, and) generate the load instruction as usual. + This means that if input asm does have save and restore of unequal sized + registers, gas/SCFI will not detect nor warn. + - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated + when a 8/16/32-bit op is seen. + + gas/ + PR gas/31326 + * config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code + comment. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early. + (x86_ginsn_move): Likewise. + (x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in + opcode_space SPACE_BASE) about skipped handling. + + gas/testsuite/: + PR gas/31326 + * gas/scfi/x86_64/ginsn-add-1.l: Update. + * gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of + add to invoke and test the ginsn_dw2_regnum code path. + +2024-02-07 GDB Administrator + + Automatic date update in version.in + +2024-02-06 Simon Marchi + + gdb: remove core_bfd macro + The core_bfd macro hides a use of current_program_space. Remove it, so + that we have the opportunity to get the program space from the context, + if possible. I guess that the macro was introduced at some point to + replace a global variable of the same name without changing all the + uses. + + Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 + Approved-By: Tom Tromey + +2024-02-06 H.J. Lu + + x86: Warn .insn instruction with length > 15 bytes + Change .insn instruction with length > 15 bytes from error to warning. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue a warning when .insn + instruction length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized64.s: Add a test for .insn + * testsuite/gas/i386/oversized64.l: Updated. + +2024-02-06 Tiezhu Yang + + gdb: LoongArch: Implement the get_syscall_number gdbarch method + In the current code, the feature 'catch syscall' is not supported + on LoongArch, implement the "get_syscall_number" gdbarch method to + get the system call number from the register a7. + + Without this patch: + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architecture yet. + +2024-02-06 Feiyang Chen + + gdb: LoongArch: Add LBT extension support + Loongson Binary Translation (LBT) is used to accelerate binary + translation, which contains 4 scratch registers (scr0 to scr3), + x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This + patch support gdb to fetch/store these registers. + + Signed-off-by: Feiyang Chen # Framework + Signed-off-by: Binbin Zhou # Detail Optimizes + Signed-off-by: Hui Li # Error Fixes + +2024-02-06 Hui Li + + gdb: LoongArch: Add vector extensions support + Add LoongArch's vector extensions support, which including + 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX + (i.e., Loongson Advanced SIMD eXtension). This patch support + gdb to fetch/store vector registers. + +2024-02-06 Alan Modra + + Link x86-64 mark-plt-1.so with --no-as-needed + Fixes + FAIL: Build mark-plt-1.so + where gcc is built with default --as-needed. + + * testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass + --no-as-needed. + +2024-02-06 GDB Administrator + + Automatic date update in version.in + +2024-02-05 Simon Marchi + + gdb: rename target_so_ops to solib_ops + I don't like the name `target_so_ops`, because: + + - The name `target` is so overloaded, and in this case it's not even + related to target_ops or anything else called "target". + - We do have an implementation that actually fetches solibs from the + target (solib_target_so_op in solib-target.c), so it's confusing for + the "base class" to be called target_something as well. + + Rename to solib_ops. + + Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f + Approved-By: Tom Tromey + +2024-02-05 Simon Marchi + + gdb: rename struct shobj -> struct solib + `struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f + ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would + have been a better name. We have solib.c, the implementations in + solib-*.c, many functions with solib in their name, the solib_loaded / + solib_unloaded observables, etc. + + Rename shobj to solib. + + Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d + Approved-By: Tom Tromey + +2024-02-05 Tom Tromey + + Remove remnants of partial DIEs from DWARF reader + When rewriting the DWARF scanner, I forgot to remove + dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies. This patch + corrects the oversight and fixes up a couple other spots that mention + partial DIEs, which no longer exist. + + Approved-By: Tom de Vries + +2024-02-05 Tom Tromey + + Avoid an allocation in attr_to_dynamic_prop + I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no + allocation is required. This patch stack-allocates the object + instead. + + Reviewed-By: Tom de Vries + +2024-02-05 Thiago Jung Bauermann + + Fix disabling of year 2038 support on 32-bit hosts by default + Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by + default") fixed a mismatch between 64-bit time_t in GDB and system headers + and 32-bit time_t in BFD. + + However, since commit 862776f26a59 ("Finalized intl-update patches") + gnulib's year 2038 support has been accidentally re-enabled — causing + problems for 32-bit hosts again. The commit split baseargs into + {h,b}baseargs, but this hasn't been done for the code that handles + --disable-year2038. + + This patch restores the intended behaviour. With this change, the number + of unexpected core files goes from 18 to 4. + + Tested on armv8l-linux-gnueabihf. + + Approved-By: Luis Machado + +2024-02-05 Tom Tromey + + Handling of arrays with optimized-out bounds + In Ada, sometimes the compiler must emit array bounds by referencing + an artificial variable that's created for this purpose. However, with + optimization enabled, these variables can be optimized away. + + Currently this can result in displays like: + + (gdb) print mumble + $1 = (warning: unable to get bounds of array, assuming null array + ) + + This patch changes this to report that the array is optimized-out, + instead, which is closer to the truth, and more generally useful. For + example, Python pretty-printers can now recognize this situation. + + In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT + enumerator and changed one place to use it. Reusing the "unknown" + state wouldn't work properly, because in C it is normal for array + bounds to be unknown. + +2024-02-05 Tom de Vries + + [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache + On arm-linux the linaro CI occasionally reports: + ... + (gdb) up 10 + #4 0x0001b864 in pthread_join () + (gdb) FAIL: gdb.threads/staticthreads.exp: up 10 + ... + while this is expected: + ... + (gdb) up 10 + #3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76 + 76 pthread_join (thread, NULL); + (gdb) PASS: gdb.threads/staticthreads.exp: up 10 + ... + + Thiago investigated the problem, and using valgrind found an invalid read in + arm_exidx_fill_cache. + + The problem happens as follows: + - an objfile and corresponding per_bfd are allocated + - some memory is allocated in arm_exidx_new_objfile using + objfile->objfile_obstack, for the "exception table entry cache". + - a symbol reread is triggered, and the objfile, including the + objfile_obstack, is destroyed + - a new objfile is allocated, using the same per_bfd + - again arm_exidx_new_objfile is called, but since the same per_bfd is used, + it doesn't allocate any new memory for the "exception table entry cache". + - the "exception table entry cache" is accessed by arm_exidx_fill_cache, + and we have a use-after-free. + + This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling + information per-bfd instead of per-objfile"), which changed the "exception + table entry cache" from per-objfile to per-bfd, but failed to update the + obstack_alloc. + + Fix this by using objfile->per_bfd->storage_obstack instead of + objfile->objfile_obstack. + + I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch + fixes it. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR tdep/31254 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254 + +2024-02-05 GDB Administrator + + Automatic date update in version.in + +2024-02-04 Tom Tromey + + Use reference result of emplace_back + Starting with C++17, emplace_back returns a reference to the new + object. This patch changes code that uses emplace_back followed by a + call to back() to simply use this reference instead. + + Approved-By: Simon Marchi + +2024-02-04 Xi Ruoyao + + LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab + When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a + TLS symbol and we should set its type to TLS in the symtab. Otherwise + when building Perl with gcc-14 -flto, we get: + + /usr/bin/ld: PL_current_context: TLS definition in + ./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference + in ./miniperl.ltrans1.ltrans.o + + A minimal reproducer: + + $ cat t1.s + .section .tbss + .globl x + x: .word 0 + $ cat t2.s + f: + lu12i.w $a0, %le_hi20_r(x) + add.d $a0, $a0, $tp, %le_add_r(x) + li.w $a1, 1 + st.w $a1, $a0, %le_lo12_r(x) + $ gas/as-new t1.s -o t1.o + $ gas/as-new t2.s -o t2.o + $ ld/ld-new t1.o t2.o + ld/ld-new: x: TLS definition in t1.o section .tbss mismatches + non-TLS reference in t2.o + + Unfortunately this was undetected before Binutils-2.42 release because + GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a + TLS LE definition and its reference in two different translation units. + So this fix should be backported to Binutils-2.42 branch too. + +2024-02-04 GDB Administrator + + Automatic date update in version.in + +2024-02-03 GDB Administrator + + Automatic date update in version.in + +2024-02-02 Andrew Burgess + + gdb: attach to a process when the executable has been deleted + Bug PR gdb/28313 describes attaching to a process when the executable + has been deleted. The bug is for S390 and describes how a user sees a + message 'PC not saved'. + + On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but + instead I see this: + + (gdb) attach 901877 + Attaching to process 901877 + No executable file now. + warning: Could not load vsyscall page because no executable was specified + 0x00007fa9d9c121e7 in ?? () + (gdb) bt + #0 0x00007fa9d9c121e7 in ?? () + #1 0x00007fa9d9c1211e in ?? () + #2 0x0000000000000007 in ?? () + #3 0x000000002dc8b18d in ?? () + #4 0x0000000000000000 in ?? () + (gdb) + + Notice that the addresses in the backtrace don't seem right, quickly + heading to 0x7 and finally ending at 0x0. + + What's going on, in both the s390 case and the x86-64 case is that the + architecture's prologue scanner is going wrong and causing the stack + unwinding to fail. + + The prologue scanner goes wrong because GDB has no unwind information. + + And GDB has no unwind information because, of course, the executable + has been deleted. + + Notice in the example session above we get this line in the output: + + No executable file now. + + which indicates that GDB failed to find an executable to debug. + + For GNU/Linux when GDB tries to find an executable for a given pid we + end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c. + Within this function we call `readlink` on /proc/PID/exe to find the + path of the actual executable. + + If the `readlink` call fails then we already fallback on using + /proc/PID/exe as the path to the executable to debug. + + However, when the executable has been deleted the `readlink` call + doesn't fail, but the path that is returned points to a non-existent + file. + + I propose that we add an `access` call to linux_proc_pid_to_exec_file + to check that the target file exists and can be read. If the target + can't be read then we should fall back to /proc/PID/exe (assuming that + /proc/PID/exe can be read). + + Now on x86-64 the output looks like this: + + (gdb) attach 901877 + Attaching to process 901877 + Reading symbols from /proc/901877/exe... + Reading symbols from /lib64/libc.so.6... + (No debugging symbols found in /lib64/libc.so.6) + Reading symbols from /lib64/ld-linux-x86-64.so.2... + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) + 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + (gdb) bt + #0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + #1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6 + #2 0x000000000040117e in spin_forever () at attach-test.c:17 + #3 0x0000000000401198 in main () at attach-test.c:24 + (gdb) + + which is much better. + + I've also tagged the bug PR gdb/29782 which concerns the test + gdb.server/connect-with-no-symbol-file.exp. After making this change, + when running gdb.server/connect-with-no-symbol-file.exp GDB would now + pick up the /proc/PID/exe file as the executable in some cases. + + As GDB is not restarted for the multiple iterations of this test + GDB (or rather BFD) would given a warning/error like: + + (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect + set sysroot target: + BFD: reopening /proc/3283001/exe: No such file or directory + (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot + + What's happening is that an executable found for an earlier iteration + of the test is still registered for the inferior when we are setting + up for a second iteration of the test. When the sysroot changes, if + there's an executable registered GDB tries to reopen it, but in this + case the file has disappeared (the previous inferior has exited by + this point). + + I did think about maybe, when the executable is /proc/PID/exe, we + should auto-delete the file from the inferior. But in the end I + thought this was a bad idea. Not only would this require a lot of + special code in GDB just to support this edge case: we'd need to track + if the exe file name came from /proc and should be auto-deleted, or + we'd need target specific code to check if a path should be + auto-deleted..... + + ... in addition, we'd still want to warn the user when we auto-deleted + the file from the inferior, otherwise they might be surprised to find + their inferior suddenly has no executable attached, so we wouldn't + actually reduce the number of warnings the user sees. + + So in the end I figured that the best solution is to just update the + test to avoid the warning. This is easily done by manually removing + the executable from the inferior once each iteration of the test has + completed. + + Now, in bug PR gdb/29782 GDB is clearly managing to pick up an + executable from the NFS cache somehow. I guess what's happening is + that when the original file is deleted /proc/PID/exe is actually + pointing to a file in the NFS cache which is only deleted at some + later point, and so when GDB starts up we do manage to associate a + file with the inferior, this results in the same message being emitted + from BFD as I was seeing. The fix included in this commit should also + fix that bug. + + One final note: On x86-64 GNU/Linux, the + gdb.server/connect-with-no-symbol-file.exp test will produce 2 core + files. This is due to a bug in gdbserver that is nothing to do with + this test. These core files are created before and after this + commit. I am working on a fix for the gdbserver issue, but will post + that separately. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782 + + Approved-By: Tom Tromey + +2024-02-02 H.J. Lu + + x86: Disallow instructions with length > 15 bytes + It is a hard error when an instruction length exceeds the limit of 15 + bytes: + + [hjl@gnu-cfl-3 tmp]$ cat x.s + .text + xacquire lock addq $0x11223344, %fs:(,%eax) + [hjl@gnu-cfl-3 tmp]$ gcc -c x.s + x.s: Assembler messages: + x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw x.o + + x.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 xacquire lock (bad) + f: 11 .byte 0x11 + [hjl@gnu-cfl-3 tmp]$ + + and + + [hjl@gnu-cfl-3 tmp]$ cat z.s + addq $0xe0, %fs:0, %rdx + [hjl@gnu-cfl-3 tmp]$ as -o z.o z.s + z.s: Assembler messages: + z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw z.o + + z.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 (bad) + ... + [hjl@gnu-cfl-3 pr31323]$ + + Instructions with length > 15 bytes are always invalid. It is quite easy + to generate invalid instructions with AVX now. We should issue an error + when instruction length exceeds the limit of 15 bytes. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue an error when instruction + length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized16.l: Updated. + * testsuite/gas/i386/oversized64.l: Likewise. + * testsuite/gas/i386/x86-64-apx-inval.l: New file. + * testsuite/gas/i386/x86-64-apx-inval.s: Likewise. + +2024-02-02 Nils-Christian Kempke + + gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers + For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like + + <2><17d>: Abbrev Number: 22 (DW_TAG_variable) + <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr + <184> DW_AT_type : <0x214> + ... + <1><219>: Abbrev Number: 27 (DW_TAG_array_type) + <21a> DW_AT_type : <0x10e> + <216> DW_AT_associated : ... + + The 'pointer property' in Fortran is implicitly modeled by adding a + DW_AT_associated to the type of the variable (see also the + DW_AT_associated description in DWARF 5). A Fortran pointer is more + than an address and thus different from a C pointer. It is a + self contained type having additional fields such as, e.g., the rank of + its underlying array. This motivates the intended DWARF modeling of + Fortran pointers via the DW_AT_associated attribute. + + This patch adds support for the sizeof intrinsic by simply dereferencing + pointer types when encountered during a sizeof evaluation. + + The patch also adds a test for the sizeof intrinsic which was not tested + before. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Bernhard Heckel + + gdb, types: Resolve pointer types dynamically + This commit allows pointers to be dynamic types (on the outmost + level). Similar to references, a pointer is considered a dynamic type + if its target type is a dynamic type and it is on the outmost level. + Also this commit removes the redundant code inside function + "value_check_printable" for handling of DW_AT_associated type. + + The pointer resolution follows the one of references. + + This change generally makes the GDB output more verbose. We are able to + print more details about a pointer's target like the dimension of an array. + + In Fortran, if we have a pointer to a dynamic type + + type buffer + real, dimension(:), pointer :: ptr + end type buffer + type(buffer), pointer :: buffer_ptr + allocate (buffer_ptr) + allocate (buffer_ptr%ptr (5)) + + which then gets allocated, we now resolve the dynamic type before + printing the pointer's type: + + Before: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(:) + End Type buffer ) + + After: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(5) + End Type buffer ) + + Similarly in C++ we can dynamically resolve e.g. pointers to arrays: + + int len = 3; + int arr[len]; + int (*ptr)[len]; + int ptr = &arr; + + Once the pointer is assigned one gets: + + Before: + + (gdb) p ptr + $1 = (int (*)[variable length]) 0x123456 + (gdb) ptype ptr + type = int (*)[variable length] + + After: + + (gdb) p ptr + $1 = (int (*)[3]) 0x123456 + (gdb) ptype ptr + type = int (*)[3] + + For more examples see the modified/added test cases. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Ijaz, Abdul B + + gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp + Improve indentation in the test file by replacing 10 spaces at second level + with 4 spaces. This helps to update the test using the right indentation + in future. + + Approved-By: Tom Tromey + +2024-02-02 Jan Beulich + + x86: move Q-suffix-to-REX.W translation logic + By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a + part of another conditional there. While moving, also drop a pointless + check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily + have both been 64-bit ones. + +2024-02-02 Jan Beulich + + x86: actually implement .noopt + For quite some time we've had support for -O command line options. With + that ignoring at least .noopt isn't really a good idea. + + Re-purpose the optimize-3 test for testing this directive's effect as + well. + + As to the doc addition - this uses the same text as is there for the + {nooptimize} pseudo-prefix, despite me not being convinced of the "size" + part being fully accurate there (and hence also here). + +2024-02-02 Sandra Loosemore + + MAINTAINERS: Update my e-mail address. + +2024-02-02 GDB Administrator + + Automatic date update in version.in + +2024-02-01 Indu Bhagat + + gas: x86: ginsn: adjust ginsns for certain lea ops + A review comment on the SCFI V4 series was to handle ginsn creation for + certain lea opcodes more precisely. + + Specifically, we should preferably handle the following two cases of lea + opcodes similarly: + - #1 lea with "index register and scale factor of 1, but no base + register", + - #2 lea with "no index register, but base register present". + + Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the + case of #1 above. For #2, however, the lea insn is translated to either + a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate + for displacement is non-zero or not respectively. + + Change the handling in x86_ginsn_lea so that both of the above lea + manifestations are handled similarly. + + While at it, remove the code paths creating GINSN_TYPE_OTHER altogether + from the function. It makes sense to piggy back on the + x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the + destination register is interesting. This was also suggested in one of + the previous review rounds; the other functions already follow that + model, so this keeps functions symmetrical looking. + + gas/ + * gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with + no base register similar to the case of no index register. Remove + creation of GINSN_TYPE_OTHER from the function. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-lea-1.l: New test. + * gas/scfi/x86_64/ginsn-lea-1.s: Likewise. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-02-01 Vladimir Mezentsev + + gprofng: Remove unused macros + gprofng/ChangeLog + 2024-02-01 Vladimir Mezentsev + + * common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION. + * common/hwctable.c: Remove DBG_LT* macros. + * libcollector/envmgmt.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/iolib.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/memmgr.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/tsd.c: Likewise. + * libcollector/unwind.c: Likewise. + +2024-02-01 Tom Tromey + + Fix "objstack" typo + I noticed some comments that mentions "objstack". The type is + actually "obstack". This patch fixes the typos. + +2024-02-01 Tom Tromey + + Rename SEARCH_ALL + The constant SEARCH_ALL conflicts with a define in a Windows header. + This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the + conflict. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307 + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix some duplicate test names in gdb.trace/ + This commit fixes some of the easier duplicate test names in the + gdb.trace/ directory. + + All of these duplicates are resolved by either given tests a name, or + by extended the existing name to make it more descriptive. + + There should be no change in what is tested after this commit. + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp + Fix some duplicate test names in gdb.base/cond-eval-mode.exp when + running with native-gdbserver or native-extended-gdbserver board + files. + + I've just added some 'with_test_prefix' blocks to make the test names + unique, there should be no change in what is tested after this commit. + +2024-02-01 Aditya Vidyadhar Kamath + + Fix AIX build break. + A recent commit broke AIX build. The thread_local type defined functions + were being considered a weak symbol and hence while creating the binary these + symbols were not visible. + + This patch is a fix for the same. + +2024-02-01 GDB Administrator + + Automatic date update in version.in + +2024-01-31 Simon Marchi + + gdb: remove some unnecessary frame_info_ptr resets + This code was probably needed before we had reinflatable + frame_info_ptrs, it's not necessary anymore. + + Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5 + Approved-By: Tom Tromey + +2024-01-31 Nick Clifton + + Mention support for AMD/znver5 in GAS + +2024-01-31 Georg-Johann Lay + + PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. + Supply these symbols as computed by the linker scripts, even when there are weak definitions. + PR 31124 + * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE. + +2024-01-31 GDB Administrator + + Automatic date update in version.in + +2024-01-30 Tom Tromey + + Really fix Windows gdbserver segment registers + My earlier attempt to mask the segment registers in gdbserver for + Windows introduced some bugs. That patch is here: + + https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html + + The problem turned out to be that these fields in the Windows + 'CONTEXT' type are just 16 bits, so while masking the values on read + is fine, writing the truncated values back then causes zeros to be + written to some subsequent field. + + This patch cleans this up by arranging never to write too much data to + a field. + + I also noticed that two register numbers here were never updated for + the 64-bit port. This patch fixes this as well, and renames the "FCS" + register to follow gdb. + + Finally, this patch applies the same treatment to windows-nat.c. + + Reviewed-by: John Baldwin + +2024-01-30 GDB Administrator + + Automatic date update in version.in + +2024-01-29 Alan Modra + + PR31314, chew crashing on use of uninitialized value + The "drop" call in wrap_comment already increments pc. Defining DOCDD + in proto.str is a warning fix. + + PR 31314 + * chew.c (wrap_comment): Don't increment pc. + * proto.str (DOCDD): Define. + +2024-01-29 Jose E. Marchesi + + sim: bpf: remove support for ldinddw and ldabsdw instructions + This patch removes support for the two instructions above from the GNU + simulator, including the corresponding tests. These instructions do + not really exist in BPF and are not recognized as such by the kernel + verifier. This has now been pointed out during the standardization of + the BPF ISA. + +2024-01-29 Lancelot SIX + + gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.def + Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the + sym-domains.def file has been introduced, and requires the user to + define the DOMAIN(x) macro. + + On older systems (centos-7 with glibc-2.17 for example), this DOMAIN + macro conflicts with another macro defined in /usr/include/math.h. + + Fix this conflict by changing sym-domains.def to use a macro named + SYM_DOMAIN instead of DOMAIN. + + Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3 + Approved-By: Tom Tromey + +2024-01-29 Jose E. Marchesi + + bfd: restore Threading menu entry in bfd.texi + I mistakenly vandalized bfd.texi in the commit + 0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the + manual menu. This commit reverts that thunk. + +2024-01-29 Jose E. Marchesi + + bpf: there is no ldinddw nor ldabsdw instructions + There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW. + For some reason we were (incorrectly) supporting these. This patch + updates the opcodes so the instructions get removed and modifies the + GAS manual and testsuite accordingly. + + See discussion at + https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev + + Tested in bpf-uknonwn-none target, x86-64-linux-gnu host. + + include/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + opcodes/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + gas/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit + load instruction. + (BPF Instructions): There is no absolute 64-bit load instruction. + * testsuite/gas/bpf/mem.s: Update test accordingly. + * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-be.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.s: Likewise. + * testsuite/gas/bpf/mem.d: Likewise. + * testsuite/gas/bpf/mem.s: Likewise. + +2024-01-29 Nick Clifton + + Update release making documentation after 2.42 release + + Remove support for the beos file format + +2024-01-29 Hannes Domani + + Fix backtrace limit stopping on inline frame + If you have set up a backtrace limit, and the backtrace stops + because of this in an inline frame with arguments, you get an + assertion failure: + ``` + (gdb) bt + (gdb) set backtrace limit 2 + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed. + ``` + + And if this one is fixed, there is another one as well: + ``` + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed. + ``` + + The reason for both of them is this kind of loop: + ``` + while (get_frame_type (frame) == INLINE_FRAME) + frame = get_prev_frame (frame); + ``` + Since get_prev_frame respects the backtrace limit, it will return + NULL, and from there on you can't continue. + This changes these loops to use get_prev_frame_always instead, so + you always get a non-inline frame in the end. + + With this backtrace works: + ``` + (gdb) bt + (gdb) + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865 + Approved-By: Andrew Burgess + +2024-01-29 Nick Clifton + + Updated French translations for GOLD and LD + +2024-01-29 GDB Administrator + + Automatic date update in version.in + +2024-01-28 Tom Tromey + + Document new Python and Guile constants + This documents the new Python and Guile constants introduced earlier + in this series. + + Approved-By: Eli Zaretskii + +2024-01-28 Tom Tromey + + Refine search in cp_search_static_and_baseclasses + This changes cp_search_static_and_baseclasses to only search for + types, functions, and modules. The latter two cases were discovered + by regression testing. I found it somewhat surprising the Fortran + name lookup ends up in this code, but did not attempt to change this. + + Only search for functions in rust_structop::evaluate_funcall + This changes rust_structop::evaluate_funcall to only search for + functions. + +2024-01-28 Tom Tromey + + Only search types in lookup_typename + This changes lookup_typename to only look for types. The check for + LOC_TYPEDEF can now also be removed, because only types will appear in + TYPE_DOMAIN. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24870 + +2024-01-28 Tom Tromey + + Only search types in cp_lookup_rtti_type + This changes cp_lookup_rtti_type to only search for types -- not + functions or variables. Due to the symbol-matching hack, this could + just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also + I hold on to some hope that perhaps the hack can someday be removed. + + Use a function-domain search in inside_main_func + This changes inside_main_func to search only for functions. + + Only look for functions in expand_symtabs_for_function + This changes expand_symtabs_for_function to only look in the function + domain. + + Only search for "main" as a function + This changes find_main_name to restrict its search to the function + domain. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in linespec.c + This simplifies some symbol searches in linespec.c. In particular, + two separate searches here can now be combined into one, due to the + new use of flags. + + Arguably the STRUCT_DOMAIN searches should perhaps not even be done. + Only C really has these, and C doesn't have member functions. + However, it seems relatively harmless -- and clearly compatible -- to + leave this in. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in Ada code + This changes some of the Ada code to simplify symbol searches. For + example, if a function is being looked for, the search is narrowed to + use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a + search of the "struct" domain is removed, because Ada does not have a + tag domain. + +2024-01-28 Tom Tromey + + Use the new symbol domains + This patch changes the DWARF reader to use the new symbol domains. It + also adjusts many bits of associated code to adapt to this change. + + The non-DWARF readers are updated on a best-effort basis. This is + somewhat simpler since most of them only support C and C++. I have no + way to test a few of these. + + I went back and forth a few times on how to handle the "tag" + situation. The basic problem is that C has a special namespace for + tags, which is separate from the type namespace. Other languages + don't do this. So, the question is, should a DW_TAG_structure_type + end up in the tag domain, or the type domain, or should it be + language-dependent? + + I settled on making it language-dependent using a thought experiment. + Suppose there was a Rust compiler that only emitted nameless + DW_TAG_structure_type objects, and specified all structure type names + using DW_TAG_typedef. This DWARF would be correct, in that it + faithfully represents the source language -- but would not work with a + purely struct-domain implementation in gdb. Therefore gdb would be + wrong. + + Now, this approach is a little tricky for C++, which uses tags but + also enters a typedef for them. I notice that some other readers -- + like stabsread -- actually emit a typedef symbol as well. And, I + think this is a reasonable approach. It uses more memory, but it + makes the internals simpler. However, DWARF never did this for + whatever reason, and so in the interest of keeping the series slightly + shorter, I've left some C++-specific hacks in place here. + + Note that this patch includes language_minimal as a language that uses + tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, + which doesn't specify the language for a type unit. Arguably this + test case is wrong. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164 + +2024-01-28 Tom Tromey + + Remove old symbol_matches_domain + Nothing calls the variant of symbol_matches_domain that accepts a + domain_enum for searching, so this patch removes it and the + corresponding symbol::matches. + + Remove some obsolete Python constants + The Python code has exported some constants, but they are no longer + documented, and were never useful. This patch removes them. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_symbol et al + This changes lookup_symbol and associated APIs to accept + domain_search_flags rather than a domain_enum. + + Note that this introduces some new constants to Python and Guile. I + chose to break out the documentation patch for this, because the + internals here do not change until a later patch, and it seemed + simpler to patch the docs just once, rather than twice. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_global_symbol_language + This changes quick_symbol_functions::lookup_global_symbol_language to + accept domain_search_flags rather than just a domain_enum, and fixes + up the fallout. + + To avoid introducing any regressions, any code passing VAR_DOMAIN now + uses SEARCH_VFT. + + That is, no visible changes should result from this patch. However, + it sets the stage to refine some searches later on. + +2024-01-28 Tom Tromey + + Introduce "scripting" domains + The Python and Guile code exposed the internal domain constants both + as attributes of symbols and as values to pass to lookup functions. + + Now, perfect backward compatibility here can't be achieved: some + symbols are going to have domain changes by the end of this series. + However, it seemed to me that we can preserve lookups using the basic + domain values. + + This patch implements this by exporting the "or"-able search constants + with an extra bit set. Then it introduces some functions to convert + such constants to domain_search_flags. This will be used by the + Python and Guile code, so that both old- and new-style lookups will + work properly; and while preserving the idea that the domain constants + can be compared to a symbol's domain. + +2024-01-28 Tom Tromey + + Remove a check of VAR_DOMAIN + completion_list_add_symbol checks that the returned symbol has + VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The + domain check is redundant -- only functions can possibly be LOC_BLOCK + -- and leaving this in place will cause a regression when combined + with a later patch in this series. This patch preemptively removes + the redundant check. + + Replace search_domain with domain_search_flags + This patch changes gdb to replace search_domain with + domain_search_flags everywhere. search_domain is removed. + + Add domain_search_flags + This adds a new flag enum type, domain_search_flags, which is the flag + version of domain_enum. Nothing uses this yet, but the goal here is + to have all symbol searches and lookups use these flags. The new + names are chosen to exactly parallel domain_enum. + +2024-01-28 Tom Tromey + + Add two new symbol domains + This adds two new symbol domain constants, TYPE_DOMAIN and + FUNCTION_DOMAIN. + + Historically, gdb was a C debugger, and the symbol tables continue to + reflect this. In particular, symbol domains match the C language, + with VAR_DOMAIN including variables, functions, and types. + + However, other languages have other approaches to namespacing. And, + in any case, it is often useful for other parts of gdb to be able to + distinguish between some domains at lookup time, without resorting to + examining a symbol's location -- in some situations, this sort of + filtering happens too late. + + Nothing uses these new domains yet, but the idea behind the patch is + to separate symbols into more domains and then let the + language-specific parts of gdb implement their semantics in terms of + these categories. + +2024-01-28 Tom Tromey + + Use a .def file for domain_enum + Future patches will change and reuse the names from domain_enum. This + patch makes this less error-prone by having a single point to define + these names, using the typical gdb ".def" file. + + Split up a big 'if' in symtab.c + global_symbol_searcher::add_matching_symbols in symtab.c has a + gigantic 'if' statement -- 33 lines of conditional expression. This + patch splits it up into a series of separate 'if's. + + Simplify symbol_to_info_string + Thi simplifies symbol_to_info_string, removing the 'kind' parameter + and instead having it use the symbol's domain. + +2024-01-28 Tom Tromey + + Remove NR_DOMAINS + NR_DOMAINS is only used for a static assert, but we no longer need it + now. If we add too many constants to this enum, GCC will warn about + the bitfield overflow: + + error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’ + +2024-01-28 Tom Tromey + + Give names to unspecified types + A patch later in this series will change check_typedef to also look in + the type domain. This change by itself caused a regression, but one + that revealed some peculiar behavior. + + The regression is in nullptr_t.exp, where examining a std::nullptr_t + will change from the correct: + + typedef decltype(nullptr) std::nullptr_t; + + to + + typedef void std::nullptr_t; + + Right now, the DWARF reader marks all unspecified types as stub types. + However, this interacts weirdly with check_typedef, which currently + does not try to resolve types -- only struct-domain objects. + + My first attempt here was to fix this by changing void types not to be + stub types, as I didn't see what value that provided. However, this + caused another regression, because call_function_by_hand_dummy checks + for stub-ness: + + if (values_type == NULL || values_type->is_stub ()) + values_type = default_return_type; + + I'm not really sure why it does this rather than check for + TYPE_CODE_VOID. + + While looking into this, I found another oddity: the DWARF reader + correctly creates a type named 'decltype(nullptr)' when it seems a + DW_TAG_unspecified_type -- but it creates a symbol named "void" + instead. + + This patch changes the DWARF reader to give the symbol the correct + name. This avoids the regression. + +2024-01-28 Tom Tromey + + Fix latent bug in mdebugread.c + mdebugread.c makes a label symbol but puts it into VAR_DOMAIN. I + think LABEL_DOMAIN is more appropriate. + + I don't have a way to test this. + +2024-01-28 Tom Tromey + + Make nsalias.exp more reliable + nsalias.exp tries to detect a complaint that is issued when expanding + a CU. However, the test is a bit funny in that, while gdb does + currently expand the CU and issue the complaint, it also emits this + error: + + No symbol "N100" in current context. + + This series will change gdb such that this CU is not expanded -- which + makes sense, the symbol in question doesn't actually match the lookups + that are done. + + So, to make the test more robust, a direct request to expand symtabs + is done instead. + +2024-01-28 Tom Tromey + + Fix latent bug in DW_TAG_entry_point handling + A DW_TAG_entry_point symbol inherits its extern/static property from + the enclosing subroutine. This is encoded in new_symbol -- but the + cooked indexer does not agree. + +2024-01-28 Tom Tromey + + Small cleanup in DWARF reader + I noticed a couple of spots in dwarf/read.c:new_symbol that call + add_symbol_to_list. However, this function is generally written to + set list_to_add, and then have a single call to add_symbol_to_list at + the end. This patch cleans up this discrepancy. + + Note that new_symbol is overlong and should probably be split up. + +2024-01-28 Tom Tromey + + Fix bug in cooked index scanner + Testing this entire series pointed out that the cooked index scanner + disagrees with new_symbol about certain symbols. In particular, + new_symbol has this comment: + + Ada and Fortran subprograms, whether marked external or + not, are always stored as a global symbol, because we want + + This patch updates the scanner to match. + + I don't know why the current code does not cause failures. + + It's maybe worth noting that incremental CU expansion -- creating + symtabs directly from the index -- would eliminate this sort of bug. + +2024-01-28 GDB Administrator + + Automatic date update in version.in + +2024-01-27 GDB Administrator + + Automatic date update in version.in + +2024-01-26 Indu Bhagat + + gas: scfi: untraceable control flow should be a hard error + PR gas/31284 + + Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be + created, and the SCFI machinery bails out with a warning: + "Warning: Untraceable control flow for func 'foo'; Skipping SCFI" + + It is, however, better suited if this is a hard error. Change it to a + hard error. Also change the message to skip mentioning "SCFI", because + the error itself may also useful when ginsns are used for other passes + (distinct from SCFI) involving GCFG, like a pass to detect if there is + unreachable code. Hence, simply say: + "Error: untraceable control flow for func 'foo'" + + gas/ + PR gas/31284 + * ginsn.c (ginsn_data_end): Use as_bad instead of as_warn. + + gas/testsuite/ + PR gas/31284 + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output + in case of errors. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning. + +2024-01-26 Indu Bhagat + + x86: testsuite: scfi: adjust COFI testcase + The testcase for change of flow instructions in its current shape is not + doing much: it checks that SCFI issues an appropriate warning. The same + warning is covered by another testcase (scfi-unsupported-cfg-1); It is + better to test the ginsn translation instead, for these 'change of flow + instructions'. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cofi-1.s: Moved to... + * gas/scfi/x86_64/ginsn-cofi-1.s: ...here. + * gas/scfi/x86_64/scfi-x86-64.exp: Adjust tests. + * gas/scfi/x86_64/scfi-cofi-1.d: Removed. + * gas/scfi/x86_64/scfi-cofi-1.l: Removed. + * gas/scfi/x86_64/ginsn-cofi-1.l: New test. + +2024-01-26 H.J. Lu + + elf: Rename is_standard_elf to uses_elf_em + Rename is_standard_elf to uses_elf_em for targets which use elf.em. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): Renamed + to ... + (uses_elf_em): This. + + ld/ + + PR ld/31289 + * testsuite/ld-elf/fatal-warnings-2a.d: Replace is_standard_elf + with uses_elf_em. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-26 Andrew Carlotti + + aarch64: move SHA512 instructions to +sha3 + SHA512 instructions were added to the architecture at the same time as SHA3 + instructions, but later than the SHA1 and SHA256 instructions. Furthermore, + implementations must support either both or neither of the SHA512 and SHA3 + instruction sets. However, SHA512 instructions were originally (and + incorrectly) added to Binutils under the +sha2 flag. + + This patch moves SHA512 instructions under the +sha3 flag, which matches the + architecture constraints and existing GCC and LLVM behaviour. + +2024-01-26 Nick Clifton + + Fix: Stripping Rust static libraries fails because of overly zealous illegal path check + PR 31250 + * objcopy.c (copy_archive): Improve the handling of archives that contain elements with invalid pathnames. + + Remove -pie from command line of fatal-warnings 1a and 1b tests. + +2024-01-26 Jan Beulich + + x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings + Re-using the entire VEX decode hierarchy for the respective major opcode + has led to those two also being decoded as-if valid. Follow the earlier + USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening. + + x86/APX: no need to have decode go through x86_64_table[] + As suggested during review already, all such entries have their first + slot as Bad_Opcode, so by adding two more enumerators we can avoid doing + that decode step altogether. + + x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix" + Adjustments made for the directive (by set_intel_syntax()) need also + making for the command line option. Break out respective code into a new + helper function, to also be invoked during command line processing. + Further also set register_prefix when processing -mnaked-reg. + + x86/APX: optimize MOVBE + With identical source and destination it can be covered by the NDD-to- + legacy conversion logic as well, even if in this case the original insn + doesn't use an NDD encoding. The size savings are even better here, for + the replacement (BSWAP) not having a ModR/M byte. + +2024-01-26 mengqinggang + + LoongArch: Fix a bug of getting relocation type + The old code works because R_LARCH_RELAX has no symbol index. It causes + '(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1. + +2024-01-26 mengqinggang + + LoongArch: gas: Add support for s9 register + In LoongArch ABI, r22 register can be used as frame pointer or + static register(s9). + + Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers + +2024-01-26 mengqinggang + + LoongArch: ld: Add support for TLS LE symbol with addend + Add support for TLS LE symbol with addend, such as: + lu12i.w $t0, %le_hi20(a + 0x8) + ori $t0, $t0, %le_lo12(a + 0x8) + +2024-01-26 Alan Modra + + Assertion failure dumping .eh_frame_hdr + dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated + sections, due to get_encoded_eh_value wrongly returning a full count + for truncated words. + + * dwarf.c (get_encoded_eh_value): Return zero for truncated words. + +2024-01-26 GDB Administrator + + Automatic date update in version.in + +2024-01-25 Simon Marchi + + gdb: remove get_gdb_program_name + Nothing uses it. + + Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7 + +2024-01-25 H.J. Lu + + elf: Add is_standard_elf + PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf, + mn10200-elf, ms1-elf and msp430-elf targets: + + FAIL: ld-elf/fatal-warnings-2a + FAIL: ld-elf/fatal-warnings-2b + FAIL: ld-elf/fatal-warnings-3a + FAIL: ld-elf/fatal-warnings-3b + FAIL: ld-elf/fatal-warnings-4a + FAIL: ld-elf/fatal-warnings-4b + + even though PR ld/31289 targets xfail for [is_generic] targets. These + targets not only don't use the generic_link_hash_table linker, but also + don't use the standard ELF emulation. Add is_standard_elf for ELF + targets which use the standard ELF emulation and replace [is_generic] + with ![is_standard_elf] in PR ld/31289 tests. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): New. + + ld/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_generic): Return 1 for + fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*, + moxie-*-moxiebox*, msp430-*-* and mt-*-*. + * testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic] + with ![is_standard_elf]. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 H.J. Lu + + ld: Always call output_unknown_cmdline_warning + Call output_unknown_cmdline_warning if there are no input files so that + + $ ld -z bad-option + + reports + + ld: warning: -z bad-option ignored + ld: no input files + + instead of + + ld: no input files + + PR ld/31289 + * ldmain.c (main): Call output_unknown_cmdline_warning if there + are no input files. + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix regexp in vgdb_start + On Fedora 39 aarch64 I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + relaying data between gdb and process 2114437^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + _start () at ../sysdeps/aarch64/dl-start.S:22^M + warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + For contrast, on openSUSE Leap 15.4 x86_64 I have: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + relaying data between gdb and process 18797^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib64/ld-linux-x86-64.so.2...^M + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M + 0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M + (gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The fail happens in vgdb_start because the regexp only matches the + "in _start ()" variant, not the "_start () at": + ... + gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb" + ... + Which variant you get is determined by presence of debug info. + + Fix this by also matching the "_start () at" variant. + + Tested aarch64-linux and x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-25 Andrew Carlotti + + gas: Update NEWS + Groups entries by architecture, and update AArch64 content. + +2024-01-25 Tom de Vries + + [gdb/build] Workaround gcc PR113599 + Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding + [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as + reported in PR build/31281. + + Work around this by flipping inherit order: + ... + -class thread_info : public refcounted_object, + - public intrusive_list_node + +class thread_info : public intrusive_list_node, + + public refcounted_object + ... + + An argument could be made that this isn't necessary, because this occurred in + an unreleased gcc version. + + However, I think it could be useful when bisecting gcc for other problems in + building gdb. Having this workaround means the bisect won't reintroduce the + problem. Furthermore, the workaround is harmless. + + Tested on Fedora rawhide x86_64. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281 + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599 + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix gdb.base/eh_return.exp + On Fedora rawhide aarch64, I run into: + ... + (gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address + run ^M + Starting program: eh_return ^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + [Inferior 1 (process 1113051) exited normally]^M + (gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited) + ... + + This happens as follows: the test-case sets a breakpoint on the last + instruction of function eh2: + ... + (gdb) break *0x00000000004103ec^M + ... + and expects to hit the breakpoint, but instead the "br x6" is taken: + ... + 0x00000000004103e0 <+176>: cbz x4, 0x4103ec ^M + 0x00000000004103e4 <+180>: add sp, sp, x5^M + 0x00000000004103e8 <+184>: br x6^M + 0x00000000004103ec <+188>: ret^M + ... + + In contrast, with fedora f39 we have: + ... + 0x00000000004103bc <+156>: ldp x2, x3, [sp, #48]^M + 0x00000000004103c0 <+160>: ldp x29, x30, [sp, #16]^M + 0x00000000004103c4 <+164>: add sp, sp, #0x50^M + 0x00000000004103c8 <+168>: add sp, sp, x4^M + 0x00000000004103cc <+172>: ret^M + + ... + and the breakpoint is reached. + + Fix this by detecting that the breakpoint is not hit, and declaring the test + unsupported. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31291 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291 + +2024-01-25 Aditya Vidyadhar Kamath + + Fix attach-twice.c testcase for AIX. + Currently, in AIX attach-twice.exp testcase is untested due to the below error. + gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace' + + This is because in AIX ptrace has five arguments. This patch is a fix for the same such that + this test case runs in AIX and other targets as well. + +2024-01-25 H.J. Lu + + ld: Improve --fatal-warnings for unknown command-line options + There are 2 problems with --fatal-warnings for unknown command-line + options: + + 1. --fatal-warnings doesn't trigger an error for an unknown command-line + option when --fatal-warnings is the last command-line option. + 2. When --fatal-warnings triggers an error for an unknown command-line + option, the message says that the unknown command-line option is ignored. + + This patch queues unknown command-line option warnings and outputs queued + command-line option warnings after all command-line options have been + processed so that --fatal-warnings can work for unknown command-line + options regardless of the order of --fatal-warnings. + + When --fatal-warnings is used, the linker message is changed from + + ld: warning: -z bad-option ignored + + to + + ld: error: unsupported option: -z bad-option + + The above also applies to "-z dynamic-undefined-weak" when the known + "-z dynamic-undefined-weak" option is ignored. + + PR ld/31289 + * ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning + to warn the ignored -z dynamic-undefined-weak option. + * ldmain.c (main): Call output_unknown_cmdline_warnings after + calling ldemul_after_parse. + * ldmisc.c (CMDLINE_WARNING_SIZE): New. + (cmdline_warning_list): Likewise. + (cmdline_warning_head): Likewise. + (cmdline_warning_tail): Likewise. + (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * ldmisc.h (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use + queue_unknown_cmdline_warning to warn unknown -z option. + * testsuite/ld-elf/fatal-warnings-1a.d: New file. + * testsuite/ld-elf/fatal-warnings-1b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 GDB Administrator + + Automatic date update in version.in + +2024-01-24 Alan Modra + + riscv64-pei uninitialised data writing relocs + Without this patch the r_offset field of struct external_reloc is + uninitialised when using objcopy. + + * coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define. + (SWAP_OUT_RELOC_OFFSET): Define. + +2024-01-24 Tom Tromey + + Emit stopped event for DAP attach request + In an earlier patch, I wrote: + + ... It also adds some machinery so that attach stops can be + suppressed, which I think is the right thing to do. + + However, after some discussions here at AdaCore, I now believe this to + be incorrect -- while DAP says that expected "continue" events should + be suppressed, there is no corresponding language for expected "stop" + events, and indeed "stop" events explicitly mention cases like "step". + + This patch arranges for the stop event to be emitted again. + +2024-01-24 Tom Tromey + + Handle DW_AT_endianity on enumeration types + A user found that gdb would not correctly print a field from an Ada + record using the scalar storage order feature. We tracked this down + to a combination of problems. + + First, GCC did not emit DW_AT_endianity on the enumeration type. + DWARF does not specify this, but it is an obvious and harmless + extension. This was fixed in GCC recently: + + https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html + https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd + + Second, GDB did not handle this attribute on enumeration types. This + patch makes this change and adds a test case that will pass with the + patched GCC. + + So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes + in, the test case in this patch can be updated to reflect that. + + Reviewed-By: Keith Seitz + +2024-01-24 Thiago Jung Bauermann + + gdb/arm: Fix epilogue frame id + arm_epilogue_frame_this_id has a comment saying that it fall backs to using + the current PC if the function start address can't be identified, but it + actually uses only the PC to make the frame id. + + This patch makes the code match the comment. Another hint that it's what + is intended is that arm_prologue_this_id, a function almost identical to + it, does that. + + The problem was found by code inspection. It fixes the following testsuite + failures: + + FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches + FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two + + Tested on arm-linux-gnueabi-hf. + +2024-01-24 Guinevere Larsen + + gdb/testsuite: add test for backtracing for threaded inferiors from a corefile + This patch is based on an out-of-tree patch that fedora has been + carrying for a while. It tests if GDB is able to properly unwind a + threaded program in the following situations: + * regular threads + * in a signal handler + * in a signal handler executing on an alternate stack + + And the final frame can either be in a syscall or in an infinite loop. + + The test works by running the inferior until a crash to generate a + corefile, or until right before the crash. Then applies a backtrace to + all threads to see if any frame can't be identified, and the order of + the threads in GDB. Finally, it goes thread by thread and tries to + collect a large part of the backtrace, to confirm that everything is + being unwound correctly. + + Co-Authored-By: Andrew Burgess + Reviewed-By: Luis Machado + Approved-By: Luis Machado + +2024-01-24 Andrew Carlotti + + aarch64: Eliminate unused variable warnings with -DNDEBUG + +2024-01-24 mengqinggang + + LoongArch: gas: Start a new frag after instructions that can be relaxed + For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20} + relocations, start a new frag to get correct eh_frame Call Frame Information + FDE DW_CFA_advance_loc info. + +2024-01-24 mengqinggang + + LoongArch: gas: Don't define LoongArch .align + Gcc may generate "\t.align\t%d,54525952,4\n" before commit + b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object + file, we call s_align_ptwo (-4). It result in alignment padding must be a + multiple of 4 if .align has second parameter. + + Use default s_align_ptwo for .align. + +2024-01-24 Paul Iannetta + + Add myself as the KVX port maintainer + binutils/ChangeLog: + + * MAINTAINERS: Add myself as the KVX port maintainer. + +2024-01-24 GDB Administrator + + Automatic date update in version.in + +2024-01-23 Andrew Carlotti + + aarch64: Update Architecture Extensions documentation + Restructure the architecture extensions table, add a new table for architecture + version dependencies, add missing architecture extensions, and improve some + extension descriptions. + + aarch64: Include +predres2 in -march=armv8.9-a + This matches the dependencies in the architecture, in LLVM, and even in the + original Binutils commit message that mistakenly included it only in armv9.4-a. + +2024-01-23 Xi Ruoyao + + [PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42 + +2024-01-23 Guinevere Larsen + + gdb: fix "list ." related crash + When a user attempts to use the "list ." command with an inferior that + doesn't have debug symbols, GDB would crash. This was reported as PR + gdb/31256. + + The crash would happen when attempting to get the current symtab_and_line + for the stop location, because the symtab would return a null pointer + and we'd attempt to dereference it to print the line. + + This commit fixes that by checking for an empty symtab and erroring out + of the function if it happens. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256 + Approved-By: Tom Tromey + +2024-01-23 Mike Frysinger + + sim: sh: fix nested braces in struct init + The op struct includes an array of strings, but doesn't use braces + around that array when initializing. This causes a ton of warnings + when using -Wmissing-braces. Add them to fix. + + The code this tool generates is the same before & after. + +2024-01-23 Jaydeep Patil + + sim: riscv: Fix crash during instruction decoding + The match_never() function has been removed and thus step_once() crashes + during instruction decoding. Fixed it by checking for null pointer before + invoking function attached to match_func member of riscv_opcode structure + +2024-01-23 Mike Frysinger + + sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752] + Some compilers warn in the frv code: + sem.c:24343:41: error: incompatible function pointer types passing + 'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)') + to parameter of type + 'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types] + + This is due to frvbf_h_acc40U_set using UDI for setting the new value, + but using the common sim_queue_fn_di_write API which uses DI. The same + size, but different sign. We could change frvbf_h_acc40U_set to take a + DI without changing behavior in practice: the UDI is already passed via + the queue function which accepts a DI, and frvbf_h_acc40U_set already + casts the input to UDI before running any operations on it. However, + these files are all generated, so manual changes here would be reverted. + + Seems like we can only change the register type for all APIs in the cpu + definition. This builds cleanly, and passes sim unittests. Not sure if + it's 100% the answer, but seems to be the best we have currently. + + Bug: https://sourceware.org/PR29752 + +2024-01-23 GDB Administrator + + Automatic date update in version.in + +2024-01-22 Simon Marchi + + gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp (and more) + Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test + name. This happens because have_index calls get_index_type with the + default test name. Refactor the test to avoid this, while cleaning a + few other things, the most important being: + + - factor out the relocated and unrelocated parts in their own procs + - give different names to generated binaries in different variations, + such that all binaries are left in the test output directory (this + makes it easier to debug a specific variation) + + Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94 + +2024-01-22 Vladimir Mezentsev + + Fix 31252 gprofng causes testsuite parallel jobs fail + Before running our tests, we made a fake installation into ./tmpdir. + This installation changes libopcodes.la in the build area. + Gas testing may fail if gas and gprofng tests are run in parallel. + + I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH, + GPROFNG_SYSCONFDIR are set. + putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create + directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used + to set up LD_PRELOAD). + + gprofng/ChangeLog + 2024-01-19 Vladimir Mezentsev + + PR gprofng/31252 + PR gprofng/30808 + * src/envsets.cc (putenv_libcollector_ld_misc): Use + $GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH. + * testsuite/config/default.exp: Create a script to run gprofng. + * testsuite/lib/display-lib.exp: Fix typo. + +2024-01-22 Nick Clifton + + Updated Serbian translations for th bfd, gold and opcodes directories + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in srconv.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils/srconv.c: In function ‘nints’: + binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 598 | return (int *) (xcalloc (sizeof (int), x)); + | ^~~ + binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * srconv.c (nints): Swap xcalloc arguments. + (wr_du): Likewise. + (wr_dus): Likewise. + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in coffgrok.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’: + binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section), + | ^~~~~~ + binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * coffgrok.c (empty_scope): Swap xcalloc arguments. + (empty_symbol): Likewise. + (do_lines): Likewise. + (doit): Likewise. + (coff_grok): Likewise. + +2024-01-22 Mark Wielaard + + libsframe: Fix calloc argument order in dump_sframe_header + GCC14 warns about the order of the arguments to calloc + + libsframe/sframe-dump.c: In function ‘dump_sframe_header’: + libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] + 70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN); + | ^~~~ + libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element + + Fix this by swapping the size and count arguments. + + libsframe/ + + * sframe-dump.c (dump_sframe_header): Swap arguments to calloc + +2024-01-22 Mark Wielaard + + opcodes: tic4x_disassemble swap xcalloc arguments + GCC 14 will detect when the size and count arguments of calloc are + swapped. + + binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’: + binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE)); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element + binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element + + opcodes/ChangeLog: + + * /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc + arguments. + +2024-01-22 Tom Tromey + + Handle EOF more gracefully in DAP + A user pointed out that gdb will print a Python exception when it gets + an EOF in DAP mode. And, it turns out that an EOF like this also + causes gdb not to exit. This is due to the refactoring that moved the + JSON reader to its own thread -- previously this caused an exception + to propagate and cause an exit, but now it just leaves the reader + hung. + + This patch fixes these problems by arranging to handle EOF more + gracefully. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217 + +2024-01-22 Tom Tromey + + Fix handling of DW_OP_GNU_push_tls_address + In one spot, DW_OP_GNU_push_tls_address is handled differently from + DW_OP_form_tls_address. However, I think they should always be + treated identically. + + Approved-by: Kevin Buettner + +2024-01-22 Mark Wielaard + + sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write} + m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit + + sim/m32c/gdb-if.c: In function ‘sim_read’: + sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local] + 162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length) + | ~~~~~~~~~^~~ + In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38: + sim/m32c/cpu.h:83:3: note: shadowed declaration is here + 83 | mem, + | ^~~ + + Fix this by renaming mem to addr in all sim_read and sim_write functions. + Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this + also meant renaming the local addr variable to vma. + +2024-01-22 Mark Wielaard + + sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.c + With GCC 14 -Werror=shadow=compatible-local flags the reuse of single + capital letters used in aarch64/cpustate.h enums + + 88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N) + | ~~~~~~~~~^ + In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27, + from ../../binutils-gdb/sim/aarch64/simulator.c:33: + 217 | N = 1 << N_IDX + | ^ + + sim/aarch64/simulator.c: In function ‘expand_logical_immediate’: + sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local] + sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here + +2024-01-22 Mark Wielaard + + sim: Fix cc -Werror=shadow=local in cr16/simops.c + include/opcode/cr16.h defines cc as an enum value, which causes GCC 14 + to warn + + sim/cr16/simops.c: In function ‘cond_stat’: + sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local] + 138 | static int cond_stat(int cc) + | ~~~~^~ + In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26, + from ../../binutils-gdb/sim/cr16/simops.c:39: + sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here + 149 | cc, + | ^~ + + Fix this by renaming cc in cr16/simops.c to cond. + +2024-01-22 Guinevere Larsen + + gdb/testsuite: relax filename restriction in some gdb.btrace tests + The test gdb.btrace/tailcall.exp has multiple tests that include the + filename in the output. When testing with gcc, only a relative path is + printed, but when using clang, the full file path is printed instead. + This makes most of those tests fail, with the exception of "record goto + 4" which allows for more characters before the file name. The test + gdb.btrace/recod_goto.exp suffers with the same issue + + This commit allows for text before the filename. However, instead of how + the aforementioned "record goto 4", it uses a regexp that doesn't allow + for newlines, just in case some off output happens. + + Approved-By: Tom Tromey + +2024-01-22 Guinevere Larsen + + gdb/testsuite: modernize gdb.dwarf2/dw2-noloc.exp + The test gdb.dwarf2/dw2-noloc.exp predates the dwarf assembler, and uses + some unreliable assumptions about where global labels get put. + Specifically, when using clang to compile the test, both labels it uses + to gauge the adresses of the main function get reshuffled to be side-by-side, + and the debug information ends up making it look like main's high pc is equal + to low pc, meaning we never enter the main function's scope, and that leads to + 22 failures because the "main_*" variables are technically never in scope. + + This patch modernizes the aforementioned test to use the dwarf + assembler, which removes all failures when using clang. It also renames + the .c file to be more inline with current standard. + + Approved-By: Tom Tromey + +2024-01-22 Xi Ruoyao + + LoongArch: Fix some test failures about TLS desc and TLS relaxation + There are two issues causing 11 test failures: + + 1. The TLS desc tests are matching the entire disassemble of a linked + executable. But if ld is configured --enable-default-hash-style=gnu + (note that most modern distros use this option), the layout of the + linked executables will be different and the immediate operands in + the linked executables will also be different. So we add + "--hash-style=both" for these tests to cancel the effect of + --enable-default-hash-style=gnu, like [x86_64 mark-plt tests]. + 2. By default objdump disassemble uses [pseudo-instructions] so "addi.w" + is outputed as "li.w", causing mismatches in TLS relaxation tests. + We can turn off the pseudo-instruction usage in objdump using "-M + no-aliases" to fix them. + + [x86_64 mark-plt tests]: 16666ccc91295d1568c5c2cb0e7600694840dfd9 + [pseudo-instructions]: 17f9439038257b1de0c130a416a9a7645c653cb0 + +2024-01-22 Tatsuyuki Ishi + + LoongArch: Do not add DF_STATIC_TLS for TLS LE + TLS LE is exclusively for executables, while DF_STATIC_TLS is for DLLs. + DF_STATIC_TLS should only be set for TLS IE (and when it's DLL), not LE. + + LoongArch: Use tab to indent assembly in TLSDESC test suite + The usual convention is to use tabs. Not all test are following this, + but at least when using tabs, let's use it consistently throughout the + file. + +2024-01-22 Jan Beulich + + x86/APX: also amend the PUSH2/POP2 testcase + Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be + encoded") took care of only half of the remaining issue. Add #pass here + as well. + +2024-01-22 GDB Administrator + + Automatic date update in version.in + +2024-01-21 Lancelot SIX + + gdb/infrun: lazily load curr_frame_id in process_event_stop_test + A recent(ish) change in gdb/infrun.c made process_event_stop_test load + debug information where it would not have done so previously. The + change is: + + commit bf2813aff8f2988ad3d53e819a0415abf295c91f + AuthorDate: Fri Sep 1 13:47:32 2023 +0200 + CommitDate: Mon Nov 20 10:54:03 2023 +0100 + + gdb/record: print frame information when exiting a recursive call + + Currently, when GDB is reverse stepping out of a function into the same + function due to a recursive call, it doesn't print frame information, as + reported by PR record/29178. This happens because when the inferior + leaves the current frame, GDB decides to refresh the step information, + clobbering the original step_frame_id, making it impossible to figure + out later on that the frame has been changed. + + This commit changes GDB so that, if we notice we're in this exact + situation, we won't refresh the step information. + + Because of implementation details, this change can cause some debug + information to be read when it normally wouldn't before, which showed up + as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that + isn't a problem, the test was changed to allow for the new output. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 + + Although there is nothing wrong with this change in principle, it + happens to break most of the tests in gdb/testsuite/gdb.rocm/*.exp. + This is because those tests do rely on GDB not loading debug + information. This is necessary because the debug information produced + for AMDGPU code is using DWARF extensions which are not supported by GDB + at this point. + + In this patch, I propose to use a lazy loading mechanism so the frame_id + for the current frame is only computed when required instead of when + entering process_event_stop_test. The lazy_loader class is currently + defined locally in infrun.c, but if it turns out to be useful elsewhere, + it could go somewhere under gdbsupport. + + This patch should restore the behavior GDB had before + bf2813aff8f2988ad3d53e819a0415abf295c91f when it comes to load debug + info. + + Another approach could have been to revert + fb84fbf8a51f5be2e78765508ebd9753af96b492 (gdb/infrun: simplify + process_event_stop_test) and adjust the implementation of + bf2813aff8f2988ad3d53e819a0415abf295c91f (gdb/record: print frame + information when exiting a recursive call). However, I think that the + lazy loading works well with the simplification done recently, so I went + down that route. + + Regression tested on x86_64-linux (Ubuntu 22.04) with AMDGPU support. + + Change-Id: Ib63a162128130d1786a77c98623e9e3dcbc363b7 + Approved-by: Kevin Buettner + +2024-01-21 mengqinggang + + LoongArch: Do not emit R_LARCH_RELAX for two register macros + For two register macros (e.g. la.local $t0, $t1, symbol) used in extreme code + model, do not emit R_LARCH_RELAX relocations. + +2024-01-21 GDB Administrator + + Automatic date update in version.in + +2024-01-20 Simon Marchi + + gdb: remove SYMBOL_*_OPS macros + Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in + favor of methods on struct symbol. More changes could be done here to + improve the design and make things safer, but I just wanted to do a + straightforward change to remove the macros for now. + + Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21 + Reviewed-by: Kevin Buettner + +2024-01-20 Tom Tromey + + Simplify DWARF symtab inclusion handling + In the past, dwarf2_per_cu_data was allocated using malloc, so special + handling was needed for the vector used for symtab handling. We + changed this to use 'new' a while back, so this code can now be + greatly simplified. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + +2024-01-20 GDB Administrator + + Automatic date update in version.in + +2024-01-19 Andrew Burgess + + gdb: remove deprecated_exec_file_display_hook and associated code + This commit removes deprecated_exec_file_display_hook and the + associated specify_exec_file_hook. + + The specify_exec_file_hook is used to add a new hook function to + deprecated_exec_file_display_hook, but is only used from the insight + debugger. + + I posted a patch to remove the use of specify_exec_file_hook from + insight, and instead use gdb::observers::executable_changed, this + patch can be found here (it has now been merged): + + https://inbox.sourceware.org/insight/6abeb45e97d9004ec331e94cf2089af00553de76.1702379379.git.aburgess@redhat.com/T/#u + + With this merged we can now cleanup the GDB side as this code is now + unused. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-01-19 Сергей Чернов + + Fix remote serial read + After closing "Bug 30770 - serial.c does not preserve errno correctly" + https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The + documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is + permissible to use recv in the case of a non-socket. + + condition: + os: Distributor ID: Ubuntu + Description: Ubuntu 23.10 + Release: 23.10 + Codename: mantic + + libc: + ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38 + kernel: + Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux + gdb: build from trank at 15.0.50.20231226-git + + GDB output: + $ arm-kgp-eabi-gdb + GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>) + 15.0.50.20231226-git + .... + (gdb) tar ext /dev/ttyACM1 + Remote debugging using /dev/ttyACM1 + Remote communication error. Target disconnected: error while reading: Socket operation on non-socket. + (gdb) + + after fix gdb work fine + + $ arm-kgp-eabi-gdb -q + (gdb) tar ext /dev/ttyACM0 + Remote debugging using /dev/ttyACM0 + (gdb) mon swd + Target voltage: 0.0V + Available Targets: + No. Att Driver + STM32F40x M4 + (gdb) att 1 + Attaching to Remote target + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x08020c80 in ?? () + (gdb) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + +2024-01-19 Aaron Merey + + gdb/ui-out.h: Fix exception handling in do_with_buffered_output + Replace throw with throw_exeception in do_with_buffered_output. + + This patch fixes regressions in gdb.dwarf2/dw2-dir-file-name.exp + caused by commit 519d63439. + + do_with_buffered_output needs to use throw_exception instead of + throw to ensure that exceptions of the correct type are thrown. + If using throw, gdb_exception_error may be wrongly converted into + gdb_exception during print_frame_info. This prevents the exception + from being caught in print_stack_frame. + +2024-01-19 Tom de Vries + + [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp + With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into: + ... + (gdb) attach 7773^M + Attaching to program: attach-many-short-lived-threads, process 7773^M + Cannot attach to lwp 7776: Operation not permitted (1)^M + (gdb) PASS: $exp: iter 1: attach + info threads^M + No threads.^M + (gdb) PASS: $exp: iter 1: no new threads + set breakpoint always-inserted on^M + (gdb) PASS: $exp: iter 1: set breakpoint always-inserted on + break break_fn^M + Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M + (gdb) PASS: $exp: iter 1: break break_fn + continue^M + The program is not being run.^M + (gdb) FAIL: $exp: iter 1: break at break_fn: 1 \ + (the program is no longer running) + ... + + There's some code in the test-case dealing with a similar warning: + ... + -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { + ... + + But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be + traced"), the warning has been changed into an error. + + Fix the FAIL by updating the test-case to expect an error instead of a + warning. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-19 Simon Marchi + + gdb: remove unnecessary NULL checks for return value of value_from_register + value_from_register can't return nullptr, remove some NULL checks. + + Change-Id: Ia6b32b8f86e593c535e3678a89dffe5544eb7ab0 + Approved-By: Tom Tromey + +2024-01-19 H.J. Lu + + ld: Remove scripttempl/elf_chaos.sc + scripttempl/elf_chaos.sc is unused. Remove it. + + * scripttempl/elf_chaos.sc: Removed. + +2024-01-19 H.J. Lu + + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc which are unused + after + + commit 3596d8ceb2cdc35b4fd702ee9daace5a2d880174 + Author: Alan Modra + Date: Wed Apr 18 15:39:34 2018 +0930 + + Remove mips aout, coff, and pe support + + bfd/ + + * hosts/mipsbsd.h: Removed. + + ld/ + + * scripttempl/mipsbsd.sc: Removed. + +2024-01-19 Oleg Tolmatcev + + ld: fix 32-bit mingw DLL symbol export bug + I think there's a bug in ld on 32-bit Windows. Here is a tiny project for reproducing the problem: + https://github.com/oltolm/ld-mingw32-bug + + A 32-bit DLL exports two stdcall functions "myfunc" and "myfunc64". The functions would normally get + exported as "myfunc@0" and "myfunc64@0". The "DEF" file exports them as "myfunc" and "myfunc64" + without the decorations. When you run the executable it shows an error message saying that it cannot + find "myfunc64". + + I think it happens because the sorting in ld is wrong. I think it should use the exported names + "myfunc" and "myfunc64", but instead it uses the decorated names "myfunc@0" or "myfunc65@0". The + ordering of functions in the DLL is different depending on which names you use. + + My patch changes ld to use undecorated exported names for sorting and it seems to fix the problem. + When I execute ctest in my project, it runs successfully. + +2024-01-19 H.J. Lu + + Update x86/APX: VROUND{P,S}{S,D} can generally be encoded + Append "#pass" to APX tests for targets which pad text sections with NOPs. + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Append + "#pass". + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. + +2024-01-19 Nick Clifton + + Update readelf's and objdump's debug frame displaying feature to include the contents of the .eh_frame_hdr section, if present. + +2024-01-19 H.J. Lu + + ld: Put all emulation options in ldlex.h + For each command line option, parse_args() calls ldemul_parse_args() + to check if the command line option is an emulation option. But when + there is a conflict between the emulation option value and the default + option value, the default command line option will be processed as if + the emulation option is used. Remove PARSE_AND_LIST_PROLOGUE and move + all emulation options to ldlex.h to avoid conflicts. + + PR ld/31247 + * ldlex.h (option_values): Add all emulation options. + * emulparams/elf32mcore.sh (PARSE_AND_LIST_PROLOGUE): Removed. + * emulparams/plt_unwind.sh (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aarch64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/alphaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/armelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/avrelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/bfin.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/cskyelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/hppaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ia64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68hc1xelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68kelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/metagelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/mipself.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nds32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nto.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/riscvelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/rxelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/s390.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/scoreelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/spuelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/tic6xdsbt.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/vxworks.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aix.em: Include "ldlex.h". + (OPTION_XXX): Removed. + (gld${EMULATION_NAME}_read_file): Replace lineno with linenumber. + * emultempl/beos.em (OPTION_XXX): Removed. + * emultempl/elf.em: Include "ldlex.h". + Don't check PARSE_AND_LIST_PROLOGUE. + (OPTION_XXX): Removed. + * emultempl/msp430.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/pe.em (OPTION_XXX): Removed. + * emultempl/pep.em (OPTION_XXX): Likewise. + * emultempl/ticoff.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/vms.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/xtensaelf.em (elf32xtensa_size_opt, + elf32xtensa_no_literal_movement, elf32xtensa_abi): Moved out of + PARSE_AND_LIST_PROLOGUE. + (PARSE_AND_LIST_PROLOGUE): Removed. + +2024-01-19 Nick Clifton + + Add multilib.am to the list of top level files included in any release created by the src-release.sh script + +2024-01-19 Jan Beulich + + x86-64: Dwarf2 register numbers for %bnd + I don't see why we shouldn't record them when they have been allocated, + even if they're (bogusly) named as reserved in the ABI right now. + + x86/APX: VROUND{P,S}{S,D} can generally be encoded + VRNDSCALE{P,S}{S,D} is the AVX512 generalization of these AVX insns. As + long as the immediate has the top 4 bits clear, they are equivalent to + the earlier VEX-encoded insns, and hence can be used to permit use of + eGPR-s in the memory operand. Since this is the normal way of using + these insns, also alter the resulting diagnostic to complain about the + immediate, not the eGPR use. + + x86/APX: be consistent with insn suffixes + When there's a suitably disambiguating register operand, suffixes are + generally omitted (unless in suffix-always mode). All NDD insns have a + suitable register operand, so they shouldn't have suffixes by default. + + x86: drop redundant EVex128 from PUSH2/POP2 + EVexMap4 already covers that. + + x86: support APX forms of U{RD,WR}MSR + This was missed in 6177c84d5edc ("Support APX GPR32 with extend evex + prefix"). + +2024-01-19 Aaron Merey + + gdb: Buffer output streams during events that might download debuginfo + Introduce new ui_file buffering_file to temporarily collect output + written to gdb_std* output streams during print_thread, print_frame_info + and print_stop_event. + + This ensures that output during these functions is not interrupted + by debuginfod progress messages. + + With the addition of deferred debuginfo downloading it is possible + for download progress messages to print during these events. + Without any intervention we can end up with poorly formatted output: + + (gdb) backtrace + [...] + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0 + function_cache=0x561221b224d0, state=... + + To fix this we buffer writes to gdb_std* output streams while allowing + debuginfod progress messages to skip the buffers and print to the + underlying output streams immediately. Buffered output is then written + to the output streams. This ensures that progress messages print first, + followed by uninterrupted frame/thread/stop info: + + (gdb) backtrace + [...] + Downloading separate debug info for /lib64/libpython3.11.so.1.0 + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=... + + Co-Authored-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-01-19 GDB Administrator + + Automatic date update in version.in + +2024-01-18 Tom Tromey + + Rewrite .debug_names writer + This rewrites GDB's .debug_names writer. It is now closer to the form + imagined in the DWARF spec. In particular, names are emitted exactly + as they appear in the original DWARF. + + In order to make the reader work nicely, some extensions were needed. + These were all documented in an earlier patch. Note that in + particular this writer solves the "main name" problem by putting a + flag into the table. + + GDB does not use the .debug_names hash table, so it also does not + write one. I consider this hash table to be essentially useless in + general, due to the name canonicalization problem -- while DWARF says + that writers should use the system demangling style, (1) this style + varies across systems, so it can't truly be relied on; and (2) at + least GCC and one other compiler don't actually follow this part of + the spec anyway. + + It's important to note, though, that even if the hash was somehow + useful, GDB probably still would not use it -- a sorted list of names + is needed for completion and performs reasonably well for other + lookups, so a hash table is just overhead, IMO. + + String emission is also simplified. There's no need in this writer to + ingest the contents of .debug_str. + + A couple of tests are updated to reflect the fact that they now "fail" + because the tests don't include .debug_aranges in the .S file. + Arguably the .debug_names writer should also create this section; but + I did not implement that in this series, and there is a separate bug + about it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 + +2024-01-18 Tom Tromey + + Export dwarf5_augmentation + I don't know why gdb had the .debug_names augmentation string in two + separate places; this patch exports it in one spot, to be used in + another. + +2024-01-18 Tom Tromey + + Rewrite .debug_names reader + This rewrites the .debug_names reader to follow the spec. + + Since it was first written, gdb's .debug_names writer has been + incorrect -- while the form of the section has been ok, the contents + have been very gdb-specific. + + This patch fixes the reader side of this equation, rewriting the + reader to create a cooked index internally -- an important detail + because it allows for the deletion of a lot of code, and it means the + various readers will agree more often. + + This reader checks for a new augmentation string. For the time being, + all other producers are ignored -- the old GDB ones because they are + wrong, and clang because it does not emit DW_IDX_parent. (If there + are any other producers, I'm unaware of them.) + + While the new reader mostly runs in a worker thread, it does not try + to distribute its work. This could be done by partitioning the name + table. The parent computations could also be done in parallel after + all names have been read. I haven't attempted this. + + Note that this patch temporarily regresses gdb.base/gdb-index-err.exp. + This test writes an index using gdb -- but at this particular stage, + gdb cannot read the indexes it creates. Rather than merge the patches + into a mega-patch, I've chosen to just accept this temporary + regression. + + In v1 of this patch, I made the new reader more strict about requiring + .debug_aranges. In v2, I've backed this out and kept the previous + logic. This solved a few test failures, though it's arguably not the + right approach. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Allow other results in DW_TAG_entry_point test + DW_TAG_entry_point is implemented by adding a new LOC_BLOCK symbol -- + that is, another function symbol. However, the test case assumes that + "bt" will never pick this symbol. + + This assumption seems unwarranted to me, and in fact this test will + regress with the debug-names target board after the .debug_names + rewrite. + + This patch changes the test to allow either answer in the backtrace. + If only the main entry point is desired, then it seems that more work + must be done to handle DW_TAG_entry_point properly, as nothing + currently guarantees this property. + +2024-01-18 Tom Tromey + + Remove some .debug_names tests + These .debug_names tests were hand-written to mimic clang. However, + they are difficult to update, and in any case the new reader won't + accept clang-generated indices. Therefore this patch removes these + tests. + +2024-01-18 Tom Tromey + + Explicitly expand CUs in dw2-inline-with-lexical-scope.exp + dw2-inline-with-lexical-scope.exp relies on the main CU being + expanded. However, it doesn't guarantee that this actually happens, + and with the new .debug_names reader, it won't, because the "main" + program will be found in the index without requiring CU expansion. + + This patch fixes the problem by explicitly expanding the CU in + question. + + Note that this is an artificial bug -- it occurs because the generated + .debug_aranges isn't correct. + +2024-01-18 Tom Tromey + + Fix dw2-zero-range.exp when an index is in use + dw2-zero-range.exp looks for a certain complaint, but this won't be + issued when an index is in use. This patch changes the test to not + fail in this case. + +2024-01-18 Tom Tromey + + Empty hash table fix in .debug_names reader + The handling of an empty hash table in the .debug_names reader is + slightly wrong. + + Currently the code assumes there is always an array of hashes. + However, section 6.1.1.4.5 Hash Lookup Table says: + + The optional hash lookup table immediately follows the list of + type signatures. + + and then: + + The hash lookup table is actually two separate arrays: an array of + buckets, followed immediately by an array of hashes. + + My reading of this is that the hash table as a whole is optional, and + so the hashes will not exist in this case. (This also makes sense + because the hashes are not useful without the buckets anyway.) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Remove cooked_index_worker::start_reading + I noticed that cooked_index_worker::start_reading isn't really needed. + This patch removes it, and also removes the SCOPED_EXIT, in favor of a + direct call. + +2024-01-18 Tom Tromey + + Change cooked_index_worker to abstract base class + This changes cooked_index_worker to be an abstract base class. The + base class implementation is moved to cooked-index.c, and a concrete + subclass is added to read.c. + + This change is preparation for the new .debug_names reader, which will + supply its own concrete implementation of the worker. + +2024-01-18 Tom Tromey + + Do not write the index cache from an index + The new .debug_names reader will work by creating a cooked index from + .debug_names. This patch updates cooked_index::maybe_write_index to + avoid writing the index in this case. + + However, in order to do this in a clean way, the readers are changed + so that a nullptr result from index_for_writing means "cannot be + done", and then the error message is moved into write_dwarf_index + (where it historically lived). + +2024-01-18 Tom Tromey + + Move cooked_index_functions to cooked-index.h + This moves the declaration of cooked_index_functions to + cooked-index.h. This makes it visible for use by the rewritten + .debug_names reader, and it also lets us move the implementation of + make_quick_functions into cooked-index.c, where it really belongs. + +2024-01-18 Tom Tromey + + Add language to cooked_index_entry + This adds a new 'lang' member to cooked_index_entry. This holds the + language of the symbol. This is primarily useful for the new + .debug_names reader, which will not scan the CUs for languages up + front. + + This also changes cooked_index_shard::add to return a non-const + pointer. This doesn't impact the current code, but is needed for the + new reader. + +2024-01-18 Tom Tromey + + Document GDB extensions to DWARF .debug_names + GDB's new .debug_names implementation uses some extensions. This + patch adds some documentation on this to the manual. + + Reviewed-By: Eli Zaretskii + +2024-01-18 Tom Tromey + + Remove IS_ENUM_CLASS from cooked_index_flag + I noticed that cooked_index_flag::IS_ENUM_CLASS is not needed. This + patch removes it. + +2024-01-18 Tom Tromey + + Refactor quick-function installation in DWARF reader + While working on the previous patch, I saw that the handling of + quick-function installation could be unified + dwarf2_initialize_objfile. In particular, at the end of the function, + if there is an index table, then it can be used to create the quick + function object. + + This cleanup will be useful when rewriting the .debug_names reader. + +2024-01-18 Tom Tromey + + Refactor 'maint set dwarf synchronous' handling + The new .debug_names reader will reuse the background reading + infrastructure of the cooked index code. In order to share the + handling of 'maint set dwarf synchronous' -- and to avoid having to + export this global -- this patch refactors this to be handled directly + in dwarf2_initialize_objfile. + +2024-01-18 Nick Clifton + + Add note to translators not to translate z/Architecture + + Updated translations for various sub-directories + +2024-01-18 Tom de Vries + + [gdb/testsuite] Call ldd --version in gdb.testsuite/dump-system-info.exp + Once in a while I'm looking at the gdb.log of an entire testsuite run, and I'm + trying to establish what glibc version is used. Sometimes this is possible, + sometimes not. + + Make this easy by calling ldd --version in test-case + gdb.testsuite/dump-system-info.exp, which for instance on openSUSE Leap 15.4 + gives: + ... + $ ldd --version + ldd (GNU libc) 2.31 + ... + $ + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-18 Mike Frysinger + + sim: ppc: implement 128-bit register read/writes with sim-endian APIs + We have APIs in sim-endian for working with 128-bit values like this code + is already doing for 8/16/32/64-bit values. Switch over to that to make + it a bit simpler, and drop the WITH_ALTIVEC check. The code probably is + only used when altivec is enabled, but it doesn't add much to always + compile it in, and avoids #ifdef rot by not actually compiling it. + +2024-01-18 Mike Frysinger + + sim: ppc: switch register read/writes to union to avoid aliasing issues + This code creates a small buffer on the stack w/alloca, then proceeds to + write to it with a cast to a pointer type based on the register type, then + reads from it with a cast to a pointer type based on the register size. + gcc will flags only one of these lines as "maybe used uninitialized", but + it seems to track back to this memory abuse. + + Create a large union with all the possible types that this code will read + or write as, and then use those. It's a bit ugly, but is probably better + than using raw memcpy's everywhere. + +2024-01-18 GDB Administrator + + Automatic date update in version.in + +2024-01-17 Alan Modra + + PR30824 internal error with -z pack-relative-relocs + This corrects a counting problem, where prior to relocate_section relr + encoded relative relocs were allowed when it was known they were on + even boundaries, but relocate_section can only put relative relocs + (non-relr) on eight byte boundaries. + + PR 30824 + * elf64-ppc.c (RELR_ALIGN): Define, use throughout. + (maybe_relr): New function, use throughout. + +2024-01-17 H.J. Lu + + Update x86-64: Add -z mark-plt and -z nomark-plt + Pass --hash-style=both to ld for -z mark-plt tests to support linker + configured with --enable-default-hash-style=gnu. + + * testsuite/ld-x86-64/mark-plt-1b-x32.d: Pass --hash-style=both + to ld. + * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. + +2024-01-17 Andrew Burgess + + gdb/testsuite: handle long filenames in gdb.base/startup-with-shell.exp + I got a report of a failure from Linaro's CI testing for the test + gdb.base/startup-with-shell.exp. + + Looking at the log I see this: + + (gdb) PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: inferior started + print argv[1] + $1 = 0xfffed978 "/home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gdb-gdb.git~master/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: first argument expanded + + Notice that the value of $1 was truncated (indicated by the trailing + ellipses), and as a result it isn't going to match the expected output + pattern. + + Avoid this by adding a call to 'set print characters unlimited' which + allows GDB to print strings of any length. + + Approved-By: Tom de Vries + +2024-01-17 Tom Tromey + + Fix crash in struct-with-sig-2.exp with debug-names target board + When I run the struct-with-sig-2.exp test with the .debug_names-using + target board, I see a gdb crash. This happens because the reader + throws an exception without calling finalize_all_units. This causes + an assertion failure later because the number of CUs and TUs doesn't + match. + + The fix is to clear 'all_units' on failure. + + Approved-By: Tom de Vries + +2024-01-17 Nick Clifton + + Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling. + +2024-01-17 Xi Ruoyao + + LoongArch: Adapt R_LARCH_{PCALA,GOT,TLS_IE,TLS_DESC}64_* handling per psABI v2.30 + In LoongArch psABI v2.30, an offset (-8 for LO20 and -12 for HI12) + should be applied on PC for these reloc types to avoid wrong relocation + when the instruction sequence crosses a page boundary. + + The lld linker has already adapted the change. Make it for the bfd + linker too. + + Link: https://github.com/loongson/la-abi-specs/releases/v2.30 + Link: https://github.com/loongson-community/discussions/issues/17 + Link: https://github.com/llvm/llvm-project/pull/73387 + +2024-01-17 GDB Administrator + + Automatic date update in version.in + +2024-01-16 GDB Administrator + + Automatic date update in version.in + +2024-01-15 Simon Marchi + + gdb/testsuite: remove spurious $ in save_vars + I noticed that running the whole testsuite in serial mode (which means + all the .exp files are ran in the same TCL environment, one after the + other) with the native-extended-gdbserver board caused some weird + failures, for instance a lot of internal errors in the reverse tests, + like: + + continue^M + Continuing.^M + /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/native-extended-gdbserver/src/binutils-gdb/gdb/remot e.c:6922: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.reverse/break-precsave.exp: run to end of main (GDB internal error) + + This only happens after running gdb.multi/attach-while-running.exp. + That test does not restore GDBFLAGS properly when it's done, it leaves + `-ex \"maint set target-non-stop on\""` in there, which breaks some + subsequent tests. The problem is that this line: + + save_vars { $::GDBFLAGS } { + + should not use a `$` before the variable name. Passes the content of + `::GDBFLAGS` to save_vars, which is not what we want. We want to pass + the `::GDBFLAGS` string. Fix that. + + Change-Id: I5ad32c527795fd10d0d94020e4fd15cebaca3a77 + +2024-01-15 Tom Tromey + + Remove addrmap_fixed::set_entry + It occurred to me that there is no reason for addrmap_fixed::set_entry + to exist. This patch removes it and removes the abstract virtual + function from the base class. This then required a few minor changes + in the DWARF reader. I consider this a type-safety improvement. + + Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-01-15 Simon Marchi + + gdb: remove unnecessary braces + Change-Id: I5e96c0f38aa788462ab19a9becfe22030e913c2a + +2024-01-15 H.J. Lu + + x86-64: Skip SCFI tests for x32 targets + Since SCFI isn't supported on x32: + + Fatal error: SCFI is not supported for this ABI + + skip SCFI tests for x32 targets. + + PR gas/31245 + * testsuite/gas/scfi/x86_64/scfi-x86-64.exp: Skip for x32 + targets. + +2024-01-15 Nick Clifton + + Update HOWTO document after creating the 2.42 branch + + Change version to 2.42.50 and regenerate files + +2024-01-15 Mark Wielaard + + Regenerate two Makefile.in files to update Copyright headers + commit 1d506c26d9772bcd84e1a7b3a8c8c5bc602dbf61 + Update copyright year range in header of all files managed by GDB + updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in + also sim/Makefile.in was updated, but the Copyright hunks/years + were off. The first hunk comes from automake 1.15.1 header-vars.am + and so should have 2017 as last year, the second hunk does come from + sim/Makefile.am and so should have 2024 as last year. + + * gnulib/Makefile.in: Regenerate. + * sim/Makefile.in: Likewise. + +2024-01-15 Nick Clifton + + Add markers for 2.42 branch + + Update branch/release creation documentation + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Regenerate aarch64-*-2.c files + +2024-01-15 Victor Do Nascimento + Srinath Parvathaneni + + aarch64: rcpc3: Add FP load/store insns + Along with the relevant unit-tests, this adds the following rcpc3 + instructions: + + STL1 { .D }[], [] + LDAP1 { .D }[], [] + + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR
, [{, #}] + LDAPUR , [{, #}] + + STLUR , [{, #}] + STLUR , [{, #}] + STLUR , [{, #}] + STLUR
, [{, #}] + STLUR , [{, #}] + + with `#' taking on a signed 8-bit integer value in the range + [-256,255] and `index' the values 0 or 1. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add integer load/store insns + Along with the relevant unit tests and updates to the existing + regression tests, this adds support for the following novel rcpc3 + insns: + + LDIAPP , , [] + LDIAPP , , [], #8 + LDIAPP , , [] + LDIAPP , , [], #16 + + STILP , , [] + STILP , , [, #-8]! + STILP , , [] + STILP , , [, #-16]! + + LDAPR , [], #4 + LDAPR , [], #8 + + STLR , [, #-4]! + STLR , [, #-8]! + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define RCPC3_INSN macro + This patch adds the necessary macro for encoding FEAT_RCPC3-dependent + instructions in Binutils. + + aarch64: rcpc3: add support in general_constraint_met_p + Given the introduction of the new address operand types for rcpc3 + instructions, this patch adds the necessary logic to teach + `general_constraint_met_p` how to proper handle these. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: New RCPC3_ADDR operand types + The particular choices of address indexing, along with their encoding + for RCPC3 instructions lead to the requirement of a new set of operand + descriptions, along with the relevant inserter/extractor set. + + That is, for the integer load/stores, there is only a single valid + indexing offset quantity and offset mode is allowed - The value is + always equivalent to the amount of data read/stored by the + operation and the offset is post-indexed for Load-Acquire RCpc, and + pre-indexed with writeback for Store-Release insns. + + This indexing quantity/mode pair is selected by the setting of a + single bit in the instruction. To represent these insns, we add the + following operand types: + + - AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND + - AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB + + In the case of loads and stores involving SIMD/FP registers, the + optional offset is encoded as an 8-bit signed immediate, but neither + post-indexing or pre-indexing with writeback is available. This + created the need for an operand type similar to + AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should + not be checked. + + We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a + variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define address operand fields and inserter/extractors + Beyond the need to encode any registers involved in data transfer and + the address base register for load/stores, it is necessary to specify + the data register addressing mode and whether the address register is + to be pre/post-indexed, whereby loads may be post-indexed and stores + pre-indexed with write-back. + + The use of a single bit to specify both the indexing mode and indexing + value requires a novel function be written to accommodate this for + address operand insertion in assembly and another for extraction in + disassembly, along with the definition of two insn fields for use with + these instructions. + + This therefore defines the following functions: + + - aarch64_ins_rcpc3_addr_opt_offset + - aarch64_ins_rcpc3_addr_offset + - aarch64_ext_rcpc3_addr_opt_offset + - aarch64_ext_rcpc3_addr_offset + + It extends the `do_special_{encoding|decoding}' functions and defines + two rcpc3 instruction fields: + + - FLD_opc2 + - FLD_rcpc3_size + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Create implicit load/store size calc function + The allowed immediate offsets in integer rcpc3 load store instructions + are not encoded explicitly in the instruction itself, being rather + implicitly equivalent to the amount of data loaded/stored by the + instruction. + + This leads to the requirement that this quantity be calculated based on + the number of registers involved in the transfer, either as data + source or destination registers and their respective qualifiers. + + This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)' + implemented here, using a cumulative sum of qualifier sizes preceding + the address operand in the OPNDS operand list argument. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add +rcpc3 architectural feature support flag + Indicating the presence of the Armv8.2-a feature adding further + support for the Release Consistency Model, the `+rcpc3' architectural + extension flag is added to the list of possible `-march' options in + Binutils, together with the necessary macro for encoding rcpc3 + instructions. + +2024-01-15 Mark Wielaard + + bfd: riscv_maybe_function_sym check _bfd_elf_is_local_label_name + This fixes the ld "Handle no DWARF information" testcase. Which + currently fails on riscv because a local label name is assumed + to be the current function name. + + bfd/ChangeLog: + + * elfnn-riscv.c (riscv_maybe_function_sym): Also check + _bfd_elf_is_local_label_name. + +2024-01-15 Andrew Carlotti + + aarch64: Fix tlbi and tlbip instructions + There are some tlbi operations that don't have a corresponding tlbip operation, + but we were incorrectly using the same list for both. Add the missing tlbi + *nxs operations, and use the F_REG_128 flag to filter tlbi operations that + don't have a tlbip analogue. For increased clarity, I have also used a macro + to reduce duplication between the 'nxs' and non-'nxs' variants, and added a + test to verify that no invalid combinations are accepted. + + Additionally, fix two missing checks for AARCH64_OPND_SYSREG_TLBIP that were + preventing disassembly of tlbip instructions. + +2024-01-15 Andrew Carlotti + + aarch64: Refactor aarch64_sys_ins_reg_supported_p + Add an aarch64_feature_set field to aarch64_sys_ins_reg, and use this for + feature checks instead of testing against a list of operand codes. + +2024-01-15 Nick Clifton + + nm: Replace --with-symbol-versions with --without-symbol-versions in --help output + PR 31243 + nm: Fix --help output + +2024-01-15 Andrew Carlotti + + aarch64: Remove unused BTI feature bit + OK for master? + +2024-01-15 Nick Clifton + + Add generated source files and fix thinko in aarch64-asm.c + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 Contiguous load/store instructions. + Hi, + + This patch add support for SVE2.1 instructions ld1q, + ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + PATCH 5/6][Binutils] aarch64: Add SVE2.1 fmin and fmax instructions. + Hi, + + This patch add support for SVE2.1 instruction faddqv, + fmaxnmqv, fmaxqv, fminnmqv and fminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 dupq, eorqv and extq instructions. + Hi, + + This patch add support for SVE2.1 instruction dupq, eorqv and extq. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE2p1. + Hi, + + This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature + along with +sve2p1 optional flag to enabe this feature. + + Also support for following SVE2p1 instructions is added + addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME2p1 instructions. + Hi, + + This patch add support for FEAT_SME2p1 and "movaz" instructions + along with the optional flag +sme2p1. + + Following "movaz" instructions are add: + Move and zero two ZA tile slices to vector registers. + Move and zero four ZA tile slices to vector registers. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_B16B16 instructions. + Hi, + + This patch add support for SVE2.1 and SME2.1 non-widening BFloat16 + (FEAT_B16B16) instructions. + + Following instructions predicated, unpredicated and indexed + variants are added in this patch. + + bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm, + bfmla,bfmls,bfmul and bfsub. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Indu Bhagat + + gas/NEWS: announce the new SCFI command line option + +2024-01-15 Indu Bhagat + + gas: testsuite: add an x86 testsuite for SCFI + The testsuite for SCFI contains target-specific tests. + + When a test is executed with --scfi=experimental command line option, + the CFI annotations in the test .s files are skipped altogether by the + GAS for processing. The CFI directives in the input assembly files are, + however, validated by running the assembler one more time without + --scfi=experimental. + + Some testcases are used to highlight those asm constructs that the SCFI + machinery in GAS currently does not support: + + - Only System V AMD64 ABI is supported for now. Using either --32 or + --x32 with SCFI results in hard error. + See scfi-unsupported-1.s. + + - Untraceable stack-pointer manipulation in function epilougue and prologue. + See scfi-unsupported-2.s. + + - Using Dynamically Realigned Arguement Pointer (DRAP) register to + realign the stack. For SCFI, the CFA must be only REG_SP or REG_FP + based. See scfi-unsupported-drap-1.s + + Some testcases are used to highlight some diagnostics that the SCFI + machinery in GAS currently issues, with an intent to help user correct + inadvertent errors in their hand-written asm. An error is issued when + GAS finds that input asm is not amenable to correct CFI synthesis. + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + + In case of (#2) and (#3), SCFI generation is skipped for the respective + function. Above is a subset of the warnings/errors implemented in the + code. + + gas/testsuite/: + * gas/scfi/README: New test. + * gas/scfi/x86_64/ginsn-add-1.l: New test. + * gas/scfi/x86_64/ginsn-add-1.s: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: New test. + * gas/scfi/x86_64/ginsn-pop-1.l: New test. + * gas/scfi/x86_64/ginsn-pop-1.s: New test. + * gas/scfi/x86_64/ginsn-push-1.l: New test. + * gas/scfi/x86_64/ginsn-push-1.s: New test. + * gas/scfi/x86_64/scfi-add-1.d: New test. + * gas/scfi/x86_64/scfi-add-1.l: New test. + * gas/scfi/x86_64/scfi-add-1.s: New test. + * gas/scfi/x86_64/scfi-add-2.d: New test. + * gas/scfi/x86_64/scfi-add-2.l: New test. + * gas/scfi/x86_64/scfi-add-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.s: New test. + * gas/scfi/x86_64/scfi-cfg-1.d: New test. + * gas/scfi/x86_64/scfi-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-cfg-2.d: New test. + * gas/scfi/x86_64/scfi-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.s: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.s: New test. + * gas/scfi/x86_64/scfi-cofi-1.d: New test. + * gas/scfi/x86_64/scfi-cofi-1.l: New test. + * gas/scfi/x86_64/scfi-cofi-1.s: New test. + * gas/scfi/x86_64/scfi-diag-1.l: New test. + * gas/scfi/x86_64/scfi-diag-1.s: New test. + * gas/scfi/x86_64/scfi-diag-2.l: New test. + * gas/scfi/x86_64/scfi-diag-2.s: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.l: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.s: New test. + * gas/scfi/x86_64/scfi-enter-1.d: New test. + * gas/scfi/x86_64/scfi-enter-1.l: New test. + * gas/scfi/x86_64/scfi-enter-1.s: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.l: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-5.s: New test. + * gas/scfi/x86_64/scfi-lea-1.d: New test. + * gas/scfi/x86_64/scfi-lea-1.l: New test. + * gas/scfi/x86_64/scfi-lea-1.s: New test. + * gas/scfi/x86_64/scfi-leave-1.d: New test. + * gas/scfi/x86_64/scfi-leave-1.l: New test. + * gas/scfi/x86_64/scfi-leave-1.s: New test. + * gas/scfi/x86_64/scfi-pushq-1.d: New test. + * gas/scfi/x86_64/scfi-pushq-1.l: New test. + * gas/scfi/x86_64/scfi-pushq-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-1.d: New test. + * gas/scfi/x86_64/scfi-pushsection-1.l: New test. + * gas/scfi/x86_64/scfi-pushsection-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-2.d: New test. + * gas/scfi/x86_64/scfi-pushsection-2.l: New test. + * gas/scfi/x86_64/scfi-pushsection-2.s: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.d: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.l: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.s: New test. + * gas/scfi/x86_64/scfi-simple-1.d: New test. + * gas/scfi/x86_64/scfi-simple-1.l: New test. + * gas/scfi/x86_64/scfi-simple-1.s: New test. + * gas/scfi/x86_64/scfi-simple-2.d: New test. + * gas/scfi/x86_64/scfi-simple-2.l: New test. + * gas/scfi/x86_64/scfi-simple-2.s: New test. + * gas/scfi/x86_64/scfi-sub-1.d: New test. + * gas/scfi/x86_64/scfi-sub-1.l: New test. + * gas/scfi/x86_64/scfi-sub-1.s: New test. + * gas/scfi/x86_64/scfi-sub-2.d: New test. + * gas/scfi/x86_64/scfi-sub-2.l: New test. + * gas/scfi/x86_64/scfi-sub-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-3.l: New test. + * gas/scfi/x86_64/scfi-unsupported-3.s: New test. + * gas/scfi/x86_64/scfi-unsupported-4.l: New test. + * gas/scfi/x86_64/scfi-unsupported-4.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: New file. + +2024-01-15 Indu Bhagat + + opcodes: i386-reg.tbl: Add a comment to reflect dependency on ordering + The ginsn representation keeps the DWARF register number of the + operands. The API ginsn_dw2_regnum relies on the the relative ordering + of these register entries in the table. Add a comment to make it clear. + + opcodes/ + * i386-reg.tbl: Add a comment. + +2024-01-15 Indu Bhagat + + gas: doc: update documentation for the new listing option + Add a new listing option, -i, to emit ginsn in the listing output. We + may also emit other SCFI information if necessary in the future. + + ginsn are most useful when seen alongside the assembly instructions. + Hence, they are emitted when the user includes the assembly instructions + in the listing output, i.e., "-ali=FILE". + + gas/doc/: + * as.texi: Add documentation for the new listing option, -i. + +2024-01-15 Indu Bhagat + + gas: x86: synthesize CFI for hand-written asm + This patch adds support in GAS to create generic GAS instructions + (a.k.a., the ginsn) for the x86 backend (AMD64 ABI only at this time). + Using this ginsn infrastructure, GAS can then synthesize CFI for + hand-written asm for x86_64. + + A ginsn is a target-independent representation of the machine + instructions. One machine instruction may need one or more ginsn. + + This patch also adds skeleton support for printing ginsn in the listing + output for debugging purposes. + + Since the current use-case of ginsn is to synthesize CFI, the x86 target + needs to generate ginsns necessary for the following machine + instructions only: + + - All change of flow instructions, including all conditional and + unconditional branches, call and return from functions. + - All register saves and unsaves to the stack. + - All instructions affecting the two registers that could potentially + be used as the base register for CFA tracking. For SCFI, the base + register for CFA tracking is limited to REG_SP and REG_FP only for + now. + + The representation of ginsn is kept simple: + + - GAS instruction has GINSN_NUM_SRC_OPNDS (defined to be 2 at this time) + number of source operands and one destination operand at this time. + - GAS instruction uses DWARF register numbers in its representation and + does not track register size. + - GAS instructions carry location information (file name and line + number). + - GAS instructions are ID's with a natural number in order of their + addtion to the list. This can be used as a proxy for the static + program order of the corresponding machine instructions. + + Note that, GAS instruction (ginsn) format does not support + GINSN_TYPE_PUSH and GINSN_TYPE_POP. Some architectures, like aarch64, + do not have push and pop instructions, but rather STP/LDP/STR/LDR etc. + instructions. Further these instructions have a variety of addressing + modes, like offset, pre-indexing and post-indexing etc. Among other + things, one of differences in these addressing modes is _when_ the addr + register is updated with the result of the address calculation: before + or after the memory operation. To best support such needs, the generic + instructions like GINSN_TYPE_LOAD, GINSN_TYPE_STORE together with + GINSN_TYPE_ADD, and GINSN_TYPE_SUB may be used. + + The functionality provided in ginsn.c and scfi.c is compiled in when a + target defines TARGET_USE_SCFI and TARGET_USE_GINSN. This can be + revisited later when there are other use-cases of creating ginsn's in + GAS, apart from the current use-case of synthesizing CFI for + hand-written asm. + + Support is added only for System V AMD64 ABI for ELF at this time. If + the user enables SCFI with --32, GAS issues an error: + + "Fatal error: SCFI is not supported for this ABI" + + For synthesizing (DWARF) CFI, the SCFI machinery requires the programmer + to adhere to some pre-requisites for their asm: + - Hand-written asm block must begin with a .type foo, @function + It is highly recommended to, additionally, also ensure that: + - Hand-written asm block ends with a .size foo, .-foo + + The SCFI machinery encodes some rules which align with the standard + calling convention specified by the ABI. Apart from the rules, the SCFI + machinery employs some heuristics. For example: + - The base register for CFA tracking may be either REG_SP or REG_FP. + - If the base register for CFA tracking is REG_SP, the precise amount of + stack usage (and hence, the value of REG_SP) must be known at all times. + - If using dynamic stack allocation, the function must switch to + FP-based CFA. This means using instructions like the following (in + AMD64) in prologue: + pushq %rbp + movq %rsp, %rbp + and analogous instructions in epilogue. + - Save and Restore of callee-saved registers must be symmetrical. + However, the SCFI machinery at this time only warns if any such + asymmetry is seen. + + These heuristics/rules are architecture-independent and are meant to + employed for all architectures/ABIs using SCFI in the future. + + gas/ + * Makefile.am: Add new files. + * Makefile.in: Regenerated. + * as.c (defined): Handle documentation and listing option for + ginsns and SCFI. + * config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end. + (obj_elf_type): Invoke ginsn_data_begin. + * config/tc-i386.c (x86_scfi_callee_saved_p): New function. + (ginsn_prefix_66H_p): Likewise. + (ginsn_dw2_regnum): Likewise. + (x86_ginsn_addsub_reg_mem): Likewise. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Likewise. + (x86_ginsn_move): Likewise. + (x86_ginsn_lea): Likewise. + (x86_ginsn_jump): Likewise. + (x86_ginsn_jump_cond): Likewise. + (x86_ginsn_enter): Likewise. + (x86_ginsn_safe_to_skip): Likewise. + (x86_ginsn_unhandled): Likewise. + (x86_ginsn_new): New functionality to generate ginsns. + (md_assemble): Invoke x86_ginsn_new. + (s_insn): Likewise. + (i386_target_format): Add hard error for usage of SCFI with non AMD64 ABIs. + * config/tc-i386.h (TARGET_USE_GINSN): New definition. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): Likewise. + (REG_FP): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (x86_scfi_callee_saved_p): Likewise. + * gas/listing.h (LISTING_GINSN_SCFI): New define for ginsn and + SCFI. + * gas/read.c (read_a_source_file): Close SCFI processing at end + of file read. + * gas/scfidw2gen.c (scfi_process_cfi_label): Add implementation. + (scfi_process_cfi_signal_frame): Likewise. + * subsegs.h (struct frch_ginsn_data): New forward declaration. + (struct frchain): New member for ginsn data. + * gas/subsegs.c (subseg_set_rest): Initialize the new member. + * symbols.c (colon): Invoke ginsn_frob_label to convey + user-defined labels to ginsn infrastructure. + * ginsn.c: New file. + * ginsn.h: New file. + * scfi.c: New file. + * scfi.h: New file. + +2024-01-15 Indu Bhagat + + opcodes: x86: new marker for insns that implicitly update stack pointer + Some x86 instructions affect the stack pointer implicitly. Add a new + operand constraint to reflect this. This will be useful for SCFI + implmentation to ensure its correctness. + + Mark all push, pop, call, ret, enter, leave, INT, iret instructions. + + opcodes/ + * i386-gen.c: Update opcode_modifiers. + * i386-opc.h: Add a new constraint. + * i386-opc.tbl: Update the affected instructions. + * i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + opcodes: gas: x86: define and use Rex2 as attribute not constraint + Rex2 is currently an operand constraint. For the upcoming SCFI + implementation in GAS, we need to identify operations which implicitly + update the stack pointer. An operand constraint enumerator for implicit + stack op seems more appropriate than an attribute. However, two opcodes + currently necessitate both Rex2 and an implicit stack op marker; this + prompts revisiting the current representations a bit. + + Make Rex2 a standalone attribute, so that later a new operand constraint + may be added for IMPLICIT_STACK_OP. + + ChangeLog: + * gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check. + * opcodes/i386-gen.c: Add a new BITFIELD for Rex2. + * opcodes/i386-opc.h (REX2_REQUIRED): Remove. + * opcodes/i386-opc.tbl: Remove Rex2 operand constraint. + * opcodes/i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + gas: scfidw2gen: new functionality to prepare for SCFI + Define a new set of handlers for CFI directives for the purpose of SCFI. + The SCFI machinery ignores many of the user-specified CFI direcives when + SCFI is in effect. A warning ("Warning: SCFI ignores most + user-specified CFI directives") is issued once per file. The following + CFI directives, however, are not ignored: + - .cfi_sections + - .cfi_label + - .cfi_signal_frame + + gas/ + * Makefile.am: Add new files to GAS_CFILES and HFILES. + * Makefile.in: Likewise. + * gas/read.c (scfi_pop_insert): New define. + (pobegin): Use the SCFI handlers. + * scfidw2gen.c: New file. + * scfidw2gen.h: New file. + +2024-01-15 Indu Bhagat + + gas: add new command line option --scfi=experimental + When the command line option --scfi=experimenta is passed to the GNU + assembler, it will synthesize DWARF call frame information (CFI) for the + input assembly. + + The option --scfi=experimental will also ignore most of the existing + .cfi_* directives, if already contained in the provided input file. + Only the following CFI directives will not be ignored: + - .cfi_sections, + - .cfi_label, + - .cfi_signal_frame + + To use SCFI, a target will need to: + - define TARGET_USE_SCFI and TARGET_USE_GINSN, and other necessary + definitions, + - provide means to help GAS understand the target specific instruction + semantics by creating ginsns. + + The upcoming support for SCFI is inteded to be experimental, hence the + option --scfi=experimental. The --scfi= may see more options like + --scfi=[all,none] added in future, once the SCFI support in GAS is + mature and robust. The offering may also see for example, an + --scfi=inline option for dealing with inline asm may be added in the + future. In --scfi=inline option, the GNU assembler may consume (and not + ignore) the compiler generated CFI for the code surrounding the inline + asm. + + Also document the option. + + gas/ + * as.c (show_usage): Add support for --scfi=experimental. + (parse_args): Likewise. + * as.h (enum synth_cfi_type): Define new type. + * doc/as.texi: Document the new option. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: externalize the all_cfi_sections + gas/ + * dw2gencfi.h: Declare all_cfi_sections as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen + scfidw2gen will use this for processing the .cfi_sections directive. + + gas/ + * dw2gencfi.c (dot_cfi_sections): Not static anymore. + * dw2gencfi.h (dot_cfi_sections): Mark as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: move some tc_* defines to the header file + Move the following three defines to the header file, so the SCFI + machinery can use them: + - tc_cfi_frame_initial_instructions + - tc_cfi_startproc + - tc_cfi_endproc + + gas/ + * dw2gencfi.c: Move from ... + * dw2gencfi.h: ... to here. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose a new cfi_set_last_fde API + gas/ + * dw2gencfi.c (cfi_set_last_fde): New definition. + (dot_cfi_endproc): Use it. + (dot_cfi_fde_data): Likewise. + (dot_cfi_inline_lsda): Likewise. + * dw2gencfi.h (struct fde_entry): New declaration. + (cfi_set_last_fde): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: use all_cfi_sections instead of cfi_sections + The code in dw2gencfi.c was checking variable cfi_sections and + all_cfi_sections seemingly randomly. Accessing all_cfi_sections seems + to the correct variable to access. + + The data in cfi_sections has already been propagated to all_cfi_sections + once cfi_dot_startproc () has been called. + + gas/ + * dw2gencfi.c (dot_cfi_startproc): Use all_cfi_sections + instead. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections + cfi_sections_set is best set to true in cfi_dot_startproc (). Setting + it to true again in other APIs (dot_cfi_endproc, dot_cfi_fde_data, and + cfi_finish) is unnecessary. Also, move setting the global var + all_cfi_sections into cfi_set_sections (). + + gas/ + * dw2gencfi.c (cfi_set_sections): Set cfi_sections_set and + cfi_sections here. + (dot_cfi_startproc): Remove unnecessarily setting + cfi_set_sections to true. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + (cfi_finish): Likewise. + +2024-01-15 GDB Administrator + + Automatic date update in version.in + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.mi/mi-dprintf.exp with read1 + When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into: + ... + (gdb) ^M + PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop + -data-evaluate-expression stderr^M + ^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M + (gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check + ... + + The problem is in proc mi_gdb_is_stderr_available: + ... + proc mi_gdb_is_stderr_available {} { + set has_stderr_symbol false + gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" { + -re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" { + } + -re "$::mi_gdb_prompt$" { + set has_stderr_symbol true + } + } + ... + which uses a gdb_test_multiple that is supposed to use the mi prompt, but + doesn't use -prompt to indicate this. Consequently, the default patterns use + the regular gdb prompt, which trigger earlier than the two custom patterns + which use "$::mi_gdb_prompt$". + + Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments. + + While we're at it, make the gdb_test_multiple call a bit more readable by + using variables, and by using -wrap. + + Tested on x86_64-linux, with: + - gcc and clang (to trigger both the has_stderr_symbol true and false cases) + - make check and make check-read1. + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/namespace.exp with read1 + With check-read1 we run into: + ... + (gdb) break DNE>::DNE^M + Function "DNE>::DNE" not defined.^M + Make breakpoint pending on future shared library load? (y or [n]) y^M + Breakpoint 9 (DNE>::DNE) pending.^M + n^M + (gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt) + n^M + ... + + The question is supposed to be handled by the question and response arguments + to this gdb_test call: + ... + gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \ + "Make breakpoint pending on future shared library load?.*" "y" + ... + but both this and the builtin handling in gdb_test_multiple triggers. + + The cause of this is that the question argument regexp is incomplete. + + Fix this by making sure that the entire question is matched in the regexp: + ... + set yn_re [string_to_regexp {(y or [n])}] + ... + "Make breakpoint pending on future shared library load\\? $yn_re " "Y" + ... + + Tested on x86_64-linux. + +2024-01-14 GDB Administrator + + Automatic date update in version.in + +2024-01-13 Yang Liu + + gdb: RISC-V: Refine lr/sc sequence support + Per RISC-V spec, the lr/sc sequence can consist of up to 16 instructions, and we + cannot insert breakpoints in the middle of this sequence. Before this, we only + detected a specific pattern (the most common one). This patch improves this part + and now supports more complex pattern detection. + + Approved-By: Andrew Burgess + Reviewed-by: Palmer Dabbelt + +2024-01-13 Yang Liu + + Add myself to gdb/MAINTAINERS + +2024-01-13 Vladimir Mezentsev + + gprofng: 30889 can't compile without large file support + gprofng/ChangeLog + 2024-01-12 Vladimir Mezentsev + + PR 30889 + * src/util.h (O_LARGEFILE): Define to 0, if not defined. + +2024-01-13 GDB Administrator + + Automatic date update in version.in + +2024-01-12 Vladimir Mezentsev + + gprofng: fix 3 bugzillas against gp-display-html + Fix two cases where gp-display-html terminates prematurely because the + input format is not recognized. This problem occurs in the function + overview and caller-callee parts of the code. + The fix consists of new regular expressions and a different approach + in handling the input from gp-display-text. + Also fix a performance problem in the caller-callee part that has a + noticeable impact on the performance for large applications. + + gprofng/ChangeLog + 2024-01-10 Ruud van der Pas + + PR gprofng/30438 + PR gprofng/30439 + PR gprofng/30942 + * gp-display-html/gp-display-html.in: fixes the issues. + +2024-01-12 Dimitar Dimitrov + + sim: Fix compile errors + The following change broke simulator testsuite with host GCC 13: + commit 435ad222b3de93fa647fba7221eece36b1b395eb + sim: warnings: compile build tools with -Werror too + + Host GCC13 complains about missing function prototypes: + + binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes] + 26 | gen_struct (void) + | ^~~~~~~~~~ + + Fix by making the functions static, which instructs the compiler that + there is no need for a prototype. + +2024-01-12 David Faust + + bpf: fix relocation addend incorrect symbol value + Relocations installed by the BPF ELF backend were sometimes incorrectly + adding the symbol value to the relocation entry addend, when the correct + relocation value was already stored in the addend. This could lead to a + relocation effectively adding the symbol value twice. + + Fix that by making bpf_elf_generic_reloc () more similar to the flow of + bfd_install_relocation in the case where howto->install_addend is set, + which is how it ought to behave. + + bfd/ + * bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64) + (R_BPF_64_NODYLD32): Set partial_inplace to true. + * elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value + of the symbol when installing relocation. Copy some additional + logic from bfd_elf_generic_reloc. + + gas/ + * testsuite/gas/bpf/bpf.exp: Run new test. + * testsuite/gas/bpf/elf-relo-1.d: New. + * testsuite/gas/bpf/elf-relo-1.s: New. + +2024-01-12 Andrew Burgess + + gdb/testsuite: fix failure in gdb.python/py-inferior.exp + After this commit: + + commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72 + Date: Thu Jan 4 10:01:24 2024 +0000 + + gdb/python: add gdb.InferiorThread.__repr__() method + + failures were reported for gdb.python/py-inferior.exp. + + The test grabs a gdb.InferiorThread object representing an inferior + thread, and then, later in the test, expects this Python object to + become invalid when the inferior thread has exited. + + The gdb.InferiorThread object was obtained from the list returned by + calling gdb.Inferior.threads(). + + The mistake I made in the original commit was to assume that the order + of the threads returned from gdb.Inferior.threads() somehow reflected + the thread creation order. Specifically, I was expecting the main + thread to be first in the list, and "other" threads to appear ... not + first. + + However, the gdb.Inferior.threads() function creates a list and + populates it from a map. The order of the threads in the returned + list has no obvious relationship to the thread creation order, and can + vary from host to host. + + On my machine the ordering was as I expected, so the test passed for + me. For others the ordering was not as expected, and it just happened + that we ended up recording the gdb.InferiorThread for the main thread. + + As the main thread doesn't exit (until the test is over), the + gdb.InferiorThread object never became invalid, and the test failed. + + Fixed in this commit by taking more care to correctly find a non-main + thread. I do this by recording the main thread early on (when there + is only one inferior thread), and then finding any thread that is not + this main thread. + + Then, once all of the secondary threads have exited, I know that the + second InferiorThread object I found should now be invalid. + + The test still passes for me, and I believe this should fix the issue + for everyone else too. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238 + +2024-01-12 Andrew Burgess + + Update copyright year range in header of all files managed by GDB + This commit is the result of the following actions: + + - Running gdb/copyright.py to update all of the copyright headers to + include 2024, + + - Manually updating a few files the copyright.py script told me to + update, these files had copyright headers embedded within the + file, + + - Regenerating gdbsupport/Makefile.in to refresh it's copyright + date, + + - Using grep to find other files that still mentioned 2023. If + these files were updated last year from 2022 to 2023 then I've + updated them this year to 2024. + + I'm sure I've probably missed some dates. Feel free to fix them up as + you spot them. + +2024-01-12 Andrew Carlotti + + aarch64: Remove unused code + Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was + already dead when it was first added. + + aarch64: Make FEAT_ASMv8p2 instruction aliases always available + There's no reason to disallow the aliases when the aliased instructions are + always available. The new behaviour matches existing LLVM behaviour. + + aarch64: Add +xs flag for existing instructions + Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of + "+d128". This is an incremental improvement; there are still some FEAT_XS tlbi + variants that are gated incorrectly or missing entirely. + + aarch64: Add +wfxt flag for existing instructions + + aarch64: Add +rcpc2 flag for existing instructions + + aarch64: Add +flagm2 flag for existing instructions + + aarch64: Add +frintts flag for existing instructions + + aarch64: Add +jscvt flag for existing fjcvtzs instruction + + aarch64: Fix option parsing to disallow prefixes of valid options + Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility + with Clang. + + aarch64: Add +fcma alias for +compnum + + aarch64: Fix +lse feature flag dependency + +2024-01-12 Andrew Burgess + + gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs + This commit updates the Python example code in the gdb.Progspace and + gdb.Objfile sections of the docs. Changes made: + + 1. Use @value{GDBP} for the GDB prompt rather than + hard-coding (gdB), + + 2. Use @group...@end group to split the example code into + unbreakable chunks, and + + 3. Add parenthesis to the Python print() calls in the examples. In + Python 2 it was OK to drop the parenthesis, but now GDB is Python 3 + only, example code should include the parenthesis. + + Approved-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/doc: add some notes on selecting suitable attribute names + In previous commits I've added Object.__dict__ support to gdb.Inferior + and gdb.InferiorThread, this is similar to the existing support for + gdb.Objfile and gdb.Progspace. + + This commit extends the documentation to offer the user some guidance + on selecting good names for their custom attributes so they + can (hopefully) avoid conflicting with any future attributes that GDB + might add. + + The rules I've proposed are: + + 1. Don't start user attributes with a lower case letter, all the + current GDB attributes start with a lower case letter, and I suspect + all future attributes would also start with a lower case letter, and + + 2. Don't start user attributes with a double underscore, this risks + conflicting with Python built in attributes (e.g. __dict__) - though + clearly the user would need to start and end with a double + underscore, but it seemed easier just to say no double underscores. + + I'm doing this as a separate commit as I've updated the docs for the + existing gdb.Objfile and gdb.Progspace so they all reference a single + paragraph on selecting attribute names. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.InferiorThread.__dict__ attribute + The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python + types already have a __dict__ attribute, which allows users to create + user defined attributes within the objects. This is useful if the + user wants to cache information within an object. + + This commit adds the same functionality to the gdb.InferiorThread + type. + + After this commit there is a new gdb.InferiorThread.__dict__ + attribute, which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> t = gdb.selected_thread() + >>> t._user_attribute = 123 + >>> t._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.Inferior.__dict__ attribute + The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have + a __dict__ attribute, which allows users to create user defined + attributes within the objects. This is useful if the user wants to + cache information within an object. + + This commit adds the same functionality to the gdb.Inferior type. + + After this commit there is a new gdb.Inferior.__dict__ attribute, + which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> i = gdb.selected_inferior() + >>> i._user_attribute = 123 + >>> i._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: remove users ability to create gdb.Progspace objects + I noticed that it is possible for the user to create a new + gdb.Progspace object, like this: + + (gdb) pi + >>> p = gdb.Progspace() + >>> p + + >>> p.is_valid() + False + + As the new gdb.Progspace object is not associated with an actual C++ + program_space object within GDB core, then the new gdb.Progspace is + created invalid, and there is no way in which the new object can ever + become valid. + + Nor do I believe there's anywhere in the Python API where it makes + sense to consume an invalid gdb.Progspace created in this way, for + example, the gdb.Progspace could be passed as the locus to + register_type_printer, but all that would happen is that the + registered printer would never be used. + + In this commit I propose to remove the ability to create new + gdb.Progspace objects. Attempting to do so now gives an error, like + this: + + (gdb) pi + >>> gdb.Progspace() + Traceback (most recent call last): + File "", line 1, in + TypeError: cannot create 'gdb.Progspace' instances + + Of course, there is a small risk here that some existing user code + might break ... but if that happens I don't believe the user code can + have been doing anything useful, so I see this as a small risk. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.Frame.__repr__() method + Add a gdb.Frame.__repr__() method. Before this patch we would see + output like this: + + (gdb) pi + >>> gdb.selected_frame() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_frame() + + + More verbose, but, I hope, more useful. + + If the gdb.Frame becomes invalid, then we will see: + + (gdb) pi + >>> invalid_frame_variable + + + which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.InferiorThread.__repr__() method + Add a gdb.InferiorThread.__repr__() method. Before this patch we + would see output like this: + + (gdb) pi + >>> gdb.selected_thread() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_thread() + + + More verbose, but, I hope, more useful. + + If the gdb.InferiorThread becomes invalid, then we will see: + + (gdb) pi + >>> invalid_thread_variable + + + Which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: hoist common invalid object repr code into py-utils.c + Many object types now have a __repr__() function implementation. A + common pattern is that, if an object is invalid, we print its + representation as: . + + I thought it might be a good idea to move the formatting of this + specific representation into a utility function, and then update all + of our existing code to call the new function. + + The only place where I haven't made use of the new function is in + unwind_infopy_repr, where we currently return a different string. + This case is a little different as the UnwindInfo is invalid because + it references a frame, and it is the frame itself which is invalid. + That said, I think it would be fine to switch to using the standard + format; if the UnwindInfo references an invalid frame, then the + UnwindInfo is itself invalid. But changing this would be an actual + change in behaviour, while all the other changes in this commit are + just refactoring. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb: add trailing '/' when using 'complete' with directory names + This patch contains work pulled from this previously proposed patch: + + https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/ + + But has been modified by me. Credit for the original idea and + implementation goes to Lancelot, any bugs in this new iteration belong + to me. + + Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is + empty other than the `foo' sub-directory, then currently within GDB, + if I type: + + (gdb) file /tmp/f + + and then hit TAB, GDB completes this to: + + (gdb) file /tmp/foo/ + + notice that not only did GDB fill in the whole of `foo', but GDB also + added a trailing '/' character. This is done within readline when the + path that was just completed is a directory. However, if I instead + do: + + (gdb) complete file /tmp/f + file /tmp/foo + + I now see the completed directory name, but the trailing '/' is + missing. The reason is that, in this case, the completions are not + offered via readline, but are handled entirely within GDB, and so + readline never gets the chance to add the trailing '/' character. + + The above patch added filename option support to GDB, which included + completion of the filename options. This initially suffered from the + same problem that I've outlined above, but the above patch proposed a + solution to this problem, but this solution only applied to filename + options (which have still not been added to GDB), and was mixed in + with the complete filename options support. + + This patch pulls out just the fix for the trailing "/" problem, and + applies it to GDB's general filename completion. This patch does not + add filename options to GDB, that can always be done later, but I + think this small part is itself a useful fix. + + One of the biggest changes I made in this version is that I got rid of + the set_from_readline member function, instead, I now pass the value + of m_from_readline into the completion_tracker constructor. + + I then moved the addition of the trailing '/' into filename_completer + so that it is applied in the general filename completion case. I also + added a call to gdb_tilde_expand which was missing from the original + patch, I haven't tested, but I suspect that this meant that the + original patch would not add the trailing '/' if the user entered a + path starting with a tilde character. + + When writing the test for this patch I ran into two problems. + + The first was that the procedures in lib/completion-support.exp relied + on the command being completed for the test name. This is fine for + many commands, but not when completing a filename, if we use the + command in this case the test name will (potentially) include the name + of the directory in which the test is being run, which means we can't + compare results between two runs of GDB from different directories. + + So in this commit I've gone through completion-support.exp and added a + new (optional) testname argument to many of the procedures, this + allows me to give a unique test name, that doesn't include the path + for my new tests. + + The second issue was in the procedure make_tab_completion_list_re, + this builds the completion list which is displayed after a double tab + when there are multiple possible completions. + + The procedure added the regexp ' +' after each completion, and then + added another ' +' at the very end of the expected output. So, if we + expected to match the name of two functions 'f1' and 'f2' the + generated regexp would be: 'f1 +f2 + +'. This would match just fine, + the actual output would be: 'f1 f2 ', notice that we get two spaces + after each function name. + + However, if we complete two directory names 'd1' and 'd2' then the + output will be 'd1/ d2/ '. Notice that now we only have a single + space between each match, however, we do get the '/' added instead. + + What happens is that when presenting the matches, readline always adds + the appropriate trailing character; if we performed tab completion of + 'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with + a trailing space added. However, if we complete 'file d1' then we get + 'file d1/'. Then readline is adding a single space after each + possible match, including the last one, which accounts for the + trailing space character. + + To resolve this I've simply remove the addition o the second ' +' + within make_tab_completion_list_re, for the function completion + example I gave above the expected pattern is now 'f1 +f2 +', which for + the directory case we expect 'd1/ +d2/ +', both of which work just + fine. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265 + Co-Authored-By: Lancelot SIX + Approved-By: Tom Tromey + Reviewed-By: John Baldwin + +2024-01-12 Andrew Burgess + + gdb/python: New InferiorThread.ptid_string attribute + This commit adds a new InferiorThread.ptid_string attribute. This + read-only attribute contains the string returned by target_pid_to_str, + which actually converts a ptid (not pid) to a string. + + This is the string that appears (at least in part) in the output of + 'info threads' in the 'Target Id' column, but also in the thread + exited message that GDB prints. + + Having access to this string from Python is useful for allowing + extensions identify threads in a similar way to how GDB core would + identify the thread. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Tom de Vries + + [gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp + In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is + missing here after the unsupported: + ... + if { ![is_x86_64_m64_target] } { + unsupported "unsupported architecture" + } + ... + and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3 + FAILs. + + Fix this by simply using require: + ... + require is_x86_64_m64_target + ... + + Tested on x86_64-linux and aarch64-linux. + +2024-01-12 Indu Bhagat + + gas: sframe: warn when skipping SFrame FDE generation + Fix PR gas/31213. + + gas/ + PR gas/31213 + * gen-sframe.c (sframe_do_cfi_insn): Add new warning. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Test the new warning as well. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-01-12 mengqinggang + + LoongArch: Fix relaxation overflow caused by section alignment + When deleting NOP instructions addend by .align at second pass, this may cause + the PC decrease but the symbol address to remain unchanged due to section + alignment. + + To solve this question, we subtract a maximux alignment of all sections like + RISC-V. + +2024-01-12 Cui, Lili + + x86: Fix indentation and use true/false instead of 1/0 + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Fix indentation. + (check_EgprOperands): Use true/false instead of 1/0. + +2024-01-12 GDB Administrator + + Automatic date update in version.in + +2024-01-11 Simon Marchi + + gdb: fix frame passed to gdbarch_value_to_register in value_assign + Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum") + introduced an unexpected change in value_assign. It replaced + `get_prev_frame_always (next_frame)` with `next_frame`in the call to + gdbarch_value_to_register. + + This is the result of a merge error, since I previously had a patch to + change gdbarch_value_to_register to take the next frame, and later + decided to drop it. Revert that change. + + Add a test based on the DWARF assembler to expose the problem and test + the fix. I also tested on ppc64le to make sure the problem reported in + PR 31231 was fixed. + + Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le + On ppc64le-linux, I run into: + ... + (gdb) bt^M + #0 0x00000000100006dc in foobar (J=2)^M + #1 0x000000001000070c in prog ()^M + (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo + ... + + The test-case attemps to emulate additional entry points of a function, with + function bar having entry points foo and foobar: + ... + (gdb) p bar + $1 = {void (int, int)} 0x1000064c + (gdb) p foo + $2 = {void (int, int)} 0x10000698 + (gdb) p foobar + $3 = {void (int)} 0x100006d0 + ... + + However, when setting a breakpoint on the entry point foo: + ... + (gdb) b foo + Breakpoint 1 at 0x100006dc + ... + it ends up in foobar instead of in foo, due to prologue skipping, and + consequently the backtrace show foobar instead foo. + + The problem is that the test-case does not emulate an actual prologue at each + entry point. + + Fix this by disabling the prologue skipping when setting a breakpoint, using + "break *foo". + + Tested on ppc64le-linux and x86_64-linux. + + Tested-By: Guinevere Larsen + Approved-By: Ulrich Weigand + + PR testsuite/31232 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Extend gdb.base/kill-during-detach.exp + I ran into the following FAIL: + ... + (gdb) python kill_and_detach()^M + Traceback (most recent call last):^M + File "", line 1, in ^M + File "", line 7, in kill_and_detach^M + gdb.error: Selected thread is running.^M + Error while executing Python code.^M + (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \ + python kill_and_detach() + ... + + The FAIL happens as follows: + - gdb is debugging a process A + - a checkpoint is created, in other words, fork is called in the inferior, + after which we have: + - checkpoint 0 (the fork parent, process A), and + - checkpoint 1 (the fork child, process B). + - during checkpoint creation, lseek is called in the inferior (process A) for + all file descriptors, and it returns != -1 for at least one file descriptor. + - the process A continues in the background + - gdb detaches, from process A + - gdb switches to process B, in other words, it restarts checkpoint 1 + - while restarting checkpoint 1, gdb tries to call lseek in the inferior + (process B), but this fails because gdb incorrectly thinks that inferior B + is running. + + This happens because linux_nat_switch_fork patches the pid of process B into + the current inferior and current thread which where originally representing + process A. So, because process A was running in the background, the + thread_info fields executing and resumed are set accordingly, but they are not + correct for process B. + + There's a line in fork_load_infrun_state that fixes up the thread_info field + stop_pc, so fix this by adding similar fixups for the executing and resumed + fields alongside. + + The FAIL did not always reproduce, so extend the test-case to reliably + trigger this scenario. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31203 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203 + +2024-01-11 changjiachen + + LoongArch: ld: Adjusted some code order in relax.exp. + ld/testsuite/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test. + +2024-01-11 Lulu Cai + + LoongArch: Discard extra spaces in objdump output + Due to the formatted output of objdump, some instructions + that do not require output operands (such as nop/ret) will + have extra spaces added after them. + + Determine whether to output operands through the format + of opcodes. When opc->format is an empty string, no extra + spaces are output. + +2024-01-11 Mike Frysinger + + sim: ppc: return register error when unhandled + We don't want to fallthru and use cooked_buf when we haven't initialized + it to anything. Returning 0 indicates the register wasn't recognized. + + sim: m32r: enable warnings in traps.c + File should be clean now! + +2024-01-11 Mike Frysinger + + sim: m32r: fixup some of the int<->pointer casts + The m32r trap code was written for a 32-bit Linux host (and really, one + whose Linux ABI matched pretty exactly). This has lead to conversions + between integers and pointers which breaks down hard on 64-bit hosts. + + Clean up some of the functions where possible to avoid unnecessary + conversions, use uintptr_t to cast 32-bit target pointers to host + pointers in some places, and just stub out a few functions that can't + easily be salvaged currently when sizeof(void*) is not 32-bits. This + is a bit ugly, but lets us enable warnings for the whole file. + +2024-01-11 Mike Frysinger + + sim: m32r: fix missing break statement + The ftime syscall should not fallthrough to the sync syscall. + Clearly the code was missing a break statement. + +2024-01-11 Mike Frysinger + + sim: m32r: migrate ftime() to clock_gettime() + The ftime() function has been deprecated since POSIX-1-2004, and + removed in POSIX.1-2008. It's also been deprecated/removed in glibc + since 2.33. POSIX has always said the function is not portable, and + its return value, timezone, and dstflag fields are unspecified. Even + if Linux/glibc & m32r had defined behavior, those aren't the host for + the sim runtime. + + So let's stop using the function and switch to clock_gettime. gnulib + already has detection support for it, and it's been around since at + least POSIX-1-2004. + +2024-01-11 Mike Frysinger + + sim: m32r: cleanup unused variables + We've been building this file with -Wno-error, so clean up unused + variable warnings. + + sim: igen: add printf attributes to the prototypes too + While gcc propagates the printf attribute via the typedef, clang + doesn't seem to, so add it to the prototypes themselves too. We + still keep it on the prototype for cases where it's used as a + variable. + +2024-01-11 Mike Frysinger + + gdbsupport: tighten up libiberty code a bit with dnl + No functional change here, just touch up generated output slightly. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + sim: build: switch to gdbsupport/libiberty.m4 + Leverage this common logic to find all the libiberty settings rather + than duplicate it ourselves. + + sim: ppc: rework defines.h to handle HAVE symbols defined to 0 + The HAVE_DECL_xxx defines are always defined to 0 or 1. The current + defines.h logic assumes every HAVE_xxx symbol is only defined iff it's + defined to 1 which causes this to break. Tweak the sed logic to only + match defines of 1. + +2024-01-11 Mike Frysinger + + gdb: libiberty: switch to AC_CHECK_DECLS_ONCE + Only check these decls once in case other m4 macros also look for them. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + gdb: move libiberty.m4 to gdbsupport + This is used by gdb, gdbsupport, and gdbserver. We want to use it + in the sim tree too. Move it to gdbsupport which is meant as the + common sharing space for these projects. + + Approved-By: Tom Tromey + +2024-01-11 GDB Administrator + + Automatic date update in version.in + +2024-01-10 Vladimir Mezentsev + + gprofng: add an examples directory + This directory contains example programs for the user to experiment with. + Initially there is one application written in C. The plan is to include + more examples, also in other langauges, over time. + In addition to the sources and a make file, a sample script how to make + a profile is included. There is also a README.md file. + + gprofng/ChangeLog + 2024-01-08 Ruud van der Pas + + * examples: Top level directory. + * examples/mxv-pthreads: Example program written in C. + +2024-01-10 Vladimir Mezentsev + + gprofng: 31123 improvements to hardware event implementation + Our hardware counter profiling is based on perf_event_open(). + Our HWC tables are absent for new machines. + I have added HWC tables for the following events: PERF_TYPE_HARDWARE, + PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. + + Did a little cleaning: marked the symbols as static, used Stringbuilder, + created a function to read /proc/cpuinfo. + + gprofng/ChangeLog + 2024-01-08 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. + * common/hwc_cpus.h: Declare a new function read_cpuinfo. + * common/hwcdrv.c: Add a new parameter in init_perf_event(). + * common/hwcentry.h: Add use_perf_event_type in Hwcentry. + * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, + type, config. + * common/hwctable.c: Add a new HWC table generic_list[]. + * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. + * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). + Add a new function read_cpuinfo. + +2024-01-10 Aditya Vidyadhar Kamath + + Fix AIX catchpoint warning during fork () event + In AIX we were missing some hooks needed to catch a fork () event + in rs6000-aix-nat.c. Due to their absence we were returning 1 while we + insert the breakpoint/catchpoint location. This patch is a fix to the same. + +2024-01-10 Nick Clifton + + Sync top level configure and makefiles + This update brings in the following commits from the gcc mainline: + + commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f + Author: Tom Tromey + Date: Tue Jan 9 06:25:26 2024 -0700 + + Pass GUILE down to subdirectories + + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb + Author: Pierre-Emmanuel Patry + Date: Wed Oct 25 13:06:48 2023 +0200 + + build: Add libgrust as compilation modules + + Define the libgrust directory as a host compilation module as well as + for targets. Disable target libgrust if we're not building target + libstdc++. + + commit 56ca59a03150cf44cea340f58967c990ed6bf43c + Author: Lewis Hyatt + Date: Thu Nov 16 11:18:37 2023 -0500 + + Makefile.tpl: Avoid race condition in generating site.exp from the top level + + A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of + a fresh build directory does not work reliably. That will spawn two + independent make processes inside the "gcc" directory, and each of those + will attempt to create site.exp if it doesn't exist and will interfere with + each other, producing often a corrupted or empty site.exp. Resolve that by + making these targets depend on a new phony target which makes sure site.exp + is created first before starting the recursive makes. + + commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1 + Author: Iain Sandoe + Date: Sun Mar 28 14:48:17 2021 +0100 + + Config,Darwin: Allow for configuring Darwin to use embedded runpath. + + Recent Darwin versions place contraints on the use of run paths + specified in environment variables. This breaks some assumptions + in the GCC build. + + This change allows the user to configure a Darwin build to use + '@rpath/libraryname.dylib' in library names and then to add an + embedded runpath to executables (and libraries with dependents). + + The embedded runpath is added by default unless the user adds + '-nodefaultrpaths' to the link line. + + For an installed compiler, it means that any executable built with + that compiler will reference the runtimes installed with the + compiler (equivalent to hard-coding the library path into the name + of the library). + + During build-time configurations any "-B" entries will be added to + the runpath thus the newly-built libraries will be found by exes. + + Since the install name is set in libtool, that decision needs to be + available here (but might also cause dependent ones in Makefiles, + so we need to export a conditional). + + This facility is not available for Darwin 8 or earlier, however the + existing environment variable runpath does work there. + + We default this on for systems where the external DYLD_LIBRARY_PATH + does not work and off for Darwin 8 or earlier. For systems that can + use either method, if the value is unset, we use the default (which + is currently DYLD_LIBRARY_PATH). + + commit 2551e10038a70901f30b2168e6e3af4536748f3c + Author: Sergei Trofimovich + Date: Mon Oct 2 12:08:17 2023 +0100 + + Makefile.tpl: disable -Werror for feedback stage [PR111663] + + Without the change profiled bootstrap fails for various warnings on + master branch as: + + $ ../gcc/configure + $ make profiledbootstrap + ... + gcc/genmodes.cc: In function ‘int main(int, char**)’: + gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] + ... + gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: + gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] + + The change removes -Werror just like autofeedback does today. + + commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a + Author: Thomas Schwinge + Date: Thu Jun 1 23:07:37 2023 +0200 + + Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] + + ..., where we need to use it (separate commits) for build-tree testing, similar + to 'gcc/Makefile.in:site.exp': + + # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation. + # They are passed first to allow individual tests to override them. + @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp + + PR testsuite/109951 + * Makefile.tpl (BASE_TARGET_EXPORTS): Add + 'SYSROOT_CFLAGS_FOR_TARGET'. + * Makefile.in: Regenerate. + +2024-01-10 Saurabh Jha + + gas: aarch64: Add system registers for Debug and PMU extensions + This patch adds support for the new AArch64 system registers that are part of the following extensions: + * FEAT_DEBUGv8p9 + * FEAT_PMUv3p9 + * FEAT_PMUv3_SS + * FEAT_PMUv3_ICNTR + * FEAT_SEBEP + +2024-01-10 Tom de Vries + + [gdb] Fix assertion failure for checkpoint delete 0 + When doing "checkpoint delete 0" we run into an assertion failure: + ... + +delete checkpoint 0 + inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed. + ... + + Fix this by handling the "pptid == null_ptid" case in + delete_checkpoint_command. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31209 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209 + +2024-01-10 Tom de Vries + + [gdb] Fix info checkpoints + Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info + checkpoints command: + ... + (gdb) info checkpoints^M + * 0 process 30570 (main process) at 0x0^M + 1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M + 2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M + 3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M + 4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M + 5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M + 6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M + 7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M + 8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M + 9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M + 10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M + ... + + According to the docs, each of these (0-10) is a checkpoint. + + But the pc address (as well as the file name and line number) is missing for + checkpoint 0. + + Fix this by sampling the pc value for the current process in + info_checkpoints_command, such that we have instead: + ... + * 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M + ... + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31211 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211 + +2024-01-10 Tom de Vries + + [gdb] Make variable printed bool in info_checkpoints_command + While reading info_checkpoints_command, I noticed variable printed: + ... + const fork_info *printed = NULL; + ... + for (const fork_info &fi : fork_list) + { + if (requested > 0 && fi.num != requested) + continue; + + printed = &fi; + ... + } + if (printed == NULL) + ... + has pointer type, but is just used as bool. + + Make this explicit by changing the variable type to bool. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + +2024-01-10 Tom de Vries + + gdb/symtab: Eliminate deferred_entry + Currently cooked_index entry creation is either: + - done immediately if the parent_entry is known, or + - deferred if the parent_entry is not yet known, and done later while + resolving the deferred entries. + + Instead, create all cooked_index entries immediately, and keep track of which + entries have a parent_entry that needs resolving later using the new + IS_PARENT_DEFERRED flag. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Make cooked_index_entry::parent_entry private + Make cooked_index_entry::parent_entry private, and add member functions to + access it. + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Allow changing of added cooked_index entries + Make cooked_index_storage::add and cooked_index_entry::add return a + "cooked_index_entry *" instead of a "const cooked_index_entry *". + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom Tromey + + Fix ASAN failure in DWO code + Simon pointed out that my recent change to the DWO code caused a + failure in ASAN testing. + + The bug here was I updated the code to use a different search type in + the hash table; but then did not change the search code to use + htab_find_slot_with_hash. + + Note that this bug would not be possible with my type-safe hash table + series, hint, hint. + + Approved-By: Simon Marchi + +2024-01-10 GDB Administrator + + Automatic date update in version.in + +2024-01-09 Tom Tromey + + Fix thread-less build + A user pointed out that the recent background DWARF reader series + broke the build when --disable-threading is in use. This patch fixes + the problem. I am checking it in. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223 + +2024-01-09 Tom Tromey + + Pass GUILE down to subdirectories + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Add GUILE. + (GUILE): New variable. + * Makefile.def (flags_to_pass): Add GUILE. + +2024-01-09 H.J. Lu + + ld: Add --enable-mark-plt configure option + Add --enable-mark-plt linker configure option to mark PLT entries with + DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by + default. + + * NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt. + * config.in: Regenerated. + * configure: Likewise. + * configure.ac: Add --enable-mark-plt. + (DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED. + * emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT): + Support DEFAULT_LD_Z_MARK_PLT. + * emultempl/elf-x86.em (elf_x86_64_before_parse): New function. + (LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for + x86-64 targets. + +2024-01-09 H.J. Lu + + elf: Add elf_backend_add_glibc_version_dependency + When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and + DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation + stores the offset of the indirect branch instruction. However, glibc + versions which don't have this commit in glibc 2.36: + + commit f8587a61892cbafd98ce599131bf4f103466f084 + Author: H.J. Lu + Date: Fri May 20 19:21:48 2022 -0700 + + x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT + + According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT + and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we + can ignore their r_addends. + + Reviewed-by: Fangrui Song + + won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. + Although this commit has been backported to glibc 2.33/2.34/2.35 release + branches, it is safer to require glibc 2.36 for such binaries. + + Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to + also add GLIBC_2.36 version dependency for -z mark-plt on the shared C + library if it provides a GLIBC_2.XX symbol version. + + * elflink.c (elf_find_verdep_info): Moved to ... + * elf-bfd.h (elf_find_verdep_info): Here. + (elf_backend_data): Add elf_backend_add_glibc_version_dependency. + (_bfd_elf_link_add_glibc_version_dependency): New function. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): + Likewise. + (elf_backend_add_glibc_version_dependency): New. + * elflink.c (elf_link_add_dt_relr_dependency): Renamed to ... + (elf_link_add_glibc_verneed): This. Modified to support other + glibc dependencies. + (_bfd_elf_link_add_glibc_version_dependency): Likewise. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + (bfd_elf_size_dynamic_sections): Call + elf_backend_add_glibc_version_dependency instead of + elf_link_add_dt_relr_dependency. + * elfxx-target.h (elf_backend_add_glibc_version_dependency): New. + (elfNN_bed): Add elf_backend_add_glibc_version_dependency. + + ld/ + + * testsuite/ld-x86-64/mark-plt-1a.rd: New file. + * testsuite/ld-x86-64/mark-plt-1b.rd: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for + GLIBC_2.36 dependency. + +2024-01-09 H.J. Lu + + x86: Don't check R_386_NONE nor R_X86_64_NONE + Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning + relocations. + + bfd/ + + * PR ld/31047 + * elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check + R_X86_64_NONE. + + ld/ + + * PR ld/31047 + * testsuite/ld-i386/i386.exp: Run PR ld/31047 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/pr31047.d: New file. + * testsuite/ld-x86-64/pr31047-x32.d: Likewise. + * testsuite/ld-x86-64/pr31047.d: Likewise. + * testsuite/ld-x86-64/pr31047a.s: Likewise. + * testsuite/ld-x86-64/pr31047b.s: Likewise. + +2024-01-09 Tom Tromey + + Fix two bugs in gdbserver thread name handling + Simon pointed out that my earlier patch to gdbserver's thread name + code: + + commit 07b3255c3bae7126a0d679f957788560351eb236 + Author: Tom Tromey + Date: Thu Jul 13 17:28:48 2023 -0600 + + Filter invalid encodings from Linux thread names + + ... introduced a regression. This bug was that the iconv output was + not \0-terminated. + + Looking at it, I found another bug as well -- replace_non_ascii would + not \0-terminate, and also would return the wrong pointer + + This patch fixes both of them. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153 + +2024-01-09 Tom Tromey + + Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu + dwarf2_base_index_functions::find_per_cu is documented as using an + unrelocated address. This patch changes the interface to use the + unrelocated_addr type, just to be a bit more type-safe. + + Regression tested on x86-64 Fedora 38. + +2024-01-09 Jan Beulich + + x86: add missing APX logic to cpu_flags_match() + As already indicated during review, we can't get away without certain + adjustments here: Without these, respective {evex}-prefixed insns are + assembled to APX encodings even when APX_F is turned off. + + While there also extend the respective comment in the opcode table, to + explain why this construct is used. + +2024-01-09 Jan Beulich + + x86: FMA insns aren't eligible to VEX2 encoding + PR gas/31178 + + In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked + that C aliases StaticRounding, and hence build_vex_prefix() now needs to + be aware of that aliasing. Disambiguation is easy, as StaticRounding is + only ever used together with SAE (hence why the overlaying works in the + first place). + +2024-01-09 Jan Beulich + + PPC64/ELF: adjust comment wrt ABI versions + While having been moved a couple of times since its introduction in + f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"), + the wording has always remained the same. In particular ELFv1 and ELFv2 + have always been the wrong way round. + +2024-01-09 Nick Clifton + + Synchronize sourceware version of the libiberty sources with the master gcc versions. + This brings in the following commits: + + commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a + Author: Jakub Jelinek + Date: Tue Dec 5 23:32:19 2023 +0100 + + libiberty: Fix build with GCC < 7 + + Tobias reported on IRC that the linker fails to build with GCC 4.8.5. + In configure I've tried to use everything actually used in the sha1.c + x86 hw implementation, but unfortunately I forgot about implicit function + declarations. GCC before 7 did have header and bit_SHA define + and __get_cpuid function defined inline, but it didn't define + __get_cpuid_count, which compiled fine (and the configure test is + intentionally compile time only) due to implicit function declaration, + but then failed to link when linking the linker, because + __get_cpuid_count wasn't defined anywhere. + + The following patch fixes that by using what autoconf uses in AC_CHECK_DECL + to make sure the functions are declared. + + commit 691858d279335eeeeed3afafdf872b1c5f8f4201 + Author: Rainer Orth + Date: Tue Dec 5 11:04:06 2023 +0100 + + libiberty: Fix pex_unix_wait return type + + The recent warning patches broke Solaris bootstrap: + + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] + 326 | pex_unix_wait, + | ^~~~~~~~~~~~~ + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') + + While pex_funcs.wait expects a function returning pid_t, pex_unix_wait + currently returns int. However, on Solaris pid_t is long for 32-bit, + but int for 64-bit. + + This patches fixes this by having pex_unix_wait return pid_t as + expected, and like every other variant already does. + + Bootstrapped without regressions on i386-pc-solaris2.11, + sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and + x86_64-apple-darwin23.1.0. + + commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 + Author: Jason Merrill + Date: Mon Sep 25 10:15:02 2023 +0100 + + c++: mangle function template constraints + + Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and + https://github.com/itanium-cxx-abi/cxx-abi/pull/166 + + We need to mangle constraints to be able to distinguish between function + templates that only differ in constraints. From the latter link, we want to + use the template parameter mangling previously specified for lambdas to also + make explicit the form of a template parameter where the argument is not a + "natural" fit for it, such as when the parameter is constrained or deduced. + + I'm concerned about how the latter link changes the mangling for some C++98 + and C++11 patterns, so I've limited template_parm_natural_p to avoid two + cases found by running the testsuite with -Wabi forced on: + + template T f() { return V; } + int main() { return f(); } + + template int max() { return i; } + template int max() + { + int sub = max(); + return i > sub ? i : sub; + } + int main() { return max<1,2,3>(); } + + A third C++11 pattern is changed by this patch: + + template