2026-02-08 GDB Administrator Automatic date update in version.in 2026-02-07 GDB Administrator Automatic date update in version.in 2026-02-06 Indu Bhagat sframe: doc: minor fixups in language for clarity libsframe/doc/ * sframe-spec.texi: Minor language and formatting fixup. (cherry picked from commit 2c4129c4cc3e715baa78a9327368a079b58bebeb) 2026-02-06 Indu Bhagat bfd: sframe: use better wording for error messages Fix PR ld/33849. Change the messages to display the owner BFD, together with the section name. E.g., when mixing SFrame V2 and V3, the linker will now emit something like: error in test.o (.sframe); unexpected SFrame format version 2 Reviewed-by: Jens Remus bfd/ PR ld/33849 * elf-sframe.c (_bfd_elf_merge_section_sframe): Improve error messages. (cherry picked from commit 34825538ba711842a0ec2e2112f2b013dafba6f2) 2026-02-06 Nick Clifton Updated/new translation files for the 2.46 release 2026-02-06 GDB Administrator Automatic date update in version.in 2026-02-05 GDB Administrator Automatic date update in version.in 2026-02-04 Alan Modra PR 33593 Misplaced synthetic plt symbols in aarch64 PIE binaries elfNN_aarch64_plt_sym_val wrongly treats PIEs. PIEs are an executable but not ET_EXEC, instead being ET_DYN with DF_1_PIE set in DT_FLAGS_1 to distinguish them from shared libraries. get_plt_type scans .dynamic for DT_AARCH64_BTI_PLT and DT_AARCH64_PAC_PLT, setting PLT_BTI and PLT_PAC in the function return value respectively. It's easy enough to extend the .dynamic scan to also return DF_1_PIE in tdata is_pie. The patch also makes a few tidies, things I noticed when scanning all the code dealing with sw_protections.plt_type. PR 33593 * elfnn-aarch64.c (get_plt_type): Return DF_1_PIE via tdata is_pie. (elfNN_aarch64_plt_sym_val): Handle PIEs as well as ET_EXEC. (setup_plt_values): Delete wrong ET_EXEC comments. (elfNN_aarch64_late_size_sections): Remove excess parentheses. (elfNN_aarch64_finish_dynamic_sections): Rename type to plt_type, and simplify test for PLT_BTI or PLT_BTI_PAC. Co-Authored-By: Michael Matz (cherry picked from commit 2dfd38f93ce3b05d25c7bd14cbcff0fa3614c056) 2026-02-04 Claudiu Zissulescu Indu Bhagat sframe: Add tests for PR ld/32769 Add simple tests that verify the behavior of garbage collection of SFrame sections during linking. x86_64-specific tests: - sframe-gc-sections-1.d checks that none of the functions get discarded with --gc-sections - sframe-gc-sections-2a.d checks the behavior of --gc-sections with two distinct .text.* sections (similar to -ffunction-sections compiler option) - sframe-gc-sections-2b.d checks the same behaviour as sframe-gc-sections-2a.d, but with a linker script that discards .eh_frame sections. This testcase is keep it ensured that the two section's GC behaviours are not unnecessarily inter-twined. All targets supporting sframe tests: - pr32769.rd simple linking test in presence of --gc-sections option. - pr32769-2.d checks the behavior of --gc-sections with two .text.* sections, one section is discarded - pr32769-2r.d Like the above, but using -r option when linking and checking for the relocations. - pr32769-3.d checks the behavior of --gc-sections with multiple sections, none is drop. ld/ PR ld/32769 * testsuite/ld-sframe/pr32769.rd: New file. * testsuite/ld-sframe/pr32769.s: Likewise. * testsuite/ld-sframe/pr32769-2.d: Likewise. * testsuite/ld-sframe/pr32769-2r.d: Likewise. * testsuite/ld-sframe/pr32769-2.s: Likewise. * testsuite/ld-sframe/pr32769-3.d: Likewise. * testsuite/ld-sframe/pr32769-3.s: Likewise. * testsuite/ld-sframe/sframe.exp: Add pr32769 test. * testsuite/ld-x86-64/sframe-baz.s: New file. * testsuite/ld-x86-64/sframe-gc-sections-1.d: Likewise. * testsuite/ld-x86-64/sframe-gc-sections-2.s: Likewise. * testsuite/ld-x86-64/sframe-gc-sections-2a.d: Likewise. * testsuite/ld-x86-64/sframe-gc-sections-2b.d: Likewise. * testsuite/ld-x86-64/sframe-gc-sections-2b.t: Likewise. * testsuite/ld-x86-64/x86-64.exp: Add new sframe gc tests. (cherry-picked from commit ae82750860f5aff1ff8a42542b87e7ad33f18b97) 2026-02-04 Claudiu Zissulescu Indu Bhagat ld: bfd: sframe: KEEP .sframe sections and support gc-sections Fix PR ld/32769 Currently, specifying --gc-sections causes the linker to discard all input .sframe sections. Fix this behaviour by adding KEEP for .sframe sections, like it is being done for .eh_frame sections, in the default ELF linker script. Additionally, add logic in the linker to gc mark .sframe sections. _bfd_elf_gc_mark () now is aware of SFrame sections. It relies on elf_section_sframe () to get the SFrame section associated with the text section. Also, the _bfd_elf_parse_sframe is changed to return TRUE when the input sframe section is already parsed. It fixes calling _bfd_elf_discard_section_sframe function in bfd_elf_discard_info, enabling correct behavior for discarding unneeded sframe sections. ld/ PR ld/32769 * scripttempl/elf.sc: KEEP .sframe sections. bfd/ * elf-bfd.h (struct elf_obj_tdata): Add sframe section pointer. (elf_sframe_section): New macro. * elflink.c (_bfd_elf_gc_mark): Handle SFrame sections. (bfd_elf_gc_sections): Likewise. (bfd_elf_discard_info): Update for handling gc operations. * elf-sframe.c (_bfd_elf_parse_sframe): Return TRUE for already parsed sframe sections. Reviewed-by: Jens Remus (cherry-picked from commit 4b5ff658b4993fae1f347793bddd5c14b76167cd) 2026-02-04 GDB Administrator Automatic date update in version.in 2026-02-03 Indu Bhagat include: libsframe: rename SFrame V3 Flexible FDE macros to CTRLWORD The existing SFrame V3 macros for Flexible FDEs used the term 'OFFSET' to refer to the data word encoding control/register data word. This can be confusing, as the control data word (register ID, dereference flags) is distinct from a stack offset. This patch renames these macros to use 'CTRLWORD' to better reflect their purpose. It also updates the assembler and libsframe dumper to use the new nomenclature. No functional change. Reviewed-by: Jens Remus gas/ * gen-sframe.c (sframe_get_fre_dataword_size): Use SFRAME_V3_FLEX_FDE_CTRLWORD_ENCODE. (output_sframe_row_entry_datawords): Likewise. include/ * sframe.h (SFRAME_V3_FLEX_FDE_REG_ENCODE): Rename from .. (SFRAME_V3_FLEX_FDE_CTRLWORD_ENCODE): .. to. (SFRAME_V3_FLEX_FDE_CTRLWORD_REGNUM): Rename from SFRAME_V3_FLEX_FDE_OFFSET_REG_NUM to this. (SFRAME_V3_FLEX_FDE_CTRLWORD_DEREF_P): Rename from SFRAME_V3_FLEX_FDE_OFFSET_REG_DEREF_P to this. (SFRAME_V3_FLEX_FDE_CTRLWORD_REG_P): Rename from SFRAME_V3_FLEX_FDE_OFFSET_REG_P to this. (SFRAME_V3_FRE_RA_UNDEFINED_P): Add new V3 macro. libsframe/ * sframe-dump.c (dump_sframe_func_fres_flex): Update all callers to use the new CTRLWORD macros. libsframe/testsuite/ * libsframe.decode/be-flipping-v3.c: Use renamed macros. (cherry picked from commit 4edeb9be08afae397e6c0dd1a57399b18ca29e35) 2026-02-03 GDB Administrator Automatic date update in version.in 2026-02-02 GDB Administrator Automatic date update in version.in 2026-02-01 GDB Administrator Automatic date update in version.in 2026-01-31 GDB Administrator Automatic date update in version.in 2026-01-30 GDB Administrator Automatic date update in version.in 2026-01-29 Jan Beulich Revert "ld: testcase for .note.GNU-stack wanting to be SHT_NOTE" etc This reverts commits a1c2fa92ac93bf50227941bd82094e6997c5fd56, bc6e40a093e700e84b549902d55e73bfe92a113b ("amend "ELF: give .note.GNU-stack proper section type""), and c8db2c887b4129732341c4a1a51cdcd3191db271 ("ELF: give .note.GNU-stack proper section type"). They're deemed to require a little more testing before being ready for a release. 2026-01-29 GDB Administrator Automatic date update in version.in 2026-01-28 Alan Modra PR 33852 Different objects for same input Testcase: $ cat aff.s .quad x@ntpoff $ gas/as-new -m64 aff.s -o t.o with MALLOC_PERTURB_ this reliably shows uninitialised memory making its way into the output. R_390_TLS_LE64 howto was sized incorrectly, resulting in the initialisation in s390_elf_cons zeroing only the first four bytes. * elf64-s390.c (elf_howto_table ): Correct size and bitsize. (cherry picked from commit 0e245c72b774658c48a14b05d78a4e0943a8a9b1) 2026-01-28 Alan Modra gas: segmentation fault in as_report_context After input_scrub_end when next_saved_file is NULL, it is possible that macro_nest will be non-zero on files with errors. If output_file_close then has an error and reports it with as_fatal we hit the segfault. PR 33746 * input_scrub.c (as_report_context): Don't assume next_saved_file is non-NULL. (as_where): Likewise. (cherry picked from commit ea96771a0188a235645558ae10d6885c91c1ac00) 2026-01-28 GDB Administrator Automatic date update in version.in 2026-01-27 Alan Modra regen pot files 2026-01-27 Alan Modra Re: PR 33840 typo in elfnn-loongarch.c The second string with the typo was unused (and had unescaped %). Remove it. (cherry picked from commit 6f8d261d200b59f0cc55581ad6cefe3912a05fa9) 2026-01-27 Alan Modra PR 33840 typo in elfnn-loongarch.c s/marching/matching/ (cherry picked from commit 5c9b48f2eda429b3ef09a8239a472f6a72541a53) 2026-01-27 Alan Modra PR 33838 Truncated translation in objcopy.c The only macros allowed are the ones specially handled by gettext, such as PRId64. * objcopy.c (copy_usage): Don't use string literal concatenation of macros in translated strings. Patch from Andreas Schwab (cherry picked from commit 1c8cfb3d217aee87562c4f4c4dbc1e4d60e8eadb) 2026-01-27 Than McIntosh PR 33835 readelf incorrect handling of DWARF5 CU DIE addr_base attribute Users of "readelf" report problems running the tool's DWARF dump flag on binaries built with the most recent version of the Go compiler (1.25), Go bug report here https://github.com/golang/go/issues/77246 dwarf.c (skip_attribute ): Skip terminating NUL too. (cherry picked from commit a72b83ab3792532b66cc5c472a20476a8a2fd969) 2026-01-27 Alan Modra Hard-coded plural in readelf.c PR 33837 * readelf.c (process_got_section_contents): Use ngettext. (cherry picked from commit 795593e667b00334e7b3fa8b11ea0e844e01b5af) 2026-01-27 GDB Administrator Automatic date update in version.in 2026-01-26 Matthieu Longo bfd/ELF: fix BFD library build --enable-shared The patch series that added support for Object Attributes v2 introduced regressions when building the BFD library as a shared object. Incorrect usages of ATTRIBUTE_HIDDEN caused the following link-time errors: /usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_record': obj-elf-attr.c: undefined reference to `bfd_elf_obj_attr_v2_init' obj-elf-attr.c: undefined reference to `_bfd_obj_attr_v2_find_by_tag' obj-elf-attr.c: undefined reference to `obj_attr_v2_t_append' /usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_subsection_record': obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append' obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_remove' obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append' This patch fixes the symbols visibility so that the BFD library links correctly when built with --enable-shared. The ATTRIBUTE_HIDDEN annotations were removed from bfd_elf_obj_attr_v2_init and _bfd_obj_attr_v2_find_by_tag, and _bfd_obj_attr_v2_find_by_tag was renamed to reflect the belonging to the public BFD API using the 'bfd_' prefix. The doubly linked list helpers remain hidden and are instead exposed through wrapper functions. 2026-01-26 Rainer Orth binutils: xfail "gnu-debuglink (objdump 1)" on Solaris/amd64 [PR33243,PR33389] As reported in PR binutils/33243, one test FAILs on Solaris/amd64: FAIL: gnu-debuglink (objdump 1) 30c30,32 < 400660: ff 35 b2 15 00 00 ff 25 b4 15 00 00 0f 1f 40 00 .5.....%......@. --- > 400660: ff 35 b2 15 00 00 push 0x15b2(%rip) # 401c18 <_GLOBAL_OFFSET_TABLE_+0x8> > 400666: ff 25 b4 15 00 00 jmp *0x15b4(%rip) # 401c20 <_GLOBAL_OFFSET_TABLE_+0x10> > 40066c: 0f 1f 40 00 nopl 0x0(%rax) This is another instance of PR binutils/33389, so this patch xfail's the test. Tested on {amd64,i386}-pc-solaris2.11 and {x86_64,i686}-pc-linux-gnu. 2026-01-25 Rainer Orth binutils: PR binutils/33243 PR binutils/33389 * testsuite/binutils-all/compress.exp (test_gnu_debuglink): xfail on Solaris/amd64. (cherry picked from commit aa3291fceac4a53054a6337a577a882b078db9be) 2026-01-25 Nick Clifton Update version to 2.45.90 Add 2.46 release markers to NEWS files. Update BRANCHES. Update README. 2026-01-25 Indu Bhagat ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs GNU ld creates SFrame stack trace info for the PLT. For x86 the linker- created .sframe section is created in setup_gnu_properties. For s390 it is created in create_dynamic_sections. For both, the section data is itself emitted a bit later in late_size_sections. Note that for aarch64 the linker does not create .sframe for PLT yet. Recall that a previous patch 832ca9ef670 uncoupled --no-ld-generated-unwind-info from the linker-generated .sframe sections. This means that the linker now generates .sframe section (for .plt*) for the first input BFD enthusiatically even when none of the input BFDs have any .sframe section, unless --discard-sframe is also added. The issue is that these (unexpected) linker-generated .sframe sections (on x86_64, and s390) may now trip the linking process, e.g., when using --orphan-handling=error together with a linker script that treats .sframe differently than the default linker script. https://sourceware.org/pipermail/binutils/2026-January/147826.html Further, with SFrame sections to be soon marked KEEP for fixing GC/SFrame (PR ld/32769), the presence of these linker generated SFrame sections will also cause emission of an empty .sframe (for x86_64 and s390x), even when all input bfd's have no .sframe section. This patch avoids creation of .sframe for .plt* if none of the input BFDs had any .sframe section. This then avoids creation of empty .sframe in linked objects on x86_64 and s390x, when none of the inputs have SFrame sections. This also fixes PR ld/33830. For the code changes: Reviewed-by: Jens Remus New testcases have (since the above Reviewed-by) been added. Since --no-ld-generated-unwind-info is not supported on aarch64, add target-specific ld tests. Additionally add a generic test (for all targets that support SFrame) to ensure no output .sframe is generated if users says no --gsframe or similar. bfd/ PR ld/33830 * elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New declaration. * elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New definition. * elf64-s390.c (elf_s390_create_dynamic_sections): Do not generate .sframe for .plt unconditionally. * elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Likewise. ld/testsuite/ PR ld/33830 * ld-s390/no-sframe.ld: Linker script with no specification for SFrame sections. * ld-s390/s390.exp: Add new test. * ld-s390/sframe-command-line-2.d: New testcase that uses --no-ld-generated-unwind-info and a linker script that has no specific rules for .sframe. * ld-x86-64/no-sframe.ld: Likewise for x86_64. * ld-x86-64/sframe-command-line-2.d: Likewise for x86_64. * ld-x86-64/x86-64.exp: Add new test. * ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in output if no .sframe in input. * ld-sframe/no-sframe.ld: Linker script with no specification for SFrame sections. * ld-sframe/test.s: Add new test. 2026-01-25 Indu Bhagat gas: aarch64: i386: s390: sframe: adjust sframe_ra_tracking_p Like the previous commit b600229503 which adjusted the implementation of flex fde hook, make a similar change for sframe_ra_tracking_p. Simply providing the definition to use boolean value direcly is sufficient for the purpose, and helps generate better code. gas/ * config/tc-aarch64.c (aarch64_sframe_ra_tracking_p): Remove. * config/tc-aarch64.h (aarch64_sframe_ra_tracking_p): Remove. (sframe_ra_tracking_p): Set to true. * config/tc-i386.c (x86_sframe_ra_tracking_p): Remove. * config/tc-i386.h (x86_sframe_ra_tracking_p): Remove. (sframe_ra_tracking_p): Set to false. * config/tc-s390.c (s390_sframe_ra_tracking_p): Remove. * config/tc-s390.h (s390_sframe_ra_tracking_p): Remove. (sframe_ra_tracking_p): Set to true. 2026-01-25 GDB Administrator Automatic date update in version.in 2026-01-24 John David Anglin hppa64: Fix Linux link The "BFD_ASSERT (r_symndx != STN_UNDEF)" assert is incorrect and triggers linking Linux kernel. 2026-01-24 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_relocate_section): Remove asserts. 2026-01-24 Alice Carlotti gas/NEWS: Add AArch64 updates aarch64: Tidy architecture extensions documentation Document mops_go, add some missing full stops, and fix alphabetization mistakes. aarch64: Fix sme2p3 and f16f32dot feature dependencies These are changed to match the dependencies we agreed with LLVM. aarch64: Add -march=armv9.7-a option aarch64: Fix documentation of armv9.6-a dependencies The sve2p2 and fprcvt extensions were removed from -march=armv9.6-a, but we forgot to update the documentation at the same time. aarch64: Remove redundant macros We no longer encode flags in the aarch64_hint_options value field, so delete the HINT_VAL, HINT_FLAG and HINT_ENCODE macros. 2026-01-24 Srinath Parvathaneni aarch64: Add support for TLBID system registers This patch adds support for following TLBID system registers. * tlbididr_el1 (RO) * vtlbid0_el2 * vtlbid1_el2 * vtlbid2_el2 * vtlbid3_el2 * vtlbidos0_el2 * vtlbidos1_el2 * vtlbidos2_el2 * vtlbidos3_el2 2026-01-24 Srinath Parvathaneni aarch64: TLBI Domains changes for PLBI instruction For the PLBI instruction with optional register argument == 0b1111, with FEAT_TLBID enabled they are permitted to have an Rt value which is not 0b11111 and this is allowed for all the TLBI instructions with a of ALLE1*, ALLE2* and VMALL* and a of IS or OS. aarch64: Enable TLBIP instructions with tlbid option TLBI Domains feature changes TLBI and TLBIP system instructions. For all TLBIP *E1IS*, TLBIP *E1OS*, TLBIP *E2IS* and TLBIP *E2OS* instructions that are currently dependent on FEAT_D128 (+d128), will also be available with FEAT_TLBID (+tlbid). 2026-01-24 Srinath Parvathaneni aarch64: Add support for FEAT_TLBID feature TLBI Domains feature changes TLBI and TLBIP system instructions. For the TLBI instruction with optional register argument == 0b1111, with FEAT_TLBID enabled they are permitted to have an Rt value which is not 0b11111 and this is allowed for all the TLBI instructions with a of ALLE1*, ALLE2*, VMALL*, VMALLS12* or VMALLWS2* and a of IS or OS. This patch add support for FEAT_TLBID feature, which is enabled by new +tlbid option. 2026-01-24 Rainer Orth ld: testsuite: Relax libgot-1-i386 test for Solaris [PR33350] When running the ld testsuite with -melf_i386_sol2 instead of -melf_i386 on Solaris, one test regresses: FAIL: Build libgot-1-i386.so The issue is that one line in the --got-contents output differs unexpectedly: Global Offset Table '.got.plt' contains 4 entries: Index: Address Reloc Sym. Name + Addend/Value - 0: 00200200 20016c - 1: 00200204 0 - 2: 00200208 0 - 3: 0020020c R_386_JUMP_SLOT bar + 156 + 0: 00200270 2001dc + 1: 00200274 0 + 2: 00200278 0 + 3: 0020027c R_386_JUMP_SLOT bar + 1c6 While ld-i386/libgot-1.rd already allows for differences in the addresses, the addend is assumed to be fixed. However, this is not the case with -melf_i386_sol2. The difference is that .hash, .dynsym, and .symtab have additional entries as required by the Solaris ABI: * In .dynsym and .symtab, _DYNAMIC, _GLOBAL_OFFSET_TABLE_, and _PROCEDURE_LINKAGE_TABLE_ are added. * .symtab also gains _END_ and _START_. This explains the differences in addresses and addends, but they are completely benign. This patch thus allows for arbitrary addends. Tested on {i386,amd64}-pc-solaris2.11 with both -melf_i386_sol2 and -melf_i386, and {i686,x86_64}-pc-linux-gnu. 2026-01-23 Rainer Orth ld: PR ld/33350 * testsuite/ld-i386/libgot-1.rd: Allow for different R_386_JUMP_SLOT addends. 2026-01-24 Rainer Orth ld: testsuite: Skip pr33577 tests with GNU extensions on Solaris [PR33577] Several of the ld-elfvers pr33577 tests FAIL on Solaris, for either or both of two reasons: * Tests using ld --hash-style=gnu cannot work on Solaris: .gnu.hash/SHT_GNU_HASH sections are a GNU extension not supported by Solaris ld.so.1. * Similarly, binding different implementations of the same symbol to different symbol versions is a GNU extension that wasn't in the original Solaris specification of symbol versioning. ld.so.1 doesn't support it and never will. This can be seen in the elfdump output for the .dynsym section: Symbol Table Section: .dynsym index value size type bind oth ver shndx name [8] 0x630 0xd FUNC GLOB D 1H .text foo [10] 0x620 0x6 FUNC GLOB D 2 .text foo foo is bound to both version 1 (the Base version) and version 2 (VERS_1 from pr33577.map). Same for .symtab: Symbol Table Section: .symtab index value size type bind oth ver shndx name [28] 0x620 0x6 FUNC GLOB D 0 .text foo [35] 0x630 0xd FUNC GLOB D 0 .text foo@ As I said, ld.so.1 doesn't support @ (in this case the Base version) at all. Therefore the tests that employ those extensions are guarded with supports_gnu_osabi. Tested on sparc{,v9}-sun-solaris2.11, sparc{,64}-unknown-linux-gnu, {i386,amd64}-pc-solaris2.11, and {x86_64,i686}-pc-linux-gnu. 2026-01-23 Rainer Orth ld: PR ld/33577 * testsuite/ld-elfvers/vers.exp (base_symbol_test): Only run pr33577a with libpr33577-versioned.so test on ELFOSABI_GNU systems. Likewise for run base_symbol_tests with --hash-style=gnu. 2026-01-24 Hans-Peter Nilsson ld: Make separate clauses where a label was before a declaration The default behavior of gcc changed from gcc-11. With gcc-10 and earlier versions, you got: In file included from ../bfd/bfd.h:45, from /src/ld/ldmisc.c:23: /src/ld/ldmisc.c: In function 'vfinfo': /src/ld/ldmisc.c:186:8: error: a label can only be part of a statement and a declaration is not a statement 186 | bool ll_type = false; | ^~~~ /src/ld/ldmisc.c:581:8: error: a label can only be part of a statement and a declaration is not a statement 581 | bool ll_type = false; | ^~~~ make[4]: *** [Makefile:1606: ldmisc.o] Error 1 Since gcc-10 matches the binutils/README requirement ("a C99 compliant compiler and library") and as binutils policy is to adjust code to handle earlier gcc versions, an obvious fix is to make a compound statement for the code after the case-label. ld: * ldmisc.c (vfinfo) : Make separate compound statements where case-labels were part of a declaration. 2026-01-24 H.J. Lu elf: Set has_local_dynsyms for forced local symbol bfd_elf_link_record_dynamic_symbol may be called by mips backend after a global symbol has been forced to local. Set has_local_dynsyms to true in this case. bfd/ PR ld/33793 * elflink.c (bfd_elf_link_record_dynamic_symbol): Set has_local_dynsyms to true for forced local symbol. ld/ PR ld/33793 * testsuite/ld-mips-elf/mips-elf.exp: Run pr33793. * testsuite/ld-mips-elf/pr33793.d: New file. * testsuite/ld-mips-elf/pr33793.s: Likewise. 2026-01-24 Alibek Omarov windres: quote the angled brackets to avoid confusing shell When invoking windres with a preprocessor parameter that contains angled brackets, the shell will try to interpret them, leading to an error. For example with an empty test.rc file: $ i686-w64-mingw32-windres '-DTEST=' -o test.o -i test.rc sh: 1: cannot open foo: No such file i686-w64-mingw32-windres: preprocessing failed. After patch it correctly complains about no resources baked in: $ ./i686-w64-mingw32-windres '-DTEST=' -o test.o -i test.rc ./i686-w64-mingw32-windres: no resources 2026-01-24 Michal Sobon opcodes: Fix branch displacement mask in M*Core disassembler The BT, BF, BR, and BSR instructions use the Scaled 11-Bit Displacement addressing mode. According to the Motorola M*Core Reference Manual, the instruction format has: - bits 15-11: opcode - bits 10-0: 11-bit signed displacement field The displacement calculation is: PC <- PC + 2 + (sign-extended disp11 << 1) The disassembler was incorrectly masking with 0x3FF (10 bits) instead of 0x7FF (11 bits). This masked off bit 10, which is the sign bit for the 11-bit signed displacement. As a result, negative (backward) branches were incorrectly disassembled as forward branches. opcodes/ * mcore-dis.c (print_insn_mcore): Fix displacement mask from 0x3FF to 0x7FF in BR case to correctly extract all 11 bits including the sign bit. 2026-01-24 Alan Modra amend supports_oa targets Add vxworks and windiss to supported targets. is_elf_target excludes them as a hack to work around multiple other elf test failures. On these targets, fixes FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute 2026-01-24 Indu Bhagat sframe: doc: prepare SFrame specification for release Remove the DRAFT marker before release. Currently needs to be done manually. libsframe/ * doc/sframe-spec.texi: Remove DRAFT marker. 2026-01-24 Alan Modra gas: move obj_begin earlier csky wants to set up ELF object attributes in its md_begin. * as.c (perform_an_assembly_pass): Move obj_begin earlier. * testsuite/gas/mmix/builtin1.d, * testsuite/gas/mmix/builtin3.d: Adjust expected output. 2026-01-24 Alan Modra fix fail of X32 DSO from x86-64 sframe.o The testcase assumes binutils is configured without --disable-separate-code. Pass -z separate-code to generate the expected output. 2026-01-24 Alan Modra score: segfault on null hi16_rel_addr On a fuzzed input object we hit a segfault when a LO16 reloc doesn't have the required preceding HI16 reloc. move score static hi16_rel_addr to elf_section_data, and check that it is non-NULL before dereferencing. 2026-01-24 Alan Modra asan: mips ecoff integer overflow Silence an inconsequential oss-fuzz complaint. * ecofflink.c (lookup_line): Make lineno unsigned to avoid integer overflow. Sign extend without a conditional. 2026-01-24 GDB Administrator Automatic date update in version.in 2026-01-23 Indu Bhagat sframe: doc: minor typos and cosmetic fixes libsframe/ * doc/sframe-spec.texi: Minor edits. 2026-01-23 Indu Bhagat libsframe: rename sframe_fre_* internal APIs to use data word instead of offset Rename three internal functions: - sframe_fre_get_offset_count to sframe_fre_get_dataword_count - sframe_fre_get_offset_size to sframe_fre_get_dataword_size - sframe_fre_offset_bytes_size to sframe_fre_datawords_bytes_size. libsframe/ * sframe.c: Rename functions and variables. 2026-01-23 Indu Bhagat libsframe: rename flip_fre_stack_offsets to flip_fre_datawords Also adjust function level comment for flip_fre_datawords. libsframe/ * sframe.c (flip_fre_stack_offsets): Rename to flip_fre_datawords. 2026-01-23 Indu Bhagat libsframe: rename offset in user-facing sframe_frame_row_entry struct This patch is the first patch to align libsframe with the terminology change of moving from 'offset' to 'data word'. With the introduction of flexible FDE type SFRAME_FDE_TYPE_FLEX, the variable-length data following an SFrame FRE header can now represent signed offsets or unsigned control data. Consequently, 'data word' is adopted as the more generic term. This change updates the names used in the user-facing sframe_frame_row_entry structure. While some API function names remain unchanged to preserve existing contracts, the underlying data buffers and size macros now reflect the data word' terminology. libsframe is a tricky spot for such a terminology change: some of APIs are still used to read (may be followed by endian swap) for dumping SFrame V2 sections in textual format. Some classic examples are sframe_decode_fre, and flip_fre (both are static functions). But moving forward, using the term 'data word' for such APIs and their internal too may be better. Subsequent commits will achieve just that. include/ * sframe-api.h (MAX_NUM_DATAWORDS): Rename from MAX_NUM_STACK_OFFSETS. (MAX_DATAWORD_BYTES): Rename from MAX_OFFSET_BYTES. (struct sframe_frame_row_entry): Rename fre_offsets to fre_datawords. libsframe/ * sframe.c (sframe_fre_sanity_check_p): Use MAX_NUM_DATAWORDS. (sframe_get_fre_offset): Update internal pointers to use 'offsets' and access fre_datawords. (sframe_get_fre_udata): Rename local variables to dataword_cnt/dataword_size and update to use SFRAME_FRE_DATAWORD_* constants. (sframe_decode_fre): Use fre_datawords and MAX_DATAWORD_BYTES. (sframe_encoder_add_fre): Use fre_datawords. (sframe_encoder_write_fre): Use fre_datawords. 2026-01-23 Indu Bhagat include: gas: sframe: fix terminology from offset to data word In SFrame V3, with the addition of flexible FDE type, the variable-length array of bytes trailing the SFrame FRE header are no longer exclusively interpreted as signed offsets. This data can now include unsigned control data, unsigned padding word data or signed offset data. Consequently, using the term "offsets" to describe this trailing data is inaccurate and can be confusing. This patch switches the terminology to 'Data Word' across the assembler and the SFrame header file. Note that, the term 'Word' is used colloquially here, the actual size (1, 2, or 4 bytes) remains determined by the applicable bits in the FRE info byte. gas/ * gen-sframe.c: Rename SFrame FRE 'offset' to 'data word'. include/ * sframe.h (SFRAME_FRE_DATAWORD_1B, SFRAME_FRE_DATAWORD_2B, SFRAME_FRE_DATAWORD_4B): New constants. (struct sframe_fre_info): Update bitfield documentation. (SFRAME_V3_FRE_DATAWORD_COUNT): New macro. (SFRAME_V3_FRE_DATAWORD_SIZE): New macro. 2026-01-23 Indu Bhagat sframe: doc: terminology change from offset to data word ChangeLog: * libsframe/doc/sframe-spec.texi 2026-01-23 Tom Tromey Simplify cp_print_class_member I noticed that cp_print_class_member's calling convention can be simplified. In particular it seems cleaner for it to simply take a value and a stream; and the "prefix" argument is only ever set to one value. This version also renames the function, to indicate a bit more clearly what it actually does. Regression tested on x86-64 Fedora 40. Reviewed-By: Keith Seitz 2026-01-23 Hannes Domani Add aarch64-windows support This makes most debugging work, except unwinding doesn't always work from inside dlls where no debug info is available, because SEH unwinding is not implemented. The number of available hardware breakpoints is taken from ID_AA64DFR0_EL1 (registry key "CP 4028"). As for hardware watchpoints, even though ARM64_MAX_WATCHPOINTS is 2, testing showed that only 1 ever works, so it's fixed to that value. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2026-01-23 Hannes Domani Move setting size of long to windows-tdep It's 32bit for all (non-cygwin) Windows ABIs. Approved-By: Tom Tromey 2026-01-23 Hannes Domani Move auto_wide_charset gdbarch method to windows-tdep It's UTF-16 for all Windows ABIs. Approved-By: Tom Tromey 2026-01-23 Hannes Domani Move software breakpoint recognition code into x86-windows-nat.c Approved-By: Tom Tromey Reviewed-By: Christina Schimpe Move x86 selector code into x86-windows-nat.c Approved-By: Tom Tromey Reviewed-By: Christina Schimpe Move x86 register code into x86-windows-nat.c Reviewed-By: Christina Schimpe Approved-By: Tom Tromey Move x86 debug registers and related code into x86-windows-nat.c Approved-By: Tom Tromey 2026-01-23 Hannes Domani Create x86-windows-nat.c Also creates the x86_windows_per_inferior and x86_windows_nat_target derived classes in there which will then hold the arch-specific data and function overrides. Approved-By: Tom Tromey 2026-01-23 Hannes Domani Move struct declarations into windows-nat.h This is done as preparation for aarch64-windows-nat, since both x86 and aarch64 will use them as base (after the x86 parts are split off into x86-windows-nat). Approved-By: Tom Tromey 2026-01-23 Hannes Domani Simplify windows_nat_target::resume Now the thread context is only needed for setting the trace bit, so move the rest out of the with_context lambda. Approved-By: Tom Tromey Reviewed-By: Christina Schimpe 2026-01-23 Hannes Domani Remove duplicate code from windows_nat_target::resume Updating the debug registers and calling SetThreadContext is already done in windows_continue, called directly afterwards, so this removes it from windows_nat_target::resume. Approved-By: Tom Tromey 2026-01-23 Tom Tromey Some cleanups to "pretend language" handling I noticed that the "pretend language" handling in the DWARF reader doesn't work as intended; the problem code in dwarf2_per_cu::set_lang is: if (unit_type () == DW_UT_partial) return; The issue here is that this subverts the very purpose of having a "pretend" language. Some background: when Jakub wrote dwz, we also added support for this style of DWARF compression to gdb. Now, dwz only shares DIEs in a "top level" way -- i.e., at the time (and as far as I know, continuing to today), it would not emit a DW_TAG_imported_unit inside a namespace. So, when implementing this we also implemented an optimization, namely that gdb would not re-read every imported unit a la '#include', but instead would make symtabs for each included unit (partial units didn't yet exist). However, an imported/partial unit might not have a language -- but a language is necessary for interpreting the DIEs. This is where the "pretend" language comes from. When reading a CU, any included partial units that do not have a language of their own will inherit that CU's language. This patch started by removing the DW_UT_partial check. This of course caused assertion failures in some modes, as set_lang also asserts that the language cannot change. But, it's possible for a CU to be prepared multiple times, and for different invocations to provide different languages. This is not a scenario we allowed for in the early days. Nowadays, though, it seems to me that it's basically fine in practice, with the reason being that sharing DIEs that differ semantically but not syntactically across different languages is hard to achieve. We do see this some cross-language sharing in a limited way -- "dwz -5" will emit inclusions from both C and C++ CUs for the gdb.fortran/mixed-lang-stack.exp test -- but note that this sharing is limited to things that are common between C and C++, like "float". Therefore this patch replaces the assertions in set_lang with some compare-exchanges. Finally I changed cutu_reader to use a std::optional for the pretend language. I think this makes it more clear what is happening. And, while doing this I found a spot in the cooked indexer where language_minimal was passed in, but where the importing CU's language should have been used. I regression tested this on x86-64 Fedora 40 using the default board, plus the cc-with-gdb-index, cc-with-debug-names, and cc-with-dwz-5 boards. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33661 2026-01-23 Tom Tromey Update black to 26.1.0 "pre-commit autoupdate" suggests a new version of black. This version seems to want to change how destructuring assignments are formatted. Approved-By: Simon Marchi 2026-01-23 Matthieu Longo aarch64 test: fix clashing test name fix build failures due to incorrect format specifier for uint64_t 2026-01-23 Nick Clifton Reword the section of the AI Acceptance Policy that refers to labelling submissions. 2026-01-23 Andrew Burgess gdb/tui: return std::string from tui_get_function_from_frame Update tui_get_function_from_frame to return a std::string rather than a pointer into a static buffer. The value returned from tui_get_function_from_frame is passed to tui_location_tracker::set_location, which already stores the data in a std::string; this just moves the string creation earlier. I don't think there was anything particularly wrong with the old code, but I'm not a huge fan of returning data in static buffers unless there's a really good reason, and it doesn't feel like there's a really good reason in this case. The current approach in tui_get_function_from_frame is to call print_address_symbolic, and then to pull the function name from the result. There is an argument that this approach could be improved, but I've not done that in this commit, nor do I plan to do that any time soon. As such the new code should do exactly what the old code did. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-23 Matthieu Longo ld: bring vfinfo() in parity with printf() for format specifiers ll[d|i|x] vfinfo() does not currently support the double-'l' ('ll') length modifier for 'd', 'u', and 'x' conversion specifiers. This caused incorrect behavior when using PRI[d|u|x][32|64] on some platforms, and is error-prone for developers who reasonably expect printf-compatible semantics. This patch adds support for ll[d|u|x] to align vfinfo() with printf() and improve portability and robustness. 2026-01-23 Rainer Orth binutils: testsuite: Fix is_elf_format indentation One line in is_elf_format isn't indented correctly. Fixed thus. Tested on x86_64-pc-linux-gnu. 2026-01-23 Rainer Orth binutils: * testsuite/lib/binutils-common.exp (is_elf_format): Fix indentation. 2026-01-23 Eli Zaretskii gdb: Document recent enhancements when using Windows Terminal * gdb/NEWS: * gdb/doc/gdb.texinfo (Output Styling): Document support for 24-bit colors and UTF-8 output, including emoji styling. 2026-01-23 H.J. Lu x32: Allow R_X86_64_PC64 for SFrame V3 SFrame V3 generates R_X86_64_PC64 relocation, instead of R_X86_64_PC32, in .sframe section for x86-64. Although x32 doesn't support SFrame, .sframe section can be found in x32 object converted from x86-64 object with objcopy, which only changes the ELF file class from ELFCLASS64 to ELFCLASS32 with all section contents unchanged. Update elf_x86_64_scan_relocs to allow R_X86_64_PC64 for x32 so that x32 object file with .sframe section can be used as x32 linker input. bfd/ PR ld/33807 * elf64-x86-64.c (elf_x86_64_scan_relocs): Allow R_X86_64_PC64 for x32. ld/ PR ld/33807 * testsuite/ld-x86-64/sframe.rd: New file. * testsuite/ld-x86-64/sframe.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run PR ld/33807 tests. 2026-01-23 Tom de Vries [gdb/testsuite] Force elf headers in linux core dump I've got a test setup consisting of a chromebook with a MediaTek MT8183 processor, running Debian userland with a custom kernel [1]. The custom kernel doesn't have CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS enabled, and consequently the default coredump_filter is 0x23 instead of 0x33, in other words bit 4 (which enables the dumping of ELF headers) is not set. The testsuite relies on the dumping of ELF headers in core files to get the build-ID of the executable and shared libraries, and consequently some test-cases fail. Fix this in core_find, by adding bit 4 in the coredump_filter, if necessary. Fixes test-cases: - gdb.base/corefile-exec-mismatch.exp - gdb.base/corefile-find-exec.exp - gdb.debuginfod/corefile-mapped-file.exp - gdb.debuginfod/solib-with-soname.exp - gdb.python/py-corefile.exp - gdb.python/py-missing-objfile.exp Tested on aarch64-linux. Reviewed-By: Keith Seitz PR testsuite/33772 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33772 [1] https://github.com/hexdump0815/linux-mainline-mediatek-mt81xx-kernel 2026-01-23 GDB Administrator Automatic date update in version.in 2026-01-22 John David Anglin hppa64: Implement support for DT_TEXTREL This fixes ld-elf/pr19539, DT_TEXTREL in shared lib, and DT_TEXTREL map file warning tests on hppa64. 2026-01-22 John David Anglin bfd/ChangeLog: * elf64-hppa.c (allocate_dynrel_entries): Set DF_TEXTREL if it isn't already set and we encounter a relocation against a readonly section. (elf64_hppa_late_size_sections): Add DT_TEXTREL dynamic entry if we have relocs and DF_TEXTREL is set in info->flags. 2026-01-22 Tom Tromey Fix typo in fetch-exec-and-args.exp pre-commit points out a typo in this file. 2026-01-22 Rainer Orth ld: testsuite: Enable ld-sparc tests on Solaris The ld-sparc tests aren't currently run on Solaris to avoid PR binutils/27666. This has been fixed, so they can be enabled there, too. Tested no sparc{v9,}-sun-solaris2.11 and sparc{64,}-unknown-linux-gnu. 2026-01-17 Rainer Orth ld: * testsuite/ld-sparc/sparc.exp: Run sparctests, sparc64tests on Solaris. 2026-01-22 Indu Bhagat gas: sframe: graceful handling of bogus sleb128 input Currently, sframe_xlate_escape_sleb128_to_offsetT () uses a gas_assert to sanity check that a DWARF sleb128 value was successfully read from a single-byte buffer. However, if the byte provided has the highest bit set (e.g., bogus input of 0x80), the value of 'read' variable will be 0, triggering an assertion failure. This concern was raised during the review of SFrame-V3 patches https://inbox.sourceware.org/binutils/807b5641-87c2-4109-9d33-bb8fa28ed5ef@suse.com/T/#u Change the internal API sframe_xlate_escape_sleb128_to_offsetT () to return an error code. Callers now check for SFRAME_XLATE_ERR_INVAL and proceed to a warning/exit path rather than aborting. gas/ * gen-sframe.c (sframe_xlate_escape_sleb128_to_offsetT): Return int status. Handle read failure gracefully. (sframe_xlate_do_escape_cfa_expr): Check returned error code of read_sleb128_to_int64 and jump to warn_and_exit on error. (sframe_xlate_do_escape_expr): Likewise. 2026-01-22 Tom Tromey Constify gdbserver "monitor" commands I noticed that the gdbserver "monitor" commands should take a const parameter. Approved-By: Simon Marchi 2026-01-22 Andrew Burgess gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp Bug PR gdb/33792 reported a gdb.server/fetch-exec-and-args.exp FAIL when using the native-gdbserver board: FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file The actual test output looks like this: (gdb) show remote exec-file The remote exec-file is unset, using automatic value "/tmp/build/gdb/testsuite/outputs/gdb.server/fetch-exec-and-args/fetch-exec-and-args". (gdb) FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file This test actually fails with native-gdbsever and native-extended-gdbserver boards. The problem is that these boards clear the sysroot. This exact test has the following conditions: + The qExecAndArgs is in use (see 'packet=on'). + We're not explicitly doing 'set remote exec-file ...' (see 'set_remote_exec=false'). + The test starts gdbserver without an executable (see 'test_server_with_no_exec'). + And because of the native-gdbsever board, the sysroot is "". What this means is that GDB knows that gdbserver doesn't have an executable thanks to qExecAndArgs, the user hasn't set an executable for GDB to use when starting a new inferior, but GDB does know that GDB and gdbserver can see the same filesystem due to the sysroot setting. GDB will then automatically use the current executable as the remote executable name. The test script doesn't expect this case, and so the test fails. Fix this by adjusting the script to expect the 'using automatic value ...' text when appropriate. I also extended the test_server_with_no_exec proc to take a new flag 'clear_sysroot', we now run the test with the sysroot set to 'target:' and with the sysroot set to "", even when using the 'unix' board. Additionally, I ran the test through check-all-boards and found one additional failure, when using --host_board=local-remote-host-native and --target_board=local-remote-host-native. In this case GDB copies the executable to the remote host, which changes its filename. When the filename appears in the 'using automatic value ...' text, I was expecting the filename assuming a local host. I could fix this, but it doesn't seem worth the extra complexity for this one test, so I've just set the test to be skipped for that one configuration. Now, when using check-all-boards, I'm seeing no failures. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33792 Approved-By: Simon Marchi 2026-01-22 Rainer Orth bfd: Use PRIu64 to print uint64_t in elf-attrs.c elf-attrs.c has two more errors when built on 32-bit hosts: In file included from bfd/elf-attrs.c:140: bfd/elf-attrs.c: In function ‘oav2_parse_subsection’: bfd/elf-attrs.c:2752:29: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Werror=format=] 2752 | _bfd_error_handler (_("%pB: error: bad subsection length (%u > max=%lu)"), In file included from bfd/sysdep.h:165, from bfd/elf-attrs.c:140: bfd/elf-attrs.c: In function ‘_bfd_elf_parse_attributes’: bfd/elf-attrs.c:2910:12: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 4 has type ‘bfd_size_type’ {aka ‘unsigned int’} [-Werror=format=] 2910 | (_("%pB: error: attribute section '%pA' too big: %" PRId64), Fixed like this. Tested on sparc-sun-solaris2.11, i386-pc-solaris2.11, and i686-pc-linux-gnu with --enable-64-bit-bfd. 2026-01-22 Rainer Orth bfd: * elf-attrs.c (oav2_parse_subsection): Use PRIu64 to print uint64_t. (_bfd_elf_parse_attributes): Use PRIu64. Cast bfd_size_t arg to uint64_t. 2026-01-22 Andrew Burgess gdb: pagination fix for emoji and unicode box output I noticed that, on a 24 line terminal, the new unicode boxed hint text was causing the pager to trigger unexpectedly: $ gdb -nx -nh GNU gdb (GDB) 18.0.50.20260107-git Copyright (C) 2026 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Find the GDB manual online at: ┃ ┃ http://www.gnu.org/software/gdb/documentation/. ┃ ┃ For help, type "help". ┃ ┃ Type "apropos " to search for commands related to . ┃ --Type for more, q to quit, c to continue without paging-- At this point there are 6 unused lines remaining in my terminal, so the pager should not have triggered yet. There are two problems here, both in pager_file::puts (in utils.c). Lets start with the easy problem first. When content is written to the pager_file we process it within a loop looking for a newline character. We handle some special cases, but if none of them apply we handle all general, printable, content with this block: else { m_wrap_buffer.push_back (*linebuffer); chars_printed++; linebuffer++; } This copies one byte from LINEBUFFER to M_WRAP_BUFFER, and increments CHARS_PRINTED. The problem is that the unicode box characters are multi-byte, this means we are over incrementing CHARS_PRINTED by counting each byte of the unicode character as one output character. GDB believes that the top line of the box is actually going to span over multiple screen lines due to the large number of bytes within the line. In reality of course, the multi-byte characters fill exactly one screen line. I propose fixing this by making use of mbrlen to spot multi-byte characters and count them as a single character. If mbrlen returns anything less than 1 (which indicates a null character, or an invalid character), then I just treat this as a single byte character and continue as before. This means if any "weird" output is sent to the pager then it will still be printed. The null wide character case shouldn't occur as the null wide character is still all zeros, which the outer control loop in ::puts should catch, so all I'm really concerned about is the invalid wide character case. Handling multi-byte wide characters does make things a little better, but doesn't fix everything. The pager still activates unnecessarily, but just a little later. On the same 80x24 terminal, the output is now: $ gdb -nx -nh GNU gdb (GDB) 18.0.50.20260107-git Copyright (C) 2026 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Find the GDB manual online at: ┃ ┃ http://www.gnu.org/software/gdb/documentation/. ┃ ┃ For help, type "help". ┃ ┃ Type "apropos " to search for commands related to . ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ --Type for more, q to quit, c to continue without paging-- We managed to get an extra line of output printed, but there is still enough room on the terminal to print everything, so why is the pager triggering? The problem now is how we deal with lines that entirely fill the terminal, and how we handle newlines. Within the pager_file::puts inner loop we process input from LINEBUFFER and copy it to the M_WRAP_BUFFER, incrementing CHARS_PRINTED as we do. This continues until we reach the end of LINEBUFFER, or until we reach a newline within LINEBUFFER. After each character is added to M_WRAP_BUFFER, we check CHARS_PRINTED to see if we have filled a line. If we have then we flush M_WRAP_BUFFER and increment LINES_PRINTED. If enough lines have now been printed then we activate the pager. Alternatively, if we encounter a newline character in LINEBUFFER then we flush M_WRAP_BUFFER and increment LINES_PRINTED, then we re-enter the inner loop, which includes performing a check to see if the pager should trigger. The problem here is that when we print the box, we entirely fill a screen line, and then print the newline character. When we print the final non-newline character then this is enough to trigger the line full logic, this flushes the line and increments LINES_PRINTED. The CHARS_PRINTED count is also reset to zero. Then we print the newline. This never enters the inner loop, but just goes straight to the newline handling code, which increments LINES_PRINTED and also resets CHARS_PRINTED to zero. Notice that we've now incremented LINES_PRINTED twice. This is the cause of the premature pager activation; lines that are exactly one screen width wide end up being double counted. My initial thoughts when trying to fix this were to move the full line check before the code which copies content from LINEBUFFER to M_WRAP_BUFFER, inside the pager_file::puts inner loop. This would mean we only check for a full line when processing the next byte of output after we've filled a screen line, but we'd never encounter this check if the first byte after a full screen line was the newline character, as in this case we'd never enter the inner loop. And this does indeed fix the immediate problem, but I think, is still not correct. On an 80 character wide terminal, what we actually care about, is when we try to add the 81st _printable_ character. If the 81st character was a tab then this doesn't wrap onto the next line. Or if the 81st character was \r, then this certainly doesn't wrap to a new line, it just resets the current line. And the same is true for the 82nd character, and so on. The only time we need to trigger a new screen line is when we try to actually print something that will be displayed to the user. It turns out, I think, that we only want to check for a full line inside the block that I mentioned above, the one I just updated to use mbrlen. This is the only place where printable content is copied from LINEBUFFER into M_WRAP_BUFFER. There are still some edge cases here that are not being handled correctly, some unicode characters are non-printable, or stack on the previous character, requiring zero width. And even some of the basic ASCII characters that we don't cover are non-printable. But I'm choosing to ignore all of these for now. These cases were broken before this patch, and continue to be broken afterwards. Broken here simply means that including these characters in GDB's output will confuse the pager, likely resulting in the pager triggering too early. But for printable characters that are 1 terminal character wide, things should now be a little better. The pager will trigger only when we try to add the first character that wraps onto the next screen line. In our original problem with the box, this means that when the top border of the box is printed this will no longer cause an increment of LINES_PRINTED. When the newline is added then this does finish off the current line and increments LINES_PRINTED as expected. We now only increment LINES_PRINTED once for each line of the box, rather than twice, and so the pager no longer needs to trigger during startup. To make the code cleaner, I moved the full line check into a new function, pager_file::check_for_overfull_line(), and added comments in the LINEBUFFER handling code to explain when the new function should be called. The test gdb.python/py-color-pagination.exp needed some updates after this patch, the current expected output was tied to how the pager used to operate. Now that we defer starting a newline until we see some printable characters GDB is better able to coalesce adjacent style changes, this accounts for the large volume of changes to this test. I've also added a couple of new tests to the gdb.python/py-color-pagination.exp file. An initial failed idea I had for fixing this problem caused a bug such that empty lines would never have triggered the pager, there's a new test that covers this case. There's also a test that lines can exceed the screen width so long as the extra content is non-printable; the test fills a line then prints some tabs and a '\r' before filling the same line a second time. There are also a couple of new pager self tests that I added. I wrote these because early on while investigating this issue, I thought I'd spotted a bug in pager_file::wrap_here, so I wrote these tests to expose that bug. It turned not to be a bug, but a gap in my understanding. I think retaining these tests isn't going to hurt, and increases coverage. Approved-By: Tom Tromey 2026-01-22 Tom de Vries [gdb/build] Declare gdb_get_ncolors Since a recent commit, I run into: .... gdb/ui-style.c: In lambda function: gdb/ui-style.c:597:20: error: ‘gdb_get_ncolors’ was not declared in this scope 597 | int colors = gdb_get_ncolors (); | ^~~~~~~~~~~~~~~ make: *** [Makefile:2096: ui-style.o] Error 1 .... Fix this by adding the missing declaration. 2026-01-22 Matthieu Longo bfd: use correct format specifier for uint64_t 2026-01-22 Thiago C Silva binutils: Fix broken bullet lists in objcopy documentation The documentation for --add-gnu-debuglink and --extract-symbol uses diverse formatting styles for list items, including @table and manual bullets. This looked broken in the generated man pages, showing raw text artifacts like "*<..>" instead of real bullet points. This patch unifies these sections to use @itemize @bullet, resulting in cleaner output and better readability for these options. binutils/ * doc/binutils.texi (objcopy): Use @itemize @bullet for --add-gnu-debuglink and --extract-symbol. 2026-01-22 Thiago C Silva binutils: Fix broken numbering in strip/objcopy --only-keep-debug doc The documentation for --only-keep-debug displayed the procedure steps as "1. 1. 1. 1." in the man pages, despite using the @enumerate command. This patch moves the item text to the line following the @item tag and adds whitespace between items. This forces the man page generator to correctly distinguish the items and increment the list counter. binutils/ * doc/binutils.texi (strip, objcopy): Reformat @enumerate list to fix man page numbering. 2026-01-22 Eli Zaretskii gdb: Support UTF-8 output on MS-Windows terminal This detects when the Windows Terminal uses codepage 65001 (a.k.a. "UTF-8") for output, and sets the default host charset to UTF-8 in that case. It also enables Emoji styling, as the Windows terminal supports it in that case. * gdb/charset.c (INIT_GDB_FILE) [USE_WIN32API]: If the Windows console uses codepage 65001, set default host charset to UTF-8, and switch to the "C" locale, to prevent Windows from interpreting UTF-8 sequences written to the console. * gdb/mingw-hdep.c (windows_initialize_console): Don't disable Emoji here... * gdb/charset.c (INIT_GDB_FILE) [USE_WIN32API]: ...disable them here instead, and only if the console doesn't use UTF-8. 2026-01-22 Eli Zaretskii gdb: Support 24-bit colors and other attributes on MS-Windows This enables Virtual Terminal Sequences on MS-Windows consoles when they are supported. (All modern Windows versions since v10 support that.) This allows to support 24-bit true-color and also other text attributes, like "dim" and "underline". * gdb/mingw-hdep.c (mingw_use_console_color_apis): Rename from mingw_console_initialized. (orig_console_mode, virt_mode_flags): New static variables. (windows_initialize_console): Setup the console for using Virtual Terminal Sequences if that is supported. (mingw_deinitialize_console, gdb_get_ncolors): New functions. * gdb/ui-style.c (colorsupport): Call gdb_get_ncolors to retrieve the number of colors supported by the terminal. If the number of colors is greater or equal 16777216, consider 24-bit color supported. * gdb/top.c (undo_terminal_modifications_before_exit) [__MINGW32__]: Call mingw_deinitialize_console to restore original settings of the terminal. * gdb/posix-hdep.c (gdb_get_ncolors): New function, a trivial wrapper for tgetnum. 2026-01-22 Alan Modra libgot-1 testcases There is no need for multiple tests of readelf --got-contents, nor should the matching be so strict that changes in section layout force editing of the testsuite. It also looks to me that the i386 --got-contents output is wrong, at least it is confusing to have .rel.plt show 0020020c 00000307 R_386_JUMP_SLOT 00000000 bar while the corresponding got-contents dump shows "bar + 156". 3: 0020020c R_386_JUMP_SLOT bar + 156 * testsuite/ld-i386/binutils.exp: Reduce number of tests. * testsuite/ld-i386/libgot-1.rd: New. * testsuite/ld-i386/libgot-1a.rd, * testsuite/ld-i386/libgot-1b.rd, * testsuite/ld-i386/libgot-1c.rd, * testsuite/ld-i386/libgot-1d.rd: Delete. * testsuite/ld-x86-64/binutils.exp: Reduce number of tests. * testsuite/ld-x86-64/libgot-1.rd: New. * testsuite/ld-x86-64/libgot-1a.rd, * testsuite/ld-x86-64/libgot-1b.rd, * testsuite/ld-x86-64/libgot-1c.rd, * testsuite/ld-x86-64/libgot-1d.rd: Delete. * testsuite/ld-x86-64/libgot-1-x32.rd: New. * testsuite/ld-x86-64/libgot-1a-x32.rd, * testsuite/ld-x86-64/libgot-1b-x32.rd, * testsuite/ld-x86-64/libgot-1c-x32.rd, * testsuite/ld-x86-64/libgot-1d-x32.rd: Delete. 2026-01-22 Andrew Burgess gdb: fix 'info frame' for tail calls with no debug information If the inferior stack contains a tail call function. And if the CU containing the tail call function doesn't have any debug information. And if the user uses 'info frame' to examine the tail call frame, then GDB will report the wrong function name, for example: Breakpoint 1, 0x000000000040110a in callee () (gdb) bt #0 0x000000000040110a in callee () #1 0x0000000000401116 in caller () #2 0x0000000000401140 in main () (gdb) up #1 0x0000000000401116 in caller () (gdb) frame #1 0x0000000000401116 in caller () (gdb) info frame Stack level 1, frame at 0x7fffffffa440: rip = 0x401116 in dummy_func; saved rip = 0x401140 called by frame at 0x7fffffffa450, caller of frame at 0x7fffffffa430 Arglist at 0x7fffffffa430, args: Locals at 0x7fffffffa430, Previous frame's sp is 0x7fffffffa440 Saved registers: rbp at 0x7fffffffa430, rip at 0x7fffffffa438 (gdb) Notice that 'info frame' claims that the current frame is 'dummy_func' rather than 'caller', as the 'backtrace', 'up', and 'frame' commands claim. This is because 'backtrace', 'up', and 'frame' all uses print_frame to print the frame details, which in turn uses find_frame_funname to get the frame's function name. In contrast, 'info_frame_command_core' contains an inlined copy of 'find_frame_funname' with one key difference. The code in info_frame_command_core uses get_frame_pc_if_available while find_frame_funname uses get_frame_address_in_block_if_available. The latter function returns '$pc - 1' if the frame in question could be a tail call function, while get_frame_pc_if_available always returns $pc. This difference means that, for a tail call function, GDB will lookup the wrong msymbol. Fix this by updating info_frame_command_core to use find_frame_funname. We end up still keeping the call to get_frame_pc_if_available as 'info frame' still needs to print this address. There should be no other noticeable changes after this commit. There's also a test in which I have tried to create a tail call function in a (relatively) target agnostic way. I compile a test program, pull some addresses from it, then recompile the test to assembly, and augment the assembler output, changing one symbol size, and adding an entirely new function symbol. The modified assembly file is then compiled, without debug information, to create the actual test executable. This gives GDB the impression that the test contains a tail call function. Approved-By: Tom Tromey 2026-01-22 Matthieu Longo gnu directives: bfd: generic tests for merge of gnu attributes v2 These tests are a copy-paste of the generic tests for AArch64. Test cases: - only one input object is copied to the output object - merge two inputs with optional subsections of both types ULEB128 and NTBS, which contains same, additional, and missing attributes. - mismatch subsection properties. - combine matching required subsections. - combine non-matching required subsections. - prune unknown attributes in known subsections. - prune unknown subsections. 2026-01-22 Matthieu Longo gnu directives: bfd: generic tests for objcopy of gnu attributes v2 2026-01-22 Matthieu Longo gnu directives: gas/readelf tests for gnu attributes v2 These tests are a copy-paste of the generic parsing tests for AArch64. The added tests cover the parsing of the new assembly directives (gnu_subsection and gnu_attribute), the serialization of the Object Attributes v2 (OAv2) data into an object file, and the dumping of those data via readelf. The parsing tests focus on the following points: - the syntax of the new directives. - the recognition of generic tokens like: NTBS, ULEB128, required, optional. The dumping tests focus on: - the OAv2 population into the correct section assigned by the backend. - the merge of the subsections and attributes when they are declared several times inside respectively the same compilation unit, and subsection. - the sorting of OAv2 before the serialization. 2026-01-22 Matthieu Longo gnu directives: add support for .gnu_attribute and .gnu_subsection in OAv2 context This patch adds support for the GNU directives .gnu_attribute and .gnu_subsection, used respectively for OAv1 and OAv2, and for OAv2 only. These directives behave like their AEABI counterparts, as they are aliases intended for use by any backends supporting OAv1 and/or OAv2. Their availability is controlled by the TC_OBJ_ATTR_v1 and TC_OBJ_ATTR_v2 macros. Previously, the "gnu_" subsection namespace was used only for "gnu_testing_" and defaulted to a private scope. This patch updates the scope recognition to correctly distinguish between private usage (e.g., testing) and public usage (e.g., actual GNU subsections storing public information). 2026-01-22 Matthieu Longo ld tests for AArch64-specific merge coverage for AEABI Build Attributes Test cases: - coverage of required subsection 'aeabi_pauthabi'. - coverage for BTI, PAC, GCS used along GNU properties. - warn on unknown attributes, and prune them from output. 2026-01-22 Matthieu Longo aarch64: merge of Object Attributes v2 during linkage This patch adds support to AArch64 backend to process AEABI Build Attributes and raise any compatibility issue. AArch64 backend declares 2 vendor subsections, and their associated tags: - aeabi_feature_and_bits: contains tags that describe the same optional bits as the GNU_PROPERTY_AARCH64_FEATURE_1_AND. For now, the following attributes are recognized: - Tag_Feature_BTI: means that all the executable sections are compatible with Branch Target Identification (BTI) mechanism. - Tag_Feature_PAC: means that all the executable sections have been protected with Return Address Signing. - Tag_Feature_GCS: means that all the executable sections are compatible with the Guarded Control Stack (GCS) extension. - aeabi_pauthabi: contains information about the Pointer Authentication Signing schema when the object uses an extension to ELF, PAUTHABI64, which is currently not supported by GCC toolchain. The pointers that are signed as well as the modifiers and key used for each type of pointer are known as the signing schema. The support of this subsection is there for completeness with the AEABI Build Attributes document, and allows readelf to dump the data nicely, and the linker to detect a use of a signing schema, and error. - Tag_PAuth_Paltform: the platform vendor id. - Tag_PAuth_Schema: the version numner of the schema. For backward-compatibilty purpose, AArch64 backend translates GNU_PROPERTY_AARCH64_FEATURE_1_AND in input files to its OAv2 equivalents. The frozen set of OAv2 is populated with values derived from command-line options for BTI (-z force-bti) and GCS (-z gcs=*). It also reports incompatibilities for BTI and GCS, and set BTI PLT type depending on the OAv2 merge result. Regarding incompatibilities, only the ones detected in objects constituting the output link unit will be reported. Supports for detecting incompatibilities in shared objects might be a future work to bring it in pair with the GNU properties merge. However, since OAv2 are translated to GNU properties, detection will still happen so this feature seems redundant and of little value given the backward compatibility support for GNU properties is required (see next paragraph). Finally, it translates OAv2s in subsection "aeabi_feature_and_bits" to GNU_PROPERTY_AARCH64_FEATURE_1_AND as GNU properties are required for the dynamic linker (it does not understand OAv2s yet). 2026-01-22 Matthieu Longo ld tests for generic merge coverage of Object Attributes v2 Test cases: - only one input object is copied to the output object - merge two inputs with optional subsections of both types ULEB128 and NTBS, which contains same, additional, and missing attributes. - mismatch subsection properties. - combine matching required subsections. - combine non-matching required subsections. - prune unknown attributes in known subsections. - prune unknown subsections. 2026-01-22 Matthieu Longo OAv2 merge: translate GNU properties to Object Attributes v2 (and vice versa) Some input objects may contain inconsistencies, i.e. they might include GNU properties but lack the corresponding object attributes, or inversely. The later case is never produced by Gas, but the former can occur with older Gas versions that do not support object attributes. To keep consistency during the merge process, each input object's GNU properties are translated into their object attributes equivalents (if they exists). Also, after object attributes have been merged at the file scope, they are translated back to GNU properties to keep the GNU properties merge process consistent. This final translation occurs before merging the input with the global merge accumulator (a.k.a. REF) and the global configuration (a.k.a FROZEN). Note: the first parameter of translate_obj_attrs_to_gnu_props(), bfd *, should be 'const', but this implies that _bfd_elf_get_property() should also be constified, and this is out of scope. 2026-01-22 Matthieu Longo OAv2 merge: prune unsupported or invalid subsections and attributes During the merge, each subsection and attribute is assigned a status. If the status is OK, the item is retained and serialized into the output object. Otherwise, unsupported or invalid subsections and attributes are pruned before serialization. When a subsection or attribute is pruned, ld emits information-level messages to inform the user, preventing confusion about the absence of elements that were present in the input objects. 2026-01-22 Matthieu Longo OAv2 merge: merging Object Attributes The Object Ottributes merge process must handle both optional and required subsections. It also treats the first merge of the frozen set specially, as the OAv2 list in the input BFD serves as the accumulator for subsequent merges. ** Optional subsections Optional subsections are processed as if merging two ordered sets — by iterating linearly through both, checking whether an element of a given ordinality is present in the opposite set, and adding it to the accumulator. The added diffuculty with subsections and attributes lies in the fact that missing elements have default values, and these must be merged with existing ones to produce the final value to be stored. ** Required subsections Required subsections are processed slightly differently from the optional subsections, as they cannot be pruned since they are mandatory, hence an error will be raised by the linker if it is not recognized. For now, the subsection for PAuth ABI is the only one use case, and no merge is applied on the values. The values simply need to match. This implementation choice might be challenged in the future if required subsections can have the same diversity as optional subsections. If the case arises, the refactoring to handle this new behavior should consist in adding a new merge policy MERGE-EQUAL, or something similar. Some "if required" should be added in the optional subsections merge logic to error on any missing elements, or mismatch, and messages should also be rephrased to point out that the error is for a required subsection. ** Important note regarding support for testing In order to test this generic logic, AArch64's use cases are not offering enough coverage, so a "GNU testing namespace" which corresponds to the name of the subsection was introduced. It follows the following pattern: gnu_testing__MERGE_ with: - : an arbitrary name for your testing subsection. - : the name of the merging policy to apply on the values in the subsection. The currently supported merge policy are: * _MERGE_AND: bitwise AND applied on numerical values. * _MERGE_OR: bitwise OR applied on numerical values. * _MERGE_ADD: concatenates strings together with a '+' in-between. Note: "_MERGE_ADD" does not make really sense, and will very likely never be used for a real merge. Its only purpose is to test the correct handling of merges with strings. Any subsection name matching neither names supported by the backend, nor following the pattern corresponding GNU testing namespace will be considered unknown and its status set to obj_attr_subsection_v2_unknown. This will have for consequence the pruning of this subsection. Additionally, the first two tags in gnu_testing namespace, GNUTestTag_0 and GNUTestTag_1, are known, and so have a name and can be initialized to the default value ('0' or NULL) depending on the encoding specified on the subsection. Any tags above 1 will be considered unknown, so will be default-initialized in the same way but its status will be set to obj_attr_v2_unknown. This behavior of the testing tags allows to test the pruning of unknown attributes. 2026-01-22 Matthieu Longo OAv2 merge: mark unknown subsections In Object Attributes v2, the merge policy is not encoded within the subsection definition. It is therefore up to the linker to determine the appropriate policy based on the subsection's name and properties. Unless a subsection is explicitly recognized by the linker, the spefication of OAv2 provides no means to infer its merge policy. Furthermore, in theory, this merge policy could vary between attributes within the same subsection. As a result, before beginning the merge process, ld inspects each subsections, and attempts to identify them as either a GNU subsection, or a backend-specific one. If this identification fails, the status of the subsection is set to 'UNKNOWN'. Subsections marked as unknown are then skipped during the merge process, and later pruned from the output before the serialization. 2026-01-22 Matthieu Longo OAv2 merge: merge subsections and tags at file scope Before merging input object files together, each input's object attributes must be sanitized to ensure that duplicate subsections and attributes are merged and properly sorted. Indeed, uniqueness and ordering of subsections and attributes are required prerequisites for the merge process. This operation also handles, on a best-effort basis, exotic objects produced by non-GNU assemblers, where duplicate subsections may appear across different sections, and similarly, duplicate attributes across subsections. It is importand to note that such cases are not covered by the Object Attributes specification, and the resulting behavior is implementation -defined. Other linkers may handle these inputs differently. 2026-01-22 Matthieu Longo OAv2 merge: create a section for object attributes bfd copies object attributes to the output BFD only if the input BFD — used to store the merge result— contains an object attribute section. bfd_linear_find_first_with_obj_attrs() returns an input BFD that may or may not already include such a section. If no object attributes section is found, the merge process must create one. This patch implements create_object_attributes_section(), which constructs the missing section with the appropriate flags, type, and alignment. The implementation is adapted from _bfd_elf_link_create_gnu_property_sec() in bfd/elf-properties.c. The code preserves the different alignment requirements for 32-bit and 64-bit ELF formats, although the rationale for this distinction remains unclear in the original source and patch history. 2026-01-22 Matthieu Longo OAv2 merge: find first input containing an object attributes section During the merge process, the linker first scans the list of input files to identify ELF object files that contain object attributes. If no such object file is found, the merge process terminates. Otherwise, the first matching file is used as the placeholder for the global merge result. This patch implements a linear search to locate the first input BFD containing an Object Attributes section, while recording a good candidate otherwise. It is worth noting that the position of the object file in the list, as well as whether it contains object attributes or not, or whether it contains an object attributes section or not, are not significant. Any input ELF object files could serve this placeholder purpose if the merge process was performed in parallel. 2026-01-22 Matthieu Longo OAv2 merge: plumbing of generic merge logic during linkage This patch adds the plumbing for the OAv2 generic merge logic in the linker. The linker is an "advanced" consumer of OAv2. After parsing, it deduplicates the attributes, merges them, detects any compatibility issues, and finally translates them to GNU properties. This patch only prepares the infrastructure required to support that processing. All operations described below rely on helpers or stubs, and their implementation details will be added in the subsequent patches. ** Intended pipeline Disclaimer: the description below documents the intended processing pipeline. This commit only establishes the phases boundaries, and call sites. The actual logic of each step is implemented in subsequent patches. The OAv2 processing pipeline follows a map-reduce pattern. Obviously, the actual processing in GNU ld is not multi-threaded, and the operations are not necessarily executed directly one after another. * Phase 1, map: successive per-file operations applied on the list of compatible input objects. 1. Parsing of the OAv2 section's data (also used by objcopy). 2. Translation of relevant GNU properties to OAv2. This is required for the backward-compatibility with input objects only marked using GNU properties. 3. Sorting of the subsections and object attributes. Further operations rely on the ordering to perform some optimization in the processing of the data. 4. Deduplication of subsections and object attributes, and detection of any conflict between duplicated subsections or tags. 5. Translation of relevant OAv2 to GNU properties for a forward -compatibility with the GNU properties merge. 6. Marking of unknown subsections to skip them during the merge (in phase 2), and to prune them before the output object's serialization (in phase 3). * Phase 2, reduce: OAv2 in input objects are merged together. 1. Gathering of "frozen" values (=coming from the command-line arguments) into a virtual read-only list of subsections and attributes. 2. Merging of OAv2 from an input file and the frozen input. 3. Merging of the results of step 2 together. Since the OAv2 merge is commutative and associative, it can be implemented as a reduce. However, GNU ld implements it as an accumulate because it does not support multithreading. Notes: the two merge phases also perform a marking of unsupported/ invalid subsections and attributes. This marking can be used for debugging, and also more practically, to drop unsupported optional subsections from the output. * Phase 3, finalization of the output. 1. Pruning of the unknown / unsupported / invalid subsections and attributes. 2. Serialization of OAv2 data (also used by objcopy). Notes: - There is no translation of the merged OAv2 to GNU properties at this stage, as the GNU properties merge process has already all the needed information (translated in step 5 of stage 1) to produce the GNU properties equivalents. - The GNU properties are currently required as the runtime linker does not understand OAv2 yet. - Phase 3 should also include a compatibility check between the final merge result of the current link unit and input shared objects. I opted for postponing this compatibility check, and GNU properties merge will take care of it as it already does. 2026-01-22 Matthieu Longo objcopy tests for Object Attributes v2 bfd: add support for copying Object Attributes v2 The OAv2 section's content of the source file is copied to the destination object file without any alteration of the attributes or subsections (no deduplication nor sorting of subsections or object attributes is performed). For now, only ELF format is supported. 2026-01-22 Matthieu Longo bfd: parse Object Attributes v2's section in input object files This patch adds to BFD the capability of parsing the Object Attributes v2 (OAv2) stored into the section defined by the backend (i.e. .ARM.attributes for AArch64). An OAv2 section is organized with the following syntactic structure: [ * ]* Once parsing is completed, OAv2 are stored in a list of subsections in elf_obj_tdata. Regarding ULEB128 parsing, the implementation of _bfd_safe_read_leb128 has known shortcomings. In particular, it may accept malformed ULEB128 values if the 8th bit is set while meeting the end condition "data < end". The error handling could be improved, but this function is old and used in more than 50 places. The same issue applies to _bfd_read_unsigned_leb128 and _bfd_read_signed_leb128, which likewise do not report errors in this case. Since this is long-standing behavior and fixing it would require broader changes outside the scope of this patch series, the issue is acknowledged but not addressed here, and is considered acceptable as this patch does not worsen the situation. 2026-01-22 Richard Ball Serialization and dumping tests of Object Attributes v2 The added tests cover the parsing of the new assembly directives (aeabi_subsection and aeabi_attribute), the serialization of the Object Attributes v2 (OAv2) data into an object file, and the dumping of those data via readelf. The parsing tests focus on the following points: - the syntax of the new directives. - the recognition of generic tokens like: NTBS, ULEB128, required, optional. - the recognition of backend-specific tokens like Tag_Feature_(BTI, PAC,GCS). The dumping tests focus on: - the OAv2 population into the correct section assigned by the backend (i.e. .ARM.attributes for AArch64). - the merge of the subsections and attributes when they are declared several times inside respectively the same compilation unit, and subsection. - the sorting of OAv2 before the serialization. Co-Authored-By: Matthieu Longo 2026-01-22 Richard Ball readelf: dump Object Attributes v2 This patch adds support to readelf for displaying Object Attributes v2 on AArch64. The list of known tags and subsections match the ones in the document "Build Attributes for the Arm 64-bit Architecture (AArch64)" available at [1]. [1]: https://github.com/ARM-software/abi-aa Co-Authored-By: Matthieu Longo 2026-01-22 Richard Ball bfd: write Object Attributes v2 This patch adds the serialization logic to write Object Attributes v2 (OAv2) into the ELF section specified by the backend (.ARM.attributes for AARch64). OAv2, once processed by the parser, are stored in the order they were declared in the assembly, so not necessarily sorted. Sorting them simplifies the comparison of the data between several files. Since sorting OAv2 is clearly not the responsibility of readelf, they need to be sorted by the producers (i.e. gas or ld). The linker sorts the subsections and attributes as a pre-requisite of the merge. Since the merge preserves the ordering, no final sort is required before the serialization, contrarilly to the assembler. Moving the final sort for gas into set_obj_attr_contents would mean that a sort would be performed on an already-sorted collections. To avoid this redundant operation at link time, we check whether the output BFD is a linker output (is_linker_output = 1). If it is not (i.e., it is gas), we perform a finalization step that sorts the subsections and attributes before writing. As previously mentioned, the logic of OAv1 and OAv2 is kept separated. Co-Authored-By: Matthieu Longo 2026-01-22 Matthieu Longo gas: use common code for object attribute v1 & v2 parsing Since the previous patch added all the code to be able to parse both OAv1 and OAv2 directives, this patch switches OAv1 to use this common code. Additionally to the common code in obj-elf.c, the following backends using a custom object attribute directive were impacted. - ARC - Arm - m68k - PowerPC - RISC-V - TI C6X A parsing test for Arm had to be adapted to the error messages of the new parser. The gas and ld test suites were successfully run for the following backends: S390, ARC, Arm, CSky, m68k, msp430, PowerPC, TI C6X, RISC-V, AArch64, MIPS, SPARC. 2026-01-22 Richard Ball gas: implement parsing of object attributes v2 This patch adds the parsing logic for Object Attributes v2 (OAv2), enabling Gas to interpret and process these attributes correctly. It also updates the AArch64 backend to utilize the new parsing capabilities, and handle the new AArch64-specific directives. This patch relies on the abstractions introduced in the previous patch to store the data. Its scope is limited to parsing the new assembly directives, checking the inputs, and storing the data into the relevant OAv2 abstractions. Note that, for now, the new parsing capabilities are only available for AArch64. Even if the implementation was splitted into a generic part available in gas/config/obj-elf.c, and an AArch64-specific one in gas/config/tc-aarch64.c, the lack of GNU generic directives to handle OAv2 prevented the capability from being exposed to others backends. ** GNU assembler interface for aeabi subsections OAv2 introduced two new directives for AArch64: - .aeabi_subsection name, comprehension, encoding Create or switch the current subsection to 'name'. Comprehension values can be 'required' or 'optional'. Encoding values are limited for now to 'ULEB128', and 'NTBS' The comprehension and encoding are mandatory arguments on the first declaration of the subsection, but become optional for subsequent ones. - .aeabi_attribute tag, value Set 'tag' to 'value' in the current subsection. Tag can either be an integer, or one of the defined symbols in the backend. The usage of those directives will error if the following requirements are breached: - If the subsection X has been previously declared, the comprehension and encoding parameters of the current .aeabi_subsection that redeclares X have to match with the previous declaration. If those parameters are omited, no check is performed. - The type of the value set via .aeabi_attribute has to align with the current subsection. - If the tag N has already been declared for the current subsection, a later assignment to tag N is tolerated only if the newly set value is equal to the former one. This check is stricter than needed. Ideally, the tag N's values should be merged together, and an error should be raised only if an incompatibility is detected. Because the attributes are set in one chunk by GCC, there is no real use case for such a merge. The new parsing code is enabled/disabled via the TC_OBJ_ATTR_v1 and TC_OBJ_ATTR_v2 defines, and supports the following configurations: - enable both OAv1 and OAv2 parsing. This is currently used by no target, but is useful for migration from OAv1 to OAv2. - enable OAv1 parsing only. This is used by all targets supporting OAs except for AArch64. - enable OAv2 parsing only. This is only used by AArch64. ** Regarding the implementation The logic of OAv1 does not always keep separated the different data processing steps: parsing, convertion to internal abstractions, error checking and further processing (if any) on those abstractions, and their serialization into the object files. This patch takes into account the specifities of syntax for OAv1 and OAv2, but mutualize as much as possible the common behavior so that the same methods can be used for parsing the OAv1 and OAv2 directives. However, the mutualization of the code is limited by a different internal model for OAv1 and OAv2. Even if it is technically feaseable to have only one middle -end for OAv1, OAv2 and even GNU properties, sharing the same data model to perform the merge logic with the same code, it is a significant amount of work. This extra work was not considered as a part of this new feature, so this patch series will stick with the minimum of mutualization as possible. Co-Authored-By: Matthieu Longo 2026-01-22 Richard Ball Object Attributes v2: new abstractions for subsections and attributes This patch lays the groundwork for the support of Object Attributes v2 (OAv2). OAv2 is an enhancement of OAv1. They retain successful aspects of OAv1, define the relationship between object attributes and existing GNU properties, separate architectural requirements from software ABI requirements, and simplify the format to make it easier for OAv2 consumers to parse, and skip subsections and attributes. Interestingly, OAv2 have only one scope: the whole relocatable file where they were specified. For the reason behind this choice, see [1], "Build attributes at file scope only". This document also provides more insights into the design rationale for OAv2. Even if OAv2 was designed primarily for AArch64, this implementation splits the generic core logic from the backend-specific one, and aims at facilitating OAv2 adoption by others backend. This logic will apply for any subsequent OAv2 patch. New abstractions for attributes and subsections are introduced in bfd/elf-attrs.h Those align with the format of OAv2 proposed in [2]. An object attribute obj_attr_v2 is a tag-value pair: - tag: a key, i.e. a unique identifier for the attribute in the subsection. - value: a variant for which the interpretation depends on the encoding set in the subsection it was stored in. 2 types of values are possible: ULEB128 (Unsigned Little Endian Base 128) or a string encoded as NTBS (Null-Terminated Byte String). A subsection obj_attr_subsection_v2 has the following members: - name: the name of this subsection. - scope: the prefix in the subsection name determines whether the subsection is public or private. - optionality: is this subsection optional or required ? Depending on whether the subsection is public or private, it can be ignored by the consumer. - encoding: see previous note regarding the value of an attribute. This encoding applies to all the attributes in this subsection. - list of object attributes. Even if OAv1 and OAv2 data structures are similar, their processing is different. Thus refactoring the code of OAv1 and OAv2 to share it does not seem the right approach for clarity and maintainability, and minimalization of the risk of introducing regressions. Consequently, utility functions to initialize, copy, swap, free, compare, mutate, and sort those structures won't be shared between OAv1 and OAv2. Finally, the version ID used to identify the storage format of the object attributes is object and backend dependent. This approach allows mixing OAv1 and OAv2 in input objects. Then the deserializer translates the input data to the internal model (currently OAv2, but it could be a more generic one in the future) to perform the merge. In the end, the output format is set by the backend: OAv2 for AArch64, OAv1 for others. The only exception for this is objcopy, which won't change the format of the object attributes, and will preserve the format of the data during the copy. Hopefully, this mechanism will make easy the migration from OAv1 to OAv2 if anyone is interested. [1]: [Design Rationale for Build Attributes for the Arm 64-bit Architecture (AARCH64)] (https://github.com/ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc /design-documents/buildattr64-rationale.rst) [2]: [Build Attributes for the Arm® 64-bit Architecture (AArch64)](https://github.com /ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc/buildattr64 /buildattr64.rst) Co-Authored-By: Matthieu Longo 2026-01-22 Tom de Vries [gdb/symtab] Fix segfault in cutu_reader::read_toplevel_die PR 33818 reports a problem when running test-case gdb.ada/uninitialized-variable-record.exp: ... (gdb) print y2 dwarf2/read.c:14073:20: runtime error: member access within null pointer of \ type 'struct dwarf2_cu' ERROR: GDB process no longer exists ... bisecting to commit 2f23cf07253 ("[gdb] Add regression test for PR symtab/33777"). I managed to reproduce it using target board readnow. The problem is here in cutu_reader::read_toplevel_die: ... m_new_cu.get ()->per_objfile->per_bfd->nr_toplevel_dies_read++; ... Class cutu_reader has two fields pointing to a dwarf2_cu: ... /* The CU of the DIE we are parsing. */ struct dwarf2_cu *m_cu; ... and: ... dwarf2_cu_up m_new_cu; ... and m_new_cu is not always set. Fix this by using m_cu instead. Reported-By: Jan Vrany Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33818 2026-01-22 Tom de Vries [gdb/testsuite] Fix regression in gdb.base/maint.exp After commit 2f23cf07253 ("[gdb] Add regression test for PR symtab/33777"), test-case gdb.base/maint.exp regressed: ... FAIL: gdb.base/maint.exp: maint print statistics ... Fix this by updating the expected output. Tested on x86_64-linux. Reported-By: Jan Vrany PR 33821 use after free commit e6357caf7579 reset_resolved_wilds didn't clear out matching_sections in output sections with constraint -1. Fix that and tidy call sites of obstack_init and obstack_free for matching_obstack so that the obstack is allocated later and freed completely. Also tidy ptroot. PR 33821 * ldlang.c (the_root): Delete, replacing with.. (ptroot): ..this, no longer a pointer. Update all uses. (lang_for_each_statement_worker): Add "constrained" param. Ignore os.constraint if false. (reset_resolved_wilds): Use lang_for_each_statement_worker. Move obstack_init.. (lang_init): ..and this obstack_init of matching_obstack.. (resolve_wilds): ..to here. * ldlang.h (lang_for_each_statement_worker): Update declaration. (lang_for_each_statement): Update. * emultempl/xtensaelf.em: Update lang_for_each_statement_worker calls throughout. 2026-01-22 Alan Modra sframe fre sanity checks I noticed the fre esz check in flip_sframe_fdes_with_fres_* was wrong, testing against the full buffer size rather than the remaining size. It is also ineffective at stopping buffer overflows to check after the buffer accesses have occurred. Likely many more buffer overflow checks in the sframe code are needed before anyone can claim it is secure. Even in the fre code, I see things like sframe_decoder_get_fres_buf merrily iterating over fres without a concern for buffer overflow. * sframe.c (flip_fre): Add fp_size param. Use it to avoid buffer overflow on fuzzed input. (flip_sframe_fdes_with_fres_v2): Pass remaining buffer size to flip_fre. Remove now redundant and wrong esz check. (flip_sframe_fdes_with_fres_v3): Likewise. 2026-01-22 Tom Tromey Remove lookup_transparent_type lang hook C++ was the only user of the lookup_transparent_type lang hook, so it can be removed entirely. basic_lookup_transparent_type and its helper function are renamed as appropriate. Approved-By: Simon Marchi 2026-01-22 Tom Tromey Remove cp_lookup_transparent_type cp_lookup_transparent_type seems to be a workaround for bugs in very old compilers. A comment mentions that the bugs are fixed in GCC 3.4 -- released in 2004. I think this is long past due for removal, which this patch does. Approved-By: Simon Marchi 2026-01-22 GDB Administrator Automatic date update in version.in 2026-01-21 Alan Modra hppa64 root.u.def assertions The aim here is to add assertions when root.u.def is accessed that the field is valid, ie. we have a bfd_link_hash_defined or bfd_link_hash_defweak symbol. On doing so I found the assertion triggering on one of the ld undefweak tests, fixed with the elf64_hppa_finish_dynamic_symbol change. The patch also refactors code using text_hash_entry and data_hash_entry. * elf64-hppa.c (elf64_hppa_finish_dynamic_symbol): Use zero value for both undefined and undefweak symbols, and when non-pic too. Assert when accessing root.u.def that the symbol is the correct type. (elf64_hppa_finalize_opd, elf64_hppa_finalize_dlt), (elf64_hppa_finalize_dynreloc): Similarly assert here. (elf64_hppa_finalize_dlt): Move duplicate code involving text_hash_entry and data_hash_entry out of conditionals. (elf64_hppa_finalize_dynreloc, elf_hppa_dlt_dynrel_reloc), (elf_hppa_final_link_relocate): Likewise. 2026-01-21 Indu Bhagat aarch64: s390: x86_64: sframe: adjust flex fde hook implementation A previous commit added new backend hook sframe_support_flex_fde_p by defining a new function for each backend that supports SFrame stack trace format: commit 2f9b3987db53d7e0606f89bfe2527dd3d0915568 [SFrame-V3] gas: sframe: add new backend hook sframe_support_flex_fde_p for FLEX FDEs As pointed out in a review comment, simply providing the definition to use true/false (as applicable) is sufficient for the purpose, and helps generate better code. So do that. https://inbox.sourceware.org/binutils/80404871-53b4-4f5c-9d86-7a3a4d0a920e@suse.com/ ChangeLog: * gas/config/tc-aarch64.c (aarch64_support_flex_fde_p): Remove. * gas/config/tc-aarch64.h (aarch64_support_flex_fde_p): Remove. (sframe_support_flex_fde_p): Define to false. * gas/config/tc-i386.c (x86_support_flex_fde_p): Remove. * gas/config/tc-i386.h (x86_support_flex_fde_p): Remove. (sframe_support_flex_fde_p): Define to true. * gas/config/tc-s390.c (s390_support_flex_fde_p): Remove. * gas/config/tc-s390.h (s390_support_flex_fde_p): Remove. (sframe_support_flex_fde_p): Define to true. 2026-01-21 Tom Tromey Remove angle brackets from "apropos" text I didn't notice during review, but the boxing patch introduced this change: - styled_string (command_style.style (), "apropos word")); + styled_string (command_style.style (), "apropos ")); GNU doesn't generally use the "<...>" convention, but instead uses upper case for "metasyntactic variables". See the GNU coding standards for this topic. In this particular spot, though, I think the old form using quotes is preferable. This patch reverts this change. Reviewed-By: Tom de Vries 2026-01-21 John David Anglin hppa64: Fallback to .text if .dynamic isn't found Commit a1c2fa92ac93bf50227941bd82094e6997c5fd56 broke the ld testcase for .note.GNU-stack wanting to be SHT_NOTE. Fix this by falling back to .text if .dynamic isn't available to define the text segment base. 2026-01-21 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_late_size_sections): Fallback to .text if .dynamic section isn't found. 2026-01-21 Tom de Vries [gdb] Ignore .sframe section in dtrace_static_probe_ops::get_probes On aarch64-linux (Debian testing), with test-case gdb.base/fission-macro.exp I run into: ... (gdb) set complaints 5^M (gdb) file fission-macro-v4-b32-s0^M Reading symbols from fission-macro-v4-b32-s0...^M During symbol reading: \ skipping section '.sframe' which does not contain valid DOF data.^M (gdb) FAIL: $exp: lang=c: dwarf_version=4: dwarf_bits=32: strict_dwarf=0: \ No complaints ... The problem is that there's an overlap between: ... ./include/elf/common.h:#define SHT_SUNW_dof 0x6ffffff4 ... and: ... ./include/elf/common.h:#define SHT_GNU_SFRAME 0x6ffffff4 ... So when dtrace_static_probe_ops::get_probes tries reading an SHT_SUNW_dof section, it fails to read the corresponding magic number and bails with this complaint: ... During symbol reading: \ skipping section '.sframe' which does not contain valid DOF data.^M ... But the section actually being read is not an SHT_SUNW_dof section, but an SHT_GNU_SFRAME section: ... [Nr] Name Type Address Off Size ES Flg Lk Inf Al [17] .sframe GNU_SFRAME 00000000000008f0 0008f0 000035 00 A 0 0 8 ... Fix this by checking for the section name .sframe in dtrace_static_probe_ops::get_probes. Tested on aarch64-linux. Approved-By: Simon Marchi Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33813 2026-01-21 Matthieu Longo readelf: constify read cursor for all object attribute parsing and display helpers aarch64: fix build issue raised by -Werror=maybe-uninitialized 2026-01-21 Jan Beulich dwarf: constify read_leb128()'s first parameter It's not clear why the 2nd one is, but the 1st one isn't. 2026-01-21 Michal Sobon opcodes: Fix BMASKI disassembly for immediate 32 on M*Core The BMASKI instruction has three encoding variants (OMa, OMb, OMc). The OMa encoding (0x2C00, mask 0xFFF0) specifically represents BMASKI with immediate 32, encoded as IMM5=0. Per Motorola M*Core specification: "An IMM5 value of 0 is interpreted as a value of 32." Previously, all three variants extracted the immediate the same way, causing OMa to incorrectly display 0 instead of 32. Before: 0x2c04 -> bmaski r4, 0 After: 0x2c04 -> bmaski r4, 32 opcodes/ * mcore-dis.c (print_insn_mcore): Handle OMa encoding to display immediate 32 instead of 0 for BMASKI. gas/testsuite/ * gas/mcore/allinsn.s: Add test for bmaski with immediate 32. Replace two clrc padding instructions with one for 4-byte alignment. Fix missing newline at end of file. * gas/mcore/allinsn.d: Update expected output. 2026-01-21 Evgeny Karpov Martin Vejbora aarch64: Add bigobj support to AArch64 COFF During Boost library testing on aarch64-w64-mingw32, it appeared that 2^16 sections are not enough. It can be handled by using the bigobj format to extend the total amount of sections to 2^32. This patch adds bigobj support to AArch64 COFF in a similar way to how it is done for x86_64. 2026-01-21 Jan Beulich ld: testcase for .note.GNU-stack wanting to be SHT_NOTE If --noexecstack is removed and instead of empty.s a source file is used which explicitly creates a @progbits .note.GNU-stack, the test fails (for the absence of a NOTE segment). 2026-01-21 H.J. Lu amend "ELF: give .note.GNU-stack proper section type" PR ld/33780 Correct the section's special_sections[] entry as well, and further constrain ld's setting of the section type. 2026-01-21 Jan Beulich readelf: don't (silently) fail on empty SHT_NOTE sections Them containing no entries is not an error. Such sections simply have nothing to dump. (Exiting with non-zero status but no error message isn't quite appropriate anyway.) 2026-01-21 Matthieu Longo aarch64: silence GCS warnings on shared libraries for -z gcs=implicit Dynamic library incompatibilities should not be reported when no GCS option is provided (defaults to '-z gcs=implicit') and no explicit diagnostic is provided via '-z gcs-report-dynamic'. Binary Linux distributions do not rebuild all packages from scratch when rolling out a new feature or creating a new release; only modified packages get rebuilt. In the context of GCS deployment, this meant that some packages were rebuilt with GCS enabled while their dependencies were not yet GCS-compatible, resulting in warnings. These warnings caused build failures for packages that treat linker warnings as errors. Those errors slowed down the GCS deployment, and Linux distribution maintainers requested that no GCS option provided should be equivalent to '-z gcs=implicit -z gcs-report-dynamic=none'. In contrast, '-z gcs=always' should continue to report such issues by default. Warnings can still be disabled or promoted to errors by explicitly setting '-z gcs-report-dynamic' to respectively 'none' or 'error'. This patch preserves the existing behaviour for '-z gcs=never', changes the default behaviour of '-z gcs=implicit' or no GCS option, and removed the inheritance mechanism between '-z gcs-report' and '-z gcs-report-dynamics'. The expected behaviour with the different possible combinations is as follows: * -z gcs=never: No diagnostic messages are emitted. * -z gcs=implicit: No diagnostic messages are emitted for input static objects. However, if all the input static objects are marked for GCS, the output object will also be marked for GCS. In this case the output is marked with GCS, '-z gcs-report-dynamic' defaults to 'none' and no diagnostics are emitted. Diagnostics can be enabled by explicitly providing the option. * -z gcs=always: Warning diagnostics for both static and dynamic input objects are enabled by default. The two options are independent of one another, and the diagnostic level can be adjusted for each by explicitly providing the desired level to '-z gcs-report-dynamic' and '-z gcs-report'. The patch also updates the existing tests, removes redundant test cases, and adds new tests covering cases with no report option provided, or report options explicitly set. 2026-01-21 Alan Modra s390 gas cfi-regnames test Fix failure on 32-bit s390-linux where addresses are shown with eight fewer leading zeros, and the CIE is smaller. 2026-01-21 Claudiu Zissulescu sframe: Use UNRESOLVED instead of FAIL Fix for PR ld/33784. The SFrame test for PR ld/33401 is a two-step link test where the second link depends on the output of the first. In the first step, the linker process generates R_*_NONE relocs for .sframe section, while the second link process should pass without any issue. This patch reworks the PR ld/33401 test by removing the call to run_cc_link_tests, and use individual command invocation for compilation, assembling and linking. It introduces the UNRESOLVED status if the first step contains a linking or assembling error. The UNTESTED status is emitted if the first stage doesn't produce R_*_NONE relocs in .sframe section to test the original issue. ld/ PR ld/33784 * testsuite/ld-sframe/sframe.exp (check_pr33401): Rework the procedure for UNRESOLVED and UNTESTED cases. (check_dump): New procedure. * testsuite/ld-sframe/pr33401.rd: Add extra line at the end of the file. 2026-01-21 Claudiu Zissulescu sframe: Add -nostdlib when testing PR 32789 As a result of the mail exchange in https://sourceware.org/pipermail/binutils/2026-January/147439.html, the run_cc_link_test procedure may want to link standard libs too. However, this is not required for running PR 32789 tests. Add -nostdlib option. ld/ * testsuite/ld-sframe/sframe.exp: Add nostdlib when testing PR 32789. 2026-01-21 Alan Modra libsframe misaligned uint32_t I saw asan complaints about misaligned loads and stores when taking a quick look at pr33810 before Jens' patch was applied. They have disappeared now, but it looks to me like a FRE can start on any address boundary and there is no padding or suchlike to align the FRE fields. * sframe.c (flip_fre_stack_offsets): Let the compiler know that integers may be misaligned. 2026-01-21 Alan Modra tidy hppa64 XPASSes Remove a bunch of xfails that now result in XPASS. 2026-01-21 GDB Administrator Automatic date update in version.in 2026-01-20 Alan Modra vms-alpha store immediate repeated Speed up parsing of fuzzed object with ridiculous repeat counts, particularly when the object will later fail alpha_vms_object_p for some reason. * vms-alpha.c (image_write_section): New function, extracted.. (image_write): ..from here. (_bfd_vms_slurp_etir ): Optimise sizing. 2026-01-20 Indu Bhagat gas: sframe: fix inaccurate function-level comment gas/ * gen-sframe.c (sframe_xlate_do_register): Fix code comments. gas: sframe: add code comment for rep block size 2026-01-20 Simon Marchi gdb/dwarf: add unit_lists structure to index writer I think it makes the code more readable than the pair of vector. Also, I'm considering adding a third list (foreigh type units), which will be easier with the structure. Change-Id: I38ec4ddf8f786a2ba10c5b371cfe04c2baaa7da9 Approved-By: Tom Tromey 2026-01-20 Simon Marchi gdb/dwarf: rename some abbrev-related things in debug_names writer I think it would be clearer for some of these things to be called "abbrev", rather than "idx". Change-Id: Ic128a77dc7ce14a6179c049a2de21f3f9636405d Approved-By: Tom Tromey 2026-01-20 Simon Marchi gdb/dwarf: add comments to debug_names::build These help me follow what is going on, when following with the spec on the side. Change-Id: I0da0047eefd233e8f7635118d67622f07c29ce01 Approved-By: Tom Tromey 2026-01-20 Simon Marchi gdb/dwarf: move DWP htab nullptr check to lookup_dwo_unit_in_dwp cutu_reader::lookup_dwo_cutu gets hold of the right htab for the kind of unit to look up (CU or TU), but then just uses the pointer to know if it should call lookup_dwo_unit_in_dwp or not. lookup_dwo_unit_in_dwp then uses the same condition to obtain the correct htab. I think it would make more sense to return early from lookup_dwo_unit_in_dwp instead, if the required htab does not exist. Change-Id: I6f8f96aba2452f8261b3c60667e72fb21b97c89d Approved-By: Tom Tromey 2026-01-20 Simon Marchi gdb/dwarf: merge one CU/TU code path Simplify the code by merging the paths for CUs and TUs. It is also not necessary to check if the maps are empty. Change-Id: I43e2cf4bb1217a72dda8a03957ed733f87bf57b2 Approved-By: Tom Tromey 2026-01-20 Andrew Burgess gdb: fail for 'maint print frame-id LEVEL' of an invalid frame I noticed that 'maint print frame-id LEVEL' will always print a frame-id, just not always for LEVEL, for example: (gdb) bt #0 woof () at stack.c:4 #1 0x000000000040111f in bar () at stack.c:10 #2 0x000000000040112f in foo () at stack.c:16 #3 0x000000000040113f in main () at stack.c:22 (gdb) maintenance print frame-id 4 frame-id for frame #3: {stack=0x7fffffffa640,code=0x0000000000401131,!special} (gdb) Notice that the request was for the frame-id of #4, which doesn't exist, but what I got was the frame-id for #3. Fix this by adding a check to maintenance_print_frame_id (frame.c), so the new behaviour is: (gdb) maintenance print frame-id 4 No frame at level 4. (gdb) This matches the behaviour of the 'frame' command: (gdb) frame 4 No frame at level 4. (gdb) I've added a new test to cover this case. Approved-By: Simon Marchi 2026-01-20 John David Anglin hppa64: Improve relocation handling for local symbols and add gc_section support With this patch, gcc-16 can be built and there are significant improvements in test results. I spent a lot of time trying to fix the EH exception support. While there are still issues with handling relocations in linkonce sessions, exception handling mostly works if pc-relative and text relative encoding is used in .eh_frame. The main problems are the HP-UX dynamic linker relocates the text and data segements indpendently, and it does not support unaligned dynamic relocations. Due to a configure bug in libstdc++-v3, the lack of gc_section support caused many test failures, so I added the gc_section support form elf32-hppa.c. I also move the HP_LOAD_MAP scratchpad to the end of the .bss section and fixed a number of issues with the linker scripts. 2026-01-20 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_check_relocs): Drop NEED_PLT from R_PARISC_LTOFF_FPTR relocations. Revise R_PARISC_FPTR64 relocation to use maybe_dynamic. Add support for R_PARISC_GNU_VTINHERIT and R_PARISC_GNU_VTENTRY relocations. Add code to handle dynamic relocations of local symbols. (elf64_hppa_gc_mark_hook): New. (ensure_undef_dynamic): New. (allocate_dynrel_entries): Revise checks to determine when to discard relocs. (elf64_hppa_late_size_sections): Revise allocation of local PLT, DLT and OPD entries. (elf64_hppa_finalize_opd): Remove assert. (elf64_hppa_finalize_dlt): Change type of dynindx to long. (elf64_hppa_finalize_dynreloc): Likewise. Add check for discarded sections. Correct handling of R_PARISC_FPTR64 relocation. Remove assert. Add new assert to check that we don't allocate more relocs in .rela.data than it can hold. (elf64_hppa_finish_dynamic_sections): Move allocation for DT_HP_LOAD_MAP to end of .bss section. Only allocate on HP-UX. (elf_hppa_dlt_dynrel_reloc): Add dynrel_type argument. Change type of dynindx. Drop use of value. Remove assert. (elf_hppa_opd_dynrel_relocs): Rename to elf_hppa_opd_eplt_reloc. Drop code to to emit R_PARISC_FPTR64 relocation. (elf_hppa_opd_fptr_reloc): New. (elf_hppa_final_link_relocate): Add SYM arguement. Move check for SEC_DEBUGGING. Rework DLT, LTOFF, FPTR and DIR64 relocation handling. (elf64_hppa_relocate_section): Add asserts to ensure symbol isn't undefined and input_section hasn't been discarded. (elf_backend_gc_mark_hook): Define. (elf_backend_can_gc_sections): Define. ld/ChangeLog: * emulparams/elf64hppa.sh (DATA_ADDR): Revise value to match HP-UX 11 value. (SHLIB_DATA_ADDR): Likewise. (NOP): Define. (OTHER_READONLY_SECTIONS): Add .data.rel, .HP.init, .preinit, .init and .fini sections to list. (__SYSTEM_ID_D, __TLS_SIZE_D, __FPU_REVISION, __FPU_MODEL, __CPU_REVISION, __CPU_KEYBITS_1, __LOAD_INFO, __ARGC, __ARGV, __ENVP, __libdl_jmp_tbl, __systab): Provide. (DATA_START_SYMBOLS, OTHER_SYMBOLS, INIT_START): Delete. (PREINIT_START, PREINIT_END, INIT_START): Define. emulparams/hppa64linux.sh (NOP): Define. (DATA_START_SYMBOLS): Delete. scripttempl/elf64hppa.sc: Delete .init and .fini sections from script. Allocate 16 bytes at end of .bss for HP_LOAD_MAP. 2026-01-20 Tom Tromey Move puts_tabular to obj-lang.c Only objc-lang.c uses puts_tabular. This patch moves the function there and makes it 'static'. It is also updated not to depend on the global (but private to utils.c) chars_printed, and not to call begin_line. Reviewed-By: Keith Seitz 2026-01-20 Tom Tromey Use n_spaces in puts_tabular This changes puts_tabular to use n_spaces rather than alloca. Reviewed-By: Keith Seitz 2026-01-20 Tom Tromey Remove right justification from puts_tabular No caller of puts_tabular uses the right-justified feature, so remove it. Reviewed-By: Keith Seitz 2026-01-20 Tom Tromey Constify puts_tabular This changes puts_tabular to accept a 'const char *'. Reviewed-By: Keith Seitz 2026-01-20 Tom Tromey Change is_import_fixup_symbol to return bool This changes the is_import_fixup_symbol in coffread.c to return bool rather than int. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove all globals from coffread.c This patch changes coffread.c to add a reader object type. All globals are moved into this type, and the majority of functions in coffread.c are changed to be methods. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove coff_symfile_init coff_symfile_init is an empty function, and rather than give it a name, just use a lambda in coff_sym_fns. I've occasionally considered adding a do_nothing template function for all our empty function needs, but still haven't bothered. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Use coffread_objfile throughout coffread.c coffread.c:coff_symtab_read sets a global objfile while working. It seemed nicer to me to hoist this so that it is set by the main entry point, and then used throughout the file. Normally I wouldn't encourage the use of globals, but shortly we'll be replacing these with an object. Note that while coff_symtab_read cleared coffread_objfile when it was finished, I haven't preserved this in the new patch. First, this should have been done with a scoped_restore. Second, this is the only global to get this treatment. Third, it's not necessary at all. And, finally, this will be moot anyway when the globals are removed. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Use symfile_bfd in more places Since coffread.c is setting symfile_bfd, it might as well use it everywhere. This changes all other BFD references in coffread.c to use the global. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove redundant nlist_bfd_global coffread.c has two BFD globals: nlist_bfd_global and symfile_bfd. There's no need for both, and since symfile_bfd is set early (in coff_symfile_read, the entry point), this removes nlist_bfd_global and replaces all the uses. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Change coffread.c:pe_file to bool This changes coffread.c:pe_file to use bool. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Fix indentation in coffread.c A couple of spots in coffread.c were indented incorrectly. This also fixes the placement of a comment in coff_symbol. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Clean up a comment in coffread.c This comment in coffread.c refers to some things that are no longer used. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Constify coffread.c:getsymname I noticed that the symbol name in coffread.c can be const. Approved-By: Simon Marchi 2026-01-20 Maciej W. Rozycki BFD: Remove extraneous BFD struct member setup from `bfd_make_readable' Complementing commit 3097045a18a8 ("ld plugin bfd_make_readable leak") remove assignments to BFD struct members from `bfd_make_readable' that now duplicate ones unconditionally made by `_bfd_free_cached_info' called earlier on. BFD: Remove null pointer checks for `bfd_hash_table_free' calls Given that as from commit 90e5645309be ("libiberty: Make `objalloc_free' `free'-like WRT null pointer") `bfd_hash_table_free' now returns with no action taken when called for a hash table with no allocation present, remove null pointer checks guarding invocations. 2026-01-20 Jens Remus s390: gas: Remove support for register names "ap" and "cc" in CFI directives The assembler erroneously converted the special register names "ap" and "cc" to the DWARF register numbers 32 and 33 respectively, which are actually assigned to the control registers c0 and c1 according to both the s390 32-bit (s390) ELF ABI [1] and s390 64-bit (s390x) ELF ABI [2]. Register numbers 32 and 33 are used internally by GCC as "argument pointer" (ap) and "condition code" (cc). Very early GCC versions leaked this out into DWARF. However, those GCC-internal special register names should never be actually used in CFI, especially given their resulting DWARF register numbers have a different meaning in DWARF (CFI). [1]: s390 ELF ABI, section "DWARF definition", https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html [2]: s390x ELF ABI, subsection "DWARF Register Numbers", https://github.com/IBM/s390x-abi/releases gas/ * config/tc-s390.c (tc_s390_regname_to_dw2regnum): Remove support for register names "ap" and "cc" in CFI directives. Suggested-by: Ulrich Weigand 2026-01-20 Jens Remus s390: gas: Support access register names in CFI directives Convert access register (AR) names a0-a15 to DWARF register numbers when used in CFI directives. Convert an access register number (0..15) to its corresponding DWARF register number (48..63) as specified in the s390 64-bit (s390x) ELF ABI [1] by adding 48. [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases gas/ * config/tc-s390.c (tc_s390_regname_to_dw2regnum): Convert access register names (a0..a15) to DWARF register numbers. gas/testsuite/ * gas/s390/cfi-regnames.d: Add test for AR names in in CFI directives. * gas/s390/cfi-regnames.s: Likewise. * gas/s390/cfi-regnames-err.l: Likewise. * gas/s390/cfi-regnames-err.s: Likewise. 2026-01-20 Jens Remus s390: gas: Support vector register names in CFI directives Convert vector register names v0-v31 to DWARF register numbers when used in CFI directives. Convert a vector register number (0..31) to its respective DWARF register number (16..31, 68..83) as specified in the s390 64-bit (s390x) ELF ABI [1] as follows: Right rotate the least significant three bits and add 16 for register numbers 0..15 or 68 for register numbers 16..31. Add a test case for the use of vector register (VR) names in CFI directives. [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases gas/ * config/tc-s390.c (tc_s390_regname_to_dw2regnum): Convert vector register names (v0..v31) to DWARF register numbers. gas/testsuite/ * gas/s390/cfi-regnames.d: Add test for VR names in in CFI directives. * gas/s390/cfi-regnames.s: Likewise. * gas/s390/cfi-regnames-err.l: Likewise. * gas/s390/cfi-regnames-err.s: Likewise. 2026-01-20 Jens Remus s390: gas: Fix conversion of FP register names to DWARF register numbers The assembler supports register names in CFI directives. For floating- point (FP) registers f0..f15 the register numbers 0..15 are erroneously converted to DWARF register numbers 16..31 by adding 16. This is wrong as the s390 64-bit (s390x) ELF ABI [1] specifies the DWARF register numbers for the FP registers as follows: DWARF BINARY BINARY DWARF REGISTER REGISTER REGISTER REGISTER NUMBER NAME NUMBER NUMBER 16 f0 0b0000 -> 0b10000 17 f2 0b0010 -> 0b10001 18 f4 0b0100 -> 0b10010 19 f6 0b0110 -> 0b10011 20 f1 0b0001 -> 0b10100 21 f3 0b0011 -> 0b10101 22 f5 0b0101 -> 0b10110 23 f7 0b0111 -> 0b10111 24 f8 0b1000 -> 0b11000 25 f10 0b1010 -> 0b11001 26 f12 0b1100 -> 0b11010 27 f14 0b1110 -> 0b11011 28 f9 0b1001 -> 0b11100 29 f11 0b1011 -> 0b11101 30 f13 0b1101 -> 0b11110 31 f15 0b1111 -> 0b11111 Convert a FP register number (0..15) to its respective DWARF register number (16..31) as follows: Right rotate the least significant three bits and add 16. Add a test case for the use of general register (GR; r0..r15) and floating-point register (FPR; f0..f15) names in CFI directives. [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases gas/ * config/tc-s390.c (tc_s390_regname_to_dw2regnum): Fix conversion of FP register names to DWARF register numbers. gas/testsuite/ * gas/s390/s390.exp (cfi-regnames, cfi-regnames-err): Run new tests. * gas/s390/cfi-regnames.d: New test for GR and FPR names in CFI directives. * gas/s390/cfi-regnames.s: Likewise. * gas/s390/cfi-regnames-err.l: Likewise. * gas/s390/cfi-regnames-err.s: Likewise. 2026-01-20 Jens Remus libsframe: use proper FRE type when flipping SFrame V3 FREs flip_sframe_fdes_with_fres_v3 was erroneously using a fixed FRE type of 0 (= SFRAME_FRE_TYPE_ADDR1) when endianness byte-flipping the FREs, regardless of the actual FRE type (i.e. ADDR1, ADDR2, or ADDR4). This only affected cross builds, where the .sframe section data may needed to be endianness byte-flipped (e.g. binutils cross-built for s390 64-bit (s390x) on x86-64). As a consequence objdump/readelf with option --sframe could fail to dump e.g. s390 64-bit (s390x) .sframe section data on x86-64 with the following error message: Error: SFrame decode failure: Buffer does not contain SFrame data. The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable object and check R_*_NONE)" cross-build for s390 64-bit (s390x) on x86-64 could fail with ld error message: error in tmpdir/StatePlaying.o(.sframe); no .sframe will be created The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable object and check R_*_NONE)" cros-build for s390 64-bit (s390x) on x86-64 could fail with BDF assertion: BFD (GNU Binutils) ... assertion fail .../bfd/elf-sframe.c:153 Add a common cfi-sframe assembler test, that forces a FDE type of SFRAME_FRE_TYPE_ADDR2. When the test is run cross-build it may exercise the SFrame FDE and FDE endianness byte flipping. libsframe/ PR ld/33810 * sframe.c (sframe_decode_fde_attr_v3): Decode and return FRE type from FDE attributes. (flip_sframe_fdes_with_fres_v3): Use proper FRE type from FDE attributes when flipping FREs. gas/testsuite/ PR ld/33810 * gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-common-pr33810): Run new test. * gas/cfi-sframe/cfi-sframe-common-pr33810.d: New test. * gas/cfi-sframe/cfi-sframe-common-pr33810.s: Likewise. Bug: https://sourceware.org/pr33810 Fixes: 8ab6e4c72ab6 ("[SFrame-V3] include: gas: libsframe: split FDE into idx and attr") Reported-by: Alan Modra 2026-01-20 Tom de Vries [gdb] Add regression test for PR symtab/33777 PR symtab/33777 reports a problem where toplevel DIEs of partial units are read many times. The problem manifest as a timeout when building gdb with -O0 and Asan, and running test-case gdb.base/tls-dlobj.exp with glibc debuginfo installed. Reproduce the problem in a simpler and quicker way, without relying on glibc debuginfo: - build an executable with 100 partial units - run info line "$file:$line" a 100 times - add a line to "maint print statistics" that tells us how many time a toplevel DIE is read. Without the fix we have: ... Number of read units: 1 Number of unread units: 108 Number of read top-level DIEs: 10118 ... and with the fix we have: ... Number of read units: 1 Number of unread units: 108 Number of read top-level DIEs: 218 ... Detect the problem by asserting: ... gdb_assert { $top_level_die <= 3 * ( $read_cu + $unread_cu ) } ... The factor 3 is used because for some target boards $top_level_die is slightly more than 2 * ( $read_cu + $unread_cu ). Tested on x86_64-linux. 2026-01-20 Tom Tromey Remove "value chain" from symbol The "value chain" code in struct symbol is no longer used and so it can be removed. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Inline add_symbol_to_list add_symbol_to_list is just a simple wrapper for push_back, so we might as well inline it. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove "alias" hack from add_symbol_to_list add_symbol_to_list has this code: /* If this is an alias for another symbol, don't add it. */ if (symbol->linkage_name () && symbol->linkage_name ()[0] == '#') return; This appears to be an old stabs hack. In the stabs removal patch (commit eaea19f98d8) we see: - /* '#' is a GNU C extension to allow one symbol to refer to another - related symbol. - - Generally this is used so that an alias can refer to its main - symbol. */ This is a classic example of an old style problem that gdb had: sometimes hacks were added to the gdb core to work around problems in symbol readers -- IMO this kind of thing should have always been handled by the stabs reader itself, not add_symbol_to_list. Anyway, this is obsolete now and this patch removes it. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove buildsym_compunit::free_pending buildsym_compunit::free_pending is only called from a single spot in buildsym.c, so let's inline it and remove the method. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove buildsym_compunit::release_macros buildsym_compunit::release_macros is only called from a single spot in buildsym.c, so let's inline it and remove the method. Approved-By: Simon Marchi 2026-01-20 Tom Tromey Remove unused methods from buildsym_compunit A few methods of buildsym_compunit are now unused and can be removed. Approved-By: Simon Marchi 2026-01-20 GDB Administrator Automatic date update in version.in 2026-01-19 Tom de Vries [gdb/symtab] Handle zero opcode_base in line number program header I build gdb with TSAN, and with test-case gdb.dwarf2/malformed-line-header.exp ran into a heap-use-after-free: ... (gdb) info line 1 ================== WARNING: ThreadSanitizer: heap-use-after-free (pid=897504) Write of size 1 at 0x72040000d000 by main thread: #0 dwarf_decode_line_header() gdb/dwarf2/line-header.c:356 (gdb+0xa0618c) ... Previous write of size 8 at 0x72040000d000 by main thread: #0 operator delete[](void*) (libtsan.so.2+0xa6128) #1 std::enable_if::value, void>::type std::default_delete::operator()(unsigned char*) const /usr/include/c++/15/bits/unique_ptr.h:134 (gdb+0xa08479) #2 std::unique_ptr >::~unique_ptr() /usr/include/c++/15/bits/unique_ptr.h:685 (gdb+0xa07324) #3 line_header::~line_header() gdb/dwarf2/line-header.h:86 (gdb+0xa0914a) #4 std::default_delete::operator()(line_header*) const /usr/include/c++/15/bits/unique_ptr.h:93 (gdb+0xa091a4) #5 std::unique_ptr >::~unique_ptr() /usr/include/c++/15/bits/unique_ptr.h:399 (gdb+0xa07f18) #6 dw2_get_file_names_reader gdb/dwarf2/read.c:1839 (gdb+0xa648ee) ... Location is heap block of size 0 at 0x72040000d000 allocated by main thread: #0 operator new[](unsigned long) (libtsan.so.2+0xa6b01) #1 dwarf_decode_line_header() gdb/dwarf2/line-header.c:354 (gdb+0xa06159) ... This is caused by allocating a zero-sized array (lh->opcode_base == 0), and writing to it: ... lh->standard_opcode_lengths.reset (new unsigned char[lh->opcode_base]); lh->standard_opcode_lengths[0] = 1; /* This should never be used anyway. */ ... Fix this by skipping this code if lh->opcode_base == 0. Tested on x86_64-linux. Approved-By: Simon Marchi 2026-01-19 Simon Marchi gdb/dwarf: remove unused includes from read-gdb-index.c There are reported as unused by clangd. Change-Id: I0e08e5d0eb5eab0fe67099c8fb1f47c827bdea3d 2026-01-19 Nick Clifton Release the data on the matching_objstack once it is no longer needed. 2026-01-19 Matthieu Longo bfd: move elf_new_obj_attr to the BFD public API 2026-01-19 Jan Beulich x86: restrict recently added ifunc gas tests These will fail on Solaris and other non-GNU targets. PPC: permit %dm0 as insn operand When the DM registers were added, sorting of the table was broken. With the present arrangement, this leads to (only) %dm0 not being found by the binary search that both use sites of the table entertain. 2026-01-19 Jan Vrany gdb/testsuite: fix FAILs in fileio.exp I'm experiencing intermittent FAILs in fileio.exp when running on (my) CI: FAIL: gdb.base/fileio.exp: Open a file FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES FAIL: gdb.base/fileio.exp: Writing to a file ... The problem turned out to be the way the OUTDIR gets defined in fileio.c. The path is passed down "naked" and turned into string by STRINGIFY macro. However, if the path happens to contain name of unrelated pre-existing C macro, this macro gets expanded during the "stringification", resulting in (likely) different path than used in fileio.exp and therefore causing failures. For example, if the GDB is compiled and tested in directory /var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu then fileio.c is compiled with -DOUTDIR_=/var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu/gdb/testsuite/outputs/gdb.base/fileio But because there's also C macro named "linux" defined to 1, the resulting OUTDIR is actually: /var/lib/jenkins/workspace/binutils-gdb/build/x86_64-1-gnu/gdb/testsuite/outputs/gdb.base/fileio This commit fixes this by defining the OUTDIR as string literal in first place (similarly to how it was done prior commit cc91060) and updating quote_for_host to handle strings that themselves contains quote ("). Tested on x86_64-linux by running all tests using quote_for_host with both target board unix and host/target board local-remote-host-native. Approved-By: Tom Tromey 2026-01-19 Alan Modra asan: vms-alpha buffer overflow * vms-alpha.c (_bfd_vms_slurp_etir): Sanity check ETIR__C_STO_IMM size. Use unsigned "size" to better catch ETIR__C_STO_IMMR errors. Make cmd_length unsigned too, and avoid pointer overflow in existing sanity check. 2026-01-19 Alan Modra asan: coff-alpha use of uninitialised value I think this is a false positive as the "use" is reported at a _bfd_link_reloc_status_error call, and the value passed is not used except when bfd_reloc_dangerous. Avoid the warning anyway. * coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Avoid false positive warning. 2026-01-19 David Guillen Fandos MIPS/opcodes: Fix floor/round exclusions for R5900 MIPS R5900 does not feature ceil/floor/round instructions, but only ceil is correctly excluded at the moment. Correct the other two. 2026-01-19 GDB Administrator Automatic date update in version.in 2026-01-18 Tom Tromey Remove extraneous semicolon from inferior.h I noticed an extra ";" in inferior.h, this removes it. 2026-01-18 Tom Tromey Fix multiple-successive-infcall.exp with gdbserver PR gdb/33791 points out that my recent change to emit the thread ID in the thread notification message broke multiple-successive-infcall.exp when run with gdbserver. This patch fixes the oversight. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33791 Approved-By: Simon Marchi 2026-01-18 Eli Zaretskii gdb/ PR gdb/33761 * gdb/ui-style.c (colorsupport) [__MINGW32__]: MS-Windows always supports at least 8 colors, even if the "Co" capability is not in the terminfo DB. This fixes "set style FOO foreground COLOR" commands in the Windows native build of GDB. 2026-01-18 Alan Modra PR 33801 strip doesn't remove .gnu.lto_.opts OK, so people want to be able to partly destroy gcc slim LTO object files. I don't see why not, despite HJ's policy-setting slim lto strip -R tests. I also don't see why it matters that objcopy/strip won't similarly break LLVM objects (pr33271). So out goes the slim lto strip -R tests, and the strip-debug test expecting slim lto files won't be modified in any way. strip-debug now removes a FILE symbol, which isn't unreasonable. PR 33801 PR 33271 PR 33246 binutils/ * objcopy.c (copy_archive, copy_file): Do not special case gcc LTO IR files. ld/ * testsuite/ld-plugin/lto-binutils.exp: Remove slim lto strip -R tests. (run_pr33246_test): Don't compare slim object files after strip-debug. * testsuite/ld-plugin/strip-1a-s-all.nd: Delete. 2026-01-18 GDB Administrator Automatic date update in version.in 2026-01-17 H.J. Lu gas: Update PR gas/33744 tests Since .set directive doesn't work on alpha and hpux has a non-standard common directive, skip the relevant tests on alpha and hpux. Also allow 2, 4, 8 byte section alignment for 1-byte section since some targets have a minimum section alignment. PR gas/33744 * testsuite/gas/elf/sh-link-abs-1.d: Skip alpha and allow 1, 2, 4, 8 byte section alignment. * testsuite/gas/elf/sh-link-abs-2.d: Likewise. * testsuite/gas/elf/sh-link-abs-3-32.d: Likewise. * testsuite/gas/elf/sh-link-abs-3-64.d: Likewise. * testsuite/gas/elf/sh-link-abs-4-32.d: Likewise * testsuite/gas/elf/sh-link-abs-4-64.d: Likewise * testsuite/gas/elf/sh-link-common-1.d: Skip hpux and allow 1, 2, 4, 8 byte section alignment. * testsuite/gas/elf/sh-link-common-2.d: Likewise * testsuite/gas/elf/sh-link-common-3-32.d: Likewise * testsuite/gas/elf/sh-link-common-3-64.d: Likewise * testsuite/gas/elf/sh-link-common-4-32.d: Likewise * testsuite/gas/elf/sh-link-common-4-64.d: Likewise 2026-01-17 Simon Marchi gdb/i386: remove i386_dbx_reg_to_regnum Following the removal of gdbarch_sdb_reg_to_regnum, i386_dbx_reg_to_regnum is only used by i386_svr4_dwarf_reg_to_regnum to handle SSE and MMX registers. Remove it and inline the relevant bits in i386_svr4_dwarf_reg_to_regnum. Change-Id: Id74fad6ef6798c4cd061905f1c01eadd90e0a118 Approved-By: Andrew Burgess 2026-01-17 Simon Marchi gdb: remove gdbarch_sdb_reg_to_regnum Following the removal of the COFF debug info support, gdbarch_sdb_reg_to_regnum is no longer used, remove it. Change-Id: I2cb43465f1fdf74863edfa4dd00fd5f28a5a26bd Approved-By: Andrew Burgess 2026-01-17 Simon Marchi gdb: remove stale comments about COFF / stabs These comments appear to be stale and no longer relevant. Change-Id: I3470969b0c0f38d809fe074ffab93ac91202de18 Approved-By: Andrew Burgess 2026-01-17 Tom de Vries [gdb/tdep] Fix gdb.base/siginfo.exp on s390x-linux On s390x-linux (SLES 15 SP5), I'm running into: ... FAIL: gdb.base/siginfo.exp: backtrace for nexti (pattern 2) FAIL: gdb.base/siginfo.exp: step out of handler ... The first FAIL is caused by a failure to unwind: ... (gdb) bt^M #0 handler (sig=26, info=0x3ffffffe428, context=0x3ffffffe4a8) at \ gdb.base/siginfo.c:31^M Backtrace stopped: Cannot access memory at address 0x1a00000088^M (gdb) ... In contrast, on x86_64-linux I get instead: ... (gdb) bt^M #0 handler (sig=26, info=0x7fffffffc170, context=0x7fffffffc040) at \ gdb.base/siginfo.c:31^M #1 ^M #2 0x0000000000401201 in main () at gdb.base/siginfo.c:67^M (gdb) ... The memory access error is triggered here in s390_sigtramp_frame_unwind_cache: ... /* Restore the previous frame's SP. */ prev_sp = read_memory_unsigned_integer ( info->saved_regs[S390_SP_REGNUM].addr (), word_size, byte_order); ... while trying to read an "Old-style RT frame" (for syscall sigreturn). The problem is that we actually have a "New-style RT frame" (for syscall rt_sigreturn). [ See linux kernel source file arch/s390/kernel/signal.c for a detailed explanation of the two. ] The choice between the two is made earlier in that same function: ... /* New-style RT frame: retcode + alignment (8 bytes) siginfo (128 bytes) ucontext (contains sigregs at offset 5 words). */ if (next_ra == next_cfa) { ... } /* Old-style RT frame and all non-RT frames: old signal mask (8 bytes) pointer to sigregs. */ else ... I'm not sure why the check gives the wrong result, but I noticed that s390_sigtramp_frame_sniffer is able to distinguish between the two, so fix this by: - factoring out new function s390_sigtramp_p out of s390_sigtramp_frame_sniffer, and - using s390_sigtramp_p in s390_sigtramp_frame_unwind_cache to distinguish between the "Old-style RT frame" and "New-style RT frame". This fixes the backtrace. The second failure is: ... (gdb) step^M 32 } /* handler */^M 1: x/i $pc^M => 0x1000772 : nopr^M (gdb) step^M 0x000003fffdffe490 in __kernel_rt_sigreturn ()^M 1: x/i $pc^M => 0x3fffdffe490 <__kernel_rt_sigreturn>: svc 173^M (gdb) FAIL: gdb.base/siginfo.exp: step out of handler ... There is some code in process_event_stop_test that is supposed to trigger: ... if (ecs->event_thread->control.step_range_end != 1 && (ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE || ecs->event_thread->control.step_over_calls == STEP_OVER_ALL) && get_frame_type (frame) == SIGTRAMP_FRAME) { infrun_debug_printf ("stepped into signal trampoline"); /* The inferior, while doing a "step" or "next", has ended up in a signal trampoline (either by a signal being delivered or by the signal handler returning). Just single-step until the inferior leaves the trampoline (either by calling the handler or returning). */ keep_going (ecs); return; } ... but it doesn't because frame is a NORMAL_FRAME instead of a SIGTRAMP_FRAME. This is caused by the "dwarf2" unwinder triggering, which has higher priority than the "s390 linux sigtramp" unwinder: ... (gdb) maint info frame-unwinders Name Type Class Enabled dummy DUMMY_FRAME GDB Y dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y inline INLINE_FRAME GDB Y jit NORMAL_FRAME EXTENSION Y python NORMAL_FRAME EXTENSION Y dwarf2 NORMAL_FRAME DEBUGINFO Y dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y s390 linux sigtramp SIGTRAMP_FRAME ARCH Y s390 stub NORMAL_FRAME ARCH Y s390 prologue NORMAL_FRAME ARCH Y ... I found some code in dwarf2_frame_sniffer: ... /* On some targets, signal trampolines may have unwind information. We need to recognize them so that we set the frame type correctly. */ if (fde->cie->signal_frame || dwarf2_frame_signal_frame_p (get_frame_arch (this_frame), this_frame)) return self->type () == SIGTRAMP_FRAME; ... and an example implementation i386_linux_dwarf_signal_frame_p, and after copying this approach, indeed the stepping failure was fixed, but the backtrace broken again. Instead, fix this by giving the "s390 linux sigtramp" unwinder a higher priority: ... (gdb) maint info frame-unwinders Name Type Class Enabled dummy DUMMY_FRAME GDB Y dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y inline INLINE_FRAME GDB Y jit NORMAL_FRAME EXTENSION Y python NORMAL_FRAME EXTENSION Y s390 linux sigtramp SIGTRAMP_FRAME ARCH Y dwarf2 NORMAL_FRAME DEBUGINFO Y dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y s390 stub NORMAL_FRAME ARCH Y s390 prologue NORMAL_FRAME ARCH Y ... Also fixes test-case gdb.base/sigaltstack.exp and gdb.base/sigbpt.exp. Tested on s390x-linux. Reviewed-By: Keith Seitz PR tdep/33708 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33708 2026-01-17 Alan Modra fix new arm and aarch64 gas test failures aarch64-pe +FAIL: gas/aarch64/fix-adj arm-pe +FAIL: MVE vmlas instructions arm-wince-pe +FAIL: MVE vmlas instructions These new tests use ELF directives. * testsuite/gas/aarch64/fix-adj.d: Only run on ELF targets. * testsuite/gas/arm/mve-vmlas.d: Likewise. 2026-01-17 Alan Modra ld: put wild matching_sections on an obstack so that the memory can be reclaimed easily when reset_resolved_wilds throws it all away. * ldlang.c (matching_obstack): New static var. (add_matching_section): Rewrite to use matching_obstack. (lang_init): Init matching_obstack. (reset_resolved_wilds): Free matching_obstack. 2026-01-17 Alan Modra Make some ldlang functions inline These are small, and making them inline lets me call lang_statement_append without adding a forward declaration in the next patch. * ldlang.c (lang_for_each_statement, lang_list_init), (lang_statement_append): Move to.. * ldlang.h: ..here making them inline functions. (bfd_input_just_syms): Group with other inlines. 2026-01-17 GDB Administrator Automatic date update in version.in 2026-01-16 Richard Ball aarch64: Add support for FEAT_MTETC This patch adds two new DC operations: *gbva *zgbva 2026-01-16 Richard Ball aarch64: Add FEAT_SCR2 System registers This patch adds the system register "SCR2_EL3" Defined by FEAT_SCR2. 2026-01-16 Simon Marchi gdb/hppa: replace bfd_map_over_sections with gdb_bfd_sections Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Change-Id: I92ba6b5ef9e9ab3d2ebe364373aeaf459fd6e34c Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/windows: replace bfd_map_over_sections with gdb_bfd_sections Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Change core_process_module_section's signature to take a cpms_data reference instead of a void pointer. Change-Id: Ic4f9a12c9c1479799ec87658fd88490106b61836 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/compile: replace bfd_map_over_sections with gdb_bfd_sections Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Rename copy_sections to copy_section and change its signature to take explicit parameters instead of the callback-style void pointer. Change-Id: I30f1c3c051415722f2220b7fba48103101b640e8 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/mips-sde: replace bfd_map_over_sections with gdb_bfd_sections Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Change-Id: If2e1141f2e9345fe50e2a63ce8f8682e82a60f21 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/mips: replace bfd_map_over_sections with gdb_bfd_sections (2) Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Change-Id: I34182a67ee52da479c1868a5880709c401cbf34e Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/mips: replace bfd_map_over_sections with gdb_bfd_sections (1) Replace bfd_map_over_sections with iteration over gdb_bfd_sections. Change-Id: Ib236b364dc81f43cab8d27271d413eb61d6c703e Approved-By: Tom Tromey 2026-01-16 Tom de Vries [gdb] Handle AT_HWCAP3/AT_HWCAP4 in default_print_auxv_entry On aarch64-linux, I run into: ... (gdb) info auxv^M ... 26 AT_HWCAP2 Extension of AT_HWCAP 0x181^M 29 ??? 0x0^M 31 AT_EXECFN File name of executable 0xffffffffffb9 ... ... 28 AT_RSEQ_ALIGN rseq allocation alignment 32^M 0 AT_NULL End of vector 0x0^M (gdb) WARNING: Unrecognized tag value: 29 ... ??? ... 0x0^M FAIL: gdb.base/auxv.exp: info auxv on live process ... Fix this by handling AT_HWCAP3 in default_print_auxv_entry. Likewise for AT_HWCAP4. Tested on aarch64-linux. Approved-By: Simon Marchi Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32590 2026-01-16 Tom de Vries [include] Add AT_HWCAP3/AT_HWCAP4 in elf/common.h Since glibc 2.39, containing commit 3ab9b88 ("powerpc: Add HWCAP3/HWCAP4 data to TCB for Power Architecture."), glibc's elf/elf.h contains constants AT_HWCAP3/AT_HWCAP4. Add these in elf/common.h. Approved-By: Simon Marchi 2026-01-16 Maximilian Bosch gdb/testsuite: add testcase for .debug_gdb_scripts being compressed This is a test-case to make sure that 8eb1701823e46179e3adcb49abf57126b3c49f28 ("gdb: fix loading compressed scripts from `.debug_gdb_scripts`-section") doesn't regress. The test was mostly implemented by Tom Tromey, with the exception of the check to make sure that the sections are actually compressed and corrected compiler flags (-Wl,--compress-debug-sections=zlib-gabi was missing). This is an individual patch since the actual fix already landed in the repository. Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/buildsym: patch_subfile_names This doesn't seem used anymore. Change-Id: I39e04f1f05fee3c6f7747923d5c1c2feef1fa315 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/buildsym: remove get_last_source_start_addr/set_last_source_start_addr methods Nothing seems to use this anymore. However, the private field is still used internally by buildsym, so keep it. Change-Id: Ie6fbd96110a3c5603359a483855bbecc4008e5b4 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/buildsym: remove m_last_source_file Nothing seems to use this anymore. Change-Id: I6a767f2251ce9e683c231708466899a3e9ff4cb1 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb: remove buildsym-legacy With the removal of the COFF debug info support, nothing uses buildsym-legacy anymore, remove it. Change-Id: I46612509889b6868f5889a4347ad8d0a28d29127 Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/coffread: remove debug info support This patch removes support for reading in the COFF debug info. I am not a specialist of the COFF format, but my understanding is that debug info in the COFF format consisted of extra symbol table entries describing the standard symbol table entries. For instance, when compiling without debug info, a function would get a simple symbol entry, akin to an ELF symbol. We would create a minimal symbol out of that. When compiling with debug info, that symbol table entry would be followed by special additional entries, describing things like parameters and local variables (what would now be in DWARF). We would create some full symbols out of that. This patch removes everything that reads this extra information, on the basis that any target still used today would not use it anymore, having switched to DWARF instead. We still read the standard symbol table entries and create minimal symbols out of that. This can be seen when loading a Windows executable (the only COFF executable kind I know how to produce): $ ./gdb -nx -q --data-directory=data-directory -ex "set debug symtab-create 2" -ex "file a.exe" ... [symtab-create] record_full: recording minsym: mst_file_bss 0x140008018 6 argv [symtab-create] record_full: recording minsym: mst_file_bss 0x140008008 6 managedapp [symtab-create] record_full: recording minsym: mst_text 0x1400013e0 0 WinMainCRTStartup [symtab-create] record_full: recording minsym: mst_text 0x140001400 0 mainCRTStartup [symtab-create] record_full: recording minsym: mst_text 0x140001420 0 atexit [symtab-create] record_full: recording minsym: mst_file_data 0x140005000 3 __EH_FRAME_BEGIN__ [symtab-create] record_full: recording minsym: mst_file_bss 0x140008060 6 obj ... [symtab-create] install: installing 299 minimal symbols of objfile /home/smarchi/src/binutils-gdb/gdb/a.exe I did not and can't easily test more than that. At least, the remaining code is understandable enough that I think we would be able to fix any bug that comes up. This change should not alter the debugging experience on Windows. For more info on the COFF symbol table format: https://www.delorie.com/djgpp/doc/coff/symtab.html Change-Id: I83220589b8e5b242a4ac42a842e504a4aa47aada Approved-By: Tom Tromey 2026-01-16 Simon Marchi gdb/coffread: replace bfd_map_over_sections with iteration Replace two uses of bfd_map_over_sections with an iteration over gdb_bfd_sections. Re-use cs_to_bfd_section in cs_section_address to simplify it. Change-Id: I2b8f70cc1deba151b7b286affe78a43ac1a26375 Approved-By: Tom Tromey 2026-01-16 Tom Tromey Use make_unique_xstrdup in tracepoint This changes the tracepoint code to use make_unique_xstrdup (and make_unique_xstrndup). This meant changing the types of some members of uploaded_tp -- but it seems to me that using array types there did not add any value. Approved-By: Andrew Burgess 2026-01-16 Tom Tromey Use make_unique_xstrdup in more places This replaces a number of uses of 'ptr.reset (xstrdup ())' with 'ptr = make_unique_xstrdup ()'. The main motivation for this is that, IMO, it's better to avoid the reset method when possible. Approved-By: Andrew Burgess 2026-01-16 Richard Ball aarch64: Add support for FEAT_CMH This patch adds the new instructions from FEAT_CMH These new instructions are hints, STCPH and SHUH. SHUH can have an operand PH or no operand. 2026-01-16 Richard Ball arm: Fix MVE vmlas encoding Continuation of fix to VMLA Bit 12 of the first halfword in the VMLAS instruction is listed as (0) in the ARMARM (document DDI0553B.w, version ID07072023). This means that the instruction does not discriminate between signed and unsigned types and processing elements do not use the bit. The encoding used by gas was based on an older version of the document that made the sign important. This change makes it possible to use vmlas.i8 (16,32) in addition to vmlas.u8 and vmlas.s8 mnemonics, with the i8, i16 and i32 aliases becoming the default when disassembling. The generated encoding sets bit 12 to 0, compatibly with other assembler implementations. 2026-01-16 Richard Ball aarch64: Add support for MLBI system instructions This patch adds support for MLB invalidate (MLBI) instruction. Syntax: MLBI {, } This instruction is an alias to "SYS #4, C7, C0, #{, }" and MLBI being the preferred disassembly. The following list of MLBI operations are supported in this patch for the MLBI instructions enabled by "+mpamv2" * alle1 * vmalle1 * vpide1 * vpmge1 2026-01-16 Richard Ball aarch64: Add FEAT_MPAMv2_VID system registers This patch adds the system registers defined by FEAT_MPAMv2_VID. These registers are: *mpamvidcr_el2 *mpamvidsr_el2 *mpamvidsr_el3 2026-01-16 Ezra Sitorus aarch64: Add FEAT_MPAMv2 system registers 2026-01-16 Jens Remus s390: gas: sframe: do not reject .cfi_register REG_SP, REG On s390 64-bit (s390x) compilers may save the SP, FP, and RA registers, which are of interest in SFrame, in other registers, such as floating- point registers, for instance when in a leaf function. SFrame does not explicitly track the SP. Instead SFrame relies on the architecture-specific CFA definition to recover the SP. The s390x ELF ABI [1] defines the CFA as SP at call site + 160, which results in the implicit SP recovery rule SP = CFA - 160. Assuming that CFI on s390 64-bit (s390x) adheres to the CFA definition, it is safe to ignore any CFI directives, that specify the SP register at entry to be saved either on the stack or in another register, as the SP can then always be recovered using the implicit SP recovery rule. [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases Committed-by: Indu Bhagat gas/ * gen-sframe.c (sframe_xlate_do_register): Ignore .cfi_register SP on s390x. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-s390x-err-4): Rename test to cfi-sframe-s390x-sp-register. * gas/cfi-sframe/cfi-sframe-s390x-err-4.d: Rename to ... * gas/cfi-sframe/cfi-sframe-s390x-err-4.s: Likewise. * gas/cfi-sframe/cfi-sframe-s390x-sp-register.d: This. Test that .cfi_register SP is ignored. * gas/cfi-sframe/cfi-sframe-s390x-sp-register.s: Likewise. Add minimal assembler sample. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: testsuite: add new testcases for SFRAME_FDE_TYPE_FLEX This patch adds two new tests for SFrame V3 changes, focusing on the newly added flexible FDE TYPE SFRAME_FDE_TYPE_FLEX. Following tests are added: - be-flipping-v3.c: Validates that big-endian SFrame V3 data is correctly endian flipped when run on little-endian hosts. It verifies the decoding of CFA offsets and the new V3 register/offset metadata bitfields using the SFRAME_V3_FLEX_FDE_OFFSET_REG_* macros. - findfre-flex-1.c: Tests a variety of sframe_find_fre lookup scenarios, apart from checking the basic encoder/decoder APIs. Documentation for the binary test data DATA-BE-V3 is provided in README-be-flipping-v3 to ensure reproducibility. libsframe/ * Makefile.in: Regenerate. * testsuite/libsframe.decode/DATA-BE-V3: New test data. * testsuite/libsframe.decode/README-be-flipping-v3: New file. * testsuite/libsframe.decode/be-flipping-v3.c: New test. * testsuite/libsframe.decode/decode.exp: Run be-flipping-v3. * testsuite/libsframe.decode/local.mk: Add be-flipping-v3. * testsuite/libsframe.find/find.exp: Run findfre-flex-1. * testsuite/libsframe.find/findfre-flex-1.c: New test. * testsuite/libsframe.find/local.mk: Add findfre-flex-1. 2026-01-16 Indu Bhagat Jens Remus [SFrame-V3] sframe: s390: gas: testsuite: enable flex FDE for s390x This commit amalgamates a patch set proposed by Jens Remus to enable the SFrame Version 3 Flexible FDE Type (SFRAME_FDE_TYPE_FLEX) generation for the s390x ABI. Previously, s390x relied on architecture-specific encoding (shifting register numbers into offset fields) to represent register recovery rules. This limited the complexity of CFI that could be supported. With Flex FDE enabled: - s390x can now represent .cfi_def_cfa using non-SP/FP registers. - The architecture-specific function s390_sframe_xlate_do_register () in GAS is replaced by the generic Flex FDE generation path. - The SFrame V3 specific macros for s390x register encoding are removed from libsframe/include, as the generic Flex FDE format handles explicit register columns natively. The testsuite is updated to replace negative tests (which asserted warnings or empty SFrame generation for these patterns) with positive tests verifying valid Flex FDE generation. gas/ * config/tc-s390.c (s390_support_flex_fde_p): Return true to enable Flex FDE generation. * gen-sframe.c (s390_sframe_xlate_do_register): Disable s390x specific implementation. (sframe_xlate_do_register): Invoke generic Flex FDE path now that flex FDE generation is supported. gas/testsuite/ * gas/cfi-sframe/cfi-sframe-s390x-err-1.d: Removed. * gas/cfi-sframe/cfi-sframe-s390x-err-1.s: Moved to... * gas/cfi-sframe/cfi-sframe-s390x-non-spfp-cfa-1.s: ...here. * gas/cfi-sframe/cfi-sframe-s390x-err-2.d: Removed. * gas/cfi-sframe/cfi-sframe-s390x-err-2.s: Moved to... * gas/cfi-sframe/cfi-sframe-s390x-non-spfp-cfa-2.s: ...here. * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-1.d: Update to expect Flex FDE output. * gas/cfi-sframe/cfi-sframe-s390x-fpra-register-2.d: Likewise. * gas/cfi-sframe/cfi-sframe.exp: Run renamed tests. include/ * sframe.h (SFRAME_V3_S390X_OFFSET_IS_REGNUM): Remove. (SFRAME_V3_S390X_OFFSET_ENCODE_REGNUM): Remove. (SFRAME_V3_S390X_OFFSET_DECODE_REGNUM): Remove. libsframe/ * sframe-dump.c (sframe_s390x_offset_regnum_p): Return false for SFrame V3. (sframe_s390x_offset_decode_regnum): Remove V3 support. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: doc: specification changes for SFrame version 3 Update the SFrame specification to document Version 3. This version introduces fundamental changes to support additional scenarios (e.g., s390x register-based recovery, x86_64 DRAP) using a 'Flexible FDE' definition while maintaining compactness for standard frames. Key changes documented include: - The SFrame Function Descriptor Entry (FDE) is split into two distinct structures: [sframe_func_desc_idx] Fixed-size index for binary search. [sframe_func_desc_attr] Variable-location attributes including new info bytes. - Flexible FDEs (SFRAME_FDE_TYPE_FLEX) A new FDE type that interprets FRE bytes not as simple stack offsets, but as pairs of "Control Data" and "Offset". This allows encoding complex recovery rules (e.g., "CFA = *(RBP - 8)") without bloating the format for standard cases. - Provision for defining new FDE types in future. A total of 5 bits are reserved for this purpose. - Make explicit distinction between FDE Types vs. PC Type [FDE Type] Defines how to interpret stack trace data (Default vs. Flex). [PC Type] Defines how PCs are advanced for an FDE (Increment vs. Mask). - Other renames like sfde_func_start_address is renamed to sfdi_func_start_offset to accurately reflect that it is a relative offset, not an absolute address. - Remove SFRAME_F_FRAME_POINTER from SFrame V3. The corresponding bit is now unused in SFrame V3. libsframe/doc/ * sframe-spec.texi: Update text for SFrame Version 3. (Changes from Version 2 to Version 3): New section. (The SFrame FDE Index): New section documenting sframe_func_desc_idx. (The SFrame FDE Attribute): New section documenting sframe_func_desc_attr. (The SFrame FDE Info Bytes): Expanded to document sfda_func_info and sfda_func_info2 split. (The SFrame FDE PC Types): Document SFRAME_V3_FDE_PCTYPE_INC and SFRAME_V3_FDE_PCTYPE_MASK. (The SFrame FDE Types): Document SFRAME_FDE_TYPE_DEFAULT and SFRAME_FDE_TYPE_FLEX. (Interpretation of SFrame FREs): Split into Default and Flexible interpretation. (Flexible FDE Type Interpretation): Document the Control Data/Offset pair encoding. 2026-01-16 Indu Bhagat [SFrame-V3] include: libsframe: remove SFRAME_F_FRAME_POINTER flag SFrame V3 has 8 precious flag bits, two of which are being used. More flag byte (s) can be added to the auxiliary header when it comes to that. But for now, it may be worthwhile to use the 8-bits frugally. SFRAME_F_FRAME_POINTER flag bit was added with the intention of marking binaries built with frame-pointer preserved. A stack tracer could then use this information, to unambiguously ascertain whether frame-pointer based stack traces will be precise. But such a marking of binary will ideally be done by the linker, and at the moment adding such a framework is not justified for such small gain. The outcome of this is that SFRAME_F_FRAME_POINTER is never set in SFrame V2 binaries. Remove the definition SFRAME_F_FRAME_POINTER for SFrame V3. The relinquished bit can be used (in future format incarnations) when reading/dumping SFrame V2 sections are no longer supported by consumers. Changing the values of existing flags, e.g., SFRAME_F_FDE_FUNC_START_PCREL, is not being done for V3, to avoid version-specific flag bit reading (albeit doable) in consumers. Related changes to the specification are done in a subsequent commit. include/ * sframe.h (SFRAME_V3_F_ALL_FLAGS): Remove SFRAME_F_FRAME_POINTER from the set of V3 flags. libsframe/ * sframe-dump.c (dump_sframe_header_flags): Add a comment for clarity. 2026-01-16 Indu Bhagat [SFrame-V3] gas: binutils: ld: NEWS: add SFrame v3 related announcements Add NEWS entries related to the SFrame version 3 release. 2026-01-16 Indu Bhagat [SFrame-V3] ld: testsuite: x86: sframe: check link of signal frame and outermost frames In this test, two "special" case FDEs are linked: - Signal frame where the SFrame stack trace data is not representable. - _start like outermost frame function. This is useful test for sframe_encoder's merge input sections functionality and its associated write code-paths (sframe_encoder_write) too. ld/testsuite/ * ld-x86-64/sframe-link-1.d: New test. * ld-x86-64/sframe-signal.s: New input file. * ld-x86-64/sframe-start.s: Likewise. * ld-x86-64/x86-64.exp: Add new test. 2026-01-16 Indu Bhagat [SFrame-V3] ld: add --discard-sframe command line option Add a new command line option --discard-sframe to the linker. This option allows users to prevent the linker from generating an output .sframe section. The rationale for this option is: Consider the case when say, the distro is shipped with SFrame sections in the installed binaries/libraries. A user application using these installed libraries, but not enabling .sframe for itself just yet, will see an output .sframe corresponding to the pulled in libraries. This is "partial" .sframe information for the application. Adding such an option to the linker, gives user a way to turn off the .sframe section completely without relying on a linker script. Previously, the existing --no-ld-generated-unwind-info option controlled whether (not just .eh_frame for PLT entries, but also) SFrame for PLT entries. The new command line option, --discard-sframe now decouples SFrame from other unwind formats (like .eh_frame), allowing for more control over the output binary's SFrame data. The option is added for architectures that currently support SFrame: AArch64, s390x, and x86_64. bfd/ * elf-sframe.c (_bfd_elf_parse_sframe): Mark with SEC_EXCLUDE if --discard-sframe is in effect. * elf64-s390.c (elf_s390_create_dynamic_sections): Use discard_sframe to guard .sframe section creation. * elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Likewise. include/ * bfdlink.h (struct bfd_link_info): Add discard_sframe bitfield. ld/ * ldlex.h (enum option_values): Add OPTION_NO_LD_SFRAME_INFO. * lexsup.c (elf_sframe_list_options): New function. (ld_list_options): Add sframe_info argument. Update callers. * ld.texi: Update documentation. * emulparams/sframe-info.sh: New file. * emultempl/aarch64elf.em: Add --discard-sframe option listing and handling. * emulparams/elf64_s390.sh: Likewise. * emulparams/elf_x86_64.sh: Likewise. * Makefile.am: Update to handle sframe-info.sh and new list options. * configure.ac: Handle SFRAME_INFO target variable. * Makefile.in: Regenerate. * configure: Regenerate. ld/testsuite/ * ld-x86-64/x86-64.exp: New test. * ld-x86-64/sframe-command-line-1.d: New test. * ld-aarch64/aarch64-elf.exp: New test. * ld-s390/s390.exp: New test. * ld-x86-64/x86-64.exp: New test. * ld-aarch64/sframe-command-line-1.d: New test. * ld-s390/sframe-command-line-1.d: New test. * ld-x86-64/sframe-command-line-1.d: New test. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: doc: testsuite: add new command line option --gsframe-3 This option will allow users to select emission of SFrame stack trace information as per the SFrame version 3 specification. Currenly, SFrame version 3 is also the default. In future, as SFrame evolves, similar command line args may be added for future versions. gas/ * as.c (enum gen_sframe_version): New definition. (parse_args): Add option processing for --gsframe-3. * as.h (enum gen_sframe_version): New declaration. * doc/as.texi: Document the new option. * gen-sframe.c (sframe_set_version): Use enum gen_sframe_version as version. (output_sframe): Likewise. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: New test. * gas/cfi-sframe/cfi-sframe-common-1d.d: Test new command line option --gsframe-3. * gas/cfi-sframe/cfi-sframe-common-1d.s: Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] include: gas: libsframe: split FDE into idx and attr This patch introduces a structural change to the SFrame V3 format. It shifts the SFrame Function Descriptor Entry (FDE) (a physical entity in SFrame V2) into a conceptual one in SFrame V3, such that an FDE is now split into two distinct parts to optimize the binary search table and data organization: - FDE Index (sframe_func_desc_idx_v3): This structure contains the essential indexing information: the function start address offset, function size in bytes, and the offset to the SFrame FDE attribute/Frame Row Entries (FREs) area for the function. - FDE Attributes (sframe_func_desc_attr_v3): The metadata regarding the function (number and size of FREs, FDE type, and repetition block size etc.) is moved to a new structure. On-Disk Layout: In V3, the "Attributes" are now stored immediately preceding the SFrame FREs for that function. The sfde_func_start_fre_off now points to the attr structure, and the actual FREs follow immediately after. IOW, the "Attributes" are now moved to the FRE sub-section, located immediately preceding the FREs for the respective function. The above layout has the advantage that: a) its cleaner with separation between the index elements vs other data b) the index has better cache locality (by virtue of it being smaller than the layout in SFrame V2). c) As the format evolves, the guarantees of alignment for FDE index are easier to maintain. FDE attr, being in the SFrame FRE sub-section, carry no guarantees of alignment. This had been previously suggested and communicated in an earlier discussion on binutils mailling list https://inbox.sourceware.org/binutils/29b1f7b0-61ea-410c-8aca-d5dd6115e668@oracle.com/ The read/write paths in sframe.c are updated to account for this split. sframe_fde_tbl_init now requires access to the FRE buffer to populate the internal FDE table, as the attributes are no longer resident in the FDE section. flip_sframe is refactored into version-specific handlers (_v2 and _v3) because the endian-swapping logic now differs significantly. In V3, the iterator must jump from the FDE table to the FRE section to swap the attributes. Lastly, the two entities generating SFrame sections (GAS and GNU ld) both now must _not_ set the sfde_func_start_fre_off to zero, when the number of FREs is zero. This is because now there will be some valid attr data at that location. Backward Compatibility: Due to the need to support readelf/objdump for SFrame V2 sections, the patch explicitly maintains V2 support via separate code paths (e.g., flip_sframe_fdes_with_fres_v2) Note about alignment: Now that the sframe_func_desc_idx_v3 is refactored out of the conceptual SFrame FDE, SFrame FDE index member elements are at aligned boundaries again. The alignment property for SFrame FDE was broken from an ealier patch "[08/36] sframe: gas: libsframe: use uint16_t for num_fres of FDE" up until this one. include/ * sframe.h (sframe_func_desc_entry_v3): Remove sfde_func_num_fres, sfde_func_info, sfde_func_info2, and sfde_func_rep_size. Rename to sframe_func_desc_idx_v3. (sframe_func_desc_attr_v3): New SFrame FDE attribute structure. libsframe/ * sframe.c (sframe_fde_tbl_init): Add argument for FRE buffer. Read attributes from the FRE section for V3. (flip_fde_desc): Rename from flip_fde. Check size against sframe_func_desc_entry_v3. (flip_fde_attr_v3): New function. (sframe_decode_fde_desc_v2): New function extracted from sframe_decode_fde. (sframe_decode_fde_desc_v3): New function. (sframe_decode_fde_attr_v3): New function. (flip_sframe_fdes_with_fres_v2): New function for V2 flipping. (flip_sframe_fdes_with_fres_v3): New function for V3 flipping. (flip_sframe): Dispatch to version-specific flip functions. (sframe_decode): Pass FRE buffer to sframe_fde_tbl_init. (sframe_decoder_get_offsetof_fde_start_addr): Adjust for subset of sframe_func_desc_entry_v3 restructured into sframe_func_desc_idx_v3. (sframe_encoder_get_offsetof_fde_start_addr): Likewise. (sframe_find_fre): Skip attribute size to find FREs in V3. (sframe_decoder_get_fre): Likewise. (sframe_decoder_get_fres_buf): Likewise. (sframe_encoder_add_fre): Add attribute size to byte count. (sframe_encoder_add_fres_buf): Read attributes from buffer. (sframe_encoder_write_fde): Write only FDE index fields. (sframe_encoder_write_func_attr): New function. (sframe_encoder_write_sframe): Write FDE attributes before FREs. gas/ * gen-sframe.c (output_sframe_funcdesc): Do not reset sfde_func_start_fre_off to zero when zero num FREs. (output_sframe_func_desc_attr): New refactored out function. (output_sframe_internal): Invoke output_sframe_func_desc_attr. libsframe/testsuite/ * libsframe.decode/DATA2: Regenerate data file. 2026-01-16 Indu Bhagat [SFrame-V3] bfd: ld: sframe: avoid unnecessary decoding of SFrame FREs at link time At link time, in _bfd_elf_merge_section_sframe (), it suffices to bring over the all per-function stack trace metadata (all FREs) as a blob into the SFrame encoder object. There is no need to "decode" each SFrame FRE, only to add them in a serial fashion. This is an optimization, and not directly related to any SFrame V3 related changes to the specification. This should also bring us a step closer to supporting SFrame for targets which use linker relaxations. Removing the need to decode the input FREs can allow the linker to simply use the available set of FREs from (relocated) contents. To support targets using linker relaxations in SFrame, other changes in the SFrame parse functionality time may also be necessary, but this brings us just a step closer. Add two new APIs to accomplish this: - sframe_decoder_get_fres_buf, and - sframe_encoder_add_fres_buf bfd/ * elf-sframe.c (_bfd_elf_merge_section_sframe): Get all FRE data and add it all in bulk. libsframe/ * libsframe.ver: Add new APIs. * sframe.c (sframe_buf_fre_entry_size): New internal API to get size of one SFrame FRE at the indicated buffer location, without fully "decoding" the SFrame FRE. (sframe_decoder_get_fres_buf): New definition. (sframe_encoder_add_fres_buf): New definition. include/ * sframe-api.h (sframe_decoder_get_fres_buf): New declaration. (sframe_encoder_add_fres_buf): New declaration. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: testsuite: handle .cfi_offset for RA With the introduction of flex FDE type, handling .cfi_offset for RA needs adjustment. On architectures like x86_64, the return address (RA) is typically saved at a fixed offset from the CFA. Previous versions of the SFrame format assumed this fixed offset was invariant for the entire function on such architectures. Consequently, GAS would warn and suppress SFrame generation if it encountered a .cfi_offset directive for the RA register that deviated from this fixed default. SFrame V3 introduces "Flex FDEs" which allows tracking the RA location explicitly even on architectures where it is usually fixed. This patch updates sframe_xlate_do_offset () to leverage Flex FDEs. When processing a .cfi_offset for the RA register: - The check for non-representable RA offsets is relaxed. If the ABI supports Flex FDEs (SFrame V3), GAS proceeds instead of issuing a warning. - For ABIs without explicit RA tracking (like AMD64), if the RA offset differs from the default fixed offset, the FDE is marked as a Flex FDE, and the new stack location is recorded. - Logic is added to detect when the RA is restored to its standard fixed offset. In this case, the tracking state is reset (ra_loc set to SFRAME_FRE_ELEM_LOC_NONE), deferring to the ABI's default fixed RA offset behavior. gas/ * gen-sframe.c (sframe_xlate_do_offset): Support .cfi_offset for RA by switching to Flex FDEs when necessary. gas/testsuite/ * gas/cfi-sframe/cfi-sframe-x86_64-6.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-6.s: New test to check transition of location of REG_RA from register to CFA-8 (default location on AMD64). Flex FDE in effect. * gas/cfi-sframe/cfi-sframe.exp: Add new test. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: testsuite: skip SFrame FDE if .cfi_register SP, reg SFrame does not track the SP. For recovery of the SP, SFrame relies on the architecture/ABI's CFA definition: CFA = SP [+ offset // on s390x] Which results in the following implicit CFA value offset rule for SP: SP = CFA [- offset // on s390x] Where offset is zero for most architectures/ABIs, except s390x. Therefore .cfi_register SP, reg directives must be rejected, as such semantics cannot be represented in SFrame yet. gas/ * gas/gen-sframe.c (s390_sframe_xlate_do_register): Check for REG_SP and reject while generating a warning. (sframe_xlate_do_register): Likewise. gas/testsuite/ * gas/cfi-sframe/cfi-sframe-s390x-err-4.d: New test. * gas/cfi-sframe/cfi-sframe-s390x-err-4.s: Likewise. * gas/cfi-sframe/cfi-sframe-x86_64-empty-5.d: Likewise. * gas/cfi-sframe/cfi-sframe-x86_64-empty-5.s: Likewise. * gas/cfi-sframe/cfi-sframe.exp: Add new tests. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: testsuite: handle .cfi_register FP/RA for flex FDE Use SFrame FDE of type SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME. When FP, RA were moved to a general-purpose register, the SFrame generation previously warned and skipped the FDE (except on s390x). This patch updates the translator to detect .cfi_register for RA (and FP), tracks the destination register in the SFrame row entry, and emits the register in the relevant FRE offsets in SFrame FDE type SFRAME_FDE_TYPE_FLEX. gas/ * gen-sframe.c (sframe_row_entry_initialize): Propagate ra_reg and ra_deref_p. (sframe_xlate_do_register): Handle .cfi_register for RA/FP on AMD64 by setting flex_p and recording the register. gas/testsuite/gas/ * cfi-sframe/cfi-sframe.exp: Run new test. * cfi-sframe/cfi-sframe-x86_64-5.d: New test. * cfi-sframe/cfi-sframe-x86_64-5.s: Simple test for checking FLEX FDE generation for `.cfi_register REG_RA, XX`. * cfi-sframe/cfi-sframe-x86_64-esc-expr-3.d: New test. * cfi-sframe/cfi-sframe-x86_64-esc-expr-3.s: New test with DWARF expression for REG_FP, followed by .cfi_register and .cfi_offset for REG_FP. * cfi-sframe/cfi-sframe-x86_64-ra-undefined-flex-1.d: New test. * cfi-sframe/cfi-sframe-x86_64-ra-undefined-flex-1.s: New test for FLEX FDE with undefined RA. 2026-01-16 Indu Bhagat [SFrame-V3] gas: x86: testsuite: add new testcases for SFRAME_FDE_TYPE_FLEX gas/testsuite/ * gas/cfi-sframe/cfi-sframe-x86_64-4.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-4.s: Non SP/FP based CFA. * gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-1.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-1.s: DRAP pattern with both CFA expression and FP expression. * gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-2.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-2.s: Test CFA expression with sleb128. * gas/cfi-sframe/cfi-sframe.exp: Add new tests. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: gas: translate specific CFI directives for SFRAME_FDE_TYPE_FLEX This patch updates the SFrame generation in GAS to translate specific .cfi_escape directives into the new SFrame V3 FDE type SFRAME_FDE_TYPE_FLEX. The primary goal is to support code patterns where: - the Canonical Frame Address (CFA) is not defined by a simple offset from the Stack Pointer (SP) or Frame Pointer (FP), or where the CFA rule involves a dereference. Such patterns are generated by compilers for stack realignment (e.g., DRAP on x86_64, or when mixing legacy codes that keep 4-byte stack alignment with modern codes that keep 16-byte stack alignment for SSE compatibility). - the Frame Pointer is not defined by a simple offset from the CFA, but may even involve another register and/or dereferencing. - the Return Address is not defined by a simple offset from the CFA, but may even involve another register and/or dereferencing. Support for non-SP/FP based CFA: Update sframe_xlate_do_def_cfa () and sframe_xlate_do_def_cfa_register () to detect when a non-SP/FP register is used for the CFA. Support for CFA expressions: A vital part of supporting the above-mentioned cases on AMD64 is support for CFA expressions. Add sframe_xlate_do_escape_cfa_expr () to parse simple DW_CFA_def_cfa_expression sequence in .cfi_escape. Support for FP expressions: Update sframe_xlate_do_escape_expr () to handle DW_CFA_expression involving DW_OP_breg6 (rbp) on AMD64, allowing for tracking of the Frame Pointer when it is saved with a dereference rule in the DRAP pattern. The "support" for both CFA expressions and FP expressions is quite minimal, and is tailored to the most commonly seen occurrences generated by GCC for AMD64. gas/ * gas/gen-sframe.c (output_sframe_row_entry_offsets): (sframe_xlate_do_def_cfa): Handle non-SP/FP CFA registers by setting flex_p for AMD64. (sframe_xlate_do_def_cfa_register): Likewise. (sframe_xlate_escape_sleb128_to_int64): New definition. (sframe_xlate_do_escape_cfa_expr): New function to handle DW_CFA_def_cfa_expression of specific shapes. (sframe_xlate_do_escape_expr): Update to handle dereferenced FP rules. (sframe_xlate_do_cfi_escape): Invoke sframe_xlate_do_escape_cfa_expr (). (create_sframe_all): In case of error, but when signal frame is also true, there cannot be a flex FDE. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: add new backend hook sframe_support_flex_fde_p for FLEX FDEs For the newly added SFrame FDE type SFRAME_FDE_TYPE_FLEX, add a new backend hook so that the respective ABI/arch can opt out of the generation of SFRAME_FDE_TYPE_FLEX in GAS. AArch64 is an example of an ABI for which SFrame is supported, but one that does not need the flexible FDE representation for any of the current usecases currently. Reviewed-by: Jens Remus gas/ * config/tc-aarch64.c (aarch64_support_flex_fde_p): New definition. * config/tc-aarch64.h (aarch64_support_flex_fde_p): New declaration. (sframe_support_flex_fde_p): Define. * config/tc-i386.c (x86_support_flex_fde_p): New definition. * config/tc-i386.h (x86_support_flex_fde_p): New declaration. (sframe_support_flex_fde_p): Define. * config/tc-s390.c (s390_support_flex_fde_p): New definition. * config/tc-s390.h (s390_support_flex_fde_p): New declaration. (sframe_support_flex_fde_p): Define. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: textual dump of fde type SFRAME_FDE_TYPE_FLEX Refactor the SFrame textual dumper in sframe-dump.c to properly handle the new FDE type. In SFrame V2, the textual dumper could afford to be oblivious to the exact DWARF register number for stack-pointer and frame-pointer registers in each ABI. This is because a single bit was used to differentiate between the two (irrespective of the ABI), and the dumper could easily just use a: const char *base_reg_str[] = {"fp", "sp"}; to get the register name. With the introduction of new SFrame FDE type SFRAME_FDE_TYPE_FLEX, which carry DWARF register numbers if applicable, this needs to change. E.g., for some patterns on AMD64, one may see CFA is the value at 'r10+0'; or FP is the value at 'rbp+8'. This means that for textual dump, we now need a mapping from: - the ABI-specific frame-pointer to string "fp" - the ABI-specific stack-pointer to string "sp" This is done via the SFRAME_ABI_REG_MAP helper macros and the new sframe_get_reg_name () API. For registers other than stack-pointer and frame-pointer, the SFrame textual dump does not print the register name (say, "rax"), but just the number (i.e., "r0"). Check the func_info2 byte and dispatch the stack frame row entry (FRE) dumping to the correct function: either dump_sframe_func_fre_simple or dump_sframe_func_fre_flex. Ensure the display is consistent to previous semantics. When flex FDE is in effect, there may not always be an RA offset (after the CFA offsets). A padding offset for RA is present if FP offsets follow. So if a padding offset for RA is seen, we will display "U". If no RA offset is seen, however, we will display a "u" unless its an ABI where RA offset is fixed (in the latter case we display "f"). libsframe/ * sframe-dump.c (SFRAME_SP): Define mapping from stack-pointer register number to "sp". (SFRAME_FP): Define mapping from frame-pointer register number to "fp". (SFRAME_ABI_REG_MAP): Helper macro to define per-ABI-arch mappings. (sframe_get_reg_name): Helper API to get register name. (dump_sframe_func_with_fres): Refactor a bit... (dump_sframe_func_fre_simple): ..into this. (sframe_format_fre_disp): New definition. (dump_sframe_func_fre_flex): Likewise. (dump_sframe): Allow both SFrame version 2 and version 3. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: testsuite: add new argument to offset access APIs For FDE type SFRAME_FDE_TYPE_FLEX, the offsets are not only laid out differently, they also have different encoding: - first data item is of unsigned type, it indicates the "Control Word" - second data item is of signed type, it indicates the "Offset Word" (The usage of "Word" above is colloquial, does not indicate a machine word of a specific size.) Adjust the APIs in libsframe to get stack frame offsets by adding a new argument type. Also add a new API to read the data items as unsigned types of the specified size: sframe_get_fre_udata. At the moment, like the generation routines in GAS, the textual dump routines in sframe-dump.c are also unaware of the FDE type SFRAME_FDE_TYPE_FLEX. In the next commits, these capabilities will be added. include/ * sframe-api.h (MAX_NUM_STACK_OFFSETS): Increase the number of stack offsets to 6 to accommodate the FDE type SFRAME_FDE_TYPE_FLEX. (sframe_get_fre_udata): New declaration. (sframe_fre_get_cfa_offset): Add new arg. (sframe_fre_get_fp_offset): Likewise. (sframe_fre_get_ra_offset): Likewise. libsframe/ * libsframe/sframe-dump.c (dump_sframe_func_with_fres): Pass SFRAME_FDE_TYPE_DEFAULT for FDE type. * sframe.c (sframe_fre_get_cfa_offset): Handle FDE type. (sframe_fre_get_fp_offset): Likewise. (sframe_fre_get_ra_offset): Likewise. * libsframe/libsframe.ver: Add new API sframe_get_fre_udata. libsframe/testsuite/ * libsframe.find/findfre-1.c: Pass SFRAME_FDE_TYPE_DEFAULT for FDE type. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: output new FDE type SFRAME_FDE_TYPE_FLEX This patch updates the routines for emission of the new FDE type SFRAME_FDE_TYPE_FLEX in the SFrame output section. The support for generating these flex FDEs themselves is added in a subsequent commit. Update struct sframe_row_entry to track additional state for CFA, FP, and RA. Modify output_sframe_row_entry_offsets () to emit metadata/offset pairs for flexible FDEs or padding where applicable, ensuring the usual ordering (CFA, RA, FP). The padding data, a.k.a. SFRAME_FRE_RA_OFFSET_INVALID is emitted in flexible FDEs when RA is untracked but FP offsets follow. Trailing padding offsets should not occur. Add a new function get_udata_size_in_bytes () to account for sizing of unsigned register metadata. gas/ * gen-sframe.c (get_udata_size_in_bytes): Get size of unsigned int data in bytes. (get_fre_num_offsets): Handle SFRAME_FDE_TYPE_FLEX. (sframe_get_fre_offset_size): Account for register metadata in flexible FDEs. (output_sframe_row_entry_offsets): Add logic for flexible FDE offset pairs. (output_sframe_row_entry): Reset base register for flex FDEs. (output_sframe_funcdesc): Emit FDE type in func_info2. (sframe_xlate_ctx_init): Initialize flex_p. (sframe_xlate_ctx_finalize): Finalize flex_p status. (sframe_row_entry_initialize): Copy new deref tracking bits. (sframe_xlate_do_offset): Set deref bits during translation. * gen-sframe.h (struct sframe_row_entry): Add cfa_deref_p, fp_deref_p, and ra_deref_p. (struct sframe_func_entry): Add fde_flex_p. (struct sframe_xlate_ctx): Add flex_p. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: use three states for location tracking Up until now, for SFrame stack trace data generation (for default FDE type), keeping two states sufficed to distinguish between the following cases: - the tracked entity is saved on a location on stack (identified by SFRAME_FRE_ELEM_LOC_STACK) - the tracked entity is in its designated register (identified by SFRAME_FRE_ELEM_LOC_REG). Soon though, we will start to generate a new FDE type SFRAME_FDE_TYPE_FLEX, where in addition to above: - the tracked entity may be saved in a temporary register - the tracked entity may be saved at a "non-standard" location, e.g., not a simple CFA+offset based location - and other cases To effectively distinguish between the various states (necessary to track for flex FDEs), define three states to track the location of each tracked entity: - SFRAME_FRE_ELEM_LOC_NONE: the entity is in its desginated location (e.g., in case of AMD64 where the RA is at fixed offset from CFA) - SFRAME_FRE_ELEM_LOC_REG: the entity is in a location based off a register - SFRAME_FRE_ELEM_LOC_STACK: the entity is in a location based off the CFA While at it, rather than asserting in sframe_xlate_do_offset (), reset the fp_reg state to SFRAME_FRE_REG_INVALID. This is in preparation for upcoming flex FDE generation patches. Co-Authored-by: Jens Remus Reviewed-by: Jens Remus gas/ * gen-sframe.c (sframe_xlate_do_offset): Reset other state. (sframe_xlate_do_same_value): Reset to SFRAME_FRE_ELEM_LOC_NONE. * gen-sframe.h (SFRAME_FRE_ELEM_LOC_REG): New definition. (SFRAME_FRE_ELEM_LOC_STACK): Likewise. (SFRAME_FRE_ELEM_LOC_NONE): Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] gas: bfd: include: libsframe: fixup terminology 'PC Type' vs 'FDE Type' In SFrame V2, we did use the the term 'FDE Type' for the two designated 'PC Type' for the SFrame FDEs (SFRAME_FDE_TYPE_PCINC, SFRAME_FDE_TYPE_PCMASK). In hindsight, 'FDE Type' was an inappropriate term for the said intent. Fix this terminology by defining two new constants: - SFRAME_V3_FDE_PCTYPE_MASK - SFRAME_V3_FDE_PCTYPE_INC The old constants from V2 (SFRAME_FDE_TYPE_PCINC, SFRAME_FDE_TYPE_PCMASK) remain, but are now unused in the codebase. The term 'FDE Type' should be used for the actual FDE Types. In a subsequent commit, we will add SFRAME_FDE_TYPE_FLEX FDE Type for SFrame V3. bfd/ * elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Rename inappropriate SFRAME_FDE_TYPE_PCINC to SFRAME_V3_FDE_PCTYPE_INC. * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise. Also rename inappropriate SFRAME_FDE_TYPE_PCMASK to SFRAME_V3_FDE_PCTYPE_MASK. gas/ * gen-sframe.c (output_sframe_funcdesc): Likewise. * sframe-opt.c (sframe_convert_frag): Likewise. libsframe/ * sframe-dump.c (dump_sframe_func_with_fres): Likewise. * sframe.c (sframe_fre_check_range_p): Likewise. (sframe_fde_create_func_info): Likewise. libsframe/testsuite/ * libsframe.encode/encode-1.c: Likewise. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] include: sframe: reserve 5 bits for new FDE types In SFrame V2, the FDE representation caters to the most common cases of stack trace metadata: - CFA is SP/FP based, - FP/RA offsets, if present are CFA based (except some cases in s390x where reg can be encoded). Introduce an additional FDE type SFRAME_FDE_TYPE_FLEX, which can encode a more flexible set of CFA, FP and RA recovery rules. Some of the patterns supported include: - CFA may be non-SP/FP based. - CFA, FP may encode dereferencing of register after offset adjustment - RA may be in a non-default register. The important bit here is that since SFrame does not track all callee-saved registers, the above-mentioned recovery rules must only be done for topmost frames (by the stack tracer). Adding a new FDE type does have implications for a stack tracer in that it needs to: - Check the FDE type before interpreting the variable length bytes trailing the SFrame FRE header as stack offsets. - If the FDE type is SFRAME_FDE_TYPE_FLEX, and the recovery rules employ the use of any non-SP/FP based register, the stack tracer must proceed only if it is the topmost frame on stack. For CFA, RA, and FP, up to two "offsets" may be used. The two offsets represent the information as follows: - (minimum 8-bit) offset1 to encode register like: (regnum << 3) | unused << 2 | deref << 1 | reg_p (=1) - offset2 to encode offset: offset reg_p = 1 indicates a register, reg_p = 0 indicates CFA. The offsets are in the usual order: CFA, RA, FP if present. For example, for FP/RA tracking, a) If the reg is REG1 for FP/RA tracking, - Encoding: + offset1 to encode register: (REG1 << 3) | unused << 2 | deref << 1 | reg_p (=1) + offset2 to encode offset: offset - Action: + if deref, FP/RA = \*(REG1 + offset) (e.g., seen for FP recovery with certain DRAP patterns on x86_64) + if no deref, FP/RA = REG1 + offset b) If the reg is CFA for FP/RA tracking, - Encoding: + [=Effectively Padding] offset1 to encode register: (( 0 << 3 ) | unused << 2 | 0 << 1 | reg_p (=0)) + offset2 to encode offset: offset - Action: + if deref, FP/RA = *(CFA + offset) + if no deref, FP/RA = CFA + offset (pattern shouldnt be seen for RA) Next for CFA tracking, - Action: + if deref, CFA = *(reg + offset) (e.g., seen for CFA recovery in some stack realignment patterns on AMD64) + if no deref, CFA = reg + offset (e.g., for .cfi_def_cfa 2, 8, or .cfi_def_cfa 10, 0) Expected usage of this FDE type is quite low (DRAP on x86_64). NB: In SFrame V2, we did use the the term 'FDE Type' for the two designated 'PC Type' for the SFrame FDEs (SFRAME_FDE_TYPE_PCINC, SFRAME_FDE_TYPE_PCMASK). In hindsight, 'FDE Type' was inappropriate term. In a subsequent commit, we will fix this terminology for SFrame V3. include/ * sframe.h (SFRAME_FDE_TYPE_FLEX): New SFrame FDE type. (SFRAME_V3_FDE_TYPE_MASK): New constant definition. (SFRAME_V3_FDE_TYPE): New macro definition. (SFRAME_V3_SET_FDE_TYPE): Likewise. (SFRAME_V3_FLEX_FDE_REG_ENCODE): Macro to encode register in the SFrame offset data. (SFRAME_V3_FLEX_FDE_OFFSET_REG_NUM): New definition. (SFRAME_V3_FLEX_FDE_OFFSET_REG_DEREF_P): Likewise. (SFRAME_V3_FLEX_FDE_OFFSET_REG_P): Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] include: gas: libsframe: add 8-bits of func_info2 for extensibility in FDE The existing field func_info (in the SFrame FDE) is used to convey important information around the encoding and interpretation of the rest of the stack trace data for the respective SFrame FDE: the SFrame FRE type, SFrame FDE PC type, etc. Currently there is 1 bit left for AArch64, and 2 bits for AMD64, s390x (and other future ABIs to be supported). Provision some additional space now (specifically an additional 8-bits) for future needs for V3 and beyond. Compared to V2, this now increases the size of SFrame FDE by 1 byte in V3. In this patch, the additional func_info2 byte is not used functionally yet. Hence, rather mechanical changes in libsframe, bfd and libsframe/testsuite accompany. We will put func_info2 into use in a later patch by reserving 5 of these bits for SFrame FDE types. With the addition of a new byte for additional func info (func_info2), add a new arg to allow usecases like textual dumper to get all data members in one API: sframe_decoder_get_funcdesc_v3. To keep the APIs symmetric looking, add new arg to sframe_encoder_add_funcdesc_v3 too. Since bfd uses these APIs, carry out the mechanical change in the respective APIs too. And of course, the testsuite which exercises these APIs. bfd/ * elf-sframe.c (_bfd_elf_merge_section_sframe): Get and set func_info2. * elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Pass 0 for func_info2 for SFrame FDE for PLT. * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise. gas/ * gen-sframe.c (output_sframe_funcdesc): Emit the uint8_t for func_info2. libsframe/ * sframe-dump.c (dump_sframe_func_with_fres): * sframe.c (sframe_fde_tbl_init): Handle the new additional member. (sframe_encoder_write_fde): Likewise. * sframe.c (sframe_decoder_get_funcdesc_v3): Update func_info2. libsframe/testsuite/ * libsframe.decode/DATA2: Update data file with SFrame section data. * libsframe.encode/encode-1.c: Pass 0 for func_info2 arg. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. include/ * sframe.h: Add new uint8_t sfde_func_info2 to sframe_func_desc_entry_v3. * sframe-api.h (sframe_decoder_get_funcdesc_v3): New arg. (sframe_encoder_add_funcdesc_v3): Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] gas: sframe: allow SFrame FDEs with 0 FREs for signal frames Update the SFrame generation logic in GAS to emit Function Descriptor Entries (FDEs) for signal frames even when no Frame Row Entries (FREs) could be generated. Previously, create_sframe_all () would discard any FDE that failed translation or resulted in zero FREs. However, for signal frames (marked with .cfi_signal_frame), preserving the FDE may be valuable even without stack offsets. The presence of the SFrame FDE with the 'Signal' attribute may allow stack tracers to identify the frame as a signal trampoline and potentially apply fallback handling, rather than treating the PC range as having no stack trace info at all. The patch modifies create_sframe_all () to detect translation errors for signal frames, effectively allowing the generation of an empty FDE (0 FREs) marked with the 'S' attribute. gas/ * gen-sframe.c (sframe_fde_free): Add NULL check for safety. (create_sframe_all): Allow FDEs for signal frames even if translation encountered errors or produced no FREs. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: New test. * gas/cfi-sframe/cfi-sframe-x86_64-signal-1.d: New test ensuring signal frame FDE is emitted with 0 FREs. * gas/cfi-sframe/cfi-sframe-x86_64-signal-1.s: New test. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: gas: bfd: add support for signal frames Reserve a bit in function info byte in the SFrame FDE to designate signal frames. Also update the SFrame opt code in GAS and dumping routines in libsframe to handle signal frame bit. include/ * sframe.h (SFRAME_V3_FDE_SIGNAL_P): Extract signal frame bit. (SFRAME_V3_FDE_UPDATE_SIGNAL_P): Set signal frame bit. gas/ * gen-sframe.c (get_dw_fde_signal_p): New function to retrieve signal frame state from DWARF FDE. (sframe_v3_set_func_info): Renamed from sframe_v1_set_func_info. Accept signal_p argument and encode it. (sframe_set_version): Update ops to use sframe_v3_set_func_info. (sframe_set_func_info): Pass signal_p to the ops hook. (output_sframe_funcdesc): Retrieve signal frame marker and pass to sframe_set_func_info. * gen-sframe.h (struct sframe_version_ops): Update set_func_info signature. * sframe-opt.c (sframe_convert_frag): Preserve signal_p bit during fragment conversion. While at it, use SFRAME_V3_* macros where applicable. libsframe/testsuite/ * gas/cfi-sframe/cfi-sframe-common-13.d: New test. * gas/cfi-sframe/cfi-sframe-common-13.s: New test. * gas/cfi-sframe/cfi-sframe.exp: Run new test. libsframe/ * sframe-dump.c (dump_sframe_func_with_fres): Decode signal frame bit and print "S" attribute in the dump output. 2026-01-16 Indu Bhagat [SFrame-V3] include: libsframe: bfd: gas: testsuite: support for signed 64-bit offset in SFrame FDE This change enables support text > 2 GiB in SFrame format. Each SFrame FDE needs to hold information about the start PC of the function it pertains to. Currently, the field 'sfde_func_start_address' in SFrame FDE is encoded as a 32-bit offset to the start PC of the function from the field itself. In SFrame V2, this offset was a signed 32-bit offset. The signedness gives the flexibility of having .sframe ELF section before or after the .text* sections. But the size of 32-bit puts the limitation that .sframe togther with the .text* sections must fit the 2 GiB range. Currently, if the linker sees the offset not representable as 32-bit signed offset, it issues an error (not seen in the wild, simulated by forcing a function to align via an '.align 2147483648' directive): test.o:(.sframe+0x1c): relocation truncated to fit: R_X86_64_PC32 against `.text' make: *** [Makefile:7: all] Error 1 ATM, EH Frame also suffers with the same issue. Moving forward, some cloud applications have been shown to be nearing 1.5 GiB threshold. Extending the offset to int64_t now seems to be good choice to make now for future-proof'ing the sections. The use of int64_t offset is done for all SFrame V3 sections. This bump from int32_t to int64_t should not lead to an increase in the size of SFrame sections, because of the following additional changes to the SFrame FDE specification: - Reduce the type of sfde_func_num_fres (from uint32_t to uint16_t) - Remove the 2 bytes of padding (sfde_func_padding2). These served the two-fold purpose of keeping FDE data aligned _and_ unused space for future needs. Now that the offset is int64_t, start using the sframe_decoder_get_funcdesc_v3 () instead of sframe_decoder_get_funcdesc_v2 () in GNU ld. This patch changes the offset type in the SFrame FDE definition to an int64_t. No further changes in gas are necessary because the code already accounts for writing out as per the size of the member of the struct: emit_expr (&exp, sizeof_member (sframe_func_desc_entry, sfde_func_start_offset)); bfd/ * elf-sframe.c (sframe_read_value): Signed offset for start PC is 8-bytes now. (_bfd_elf_merge_section_sframe): Likewise. * elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Use V3 API. (elf_s390_finish_dynamic_sections): Signed offset for start PC is 8-bytes now. * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use V3 API. (_bfd_x86_elf_finish_dynamic_sections): Signed offset for start PC is 8-bytes now. gas/ * sframe.c (output_sframe_funcdesc): Rename to sfde_func_start_offset. libsframe/ * libsframe/sframe.c (sframe_fde_tbl_init): Rename to sfde_func_start_offset. (flip_fde): Likewise. (sframe_decoder_get_secrel_func_start_addr): Use int64_t. (sframe_fre_check_range_p): Likewise. (sframe_decoder_get_offsetof_fde_start_addr): Rename to sfde_func_start_offset. (sframe_get_funcdesc_with_addr_internal): Use int64_t. (sframe_find_fre): Likewise. (sframe_encoder_get_offsetof_fde_start_addr): Rename to sfde_func_start_offset. (sframe_encoder_add_funcdesc_internal): Use int64_t. (sframe_encoder_add_funcdesc): Likewise. And rename to sfde_func_start_offset. (sframe_encoder_write_fde): Rename to sfde_func_start_offset. libsframe/testsuite/ * libsframe.decode/DATA2: Regenerate the data file. * libsframe.encode/encode-1.c: Use int64_t for start pc offset. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. include/ * sframe-api.h (sframe_find_fre): Update arg type to int64_t. (sframe_encoder_add_funcdesc): Likewise. * sframe.h: Change data type to int64_t. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: gas: libsframe: remove padding field from FDE Remove the unused sfde_func_padding2 member from the sframe_func_desc_entry_v3 structure. A later patch in this series reorganizes the members of the FDE structure in a way explicit padding is no longer necessary to keep natural alignment. So remove the explicit padding now. Reviewed-by: Jens Remus include/ * sframe.h: Remove sfde_func_padding2 from sframe_func_desc_entry_v3. gas/ * gen-sframe.c (output_sframe_funcdesc): Stop writing sfde_func_padding2. libsframe/ * sframe.c (sframe_encoder_write_fde): Stop writing sfde_func_padding2. * testsuite/libsframe.decode/DATA2: Regenerate binary test data. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: gas: libsframe: use uint16_t for num_fres of FDE Reduce the size of the num_fres field in the Function Descriptor Entry (FDE) from 32 bits to 16 bits. The number of Frame Row Entries (FREs) for a single function is extremely unlikely to exceed 65,535 in real-world scenarios. Reducing this field saves 2 bytes per FDE, contributing to a smaller overall SFrame section size. (BTW, these savings will be eaten up by a later commit which adds support for text > 2 GiB by increasing an offset from int32_t to int64_t). Safety checks are added to the assembler to warn and skip SFrame FDE generation if a function's FRE count exceeds UINT16_MAX. Note regarding alignment: With the current patch, the members of sframe_func_desc_entry_v3 are not at aligned boundaries anymore. Recall that all sframe_func_desc_entry_v3 entries are stored together in the "SFrame FDE sub-section" forming an index. Only after a later patch in the series "[29/36] [SFrame-V3] include: gas: libsframe: split FDE into desc and attr" will the alignment properties of SFrame index will be restored. include/ * sframe.h (sframe_func_desc_entry_v3): Change sfde_func_num_fres type to uint16_t. gas/ * gen-sframe.c (output_sframe_funcdesc): Write 2 bytes for num_fres and assert it fits in uint16_t. (sframe_do_fde): Add check to skip FDE emission if num_fres exceeds UINT16_MAX. libsframe/ * sframe.c (sframe_encoder_write_fde): Cast num_fres to uint16_t to ensure correctly written out data. * testsuite/libsframe.decode/DATA2: Update binary test data. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: add V3 APIs for adding and getting SFrame FDE (Similar to V2) Add two new APIs for adding and getting SFrame FDE: - sframe_encoder_add_funcdesc_v3 - sframe_decoder_get_funcdesc_v3 Note the argument for the function start address is int64_t instead of int32_t (the latter is used in sframe_encoder_add_funcdesc_v2 and sframe_encoder_get_funcdesc_v2). The new V3 APIs will be used in a subsequent commit to extend SFrame V3 to support text > 2 GiB by allowing int64_t offsets by default. Similar to the analogous V2 APIs, they return 0 on success and SFRAME_ERR (in case of sframe_decoder_get_funcdesc_v3) or error code (in case of sframe_encoder_add_funcdesc_v3) on failure. Reviewed-by: Jens Remus include/ * sframe-api.h (sframe_decoder_get_funcdesc_v3): New declaration. (sframe_encoder_add_funcdesc_v3): Likewise. libsframe/ * libsframe.ver: Add the new APIs. * sframe.c (sframe_decoder_get_funcdesc_v3): New definition. (sframe_encoder_add_funcdesc_v3): Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: bump so version to libsframe.so.3.0.0 Consolidate the 2.0 and 2.1 nodes into a new 3.0 node. In subsequent patches for releasing SFrame V3, libsframe APIs will be affected. A non-exhaustive list of noteworthy changes are mentioned next. Some existing APIs (breaking binary compatibility) by adding an additional arg to these: - sframe_fre_get_ra_offset - sframe_fre_get_fp_offset - sframe_fre_get_cfa_offset Change of argument type: - sframe_find_fre The behaviour of some APIs will change: - sframe_encoder_write now writes out V3. And lastly removal of two APIs: - sframe_decoder_get_funcdesc - sframe_encoder_add_funcdesc Above make this release of the library binary incompatible with previous release, hence a version bump and new version node 3.0. Reviewed-by: Jens Remus libsframe/ * libsframe.ver: Create a new 3.0 node. Remove the 2.0 node. * libtool-version: Bump the so version. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: gas: bfd: ld: format bump to version 3 Bump version to SFRAME_VERSION_3. Introduce a new definition of SFrame FDE for version 3, which is a duplicate of SFrame FDE in V2, for now. In other words, no changes to the format specification yet. GNU as emits SFrame V3 by default. SFrame encoder (ld) emits SFrame V3 sections. In a later commit, we will add a new command line option to gas: --gsframe-3 which will bind the implementation in gas to emit SFrame V3. Also, adjust the testcases for the new version string "SFRAME_VERSION_3". bfd/ * elf-sframe.c (_bfd_elf_merge_section_sframe): Linker emits the latest version by default. * elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Linker emitted PLT sections are also SFRAME_VERSION_3. * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise. gas/ * gen-sframe.c (sframe_set_version): GAS emits SFrame V3 by default. (output_sframe): Likewise. libsframe/ * sframe-dump.c (dump_sframe): Enable dumping for both SFRAME_VERSION_2 and SFRAME_VERSION_3. include/ChangeLog: * sframe.h (SFRAME_VERSION_3): New definition. (SFRAME_VERSION): Current version is now SFRAME_VERSION_3. (SFRAME_V3_FDE_FUNC_INFO): New definition. (SFRAME_V3_FDE_FRE_TYPE): Likewise. (SFRAME_V3_FDE_PC_TYPE): Likewise. (SFRAME_V3_AARCH64_FDE_PAUTH_KEY): Likewise. (SFRAME_V3_FDE_UPDATE_PAUTH_KEY): Likewise. binutils/testsuite/ * all affected tests: Replace SFRAME_VERSION_2 with SFRAME_VERSION_3. gas/testsuite/ * all affected tests: Likewise. ld/testsuite/ * all affected tests: Likewise. libsframe/testsuite/ * all affected tests: Likewise. 2026-01-16 Indu Bhagat [SFrame-V3] sframe: use const for sframe_decoder_ctx object arg As the library version will be bumped soon, include this change now. Note the arg names in sframe-dump.c APIs have 'sfd_ctx' instead of the usual 'dctx'. We can address this cosmetic change at a later time. Other cosmetic changes, e.g. to make fixing function-level comments more consistent, are left out of the patch for now. Additionally, constify the return type of static function sframe_decoder_get_header, now that the call sites consistently use a const object. Reviewed-by: Jens Remus 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: remove old sframe_decoder_get_funcdesc API sframe_decoder_get_funcdesc () was added for SFRAME_VERSION_1. This has since been obsoleted by introduction of SFRAME_VERSION_2 and its corresponding sframe_decoder_get_funcdesc_v2 API. Remove from the version script file as well. We will bump the version of the library to 3.0.0 in a subsequent patch (closer to release) and consolidate the entries into a new LIBSFRAME_3.0 node. Reviewed-by: Jens Remus include/ * sframe-api.h (sframe_decoder_get_funcdesc): Remove. libsframe/ * libsframe.ver: Likewise. * sframe.c (sframe_decoder_get_funcdesc): Remove definition. 2026-01-16 Indu Bhagat [SFrame-V3] libsframe: testsuite: add a new test for SFrame V2 The existing frecnt-2.c testcase reads the SFrame section from the provided DATA2 buffer. It exercises the sframe_decode (), sframe_decoder_get_num_fidx (), and sframe_decoder_get_funcdesc_v2 () APIs. Currently DATA2 file is the SFrame section created from the test input (mentioned in the comments in the file) in SFrame version 2 format. Moving forward, creating SFrame V2 section via GNU assembler and GNU ld will not be supported. But textual dump of SFrame V2 sections via readelf/objdump will need to be supported. Add a test similar to frecnt-2.c using SFrame version 2 binary data to the libsframe testsuite. Such a test will help ensure that sframe_decode () and related APIs remain tested for multiple supported arches till the support for dumping V2 sections is to be maintained. Duplicate frecnt-2.c to create a frecnt-v2.c, the latter will test with a SFrame V2 input section always. Reviewed-by: Jens Remus libsframe/ * Makefile.in: Regenerated. libsframe/testsuite/ * libsframe.decode/decode.exp: Add new test. * libsframe.decode/local.mk: Likewise * libsframe.decode/DATA-V2: New SFrame V2 test data file. * libsframe.decode/frecnt-v2.c: New test. 2026-01-16 Indu Bhagat [SFrame-V3] readelf: testsuite: sframe: add new SFrame V2 test In subsequent commits, we will add support for SFrame V3. In the next GNU Binutils release, GNU as and ld will only generate SFrame V3; SFrame V2 will not be supported for generation nor linking. For readelf/objdump, however, continue to support textual dump of SFrame V2 sections. Add a binary file (with no debug data) with SFrame V2 section to keep the dumping tested. Add ET_REL And ET_EXEC binary file based tests for x86_64 and s390x. Check that both readelf and objdump works on the SFrame V2 sections. binutils/testsuite/ * binutils-all/s390/README-sframe-tests: New test. * binutils-all/s390/sframe.exp: New test. * binutils-all/s390/test-v2-ET_EXEC.sframe.bz2: New test. * binutils-all/s390/test-v2-ET_EXEC.sframe.dump: New test. * binutils-all/s390/test-v2-ET_REL.sframe.bz2: New test. * binutils-all/s390/test-v2-ET_REL.sframe.dump: New test. * binutils-all/x86-64/README-sframe-tests: New test. * binutils-all/x86-64/sframe.exp: New test. * binutils-all/x86-64/test-v2-ET_EXEC.sframe.bz2: New test. * binutils-all/x86-64/test-v2-ET_EXEC.sframe.dump: New test. * binutils-all/x86-64/test-v2-ET_REL.sframe.bz2: New test. * binutils-all/x86-64/test-v2-ET_REL.sframe.dump: New test. 2026-01-16 GDB Administrator Automatic date update in version.in 2026-01-15 Simon Marchi gdb/NEWS: mention DWP v1 support removal Support for DWP v1 was removed in commit 92a222b648d ("gdb/dwarf: remove support for DWP v1"). Change-Id: I6ce341bb6a2238b434fb458b3e2aa81db74cd8ae Approved-By: Eli Zaretskii 2026-01-15 Simon Marchi gdb/NEWS: add missing newline Change-Id: Ib3714d1b75d42580460f5e4183d7801314aa4b9a 2026-01-15 Tom Tromey Apply [noreturn] in more places I looked at adding -Wmissing-noreturn to the warning flags. This resulted in too many false reports, IMO, so I am not planning to submit it. However, it did point out a few spots that legitimately should have [[noreturn]]. In making this patch, my criterion was to mark up a function whose contract is that it always throws an exception. I did not include functions that just happen to always throw (e.g., default_infcall_mmap). That is, this patch uses the attribute as a form of documentation and not really for its code-generation application. Tested by rebuilding. Approved-By: Simon Marchi 2026-01-15 Simon Marchi gdb/dwarf: fix mis-indented lines in dwarf2/read.c Change-Id: I4070a60531d396237afa298bbaf6482004f3ab39 2026-01-15 Simon Marchi gdb, gdbsupport, gdbserver: add support for printf 't' length modifier Tom de Vries reported [1] that a use of the `t` printf length modifier (used for ptrdiff_t) breaks "set debug dwarf-die 1": +break -qualified main Reading Reading compcomp unit at offset unit at offset 0x00x39 Reading comp unit at offset 0x1a8 Reading comp unit at offset 0x1e9 Reading comp unit at offset 0x2c5 Reading comp unit at offset 0x2a2 Reading comp unit at offset 0x904 Unrecognized format specifier 't' in printf This use is in dwarf2/read.c: gdb_printf (gdb_stdlog, "Read die from %s@0x%tx of %s:\n", m_die_section->get_name (), (begin_info_ptr - m_die_section->buffer), bfd_get_filename (m_abfd)); Add support for the `t` length modifier in format_pieces, which gdb_printf ultimately uses (through ui_out::vmessage). Modify the three users of format_pieces: gdb's printf command, gdb's ui_out::vmessage function and gdbserver's ax_printf function. The implementation is mostly copied from what we do for size_t. Since format_pieces is also used to implement the printf command, this patch brings user-visible changes. Before: (gdb) printf "%td\n", -123 ❌️ Unrecognized format specifier 't' in printf After: (gdb) printf "%td\n", -123 -123 [1] https://inbox.sourceware.org/gdb-patches/d4ccce34-aad5-4e3d-8fc9-efb2fc11275c@suse.de/ Change-Id: Ie9fce78f5f48082d8f8a9ca2847b5ae26acaa60d Approved-By: Tom Tromey 2026-01-15 Andrew Burgess gdb/Makefile: update HFILES_NO_SRCDIR The HFILES_NO_SRCDIR in our Makefile has gotten a little out of date. The files: expanded-symbol.h, finish-thread-state.h, and nat/amd64-linux.h are missing, and there are a few files that are in the list twice. This commit adds the missing files and removes the duplicates. There should be no changes to a built GDB after this commit. Approved-By: Tom Tromey 2026-01-15 Andrew Burgess gdb: fix handling of raw ANSI escape sequences printed from Python Bug PR gdb/33748 reports a regression with print styled output from Python when using ANSI escape sequences to apply the styling. This regression was introduced by commit: commit 3825c972a636852600b47c242826313f4b9963b8 Date: Wed Jun 18 15:02:29 2025 +0100 gdb: allow gdb.Color to work correctly with pagination Prior to this commit GDB would always forward any ANSI escape sequences directly to the output stream, but this meant that GDB didn't know which style was currently in effect. The above commit changed GDB so that we would parse the ANSI escape sequence, and then apply it to the output stream, this allowed GDB to track which style was in use, which in turn meant that GDB could correctly suspend the style and reapply it when the pager was activated. The problem though is that ANSI escape sequences can be built up in parts. For example, a user can emit the sequence to change the foreground blue, and then later emit the sequence to change the text to bold. The result is output that is both blue and bold. In the above commit, when parsing an incoming ANSI sequence, GDB was always starting from the default styling state. The result of parsing the ANSI sequence was then being applied. In our above example, this meant that when parsing the sequence for bold text we would "forget" that the current style had a blue foreground color. This can be easily fixed by starting from the current style, rather than the default style. This fix was suggested by Patryk Sondej who originally reported the bug. Co-Authored-By: Patryk Sondej Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33748 Approved-By: Tom Tromey 2026-01-15 Tom Tromey Remove extraneous 'return' This 'return' comes after a call to a 'noreturn' function, and can be removed. I am not sure exactly what is up with the comment, but perhaps there was a time when 'error' was not marked this way. 2026-01-15 Simon Marchi gdb/dwarf: merge create_dwo_unit_in_dwp_{v2,v5} create_dwo_unit_in_dwp_v2 and create_dwo_unit_in_dwp_v5 are very similar. Merge them into a common create_dwo_unit_in_dwp function, with a few conditionals for what differs. This makes it easier to spot the differences between the two paths, and it's less code to maintain. Change-Id: I71c44b827fff3d4c8214a075a397a852a38d1cf9 Reviewed-By: Tom Tromey 2026-01-15 Simon Marchi gdb/dwarf: remove v2 and v5 section pool structures variants The two variants of section_pool are identical, except the size of the section_ids array. We can have only one, we just need to ensure that it is large enough for v5. And then I think that the "section_pool" struct is unnecessary, we can have the fields directly in dwp_hash_table. Change-Id: I70167a95ff61ff668c09c7e19568ced2798fa6f3 Reviewed-By: Tom Tromey 2026-01-15 Simon Marchi gdb/dwarf: cleanup dwarf2_locate_v{2,5}_dwp_sections parameters Change the `void *` parameter to `dwp_file *`. Remove the unused `abfd` parameter. These were probably missed when converting the caller from bfd_map_over_sections to gdb_bfd_sections. Change-Id: I0420c83ba35ae304901b9e140584ebaba31f2330 Approved-By: Tom Tromey 2026-01-15 Simon Marchi gdb/dwarf: remove support for DWP v1 The GCC wiki [1] says that version 1 of the DWP format "was an experimental version that is no longer supported". That comment was written in 2013. From what I understand, DWP version 1 was not widely adopted. Unlike version 2 and version 5 (which is part of DWARF 5). I propose to get rid of v1 support, which allows removing a bit of code, making things a bit easier when reasoning about DWARF code. [1] https://gcc.gnu.org/wiki/DebugFissionDWP Change-Id: Ie46b55662e63b7f341b7827330154ec4ab5af9e5 Approved-By: Tom Tromey 2026-01-15 Simon Marchi gdb/dwarf: initialize fields of virtual_v2_or_v5_dwo_sections I noticed that create_dwo_unit_in_dwp_v2 and create_dwo_unit_in_dwp_v5 initialized structure virtual_v2_or_v5_dwo_sections differently, one with a memset and one with default initialization. Make that consistent by moving the initialization in the struct itself, which is less error-prone anyway. Change-Id: I48a21a871601d076bbeeb19befd0ad62e9ba7f2a Approved-By: Tom Tromey 2026-01-15 Kito Cheng RISC-V: Add second-pass relaxation for JAL to C.J/C.JAL When linker relaxation converts CALL (auipc+jalr, 8 bytes) to JAL (4 bytes), further relaxation to C.J or C.JAL (2 bytes) may become possible as code shrinks and jump distances decrease. This patch adds _bfd_riscv_relax_jal to perform this second-pass relaxation. To enable this, we introduce R_RISCV_DELETE_AND_RELAX, a new internal relocation that combines piecewise deletion with preservation of relaxation capability. When _bfd_riscv_relax_call relaxes CALL to JAL, it marks the deletion as R_RISCV_DELETE_AND_RELAX instead of R_RISCV_DELETE. After the piecewise deletion is resolved, R_RISCV_DELETE_AND_RELAX is converted back to R_RISCV_RELAX at the JAL instruction offset, allowing _bfd_riscv_relax_jal to further relax JAL to C.J/C.JAL. C.JAL is only available on RV32 (rd=ra), while C.J is available on both RV32 and RV64 (rd=x0). Changes since v1: - Use R_RISCV_DELETE_AND_RELAX with piecewise deletion instead of calling _riscv_relax_delete_immediate directly, to maintain relaxation performance. - Add preserve_relax parameter to riscv_relax_delete_bytes to simplify the logic in _bfd_riscv_relax_call. 2026-01-15 Maciej W. Rozycki MIPS/BFD: Initialize `error_message' in `_bfd_mips_elf_orphan_shr16_reloc' There is no value assigned in `_bfd_mips_elf_generic_reloc' via the `error_message' parameter and consequently the original `error_message' variable in `_bfd_mips_elf_orphan_shr16_reloc' remains uninitialized in the error case, which newer versions of GCC can correctly diagnose: In function '_bfd_mips_elf_orphan_shr16_reloc', inlined from 'mips_elf_free_hi16_list' at ../../binutils-gdb/bfd/elfxx-mips.c:13309:12: ../../binutils-gdb/bfd/elfxx-mips.c:13281:5: error: 'error_message' may be used uninitialized [-Werror=maybe-uninitialized] 13281 | _bfd_link_reloc_status_error (abfd, info, hi->input_section, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13282 | &hi->rel, error_message, r); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../binutils-gdb/bfd/elfxx-mips.c: In function 'mips_elf_free_hi16_list': ../../binutils-gdb/bfd/elfxx-mips.c:13255:9: note: 'error_message' declared here 13255 | char *error_message; | ^~~~~~~~~~~~~ cc1: all warnings being treated as errors Fix the problem by preinitializing the variable to NULL as at other places. 2026-01-15 GDB Administrator Automatic date update in version.in 2026-01-14 Alan Modra Move mips_hi16_list to mips_elf_section_data This patch is in response to fuzzing testcases that manage to cause segfaults due to stale references to freed memory via mips_hi16.data. A number of the error/warning handlers in ldmain.c use %C. This can cause debug info to be parsed for the first time in order to print file/function/line. If one of those warnings is triggered after some hi16 relocs have been processed but before the matching lo16 reloc is handled, *and* the debug info is corrupted with a lo16 reloc, then the mips_hi16_list will be flushed with the result that printing a warning changes linker output. It is also possible that corrupted debug info adds to the hi16 list, with the result that when the linker handles a later lo16 reloc in a text section, ld will segfault accessing mips_hi16.data after the debug buffers have be freed. Both of these problems are fixed by keeping a per-section mips_hi16_list rather than a per-file list. * elfxx-mips.c (struct mips_hi16): Move earlier, deleting input_section field. (struct _mips_elf_section_data): Add mips_hi16_list. (struct mips_elf_obj_tdata): Delete mips_hi16_list. (_bfd_mips_elf_free_cached_info): Adjust to suit new location of mips_hi16_list. (_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc): Likewise. (_bfd_mips_elf_orphan_shr16_reloc): Likewise. (mips_elf_free_hi16_list): Likewise. (_bfd_mips_elf_finalize_section_relocs): Likewise. (_bfd_elf_mips_get_relocated_section_contents): Likewise. 2026-01-14 Maciej W. Rozycki MIPS: Add tests for orphan REL HI16 relocation addend processing Add GAS and LD test cases for orphan REL HI16 relocation processing, including verification of the addends produced as well as the warning messages expected. Due to the ordering used for the list of oustanding cached HI16 reloc entries warnings for non-ELF links are issued in the reverse order compared to one for ELF links. This is not considered a defect as all the required warnings are produced in both cases, however separate warning lists are required and included here for ELF and srec output. 2026-01-14 Maciej W. Rozycki MIPS/BFD: Fix howto orphan REL HI16 relocation addend processing Correct the addend being ignored for orphan REL HI16 relocations. For assembly and non-ELF links `_bfd_mips_elf_hi16_reloc' is called from `bfd_install_relocation' and `bfd_perform_relocation' respectively via the respective howtos. It caches the relocation for later processing as `_bfd_mips_elf_lo16_reloc' is called via the corresponding LO16 reloc's howto, at which point both the HI16 and the LO16 parts are calculated and installed. If no matching LO16 relocation has been later encountered, then the cached entry is never processed, with the outstanding cached entries silently dropped at the conclusion of processing, resulting in zero addend being used for the field relocated. Dropping of the entries only happens in `_bfd_mips_elf_free_cached_info' at the time the BFD is being successfully closed and section contents long written to output. For non-ELF links dropping will also execute in `_bfd_elf_mips_get_relocated_section_contents' via a separate piece of code if the function has encountered an error. Address the issues first by factoring out code to process outstanding cached entries to `mips_elf_free_hi16_list' and then by making the function actually install the relocations cached as required. This has to happen before section contents have been written and therefore the success path wires the function call to `bfd_finalize_section_relocs', for assembly and `_bfd_elf_mips_get_relocated_section_contents' for non-ELF links. For housekeeping purposes the latter call will just drop cached entries as it happens now in the case of an error, and likewise the call from `_bfd_mips_elf_free_cached_info' is retained in case a fatal error in the assembler prevents `bfd_finalize_section_relocs' from being called. This also results in a warning being issued now about orphan REL HI16 relocations encountered in non-ELF links. Previously no such warning was produced since the cached entries were dropped. For assembly we expect the tool to have issued its own warning, so we process orphan relocations silently if successful, but still issue a warning if an error is returned. We are careful in `mips_elf_free_hi16_list' to retain any incoming BFD error as the function may be called under an error condition and if there's another failure in processing at this stage we don't want to clobber the original error. Test cases will be added with a separate change. 2026-01-14 Maciej W. Rozycki MIPS/BFD: Fix ELF link orphan REL HI16 relocation addend processing Correct the addend being ignored for orphan REL HI16 relocations. For ELF links `_bfd_mips_elf_relocate_section' handles relocation and uses `mips_elf_add_lo16_rel_addend' to shift the incoming HI16 in-place addend into its intended [31:16] bit positions and combine it with the LO16 part. If no matching LO16 reloc has been found, then the function returns early and consequently the incoming HI16 addend is not shifted and remains in bits [0:15]. For final links any value of the symbol referred is then added. Then the final value is shifted back into bits [0:15] for installation into the field relocated. It is obviously wrong as the original HI16 in-place addend has now been lost. Fix the issue by shifting the incoming HI16 in-place addend before using `mips_elf_next_relocation' to find the matching LO16 relocation. Then upon early return from `mips_elf_add_lo16_rel_addend' the addend is in the intended [31:16] bit positions already. Test cases will be added with a separate change. 2026-01-14 Maciej W. Rozycki MIPS/BFD: Standardize orphan REL HI16 relocation warning Use the warning callback for the orphan REL HI16 relocation warning just as with any other linker relocation processing warnings, standardizing the message format and providing source location where available. Test cases will be added with a separate change. 2026-01-14 Maciej W. Rozycki MIPS/GAS: Warn about unmatched REL HI16 relocations Ever since commit 749b8d9d455c ("PATCH: ld/4208: `final link failed: Bad value' when building Linux MIPS kernels."), which went in back in 2007, , we've been warning about unmatched HI16 REL relocations in the linker, as it has been concluded in the discussion on PR ld/4208 that we have no need to be forgiving about compiler bugs that lead to object files to be made that are not compliant with the psABI. However no corresponding update has ever been made to GAS, despite that it's always helpful to issue a warning as early as possible in the build process. In this particular case GAS also has more information to hand as it always has the full original addend available that has been used for both the high-part and the low-part relocation, while the linker has to rely on the in-place value stored in the relocatable field by earlier processing, which has necessarily been truncated. Therefore the linker may miss cases where unrelated high-part and low-part relocations have been put next to each other that had significantly different addends at assembly time (small differences are deliberately permitted where they are known not to affect any borrow from the high part). Additionally GAS is able to point at the exact place in sources where any offending orphan relocations have been used. Update GAS to issue the warning then where applicable and remove an old comment referring to GCC producing orphan HI16 relocations. Test cases will be added with a separate change. 2026-01-14 Maciej W. Rozycki BFD: Make `bfd_finalize_section_relocs' return status Update `bfd_finalize_section_relocs' to return status so that backends can fail in this interface and propagate that to the respective callers. Add suitable error reporting there. No failure cases in the existing handlers though. 2026-01-14 Maciej W. Rozycki BFD: Rename `*_set_reloc' to `*_finalize_section_relocs' The `*_set_reloc' interface is to be called at the conclusion of section relocation processing, however its name reflects a particular action to take rather than the context of invocation. Implementation is already backend-specific. Rename the interface such as not to make its name artificially limit the intended purpose. Update the callers and documentation accordingly. No functional change. 2026-01-14 Maciej W. Rozycki GAS: Unify code for SET_SECTION_RELOCS call Fold a separate call to `bfd_set_reloc' into SET_SECTION_RELOCS itself, so that the GAS interface to this facility is contained in a single invocation. Currently both `write_relocs' and `obj_mach_o_reorder_section_relocs' call `bfd_set_reloc', causing the function to be called twice by Mach-O targets, such as `i386-darwin', once before target-specific processing and again afterwards, which is at the very least fragile in terms of assuming that any actions made by the function on the first invocation won't interfere with the final intended result. Set the macro by default to a plain call to `bfd_set_reloc', letting backends override the macro, with the requirement now to factor in a call to said function at the appropriate time. Backends can choose whether to call `bfd_set_reloc' first (such as COFF), or last (such as Mach-O), or at any other point in relation to their own additional actions. Update the COFF variant accordingly, moving it to a new function for a better code structure, retaining functionality. This is in preparation for `bfd_set_reloc' to return an error status. 2026-01-14 Tom de Vries [gdb/testsuite] Speed up gdb.base/tls-dlobj.exp In test-case gdb.base/tls-dlobj.exp we use breakpoints to step through the executable. The breakpoints are used only once, but they are permanent, so we end up with 11 breakpoints, 10 of which of the form $srcfile:$n. The executable loads and unloads shared libraries, triggering solib events in gdb, which will re-set the breakpoints. Setting a breakpoint of the form $srcfile:$n triggers a filename search that iterates over all CUs in all objfiles for which we have debuginfo. In case glibc debuginfo is installed, and in case we have a slow gdb, for instance because of building with -O0 and Address Sanitizer, this might become noticeable. While it's a good idea to try to speed up this search (see for instance PR33781), measuring this speed is not the point of this test-case, so fix this by making the breakpoints temporary. Tested on x86_64-linux. Approved-by: Kevin Buettner 2026-01-14 Jan Vrany gdb/jit: add function symbols to global block While playing with JIT reader I realized that it is not possible to set a breakpoint on jitted function: (gdb) b jit_function_stack_mangle Function "jit_function_stack_mangle" not defined. Make breakpoint pending on future shared library load? (y or [n]) The problem is that symbols for jitted functions (jit_function_stack_mangle in the above example) are not added to jitted compunit's global block: (gdb) maint print symtabs ... Symtab for file at 0x55d6f8c186c0 Read from object file << JIT compiled code at 0x5555555592a0 >> (0x55d6f8cd4090) Language: unknown Line table: line 1 at 0x7ffff7fbc000 (stmt) line 0 at 0x7ffff7fbc001 (stmt) Blockvector: block #000, object at 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011 block #001, object at 0x55d6f8c18910 under 0x55d6f8c188b0, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011 block #002, object at 0x55d6f8c18730 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle block #003, object at 0x55d6f8c187f0 under 0x55d6f8c18910, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add This commit changes JIT reader to add jitted functions to the global block: ... Blockvector: block #000, object at 0x55ed6665b180, 2 symbols in 0x7ffff7fbc000..0x7ffff7fbc011 void jit_function_stack_mangle(); block object 0x55ed6665b000, 0x7ffff7fbc000..0x7ffff7fbc00a void jit_function_add(); block object 0x55ed6665b0c0, 0x7ffff7fbc00a..0x7ffff7fbc011 block #001, object at 0x55ed6665b230 under 0x55ed6665b180, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc011 block #002, object at 0x55ed6665b000 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc000..0x7ffff7fbc00a, function jit_function_stack_mangle block #003, object at 0x55ed6665b0c0 under 0x55ed6665b230, 0 symbols in 0x7ffff7fbc00a..0x7ffff7fbc011, function jit_function_add Approved-By: Tom Tromey 2026-01-14 Jens Remus gas: sframe: simplify get_offset_size_in_bytes Type offsetT is either defined as signed 32-bit or 64-bit integer depending on whether BFD64 is defined. Do not test for whether an offsetT value exceeds INT32_MIN..INT32_MAX for !BFD64 32-bit offsetT (or INT64_MIN..INT64_MAX for BFD64 64-bit offsetT). This is always true and may result in a compile error when using compiler option -Werror=type-limits, such as the one resolved with commit 6b8fb74a9403 ("gas: sframe: do not test whether offsetT exceeds INT64_MIN..INT64_MAX") for BFD64 64-bit offsetT: ../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’: ../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits] 213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN)) | ^~ ../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits] 213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN)) | ^~ Instead of testing for whether the value is in range of INT8_MIN..INT8_MAX, INT16_MIN..INT16_MAX, or INT32_MIN..INT32_MAX, test whether the value is unchanged when casted to int8_t, int16_t, or int32_t. This also improves readability. gas/ * gen-sframe.c (get_offset_size_in_bytes): Simplify. Do not test whether !BFD64 32-bit offsetT exceeds INT32_MIN..INT32_MAX. Fixes: 58008ed4e6af ("gas: sframe: use standard min/max integer constants") Suggested-by: Jan Beulich 2026-01-14 Matthieu Longo py-gdb-readline: replace deprecated interfaces in GdbRemoveReadlineFinder A previous patch [1] enabled readline in Python in a GDB-specific way and blocked the standard Python readline module to prevent conflicts with GDB by adding a custom importer raising an exception for the readline module. This custom importer was written back in 2012 for old Python versions, and does not seem to work anymore with Python 3.x. find_module() and load_module() have been deprecated since Python 3.4, and the first one has been removed since 3.12, and the second will be removed in 3.15. The GDB testsuite does not cover this use case, and the removal of find_module() was not detected by the testsuite. This issue is tracked in bug 32473. importlib.abc.MetaPathFinder: find_module(fullname, path) Deprecated since version 3.4: Use find_spec() instead. Changed in version 3.10: Use of find_module() by the import system now raises ImportWarning. Changed in version 3.12: find_module() has been removed. Use find_spec() instead. find_spec(fullname, path, target=None) New in version 3.4, as a replacement for find_module. importlib.abc.Loader: load_module(fullname): Deprecated since version 3.4, will be removed in version 3.15 The recommended API for loading a module is exec_module() (and create_module()). This patch uses Patryk Sondej's approach detailed in bug 32473, but with a slight variation regarding the finder insertion in sys.meta_path. It also adds a new test to prevent future regression. [1]: 037bbc8eeaf8e6f3a5e185e78268aa71a1159ae7 Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32473 2026-01-14 Nelson Chu MAINTAINERS: Update my email address 2026-01-14 GDB Administrator Automatic date update in version.in 2026-01-13 H.J. Lu elf: Handle the section flag 'o' linked to special sections Call _bfd_elf_section_from_bfd_section to get the sh_link value from the section flag 'o' directive, which may point to special sections, like SHN_ABS or SHN_COMM. Update readelf to print the special section names in the sh_link field and replace "internal->sh_link > num" with "internal->sh_link >= num". bfd/ PR gas/33744 * elf.c (assign_section_numbers): Call _bfd_elf_section_from_bfd_section to get the sh_link value. binutils/ PR gas/33744 * readelf.c (special_defined_section_index): New. (get_32bit_section_headers): Don't warn special section indexes in the sh_link field. (get_64bit_section_headers): Likewise. (process_section_headers): Print special defined section names. gas/ PR gas/33744 * testsuite/gas/elf/elf.exp: Run PR gas/33744 tests. * testsuite/gas/elf/sh-link-abs-1.d: New file. * testsuite/gas/elf/sh-link-abs-2.d: Likewise. * testsuite/gas/elf/sh-link-abs-3-32.d: Likewise. * testsuite/gas/elf/sh-link-abs-3-64.d: Likewise. * testsuite/gas/elf/sh-link-abs-4-32.d: Likewise. * testsuite/gas/elf/sh-link-abs-4-64.d: Likewise. * testsuite/gas/elf/sh-link-abs.s: Likewise. * testsuite/gas/elf/sh-link-common-1.d: Likewise. * testsuite/gas/elf/sh-link-common-2.d: Likewise. * testsuite/gas/elf/sh-link-common-3-32.d: Likewise. * testsuite/gas/elf/sh-link-common-3-64.d: Likewise. * testsuite/gas/elf/sh-link-common-4-32.d: Likewise. * testsuite/gas/elf/sh-link-common-4-64.d: Likewise. * testsuite/gas/elf/sh-link-common.s: Likewise. * testsuite/gas/elf/sh-link-large-common-1.d: Likewise. * testsuite/gas/elf/sh-link-large-common-2.d: Likewise. * testsuite/gas/elf/sh-link-large-common-3.d: Likewise. * testsuite/gas/elf/sh-link-large-common-4.d: Likewise. * testsuite/gas/elf/sh-link-large-common.s: Likewise. 2026-01-13 Jens Remus gas: sframe: do not test whether offsetT exceeds INT64_MIN..INT64_MAX A value of type offsetT, which is either a signed 32-bit or 64-bit integer, cannot exceed the range of INT64_MIN..INT64_MAX. This resolves the following compile error: ../../binutils-gdb/gas/gen-sframe.c: In function ‘get_offset_size_in_bytes’: ../../binutils-gdb/gas/gen-sframe.c:213:45: error: comparison is always true due to limited range of data type [-Werror=type-limits] 213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN)) | ^~ ../../binutils-gdb/gas/gen-sframe.c:213:67: error: comparison is always true due to limited range of data type [-Werror=type-limits] 213 | else if ((sizeof (offsetT) > 4) && (value <= INT64_MAX && value >= INT64_MIN)) | ^~ Fixes: 58008ed4e6af ("gas: sframe: use standard min/max integer constants") 2026-01-13 Jens Remus gas: sframe: use standard min/max integer constants Replace the use of custom VALUE_{8|16|32|64}BIT constant definitions with the standard INT{8|16|32|64}_{MIN|MAX} ones from stdint.h. Besides improving readability this also fixes the issue that the smallest representable signed 8/16/32-bit integer value was erroneously sized as the next larger integer type. For example get_offset_size_in_bytes (INT8_MIN) returned 2 instead of 1, due to INT8_MIN (= -128) != -VALUE_8BIT (= -127): (gdb) call get_offset_size_in_bytes (-127) $1 = 1 (gdb) call get_offset_size_in_bytes (-128) $2 = 2 gas/ * gen-sframe.c (VALUE_8BIT, VALUE_16BIT, VALUE_32BIT, VALUE_64BIT): Remove. (get_offset_size_in_bytes): Use standard min/max integer constants. 2026-01-13 Andrew Burgess gdb: yet more miscellaneous styling fixes The previous patch was all about address styling, but I spotted some non-address styling that was missing. This patch covers those cases. There's function name styling for the 'jump' command, and line number, and function name styling for 'maint print symbols'. Other than the extra styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-13 Andrew Burgess gdb: more address styling throughout I looked for the pattern 'gdb_puts (paddress (', these are places in GDB where we are printing a target address without styling. I changed most of what I found to print the address as styled. I did leave a few unchanged in psymtab.c, these are all in maintenance commands 'maint print psymbols', 'maint info psymtabs', and 'maint check psymtabs'. None of these commands appear to print anything for me (do we even use partial symtabs these days? I thought not) so I didn't want to mess with commands that I couldn't test. Other than the additional styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-13 Andrew Burgess gdb: output styling, and GDB code style fixes, for 'info frame' I noticed that the output of 'info frame' was not styled much; the frame's filename is styled, as are the names of any frame local variables. But there's lots of address and line number styling missing. When I started looking at the info_frame_command_core function though, there were lots of coding standard changes that could be made too, so while I was in the area I thought I'd make some coding standard changes to the function: + Inlined local variable declarations. + Removed the 'caller_pc_p' local, and made 'caller_pc' a std::optional instead. + Converted a local from 'int' to 'bool'. + Replaced NULL with nullptr. + Replaced calls to gdb_printf with gdb_puts when the thing to print is a constant string. + Added { ... } around if/else bodies that are a single statement AND a comment inline with GDB coding style. + Avoid treating pointers and integers as booleans in 'if' conditions. Compare to nullptr and/or zero instead. Other than the new styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-13 Andreas Schwab gas/riscv: Fix grammar in error messages objcopy: Set bfd_error_system_call before reporting error from make_tempname readelf: Handle R_RISCV_SET32 2026-01-13 Nick Clifton Regenerate libiberty/aclocal.m4 and ld/config.in using the correct versions of the autotools 2026-01-13 Christina Schimpe gdb: Update comment of c_type_print_template_args. Remove function description for TABLE. This function does not take a parameter "table". Approved-By: Tom Tromey 2026-01-13 Abhay Kandpal PowerPC: Support for eTCE (RFC02662) opcodes/ * ppc-opc.c (XTLBIE_MASK, XTLBIEIO_MASK): New macros. (powerpc_opcodes): Add tlbiep, tlbieio, tlbsyncio, ptesyncio. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise. 2026-01-13 Abhay Kandpal PowerPC: Support for Additional Performance Monitor Counters (RFC02666) opcodes/ * ppc-opc.c (powerpc_opcodes): Add mtummcrae, mtummcr2e, mtmmcr2e, mtmmcrae, mtmmcr1e, mtmmcr3e, mtupmc7, mtupmc8, mtpmc7, mtpmc8, mfummcrae, mfmmcrae, mfummcr1e, mfmmcr1e, mfummcr2e, mfmmcr2e, mfummcr3e, mfmmcr3e, mfupmc7, mfpmc7, mfupmc8, mfpmc8. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise. 2026-01-13 Maciej W. Rozycki libiberty: sync with gcc Import the following commits from GCC as of r16-6728-g7c3584be8c8806: 07df546fb90 libiberty/testsuite: make test-pexecute's -t option a little more useful 0c775dcf3e7 libiberty: Make `objalloc_free' `free'-like WRT null pointer 2026-01-13 GDB Administrator Automatic date update in version.in 2026-01-12 H.J. Lu gas: Check @@@ before renaming the versioned symbol The versioned symbol with the @@@ syntax is a special case. If the symbol is not defined, 2 `@'s will be removed from the versioned_name. Otherwise, 1 `@' will be removed. But for malformed versioned symbols may not have @@@: .symver foo,foo@@@version1 .symver foo,foo@version2 Check @@@ before renaming the versioned symbol. PR gas/33745 * config/obj-elf.c (elf_frob_file_before_adjust): Check @@@ before renaming the versioned symbol. * testsuite/gas/symver/symver.exp: Run symver17. * testsuite/gas/symver/symver17.l: New file. * testsuite/gas/symver/symver17.s: Likewise. 2026-01-12 Jan Vrany gdb/testsuite: fix DUPLICATE in call-sc.exp With test-case gdb.base/call-sc.exp I get: DUPLICATE: gdb.base/call-sc.exp: tc: ptype; call-sc-tc (char) DUPLICATE: gdb.base/call-sc.exp: ts: ptype; call-sc-ts (short) DUPLICATE: gdb.base/call-sc.exp: ti: ptype; call-sc-ti (int) ... Fix this by changing test name in testcase added in commit be90f3e2. Tested on x86_64-linux. Approved-By: Tom de Vries 2026-01-12 Simon Marchi gdb/dwarf: make dwarf2_per_cu size fields atomic Make m_addr_size, m_offset_size, and m_ref_addr_size use std::atomic. Multiple indexer threads may set these values concurrently, which currently causes a TSan failure: WARNING: ThreadSanitizer: data race (pid=1535364) Write of size 1 at 0xfffed1813515 by thread T1: #0 dwarf2_per_cu::set_addr_size(unsigned char) /home/vries/gdb/src/gdb/dwarf2/read.h:291 (gdb+0x98af68) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #1 cutu_reader::cutu_reader(dwarf2_per_cu&, dwarf2_per_objfile&, abbrev_table const*, dwarf2_cu*, bool, language, abbrev_table_cache const*) /home/vries/gdb/src/gdb/dwarf2/read.c:3114 (gdb+0x9472b4) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #2 std::__detail::_MakeUniq::__single_object std::make_unique(dwarf2_per_cu&, dwarf2_per_objfile&, decltype(nullptr)&&, decltype(nullptr)&&, bool&&, language&&, abbrev_table_cache const*&&) /usr/include/c++/15/bits/unique_ptr.h:1084 (gdb+0x891f98) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #3 cooked_indexer::ensure_cu_exists(cutu_reader*, section_and_offset const&, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:118 (gdb+0x88e1e8) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #4 cooked_indexer::scan_attributes(dwarf2_per_cu*, cutu_reader*, unsigned char const*, unsigned char const*, abbrev_info const*, char const**, char const**, enum_flags*, sect_offset*, cooked_index_entry const**, parent_map::addr_type*, bool*, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:316 (gdb+0x88ed1c) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #5 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, std::variant, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:539 (gdb+0x88fa50) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #6 cooked_indexer::make_index(cutu_reader*) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:718 (gdb+0x890430) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) ... Previous write of size 1 at 0xfffed1813515 by thread T4: #0 dwarf2_per_cu::set_addr_size(unsigned char) /home/vries/gdb/src/gdb/dwarf2/read.h:291 (gdb+0x98af68) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #1 cutu_reader::cutu_reader(dwarf2_per_cu&, dwarf2_per_objfile&, abbrev_table const*, dwarf2_cu*, bool, language, abbrev_table_cache const*) /home/vries/gdb/src/gdb/dwarf2/read.c:3114 (gdb+0x9472b4) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #2 std::__detail::_MakeUniq::__single_object std::make_unique(dwarf2_per_cu&, dwarf2_per_objfile&, decltype(nullptr)&&, decltype(nullptr)&&, bool&&, language&&, abbrev_table_cache const*&&) /usr/include/c++/15/bits/unique_ptr.h:1084 (gdb+0x891f98) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #3 cooked_indexer::ensure_cu_exists(cutu_reader*, section_and_offset const&, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:118 (gdb+0x88e1e8) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #4 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, abbrev_info const*) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:431 (gdb+0x88f454) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #5 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, std::variant, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:498 (gdb+0x88f770) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #6 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, abbrev_info const*) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:434 (gdb+0x88f4ac) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #7 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, std::variant, bool) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:498 (gdb+0x88f770) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) #8 cooked_indexer::make_index(cutu_reader*) /home/vries/gdb/src/gdb/dwarf2/cooked-indexer.c:718 (gdb+0x890430) (BuildId: cce1d3c72972f5759cd1746e1a001e90d7498301) ... It's fine for multiple threads to try to set these values concurrently. The only condition is that either the previous value was 0 (unset) or equals the new value being set. Change-Id: Ib13218707cefdf33a51b3246ba5773a7800463b9 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33775 Reviewed-By: Tom de Vries 2026-01-12 Jens Remus gas: Explicitly code void parameter list This fixes the following compile errors reported by Clang: CC config/obj-elf-attr.o ../../gas/config/obj-elf-attr.c:64:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 64 | oav1_attr_info_init () | ^ | void ../../gas/config/obj-elf-attr.c:74:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 74 | oav1_attr_info_exit () | ^ | void gas/ * config/obj-elf-attr.c (oav1_attr_info_init, oav1_attr_info_exit): Explicitly code void parameter list. 2026-01-12 Tom Tromey Use a map for symfile.c:symtab_fns This changes symfile.c:symtab_fns to use a map rather than a vector, letting us remove an otherwise extraneous type. Approved-By: Simon Marchi 2026-01-12 Richard Earnshaw aarch64: Don't relax relocations to static function symbols The aarch64 ABI states that long branch veneers may be added to facilitate linking code that is beyond the range of a 26-bit call or branch; but it requires that the target symbol be a function symbol. Ensure that this latter condition is maintained by rejecting relaxation of a static function symbol to it's section symbol. Note that there should probably be a fix to the linker to enforce this during link time. I've not done this for now because that might break some existing object code that has been built with older versions of gas. At some point we should revisit this. This change also causes a small change in the LD testsuite: instead of generating some veneers with the section name we now (correctly) generate them using the name of the called function. 2026-01-12 GDB Administrator Automatic date update in version.in 2026-01-11 H.J. Lu gas: Update testsuite/gas/symver/symver15.l Update testsuite/gas/symver/symver15.l to expect: Error: multiple versions [`foo@version2'|`foo@version1'] for symbol `foo' * testsuite/gas/symver/symver15.l: Expect '|'. 2026-01-11 Tom de Vries [gdbsupport] Regenerate Makefile.in The buildbot complains about an out-of-date Makefile.in. Fix this by regenerating it from Makefile.am using automake. 2026-01-11 H.J. Lu or1k: Mark undefined TLS symbol as STT_TLS Update or1k_apply_fix to handle all TLS relocations. PR gas/33426 * config/tc-or1k.c (or1k_apply_fix): Handle all TLS relocations. 2026-01-11 H.J. Lu x86: Cache the symbol table when packing relative relocations When packing relative relocations, x86 linker may load the same symbol table repeatedly, which can take a long time. On Intel Core i7-1195G7 with 32GB RAM, it takes more than 45 minutes to create an output with -pie -z pack-relative-relocs from an input with 208025 code sections. Cache the symbol table to reduce the link time to less than 2 seconds. On the same machine, creating 3.1GB clang executable in LLVM 21.1.3 debug build: user 55.39 seconds system 6.71 seconds total 65.80 seconds maximum set(GB) 10.43 page faults 2406941 PR ld/33765 * elfxx-x86.c (elf_x86_relative_reloc_record_add): Remove keep_symbuf_p. (_bfd_x86_elf_link_relax_section): Updated. Cache the symbol table to avoid loading it again. 2026-01-11 GDB Administrator Automatic date update in version.in 2026-01-10 Tom de Vries [gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp With a gdb build with -O0 and Address Sanitizer and test-case gdb.multi/sched-multi-add-inferior.exp, I get: ... FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \ continue to function1 FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \ continue to function2 FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \ continue to function1 FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \ continue to function2 FAIL: $exp: target_type_1=native: target_type_2=native: continue to function1 FAIL: $exp: target_type_1=native: target_type_2=native: continue to function2 ... In more detail, for the target_type_1 == target_type_2 == native configuration, we have: ... (gdb) continue^M Continuing.^M [Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M ^M Thread 2.1 "sched-multi-add" hit Breakpoint 4, main (...) at multi-target.c:94^M 94 function2 (); /* set break 2 here */^M (gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \ continue to function1 thread apply 2.1 set wait_for_gdb = 0^M ^M Thread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) "sched-multi-add"):^M (gdb) PASS: $exp: target_type_1=native: target_type_2=native: \ thread apply 2.1 set wait_for_gdb = 0 continue^M Continuing.^M [Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M ^M Thread 3.1 "sched-multi-add" hit Breakpoint 3, main (...) at multi-target.c:93^M 93 function1 (); /* set break 1 here */^M (gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \ continue to function2 ... The situation is as follows: - there are two inferiors - due to "set schedule-multiple on", continue continues both inferiors - after the first continue, the test-case expects the breakpoint on thread 3.1 to trigger - instead, the breakpoint in thread 2.1 triggers The mechanism by which this order is supposed to be guaranteed, is that thread 2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint: ... # Unblock thread 2.1 and continue again. This time, thread 2.1 # will hit a breakpoint. gdb_test "thread apply 2.1 set wait_for_gdb = 0" ".*" ... However, thread 2.1 is never blocked. Fix this by adding the missing: ... gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*" ... Tested on x86_64-linux. Approved-by: Kevin Buettner Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540 2026-01-10 GDB Administrator Automatic date update in version.in 2026-01-09 Simon Marchi gdb/coffread: simplify stab section detection We look for stab sections for the sole purpose of emitting a warning if we see one. Simplify this by using a boolean to indicate if we saw a stab section or not. Simplify the search to just look for sections starting with ".stab", it should be enough for this purpose. Also, remove the make_scoped_restore that would overwrite the stab section vector, I'm not sure why it's there. It seems to me like it would cause the warning to never be shown. Change-Id: I56323189ffdaa2d06a96d457cdd999b23efa5979 Approved-By: Tom Tromey 2026-01-09 Sébastien Darche gdb: update shared libraries when inferior is created, even if no bfd exists I noticed an unexpected behaviour difference when loading a core file in GDB depending on whether the main executable can be accessed or not. If GDB knows about the main executable, then symbols for unrelated libraries (such as libc) are loaded. If GDB cannot find the main executable, then they are not. Here is a reproducer using the artifacts from gdb.python/py-missing-objfile.exp. This test is ideal to reproduce the problem, because it hides from GDB the executable and library used to generate the core file. In the "good" case, where we give an executable to GDB (in addition to the core), we get a complete backtrace (assuming GDB can find debug symbols for glibc): $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.python/py-missing-objfile/hidden/py-missing-objfile -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch ... #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007fcbd0c98a13 in __pthread_kill_internal (threadid=, signo=6) at pthread_kill.c:89 #2 0x00007fcbd0c3e410 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fcbd0c2557a in __GI_abort () at abort.c:77 #4 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34 #5 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46 Or, if debug symbols for glibc aren't available, GDB at least tells us from which .so each frame comes from: #0 0x00007fcbd0c9894c in ?? () from /usr/lib/libc.so.6 #1 0x00007fcbd0c3e410 in raise () from /usr/lib/libc.so.6 #2 0x00007fcbd0c2557a in abort () from /usr/lib/libc.so.6 #3 0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34 #4 0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46 If we omit passing the main executable to GDB (and GDB has no way to find it, because the test moved it on purpose), we get: $ ./gdb -nx -q --data-directory=data-directory -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch #0 0x00007fcbd0c9894c in ?? () #1 0x0000000000000000 in ?? () Upon investigating, the "normal" path to load associated sos is through the post_create_inferior function in infcmd.c, which calls solib_create_inferior_hook. The solib_ops in turn loads the symbols by calling solib_add. When loading a core file, the list of loaded shared libraries can be found (and as we can see with `info sharedlibraries`, this is done properly). However, the current control flow handling in post_create_inferior does not ask the solib to load the symbols through solib_create_inferior_hook if a main exec_bfd is not present. The proposed change eliminates the if statement in the post_create_inferior function. This change may have side-effects on some solib_ops which may not check if the current inferior has a valid exec_bfd(). This commit also modifies the gdb.python/py-missing-objfile.exp test, providing a test case in which the main exec file is missing, but not the shared library. This is a good way to confirm this fix works, as the symbols from the shared library should be found even though the main exec file is missing. The test cases also ask GDB to clean_restart to ensure there is no leftover bfd or symbols. Furthermore, the total number of calls to the missing objfiles handler is 4 in the "all objfiles missing" test case instead of the previous 3 : - 2 for the mapped files (exec and so), in core_target_build_file_mappings - 1 for the core file exec, in locate_exec_from_corefile_build_id - 1 for the missing so, in solib_map_sections The changes in check_loaded_debug handle the case where no symbol exist at all, and also when a symbol table exists (but the symbol cannot be found) Note: Some comments in some solib_ops (frv, dbst) seem to indicate that solib_add should be called before solib_create_inferior_hook by post_create_inferior, but this does not seem to be the case anymore. Those comments might need to be updated. Change-Id: I517ff85813c941215b19fa8540c77f755a0aca28 Reviewed-By: Tankut Baris Aktemur Tested-By: Guinevere Larsen Approved-By: Simon Marchi 2026-01-09 Sébastien Darche gdb/solib-svr4: update solib when an inferior is not being executed (e.g. core files) Loading a core file currently generates a warning when enabling `set verbose on`: $ ./gdb -nx -q --data-directory=data-directory a.out -ex "set verbose on" -ex "core core.151894" -batch ... warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. The warning comes from infcmd.c:post_create_inferior() which initializes the solib_ops. The latter is in charge of calling solib_add() in its implementation of solib_ops::create_inferior_hook. The svr4_solib_ops class, however, does not call solib_add (through enable_break) if the inferior is not being executed. This patch moves the call to solib_add() outside of the conditional nested call. No user-visible change should be expected, except for fact that the warning will no longer be shown. Change-Id: I5488dc166fdc985669422a0f1c0c2f43158cd8c4 Reviewed-By: Tankut Baris Aktemur Approved-By: Simon Marchi 2026-01-09 Sébastien Darche gdb/testsuite: fix typo in gdb.python/py-missing-objfile.exp The py-missing-objfile.exp test attempts to load a core file with missing debug info and counts the number of times a python missing objfile handler is called. In one test case, the number of expected calls to the missing objfile handler is two, but the test case misleadingly says three. This commit fixes this typo. Change-Id: I421143ebed392227f14918ea529eb0e9cbd98dda Approved-By: Simon Marchi 2026-01-09 Simon Marchi gdb/coffread: remove unused fields of coff_symfile_info Change-Id: I34ae3f3ab17764d40e695a61894d155652a708dd Approved-By: Tom Tromey gdb/coffread: remove unnecessary forward declarations Change-Id: Id68fe282654a6fce316d4c58b3007a00a3a94597 Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb: remove gdbarch_ecoff_reg_to_regnum It is unused since the mdebugread removal. Change-Id: I76a2f4208f00784770dbdcb601b12282914b1cd5 Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb: remove gdbarch_stab_reg_to_regnum It is unused, presumably since we removed stab support. Change-Id: I71d00707afc4a4a23a1644b4233caaa47f4301e4 Approved-By: Tom Tromey 2026-01-09 Tom de Vries [gdb/symtab] Cache dw2_get_file_names result for dummy CU Consider function dw2_get_file_names: ... static struct quick_file_names * dw2_get_file_names (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile) { /* This should never be called for TUs. */ gdb_assert (!this_cu->is_debug_types ()); if (this_cu->files_read) return this_cu->file_names; cutu_reader reader (*this_cu, *per_objfile, nullptr, per_objfile->get_cu (this_cu), true, language_minimal, nullptr); if (!reader.is_dummy ()) dw2_get_file_names_reader (reader.cu (), reader.top_level_die ()); return this_cu->file_names; } ... If dw2_get_file_names_reader is called, the result is cached in this_cu->file_names, and this fact is tracked in this_cu->files_read, allowing subsequent calls to access the cached value. But for dummy CUs, while the result (nullptr) is cached in this_cu->file_names, this is not noted in this_cu->files_read, and consequently subsequent calls will read the top-level DIE in the CU again. Fix this by setting this_cu->files_read also for dummy CUs. Tested on x86_64-linux. Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33777 2026-01-09 Tom Tromey Show constants in DAP scopes output This changes the DAP code so that constants will now be returned by a DAP scopes request. This is perhaps slightly strange with Ada enumerators, but on the other hand this is consistent with what the CLI does. Reviewed-By: Eli Zaretskii 2026-01-09 Tom Tromey Allow DAP client to set Ada source charset at launch A co-worker reported that certain symbols weren't appearing in the DAP 'scopes' response. In particular, symbols with non-ASCII names didn't appear; though further research showed that this was in fact a result of the variable in question actually being a constant. Unfortunately Ada still requires the user to set the Ada source character set in order to properly display symbol names. For DAP, it seemed to make sense to allow this as a launch parameter. This patch implements this. Reviewed-By: Eli Zaretskii 2026-01-09 Tom Tromey Minor reorganization to DAP launch documentation This changes the DAP launch/attach documentation so that common options are called out in a separate table. Approved-By: Eli Zaretskii 2026-01-09 Tom Tromey Explicitly use print_name in DAP This changes some DAP code to explicitly use a symbol's print name. Some places were using '.name'; and while 'str' does use the print name, it seems better to be both consistent and explicit. 2026-01-09 Jan Vrany gdb: install expanded_symbols_functions into objfiles created by JIT reader This commit installs expanded_symbols_functions into objfiles created by JIT reader API. This is needed so the JIT symbols can be used just like any other symbols. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33554 Approved-By: Tom Tromey 2026-01-09 Jan Vrany gdb: introduce expanded_symbols_functions This commit adds new "quick" symbol functions, expanded_symbols_functions, that work purely on examining objfile's compunits. This is useful for example for JIT reader API where symbols are created by user-provided code. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33554 Approved-By: Tom Tromey 2026-01-09 Daniel Knezevic gdb: Make printing enum types prettier. Update printing of enum types to follow the same formatting conventions as for structs resulting in more readable output. Now that horizontal space is less of an issue enum values are always printed. Empty enums are now printed with an added "" message. Example of printing an enum with default values: enum class TestEnum {A, B, C, D}; (gdb) ptype TestEnum type = enum class TestEnum : int { TestEnum::A = 0, TestEnum::B = 1, TestEnum::C = 2, TestEnum::D = 3 } Example of printing an empty enum: enum class TestEnum {}; (gdb) ptype TestEnum type = enum class TestEnum : int { } Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19294 Approved-By: Tom Tromey 2026-01-09 Daniel Knezevic gdb: Replace \r\n with multi_line to make tests more readable Approved-By: Tom Tromey gdb: Move logic for printing enums to a helper function Approved-By: Tom Tromey gdb: Add myself to gdb/MAINTAINERS 2026-01-09 Hannes Domani Forget the last displayed sal when the referenced objfile is destroyed When creating a new line-breakpoint after rerunning with a disabled or removed breakpoint in a solib, you currently get this use-after-free crash: (gdb) break solib_main Breakpoint 1 at 0x1030 (gdb) run Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". Breakpoint 1, solib_main (arg=100) at /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/solib1.c:7 7 int ans = arg*arg; /* HERE */ (gdb) disable (gdb) set confirm off (gdb) run Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [Inferior 1 (process 50868) exited normally] (gdb) break 18 ================================================================= ==50836==ERROR: AddressSanitizer: heap-use-after-free on address 0x7d65a543d488 at pc 0x55f022334c29 bp 0x7ffe9c7f45f0 sp 0x7ffe9c7f45e0 READ of size 8 at 0x7d65a543d488 thread T0 #0 0x55f022334c28 in symtab::filename() const ../../gdb/symtab.h:1747 #1 0x55f023a32b7d in create_sals_line_offset ../../gdb/linespec.c:2013 #2 0x55f023a37937 in convert_linespec_to_sals ../../gdb/linespec.c:2294 #3 0x55f023a3cf79 in parse_linespec ../../gdb/linespec.c:2652 #4 0x55f023a415b2 in location_spec_to_sals ../../gdb/linespec.c:3050 #5 0x55f023a423b0 in decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) ../../gdb/linespec.c:3126 #6 0x55f022826e1b in parse_breakpoint_sals ../../gdb/breakpoint.c:9069 #7 0x55f0228291c2 in create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) ../../gdb/breakpoint.c:9312 #8 0x55f02282c298 in break_command_1 ../../gdb/breakpoint.c:9471 #9 0x55f02282d0bb in break_command(char const*, int) ../../gdb/breakpoint.c:9541 #10 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94 0x7d65a543d488 is located 904 bytes inside of 4064-byte region [0x7d65a543d100,0x7d65a543e0e0) freed by thread T0 here: #0 0x7f55aa91f79d in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:51 #1 0x55f0221f6403 in xfree ../../gdb/../gdbsupport/gdb-xfree.h:37 #2 0x55f027b64851 in call_freefun ../../libiberty/obstack.c:103 #3 0x55f027b66283 in _obstack_free ../../libiberty/obstack.c:280 #4 0x55f0221f7a07 in auto_obstack::~auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:126 #5 0x55f023f3dd83 in objfile::~objfile() ../../gdb/objfiles.c:509 #6 0x55f023f511d8 in std::default_delete::operator()(objfile*) const /usr/include/c++/15.2.1/bits/unique_ptr.h:93 #7 0x55f023f4b8cd in std::unique_ptr >::~unique_ptr() /usr/include/c++/15.2.1/bits/unique_ptr.h:399 #8 0x55f0240b6dab in owning_intrusive_list >::erase(intrusive_list_iterator >) ../../gdb/../gdbsupport/owning_intrusive_list.h:113 #9 0x55f0240adb68 in program_space::remove_objfile(objfile*) ../../gdb/progspace.c:202 #10 0x55f023f3cfcf in objfile::unlink() ../../gdb/objfiles.c:409 #11 0x55f023f40faf in objfile_purge_solibs(program_space*) ../../gdb/objfiles.c:687 #12 0x55f02487ec19 in no_shared_libraries(program_space*) ../../gdb/solib.c:1359 #13 0x55f024b37e1e in target_pre_inferior() ../../gdb/target.c:2474 #14 0x55f0238ac7cd in run_command_1 ../../gdb/infcmd.c:381 #15 0x55f0238ae438 in run_command ../../gdb/infcmd.c:510 #16 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94 previously allocated by thread T0 here: #0 0x7f55aa920cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67 #1 0x55f02241d780 in xmalloc ../../gdb/alloc.c:52 #2 0x55f027b6461f in call_chunkfun ../../libiberty/obstack.c:94 #3 0x55f027b649d1 in _obstack_begin_worker ../../libiberty/obstack.c:141 #4 0x55f027b650c5 in _obstack_begin ../../libiberty/obstack.c:164 #5 0x55f0221f775a in auto_obstack::auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:123 #6 0x55f023f39c91 in objfile::objfile(gdb::ref_ptr, program_space*, char const*, enum_flags) ../../gdb/objfiles.c:257 #7 0x55f023f3ccaa in objfile::make(gdb::ref_ptr, program_space*, char const*, enum_flags, objfile*) ../../gdb/objfiles.c:392 #8 0x55f02498b1d2 in symbol_file_add_with_addrs ../../gdb/symfile.c:1069 #9 0x55f02498c099 in symbol_file_add_from_bfd(gdb::ref_ptr const&, char const*, enum_flags, std::vector >*, enum_flags, objfile*) ../../gdb/symfile.c:1156 #10 0x55f02487255b in solib_read_symbols(solib&, enum_flags) ../../gdb/solib.c:660 #11 0x55f024876c0c in solib_add(char const*, int, int) ../../gdb/solib.c:993 #12 0x55f02487f1f8 in handle_solib_event() ../../gdb/solib.c:1399 #13 0x55f0227df91f in bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const&, bpstat*) ../../gdb/breakpoint.c:5962 #14 0x55f023944fa8 in handle_signal_stop ../../gdb/infrun.c:7130 #15 0x55f02393e2a1 in handle_inferior_event ../../gdb/infrun.c:6574 #16 0x55f0239279f2 in fetch_inferior_event() ../../gdb/infrun.c:4713 #17 0x55f023885fe3 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:42 #18 0x55f023af706e in handle_target_event ../../gdb/linux-nat.c:4449 #19 0x55f027c2d2f0 in handle_file_event ../../gdbsupport/event-loop.cc:551 #20 0x55f027c2e4ff in gdb_wait_for_event ../../gdbsupport/event-loop.cc:672 It happened because last_displayed_symtab_info of stack.c still contained a reference to a symtab that was already freed in the 2nd run. This fixes it by clearing last_displayed_symtab_info in the objfile destructor, if it is pointing to that objfile. Now setting of the 2nd breakpoint works: (gdb) break 18 Breakpoint 2 at 0x555555555141: file /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/so-impl-ld.c, line 18. (gdb) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32668 Reviewed-By: Guinevere Larsen Approved-By: Simon Marchi 2026-01-09 Richard Earnshaw aarch64: Fix out-of-range branch veneers when --fix-cortex-a53-843419 The erratum mitigation support for the Cortex-A53 843419 erratum inserts a new stub for every possible instance of the erratum. Since each stub ends up inserting 4k of space into the binary, in order to avoid perturbing the alignment of other potential erratum sequences we can end up adding substantially more space than the distance to the next long-branch stub that we've prepared for. The problem is, fundamentally a phase ordering problem, but that's easily resolvable by running the 843419 erratum pass first and then creating the stub groups once that is done. In this way we take into account the additional padding when forming the groups to ensure that they remain within range. 2026-01-09 Richard Earnshaw aarch64: Use section names for empty stub symbols If the target symbol for a stub was empty we would previously end up using an anonymous stub name of the form ___veneer. To make things a little clearer use the section symbol for the target section in this case. We now end up with veneer symbols like __.text_veneer. Adjusted the tests accordingly. 2026-01-09 Jan Beulich x86: optimize MOVZX in a few cases There are shorter encoding options available, so space optimization is possible. x86: optimize MOVSX between accumulator regs Except on the K6 CBW/CWDE/CDQE perform equally well, but are shorter to encode. bfd: avoid elf-properties.c for ELF-free targets It is absurd to build this file when it's not possibly used. Move its references to where other elf-*.* are and introduce a compiler define (paralleling what gas uses, as having the same purpose) to isolate out ELF-specific pieces in compress.c (which is where the references into elf-properties.c are coming from). ELF: give .note.GNU-stack proper section type Like all .note and .note.* sections it should be SHT_NOTE, not SHT_PROGBITS. 2026-01-09 Jan Beulich ld/ELF: suppress note section rearrangement for relocatable linking Input sections would generally best retain their order from in the input(s) or relocatable links. In particular the (odd) sorting of note sections by alignment is entirely unnecessary there, and could potentially even be harmful. Simply accumulate orphan sections in the order observed. Of course this has an effect on section order, so a few testsuite adjustments are necessary. The test for PR ld/27590 is being relaxed, as it's no clear why sh_link fields would need to have exact expectations when at the same time section numbers aren't matched. (Obviously the .rela sections should match their corresponding data sections', but afaict this cannot be [easily] expressed.) Xstormy16 XFAILs for a few tests can be dropped as the sections of interest there are orphan ones, and hence now are placed independent of the linker scripts unusual placing of .data ahead of .text. 2026-01-09 Simon Marchi gdb/xcoffread: stylistic cleanup Do a few cleanups: - declaring variables where they are used - rename functions to be more precise - add explicit comparison against nullptr or 0 - remove struct/union keywords - remove or update outdated comments Change-Id: I3f9e8604f79ee4d36cbe3d65079cb23051fcc703 Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: replace 2 switches with if Replace these 2 switches that have only one case with a single if statement. It is highly unlikely that we'll ever need to check for other values. Change-Id: I6a48d4f27ba4d1d128aaa39d5f3d693a11e99fc9 Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: simplify xcoff_secnum_to_sections The only remaining caller of xcoff_secnum_to_sections doesn't care about the section index in the objfile, so remove that part. Return the BFD section as the return value of the function, instead of an output parameter. Remove the unnecessary default in the switch, to avoid a "jump to label over variable initialization" warning. Rename to xcoff_secnum_to_section (singular). Change-Id: I464d8b0e1425ea2732b0d61355c5b0c66218122e Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: allocate symbol table using vector in scan_xcoff_symtab The symbol table content is only needed for the duration of scan_xcoff_symtab, so it's not necessary to allocate it on the objfile obstack. Switch to using a vector that is freed at the end of the function. Change-Id: Ib5acdea460969300a92816a3e71b7d82c80faebf Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: remove xcoff_symfile_info::{symtbl,symtbl_num_syms} It is not necessary to save the symbol table content and number of symbols in xcoff_symfile_info, because they are only needed for the duration of scan_xcoff_symtab. Move the reading of the symbol table content to scan_xcoff_symtab, and keep everything as local variables. Change-Id: I21e2b95a0b8df2255ba46904083658a4e8cb89f0 Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: remove XCOFF_DATA macro Change-Id: I3e2c681689f8386805041c9f007d399df545f6cd Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: remove read of .debug section This is not used by anything. Change-Id: Icc5e72b2f30521b8856db46f4d6cabf26f615b0b Approved-By: Tom Tromey 2026-01-09 Simon Marchi gdb/xcoffread: remove name computation It is no longer necessary to get names of symbols. The only thing we are interested in is the symbol to get the TOC offset, for which the name doesn't matter. Change-Id: I47e6009ed7600ea9c412fb25ed21a295cd0fec49 Approved-By: Tom Tromey 2026-01-09 GDB Administrator Automatic date update in version.in 2026-01-08 Tom Tromey Fix error case in coffread.c coffread.c is the last spot (that I know of) that incorrectly calls perror_with_name when a BFD function fails. The issue here is that perror_with_name examines errno, but BFD failures do not set this. This patch changes this to use error and bfd_errmsg. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31041 Approved-By: Simon Marchi 2026-01-08 Indu Bhagat gas: sframe: fix PR gas/33756 Previously, sframe_xlate_do_remember_state () relied exclusively on last_fre (the last Frame Row Entry for the previous PC range block). At the start of a function (before an advance in location), last_fre is NULL. The intent of DW_CFA_remember_state, however, is to simply snapshot the state of the call frame information at the time. In terms of SFrame generation, this means that we should simply look at cur_fre (the scratchpad FRE currently being built from initial CFI instructions in the current context). Remove the common-empty-1.s which assumed that .cfi_startproc, immediately followed by a .cfi_remember_state is not present out in the wild. Its best to not make such an assumption, as such a sequence is valid CFI, FWIW. Initial CFI are arch-specific, so add a new testcase for x86_64 to check .cfi_remember_state handling for SFrame is sensible. While at at, also add a new testcase for s390x. Co-Authored-by: Jens Remus Reviewed-by: Jens Remus gas/ PR gas/33756 * gen-sframe.c (sframe_xlate_do_remember_state): Use cur_fre. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: Adjust common-empty-1 test to be repurposed as cfi-sframe-x86_64-pr33756. Add s390x testcase. * gas/cfi-sframe/common-empty-1.d: Removed. * gas/cfi-sframe/common-empty-1.s: Removed. * gas/cfi-sframe/cfi-sframe-x86_64-pr33756.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-pr33756.s: New test. * gas/cfi-sframe/cfi-sframe-s390x-pr33756.d: New test. * gas/cfi-sframe/cfi-sframe-s390x-pr33756.s: New test. 2026-01-08 Tom Tromey Remove two fields from xcoff_symfile_info Inspection shows that xcoff_symfile_info::min_lineno_offset and xcoff_symfile_info::max_lineno_offset are never really used. Removing this then shows that find_linenos doesn't do any useful work. So, remove the fields and this function. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Include libiberty.h in bfdio.c On my Fedora 41 machine, a cross-hosted mingw build fails with: ../../binutils-gdb/bfd/bfdio.c:249:50: error: implicit declaration of function 'ARRAY_SIZE'; did you mean 'ARRAYSIZE'? [-Wimplicit-function-declaration] Including libiberty.h in bfdio.c fixes the failure. 2026-01-08 Tom Tromey Remove obsolete wrap_here declaration wrap_here is still declared in utils.h, but hasn't been defined in quite some time. This removes the obsolete declaration. 2026-01-08 Tom Tromey Remove sym_fns::sym_read_linetable The last user of sym_fns::sym_read_linetable was xcoffread.c. Now that the code there has been removed, this callback can be removed as well. This slightly simplifies buildsym. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Remove sym_fns::sym_finish sym_finish::sym_finish isn't needed by any existing code, so this patch removes it. Note that it should never be needed again. It's much cleaner, IMO, for symbol readers to attach data to the objfile or per-BFD via the registry. Then, any cleanup will be automatic. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Remove sym_fns::sym_new_init sym_fns::sym_new_init has long been weird. There's even a comment in symfile.c saying this. After some recent changes, nothing needs this any more. So, this patch removes it entirely. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Don't call set_last_source_file from xcoffread.c xcoffread.c is no longer really using the buildsym code. This removes the last call, which should not be needed, and then removes the include. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Remove unused includes from xcoffread.c I found a number of includes in xcoffread.c that aren't needed. Approved-By: Simon Marchi 2026-01-08 Tom Tromey Remove dead code from xcoffread.c This removes a lot of obviously dead code from xcoffread.c. There are some unused macros and types. A few globals can be removed because they are never assigned to or really used for anything. 2026-01-08 Nick Clifton Import the following commits from the master config sources: a2287c3041a3f2a204eb942e09c015eab00dc7dd 973e3e6af23b73a4f1b8d95680454cae22593bf8 3a71dc102953608d4592ec401b519837c28a672a f91a544533876c70f43b9fd51064b2bcf3fa7382 484648c73f3843b256dd011bd415e81594300a0a 7f4149527babe92cb5da1032734f5cb90cefdac5 9f6e0fe8ce04628bbd4a455118ff3f8309a1aef9 Restore changes to libiberty sources created in commit 219822fd5db6305592b45677a3b38c02b523360e 2026-01-08 Tom de Vries [gdb/testsuite] Add missing require in gdb.debuginfod/solib-with-dwz.exp Add missing "require allow_debuginfod_tests" in test-case gdb.debuginfod/solib-with-dwz.exp. 2026-01-08 GDB Administrator Automatic date update in version.in 2026-01-07 Simon Marchi gdb/copyright.py: run autoconf The last new year procedure missed running autoreconf in gnulib/ and sim/ to update the Makefile.in files (following the updates of the corresponding Makefile.am files). I propose to make the script run `autoreconf -v` to ensure we don't miss those anymore. It takes a bit of time, but that script isn't run very frequently (I'd say more or less once a year). Change-Id: Iab64415cedac716632d6a1230ebb87cc3190f4e4 Approved-By: Tom Tromey 2026-01-07 Simon Marchi gdb/copyright.py: update unordered_dense path The unordered_dense library is now contained in the gdbsupport/unordered_dense directory, update the exclusion entry accordingly. Change-Id: If82355b94b245099ab4c2b27c929639242e33988 Approved-By: Tom Tromey 2026-01-07 Simon Marchi gdb/dwarf: add dwarf2_per_cu::as_signatured_type Add dwarf2_per_cu::as_signatured_type, which returns the dwarf2_per_cu cast to signatured_type if it is indeed a signatured type (type unit), and nullptr otherwise. It can replace a few spots where we use the pattern "check if it's a signatured_type and cast". Change-Id: I10326cd597a0306b15e2ffd7572b79e96068c81a Approved-By: Tom Tromey 2026-01-07 Tom Tromey Mention gdb thread ID in thread messages Currently the "new thread" message that gdb might print does not include gdb's own thread ID -- so, if you want to reference the thread, you must first use "thread find" or "info threads". This patch changes the announcement to mention the thread. The thread-exit message is also updated. I chose to have it display like this: [New Thread 0x7ffff7cbe6c0 (LWP 1267702) (id 2)] [Thread 0x7ffff6cbd6c0 (LWP 1267703) (id 3) exited] ... with the 'id' coming later, because it's somewhat of a pain to wedge the thread id just after the "thread" string where (IMO) it would more naturally belong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19584 2026-01-07 Tom Tromey Make 'print_thread_events' static This makes the 'print_thread_events' global static. It's never used outside of thread.c. Reviewed-by: Stephan Rohr 2026-01-07 Tom Tromey Fix new test for whitespace checker pre-commit complained about a trailing blank line on this new test. I've fixed this and also updated the copyright date. 2026-01-07 Ezra Sitorus aarch64: Add FEAT_NV3, FEAT_SRMASK2 system registers 2026-01-07 Srinath Parvathaneni aarch64: Add support for FEAT_TPS and FEAT_TPSP system registers This patch adds support for TPMIN*/TPMAX* system registers as part of POE2 extension. 2026-01-07 Andrew Burgess gdb: avoid creating misplaced symtabs for dwz files This commit fixes the issue that is described in detail in the previous commit; when processing a DWZ file, GDB can end up creating a symtab associated with a compunit_symtab for a file that was never compiled into a given compunit_symtab. The previous commit added a test for this issue, however, things are slightly complicated because a recent change to GDB: commit a736ff7d886dbcc85026264c3ce11c125a8409b2 Date: Sat Sep 27 22:29:24 2025 -0600 Clean up iterate_over_symtabs Changed GDB in such a way that the problem being discussed here no longer appears to cause any incorrect behaviour. Still, I think this problem is worth fixing. Adding additional symtabs that are in the wrong place has the potential to cause problems in the future, but also, wastes GDB memory, and increases time needed to search through all symtabs. The precise problem here is triggered when a DWZ file is created from multiple object files (as is usually the case). The DWZ file will contain a line table which can hold references to any of the source files, from any of the object files. Note that a source file doesn't have to be included in every object file in order to be added to the line table of the DWZ file. Within GDB the problem originates from the 'new_symbol' function (in dwarf2/read.c). This function looks for the DW_AT_call_file or DW_AT_decl_file of a symbol, uses this to lookup the line table entry, and uses this to obtain the symtab to which the symbol should be attached. For an inlined subroutine instance, this information can be split between an objfile's debug information and a shared DWZ file. For example, from the gdb.debuginfod/solib-with-dwz.exp test case, this first bit of DWARF is from the objfile's debug information: <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine) <92> DW_AT_abstract_origin: <96> DW_AT_low_pc : 0x1121 <9e> DW_AT_high_pc : 31 <9f> DW_AT_call_file : 1 DW_AT_call_line : 26 DW_AT_call_column : 15 <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20) The DW_AT_abstract_origin attributes are referencing the following DWARF which has been placed into the DWZ file: <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram) <1c> DW_AT_name : (indirect string, offset: 0x18a): add_some_int <20> DW_AT_decl_file : 1 <21> DW_AT_decl_line : 24 <22> DW_AT_decl_column : 1 <23> DW_AT_prototyped : 1 <23> DW_AT_type : <0x14> <24> DW_AT_inline : 3 (declared as inline and inlined) <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter) <26> DW_AT_name : a <28> DW_AT_decl_file : 1 <29> DW_AT_decl_line : 24 <2a> DW_AT_decl_column : 19 <2b> DW_AT_type : <0x14> <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter) <2d> DW_AT_name : b <2f> DW_AT_decl_file : 1 <30> DW_AT_decl_line : 24 <31> DW_AT_decl_column : 26 <32> DW_AT_type : <0x14> When GDB tries to create the symbols for the DW_TAG_formal_parameter then this will find the DW_AT_decl_line in the DWZ file. This will cause the line table of the DWZ file to be parsed. This parsing currently creates symtabs for every file mentioned in the DWZ file's line table, which includes files that are not part of the original objfile. Currently GDB creates and stores the symtabs within the file_entry object (see dwarf2/line-header.h). I propose that we make the symtab creation lazy; when the symtab is requested from a file_entry object, the symtab will be created at this point. Doing this will cause another problem though. In dwarf_decode_lines, we specifically create all of the symtabs so that there will be a symtab even for files that contain no code. We don't want to regress this case. The solution is that dwarf_decode_lines will still trigger the symtab creation (by asking the file_entries for their symtab), unless we're processing a DWZ file. We don't need to worry about files that have no code, which are mentioned in a DWZ file, as these files will also be mentioned in the original objfile's line table. When that line table is processed (as it will be), then symtabs for all files mentioned will be created. In this way we will get: (a) symtabs for every source file mentioned in the original objfile, and (b) symtabs for every source file that is specifically used by the DWARF from the DWZ file. I've update the gdb.debuginfod/solib-with-dwz.exp test to check the symtab creation, and also added gdb.base/dwz-symtabs.exp, which is very similar to solib-with-dwz.exp, but doesn't depend on debuginfod and instead just focuses on which symtabs are created, this make the test a little simpler overall. Approved-By: Tom Tromey Reviewed-By: Simon Marchi 2026-01-07 Andrew Burgess gdb: test for misplaced symtab causing file not found error This patch adds a new test that checks for a bug that was, if not fixed, then at least, worked around, by commit: commit a736ff7d886dbcc85026264c3ce11c125a8409b2 Date: Sat Sep 27 22:29:24 2025 -0600 Clean up iterate_over_symtabs The bug was reported against Fedora GDB which, at the time the bug was reported, is based off GDB 16, and so doesn't include the above commit. The bug report can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=2403580 To summarise the bug report: a user is inspecting an application backtrace. The original bug report was from a core file, but the same issue will trigger for a live inferior. It's the inspection of the stack frames which is important. The user moves up the stack with the 'up' command and eventually finds an interesting frame. They use 'list' to view the source code at the current location, this works and displays lines 6461 to 6470 from the source file '../glib/gmain.c'. The user then does 'list 6450' to try and display some earlier lines from the same source file, at which point GDB gives the message: warning: 6445 ../glib/gmain.c: No such file or directory So GDB initially manages to find the source file, but for the very next command, GDB now claims that the source file doesn't exist. As I said, commit a736ff7d886d appears to fix this issue, but it wasn't clear to me (from the commit message) if this commit was intended to fix any bugs, or if the bug was being hidden by this commit. I've spent some time trying to understand what's going on, and have come up with this test case. I think there might still be an issue in GDB, but I do think that the above commit really is making it so that the issue (if it is an issue) doesn't occur in that particular situation any more, so I think we can consider the above commit a fix, and testing for this bug is worth while to ensure it doesn't get reintroduced. In order to trigger this bug we need these high level requirements: 1. Multiple shared libraries compiled from the same source tree. In this case it was glib, but the test in this commit uses a much smaller library. 2. Common DWARF must be pulled from the libraries using the 'dwz' tool. 3. Debuginfod must be in use for at least downloading the source code. In the original bug, and in the test presented here, debuginfod is used for fetching both the debug info, and the source code for the library. There are some additional specific requirements for the DWARF in order to trigger the bug, but to make discussing this easier, lets look at the structure of the test presented here. When discussing the source files I'll drop the solib-with-dwz- prefix, e.g. when I mention 'foo.c' I really mean 'solib-with-dwz-foo.c'. There are three shared libraries built for this test, libbar.so, libfoo.so, and libfoo-2.so. The source file bar.c is used to create libbar.so, and foo.c is used to create libfoo.so and libfoo-2.so. The main test executable is built from main.c, and links against libbar.so and libfoo.so. libfoo-2.so is not used by the main executable, and just exists to trigger some desired behaviour from the dwz tool. The debug information for each shared library is extracted into a corresponding .debug file, and the dwz tool is used to extract common debug from the three .debug files into a file called 'common.dwz'. Given all this then, in order to trigger the bug, the following additional requirements must be met: 4. libbar.so must NOT make use of foo.c. In this test libbar.so is built from bar.c (and some headers) only. 5. A reference to foo.c must be placed into common.dwz. This is why libfoo-2.so exists, as this library is almost identical to libfoo.so, there is lots of shared DWARF between libfoo.so and libfoo-2.so which can be moved into common.dwz, this shared DWARF includes references to foo.c, so an entry for foo.c is added to the file table list in common.dwz. 6. There must be a DWARF construct within libbar.so.debug that references common.dwz, and which causes GDB to parse the line table from within common.dwz. For more details on this, see below. 7. We need libbar.so to appear before libfoo.so in GDB's comunit_symtab lists. This means that GDB will scan the symtabs for libbar.so before checking the symtabs of libfoo.so. I achieve this by mentioning libbar.so first when building the executable, but this is definitely the most fragile part of the test. To satisfy requirement (6) the inline function 'add_some_int' is added to the test. This function appears in both libbar.so and libfoo.so, this means that the DW_TAG_subprogram representing the abstract instance tree will be moved into common.dwz. However, as this is an inline function, the DW_TAG_inlined_subroutine DIEs for each concrete instance, will be left in libbar.so.debug and libfoo.so.debug, with a DW_AT_abstract_origin that points into common.dwz. When GDB parses libbar.so.debug it finds the DW_TAG_inlined_subroutine and begins processing it. It sees the DW_AT_abstract_origin and so jumps into common.dwz to read the DIEs that define the inline function. Here is the DWARF from libbar.so.debug for the inlined instance: <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine) <92> DW_AT_abstract_origin: <96> DW_AT_low_pc : 0x1121 <9e> DW_AT_high_pc : 31 <9f> DW_AT_call_file : 1 DW_AT_call_line : 26 DW_AT_call_column : 15 <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <3>: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_abstract_origin: DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20) And here's the DWARF from common.dwz for the abstract instance tree: <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram) <1c> DW_AT_name : (indirect string, offset: 0x18a): add_some_int <20> DW_AT_decl_file : 1 <21> DW_AT_decl_line : 24 <22> DW_AT_decl_column : 1 <23> DW_AT_prototyped : 1 <23> DW_AT_type : <0x14> <24> DW_AT_inline : 3 (declared as inline and inlined) <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter) <26> DW_AT_name : a <28> DW_AT_decl_file : 1 <29> DW_AT_decl_line : 24 <2a> DW_AT_decl_column : 19 <2b> DW_AT_type : <0x14> <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter) <2d> DW_AT_name : b <2f> DW_AT_decl_file : 1 <30> DW_AT_decl_line : 24 <31> DW_AT_decl_column : 26 <32> DW_AT_type : <0x14> While processing the common.dwz DIEs GDB sees the DW_AT_decl_file attributes, and this triggers a read of the file table within common.dwz, which creates symtabs for any files mentioned, if the symtabs don't already exist. But, and this is the important bit, when doing this, GDB is creating a compunit_symtab for libbar.so.debug, so any symtabs created will be attached to the libbar.so.debug objfile. Remember requirement (5), the file list in common.dwz mentions 'foo.c', so even though libbar.so doesn't use 'foo.c' we end up with a symtab for 'foo.c' created within the compunit_symtab for libbar.so.debug! I don't think this is ideal. This wastes memory and time; we have more symtabs to search through even if, as I'll discuss below, we usually end up ignoring these symtabs. The exact path that triggers this weird symtab creation starts with a call to 'new_symbol' (dwarf2/read.c) for the DW_TAG_formal_parameter in the abstract instance tree. These include DW_AT_decl_file, which is read in 'new_symbol'. In 'new_symbol' GDB spots that the line_header has not yet been read in, so handle_DW_AT_stmt_list is called which reads the file/line table and then calls 'dwarf_decode_lines' (line_program.c), which then creates symtabs for all the files mentioned. This symtab creation issue still exists today in GDB, though I've not been able to find any real issues that this is causing after commit a736ff7d886d fixed the issue I'm discussing here. So, having tricked GDB into creating a misplaced symtab, what problem did this cause prior to commit a736ff7d886d? To answer this, we need to take a diversion to understand how a command like 'list 6450' works. The two interesting functions are create_sals_line_offset and decode_digits_list_mode, which is called from the former. The create_sals_line_offset is called indirectly from list_command via the initial call to decode_line_1. In create_sals_line_offset, if the incoming linespec doesn't specify a specific symtab, then GDB uses the name of the default symtab to lookup every symtab with a matching name, this is done with the line: ls->file_symtabs = collect_symtabs_from_filename (self->default_symtab->filename (), self->search_pspace); In our case, when the default symtab is 'foo.c', this is going to return multiple symtabs, these will include the correct 'foo.c' symtab from libfoo.so, but will also include the misplaced 'foo.c' symtab from libbar.so. This is where the ordering is important. As list will only ever list one file, at a later point in this process we're going to toss out everything except the first result. So, to trigger the bug, it is critical that the FIRST result returned here be the misplaced 'foo.c' symtab from libbar.so. In the test I try to ensure this by mentioning libbar.so before libfoo.so when building the executable, which currently means we get back the misplaced symtab first, but this could change in the future and wouldn't necessarily mean that the problem has gone away. Having got the symtab list GDB then calls decode_digits_list_mode which iterates over the symtabs and converts them into symtab_and_line objects, at the heart of which is a call to find_line_symtab, which checks if a given symtab has a line table entry for the desired line. If it does then the symtab is returned. If it doesn't then GDB looks for another symtab with the same name that does have a line table entry. If no suitably named symtab has an exact match, then the symtab with the closest line above the required line is returned. If no symtab has a matching line table entry then find_line_symtab returns NULL. Remember, the misplaced symtab was only created as a side effect of trying to attach the DW_TAG_formal_parameter symbol to a symtab. The actual line table for libbar.so (in libbar.so.debug) has no line table entries for 'foo.c'. What this means is that the line table for 'foo.c' attached to libbar.so.debug is empty. So normally what happens is that find_line_symtab will instead find a line table entry for 'foo.c' in libfoo.so.debug that does have a suitable line table entry, and will switch GDB back to that symtab, effectively avoiding the problem. However, that is not what happens in the bug case. In the bug case find_line_symtab returns NULL, which means that decode_digits_list_mode just uses the original symtab, in this case the symtab for 'foo.c' from libbar.so.debug. In the original bug, the code is compiled with -O2, and this optimisation has left the line table covering the problem file pretty sparse. In fact, there are no line table entries for any line after the line that the user is trying to list. This is why find_line_symtab doesn't find a better alternative symtab, and instead just returns NULL. In the test I've replicated this by having a comment at the end of the source file, and asking GDB to list a line within this comment. The result is that there are no line table entries for that line in any 'foo.c' symtab, and so find_line_symtab returns NULL. After decode_digits_list_mode sees the NULL from find_line_symtab, it just uses the initial symtab. After this we eventually return back to list_command (cli/cli-cmds.c) with a list of symtab_and_line objects. The first entry in this list is for the symtab 'foo.c' from libbar.so. In list_command we call filter_sals which throws away everything but the first entry as all the symtabs have the same filename (and are in the same program space). Using the symtab we build an absolute path to the source file. Now, if the source is installed locally, GDB performs no additional checks; we found a symtab, the symtab gave us a source filename, if the source file exists on disk, then the requires lines are listed for the user. But if the source file doesn't exist on disk, then we are going to ask debuginfod for the source file. To do that we use two pieces of information; the absolute path to the source file, which we have; and the build-id of an objfile, this is the objfile that owns the symtab we are trying to get the source for. In this case libbar.so. And so we send the build-id and filename to debuginfod. Now debuginfod isn't going to just serve any file to anyone, that would be a security issue for the server. Instead, debuginfod scans the DWARF and builds up its own model of which objfiles use which source files, and for a given build-id, debuginfod will only serve back files that the objfile matching that build-id, actually uses. So, in this case, when we ask for 'foo.c' from libbar.so, debuginfod correctly realises the 'foo.c' is not part of libbar.so, and refuses to send the file back. And this is how the original bug occurred. So, why does commit a736ff7d886d fix this problem? The answer is in iterate_over_symtabs, which is used by collect_symtabs_from_filename to find the matching symtabs. Prior to this commit, iterate_over_symtabs had two phases, first a call to iterate_over_some_symtabs which walks over compunit_symtabs that already exist looking for matches, during this phase only the symtab filenames are considered. The second phase uses objfile::map_symtabs_matching_filename to look through the objfiles and expand new symtabs that match the required name. In our case, by the time iterate_over_symtabs is called, all of the interesting symtabs have already been expanded, so we only perform the filename check in iterate_over_some_symtabs, this passes, and so 'foo.c' from libbar.so is considered a suitable symtab. After commit a736ff7d886d the initial call to iterate_over_some_symtabs has been removed from iterate_over_symtabs, and only the objfile::map_symtabs_matching_filename call remains. This ends up in cooked_index_functions::search (dwarf2/read.c) to search for matching symtabs. The first think cooked_index_functions::search does is setup a vector of CUs to skip by calling dw_search_file_matcher, this then calls dw2_get_file_names to get the file and line table for a CU, this function in turn creates a cutu_reader object, passing true for the 'skip_partial' argument to its constructor. As our 'foo.c' symtab was created from within the dwz extracted DWARF, then it is associated with the DW_TAG_partial_unit that held the DW_TAG_subprogram DIEs that were being processed when the misplaced symtab was original created; this is a partial unit. As this is a partial unit, and the skip_partial flag was passed true, the cutu_reader::is_dummy function will return true. Back in dw2_get_file_names, if cutu_reader::is_dummy is true then dw2_get_file_names_reader is never called, and the file names are never read. This means that back in dw_search_file_matcher, the file data, returned from dw2_get_file_names is NULL, and so this CU is marked to be skipped. Which is exactly what we want, this misplaced symtab, which was created for a partial unit and associated with libbar.so, is skipped and never considered as a possible match. There is a remaining problem, which is marked in the test with an xfail. That is, when the test does the 'list LINENO', GDB still tries to download the source for 'foo.c' from libbar.so. The reason for this is that, while it is true that the initial collect_symtabs_from_filename call no longer returns 'foo.c' from libbar.so, when decode_digits_list_mode calls find_line_symtab for the correct 'foo.c' from libfoo.so, it is still the case that there is no exact match for LINENO in that symtabs line table. As a result, GDB looks through all the other symtabs for 'foo.c' to see if any are a better match. Checking if another symtab is a possible better match requires a full comparison of the symtabs source file name, which in this case triggers an attempt to download the source file from debuginfod. Here's the backtrace at the time of the rogue source download request, which appears as an xfail in the test presented here: #0 debuginfod_source_query (build_id=..., build_id_len=..., srcpath=..., destname=...) at ../../src/gdb/debuginfod-support.c:332 #1 0x0000000000f0bb3b in open_source_file (s=...) at ../../src/gdb/source.c:1152 #2 0x0000000000f0be42 in symtab_to_fullname (s=...) at ../../src/gdb/source.c:1214 #3 0x0000000000f6dc40 in find_line_symtab (sym_tab=..., line=..., index=...) at ../../src/gdb/symtab.c:3314 #4 0x0000000000aea319 in decode_digits_list_mode (self=..., ls=..., line=...) at ../../src/gdb/linespec.c:3939 #5 0x0000000000ae4684 in create_sals_line_offset (self=..., ls=...) at ../../src/gdb/linespec.c:2039 #6 0x0000000000ae557f in convert_linespec_to_sals (state=..., ls=...) at ../../src/gdb/linespec.c:2289 #7 0x0000000000ae6546 in parse_linespec (parser=..., arg=..., match_type=...) at ../../src/gdb/linespec.c:2647 #8 0x0000000000ae7605 in location_spec_to_sals (parser=..., locspec=...) at ../../src/gdb/linespec.c:3045 #9 0x0000000000ae7c7f in decode_line_1 (locspec=..., flags=..., search_pspace=..., default_symtab=..., default_line=...) at ../../src.dev-m/gdb/linespec.c:3167 I think that this might not be what we really want to do here. After downloading the source file we'll end up with a filename within the debuginfod download cache, which will be different for each objfile (the cache partitions downloads based on build-id). So if two symtabs originate from the same source file, but are in two different objfiles, then, when the source is on disk, the filenames for these symtabs will be identical, and the symtabs will be considered equivalent by find_line_symtab. But when debuginfod is downloading the source the source paths will be different, and find_line_symtab will consider the symtabs different. This doesn't seem right to me. But I'm going to leave worrying about that for another day. Given this last bug, I am of the opinion that the misplaced symtab is likely a bug, though after commit a736ff7d886d, the only issue I can find is the extra debuginfod download request, which isn't huge. But still, maybe just reducing the number of symtabs would be worth it? But this patch isn't about fixing any bugs, it's about adding a test case for an issue that was a problem, but isn't any longer. Approved-By: Tom Tromey 2026-01-07 Andrew Burgess gdb: fix line wrapping in new boxed hints when styling is enabled I noticed that the startup hint text, the stuff that's placed into a box, is not line wrapping correctly. For example: $ gdb -nw -nh -eiex 'set width 60' ... snip ... ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Find the GDB manual online at: ┃ ┃ http://www.gnu.org/software/gdb/documentation/. ┃ ┃ For help, type "help". ┃ ┃ Type "apropos " to search ┃ ┃ for commands related to ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ (gdb) Notice the final two lines within the box, there's no need to wrap after the word 'search', plenty more would fit on that line. And indeed, if we switch off styling: $ gdb -nw -nh -eiex 'set width 60' -eiex 'set style enabled off' ... snip ... +----------------------------------------------------------+ | Find the GDB manual online at: | | http://www.gnu.org/software/gdb/documentation/. | | For help, type "help". | | Type "apropos " to search for commands related to | | | +----------------------------------------------------------+ (gdb) That's mostly fixed it, except I still think there's a stray white space character before '' on the final line. The fact that the output is wrapped differently with styling on and off tells me that this is not an intentional choice. The problems are, I think all in box_one_message (from top.c). There are a number of issues. 1. Each time around the loop we count all escape characters in MESSAGE, not just the escape characters up to the point where we might wrap the message. This has the potential to over count the escape characters. 2. When splitting MESSAGE we search for a space character. This search starts based on the terminal width, but neglects to take into account any escape characters prior to the split point. 3. If we split a line after an alternative style has been activated, but before the style has been reset, then the border of the box on that line is going to be rendered in the alternative style. 4. When computing what content needs to be moved onto the second line, we don't move past the space character (as found in point 2). Now it just so happens that issues (1) and (3) can be ignored for now. The surrounding box is only added (and line wrapping performed) if the terminal is at least wide enough to fit the documentation URL (plus box borders). This means a minimum width of 51 characters. On all the other lines, any styled output is always to the left of the line, occurring before character 51. This means that counting all escape characters is the same as counting just the escape characters that will appear before the line break. And we will never need to line break part way through some styled text. Obviously we _could_ fix this code properly, but it's not simple, and it would all be completely theoretical. So in this commit I plan to add an assert that all escape sequences occur within the first 51 characters, then if the above text ever changes we will immediately know that box_one_message will need to be rewritten. Fixing issue (2) is pretty easy, this line: line = message.substr (0, message.rfind (" ", width)); just needs to be updated to take N_ESCAPE_CHARS into account. We currently look for a space after WIDTH characters in MESSAGE, but MESSAGE also contains escape sequences, so we really need to search in for a space starting from 'WIDTH + N_ESCAPE_CHARS'. And fixing (4) is also easy, this line: message = message.substr (line.length ()); finds the remainder of MESSAGE based on LINE. But LINE was all content up to (but not including) the space character we found. What we actually need to do is: message = message.substr (line.length () + 1); To add the assert that I discussed above, I've moved the escape characters counting code out of the line printing loop. We now count the escape characters just once, and assert that these all fit within the WIDTH, this means they will all appear before any line break. While making these changes I've also made use of std::move to avoid copying a string in one place. Finally, the gdb.base/startup-hints.exp test has been expanded to cover both styled and non-styled output, as well as a greater range of terminal widths. 2026-01-07 Nick Clifton Sync libiberty sources with gcc master version 2026-01-07 Andrew Burgess gdb: hold a target_ops_ref in scoped_finish_thread_state This commit fixes a use after free issue that was reported here: https://inbox.sourceware.org/gdb-patches/68354b98-795a-4b50-9eac-e54aa1d01b9d@simark.ca This issue was exposed by the gdb.replay/missing-thread.exp test that was added in this commit: commit 8bd08ee92c4a7bf2ad9e29c4da32a276ef2257fc Date: Fri May 16 17:56:58 2025 +0100 gdb: crash if thread unexpectedly disappears from thread list It is worth pointing out that the use after free issue existed before this commit, this commit just introduced a test that exposed the issue when GDB is run with the address sanitizer. It has taken a while to get this fix ready for upstream as this fix depended on the recently committed patch: commit 43db8f70d86b2492b79f59342187b919fd58b3dd Date: Thu Oct 23 16:34:20 2025 +0100 gdbsupport: remove undefined behaviour from (forward_)scope_exit The problem is that the first commit above introduces a test which causes the remote target to disconnect while processing an inferior stop event, specifically, within normal_stop (infrun.c), GDB calls update_thread_list, and it is during this call that the inferior disconnects. When the remote target disconnects, GDB immediately unpushes the remote target. See remote_unpush_target and its uses in remote.c. If this is the last use of the remote target, then unpushing it will cause the target to be deleted. This is a problem, because in normal_stop, we have an RAII variable maybe_finish_thread_state, which is an optional scoped_finish_thread_state, and in some cases, this will hold a pointer to the process_startum_target which needs to be finished. So the order of events is: 1. Call to normal_stop. 2. Create maybe_finish_thread_state with a pointer to the current remote_target object. 3. Call update_thread_list. 4. Remote disconnects, GDB unpushes and deletes the current remote_target object. GDB throws an exception. 5. The exception propagates back to normal_stop. 6. The destructor for maybe_finish_thread_state runs, and tries to make use of its cached pointer to the (now deleted) remote_target object. Badness ensues. This bug isn't restricted to normal_stop. If a remote target disconnects anywhere where there is a scoped_finish_thread_state in the call stack then this issue could arise. I think what we need to do is to ensure that the remote_target is not actually deleted until after the scoped_finish_thread_state has been cleaned up. And so, to achieve this, I propose changing scoped_finish_thread_state to hold a target_ops_ref rather than a pointer to the target_ops object. Holding the reference will prevent the object from being deleted. The new scoped_finish_thread_state is defined within its own file, and is a drop in replacement for the existing class. On my local machine the gdb.replay/missing-thread.exp test passes cleanly after this commit (with address sanitizers), but when I test on some other machines with a more recent Fedora install, I'm still seeing test failures (both before and after this patch), though not relating to the address sanitizer (at least, I don't see an error from the sanitizer). I don't think these other issues are directly related to the problem being addressed in this commit, and so I'm proposing this patch for inclusion anyway. I'll continue to look at the test and see if I can fix the other failures too. Or maybe I'll end up having to back out the test. Approved-By: Simon Marchi Reviewed-By: Guinevere Larsen 2026-01-07 Nick Clifton Improve the linker's --stats option to record memory use information provided by mallinfo(). 2026-01-07 Aditya Vidyadhar Kamath Simon Marchi Add TOC calculation for XCOFF binary in AIX and remove legacy line number information. Closes https://sourceware.org/bugzilla/show_bug.cgi?id=33606 This is a patch to bring back certain XCOFF reading sections back to the GDB code which was removed during the STABS removal. This patch also removes the legacy line table calculation for STABS since we no longer will support it. The issue we removed code that will get us the TOC offset in AIX. This will now cause regressions. For example,Consider a code where we create a simple library x as below. int g_in_lib = 777; int lib_func() { return g_in_lib + 1; } int lib_func(); Then we use this library X in main(). int main() { printf ("lib_func() = %d \n", lib_func()); return 0; } If we as of today compile master branch in AIX and try to call lib_func() from GDB we get, GNU gdb (GDB) 18.0.50.20251112-git Breakpoint 1, main () at //gdb_tests/main.c:5 5 printf ("lib_func() = %d \n", lib_func()); (gdb) call lib_func() $1 = 536875277 (gdb) q which is a garbage value instead of 778. DWARF will not have any information about TOC to maintain uniformity with other operating system. TOC (Table Of Contents) is a part of XCOFF/AIX ABI and is required for: 1: Loading shared libraries as we need TOC that contain pointers to access global variables and functions entry points. 2: Function calls like the above call where AIX expects register r2 = pointer to TOC which gives fast access to global data plus an ofset 3: Large code model = TOC solves the fact that PPC64 can't embed large 64 bit addresses. So we need to get GDB to fetch this even though we only read DWARF debug sections in the XCOFF binary. (AIX uses GCC-13 now which produces only DWARF now.). In the above case since the toc_offset is not there now we cannot access lib_func() causing the regression. The patch right now brings back the code required to fetch the same. Once this patch is applied we get, GNU gdb (GDB) 18.0.50.20251204-git Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc64-ibm-aix7.2.0.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . +------------------------------------------------------------------------------+ | Find the GDB manual online at: | | http://www.gnu.org/software/gdb/documentation/. | | For help, type "help". | | Type "apropos " to search for commands related to | +------------------------------------------------------------------------------+ .. Reading symbols from //gdb_tests/main... (gdb) b main Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5. (gdb) r Starting program: /gdb_tests/main Breakpoint 1, main () at //gdb_tests/main.c:5 5 printf ("lib_func() = %d \n", lib_func()); (gdb) call lib_func() $1 = 778 (gdb) q A debugging session is active. Inferior 1 [process 7340312] will be killed. Quit anyway? (y or n) y Also some clean ups of code and additions, they are: 1: Replaced old APIs like bfd_map_over_sections with gdb_bfd_sections() and range-based loops. 2: Used helpers like obstack_strndup instead of manual allocation like changing p = (char *) obstack_alloc (&objfile->objfile_obstack, and strncpy (p, symbol->n_name, E_SYMNMLEN); to *name = obstack_strndup(&objfile->objfile_obstack, symbol->n_name, E_SYMNMLEN); 3: Removed unused macros as unnecessary global variables as you mentioned 4: Replaced perror_with_name with error() and bfd_errmsg. See: error(_("reading symbol table: %s"), bfd_errmsg(bfd_get_error())); 5: Also used bfd_get_section_alloc_size(). 6: Eliminated the xcoff_find_targ_sec_arg struct used in GDB 17 or earlier because it is no longer necessary for context handling. 7: Eliminated the find_targ_sec () used in GDB 17 or earlier since we find the bfd_sect in xcoff_secnum_to_sections(). Approved-By: Tom Tromey 2026-01-07 GDB Administrator Automatic date update in version.in 2026-01-06 Tom de Vries [gdb] Fix heap-buffer-overflow in args_complete_p PR gdb/33754 reports a heap-buffer-overflow args_complete_p, while checking the while condition: ... while (*input != '\0') { input = skip_spaces (input); ... ++input; } ... The problem can be reproduced by calling args_complete_p (" "). The following happens: - at function entry, input == " " - the while loop is entered - after skip_spaces, input == "" - after the ++input at the end of the loop body, input points past the terminating '\0' - while checking the while condition, *input does an out-of-bound access. Add a unit test exercising this minimal example, fix this by checking input after skip_spaces, and add an assert to detect the heap-buffer-overflow without Address Sanitizer. Another heap-buffer-overflow can be found by calling args_complete_p ("\"\\"). In this case, the following happens: - at function entry, input == "\"\\" - the while loop is entered - dquote is set to true and input == "\\" - the while loop is entered a second time - the condition *input == '\\' && strchr ("\"\\", *(input + 1)) != nullptr evaluates to true (which is not trivial to understand, because the char found in the string "\"\\" is '\0'), leading to two increments of input, again making input point past the terminating '\0'. Fix this by checking for *(input + 1) == '\0', and likewise add a unit test. Tested on x86_64-linux. Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33754 2026-01-06 Tom de Vries [gdb] Fix confusing string in command_line_append_input_line While writing a unit test for PR33754, I ran into an std::string s where where strlen (s.data ()) != s.size (). I tracked this down to command_line_append_input_line, where we do: ... /* Copy whole line including terminating null, and we're done. */ cmd_line_buffer.append (rl, len + 1); ... As example, consider string s: ... std::string s = ""; s.append ("", 1); ... Initially, the string is empty, and we have: - strlen (s.data ()) == 0 - s.size () == 0 After appending '\0', we have: - strlen (s.data ()) == 0 - s.size () == 1 While I suppose this is legal, I think it's better to avoid this type of string, since it tends to cause confusion and off-by-one errors. And AFAIU, in this case the '\0' is not necessary, it's a remnant of using C strings. Fix this by simply appending rl. Approved-By: Tom Tromey Tested on x86_64-linux. 2026-01-06 Simon Marchi gdb/dwarf: remove redundant DW_AT_containing_type checks I noticed that some places first check if a DIE has a DW_AT_containing_type attribute, like so: if (dwarf2_attr (type_die, DW_AT_containing_type, type_cu) == NULL) return NULL; and then call function die_containing_type, which does the same check, erroring out if the attribute does not exist. The second check is redundant in these cases. There is only one call site that does not do a check before, for which the error might be relevant. Remove the error call from die_containing_type, making it return nullptr if the DIE does not have a DW_AT_containing_type attribute, and remove the redundant checks in all but that one call site. For that one call site, error out if the return value of die_containing_type is nullptr. I changed the error message to be a little more precise. There is no expected behavior change, apart from the content of that error message. Change-Id: I99e89bd89d4fffef73f00e7ecc9d6ba11c0bd085 Approved-By: Tom Tromey 2026-01-06 Simon Marchi sim: re-generate Makefile.in Makefile.am was updated by the new year procedure, but Makefile.in should have been re-generated as well, do it now. Change-Id: I82f36aebbd9ebe33f37eb4af71933ee84c257f38 2026-01-06 Simon Marchi gnulib: re-generate Makefile.in Makefile.am was updated by the new year procedure, but Makefile.in should have been regenerated as well, do it now. Change-Id: Id56fcce79a5d6efaaeca219d5809011af187787f 2026-01-06 Tom de Vries [gdbsupport] Fix get_print_cell use in threads PR gdb/33753 reports problems with get_print_cell when used from threads. Fix this by making the two static variables in get_print_cell thread_local. Tested on x86_64-linux. Approved-By: Simon Marchi Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33753 2026-01-06 Simon Marchi gdb: remove smash_to_memberptr_type smash_to_memberptr_type is only used by lookup_memberptr_type, remove it and inline its code there. Change-Id: I8bc1b8da38f1124e231451aed183d957ea1c37af Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: remove make_cv_type typeptr parameter It is always passed nullptr. Change-Id: Iecc170545c0504af35d83bcb06e07d29994d18e1 Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: remove make_function_type We now have make_function_type and lookup_function_type exposed by gdbtypes.h, which do essentially the same thing. Remove make_function_type, inlining its code inside create_function_type. Change all other callers of make_function_type to use lookup_function_type instead. Change-Id: Id7c25f02059efe5c0f15e8ab8a35ac1fa97d9d6a Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: remove make_function_type typeptr parameter In a few places, it is passed nullptr, meaning that we allocate a type using a type allocator derived from the return type. In the -> lookup_function_type_with_arguments -> create_function_type -> make_function_type and -> lookup_function_type -> create_function_type -> make_function_type paths, we create an allocator based on the return type, pass it down, and create a type using that, which then gets passed to make_function_type. Instead, we can let make_function_type allocate the type based on the return type. Change-Id: I3f38e2f4744ab664bd91b006b00501332df617b5 Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: remove make_reference_type typeptr parameter It is always passed nullptr. Change-Id: I1ec2afacb694c6d708df28ea6d47f08ceaf973db Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: remove make_pointer_type typeptr parameter It is always nullptr. Change-Id: I88e81427c781bd6356203ccc969eae1ab84ac0ef Approved-By: Tom Tromey 2026-01-06 Simon Marchi gdb: make create_function_type static It is only used within gdbtypes.c. Change-Id: I3976ca1ec3253c0ade6e7ac71d967d09108d2454 Approved-By: Tom Tromey 2026-01-06 Tom Tromey Fix check-whitespace complaint check-whitespace complaint about a trailing empty line in gdb/dwarf2/cu.c. This fixes it. Reindent gdb.ada tests Various gdb.ada tests had incorrect indentation. This patch reformats these. It was written by script. 2026-01-06 Tom Tromey Small cleanup to interpreter initialization interp::inited is currently public, because interp_set does the task of making sure the interpreter is only initialized a single time. However, the interpreter can do this job itself, and this member can be private. 2026-01-06 Tom Tromey Remove two "unsupported" tests from gdb.dwarf2/imported-unit.exp gdb.dwarf2/imported-unit.exp yields two "unsupported" results but then carries on. These tests look for psymtabs, which haven't been used by the DWARF reader since the introduction of the cooked index. This patch removes these tests and also the supporting function psymtabs_p, which is no longer used. 2026-01-06 Simon Marchi gdb: remove context_stack::static_link I don't think it's needed to record this information in the context_stack structure. The only user is the DWARF reader, where it can very well be a local variable. Change-Id: I6e33affbf03f11c0d0ab60067f169137fde1c994 Approved-By: Tom Tromey 2026-01-06 Tom Tromey Simplify linespec.c:collect_info I noticed that linespec has a subclass of collect_info that would be easily replaced by a boolean. This patch cleans up this area by removing the subclass, adding a constructor to collect_info, and removing an unnecessary structure type used by it. Regression tested on x86-64 Fedora 40. Approved-By: Andrew Burgess 2026-01-06 Tom de Vries [gdb/testsuite] Fix gdb.base/watchpoint-adjacent.exp with m32 PR testsuite/33727 reports the following failure with test-case gdb.base/watchpoint-adjacent.exp and i686-linux (or, x86_64-linux and target board unix/-m32): ... (gdb) continue^M Continuing.^M watchpoint-adjacent-type_ll: watchpoint-adjacent.c:63: main: \ Assertion `(((uintptr_t) &obj.a) & 0x7) == 0' failed.^M ^M Program received signal SIGABRT, Aborted.^M 0xb7fc5579 in __kernel_vsyscall ()^M (gdb) FAIL: $exp: var_type=type_ll: test= a {a b} : rwatch_first=true: \ continue to breakpoint: prepare for read test ... The problem is that the test-case expects 8-byte aligned data as an effect of using long long, but long long has an alignment of 4 bytes [1]. Fix this by using __attribute__((aligned(8))). After fixing this, we find one remaining failure. This has been filed as PR breakpoints/33762. Tested on x86_64-linux with target boards unix/-m64 and unix/-m32. Approved-By: Andrew Burgess Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33727 [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-malign-double 2026-01-06 Andrew Burgess gdb/dwarf: rename dwarf2_start_subfile to dwarf2_cu::start_subfile Rename dwarf2_start_subfile to dwarf2_cu::start_subfile. This refactor continues the work started in the previous commit. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-06 Andrew Burgess gdb/dwarf: move subfile and symtab creation into dwarf2_cu method There are two places in the dwarf2/ code where we create subfiles and symtabs for the entries in a dwarf2_cu's line_header. The code in each location is basically the same. Move this code into a new dwarf2_cu member function. In dwarf2/read.c the existing code had an additional task; this is left in dwarf2/read.c in its own loop immediately after the call to the new member function. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-06 Andrew Burgess gdb/dwarf: remove the line_header argument from dwarf2_start_subfile As with the previous two commits, this commit removes the line_header argument from dwarf2_start_subfile. This function already takes a dwarf2_cu argument, and the line_header passed in is always the line header pointed to by the dwarf2_cu argument, so lets just access the line header through the dwarf2_cu. As dwarf2_start_subfile relies on the dwarf2_cu always being non-NULL, I've converted the dwarf2_cu argument from a pointer to a reference. The alternative was adding an assert within dwarf2_start_subfile that the pointer was not NULL. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-06 Andrew Burgess gdb/dwarf: remove m_line_header from lnp_state_machine class Following on from the previous commit, this commit remove m_line_header from the lnp_state_machine class. The lnp_state_machine class already holds m_cu, a dwarf2_cu, and the m_line_header was always just m_cu->line_header, so instead of holding both of these separately, lets just hold m_cu, and access the line header through that. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-06 Andrew Burgess gdb/dwarf: remove line_header parameter from dwarf2_decode_lines The function declaration for dwarf2_decode_lines is: void dwarf_decode_lines (struct line_header *lh, struct dwarf2_cu *cu, unrelocated_addr lowpc, bool decode_mapping) However, it is always the case that: lh == cu->line_header I propose that we simplify the dwarf_decode_lines signature by removing the line_header parameter. The same is true for dwarf_decode_lines_1, which is only called from dwarf_decode_lines. I'm proposing this change because I was looking through the DWARF code, trying to understand how symtabs are created, and this extra complexity just makes things harder to understand: what is the relationship between the line_header (LH) and dwarf2_cu (CU) parameters? When would we ever want to process a line_header other than the one attached to CU? (answer: never, and we don't). This simplification makes things easier to understand (IMHO). There should be no user visible changes after this commit. Approved-By: Tom Tromey 2026-01-06 GDB Administrator Automatic date update in version.in 2026-01-05 Indu Bhagat gas: dw2gencfi: reset reloc to TC_PARSE_CONS_RETURN_NONE for [su]leb128 Some consumers, like SFrame generation logic in GAS, may want to check reloc value (without qualifying by e->type) as a part of their admissibility criteria. Setting reloc to TC_PARSE_CONS_RETURN_NONE for these CFI escape expr nodes for [su]leb128 keeps the admissibility checks simple and generic. Previous discussion here: https://sourceware.org/pipermail/binutils/2025-December/146807.html gas/ * gas/dw2gencfi.c (dot_cfi_escape): Set reloc to TC_PARSE_CONS_RETURN_NONE. 2026-01-05 Tom de Vries [gdb/testsuite] Fix gdb.python/py-corefile.py with m32 With target board unix/-m32 and test-case gdb.python/py-corefile.exp I run into: ... FAIL: $exp: test mapped files data: diff input and output one ... due to differences like 0x0000000008048000 vs 0x08048000. Fix this in gdb.python/py-corefile.py by detecting and handling the ptr_size == 4 case. Tested on x86_64-linux. Approved-By: Andrew Burgess PR testsuite/33728 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33728 2026-01-05 Simon Marchi gdb: remove mdebugread & al After working on the "gdb: replace msym_bunch with deque" patch, I dug into the history of the mdebug format, and have come to the conclusion that it is time to remove that code. ECOFF and mdebug were apparently relevant up to the mid 90s, after which they were replaced with ELF and DWARF. It was apparently possible to have mdebug-in-ELF, which is why elfread.c calls into mdebugread.c, as well as stabs-in-mdebug(-in-ELF), which is why mdebugread.c used to call into stabsread.c (following the stabs removal, mdebugread.c now just errors out when encountering stabs). Here are some pointers to understand the history of this: - David Anderson's note about mdebug, which says "SGI moved on to DWARF2 as its debugging format (as have nearly all modern compilers)" [1] (modern likely meaning anything in the 2000s). - Peter Rowell's (from Third Eye Software) post that explains the history of what became mdebug [2][3]. - The ECOFF spec [4]. - A post on gcc-patches indicating that mdebug for Alpha was obsolete in 2001 [5]. This patch deletes: - mdebugread.c - mdebugread.h - mipsread.c - alpha-mdebug-tdep.c Remove mdebug support stuff from configure.ac. Adjust elfread.c to not call into mdebugread.c anymore. Leave a warning just like we have for stabs. Adjust the Alpha tdep code to not call alpha_mdebug_init_abi anymore. [1] https://www.prevanders.net/#mdebug [2] http://www.datahedron.com/mips.html [3] https://www.prevanders.net/mdebug.html [4] https://web.archive.org/web/20160305114748/http://h41361.www4.hp.com/docs/base_doc/DOCUMENTATION/V50A_ACRO_SUP/OBJSPEC.PDF [5] https://gcc.gnu.org/legacy-ml/gcc/2001-02/msg00389.html Change-Id: I784b19ed802a3af536d208b9f039b927543f0e02 Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: replace struct pending with std::vector Replace `struct pending`, a home-made linked list of chunks of symbols, with `std::vector`. This removes manual memory management and simplifies the code. The change starts by switching m_local_symbols, m_file_symbols and m_global_symbols in buildsym_compunit to be vectors, and propagates from there. ~buildsym_compunit no longer needs to manually free the lists (it did not free m_local_symbols, was it on purpose?). add_symbol_to_list just appends the symbol to the vector. Obviously, this sometimes causes a vector reallocation, but it is amortized O(1) and I did not find that it causes a performance degradation (more details later). We could try to reserve some space in the vectors up front if we had an estimate of how many entries we'll have, but I am not sure we really can have a good idea up front. collate_pending_symbols_by_language iterates the vector backwards to keep the existing behavior. I am not sure if this is actually needed. buildsym_compunit::push_context std::moves m_local_symbols, to avoid copying the contents of the vector. I don't think buildsym_compunit::pop_context needs to change, everything should be efficient thanks to NRVO. Users of buildsym_compunit::pop_context use std::move to move context_stack::locals back to m_local_symbols. There is a non-trivial change in coff_read_enum_type, which I can't test easily. I did the following test to see if this change would have a performance impact: - I added a scoped_time_it in maintenance_expand_symtabs, to measure just that step - I use a build of blender compiled with "-O2 -g" - I run: $ ./gdb -q -nx --data-directory=data-directory -iex 'maint set dwarf sync on' -iex "maint set per-command time on" -ex "file /data1/smarchi/blender/build-RelWithDebInfo-gcc/bin/blender" -ex "maint expand windowmanager" -batch - I record the time taken by maintenance_expand_symtabs Before looks like: Time for "maintenance_expand_symtabs": wall 34.311, user 32.335, sys 1.829, user+sys 34.164, 99.6 % CPU Time for "maintenance_expand_symtabs": wall 34.208, user 32.265, sys 1.800, user+sys 34.065, 99.6 % CPU Time for "maintenance_expand_symtabs": wall 34.420, user 32.378, sys 1.894, user+sys 34.272, 99.6 % CPU After looks like: Time for "maintenance_expand_symtabs": wall 34.316, user 32.342, sys 1.838, user+sys 34.180, 99.6 % CPU Time for "maintenance_expand_symtabs": wall 34.318, user 32.347, sys 1.831, user+sys 34.178, 99.6 % CPU Time for "maintenance_expand_symtabs": wall 34.357, user 32.272, sys 1.943, user+sys 34.215, 99.6 % CPU I also measured the execution of the whole command (with "maint set per-command time off" this time). Before looks like: 116.12user 12.61system 1:30.68elapsed 141%CPU (0avgtext+0avgdata 10707780maxresident)k 116.69user 12.33system 1:31.42elapsed 141%CPU (0avgtext+0avgdata 10709132maxresident)k 116.51user 12.57system 1:30.83elapsed 142%CPU (0avgtext+0avgdata 10729880maxresident)k After looks like: 115.75user 12.03system 1:29.35elapsed 143%CPU (0avgtext+0avgdata 10712348maxresident)k 116.41user 12.58system 1:30.94elapsed 141%CPU (0avgtext+0avgdata 10727488maxresident)k 115.91user 11.90system 1:29.36elapsed 143%CPU (0avgtext+0avgdata 10770412maxresident)k Change-Id: I984fdaf47b9bddd840c033a6c6052b007bdcd13d Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: add constructor to context_stack This makes it clearer what is set up front vs what is set later by callers. Change-Id: I2ee8d053c068f2b9ca37d48834aa688aeb6c0560 Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: make buildsym_compunit return a reference This is more C++-y. Remove the struct keywords from pop_context just to match. Rename "newobj" to "ctx" in the users of context_stack, because I think the "newobj" name is meaningless. For a later task: I think we should find a better name for context_stack, because it is not a stack (it is an entry in the context stack). Change-Id: Ibc66b910ab0f31b367b99812e0469311a99641c9 Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: fix indentation of struct context_stack While at it, fixup some comments, remove unnecessary empty lines, remove unnecessary struct keywords. Change-Id: I67a4c8302dfca46417d5f46f5dc0378a066f80c4 Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: remove context_stack::end_addr It is unused. Change-Id: Ie86448552500a049d47118d0306231da0ef9a5e1 Approved-By: Tom Tromey 2026-01-05 Simon Marchi gdb/buildsym: remove find_symbol_in_list It is unused. Change-Id: Iecc488afeaa123d6ad6e7a2952bb46539ef020a2 Approved-By: Tom Tromey 2026-01-05 Tom Tromey Update copyright dates to include 2026 This updates the copyright headers to include 2026. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. 2026-01-05 Indu Bhagat libsframe: add README and mention expectations libsframe is not meant for consumption by tools external to GNU Binutils. libsframe/ * Makefile.in: Regenerate. * libsframe/README: New file. 2026-01-05 Tom Tromey Fix Ada 'Modulus attribute The internal AdaCore test suite pointed out that my earlier patch to displaying modular types broke the 'Modulus attribute -- it was off-by-one. While fixing this, though, I realized that the earlier 'ptype' problem also affected this attribute. So, this patch implements a similar fix in the parser. This adds some operator+ overloads to gdb_mpz for convenience. That class still doesn't have the full complement of operators -- they are added as needed. 2026-01-05 Tom Tromey Add variable styling to "finish" output "finish" will print a line like: Value returned is $1 = 0 Here, the "$1" is not styled, but in other places, history variables are styled using the "variable" style. This patch corrects the oversight. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33714 2026-01-05 Srinath Parvathaneni aarch64: Add support for POE2 PLBI instruction This patch adds support for PLB invalidate operation (PLBI) instruction and the corresponding system registers as operand (). Syntax: PLBI {, } This instruction is an alias to "SYS #, C10, , #{, }" and PLBI being the preferred disassembly. The following list of system registers are supported in this patch for the PLBI instructions enabled by "+poe2" flag and also the "nxs" variants of these system registers are enabled by "+poe2+xs" flag. * alle1 * alle1is * alle1os * alle2 * alle2is * alle2os * alle3 * alle3is * alle3os * aside1 * aside1is * aside1os * permae1 * permae1is * permae1os * perme1 * perme1is * perme1os * perme2 * perme2is * perme2os * perme3 * perme3is * perme3os * vmalle1 * vmalle1is * vmalle1os 2026-01-05 Srinath Parvathaneni aarch64: Add support for TEV instructions This patch adds support for FEAT_TEV feature enabled by "+tev" flag along with support for following instructions. * TENTER * TEXIT TENTER instruction uses the existing AARCH64_OPND_NOT_BALANCED_17 operand to handle the not_balanced (NB) argument , where as a new operand AARCH64_OPND_NOT_BALANCED_10 is added to support the NB (not_balanced) argument in TEXIT instruction. 2026-01-05 Srinath Parvathaneni Matthew Malcomson aarch64: Add support for POE2 system registers This patch adds support for POE2 system registers which are available by default, however if guarding restrictions are enabled using -menable-sysreg-checking than "+poe2" option need to specified to the -march. 2026-01-05 Srinath Parvathaneni Matthew Malcomson aarch64: Add support for POE2 instructions This patch adds support for FEAT_S1POE2 feature enabled by "+poe2" flag along with support for following instructions. * TCHANGEB (immediate) * TCHANGEB (register) * TCHANGEF (immediate) * TCHANGEF (register) A new operand AARCH64_OPND_NOT_BALANCED_17 is added to the code in this patch to support the new optional argument "NB" (not_balanced) which is a 1-bit field in the encoding for all the above mentioned instructions. 2026-01-05 Tom de Vries [pre-commit] Move tclint.toml settings to pyproject.toml Starting release v0.7.0, tclint has config discovery support, allowing us to move the tclint settings from tclint.toml to pyproject.toml. Approved-By: Tom Tromey 2026-01-05 Tom de Vries [pre-commit] Require pyyaml for pre-commit-setup hook I ran pre-commit in a fresh virtual environment, and ran into pre-commit-setup missing package pyyaml. Fix this by: - changing the language to python, and - adding pyyaml in the additional_dependencies. Approved-By: Tom Tromey 2026-01-05 Tom Tromey Add Ada unhandled exception filter to DAP This adds a way for DAP clients to catch unhandled Ada exceptions, similar to the "catch exception unhandled" CLI command. Reviewed-By: Eli Zaretskii 2026-01-05 Tom Tromey Change handling of over-long DAP variables requests In PR dap/33228, we changed gdb to gracefully report an error if a DAP 'variables' request asked for more variables than had been reported. This behavior was clarified in the spec, see https://github.com/microsoft/debug-adapter-protocol/issues/571 This patch changes gdb to conform to the specified approach, namely truncating the list rather than erroring. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228 Approved-By: Andrew Burgess 2026-01-05 Tom Tromey Fix DAP 'disconnect' implementation gdb's implementation of the DAP 'disconnect' request was incorrect in a few ways. First, the 'terminateDebuggee' field is optional, and has a special meaning when not supplied: it should do whatever the default is. Second, if the inferior was attached, it should detach rather than terminate by default. Finally, if the inferior was not started at all, it seems reasonable for this request to simply succeed silently -- currently it returns "success: false" with the reason being that the inferior isn't running. Approved-By: Andrew Burgess 2026-01-05 GDB Administrator Automatic date update in version.in 2026-01-04 Alan Modra Set ELF_OSABI for x86 and sparc The idea of this patch is to match the solaris target over other targets if e_ident contains ELFOSABI_SOLARIS. The solaris target will continue to recognise ELFOSABI_NONE objects. This has the side effect of disabling gnu features that require ELFOSABI_GNU, such as ifuncs. I think that is correct, so I've made the required testsuite changes to fix the resulting regressions: FAIL: nm --ifunc-chars (assembly) FAIL: mbind sections without SHF_ALLOC The patch also sets ELF_OSABI for the gnu x86 and sparc targets, for the same reason as the solaris targets. This doesn't mean object files will automatically be marked ELFOSABI_GNU/LINUX. As before that will only happen when certain GNU extensions are present. bfd/ * elf32-i386.c: Define ELF_OSABI for solaris and gnu targets. * elf32-sparc.c: Likewise. * elf64-sparc.c: Likewise. * elf64-x86-64.c: Likewise. * format.c (bfd_check_format_matches): Bump match_priority for matching e_ident EI_OSABI. binutils/ * testsuite/binutils-all/nm.exp: Use !supports_gnu_osabi to disable ifunc test. gas/ * testsuite/gas/elf/section13.d: Only run on supports_gnu_osabi targets. Remove xfails. 2026-01-04 Alan Modra ELF OSABI matching Currently a binutils ELF target with ELF_OSABI defined to something other than the default ELFOSABI_NONE will only accept object files with e_ident[EI_OSABI] having the value ELF_OSABI. An ELF target with ELF_OSABI as ELFOSABI_NONE will match any e_ident[EI_OSABI] value, and typically that target's object files will have ELFOSABI_NONE or one other value in e_ident[EI_OSABI]. Given an object file with that "other value" we'd like to be able to choose the correct target but currently have no way to do so. This patch is a step towards implementing better target matching. It does so by adding an ELF_OSABI_EXACT to the target description, setting that true for all targets that currently define ELF_OSABI, and testing the new flag for exact matching. This will allow a future patch to define ELF_OSABI without forcing exact matching but giving a hint as to the best target match. Some other tweaks are done as shown by the changelog below but no user functional changes should be seen with this patch. * elf-bfd.h (struct elf_backend_data): Add osabi_exact. * elf.c (_bfd_elf_final_write_processing): Only set e_ident from elf_osabi when osabi_exact. * elfcode.h (elf_object_p): Test osabi_exact to reject mismatching e_ident. Remove unnecessary EM_NONE test. * elfcore.h (elf_core_file_p): Likewise. * elfxx-target.h (ELF_OSABI_EXACT): Provide default of 0, and init elfNN_bed. (elf_match_priority): Handle ELF_OSABI_EXACT. * elf32-arm.c (ELF_OSABI_EXACT): Define and undef along with ELF_OSABI. * elf32-hppa.c: Likewise. * elf32-i386.c: Likewise. * elf32-mips.c: Likewise. * elf32-ppc.c: Likewise. * elf32-tic6x.c: Likewise. * elf32-visium.c: Likewise. * elf64-alpha.c: Likewise. * elf64-hppa.c: Likewise. * elf64-ia64-vms.c: Likewise. * elf64-mips.c: Likewise. * elf64-ppc.c: Likewise. * elf64-sparc.c: Likewise. * elf64-x86-64.c: Likewise. * elfn32-mips.c: Likewise. * elfnn-ia64.c: Likewise. * elf32-msp430.c: Likewise. Don't define ELF_OSABI to ELFOSABI_NONE. 2026-01-04 Alan Modra elf_backend_data typedef "const struct elf_backend_data" appears many places in the source, and in some cases makes a line too long without wrapping. This patch introduces a "typedef const struct elf_backend_data elf_backend_data;" and uses it throughout binutils sources, with a few exceptions for c++ use of header files. Compact elf_backend_data * elf-bfd.h (struct elf_backend_data): Make arch, elf_osabi, elf_machine_code and target_os bitfields, and reorder. Make maxpagesize, minpagesize, commonpagesize and p_align unsigned int. * elfxx-target.h (elfNN_bed): Reorder to suit. Delete useless comments. 2026-01-04 Alan Modra elf_backend_can_make_multiple_eh_frame This flag is never set for any target. Delete it. Also, I think it is safe to unconditionally enable what it was supposed to control. * elf-bfd.h (struct elf_backend_data): Delete elf_backend_can_make_multiple_eh_frame. * elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Don't define or use. * elflink.c (_bfd_elf_default_action_discarded): Move SHT_GNU_SFRAME check earlier. Return 0 for ".eh_frame" and ".eh_frame.*". 2026-01-04 Alan Modra wasm ELF_TARGET_ID ELF_TARGET_ID is supposed to be an enum elf_target_id. * elf-bfd.h (enum elf_target_id): Add WEBASSEMBLY_ELF_DATA and re-order VAX_ELF_DATA. * elf32-wasm32.c (ELF_TARGET_ID): Use WEBASSEMBLY_ELF_DATA. 2026-01-04 Alan Modra gas style and readability nit * config/obj-elf.c (obj_elf_section): Introduce a variable rather than unreadable line wrapping. ld/deffilep.y tidies Formatting. Replace "sizeof (type)" with "sizeof (*varp)" where that makes sense. Use xcalloc in place of xmalloc+memset. Don't special case xrealloc of NULL pointer, xrealloc handles that fine. 2026-01-04 GDB Administrator Automatic date update in version.in 2026-01-03 Tom de Vries [pre-commit] Change check-gnu-style language to python Currently, the language of pre-commit hook check-gnu-style is script. Change it to python, allowing us to specify termcolor and unidiff as additional_dependencies. 2026-01-03 Tom de Vries [gdb/testsuite] Fix gdb.base/local-env.exp on remote host With host/target board local-remote-host-native.exp and other remote host configurations, and test-case gdb.base/local-env.exp I get: ... (gdb) show environment^M ... (gdb) FAIL: $exp: show environment displayed variable ... The test attempt to detect variable GDB_TEST_ENV_VAR in the environment, which has been set with setenv. This doesn't work with remote host, so declare the test unsupported. Likewise in gdb.base/environ.exp. Tested on x86_64-linux with make-check-all.sh. 2026-01-03 Tom de Vries [gdb/testsuite] Fix gdb.base/gdb11531.exp with m32 PIE With test-case gdb.base/gdb11531.exp and target board unix/-m32/-fPIE/-pie I get: ... (gdb) next^M 34 myrec.x = 5;^M (gdb) FAIL: gdb.base/gdb11531.exp: watchpoint variable triggers at next ... For contrast, with target board unix/-m32 I get instead: ... (gdb) next^M ^M Hardware watchpoint 2: myrec.x^M ^M Old value = 0^M New value = 5^M main () at /data/vries/gdb/src/gdb/testsuite/gdb.base/gdb11531.c:35^M 35 myrec.y = 3.4;^M (gdb) PASS: gdb.base/gdb11531.exp: watchpoint variable triggers at next ... The problem is that the runto_main doesn't set a breakpoint on the same line in both cases. Fix this by using runto "$srcfile:34". [ The underlying problem here is the failure of prologue analysis to deal with get_pc_thunk. But since there's a PR [1] open about this, and the problem is unrelated to the test-case, we work around it. ] Tested on x86_64-linux. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29043 2026-01-03 Tom de Vries [pre-commit] Move codespell-log back to commit-msg stage Commit 7acd390ffd9 ("[pre-commit] Move codespell-log to post-commit") moved the codespell-log hook from the commit-msg to the post-commit stage. This was deemed to make git rebase too slow [1], so move it back to the commit-msg stage. Don't do this using a full revert, to keep unrelated improvements from that commit. Since we use codespell-log to produce warnings rather than errors, running the hook at the commit-msg stage requires us to ignore codespell exit status, and set verbose=true. [1] https://sourceware.org/pipermail/gdb-patches/2025-December/223533.html 2026-01-03 Tom de Vries [gdb/testsuite] Fix another timeout in gdb.mi/mi-multi-commands.exp On aarch64-linux, with a gdb version 16.3 based package, I ran into (edited for readability): ... (gdb) -data-evaluate-expression $a ^done,value="\"FIRST COMMAND\"" (gdb) -data-evaluate-expression $b ^done,value="\"TEST COMPLETE\"" (gdb) PASS: $exp: look for first command output, command length $n FAIL: $exp: look for second command output, command length $n (timeout) ... For contrast, a passing example looks like: ... (gdb) -data-evaluate-expression $a -data-evaluate-expression $b ^done,value="\"FIRST COMMAND\"" (gdb) PASS: $exp: look for first command output, command length $n ^done,value="\"TEST COMPLETE\"" (gdb) PASS: $exp: look for second command output, command length $n ... The setup 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, shown as above. What happens is that gdb, after parsing the first command, executes it, which generates output and a prompt. Then that prompt intermixes with the echoing of the second command, and consequently the matching of the prompt fails. This is very similar to what was fixed in commit 59c9bc5fb6c ("[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp"). Fix this by making the matching of the first prompt optional. While we're at it, make the test-case more readable using {}, string_to_regexp and multi_line_input. PR testsuite/33671 Bug https://sourceware.org/bugzilla/show_bug.cgi?id=33671 2026-01-03 GDB Administrator Automatic date update in version.in 2026-01-02 GDB Administrator Automatic date update in version.in 2026-01-01 Alan Modra Solaris .strtab and .shstrtab flags These sections have SHF_STRINGS in sh_flags on Solaris. Commit 84865015459b in part implemented this variation by an elf_backend_data field used to set the flags, but that only works of course if one of the solaris targets is used. Which in some ways is fair enough. If you want solaris support then it is reasonable to require the solaris targets to be compiled in. However if they are not the default, other ELF targets may be used even when the solaris targets are compiled in, because many ELF targets allow any ELFOSABI object to match. (Which is arguably a bug.) So instead of the current scheme this patch implements the solaris specific sh_flags in _bfd_elf_final_write_processing. That way either a solaris target being used, or ELFOSABI_SOLARIS in the object will get the correct sh_flags. PR 19938 * elf-bfd.h (struct elf_backend_data): Delete elf_strtab_flags. * elf.c (_bfd_elf_final_write_processing): Handle solaris peculiarities here. (_bfd_elf_compute_section_file_positions): Leave shstrtab sh_flags zero, and don't re-zero other fields. (swap_out_syms): Similarly for sym strtab. * elflink.c (_bfd_elf_final_link): Likewise. * elf32-i386.c (elf_backend_strtab_flags): Don't define. * elf32-sparc.c: Likewise. * elf64-sparc.c: Likewise. * elf64-x86-64.c: Likewise. * elfxx-target.h: Likewise. 2026-01-01 Alan Modra gas .xstabs missing string results in a segfault Found by oss-fuzz. * stabs.c (s_xstab): Check result of demand_copy_C_string. (s_stab_generic): Remove duplicate warning and ignore_r_o_l after demand_copy_C_string error. 2026-01-01 Alan Modra ld config targ_extra_emuls and targ_extra_libpath There is no need to duplicate targets in these variables, one or the other is sufficient. This patch removes such duplication but otherwise makes no user visible changes. Quite likely some targets ought to be in targ_extra_emuls rather than targ_extra_libpath. * configure.tgt: Don't duplicate targ_extra_libpath targets in targ_extra_emuls, and similarly for targ64 variants. 2026-01-01 Alan Modra Update year range in copyright notice of binutils files Avoid warnings about invalid escapes in etc/update-copyright.py by using raw strings, add BinutilsFilter to skip psql.rc and add "Kalray SA." as another copyright holder. 2026-01-01 GDB Administrator Automatic date update in version.in 2025-12-31 Andre Vieira arm, as: Support case incensitive VLDR/VSTR SYSREG To be consistent with VMRS/VMSR this changes VLDR/VSTR SYSREG to support case insensitive system register operands. 2025-12-31 GDB Administrator Automatic date update in version.in 2025-12-30 GDB Administrator Automatic date update in version.in 2025-12-29 Alice Carlotti aarch64: Remove sme2_movaz instruction class The behaviour of sme2_movaz was identical to sme_misc, so use that instead. aarch64: Remove a space from movaz za operand The za operands of most movaz instructions were originally printed with an extra space compared to other za operands. Remove this space, and reduce code duplication in the process. aarch64: Accept .b/.h/.s in movaz (array to vector) While the .d form is preferred for disassembly, assemblers should accept any element size that is used consistently. The sme2_mov class handles this already for mov instructions, so use that here as well. aarch64: Fix luti2/luti4 decode mask Neither the opcode mask nor the size determination were checking bit 13, so some undefined opcodes were being incorrectly disassembled as valid luti2/luti4 instructions. 2025-12-29 Rainer Orth bfd: Re-enable 64-bit support for 32-bit Solaris targets One of the recent Solaris patches removed want64=true from the 32-bit Solaris targets. This breaks GCC bootstrap: unlike Linux, GCC on Solaris is always biarch, both in 32-bit-default and 64-bit-default configurations, so the 64-bit multilib fails to build. This patch undoes this incompatible change. Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. 2025-12-24 Rainer Orth bfd: * config.bfd (want64): Add. : Likewise. 2025-12-29 GDB Administrator Automatic date update in version.in 2025-12-28 GDB Administrator Automatic date update in version.in 2025-12-27 Sivan Shani AArch64 v9.7 extensions: FEAT_SVE_B16MM This patch includes: - Feature flag for FEAT_SVE_B16MM - Instruction: - BFMMLA (non-widening) BFloat16 matrix multiply-accumulate. AArch64 v9.7 extensions: FEAT_F16MM This patch includes: - Feature flag for FEAT_F16MM - Instructions: - FMMLA (non-widening) Half-precision matrix multiply-accumulate - FMMLA (non-widening) Floating-point matrix multiply-accumulate AArch64: Add FEAT_F16F32MM This patch includes: - The feature flag for the FEAT_F16F32MM feature. - Instruction FMMLA Half-precision matrix multiply-accumulate to single-precision. AArch64: Add FEAT_F16F32DOT instructions This includes the instructions for the F16F32DOT feature: - FDOT half-precision to single-precision, by element - FDOT half-precision to single-precision, vector 2025-12-27 Sivan Shani AArch64: Add FEAT_SVE2p3 and FEAT_SME2p3 instructions. This patch includes: - Flags for the FEAT_SVE2p3 and FEAT_SME2p3 features. - Instructions: - ADDQP - ADDSUBP - FCVTZSN - FCVTZUN - LUTI6 16-bit - LUTI6 8-bit - SABAL - SCVTF - SCVTFLT - SDOT vectors - SDOT indexed - SQRSHRN - SQRSHRUN - SQSHRN - SQSHRUN - SUBP - UABAL - UCVTF - UCVTFLT - UDOT vectors - UDOT indexed - UQRSHRN - UQSHRN - LUTI6 vector - LUTI6 table, four registers - LUTI6 table, single, 8-bit In addition, new operands: - OPND_SME_Zmx2_INDEX_22: an operand represents a list of vector registers with an index. - OPND_SME_Zn7xN_UNTYPED: an operand represents an untyped list of vector registers. 2025-12-27 Yury Khrustalev aarch64: Add tests for FEAT_MOPS_GO instructions aarch64: Add FEAT_MOPS_GO instructions Also add +mops-go feature flag and make the mops-go feature depend on the memtag and mops features. 2025-12-27 GDB Administrator Automatic date update in version.in 2025-12-26 Alan Modra Re: bfd ASSOCIATED_VECS What I committed in f4e835a40c wasn't wrong but it wasn't elegant. Unlike looking for a word separated by spaces, it isn't necessary to prepend and append the separators in the match string. * configure.ac (assocvecs): Tidy uniquify code. * configure: Regenerate. 2025-12-26 Alan Modra PR 33726, symbols in excluded sections This improves "nearby" section choice when memory regions are active, preferring a section in the same region as the excluded section over other sections. PR 33726 include/ * bfdlink.h (struct bfd_link_callbacks): Add nearby_section. (_bfd_nearby_section): Delete. (bfd_fix_excluded_sec_syms): Rename and remove bfd param from _bfd_fix_excluded_sec_syms. bfd/ * linker.c (_bfd_nearby_section): Delete. (fix_syms): Use linker callback. * elflink.c (elf_link_input_bfd): Likewise. (_bfd_elf_final_link): Update. ld/ * ldemul.c (finish_default): Update. * ldlang.c (lang_output_section_get): Delete. (ldlang_nearby_section): New function. * ldlang.h (ldlang_nearby_section): Declare. (lang_output_section_get): New static inline. * ldmain.c (link_callbacks): Add ldlang_nearby_section. 2025-12-26 GDB Administrator Automatic date update in version.in 2025-12-25 Jan Vrany Revert "gdb: change blockvector::contains() to handle blockvectors with "holes"" This reverts commit cc1fc6af4150b19f9c4c70d0463ff498703fb637, since it causes a number of regressions that seem not to be easily fixable. The problem lies in existence of "freestanding" code, a code that is part of a CU but does not have any block associated with it. Consider following program: __asm__( ".type foo,@function \n" "foo: \n" " mov %rdi, %rax \n" " ret \n" ); static int foo(int i); int main(int argc, char **argv) { return foo(argc); } When compiled, the foo function has no block of itself: Blockvector: no map block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148 int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 section .text block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols in 0x1129..0x1148 typedef int int; typedef char char; block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbols in 0x112d..0x1148, function main int argc; computed at runtime char **argv; computed at runtime In this case lookup(0x1129) returns static block and, because of the change in cc1fc6af4, contains(0x1129) which is wrong. Such "freestanding" code is perhaps not common but it does exist, especially in system code. In fact the regressions were at least in part caused by such "freestanding" code in glibc (libc_sigaction.c). The whole idea of commit cc1fc6af4 was to handle "holes" in CUs, a case where one CU spans over multiple disjoint regions, possibly interleaved with other CUs. Consider somewhat extreme case with two CUs: /* hole-1.c */ int give_me_zero (); int main () { return give_me_zero (); } /* hole-2.c */ int __attribute__ ((section (".text_give_me_one"))) __attribute__((noinline)) baz () { return 42; } __asm__( ".section .text_give_me_one,\"ax\",@progbits\n" ".type foo,@function \n" "foo: \n" " mov %rdi, %rax \n" " ret \n" " nop \n" " nop \n" " nop \n" ); int __attribute__ ((section (".text_give_me_one"))) __attribute__((noinline)) give_me_one () { return 1; } __asm__( ".section .text_give_me_zero,\"ax\",@progbits\n" "bar: \n" " jmp give_me_one \n" " nop \n" " nop \n" " nop \n" ); int __attribute__ ((section (".text_give_me_zero"))) give_me_zero () { extern int bar(); return give_me_one() - 1; } This when compiled with a carefully crafted linker script to force code at certain positions, creates following layout: 0x080000..0x080007 # "freestanding" bar from hole-2.c 0x080008..0x080016 # give_me_zero() from hole-2.c 0x080109..0x080114 # main from hole-1.c 0xf00000..0xf0000b # baz() from hole-2.c 0xf0000b..0xf00011 # "freestanding" foo from hole-2. 0xf0000b..0xf0001c # gice_me_one() from hole-2. The block vector for hole-1.c looks: Blockvector: no map block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114 int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section .text block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols in 0x80109..0x80114 typedef int int; block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbols in 0x80109..0x80114, function main And for hole-2.c: Blockvector: map 0x0 -> 0x0 0x80008 -> 0x555a5d85ff50 0x80016 -> 0x0 0xf00000 -> 0x555a5d860280 0xf0000b -> 0x0 0xf00012 -> 0x555a5d860110 0xf0001d -> 0x0 block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 section .text int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d section .text int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section .text block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols in 0x80008..0xf0001d typedef int int; block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbols in 0xf00000..0xf0000b, function baz block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one Note that despite the fact "freestanding" bar belongs to hole-2.c, the corresponding CU's global and static blocks start at 0x80008! Looking at DWARF for the second program, it looks like that the compiler (GCC 15) did not record the presence of "freestanding" code: <0><71>: Abbrev Number: 1 (DW_TAG_compile_unit) <72> DW_AT_producer : (indirect string, offset: 0): GNU C23 15.2.0 -mtune=generic -march=x86-64 -g -fasynchronous-unwind-tables <76> DW_AT_language : 29 (C11) <77> Unknown AT value: 90: 3 <78> Unknown AT value: 91: 0x31647 <7c> DW_AT_name : (indirect line string, offset: 0x2d): hole-2.c <80> DW_AT_comp_dir : (indirect line string, offset: 0): test_programs <84> DW_AT_ranges : 0xc <88> DW_AT_low_pc : 0 <90> DW_AT_stmt_list : 0x51 and corresponding part of .debug_aranges: Length: 76 Version: 2 Offset into .debug_info: 0x65 Pointer Size: 8 Segment Size: 0 Address Length 0000000000f00000 000000000000000b 0000000000f00012 000000000000000b 0000000000080008 000000000000000e 0000000000000000 0000000000000000 Thiago suggested to use minsymbols to tell whether or a CU contains given address. I do not think this would work reliably as minsymbols do no know to which CU they belong. In slightly more complicated case of interleaved CUs it does not seem to be possible to tell for sure to which one a given minsymbol belongs. Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sect (which led to cc1fc6af4) may be outdated [2]. Given all that, I'm just reverting the change. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=33679#c13 [2]: https://inbox.sourceware.org/gdb-patches/87cy6xzd3j.fsf@tromey.com/ Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33679 2025-12-25 GDB Administrator Automatic date update in version.in 2025-12-24 Indu Bhagat gas: sframe: reset fp_reg to SFRAME_FRE_REG_INVALID It makes sense to keep all internal state related to registers (cfa_base_reg, fp_reg) reset to SFRAME_FRE_REG_INVALID. While at it, also make sure fp_reg state is copied over when intializing an SFrame FRE. gas/ * gen-sframe.c (sframe_row_entry_new): Reset to SFRAME_FRE_REG_INVALID. (sframe_row_entry_initialize): Copy over fp_reg too. (sframe_xlate_do_offset): Adjust accordingly. 2025-12-24 Indu Bhagat gas: sframe: rename "bp" to "fp" Reviewed-by: Jens Remus 2025-12-24 Indu Bhagat libsframe: refactor out sframe_fre_grow_tbl Usage of a global int number_of_entries is likely unnecessary. The same global is used for growing the FDE tbl too, when adding FDEs. At the moment, however, carve out a new function to grow the FRE table, and use a macro instead of 'number_of_entries'. This refactoring helps provide basis for a later patch where we add SFrame FREs in bulk instead of one at a time to the SFrame encoder object. Reviewed-by: Jens Remus libsframe/ * sframe.c (SFRAME_FRE_ALLOC_LEN): New definition. (sframe_grow_fre_tbl): New definition. (sframe_encoder_add_fre): Use the new function. 2025-12-24 Indu Bhagat libsframe: use tmp variable for realloc pattern If realloc fails, the original buffer isnt free'd otherwise. Reviewed-by: Jens Remus libsframe/ * sframe.c (sframe_encoder_add_fre): Use tmp variable. (sframe_encoder_add_funcdesc_internal): Likewise. 2025-12-24 Indu Bhagat libsframe: refactor sframe_decoder_add_funcdesc for internal use sframe_encoder_add_funcdesc () was added for SFRAME_VERSION_1. This has since been obsoleted by introduction of SFRAME_VERSION_2 and its corresponding sframe_decoder_add_funcdesc_v2 API. Refactor the functionality into an internal-only API: sframe_encoder_add_funcdesc_internal (). Ensure it returns the error code for the caller to take necessary action or pass to user. Keep only two args for sframe_encoder_add_funcdesc: function size and function start addr. This simple barebone API will be used in a subsequent commit to adjust the link-time behaviour of SFrame sections. Reviewed-by: Jens Remus include/ * sframe-api.h (sframe_encoder_add_funcdesc): Remove args to create the barebone API. libsframe/ * sframe.c (sframe_encoder_add_funcdesc): Refactor out into sframe_encoder_add_funcdesc_internal. Change args. (sframe_encoder_add_funcdesc_v2): Use the new internal API. * libsframe.ver: Move sframe_encoder_add_funcdesc to 2.1 node. 2025-12-24 Indu Bhagat gas: sframe: refactor out the offsets emission code Minor refactoring. Carve out the SFrame FRE offsets emission code into a new output_sframe_row_entry_offsets (). This change helps prepare for later supporting a new FDE type in SFrame V3. Reviewed-by: Jens Remus gas/ * gen-sframe.c (output_sframe_row_entry_offsets): New definition. (output_sframe_row_entry): Use the new definition. 2025-12-24 Indu Bhagat gas: sframe: pass SFrame FDE as argument to output_sframe_row_entry Minor refactoring. Will be needed later for supporting flexible topmost frames in SFrame V3. Reviewed-by: Jens Remus gas/ * gen-sframe.c (output_sframe_row_entry): Use new argument. (output_sframe_internal): Likewise. 2025-12-24 Indu Bhagat gas: sframe: add new sframe_xlate_ctx_get_cur_cfa_reg Purely cosmetic change. Reviewed-by: Jens Remus gas/ * gen-sframe.c (sframe_xlate_ctx_get_cur_cfa_reg): New definition. (sframe_xlate_do_def_cfa_offset): Use it. (sframe_xlate_do_escape_expr): Likewise. (sframe_xlate_do_escape_gnu_args_size): Likewise. 2025-12-24 Indu Bhagat gas: libsframe: use SFRAME_V2_* macro where available No functional change. Reviewed-by: Jens Remus gas/ * sframe-opt.c (sframe_convert_frag): Use SFRAME_V2_ prefixed macro instead. libsframe/ * sframe-dump.c (dump_sframe_func_with_fres): Likewise. * sframe.c (sframe_get_fre_type): Likewise. (sframe_get_fde_type): Likewise. (sframe_fre_check_range_p): Likewise. (sframe_fde_create_func_info): Likewise. 2025-12-24 Indu Bhagat include: sframe: add SFRAME_V2_ prefixed macro names for FDE Such a change for readability only. SFrame V1 is now obsolete, and with newer versions like V3 or later, its likely better to have macro names reflect the applicable version. Add new macro names for FDE information related macros. Reviewed-by: Jens Remus include/ * sframe.h (SFRAME_V2_FUNC_INFO): New definition. (SFRAME_V2_FUNC_FRE_TYPE): Likewise. (SFRAME_V2_FUNC_PC_TYPE): Likewise. (SFRAME_V2_FUNC_PAUTH_KEY): Likewise. (SFRAME_V2_FUNC_INFO_UPDATE_PAUTH_KEY): Likewise. 2025-12-24 Indu Bhagat libsframe: implement an internal-only SFrame FDE representation Up until now, libsframe has used the same SFrame FDE representation as the on-disk representation (sframe_func_desc_entry). The choice made by the author of the library, back when it was first contributed, perhaps sufficed the needs then. But looking forward, we need to be able to allow reading and dumping out of not just sections with version SFRAME_VERSION_2 but also future supported versions. Note that libsframe did not (and still does not) expose the SFrame FDE representation in any public APIs; doing so is not recommended. For the path forward, create an internal-only SFrame FDE representation (sframe_func_desc_entry_int). libsframe now keeps all in-memory FDEs of type sframe_func_desc_entry_int. Doing so means instead of memcpy, we need to resort to member-by-member mapping. This can be seen in sframe_fde_tbl_init (read time) and the new function sframe_encoder_write_fde (write time). Other than that, replace out the previous direct interaction with on-disk format when: - flipping SFrame contents before decoding them in sframe_decode. - flipping SFrame contents before writing them out in sframe_encode. Reviewed-by: Jens Remus 2025-12-24 GDB Administrator Automatic date update in version.in 2025-12-23 Indu Bhagat include: gas: bfd: sframe: clean the abstraction ... between specification and implmentation. Move to definition in the implementation (gas/ld/libsframe) and not the specification (include/sframe.h). At this time the implementation in gas and ld generate the sections in the latest SFrame version only. Reviewed-by: Jens Remus bfd/ * elf-sframe.c: Add definition here. gas/ * gen-sframe.c: Likewise. libsframe/ * sframe.c: Likewise. include/ * sframe.h: Remove the definition. 2025-12-23 Indu Bhagat gas: sframe: ignore .cfi_offset for RA selectively For ABIs not tracking RA (e.g., AMD64), the return address is expected to be in a specific location (usually a fixed offset from CFA on stack). Explicit manourvering to a different offset may be non-representable in SFrame, and should not be simply ignored. Although such patterns are not usually seen in the wild, it is more correct to catch them if at all they manifest. Reviewed-by: Jens Remus gas/ * gen-sframe.c (sframe_xlate_do_offset): Do not ignore .cfi_offset for RA all the time. 2025-12-23 Indu Bhagat Revert "gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking" This reverts commit df174a6b760. commit df174a6b760ac5c66ee62ecb872c760ae21fd4cd Date: Thu Jul 4 10:34:12 2024 +0200 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. Even for ABI/arch without RA tracking, there may be instances where user may specify '.cfi_register RA, reg'. This needs to be caught, skipping this from SFrame generation may not be correct. This may be done in certain hand-written asm sequences where the user needs to manipulate the return to a certain function. No testcase is being added ATM because in SFrame V3, a new FDE type can be used to represent such cases (A new test case will be added then). Reviewed-by: Jens Remus 2025-12-23 Matthieu Longo gas: add as_info() for informational diagnostics This patch adds as_info(), a shortened version of as_info_where(), for emitting informational diagnostics from Gas. This new helper provides the same formatting and source location handling as as_info_where(), while offering a simpler interface for the common case. It respects the --no-info flag, and supports indentation in the same way as its sibling. 2025-12-23 Andrew Burgess gdb: allow 'set args' and run commands to contain newlines When starting GDB it is possible to set an inferior argument that contains a newline, for example: shell> gdb --args my.app "abc > def" ... (gdb) show args Argument list to give program being debugged when it is started is "abc' 'def". However, once GDB is started, the only way to install an argument containing a newline is to use the Python API. This commit changes that. After this commit 'set args' as well as 'run', 'start', and 'starti', will now accept multi-line inferior arguments, e.g.: (gdb) set args "abc > def" (gdb) show args Argument list to give program being debugged when it is started is ""abc def"". And also: (gdb) run "abc > def" ... etc ... Once GDB has presented the secondary prompt to gather the remaining inferior arguments then it is possible for the user to quit argument entry by sending SIGINT (usually, Ctrl-c), or sending EOF (usually, Ctrl-d). For the 'set args' case this will abort the argument change, leaving the arguments as they were previously. For the run style commands, this aborts the run command completely, the inferior is not changed, and the partially collected arguments are not installed. On Unix hosts, arguments can be wrapped with either single or double quotes, while on MS-Windows hosts, arguments can only be wrapped with double quotes. This gives the expected behaviour when native debugging, but isn't entirely accurate. If a user is cross debugging between Unix and MS-Windows then the host machine will determine which set of quotes is valid, which will then be incorrect for the actual target machine. This should probably be fixed in the future, but isn't something I plan to fix immediately. If this patch is accepted, then I can create a bug to track this issue. Reviewed-By: Eli Zaretskii Tested-By: Guinevere Larsen 2025-12-23 Matthieu Longo loongarch: add back support for object attributes v1 A previous commit [1] mistakenly removed support for Object Attributes for LoongArch targets. This patch adds back the OA feature into Gas for the LoongArch targets following the new approach which consists in: - defining TC_OBJ_ATTR to 1 in tc-loongarch.h - enabling the compilation of obj-elf-attr.c in gas/configure.ac [1]: 28a51085ae59fdb530fbdce1e2a7d160667e3007 2025-12-23 GDB Administrator Automatic date update in version.in 2025-12-22 Tom Tromey Use gdb_bfd_sections in more places I found a few spots still iterating over sections using "->next", and thought it would be a little cleaner to use gdb_bfd_sections instead. In one spot the loop indentation turned out to be wrong as well. 2025-12-22 Tom Tromey Remove rust_parser::get_string Now that struct stoken has been replaced with string_view, rust_parser::get_string doesn't provide much value. In some places it can even be replaced with a direct use of the string_view. Approved-By: Simon Marchi 2025-12-22 Tom Tromey Don't use stoken in rust-parse.c I wanted to change rust-parse.c to use string_view and not stoken. This was simple enough, but it seemed good to also change parser_state::push_dollar to use string_view; and as it turned out, this simplified the code a little. Approved-By: Simon Marchi 2025-12-22 Tom Tromey Use string_view in user_reg_map_name_to_regnum This changes user_reg_map_name_to_regnum to use std::string_view. This pointed out some dead code in that function: the "len < 0" test in the loop can never be true, because earlier code changes 'len' in this case. Approved-By: Simon Marchi 2025-12-22 Tom Tromey Fix --help output In commit 9e69a2e127940cc5, which introduced "command" styling, I accidentally made gdb's --help output mention the "stream" command, rather than the "help" command. While doing this I also found a spot where --help output was incorrectly formatted. This patch fixes this as well. I'm going to backport this to the gdb-17 branch as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33737 2025-12-22 Guinevere Larsen gdb/reverse: force direction to forward when stopping record If a user had set the execution direction to reverse, and then they use the command "record stop", the execution direction will be cached as reversed, which will affect some warning messages, and can confuse users. This commit fixes this by forcing the execution direction to "forward" when the command "record stop" is executed. Approved-By: Guinevere Larsen 2025-12-22 Hannes Domani Fix crash when breakpoint condition causes inferior exit When using a breakpoint condition that causes an inferior exit, gdb crashes with a null pointer access: (gdb) b main if callexit() Breakpoint 1 at 0x114b: file callexit.c, line 32. (gdb) r Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [Inferior 1 (process 218586) exited normally] ../../gdb/infcall.c:895:50: runtime error: member call on null pointer of type 'struct thread_fsm' ../../gdb/infcall.c:895:50: runtime error: member access within null pointer of type 'struct thread_fsm' Fix this by checking the thread_fsm pointer beforehand, now the result looks like this: (gdb) b main if callexit() Breakpoint 1 at 0x114b: file callexit.c, line 32. (gdb) r Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [Inferior 1 (process 220707) exited normally] ❌ Error in testing condition for breakpoint 1: The program being debugged exited while in a function called from GDB. Evaluation of the expression containing the function (callexit) will be abandoned. ❌ No registers. (gdb) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16156 Approved-By: Andrew Burgess 2025-12-22 Hannes Domani Fix crash if breakpoint commands contain detach or kill If breakpoint commands contain detach or kill, then gdb tries to access freed memory: (gdb) b main Breakpoint 1 at 0x111d: file main.c, line 21. (gdb) commands Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >detach >end (gdb) run Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". main () at main.c:21 21 return 0; [Inferior 1 (process 241852) detached] ================================================================= ==241817==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b7a3de0b760 at pc 0x55fcb92613fe bp 0x7ffec2d524f0 sp 0x7ffec2d524e0 READ of size 8 at 0x7b7a3de0b760 thread T0 #0 0x55fcb92613fd in bpstat_do_actions_1 ../../gdb/breakpoint.c:4898 #1 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012 #2 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71 #3 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769 0x7b7a3de0b760 is located 0 bytes inside of 56-byte region [0x7b7a3de0b760,0x7b7a3de0b798) freed by thread T0 here: #0 0x7f1a43522a2d in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:155 #1 0x55fcb925d5cd in bpstat_clear(bpstat**) ../../gdb/breakpoint.c:4646 #2 0x55fcbb69ea6a in clear_thread_inferior_resources ../../gdb/thread.c:185 #3 0x55fcbb69f4cb in set_thread_exited(thread_info*, std::optional, bool) ../../gdb/thread.c:244 #4 0x55fcba368d64 in operator() ../../gdb/inferior.c:269 #5 0x55fcba375e2b in clear_and_dispose > ../../gdb/../gdbsupport/intrusive_list.h:529 #6 0x55fcba368f19 in inferior::clear_thread_list() ../../gdb/inferior.c:265 #7 0x55fcba3694ba in exit_inferior(inferior*) ../../gdb/inferior.c:322 #8 0x55fcba369e35 in detach_inferior(inferior*) ../../gdb/inferior.c:358 #9 0x55fcba319d9f in inf_ptrace_target::detach_success(inferior*) ../../gdb/inf-ptrace.c:214 #10 0x55fcba56a2f6 in linux_nat_target::detach(inferior*, int) ../../gdb/linux-nat.c:1582 #11 0x55fcba62121c in thread_db_target::detach(inferior*, int) ../../gdb/linux-thread-db.c:1381 #12 0x55fcbb5ca49e in target_detach(inferior*, int) ../../gdb/target.c:2557 #13 0x55fcba356ba4 in detach_command(char const*, int) ../../gdb/infcmd.c:2894 #14 0x55fcb9597eea in do_simple_func ../../gdb/cli/cli-decode.c:94 #15 0x55fcb95b10b5 in cmd_func(cmd_list_element*, char const*, int) ../../gdb/cli/cli-decode.c:2831 #16 0x55fcbb6f5282 in execute_command(char const*, int) ../../gdb/top.c:563 #17 0x55fcb95eedb9 in execute_control_command_1 ../../gdb/cli/cli-script.c:526 #18 0x55fcb95f04dd in execute_control_command(command_line*, int) ../../gdb/cli/cli-script.c:702 #19 0x55fcb9261175 in bpstat_do_actions_1 ../../gdb/breakpoint.c:4940 #20 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012 #21 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71 #22 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769 previously allocated by thread T0 here: #0 0x7f1a435218cd in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:86 #1 0x55fcb927061f in build_bpstat_chain(address_space const*, unsigned long, target_waitstatus const&) ../../gdb/breakpoint.c:5880 #2 0x55fcba3d63b6 in handle_signal_stop ../../gdb/infrun.c:7083 #3 0x55fcba3d01c7 in handle_inferior_event ../../gdb/infrun.c:6574 #4 0x55fcba3b9918 in fetch_inferior_event() ../../gdb/infrun.c:4713 This checks after executing commands of each breakpoint if the bpstat was deleted already, and stops any further processing immediately. Now the result looks like this: (gdb) b main Breakpoint 1 at 0x111d: file main.c, line 21. (gdb) commands Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >detach >end (gdb) run Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". main () at main.c:21 21 return 0; [Inferior 1 (process 242940) detached] (gdb) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14354 Approved-By: Andrew Burgess 2025-12-22 Jan Beulich gas: stub out sframe-opt.c functions when SFrame is not supported Much like everything in gen-sframe.c, these functions are supposed to never be reached when SFrame isn't supported by a target. Adding respective assertions reduces code size for such targets, while at the same time adding consistency checking for targets which optionally support the feature. gas/x86: reduce / correct target checks for --64 command line option First, pei-x86-64 is meaningless for gas; it's a linker output target, not one object files would use. Next, coff-x86-64 is meaningless for TE_PE (and really coff-x86-64 isn't currently provided by any libbfd configuration anyway). Then, of the three ones left exactly one is a possible candidate for a given gas configuration. Checking others as well would only lead to (possibly cryptic) errors later. And finally, even for ELF we want to check for the one target which i386_target_format() would also use. This last aspect then applies to --x32 handling as well (just that there it's benign right now, as only one target exists starting "elf32-x86-64". 2025-12-22 Jan Beulich gas/CFI: fix .cfi_escape parsing when equates are in use The restoring of the line pointer needs to happen in more cases. While there also adjust a slightly misleading comment. Reviewed-by: Jens Remus 2025-12-22 GDB Administrator Automatic date update in version.in 2025-12-21 GDB Administrator Automatic date update in version.in 2025-12-20 Alan Modra Add back non-solaris ELF targets to solaris config This reverses some of the changes made in config.bfd for PR 27666. Removing targets for that PR was really just a workaround, and since the underlying bug is now fixed they can be added back. I chose to add the non-solaris ELF targets to the linker config using targ_extra_emuls rather than targ_extra_libpath because someone using the elf32_sparc emulation probably doesn't want to pick up solaris libraries by accident. PR 33374 bfd/ * config.bfd: Remove pr27666 comments. Add back non-solaris ELF targets to selvecs for solaris targets. ld/ * configure.tgt: Adjust solaris targets to suit config.bfd change. 2025-12-20 Indu Bhagat libsframe: testsuite: fix build failure Previous commit 4651bea1193 to fix PR ld/32789 missed making the necessary changes to the libsframe testsuite. libsframe/testsuite/ PR ld/32789 PR libsframe/33731 * libsframe.encode/encode-1.c: Add additional arg for sorting FDEs. Set to true. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. 2025-12-20 Indu Bhagat bfd: include: sframe: fix PR ld/32789 Currently, when SFrame sections are emitted after linking the input SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for relocatable links has no effect (SFrame FDEs remain in place), because the start PC is unrelocated data. For relocatable links, then, the emitted SFrame FDEs in the output section remain in the same order as that in the respective input BFD. The assembler does not guarantee the emission of SFrame FDEs in the same order as the placement of the associated .text* sections, (SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS). This means setting SFRAME_F_FDE_SORTED by the linker was wrong when: - doing relocatable link, and - the input bfds contain multiple .text sections, say .text.hot, .text.init, .text.unlikely etc. For relocatable links, skip sorting the SFrame FDEs. Do not set SFRAME_F_FDE_SORTED for relocatable links. This is achieved by adding an explicit argument (bool sort_fde_p) to the sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this is an ABI-incompatible change. Skip bumping the "current" in libsframe/libtool-version ATM, we will do so closer to release. When writing of SFrame data for PLT entries, indicate sort_fde_p to false: these sections are like the other SFrame sections for any other ET_REL binary. Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for all ABIs supported for SFrame. In this test, for object file generated for pr32789-1a.c: - the emitted SFrame FDEs by GAS are in the order of the .text* in the input assembly (i.e., .text.init, .text, .text.exit) - the emitted .text* sections by GAS are placed in the following order .text, .text.init, .text.exit. - GAS does not set SFRAME_F_FDE_SORTED, as expected. Reviewed-by: Jens Remus bfd/ PR ld/32789 * elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the SFrame FDEs for relocatable links. * elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional argument to sframe_encoder_write. * elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise. libsframe/ * libsframe.ver: Move from 2.0 node to 2.1. * sframe.c (sframe_encoder_write_sframe): Conditionalize based on argument sort_fde_p. (sframe_encoder_write): New argument to indicate whether SFrame FDEs are to be sorted in output. include/ * sframe-api.h (sframe_encoder_write): New argument. ld/testsuite/ PR ld/32789 * ld/testsuite/ld-sframe/sframe.exp: New test. * ld/testsuite/ld-sframe/pr32789-1.rd: New test. * ld/testsuite/ld-sframe/pr32789-1.sd: New test. * ld/testsuite/ld-sframe/pr32789-1a.c: New test. * ld/testsuite/ld-sframe/pr32789-1b.c: New test. * ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove SFRAME_F_FDE_SORTED. 2025-12-20 Alan Modra ld targ_extra_emuls and targ_extra_libpath targ_extra_libpath are for those targets other than the default target that might have libraries available in the default library search paths. targ_extra_emuls are for those targets that likely don't. Sort them so those on the libpath come first. This currently does not have any effect except for order of compilation of e*.c and the order printed in ld help messages, but I thought it worth doing anyway. * configure.ac (all_emuls): Sort targ_extra_libpath before targ_extra_emuls. * configure: Regenerate. 2025-12-20 Alan Modra more solaris config tidies This patch is primarily about making ld and bfd config match for solaris targets. In commit 3677b7296185 I made the bfd config match the ld config, which resulted in PR 27666. This goes the other way, changing the ld config to match bfd. The current mismatch results in failures like: ..ld-new: target elf32-i386 not found FAIL: Build libgot-1-i386.so The problem is that even though the elf32-i386 target is compiled in to bfd, it is excluded from the list of targets supported by bfd. ld -V says it is there, but can't use it.. Secondarily, remove "want64" from the 32-bit x86 and sparc solaris targets in config.bfd, and arrange for ld/configure.tgt to match that by using targ64_extra_emuls. This means that on a 32-bit host you won't get the 64-bit solaris target support by default. Setting "want64" forces use of 64-bit bfd_vma on such hosts, which usually isn't needed for a 32-bit target, and when "want64" is true it is a little odd to see targ64_selvecs used. Also, some nonsense has crept in to ld/configure.tgt regarding targ_extra_libpath. Any target mentioned in targ_extra_libpath does not need to be mentioned in targ_extra_emuls. So tidy that for solaris. Finally, matching of solaris targets has been simplified. This does not change target triple matching, except with --enable-obsolete. Without --enable-obsolete, you will still need to specify solaris2.10 or solaris2.11 as the operating system part of the target triple, and this is expected to become permanent after the next binutils release. PR 27666 bfd/ * config.bfd: Simplify solaris target matching. Remove "want64" from x86 and 32-bit sparc solaris targets. ld/ * configure.tgt: Remove non-solaris targets from the x86 and 32-bit sparc solaris targets, and use targ64 variables to add conditional 64-bit targets. Don't unnecessarily add targets to targ_extra_emuls that appear in targ_extra_libpatch. Simplify solaris target matching. 2025-12-20 Alan Modra bfd ASSOCIATED_VECS Tidy code setting ASSOCIATED_VECS, which could be fooled by unusual configure options such as --enable-targets="srec,all". * targets.c (_bfd_associated_vector): Remove comma after ASSOCIATED_VECS. * configure.ac: Set assocvecs from targ_defvec and targ_selvecs when handling the target, rather than assuming those variables are still set for the target when handling --enable-targets=all. Move code making assocvecs unique later. Do so in a way that need not run sed afterwards, and leave a trailing comma. * configure: Regenerate. 2025-12-20 Alan Modra PR 27666, bfd_check_format_matches bfd_check_format_matches should not change what matches depending on its "matching" arg. Fix that. This bug in bfd_check_format_matches is the underlying cause of pr27666. PR 27666 * format.c (bfd_check_format_matches): Always allocate matching_vector. 2025-12-20 Lulu Cai LoongArch: Add disassembly support for ud ui5 ud ui5, also known as amswap.w rd,$r1,rj(rd==rj), is displayed as "ud ui5" by default during disassembly. Alternatively, the original instruction can be printed using the objdump -M no-aliases. To implement this support, a format specifier "ru0:5,ru5:5" for ud is applied exclusively during disassembly. This specifier indicates that registers should be printed using their corresponding numeric values, and when the instruction is identified as ud, only a single parameter is displayed. binutils/ * testsuite/binutils-all/loongarch64/dis-amswap-ud-noaliases.d: New test. * testsuite/binutils-all/loongarch64/dis-amswap-ud.d: New test. * testsuite/binutils-all/loongarch64/dis-amswap-ud.s: New test. gas/ * testsuite/gas/loongarch/macro_ud.d: Update test. include/ * opcode/loongarch.h: New macro. opcodes/ * loongarch-dis.c (get_loongarch_opcode_by_binfmt): Correct match `ud`. (dis_one_arg): Disassemble the `ud` parameter. * loongarch-opc.c: Add opcode for "ud" alias. 2025-12-20 GDB Administrator Automatic date update in version.in 2025-12-19 Alan Modra Re: asan: alpha-vms: mmember access within null pointer Fix commit c01de193638c error. This in combination with the vms_lib_bstat error led to an uninitialised stat buf st_size and intermittent test failures. * bfdio.c (bfd_get_file_size): Correct brace placement. * vms-lib.c (vms_lib_bflush): Return -1. 2025-12-19 Jan Beulich bfin: avoid gcc extension using __VA_ARGS__ We shouldn't be using extensions when we don't have a suitable fallback in place. For cases where there's no argument wanted, OUTS() already exists. 2025-12-19 Peter Damianov Add windres to TOOL_PROGS I sent a patch to GCC adding support for passing .rc and .res files to the driver directly, allowing support for doing things like: gcc file.c file.rc -o file.exe However, binutils doesn't install windres into the tooldir, so by default, gcc will be unable to find windres. This patch adds windres to TOOL_PROGS so this can work. binutils/ChangeLog: * Makefile.am (TOOL_PROGS): Add windres. * Makefile.in: Regenerate. 2025-12-19 Jan Beulich bfd: correct dir separator conversion for Win32 Iterating a wchar_t array holding the conversion of multi-byte (likely UTF-8) input using array indexes from the corresponding char array isn't going to work as soon as any characters wider than a single char are present. Simply walk the wchar_t array all by itself. While looking at that code I also noticed a wrong argument being passed to a later MultiByteToWideChar() invocation: This needs to be number of characters, which isn't sizeof() when the array is of wchar_t elements. 2025-12-19 Jan Beulich MAINTAINERS: move three people to "Past Maintainers" ... for the respective emails bouncing. Thanks to them for their past work. Sadly this renders KVX and XCOFF unmaintained. While there also restore alphabetic sorting of the list. 2025-12-19 GDB Administrator Automatic date update in version.in 2025-12-18 Tom Tromey Don't use "module" name In C++20, "module" is an "identifier with special meaning". While it can be used as a variable name, it highlights as a keyword in Emacs, and I think it's nicer to just avoid it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32660 2025-12-18 Andrew Burgess gdb/testsuite: fix tclint errors After commit: commit b5160e2ee6a0192389caf7acee1fc32961ed29f4 (upstream/master, upstream/HEAD, gdb-tmp-g) Date: Fri Jul 26 16:32:33 2024 +0100 gdb: improve line number lookup around inline functions the following tclint errors were reported: gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:211:26: expression with substitutions should be enclosed by braces [unbraced-expr] gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:212:26: expression with substitutions should be enclosed by braces [unbraced-expr] Fixed by this commit. 2025-12-18 Tom Tromey Add Do_Nothing to two more Ada tests A couple of Ada tests were failing with gnat-llvm, because LLVM is a bit more aggressive about eliminating unused local variables. This patch arranges for some variables to be kept alive a little longer, using the usual Do_Nothing technique. 2025-12-18 Tom de Vries binutils-gdb/git: Handle *.ac and *.m4 files in .gitattributes Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig files"), .editorconfig has settings for .ac and .m4 files: ... [*.{ac,m4}] indent_style = tab indent_size = 2 trim_trailing_whitespace = true ... There are no setting for those files in .gitattributes, so the whitespace attribute defaults to trailing-space (shorthand for blank-at-eol, blank-at-eof) and space-before-tab. Since according to .editorconfig the indentation style is tab, add indent-with-non-tab as well. Since aclocal.m4 is generated, unset the whitespace attribute. Likewise for configure. 2025-12-18 Markus Metzger gdb, btrace: fix assert with gcc-15 This fixes /usr/include/c++/15/optional:1186: constexpr _Tp& std::optional<_Tp>::operator*() & [with _Tp = std::__cxx11::basic_string]: Assertion 'this->_M_is_engaged()' failed. encountered in gdb.btrace/ptwrite.exp. Approved-By: Simon Marchi 2025-12-18 GDB Administrator Automatic date update in version.in 2025-12-17 Simon Marchi gdb: replace msym_bunch with deque This patch replaces the msym_bunch implementation with an std::deque. I initially tried to replace it with a vector. However, that doesn't work, because minimal_symbol references need to stay valid across calls to minimal_symbol_reader::record_full in at least one spot. elf_symtab_read calls minimal_symbol_reader::record_full (through function record_minimal_symbol) to record a minimal symbol for a PLT entry and then uses a previously added minimal symbol to set the size of the PLT minimal symbol. If we used a vector, a re-allocation could happen which would invalidate the reference to the previous minimal symbol (luckily this was caught by ASan). An std::deque implementation typically uses a sequence of fixed-sized arrays, much like our current msym_bunch implementation. So adding an item at the end will not invalidate existing references. But unlike our msym_bunch, we don't have to worry about memory management. I was a bit puzzled about this code in minimal_symbol_reader::record_full: /* If we already read minimal symbols for this objfile, then don't ever allocate a new one. */ if (!m_objfile->per_bfd->minsyms_read) { m_msym_bunch_index++; m_objfile->per_bfd->n_minsyms++; } From what I understand, this "feature" gets used when you have ECOFF debug info in an ELF executable. We first parse the ELF minimal symbols in elf_symfile_read, then go into elfmdebug_build_psymtabs. elfmdebug_build_psymtabs has the capability to generate minimal symbols (useful when you use ECOFF debug info in an ECOFF executable I guess), but in this case we already have the ELF ones, so we don't want to record the ECOFF minimal symbols. Hence this mechanism to suppress new minimal symbols. The consequence of this patch, I believe, is that minimal_symbol_reader::record_full will unnecessarily allocate minimal symbols in this case. These minimal symbols won't be installed, because of the check in minimal_symbol_reader::install. The minimal symbols will be freed when the minimal_symbol_reader gets destroyed. That means a higher temporary memory usage when reading an ECOFF-in-ELF file, but no change in behavior. See discussion at [1]. [1] https://inbox.sourceware.org/gdb-patches/85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca/T/#meaf9b53da296e7f6872b441ec97038d172ca907f Change-Id: I7d10c6aca42cc9dcf80b483394e1e56351a9465f Approved-By: Tom Tromey 2025-12-17 Tom de Vries [gdb/contrib] Add tcllint->tclint in codespell-dictionary.txt Confusingly, the Tcl linter we're using is called tclint instead of tcllint. Add a corresponding entry in gdb/contrib/codespell-dictionary.txt. Approved-By: Simon Marchi 2025-12-17 Andrew Burgess gdb: improve line number lookup around inline functions This commit aims to fix an issue where GDB would report the wrong line for frames other than #0 if a previous frame had just left an inline function. Consider this example which is compiled at -Og: volatile int global = 0; static inline int bar (void) { asm (""); return 1; } static void foo (int count) { global += count; } int main (void) { foo (bar ()); return 0; } Used in this GDB session: (gdb) break foo Breakpoint 1 at 0x401106: file test.c, line 6. (gdb) run Starting program: /tmp/inline-bt/test.x Breakpoint 1, foo (count=count@entry=1) at test.c:6 6 { global += count; } (gdb) frame 1 #1 0x0000000000401121 in main () at test.c:3 3 static inline int bar (void) { asm (""); return 1; } Notice that GDB incorrectly reports frame #1 as being at line 3 when it should really be reporting this line: foo (bar ()); The cause of this problem is in find_pc_sect_line (symtab.c). This function is passed a PC for which GDB must find the symtab_and_line information. The function can be called in two modes based on the NOTCURRENT argument. When NOTCURRENT is false then we are looking for information about the current PC, i.e. the PC at which the inferior is currently stopped at. When NOTCURRENT is true we are looking for information about a PC that it not the current PC, but is instead the PC for a previous frame. The interesting thing in this case is that the PC passed in will be the address after the address we actually want to lookup information for, this is because as we unwind the program counter from frame #0 what we get is the return address in frame #1. The return address is often (or sometimes) on the line after the calling line, and so in find_pc_sect_line, when NOTCURRENT is true, we subtract 1 from PC and then proceed as normal looking for information about this new PC value. Now lets look at the x86-64 disassembly for 'main' from the above example. The location marker (=>) represents the return address in 'main' after calling 'foo': (gdb) run Starting program: /tmp/inline-bt/test.x Breakpoint 1, foo (count=count@entry=1) at test.c:6 6 { global += count; } #0 foo (count=count@entry=1) at test.c:6 #1 0x000000000040111f in main () at test.c:3 (gdb) up #1 0x000000000040111f in main () at test.c:3 3 static inline int bar (void) { asm (""); return 1; } (gdb) disassemble Dump of assembler code for function main: 0x0000000000401115 <+0>: mov $0x1,%edi 0x000000000040111a <+5>: call 0x401106 => 0x000000000040111f <+10>: mov $0x0,%eax 0x0000000000401124 <+15>: ret End of assembler dump. And the corresponding line table: (gdb) maintenance info line-table objfile: /tmp/inline-bt/test.x ((struct objfile *) 0x59405a0) compunit_symtab: test.c ((struct compunit_symtab *) 0x53ad320) symtab: /tmp/inline-bt/test.c ((struct symtab *) 0x53ad3a0) linetable: ((struct linetable *) 0x53adc90): INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN 0 6 0x0000000000401106 0x0000000000401106 Y 1 6 0x0000000000401106 0x0000000000401106 Y 2 6 0x0000000000401106 0x0000000000401106 3 6 0x0000000000401114 0x0000000000401114 4 9 0x0000000000401115 0x0000000000401115 Y 5 10 0x0000000000401115 0x0000000000401115 Y 6 3 0x0000000000401115 0x0000000000401115 Y 7 3 0x0000000000401115 0x0000000000401115 Y 8 3 0x0000000000401115 0x0000000000401115 Y 9 10 0x0000000000401115 0x0000000000401115 10 11 0x000000000040111f 0x000000000040111f Y 11 12 0x000000000040111f 0x000000000040111f 12 END 0x0000000000401125 0x0000000000401125 Y When looking for the line information of frame #1 we start with the return address 0x40111f, however, as this is not the current program counter value we subtract one and look for line information for 0x40111e. We will find the entry at index 9, this is the last entry with an address less than the address we're looking for, the next entry has an address greater than the one we're looking for. The entry at index 9 is for line 10 which is the correct line, but GDB reports line 3, so what's going on? Having found a matching entry GDB checks to see if the entry is marked as is-stmt (is statement). In our case index 9 (line 10) is not a statement, and so GDB looks backwards for entries at the same address, if any of these are marked is-stmt then GDB will use the last of these instead. In our case the previous entry at index 8 is marked is-stmt, and so GDB uses that. The entry at index 8 is for line 3, and that is why GDB reports the wrong line. So why perform the backward is-stmt check? When NOTCURRENT is false (not our case) the backward scan makes sense. If the inferior has just stopped at some new location, and we want to report that location to the user, then it is better (I think) to select an is-stmt entry. In this way we will report a line number for a line which the inferior is just about to start executing, and non of the side effects of that line have yet taken place. The line GDB prints will correspond with the reported line, and if the user queries the inferior state, the inferior should (assuming the compiler emitted correct is-stmt markers) correspond to the line in question having not yet been started. However, in our case NOTCURRENT is true. We're looking back to previous frames that are currently in-progress. If upon return to the previous frame we are about to execute the next line then (it seems to me) that this indicates we must be performing the very last action from the previous line. As such, looking back through the line table in order to report a line that has not yet started is the wrong thing to do. We really want to report the very last line table entry for the previous address as this is (I think) most likely to represent the previous line that is just about to complete. Further, in the NOTCURRENT case, we should care less about reporting an is-stmt line. When a user looks back to a previous frame I don't think they expect the line being reported to have not yet started. In fact I think the expectation is the reverse ... after all, the previous line must have executed enough to call the current frame. So my proposal is that the backward scan of the line table looking for an is-stmt entry should not be performed when NOTCURRENT is true. In the case above this means we will report the entry at index 9, which is for line 10, which is correct. For testing this commit I have: 1. Extended the existing gdb.opt/inline-bt.exp test. I've extended the source code to include a test similar to the example above. I have also extended the script so that the test is compiled at a variety of optimisation levels (O0, Og, O1, O2). 2. Added a new DWARF assembler test which hard codes a line table similar to the example given above. My hope is that even if test case (1) changes (due to compiler changes) this test will continue to test the specific case I'm interested in. I have tested the gdb.opt/inline-bt.exp test with gcc versions 8.4.0, 9.3.1, 10.5.0, 11.5.0, 12.2.0, and 14.2.0, in each case the test will fail (with the expected error) without this patch applied, and will pass with this patch applied. I was inspired to write this patch while reviewing these patches: https://inbox.sourceware.org/gdb-patches/AS8P193MB1285C58F6F09502252CEC16FE4DF2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM https://inbox.sourceware.org/gdb-patches/AS8P193MB12855708DFF59A5309F5B19EE4DF2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM though this patch only covers one of the issues addressed by these patches, and the approach taken is quite different. Still, those patches are worth reading for the history of this fix. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25987 Approved-By: Tom Tromey 2025-12-17 Tom Tromey Minor test fix for gnat-llvm This patch fixes a spot in the gdb test suite where gnat-llvm seems to emit slightly better DWARF than GNAT. 2025-12-17 Tom de Vries bfd/ELF: Handle prstatus of 156 bytes in elf32_arm_nabi_grok_prstatus For a corefile generated on openSUSE Leap 15.2 armv7l with linux version 5.3.18, we get: ... $ gdb -q --core core ... Core was generated by `/usr/bin/rs_scope -d'. ⚠️ warning: Couldn't find general-purpose registers in core file. (gdb) ... The warning is emitted because the pseudo-section .reg is missing, because elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but instead we have: ... $ eu-readelf -n core | grep -i prstatus CORE 156 PRSTATUS CORE 156 PRSTATUS CORE 156 PRSTATUS CORE 156 PRSTATUS ... This is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of elf_prstatus out"). The bug causes the FDPIC-specific unsigned long fields pr_exec_fdpic_loadmap and pr_interp_fdpic_loadmap to be added to struct elf_prstatus in case the FDPIC ABI is not used. Work around this bug in elf32_arm_nabi_grok_prstatus, by ignoring the extra fields, which gets us instead: ... Core was generated by `/usr/bin/rs_scope -d'. Program terminated with signal SIGSEGV, Segmentation fault. [Current thread is 1 (LWP 30047)] (gdb) ... Tested gdb, gas, binutils and ld on x86_64-linux and arm-linux with --enable-targets=all. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560 2025-12-17 Tom de Vries [gdb] Fix style.indent in tclint.toml The style.indent setting in gdb/tclint.toml is set to 4 spaces, which is an approximation. Starting with v0.6.2, tclfmt supports setting style.indent to mixed,,, which allows us to specify the actual indentation scheme. Set style.indent to mixed,4,8. PR testsuite/33724 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33724 2025-12-17 Simon Marchi gdb: remove unused includes from valops.c clangd says they are unused. Change-Id: I17362d38eabf7b93a311265ba7497560592faa94 2025-12-17 Simon Marchi gdb: remove unused include from gdbtypes.c clangd says it's not used. Change-Id: I49ae57264599b490c3fe4c61c05a11e7c0891056 2025-12-17 GDB Administrator Automatic date update in version.in 2025-12-16 Alan Modra PR 33721 load/store of misaligned address This fixes PR33721 by a common technique of declaring a packed struct to access unaligned integer fields. (See eg. linux kernel include/vdso/unaligned.h) I've tidied the PR29856 fix for a similar bug too (not that there was anything wrong with that fix). PR 33721 PR 29856 * sframe.c (flip_fre_start_address): Use a packed struct to access 2-byte and 4-byte unaligned fields. Make addr a void*. (sframe_decode_fre_start_address): Similarly, and remove unnecessary casts. Always set *fre_start_addr. 2025-12-16 Alan Modra more solaris tidies Don't overspecify the obsolete solaris targets: match solaris* rather than solaris2.[0-9]*. Move the sparc-*-solaris2.[0-6]* match later, and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64. This change is necessary for internal binutils consistency so that selecting --target=sparc-sun-solaris2 gets an error that the target is obsolete, and furthermore that the same target with --enable-obsolete does not result in runtime errors. bfd/ * config.bfd: Don't overspecify obsolete solaris targets. ld/ * configure.tgt: Don't overspecify obsolete solaris targets. * po/BLD-POTFILES.in: Regenerate. 2025-12-16 Tom de Vries [gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE On x86_64-linux, if I run test-case gdb.cp/typeid.exp with target boards: - unix/-m64 - unix/-m32 - unix/-fPIE/-pie/-m64 - unix/-fPIE/-pie/-m32 for only target board unix/-fPIE/-pie/-m32 I get: ... (gdb) print &typeid(i)^M could not find typeinfo symbol for 'int'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) print &typeid(i) == &typeid(typeof(i))^M could not find typeinfo symbol for 'int'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) == &typeid(typeof(i)) print &typeid(cp)^M could not find typeinfo symbol for 'char*'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) print &typeid(cp) == &typeid(typeof(cp))^M could not find typeinfo symbol for 'char*'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) == &typeid(typeof(cp)) print &typeid(ccp)^M could not find typeinfo symbol for 'char const*'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) print &typeid(ccp) == &typeid(typeof(ccp))^M could not find typeinfo symbol for 'char const*'^M (gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) == &typeid(typeof(ccp)) ... This is yet another configuration for which these tests don't work. We're already allowing this for clang and istarget "powerpc*-*-*". I don't think there is value in trying to detect yet another configuration. Instead, just allow it in general. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-12-16 Indu Bhagat gas: sframe: fix memory leak of remember_fre While at it, use the same pattern for cleaning up memory in sframe_xlate_ctx_cleanup. gas/ * gen-sframe.c (sframe_xlate_ctx_cleanup): Use the same pattern for free'ing memory consistently. (sframe_xlate_ctx_finalize): Free up remember_fre. 2025-12-16 Simon Marchi gdb: trivial cleanups in minimal_symbol_is_less_than Remove unnecessary braces. Replace `&` + `->` with `.`. Remove the trivial comments that just explain how the comparison operators work in C. Change-Id: Id77ae534c90219e2c02332ff5606c54d00286eca 2025-12-16 Tom Tromey Untabify gdb 'help' output This changes the gdb 'help' command to untabify its output. This lets us fix the last couple of warnings from the whitespace checker. Regression tested on x86-64 Fedora 41. Approved-By: Andrew Burgess 2025-12-16 Andrew Burgess gdb: shortcut 'list LINENO' While working on a test for a weird interaction between the DWARF parser, debuginfod, and the 'list' command, I noticed that performing 'list LINENO' can incur a significant amount of work trying to figure out which symtab the source should be listed from. This seems a little weird as a plain 'list' just uses the default symtab with no searching through all of the symtabs. The symtab lookup is all hidden behind the decode_line_1 call, which is made from list_command (cli/cli-cmds.c). The thing is, in list_command we already have code which (basically) checks if the argument to 'list' is a line number, here's the code: for (p = arg; p != arg1 && *p >= '0' && *p <= '9'; p++); linenum_beg = (p == arg1); And we already have code within list_command which depends on the default symtab, look at how 'list .', 'list +', and 'list -' are handled. I think that 'list LINENO' is such a common use case that is makes sense to optimise this case in order to avoid the need to perform symtab lookup. I think this can be achieved without any significant changes to the list_command function; we'll just move the existing line number check (see above code) a little earlier in the function and change it to a strtol call so that the actual line number is recorded. Then there's a little error checking, before finally we can skip straight to listing the source code using the default symtab. For anything other than 'list LINENO' we will handle the command just as we've always done. I think there's actually scope for list_command to handle more cases internally, without calling out to decode_line_1, but I thought I'd see how happy people were with this smaller change first before I tried anything larger. There should be no user visible changes after this commit, other than 'list LINENO' might be a little faster. Reviewed-By: Keith Seitz 2025-12-16 Andrew Burgess gdb: minor code cleanups in list_command There should be no functional change after this commit, this is mostly just a code cleanup in the list_command function. I have inlined local variables into the function body, changing 'int' to 'bool' where appropriate, and updating 'if' conditions to avoid treating non-bools as a bool. I also make more use of list_around_line towards the end of the list_command function, which avoids some code duplication, but shouldn't be a functional change. Reviewed-By: Keith Seitz 2025-12-16 Tom de Vries [gdb] Fix "the the" Replace "the the" with "the". Result of running: ... $ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the /the /' $ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the$/the/' ... The only change I have doubts about, is this comment in queue_comp_unit in gdb/dwarf2/read.c: ... ... . If the CU gets enqueued by this function but its DIEs - are not yet loaded, the the caller must load the CU's DIEs to ensure the + are not yet loaded, the caller must load the CU's DIEs to ensure the invariant is respected. ... where I think "the the" -> "then the" also make sense. But for now, I'm going with "the the" -> "the". Tested by building gdb on x86_64-linux. Approved-By: Simon Marchi 2025-12-16 Andrew Burgess gdb: fix crash from 'shell' when GDB has no terminal Bug PR gdb/33716 identifies a problem where GDB will crash when using the 'shell' command if GDB is not attached to a terminal. E.g.: $ gdb -nw -nh -q -batch -ex 'shell echo hello' 2025-12-16 Andrew Burgess gdb: rename scoped_gdb_tty_state, and make it non-copyable The scoped_gdb_tty_state class seems misnamed. For save/restore type classes the pattern in GDB is usually scoped_restore_, so lets rename this to scoped_restore_tty_state. I dropped the 'gdb' part of the name as the underlying functions being called are serial_get_tty_state and serial_set_tty_state, so the new name matches (I think) what's actually being called. I've also made the class non-copyable like other scoped_restore_ classes. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-12-16 Andrew Burgess gdb/doc: fix incorrect use of @value In commit: commit 255a9c42709958d0925d1d0d1d39d262972fd2a6 Date: Fri Dec 5 11:33:29 2025 +0000 gdb: new setting to disable progress bars I incorrectly used @value{on} and @value{off} to reference the on/off settings of a new flag. This caused the following warnings when building the docs: gdb.texinfo:51356: warning: undefined flag: off gdb.texinfo:51357: warning: undefined flag: on Looking through the docs there seems to be a split, in some cases we use @code and in others we use @samp. I'm not sure @code is correct, so I've switched to use @samp. The warnings are gone after this patch. 2025-12-16 Alan Modra Re: LoongArch: Add linker relaxation support for R_LARCH_CALL30 clang catches this error and another like it on line 6320. elfnn-loongarch.c:6357:35: error: overlapping comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare] 6357 | && (r_type != R_LARCH_CALL36 || r_type != R_LARCH_CALL30)) | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ * elfnn-loongarch.c (loongarch_elf_relax_section): Correct tests for R_LARCH_CALL36 and_LARCH_CALL30. 2025-12-16 GDB Administrator Automatic date update in version.in 2025-12-15 Simon Marchi gdb/testsuite: fix tcllint errors in gdb.base/startup-hints.exp Fix: gdb/testsuite/gdb.base/startup-hints.exp:61:44: expression with substitutions should be enclosed by braces [unbraced-expr] gdb/testsuite/gdb.base/startup-hints.exp:64:28: expression with substitutions should be enclosed by braces [unbraced-expr] Change-Id: Id21ff11ced82b11c11d0eb0d186fe6fc5c4c06c5 2025-12-15 Maciej W. Rozycki LD/testsuite: Expand archive verification to group feature Expand archive verification to cover the group feature. Linker error messages for unsatisfied symbol references vary between targets a bit, in particular `arc-*-*' produce duplicate messages and `alpha*-*-osf*' and `alpha*-*-linux*ecoff*' add a "final link failed" message. Factor this in with the error pattern list to match. Usual XFAIL annotations apply. 2025-12-15 Maciej W. Rozycki CRIS/LD/testsuite: Add tests for emulation switching Add tests matching generic ones from ld-archive/archive.exp for explicit link emulation switching, verifying that correct output is produced from a link including an archive the format of which is not the default one. This covers generic BFD code using `cris-aout' and `cris-elf' targets as ones that permit switching between dissimilar emulations from assembly through the link. Only tests for link emulation explicitly specified are included at this stage, as bugs in BFD currently prevent links from successful completion that use the default emulation while involving archives in a non-default format. Additional tests will be included with a subsequent change that addresses said bugs. 2025-12-15 Maciej W. Rozycki LD/testsuite: Expand archive verification to `--whole-archive' feature Expand archive verification to cover the `--whole-archive' feature, adding link map and verbose output matching to verify the correct archive members are added and the unwanted ones omitted. Adjust the linker flags accordingly for XCOFF targets, by switching from the `-bexpall' option to `-unix' (`-bexpfull' would do too, but has some test coverage already, unlike `-unix', which is a superset of the former option), so that additional symbols pulled with `--whole-archive' aren't discarded by linker garbage collection. This test expansion has revealed the lack of thin archive support in AR for Alpha/VMS and XCOFF targets, despite apparent presence of relevant code in the respective BFD backends. With `ar rcT' invocation a regular archive is silently produced instead. Rather than making the relevant tests overly permissive, XFAIL them for the affected targets, referring PR binutils/33600. 2025-12-15 Maciej W. Rozycki VMS/BFD: Fix a sign extension issue with archive symbol lookup Symbol binary search code for VMS archive files uses plain `char' data type to cast a difference between characters to data of the `int' type. Consequently the difference is consider unsigned in the range between 0 and 255 on hosts where plain `char' data type is unsigned, resulting in symbol lookup failures, such as with the test expansion included with this change causing regressions as follows: FAIL: Regular archive link FAIL: Thin archive link FAIL: Regular archive plus regular link FAIL: Regular archive plus thin link FAIL: Thin archive plus regular link FAIL: Thin archive plus thin link owing to link failures such as: .../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa' .../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa' .../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa' .../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa' with the `alpha-dec-vms' target on the `powerpc64le-linux-gnu' host. Use explicit `signed char' data type for the cast then, removing the failures. 2025-12-15 Maciej W. Rozycki LD/testsuite: Fix archive verification for Alpha/VMS As from commit a2298f23f2e2 ("PR 33385 vms archives") the handling of Alpha/VMS archives has been recently unbroken, after 7 years, revealing issues with archive tests added with commit 435223a9ae70 ("LD/testsuite: Add tests for archive handling"), the change of the failure mode of which went unnoticed. In particular there is no NM support for executables and archives always have an index by the nature of the format; cf. `_bfd_vms_lib_archive_p': "The map is always present." Address these peculiarities by excluding NM tests for the executables produced and by omitting mapless archive rejection tests just as with XCOFF targets, removing all the test failures: alpha-dec-vms -FAIL: Regular archive link alpha-dec-vms -FAIL: Thin archive link alpha-dec-vms -FAIL: Regular archive plus regular link alpha-dec-vms -FAIL: Regular archive plus thin link alpha-dec-vms -FAIL: Thin archive plus regular link alpha-dec-vms -FAIL: Thin archive plus thin link alpha-dec-vms -FAIL: Regular archive w/o index link alpha-dec-vms -FAIL: Thin archive w/o index link Factor out code to filter out unwanted tests to a procedure for a better structure of the code. 2025-12-15 Maciej W. Rozycki PR binutils/33485: LD/testsuite: Also XFAIL `ns32k-*-*' targets NS32k targets also use the a.out archive format, which suffers from PR binutils/33485 where symbol indexes in a.out thin archives are missing symbols for subsequent members. This affects `ns32k-pc532-lites*', `ns32k-pc532-mach*', and `ns32k-pc532-ux*' targets in particular; other NS32k targets appear defunct. Add suitable XFAIL annotation, removing failures such as: ns32k-pc532-lites -FAIL: Thin archive link ns32k-pc532-lites -FAIL: Regular archive plus thin link ns32k-pc532-lites -FAIL: Thin archive plus regular link ns32k-pc532-lites -FAIL: Thin archive plus thin link 2025-12-15 Tom de Vries [pre-commit] Move codespell-log to post-commit The current pre-commit hook codespell-log works with script gdb/contrib/codespell-log.sh. During the commit-msg phase of a commit, the following happens: - git calls pre-commit - pre-commit calls gdb/contrib/codespell-log.sh, - gdb/contrib/codespell-log.sh calls pre-commit, and - precommit calls codespell. This purpose of this indirection is to: - ignore the exit status of codespell (to make sure that the commit is not aborted), and - control the version of codespell. However, if the check fails, the output is a bit messy due to the indirection: ... $ touch gdb/bla.c $ git add gdb/bla.c $ git commit -m "Usuable" ... codespell-log............................................................Passed - hook id: codespell-log - duration: 0.43s codespell-log-internal...................................................Failed - hook id: codespell - exit code: 65 .git/COMMIT_EDITMSG:1: Usuable ==> Usable [detached HEAD 18ec133830f] Usuable 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 gdb/bla.c ... And if the check passes, the output is still verbose due to the verbose=true setting. I found a simpler way to implement this. Given that we don't want to abort the commit, the post-commit stage is a more natural place for this check. Moving it there solves two problems: - we no longer need to ignore the exit status of codespell - we no longer need the verbose=true setting The only issue is that we need to generate the file containing the commit message ourselves, something that is provided by git in the commit-msg stage. So we still need a wrapper script. However, it seems that specifying a shell script as entry point of a codespell hook is fine, so we no longer need to call pre-commit from codespell-log.sh. Having simplified codespell-log.sh, we can downgrade it to a /bin/sh script, instead of requiring bash. Checked with shellcheck. 2025-12-15 Andrew Burgess gdb: new setting to disable progress bars Two commits ago, in the commit titled: gdb: make get_chars_per_line return an unsigned value A bodge was added in cli-out.c so that progress bars (as seen when debuginfod downloads a file) would be disabled when the output terminal had unlimited width. The hack was added because this previous commit fixed a bug such that progress bars could now be displayed in very wide, or even on unlimited width output terminals. By fixing this bug, progress bars were now being displayed when running the testsuite, as the testsuite sets the output terminal to unlimited width. To avoid breaking the tests, this previous commit added a bodge such that on unlimited width output terminals, progress bars would always be disabled. This got the tests passing again, but isn't an ideal solution. This commit cleans things up. We now have a new setting: set progress-bars enabled on|off show progress-bars enabled This setting allows progress bars to be turned off. The tests are then updated to explicitly turn off progress bars. The bodge from the earlier commit is then removed. Now, progress bars should display correctly on any width of output terminal over 50 characters, the minimum required. And the debuginfod tests should all pass as they turn off progress bars. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-12-15 Andrew Burgess gdb: fix crashes and weird output from new boxed hint text After the commit: commit f6df8aa48f120b78f0670b429f8a3363020a47dc Date: Mon Sep 15 11:56:17 2025 -0300 gdb: Make startup message more user friendly I noticed, that when I start GDB with a file on the command line, I was seeing some stray '..'. Like this: $ gdb -nw -nh /tmp/hello.x GNU gdb (GDB) 18.0.50.20251202-git Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Find the GDB manual online at: ┃ ┃ http://www.gnu.org/software/gdb/documentation/. ┃ ┃ For help, type "help". ┃ ┃ Type "apropos " to search for commands related to ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ .. Reading symbols from /tmp/hello.x... Notice the '..' after the boxed hint text, that's what I'm complaining about. Also, notice that the last line within the box is missing its period. Before the above commit the last line would appear like this when no file was loaded: Type "apropos " to search for commands related to . And like this when a file was being loaded: Type "apropos " to search for commands related to ... The extra '..' are added to show that a file is being loaded, and that this might take some time. But we have the 'Reading symbols from ...' text to indicate this now, so I think the extra '..' are redundant. Lets just drop them. This will leave just a single period at the end of the sentence. The above commit unfortunately, didn't include any tests, so I thought I'd write some to cover this fix.... and that uncovered a bug where the box around the startup hints could be corrupted: $ gdb -eiex 'set width 50' -nw -nh GNU gdb (GDB) 18.0.50.20251202-git Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Find the GDB manual online at: ┃ ┃ http://www.gnu.org/software/gdb/documentation/. ┃ ┃ For help, type "help". ┃ ┃ Type "apropos " to ┃ ┃ search for commands related to ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ (gdb) This was caused by a mistake on the line where we choose whether to box or not. The line is currently: if (width - 3 <= docs_url.length ()) There are two problems here, the '3' should be '4'. The box adds 4 characters '| ' and ' |'. But also, the WIDTH can be very small, less than 4 even, which means that the subtraction can underflow, wrapping around and giving a very large value. I plan to rewrite the line to: if (width < docs_url.length () + 1 + 4) The '+ 1' accounts for the period at the end of the URL line (which was previously handled by the '<=', and the '+ 4' accounts for the box borders. By making it a '+ 4' on the URL, rather than '- 4' from the width, we avoid underflow. This is fine so long as the URL to our documentation doesn't approach UINT_MAX in length. Which I hope it never does. I've added a couple of asserts to print_gdb_hints to reflect things that must be true. The first is that get_chars_per_line never returns 0. And later on, I assert that 'width > 4' in a place where we are about to do 'width - 4'. If the assert triggers then underflow would have occurred. Reviewed-By: Guinevere Larsen Approved-By: Tom Tromey 2025-12-15 Andrew Burgess gdb: make get_chars_per_line return an unsigned value I noticed that get_chars_per_line currently returns an 'int', but the value it is returning, from utils.c, is an 'unsigned int'. In some cases this can cause weird behaviour as an unlimited width terminal will have UINT_MAX characters per line, which will appear as negative when returned from get_chars_per_line. This has been the case since get_chars_per_line was added in commit: commit 2f2287318b33ddf855a692fcc191f6b25caf4644 Date: Wed Dec 16 18:18:40 2020 +0100 [gdb/cli] Add a progress meter Lets make get_chars_per_line return an unsigned value, and update all the uses of this function to hold the result in an unsigned variable. I ran into this issue when looking at print_gdb_hints (from top.c) where a very large get_chars_per_line() value would appear negative, and so the startup hints would be printed without a box when really they should have been boxed. Someone else noticed this problem while I was building this patch, and pushed commit: commit 06e470d8fc0ae0e83fe0977fdf8c011998980891 Date: Sat Nov 29 15:48:55 2025 +0100 gdb: handle unlimited screen width case in print_gdb_hints This commit works around the signed / unsigned confusion entirely within print_gdb_hints by adding a case to 'int' in one place. The change I present here reverts parts of 06e470d8fc0a in favour of fixing the type of WIDTH within print_gdb_hints. It is worth nothing that there are other bugs in print_gdb_hints relating to how WIDTH is handled, but these are fixed in the next commit. By updating the return type of get_chars_per_line, I ran into some issues in cli-out.c relating to how progress bars are handled. The existing code includes code like: if (!stream->isatty () || !current_ui->input_interactive_p () || chars_per_line < MIN_CHARS_PER_LINE) return; The early return here triggers when progress bars should not be printed. Notice that when the terminal width is unlimited, CHARS_PER_LINE will appear negative, and so the early return will trigger. It turns out that our testsuite depends on this; the debuginfod tests don't expect to see a progress bar, and they don't because within the tests we set the width to unlimited. By "fixing" the type of CHARS_PER_LINE to 'unsigned int', an unlimited width terminal no longer triggers the early return, and GDB starts trying to print a progress bar in our debuginfod tests, which cause the tests to fail. I think the real fix is to add a new flag to allow progress bars to be disabled, the tests can then use this. I will add just such a flag at the end of this series. For now though, I propose adding a bodge. If CHARS_PER_LINE is UINT_MAX, then we should act as if progress bars are disabled. The above code now becomes: if (!stream->isatty () || !current_ui->input_interactive_p () || chars_per_line < MIN_CHARS_PER_LINE || chars_per_line == UINT_MAX) return; This change is in cli_ui_out::clear_progress_notify. There is a similar change in cli_ui_out::do_progress_notify. With these two changes, the debuginfod tests are working again. This bodge will be removed by the last patch in this series. There's no tests with this commit yet as print_gdb_hints has other bugs which will be fixed in the next commit. At this point I'll add some tests. Reviewed-By: Guinevere Larsen Approved-By: Tom Tromey 2025-12-15 Tom Tromey Minor DAP test cleanups This patch removes the "-1" from returns in the DAP tests, and also reindents one of those lines at the same time. 2025-12-15 Ronan Desplanques DAP: accept requests with '"arguments": null' Some Debug Adapter Protocol clients like Helix set the optional "arguments" field of the ConfigurationDone request to null, which is a bit odd but seems to be allowed by the protocol specification. Before this patch, Python exceptions would be raised on such requests. This patch makes it so these requests are treated as if the "arguments" field was absent. 2025-12-15 Tom Tromey Use skip_spaces in more places I looked through gdb for instance of: while (*p == ' ' || *p == '\t') p++; ... and replaced these with a call to skip_spaces. In some cases this might slightly change the semantics, as now other whitespace (like \r or \f) will be considered. However I don't think this matters. Regression tested on x86-64 Fedora 41. Approved-By: Simon Marchi 2025-12-15 Srinath Parvathaneni aarch64: Add support for new BTI "r" This patch adds support for new BTI "r" (instruction: bti r), which is an alias to "bti" (with no target), for both "bti" and "bti r" the preferred disassembly is "bti r". This "bti r" instruction is by default available from Armv8-A architecture. The HINT_OPD_F_NOPRINT macro has become redundant with these changes and has been removed. 2025-12-15 Jan Beulich bfd/s12z: put relocations next to each other It's not helpful to have two separate "sections", each with a single relocation. bfd/ELF: fold BFD_RELOC__RELATIVE There's no need to have a separate reloc per arch; just like for other more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and KVX - sadly - are exceptions. bfd/ELF: fold BFD_RELOC__J{,U}MP_SLOT There's no need to have a separate reloc per arch; just like for other more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and KVX - sadly - are exceptions. bfd/ELF: fold BFD_RELOC__GLOB_DAT There's no need to have a separate reloc per arch; just like for other more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and KVX - sadly - are exceptions. bfd/ELF: fold BFD_RELOC__COPY There's no need to have a separate reloc per arch; just like for other more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and KVX - sadly - are exceptions. bfd/ELF: fold BFD_RELOC__IRELATIVE There's no need to have a separate reloc per arch; just like for other more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and KVX - sadly - are exceptions. S/390: use BFD_RELOC__PLT_PCREL in favor of custom types No reason to have separate types when the generic ones have no (other) meaning for this target. Sparc: use BFD_RELOC__PLT_PCREL in favor of custom types No reason to have separate types when the generic ones have no (other) meaning for this target. Arc: use generic BFD_RELOC_... in favor of custom types No reason to have separate types when the generic ones have no (other) meaning for this target. 2025-12-15 Jan Beulich Arm: use BFD_RELOC_32_PLT_PCREL in favor of custom type No reason to have a separate type when the generic one has no (other) meaning for this target. Doing the adjustments makes obvious that elf32_arm_reloc_map[] had two identical entries; that duplicate is being removed. 2025-12-15 GDB Administrator Automatic date update in version.in 2025-12-14 John David Anglin Fix configure rebuild 2025-12-14 John David Anglin bfd/ChangeLog: * configure: Regenerate. ld/ChangeLog: * configure: Regenerate. 2025-12-14 John David Anglin Fix binutils build on hppa64-hpux with gcc-16 (v3) With recent gcc versions, implicit function declarations are errors. We need to ensure that ffs() and strtoull() are declared and correctly checked for by configure. strtoull() is not declared on hpux but it's provided by libiberty. An unnecessary include of strings.h in elf32-xtensa.c is removed. Approved-By: Jan Beulich 2025-12-14 John David Anglin bfd/ChangeLog: * configure.ac: Check for strtoull declaration. * elf32-xtensa.c: Remove strings.h include. * configure: Regenerate. * config.in: Regenerate. * sysdep.h: Include strings.h and declare strtoull() if a declaration for it isn't found by configure. ld/ChangeLog: * configure.ac: Check for strtoull declaration. * configure: Regenerate. * config.in: Regenerate. * sysdep.h: Declare strtoull() if a declaration for it isn't found by configure. 2025-12-14 GDB Administrator Automatic date update in version.in 2025-12-13 Tankut Baris Aktemur gdb: use the pid from inferior in setup_inferior This is a step to reduce the dependency on the global inferior_ptid variable. Approved-By: Simon Marchi 2025-12-13 Lulu Cai LoongArch: Set the default ABI of loongarch*-elf targets to double-float The ABI setting for the elf target was ommitted in commit "db614f37cab". Set the default ABI for elf to double-float. In addition, test case failures caused by the loongarch*-elf linker not supporting relevant options have also been skipped. gas/ * config/tc-loongarch.c (loongarch_after_parse_args): Set default ABI to double-float for other targets. ld/ * testsuite/ld-loongarch-elf/la32.d: Skip tests when not supported. * testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Likewise. * testsuite/ld-loongarch-elf/relax.exp: Likewise. 2025-12-13 Alan Modra Re: ld: testsuite: Add sframe test for PR 33401 If user CXXFLAGS include -fno-inline the test fails with FAIL: PR ld/33401 (Step 1: Create relocatable object and check R_*_NONE) This should not be a FAIL. If the compiler does not generate R_*_NONE (a good thing!) then it should be UNTESTED, which means the readelf check can't be done by run_cc_link_tests. I haven't made that change in this patch, just worked around a user -fno-inline. 2025-12-13 GDB Administrator Automatic date update in version.in 2025-12-12 Lancelot SIX gdb/breakpoint.c: fix style issues in get_sal_arch Fix coding standard related issues in get_sal_arch. Approved-By: Simon Marchi Change-Id: I62b059e0bf060f368c9895c97d8b162d73ff61ce 2025-12-12 Claudiu Zissulescu Indu Bhagat ld: testsuite: Add sframe test for PR 33401 When linking for a relocable output file (-r), one or more R_*_NONE relocations may be generated for .sframe section. Two new tcl procedures are added to sframe.exp file. 'check-dump' is checking if an input bin file has the same relocation as specified in the second input argument. 'check_pr33401' is the main checking function for PR33401 which calls twice the ld tool to produce an relocable output file. ld: PR33401 * testsuite/ld-sframe/StateClient.cpp: New file. * testsuite/ld-sframe/StatePlaying.cpp: Likewise. * testsuite/ld-sframe/pr33401.rd: Likewise. * testsuite/ld-sframe/sframe.exp (check_pr33401): New procedure. Reviewed-by: Indu Bhagat 2025-12-12 Indu Bhagat bfd: ld: sframe: skip R_*_NONE relocations from input bfds Fix PR ld/33401 - SFrame assertion when linking gav-0.9.1 As the issue demonstrates, R_*_NONE relocations are not necessarily at the end of .sframe section (previously thought so with PR ld/33127). Skip over R_*_NONE relocs when they are strewn intermittently inside the .rela.sframe section. bfd/ PR ld/33401 * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Skip over R_*_NONE relocations. 2025-12-12 Jan Beulich gas/gen-sframe: avoid gcc extension using __VA_ARGS__ We shouldn't be using extensions when we don't have a suitable fallback in place. Introducing a format-argument-less counterpart macro would feel a little odd here. Instead make the sole use site have a (fake) argument (the non-translatable part of the string). 2025-12-12 LIU Hao ld/pe-dll: Don't auto-export symbols from .tls section The .tls section of an image contains template data that will be duplicated for each new thread to be created. Accessing thread-local data involves an image-specific global variable, _tls_used, for calculation. Therefore, it is impossible to export thread-local variables from a DLL. The only symbol that exists in the .tls input section is _tls_start, but it's a CRT symbol and is never auto-exported. It's only necessary to check for user symbols, which are always generated in the subsection .tls$ by default, or in subsections like .tls$$ when -fdata-sections is specified. Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 2025-12-12 Vignesh Balasubramanian bfd: Add minimal support to handle note that describes xsave layout This note section is already supported by Linux kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/fpu/xstate.c?id=ba386777a30b38dabcc7fb8a89ec2869a09915f7 Co-Authored-By: Jini Susan George 2025-12-12 Jan Beulich gas/d30v: make use of tc_symbol_chars[] ... instead of having arch-specific code in app.c. 2025-12-12 Tom de Vries [gdb/testsuite] Fix timeout in gdb.base/async-shell.exp For test-case gdb.base/async-shell.exp, I usually get: ... (gdb) run &^M Starting program: async-shell ^M (gdb) PASS: $exp: run & [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M shell echo foo^M foo^M (gdb) PASS: $exp: shell echo foo ... And with taskset -c 11, I get instead: ... (gdb) run &^M Starting program: async-shell ^M (gdb) PASS: $exp: run & shell echo foo^M foo^M (gdb) PASS: $exp: shell echo foo [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M ... With a gdb 16.3 based package I ran into: ... (gdb) run & Starting program: async-shell (gdb) PASS: $exp: run & shell echo foo foo (gdb) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". FAIL: $exp: shell echo foo (timeout) ... I have tried to reproduce this using various timing tricks, but haven't managed. Nevertheless, I believe this can reproduced with trunk, so fix this using -no-prompt-anchor. PR testsuite/33667 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33667 2025-12-12 Jan Beulich RISC-V: avoid ld crashes due to bogus use by testcases Specifying a little-endian emulation isn't very helpful when the target is big-endian (and hence gas defaults to that). Surely the linker better wouldn't crash when invoked like this, but making sure of this isn't the purpose of any of these tests (afaict). Make assembly output match linker options. With this the ld testsuite completes successfully for me. binutils and gas testsuites still have issues. 2025-12-12 Jan Beulich x86: replace XFAILs in "GOTX default" tests The use of XFAIL was wrong here. XFAIL marks tests which in principle should work, but where making them work requires extra effort. 2025-12-12 Jan Beulich gas/macro: drop ISSEP() I've been irritated by it more than once: It very obviously doesn't cover all separators, hence resulting in inconsistent behavior. Nor do both use sites look to really want the same set of separators. In macro_expand() we really can pull the get_token() call ahead. If we don't find the expected '=' we can simply continue parsing from the original position. The use in get_any_string() is dead code afaict, inherited from gasp. The sole leftover thereof is handled in the scrubber (see H_TICK_HEX, LEX_IS_H, and alike there). With that dropped, ISBASE() also can be. 2025-12-12 Jan Beulich ld/ELF: correct tidying of sec64k object files These consume quite a bit of space (especially noticeable during batch testing), but are rather mechanical to (re)create. In 2.28, when the object file names used were changed (from dump.o to names derived from source file names), the tidying code wasn't updated (and hence lost its effect). 2025-12-12 Jan Beulich ld/ELF: leave note sections alone for relocatable linking Commit 023e60ced0c8 ("ld: Move note sections after .rodata section") had a rather undesirable effect for relocatable links (which typically wouldn't use a custom linker script): .note.GNU-stack, which isn't even a proper notes sections (it's SHT_PROGBITS instead, which likely will want correcting independently), would be moved immediately past .text and .rodata (and alike), ahead of any custom notes sections. A later final link, possibly simply combining all .note and .note.* sections, would then find .note.GNU-stack first, resulting in the output section to also become SHT_PROGBITS. This way consumers looking for SHT_NOTE wouldn't find the data they're after. The goal of mentioning some known .note.* in the linker scripts is to avoid orphan section diagnostics. That's not typically of interest for relocatable links, though (people caring about this will want to have custom scripts anyway, much like they may need to if they had any custom .note.* sections). Therefore suppress that part of the linker script for relocatable links. 2025-12-12 Jan Beulich ld/Linux: determine program name in a more reliable manner What argv[0] holds can be pretty arbitrary. As long as it's used for just diagnostics, that may be pretty okay to go from, but ld also uses it to find linker scripts. For that we want to be sure we start from the real executable name. Which on Linux we can determine from the /proc/self/exe symbolic link target (provided of course procfs is mounted). While there constify program_name as well. 2025-12-12 GDB Administrator Automatic date update in version.in 2025-12-11 Tom Tromey Use -wrap in two test cases Both Baris and Tom pointed out spots in recent patches where -wrap could have been used. This patch changes both the relevant tests to use it. 2025-12-11 Tom de Vries [pre-commit] Add pre-commit setup check I wrote a patch and accidentally introduced a typo in the commit message. This didn't get detected because codespell-log didn't run. I installed pre-commit on that setup a while back, before codespell-log was around and consequently only the .git/hooks/pre-commit script was installed. This is a bit hard to notice given that all other hooks do run. Add a pre-commit check that checks for this situation: ... $ rm .git/hooks/commit-msg $ git commit --amend ... pre-commit-setup........................................................Failed - hook id: pre-commit-setup - exit code: 1 missing hook: .git/hooks/commit-msg (please run pre-commit install) ... $ ... This is a bit niche, but worthwhile if you're using a dozen build and test installations. 2025-12-11 Tom de Vries [gdb/testsuite] Add tclint-plugin.py Tclint v0.6.2 adds the possibility to specify a dynamic plugin using: ... $ tclint --commands tclint-plugin.py ... Update the pre-commit tclint version to v0.6.2, and add a plugin gdb/testsuite/tclint-plugin.py. The new plugin informs tclint about procs like proc_with_prefix which have a script-type parameter, making tclint check the body of proc foo: ... proc_with_prefix foo {} { ... } ... Declaring proc_with_prefix a builtin command makes tclint issue a redefined-builtin for the definition of proc_with_prefix. Fix this by adding "tclint-disable redefined-builtin" at the start of each file containing such procs. The plugin is not complete. Most entries were found by grepping for something like "proc.*body". The hope is that eventually we get to a situation where we can drop the plugin and instead annotate like this [1]: ... # tclint-args: name: any, arguments: any, body: script proc proc_with_prefix { name arguments body } { ... } ... One fix in the testsuite, in test-case gdb.python/py-missing-objfile.exp. [1] https://github.com/nmoroze/tclint/issues/121#issuecomment-3319368338 2025-12-11 Jan Vrany gdb/testsuite: use with_timeout_factor in huge.exp testcases I occasionally run GDB testsuite on sluggish targets that need higher timeout. The usual remedy I use is to set timeout to higher value in site.exp. This does not help with gdb.fortran/huge.exp, gdb.base/huge.exp and gdb.ada/huge.exp, which set the timeout to fixed value of 30, regardless of whether the timeout has been increased or not, causing them to fail on some of my machines. This commit fixes the problem by using with_timeout_factor. Approved-By: Tom Tromey 2025-12-11 Rainer Orth ld: Remove elf_i386_ldso reference There's still a reference to the removed elf_i386_ldso emulation, breaking the build with --enable-targets=all. Tested on x86_64-pc-linux-gnu. 2025-12-11 Rainer Orth ld: * Makefile.am (ALL_EMULATION_SOURCES): Remove eelf_i386_ldso.c. * Makefile.in: Regenerate. 2025-12-11 Alice Carlotti aarch64: Update parse_vector_reg_list comment The information about indexes was wrong. I've also adjusted the formatting and improved other parts of the comment. 2025-12-11 Richard Ball aarch64: Add support for FEAT_LSCP This patch adds the new instructions from FEAT_LSCP. These instructions are LDAP, LDAPP and STLP. 2025-12-11 Rainer Orth Cleanup bfd target vectors and ld emulations on Solaris (missed part) This reordering of the x86_64-*-solaris2.1[01] entry in config.bfd was missed in the original commit. 2025-09-09 Rainer Orth bfd: * config.bfd [BFD64] : Move down. 2025-12-11 Tom Tromey Fix "unset local-environment" when clearenv not available Tom de Vries pointed out that clearenv isn't available on all hosts. Since this seems like a niche command at best, it seemed fine to disable this command on such platforms. Reviewed-By: Tom de Vries 2025-12-11 Rainer Orth Cleanup bfd target vectors and ld emulations on Solaris This patch is a major cleanup of the Solaris configurations of both bfd and ld. The Solaris cases in both bfd/config.bfd and ld/configure.tgt have seen a major cleanup, making the support for various Solaris versions explicit, correcting several inconsistencies, and making it easier to remove support for some versions in the future. * All 32-bit-only configurations (Solaris < 7 on SPARC, Solaris < 10 on x86) only include the 32-bit target vectors and linker emulations. * For 32-bit-default targets on 64-bit systems (Solaris >= 7 on SPARC, Solaris >= 10 on x86), the 32-bit target vectors and linker emulations are the default while supporting the 64-bit ones. * For 64-bit-default targets on 64-bit systems, it's the other way round. They default to 64-bit target vectors etc. while also supporting the 32-bit ones. * Added a warning to all Solaris cases in config.bfd not to include the non-*_sol2 vectors to avoid the ambiguity reported in PR binutils/27666. * On x86, the iamcu target vectors and linker emulations have been removed: Solaris never supported the Intel MCU. * On x86, the PE and PEI target vectors have been removed: they were only supported in binutils proper. Their only use would be on EFI files e.g. in GRUB, which doesn't justify their inclusion. * With iamcu support gone, a few gas tests had to be disabled as on VxWorks. * The 32-bit Solaris/x86 ld configuration currently includes the elf_i386_ldso emulation, which was never a emulation in its own right but just an implementation detail of the elf_i386_sol2 emulation. Instead, the settings that are not already provided by sourced .sh files are moved into elf_i386_sol2.sh. Many settings became superfluous by just sourcing elf_i386.sh as is already done in elf_x86_64_sol2.sh, massively simplifying the emulation. * Solaris-specific settings in generic emulparams scripts have been moved to the *_sol2.sh files. * NATIVE_LIB_DIRS in ld/configure.tgt now uses the default setting: /usr/ccs/lib contains just a bunch of symlinks into /usr/lib at least since Solaris 8. * ld/emulparams/solaris2.sh now sets ELF_INTERPRETER_NAME to /usr/lib/amd64/ld.so.1, matching both the native linker and elf_i386_sol2.sh. * The SEARCH_DIR statements in linker scripts on 64-bit targets contained both the native (64-bit) and non-default (32-bit) directies. The latter are completely pointless and are omitted using a new LIBPATH_SKIP_NONNATIVE setting. Tested on {amd64,i386}-pc-solaris2.11 and {sparcv9,sparc}-sun-solaris2.11, and {x86_64,i686}-pc-linux-gnu as well as with gcc trunk bootstraps on the Solaris targets. On those, I've compared the gas/ld and gas/gld 2.45.50 testresults with 2.45 ones. 2025-09-09 Rainer Orth bfd: * config.bfd : Split into ... ... this. (targ_selvecs): Remove iamcu_elf32_vec, i386_coff_vec, i386_pei_vec. (targ64_selvecs): Remove x86_64_pe_vec, x86_64_pei_vec. : ... and this. [BFD64] : Change into x86_64-*-solaris2.1[01]*. (targ_defvecs): Change to x86_64_elf64_sol2_vec. (targ_selvecs): Remove iamcu_elf32_vec, i386_coff_vec, i386_pei_vec, x86_64_pe_vec, x86_64_pei_vec. : Split into ... : ... this. : ... this. [BFD64] : Omit sparc-*-solaris2*. (targ_defvec): Swap with targ_selvecs. * testsuite/gas/i386/i386.exp: Disable iamcu tests on Solaris. ld: * configure.tgt : Split into ... : .. this. (targ_extra_emuls): Remove elf_i386_ldso and elf_iamcu. : ... and this. : Change into ... : ... this (targ_extra_emuls): Reorder. (tdir_elf32_sparc): Remove. : New case. : Change into ... : ... this. : Remove. : Change into ... : ... this. (targ_extra_emuls): Reorder. Remove elf_i386_ldso, elf_iamcu. (tdir_elf_i386): Remove. (NATIVE_LIB_DIRS): Remove Solaris handling. * emulparams/elf32_sparc_sol2.sh (ELF_INTERPRETER_NAME): New variable. * emulparams/elf64_sparc.sh (LIBPATH_SUFFIX): Move ... * emulparams/elf64_sparc_sol2.sh: ... here. (LIBPATH_SKIP_NONNATIVE): New variable. (ELF_INTERPRETER_NAME): Likewise. * emulparams/elf_i386_ldso.sh: Merge into ... * emulparams/elf_i386_sol2.sh: ... this. Remove duplicate variables. Source elf_i386.sh instead of elf_i386_ldso.sh. * emulparams/elf_x86_64.sh <*-*-solaris2*> (ELF_INTERPRETER_NAME): Move ... * emulparams/elf_x86_64_sol2.sh: ... here. Use /usr/lib/amd64/ld.so.1. (LIBPATH_SKIP_NONNATIVE): New variable. * emulparams/solaris2.sh: Fix comment. * genscripts.sh: Fix typos. Heed LIBPATH_SKIP_NONNATIVE. 2025-12-11 H.J. Lu lto: Compile LTO 15 test with -fno-fat-lto-objects When -ffat-lto-objects is used to compile binutils, LTO 15 test fails on 32-bit targets the same way as -fno-lto, where the builtin function is used to divide unsigned 64-bit integers. Compile LTO 15 test with -fno-fat-lto-objects so that it passes on both 32-bit and 64-bit targets. PR ld/33709 * testsuite/ld-plugin/lto.exp (lto_link_tests): Compile lto-15a.c and lto-15b.c with -fno-fat-lto-objects. 2025-12-11 GDB Administrator Automatic date update in version.in 2025-12-10 Lulu Cai LoongArch32: Fix and add testcases Fixed several test failures caused by the LoongArch32 assembler adding labels during assembly. Additionally, skipped tests specific to LoongArch64. Add test for new relocations. Add test for tls type transition, got relaxation and call30 relaxation. 2025-12-10 mengqinggang LoongArch: Add linker relaxation for got_pcadd_hi20 and got_pcadd_lo12 .L1: pcaddu12i $t0, %got_pcadd_hi20(a) -> pcaddu12i $t0, %pcadd_hi20(a) ld.w/d $t0, $t0, %got_pcadd_lo12(.L1) -> addi.w/d $t0, $t0, %pcadd_lo12(.L1) 2025-12-10 mengqinggang LoongArch: Add support for tls type transition on LA32 desc -> le ie -> le desc -> ie For desc/ie -> le, need to change the symbol of le_lo12 to the symbol of [desc|ie]_pcadd_hi20. 2025-12-10 mengqinggang LoongArch: Add linker relaxation support for R_LARCH_CALL30 Relax call30 to bl, relax tail30 to b. LoongArch: LA32R macros expand Define a symbol .Lpcadd_hi* at R_LARCH_*_PCADD_HI20 if the instruction expand from macro. Change the symbol of R_LARCH_PCADD_LO12 to .Lpcadd_hi* if the instruction expand from macro. LoongArch: LA32 macros support Change pcalau12i to pcaddu12i for LA32 macros. Add call/tail and call30/tail30 macros, call/tail can expand to call36/tail36 or call30/tail30 by mabi option. 2025-12-10 mengqinggang LoongArch: Add processing for LA32/LA32R relocations R_LARCH_CALL30: pcaddu12i $ra, %call30(func) jirl $ra, $ra, 0 Similar with R_LARCH_CALL36, pcaddu12i and jirl must be adjacent. R_LARCH_PCADD_HI20, R_LARCH_PCADD_LO12: .Lpcadd_hi0: pcaddu12i $t0, %pcadd_hi20(sym) addi.w $t0, $t0, %pcadd_lo12(.Lpcadd_hi0) Similar with RISCV PCREL_HI20, PCREL_LO12, R_LARCH_PCADD_LO12 reference to the symbol at R_LARCH_PCADD_HI20. 2025-12-10 mengqinggang LoongArch: Add LA32 and LA32R relocations LA32 and LA32R do not have pcaddu18i. LA32R does not have pcalau12i. Add R_LARCH_CALL30 for pcaddu12i + jirl used in LA32 and LA32R. Add R_LARCH_*_PCADD_HI20 for pcaddu12i used in LA32R. Add R_LARCH_*_PCADD_LO12 for addi.w/ld.w used in LA32R. 2025-12-10 mengqinggang LoongArch: Enable all instructions by default on LA32 like LA64 Glibc checks LSX/LASX support when configure. Kernel has float instructions but with -msoft-float option. LoongArch: Add R_LARCH_TLS_LE_ADD_R relocation support for add.w Fix compiler error for "add.w $r12,$r12,$r2,%le_add_r(a)". 2025-12-10 Jiajie Chen LoongArch: Change DWARF2_CIE_DATA_ALIGNMENT to -4 for loongarch32 2025-12-10 mengqinggang LoongArch: Enable loongarch_elf64_vec loongarch64_pei_vec on LA32 target Fix -march=loongarch64 error on LA32 target. 2025-12-10 Thiago Jung Bauermann Revert "[gdb/guile] Use SCM_DEBUG_TYPING_STRICTNESS 0" This reverts commit 852cbc7ffadf9daf173e13ea56caff49d52733af. It fixed the build with libguile v2.0.9, but now GDB only supports Guile >= 2.2. I was able to build GDB using -std=c++20 with both Guile 2.2 and Guile 3.0 (tested with GCC 14.3) without any error or warning. Approved-By: Tom Tromey 2025-12-10 Thiago Jung Bauermann GDB: Guile: Remove procedures ineffectual since Guile 2.2 The manual mentions since GDB 10 that the functions for getting and setting the size of memory port buffers are deprecated, and don't work when using Guile 2.2 or later. Since now GDB only supports Guile 2.2 and newer, perform the promised removal. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-12-10 Thiago Jung Bauermann GDB: Guile: Remove code meant for Guile < 2.2 Approved-By: Tom Tromey 2025-12-10 GDB Administrator Automatic date update in version.in 2025-12-09 Tom de Vries [gdb] Fix whitespace in NEWS Fix this: ... $ empty=$(git hash-object -t tree /dev/null) $ git diff-index --check $empty gdb/NEWS gdb/NEWS:1874: space before tab in indent. + [--basename | --dirname] ... and add the file to the clean list in gdb/contrib/check-whitespace-pre-commit.py. [ I'm not sure if NEWS has an official style. There are no settings for NEWS in .gitattributes, so the whitespace attribute defaults to trailing-space (shorthand for blank-at-eol, blank-at-eof) and space-before-tab. We could require either spaces only (tab-in-indent) in gdb/.gitattributes: ... NEWS whitespace=space-before-tab,tab-in-indent,trailing-space ... or tab style (indent-with-non-tab): ... NEWS whitespace=space-before-tab,indent-with-non-tab,trailing-space ... For tab-in-indent, we get: ... $ git diff-index --check $empty gdb/NEWS | wc -l 228 ... and for indent-with-non-tab instead: ... $ git diff-index --check $empty gdb/NEWS | wc -l 40 ... so the more common style seems to be tab style. But I'm leaving this as is for now. ] 2025-12-09 Tom de Vries [gdb] Fix whitespace in *.def Add indent-with-non-tab for *.def in gdb*/.gitattributes. Fix whitespace in the *.def files in gdb*, and add these files to the clean list in gdb/contrib/check-whitespace-pre-commit.py. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-12-09 Tom de Vries [gdb] Fix whitespace in *.[ly] Add indent-with-non-tab for *.[ly] in gdb/.gitattributes. Fix whitespace in the *.[ly] files in gdb, and add these files to the clean list in gdb/contrib/check-whitespace-pre-commit.py. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-12-09 Tom de Vries [gdb] Fix whitespace in *.c Fix whitespace in the *.c files in gdb, and add these files to the clean list in gdb/contrib/check-whitespace-pre-commit.py. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-12-09 Tom de Vries [gdb] Fix whitespace in *.h Fix whitespace in the *.h files in gdb, and add these files to the clean list in gdb/contrib/check-whitespace-pre-commit.py. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-12-09 H.J. Lu x86: Add _bfd_elf_x86_copy_special_section_fields When Linux/x86 objcopy is used on Solaris binary, it sets EI_OSABI to ELFOSABI_SOLARIS, but it doesn't set the sh_info and sh_link fields of Solaris specific sections. Add _bfd_elf_x86_copy_special_section_fields to return false for Solaris binary to properly set the sh_info and sh_link fields of Solaris specific sections. PR binutils/33705 * elf32-i386.c (elf32_i386_copy_solaris_special_section_fields): Removed. (elf_backend_copy_special_section_fields): Likewise. * elf64-x86-64.c (elf64_x86_64_copy_solaris_special_section_fields): Likewise. (elf_backend_copy_special_section_fields): Likewise. * elfxx-x86.c (_bfd_elf_x86_copy_special_section_fields): New. * elfxx-x86.h (_bfd_elf_x86_copy_special_section_fields): Likewise. (elf_backend_copy_special_section_fields): Likewise. 2025-12-09 Tom Tromey Partly rewrite dwarf2_get_symbol_read_needs This patch partly rewries dwarf2_get_symbol_read_needs. The goal is to simplify it and perhaps make it a little more efficient. With this patch, if an operation simply continues to the next operation in the expression, then no manipulation of ops_to_visit is needed. This avoids excess pushes and pops. Also, visited_ops is changed to be a std::vector rather than a map. Regression tested on x86-64 Fedora 41. 2025-12-09 Tom Tromey Implement local-environment commands A user noted that "set environment" does not affect things like "shell" or "pipe". This makes some sense, because the environment is per-inferior, and also in the general case it may be affecting a remote machine -- i.e., the settings may not be locally appropriate. This patch adds a new set of "local-environment" commands (set, show, and unset) that affect gdb's own environment. Approved-By: Andrew Burgess Reviewed-By: Eli Zaretskii Reviewed-by: Kévin Le Gouguec 2025-12-09 Tom Tromey Allow NULL to be passed to environment-related functions This changse the various environment-related helper functions to accept a NULL environment pointer. This special case means that the function should affect gdb's global environment. Approved-By: Andrew Burgess Reviewed-by: Kévin Le Gouguec 2025-12-09 Tom Tromey Switch environment-related functions to accept a pointer This changes the environment-related helper functions to accept a pointer argument rather than a reference. Reviewed-by: Kévin Le Gouguec 2025-12-09 Tom Tromey Refactor environment-related commands This patch refactors the various environment-related commands into functions that accept gdb_environ parameter. Reviewed-by: Kévin Le Gouguec 2025-12-09 Tom Tromey Rewrite the "show environment" test In a review early in the year: https://inbox.sourceware.org/gdb-patches/874iz3f4ek.fsf@redhat.com/ Andrew pointed out that a new test I proposed failed with read1. This test was essentially a copy of gdb.base/environ.exp. I couldn't reproduce the read1 problem, but this patch rewrites the one test there that seems like it could possibly fail in this mode. Now it uses line-by-line mode and checks for a certain environment variable appearing in the output. Approved-By: Simon Marchi 2025-12-09 Simon Marchi gdb: remove unused includes from c-lang.{c,h} These includes are reported as unused by clangd. Change-Id: Ib5c655d9c96e7a612e223bd87d124f90112acc5a 2025-12-09 Simon Marchi gdb: remove unused arch-utils.h include from solib-rocm.c This include is reported as unused by clangd. Change-Id: I4fe6048d072d445a2133ac17887fe37ccc5e2d90 2025-12-09 Simon Marchi gdb: adjust guile 2.0 NEWS entry I forgot to update the previous patch based on a review comment before pushing. Change-Id: Ib357d105ba67725bfa4772f95d0b658456173be6 2025-12-09 Simon Marchi gdb: more guile 2.0 support removal Commit f14bbacae00d ("gdb/guile: remove support for Guile < 2.2") removed some code supporting Guile 2.0. This patch removes more bits related to Guile 2.0, and adds a NEWS entry. * Remove Guile 2.0 mention from the doc. * Remove HAVE_GUILE_MANUAL_FINALIZATION, assume it is always true. * Remove guile-2.0 from the versions automatically tried by configure. * Remove check for scm_new_smob (HAVE_SCM_NEW_SMOB), assume it is always true. * Remove hack to fill ac_cv_guild_program_name when the .pc file wouldn't specify it. Tested by rebuilding against guile-3.0 and guile-2.2. Change-Id: I2e89bcd4a4429262f4c3a1c74b275768e60f0cb0 Reviewed-by: Thiago Jung Bauermann Reviewed-By: Eli Zaretskii 2025-12-09 Maciej W. Rozycki BFD: Unify relocation error reporting A couple of targets use virtually the same code for error reporting in relocation processing. Merge the copies, removing small discrepancies such as a fallback call to `abort' for NDS32 targets as per PR 17512, and factor out for backends to use. 2025-12-09 Andrew Burgess gdb: fix build error after forward_scope_exit changes After commit: commit 43db8f70d86b2492b79f59342187b919fd58b3dd Date: Thu Oct 23 16:34:20 2025 +0100 gdbsupport: remove undefined behaviour from (forward_)scope_exit A build failure was reported[1] when using clang++. The failure looks like this: CXX aarch64-fbsd-tdep.o In file included from /tmp/src/binutils-gdb/gdb/aarch64-fbsd-tdep.c:22: In file included from /tmp/src/binutils-gdb/gdb/gdbarch.h:28: In file included from /tmp/src/binutils-gdb/gdb/infrun.h:21: In file included from /tmp/src/binutils-gdb/gdb/gdbthread.h:35: /tmp/src/binutils-gdb/gdb/../gdbsupport/forward-scope-exit.h:112:20: error: too many template arguments for class template 'forward_scope_exit_policy' 112 | = scope_exit_base>; | ~~~~~~~~ /tmp/src/binutils-gdb/gdb/../gdbsupport/forward-scope-exit.h:82:8: note: template is declared here 81 | template | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 82 | struct forward_scope_exit_policy; | ^ The problem is that the forward_scope_exit_policy class expects 3 template arguments, but in forward-scope-exit.h we say: template using forward_scope_exit = scope_exit_base>; Which passes 4 template arguments. Fix this by changing the above 'using' like too: template using forward_scope_exit = scope_exit_base>; This now compiles with clang++. 2025-12-09 Alan Modra tail recursion in _bfd_elf_link_hide_symbol We can clear the flags first if no backend hide_symbol function tests or sets them, which is true. * elflink.c (_bfd_elf_link_hide_symbol): Clear flags before calling elf_backend_hide_symbol, to enable tail recursion. 2025-12-09 Alan Modra gold testsuite volatile fixes Avoid these mainline gcc complaints (C23 WG14 n2743). copy_test_relro.cc:42:5: error: ‘++’ expression of ‘volatile’-qualified type is deprecated [-Werror=volatile] icf_test_pr21066.cc:50:55: error: ‘volatile’-qualified parameter is deprecated [-Werror=volatile] * testsuite/copy_test_relro.cc (segv): Avoid gcc warning. * testsuite/icf_test_pr21066.cc (capture_exception_of_type): Likewise. 2025-12-09 Alan Modra bitwise operation between different enumeration types mips.cc:9478:50: error: bitwise operation between different enumeration types ‘elfcpp::’ and ‘elfcpp::’ is deprecated [-Werror=deprecated-enum-enum-conversion] 9478 | merged_flags &= ~(elfcpp::EF_MIPS_ARCH | elfcpp::EF_MIPS_MACH); | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ * mips.h: Define all the EF_MIPS values in one enum. 2025-12-09 Lulu Cai LoongArch: Add support for the ud macro instruction In the "ud ui5" macro, the value of ui5 must be in the range 0–31. It expands to "amswap.w $rd, $r1, $rj", where ui5 specifies the register number for $rd in the amswap.w instruction, and $rd == $rj. The test case have been adjusted to no longer report errors for illegal operands of the amswap.w instruction. gas/ * config/tc-loongarch.c (check_this_insn_before_appending): No longer check amswap.w. * testsuite/gas/loongarch/illegal-operand.l: Update. * testsuite/gas/loongarch/illegal-operand.s: Update. * testsuite/gas/loongarch/macro_ud.d: New test. * testsuite/gas/loongarch/macro_ud.s: New test. include/ * opcode/loongarch.h: Add new macro for amswap.w. opcodes/ * loongarch-opc.c: Add macro for ud. 2025-12-09 Alan Modra lto-wrapper warning note Current gcc adds a note to the LTO "using serial compilation" warning. * lib/binutils-common.exp (prune_warnings_extra): Remove lto-wrapper note. 2025-12-09 GDB Administrator Automatic date update in version.in 2025-12-08 H.J. Lu i386: Add GLIBC_ABI_GNU_TLS dependency only if used Add GLIBC_ABI_GNU_TLS version dependency only if ___tls_get_addr is referenced by regular object. bfd/ PR ld/33287 PR ld/33702 * elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Set has_tls_get_addr_call only if referenced by regular object. ld/ PR ld/33287 PR ld/33702 * testsuite/ld-i386/i386.exp: Run PR ld/33702 test. * testsuite/ld-i386/no-tls.c: New file. 2025-12-08 Alan Modra Revert "Re: Add warning message to readelf for local symbols" This reverts commit f70242a98f91b7f5ec5b375346d8bfa7f9a61c4a. Nick already applied this.. Re: Add warning message to readelf for local symbols Limit the warning to ET_REL. 2025-12-08 Tom de Vries [gdb/contrib] Add more clean files in check-whitespace-pre-commit.py Add gdbsupport and gdbserver as whitespace-clean in gdb/contrib/check-whitespace-pre-commit.py. Likewise for *.ac and *.m4. Also drop the ignore of configure, that's already taken care of in .gitattributes. Approved-By: Tom Tromey 2025-12-08 Tom de Vries [gdb/testsuite] Simplify gdb.multi/remote-with-running-inferior.exp Simplify regexps in test-case gdb.multi/remote-with-running-inferior.exp using string_to_regexp and {}. While we're at it, also break an overly long line. Tested on x86_64-linux. 2025-12-08 Tom de Vries [gdb/testsuite] Fix two typos in gdb.multi/remote-with-running-inferior.exp Fix two typos in test-case gdb.multi/remote-with-running-inferior.exp. 2025-12-08 Tom de Vries [gdb/testsuite] Fix FAIL in gdb.multi/remote-with-running-inferior.exp Occasionally, with test-case gdb.multi/remote-with-running-inferior.exp I run into: ... (gdb) continue^M Continuing.^M ^M Thread 1.1 "remote-with-run" hit Breakpoint 1.1, main () at \ remote-with-running-inferior.c:31^M 31 for (int i = 0; i < 30; ++i)^M (gdb) PASS: $exp: target_non_stop=auto: non_stop=off: \ continue to breakpoint: continue to breakpoint in breakpt bt 1^M (gdb) FAIL: $exp: target_non_stop=auto: non_stop=off: \ check inferior 1 is in breakpt ... The problem is a race between: - inferior 1 reaching main, and - gdb setting a breakpoint on main. If the breakpoint on main is set before inferior 1 reaches main, the breakpoint triggers for inferior 1, which the test-case doesn't expect. Fix this by setting the breakpoint on main only for inferior 2. Tested on x86_64-linux. PR testsuite/33621 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33621 2025-12-08 Alan Modra readelf: Only check for out of bounds local symbols in object files 2025-12-08 Nick Clifton Fix typo in aarch64-opc.c 2025-12-08 Andrew Burgess gdbsupport: remove undefined behaviour from (forward_)scope_exit Our implementation of scope_exit and forward_scope_exit make use of the Curiously Recurring Template Pattern (CRTP) to provide the "release" functionality, this is done in the scope_exit_base class in scope-exit.h. The interesting (for this commit) parts of scope_exit_base look like this: template class scope_exit_base { public: scope_exit_base () = default; ~scope_exit_base () { if (!m_released) { auto *self = static_cast (this); self->on_exit (); } } ... snip ... }; By the time ~scope_exit_base is called the destructor for the derived class (called CRTP here) has already been run, which means any data members in the derived class will have also have had their destructors run. As a result of this I believe that casting 'this' to the derived type, and then calling the on_exit method is undefined behaviour, as 'this' can no longer be considered a valid instance of CRTP (the CRTP part has been destructed). In reality, the memory for the derived type is not reclaimed until after ~scope_exit_base has finished, so as long as the data members of the derived type are Plain Old Data (POD), then the current code should be just fine; any data members of the derived class will remain in place, and untouched, until ~scope_exit_base has completed. But still, I don't think we should rely on undefined behaviour. I actually ran into this when, in another series, I tried to reuse scope_exit_base with a class where a data member was not POD, and in this case GDB would crash because my new on_exit function was making use of the non-POD data member after it had been destructed, and resources released. I propose that we move away from the CRTP, and instead flip the class hierarchy. Instead of derived classes like scope_exit inheriting from scope_exit_base, scope_exit_base should inherit from scope_exit. What this means, is that when ~scope_exit_base is called, ~scope_exit will not yet have been run, and the data members of scope_exit will still be valid. To allow the existing names to be used, the plan is that the existing scope_exit and forward_scope_exit classes are renamed to scope_exit_policy and forward_scope_exit_policy. These policy classes will then be injected via a template argument as the base class for scope_exit_base. Finally, we can: template using scope_exit = scope_exit_base>; which defines the scope_exit type. This type is a drop in replacement with all of GDB's existing code, but avoids the undefined behaviour. We can do something similar with forward_scope_exit. There should be no user visible changes after this commit. 2025-12-08 Nick Clifton readelf: Do not warn about mapping symbols that extend beyond the end of mergeable sections 2025-12-08 Guinevere Larsen Revert "gdb/record_full: add ptid entry for history." This reverts commit b8524f61e398072f83938fb805f377f22198f9a9. It was pushed by mistake with an unrelated patch. 2025-12-08 Guinevere Larsen bfd: fix build with C23 Starting in C23, strchr and strrchr will return const char *, if fed a const char *. This means that several files in the BFD directory will fail to build as they are assigning the return of those functions to a char *. Fix this by const-ifying several variables. The only place where that wasn't just that was in targets.c, where a variable was being used in subsequent strrchr invocations to change the underlying string, so a new variable had to be introduced. No user-visible change should happen after this commit. 2025-12-08 Guinevere Larsen gdb/record_full: add ptid entry for history. For record full to work on multi-threaded inferiors, we must know to which thread any given recorded instruction belongs to. This commit adds this as a new entry for each instruction when an inferior is multi-threaded. This way, when replaying the instruction, the subsystem is able to change inferior thread as needed, and avoid SIGILLs when changing stuff Ideally, we would only add the PTID entry when we actually need to switch threads, but that is left as a future improvement. WIP: replaying doesn't automatically change threads yet, but there was an attempt 2025-12-08 Magnus Wållberg PR 33676 ld segfaults when using binary input inside NOLOAD The code at ldlang.c:2840-2841 checks if the output BFD is ELF format, then unconditionally uses elf_section_type() on the input section without verifying the input section is also ELF format. This was introduced in commit d87be451e (PR ld/32787) which added special handling for NOLOAD note sections. PR 33676 PR 32787 * ldlang.c (lang_add_section): Check section owner's BFD flavour before using elf_section_type. 2025-12-08 Alan Modra PR 33701, abort in byte_get_little_endian PR 33701 * dwarf.c (process_debug_info): Set debug_info_p NULL when DEBUG_INFO_UNAVAILABLE. 2025-12-08 Alan Modra PR 33698 and PR 33700 It is possible for dump_relocations to return on an error from slurp_rela_relocs or slurp_rel_relocs without writing to "all_relocations". In that case an uninitialised r_symbol is passed to free at the end of process_got_section_contents. PR 33698 PR 33700 * readelf.c (update_all_relocations): Zero array. Remove unnecessary casts. 2025-12-08 Alan Modra PR 33697, fuzzer segfault PR 33697 * readelf.c (process_relocs): Don't segfault on no sections. 2025-12-08 Nick Clifton GAS: Change S parameter of find_no_app to CHAR* in order to avoid problems with STRSTR returning a CONST CHAR* PR 33696 2025-12-08 Tom de Vries [gdb/build] Add gdb subdirs in gdb.pot I found that gettext strings from gdb/cli are not added to gdb.pot. Fix this by explicitly listing the gdb subdirs in the po/$(PACKAGE).pot rule in gdb/Makefile.in. Tested by doing: ... $ cd build/gdb $ make po/gdb.pot ... $ grep -c cli/ po/gdb.pot 345 ... 2025-12-08 Tom de Vries [gdb/build] Re-add *.[ch] in gdb.pot In commit 4a40fe05bf0 ("[gdb/build] Handle gdbsupport and gdbserver in gdb.pot"), in order to handle '*.cc' files I did: ... - -name '*.[hc]' -print + -name '*.[hc]' -o -name '*.cc' -print ... but failed to understand that this no longer printed the '*.[hc]' names. Fix this by adding a '-print' for '*.[hc]'. Tested by doing: ... $ cd build/gdb $ make po/gdb.pot ... $ grep -c symtab.c po/gdb.pot 102 ... 2025-12-08 H.J. Lu elf: Add SHT_SUNW_ctf and SHT_SUNW_symnsort On Solaris 11.4, there is SHT_SUNW_symnsort and no SHT_SUNW_symtabnsort. SHT_SUNW_symnsort is defined to 0x6fffffec, which is the same as SHT_SUNW_symtabnsort. There is also SHT_SUNW_ctf. Add SHT_SUNW_ctf and rename SHT_SUNW_symtabnsort to SHT_SUNW_symnsort. Move SHT_SUNW_phname after SHT_SUNW_symnsort. binutils/ * readelf.c (get_solaris_section_type): Add SHT_SUNW_ctf and SHT_SUNW_symnsort. Move SHT_SUNW_phname after SHT_SUNW_symnsort. Remove SHT_SUNW_symtabnsort. include/ * elf/common.h (SHT_SUNW_ctf): New. (SHT_SUNW_symtabnsort): Renamed to ... (SHT_SUNW_symnsort): This. (SHT_SUNW_phname): Moved after SHT_SUNW_symnsort. 2025-12-08 GDB Administrator Automatic date update in version.in 2025-12-07 Tom Tromey Unconditionally pass is_a_field_of_this in c-exp.y In a review to a different patch of mine, Simon asked for this change. The idea here is that there's no need to pass null as the "field of this" parameter, as lookup_language_this checks the language anyway. Approved-By: Simon Marchi 2025-12-07 Tom de Vries [gdb/contrib] Check clean files in check-whitespace-pre-commit.sh The pre-commit check check-whitespace checks diffs. Consequently, we detect something like this: ... $ echo >> gdb/testsuite/lib/gdb.exp $ git commit -a -m trailing-empty-line ... check-whitespace.........................................................Failed - hook id: check-whitespace - duration: 0.01s - exit code: 2 gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF. ... But say we work around the failing check using --no-verify, then we no longer detect it after the commit has succeeded: ... $ git commit -a -m trailing-empty-line --no-verify [detached HEAD e6302105522] trailing-empty-line 1 file changed, 1 insertion(+) $ pre-commit run --all-files check-whitespace check-whitespace.........................................................Passed - hook id: check-whitespace - duration: 0.3s ... Fix this in check-whitespace-pre-commit.sh by distinguishing between clean and other files. Doing so is easier to do in a more advanced scripting language, so rewrite into python. Since a recent commit, gdb/testsuite is clean, so I'm using that as simple classifier for now. For the other files we do what we did before, and check just the staging area: ... $ git --no-pager diff --staged --check "${other[@]}" ... But for clean files, we check the entire file, including staged changes: ... $ empty=$(git hash-object -t tree /dev/null) $ git diff-index --cached --check $empty "${clean[@]}" ... Consequently, we do see: ... $ git commit -a -m trailing-empty-line --no-verify [detached HEAD e6302105522] trailing-empty-line 1 file changed, 1 insertion(+) $ pre-commit run --all-files check-whitespace check-whitespace.........................................................Failed - hook id: check-whitespace - duration: 0.64s - exit code: 2 gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF. ... PR build/33616 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616 2025-12-07 GDB Administrator Automatic date update in version.in 2025-12-06 H.J. Lu hppa64: Set has_local_dynsyms when adding __text_seg/__data_seg commit 54fbc12d6404b645363f901110a21f4410067df5 Author: H.J. Lu Date: Fri Nov 28 16:07:57 2025 +0800 elf: Renumber local dynamic symbols only if needed caused regressions for hppa64-linux which adds local dynamic symbols, __text_seg and __data_seg in elf64_hppa_late_size_sections. Set has_local_dynsyms to true when adding __text_seg and __data_seg. * elf64-hppa.c (elf64_hppa_late_size_sections): Set has_local_dynsyms to true when adding __text_seg and __data_seg. 2025-12-06 GDB Administrator Automatic date update in version.in 2025-12-05 Andrew Burgess sim: make local variable 'const' This build error was reported to me off list: common/callback.c:993:13: error: initializing 'char *' with an expression of type 'const char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] 993 | char *q = strchr (m, ','); | ^ ~~~~~~~~~~~~~~~ This is because with C23, strchr returns 'const char *' if a 'const char *' is passed as an argument. In this case M is 'const char *', so Q should also be 'const char *'. And indeed, we don't write via Q at any time, so lets make it 'const'. There should be no user visible changes after this commit. 2025-12-05 Andrew Burgess gdb: display a symbol more often in multi-file list output I noticed that when a command line 'list foo.c:10' displays multiple files, the symbol would always be shown as "???", e.g.: file: "/tmp/foo.c", line number: 10, symbol: "???" this is because, when the symtab_and_line is created for the 'foo.c:10', the pc and symbol are never filled in. In this commit, I propose that, when we decide that the above header line needs to be printed, we should attempt to lookup a symbol for the relevant line, and if one is found, we can use that. The symbol lookup is done by first calling find_pc_for_line, and then using find_symbol_for_pc to find a suitable symbol. Approved-By: Tom Tromey 2025-12-05 Lancelot SIX [gdb/testsuite] Use gdb_load in gdb.rocm/break-kernel-no-debug-info.exp The gdb.rocm/break-kernel-no-debug-info.exp builds a testcase without debug info, and loads the binary in GDB with: gdb_test "file $::binfile" ".*No debugging symbols.*" "load file" On some configurations (SLES with glibc-devel installed), the compiler links /usr/lib64/crit1.o (which contains some debug information) into the final binary. As a result, the binary contains "some" debug information, which makes the above pattern fail. The testcase is still valid as we only really need the GPU code object (embedded in the main binary) to not contain debug information, so this patch proposes to relax this first step by using "gdb_load" instead. Tested on x86_64-linux + AMDGPU gfx1031. Change-Id: Id903f62e170af69c001b39f4681602a54e2fdaf1 Approved-By: Tom Tromey 2025-12-05 Andrew Burgess gdb: fix 'list' for multiple source file results This commit: commit c7a45b98a61451f05ff654c4fb72a9c9cb2fba36 Date: Thu Jun 12 15:37:50 2025 +0000 gdb, linespec: avoid multiple locations with same PC broke GDB's ability to list multiple source files using a 'list' command. In GDB 16 and earlier something like 'list foo.c:10' could print multiple results if there were multiple 'foo.c' files compiled into the executable. The above commit added a filter to add_sal_to_sals (linespec.c) such that multiple sals in the same program space, but with the same pc value, could not be added, only the first sal would actually be recorded. The problem with this is that add_sal_to_sals is used from decode_digits_list_mode (also linespec.c) where the pc value is forced to zero. This force to zero makes sense I think as there might not be any compiled code for the requested line (this is for 'list' after all), so there might not be a valid pc to use. I'm not a fan of using '0' as a special pc value, there are embedded targets where 0 is a valid pc value, but given we're already using 0 here, I propose to just roll with it. So, my proposal is that, if the pc is 0, add_sal_to_sals should always add the sal. This fixes the decode_digits_list_mode, but should keep the fix that c7a45b98a614 introduced. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33647 Approved-By: Tom Tromey Reviewed-By: Kevin Buettner 2025-12-05 Jan Beulich x86-64: use BFD_RELOC_32_PLT_PCREL in favor of custom type No reason to have a separate type when the generic one has no (other) meaning for this target. x86-64: use BFD_RELOC_64_PLTOFF in favor of custom type No reason to have a separate type when the generic one has no (other) meaning for this target. bfd: drop BFD_RELOC_VPE4KMATH_* These relocation types are entirely unused. bfd: drop BFD_RELOC_I370_D12 i370 support is long gone from binutils, and this relocation is entirely unused. 2025-12-05 Umesh Kalvakuntla Add AMD znver6 processor support In --help option, adds znver6 to the list of CPUs under -march. Please find the ISA descriptions for AVX512_BMM instructions below. AVX512 Bit Manipulation Instructions ==================================== The AVX512BMM instructions include Bit Matrix Multiply and Bit Reversal operations. CPUID ----- Support is indicated by the new CPUID 8000_0021, EAX bit 23, labeled AVX512_BMM. Encoding -------- VBMACOR16x16x16 EVEX.256.NP.MAP6.W0 80 /r VBMACOR16x16x16 ymm1, ymm2, ymm3/m256 EVEX.512.NP.MAP6.W0 80 /r VBMACOR16x16x16 zmm1, zmm2, zmm3/m512 VBMACXOR16x16x16 EVEX.256.NP.MAP6.W1 80 /r VBMACXOR16x16x16 ymm1, ymm2, ymm3/m256 EVEX.512.NP.MAP6.W1 80 /r VBMACXOR16x16x16 zmm1, zmm2, zmm3/m512 DESCRIPTION ----------- 256 BIT VERSIONS ---------------- 16x16 non-transposed fused BMM-accumulate (BMAC) with OR/XOR reduction. A ymm register holds a 16x16 bit matrix. The third source matrix for accumulation is in ymm1. 512 BIT VERSIONS ---------------- 2 parallel 16x16 non-transposed fused BMM-accumulate (BMAC) with OR/XOR reduction. Each 256-bit chunk of a zmm register holds a 16x16 bit matrix. The third source matrices for accumulation are in zmm1. VBITREVB -------- EVEX.128.NP.MAP6.W0 81 /r VBITREVB xmm1{k1}{z}, xmm2/m128 EVEX.256.NP.MAP6.W0 81 /r VBITREVB ymm1{k1}{z}, ymm2/m256 EVEX.512.NP.MAP6.W0 81 /r VBITREVB zmm1{k1}{z}, zmm2/m512 DESCRIPTION ----------- Bit reversal within a byte boundary. Only applied to input bytes where the corresponding mask bit is set; otherwise, bytes are left untouched or zeroed out if zero masking is indicated. gas/ChangeLog: * NEWS: Add znver6 ARCH. * config/tc-i386.c: Add znver6 ARCH, avx512_bmm SUBARCH. * doc/c-i386.texi: Likewise. * testsuite/gas/i386/i386.exp: Add znver6 test cases. * testsuite/gas/i386/x86-64.exp: Add znver6 test cases. * testsuite/gas/i386/arch-16-znver6.d: New test. * testsuite/gas/i386/arch-16.d: New test. * testsuite/gas/i386/arch-16.s: New test. * testsuite/gas/i386/avx512_bmm.d: New test. * testsuite/gas/i386/avx512_bmm.s: New test. * testsuite/gas/i386/avx512_bmm_vl-inval.l: New test. * testsuite/gas/i386/avx512_bmm_vl-inval.s: New test. * testsuite/gas/i386/avx512_bmm_vl.d: New test. * testsuite/gas/i386/avx512_bmm_vl.s: New test. * testsuite/gas/i386/x86-64-arch-6-znver6.d: New test. * testsuite/gas/i386/x86-64-arch-6.d: New test. * testsuite/gas/i386/x86-64-arch-6.s: New test. * testsuite/gas/i386/x86-64-avx512_bmm-bad.d: New test. * testsuite/gas/i386/x86-64-avx512_bmm-bad.s: New test. * testsuite/gas/i386/x86-64-avx512_bmm.d: New test. * testsuite/gas/i386/x86-64-avx512_bmm.s: New test. * testsuite/gas/i386/x86-64-avx512_bmm_vl-inval.l: New test. * testsuite/gas/i386/x86-64-avx512_bmm_vl-inval.s: New test. * testsuite/gas/i386/x86-64-avx512_bmm_vl.d: New test. * testsuite/gas/i386/x86-64-avx512_bmm_vl.s: New test. opcodes/ChangeLog: * i386-dis-evex-len.h: Likewise. * i386-dis-evex-w.h: Likewise. * i386-dis-evex.h: Likewise. * i386-dis.c: Add EVEX_W_MAP6_80, EVEX_W_MAP6_81, EVEX_LEN_MAP6_80_W_0, EVEX_LEN_MAP6_80_W_1. * i386-gen.c: Likewise. * i386-init.h: Re-generated. * i386-mnem.h: Re-generated. * i386-opc.h (enum i386_cpu): Add CpuAVX512_BMM. (i386_cpu_flags): Add cpuvavx512_bmm. * i386-opc.tbl: Add vbmacor16x16x16, vbmacxor16x16x16, vbitrevb. * i386-tbl.h: Re-generated. 2025-12-05 Jan Beulich x86: sub-divide APX_F - NCI-NDD-NF and testing To reflect spec version 007's introduction of the three-way APX-NCI-NDD-NF also introduce a respective ISA specifier, without that actually having a counterpart in opcodes. Add a testcase to cover all four new ISA specifiers. 2025-12-05 Jan Beulich x86: sub-divide APX_F - NF While spec version 007 introduced the three-way APX-NCI-NDD-NF, let's split the three aspects (NCI, NDD, and NF) in gas. For NF we only need to guard the {nf} pseudo-prefix. 2025-12-05 Jan Beulich x86: sub-divide APX_F - NDD While spec version 007 introduced the three-way APX-NCI-NDD-NF, let's split the three aspects (NCI, NDD, and NF) in gas. Note that NDD also applies to a number of EVEX-encoded insns with EVEX.ndd clear. Some extra logic is needed in cpu_flags_match() to avoid the need to add APX_NDD to CPU_FLAGS_COMMON. 2025-12-05 Jan Beulich x86: sub-divide APX_F - NCI While spec version 007 introduced the three-way APX-NCI-NDD-NF, let's split the three aspects (NCI, NDD, and NF) in gas. While adjusting CMOVcc and CFCMOVcc, drop the bogus CpuCMOV dependencies. Such a requirement was never specified in any public doc revision. Note also that the EVEX-encoded forms of TEST were lacking CpuAPX_F so far. 2025-12-05 Jan Beulich x86: correct {RD,WR}{FS,GS}BASE {dis,}assembly First they are valid only in 64-bit mode. And then an operand size prefix has no meaning here, hence v_mode is wrong to use; switch to dq_mode. 2025-12-05 Tom de Vries [gdb/testsuite] Fix gdb.base/long_long.exp on arm On armv7hl-suse-linux-gnu, I run into: ... (gdb) p/f val.oct $26 = -5.9822653797615723e-120 (gdb) FAIL: gdb.base/long_long.exp: p/f val.oct ... There's some complicated logic here in the test-case: ... if { $sizeof_double == 8 || $sizeof_long_double == 8 } { # ARM FPA floating point numbers are not strictly little endian or big # endian, but a hybrid. They are in little endian format with the two # words swapped in big endian format. # EABI targets default to natural-endian VFP format. if { ([istarget "arm*-*-*"]) \ && !([istarget "*-*-*eabi*"] || \ [istarget "*-*-mingw32ce*"] || \ [istarget "*-*-openbsd*"]) } then { # assume the long long represents a floating point double in ARM format gdb_test "p/f val.oct" "2.1386676354387559e\\+265" } else { # assume the long long represents a floating point double in little # endian format gdb_test "p/f val.oct" "-5.9822653797615723e-120" } } else { gdb_test "p/f val.oct" "-2.42716126e-15" } ... which makes the test-case expect the ARM FPA variant. I think trying to pin down the exact circumstances under which we have ARM FPA is unnecessary, so I could live with: ... set re_val_oct_f [string_to_regexp "-5.9822653797615723e-120"] if { [istarget "arm*-*-*"] } { set re_val_oct_f_arm_fpa [string_to_regexp "2.1386676354387559e+265"] re_val_oct_f "$re_val_oct_f|$re_val_oct_f_arm_fpa" } .... But instead, I propose to just drop the arm-specific part. I doubt whether an ARM VPA setup is still part of any test matrix. And if it is, then I expect other tests to fail as well for the same reason. The ARM FPA logic is used only once in the test-case, but -5.9822653797615723e-120 is used more frequently. Indeed, I wonder the same about setups where -2.42716126e-15 is expected. On such a setup, won't this fail as well: ... gdb_test "x/2gf g" "3.5127005640885037e-303.*-5.9822653797615723e-120" ... ? Unfortunately I'm not sure what setup to use to trigger the -2.42716126e-15 case. Fix this as good as possible by choosing once between -5.9822653797615723e-120 and -2.42716126e-15, assigning it to re_val_oct_f, and using it everywhere where those constants are used. Tested on x86_64-linux. Reviewed-by: Thiago Jung Bauermann PR testsuite/33669 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33669 2025-12-05 GDB Administrator Automatic date update in version.in 2025-12-04 Andrew Burgess gdb: small white space fix in print_gdb_hints A small white space fix in print_gdb_hints. There should be no user visible changes after this commit. Reviewed-By: Guinevere Larsen 2025-12-04 Andrew Burgess gdb: remove some unnecessary code from print_gdb_hints I noticed some code in print_gdb_hints that is unused. I rolled a patch, but while I was doing that commit: commit 06e470d8fc0ae0e83fe0977fdf8c011998980891 Date: Sat Nov 29 15:48:55 2025 +0100 gdb: handle unlimited screen width case in print_gdb_hints was merged that deleted some of the code I'd spotted. All that's left is a 'return' that can be removed, there's nothing after the 'if' block, the function just returns. There should be no user visible changes after this commit. Reviewed-By: Guinevere Larsen 2025-12-04 Tom Tromey Fix 'ptype' of a certain Ada modular type If an Ada modular type is the same size as gdb's own ULONGEST, ptype will show "mod 0". This happens because ada_modulus does: return (ULONGEST) high.const_val () + 1; This patch cleans this up, replacing ada_modulus with a function to return the upper bound (if available), and then fixing the various callers. The type-printing caller still does the "+1", but now this is done with a gdb_mpz. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33690 Approved-By: Simon Marchi 2025-12-04 Simon Marchi gdb: remove find_target_at ... to make the current_inferior reference bubble up one level. Since find_target_at would become a trivial wrapper around inferior::target_at, remove it. I think it's clearer anyway to see explicitly that the "subject" of the method call is the inferior. Change-Id: I73ec44d37e7afea6e85b1689af65e32ae8e5a695 Approved-By: Tom Tromey 2025-12-04 Alice Carlotti aarch64: Enable `-M notes' by default We already print other instruction comments, such as condition code aliases, by default. The `-M no-notes' option has been available in Binutils for over 7 years, so if anyone does need the notes to be disabled then they can do so explicitly. aarch64: Refactor sysreg operand printing This hopefully makes the logic clearer. It also adds NULL checks before recording notes, and explicitly compares the inexactness of inexact matches (although this extra comparison isn't used for any existing encodings). 2025-12-04 Alice Carlotti aarch64: Fix incorrect sysreg notes operand notes When support for Armv8-R was added in 2020, aarch64_print_operand was modified to check architecture features when searching for a system register name. However, this mismatch is then conflated with read-only/write-only mismatches, leading to incorrect note emission when reading a read-only or writing a write-only system register that is not available in whichever of Armv8-A or Armv8-R we are using. The original code also segfaults when parsing `msr mpuir_el1, w1'. This segfault arises while suggesting alternative assembler input with corrected qualifiers, due to a missing NULL check when attempting to emit notes. The segfault is unreachable after this change, but a subsequent patch will incorporate NULL checking anyway. Once notes are enabled by default, an existing `mrs x0, mpuir_el1' test will verify that the incorrect notes are no longer generated. 2025-12-04 Alice Carlotti aarch64: Improve comment for aarch64_opnd_info.sysreg.flags This field is used differently during assembly and disassembly. It would be nice if we could make this more consistent, but for now just extend the comment to explain what is going on. 2025-12-04 Tom Tromey Return bool from ada_is_modular_type This changes ada_is_modular_type to return bool. 2025-12-04 Patrick Monnerat gdb: handle unlimited screen width case in print_gdb_hints This avoids a crash when this function is called while screen width is unlimited. In such a case (unconditionally occurring in insight), WIDTH is returned as a negative signed integer, so it has to be compared to another signed integer, not a size_t. Also remove an unused WIDTH-sized variable that may fail in the above case. 2025-12-04 Nick Clifton Add warning message to readelf for local symbols that reference beyond the end of a mergeable section. 2025-12-04 Tom de Vries [gdb/testsuite] Fix build-id check in gdb.python/py-missing-objfile.exp I recently added two requires in test-case gdb.python/py-missing-objfile.exp: ... # The following tests assume that the build-ids of binfile and libfile can be # found in the core file. require {expect_build_id_in_core_file $binfile} require {expect_build_id_in_core_file $libfile} ... However, at the point where the check is done, the files are no longer available at that location, which makes the require fail. First, make the problem visible, by making proc expect_build_id_in_core_file throw an error if the filename argument specifies a non-existing file. Then, fix test-case gdb.python/py-missing-objfile.exp by moving the calls to expect_build_id_in_core_file to a point where the files exist. Tested on x86_64-linux. 2025-12-04 H.J. Lu copy_object: Re-indent * objcopy.c (copy_object): Re-indent. 2025-12-04 GDB Administrator Automatic date update in version.in 2025-12-03 Thiago Jung Bauermann gdb/testsuite: Fix doc comment in allow_aarch64_sme_tests The comment says that it returns 0 if the target supports SME and 1 if it doesn't, but it actually does the opposite. The code does the right thing, so fix the comment. 2025-12-03 timurgol007 gdb/record: Support fense.tso, zicond, bitmanip, sinval and zihintntl in RISC-V Added record-full support for these extensions. Approved-by: Tom Tromey 2025-12-03 Tom Tromey Fix some indentation in rust-lang.c I noticed some incorrect indentation in rust-lang.c. This fixes it. 2025-12-03 Tom de Vries [gdbsupport] Clean whitespace Clean whitespace issues in ax.def and rsp-low.cc. Approved-By: Simon Marchi 2025-12-03 Tom de Vries [gdbsupport] Handle Makefile.in and unordered_dense in .gitattributes Unset the whitespace attribute in .gitattributes for: - Makefile.in (because it's generated), and - unordered_dense/* (because they're imported). Approved-By: Simon Marchi 2025-12-03 Simon Marchi gdb/guile: remove support for Guile < 2.2 I propose to remove the code in guile/scm-ports.c supporting Guile < 2.2. The rationale is: - The code within USING_GUILE_BEFORE_2_2 amounts to about half of the file, it makes it much more complicated than it would be otherwise. I'm trying to investigate PR 29825 [1] and this is getting in the way. - Guile 2.2, which would now be the baseline for what we require, is now 8 years old. Guile 2.2 is legacy (the current stable branch is 3.0), but it is still actively packaged [2][3]. - The Guile support code doesn't receive as much contribution, testing and love as the Python support code, for instance. We don't have cycles to spare to support an obsolete version of Guile. This patch removes the USING_GUILE_BEFORE_2_2 define and all the portions of code within `#if USING_GUILE_BEFORE_2_2`. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29825 [2] https://packages.debian.org/sid/guile-2.2-dev [3] https://archlinux.org/packages/extra/x86_64/guile2.2/ Change-Id: I926e79cde9835567eb3b7e3d22db402c841b79d7 Reviewed-by: Thiago Jung Bauermann 2025-12-03 Tom Tromey Print more template parameters with ptype This bug points out that a template parameter that is a constant is not printed by 'ptype' -- in fact, only type parameters are displayed. However, there's no real reason for this, and any template parameter that the DWARF reader can turn into a symbol should be printable. Note that some parameters are still missing from the DWARF; see the kfails in the test for details. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33670 Reviewed-By: Christina Schimpe Approved-By: Andrew Burgess 2025-12-03 Tom de Vries [gdb/testsuite] Fix ERROR: can't read _line_unit_advertised_version: no such variable With test-case gdb.base/until-trailing-insns.exp I run into: ... ERROR: tcl error code TCL READ VARNAME ERROR: can't read "_line_unit_advertised_version": no such variable while executing "if {$_line_unit_advertised_version == "default"} { set _line_unit_advertised_version $_line_unit_version }" ... Fix this by using the correct variable name in two places in Dwarf::lines: use _line_unit_advertised_version instead of _line_advertised_unit_version. Tested on x86_64-linux. 2025-12-03 Tom de Vries [gdb/symtab] Fix DW_TAG_member regression On openSUSE Leap 15.6 x86_64, with gcc 7 and test-case gdb.base/condbreak-multi-context.exp I run into: ... (gdb) print aaa^M $3 = ^M (gdb) FAIL: $exp: start_before=true: scenario_1: print aaa ... This is a regression since commit 86ac8c54623 ("Convert lookup_symbol_in_objfile"). Likewise in test-cases gdb.cp/m-static.exp and gdb.cp/namespace.exp. The failure is specific to using Dwarf v4: - using target board unix/gdb:debug_flags=-gdwarf-5 fixes it - using target board unix/gdb:debug_flags=-gdwarf-4 on Tumbleweed (with gcc 15 and Dwarf v5 default) triggers it The variable we're trying to print, A::aaa is a static const int member: ... class A : public Base { public: static const int aaa = 10; ... }; ... With Dwarf v5, we have this DIE: ... <2><356>: Abbrev Number: 2 (DW_TAG_variable) <357> DW_AT_name : aaa <35c> DW_AT_linkage_name: _ZN1A3aaaE <364> DW_AT_external : 1 <364> DW_AT_accessibility: 1 (public) <364> DW_AT_declaration : 1 <364> DW_AT_const_value : 10 ... and the cooked index contains these corresponding entries: ... [45] ((cooked_index_entry *) 0x7facf0004730) name: _ZN1A3aaaE canonical: _ZN1A3aaaE qualified: _ZN1A3aaaE DWARF tag: DW_TAG_variable flags: 0x4 [IS_LINKAGE] DIE offset: 0x356 parent: ((cooked_index_entry *) 0) [52] ((cooked_index_entry *) 0x7facf0004700) name: aaa canonical: aaa qualified: A::aaa DWARF tag: DW_TAG_variable flags: 0x0 [] DIE offset: 0x356 parent: ((cooked_index_entry *) 0x7facf00046d0) [A] ... With Dwarf v4, we have instead the following DIE: ... <2><350>: Abbrev Number: 3 (DW_TAG_member) <351> DW_AT_name : aaa <35b> DW_AT_external : 1 <35b> DW_AT_accessibility: 1 (public) <35c> DW_AT_declaration : 1 <35c> DW_AT_const_value : 4 byte block: a 0 0 0 ... and there are no corresponding entries. Fix this by adding an entry: ... [47] ((cooked_index_entry *) 0x7f5a24004660) name: aaa canonical: aaa qualified: A::aaa DWARF tag: DW_TAG_member flags: 0x0 [] DIE offset: 0x350 parent: ((cooked_index_entry *) 0x7f5a24004630) [A] ... Add a regression test in the form of a dwarf assembly test-case printing the value of variable A::aaa. In the test-case, for A::aaa, DW_FORM_flag is used to encode DW_AT_declaration. In v1 of this patch that mattered (because of using has_hardcoded_declaration in abbrev_table::read), but that's no longer the case. Nevertheless, also add an A::bbb using FORM_flag_present for DW_AT_declaration (and while we're at it, DW_AT_external as well). Also add two variants, for which is printed: - A::ccc: a variant with DW_AT_location instead of DW_AT_const_value, and - A::ddd: a variant without external. This behavior is not part of the regression. I've reproduced it using a system gdb based on 14.2. It's also not specific to using the cooked index, it reproduces with -readnow as well. Tested on x86_64-linux. Approved-By: Tom Tromey PR symtab/33415 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33415 2025-12-03 Tom de Vries [gdb/symtab] Bail out for too short line header The Free Pascal Compiler fpc supports generating different versions of DWARF: ... $ fpc -h Free Pascal Compiler version 3.2.2 [2025/09/10] for x86_64 ... -gw Generate DWARFv2 debug information (same as -gw2) -gw2 Generate DWARFv2 debug information -gw3 Generate DWARFv3 debug information -gw4 Generate DWARFv4 debug information (experimental) ... The v4 support is experimental, and indeed the line number information is broken (missing maximum_operations_per_instruction field in the .debug_line header), so setting a breakpoint on a line number is not possible: ... $ fpc -gw4 hello.pas ... $ gdb -q hello Reading symbols from hello... (gdb) b hello.pas:8 No compiled code for line 8 in file "hello.pas". Make breakpoint pending on future shared library load? (y or [n]) ... The brokenness is detected by llvm-dwarfdump (second warning): ... $ llvm-dwarfdump -debug-line hello hello: file format elf64-x86-64 .debug_line contents: debug_line[0x00000000] warning: parsing line table prologue at offset 0x0 found opcode base of 0. \ Assuming no standard opcodes warning: unknown data in line table prologue at offset 0x0: parsing ended (at \ offset 0x00000017) before reaching the prologue end at offset 0x2a ... Likewise, detect the situation the second warning describes in dwarf_decode_line_header, getting us instead: ... (gdb) b hello.pas:8 ❌malformed line number program header, advertised length does not match \ actual length (gdb) ... Tested on x86_64-linux. Approved-By: Simon Marchi 2025-12-03 GDB Administrator Automatic date update in version.in 2025-12-02 Tom de Vries [gdb] Fix typos in gdb/dwarf2 Fix the following typos: ... gdb/dwarf2/cooked-index-shard.c:296: re-use ==> reuse gdb/dwarf2/read-gdb-index.c:629: re-use ==> reuse gdb/dwarf2/read.c:2399: re-using ==> reusing gdb/dwarf2/read.c:11692: endianity ==> endianness gdb/dwarf2/read.c:11694: endianity ==> endianness gdb/dwarf2/read.c:11696: endianity ==> endianness gdb/dwarf2/read.c:11709: endianity ==> endianness ... Add aranges to the ignore list. Also replace readin by "read_in". Approved-By: Simon Marchi 2025-12-02 Tom de Vries [gdb] Clean whitespace in *.ac and *.m4 files This is the result of: ... $ git rm -f $(find gdb* -name "*.ac") $ git rm -f $(find gdb* -name "*.m4") $ git commit -a -m tmp $ git revert HEAD $ git rebase --whitespace=fix HEAD^ $ git reset --soft HEAD^ $ git commit --amend ... and running autoreconf -f in directories gdb, gdb/testsuite, gdbsupport and gdbserver. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-12-02 Tom de Vries [gdb] Handle *.ac and *.m4 files in .gitattributes Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig files"), .editorconfig has settings for .ac and .m4 files: ... [*.{ac,m4}] indent_style = tab indent_size = 2 trim_trailing_whitespace = true ... There are no setting for those files in .gitattributes, so the whitespace attribute defaults to trailing-space (shorthand for blank-at-eol, blank-at-eof) and space-before-tab. Since according to .editorconfig the indentation style is tab, add indent-with-non-tab as well. Since aclocal.m4 is generated, unset the whitespace attribute. Likewise for configure. Probably, this eventually needs to be added to root level .gitattributes, but for now try this in gdb*/.gitattributes. Approved-By: Simon Marchi 2025-12-02 Simon Marchi gdb/ser-unix: work around conflicting types for tcflag_t When trying to cross-compile GDB to sparc-buildroot-linux-uclibc, I get: CXX ser-unix.o In file included from /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/termios.h:39, from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:51: /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/bits/termios.h:26:22: error: conflicting declaration ‘typedef unsigned int tcflag_t’ 26 | typedef unsigned int tcflag_t; | ^~~~~~~~ In file included from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:46: /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:13:25: note: previous declaration as ‘typedef long unsigned int tcflag_t’ 13 | typedef unsigned long tcflag_t; | ^~~~~~~~ uClibc and the kernel don't agree on the definition of tcflag_t for this architecture. Here' uClibc [1]: typedef unsigned int tcflag_t; And here's the kernel [2]: #if defined(__sparc__) && defined(__arch64__) typedef unsigned int tcflag_t; #else typedef unsigned long tcflag_t; <--- that branch is take #endif glibc [3] has the same definition as uClibc, so we would get the same problem. I propose to work around this the same way as we handle differences in the termios structure, by renaming the version from the kernel. I opened a bug on the glibc bugzilla [4] to ask if this is something that would need to be fixed on the libc side, but in the mean time we need to work around it. [1] https://github.com/kraj/uClibc/blob/ca1c74d67dd115d059a875150e10b8560a9c35a8/libc/sysdeps/linux/sparc/bits/termios.h#L26 [2] https://github.com/torvalds/linux/blob/e7c375b181600caf135cfd03eadbc45eb530f2cb/arch/sparc/include/uapi/asm/termbits.h#L7-L11 [3] https://gitlab.com/gnutools/glibc/-/blob/efc8642051e6c4fe5165e8986c1338ba2c180de6/bits/termios.h#L104 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=33643 Change-Id: I71c6e0df5ac8e2ff3db3233a2220faaf70c3df6d Approved-By: Tom Tromey 2025-12-02 Yu-Cheng Liang gdb/testsuite: Fix gdb/testsuite/gdb.arch/riscv-unwind-long-insn.S The .size calculation for bar's function incorrectly uses the label func instead of bar. Fix it. 2025-12-02 Tom Tromey Rewrite the @selector code This rewrites the Objective-C @selector implementation in c-exp.y, following a couple general comments in the patch supplied for bug 20503. I suspect something else changed in the Objective-C runtime, though, as most of the examples in that bug still do not work, even though this series (I believe) addresses all the same points. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20503 2025-12-02 Tom Tromey Avoid crash with "NSString" literals Evaluating an Objective-C "NSString" literal will cause gdb to crash. This patch fixes the crash. I think the result here still isn't correct -- I see a warning from the runtime ("autorelease called without pool for object") with the new code. However, not crashing is an improvement on its own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20501 2025-12-02 Tom Tromey Remove a couple Objective-C expression helpers The Objective-C expression code has a couple of helper functions with just a single caller. This patch unifies them with the appropriate evaluate method. Rename lookup_struct_typedef The helper function lookup_struct_typedef is only ever called with "noerr=1". This patch removes the parameter, changes the name, and removes some unnecessary code. Minor fixes to make gdb.objc tests pass Once the gdb.objc tests compile, you can see that they do not pass. The issue is primarily that they are over-strict about line numbers. This fixes the problem by replacing these line numbers with $decimal. 2025-12-02 Tom Tromey Make the gdb.objc tests compile The gdb.objc tests haven't compiled in years. This patch fixes this, based on a comment in bug 31671. I don't know whether this approach works with the clang implementation of Objective-C. However, it does work with GCC, provided that gnustep-base is installed. 2025-12-02 Tom Tromey Reformat gdb.objc tests This patch applies some minor formatting changes and cleanups to the gdb.objc tests. 2025-12-02 Tom Tromey Require GNAT 8 for gdb.ada/recursive-access.exp Tom pointed out that gdb.ada/recursive-access.exp causes a compiler crash with gcc 7.5. This patch adjusts the test case to skip testing in this case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33664 Approved-By: Tom de Vries 2025-12-02 Nick Clifton Synchronize the dwarf2.h and dwarf2.def files with their gcc counterparts, bringing the definitions of DW_AT_language_name and DW_AT_language_version. Add code to binutils/dwarf.c to display these attributes. 2025-12-02 H.J. Lu x86: traverse loc_hash_table only if used Traverse x86 loc_hash_table only if it is used. * elf32-i386.c (elf_i386_output_arch_local_syms): Traverse loc_hash_table only if has_loc_hash_table is set. * elf64-x86-64.c (elf_x86_64_output_arch_local_syms): Likewise. * elfxx-x86.c (_bfd_elf_x86_get_local_sym_hash): Set has_loc_hash_table. (_bfd_x86_elf_late_size_sections): Traverse loc_hash_table only if has_loc_hash_table is set. * elfxx-x86.h (elf_x86_link_hash_table): Move plt0_pad_byte and add has_loc_hash_table. 2025-12-02 Alan Modra mips regression fixes Commit 54fbc12d64 introduced mips-linux testsuite regressions. +FAIL: MIPS magic __ehdr_start symbol test 1 (o32) +FAIL: PR ld/21334 MIPS GOT16 relocation in static binary +FAIL: PR ld/21375 in SVR4 executable (hidden) These are all assertion failures in mips_elf_sort_hash_table BFD_ASSERT (hsd.max_local_dynindx <= htab->root.local_dynsymcount + 1); This was a pre-existing problem exposed by commit 54fbc12d64. * elfxx-mips.c (mips_elf_sort_hash_table): Properly test for no dynsyms. 2025-12-02 GDB Administrator Automatic date update in version.in 2025-12-01 Simon Marchi gdb, gdbserver: propagate use of target_desc unique pointers Propagate the use of target_desc unique pointers further. Basically, avoid releasing target_desc objects, except in some spots in gdbserver (e.g. netbsd) where we don't currently have a persistent container for created target descriptions (and the target desc just leaks). Introduce const_target_desc_up to change some `const target_desc *` to a unique pointer without loss of constness. Architectures that use the old regformats/regdat.sh don't need to be changed, because their target_desc objects are statically allocated in the generated files. I was able to built-test these native configs: - Linux AArch64 - Linux ARC - Linux AMD64 - Linux ARM - Linux LoongArch - Linux M68K - Linux Microblaze - Linux MIPS (32 and 64) - Linux or1k - Linux PPC (32 and 64) - Linux RISC-V - Linux s390x - Linux SH4 - Linux Sparc (32 and 64) - Linux Xtensa - FreeBSD AMD64 - NetBSD AMD64 - Windows i686 - Windows AMD64 For the rest, I did my best by staring at the code long enough. I probably missed or messed some spots, but that shouldn't be difficult to fix. Change-Id: I8db8790c57942edd2bfe890987157e2dc0c67879 Reviewed-by: Thiago Jung Bauermann 2025-12-01 Simon Marchi gdbserver: remove leftovers from tic6x target_desc selftests Commit 9a5d3e6c4a50 ("gdb: remove tic6x .dat files") removed the .dat files that were used solely for selftests in linux-tic6x-low.cc. However, I forgot to remove the things that depended on that in linux-tic6x-low.cc (or rather, I put them in the wrong patch). As-is, linux-tic6x-low.cc will certainly no build, because function selftests::tdesc::tic6x_tdesc_test is not defined anywere. Remove those remaining bits. Change-Id: I3f307a6ae4848ef748e2a685a870b662c88180b5 2025-12-01 Tom Tromey Merge eval_op_objc_msgcall into objc_msgcall_operation::evaluate objc_msgcall_operation::evaluate is the only caller of eval_op_objc_msgcall. This patch merges them into a single function. This is just a leftover from the big expression change from several years ago. There are probably still many such cases remaining. 2025-12-01 Tom Tromey Rename some locals in objc_msgcall_operation::evaluate This renames a couple of local variables in objc_msgcall_operation::evaluate, in preparation for the next patch. This is done separately because the next patch is pretty messy and this makes it a little simpler. Use a vector in objc_msgcall_operation::evaluate This changes objc_msgcall_operation::evaluate to use a std::vector rather than XALLOCAVEC. alloca is bad and should generally be avoided; and anyway there's no justification for it here. 2025-12-01 Tom Tromey Fix crash from eval_op_objc_msgcall Trying to evaluate an Objective-C message call will cause gdb to crash. This happens because this code was not correctly updated when call_function_by_hand was changed to accept an array_view, and the trailing NULL pointer was no longer required. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33628 2025-12-01 Ronan Desplanques Add support for new Ada task state GNAT recently added support for asynchronous aborts of tasks blocked in calls to Ada.Synchronous_Task_Control.Suspend_Until_True. That GNAT change added a new value to the Task_States enumerated type. This patch adds the corresponding value to task_states. 2025-12-01 Simon Marchi gdb/dwarf: clarify meaning dwarf2_per_cu::{m_section,m_sect_off,m_length} in presence of DWO file The comments above these fields are almost accurate. If a unit in a DWO file has a corresponding skeleton in the main file, these fields describe the skeleton in the main file. However, it's missing the detail that if the unit in the DWO file does not have a corresponding skeleton in the main file, then the fields describe the unit in the DWO file. Update the comments to reflect that. Change-Id: I0681bc0d884f7e373b227416cbdef307d462ae71 Approved-By: Tom Tromey 2025-12-01 Simon Marchi gdb/dwarf: use dwarf2_per_cu::ref_addr_size in one spot I noticed this spot that could use dwarf2_per_cu::ref_addr_size, instead of implementing the same logic. Change-Id: I894ef1dcaa687c659e49bc1eb433e42818038cf2 Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/dwarf: store addr/offset/ref_addr sizes in dwarf2_per_cu New in v2: - make the test try with indexes by default - using uint8_t instead of unsigned char In some specific circumstances, it is possible for GDB to read a type unit from a .dwo file without ever reading in the section of the stub in the main file. In that case, calling any of these methods: - dwarf2_per_cu::addr_size() - dwarf2_per_cu::offset_size() - dwarf2_per_cu::ref_addr_size() will cause a crash, because they will try to read the unit header from the not-read-in section buffer. See the previous patch for more details. The remaining calls to these methods are in the loc.c and expr.c files. That is, in the location and expression machinery. It is possible to set things up to cause them to trigger a crash, as shown by the new test, when running it with the cc-with-gdb-index board: $ make check TESTS="gdb.dwarf2/fission-type-unit-locexpr.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index" Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-type-unit-locexpr.exp ... ERROR: GDB process no longer exists The backtrace at the moment of the crash is: #0 0x0000555566968b1f in bfd_getl32 (p=0x78) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846 #1 0x00005555642e51b7 in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x78 , bytes_read=0x7bfff09daca0, handle_nonstd=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92 #2 0x00005555647ca584 in read_unit_head (header=0x7d0ff1e06c70, info_ptr=0x78 , section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE) at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44 #3 0x000055556452df18 in dwarf2_per_cu::get_header (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531 #4 0x000055556452e10e in dwarf2_per_cu::addr_size (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544 #5 0x0000555564314ac3 in dwarf2_locexpr_baton_eval (dlbaton=0x7bfff0c9a508, frame=..., addr_stack=0x7bfff0b59150, valp=0x7bfff0c9a430, push_values=..., is_reference=0x7bfff0d33030) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1593 #6 0x0000555564315bd2 in dwarf2_evaluate_property (prop=0x7bfff0c9a450, initial_frame=..., addr_stack=0x7bfff0b59150, value=0x7bfff0c9a430, push_values=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1668 #7 0x0000555564a14ee1 in resolve_dynamic_field (field=..., addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2758 #8 0x0000555564a15e24 in resolve_dynamic_struct (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2839 #9 0x0000555564a17061 in resolve_dynamic_type_internal (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=..., top_level=true) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2972 #10 0x0000555564a17899 in resolve_dynamic_type (type=0x7e0ff1f02550, valaddr=..., addr=0x4010, in_frame=0x7bfff0d32e60) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:3019 #11 0x000055556675fb34 in value_from_contents_and_address (type=0x7e0ff1f02550, valaddr=0x0, address=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/value.c:3674 #12 0x00005555666ce911 in get_value_at (type=0x7e0ff1f02550, addr=0x4010, frame=..., lazy=1) at /home/simark/src/binutils-gdb/gdb/valops.c:992 #13 0x00005555666ceb89 in value_at_lazy (type=0x7e0ff1f02550, addr=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/valops.c:1039 #14 0x000055556491909f in language_defn::read_var_value (this=0x5555725fce40 , var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame_param=...) at /home/simark/src/binutils-gdb/gdb/findvar.c:504 #15 0x000055556491961b in read_var_value (var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame=...) at /home/simark/src/binutils-gdb/gdb/findvar.c:518 #16 0x00005555666d1861 in value_of_variable (var=0x7e0ff1f02500, b=0x7e0ff1f025d0) at /home/simark/src/binutils-gdb/gdb/valops.c:1384 #17 0x00005555647f7099 in evaluate_var_value (noside=EVAL_NORMAL, blk=0x7e0ff1f025d0, var=0x7e0ff1f02500) at /home/simark/src/binutils-gdb/gdb/eval.c:533 #18 0x00005555647f740c in expr::var_value_operation::evaluate (this=0x7c2ff1e3b690, expect_type=0x0, exp=0x7c2ff1e3aa00, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:559 #19 0x00005555647f3347 in expression::evaluate (this=0x7c2ff1e3aa00, expect_type=0x0, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:109 #20 0x000055556543ac2f in process_print_command_args (args=0x7fffffffe728 "global_var", print_opts=0x7bfff0be4a30, voidprint=true) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1328 #21 0x000055556543ae65 in print_command_1 (args=0x7fffffffe728 "global_var", voidprint=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1341 #22 0x000055556543b707 in print_command (exp=0x7fffffffe728 "global_var", from_tty=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1408 The problem to solve is: in order to evaluate a location expression, we need to know some information (the various sizes) found in the unit header. In that context, it's not possible to get it from dwarf2_cu::header, like the previous patch did: at the time the expression is evaluated, the corresponding dwarf2_cu might have been freed. We don't want to re-build a dwarf2_cu just for that, it would be very inefficient. We could force reading in the dwarf2_per_cu::section section (in the main file), but we never needed to read that section before, so it would be better to avoid reading it unnecessarily. My initial attempt was to store this information in baton objects (dwarf2_locexpr_baton & co), so that it can be retrieved when the time comes to evaluate the expressions. However, it quickly became obvious that storing it there would be redundant and wasteful. I instead opted to store this information directly inside dwarf2_per_cu, making it easily available when evaluating expressions. These fields initially have the value 0, and are set by cutu_reader whenever the unit is parsed. The various getters (dwarf2_per_cu::addr_size & al) now just return these fields. Doing so allows removing anything related to reading the header from dwarf2_per_cu, which I think is a nice simplification. This means that nothing ever needs to read the header from just a dwarf2_per_cu. It also happens to shrink the dwarf2_per_cu object size a bit, going from: (top-gdb) p sizeof(dwarf2_per_cu) $1 = 176 to (top-gdb) p sizeof(dwarf2_per_cu) $1 = 120 I placed the new fields at this strange location in dwarf2_per_cu because there happened to be a nice 3 bytes hole there (on Linux amd64 at least). The new test set things up as described previously. Note that the crash only occurs if using the cc-with-gdb-index board. Change-Id: I50807a1bbb605f0f92606a9e61c026e3376a4fcf Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/dwarf: when in dwarf2_cu, read addr_size from dwarf2_cu::header New in v2: make the test try with indexes by default This patch fixes a crash caused by GDB trying to read from a section not read in. The bug happens in those specific circumstances: - reading a type unit from .dwo - that type unit has a stub in the main file - there is a GDB index (.gdb_index) present This crash is the cause of the following test failure, with the cc-with-gdb-index target board: $ make check TESTS="gdb.dwarf2/fission-reread.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index" Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-reread.exp ... ERROR: GDB process no longer exists Or, manually: $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread -ex "p 1" Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread... Fatal signal: Segmentation fault For this last one, you need to interrupt the test (e.g. add a return) before the test deletes the .dwo file. The backtrace at the moment of the crash is: #0 0x0000555566968f7f in bfd_getl32 (p=0x0) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846 #1 0x00005555642e561d in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x0, bytes_read=0x7bfff0962fa0, handle_nonstd=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92 #2 0x00005555647ca9ea in read_unit_head (header=0x7d0ff1e068b0, info_ptr=0x0, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE) at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44 #3 0x000055556452e37e in dwarf2_per_cu::get_header (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531 #4 0x000055556452e574 in dwarf2_per_cu::addr_size (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544 #5 0x000055556406af91 in dwarf2_cu::addr_type (this=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/cu.c:124 #6 0x0000555564534e48 in set_die_type (die=0x7e0ff1f23dd0, type=0x7e0ff1f027f0, cu=0x7d7ff1e20880, skip_data_location=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19020 #7 0x00005555644dcc7b in read_structure_type (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11239 #8 0x000055556451c834 in read_type_die_1 (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16878 #9 0x000055556451c5e0 in read_type_die (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16861 #10 0x0000555564526f3a in get_signatured_type (die=0x7e0ff1f0ffb0, signature=10386129560629316377, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:17998 #11 0x000055556451c23b in lookup_die_type (die=0x7e0ff1f0ffb0, attr=0x7e0ff1f10008, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16808 #12 0x000055556451b2e9 in die_type (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16684 #13 0x000055556451457f in new_symbol (die=0x7e0ff1f0ffb0, type=0x0, cu=0x7d7ff1e0f480, space=0x0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16089 #14 0x00005555644c52a4 in read_variable (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9119 #15 0x0000555564494072 in process_die (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5197 #16 0x000055556449c88e in read_file_scope (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6125 #17 0x0000555564493671 in process_die (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5098 #18 0x00005555644912f5 in process_full_comp_unit (cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4851 #19 0x0000555564485e18 in process_queue (per_objfile=0x7d6ff1e71100) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4161 #20 0x000055556446391d in dw2_do_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1650 #21 0x0000555564463b3c in dw2_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1671 #22 0x00005555644687fd in dwarf2_base_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1990 #23 0x0000555564381050 in cooked_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index.h:237 #24 0x0000555565df5b0d in objfile::expand_all_symtabs (this=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/symfile-debug.c:372 #25 0x0000555565eafc4a in maintenance_expand_symtabs (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/symmisc.c:914 The main file contains a stub (skeleton) for a compilation unit and a stub for a type unit. The .dwo file contains a compilation unit and a type unit matching those stubs. When doing the initial scan of the main file, the DWARF reader parses the CU/TU list from the GDB index (.gdb_index), and thus creates a signatured_type object based on that. The section field of this signatured_type points to the .debug_types section in the main file, the one containing the stub. And because GDB trusts the GDB index, it never needs to look at that .debug_types section in the main file. That section remains not read in. When expanding the compilation unit, GDB encounters a type unit reference (by signature) corresponding to the type in the type unit. We get in lookup_dwo_signatured_type, trying to see if there is a type unit matching that signature in the current .dwo file. We proceed to read and expand that type unit, until we eventually get to a dwarf2_cu::addr_type() call, which does: int addr_size = this->per_cu->addr_size (); dwarf2_per_cu::addr_size() tries to read the header from the section pointed to by dwarf2_per_cu::section which, if you recall, is the .debug_types section in the main file that was never read in. That causes the segfault. All this was working fine before these patches of mine, that tried to do some cleanups: a47e2297fc28 ("gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor") c44ab627b021 ("gdb/dwarf: pass section to dwarf2_per_cu_data constructor") 39ee8c928551 ("gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor") Before these patches, the fill_in_sig_entry_from_dwo_entry function (called from lookup_dwo_signatured_type, among others) would overwrite some dwarf2_per_cu fields (including the section) to point to the .dwo, rather than represent what's in the main file. Therefore, the header would have been read from the unit in the .dwo file, and things would have been fine. When doing these changes, I mistakenly assumed that the section written by fill_in_sig_entry_from_dwo_entry was the same as the section already there, which is why I removed the statements overwriting the section field (and the two others). To my defense, here's the comment on dwarf2_per_cu::section: /* The section this CU/TU lives in. If the DIE refers to a DWO file, this is always the original die, not the DWO file. */ struct dwarf2_section_info *section = nullptr; I would prefer to not reintroduce the behavior of overwriting the section info in dwarf2_per_cu, because: 1. I find it confusing, I like the invariant of dwarf2_per_cu::section points to the stub, and dwarf2_cu::section points to where we actually read the debug info from. 2. The dwarf2_per_bfd::all_units vector is nowadays sorted by (section, section offset). If we change the section and section offset of a dwarf2_per_cu, then we can no longer do binary searches in it, we would have to re-sort the vector (not a big deal, but still adds to the confusion). One possible fix would be to make sure that the section is read in when reading the header, probably in dwarf2_per_cu::get_header. An approach like that was proposed by Andrew initially, here: https://inbox.sourceware.org/gdb-patches/60ba2b019930fd6164f8e6ab6cb2e396c32c6ac2.1759486109.git.aburgess@redhat.com/ It would work, but there is a more straightforward fix for this particular problem, I believe. In dwarf2_cu, we have access to the header read from the unit we're actually reading the DWARF from. In the DWO case, that is the header read from the .dwo file. We can get the address size from there instead of going through the dwarf2_per_cu object. This is what this patch does. However, there are other case where we get the address (or offset) size from the dwarf2_per_cu in the DWARF expression evaluator (expr.c, loc.c), that could cause a similar crash. The next patch handles these cases. Modify the gdb.dwarf2/fission-reread.exp test so that it tries running with an index even with the standard board (that part was originally written by Andrew). Finally, just to put things in context, having a stub in the main file for a type unit is obsolete. It happened in the gcc 4.x days, until this commit: commit 4dd7c3b285daf030da0ff9c0d5e2f79b24943d1e Author: Cary Coutant Date: Fri Aug 8 20:33:26 2014 +0000 Remove skeleton type units that were being produced with -gsplit-dwarf. In DWARF 5, split type units don't have stubs, only split compilations units do. Change-Id: Icc5014276c75bf3126ccb43a4424e96ca1a51f06 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33307 Co-Authored-By: Andrew Burgess Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/testsuite/dwarf: emit type unit sections as COMDAT In an effort to generate ELF files and DWARF info as close as possible as an actual compiler would generate, change how we emit type unit sections to emit each type unit in its own section, in COMDAT section groups. We currently emit all type units in a single, standard section (either .debug_info or .debug_types, depending on the DWARF version). Compilers emit each type unit in its own .debug_types section. Each section is placed in a COMDAT section group with a signature based on the type unit's signature. This lets the linker deduplicate identical type units by discarding section groups with identical signatures (keeping only one group with a given signature). Looking at a .s file generated by gcc, we can see that this is how it specifies the section for a type unit: .section .debug_info,"G",@progbits,wi.006fd2152a3054a6,comdat The "G" flag tells the assembler to place the section in a section group with signature "wi.006fd2152a3054a6". That string was generated from the type unit, signature. Finally, the comdat linkage field indicates that the section group should have the COMDAT flag. Update the tu proc to emit a section with these properties. In this case, it's mandatory to specify the type of the section (progbits). Update the _section proc to accept the new options "group_signature" and "linkage". As a result, if you look at the .debug_types section in a .o file from gcc: $ readelf -g main.o COMDAT group section [ 1] `.group' [wt.006fd2152a3054a6] contains 2 sections: [Index] Name [ 11] .debug_types [ 12] .rela.debug_types COMDAT group section [ 2] `.group' [wt.c621aa8e3c23e450] contains 2 sections: [Index] Name [ 13] .debug_types [ 14] .rela.debug_types And a .o file created by our DWARF assembler: $ readelf -g testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig1.o COMDAT group section [ 1] `.group' [sig.0x0000000000000001] contains 2 sections: [Index] Name [ 10] .debug_types [ 11] .rela.debug_types COMDAT group section [ 2] `.group' [sig.0x0000000000000002] contains 2 sections: [Index] Name [ 12] .debug_types [ 13] .rela.debug_types In both cases, in the fully linked files, there is a single .debug_types section containing the two type units, as expected. Before this patch, when I run gdb.dwarf2/fission-with-type-unit.exp, the resulting .dwo file has a single .debug_info.dwo. After this patch it has two: one with the type unit and one with the compile unit (the test uses DWARF 5). Based on what I see gcc generate when using "-gdwarf-5 -gsplit-dwarf -fdebug-types-section", this is what we expect. Change-Id: Ie1954dc697fe100b5dbe664d148c71fa02888d96 Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/testsuite/dwarf: convert _section proc to use parse_options New in v2: return early if the section is .debug_str The following patch will add more options to the _section proc, so convert it to use options, to be more user-friendly. Change-Id: I971e4e10e55d63af2a5e29dc5e1d00f368b3ecaa Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/testsuite/dwarf: use single abbrev table in .dwo files When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use build_executable_and_dwo_files, because it wouldn't work to have multiple units in the .dwo file, each referring to their own abbrev table using labels. build_executable_and_dwo_files extracts the .dwo file content from the .o using objcopy (just like gcc does, I learned), meaning that the .dwo file never runs through a linker. Anything needing relocation (like labels pointing to abbrev tables) doesn't work. I instead opted to use gdb_compile_shlib to build the .dwo file on its own, so that those labels would get resolved. That causes problems now that I'm trying to write a test with multiple type units in a .dwo file, where each type unit should be in its own .debug_types section. Running the .dwo file through the linker causes all the .debug_types section to be collapsed into one. And generally, I think it was a bad idea to generate a .dwo file using the linker, since the idea behind .dwo files is that they do not need to be linked (therefore improving link times). We want to produce files as close to what an actual compiler would produce. This patch fixes this by doing what compilers do in the same situation: use a single abbrev table shared by all units in the .dwo file. This requires the following changes in lib/dwarf.exp: - Declare a new variable _dwo_abbrev_num, which holds the next abbrev number to use in the .dwo file's abbrev section (.debug_abbrev.dwo). Initialize this variable to 1. - When producing a CU or TU in a .dwo file, use 0 as the abbrev table offset. - When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num, depending on whether the current CU is in a .dwo file. - After producing a CU or TU in a .dwo file, don't append the terminator byte. - After finishing producing the CUs and TUs, append the terminator byte in .debug_abbrev.dwo if we did output anything there. Update gdb.dwarf2/fission-with-type-unit.exp to use build_executable_and_dwo_files, as it should. Remove the gdb_remote_download call from gdb.dwarf/fission-with-type-unit.exp, because build_executable_and_dwo_files does not support remote hosts anyway. With this change, running with the cc-with-gdb-index board, I see: (gdb) maint expand-symtabs /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error) This is actually an improvement, as the test case didn't run properly before. The compilation failed with: gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit] The reason was that the old code would try to generate the GDB index during this step: # Build main file. if { [build_executable "${testfile}.exp" $binfile \ [list ${srcfile} ${main_asm_file}] {nodebug}] } { return } ... which is before the DWO file is even generated. With this patch things are done in the correct order: - The -dw.S file is generated - The -dw.o file is compiled from the -dw.S - The .dwo sections are extracted to the .dwo file, and stripped from the -dw.o file - The executable is linked from the .o and -dw.o - gdb-add-index is ran on the executable When gdb-add-index runs, the .dwo file exists, so GDB is able to produce an index. That index is bogus though, because the .gdb_index format is unable to describe skeletonless type units. And then GDB gets confused trying to use that index, leading to the internal error. Change-Id: Iabbcf00db97faf2a4fa5fc71652ad273081189f9 Approved-By: Andrew Burgess 2025-12-01 Simon Marchi gdb/testsuite/dwarf: ensure build_executable_and_dwo_files calls untested in all failure paths There are some paths of build_executable_and_dwo_files that return -1 without calling "untested". As a result, tests such as gdb.dwarf2/fission-absolute-dwo.exp would exit without leaving a trace. Add some untested calls to fix that. Change-Id: I2e632b5b44b11b4beb39791316f1203f9a12bf4f Approved-By: Tom Tromey 2025-12-01 Simon Marchi gdb/dwarf: remove nullptr check in dwarf2_locexpr_baton_eval The sole caller of this function passes the address of a field, we know it's not nullptr. Change-Id: Ie8c609136e225667b724ebc27a395f6e615f1dea Approved-By: Tom Tromey 2025-12-01 Simon Marchi gdb/dwarf: remove nullptr prop check in dwarf2_evaluate_property This nullptr is pointless most of the time: almost all callers either check that the prop is not nullptr or they pass the address of a local variable, which is necessarily not nullptr. I propose to remove it. I found only one call site where I needed to add a check. Change-Id: Iada84d529b8edc6b20486f3539c675dad6b364f5 Approved-By: Tom Tromey 2025-12-01 Andrew Burgess gdb/testsuite: make more use of clean_restart's argument Commits: commit aaad5a3254db53434eaf1cf70384e7ee0dfb886a Author: Tom de Vries Date: Fri Sep 5 15:36:23 2025 +0200 [gdb/testsuite] Fix clean_restart in gdb.base, part 3 commit 2e61486fcefe8812714dcb0fb787581592675502 Author: Tom de Vries Date: Fri Sep 5 15:36:23 2025 +0200 [gdb/testsuite] Fix clean_restart in gdb.base, part 2 commit 202beb3feebd44fbc1979d9fdb4d74c44e16a417 Author: Tom de Vries Date: Fri Sep 5 15:36:23 2025 +0200 [gdb/testsuite] Fix clean_restart in gdb.base, part 1 were made to work around the changes to clean_restart in commit: commit cba778b944af90c362a618af0630877736a54baa Date: Sun Sep 7 11:53:30 2025 +0200 [gdb/testsuite] Error out on clean_restart These commits added a lot of calls to gdb_load which can be removed in many cases by passing $testfile to clean_restart, or by switching to use prepare_for_testing to compile the test executable. In this commit I've gone through the gdb.base/ directory and removed as many of the gdb_load calls as possible. I was only looking for places where the gdb_load call immediately follows the call to clean_restart. And I did skip a few where it was not as simple as just passing $testfile. Where possible I've updated tests to use calls to prepare_for_testing, and simply removed the clean_restart call altogether (this is done as part of prepare_for_testing). This is, I think, the best solution. In other cases I've removed the gdb_load call, and passed $testfile to clean_restart. I've preferred $::testfile to adding a 'global' declaration, and in some cases switching to testfile has allowed me to remove the 'global binfile' as an additional cleanup. I ran the complete set of tests that I touched and I didn't see any regressions, so I don't believe I broke anything. I know that there are probably gdb_load calls that can be cleaned up in other testsuite sub-directories, if/when this patch is merged I'll take a look at those too. Reviewed-By: Tom de Vries 2025-12-01 Andrew Burgess gdb/aarch64: change target_ops::stopped_data_address API At Red Hat we have an out of tree AArch64 watchpoint test which broke after this commit: commit cf16ab724a41e4cbaf723b5633d4e7b29f61372b Date: Tue Mar 12 17:08:18 2024 +0100 [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64 The problem with AArch64 hardware watchpoints is that they (as I understand it) are restricted to a minimum of 8 bytes. The problem is that current AArch64 hardware has imprecise hardware watchpoint events due to unaligned accesses. The address reported for the watchpoint event will depend on the access size. As a result, it is possible that multiple watchpoints could potentially account for a single watchpoint event, which is the case in the RH test. GDB can then miss-identify which watchpoint actually triggered. Prior to the above commit the RH test was passing. However, the test was relying on, in the case of ambiguity, GDB selecting the first created watchpoint. That behaviour changed with the above commit. Now GDB favours reporting non write breakpoints, and will only report a write breakpoint if no non-write breakpoint exists in the same region. I originally posted a patch to try and tweak the existing logic to restore enough of the original behaviour that the RH test would pass, this can be found here (2 iterations): https://inbox.sourceware.org/gdb-patches/65e746b6394f04faa027e778f733eda95d20f368.1753115072.git.aburgess@redhat.com https://inbox.sourceware.org/gdb-patches/638cbe9b738c0c529f6370f90ba4a395711f63ae.1753971315.git.aburgess@redhat.com Neither of these really resolved the problem, they fixed some cases, but broke others. Ultimately, the problem on AArch64 is that for a single watchpoint trap, there could be multiple watchpoints that are potentially responsible. The existing API defined by the target_ops methods stopped_by_watchpoint() and stopped_data_address() only allow for two possible options: 1. If stopped_by_watchpoint() is true then stopped_data_address() can return true and a single address which identifies all watchpoints at that single address, or 2. If stopped_by_watchpoint() is true then stopped_data_address() can return false, in which case GDB will check all write watchpoints to see if any have changed, if they have, then GDB tells the user that that was the triggering watchpoint. If we are in a situation where we have to choose between multiple write and read watchpoints then the current API doesn't allow the architecture specific code to tell GDB core about this case. In this commit I propose that we change the target_ops API, specifically, the method: bool target_ops::stopped_data_address (CORE_ADDR *); will change to: std::vector target_ops::stopped_data_addresses (); The architecture specific code can now return a set of watchpoint addresses, allowing GDB to identify a set of watchpoints that might have triggered. GDB core can then select the most likely watchpoint, and present that to the user. As with the old API, target_ops::stopped_data_addresses should only be called when target_ops::stopped_by_watchpoint is true, in which case it's return values can be interpreted like this: a. An empty vector; this replaces the old case where false was returned. GDB should check all the write watchpoints and select the one that changed as the responsible watchpoint. b. A single entry vector; all targets except AArch64 currently return at most a single entry vector. The single address indicates the watchpoint(s) that triggered. c. A multi-entry vector; currently AArch64 only. These addresses indicate the set of watchpoints that might have triggered. GDB will check the write watchpoints to see which (if any) changed, and if no write watchpoints changed, GDB will present the first access watchpoint. In the future, we might want to improve the handling of (c) so that GDB tells the user that multiple access watchpoints might have triggered, and then list all of them. This might clear up some confusion. But I think that can be done in the future (I don't have an immediate plan to work on this). I think this change is already a good improvement. The changes for this are pretty extensive, but here's a basic summary: * Within gdb/ changing the API name from stopped_data_address to stopped_data_addresses throughout. Comments are updated too where needed. * For targets other than AArch64, the existing code is retained with as few changes as possible, we only allow for a single address to be returned, the address is now wrapped in a vector. Where we used to return false, we now return the empty vector. * For AArch64, the return a vector logic is pushed through to gdb/nat/aarch64-hw-point.{c,h}, and aarch64_stopped_data_address changes to aarch64_stopped_data_addresses, and is updated to return a vector of addresses. * In infrun.c there's some updates to some debug output. * In breakpoint.c the interesting changes are in watchpoints_triggered. The existing code has three cases to handle: (i) target_stopped_by_watchpoint returns false. This case is unchanged. (ii) target_stopped_data_address returns false. This case is now calling target_stopped_data_addresses, and checks for the empty vector, but otherwise is unchanged. (iii) target_stopped_data_address returns true, and a single address. This code calls target_stopped_data_addresses, and now handles the possibility of a vector containing multiple entries. We need to first loop over every watchpoint setting its triggered status to 'no', then we check every address in the vector setting matching watchpoint's triggered status to 'yes'. But the actual logic for if a watchpoint matches an address or not is unchanged. The important thing to notice here is that in case (iii), before this patch, GDB could already set _multiple_ watchpoints to triggered. For example, setting a read and write watchpoint on the same address would result in multiple watchpoints being marked as triggered. This patch just extends this so that multiple watchpoints, at multiple addresses, can now be marked as triggered. * In remote.c there is an interesting change. We need to allow gdbserver to pass the multiple addresses back to GDB. To achieve this, I now allow multiple 'watch', 'rwatch', and 'awatch' tokens in a 'T' stop reply packet. There's a new feature multi-wp-addr which is passed in the qSupported packet to determine if the remote is allowed to pass back multiple watchpoint stop reasons. If the remote passed multiple watchpoint addresses then these are collected and returned from the target_ops::stopped_data_addresses call. If a new GDB connects to an old gdbserver that doesn't understand the multi-wp-addr feature, then gdbserver will continue to return a single watchpoint address in the 'T' packet, which is what happens before this patch. * In gdbserver/ the changes are pretty similar. The API is renamed from ::stopped_data_address to ::stopped_data_addresses, and ::low_stopped_data_address to ::low_stopped_data_addresses. There's also code added to detect the new multi-wp-addr feature. If this feature is not advertised from GDB then only a single watchpoint address will be returned in the 'T' stop reply packet. * In GDB and gdbserver, for all targets except AArch64, the existing code to figure out a watchpoint address is retained, we just wrap the single address into a vector. * For AArch64, we call aarch64_stopped_data_addresses, which returns the required vector. For testing, I've built GDB on GNU/Linux for i386, x86-64, PPC64le, ARM, and AArch64. That still leaves a lot of targets possibly impacted by this change as untested. Which is a risk. I certainly wouldn't want to push this patch until after GDB 17 branches so we have time to find and fix any regressions that are introduced. I've run a full regression test on AArch64 and x86-64 (both GNU/Linux) with no regressions. As I said above, for other targets nothing should really have changed, all non-AArch64 targets just return a single watchpoint address from target_ops::stopped_data_addresses(), so, as long as the target builds, it should run unchanged. I also sent the branch through the sourceware CI, and everything passed. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33240 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33252 Acked-By: Tom de Vries 2025-12-01 Tom de Vries [gdb/corefiles] Sort info proc mappings table On x86_64-linux, with test-case gdb.python/py-corefile.exp I run into: ... FAIL: $exp: test mapped files data: diff input and output one ... The failing test compares the output of: - info proc mappings, and - info proc py-mappings, a python implementation of "info proc mappings". The difference in output is order: while the latter prints the entries sorted on start address, the former doesn't. Fix this by sorting the entries in linux_read_core_file_mappings. Tested on x86_64-linux. PR corefiles/33543 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33543 2025-12-01 GDB Administrator Automatic date update in version.in 2025-11-30 H.J. Lu lto: Compile PR ld/23818 test with -fPIC Compile PR ld/23818 test with -fPIC to fix testsuite/ld-plugin/pr23818b.c:6:(.text+0x34): relocation R_MIPS_26 against `a local symbol' cannot be used when making a shared object; recompile with -fPIC FAIL: Build libpr23818.so for mips. PR ld/23818 * testsuite/ld-plugin/lto.exp: Compile PR ld/23818 test with -fPIC. 2025-11-30 H.J. Lu elf: Properly place base symbols in DT_GNU_HASH and DT_HASH The base symbol, a symbol with the empty version string, created by asm (".symver foo_base, foo@"); is used to provide a compatibility symbol in a versioned shared library for binaries linked against the previous unversioned shared library. The dynamic linker will pick the first match to resolve the unversioned symbol reference. If the newest version, VERS_1, asm (".symver foo_v1, foo@@VERS_1"); is picked before the base symbol in DT_GNU_HASH and DT_HASH, foo@@VERS_1, instead of foo@, will be used to resolve the unversioned reference. Properly place base symbols in DT_GNU_HASH and DT_HASH so that they will be picked first. Also check defined function symbol, foo, and undefined function symbol, bar, separately to support different dynamic symbol orders. bfd/ PR ld/33577 PR ld/33673 * elf-bfd.h (elf_link_hash_entry): Add base_symbol. (elf_link_hash_table): Add has_base_symbols. * elflink.c (_bfd_elf_merge_symbol): Set base_symbol and has_base_symbols if the version string is empty. (collect_gnu_hash_codes): Add base_symbol. (elf_gnu_hash_process_symidx): Skip if base symbol doesn't match. (bfd_elf_size_dynsym_hash_dynstr): If there are base symbols, output base symbols first in DT_GNU_HASH. (elf_outext_info): Add base_symbol. (elf_link_output_extsym): Skip if base symbol doesn't match. (_bfd_elf_final_link): If there are base symbols, output base symbols last in DT_HASH. ld/ PR ld/33577 PR ld/33673 * testsuite/ld-elfvers/pr33577-unversioned.rd: Removed. * testsuite/ld-elfvers/pr33577-versioned.rd: Likewise. * testsuite/ld-elfvers/pr33577-unversioned-a.rd: New file. * testsuite/ld-elfvers/pr33577-unversioned-b.rd: Likewise. * testsuite/ld-elfvers/pr33577-versioned-a.rd: Likewise. * testsuite/ld-elfvers/pr33577-versioned-b.rd: Likewise. * ld-elfvers/vers.exp (base_symbol_test): New. Run PR ld/33673 tests. 2025-11-30 H.J. Lu elf: Renumber local dynamic symbols only if needed Only hppa, ia64 and sparc ELF targets use local dynamic symbols. But elf_link_renumber_local_hash_table_dynsyms is always called to renumber local dynamic symbols even if there is none. Add has_local_dynsyms to elf_link_hash_table and set it to true only if there are local dynamic symbols. Renumber local dynamic symbols only if there are local dynamic symbols. * elf-bfd.h (elf_link_hash_table): Add has_local_dynsyms. * elflink.c (_bfd_elf_link_renumber_dynsyms): Renumber local dynamic symbols only if there are local dynamic symbols. (_bfd_elf_adjust_dynamic_symbol): Set has_local_dynsyms if there are local dynamic symbols. 2025-11-30 Alan Modra ELF symbol version output cleanup * elflink.c (elf_link_output_extsym): Localise code setting VERSYM_HIDDEN to previous branch of "if" where def_regular might be true. Delete noversion. Set vs_vers to zero instead. 2025-11-30 Alan Modra PR 33637, abort in byte_get When DWARF5 support was added to binutils in commit 77145576fadc, the loop over CUs in process_debug_info set do_types when finding a DW_UT_type unit, in order to process the signature and type offset entries. Unfortunately that broke debug_information/debug_info_p handling, which previously was allocated and initialised for each unit in .debug_info. debug_info_p was NULL when processing a DWARF4 .debug_types section. After the 77145576fadc change it was possible for debug_infp_p to be non-NULL but point to zeroed data, in particular a zeroed offset_size. A zero for offset_size led to the byte_get_little_endian abort triggered by the fuzzer testcase. I haven't investigated whether there is any need for a valid offset_size when processing a non-fuzzed DWARF4 .debug_types section. Presumably we'd have found that out in the last 6 years if that was the case. We don't want to change debug_information[] for .debug_types! PR 33637 * dwarf.c (process_debug_info): Don't change DO_TYPES flag bit depending on cu_unit_type. Instead test cu_unit_type along with DO_TYPES to handle signature and type_offset for a type unit. Move find_cu_tu_set_v2 call a little later. 2025-11-30 Alan Modra Re: bfd/Dwarf: Add suitable defines to use at call and use sites Commit 1f7e70ddd2c4 made changes to process_debug_info parameters without adjusting the function comment to suit. Fix that, and tidy do_printing flag use. * dwarf.c (process_debug_info): Edit function comment. Make do_printing a bool. Fold DO_LOC test into do_printing. 2025-11-30 Roman Kapl bfd: fix potential missing seek If a file was closed by cache and then bfd_open_file was called followed by e.g. bfd_seek to the original position, the seek would be optimized out while the real file position was still zero (as fopened). I added `bfd_io_force` to force the seek at next IO occasion. This could lead e.g. to appearence of a corrupted object in ld: symbol number 0 uses unsupported binding of 6 or invalid string offset #X >= #Y for section 2025-11-30 GDB Administrator Automatic date update in version.in 2025-11-29 GDB Administrator Automatic date update in version.in 2025-11-28 Andreas Schwab gprofng: protect against standard library macros The CALL_UTIL macro can expand to an unparsable expression of the argument is a macro, like with the new const-preserving standard library macros in C23. * gprofng/src/collector_module.h (CALL_UTIL): Add parens to not expand its argument if it is a function-like macro. 2025-11-28 Simon Marchi gdb/testsuite: fix a few typos When merging the big "whitespace fix" commit in a downstream repo, pre-commit/codespell identified a lot of typos, fix a few of them. Change-Id: Ie898e9903daa4e6e0e49a623891a739071e91392 Approved-By: Tom de Vries 2025-11-28 Jan Vrany gdb: update is_addr_in_objfile to support "dynamic" objfiles While working with objfiles in Python I noticed that gdb.Progspace.objfile_for_address () does not return "dynamic" objfiles created by (for example) GDB's JIT reader API. This is because is_addr_in_objfile() checks if a given address falls into any (mappped) section of that objfile. However objfiles created by JIT reader API do not have sections. To solve this issue, this commit updates is_addr_in_objfile() to also check if the address fall into any compunit in that objfile. It does so only if the objfile has no sections. 2025-11-28 Jan Vrany gdb: add unittests for blockvector lookup functions This commit adds new unittest - blockvector-lookup - that tests blockvector::lookup () and blockvector::contains (). Approved-By: Simon Marchi 2025-11-28 Jan Vrany gdb: change blockvector::contains() to handle blockvectors with "holes" This commit slightly changes the logic in blockvector::contains() to handle a case where the blockvector contains blocks with disjoint regions (see the comment in blockvector::contains for details). This change may potentially change GDB's behavior. It is not clear to me if there was a reason for blockvector_contains_pc() behaving differently depending whether or not given blockvector contain a map. With this change, blockvector::contains() return the same value regardless. The reason for it is to make it work as expected also for "dynamic" code created by JIT reader (and perhaps by Python in the future). Note that for CUs created from DWARF, blockvectors have always a map set so this change in behavior should not affect them. Running testsuite on Linux x86_64 shown no regressions. Finally, I was considering of making this change up in lookup method but in the end decided to be bit more conservative because comment in original find_block_in_blockvector() suggested that returning a static block from there is an expected situation. Approved-By: Simon Marchi 2025-11-28 Jan Vrany gdb: update blockvector::lookup This commit changes blockvector::lookup() to improve style and readability. It also adds quick range check to see if given address falls into global block. Approved-By: Simon Marchi 2025-11-28 Tom de Vries [gdb/build, c++20] Fix UTF-8 string literal usage PR build/33675 reports a build breaker: ... top.c: In function ‘void box_one_message(ui_file*, std::string, int)’: top.c:1368:35: error: conditional expression between distinct pointer types \ ‘const char8_t*’ and ‘const char*’ lacks a cast 1368 | const char *wall = emojis_ok () ? u8"\u2503" : "|"; | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ ... The problem is that UTF-8 string literals have type: - const char[N] (until C++20), or - const char8_t[N] (since C++20) Fix this by assigning to variables: ... static const char bd_heavy_vertical[] = u8"\u2503"; ... and using the variables instead. Tested by rebuilding on x86_64-linux, and starting gdb and checking the welcome message box. Reviewed-By: Guinevere Larsen Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33675 2025-11-28 Tom de Vries [gdb/testsuite] Fix three typos in gdb.base/long_long.exp Fix three types in test-case gdb.base/long_long.exp: ... $ codespell gdb.base/long_long.exp gdb.base/long_long.exp:19: differnet ==> different gdb.base/long_long.exp:208: Implict ==> Implicit gdb.base/long_long.exp:224: Implict ==> Implicit ... 2025-11-28 Jan Beulich x86: drop a few excess AVX512VL from opcode table In commit 24187fb9c0d0 ("x86/APX: extend SSE2AVX coverage") I apparently went a little to far with AVX512VL uses: - PEXTRQ and PINSRQ are AVX512DQ alone, despite using 128-bit (XMM) registers, - SSE41DQ is used for only PEXTRD and PINSRD, falling in the same category. With the SSE41DQ observation above, also simplify Disp8MemShift handling there: No need to override it in the insn template, as long as the manufacturing template specifies it correctly. Note that the AVX512DW form of PINSRQ also had a stray "AVX" CPU specifier on it. Make this disappear by templatizing via a new SSE41DQ64 manufacturing template (covering PEXTRQ and PINSRQ, paralleling SSE41DQ). 2025-11-28 Jan Beulich ld: support most modifiers for printf() like vfinfo() format specifiers Not doing so is pretty error prone: One needs to distinguish e.g. ->einfo() and alike invocations out of libbfd from _bfd_error_handler() ones. Omit support for * though for now, as that would be more intrusive to implement. Use this then to disambiguate x86'es ISA level diagnostic of unknown bits, where decimal vs hex isn't immediately clear. 2025-11-28 Guillaume VACHERIAS bfd/Dwarf: Add suitable defines to use at call and use sites use do_loc and do_types arguments into a signle unsigned int do_flags for better code readability. binutils/ * dwarf.c (DO_LOC, DO_TYPES): Define. (process_debug_info): Change arguments do_loc and do_types to a single unsigned int do_flags. (find_cu_tu_set_v2): Change parameter do_types from int to bool. 2025-11-28 GDB Administrator Automatic date update in version.in 2025-11-27 Simon Marchi gdb/MAINTAINERS: add Christina Schimpe as x86-64 and i386 maintainer Christina Schimpe has kindly agreed to take on the role of maintainer for the x86-64 and i386 targets (thank you!). Update the MAINTAINERS file to reflect that. Change-Id: I0b01ea5a1dedf0f5f58dc9f66d54014d4f5bbb00 2025-11-27 Guinevere Larsen gdb: Make startup message more user friendly Currently, on startup, GDB prints a lot of licensing information and then a few hints for new users. While there is an attempt to separate the hints from the rest of the text, my user testing showed that it is not good enough, and most unfamiliar users will just skip the information. Especially considering that the documentation link happens before the separation. This commit attempts to make the startup message more friendly to new users by visually separating the most important commands from the copyright. If there is enough space available, a box is printed containing the hints (either using unicode box drawing characters, if emojis are allowed, or using ascii). If there isn't space for a box, a simple line separator is printed. The code deems "enough space available" when there is enough space to print the documentation URL inside the box, since the other hints will be broken into multiple lines if necessary. Here are examples of the 2 possible startups, with enough space: +-----------------------------------------------------------------+ | Find the GDB manual online at: | | http://www.gnu.org/software/gdb/documentation/ | | For help, type "help". | | Type "apropos " to search for commands related to "word". | +-----------------------------------------------------------------+ And with limited space: --------------------------------------------- Find the GDB manual documentation resources o nline at: . For help, type "help". Type "apropos word" to search for commands re lated to "word". Approved-By: Tom Tromey 2025-11-27 Tankut Baris Aktemur gdb: make test name initials lowercase in gdb.base/gdbvars.exp According to GDB coding style, test names should start with lowercase: https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Follow_the_test_name_convention Modify the test names in gdb.base/gdbvars.exp accordingly. 2025-11-27 Tom de Vries [gdb/tdep] Simplify i386_thiscall_push_dummy_call I came across this code in i386_thiscall_push_dummy_call: ... int args_space = 0; ... for (write_pass = 0; write_pass < 2; write_pass++) { int args_space_used = 0; ... if (write_pass) { store_unsigned_integer (buf, 4, byte_order, struct_addr); write_memory (sp, buf, 4); args_space_used += 4; } else args_space += 4; ... and wondered about the difference between arg_space and arg_space_used. AFAICT, there is none: - args_space is available after the loop, but unused after the loop - in the loop body: - if write_pass == 0: args_space is used - if write_pass == 1: arg_space_used - the code modifying args_space and args_space_used is identical Simplify the loop body by using just one variable: args_space. Tested on x86_64-linux with target board unix/-m32. 2025-11-27 Rainer Orth Obsolete support for Solaris < 10 Support for Solaris 8 and 9 has long been removed from GCC: * Solaris 8 support in GCC 4.8 (2013) * Solaris 9 support in GCC 5 (2015) so it's time to obsolete anything before Solaris 10 in binutils, too. Both wouldn't even build since binutils 2.41. Tested on both i386-pc-solaris2.8 (with and without --enable-obsolete) and i386-pc-solaris2.11. 2025-11-26 Rainer Orth bfd: * config.bfd <*-*-solaris2.[0-9]*>: Obsolete. 2025-11-27 GDB Administrator Automatic date update in version.in 2025-11-26 Alan Modra PR 33453 linker generated .eh_frame This is the final piece to fix the PR33453 testcase. It makes use of the extended size final link buffer when writing linker generated .eh_frame. PR 33453 * elf-bfd.h (_bfd_elf_write_linker_section_eh_frame): Declare. * elf-eh-frame.c (_bfd_elf_write_linker_section_eh_frame): New. * elf32-ppc.c (ppc_elf_finish_dynamic_sections): Use new function. * elf64-ppc.c (ppc64_elf_finish_dynamic_sections): Likewise. * elf64-s390.c (elf_s390_finish_dynamic_sections): Likewise. * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Likewise. 2025-11-26 Alan Modra PR 33453 backend_finish_dynamic_sections final link buffer This adds a pointer parameter to backend_finish_dynamic_sections, to give the function access to the final link section contents buffer. The patch is entirely mechanical changes in preparation for the next patch. No use is made of the buffer here. 2025-11-26 Alan Modra PR 33453 allow extra for .eh_frame in final link buffer The PR33453 testcase overflows a buffer allocated for the .eh_frame section. This happens with a silly large alignment for .eh_frame, creating a large gap between two .eh_frame sections. When the last FDE of the first section is stretched to cover the gap, we get a buffer overflow. This patch makes the final link buffer large enough to cover such gaps. It doesn't fix the testcase yet, because there the first .eh_frame section in question is the x86 plt_eh_frame section which uses a different buffer. However, similar testcases could be constructed using object file .eh_frame sections. PR 33453 * elflink.c (bfd_elf_final_link): Round up max_contents_size for .eh_frame alignment. 2025-11-26 Alan Modra Tidy .eh_frame rawsize manipulation bfd_elf_discard_info is only called once. Well, it was until commit 9b854f169df9 introduced cmdline_emit_object_only_section, but I think and hope that function does enough reinitialisation to not cause a problem. There would be a problem if bfd_elf_discard_info was called iteratively, shrinking an eh_frame section on the first pass, then further shrinking on another pass. That's because _bfd_elf_discard_section_eh_frame uses rawsize to store the last section size, which is against the general rules for input sections. rawsize needs to be kept as the initial size to be able to read section contents again (or you'd need to cache the edited contents). Other eh_frame functions would break too. So this tidy makes it obvious when looking at _bfd_elf_discard_section_eh_frame alone that rawsize is only set once, to the initial size. There are no functional changes here. * elf-bfd.h (_bfd_elf_discard_section_eh_frame): Update decl. * elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Return an int status. Don't set rawsize unless it is zero. * elflink.c (bfd_elf_discard_info): Use new return status from _bfd_elf_discard_section_eh_frame rather than comparing section size with rawsize. 2025-11-26 Simon Marchi gdb: fix some whitespace issues Replace 8 spaces with a tab. Change-Id: Ie8f942ce4b4ba4a83c2ee83cb904153b2e58cf8c 2025-11-26 Indu Bhagat libsframe: testsuite: remove usage of ##__VA_ARGS__ '##__VA_ARGS' is a GNU extension, the usage of which in the testsuite of libsframe may cause failure to build on platforms where the compiler may not support the GNU extension. This GNU extension swallows the preceding comma if the variable arguments list is empty. In libsframe testsuite though, an empty list is never used. Usages will remain of the following type: - TEST (cond, "string", vars); or - TEST (cond, "string"); Mailing list discussion: https://sourceware.org/pipermail/binutils/2025-November/145825.html PR libsframe/33437 libsframe/testsuite/ PR libsframe/33437 * sframe-test.h: Replace ##__VA_ARGS__ with __VA_ARGS__. 2025-11-26 Abhay Kandpal PowerPC: Skip base type RTTI tests before inferior start On PowerPC targets, RTTI typeinfo objects for simple base types such as `int`, `char*`, and `const char*` may not be emitted until the inferior has been started. As a result, the `gdb.cp/typeid.exp` test fails when checking typeid results before program execution begins. This patch extends the existing Clang-specific logic that skips base type RTTI checks before the inferior starts, to also apply on PowerPC. This ensures consistent test behavior across compilers and targets. gdb/testsuite/ * gdb.cp/typeid.exp (do_typeid_tests): Skip base type RTTI tests before inferior start on PowerPC. Approved-By: Tom de Vries 2025-11-26 Indu Bhagat libsframe: bugfix in flip_sframe A previous commit bdb0d62281a to make flip_fde version aware added a new argument for passing the remaning buffer size to the involved functions. Fix the passed value to the intended. libsframe/ * sframe.c (flip_sframe): Correct the passed value of buf size. 2025-11-26 GDB Administrator Automatic date update in version.in 2025-11-25 Simon Marchi gdb/solib-svr4: remove unnecessary assert and variable I don't think this assert adds any value. Change-Id: Ibc12566f97bf9b7c091967a34b74d2b76c2b8e54 Cc: Lancelot SIX 2025-11-25 Simon Marchi gdb: replace FRAME_OBSTACK_{C,Z}ALLOC macros with templated functions While reviewing a patch, I saw these macros and thought they could be modernized a bit. Change-Id: I540edbcfd2e1e3cfd6afa0e911f43c8b89862414 2025-11-25 lijian1 LoongArch: set PRSTATUS_SIZE=0x1e0 to match kernel's struct elf_prstatus size As PRSTATUS_SIZE is now with the value 0x1d8, which causes inconsistency with the kernel definition and then can not lead to the correct branch for loongarch64 backend. With the correct value 0x1e0 for the master branch, the loongarch64 banckend will work well. 2025-11-25 John David Anglin hppa64: Fix bogus warning from elf_hppa_final_link_relocate 2025-11-24 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf_hppa_final_link_relocate): Initialize opd_off. 2025-11-25 GDB Administrator Automatic date update in version.in 2025-11-24 John David Anglin hppa64: Fix R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocation support The elf_hppa_final_link_relocate function didn't handle R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocations for local symbols. DLT and OPD output relocation support for local symbols is consolidated in elf_hppa_dlt_dynrel_reloc() and elf_hppa_opd_dynrel_relocs(). 2025-11-24 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf_hppa_dlt_dynrel_reloc): New. (elf_hppa_opd_dynrel_relocs): New. (elf_hppa_final_link_relocate): Use elf_hppa_dlt_dynrel_reloc() and elf_hppa_opd_dynrel_relocs(). Fix relocation support for R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64. 2025-11-24 Alan Modra PR 33474 SEGV in init_reloc_cookie This segfault is triggered by a tekhex input. PR 33474 * elflink.c (bfd_elf_gc_sections): Don't try to parse .eh_frame in non-ELF input files. 2025-11-24 Alan Modra PR 33473 SEGV in _bfd_elf_gc_mark_debug_special_section_group The code that faulted made the assumption that a group section always had at least one valid member. Fix that assumption. Also fail if all entries in a SHT_GROUP section are invalid. (An empty group will not result in a call to process_sht_group_entries.) PR 33473 * elflink.x (_bfd_elf_gc_mark_debug_special_section_group): Don't segfault on empty group. * elf.c (process_sht_group_entries): Return false if all entries are invalid. 2025-11-24 Alan Modra replace tail with sed The default Solaris tail doesn't support "tail -n +4", apparently. Use sed instead. PR 33396 * testsuite/binutils-all/objdump.exp: Replace tail with an equivalent sed expression in dwarf5 objdump -Wi test. 2025-11-24 Alan Modra bogus FAILs from mmix ld testsuite Get rid of [^c][^h][^i][^l][^d] from error regex. It won't match /home/... and other legitimate paths printed for the program name of the ld under test. * testsuite/ld-mmix/bpo-15.d: Fix error regex. * testsuite/ld-mmix/bpo-15m.d: Likewise. * testsuite/ld-mmix/bpo-21.d: Likewise. * testsuite/ld-mmix/bpo-21m.d: Likewise. 2025-11-24 Michael Matz Use version index 1 for defined symbols It's reasonable to use version index 0 for undefined symbols, so let's continue doing that. For defined (global) symbols that aren't otherwise versioned continue using VER_NDX_GLOBAL (partly reverting behaviour introduced in commit f685e395). bfd/ PR ld/33577 * elflink.c (elf_link_output_extsym): Don't set noversion for defined syms. ld/ PR ld/33577 * ld-elfvers/vers16.dsym: Add back the "Base" version for defined syms. 2025-11-24 Michael Matz Make readelf not print 'foo@@' for normal symbols when a symbol 'foo' is exported and non-hidden and hence is available for resolving from other objects it's unreasonable for readelf to print it as 'foo@@'. If it's not available for unversioned resolving because its version is hidden (but without name), then continue printing it as 'foo@' to indicate that something special goes on. 2025-11-24 Matthieu Longo aarch64: constify BTI and GCS report functions This patch consitifies the arguments of the functions used to report BTI and GCS errors, and also renames the argument "ebfd" to "abfd" as this naming is confusing and inconsistent with others places. 2025-11-24 Matthieu Longo gas: move code for object attribute parsing into obj-elf-attr.c Gas, contrarilly to others binutils tools, is compiled for a specific target. Some targets don't support Object Attributes (OAs). For those cases, today the OA directive ".gnu_attribute" is still enabled but the processing would probably fail in most of cases because the named tag would be unknown. Most of the parsing code on such a target can be considered as dead code. This patch aims at removing this dead code from Gas when the target does not support the OAs by: - moving the code of OA parsing into a separate file under gas/config which is only included for the relevant targets supporting OAs. - disabling the code related to OAs on non-OA target via a TC_OBJ_ATTR macro. Adding/removing the OA feature from Gas for a specific target can easilly be done from tc-.h by changing the values of TC_OBJ_ATTR: 1 enabled, 0 disabled. You might also want to guard the enablement of OAs only for ELF targets with OBJ_ELF (see example below). \#ifdef OBJ_ELF /* The target supports Object Attributes. */ \#define TC_OBJ_ATTR 1 \#endif 2025-11-24 Matthieu Longo bfd: rename parsing methods of object attribute v1 API This patch is a preparation for the introduction of object attributes v2. It aims at: - making clear what methods are used to parse OAv1 - adding more constaints on parameters type by using enums instead of defines. - hiding the attribute tag type behind a typedef. - preparing the move of object attributes's parsing code to another file. Note: the name obj_attr_v1_process_attribute is exposed in the API. Ideally, the version should not be part of the name, and be hidden behind a macro. However, a later patch will unify the parsing of OAv1 and OAv2, and will make the use of such a macro obsolete. 2025-11-24 Matthieu Longo bfd: rename old references to build attributes A previous refactoring patch [1] introduced "build_attributes" in the functions naming. However this naming is specific to the AArch64 Build Attributes specification, and should be replaced by "object_attributes" going forward. [1]: 011e50143f0ec1be271f93facb56def9394947d2 2025-11-24 Nelson Chu RISC-V: Tidy and aligned riscv_supported_std_[z|x]_ext tables 2025-11-24 Simon Marchi gdb: resolve dynamic type in one value_cast case This particular path for value_cast does not attempt to resolve a dynamic target type before assigning it to the new value. Having a value with a dynamic type that hasn't been resolved causes an assert later, when printing the value. For instance, running the added test without the fix yields: (gdb) p (outer_type) g_outer_as_char_array $7 = ( /home/smarchi/src/binutils-gdb/gdb/value.c:3111: internal-error: primitive_field: Assertion `type->dyn_prop (DYN_PROP_DATA_LOCATION)->is_constant ()' failed. This code path is taken when the value being cast has the same size as the target type, and no earlier more specific rule matched. Fix it by adding a call to resolve_dynamic_type before assigning the target type to the value. The test exercises this by defining a char array (`g_outer_as_char_array`) with the same size as `outer_type` in the DWARF info, then casting it to `outer_type`. Without the fix, this triggers the assertion when printing the result. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33575 Change-Id: I547da32bbd24462b779e76bceb6e0a87859188d1 Approved-By: Tom Tromey 2025-11-24 Simon Marchi gdb: force lval_memory for value components with dynamic data location Using the test program from the added test, I get this internal error: $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/data-loc-cast/data-loc-cast -ex "with language fortran -- p (outer_type) g_outer_var" -batch $1 = ( /home/smarchi/src/binutils-gdb/gdb/value.c:1697: internal-error: set_component_location: Assertion `this->lval () == lval_memory' failed. The test added by this patch mimics a problem that was reported when debugging a Fortran program. The situation is: - The DWARF defines a Fortran-style array type, with a DW_AT_data_location attribute. - It then defines a structure type (outer_type) with a field (outer_type::assoc) of that array type. - Trying to cast a minimal symbol (g_outer_var) to that structure type leads to the internal error shown above. The use case for this is: for some reason, a variable of type S isn't described in the debug info, but GDB still knows about type S. The user is trying to say: I know that the variable at this address is an S, show it to me. A Fortran-style array doesn't hold the data directly. It's a structure (a descriptor) that contains a pointer to the data and possible other properties, like the length of the array. The DW_AT_data_location attribute contains a DWARF expression that yields the location the actual data, given the location of the descriptor. In GDB's type system, this translates to a dynamic property of kind DYN_PROP_DATA_LOCATION pointing to the DWARF expression. Before instantiating a value with such a dynamic type, the dynamic type must first be resolved, which is done by function resolve_dynamic_type. That is, for each dynamic property, compute a concrete value for the specific instance we're dealing with here. The result of resolve_dynamic_type is a type that is just like the input type, but where all dynamic properties now have concrete, constant values. Here's the timeline of what happens when doing "p (outer_type) g_outer_var": 1. We start in var_msym_value_operation::evaluate_for_cast. 2. We go in function value_cast, in this branch: else if (arg2->lval () == lval_memory) return value_at_lazy (to_type, arg2->address ()); ... where to_type is the "outer_type" structure and arg2 is the minsym. This effectively builds a value pretending that there exists an instance of outer_type at the address of the minsym, which is what we want. The resulting value is "lval_memory". 3. Somewhere inside value_at_lazy, there is a call to resolve_dynamic_type: #0 resolve_dynamic_type (type=0x7e0ff1cfd560, valaddr=..., addr=0x4340, in_frame=0x7bfff0b3f100) at /home/smarchi/src/binutils-gdb/gdb/gdbtypes.c:3011 #1 0x000055556687dcba in value_from_contents_and_address (type=0x7e0ff1cfd560, valaddr=0x0, address=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/value.c:3669 #2 0x00005555667ec527 in get_value_at (type=0x7e0ff1cfd560, addr=0x4340, frame=..., lazy=1) at /home/smarchi/src/binutils-gdb/gdb/valops.c:992 #3 0x00005555667ec79f in value_at_lazy (type=0x7e0ff1cfd560, addr=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/valops.c:1039 #4 0x00005555667e902b in value_cast (type=0x7e0ff1cfd560, arg2=0x7d0ff1c35540) at /home/smarchi/src/binutils-gdb/gdb/valops.c:645 This is good, it returns a structure type where the type of field "assoc" has a constant DYN_PROP_DATA_LOCATION property that holds the memory address where the data for this array resides. 4. Back in var_msym_value_operation::evaluate_for_cast, we do: val = value_cast (to_type, val); /* Don't allow e.g. '&(int)var_with_no_debug_info'. */ if (val->lval () == lval_memory) { if (val->lazy ()) val->fetch_lazy (); val->set_lval (not_lval); } This is meant to make GDB behave more or less like C, where the result of a cast is not an lvalue, of which you can't take the address, for instance. I am not an expert in this area, but Pedro explained that this lval thing in GDB actually conflates two things: - where is the value (memory, register, only in GDB's mind, etc) - is this an lvalue (is it assignable, can you take its address, etc) Here, we would ideally want to say that the value is not an lvalue, but still say that it lives at a given address in memory. But since the two concepts are conflated, we set it to "not_lval", which means "not an lval and does not exist on target". If there was a way to say "non-lvalue" and "in memory", I think that the bug that follows would be hidden. 5. When printing the value, the value-printing code attempts to fetch the "assoc" field of the struct using value::primitive_field, which then goes into value::set_component_location. In set_component_location there is this code, which is where we find the assert that fails: /* If the COMPONENT has a dynamic location, and is an lval_internalvar_component, then we change it to a lval_memory. Usually a component of an internalvar is created non-lazy, and has its content immediately copied from the parent internalvar. However, for components with a dynamic location, the content of the component is not contained within the parent, but is instead accessed indirectly. Further, the component will be created as a lazy value. By changing the type of the component to lval_memory we ensure that value_fetch_lazy can successfully load the component. This solution isn't ideal, but a real fix would require values to carry around both the parent value contents, and the contents of any dynamic fields within the parent. This is a substantial change to how values work in GDB. */ if (this->lval () == lval_internalvar_component) { gdb_assert (lazy ()); m_lval = lval_memory; } else gdb_assert (this->lval () == lval_memory); I think that what this comment is really trying to say is: if a structure is an internalvar, and a field of that structure has a dynamic data location, then the actual data is not contained in the internalvar, it is in memory. The message for the commit that introduced that code (3c8c6de21da "gdb: user variables with components of dynamic type")) confirms it, I think. The message also goes on to explain that we could imagine a world where the internalvar outer struct value would also capture the (indirect) contents of the array field. The internalvar value would then be completely self-contained. I imagine this could be useful in some cases, but we don't have that today. The comment makes it sound like it's a hack, but I actually think it makes sense. This is what is really happening. This all assumes that the result of the DW_AT_data_location is a location in memory. I guess this is true for all practical purposes today, but it would be possible for DW_AT_data_location to yield a register, a composite, or even "undefined" (meaning optimized out) as a location (which would be even easier to implement with the upcoming DWARF 6 "Location descriptions on the DWARF stack" feature [1]). In that case, the location that we set for the array component should reflect whatever the DWARF expression returned. But that is future work, for now, we assume that the data location can only be in memory. So, the fix is basically to always set the location of a value sub-component to "memory", because we assume (for now) that the result of all DW_AT_data_location expressions will be memory locations. Now, referring back to point 4 above: if the code in var_msym_value_operation::evaluate_for_cast could in fact set the value to "non-lvalue in memory", then we wouldn't hit the assert in value::set_component_location, because the subcomponent would have inherited lval_memory from the parent structure. However, I still think that the fix in this patch is valid on its own. Imagine that the DWARF says that the outer struct (and thus the array descriptor) is in a register. Once we evaluate the DW_AT_data_location of the array field, the value describing the actual data is still in memory. The takeaway is that regardless of the location of the descriptor, the DW_AT_data_location expression always returns a memory location (for now), so we should always set the location of that value to memory. In other words, we apply the same logic as commit 3c8c6de21da regardless of the location of the outer value". Finally, a note about the test: I made the array content very long (100 elements), because I did spot some issues where GDB would conflate the size of the array data with the size of the array field, within the outer structure. The test does not expose these issues and I didn't try to fix them here (one thing at a time), but making the array size very large might help spot these issues in the future. [1] https://dwarfstd.org/issues/230524.1.html Change-Id: Ib10a77b62cd168fc7c08702e0f6dd47b5ac0f097 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33575 Approved-By: Tom Tromey 2025-11-24 H.J. Lu elf: Verify base symbol version works properly Add a testcase to verify that VER_NDX_GLOBAL can be used with asm (".symver foo_base, foo@"); to create the base version to provide an unversioned compatible symbol. PR ld/33577 * testsuite/ld-elfvers/pass.out: New file. * testsuite/ld-elfvers/pr33577-unversioned.c: Likewise. * testsuite/ld-elfvers/pr33577-unversioned.rd: Likewise. * testsuite/ld-elfvers/pr33577-versioned.c: Likewise. * testsuite/ld-elfvers/pr33577-versioned.rd: Likewise. * testsuite/ld-elfvers/pr33577.map: Likewise. * testsuite/ld-elfvers/pr33577a.c: Likewise. * testsuite/ld-elfvers/pr33577b.c: Likewise. * testsuite/ld-elfvers/vers.exp: Run ld/33577 tests. 2025-11-24 GDB Administrator Automatic date update in version.in 2025-11-23 Tom Tromey Remove a call to blockvector::map block_starting_point_at checks blockvector::map before doing a lookup. This patch removes this call, a step toward making the blockvector API a bit more opaque. It arranges to find the necessary blockvector just once, in gather_inline_frames, and then uses the 'lookup' method to find the desired block. Note that this is a slight change of semantics, in that the old code looked only in the map while the new code looks in the blockvector, regardless of whether a map was made. However, I don't think this should matter, and furthermore this seems like an abstraction violation, with the inline-frame code knowing details of how buildsym decided to create the blockvector. in the longer run, I think only the 'lookup' method should be provided by blockvector -- that is, separately checking the map should be impossible. The idea here is that eventually, for lazy CU expansion, we will want to be able to expand the blockvector. This may be easier with a different underlying data structure, so perhaps the map will go away entirely. After this patch, one such use remains. Regression tested on x86-64 Fedora 40. Approved-by: Kevin Buettner 2025-11-23 Tom de Vries [gdb/testsuite] Fix whitespace issues This is the result of: ... $ git rm -rf gdb/testsuite $ git commit -a -m tmp $ git revert HEAD $ git rebase --whitespace=fix HEAD^ ... Tested on x86_64-linux. PR build/33616 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616 2025-11-23 Tom de Vries [gdb/build, c++20] Fix deprecated implicit capture in cooked_index::set_contents Fix deprecated implicit capture of this in cooked_index::set_contents, by removing the capture default, and explicitly listing all captures. Tested on x86_64-linux. 2025-11-23 GDB Administrator Automatic date update in version.in 2025-11-22 Tom Tromey Change dw2_search_one to be static I noticed that dw2_search_one can be static. Tested by rebuilding. 2025-11-22 Tom de Vries [gdb/testsuite] Rewrite strings in gdb.ada/unchecked_union.exp In test-case gdb.ada/unchecked_union.exp, git --check reports some whitespace issues: ... $ git diff-tree --check $(git hash-object -t tree /dev/null) HEAD \ -- gdb/testsuite/gdb.ada/unchecked_union.exp \ | grep -c "indent with spaces" 12 ... The problem is that this style of string is used containing space-indented text: ... set inner_string { case ? is when 0 => small: range 0 .. 255; second: range 0 .. 255; when ? => bval: range 0 .. 255; when others => large: range 255 .. 510; more: range 255 .. 510; end case; } ... Fix this by changing the string into a list of strings: ... set inner_string \ [list \ " case ? is" \ " when 0 =>" \ " small: range 0 .. 255;" \ " second: range 0 .. 255;" \ " when ? =>" \ " bval: range 0 .. 255;" \ " when others =>" \ " large: range 255 .. 510;" \ " more: range 255 .. 510;" \ " end case;"] ... which also fixes the odd position of the first line in the original version. Tested on x86_64-linux. Approved-By: Tom Tromey PR build/33616 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616 2025-11-22 Sam James gprofng: disable LTO as a workaround Temporarily disable LTO by passing -fno-lto until PR32092 is fixed, as we get test failures and seemingly a completely broken gprofng otherwise. Use the same idiom as libdecnumber for -fno-lto. gprofng/ PR gprofng/32092 * Makefile.am: Pass -fno-lto if supported. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Pass -fno-lto if supported. * doc/Makefile.in: Regenerate. * gp-display-html/Makefile.in: Regenerate. * libcollector/Makefile.am: Pass -fno-lto if supported. * libcollector/Makefile.in: Regenerate. * src/Makefile.am: Pass -fno-lto if supported. * src/Makefile.in: Regenerate. 2025-11-22 Alan Modra Re: dlltool memory leaks I missed one needed strdup of symbol names, needed since the original symbol name memory is freed on bfd_close. PR 33651 * dlltool.c (scan_filtered_symbols): xstrdup symbol name. 2025-11-22 GDB Administrator Automatic date update in version.in 2025-11-21 Alan Modra PR 33639 .debug_loclists output The fuzzed testcase in this PR prints an almost endless table of offsets, due to a bogus offset count. Limit that count, and the total length too. PR 33639 * dwarf.c (display_loclists_unit_header): Return error on length too small to read header. Limit length to section size. Limit offset count similarly. 2025-11-21 Alan Modra PR 33638, debug_rnglists output The fuzzed testcase in this PR continuously outputs an error about the debug_rnglists header. Fixed by taking notice of the error and stopping output. The patch also limits the length in all cases, not just when a relocation is present, and limits the offset entry count read from the header. I removed the warning and the test for relocs because the code can't work reliably with unresolved relocs in the length field. PR 33638 * dwarf.c (display_debug_rnglists_list): Return bool. Rename "inital_length" to plain "length". Verify length is large enough to read header. Limit length to rest of section. Similarly limit offset_entry_count. (display_debug_ranges): Check display_debug_rnglists_unit_header return status. Stop output on error. 2025-11-21 Alan Modra som foreign syms The makes use of the copy_private_symbol_data change in order to prevent bogus writes seen when running objcopy with binary input and som output. It doesn't fix "FAIL: binary symbol", because the som backend also doesn't copy binary sections to the output, a fact that I didn't notice until I'd gone quite some way into fixing symbols.. * som.c (som_bfd_copy_private_symbol_data): Make som symbols for non-som input. 2025-11-21 Alan Modra bfd_copy_private_symbol_data Allow copy_private_symbol_data to replace osym if a target desires. Change isym similarly for symmetry. The idea is to make it possible to give the asymbol an output target specific extension. Some targets, eg. som, use such an extension when outputting symbols, behaving badly if the input object is not som. There are no functional changes in this patch; It just changes the signatures. bfd/ * elf-bfd.h (_bfd_elf_copy_private_symbol_data): Replace asymbol* params with asymbol**. * elf.c (_bfd_elf_copy_private_symbol_data): Likewise. * libbfd-in.h (_bfd_bool_bfd_asymbol_bfd_asymbol_true): Likewise. * libbfd.c (_bfd_bool_bfd_asymbol_bfd_asymbol_true): Likewise. * mach-o.c (bfd_mach_o_bfd_copy_private_symbol_data): Likewise. * mach-o.h (bfd_mach_o_bfd_copy_private_symbol_data): Likewise. * plugin.c (bfd_plugin_bfd_copy_private_symbol_data): Likewise. * som.c (som_bfd_copy_private_symbol_data): Likewise. * targets.c (bfd_target <_bfd_copy_private_symbol_data>): Likewise. * bfd-in2.h: Regenerate. * libbfd.h: Regenerate. binutils/ * objcopy.c (copy_object): Adjust bfd_copy_private_symbol_data call. gas/ * symbols.c symbol_clone): Adjust bfd_copy_private_symbol_data call. 2025-11-21 Alan Modra copy_private and merge_private functions These are all called via BFD_SEND on the output bfd xvec. Thus there is no need to verify the output bfd flavour. There *is* a need to verify the input bfd flavour. Also of course target specific data shouldn't be accessed until the input target is verified. Tidy these issues in many places. bfd_copy_private_section_data, bfd_copy_private_symbol_data, and bfd_merge_private_bfd_data are macros. Delete prototypes created via synopsis entry in comments. * aout-target.h (MY_bfd_copy_private_section_data): Remove unnecessary output bfd flavour check. * coff-arm.c (coff_arm_merge_private_bfd_data): Likewise. * elf-m10300.c (_bfd_mn10300_elf_merge_private_bfd_data): Likewise. * ecoff.c (_bfd_ecoff_bfd_copy_private_bfd_data): Likewise, and move setup of pointers into target specific data after check. * elf.c (_bfd_elf_copy_private_bfd_data): Likewise. (_bfd_elf_copy_private_symbol_data): Likewise. (copy_private_bfd_data): Remove checks duplicating those done in caller. (_bfd_elf_copy_private_section_data): Remove unnecessary output bfd flavour check. (_bfd_elf_copy_private_header_data): Likewise. * elf32-arc.c (arc_elf_print_private_bfd_data): Likewise. (arc_elf_merge_private_bfd_data): Likewise. * elf32-arm.c (elf32_arm_copy_private_bfd_data): Likewise. (elf32_arm_merge_private_bfd_data): Likewise. * elf32-cr16.c (_bfd_cr16_elf_merge_private_bfd_data): Likewise. * elf32-cris.c (cris_elf_merge_private_bfd_data): Likewise. (cris_elf_merge_private_bfd_data): Likewise. * elf32-csky.c (csky_elf_merge_private_bfd_data): Likewise. * elf32-h8300.c (elf32_h8_merge_private_bfd_data): Likewise. * elf32-lm32.c (lm32_elf_fdpic_copy_private_bfd_data): Likewise. * elf32-m32r.c (m32r_elf_merge_private_bfd_data): Likewise. * elf32-m68hc1x.c (_bfd_m68hc11_elf_merge_private_bfd_data): Likewise. * elf32-m68k.c (elf32_m68k_merge_private_bfd_data): Likewise. * elf32-mcore.c (mcore_elf_merge_private_bfd_data): Likewise. * elf32-nds32.c (nds32_elf_merge_private_bfd_data): Likewise. * elf32-or1k.c (elf32_or1k_merge_private_bfd_data): Likewise, and move setup of pointers into target specific data after check. * elf32-ppc.c (ppc_elf_merge_private_bfd_data): Remove unnecessary output bfd flavour check. * elf32-s390.c (elf32_s390_merge_private_bfd_data): Likewise. * elf32-score.c (s3_elf32_score_merge_private_bfd_data): Likewise, and move check before target specific data accesss. * elf32-sh.c (sh_elf_copy_private_data): Remove unnecessary output bfd flavour check. (sh_elf_merge_private_data): Likewise. * elf32-sparc.c (elf32_sparc_merge_private_bfd_data): Likewise. * elf32-v850.c (v850_elf_merge_private_bfd_data): Likewise. * elf32-vax.c (elf32_vax_merge_private_bfd_data): Likewise. * elf32-visium.c (visium_elf_copy_private_bfd_data): Likewise. * elf32-xtensa.c (elf_xtensa_merge_private_bfd_data): Likewise. * elf64-ia64-vms.c (elf64_ia64_merge_private_bfd_data): Likewise. * elf64-ppc.c (ppc64_elf_merge_private_bfd_data): Likewise. * elf64-s390.c (elf64_s390_merge_private_bfd_data): Likewise. * elf64-sparc.c (elf64_sparc_merge_private_bfd_data): Likewise. * elfnn-aarch64.c (elfNN_aarch64_merge_private_bfd_data): Likewise. * elfnn-ia64.c (elfNN_ia64_merge_private_bfd_data): Likewise. * elfnn-kvx.c (elfNN_kvx_merge_private_bfd_data): Likewise. * elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data): Likewise. * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Likewise. * elfxx-mips.c (_bfd_mips_elf_merge_private_bfd_data): Likewise. * mach-o.c (bfd_mach_o_bfd_copy_private_section_data): Likewise. (bfd_mach_o_bfd_copy_private_header_data): Likewise. * mmo.c (mmo_bfd_copy_private_bfd_data): Likewise. * peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Likewise. (_bfd_XX_bfd_copy_private_section_data): Likewise. * som.c (som_bfd_copy_private_section_data): Likewise. (som_bfd_copy_private_bfd_data): Likewise. (som_bfd_copy_private_symbol_data): Likewise, and move setup of pointers into target specific data after check. * elf32-bfin.c (elf32_bfin_merge_private_bfd_data): Check input bfd flavour. * elf32-frv.c (frv_elf_merge_private_bfd_data): Likewise. * elf32-iq2000.c (iq2000_elf_merge_private_bfd_data): Likewise. * elf32-m32c.c (m32c_elf_merge_private_bfd_data): Likewise. * elf32-mep.c (mep_elf_merge_private_bfd_data): Likewise. * elf32-rl78.c (rl78_elf_merge_private_bfd_data): Likewise. * elf32-rx.c (rx_elf_merge_private_bfd_data): Likewise. * elf32-score7.c (s7_elf32_score_merge_private_bfd_data): Likewise. * elf32-tic6x.c (elf32_tic6x_merge_private_bfd_data): Likewise. * elf32-v850.c (v850_elf_copy_notes): Likewise. * elf32-visium.c (visium_elf_merge_private_bfd_data): Likewise. * mach-o.c (bfd_mach_o_bfd_copy_private_symbol_data): Likewise. * linker.c (bfd_merge_private_bfd_data): Delete SYNOPSIS. * section.c (bfd_copy_private_section_data): Likewise. * syms.c (bfd_copy_private_symbol_data): Likewise. * bfd-in2.h: Regenerate. 2025-11-21 Alan Modra ecoff foreign syms This fixes the alpha-linux-gnuecoff failures exposed by commit 35e1c33162bf. * ecoff.c (ecoff_get_extr): Choose better symbol class for non-ecoff symbols. 2025-11-21 timurgol007 RISC-V: Fixed opcodes for some bitmanip instructions Currently some of the instructions in bitmanip extensions can not be obtained using DECLARE_INSN macros. I generated them using riscv-opcodes and added to other opcodes. Approved-By: Nelson Chu 2025-11-21 Tom de Vries [gdb/corefiles] Fix segfault in add_thread_silent A user reported a segfault when loading a core file [1]. The core file is from arm-linux, but I reproduced the segfault on x86_64-linux: ... $ gdb -q --core core warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing Fatal signal: Segmentation fault ----- Backtrace ----- 0x64a4ff gdb_internal_backtrace_1 gdb/bt-utils.c:122 0x64a59d _Z22gdb_internal_backtracev gdb/bt-utils.c:175 0x9429e7 handle_fatal_signal gdb/event-top.c:1013 0x942b96 handle_sigsegv gdb/event-top.c:1090 0x7fbf6a64708f ??? /usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_ /usr/include/c++/15/bits/stl_iterator.h:1059 0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv /usr/include/c++/15/bits/stl_vector.h:1029 0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv /usr/include/c++/15/bits/stl_vector.h:1224 0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv gdb/../gdbsupport/unordered_dense.h:1351 0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_ gdb/../gdbsupport/unordered_dense.h:1119 0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_ gdb/../gdbsupport/unordered_dense.h:1773 0xa6f787 _ZN8inferior11find_threadE6ptid_t gdb/inferior.c:253 0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t gdb/thread.c:310 0x73b995 core_target_open gdb/corelow.c:1111 0x73a095 _Z17core_file_commandPKci gdb/corelow.c:708 0xb6cb38 catch_command_errors gdb/main.c:510 0xb6e354 captured_main_1 gdb/main.c:1279 0xb6e9a2 captured_main gdb/main.c:1372 0xb6eaa3 _Z8gdb_mainP18captured_main_args gdb/main.c:1401 0x419704 main gdb/gdb.c:38 ... The problem happens as follows. In core_target_open, we do: ... if (thread == NULL) thread = add_thread_silent (target, ptid_t (CORELOW_PID)); ... and then in add_thread_silent: ... struct thread_info * add_thread_silent (process_stratum_target *targ, ptid_t ptid) { gdb_assert (targ != nullptr); inferior *inf = find_inferior_ptid (targ, ptid); ... find_inferior_ptid returns nullptr, which eventually causes the segfault. So, why can't we find an inferior with CORELOW_PID? A bit earlier in core_target_open, we do: ... /* Find (or fake) the pid for the process in this core file, and initialise the current inferior with that pid. */ bool fake_pid_p = false; int pid = bfd_core_file_pid (target->core_bfd ()); if (pid == 0) { fake_pid_p = true; pid = CORELOW_PID; } inferior *inf = current_inferior (); gdb_assert (inf->pid == 0); inferior_appeared (inf, pid); inf->fake_pid_p = fake_pid_p; ... The problem is that looking for an inferior using CORELOW_PID is correct in case fake_pid_p == true, but otherwise not. Fix this by using inf->pid instead: ... - thread = add_thread_silent (target, ptid_t (CORELOW_PID)); + thread = add_thread_silent (target, ptid_t (inf->pid)); ... Doing so enables us to continue to a gdb prompt: ... Core was generated by `/usr/bin/rs_scope -d'. ⚠️ warning: Couldn't find general-purpose registers in core file. (gdb) ... The warning is emitted because the pseudo-section .reg is missing, because elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but instead we have: ... $ eu-readelf -n core | grep -i prstatus CORE 156 PRSTATUS CORE 156 PRSTATUS CORE 156 PRSTATUS CORE 156 PRSTATUS ... I'm assuming this is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of elf_prstatus out"). The core was generated using a kernel with CONFIG_BINFMT_ELF_FDPIC=y and v5.3.18. We can try to work around this bug in elf32_arm_nabi_grok_prstatus, but that's out of scope for this commit, which focuses on fixing the segfault. Tested on x86_64-linux. Approved-By: Andrew Burgess PR corefiles/33560 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560 [1] https://bugzilla.suse.com/show_bug.cgi?id=1251213 2025-11-21 Claudiu Zissulescu gprofng: Remove public hz and whoami variables Remove public hz and whoami variables. This fixes the errors when building with --enable-shared. 2025-11-21 Andrew Burgess gdb/testsuite: avoid pointer values in test names A test added in: commit 91eee81d23537366bb6072c66f662ab46d88380a Date: Tue Jan 21 17:22:04 2025 +0000 gdb: include NT_I386_TLS note in generated core files includes a pointer value in the test name. The value changes from run to run making it harder to compare test results. Fix this by giving the test an actual name. There's no change to what is being tested with the commit. 2025-11-21 Jan Beulich bfd/COFF: mark a function exposed to ld as non-private As a non-private function, _bfd_coff_read_internal_relocs() shouldn't have a "_bfd_" prefix, but merely a "bfd_" one. Tidy arguments passed whle at it. bfd/PEI: mark internal functions hidden This reduces the dynamic symbol table a bit (over a hundred symbols when building all targets) and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/XCOFF: mark internal data hidden This reduces the dynamic symbol table a bit (about a dozen symbols) and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ECOFF: mark internal functions hidden This reduces the dynamic symbol table a bit (about 30 symbols) and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/COFF: properly mark bfd_coff_{gc_sections,group_name}() as private Add an underscore prefix and make them hidden. bfd/COFF: mark internal functions hidden This reduces the dynamic symbol table a bit (about 50 symbols) and allows the compiler to be more aggressive about inlining (as it sees fit, of course). 2025-11-21 GDB Administrator Automatic date update in version.in 2025-11-20 Simon Marchi gdb/dwarf2: add dwarf2_get_symbol_read_needs selftest Add a test for the fix introduced by commit cc27559a20f4 ("Fix dwarf2 "assertion failed" on bra without skip dwarf expression op"). Change-Id: I3f18f1c5169a9851e9f87a18c71070486df6da5c Approved-By: Tom Tromey 2025-11-20 Andrew Burgess gdb: include NT_I386_TLS note in generated core files This commit extends GDB for x86/Linux to include the NT_I386_TLS note in generated core files (i.e. created with `generate-core-file` or `gcore` command). This note contains the 3 per-thread TLS related GDT (global descriptor table) entries, and is present for i386 binaries, or those compiled on x86-64 with -m32. The approach I have taken to achieve this, is to make the 3 GDT entries available within 3 new registers. I added these registers to the org.gnu.gdb.i386.linux target description feature, as this feature seemed perfectly named. As the new registers are optional I don't see any harm in extending this existing feature. I did consider adding a new feature with `tls` in the name, but this seemed excessive given the existing feature. Which GDT entries are used for TLS varies between i386 and x86-64 running in 32-bit mode. As such the registers are named with suffixes 0, 1, and 2, and it is left to GDB or gdbserver, to find the correct GDT entries (based on the precise target) and place the contents into these registers. With this done, adding the relevant regset is sufficient to get the tls contents emitted as a core file note. Support for emitting the note into the generated core file relies on some BFD changes which were made in an earlier commit: commit ea6ec00ff4520895735e4913cb90c933c7296f04 Date: Fri Jul 25 19:51:58 2025 +0100 bfd: support for NT_386_TLS notes The three new registers are readable and writable. Writing to one of the new registers will update the relevant kernel GDT entry. Each TLS GDT is represented by a 'struct user_desc' (see 'man 2 get_thread_area' for details), the first 4 bytes of each 'user_desc' is the 'entry_number' field, this is the index of the GDT within the kernel, and cannot be modified. Attempts to write to this region of the register will be ignored, but will not give an error. I did consider not including this part of the user_desc within the register value, but this becomes difficult when we consider remote targets, GDB would then need to figure out what these indexes were so that the core file note could be generated. Sure, we probably could figure the correct index values out, but I figure, why bother, we can just pass them through in the register and know for certain that we have the correct values. For testing, there's a new test that covers the basic functionality, including read/write access to the new registers, and checking that the NT_386_TLS note is added to the core file, and that the note contents can be read by GDB. I also manually tested opening a core file generated from an old GDB (so no NT_386_TLS notes) using a GDB with this patch. This works fine, the new tls registers are not created as the NT_GDB_TDESC note (the target description) doesn't include the new registers. Out of interest I also patched an old version of GDB to avoid creating the NT_GDB_TDESC, and created a core file. This core file contained neither the NT_386_TLS nor NT_GDB_TDESC. When opening this core file with a patched GDB, the new registers do show up, but their contents are given as , which is exactly what we'd expect, GDB builds a target description based on the architecture, the architecture says these registers should exist, but they are missing from the core file, hence, . I also tested using a patched GDB with an old version of gdbserver, the new registers don't show up as the old gdbserver doesn't send them in its target description. And a core file created using the gcore command in such a setup leaves no NT_386_TLS notes added, which is what we'd expect. And I also tested a new gdbserver running with an old version of GDB. As the new tls registers are now mentioned in the target description, then obviously, the old GDB does see the registers, and present them to the user, however GDB doesn't know how to use these registers to create a NT_386_TLS, so that note isn't added to any core files. Also, while a new GDB places the tls registers into the 'system' group, an old GDB doesn't do this, so the registers end up in the 'general' group by default. This means they show up within 'info registers' output. This isn't ideal, but there's not much that can be done about this. Overall, I feel the combinations of old and new tools has been tested, and the behaviours are what we'd want or expect. I'm tagging this commit with PR gdb/15591, even though this patch isn't directly related. That bug is for improving GDB's testing of TLS support in core files. The test in this commit does do some very simple reading of a TLS variable, but there's only two threads, and one TLS variable, so it's not extensive. Additionally, the test in this commit is x86 only, so this should not be considered a full resolution to that bug. But still, it's something. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15591 Reviewed-By: Eli Zaretskii Reviewed-By: Christina Schimpe Reviewed-By: Keith Seitz 2025-11-20 Tom Tromey Do not apply properties to arch-allocated types A user reported that gdb would crash when debugging a certain Fortran executable. The bug is that the DWARF reader may try to apply dynamic properties to an arch-allocated type. This came as a bit of a surprise, but the issue is that the function-type-allocation code could end up creating an arch-owned type, when the return type is arch-owned. This patch fixes the problem, and any other potential future problems, by arranging for all types created by the DWARF reader to be objfile-owned. A better long-term solution might be the fabled "type GC", where the arch/objfile distinction is finally removed. However, this is more difficult to implement. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32793 2025-11-20 Jaro Fietz Fix dwarf2 "assertion failed" on bra without skip dwarf expression op When interpreting dwarf expressions, the function dwarf2_get_symbol_read_needs walks over all instructions via the call graph by using a to-visit and a visited list. Upon reaching a bra operation, it pushes both the next op and the branch target into the to-visit list. If the branch-target can be reached linearly from the next op, the branch-target will be visited twice. At the top of the visit-loop, there is an assertion that a visited instruction must never be visited again. This assertion fails in the above case. For example a DIE with DW_AT_location: 30 31 28 0 0 9f (DW_OP_lit0; DW_OP_lit1; DW_OP_bra: 0; DW_OP_stack_value) will result in .././binutils-gdb/gdb/dwarf2/loc.c:1905: internal-error: dwarf2_get_symbol_read_needs: Assertion `visited_ops.find (op_ptr) == visited_ops.end ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Adding a skip operation which makes the branch-target not linearly accessible from the next op, makes the example work. For example a DIE with DW_AT_location: 32 31 28 3 0 2f 1 0 96 9f (DW_OP_lit2; DW_OP_lit1; DW_OP_bra: 3; DW_OP_skip: 1; DW_OP_nop; DW_OP_stack_value) produces the correct result $1 = 2. This patch replaces the failing assertion with a continue to properly skip an already visited dwarf expression op. This makes the first example work correctly and result in $1 = 0. Running the testsuite resulted in different results upon every run (arch-linux 6.17.7-arch1-1 x86_64). Comparing the results of 3 runs of the unmodified code with three runs containing the fix does not yield a significant difference: unmodified version: # of expected passes 126821, 126813, 126838 fix version: # of expected passes 126866, 126801, 126817 Approved-By: Tom Tromey 2025-11-20 Claudiu Zissulescu gprofng: Remove runstatedir from Makefile.in gprofng: Add gprofng gmon conversion command test gprofng: Add documentation on converting gmon files. 2025-11-20 Claudiu Zissulescu gprofng: New tool for converting gmon.out file to experiments This patch introduces the capability to convert a gmon.out file into a gprofng experiment. The gmon.out file format includes a histogram record, a call graph record, and basic block execution count records. A gprofng experiment folder consists of various files, of which four are particularly important: - log.xml: Contains the profile timer setup and defines the profile data structure fields. - map.xml: Contains the memory map information of the profiled executable. - profile: Holds the time profile information. - data.frameinfo: Records the stack trace at a specific sampling moment, with each trace linked to the time profile information stored in the profile file. This patch adds a new tool to gprofng that reads the gmon.out file and the profiled executable. With the executable, we can reconstruct information about the profiled symbols and the memory map layout. The gmon.out file provides details about the execution duration for each symbol, as well as data used to build the call graph. This new patch is a subcommand for the display command. New gmon subcommand options: --version print the version number and exit. -h/--help print usage information and exit. -o specify the name for (and path to) the experiment directory; the the default path is the current directory. -O the same as -o, but unlike the -o option, silently overwrite an existing experiment directory with the same name. The new tool can be executed using the command line: $ gprofng display gmon EXEC_FILE GMON_FILE N.B. If EXEC_FILE or GMON_FILE is missing the default a.out and gmon.out names are considered. Upon successful execution, an experiment file is created that can be processed with existing gprofng tools. For example: $ gprofng display text -calltree EXPERIMENT This command will display the call tree from the converted gmon file. 2025-11-20 Tom de Vries [contrib] Accept _("") and operator() in check_GNU_style_lib.py Currently contrib/check_GNU_style_lib.py warns about '_("foo")', expecting '_ ("foo")' instead: ... $ cat tmp.patch ... +const char * +foo (void) +{ + return _("foo"); +} $ ./contrib/check_GNU_style.py tmp.patch === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === test.c:4:10: return _("foo"); $ ... However '_("")' is an exception [1] to the rule, so skip the ERROR in this case. Likewise for 'operator()', which seems common enough: ... $ find gdb* -type f \ | egrep -v '/testsuite/|ChangeLog' \ | xargs grep "::operator()" \ | wc -l 27 ... for example in gdb/dwarf2/read.c: ... dwo_file_hash::operator() (const dwo_file_up &file) const noexcept ... [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Gettext_macro 2025-11-20 Tom de Vries [contrib] Fix typo in check_GNU_style_lib.py Fix typo: TrailinigOperatorCheck -> TrailingOperatorCheck. 2025-11-20 GDB Administrator Automatic date update in version.in 2025-11-19 Tom Tromey Remove section_offsets typedef This patch removes the section_offsets typedef, in favor of using either std::vector or gdb::array_view as appropriate. v2: preserve const-ness when creating views Regression tested on x86-64 Fedora 40. Approved-By: Simon Marchi 2025-11-19 Tom Tromey Return bool from block_starting_point_at This changes block_starting_point_at to return bool. 2025-11-19 Simon Marchi gdb/dwarf: use offset in dwarf_expr_context::read_mem The `offset` variable is the offset within the passed-in object where `addr` falls. We use it to verify whether `addr` falls within that object's bounds, but then the memcpy fails to consider it, meaning that we always copy from the beginning of the passed-in object, even if `addr` lands in the middle of the object. Fix that by adding `offset` to the source argument of the memcpy. I caught this by writing a patch later in this series, so this fix is covered by the test added in that later patch. Also, I find it a bit odd to compute the offset of `addr` within the passed-in object, before knowing if `addr` even lands within the passed-in object's address range. If `addr` is before the object's address, it does an unsigned underflow, which I guess works, but is not really intuitive. Change it to check whether `addr` falls within the object first, and if so, compute the offset of `addr` within the object. Change-Id: Ibbacab6d57e693e02e2bdfec4f3a7d42d9a1bd4b Approved-By: Tom Tromey 2025-11-19 Tom Tromey Make blockvector a little more self-contained This patch changes blockvector to be a little more self-contained. The idea here is that code outside of blockvector shouldn't really know how it operates. After this patch, this still doesn't fully happen -- a couple spots check the result of map() and make decisions based on that -- but this is a step toward making that happen. The longer term idea here is that this is needed to enable lazier CU expansion. Meanwhile, this patch seems like a simple cleanup. Relocation is now handled by the blockvector itself and the non-const map() method can be removed. There wasn't a great spot to move the section_offsets typedef. I chose defs.h. I've also updated the comment there as it has been out of date for a long time. I've also removed an obsolete comment from the symbol-relocation code. Regression tested on x86-64 Fedora 40. Approved-By: Simon Marchi 2025-11-19 Tom de Vries [gdb/build] Handle gdbsupport and gdbserver in gdb.pot Currently, when making gdb.pot: ... $ cd build/gdb $ make po/gdb.pot test -d po || mkdir po sh -e /data/vries/gdb/src/gdb/po/gdbtext /usr/bin/xgettext gdb . /data/vries/gdb/src/gdb $ ... only strings from build/gdb and gdb are added. Also add strings from gdbsupport and gdbserver. Update gdb/po/gdbtext to handle the .cc files in gdbsupport and gdbserver. Approved-By: Tom Tromey 2025-11-19 Andrew Burgess gdb: add more styling to cli/cli-cmds.c Adds more filename, line number, and address styling to cli/cli-cmds.c. Approved-By: Tom Tromey 2025-11-19 GDB Administrator Automatic date update in version.in 2025-11-18 GDB Administrator Automatic date update in version.in 2025-11-17 H.J. Lu gold: Treat symbols with version index 0 as unversioned Oracle Solaris 11.4 Linker and Libraries Guide: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/linkers-libraries/version-symbol-section.html defines VER_NDX_LOCAL to 0 with a comment, "Symbol has local scope". This leads to different interpretations by different linker implementations. However Solaris as well as ld and ld.so in glibc always treat symbols with version index 0 as unversioned symbols with global binding. As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=33577 in hindsight, VER_NDX_NONE might be a better name. Ali from Oracle is working on clarifying what version index 0 really means for unversioned symbols with global binding. In the meantime, update gold to treat symbols with version index 0 as unversioned with global binding. elfcpp/ PR gold/33577 * elfcpp.h (VER_NDX_LOCAL): Update comments. (VER_NDX_GLOBAL): Likewise. gold/ PR gold/33577 * dynobj.cc (Versions::symbol_section_contents): Set unversioned symbol version index to VER_NDX_LOCAL. * symtab.cc (Symbol_table::add_from_dynobj): Don't check VER_NDX_LOCAL. * testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr33577.sh. (check_DATA): Add ver_test_pr33577a.syms and ver_test_pr33577b.syms. (ver_test_pr33577a.syms): New rule. (ver_test_pr33577.so): Likewise. (ver_test_pr33577b.syms): Likewise. (ver_test_pr33577): Likewise. * testsuite/Makefile.in: Regenerated. * testsuite/ver_matching_test.sh: Updated to checking missing Base version. * testsuite/ver_test_14.sh (check_missing): New. Updated to check missing Base version. * testsuite/ver_test_pr33577.sh: New fille. * testsuite/ver_test_pr33577a.c: Likewise. * testsuite/ver_test_pr33577b.c: Likewise. 2025-11-17 Simon Marchi gdb/mips: fix lwp_info ptr -> ref Fix this: CXX mips-linux-nat.o /home/smarchi/src/binutils-gdb/gdb/mips-linux-nat.c: In function ‘int write_watchpoint_regs()’: /home/smarchi/src/binutils-gdb/gdb/mips-linux-nat.c:640:39: error: cannot convert ‘lwp_info’ to ‘const lwp_info*’ in initialization 640 | for (const lwp_info *lp : all_lwps ()) | ^ ... which is a fallout of e92df1d0eb6c ("gdb: make lwp_info_iterator yield references"). Change-Id: I3cfb9eb597bea6c6921219bbf28937784fd8ac55 2025-11-17 Simon Marchi gdb: revert std -> gdb unordered_map change in x86-nat.c This particular change in commit 965deba1208 ("gdb: use gdb::unordered_{set,map} at a few places") causes some regressions, for instance when running gdb.base/catch-fork-kill.exp: (gdb) PASS: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=exit: fork: continue to child fork continue^M Continuing.^M [Attaching after Thread 0x7ffff7e74740 (LWP 490949) fork to child process 490952]^M [New inferior 2 (process 490952)]^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".^M =================================================================^M ^[[1m^[[31m==490919==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c9bac051d88 at pc 0x55f46adc7583 bp 0x7ffc862a1e90 sp 0x7ffc862a1e80 Function x86_linux_nat_target::low_new_fork calls function x86_debug_reg_state twice in a row. The first one returns a reference to an x86_debug_reg_state object in the map. The second causes an insertion to be made, moving the first object, rendering the first reference invalid. Revert the change and add a comment indicating that the location of x86_debug_reg_state objects is important. Change-Id: I85789d7657bec658a01908117efa25611e660878 2025-11-17 Simon Marchi gdb/netbsd: fix fallout of thread_info ptr to ref change Fix: CXX netbsd-nat.o /home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c: In function 'void nbsd_resume(nbsd_nat_target*, ptid_t, int, gdb_signal)': /home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c:481:10: error: base operand of '->' has non-pointer type 'thread_info' 481 | if (tp->ptid.lwp () == ptid.lwp ()) | ^~ ... following the changes that made thread iterators yield references instead of points (e.g. 1ad8737b3c5 ("gdb: change inf_threads_iterator to yield references")). Change-Id: I6b96d1a81fbe8792e82e071c4871f0f212d2e49d 2025-11-17 Tom de Vries [gdb] Rewrite strings in producer_parsing_tests I noticed some odd-looking strings in producer_parsing_tests, like this one: ... static const char extern_f_14_0[] = "\ Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on \ Intel(R) 64, \ Version 14.0.1.074 Build 20130716"; ... Rewrite this in a more regular style: ... static const char extern_f_14_0[] = ("Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on" " Intel(R) 64, Version 14.0.1.074 Build 20130716"); ... Tested on x86_64-linux. Approved-By: Simon Marchi 2025-11-17 Tom de Vries [gdb] Rewrite producer_is_gcc and producer_is_clang Rewrite functions producer_is_gcc and producer_is_clang into an early-exit style. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-11-17 Tom de Vries [gdb] Use nullptr instead of NULL in producer.[ch] Replace the uses of NULL in gdb/producer.[ch] by nullptr. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-11-17 Tom de Vries [gdb] Fix producer_is_gas comment The comment for producer_is_gas in gdb/producer.h: ... /* Returns nonzero if the given PRODUCER string is GAS and sets the MAJOR and MINOR versions when not NULL. Returns zero if the given PRODUCER is NULL or it isn't GAS. */ bool producer_is_gas (const char *producer, int *major, int *minor); ... uses 'nonzero' and 'zero', while the return type is bool. Fix this by using 'true' and 'false' instead. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-11-17 Tom de Vries [gdb] Return bool in producer_is_gcc Function producer_is_gcc returns int, but the result is interpreted as zero or non-zero. Make it return bool instead. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-11-17 Simon Marchi gdb: use gdb::unordered_{set,map} at a few places Use the gdb:: set/map types instead of the std:: ones. I only changed places in files I can build on my dev machine. I needed to explicitly default the move constructor and assigment operator in proc_mem_file. I think this is ok, as nothing takes the address of a proc_mem_file, requiring it not to move. I also needed to do it for refcnt_fd, in solib-rocm.c. It's a bit odd to prevent moving / copying a refcnt_fd, as this struct doesn't directly hold a resource, but I think I get why it was done. Change-Id: If6f2d7ba3b1ae338eba38b0ab9f987400e661dff Approved-By: Tom Tromey 2025-11-17 Tom de Vries [gdb/i18n] Use c++ in po/gdbtext I came across a script gdb/po/gdbtext: ... $ ./po/gdbtext Usage: ./po/gdbtext ... ... When using it, I get: ... $ ./po/gdbtext xgettext gdb ../gdb ../gdbsupport/ ../gdbserver/ unittests/memory-map-selftests.c:30: warning: unterminated string literal unittests/memory-map-selftests.c:41: warning: unterminated string literal $ ... due to raw strings being used in unittests/memory-map-selftests.c. Fix this by updating the language used in ./po/gdbtext to C++. 2025-11-17 Tom de Vries [gdb] Fix '_ ("foo")' Our documented style [1] is to use '_("foo")', not '_ ("foo")'. Fix this in a few places. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Gettext_macro 2025-11-17 Tom de Vries [gdb/cli] Add missing _() for dump commands Fix a missing _() for help strings for the dump memory/value commands. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-11-17 Tom Tromey Do not crash on recursive pointer types In Ada, it's possible to create a recursive pointer type, or two mutually recursive pointer types. gdb will crash when reading the DWARF for these. These types aren't actually useful, and so are unlikely to appear in real code. Still, gdb shouldn't crash. This patch handles this case by noticing recursive pointer types and representing them as pointer-to-void. Approved-by: Kevin Buettner 2025-11-17 Ezra Sitorus gdb/doc: Document AArch64 FPMR support Add NEWS entry and document new feature in gdb.texinfo. Reviewed-By: Eli Zaretskii Approved-By: Luis Machado 2025-11-17 Ezra Sitorus gdb/aarch64: Tests for fpmr Add tests for FPMR support in gdb/gdbserver. These tests check availability of FPMR, reading/writing to FPMR, core file generation and preservation under sighandler frame unwinding. A run of the full gdb testsuite has been done on aarch64-none-linux-gnu without FPMR support. The gdb.arch tests were run on Shrinkwrap with FPMR support. Approved-By: Luis Machado 2025-11-17 Ezra Sitorus gdb/aarch64: core file support for FPMR Add support for FPMR dumps/reads for core files. Approved-By: Luis Machado 2025-11-17 Ezra Sitorus gdb/aarch64: signal frame support for fpmr Add support for FPMR in signal frames and restore contents of FPMR. Approved-By: Luis Machado 2025-11-17 Ezra Sitorus gdbserver/aarch64: Enable FPMR for AArch64 in gdbserver on Linux Add support for FPMR in gdbserver. Approved-By: Luis Machado 2025-11-17 Ezra Sitorus gdb/aarch64: Enable FPMR for AArch64 in gdb on Linux The Floating Point Mode Register controls the behaviours of FP8 instructions. This patch add FPMR to GDB if it is enabled on the target. Approved-By: Luis Machado 2025-11-17 Ezra Sitorus bfd/ELF: Core file support for AArch64 FPMR The Floating Point Mode Register is a new register which controls the behaviour of FP8 instructions. This is handled by the Linux kernel through a new NT_ARM_FPMR register set. This patch adds required code to support core file dumps with NT_ARM_FPMR in them. 2025-11-17 Jan Vrany gdb: simplify find_symbol_at_address This commit further simplifies find_symbol_at_address by moving the special handling in case of -readnow down to readnow_functions. Running all tests in gdb.rust with and without -readnow shown no regressions (tested on Debian, x86_64). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33555 Approved-By: Tom Tromey 2025-11-17 Jan Vrany gdb: change find_compunit_symtab_by_address to find_symbol_by_address This commit changes objfile::find_compunit_symtab_by_address and corresponding quick_symbol_functions::find_compunit_symtab_by_address to find_symbol_by_address return symbol. This will allow simplifying find_symbol_at_address (the only caller of find_compunit_symtab_by_address) by removing the special-case for -readnow and moving the logic down to readnow_functions. Approved-By: Tom Tromey 2025-11-17 Jan Vrany gdb: change search_symtab helper to be a method This commit changes search_symtab helper in find_symbol_at_address to be a method. Approved-By: Tom Tromey 2025-11-17 Markus Metzger gdb, gdbserver: fix read/write_ptid types In write_ptid(), a ptid's LWP member, which is declared long, is stored in an int local variable before printing, potentially truncating it. Fix it. In read_ptid(), both PID and LWP are read as ULONGEST and then cast to their respective type without checking for overflows. Fix it. In read_ptid(), an empty component is treated as zero. Diagnose that as an error, instead. Approved-By: Tom Tromey 2025-11-17 Markus Metzger gdb, remote: fix set_thread () in start_remote () remote_target::start_remote_1 () calls set_continue_thread (minus_one_ptid) with the intent to /* Let the stub know that we want it to return the thread. */ set_continue_thread (minus_one_ptid); I interpret it such that it expects a later get_current_thread () to return the thread selected by the target: /* We have thread information; select the thread the target says should be current. If we're reconnecting to a multi-threaded program, this will ideally be the thread that last reported an event before GDB disconnected. */ ptid_t curr_thread = get_current_thread (wait_status); This results in the packet sequence Hc-1, qC. Hc simply sets cont_thread: else if (cs.own_buf[1] == 'c') cs.cont_thread = thread_id; write_ok (cs.own_buf); and qC returns the general thread. This doesn't match. It also has some special treatment for null_ptid and minus_one_ptid: if (cs.general_thread != null_ptid && cs.general_thread != minus_one_ptid) ptid = cs.general_thread; else { init_thread_iter (); ptid = thread_iter->id; } Similarly, Hg has some special treatment for null_ptid: if (cs.own_buf[1] == 'g') { if (thread_id == null_ptid) { /* GDB is telling us to choose any thread. Check if the currently selected thread is still valid. If it is not, select the first available. */ thread_info *thread = find_thread_ptid (cs.general_thread); if (thread == NULL) thread = get_first_thread (); thread_id = thread->id; } cs.general_thread = thread_id; The comment at Hg matches the intent of GDB for sending Hc-1. Change the set_thread () call in remote_target::start_remote_1 () to set_general_thread (any_thread_ptid); This results in GDB sending Hg0 and gdbserver preserving the currently selected thread that is later returned in response to qC. CC: Thiago Jung Bauermann Approved-By: Tom Tromey 2025-11-17 Markus Metzger gdbserver, read_ptid: handle '0' and '-1' thread ids The special thread id '-1' means 'all threads'. The special thread id '0' means 'any thread'. Read_ptid () currently returns .-1.0 and .0.0 respectively. Change that to minus_one_ptid for '-1' and to null_ptid for '0'. CC: Thiago Jung Bauermann Approved-By: Tom Tromey 2025-11-17 Simon Marchi gdb: build solib-svr4-linux.o when building for targets xtensa*-*-*linux* When building a GDB configured with --target=xtensa-buildroot-linux-uclibc, we get: CXXLD gdb /usr/bin/ld: xtensa-linux-tdep.o: in function `xtensa_linux_init_abi(gdbarch_info, gdbarch*)': /home/simark/src/binutils-gdb/gdb/xtensa-linux-tdep.c:115:(.text+0x102): undefined reference to `make_linux_ilp32_svr4_solib_ops(program_space*)' Fix it by adding solib-svr4-linux.o to the list of objects build for targets xtensa*-*-*linux*. Change-Id: I0caa04a1d1c097defb5ea9c285cccc09ba80058d 2025-11-17 GDB Administrator Automatic date update in version.in 2025-11-16 John David Anglin hppa64: Fix handling of dynamic relocations This change fixes issues with dynamic relocations. We now support R_PARISC_FPTR64 relocations for local symbols for both LTOFF and simple FPTR64 relocations. Allocation of dynrel relocations is revised along the lines of ia64. OPDs are reduced in size to 16 bytes so .opd section is now identical to that generated by the HP linker. Small applications now link and run successfully on HP-UX but better stub support is needed for executables larger than roughly 8 MB. Many PCREL22F branches can't reach their target. This prevents building any recent version of gcc. 2025-11-16 John David Anglin bfd/ChangeLog: * elf64-hppa.c (OPD_ENTRY_SIZE): Change to 16 bytes. (elf64_hppa_check_relocs): Revise maybe_dynamic calculation. Revise R_PARISC_FPTR64 case to request dynrel when hh is not NULL. Add local symbols to local dynamic symbol table. Always add global symbols to dynamic symbol table when a dynrel may be needed. (allocate_global_data_opd): Update OPD entry allocation for reduced OPD size. (allocate_dynrel_entries): Rework along the lines of ia64. (elf64_hppa_late_size_sections): Revise DLT allocation. Revise OPD allocation. (elf64_hppa_finalize_opd): Revise for reduced OPD size. Remove unnecessary NULL check. (elf64_hppa_finalize_dlt): Remove unnecessary NULL check. (elf64_hppa_finalize_dynreloc): Rework along the lines of ia64. Correct relocation handling. (elf_hppa_final_link_relocate): Don't zero first two words of OPD. Update relocation handling to output EPLT and FPTR64 relocations for local symbols. 2025-11-16 GDB Administrator Automatic date update in version.in 2025-11-15 H.J. Lu ld-elfvers: Remove vers8.c commit c8a8d3bb27743c6894b7d5406a84e809965b9266 Author: Ian Lance Taylor AuthorDate: Thu Mar 13 02:46:09 1997 +0000 Commit: Ian Lance Taylor CommitDate: Thu Mar 13 02:46:09 1997 +0000 Wed Mar 12 21:44:19 1997 Eric Youngdale * ld-elfvers/vers.exp, *: New tests for symbol versioning. * config/default.exp: Set ar and strip. added an unused vers8.c. There is build_vers_lib_pic "vers8" vers1.c vers8 vers8.map "" vers8.ver vers1.dsym vers1.sym The differences are: 1. Version scripts: vers1.map: VERS_1.1 { local: hide_old*; hide_original*; hide_new*; }; VERS_1.2 { } VERS_1.1; VERS_2.0 { show_bar1; show_bar2; } VERS_1.2; vers8.map: VERSION { VERS_1.1 { local: hide_old*; hide_original*; hide_new*; }; VERS_1.2 { } VERS_1.1; VERS_2.0 { show_bar1; show_bar2; } VERS_1.2; } 2. Symbol version dump: vers1.ver: Version definitions: [1-4] 0x01 0x0c96425f vers1.so [1-4] 0x00 0x0a7927b1 VERS_1.1 [1-4] 0x00 0x0a7927b2 VERS_1.2 VERS_1.1 [1-4] 0x00 0x0a7922b0 VERS_2.0 VERS_1.2 vers8.ver: Version definitions: [1-4] 0x01 0x0c96b25f vers8.so [1-4] 0x00 0x0a7927b1 VERS_1.1 [1-4] 0x00 0x0a7927b2 VERS_1.2 VERS_1.1 [1-4] 0x00 0x0a7922b0 VERS_2.0 VERS_1.2 We can remove the unused vers8.c. PR ld/33631 * testsuite/ld-elfvers/vers8.c: Removed. 2025-11-15 H.J. Lu elf: Wire up PR ld/21086 test commit 3c5fce9bc29b216af7d10f8d6e4d8c3f11a48359 Author: H.J. Lu Date: Fri Apr 21 12:00:55 2017 -0700 Require --no-dynamic-linker with -static -E/--dynamic-list added pr21086.c and pr21086.list without wiring them up. Wire them up to verify that there is no dynamic section with -static -E/--dynamic-list. PR ld/21086 PR ld/33630 * testsuite/ld-elf/pr21086.rd: New file. * testsuite/ld-elf/shared.exp: Wire PR ld/21086 test. 2025-11-15 H.J. Lu shared.exp: Use pr14862.map to build libpr14862.so commit dda8ddc56f160befb8f8fc3ddc69d66cec6ac4f8 Author: H.J. Lu Date: Tue Nov 20 22:17:27 2012 +0000 Remove ref_dynamic_nonweak added by accident used pr11138-1.map to build libpr14862.so by accident and pr14862.map should be used instead. The difference is pr11138-1.map: VERS_1 { global: bar; foo; local: *; }; vs pr14862.map: VERS_1 { global: bar; local: *; }; Since only "bar" is used, it didn't cause test failure. Use pr14862.map to build libpr14862.so as intended. PR ld/14862 * ld-elf/shared.exp: Replace pr11138-1.map with pr14862.map when building libpr14862.so. 2025-11-15 GDB Administrator Automatic date update in version.in 2025-11-14 Maximilian Ciric MIPS/GAS: Select symbolic GPR and FPR names based on current ABI setting Add GPR and FPR symbolic register names to GAS for all ABI choices, selecting the set of names based on the ABI being assembled for. This extends the existing feature where the oldabi and newabi would provide different symbolic GPR names to the assembler. Both EABIs and o64 are now supported along with symbolic FPR names for all ABI choices. 2025-11-14 Simon Marchi gdb: add microblaze-linux.xml to XMLTOC, regenerate microblaze-linux.c microblaze-linux.c is out of date compared to the other .c files in the features directory. I think it's because it's missing from XMLTOC. Add it there and run the "cfiles" target, causing the updates to microblaze-linux.c. I thought that we could get rid of regformats/microblaze-linux.dat, since microblaze-linux is described with an XML target, but apparently not, I don't really understand (or forget) how these things work. Change-Id: Idaa55980b3bbdcc6597e9bf332d5824759ef9d0f Approved-By: Tom Tromey 2025-11-14 Simon Marchi gdbserver: adjust init_target_desc call in tic6x_read_description I spotted this call missing an argument. For context, init_target_desc gained this osabi parameter in this commit: Author: Andrew Burgess AuthorDate: Fri Oct 4 19:30:04 2024 +0100 Commit: Andrew Burgess CommitDate: Tue Nov 12 12:51:36 2024 +0000 gdbserver: pass osabi to GDB in more target descriptions This bug was present in GDB 16. I wonder if anybody uses this today. Change-Id: Id5483be3efa0ca9d238d59af8abae94e8bdbd57c Approved-By: Tom Tromey 2025-11-14 Simon Marchi gdb: remove tic6x .dat files The tix6x gdbserver port was modified to use target descriptions in commit 506fe5f49967 ("Change tic6x target descriptions"). The old regformats .dat files were kept as a way to make sure the new target descriptions matched the old register decsriptions. I think by now it's not necessary to keep the .dat files. I don't have a way to build-test this though. Change-Id: Ia90b5ae6381234c6e95555201d3e65ed9be880ea Approved-By: Tom Tromey 2025-11-14 Simon Marchi gdb, gdbsupport: use DISABLE_COPY_AND_ASSIGN in a few spots Replace some explicitly deleted copy constructor and copy assignment operator with the DISABLE_COPY_AND_ASSIGN macro for consistency with the rest of the codebase. Change-Id: If3fe2c4d7b3cb4530eace86d589116f805c7656f Approved-By: Tom Tromey 2025-11-14 Tom Tromey Reject negative children in DAP This changes DAP to ignore the case where a pretty-printer returns a negative number from the num_children method. It didn't seem worth writing a test case for this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33594 Reviewed-By: Ciaran Woodward 2025-11-14 Tom Tromey Have DAP handle multiple breakpoints at same location A user pointed out that if multiple breakpoints are set at the same spot, in DAP mode, then changing the breakpoints won't reset all of them. The problem here is that the breakpoint map only stores a single breakpoint, so if two breakpoints have the same key, only one will be stored. Then, when breakpoints are changed, the "missing" breakpoint will not be deleted. The fix is to change the map to store a list of breakpoints. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33467 Reviewed-By: Ciaran Woodward 2025-11-14 Tom Tromey Rename variable in DAP breakpoint.py This renames the variable 'breakpoint_map' in DAP's breakpoint.py, adding an underscore to make it clear that it is private to the module. Reviewed-By: Ciaran Woodward 2025-11-14 Tom Tromey Mark Pascal as case-insensitive The Pascal language is not case-sensitive, so implement the appropriate language method. This fixes gdb.pascal failures with -gw3. I wasn't sure if -gw3 should be the default so I've left it as-is. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33617 Approved-By: Tom de Vries 2025-11-14 Tom de Vries [gdb/testsuite] Fix gdb.rust/methods.exp on i686-linux On i686-linux, with test-case gdb.rust/methods.exp I get: ... (gdb) print x.take() $5 = methods::HasMethods {value: 4} (gdb) FAIL: $exp: print x.take() ... The instructions for the function methods::HasMethods::take look like this: ... 00007b90 <_ZN7methods10HasMethods4take17hf373500ea3bd6e27E>: 7b90: 8b 44 24 04 mov 0x4(%esp),%eax 7b94: c3 ret ... which is equivalent to what you get for: ... $ cat test.c int foo (int val) { return val; } $ gcc test.c -O2 -S -o- ... movl 4(%esp), %eax ret ... $ ... The inferior call mechanism however decides that this is a return_method_struct function, and adds an implicit first parameter pointing to the return value location. Then two things go wrong: - the argument is written to a place where the code doesn't read from, and - the return value is read from a place where the code doesn't write to. AFAIU, both gdb and rustc are behaving correctly: - there's no stable ABI and consequently rustc is at liberty to optimize this function how it wants, and - gdb cannot be expected to target an unstable ABI. The solution is to mark the function for interoperability using 'extern "C"'. Doing so causes a compilation warning: ... warning: `extern` fn uses type `HasMethods`, which is not FFI-safe --> gdb.rust/methods.rs:50:28 | 50 | pub extern "C" fn take(self) -> HasMethods { | ^^^^ not FFI-safe | = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout ... which we fix by using '#[repr(C)]'. Likewise in gdb.rust/generics.exp. Tested on i686-linux and x86_64-linux. Approved-By: Tom Tromey 2025-11-14 Jens Remus s390: Mention GOTIE20 relocation in TLS related comment Commit bd1ea41b84b0 introduced the R_390_TLS_GOTIE20 relocation, but missed to update a comment that mentions the related R_390_TLS_GOTIE12 relocation. bfd/ * elf32-s390.c (allocate_dynrelocs): Mention GOTIE20 relocation in TLS related comment. * elf64-s390.c (allocate_dynrelocs): Likewise. 2025-11-14 Jens Remus s390: Do not emit orphaned GOT entry for TLS IE to LE transition Commit 69fc87f180bf introduced TLS support for s390 32-bit and 64-bit. It defined GOT_TLS_IE_NLT in both elf32-s390.c and elf64-s390.c, but erroneously assigned it the same value as GOT_TLS_IE in elf64-s390.c. As a consequence the linker for s390 64-bit erroneously emitted an orphaned GOT entry when performing TLS Initial Exec (IE) to Local Exec (LE) transition optimization. Correct the value of GOT_TLS_IE_NLT in elf64-s390.c. This causes the liker to actually optimize away the GOT entry when performing IE to LE transition. While at it add a comment that the suffix NLT denotes "no literal (pool entry)". Found while inspecting and cleaning up differences between elf32-s390.c and elf64-s390.c. bfd/ * elf32-s390.c (GOT_TLS_IE_NLT): Add comment that NLT denotes no literal pool entry. * elf64-s390.c (GOT_TLS_IE_NLT): Likewise. Correct value. ld/testsuite/ * ld-s390/tlsbin_64.dd: Adjust expected test results. * ld-s390/tlsbin_64.sd: Likewise. Fixes: 69fc87f180bf 2025-11-14 Jens Remus s390: Check sreldynrelro in elf_s390_finish_dynamic_symbol Add check for sreldynrelro being NULL, introduced by commit 5474d94f03ae ("dynrelro section for read-only dynamic symbols copied into executable") in elf32-s390.c function elf_s390_finish_dynamic_symbol, also to its elf64-s390.c counterpart. Found while inspecting and cleaning up differences between elf32-s390.c and elf64-s390.c. bfd/ * elf64-s390.c (elf_s390_finish_dynamic_symbol): Add sreldynrelro check from elf32-s390.c. Fixes: 5474d94f03ae ("dynrelro section for read-only dynamic symbols copied into executable") 2025-11-14 Jens Remus s390: Increment PC-relative relocation count for PC24DBL relocs Commit fb798c50b2c8 added the R_390_PC24DBL relocation. Due to a copy and paste error it messed up to increment the PC-relative relocation count in elf64-s390.c function elf_s390_check_relocs (i.e. duplicate check for R_390_PC16DBL). Found while inspecting and cleaning up differences between elf32-s390.c and elf64-s390.c. bfd/ * elf64-s390.c (elf_s390_check_relocs): Increment PC-relative relocation count for R_390_PC24DBL. Fixes: fb798c50b2c8 2025-11-14 Jan Beulich bfd/ELF: properly mark bfd_elf_{,gc_common_}final_link() as private They're solely used as hook functions (or helpers thereof), so aren't intended to be invoked directly from outside the library. Add underscore prefixes and make them hidden. bfd/ELF: nds32_convert_{16_to_32,32_to_16}() are exposed to gas As non-private functions, they should come with full disambiguating prefixes - add bfd_elf_ to both. Hence commit bf4128d0cc6d2 ("bfd/ELF: mark internal NDS32 functions hidden") also wrongly added ATTRIBUTE_HIDDEN to them. 2025-11-14 Jan Beulich bfd/ELF: loongarch_{larch_reloc_name_lookup,adjust_reloc_bitsfield}() are exposed to gas As non-private functions, they should come with full disambiguating prefixes - add bfd_elf_ to both. Hence commit 2903d813fcc2 ("bfd/ELF: mark internal LoongArch functions hidden") also wrongly added ATTRIBUTE_HIDDEN to them. While loongarch_get_uleb128_length() also falls in the same category, having it live in libbfd, when outside of gas there's hardly any use to be expected, isn't very useful. Drop the function altogether and simplify the clearing of the ULEB128 in md_apply_fix(). For loongarch_larch_reloc_name_lookup() drop gas'es custom declaration; the libbfd one ought to be used, for producer and consumer to "see" the same one. Also drop ATTRIBUTE_UNUSED there, as that makes sense only for parameters in function definitions. 2025-11-14 Alan Modra objcopy binary symbol type check This exposes an error on alpha-linux-gnuecoff where the start and end syms are given the wrong storage class. * testsuite/binutils-all/objcopy.exp (binary_symbol): Tighten symbol type checking. 2025-11-14 GDB Administrator Automatic date update in version.in 2025-11-13 Abhay Kandpal PowerPC: Add support for RFC02660 - Context Switch Instruction opcodes/ * ppc-opc.c: (powerpc_opcodes): Add mtlpl. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise. 2025-11-13 Abhay Kandpal PowerPC: Support for Controlled Cluster Memory (RFC02689) opcodes/ * ppc-opc.c (powerpc_opcodes): Add ccmclean, ccmrl. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise. 2025-11-13 Simon Marchi pre-commit: bump black to 25.11.0 Ran `pre-commit autoupdate`. No changes in formatting. Change-Id: I6d779433e50efff858ac407917047b902f821503 2025-11-13 Simon Marchi gdb: fix flake8 warnings in gdb.base/gdb-index-many-types.py Fix those: gdb/testsuite/gdb.base/gdb-index-many-types.py:17:18: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:26:42: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:29:16: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:31:19: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:33:16: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:33:51: F821 undefined name 'gdb' gdb/testsuite/gdb.base/gdb-index-many-types.py:47:17: E722 do not use bare 'except' Change-Id: Iba1949a211af66e8dd1e6cb77a44845e5fa60c2e 2025-11-13 Andrew Burgess gdb: remove attempted type de-duplication when building gdb-index This commit removes the attempted de-duplication of types when building the gdb-index. This commit is the natural extension of this earlier commit: commit aef36dee93bf194cb0b976a4ae49a79a736a188d Date: Sun Aug 13 14:08:06 2023 +0200 [gdb/symtab] Don't deduplicate variables in gdb-index Which removed the de-duplication of variables. It is worth reading the earlier commit as all the justifications for that patch also apply to this one. Currently, when building the gdb-index we sort the type entries, moving declarations to the end of the entry list, and non-declarations to the front. Then within each group, declarations, and non-declarations, the index entries are sorted by CU offset. We then emit the first entry for any given type name. There are two problems with this. First, a non-declaration entry could be a definition, but it could also be a typedef. Now sure, a typedef is a type definition, but not necessarily a useful one. If we have a header file that contains: typedef struct foo_t foo_t; And a CU which makes use of 'foo_t', then the CU will include both a typedef and a type declaration. The target of the typedef will be the declaration. But notice, the CU will not include a type definition. If we have two CUs, one which only sees the above typedef and declaration, and another which sees the typedef and an actual type definition, then the final list of entries for this type's name will be: 1. A typedef entry that points at the declaration. 2. A typedef entry that points at the definition. 3. A definition. 4. A declaration. Now (4) will get sorted to the end of the entry list. But the order of (1), (2), and (3) will depend on the CU offset. If the CU which containing the typedef and declaration has the smallest offset, then (1) will be sorted to the front of the list of entries for this type name. Due to the de-duplication code this means that only (1) will be added to the gdb-index. After GDB starts and parses the index, if a user references 'foo_t' GDB will look in the index and find just (1). GDB loads the CU containing (1) and finds both the typedef and the declaration. But GDB does not find the full type definition. As a result GDB will display 'foo_t' as an incomplete type. This differs from the behaviour when no index is used. With no index GDB expands the first CU containing 'foo_t', finds the typedef and type declaration, decides that this is not good enough and carries on. GDB will then expand the second CU and find the type's definition, GDB now has a full understanding of the type, and can print the type correctly. We could solve this problem by marking typedefs as a distinct sub-category of types, just as we do with declarations. Then we could sort definitions to the front of the list, then typedefs, and finally, declarations after that. This would, I think, mean that we always prefer emitting a definition for a type, which would resolve this first problem, or at least, it would resolve it well enough, but it wouldn't fix the second problem. The second problem is that the Python API and the 'info types' command can be used to query all type symbols. As such, GDB needs to be able to find all the CUs which contain a given type. Especially as it is possible that a type might be defined differently within different CUs. NOTE: Obviously a program doing this (defining a type differently in different CUs) would need to be mindful of the One Definition Rule, but so long as the type doesn't escape outside of a single CU then reusing a type name isn't, as I understand it, wrong. And even if it is, the fact that it compiles, and could be a source of bugs, means (in my opinion) that GDB should handle this case to enable debugging of it. Even something as simple as 'info types ....' relies on GDB being able to find multiple entries for a given type in different CUs. If the index only contains a single type entry, then this means GDB will see different things depending on which CUs happen to have been expanded. Given all of the above, I think that any attempt to remove type entries from the gdb-index is unsafe and can result in GDB behaving differently when using the gdb-index compared to using no index. The solution is to remove the de-duplication code, which is what this patch does. Now that we no longer need to sort declarations to the end of the entry list, I've removed all the code related to the special use of GDB_INDEX_SYMBOL_KIND_UNUSED5 (which is how we marked declarations), this cleans things up a little bit. I've also renamed some of the functions away from minimize, now that there's no minimization being done. A problem was revealed by this change. When running the test gdb.cp/stub-array-size.exp with the --target_board=cc-with-gdb-index, I was seeing a failure using gcc 15.1.0. This test has two CUs, and a type 'A'. The test description says: Test size of arrays of stubbed types (structures where the full definition is not immediately available). Which I don't really understand given the test's source code. The type 'A' is defined in a header, which is included in both CUs. However, the test description does seem to be accurate; in one CU the type looks like this: <1><4a>: Abbrev Number: 8 (DW_TAG_structure_type) <4b> DW_AT_name : A <4d> DW_AT_declaration : 1 <4d> DW_AT_sibling : <0x6d> <2><51>: Abbrev Number: 9 (DW_TAG_subprogram) <52> DW_AT_external : 1 <52> DW_AT_name : ~A <55> DW_AT_decl_file : 2 <56> DW_AT_decl_line : 20 <57> DW_AT_decl_column : 11 <58> DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev <5c> DW_AT_virtuality : 1 (virtual) <5d> DW_AT_containing_type: <0x4a> <61> DW_AT_declaration : 1 <61> DW_AT_object_pointer: <0x66> <65> DW_AT_inline : 0 (not inlined) <3><66>: Abbrev Number: 10 (DW_TAG_formal_parameter) <67> DW_AT_type : <0x8c> <6b> DW_AT_artificial : 1 <3><6b>: Abbrev Number: 0 <2><6c>: Abbrev Number: 0 while in the second CU, the type looks like this: <1><178>: Abbrev Number: 4 (DW_TAG_structure_type) <179> DW_AT_name : A <17b> DW_AT_byte_size : 8 <17c> DW_AT_decl_file : 2 <17d> DW_AT_decl_line : 18 <17e> DW_AT_decl_column : 8 <17f> DW_AT_containing_type: <0x178> <183> DW_AT_sibling : <0x1ac> <2><187>: Abbrev Number: 5 (DW_TAG_member) <188> DW_AT_name : (indirect string, offset: 0x19e): _vptr.A <18c> DW_AT_type : <0x1be> <190> DW_AT_data_member_location: 0 <191> DW_AT_artificial : 1 <2><191>: Abbrev Number: 6 (DW_TAG_subprogram) <192> DW_AT_external : 1 <192> DW_AT_name : ~A <195> DW_AT_decl_file : 1 <196> DW_AT_decl_line : 20 <197> DW_AT_decl_column : 1 <198> DW_AT_linkage_name: (indirect string, offset: 0x103): _ZN1AD4Ev <19c> DW_AT_virtuality : 1 (virtual) <19d> DW_AT_containing_type: <0x178> <1a1> DW_AT_declaration : 1 <1a1> DW_AT_object_pointer: <0x1a5> <3><1a5>: Abbrev Number: 7 (DW_TAG_formal_parameter) <1a6> DW_AT_type : <0x1cd> <1aa> DW_AT_artificial : 1 <3><1aa>: Abbrev Number: 0 <2><1ab>: Abbrev Number: 0 So, for reasons that I don't understand, the type, despite (as far as I can see) having its full definition available, is recorded only as declared in one CU. The test then performs some actions that rely on 'sizeof(A)' and expects GDB to correctly figure out the size. This requires GDB to find, and expand the CU containing the real definition of 'A'. Prior to this patch GDB would sort the two type entries for 'A', placing the declaration second, and then record only one entry, the definition. When it came to expansion there was only one thing to expand, and this is the declaration we needed. It happens that in this test the definition is in the second CU, that is, the CU with the biggest offset. This means that, if all index entries were considered equal, the definition entry would be second. However, currently, due to the way GDB forces definitions to the front, the entry for the second CU, the definition, is placed first in the index, and with de-duplication, this is the only entry added to the index. After this patch, both the declaration and the definition are placed in the index, and as the declaration is in the CU at offset 0, the declaration is added first to the index. This should be fine. When looking for 'A' GDB should expand the CU containing the declaration, see that all we have is a declaration, and so continue, next expanding the definition, at which point we're done. However, in read-gdb-index.c, in the function mapped_gdb_index::build_name_components, there is a work around for gold bug PR gold/15646. Ironically, the bug here is that gold was not removing duplicate index entries, and it is noted that this has a performance impact on GDB. A work around for this was added to GDB in commit: commit 8943b874760d9cf35b71890a70af9866e4fab2a6 Date: Tue Nov 12 09:43:17 2013 -0800 Work around gold/15646. A test for this was added in: commit 40d22035a7fc239ac1e944b75a2e3ee9029d1b76 Date: Tue May 26 11:35:32 2020 +0200 [gdb/testsuite] Add test-case gold-gdb-index.exp And the fix was tweaked in commit: commit f030440daa989ae3dadc1fa4342cfa16d690db3c Date: Thu May 28 17:26:22 2020 +0200 [gdb/symtab] Make gold index workaround more precise The problem specifically called out in the bug report is that namespaces can appear in multiple CUs, and that trying to complete 'ns::misspelled' would expand every CU containing namespace 'ns' due to the duplicate 'ns' type symbols. The work around that was added in 8943b874760d9cf3 was to ignore duplicate global symbols when expanding entries from the index. In commit f030440daa989ae3 this work around was restricted to only ignore duplicate type entries. This restriction was required to allow the earlier de-duplication patch aef36dee93bf194c to function correctly. Now that I'm taking the work started in aef36dee93bf194c to its logical conclusion, and allowing duplicate type entries, the work around of ignoring duplicate global type symbols is no longer needed, and can be removed. The associated test for this, added in 40d22035a7fc239a, is also removed in this commit. To be clear; the performance issue mentioned in PR gold/15646 is now back again. But my claim is that gold was right all along to include the duplicate index entries, and any performance hit we see as a result, though unfortunate, is just a consequence of doing it right. That doesn't mean there's not room for optimisation and improvement in the future, though I don't have any immediate ideas, or plans in this area. It's just we can't throw out a bunch of index entries that are critical, and claim this as a performance optimisation. I am seeing some failure with this patch when using the board file dwarf5-fission-debug-types. These failures all have the error: DWARF Error: wrong unit_type in unit header (is DW_UT_skeleton, should be DW_UT_type) [in module ....] However, I ran the whole testsuite with this board, and this error crops up often, so I don't think this is something specific to my patch, so I'm choosing to ignore this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15646 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15035 Approved-By: Tom Tromey 2025-11-13 Andrew Burgess gdb: symbol_search objects of different types are not the same Consider the C construct: typedef struct foo { int a; int b; } foo; GDB will see two types here, 'struct foo' and the typedef 'foo'. However, if we use 'info types foo' we will see this: File test.c: 18: struct foo; At least that's what I see with current HEAD of master. However, it is really just luck that we see the 'struct' here. See more below. When searching for symbols matching 'foo' GDB ends up in the function global_symbol_searcher::add_matching_symbols, where we consider all possible matching symbols. This will include the 'struct foo' and the typedef 'foo'. However, before a new symbols is added to the results, we attempt to remove duplicates with this code: /* Match, insert if not already in the results. */ symbol_search ss (block, sym); if (result_set->find (ss) == result_set->end ()) result_set->insert (ss); If a symbol is already present in result_set then it will not be added a second time. The symbol_search equality check is done using the function symbol_search::compare_search_syms, this function does a number of checks, but at the end, any two symbols that are in the same block within the same file, with the same name, are considered the same, even if the types of those symbols are different. This makes sense in most cases, it usually wouldn't make sense to have two symbols within a single block with different types. But the 'struct foo' and typedef 'foo' case is a bit of a strange one. Within DWARF and GDB we consider both of these as just types. But in C types and structure names live in different namespaces, and so we can have both in the same block. I don't think that GDB should consider these two as the same, especially if we consider something really ill-advised like this: struct foo { int a; int b; }; typedef int foo; This is perfectly valid C code, 'struct foo' and the typedef 'foo' are in different namespaces, and can be used within the same block. But please, never write C code like this. Given the above, I think, when asked about 'foo', GDB should, report both 'struct foo' and the typedef 'foo'. To do this I propose extending symbol_search::compare_search_syms such that if two symbol_search objects are in the same block, within the same file, and they have the same name, then if just one of them is a typedef, the two objects will not be considered equal. The results will be sorted by line number if the line numbers are different, or, if the line numbers are the same, the non-typedef will be sorted first. This means that for something like this: typedef struct foo { int a; } foo; We'll get an 'info types foo' result like: File test.c: 18: struct foo; 18: typedef struct foo foo; I mentioned earlier that it is really just luck that we see 'struct foo'. I ran into this problem while working on another patch. When testing with the 'debug-types' board file I was seeing the typedef being reported rather than the struct. In "normal" DWARF given the 'typedef struct foo { ...} foo;' construct, the compiler will usually emit the struct definition first, and then the typedef definition. So when GDB parses the DWARF it sees the struct first. It is the typedef that becomes the duplicate which is not added to the results list. But with the 'debug-types' board the compiler moves the struct definition out to the .debug_types section. And GDB now parses the CU containing the typedef first, and then expands the structure definition from the separate section afterwards. As a result, it is the structure that is now considered the duplicate, and the typedef is the result that gets reported. I think this is yet another motivation for this patch. Changes like this (the use of .debug_types section) shouldn't impact what results GDB shows to the user. There is an interesting update to the gdb.base/info-types.exp.tcl test script. In this case the C results only needed to change to include the typedef. The C++ results already included both the struct and the typedef in the expected results. The reason for this is that C places both the struct baz_t and the typedef for baz_t into the global block, while C++ places the struct in the global block, and the typedef into the static block. I have no idea why there's a difference in the placement, but I'm choosing to believe the difference is correct. But this explains why only the C results needed to change. If anything this (I think) is yet another justification for this change; having C not show the typedef in this case seems weird when the same source code compiled as C++ does show the typedef. Approved-By: Tom Tromey 2025-11-13 GDB Administrator Automatic date update in version.in 2025-11-12 Tom de Vries [gdb/testsuite] Fix typo IBM'x -> IBM's some more Fix typo in lib/compiler.cc: IBM'x -> IBM's. [gdb/testsuite] Fix typo IBM'x -> IBM's Fix typo in gdb.base/nodebug.exp and lib/compiler.c: IBM'x -> IBM's. 2025-11-12 Tom de Vries [gdb/testsuite] Use -std=c99 in gdb.base/nodebug.exp With test-case gdb.base/nodebug.exp I run into: ... gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto': gdb.base/nodebug.c:63:1: warning: old-style function definition \ [-Wold-style-definition] 63 | multf_noproto (v1, v2) | ^~~~~~~~~~~~~ ... Fix this using -std=c99. Tested on x86_64-linux. PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 2025-11-12 GDB Administrator Automatic date update in version.in 2025-11-11 Tom Tromey Allow Python to create const+volatile types A user pointed out that the Python API can't create a type that is both const and volatile. The bug is that the calls to make_cv_type did not preserve the "other" flag. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33585 Reviewed-By: Tankut Baris Aktemur 2025-11-11 Tom de Vries [gdb/rust] Fix handling of unsigned discriminant On i686-linux, with test-case gdb.rust/simple.exp, we get: ... (gdb) print str_none^M $71 = core::option::Option::Some(alloc::string::String {vec: alloc::vec::Vec {buf: alloc::raw_vec::RawVec {inner: alloc::raw_vec::RawVecInner {ptr: core::ptr::unique::Unique {pointer: core::ptr::non_null::NonNull {pointer: 0xbfffe6e8}, _marker: core::marker::PhantomData}, cap: core::num::niche_types::UsizeNoHighBit (2147483648), alloc: alloc::alloc::Global}, _marker: core::marker::PhantomData}, len: 4321411}})^M (gdb) FAIL: $exp: print str_none ... while this is expected: ... (gdb) print str_none^M $71 = core::option::Option::None^M (gdb) PASS: $exp: print str_none ... Printing the variable in C mode: ... $ gdb -q -batch outputs/gdb.rust/simple/simple \ -ex "b 161" \ -ex run \ -ex "set language c" \ -ex "p /x str_none" ... $1 = {0x80000000, Some = {__0 = {vec = {buf = {inner = {ptr = {pointer = {pointer = 0xbfffedd8}, _marker = {}}, cap = {__0 = 0x80000000}, alloc = {}}, _marker = {}}, len = 0x41f083}}}} ... shows us that the discriminant value is 0x80000000, which matches the "None" variant: ... <3><1427>: Abbrev Number: 16 (DW_TAG_structure_type) <1428> DW_AT_name : Option <142c> DW_AT_byte_size : 12 <142d> DW_AT_accessibility: 1 (public) <142e> DW_AT_alignment : 4 <4><142f>: Abbrev Number: 47 (DW_TAG_variant_part) <1430> DW_AT_discr : <0x1434> <5><1434>: Abbrev Number: 48 (DW_TAG_member) <1435> DW_AT_type : <0x2cba> <1439> DW_AT_alignment : 4 <143a> DW_AT_data_member_location: 0 <143b> DW_AT_artificial : 1 <5><143b>: Abbrev Number: 52 (DW_TAG_variant) <143c> DW_AT_discr_value : 0x80000000 <6><1440>: Abbrev Number: 4 (DW_TAG_member) <1441> DW_AT_name : None <1445> DW_AT_type : <0x145a> <1449> DW_AT_alignment : 4 <144a> DW_AT_data_member_location: 0 <6><144b>: Abbrev Number: 0 <5><144c>: Abbrev Number: 51 (DW_TAG_variant) <6><144d>: Abbrev Number: 4 (DW_TAG_member) <144e> DW_AT_name : Some <1452> DW_AT_type : <0x146c> <1456> DW_AT_alignment : 4 <1457> DW_AT_data_member_location: 0 <6><1458>: Abbrev Number: 0 <5><1459>: Abbrev Number: 0 ... but the dynamic type resolves to the "Some" variant instead. This is caused by signedness confusion. The DW_AT_discr_value 0x80000000 is encoded as an LEB128 number, and the signedness is determined by the "tag type for the variant part", which in this case is unsigned: ... <1><2cba>: Abbrev Number: 6 (DW_TAG_base_type) <2cbb> DW_AT_name : u32 <2cbf> DW_AT_encoding : 7 (unsigned) <2cc0> DW_AT_byte_size : 4 ... However, the value gets interpreted as signed instead (value printed in resolve_dynamic_struct): ... (gdb) p /x variant_prop.m_data.variant_parts.m_array.variants.m_array[0].discriminants.m_array[0] $3 = {low = 0xffffffff80000000, high = 0xffffffff80000000} ... and then compared against an unsigned 0x80000000 in variant::matches(). Fix this in create_one_variant_part, by passing the required signedness as a parameter to create_one_variant. Tested on i686-linux and x86_64-linux. Approved-By: Tom Tromey PR rust/33620 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33620 2025-11-11 Tom de Vries [gdb/testsuite] Fix sizeof test in gdb.rust/simple.exp On x86_64-linux, with test-case gdb.rust/simple.exp I get: ... (gdb) print sizeof(e)^M $52 = 24^M (gdb) PASS: $exp: print sizeof(e) ... but on i686-linux I get instead: ... (gdb) print sizeof(e)^M $52 = 20^M (gdb) FAIL: $exp: print sizeof(e) ... The variable e for which we print the size: ... let e = MoreComplicated::Two(73); ... has type MoreComplicated which is defined like this: ... pub struct HiBob { pub field1: i32, field2: u64, } ... enum MoreComplicated { One, Two(i32), Three(HiBob), Four{this: bool, is: u8, a: char, struct_: u64, variant: u32}, } ... The answer to the question what the size of the enum should be seems to be non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can differ between different platforms. Fix this by accepting both 20 and 24 as valid size. Tested on x86_64-linux and i686-linux. Approved-By: Tom Tromey [1] https://doc.rust-lang.org/reference/types/enum.html [2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation 2025-11-11 Andrew Burgess gdb: use current executable for 'remote exec-file' in some cases This commit allows GDB to make use of the file set with the 'file' command when starting a new inferior on an extended-remote target. There are however some restrictions. If the user has used 'set remote exec-file', then this setting is always used in preference to the file set with the 'file' command. Similarly, if the qExecAndArgs packet has succeeded, and GDB knows that the remote target has an executable set, then this will be used in preference to the file set with the 'file' command; this preserves GDB's existing behaviour. In effect, when GDB connects to the remote target, the remote sets the 'remote exec-file' and this prevents GDB from using the 'file' filename. And, GDB can only use the file set with the 'file' command if it believes that both GDB and the remote target will both be able to access this file. This means that one of these is true: + the the remote_target::filesystem_is_local function returns true (see the implementation of that function for details of when this can happen). This means GDB and the remote target can see the same file system, GDB can just use the current executable's filename as is, or + the user has set the 'file' to something with a 'target:' prefix, e.g. 'file target:/path/to/exec'. In this last case, GDB will use the exec filename without the 'target:' prefix, this filename is, by definition, something the remote target can see, or + the sysroot has been updated by the user and no longer contains a 'target:' prefix. In this case, if the 'file' filename is within the sysroot, then it is assumed the remote will also be able to see a file with the same filename. For example, if the sysroot is '/aa/', and the current executable is '/aa/bb/cc', then GDB will tell the remote to run '/bb/cc'. One common case here is when the sysroot is set to the empty string, which is usually done when GDB and the remote target can see the same filesystem, in this case GDB will use the current executable's filename unmodified. If one of these conditions is met, then GDB will use the current executable's filename (with possible modifications as mentioned above), when starting a new extended-remote inferior, in all other cases, GDB will use the file name set with 'set remote exec-file'. This change could be useful any time a user is running a remote target on the same machine as GDB, but I am specifically thinking of the case where GDB is using a tool other than gdbserver, e.g. valgrind, as this saves one additional step that a user must remember. The current steps to start valgrind with GDB, as given on the valgrind website (https://valgrind.org/docs/manual/manual-core-adv.html) are: $ gdb prog (gdb) set remote exec-file prog (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi --vargs -q (gdb) start With this GDB work, and once support for the qExecAndArgs packet is added to valgrind, then the 'set remote exec-file' line can be dropped from those instructions. This commit also extends the 'show remote exec-file' command so that GDB will display the automatic value that it plans to use. Here's an example of the new output: $ gdb -q /tmp/hello Reading symbols from /tmp/hello... (gdb) set sysroot (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once - Remote debugging using | ./gdbserver/gdbserver --multi --once - Remote debugging using stdio (gdb) show remote exec-file The remote exec-file is unset, using automatic value "/tmp/hello". The last line shows the new output. Reviewed-By: Eli Zaretskii Approved-By: Simon Marchi 2025-11-11 Simon Marchi gdb/mips: make mips_tdesc_gp{32,64} target_desc_up Change the types to target_desc_up so it's not needed to `.release()` them. This is similar to this review comment: https: //inbox.sourceware.org/gdb-patches/87seeuak0z.fsf@tromey.com/ Change-Id: I45e0e77b00701aa979e8f7f15f397836b4e19849 Approved-By: Maciej W. Rozycki Tested-By: Maciej W. Rozycki 2025-11-11 Alan Modra objcopy binary symbol test A small tidy that allows other symbols or warnings to appear in nm output, and works around the case problem of windows drive letters by simply omitting the $srcdir match. * testsuite/binutils-all/objcopy.exp (binary_symbol): Check objcopy and nm return status. Don't repeat prune_warnings already done in binutils_run. Match each symbol separately, reporting which match failed on a failure. Don't match $srcdir in implicit test. 2025-11-11 Alan Modra Re: readelf: Display the base symbol version as empty string Update a gold test for commit 2be0f2da2100. PR binutils/33599 * testsuite/ver_test_4.sh: Expect "t1_2@". 2025-11-11 GDB Administrator Automatic date update in version.in 2025-11-10 Sven Schnelle gdb/hppa: guess g packet size With qemu supporting 64 bit now, add some code to determine the register size of a hppa remote target. Approved-By: Simon Marchi Change-Id: Iffade4e02d758b9cb20c8f206e812bf3205518f7 2025-11-10 Tom de Vries [gdb/testsuite] Force DWARF in gdb.pascal On i686-linux (and likewise arm-linux), I run into: ... (gdb) file str-chars^M Reading symbols from str-chars...^M warning: stabs debug information is not supported.^M (No debugging symbols found in str-chars)^M (gdb) delete breakpoints^M ... Fix this by using fpc option -gw2. Tested on i686-linux. Approved-By: Simon Marchi PR testsuite/33564 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564 2025-11-10 Tom Tromey Add uses of _() to symmisc.c A review of an earlier version of this series pointed out some missing _() invocations in symmisc.c. This fixes the ones I thought were appropriate. In some spots I chose not to add them because the text didn't seem like something that ought to be translated. Approved-By: Simon Marchi 2025-11-10 Tom Tromey Print the CU index in cooked_index::dump While exploring a question I had about the DWARF indexer, I found I wanted to see the CU index of each entry. This patch adds this information. Approved-By: Simon Marchi 2025-11-10 Tom Tromey Add styling to cooked_index::dump This patch adds some styling to cooked_index::dump, making the output a bit easier to read. Approved-By: Simon Marchi 2025-11-10 Tom Tromey Add styling to symmisc.c I was looking at some "maint" output and noticed that symmisc.c could apply styling in a few spots. This patch is the result. Approved-By: Simon Marchi 2025-11-10 Tom Tromey Use unordered_map in record-btrace This changes the bfcache in record-btrace.c to use a gdb::unordered_map. Approved-By: Simon Marchi 2025-11-10 Tom Tromey Use unordered_set for frame_stash This changes the frame_stash global to be an unordered_set rather than a htab_t. Approved-By: Simon Marchi 2025-11-10 Simon Marchi gdb: remove unused includes in target-descriptions.c Remove includes reported as unused by clangd. Change-Id: I3b01165ed7c79d7305a6ba70f1f4c2b30864d26c 2025-11-10 Tom de Vries [pre-commit] Set verbose=false for check-whitespace Currently, the pre-commit check check-whitespace has verbose=true: ... $ pre-commit run --all-files check-whitespace check-whitespace........................................................Passed - hook id: check-whitespace - duration: 0.3s $ ... That's not necessary, since: - check-whitespace has no output if the check passes, and - pre-commit shows the output anyway if the check fails. Fix this by removing the verbose setting, getting us instead: ... $ pre-commit run --all-files check-whitespace check-whitespace........................................................Passed $ ... Approved-By: Simon Marchi 2025-11-10 Tom de Vries [gdb/testsuite] Drop address from test name in gdb.mi/mi-memory-changed.exp I ran the testsuite twice, once with target board unix, and once with target board unix/-fPIE/-pie, compare the two sum files, and got for test-case gdb.mi/mi-memory-changed.exp: ... < PASS: $exp: set var *(unsigned int *) 0x4011b0 = 0xe5894855 --- > PASS: $exp: set var *(unsigned int *) 0x5555555551c3 = 0xe5894855 ... Fix this by dropping the concrete address from the test name: ... PASS: $exp: set var *(unsigned int *) 0x${main_addr} = ${main_insn} ... Tested on x86_64-linux. 2025-11-10 Tom de Vries [gdb/testsuite] Drop address from test name in gdb.arch/amd64-shadow-stack-corefile.exp I ran the testsuite twice, compare the two sum files, and got for test-case gdb.arch/amd64-shadow-stack-corefile.exp: ... 3077c3077 < PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f7a38 3fffe0 --- > PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f179e ... Fix this by dropping the address from the test name. Tested on x86_64-linux. 2025-11-10 Dennis Dyallo readelf: Fix typo in --version-info documentation Change "it they exist" to "if they exist" in the description of the --version-info option in the readelf man page. 2025-11-10 Jan Dubiec Minor cleanup in ld documentation ld/ * ld.texi : Remove a remnant of previous edits. 2025-11-10 Jan Beulich bfd/ELF: mark internal MIPS functions hidden This reduces the dynamic symbol table some and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: _bfd_elf_ppc_at_tls_transform() is exposed to gas As a non-private function, it shouldn't have a "_bfd_" prefix, but merely a "bfd_" one. Hence commit 50efe229ddf5 ("bfd/ELF: mark internal functions hidden") also wrongly added ATTRIBUTE_HIDDEN to it. 2025-11-10 Jan Dubiec ld: Fix a H8/300 specific test case It seems that glob patterns no longer work in the test suite, at least on some host/dejagnu/shell combinations. In any case it is better here not to create a single relax-7?.o file from the two source files, but to create two separate objects for linking. ld/ * testsuite/ld-h8300/relax-7.d: Replace the glob pattern with multiple "source" options. 2025-11-10 GDB Administrator Automatic date update in version.in 2025-11-09 Indu Bhagat libsframe: rename encoder to ectx for readability Addressing (an old) review comment suggesting this housekeeping item. Use consistent naming style in libsframe. sframe_decoder_ctx objects are named 'dctx', so use 'ectx' for sframe_encoder_ctx objects. Make necessary changes in all the applicable declarations and definitions. Reviewed-by: Jens Remus 2025-11-09 Tom de Vries [gdb/testsuite] Fix main in gdb.trace/mi-trace-frame-collected.exp With test-case gdb.trace/mi-trace-frame-collected.exp I run into: ... gdb compile failed, gdb.trace/actions.c: In function 'main': gdb.trace/actions.c:139:1: warning: old-style function definition \ [-Wold-style-definition] 139 | main (argc, argv, envp) | ^~~~ ... Fix this by rewriting main into a prototyped function. Tested on x86_64-linux. PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 2025-11-09 Indu Bhagat libsframe: fix checks in flip_fde Adjust the sanity checks for flip_fde workflow and optional trailing section padding to account for the case of ihp->sfh_fdeoff != 0 or ihp->sfh_freoff != total FDEs size. Reviewed-by: Jens Remus libsframe/ * sframe.c (flip_sframe): Fix checks in flip_fde to accommodate cases when sfh_fdeoff != 0 or when SFrame FREs are placed after a gap from SFrame FDEs. 2025-11-09 Tom de Vries [gdb/testsuite] Use -std=c99 in gdb.base/callfuncs.exp In test-case gdb.base/callfuncs.exp I run into: ... gdb compile failed, gdb.base/callfuncs.c: In function 't_func_values': gdb.base/callfuncs.c:611:12: error: too many arguments to function \ 'func_arg1'; expected 0, have 2 611 | return ((*func_arg1) (5,5) == (*func_val1) (5,5) | ~^~~~~~~~~~~ ~ ... Fix this by using -std=c99. Tested on x86_64-linux. Approved-By: Tom Tromey PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756 2025-11-09 GDB Administrator Automatic date update in version.in 2025-11-08 GDB Administrator Automatic date update in version.in 2025-11-07 H.J. Lu readelf: Display the base symbol version as empty string Update readelf to display the base symbol version as Symbol table for image contains 5 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@ 2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1 3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1 4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo@ instead of Symbol table for image contains 5 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar 2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1 3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1 4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo That is bar@@ and foo@ vs bar and foo. binutils/ PR binutils/33599 * readelf.c (process_version_sections): Replace 0x8001 with (VERSYM_HIDDEN | VERSYM_BASE). (get_symbol_version_string): Likewise. Return "" for the base version. include/ PR binutils/33599 * elf/common.h (VERSYM_BASE): New. ld/ PR binutils/33599 * testsuite/ld-elf/pr33599.d: New file. * testsuite/ld-elf/pr33599.map: Likewise. * testsuite/ld-elf/pr33599.s: Likewise. 2025-11-07 Simon Marchi gdb/testsuite: adjust yet another add-inferior test for native-extended-gdbserver board I'm seeing this FAIL with the native-extended-gdbserver board: (gdb) add-inferior^M [New inferior 2]^M Added inferior 2 on connection 1 (extended-remote localhost:2365)^M (gdb) FAIL: gdb.python/py-parameter.exp: test_per_inferior_parameters: add-inferior This is another case of add-inferior producing more output when connected to a remote target. Adjust the regexp to accomodate it. Change-Id: Ic5760ff66712c54b90b9debf379dcbf6e07f6eeb 2025-11-07 Simon Marchi gdb/testsuite: adjust another add-inferior test for native-extended-gdbserver board I see this FAIL when running with the native-extended-gdbserver board: Expecting: ^(-add-inferior[^M ]+)?(.*\^done,inferior="i2"[^M ]+[(]gdb[)] ^M [ ]*) -add-inferior^M =thread-group-added,id="i2"^M ~"[New inferior 2]\n"^M ~"Added inferior 2 on connection 1 (extended-remote localhost:2345)\n"^M ^done,inferior="i2",connection={number="1",name="extended-remote"}^M (gdb) ^M FAIL: gdb.mi/set-show.exp: test_per_inferior_parameters: add inferior (unexpected output) This is another case of the add-inferior command producing more output when connected to a remote target. Adjust the regexp to accomodate it. Change-Id: Ifa0590211fd75d4a01dff942c6bb810d5caf1257 2025-11-07 Jan Vrany pre-commit: check for whitespace errors in on all files under gdb I got a review comment [1] because I forgot to run git diff --staged --check to check commits before submitting. This commit adds a pre-commit hook to do this automatically. Approved-By: Simon Marchi [1]: https://inbox.sourceware.org/gdb-patches/c231d267-f541-4774-8005-6d433a9d6e96@simark.ca/ 2025-11-07 Tom Tromey Write entire buffer in gdbserver write_prim We had a customer bug report which was eventually tracked down to gdbserver not fully sending a target description to gdb. (This presented as a timeout on the gdb side.) The customer was using the WINAPI code, which does this: # define write(fd, buf, len) send (fd, (char *) buf, len, 0) In this setup, I think it's possible to have a partial write. However, gdbserver does not account for this possibility, despite the fact that write_prim documents this. This patch attempts to fix the problem by always writing the full buffer in write_prim. In this case the customer fixed their bug in a different way, so we haven't actually tested this in the wild. v2: Return bool from write_prim. Reviewed-by: Kévin Le Gouguec 2025-11-07 Simon Marchi gdb/dwarf: pass is_debug_types to dwarf2_per_cu constructor, make field private Make the field private to make it clear it is never meant to change. Pass its value through the constructor, and add a getter. The only place that passes true is the signature_type constructor. Change-Id: Ifb76bc015bca16696fd66cdf45c048b4ba713479 Approved-By: Tom Tromey 2025-11-07 Simon Marchi gdb/dwarf: make some fields in dwarf2_per_cu private Except for the m_length field, that is already private and has a setter, make the fields whose values are passed through the constructor private. The idea is that their values should be constant throughout the life of the object. Add some getters and update the callers. I wasn't sure if making some bitfields public and some private would change how they are packed, so I checked with "ptype/o", it does not. Change-Id: I7087bebf69e44d16a36c1dd4d7edf9b8bf085343 Approved-By: Tom Tromey 2025-11-07 Simon Marchi gdb/dwarf: clarify comment on dwarf_per_bfd::all_units I thought that this comment could be updated to clarify what this vector holds and what it is used for. Change-Id: I0e1968c8c6455b49aa156669c43ea8c436c59e45 Approved-By: Tom Tromey 2025-11-07 Simon Marchi Revert "bfd/ELF: make is_debuginfo_file() static" This reverts commit 5e648fc6a0a066fad38d99b72fb85f2710f2c098, since it breaks the GDB build: CXX elfread.o /home/smarchi/src/binutils-gdb/gdb/elfread.c: In function ‘symfile_segment_data_up elf_symfile_segments(bfd*)’: /home/smarchi/src/binutils-gdb/gdb/elfread.c:145:12: error: ‘is_debuginfo_file’ was not declared in this scope 145 | if (!is_debuginfo_file (abfd) | ^~~~~~~~~~~~~~~~~ Change-Id: I180a9f6936365c365a853c7dae2af01f5207a84e 2025-11-07 Simon Marchi gdb/testsuite: issue "no repeat" command before "no previous command to relaunch" test I see this failure: $ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" FAIL: gdb.base/with.exp: repeat: reinvoke with no previous command to relaunch It seems like that failure has always been there and I didn't notice? I'm not sure what is the intent of the test exactly. It sounds like it is meant to test what happens when you use command "with language ada" as the very first command of a GDB session? However, clean_restart and gdb_load issue some commands before that test. The different between the native-extended-gdbserver board and the other boards is: for other boards, the previous command is a "file" command, which is a "no repeat" command, which gives the expected error message. With the native-extended-gdbserver board, the previous command is "set remote exec-file", which is a repeatable command. "Fix" it by making a "no repeat" command just before the test, so that it works the same regardless of the target board. Change-Id: I254faf196f49e9efd492fc9dd5f6ce7b96f72af7 Approved-By: Tom Tromey 2025-11-07 Lukas Durfina gdb/testsuite: rename thread_local variables C standard gnu23 introduces a new keyword 'thread_local'. So, this variables must be renamed to avoid build errors. Approved-By: Tom Tromey 2025-11-07 Jens Remus s390: Bind defined symbol locally in PIE Symbols defined in PIE should be bound locally, the same as -shared -Bsymbolic. Port x86 commit 4e0c91e45402 ("Bind defined symbol locally in PIE") change of relocate_section as well as linker tests to s390. Similar as done for other architectures with the following commits: - AArch64: ac33b731d214 ("[AArch64] Bind defined symbol locally in PIE") - ARM: 1dcb9720d62c ("[ARM] Bind defined symbol locally in PIE") - RISC-V: 39c7793ba8be ("RISC-V: Bind defined symbol locally in PIE") - x86: 4e0c91e45402 ("Bind defined symbol locally in PIE") With this change symbols defined in an executable (i.e. PDE or PIE) are bound locally, as they cannot be interposed. In the same way as symbols defined in a shared library linked with -Bsymbolic are bound locally. This also ensures that all defined symbols are bound locally in static PIE. Do not port the x86 change of check_relocs (now scan_relocs). None of the linker tests where the change in condition triggers (e.g. bootstrap, cdtest) produce different readelf -Wa output. The change appears to affect accounting of space required for dynamic relocations. Instead of accounting them in check_relocs and later filtering them away in allocate_dynrelocs, they would not get accounted in the first place: The change in the expression would only have an effect if the following conditions are all met in addition to PIE: ALLOC, PC-relative relocation, global symbol, not defined weak, and defined regular. In this specific case the accounting of the PC relative relocation in h->dyn_relocs would be skipped for PIE. But allocate_dynrelocs later eliminates any PC-relative dynamic relocations if PIC (= PIE or shared library) and SYMBOL_CALLS_LOCAL. bfd/ PR ld/33141 * elf64-s390.c (elf_s390_relocate_section): Bind defined symbol locally in PIE. ld/testsuite/ PR ld/33141 * ld-s390/s390.exp: Add pr33141 tests. * ld-s390/pr33141.rd: New file. * ld-s390/pr33141a.s: Likewise. * ld-s390/pr33141b.s: Likewise. 2025-11-07 Jan Beulich bfd/ELF: _bfd_elf_linker_x86_set_options() is exposed to ld As a non-private function, it shouldn't have a "_bfd_" prefix, but merely a "bfd_" one. bfd/ELF: _bfd_elf_link_create_dynamic_sections() is exposed to ld As a non-private function, it shouldn't have "_bfd_" prefixes, but merely a "bfd_" one. Even if, sadly, it needs exposing just for the sake for VxWorks. bfd/ELF: mark functions exposed to ld as non-private As non-private functions, these shouldn't have "_bfd_" prefixes, but merely "bfd_" ones: - _bfd_elf_size_group_sections(), - _bfd_elf_match_sections_by_type(), - _bfd_elf_strtab_{str,len}(), - _bfd_elf_map_sections_to_segments(), - _bfd_elf_tls_setup(). bfd/ELF: _bfd_elf{,32,64}_hppa_gen_reloc_type are exposed to gas As non-private functions / macros, they shouldn't have "_bfd_" prefixes, but merely "bfd_" ones. bfd/ELF: _bfd_elf_large_com_section is exposed to gas and x86-only As a non-private data item, it shouldn't have a "_bfd_" prefix, but merely a "bfd_" one. Furthermore, as being x86-only (forever since its introduction), it doesn't need to be present in libbfd.{a,so} at all for other targets. bfd/ELF: _bfd_elf_obj_attrs_arg_type() is exposed to gas As a non-private function, it shouldn't have a "_bfd_" prefix, but merely a "bfd_" one. bfd/ELF: properly mark elf_appent_rel{a,}() as private Add _bfd_ prefixes and make them hidden. bfd/ELF: properly mark elf_read_notes() as private Add a _bfd_ prefix and make it hidden. bfd/ELF: properly mark bfd_elf_print_symbol() as private Add a leading underscore and make it hidden. bfd/ELF: adjust *_size_info properties Target-specific symbols can be static. The common ones can at least be hidden. bfd/ELF: make is_debuginfo_file() static No need to expose it, even less so in the dynamic symbol table. bfd/ELF: mark VxWorks functions hidden They're all internal to libbfd. bfd/x86: mark _bfd_x86_elf_link_report_tls_{transition,invalid_section}_error() hidden For some reason the attributes were missing there. bfd/ELF: mark internal TileGX functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal Sparc functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal SCore functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal RISC-V functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). 2025-11-07 Jan Beulich bfd/ELF: mark an internal PowerPC function hidden This reduces the dynamic symbol table a little. Also drop the ppc_elf_section_processing() declaration, as its definition was dropped almost 10 years ago. 2025-11-07 Jan Beulich bfd/ELF: mark internal NDS32 functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal M68HC1x functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal LoongArch functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal KVX functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal IA-64 functions hidden This reduces the dynamic symbol table a little and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal aarch64 functions hidden This reduces the dynamic symbol table some and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd/ELF: mark internal functions hidden This reduces the dynamic symbol table quite a bit (almost 200 symbols) and allows the compiler to be more aggressive about inlining (as it sees fit, of course). bfd: move ATTRIBUTE_HIDDEN to separate header ... for it to become usable in places where libbfd.h cannot (easily) be included. x86: support SALC Now that the SDM (finally) at least mentions it (without giving it a proper instruction page, though), let's (again: finally) also support it in assembler and disassembler. 2025-11-07 GDB Administrator Automatic date update in version.in 2025-11-06 Tom Tromey Fix use of "main" in gdb_index with C++ In commit f283e80f (Fix use of "main" marker in gdb index), I changed the DWARF reader to understand that the C language's "main" might appear in the .gdb_index, and should not be ignored. This week I realized that this same problem can affect C++ as well. I'm not sure why I didn't consider this at the time. This patch fixes the bug. It's somewhat of a hack, I guess, but also at least understandable. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33441 2025-11-06 Jan Dubiec sframe: Minor format string fix in sframe_decode The type of fidx_size is size_t so the proper length modifier is not "l" but "z". libsframe/ * sframe.c (sframe_decode): Fix format string (length modifier) for fidx_size. 2025-11-06 Tom Tromey Move symbol::value_block to symtab.c It seems to me that symbol::value_block doesn't particularly need to be inlined. This patch moves it to symtab.c. 2025-11-06 Simon Marchi gdb/testsuite: adjust add-inferior test for native-extended-gdbserver board I see this failure: $ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" FAIL: gdb.base/with.exp: per-inferior parameters: add-inferior The add-inferior command produces more output than expected when using the native-extended-gdbserver board, because it is already connected to a remote target: (gdb) add-inferior [New inferior 2] Added inferior 2 on connection 1 (extended-remote localhost:2348) Fix that by accepting output after "Added inferior 2", as is done elsewhere in the testsuite already (e.g. gdb.btrace/multi-inferior.exp). Change-Id: I047a3be5249dd803839b213dd2f1646736fc8289 2025-11-06 Rainer Orth gas: Default to -mrelax-relocations=no on Solaris/x86 [PR19520] I recently noticed a complex case statement in gas/configure.ac controlling the setting of ac_default_x86_relax_relocations on Solaris/x86. Since it included all versions of Solaris, it could be massively simplified. Looking closer however, I found that it was introduced in commit 0cb4071ef9e10f703220f5e731141bf438aca16e Author: H.J. Lu Date: Wed Feb 3 08:25:15 2016 -0800 Add -mrelax-relocations= to x86 assembler based on PR gas/19520. This PR reported that the new R_386_GOT32X etc. relocations weren't supported on older versions of Solaris, breaking gcc bootstrap. In response, they were disabled on all Solaris versions except Solaris 12, where they had been implemented in the native toolchain based on my findings. However, Solaris 12 has been rechristened to 11.4 before release, effectively disabling DEFAULT_GENERATE_X86_RELAX_RELOCATIONS on all versions of Solaris/x86. Since Solaris 11.4 cannot be distinguished from earlier versions in cross configurations, this patch fixes this by removing --enable-x86-relax-relocations completely, instead disabling DEFAULT_GENERATE_X86_RELAX_RELOCATIONS in tc-i386.c on Solaris. It also adds testcases to verify the -mrelax-relocations default. Tested on {i386,amd64}-pc-solaris2.11 and {i686,x86_64}-pc-linux-gnu. 2025-10-16 Rainer Orth gas: PR gas/19520 * configure.ac (ac_default_x86_relax_relocations): Remove. : Likewise. * configure: Regenerate. * config.in: Regenerate. * config/tc-i386.c (DEFAULT_GENERATE_X86_RELAX_RELOCATIONS): Define. * doc/c-i386.texi (i386-Options, -mrelax-relocations): Remove --enable-x86-relax-relocations reference. * testsuite/gas/i386/gotx.s: New source. * testsuite/gas/i386/gotx-default.d: New test. * testsuite/gas/i386/no-gotx-default.d: Likewise. * testsuite/gas/i386/i386.exp: Run them. 2025-11-06 Tom Tromey Fix build after command_classes change Commit 7028626eff3 (gdb: make command classes be bitmaps) broke the build, causing the compiler to issue an error message about the global scm-cmd.c:command_classes being redefined as a different type. Renaming the global fix the problem. 2025-11-06 Andrew Burgess gdb/python: fix gdb.Block repr output I noticed that when printing a gdb.Block object in Python, I would occasionally get corrupted, nonsensical output, like this: {intintyinty_1inty_3inty_5... (-5 more symbols)}> The symbol list is missing commas, it should be: int, inty, inty_1, inty_3, inty_5, ... And the '-5 more symbols' is clearly not right. The problem is in python/py-block.c, we use this line to calculate the number of symbols in a block: const int len = mdict_size (block->multidict ()); Then we loop over the symbols in the block like this: for (struct symbol *symbol : block_iterator_range (block)) ... The problem here is that 'block_iterator_range (block)' can loop over more symbols than just those within 'block'. For global and static blocks, block_iterator_range() takes into account included CUs; and so can step through multiple global or static blocks. See block_iterator_step and find_iterator_compunit_symtab in block.c for more details. In contrast, 'mdict_size (block->multidict ())' only counts the symbols contained within 'block' itself. I could fix this by either fixing LEN, or by only iterating over the symbols within 'block'. I assume that printing a gdb.Block object is used mostly for debug purposes; the output isn't really user friendly, so I cannot imagine a user script that is relying on printing a gdb.Block as a way to inform the user about blocks in their program. As such, I think it makes more sense if the symbols listed are restricted to those strictly held within the block. And so, instead of block_iterator_range, I've switched to iterating over the multidict symbols. Now the calculated LEN will match the number of symbols being printed, which fixes the output seen above. However, as we're now only printing symbols that are within the block being examined, the output above becomes: {}> All the symbols that GDB previously tried to print, are coming from an included CU. For testing, I've made use of an existing DWARF test that tests DW_AT_import. In the wild I saw this in an inferior that used multiple shared libraries that has their debug information stored in a separate debug file, and then parts of that debug information was combined into a third separate file using the DWZ tool. I made a few attempts to craft a simpler reproducer, but failed. In the end it was easier to just use a DWARF assembler test to reproduce the issue. I have added some more typedef symbols into the DWARF test, I don't believe that this will impact the existing test, but makes the corrupted output more obvious. Approved-By: Tom Tromey 2025-11-06 Tom de Vries [gdb/testsuite] Fix DUPLICATE in callfuncs.exp With test-case gdb.base/callfuncs.exp I get: ... UNTESTED: gdb.base/callfuncs.exp: failed to prepare ... UNTESTED: gdb.base/callfuncs.exp: failed to prepare DUPLICATE: gdb.base/callfuncs.exp: failed to prepare ... Fix this by moving a with_test_prefix up one level. Tested on x86_64-linux. 2025-11-06 Jerry Zhang Jian RISC-V: Fix missing instruction classes in error messages Add 6 missing instruction class cases to riscv_multi_subset_supports_ext() to provide proper extension names in error messages instead of producing "internal: unreachable INSN_CLASS_*" errors. These instruction classes exist in riscv_multi_subset_supports() but were missing from riscv_multi_subset_supports_ext(), causing the assembler to produce internal errors when instructions are used without the required -march specification. Missing classes added: - INSN_CLASS_ZABHA_AND_ZACAS (zabha and zacas) - INSN_CLASS_XVENTANACONDOPS (xventanacondops) - INSN_CLASS_XSFVCP (xsfvcp) - INSN_CLASS_XSFVQMACCQOQ (xsfvqmaccqoq) - INSN_CLASS_XSFVQMACCDOD (xsfvqmaccdod) - INSN_CLASS_XSFVFNRCLIPXFQF (xsfvfnrclipxfqf) Before this fix: Error: internal: unreachable INSN_CLASS_* Error: unrecognized opcode `amocas.b a0,a1,(a2)' After this fix: Error: unrecognized opcode `amocas.b a0,a1,(a2)', extension `zabha' and `zacas' required bfd/ * elfxx-riscv.c (riscv_multi_subset_supports_ext): Add 6 missing instruction class cases. 2025-11-06 GDB Administrator Automatic date update in version.in 2025-11-05 Guinevere Larsen gdb: add "essential" command class Currently, there is no way for a new user to have an idea of common useful commands and behaviors from the GDB interface itself, without checking the example session in the documentation. This command class aims to close that gap by providing a set of quickstart commands that allows for any simple debug session to happen without anything too egregious missing. The set of commands was chosen somewhat arbitrarily, based on what I used or missed the most. The one overarching important thing, however, is that the list is kept short, so as to not overwhelm new users. This is confirmed by the newly introduced selftest, essential_command_count, which ensures there are 20 or fewer essential commands. Here's the reasoning for some of the choices: * The command "start" was picked over "run" because combining it with "continue" achieves the same effect, and I prefer it over needing to set a breakpoint on main to stop at the start of the inferior. * The command "ptype" is chosen because I believe it is important to provide a way for the user to check a variable's type from inside GDB, and ptype is a more complete command than the alternative, "whatis". Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-11-05 Guinevere Larsen gdb: make command classes be bitmaps This commit makes it so GDB's command classes can be represented with a single bit, allowing for a command to have multiple classes. This is primarily done as preparation for the next patch, but it can provide value on its own as some commands could be described as belonging to multiple classes, such as "record" being obscure and related to running the inferior. Approved-By: Tom Tromey 2025-11-05 Jose E. Marchesi binutils/MAINTAINERS: list new gprofng maintainers As agreed with Nick I will be co-maintaining gprofng moving forward along with Claudiu. Update the MAINTAINERS file accordingly. 2025-11-05 Simon Marchi gdb/testsuite: remove unused "variable" statement Change-Id: I2e26a9953324c752edd01b37db6b176fd0ee9187 2025-11-05 Maciej W. Rozycki LD/doc: Add missing `--push-state' option markup There is a missing option markup for a `--push-state' reference in the description of the `--pop-state' option, fix it. BFD: Remove unused file position member of `struct orl' The `pos' member of `struct orl' has never been used. Remove it along with the enclosing union so as not to propagate clutter with a later change, which adds that union as a distinct type. No functional change. 2025-11-05 Tom de Vries [gdb/testsuite] Yet another attempt to fix gdb.threads/thread-specific-bp.exp When running test-case gdb.threads/thread-specific-bp.exp using taskset to select an Efficient-core in a loop, it fails 19 out of 100 runs. For example, like this: ... (gdb) continue -a^M Continuing.^M ^M Thread 1 "thread-specific" hit Breakpoint 4, end () at thread-specific-bp.c:29^M 29 }^M (gdb) FAIL: $exp: non_stop=on: continue to end [Thread 0x7ffff7cbe6c0 (LWP 2348848) exited]^M Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M ... The way we're trying to match this gdb output is: ... gdb_test_multiple "$cmd" "continue to end" { -re "$\r\n${gdb_prompt} .*${msg_re}\r\n" { pass $gdb_test_name } -re "\r\n${msg_re}\r\n.*$gdb_prompt " { pass $gdb_test_name } } ... The problem is that the two -re clauses above do not match the output ending in a prompt, so the default fail in gdb_test_multiple triggers. Fix this by splitting this up in two gdb_test_multiple calls: - the first matches a prompt (with or without preceding $msg_re), making sure that the default fail doesn't trigger, and - the second matches $msg_re, if that was not already matched by the first call. Using this approach, the test-case passes 100 out of 100 runs. Tested on x86_64-linux, also with make-check-all.sh. PR testsuite/32688 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32688 2025-11-05 Tom de Vries [gdb/testsuite] Remove gdb.dwarf2/dw2-ranges.exp On openSUSE Leap 15.6 x86_64 with test-case gdb.dwarf2/dw2-ranges.exp I ran into: ... (gdb) file dw2-ranges^M Reading symbols from dw2-ranges...^M warning: stabs debug information is not supported.^M (gdb) ... The test-case checks a combination of dwarf and stabs. Now that stabs is no longer supported, checking the combination is no longer possible. Fix this by removing the test-case. 2025-11-05 Indu Bhagat include: sframe: fix minor typos in sframe_decode Change argument names (in declaration) to SF_BUF and SF_SIZE (instead of the current CF_BUF and CF_SIZE respectively). include/ * sframe-api.h (sframe_decode): Fix typos. Use same name as used for the definition. 2025-11-05 Indu Bhagat gas: sframe: fix PR gas/33277 In SFrame stack trace format, the representation of stack offsets allows for either 1-byte, 2-byte or 4-byte integers. Add new internal function sframe_fre_stack_offset_bound_p () which checks if the given offset is within bounds (at most as a 4-byte integer). Use this to check if CFA offset is within bounds, if not skip emitting the FDE, and warn the user. Reviewed-by: Jens Remus gas/ PR gas/33277 * gen-sframe.c (sframe_fre_stack_offset_bound_p): New definition. (sframe_xlate_do_def_cfa): Check bounds of offset. (sframe_xlate_do_def_cfa_offset): Likewise. gas/testsuite/ PR gas/33277 * gas/cfi-sframe/cfi-sframe.exp: Add new test. * gas/cfi-sframe/cfi-sframe-x86_64-empty-pr33277.d: Likewise. * gas/cfi-sframe/cfi-sframe-x86_64-empty-pr33277.s: Likewise. 2025-11-05 GDB Administrator Automatic date update in version.in 2025-11-04 John David Anglin hppa64: Fix some issues handling dynamic relocaltions This change fixes the allocation logic in allocate_dynrel_entries and elf64_hppa_finalize_dynreloc. It also fixes addend calculation for segment based relocations. Some applications now link successfully on HP-UX but there are still issues with external weak symbols. This breaks linking with libgcc. It looks like we need support for .rela.data.rel.ro, ... 2025-11-04 John David Anglin bfd/ChangeLog: * elf64-hppa.c (allocate_dynrel_entries): Correct hh->want_opd if condition. (elf64_hppa_finalize_dynreloc): Likewise. Use symbol address instead of OPD address. Include sec->output_offset in value2 calculation. (elf64_hppa_finalize_opd): Likewise. (elf64_hppa_finalize_dlt): Likewise. (elf_hppa_final_link_relocate): Fix symbol address calculation. 2025-11-04 Jan Vrany gdb: change blockvector_contains_pc to be a method This changes blockvector_contains_pc() to be a method contains() of struct blockvector. Approved-By: Simon Marchi 2025-11-04 Jan Vrany gdb: change find_block_in_blockvector to be a method This changes find_block_in_blockvector() to be a method lookup() of struct blockvector. Approved-By: Simon Marchi 2025-11-04 Jens Remus s390: Emit relocation for 32-bit immediate operand IBM Z instruction format RIL-a has a 32-bit immediate operand in instruction bits 16 to 47. Enable the assembler to emit a 32-bit direct or PC-relative relocation when processing a fixup, similar as it is already done for 16-bit immediate operands in bits 16-31. This enables to assemble the following: lgfi %r1,symbol # R_390_32 lgfi %r1,symbol-. # R_390_PC32 Furthermore it brings GNU assembler on par with LLVM assembler in that regard. gas/ * config/tc-s390.c (md_apply_fix): Emit 32-bit direct or PC-relative relocation for 32-bit immediate operand in instruction bits 16-47. gas/testsuite/ * gas/s390/zarch-reloc.d: Add tests for relocation of RIL-a 32-bit immediate operand. * gas/s390/zarch-reloc.s: Likewise. 2025-11-04 GDB Administrator Automatic date update in version.in 2025-11-03 Simon Marchi gdb: introduce blockvector_up Change-Id: Id43c5982969f85b5931ba8a32d208a7326ed3492 Approved-By: Tom Tromey 2025-11-03 Tankut Baris Aktemur gdb: fix a typo in a comment in gdbtypes.h Fix the typo "can server" to "can serve". Also re-align the comment to make `void (*) ()` not break. 2025-11-03 Tom Tromey Clean up "return -1" in gdb.rust This changes gdb.rust tests to use plain "return" rather than "return -1". In these spots, the "-1" has no meaning. Approved-by: Kevin Buettner 2025-11-03 Nick Clifton Remove call to abort in the DGB debug format printing code, thus allowing the display of a fuzzed input file to complete without triggering an abort. PR 33448 2025-11-03 Sam James Sync top-level with GCC This just brings in the following two changes: commit 04df8fa9e73e612f978fff35a97841703b872f6c Author: Thomas Schwinge AuthorDate: Tue Oct 21 09:46:32 2025 +0200 Commit: Thomas Schwinge CommitDate: Fri Oct 24 12:40:22 2025 +0200 Simplify 'Makefile' dependencies for libatomic [PR81358] ... commit e63cf4b130b86dd7dde1bf499d3d40faca10ea2e Author: Prathamesh Kulkarni AuthorDate: Thu Oct 9 07:07:24 2025 +0000 Commit: Prathamesh Kulkarni CommitDate: Thu Oct 9 07:26:51 2025 +0000 PR81358: Enable automatic linking of libatomic. ... ChangeLog: * Makefile.def: Sync with GCC. * configure.ac: Ditto. * configure: Regenerate. 2025-11-03 Indu Bhagat libsframe: use sframe_decoder_get_funcdesc_v2 in dumper Not strictly necessary for correctness. But using '_v2' named APIs is more appropriate. libsframe/ * sframe-dump.c (dump_sframe_func_with_fres): 2025-11-03 Indu Bhagat gas: sframe: improve code comments around SFRAME_FRE_BASE_REG_INVAL Rename it to SFRAME_FRE_REG_INVALID. gas/ * gen-sframe.c (sframe_row_entry_new): Adjust code comments a bit. * gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): Rename from.. (SFRAME_FRE_REG_INVALID): ..to this. 2025-11-03 H.J. Lu elf: Don't set its DT_VERSYM entry for unversioned symbol 1. Referenced symbol without '@' has no version. 2. Defined symbol without the .symver directive has no version if there is no linker version script. Symbol without version shouldn't have the base version in its DT_VERSYM entry. Instead, its DT_VERSYM entry should be all zero to indicate that the symbol doesn't have a version. NB: Symbol with the base version has a '@' suffix, like "foo@", defined with .symver hide_original_foo, foo@ bfd/ PR ld/33577 * elflink.c (elf_link_output_extsym): Don't set its DT_VERSYM entry for the symbol without version. ld/ PR ld/33577 * ld-elfvers/vers16.dsym: Remove the "Base" version on symbols without version. 2025-11-03 Markus Metzger btrace: stopped_by_*() consider the selected thread In stopped_by_sw_breakpoint() and stopped_by_hw_breakpoint(), we check whether any thread is replaying. This is unnecessary as it only matters if inferior_ptid is replaying. Narrow the check to inferior_ptid. 2025-11-03 Markus Metzger btrace: remove update_thread_list() and thread_alive() The record btrace target does not create or destroy threads. There is no reason to override the update_thread_list() and thread_alive() target methods. 2025-11-03 Markus Metzger btrace, infrun: replay scheduler locking only depends on to-be-resumed thread Similar to the parent commit, simplify schedlock_applies() by only checking the argument thread. When resuming that thread, GDB will automatically stop replaying its inferior. The replay state of other inferiors is not considered by user_visible_resume_ptid(), so let's not consider them in schedlock_applies(), either. Approved-By: Tom Tromey 2025-11-03 Markus Metzger btrace, infrun: simplify scheduler-locking replay When scheduler-locking is set to replay and we're resuming a thread at the end of its execution history, we check whether anything is replaying in user_visible_resume_ptid() only to check again in clear_proceed_status() before we stop replaying the current process. What really matters is whether the selected thread is replaying or will start replaying. Simplify this by removing redundant checks. Also avoid a redundant pass over all threads to check whether anything is replaying before stopping replaying. Make record_stop_replaying() handle the case when we're not replaying gracefully. Approved-By: Tom Tromey 2025-11-03 Markus Metzger gdb, remote: adjust debug printing remote::wait () may get called rather frequently, polluting the logging output with tons of [remote] wait: enter [remote] wait: exit messages. Similarly, remote_target::remote_notif_remove_queued_reply () will print the debug message even if nothing was actually removed. Change that to only print a debug message if a stop reply was removed. Approved-By: Tom Tromey 2025-11-03 Markus Metzger gdb, btrace: set wait status to ignore if nothing is moving When record_btrace::wait() is called and no threads are moving, we set the wait status to no_resumed. Change that to ignore. This helps with enabling per-inferior run-control for the record btrace target as it avoids breaking out of do_target_wait() too early with no_resumed when there would have been an event on another thread. 2025-11-03 Markus Metzger gdb, btrace: simplify gdb.btrace/multi-inferior.exp We don't really need three inferiors to test multi-inferior recording. We don't really need to check info record before starting recording. If we were recording, there would be output, causing a fail. This just complicates the test when there is something to debug. 2025-11-03 Markus Metzger btrace: clear thread stopped state when stopping replaying When we stop replaying a thread, it moves to the end of its execution history. It retains its state from when it was replaying, though, so a subsequent 'info program' command would show wrong information. Clear all execution state used by the 'info program' command. 2025-11-03 Markus Metzger btrace: do not allow moving running threads with 'record goto' With asynchronous commands, a thread can be replaying in the background while it is being moved using the 'record goto' command in the foreground. Do not allow that. 2025-11-03 Markus Metzger btrace: do not stop replaying or recording while a thread is running With asynchronous stepping commands, one may start replaying a thread in the background and then stop recording its inferior in the foreground. This causes the execution history to be cleared and the record target to be unpushed while the thread is using said execution history. I fail to see a use-case for this, so rather than trying to make this work, I prevent such a scenario by not allowing replaying or recording to be stopped while a thread is running. We could do this only when a thread is running in replay mode and preserve the existing behavior of being able to stop recording while threads are running in recording mode. It seems more consistent to not allow this for both replaying and recording threads, though. 2025-11-03 Markus Metzger btrace: update record_btrace_stop_replaying_at_end In record_btrace_stop_replaying_at_end, we know that we are at the end of the execution history, so PC must match the current PC if we're not replaying. We're not changing any other registers during btrace replay, so we should be fine leaving the regcache. But we need to reinit the frame cache, since current frames used the btrace unwinder. The main motivation for this, however, is that future patches extend stop replaying in ways that is not relevant to stop replaying at the end. 2025-11-03 Markus Metzger gdb, record: notify frame change on 'record stop' when selected thread moves As a side effect of the 'record stop' command, threads may move to the end of their execution history if they had been replaying. When using CLI or TUI, there is no indication of that move for the selected thread. Notify about the frame change for the selected thread. This makes CLI print the selected frame and TUI update their view. Add a note to the MI record-stopped event. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-11-03 Markus Metzger gdb, btrace: fix pr19340 GDB fails with an assertion when stopping recording on a replaying thread and then resuming that thread. Stopping recording left the thread replaying but the record target is gone. Stop replaying all threads in the selected inferior before stopping recording. I had to change the stepping test slightly to account for different compilers generating slightly different debug information, so when stepping the 'return 0' after 'record stop' I would end up in a different location depending on which compiler I used. The test still covers all stepping commands. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19340 Approved-By: Andrew Burgess 2025-11-03 Alan Modra ctf-archive sanity checks Existing code checks that the first uint64_t ctfa_magic field is available before reading but neglects to check that the last uint64_t ctfa_ctfs is available before reading it in ctf_arc_bufpreamble. ctf_arc_bufopen sets up a pointer to the struct ctf_archive in ctf_new_archive_internal. Extend the check to cover the entire struct. PR 33548 PR 33549 * ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Check that buffer contains at least an entire struct ctf_archive when accessing such a struct. 2025-11-03 Alan Modra regen some configure files commit 87b6078fc212 had some stale files 2025-11-03 Alan Modra tidy m4 plugin config support In CLANG_PLUGIN_FILE it is possible for plugin_file to be non-NULL when LLVMgold.so does not exist. configure output is messy, with results not printed against their "checking.." line, eg. checking for clang... (cached) yes checking for clang plugin file... checking for x86_64-pc-linux-gnu-ar... (cached) ar --plugin /usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so /usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so This patch fixes those problems, and a similar interposition of other configure output between AC_MSG_CHECKING and AC_MSG_RESULT in gcc-plugin.m4. It also tidies some of the message text, and makes similar code in gcc-plugin.m4 and clang-plugin.m4 a little more consistent. config/ * clang-plugin.m4 (CLANG_PLUGIN_FILE): Don't place checks for tools (llvm-config, ar) inside AC_MSG_CHECKING..AC_MSG_RESULT for clang plugin file. Clear plugin_file before loop exit. (CLANG_PLUGIN_FILE_FOR_TARGET): Similarly. * gcc-plugin.m4 (GCC_PLUGIN_OPTION): Similarly. (GCC_PLUGIN_OPTION_FOR_TARGET): Correct AC_MSG_CHECKING. Tidy return code. binutils/ * testsuite/lib/binutils-common.exp : Set for non-native. * configure: Regenerate. / * configure: Regenerate. bfd/ * configure: Regenerate. gas/ * configure: Regenerate. gdb/ * configure: Regenerate. gprof/ * configure: Regenerate. gprofng/ * configure: Regenerate. * libcollector/configure: Regenerate. ld/ * configure: Regenerate. libbacktrace/ * configure: Regenerate. libctf/ * configure: Regenerate. libiberty/ * configure: Regenerate. libsframe/ * configure: Regenerate. opcodes/ * configure: Regenerate. sim/ * configure: Regenerate. zlib/ * configure: Regenerate. 2025-11-03 Alan Modra PR 33455 SEGV in vfinfo at ldmisc.c:527 A reloc howto set up with EMPTY_HOWTO has a NULL name. More than one place emitting diagnostics assumes a reloc howto won't have a NULL name. PR 33455 * coffcode.h (coff_slurp_reloc_table): Don't allow a howto with a NULL name. 2025-11-03 GDB Administrator Automatic date update in version.in 2025-11-02 John David Anglin hppa64: Implement segment based relocations for local symbols There is progress in implementing 64-bit shared library support. Fixes link error compiling vdso64.so. HP-UX dynamic linker no longer complains that libgcc_s.4 linked with GNU ld is an invalid shared library. Relocations are now generated for all slots in .rela.data, .rela.dlt and .rela.opd. Relocation counts for libgcc_s.4 linked using GNU and HP ld are the same except .rela.plt. That may be okay as GNU ld directs pc-relative calls to stubs. Glibc's ld.so.new appears to link okay. However, libgcc_s.4 linked with GNU ld is still broken on HP-UX. There are six unexpected fails in the testsuite and three unexpected passes. There's at least one fail due to name munging in the .dynsym table. 2025-11-02 John David Anglin bfd/ChangeLog: * elf64-hppa.c (struct elf64_hppa_link_hash_entry): Remove sym_ind and owner fields. Rename hash entries for __text_seg and __data_seg. Adjust all users. (global_sym_index): Remove. (hppa64_elf_local_refcounts): Assert size is not 0. (elf64_hppa_check_relocs): Drop NEED_PLT from R_PARISC_FPTR64 relocation. Don't stash abfd and r_symndx in hh->owner and hh->sym_indx. Add global symbols with hh->eh.dynindx equal -1 to dynamic table. Don't record section symbols to the local dynamic symbol table. (allocate_global_data_dlt): Don't add symbol to local dynamic symbol table. (allocate_global_data_opd): Likewise. (elf64_hppa_late_size_sections): Rework code to add __text_seg and __data_seg symbols to the dynamic table. (elf64_hppa_finalize_dlt): Revise to use __text_seg and __data_seg symbols. (elf64_hppa_finalize_dynreloc): Likewise. (elf_hppa_final_link_relocate): When generating a shared library, ignore relocs in debugging sections. Revise relocations needing DLT and OPD dynamic relocations to output dynamic relocatios for local symbols. Move code to initialize segment base values back to SEGREL case. 2025-11-02 Andrew Burgess gdb: add a constructor for symtab Convert symtab to use obstack_new, and have a real constructor. The filename, filename_for_id and m_compunit, members should really not change once the symtab has been created, so make these members private (m_compunit was already private) and set them just once from the constructor. The set_compunit function has been deleted, and new getter functions for filename and filename_for_id have been added. The language is also set at construction time, but can be updated later, so set the language in the constructor, but retain symtab::set_language for when the language needs to be updated. Prior to this patch the symtab was allocated with OBSTACK_ZALLOC which would zero out the symtab object. With the call to objstack_new fields in the symtab would no longer be initialised, so I've added default member initialisation for everything not set in the constructor. The interesting changes are in symtab.h, and symfile.c. Everything else is just updating to handle symfile::filename and symfile::filename_for_id becoming methods. Approved-By: Simon Marchi 2025-11-02 GDB Administrator Automatic date update in version.in 2025-11-01 Indu Bhagat libsframe: use sf_fde_tbl data structure internally for the decoder Instead of the current sframe_func_desc_entry (on-disk format representation) data structure. The decoder context in libsframe, so far, has been internally directly tied to the sframe_func_desc_entry (on-disk format representation) data structure. While this allows libsframe to avoid some operations, this is not desirable anymore as the format evolves: we will need to support reading in of older version(s) of SFrame FDE, as well as a newer on-disk representations for SFrame FDE. Use sf_fde_tbl internally in the decoder context. Note that libsframe already does _not_ use sframe_func_desc_entry in any external-facing, user-visible APIs. Note that this commit is simply preparatory in nature. At the moment, the 'sf_fde_tbl' internally uses the sframe_func_desc_entry (on-disk format representation). When need arises (as SFrame FDE evolves), we may change sf_fde_tbl to use an alternative (but still libsframe internal) definition of SFrame FDE. lisbframe/ * sframe-impl.h (sf_fde_tbl, sf_fre_tbl): Move definition before use. Use sf_fde_tbl instead of sframe_func_desc_entry in struct sframe_decoder_ctx. * sframe.c (sframe_fde_tbl_alloc): New internal definition. (sframe_fde_tbl_init): Likewise. (sframe_decoder_get_funcdesc_at_index): Adjust for sf_fde_tbl usage. (sframe_decoder_get_secrel_func_start_addr): Likewise. (sframe_fre_check_range_p): Likewise. (sframe_decode): Likewise. (sframe_get_funcdesc_with_addr_internal): Likewise. 2025-11-01 Indu Bhagat libsframe: make flip_header version aware Future versions of the format may have alternative representation of an FDE. As the format evolves, endian flipping of the SFrame header may need to be version aware. flip_header () now takes the SFrame version as argument and also returns SFRAME_ERR in case of error. Currently the SFrame version as argument remains unused. SFrame encoder, at the momemnt, writes the SFrame data in the most recent format version by default. libsframe/ * sframe.c (flip_header): Make version aware. (sframe_decode): Adjust usage of flip_header. (sframe_encoder_write): Likewise. 2025-11-01 Indu Bhagat libsframe: make flip_fde version aware Future versions of the format may have a different representation of an SFrame FDE. As the format evolves, endian flipping will need to be version aware. Refactor flip_fde a bit by carving out an internal sframe_decode_fde API which can read information from an on-disk SFrame FDE. libsframe/ * sframe.c (flip_fde): Make version aware. (sframe_decode_fde): New internal definition. (flip_sframe): Use the new definitions. 2025-11-01 GDB Administrator Automatic date update in version.in 2025-10-31 GDB Administrator Automatic date update in version.in 2025-10-30 H.J. Lu lto: Set plugin_format to bfd_plugin_no only if known_used is set commit b21318bd2c29fcca8f99c1de7facdaa5cb2e66e2 Author: Joseph Myers Date: Thu May 11 14:31:09 2023 +0000 Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128] added the LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook for offload support. Since the V2 linker plugin hook doesn't claim the offload IR if known_used is unset, set input plugin_format to bfd_plugin_no only if known_used is set or the V2 linker plugin hook is unused. PR ld/33584 * plugin.c (plugin_object_p): Set plugin_format to bfd_plugin_no only if known_used is set or the V2 linker plugin hook is unused. 2025-10-30 Alan Modra tic4x_scan: match printable arch string Fix odd behaviour of objcopy -I -B on tic4x, where the tms320c4x string reported by objcopy --info isn't a valid arch string. * cpu-tic4x.c (tic4x_scan): Match arch string reported by objcopy --info. 2025-10-30 Alan Modra Pass -B to objcopy binary symbol test objcopy -I binary -O some_coff_target does not currently work without choosing a valid arch with -B. This used to be the case for ELF targets too, until commit 6765ee1825d9. * testsuite/binutils-all/objcopy.exp (binary_symbol): Pass -B arch to objcopy. Choose different output object files for the two tests. 2025-10-30 John David Anglin hppa64: Use address of __text_seg symbol in elf64_hppa_finalize_opd 2025-10-30 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_finalize_opd): Use address of __text_seg symbol instead of hppa_info->text_segment_base. 2025-10-30 John David Anglin hppa64: Use address of __text_seg symbol insted of hppa_info->text_segment_base 2025-10-30 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf_hppa_final_link_relocate): Use address of __text_seg symbol insted of hppa_info->text_segment_base. 2025-10-30 John David Anglin hppa64: Add code to intialize __data_seg section symbol 2025-10-30 John David Anglin bfd/ChangeLog: * elf64-hppa.c (struct elf64_hppa_link_hash_table): Add data_segment field. (allocate_global_data_opd): Move code to initialize text segment section symbol to elf64_hppa_late_size_sections. (elf64_hppa_late_size_sections): Add code to setup __data_seg section symbol. 2025-10-30 Simon Marchi gdbsupport: bump unordered_dense to 4.8.0 We don't need anything in this release, but I think it doesn't hurt to just stay up to date. The new version has a new include file, stl.h. To keep things clean and separated, move the imported files to a new sub-directory. This requires a small change in gdb/check-include-guards.py, to be able to ignore the whole new directory. Change-Id: Ic8c5d0dd5ea8b6691c99975d6ca78f637175ef42 Approved-By: Tom Tromey 2025-10-30 Simon Marchi pre-commit: use ^ anchors in `files` Some `files` regexes use a ^ anchor, some don't. I think it's good to be explicit about it (and consistent), so use it everywhere. Change-Id: I14eb2082a1c0ff6bc219e202fb16c3f12001fd73 Approved-By: Tom Tromey 2025-10-30 Simon Marchi pre-commit: run flake8 on all .py(.in)? files under gdb This covers Python files under gdb/contrib and gdb/testsuite, which are now flake8-clean. Change-Id: If587964d0735f6f585c72d18df40439424215644 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/contrib/dwarf-to-dwarf-assembler.py: remove unused imports Remove imports reported as unused by flake8. Change-Id: I1a1e5edab6ecd6ee774cb4bd20bf22b8952898aa Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: avoid assigning lambdas in Python files Fix flake8 warnings like this one: gdb/testsuite/gdb.perf/template-breakpoints.py:35:13: E731 do not assign a lambda expression, use a def I chose to inline the lambdas in the expressions, since they are simple enough and only used once each. Change-Id: I46fac428a95da38f5a6a87e101be4da9fa4acc31 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: rename ambiguous variable in py-command-breakpoint.py Fix this flake8 warning: gdb/testsuite/gdb.python/py-commands-breakpoint.py:37:13: E741 ambiguous variable name 'l' This one is a bit subjective, but renaming the variable is easy enough and the simplest way to get rid of the warning. Change-Id: I9b1ffd898e27a9d0e172f29715aff3ff3cc785b9 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: use "not in" in Python files Fix flake8 warnings like this one: gdb/testsuite/gdb.python/py-send-packet.py:68:12: E713 test for membership should be 'not in' Change-Id: I2b4cc1eeb63ee2fceb8c4264e7d6ce2d22824688 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: address "unused not at top of file" warnings in Python files Address flake8 warnings like this one: gdb/testsuite/gdb.python/py-typeprint.py:60:1: E402 module level import not at top of file Change-Id: I6ab7880ec5b55b6a5c85cb01d0f85172d44b4ee1 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: remove unused but set variables in Python files Fix flake8 errors like this one: gdb/testsuite/gdb.python/py-unwind-inline.py:61:17: F841 local variable 'v' is assigned to but never used For this one, there is a slight possibility that removing a variable changes some behavior, and perhaps renders some test uneffective (where the test would no longer exercises what it meant to). Removing a variable means that the object it pointed to likely gets de-allocated earlier (its tp_dealloc method gets called). So if the intent of the variable was to ensure the variable outlives the statements that come after, then this change would be wrong. But I didn't see any evidence of that being the intent in all the occurences. Change-Id: Ic57bc68ad225a43ae6771c47b7f443956e8029a6 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: avoid bare except in Python files Fix flake8 warnings like this: gdb/testsuite/gdb.python/py-unwind-inline.py:62:9: E722 do not use bare 'except' Change-Id: I9736c948bc84fefcb7db2a6ac7322cbbfe39da94 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: use "is" to check against None Fix flake8 warnings like: gdb/testsuite/gdb.base/pc-not-saved.py:55:18: E711 comparison to None should be 'if cond is None:' Change-Id: Icb8bbe3ea444125c9d7ae63b7c1461045782b4b2 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: use "is" for type comparison in Python files Fix flake8 warnings like: gdb/testsuite/gdb.python/py-unwind.py:253:20: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()` Change-Id: I506c0874bba88aa418757d94168992bf4ec677f8 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: remove unused "global" statements in Python files Fix the flake8 warnings of this type: gdb/testsuite/gdb.python/py-disasm.py:855:9: F824 `global current_pc` is unused: name is never assigned in scope Change-Id: If492c69553cebea932cfb21e6fea26529761254c Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: remove unused imports in Python files Remove the imports reported as unused by flake8. Change-Id: I6e657de3dea8db18a99e711e594cb92f98e1cebb Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/testsuite: remove variable with ambiguous name in gdb.server/fileio-packets.py flake8 complains about: gdb/testsuite/gdb.server/fileio-packets.py:67:9: E741 ambiguous variable name 'l' I think the variable is unnecessary anyway, inline the expression in the format string. Change-Id: Ib294f58e663e79e65de058139a770d572bafb282 Approved-By: Tom Tromey 2025-10-30 Simon Marchi gdb/{testsuite,system-gdbinit}: import gdb module in Python scripts Fix flake8 warnings like: gdb/system-gdbinit/wrs-linux.py:21:5: F821 undefined name 'gdb' These scripts get executed in a context where the gdb module is already loaded, so this is not strictly necessary. However, adding these imports removes a lot of red lines when editing these files in an IDE. Without them, the code uses this `gdb` thing that appears to be undefined. Pylance is able to pull the module definition from typeshed [1] and provide a good experience with typings. [1] https://github.com/python/typeshed/tree/main/stubs/gdb/gdb Change-Id: I09c6ae1866ef66f10d8270457771687343c84e32 Approved-By: Tom Tromey 2025-10-30 Can Acar darwin-nat.c: fix broken build caused by typing issues from 1ad8737b 1ad8737b is gdb: change inf_threads_iterator to yield references Change-Id: Ic9478f4a292c3309481b16ace24ee23e82bbed4a Approved-By: Tom Tromey 2025-10-30 Luis Machado Fix device index in gdb.rocm/addr-bp-gpu-no-deb-info.exp On a system with a single GPU, I spotted this test failing. The environment variable ROCR_VISIBLE_DEVICES can be a bit misleading, as it actually expects a list of device id's as opposed to a literal number of devices to make visible. This test sets it to 1, which is the second GPU on the system. As a result, systems with a single GPU will have no visible GPU's and the test will FAIL. Set ROCR_VISIBLE_DEVICES to 0 to make use of the first GPU on the system. Approved-By: Lancelot Six (AMDGPU) 2025-10-30 Maciej W. Rozycki MIPS/GAS: Add HI16/LO16 pairing for REL TLS relocs Complementing commit 7ea90d9316d3 ("MIPS: Fix linker for REL TLS HI16/LO16 relocs") also add pairing for HI16/LO16 REL TLS relocations in GAS, which is where it needs to be done in the first place and which is required for later linker operation on the objects produced. Pairing also corrects in-place addend installation for the high-part relocations, which used not to happen in the absence of this fix for ones not already followed by the corresponding low-part relocation. Add test cases to verify relocation ordering and addend installation. 2025-10-30 Maciej W. Rozycki MIPS/GAS: Fix microMIPS TLS reloc classification Fix `micromips_reloc_p' wrongly classifying microMIPS TLS relocations as non microMIPS relocations. Owing to where the function is called this issue does not trigger in reality, but with an upcoming change it would, where suitable tests will be included. 2025-10-30 Maciej W. Rozycki MIPS: Add o32 RELA relocations for VxWorks targets MIPS/VxWorks targets have an unusual arrangement in that they use RELA relocations with the o32 ABI, unlike any other MIPS target. Due to an inconsistency in BFD however "hybrid" relocations are produced by GAS, where despite the relocations being of the RELA type the field to be relocated also holds an in-place addend to be applied at link time. For example: $ cat vxworks-rela.s .text foo: la $2, bar + 0x12345678 $ mips-vxworks-as -o vxworks-rela.o vxworks-rela.s $ mips-vxworks-objdump -dr vxworks-rela.o vxworks-rela.o: file format elf32-bigmips-vxworks Disassembly of section .text: 00000000 : 0: 3c021234 lui v0,0x1234 0: R_MIPS_HI16 bar+0x12345678 4: 24425678 addiu v0,v0,22136 4: R_MIPS_LO16 bar+0x12345678 $ This is due to the BFD backend being strapped for RELA relocations: #undef elf_backend_may_use_rel_p #define elf_backend_may_use_rel_p 0 #undef elf_backend_may_use_rela_p #define elf_backend_may_use_rela_p 1 #undef elf_backend_default_use_rela_p #define elf_backend_default_use_rela_p 1 but the howtos in use requesting an in-place addend, e.g.: /* High 16 bits of symbol value. */ HOWTO (R_MIPS_HI16, /* type */ 16, /* rightshift */ 4, /* size */ 16, /* bitsize */ false, /* pc_relative */ 0, /* bitpos */ complain_overflow_dont, /* complain_on_overflow */ _bfd_mips_elf_hi16_reloc, /* special_function */ "R_MIPS_HI16", /* name */ true, /* partial_inplace */ 0x0000ffff, /* src_mask */ 0x0000ffff, /* dst_mask */ false), /* pcrel_offset */ /* Low 16 bits of symbol value. */ HOWTO (R_MIPS_LO16, /* type */ 0, /* rightshift */ 4, /* size */ 16, /* bitsize */ false, /* pc_relative */ 0, /* bitpos */ complain_overflow_dont, /* complain_on_overflow */ _bfd_mips_elf_lo16_reloc, /* special_function */ "R_MIPS_LO16", /* name */ true, /* partial_inplace */ 0x0000ffff, /* src_mask */ 0x0000ffff, /* dst_mask */ false), /* pcrel_offset */ This arrangement nevertheless happens to produce correct ELF executables owing to the ELF linker avoiding the use of howtos and doing relocation calculations using its own knowledge of relocation semantics embedded directly in `mips_elf_calculate_relocation' code. Beyond producing questionable link object files it however breaks badly with the generic linker, such as when output is srec. Fix the problem by providing a set of o32 RELA howtos and making VxWorks targets use it. Complement it with a set of test cases for GAS and LD; we expect link object files to be essentially the same as n32 ones for other MIPS targets sans the ABI2 ELF file header flag, and machine code produced to be the same between SREC and ELF executables. 2025-10-30 Maciej W. Rozycki MIPS/LD/testsuite: Run HI16/LO16 tests for VxWorks too Run ELF linker tests for HI16/LO16 relocations with MIPS/VxWorks targets as well. Despite issues only fixed in the next change they produce the same results as with other MIPS targets, so just use the existing tests verbatim, however refrain from adding other tests until said issues have been fixed. 2025-10-30 Hui Li gdb: LoongArch: Change default char data type to signed According to "Procedure Call Standard for the LoongArch Architecture" [1], for all base ABI types of LoongArch, the char data type in C is signed by default, so change the char data type to signed in gdb/loongarch-tdep.c. Before this patch: make check-gdb TESTS="gdb.base/sizeof.exp" === gdb Summary === # of expected passes 75 # of unexpected failures 1 make check-gdb TESTS="gdb.base/charset.exp" === gdb Summary === # of expected passes 277 # of unexpected failures 6 # of unsupported tests 1 After this patch: make check-gdb TESTS="gdb.base/sizeof.exp" === gdb Summary === # of expected passes 76 make check-gdb TESTS="gdb.base/charset.exp" === gdb Summary === # of expected passes 283 # of unsupported tests 1 [1] https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#appendix-c-data-types-and-machine-data-types 2025-10-30 Zewei Yang gdb/testsuite: Add LoongArch case in my-syscalls.S When running the following command on LoongArch: git clone git://sourceware.org/git/binutils-gdb.git gdb mkdir -p build && cd build && ../gdb/configure && make -j"$(nproc)" make check-gdb TESTS="gdb.threads/step-over-thread-exit-while-stop-all-threads.exp" there exists the following error: gdb/gdb/testsuite/lib/my-syscalls.S:67:3: error: #error "Unsupported architecture" this is because there is no SYSCALL macro for LoongArch, just add it. With this patch, the above test passes on LoongArch. Tested-by: Tiezhu Yang 2025-10-30 Jens Remus s390: Do not generate incomplete opcode table The s390 opcode table s390-opc.tbl is generated from s390-opc.txt using the s390-mkopc utility using output redirection. If s390-mkopc fails with a non-zero return code, e.g. due to a warning or error, an incomplete opcode table may be generated in the build directory. A subsequent invocation of make then assumes that incomplete opcode table to be up to date. Depending on the s390-mkopc issue the build may then proceed without any follow-on warnings or errors, causing the preceding error or warning to go unnoticed. Generate the s390 opcode table into an intermediate temporary file s390-opc.tbl.tmp in the build directory and only move it to the final target s390-opc.tbl if the generation was successful. Tested by appending an unsupported inline comment "# TEST" to one of the instructions defined in s390-opc.txt. opcodes/ * Makefile.am (s390-opc.tab): Use an intermediate temporary file to prevent updating of the target on error/warning. * Makefile.in: Regenerated. 2025-10-30 Alan Modra Sanity check elf_sym_hashes indexing I'm a little surprised we haven't already had fuzzing reports of indexing off the end of sym_hashes. The idea here is to preempt such bugs. One wrinkle is that ppc64 can't leave a zero symtab_hdr when setting up sym_hashes for the fake stub bfd. * elf-bfd.h (struct elf_reloc_cookie): Add "num_sym". (_bfd_elf_get_link_hash_entry): Update declaration. * elf-eh-frame.c (find_merged_cie): Sanity check reloc symbol index. * elf64-ppc.c (use_global_in_relocs): Fake up symtab_hdr for stub bfd. * elflink.c (_bfd_elf_get_link_hash_entry): Add "num_sym" param. Check symndx against it. Update all calls. (set_symbol_value): Add "num_sym" param and update all calls. (elf_link_input_bfd): Add "num_syms" var and use for above. (init_reloc_cookie): Set "cookie->num_syms". * elf64-x86-64.c (elf_x86_64_scan_relocs): Pass symtab number of entries to _bfd_elf_get_link_hash_entry. * elfxx-x86.c (_bfd_x86_elf_check_relocs): Likewise. (_bfd_x86_elf_link_relax_section): Likewise. 2025-10-30 Alan Modra Don't read and cache local syms for gc-sections Most places just need the local sym section, so reading and sometimes caching the symbols is excessive. A symbol shndx can be stored in 4 bytes, an elf symbol internal form requires 32 bytes. When caching the local symbols we went slightly crazy trying to avoid memory usage, resulting in the symbols being freed then immediately read again for the testcase in the PR33530. To avoid this problem, this patch caches the local symbol section indices in the bfd rather than in the reloc cookie. They are not initialised until there is a need for them, so unlike elf_sym_hashes for global syms you cannot rely on them being present. One place that does need local syms is adjust_eh_frame_local_symbols, but that is called once via bfd_discard_info so there is no problem simply reading them. The other place that needs local syms is ppc64_elf_gc_mark_hook for the old ELFv1 ABI when handling .opd. bfd_sym_from_r_symndx should be sufficient for function pointer references to static functions, which is how this code is triggered. PR 33530 * elf-bfd.h (struct elf_reloc_cookie): Delete "locsyms", "sym_hashes", "bad_symtab". Make "locsymcount" and "extsymoff" unsigned int. (struct elf_obj_tdata): Add loc_shndx. (elf_loc_shndx): Define. (_bfd_get_local_sym_section): Declare. * elf-eh-frame.c (find_merged_cie): Use _bfd_get_local_sym_section for local syms. (adjust_eh_frame_local_symbols): Read local syms if any match .eh_frame section. Return them if changed. (_bfd_elf_discard_section_eh_frame): Adjust. * elf64-ppc.c (ppc64_elf_gc_mark_hook): Use _bfd_get_local_sym_section. Use bfd_sym_from_r_symndx when reading opd local symbol. * elflink.c (_bfd_get_local_sym_section): New function. (_bfd_elf_section_for_symbol): Use it. (elf_link_add_object_symbols): Remove unnecessary cast on bfd_zalloc return. (init_reloc_cookie): Remove "info" and "keep_memory" params. Adjust all callers. Don't stash elf_sym_hashes and elf_bad_symtab to cookie. Don't read local syms to cookie. (fini_reloc_cookie): Do nothing. (_bfd_elf_gc_mark_hook): Use _bfd_get_local_sym_section. (elf_gc_mark_debug_section): Likewise. (bfd_elf_reloc_symbol_deleted_p): Likewise. Update cookie use. 2025-10-30 Alan Modra _bfd_elf_get_link_hash_entry tidy Replace the "Elf_Internal_Shdr *symtab_hdr" parameter with "unsigned int ext_sym_start", making it a duplicate of the existing get_link_hash_entry function. Also remove unnecessary checks from get_ext_sym_hash_from_cookie and find_merged_cie. The sym_hashes and symbol index checks in get_ext_sym_hash_from_cookie are duplicates of those done in _bfd_elf_get_link_hash_entry, and there is no need to check for a global symbol before calling _bfd_elf_get_link_hash_entry. When bad_symtab, local symbols will have a NULL sym_hashes entry. Removing these unnecessary checks gets rid of some cookie->locsyms references. PR 33530 * elf-bfd.h (_bfd_elf_get_link_hash_entry): Update declaration. * elflink.c (_bfd_elf_get_link_hash_entry): Rename from get_link_hash_entry, adjusting all calls and deleting original function. (get_ext_sym_hash_from_cookie): Make "symndx" unsigned int. Remove unnecessary check on sym_hashes, symbol index and symbol binding. * elf-eh-frame.c (find_merged_cie): Remove similar unnecessary checks. * elf64-x86-64.c (elf_x86_64_scan_relocs): Adjust. * elfxx-x86.c (_bfd_x86_elf_check_relocs): Adjust. (_bfd_x86_elf_link_relax_section): Adjust. 2025-10-30 Alan Modra Pass cookie and symndx to gc_mark_hook Replace the "sym" param with "cookie" and "symndx". This is in preparation for the next patch. Also remove "rel" param since this is available via "cookie", and is always set from cookie->rel. PR 33530 * elf-m10300.c (mn10300_elf_gc_mark_hook): Replace "rel" and "sym" params with "cookie" and "symndx". Adjust to suit. * elf32-arm.c (elf32_arm_gc_mark_hook): Likewise. * elf32-bfin.c (bfin_gc_mark_hook): Likewise. * elf32-cris.c (cris_elf_gc_mark_hook): Likewise. * elf32-csky.c (csky_elf_gc_mark_hook): Likewise. * elf32-d10v.c (elf32_d10v_gc_mark_hook): Likewise. * elf32-fr30.c (fr30_elf_gc_mark_hook): Likewise. * elf32-frv.c (elf32_frv_gc_mark_hook): Likewise. * elf32-hppa.c (elf32_hppa_gc_mark_hook): Likewise. * elf32-iq2000.c (iq2000_elf_gc_mark_hook): Likewise. * elf32-lm32.c (lm32_elf_gc_mark_hook): Likewise. * elf32-m32r.c (m32r_elf_gc_mark_hook): Likewise. * elf32-m68k.c (elf_m68k_gc_mark_hook): Likewise. * elf32-mcore.c (mcore_elf_gc_mark_hook): Likewise. * elf32-metag.c (elf_metag_gc_mark_hook): Likewise. * elf32-microblaze.c (microblaze_elf_gc_mark_hook): Likewise. * elf32-nds32.c (nds32_elf_gc_mark_hook): Likewise. * elf32-or1k.c (or1k_elf_gc_mark_hook): Likewise. * elf32-ppc.c (ppc_elf_gc_mark_hook): Likewise. * elf32-s390.c (elf_s390_gc_mark_hook): Likewise. * elf32-score.c (s3_bfd_score_elf_gc_mark_hook): Likewise. (_bfd_score_elf_gc_mark_hook): Likewise. * elf32-score7.c (s7_bfd_score_elf_gc_mark_hook): Likewise. * elf32-sh.c (sh_elf_gc_mark_hook): Likewise. * elf32-tilepro.c (tilepro_elf_gc_mark_hook): Likewise. * elf32-v850.c (v850_elf_gc_mark_hook): Likewise. * elf32-vax.c (elf_vax_gc_mark_hook): Likewise. * elf32-visium.c (visium_elf_gc_mark_hook): Likewise. * elf32-xstormy16.c (xstormy16_elf_gc_mark_hook): Likewise. * elf32-xtensa.c (elf_xtensa_gc_mark_hook): Likewise. * elf64-alpha.c (elf64_alpha_gc_mark_hook): Likewise. * elf64-mmix.c (mmix_elf_gc_mark_hook): Likewise. * elf64-ppc.c (ppc64_elf_gc_mark_hook): Likewise. * elf64-s390.c (elf_s390_gc_mark_hook): Likewise. * elfnn-loongarch.c (loongarch_elf_gc_mark_hook): Likewise. * elfxx-mips.c (_bfd_mips_elf_gc_mark_hook): Likewise. * elfxx-sparc.c (_bfd_sparc_elf_gc_mark_hook): Likewise. * elfxx-tilegx.c (tilegx_elf_gc_mark_hook): Likewise. * elfxx-x86.c (_bfd_x86_elf_gc_mark_hook): Likewise. * elflink.c (_bfd_elf_gc_mark_hook): Likewise. (elf_gc_mark_debug_section): Likewise. (_bfd_elf_gc_mark_rsec): Adjust gc_mark_hook calls. * elf32-cr16.c (elf32_cr16_gc_mark_hook): Delete. (elf_backend_gc_mark_hook): Don't define. * elf32-moxie.c (moxie_elf_gc_mark_hook): Delete. (elf_backend_gc_mark_hook): Don't define. * elf-bfd.h (elf_gc_mark_hook_fn, _bfd_elf_gc_mark_hook): Update declarations. * elf32-score.h (s7_bfd_score_elf_gc_mark_hook): Likewise. * elfxx-mips.h (_bfd_mips_elf_gc_mark_hook): Likewise. * elfxx-sparc.h (_bfd_sparc_elf_gc_mark_hook): Likewise. * elfxx-tilegx.h (tilegx_elf_gc_mark_hook): Likewise. * elfxx-x86.h (_bfd_x86_elf_gc_mark_hook): Likewise. 2025-10-30 Alon Bar-Lev objcopy: add option to specify custom prefix for symbol of binary input When using --input-target=binary, objcopy currently derives symbol names from a mangled version of the input file name. This approach can lead to unpredictable results, as the generated symbols depend on the file path and working directory. This patch introduces a new option: --binary-symbol-prefix Use as the base symbol name for the input file (default: derived from file name) It allows specifying an explicit symbol prefix, while preserving the existing behavior as a fallback. 2025-10-30 GDB Administrator Automatic date update in version.in 2025-10-29 Andrew Burgess gdb/testsuite: fix git repository check in gdb.src/pre-commit.exp In the recently added gdb.src/pre-commit.exp test, we check if the source directory is a git repository like this: if {![file isdirectory $repodir/.git]} { unsupported "Not in a git repository" return } I make extensive use of git worktrees for development. In a worktree .git is a file containing the location of the actual .git directory, it is not itself a directory. As such, the above check fails, claiming my source tree is not a git repository, when in fact, it is. Fix this by relaxing the check to 'file exists $repodir/.git', which will cover the directory and file case. Approved-By: Kevin Buettner 2025-10-29 Haochen Jiang x86: Disable AMX-TRANSPOSE by default In Binutils, we choose to keep the AMX-TRANSPOSE support for now in case there are vendors want to utilize the instructions although the feature itself is de-published. AMX-TRANSPOSE will not show up on any Intel/AMD hardware. Also in foreseeable future, no hardware will support AMX-TRANSPOSE, we will disable it by default. gas/ChangeLog: * testsuite/gas/i386/x86-64-amx-movrs-intel.d: Move AMX-TRANSPOSE part to AMX-TRANSPOSE test. * testsuite/gas/i386/x86-64-amx-movrs.d: Ditto. * testsuite/gas/i386/x86-64-amx-movrs.s: Ditto. * testsuite/gas/i386/x86-64-amx-tf32-bad.d: Ditto. * 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. * 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. * testsuite/gas/i386/x86-64-amx-movrs-inval.l: Move AMX-TRANSPOSE part to AMX-TRANSPOSE file. Remove noamx_transpose test. * testsuite/gas/i386/x86-64-amx-movrs-inval.s: Ditto. * testsuite/gas/i386/x86-64-amx-transpose-bad.d: Add AMX-MOVRS and AMX-TF32 related 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. * testsuite/gas/i386/x86-64.exp: Remove AMX-MOVRS invalid test. * testsuite/gas/i386/x86-64-amx-transpose-apx-intel.d: New test originally comes from APX_F test. * testsuite/gas/i386/x86-64-amx-transpose-apx-wig.d: Ditto. * testsuite/gas/i386/x86-64-amx-transpose-apx.d: Ditto. * testsuite/gas/i386/x86-64-amx-transpose-apx.s: Ditto. opcodes/ChangeLog: * i386-gen.c: Disable AMX-TRANSPOSE by default. * i386-init.h: Regenerated. 2025-10-29 Haochen Jiang Revert "x86/APX: drop AMX-TRANSPOSE promoted insns" This reverts commit bafcf0823c1ae4c2201670225c9cf14ccf2abc67. The patch (the removal) was done on the wrong assumption that it was only the APX-promoted forms which would be dropped because the APX spec was updated ahead of ISE and there was no info that AMX-TRANSPOSE would be de-published at that time. Given the current situation, since we will choose to disable AMX-TRANSPOSE but not to remove the support in Binutils, we will also not remove the APX support. 2025-10-29 GDB Administrator Automatic date update in version.in 2025-10-28 Simon Marchi gdb/solib-rocm: avoid expensive gdbarch_from_bfd call in rocm_solib_relocate_section_addresses Loading a library containing a lot (> 100k) sections proved very slow with whenever the support for ROCm was built into gdb. The culprit is the gdbarch_from_bfd call in rocm_solib_relocate_section_addresses: if (!is_amdgpu_arch (gdbarch_from_bfd (so.abfd.get ()))) This function gets called for every section, and gdbarch_from_bfd is somewhat slow. It turns out that we can skip the gdbarch_from_bfd call, since all is_amdgpu_arch needs is the bfd_architecture value, which we can directly extract from the `bfd *`, without going through the gdbarch. Add an overload of is_amdgpu_arch that takes a `bfd *`, and use it in rocm_solib_relocate_section_addresses. Update a call site in rocm_solib_bfd_open to use the new overload as well. That call site is not as much in a hot path, but there is no point in paying the extra cost of looking up the gdbarch there. I removed the other assert that checked that gdbarch_from_bfd returned a non-nullptr value. If that was the case, something would be very wrong with ROCgdb, and the problem would manifest very soon after anyway. Change-Id: I55e9e68af59903b1b9727ff57388f9469d0e0002 Approved-by: Lancelot Six (AMDGPU) 2025-10-28 Tom Tromey Fix typo in break-kernel-no-debug-info.exp pre-commit / codespell pointed out a typo in break-kernel-no-debug-info.exp. This patch fixes it. 2025-10-28 Tom Tromey Emit language and encoding names from dwarf-to-dwarf-assembler This changes dwarf-to-dwarf-assembler to emit DW_LANG_* and DW_ATE_* names when decoding the appropriate attributes. This makes the output a little more readable and a little closer to something we'd check in. Approved-By: Andrew Burgess 2025-10-28 Tom Tromey Update "usage" line in dwarf-to-dwarf-assembler This changes the "usage" text in dwarf-to-dwarf-assembler to be a bit more GNU-like. It also fixes the name used in the message. Approved-By: Andrew Burgess 2025-10-28 Tom Tromey Fix formatting of attributes in dwarf-to-dwarf-assembler output This updates dwarf-to-dwarf-assembler.py to reflect the changes made to how attributes are parsed; see commit c44edec047d (Make location expressions be code in DWARF assembler). Approved-By: Andrew Burgess 2025-10-28 Sébastien Darche gdb: assign a valid section in convert_address_location_to_sals The convert_address_location_to_sals function builds a symtab_and_line from an explicit pc. Unless overlay debugging is enabled, the sal does not contain a valid section (as find_pc_overlay will simply return nullptr). While it is usually not a problem (as the sal users often recompute the proper section, when needed), it may lead to the proper gdbarch not being assigned when setting a breakpoint. In code_breakpoint::add_location, gdb attempts to retrieve the gdbarch through get_sal_arch by checking for the section or the symtab. However, neither are currently set by cinvert_address_location_to_sals if the debug symbols cannot be found. We then fall back to the current architecture, which may cause errors in heterogeneous programs (in ROCm, a breakpoint was not being hit since GDB was setting an x86 int3 instruction instead of the architecture-appropriate s_trap 1). This is a rework of a patch that was approved, but never merged upstream (https://inbox.sourceware.org/gdb-patches/20241108195257.485488-2-lancelot.six@amd.com/). The original change proposed to set the objfile field in the sal, and check this field in get_sal_arch() if neither the section, nor the symtab is defined. This patch makes GDB compute the section from the pc instead of checking from the objfile in get_sal_arch, in accordance with the rule of trying to set the section when creating the sal implemented in this patch series. The test cases from the original patch are included in this new one. This should have minimal impact on other parts of GDB as users of this section field would either (1) recompute it the same way (2) not use it at all. In the case of overlay debugging, then the preceding call to find_pc_overlay would likely assign a section. Co-Authored-By: Lancelot SIX Approved-By: Tom Tromey Change-Id: I23cef6ad5a66f696536c7c49c885a074bfea9b23 2025-10-28 Sébastien Darche gdb: pass minsym section to find_function_start_sal, when possible We may rely on a minimal symbol to place a breakpoint on a function, for instance when debug infos are unavailable. The minsym_found function attempts to convert that minsym to a sal using either find_function_start_sal or filling a sal manually from the minimal symbol. This patch implements the decision to make it the responsibility of the sal creation site to properly fill out the section field when that is possible. The function address may be updated when dealing with ifuncs, which means the section from the minsym may be completely different from the actual function address's section. A preceding change (6f7ad238 : gdb: ensure bp_location::section is set correct to avoid an assert) has proposed recomputing the section by calling find_pc_overlay. However, this ends up setting the section to NULL in most cases. While the section is often recomputed later on, I think it might be more appropriate to set it once and for all when creating the sal. The parent commit ensures that find_function_start_sal will return a symtab_and_line with a section if possible. minsym_found can pass the section if it can be trusted later on - it is in fact necessary to ensure we get the proper pc/section with overlays. When dealing with an ifunc that was resolved, then the section has to be recomputed since the ifunc implementation may be in another section, or objfile. This is now done in find_sal_for_pc_sect. This change restores the section argument in find_function_start_sal that was removed in a previous commit (6b0581fc : gdb/symtab: remove section parameter from find_function_start_sal), as it avoids an unnecessary lookup later in find_sal_for_pc_sect. The function now sends the minsym's section if it corresponds to the actual function, and not an ifunc. This commit fixes a failure on gdb.rocm/displaced-stepping.exp. A new test case is also provided to check that a breakpoint on a kernel is hit without debug infos. Approved-By: Tom Tromey Change-Id: I7a502dc4565911cec92618f34be3d4bcbf8560c5 2025-10-28 Sébastien Darche gdb: make find_sal_for_pc_sect attempt to fill sal section The find_sal_for_pc_section function inconsistently fills the section field from its output symtab_and_line, depending on whether a symtab is present or not. In the case that we cannot find a symtab for the pc and section, the function would construct a sal with a pc but no section, even though it could be either forwarded from the arguments, or computed from the pc. With the proposed changes, the function attempts to set the section in all code paths and performs a section lookup when it is not provided as an argument. This change is part of a patch series to fix inconsistencies in symtab_and_line constructions, making it the responsibility of the sal creator to fill out the section field (when possible). This section may be passed from a minsym in an unmapped overlay section. Leaving the section field empty would mean in most cases losing some important context (e.g. which overlay section this pc corresponds to). Approved-By: Tom Tromey Change-Id: I818a08c4f61803b6d2cadd32ec106fe416af4c66 2025-10-28 Sébastien Darche gdb: lookup minsym using section in find_sal_for_pc_sect The find_sal_for_pc_sect function attempts to find the line that is closest to a pc+section in the available symbols. One of the first thing the function does is search for a bound minimal symbol corresponding to that pc. In its original version, the lookup is performed by lookup_minimal_symbol_by_pc, discarding the section. This is misleading and may cause issues with overlay debugging if a second minsym with the same pc (but a different section) can be found -- although this is only in theory after inspecting the code, as I have no way to test this on a system supporting overlays. This should have no observable effects for the end user. One slight benefit is that we can avoid a section lookup inside lookup_minimal_symbol_by_pc_section if the caller does provide a section. Since the section is already passed as an argument to the function, the proposed change forwards this section to the minsym lookup section. Approved-By: Tom Tromey Change-Id: I86a16bf397ea7167d3e9c7db79b8d7901fad1a97 2025-10-28 Abhay Kandpal PowerPC: Support for Load/Store VSX Vector Paired Byte*32 Indexed (RFC02678) opcodes/ * ppc-opc.c (powerpc_opcodes): Add lxvpb32x, stxvpb32x. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise. 2025-10-28 Alfie Richards aarch64: gas: Allow movprfx with fmmla and bfscale [PR gas/33562] These instructions were previously incorrectly marked as not accepting movprfx. Fix this and add tests. PR gas/33562 opcodes: * aarch64-tbl.h: Update widening fmmmla and bfscale instructions. gas: * testsuite/gas/aarch64/f8f16mm_sve2-bad.l: Update test with movprfx. * testsuite/gas/aarch64/f8f16mm_sve2.d: Ditto. * testsuite/gas/aarch64/f8f16mm_sve2.s: Ditto. * testsuite/gas/aarch64/f8f32mm_sve2-bad.l: Ditto. * testsuite/gas/aarch64/f8f32mm_sve2.d: Ditto. * testsuite/gas/aarch64/f8f32mm_sve2.s: Ditto. * testsuite/gas/aarch64/sve-f16f32mm-bad.l: Ditto. * testsuite/gas/aarch64/sve-f16f32mm.d: Ditto. * testsuite/gas/aarch64/sve-f16f32mm.s: Ditto. * testsuite/gas/aarch64/sve-bfscale-sve2.s: Ditto. * testsuite/gas/aarch64/sve-bfscale-sve2.d: Ditto. Approved-By: Alice Carlotti 2025-10-28 GDB Administrator Automatic date update in version.in 2025-10-27 John David Anglin hppa64: Remove code to generate dot symbols for EPLT relocations 2025-10-27 John David Anglin bfd/ChangeLog: * elf64-hppa.c (USE_DOT_ELPT_PREFIX): Delete define. (allocate_global_data_opd): Remove dot code. (elf64_hppa_finalize_opd): Likewise. Update comments. 2025-10-27 John David Anglin hppa64: Handle R_PARISC_EPLT relocations for local symbols 2025-10-27 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf_hppa_final_link_relocate): Handle R_PARISC_EPLT relocations for local symbols. 2025-10-27 Simon Marchi gdb/dwarf: make some fields of dwarf2_per_cu private The comments on these fields mention that they should be private, but we can't. I think this comes from the time where dwarf2_per_cu was and had to remain POD. I don't think it's relevant anymore, there are other private fields anyway. Make them private. Change-Id: I1915ea531f42d685f68ff547833816906f79cd58 Approved-By: Tom Tromey 2025-10-27 Simon Marchi gdbsupport: bump unordered_dense library to 4.6.0 This version brings a fix made by Pedro [1] to fix compilation on some Windows systems. [1] https://github.com/martinus/unordered_dense/pull/132 Change-Id: I5cedec0e644074e2274346ecc1c73e5be00f84b0 Approved-By: Tom Tromey 2025-10-27 Nick Clifton Add more details to the linker documentation for the --hash-size and --max-cache-size options 2025-10-27 Guinevere Larsen gdb/help: Update help message for target record-core Before this commit, the help message for target record-core is the same as the help message for target record-full, which is the following: Log program while executing and replay execution from log. For one, having the same message is unhelpful, since it doesn't tell users what the difference between the two is. But, more importantly, that message seems to also be incorrect, since attempting to execute the inferior forward from a restored file past the end of history will crash GDB, since there isn't an actual live inferior to run. To fix this, the help text is updated to the following: Load a saved execution log, allowing replay of the last instructions This message doesn't imply that future execution is supported, while it shows that replaying within recorded instructions *is* supported. Approved-By: Tom Tromey 2025-10-27 GDB Administrator Automatic date update in version.in 2025-10-26 John David Anglin hppa64: Mostly fix symbol versioning support The dot prefix used for R_PARISC_EPLT relocations causes issues for symbol version support as no version section is defined for these symbols. This causes the linker to exit with an error. This change modifies the handling of EPLT relocations to use offsets relative to a __text_seg base symbol. This symbol is defined in the same way as the HP linker (a section symbol for the .dynamic section). This mostly fixes the symbol versioning support. There are still issues caused by the munging of the value and section of dynamic symbols. The value modifies the sorting of the dynamic table by number. The section changes the type of text symbols to data symbols. I don't think the section munging is actually needed but that's an issue for another patch. 2025-10-26 John David Anglin bfd/ChangeLog: * elf64-hppa.c (USE_DOT_ELPT_PREFIX): Define. (struct elf_link_hash_entry): Add text_segment field. (allocate_global_data_opd): Compute hppa_info. Condition old dot prefix code on USE_DOT_ELPT_PREFIX. Add new code to setup __text_seg hash table entry. (elf64_hppa_finalize_opd): Check hh. Rework to output relocation using __text_seg base. (elf64_hppa_finish_dynamic_sections): Remove duplicate comment. (elf_hppa_final_link_relocate): Move code to initialize the segment base values forward. 2025-10-26 John David Anglin hppa64: Fix linking of linux kernel Relocation handling is currently brokern for linker and ld script symbols. 2025-10-26 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_check_relocs): Don't set hh to NULL for linker and ld script symbols. 2025-10-26 GDB Administrator Automatic date update in version.in 2025-10-25 GDB Administrator Automatic date update in version.in 2025-10-24 H.J. Lu elf: Drop the FIXME comment in set_symbol_value Since commit aeaaa9af6359c8e394ce9cf24911fec4f4d23703 Author: H.J. Lu Date: Tue Sep 23 08:52:26 2025 +0800 elf: Return error on unsorted symbol table if not allowed returns false when get_link_hash_entry returns NULL, we can drop the FIXME comment now. PR ld/33450 * elflink.c (set_symbol_value): Drop the FIXME comment. 2025-10-24 Maciej W. Rozycki BFD: Fix function prototype breakage through stabs.c Update function prototype templates through stabs.c according to commit eb92a17c47ea ("bfd: move sec_info from ELF to general section struct"), which changed the generated prototypes in libbfd.h by hand rather than by remaking them properly from sources, and causing the build to fail as soon as libbfd.h has been regenerated. While at it remove an extraneous character introduced by the same commit to a comment for a new member of `struct bfd_section'. 2025-10-24 Guinevere Larsen gdb/reverse: update error message for "reverse-" commands Before this change, when a user tried to use a command that executes the inferior in reverse, they would get the following error message: Target multi-thread does not support this command. As an end-user with no knowledge of the internals of GDB would have as a best guess, that reverse execution as a whole would not be supported in their system (verified by asking a couple new users). This commit changes the message to avoid the internal terminology, and to add a hint that the user may need to create a recording somehow to be able to execute in reverse. Approved-By: Tom Tromey 2025-10-24 Tom Tromey Handle dynamic DW_AT_bit_size gnat-llvm will sometimes emit a structure that that uses DW_AT_bit_size with an expression to compute the bit size of a record. I believe this is a DWARF extension. This patch implements support for this in gdb. Reviewed-By: Keith Seitz 2025-10-24 Simon Marchi gdb: remove TYPE_DATA_LOCATION_ADDR macro Remove it in favor of using the dynamic_prop::const_val method directly. Change-Id: I8dea18d7f504d4ec982b6624342f7a301e8fd636 Approved-By: Tom Tromey 2025-10-24 Simon Marchi gdb: remove TYPE_DATA_LOCATION_KIND Remove it in favor of accessing the dynamic_prop::kind method directly. Change-Id: I8e5da4443b0df558286ce46eba5754c61f1b95db Approved-By: Tom Tromey 2025-10-24 Simon Marchi gdb: remove TYPE_DATA_LOCATION_BATON macro It is unused. Change-Id: Ide860825d8365cfa2370944725c7c999ec2a1cbd Approved-By: Tom Tromey 2025-10-24 Simon Marchi gdb: remove TYPE_*_PROP macros Remove the macros in favor of using the dyn_prop member function directly. Change-Id: I29758ea408610a2df0a6a226327d1f1af39a178d Approved-By: Tom Tromey 2025-10-24 Simon Marchi gdb: add gdb_rl_tilde_expand util Add gdb_rl_tilde_expand, a wrapper around readline's tilde_expand that returns a gdb::unique_xmalloc_ptr. Change all callers of tilde_expand to use gdb_rl_tilde_expand (even the couple of spots that release it immediatly, for consistency). This simplifies a few callers. The name gdb_tilde_expand is already taken by a home-made implementation in gdbsupport/gdb_tilde_expand.{h.cc}. I wonder if we could just use that one instead of readline's tilde_expand, but that's an orthogonal question. I don't know how they differ, and I don't want to introduce behavior changes in this patch. Change-Id: I6d34eef19f86473226df4ae56d07dc01912e3131 Approved-By: Tom Tromey 2025-10-24 Simon Marchi gdb: replace use of alloca with std::string in openp This makes the code simpler and hopefully safer. Change-Id: I30c7f0bc0c786621858d3f46d138f3b596dc49f5 Approved-By: Tom Tromey 2025-10-24 Rainer Orth ld: testsuite: xfail ld-elf/compress1a etc. on Solaris/sparcv9 [PR25802] A couple of tests FAIL on Solaris/sparcv9: FAIL: ld-elf/compress1a FAIL: ld-elf/compressed1a FAIL: ld-elf/eh5 FAIL: --gc-sections with multiple debug sections for a function section The symptom is always similar: compress1.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 against `.text' eh5.o:(.eh_frame+0x3e): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v0' defined in .text section in eh5.o all-debug-sections.o: in function `debug_info_main': (.debug_info.text.main+0x4): relocation truncated to fit: R_SPARC_32 against symbol `main' defined in .text.main section in all-debug-sections.o With the default Solaris/sparcv9 text address of 0x100000000, the relocations are out of the 32-bit range of R_SPARC_UA32 resp. R_SPARC_32, so the "relocation truncated to fit" errors are benign. One could avoid those by linking the affected tests with -Ttext=0x80000000, matching Solaris /usr/lib/ld/map.below4G, but that doesn't reflect real usage. Therefore this patch xfail's those tests. Tested on sparcv9-sun-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-07-30 Rainer Orth ld: PR ld/25802 * testsuite/ld-elf/compress1a.d: xfail on sparcv9-*-solaris2*. * testsuite/ld-elf/compressed1a.d: Likewise. * testsuite/ld-elf/eh5.d: Likewise. * testsuite/ld-gc/all-debug-sections.d: Likewise. 2025-10-24 Tom de Vries [gdb/testsuite] Remove gdb.base/gdbindex-stabs.exp On openSUSE Leap 15.6 x86_64 I ran into: .... (gdb) file gdbindex-stabs^M Reading symbols from gdbindex-stabs...^M warning: stabs debug information is not supported.^M (gdb) list stabs_function^M (gdb) FAIL: gdb.base/gdbindex-stabs.exp: list stabs_function ... Fix this by removing the test-case. Approved-By: Tom Tromey 2025-10-24 H. Peter Anvin z80, gas: follow historical assemblers and allow "op A,x" and "op x" For arithmetic ops, Z80 syntax wants "op A,x" for ADD, ADC and SBC and "op x" for SUB, AND, OR, XOR, and CP. Many historical assemblers simply treat them orthogonally; allowing but not requiring the "A," operand for any of these operations. This is widely used in legacy source code, and there is no reason not to. 2025-10-24 Jan Beulich bfd: section merging for PE/COFF images Leverage the generalized section merging to enable it also when linking PE/COFF images (from ELF objects). Sadly the previous hack in bfd_generic_get_relocated_section_contents() (from "bfd: generalize _bfd_elf_merge_sections()") is getting yet more bogus. 2025-10-24 Jan Beulich bfd: replace _bfd_merge_sections() hook with simple boolean There's no need for a hook; what needs doing is uniform, the question is only whether to perform any merging (i.e. whether other parts of a backend are capable of dealing with the effects). Where _bfd_nolink_bfd_merge_sections() was used, false is hardcoded. For ELF no real target override is permitted; true is hardcoded except for the cases where bfd_generic_merge_sections() was used as the hook function before. 2025-10-24 Jan Beulich bfd: generalize _bfd_elf_merge_sections() Except for the ELF class check, which isn't needed anymore when the generic linker knows how to deal with SEC_MERGE sections, there isn't anything substantially ELF-specific left in the function. This also eliminates the need for the "remove_hook" callback. As a result, section merging itself now works for mixed-class ELF input objects (issues with dropping of symbols and relocations that were there before for such cases remain present, though), i.e. the PR ld/19013 testcases need adjusting accordingly: Both now expect identical .rodata contents. While making the change, add another line of expected output, to properly match after "#...". Else a mismatch on the important line isn't properly visible in ld.log. In set_symbol_from_hash() additionally set BSF_GLOBAL when dealing with a defined symbol. Without that the if() body ahead of the one being added to default_indirect_link_order() would not be entered once previously undefined symbols become defined (suggesting that there is a pre-existing issue there). 2025-10-24 Jan Beulich bfd: simplify _bfd_{link,write,discard}_section_stabs() interface ... as well as that of _bfd_stab_section_offset(): As sec_info is now hanging off of sec, there's no need for the extra 4th parameter anymore. Along these line struct struct coff_section_tdata's stab_info member then isn't needed anymore either. Furthermore there also hasn't been a good reason to have the caller of _bfd_link_section_stabs() set sec_info_type. 2025-10-24 Jan Beulich bfd: simplify _bfd_merged_section_offset() interface As sec_info is now hanging off of sec, there's no need for the extra 3rd parameter anymore; all callers pass as 2nd argument the address of a section pointer that sec_info can be fetched from. 2025-10-24 Jan Beulich bfd: simplify _bfd_{add_merge,write_merged}_section() interface As sec_info is now hanging off of sec, there's no need for the extra 4th / 3rd parameter anymore. Along these line struct sec_merge_sec_info's psecinfo member then isn't needed anymore either. Furthermore there also hasn't been a good reason to have the caller of _bfd_add_merge_section() set sec_info_type. 2025-10-24 Jan Beulich bfd: move sec_info from ELF to general section struct This is in preparation of supporting section merging also when the output isn't ELF (or not of the same class). Note that it's also more consistent this way, as the related sec_info_type field also live in the same struct. bfd: move merge_info from ELF to general link hash table This is in prepration of supporting section merging also when the output isn't ELF (or not of the same class). 2025-10-24 Tom Tromey Remove get_context_stack_depth Nothing calls get_context_stack_depth, so this patch removes it. I looked at also removing context_stack::depth but apparently this is used in coffread.c, and I didn't want to figure out how to make it local to just that code. I'm checking this in as obvious. 2025-10-24 GDB Administrator Automatic date update in version.in 2025-10-24 Tom Tromey Use bool in buildsym This changes the buildsym code to use bool rather than int, where appropriate. Approved-By: Simon Marchi 2025-10-24 Tom Tromey Remove buildsym_compunit::end_compunit_symtab_with_blockvector This patch removes buildsym_compunit::end_compunit_symtab_with_blockvector. This method is only called in one spot and the two methods can easily be combined. Approved-By: Simon Marchi 2025-10-23 Jan Vrany gdb: change find_pcs_for_symtab_line() to return entries instead of PCs This commit changes find_pcs_for_symtab_line() to return complete linetable entries instead of just PCs. This is a preparation for adding more attributes to gdb.LinetableEntry objects. I also renamed the function to find_linetable_entries_for_symtab_line() to better reflect what it does. Approved-By: Tom Tromey 2025-10-23 Tom Tromey Remove iterate_over_symbols_terminated iterate_over_symbols_terminated only has a single caller, in ada-lang.c. It's simpler to handle this case directly there. Approved-By: Simon Marchi 2025-10-23 Tom Tromey Free multidicts from blockvector Currently, nothing in the tree ever calls mdict_free. However, code does heap-allocate some multidicts. A simple way to see this is to use valgrind, run "gdb -readnow" on the executable created by gdb.dwarf2/struct-with-sig.exp, and then use "file" to clear the objfile list. This yields: ==1522843== 144 (16 direct, 128 indirect) bytes in 1 blocks are definitely lost in loss record 905 of 3,005 ==1522843== at 0x4843866: malloc (vg_replace_malloc.c:446) ==1522843== by 0x48E397: xmalloc (alloc.c:52) ==1522843== by 0x59DE66: multidictionary* xnew() (poison.h:102) ==1522843== by 0x59CFF4: mdict_create_hashed_expandable(language) (dictionary.c:965) ==1522843== by 0x50A269: buildsym_compunit::finish_block_internal(symbol*, pending**, pending_block*, dynamic_prop const*, unsigned long, unsigned long, int, int) (buildsym.c:221) ==1522843== by 0x50AE04: buildsym_compunit::end_compunit_symtab_get_static_block(unsigned long, int, int) (buildsym.c:818) ==1522843== by 0x50C4CF: buildsym_compunit::end_expandable_symtab(unsigned long) (buildsym.c:1037) ==1522843== by 0x61DBC6: process_full_type_unit (read.c:4970) This patch fixes the leaks by calling mdict_free when a blockvector is destroyed. Approved-By: Simon Marchi 2025-10-23 Tom Tromey Two bug fixes in mdict_free A heap-allocated multidictionary should be freed by calling mdict_free. However, while this function does free the contents of the dictionary, it neglects to free the dictionary itself. There's also a second bug, which is that if a multidictionary is created with no dictionaries, gdb will crash on the first line of mdict_free: enum dict_type type = mdict->dictionaries[0]->vector->type; So, this patch also adds the type to struct multidictionary, avoiding this problem. Note that this does not increase the structure size on x86-64, because the new member fits into the padding. Approved-By: Simon Marchi 2025-10-23 Tom Tromey Remove Python API checker defines The GCC plugin that implements the Python API checker does not appear to really be maintained. And, as far as I know, it never really worked for C++ code anyway. Considering those factors, and that no one has tried to run it in years, I think it's time to remove the macros from the gdb source. Approved-By: Simon Marchi 2025-10-23 Tom Tromey Remove Py_TPFLAGS_CHECKTYPES According to 'git annotate', the Py_TPFLAGS_CHECKTYPES was added to python-internal.h way back when gdb was first ported to Python 3. It was a compatibility fix for Python 2. This is not needed any more, because Python 2 is no longer supported. This patch removes the vestiges. Approved-By: Simon Marchi 2025-10-23 Jan Vrany gdb: update mdebugread.c to use blockvector::block_less_than This commit updates mdebugread.c to use common blockvector ordering predicate. It also changes the code to use std::stable_sort as in buildsym.c. This is probably not necessary but should not hurt and makes block sorting code more consistent. Approved-By: Tom Tromey 2025-10-23 Jan Vrany gdb: add block ordering predicate for ordering blocks in blockvector This commit adds blockvector::block_less_than() predicate that defines required ordering of blocks within blockvector. It orders blocks so that blocks with lower start address come before blocks with higher start address. If two blocks start at the same address, enclosing (larger) block should come before nested (smaller) block. This ordering is depended upon in find_block_in_blockvector(). Although its comment did not say so, find_block_in_blockvector() is called from blockvector_for_pc_sect() which is explicit about it. While at it, I changed the comment of find_block_in_blockvector() to say so explicitly too. As Andrew pointed out, buildsym.c sorts block slightly differently, taking only the start address into account. The comment there says blocks with same start address should not be reordered as they are in correct order already and that order is needed. It is unclear to me if buildsym.c arranges blocks starting at the same address in required order before sorting them or this happens "by chance". I did modify buildsym_compunit::make_blockvector() to assert blocks are properly ordered and running testsuite did not show any regressions. Approved-By: Tom Tromey 2025-10-23 Jan Vrany gdb: use std::vector<> to hold on blocks in struct blockvector This patch changes blockvector to be allocated on the heap (using 'new') and changes internal implementation to use std::vector<> rather than flexible array to add blocks to existing blockvector. This is needed for lazy CU expansion and for Python API to build objfiles, compunits and symtabs dynamically (similarly to JIT reader API). The downside is higher memory consumption. The size of std::vector is 24 bytes (GCC 14) compared to 8 bytes used currently to store the number of blocks (m_num_blocks). Stopping gdb at its main(), followed by "maint expand-symtabs" results in 4593 compunit symtabs so in this case the overhead is 16*4593 = 73488 bytes which I hope is acceptable. While at it, add blockvector::append_block() to add more block at the end of block vector. This is currently used only in mdebugread.c. Approved-By: Tom Tromey 2025-10-23 GDB Administrator Automatic date update in version.in 2025-10-22 John David Anglin hppa64: Fix bfd_put_xx bfd argument in elf_hppa_final_link_relocate 2025-10-22 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf_hppa_final_link_relocate): Change bfd_put_32 and bfd_put_64 bfd argument from input_bfd to output_bfd. 2025-10-22 Tom Tromey Avoid c-ctype.h in libinproctrace.so libinproctrace.so doesn't link against gnulib, and some versions of clang won't inline the c-ctype.h functions. This causes link failures. This patch works around the problem by reverting to in this case. Tested-By: Guinevere Larsen 2025-10-22 timurgol007 gdb/record: Speeding up recording in RISC-V I measured that removing saving mem chunks and regs to std::vector before calling API functions speeds up stepping up to 15%, so I added this optimization (as Guinevere Larsen recommended in initial support). It turns out that after this, the m_record_type and m_error_occured no longer needed, so I removed them too. Approved-By: Guinevere Larsen 2025-10-22 Tom de Vries [gdb/testsuite] Simplify gdb.cp/local-static.exp Simplify test-case gdb.cp/local-static.exp in the following way. First rewrite this uplevel into a more usual form: ... -set print_quoted_re [uplevel 1 "subst_vars \"$print_quoted_re\""] +set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]] ... This requires us to use "subst -nocommands" instead of subst_vars, to allow backslash substitution, which previously was happening implicitly because of the way uplevel was used. Then, declare globals hex and syntax_re, such that we no longer have to use uplevel: ... -set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]] +set print_quoted_re [subst -nocommands $print_quoted_re] ... Finally, stop applying backslash substitution, simplifying cxx_scopes_list and c_scopes_list: ... -set print_quoted_re [subst -nocommands $print_quoted_re] +set print_quoted_re [subst_vars $print_quoted_re] ... While we're at it, simplify some regexps using string_to_regexp in a few places. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-10-22 Maximilian Bosch gdb: fix loading compressed scripts from `.debug_gdb_scripts`-section The function `gdb_bfd_get_full_section_contents` doesn't implement decompressing debug sections. This regresses loading `.debug_gdb_scripts`-section from ELFs that were built with `-ggdb -Wa,--compress-debug-sections` giving the following warnings on load: warning: BFD: /home/ma27/.cache/debuginfod_client/8284e3a74f442359679ee97e96ee1c434e4479b7/debuginfo: unable to get decompressed section .debug_gdb_scripts warning: Couldn't read .debug_gdb_scripts section of /home/ma27/.cache/debuginfod_client/8284e3a74f442359679ee97e96ee1c434e4479b7/debuginfo The problem can be reproduced with a `test.cc` like this: __asm__(".pushsection \".debug_gdb_scripts\", \"MS\",%progbits,1\n" ".ascii \"\\4gdb.inlined-script.BOOST_OUTCOME_INLINE_GDB_PRETTY_PRINTER_H\\n\"\n" ".ascii \"import gdb.printing\\n\"\n" ".ascii \"import os\\n\"\n" /* a sufficiently long script such that it gets actually compressed */ ".byte 0\n" ".popsection\n"); #include int main(void) { std::cout << "hello world\n"; return 0; } I compiled the file with `g++ test.cc -o test-program -ggdb -Wa,--compress-debug-sections` (GCC version 14.3.0). As suggested, this refactors gdb_bfd_get_full_section_contents to use bfd_get_full_section_contents which implements decompression. Approved-By: Tom Tromey 2025-10-22 Tom de Vries [gdb] Drop gdb.stabs exclude from tclint.toml Now that gdb/testsuite/gdb.stabs has been removed, drop the corresponding exclude from gdb/tclint.toml. Tested by running "pre-commit run --all-files". 2025-10-22 Tom de Vries [gdb/testsuite] Add proc subst_vars Add proc subst_vars, an alias of subst -nobackslashes -nocommands. I've used tailcall to implement this: ... proc subst_vars { str } { tailcall subst -nobackslashes -nocommands $str } ... but I found that this also works: ... proc subst_vars { str } { return [uplevel 1 [list subst -nobackslashes -nocommands $str]] } ... I've found other uses of subst that don't add "-nobackslashes -nocommands", but really only use subst to do variable substitution. Also use subst_vars in those cases. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-10-22 Tom de Vries [gdb/contrib] Handle unknown attribute in dwarf-to-dwarf-assembler.py I ran gdb/contrib/dwarf-to-dwarf-assembler.py on a hello world compiled with gcc 15, and ran into: ... Traceback (most recent call last): File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 642, in main(sys.argv) ~~~~^^^^^^^^^^ File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 638, in main generator.generate() ~~~~~~~~~~~~~~~~~~^^ File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 610, in generate self.generate_die(die, indent_count) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^ File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 589, in generate_die die_lines = die.format(self.dwarf_parser.offset_to_die, indent_count) File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 279, in format return "\n".join(self.format_lines(offset_die_lookup, indent_count)) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 376, in format_lines inner_lines = super().format_lines(offset_die_lookup, indent_count + 1) File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 251, in format_lines attr_line = attr.format( offset_die_lookup, indent_count=indent_count + 1 ) File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 199, in format s += self.name + " " ~~~~~~~~~~^~~~~ TypeError: unsupported operand type(s) for +: 'int' and 'str' ... because of trying to print DWARF v6 attributes DW_AT_language_name (0x90) and DW_AT_language_version (0x91). Fix this by printing the number if the name is not known: ... {DW_AT_0x90 3 DW_FORM_data1} {DW_AT_0x91 202311 DW_FORM_data4} ... 2025-10-22 Tom de Vries [gdb/contrib] Fix errno.EOPNOTSUP in dwarf-to-dwarf-assembler.py When running dwarf-to-dwarf-assembler.py without arguments, I run into: ... $ ./gdb/contrib/dwarf-to-dwarf-assembler.py Usage: python ./asm_to_dwarf_assembler.py Traceback (most recent call last): File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 621, in main filename = argv[1] ~~~~^^^ IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 642, in main(sys.argv) ~~~~^^^^^^^^^^ File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 625, in main sys.exit(errno.EOPNOTSUP) ^^^^^^^^^^^^^^^ AttributeError: module 'errno' has no attribute 'EOPNOTSUP'. Did you mean: 'EOPNOTSUPP'? ... Fix this by using errno.EOPNOTSUPP. 2025-10-22 Pietro Monteiro objcopy: Don't add zstd to the debug compression options if not available If zstd is not available or was intentionally disabled by the user don't add it to the list of the available options to compress debug sections when showing usage. binutils/ * objcopy.c (copy_usage): Only output --compress-debug-sections=zstd if HAVE_ZSTD. 2025-10-22 GDB Administrator Automatic date update in version.in 2025-10-21 Luis Machado AArch64: Fix SME za register description Peter Maydell and Vacha Bhavsar pointed out that we have an incorrect description of the SME za register in the documentation. It is currently described as a vector of SVL x SVL bytes, but that is incorrect. What we really have is a 2-dimensional array of bytes, with each dimension having size SVL. Change the documentation to reflect that. Approved-By: Eli Zaretskii 2025-10-21 Maciej W. Rozycki LD/testsuite: Add tests for mapless archive rejection Verify that archives are rejected in the link, regular and thin, that have no symbol map included. Exclude XCOFF targets from verification which have handling for such archives implemented and therefore accept them. These targets will be handled with a follow-up change. 2025-10-21 Maciej W. Rozycki LD/testsuite: Add tests for archive handling Add basic verification for archives to work, regular and thin, in the link. Refer to PR binutils/33484 and PR binutils/33485 for targets that fail these basic checks, where `ar' fails to add subsequent members to the archive or fails to add symbols from subsequent members to the map respectively, for thin archives. NB symbol names chosen such as to avoid a clash with Z80 CPU registers. 2025-10-21 Guinevere Larsen gdb: remove support for dbx from GDB With the removal of stabs support, reading a dbx inferior has become a no-op and GDB is unable to perform sybmolic debugging in such inferiors. As such, this commit removes the files that work on it with spotty support. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: Fully remove stabs code from GDB This commit is the last in the series removing GDB's support for stabs. It removes the stabsread.{c|h} files, and removes the last usage of stabsread stuff in buildsym. Notably, the header file gdb-stabs.h remains in the tree as it is misnamed at this point - it is used for reading dbx objfiles. It (and dbxread) will be removed in a future commit. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: Remove stabs support from XCOFF inferiors This commit is the second to last in the series fully removing support for stabs in GDB, removing it from XCOFF inferiors. According to IBM's AIX documentation[1], xcoff binaries can only have stabs or DWARF debug info, meaning removing stabs seems pretty trivial, as anything that isn't related to setting base information on the objfile or reading dwarf can be removed. The unfortunate part of this removal is that XCOFF minimal symbols are encoded in stabs, so if an inferior has not been compiled with dwarf debuginfo, GDB will only be able to do assembly-level debugging. Due to this, the xcoff reader now emits a warning if no dwarf is read, saying: "No usable debug information found". This change would also add a lot of regressions to to AIX, so the gdb_compile proc has been changed to not work when a test tries to compile a test with nodebug. As a sidenote, gdb-stabs.h can just be removed from rs6000-aix-nat, as none of the structs or macros defined in the header are used in the nat file, so that is an unnecessary include. This commit introduces some known regressions when testing GDB in AIX systems. The main ones are: * inferior function calls now crash with a corrupted stack. This seems to be some fault of dwarf in explaining how to correctly set the frame for a function. * fortran tests can't runto_main: the fortran compiler does not add any symbol for MAIN__ in the dwarf information, only in stabs, so the fortran_runto_main proc can't set the breakpoint correctly. * When dealing with c++ class methods, there are cases when we fail to properly recognize a method call as a new function. * When dealing with c++ virtual inheritance, GDB has issues finding a derived class's members when it has been downcast to a base class. [1] https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: Remove stabs support for COFF files This commit continues the removal of stabs by removing support from coff inferiors. This is trivial for the most part, just a removal of code setting things only relevant for stabs, with one exception. The global variables symnum and within_function were introduced to coffread.c (and within_function was converted to boolean). I looked into making them parameters to the relevant function, but this would require changes to several otherwise untouched functions, so I kept them as globals instead. Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: Remove stabs support from dbx This commit makes it so reading dbx inferiors will not read stabs debuginfo from the inferiors. This has the side effect of making reading DBX inferiors a noop. It will be removed in a future commit, however, the present series of commit is focused on just removing stabs. Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: Remove stabs support from ELF files This commit makes it so that GDB won't read stabs information from ELF files. If stabs is detected in an ELF file, the reader now warns the user that stabs is not supported. This test would cause two new failures in the test gdb.stabs/weird.exp (that surprisingly didn't happen in the mips commit). Rather than fixing the test that'll be removed soon, I just removed the test instead. Approved-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb/mdebug: Remove stabs support from mips inferiors Ostensibly, the mdebugread.c is about reading debug information in the ecoff format, but it also supports stabs-in-ecoff according to comments in there, and also relied in some stabs facilities for ecoff reading itself. This commit takes the first step in removing stabs support by removing those dependencies from mdebug. And in order to support stabs-in-ecoff, mipsread would also call stabsread_new_init. Removing stabs-in-ecoff is trivial, as the code was well demarcated with comments mentioning where stabs was read. Plus the call to stabsread_new_init in mipsread can be trivially removed. Another simple removal was the dependence on stabs_end_psymtabs: because the local variables dependencies_used and includes_used were only touched by stabs-reading code, they are always 0 in the new version, which means we can find the exact code path that'd be followed in stabs_end_psymtab and move the relevant lines to mdebug instead. After all those, the last remaining dependency is when reading a fortran common block from an inferior compiled by SGI fortran compilers (and maybe more). The block could have no address, meaning it'd need to be fixed after all the minimal symbols have been read. This was done by adding the symbol to the stabs global_sym_chain, then calling scan_file_globals to fix them up. This commit copies all the necessary code for handling the fortran symbols onto mdebug, technically making some code duplication, but since stabsread will be removed soon, this shouldn't be too concerning. This change was tested in the compile farm's mips64 machine (number 230), where it actually seems to have solved some 50 failures in the testsuite, not including changes in tests from gdb.threads, as those are often very racy. I'm not sure if these were true fixes or racy cases, but since the new version has no newly introduced fails, only fewer of them, I'm inclined to think this change is at least harmless. Acked-By: Tom Tromey 2025-10-21 Guinevere Larsen gdb: move some stabs functions to gdb/buildsym-legacy.h The gdb/stabsread.h and .c files define 2 things that, while originally intended only for stabs reading, actually end up being used for coff, ecoff and maybe more debuginfo formats. That is the function "hashname", and the macro HASHSIZE. Both are used for small hashtables when reading some symbols with incomplete information. With the upcoming removal of stabs code, this code should be moved somewhere, and the location that looked most reasonable was gdb/buildsym-legacy. No change in behavior is expected after this commit. Approved-By: Tom Tromey 2025-10-21 Simon Marchi gdb/testsuite/gdb.python/py-symbol.exp: accept either rr static symbol when calling lookup_static_symbol Since commit dad36cf91992 ("gdb/dwarf: use dynamic partitioning for DWARF CU indexing"), we get the intermittent failures: python print (gdb.lookup_static_symbol ('rr').line) 18 (gdb) FAIL: gdb.python/py-symbol.exp: print line number of rr python print (gdb.lookup_static_symbol ('rr').value ()) 99 (gdb) FAIL: gdb.python/py-symbol.exp: print value of rr The situation is: - The program isn't running. - Two compilation units define a static symbol named `rr`. - The test does: gdb.lookup_static_symbol ('rr') The test expects this to return one specific (out of the two) `rr` static symbols. Since dad36cf91992, the call sometimes returns the wrong symbol. The documentation for gdb.lookup_static_symbol says this: There can be multiple global symbols with static linkage with the same name. This function will only return the first matching symbol that it finds. Which symbol is found depends on where GDB is currently stopped, as GDB will first search for matching symbols in the current object file, and then search all other object files. If the application is not yet running then GDB will search all object files in the order they appear in the debug information. cooked_index_functions::search searches index shards linearly and returns the first matching symbol. Before dad36cf91992, the work was split statically among threads, so symbols would end up in shards deterministically. Since the first part of the debug info ends up in the first shard, it happens to work as described in the doc. Since dad36cf91992, symbols end up in random shards, based on which thread happened to pop their CU from the work queue. I don't think that specifying which of the multiple matching static symbols is returned is really useful, as it unnecessarily restricts the implementation. If multiple static symbols match the criteria, I think it makes sense that you'll get an unspecified one. Code that needs to deal with the possibility of multiple static symbols of the same name should use gdb.lookup_static_symbols. I propose to remove this guarantee from gdb.lookup_static_symbol. I understand that this is a breaking change, but I think it's easy enough to deal with it. Update the test to accept either symbol. Update the doc to say that an unspecified symbol will be returned if the program is not running and there are multiple matching symbols. The previous text also seemed a bit wrong about its use of the term "object file". GDB searches a static symbol for the current compilation unit first. It then falls back to searching all symbols. Change-Id: I22f81c186b1483a488ea7614fb81fd102db3c7f1 Approved-By: Tom Tromey Reviewed-By: Tom de Vries Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33518 Approved-By: Andrew Burgess Reviewed-By: Eli Zaretskii 2025-10-21 William Ferreira Create script to convert old tests into Dwarf::assemble calls. PR testsuite/32261 requests a script that could convert old .S-based tests (that were made before dwarf.exp existed) into the new Dwarf::assemble calls in Tcl. This commit is an initial implementation of such a script. Python was chosen for convenience, and only relies on a single external library. Usage: the script operates not on .S files, but on ELF files with DWARF information. To convert an old test, one must run said test via `make check-gdb TESTS=testname` in their build directory. This will produce, as a side effect, an ELF file the test used as an inferior, at gdb/testsuite/outputs/testname/testname. This ELF file is this script's input. Reliability: not counting the limitations listed below, the script seems functional enough to be worthy of discussion in the mailing list. I have been testing it with different tests that already use Dwarf::assemble, to see if the script can produce a similar call to it. Indeed, in most cases that I've tested (including some more complex ones, marked with an asterisk below) it is able to produce comparable output to the original exp file. Of course, it can't reproduce the complex code *before* the Dwarf::assemble call. Values calculated then are simply inlined. The following .exp files have been tried in this way and their outputs highly resemble the original: - gdb.dwarf2/dynarr-ptr - gdb.dwarf2/void-type - gdb.dwarf2/ada-thick-pointer - gdb.dwarf2/atomic-type - gdb.dwarf2/dw2-entry-points (*) - gdb.dwarf2/main-subprogram The following .exp files work, with caveats addressed in the limitations section below. - gdb.dwarf2/cpp-linkage-name - Works correctly except for one attribute of the form SPECIAL_expr. - gdb.dwarf2/dw2-unusual-field-names - Same as above, with two instances of SPECIAL_expr. - gdb.dwarf2/implptr-optimized-out - Same as above, with two instances of SPECIAL_expr. - gdb.dwarf2/negative-data-member-location - Same as above, with one instance of SPECIAL_expr. The following .exp files FAIL, but that is expected: - gdb.dwarf2/staticvirtual.exp - high_pc and low_pc of subprogram "~S" are hardcoded in the original .exp file, but they get replaced with a get_func_info call. Since the function S::~S is not present in the original, get_func_info will fail. The following .exp files DO NOT WORK with this script: - gdb.dwarf2/cu-no-addrs - `aranges` not supported. - Compile unit high_pc and low_pc hardcoded, prone to user error due to forgetting to replace with variables. - gdb.dwarf2/dw2-inline-stepping - Same as above. - gdb.dwarf2/fission-relative-dwo - `fission` not supported. - gdb.dwarf2/dw2-prologue-end and gdb.dwarf2/dw2-prologue-end-2 - Line tables not supported. Currently the script has the following known limitations: - It does not support line tables. - It does not use $srcfile and other variables in the call to Dwarf::assemble (since it can't know where it is safe to substitute). - It does not support "fission" type DWARFs (in fact I still have no clue what those are). - It does not support cu {label LABEL} {} CUs, mostly because I couldn't find the information using pyelftools. - It sometimes outputs empty CUs at the start and end of the call. This might be a problem with my machine, but I've checked with DWARF dumps and they are indeed in the input ELF files generated by `make check-gdb`. - It does not support attributes with the forms DW_FORM_block* and DW_FORM_exprloc. This is mostly not a concern of the difficulty of the implementation, but of it being an incomplete feature and, thus, more susceptible to users forgetting to correct its mistakes or unfinished values (please see discussion started by Guinevere at comment 23 https://sourceware.org/bugzilla/show_bug.cgi?id=32261#c23). The incompleteness of this feature is easy to demonstrate: any call to gdb_target_symbol, a common tool used in these attributes, needs a symbol name that is erased after compilation. There is no way to guess where that address being referenced in a DW_OP_addr comes from, and it can't be hard coded since it can change depending on the machine compiling it. Please bring up any further shortcomings this script may have with your expectations. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32261 Approved-By: Tom Tromey 2025-10-21 Simon Marchi gdb: remove return value of set_current_source_symtab_and_line It is never used. Change-Id: I9bbc87a232a2d0f074fefa08f3435aac82cd3dcf Approved-By: Tom Tromey 2025-10-21 Alan Modra Correct _bfd_elf_section_for_symbol This function was added in commit 2f0c68f23bb3 as part of the compact EH support. By the comments it looks like to code was copied from bfd_elf_reloc_symbol_deleted_p without sufficient editing, and would only work for local syms due to the discarded_section test left in place for global syms. Fix that, and remove the discard param. * elf-bfd.h (_bfd_elf_section_for_symbol): Update prototype. * elf-eh-frame.c (_bfd_elf_parse_eh_frame_entry): Adjust. * elflink.c (_bfd_elf_section_for_symbol): Remove "discard". Don't test for discarded_section. 2025-10-21 GDB Administrator Automatic date update in version.in 2025-10-21 Tom Tromey Only set call site if not empty In an earlier discussion, I noted that most compunit_symtabs do not have a call-site hash table, so inlining the object into compunit_symtab did not make sense. It turns out that this is not entirely true -- while most compunit_symtabs do not have any data in this object, the object itself is always created. This in turn is a regression introduced by commit de2b4ab5 ("Convert dwarf2_cu::call_site_htab to new hash table"). This patch fixes the issue by arranging to only store a call-site hash table when it is non-empty. Approved-By: Simon Marchi 2025-10-20 Simon Marchi gdb: remove unused includes in source.c These two are reported as unused by clangd. Change-Id: I30fb0b986efd27fc6a24b855aeec86c2720ac934 2025-10-20 Simon Marchi gdb, gdbserver, gdbsupport: trim trailing whitespaces I noticed my IDE (VSCode) starting to automatically trim trailing whitespaces on save, despite the setting for it being disabled. I realized that this is because the .editorconfig file now has trim_trailing_whitespace = true for many file types. If we have this EditorConfig setting forcing editors to trim trailing whitespaces, I think it would make sense to clean up trailing whitespaces from our files. Otherwise, people will always get spurious whitespace changes when editing these files. I did a mass cleanup using this command: $ find gdb gdbserver gdbsupport -type f \( \ -name "*.c" -o \ -name "*.h" -o \ -name "*.cc" -o \ -name "*.texi" -o \ -name "*.exp" -o \ -name "*.tcl" -o \ -name "*.py" -o \ -name "*.s" -o \ -name "*.S" -o \ -name "*.asm" -o \ -name "*.awk" -o \ -name "*.ac" -o \ -name "Makefile*" -o \ -name "*.sh" -o \ -name "*.adb" -o \ -name "*.ads" -o \ -name "*.d" -o \ -name "*.go" -o \ -name "*.F90" -o \ -name "*.f90" \ \) -exec sed -ri 's/[ \t]+$//' {} + I then did an autotools regen, because we don't actually want to change the Makefile and Makefile.in files that are generated. Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691 2025-10-20 Simon Marchi gdb: rename find_line_pc_range -> find_pc_range_for_sal Change-Id: Ibd1692292dfcad088ae74b797c38a483080f2ec1 Approved-by: Kevin Buettner gdb: rename find_pc_line_symtab -> find_symtab_for_pc Change-Id: I2940e0f80c4b1d63fb1aee85f5753df5fbf4326a Approved-by: Kevin Buettner gdb: rename find_pc_sect_line -> find_sal_for_pc_sect Change-Id: I9c2a72de57a4ea9c316fc949db4fb0bf7f78eb4b Approved-by: Kevin Buettner gdb: rename find_pc_line -> find_sal_for_pc Change-Id: I293b655e8753fc650f3ec10bb4e34a9632d8e377 Approved-by: Kevin Buettner gdb: rename find_pc_line_pc_range -> find_line_pc_range_for_pc Change-Id: Iff7590d9d4e914ae74ba4818f338e911f7ab5416 Approved-by: Kevin Buettner gdb: rename find_pc_sect_compunit_symtab -> find_compunit_symtab_for_pc_sect Change-Id: Idb4941f6a24ddd97ee98d35a40bfbe7ceba82ec1 Approved-by: Kevin Buettner gdb: rename find_pc_compunit_symtab -> find_compunit_symtab_for_pc Change-Id: I6eef5db4ae55f3eb0415768207ae3c26b305f773 Approved-by: Kevin Buettner 2025-10-20 Simon Marchi gdb: rename find_pc_sect_containing_function -> find_symbol_for_pc_sect_maybe_inline Use the suffix "maybe_inline" to differentiate it from find_symbol_for_pc_sect. find_symbol_for_pc_sect_maybe_inline can return symbols for inline functions, while find_symbol_for_pc_sect doesn't. Change-Id: I6c4ef961383429ee26c8fcc0cc5df2e4e1e24959 Approved-by: Kevin Buettner 2025-10-20 Simon Marchi gdb: rename find_pc_sect_function -> find_symbol_for_pc_sect Change-Id: I24d584024053655b469cabc78809abf05f0f0f02 Approved-by: Kevin Buettner gdb: rename find_pc_function -> find_symbol_for_pc Change-Id: I2069be1a6d7c3250cf330574c941bf851c89bab4 Approved-by: Kevin Buettner 2025-10-20 Simon Marchi gdb: fix slowdown during skeletonless type units processing My commit 6474c699a525 ("gdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset)") introduced a pretty bad performance regression in the "skeletonless type units" step. I have a pretty big executable (Blender) compiled with -gsplit-dwarf (to generate .dwo files) and -fdebug-types-section (to generate type units). Before the offending commit: Time for "DWARF skeletonless type units": wall 29.126, user 28.507, sys 0.497, user+sys 29.004, 99.6 % CPU ... and after: Time for "DWARF skeletonless type units": wall 120.768, user 119.543, sys 0.651, user+sys 120.194, 99.5 % CPU The reason for the slowdown is that add_type_unit now inserts type units at the right place in the all_units vector to keep it sorted. These repeated insertions in the middle of the vector require shifting a lot of elements and end up taking a lot of time. This patch fixes it by doing just one sort at the end of process_skeletonless_type_units. The responsibility of keeping the all_units sorted is delegated to the callers of add_type_unit. The other two callers call finalize_all_units right after calling add_type_unit. One drawback that is probably not a real one: in process_skeletonless_type_unit, we call process_type_unit. If something in there needs to look up another type unit by (section, offset), it wouldn't find it. I don't think that's a real issue though, as type units are typically self contained. If a type unit needs to refer to a type defined in another type unit, it would do so by signature, with DW_FORM_ref_sig8. And during the indexing phase, I don't think we even look at the DW_AT_type of things anyway. With this patch applied, I am back to: Time for "DWARF skeletonless type units": wall 29.277, user 28.632, sys 0.521, user+sys 29.153, 99.6 % CPU I would like to cherry pick this patch to GDB 17, to avoid shipping GDB 17 with the performance regression. Change-Id: I2a5b89ebca9e1a4e6248032e144520c9a579f47a Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33526 Approved-By: Tom Tromey Reviewed-By: Andrew Burgess 2025-10-20 Tom de Vries [gdb/testsuite] Use gnat_version_compare in gdb.ada Convert the remaining uses of gcc_major_version in gdb.ada. Tested on x86_64-linux with gcc 7, gcc 13 and gcc 15. Approved-By: Tom Tromey 2025-10-20 Kévin Le Gouguec Drop bashism from configure script Results of evaluating 'test "no" == yes' in non-Bash shells range from unfortunate (dash: "test: no: unexpected operator") to comically wrong (AdaCore's gsh: returns 0). 2025-10-20 Nick Alcock libctf: tests: fix clang 21 uninitialized variable warning The warning is spurious (the variable is unused in this situation), but clang cannot know that. libctf/ChangeLog: * testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Initialize dummy variable. 2025-10-20 Nick Alcock libctf: fix unnecessary glibcism in testsuite libctf-regression/open-error-free.c #defines _GNU_SOURCE at its top. This is already done by config.h if necessary: drop it. libctf/ChangeLog: * testsuite/libctf-regression/open-error-free.c: Drop unnecessary system-dependent #define. 2025-10-20 Bruce McCulloch libctf: fix libctf/testsuite/libctf-lookup/multidim-array on older arches This patch inverts the ordering of nelems on multidimensional arrays on versions of gcc without the CTF_F_ARRNELEMS flag. This allows those systems which run older gcc to pass the test without modification to the multidim-array.lk file. libctf/ChangeLog: * testsuite/libctf-lookup/multidim-array.c: Test fixes. 2025-10-20 Tom de Vries [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux On ppc64-linux, with test-case gdb.tui/resize-3.exp I run into: ... FAIL: gdb.tui/resize-3.exp: after resize: Assembler for foo is shown ... because the disassembly window shows: ... 0 +----------------------------------------------------------------------+ 1 | 0x10000093c <.foo> std r31,-8(r1) | 2 | 0x100000940 <.foo+4> stdu r1,-64(r1) | 3 | 0x100000944 <.foo+8> mr r31,r1 | 4 |B+>0x100000948 <.foo+12> li r9,0 | ... and we grep for " [gdb/testsuite] Use with_cwd in gdb.src/pre-commit.exp I ran the testsuite and ran into ERRORs in two test-cases, gdb.trace/save-trace.exp and gdb.threads/tls-sepdebug.exp. Recently added test-case gdb.src/pre-commit.exp changes the working directory, and the change stays active in following test-cases, which was not the intention. Fix this using with_cwd. Tested on x86_64-linux. 2025-10-20 Indu Bhagat libsframe: use const qualifier for sframe_header object ...where applicable. For the static functions that do not modify the sframe_header object, use const. Ditto for local vars. Reviewed-by: Jens Remus libsframe/ * sframe.c (sframe_get_hdr_size): Use const qualifier. (sframe_header_sanity_check_p): Likewise. (flip_sframe): Use const for local var. (sframe_decode): Likewise. While at it, use similar looking var name. (sframe_decoder_get_hdr_size): Use const for local var. (sframe_decoder_get_abi_arch): Likewise. (sframe_decoder_get_version): Likewise. (sframe_decoder_get_fixed_fp_offset): Likewise. (sframe_decoder_get_fixed_ra_offset): Likewise. (sframe_get_funcdesc_with_addr_internal): Likewise. (sframe_decoder_get_num_fidx): Likewise. (sframe_encoder_get_hdr_size): Likewise. (sframe_encoder_get_abi_arch): Likewise. (sframe_encoder_get_version): Likewise. (sframe_encoder_get_num_fidx): Likewise. 2025-10-20 Indu Bhagat include: sframe: rename sframe_func_desc_entry to use an explicit v2 As SFrame format evolves, this will be useful to refer to v2 on-disk layout directly as the format evolves. Reviewed-by: Jens Remus include/ * sframe.h (struct sframe_func_desc_entry): Rename to tag v2. 2025-10-20 GDB Administrator Automatic date update in version.in 2025-10-19 Tom de Vries [gdb/testsuite] Add gdb.src/pre-commit.exp Add a test-case running the pre-commit hooks, as suggested here [1]. [1] https://sourceware.org/pipermail/gdb-patches/2025-October/221441.html 2025-10-19 GDB Administrator Automatic date update in version.in 2025-10-18 GDB Administrator Automatic date update in version.in 2025-10-17 Tom de Vries [gdb/python] Use PyConfig for python 3.9 On ppc64le-linux (AlmaLinux 9.6) with python 3.9 and test-case gdb.python/py-failed-init.exp I run into: ... builtin_spawn $gdb -nw -nx -q -iex set height 0 -iex set width 0 \ -data-directory $build/gdb/data-directory -iex set interactive-mode on^M Python path configuration:^M PYTHONHOME = 'foo'^M PYTHONPATH = (not set)^M program name = '/usr/bin/python'^M isolated = 0^M environment = 1^M user site = 1^M import site = 1^M sys._base_executable = '/usr/bin/python'^M sys.base_prefix = 'foo'^M sys.base_exec_prefix = 'foo'^M sys.platlibdir = 'lib64'^M sys.executable = '/usr/bin/python'^M sys.prefix = 'foo'^M sys.exec_prefix = 'foo'^M sys.path = [^M 'foo/lib64/python39.zip',^M 'foo/lib64/python3.9',^M 'foo/lib64/python3.9/lib-dynload',^M ]^M Fatal Python error: init_fs_encoding: failed to get the Python codec of the \ filesystem encoding^M Python runtime state: core initialized^M ModuleNotFoundError: No module named 'encodings'^M ^M Current thread 0x00007fffabe18480 (most recent call first):^M ^M ERROR: (eof) GDB never initialized. Couldn't send python print (1) to GDB. UNRESOLVED: gdb.python/py-failed-init.exp: gdb-command Couldn't send quit to GDB. UNRESOLVED: gdb.python/py-failed-init.exp: quit ... The test-case expects gdb to present a prompt, but instead gdb calls exit with this back trace: ... (gdb) bt #0 0x00007ffff6e4bfbc in exit () from /lib64/glibc-hwcaps/power10/libc.so.6 #1 0x00007ffff7873fc4 in fatal_error.lto_priv () from /lib64/libpython3.9.so.1.0 #2 0x00007ffff78aae60 in Py_ExitStatusException () from /lib64/libpython3.9.so.1.0 #3 0x00007ffff78c0e58 in Py_InitializeEx () from /lib64/libpython3.9.so.1.0 #4 0x0000000010b6cab4 in py_initialize_catch_abort () at gdb/python/python.c:2456 #5 0x0000000010b6cfac in py_initialize () at gdb/python/python.c:2540 #6 0x0000000010b6d104 in do_start_initialization () at gdb/python/python.c:2595 #7 0x0000000010b6eaac in gdbpy_initialize (extlang=0x11b7baf0 ) at gdb/python/python.c:2968 #8 0x000000001069d508 in ext_lang_initialization () at gdb/extension.c:319 #9 0x00000000108f9280 in captured_main_1 (context=0x7fffffffe870) at gdb/main.c:1100 #10 0x00000000108fa3cc in captured_main (context=0x7fffffffe870) at gdb/main.c:1372 #11 0x00000000108fa4d8 in gdb_main (args=0x7fffffffe870) at gdb/main.c:1401 #12 0x000000001001d1d8 in main (argc=3, argv=0x7fffffffece8) at gdb/gdb.c:38 ... This may be a python issue [1]. The problem doesn't happen if we use the PyConfig approach instead of the py_initialize_catch_abort approach. Fix this by using the PyConfig approach starting 3.9 (previously, starting 3.10 to avoid Py_SetProgramName deprecation in 3.11). It's possible that we have the same problem and need the same fix for 3.8, but I don't have a setup to check that. Add a todo in a comment. Tested on ppc64le-linux. Approved-By: Tom Tromey [1] https://github.com/python/cpython/issues/107827 2025-10-17 Andrew Burgess gdb: restore warning when core file and executable don't match Consider the following GDB session: (gdb) file /path/to/program (gdb) core /path/to/corefile warning: core file may not match specified executable file. ... etc ... (gdb) Notice the warning. GDB produces this warning when one of the following conditions is true: + The build-id for the core file doesn't match the build-id of the executable, or + The filename of the executable doesn't match the partial filename stored in the PRPSINFO note from the core file. Unfortunately, this warning was broken by the following two commits: commit c97e57bc9d2e081b7c842742933b7262f1d7ce39 Date: Wed Oct 8 11:18:07 2025 +0100 gdb: move core file bfd from program_space into core_target commit 84f8be0d9c8ce30bf56eb9e14ce6fe012125fa53 Date: Wed Sep 10 11:04:45 2025 +0100 gdb: remove program_space::core_bfd member function These commits changed how the validate_files function (in corefile.c), which is where the warning is emitted, find the core file BFD object. Prior to the above commits, the core file BFD was stored in the program_space, and was set by the time validate_files was called. After the above commits the core file BFD is stored in the inferior's core_target, and can only be accessed if the core_target has been pushed onto the inferior's target stack. Unfortunately, validate_files is called just before core_target is pushed. As a result, in validate_files it appears as if there is no core file loaded, and so no validation is performed. This commit fixes that by moving the call to validate_files to after the core_target is pushed. The warning is now restored. I was surprised that this wasn't caught in testing. I was sure we had a test for that warning. But, when I look now, I cannot find any such test, so this commit adds one. While I'm adding the test, validate_files also has a warning that it can emit if the core file is older than the executable. I've made sure that the test covers this warning too. Approved-By: Tom Tromey 2025-10-17 Jeremy Bryant doc/python.texi : Adapt to Python 3 print syntax This change adapts the print syntax to Python 3. The documentation examples will then work on current installations. Python 2 was sunsetted in January 2020. Approved-By: Tom Tromey 2025-10-17 Tom de Vries [gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi some more PR tdep/33534 reports a regression due to commit 13f1820106c ("[gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi"). The regression can be reproduced with the test-case introduced in the commit: gdb.ada/return-small-char-array.exp, on a ppc64-linux setup with v1 elf abi (cfarm121). The commit contains two changes to a piece of code in ppc64_sysv_abi_return_value: ... /* Small character arrays are returned, right justified, in r3. */ - if (valtype->code () == TYPE_CODE_ARRAY + if (tdep->elf_abi == POWERPC_ELF_V1 + && valtype->code () == TYPE_CODE_ARRAY && !valtype->is_vector () && valtype->length () <= 8 - && valtype->target_type ()->code () == TYPE_CODE_INT + && (valtype->target_type ()->code () == TYPE_CODE_INT + || valtype->target_type ()->code () == TYPE_CODE_CHAR) && valtype->target_type ()->length () == 1) ... The first change limits the effect of the if clause to the v1 elf abi. This change doesn't affect the regression, since it's on a ppc64-linux setup with v1 elf abi. Furthermore, it's correct in the sense that the v2 elf abi doesn't have this kind of special treatment of small character arrays. The second change is the part that causes the regression. The code itself seems correct, in the sense that it enables gdb to recognize small char arrays in ada. The regression stems from the following discrepancy. The comment in gdb states that "small character arrays are returned, right justified, in r3". This matches the v1 ABI [1]. OTOH, gcc produces code that is not in agreement with this. Instead, it passes the small character arrays in memory, in a caller-allocated storage buffer pointed at by r3. This turns out to be an gcc bug [2]. Fix this by treating this as an abi spec bug, and replacing the code handling the "Small character arrays" case with a comment. Doing so reveals that there are two problems in the test-case: - missing fvar-tracking, and - the "step 2" command doesn't land at the intended line. Fix these by: - adding fvar-tracking, and - setting a breakpoint at the intended line, and continuing to it. Tested on ppc64-linux (v1 abi), ppc64le-linux (v2 abi), and x86_64-linux. Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33534 [1] https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html. [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122282 2025-10-17 Alan Modra Don't build libctf tests in source dir Running the libctf testsuite currently leaves big-struct-ctf.o in libctf/testsuite/libctf-lookup/. It ought to be possible to make the binutils source dir read-only, and putting compiler output in the source dir leads to interesting effects when testing multiple binutils targets in parallel. * lib/ctf-lib.exp (run_lookup_test): For "link: objects" compile objects in tmpdir. 2025-10-17 GDB Administrator Automatic date update in version.in 2025-10-16 Indu Bhagat libsframe: fix warning about argument of sframe_fre_sanity_check_p Recent commit (6ca8915c) added a new API sframe_fre_get_ra_undefined_p (). It has a 'const sframe_frame_row_entry *fre' argument, causing a warning in function ‘sframe_fre_get_ra_undefined_p’: libsframe/sframe.c:794:50: warning: passing argument 1 of ‘sframe_fre_sanity_check_p’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 794 | if (fre == NULL || !sframe_fre_sanity_check_p (fre)) | ^~~ libsframe/sframe.c:293:52: note: expected ‘sframe_frame_row_entry *’ but argument is of type ‘const sframe_frame_row_entry *’ 293 | sframe_fre_sanity_check_p (sframe_frame_row_entry *frep) | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~ Fix it by using const qualifier. libsframe/ * sframe.c (sframe_fre_sanity_check_p): Use const. 2025-10-16 Simon Marchi Bump 'isort' version for pre-commit I ran `pre-commit autoupdate` and this showed up. No changes in the formatting. Change-Id: If06cec2ab902d3174caf6d5b13885f4b66b66c61 2025-10-16 Tom de Vries [pre-commit] Add check-gnu-style I got a review comment [1] because I forgot to do "space before paren". I realized I forgot to run check_GNU_style.py, a script from the GCC repo, which warns about things like this. [ The python script has been around since 2017 (and an earlier version written in shell script since 2010). ] So for this change in gdb/gdb.c: ... - return gdb_main (&args); + return gdb_main(&args); ... we get: ... $ ./contrib/check_GNU_style.py <(git diff) === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === gdb/gdb.c:38:17: return gdb_main(&args); ... Add a pre-commit hook to do this automatically. This copies two files from the GCC repo to root-level contrib, and adds a wrapper script gdb/contrib/check-gnu-style-pre-commit.sh (checked with shellcheck). The wrapper script is setup to not fail on violations, so the messages are informational at this point. I'm not sure all checks are 100% applicable to our coding style. The python script check_GNU_style.py has two dependencies: unidiff and termcolor, which users need to install themselves. The check is added at the pre-commit stage. I also considered post-commit, and I'm still not sure what is the better choice. As with all pre-commit checks, if the check is not to your liking, you can use SKIP=check-gnu-style to skip it. In summary, with the new pre-commit check we get: ... $ git commit -a -m "style error" 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 check-gnu-style.........................................................Passed - hook id: check-gnu-style - duration: 0.04s === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === gdb/gdb.c:38:17: return gdb_main(&args); tclint..............................................(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.19s tclint...............................................(no files to check)Skipped [master $hex] style error ... Approved-By: Simon Marchi [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220983.html 2025-10-16 Tom de Vries [gdb/c++] Fix hang on whatis std::string::npos Consider the following scenario, exercising "whatis std::string::npos": ... $ cat test.cc int main (void) { std::string foo = "bar"; return foo.size (); } $ g++ test.cc -g $ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in +start Temporary breakpoint 1 at 0x4021c7: file test.cc, line 3. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at test.cc:3 3 std::string foo = "bar"; +info auto-load python-scripts No auto-load scripts. +whatis std::string type = std::__cxx11::basic_string, \ std::allocator > +whatis std::string::npos type = const std::__cxx11::basic_string, \ std::allocator >::size_type ... After installing the package containing the pretty-printers: ... $ zypper install libstdc++6-pp ... and adding some commands to use them, we get instead: ... $ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in +add-auto-load-safe-path /usr/share/gdb/auto-load +add-auto-load-scripts-directory /usr/share/gdb/auto-load +start ... +info auto-load python-scripts Loaded Script Yes /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.34-gdb.py +whatis std::string type = std::string +whatis std::string::npos type = const std::__cxx11::basic_string, \ std::allocator >::size_type ... Note that "whatis std::string" now prints "std::string", but that "whatis std::string::npos" still uses the longer name for std::string. This is when compiling gdb with -O0. With -O2 -fstack-protector-strong, we have a hang instead: ... +whatis std::string type = std::string +whatis std::string::npos ... Valgrind complains about an uninitialized field demangle_component::d_counting, which is fixed by using cplus_demangle_fill_name in replace_typedefs_qualified_name. After fixing that, the hang is also reproducible at -O0. The hang happens because we're stuck in the while loop in replace_typedefs_qualified_name, replacing "std::string::size_type" with "std::string::size_type". Fix this in inspect_type by checking for this situation, getting us instead: ... +whatis std::string type = std::string +whatis std::string::npos type = const std::string::size_type $ ... The test-case is a bit unusual: - pretty-print.cc is a preprocessed c++ source, reduced using cvise [1], then hand-edited to fix warnings with gcc and clang. - the pretty-printer .py file is a reduced version of /usr/share/gcc-15/python/libstdcxx/v6/printers.py. Using the test-case (and the cplus_demangle_fill_name fix), I managed to reproduce the hang on both: - openSUSE Leap 15.6 with gcc 7, and - openSUSE Tumbleweed with gcc 15. The test-case compiles with clang, but the hang didn't reproduce. Tested on x86_64-linux. PR testsuite/33480 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33480 [1] https://github.com/marxin/cvise 2025-10-16 Jens Remus s390: Do not rewrite insns and their relocs in linker if --no-relax Under certain conditions the linker rewrites: - GOT access using lgrl to larl, changing the GOTENT to a PC32DBL reloc - GOT access using lg to larl, changing the GOT20 to a PC32DBL reloc - Relative long addressing instructions of weak symbols, which definitively resolve to zero to either (1) load address of zero, (2) a NOP, or (3) a trapping instruction, changing the relocation to a NONE reloc. Suppress rewriting of non-TLS instructions and related relocations in linker if option --no-relax is specified. This aligns with LLVM linker behavior on s390. Like x86-64 do not actually enable the linker relaxation option by default, as other targets would do using ENABLE_RELAXATION or TARGET_ENABLE_RELAXATION in their linker emulation scripts. Instead perform linker instruction/relocation rewrites by default unless linker option --no-relax is explicitly specified by the user. This ensures no functional change unless --no-relax is used. bfd/ * elf64-s390.c (elf_s390_relocate_section): Do not rewrite non-TLS instructions and related relocations if --no-relax. * elf32-s390.c (elf_s390_relocate_section): Likewise. ld/testsuite/ * ld-s390/s390.exp: New tests. Same as gotreloc_*-1a and weakundef-*a, but with linker option --no-relax, to verify suppression of linker non-TLS insn and reloc rewrites. * ld-s390/gotreloc_31-1b.dd: Likewise. * ld-s390/gotreloc_31-no-pie-1b.dd: Likewise. * ld-s390/gotreloc_64-no-pie-1b.dd: Likewise. * ld-s390/gotreloc_64-norelro-1b.dd: Likewise. * ld-s390/gotreloc_64-relro-1b.dd: Likewise. * ld-s390/weakundef-1b.d: Likewise. Check for expected reloc overflows. * ld-s390/weakundef-2b.d: Likewise. 2025-10-16 Jens Remus s390: Rename linker tests gotreloc_*-1 and weakundef-* This enables a subsequent patch to introduce a variation of those tests with linker option --no-relax added. ld/testsuite/ * ld-s390/gotreloc_31-1.dd: Rename to ... * ld-s390/gotreloc_31-1a.dd: ... this. * ld-s390/gotreloc_31-no-pie-1.dd: Likewise. * ld-s390/gotreloc_31-no-pie-1a.dd: Likewise. * ld-s390/gotreloc_64-no-pie-1.dd: Likewise. * ld-s390/gotreloc_64-no-pie-1a.dd: Likewise. * ld-s390/gotreloc_64-norelro-1.dd: Likewise. * ld-s390/gotreloc_64-norelro-1a.dd Likewise. * ld-s390/weakundef-1.dd: Likewise. * ld-s390/weakundef-1a.dd: Likewise. * ld-s390/weakundef-2.dd: Likewise. * ld-s390/weakundef-2a.dd: Likewise. * ld-s390/s390.exp: Rename tests likewise. 2025-10-16 Jens Remus s390: Rewrite emitted relocations when rewriting instructions When the linker rewrites instructions it may need to rewrite the associated relocations, so that when emitted with option --emit-relocs, they make sense with the rewritten instructions. Otherwise post link analysis and optimization tools may not be able to perform correct modifications of executables. Under certain conditions the linker rewrites: - GOT access using lgrl to larl, changing the GOTENT to a PC32DBL reloc - GOT access using lg to larl, changing the GOT20 to a PC32DBL reloc - Relative long addressing instructions of weak symbols, which definitively resolve to zero, to either (1) load address of zero, (2) a NOP, or (3) a trapping instruction. In case of a rewrite of GOT access using lgrl/lg to larl emit the PC32DBL relocation. In case of a rewrite of relative long addressing instructions of weak symbols, which definitively resolve to zero, emit a NONE relocation and reset the symbol table index and addend. Update the gotreloc* and weakundef* tests to check for the respective relocations. This aligns with how GNU linker behaves on x86-64, when rewriting instructions/relocations in elf_x86_64_convert_load_reloc(). bfd/ * elf64-s390.c (elf_s390_relocate_section): Rewrite emitted relocations when rewriting instructions. * elf32-s390.c (elf_s390_relocate_section): Likewise. ld/testsuite/ * ld-s390/s390.exp: Link gotreloc* and weakundef* tests with option --emit-relocs. * ld-s390/gotreloc_31-1.dd: Expect rewritten instructions to be accompanied by a PC32DBL or NONE relocation respectively. * ld-s390/gotreloc_31-no-pie-1.dd: Likewise. * ld-s390/gotreloc_64-no-pie-1.dd: Likewise. * ld-s390/gotreloc_64-norelro-1.dd: Likewise. * ld-s390/gotreloc_64-relro-1.dd: Likewise. * ld-s390/weakundef-1.dd: Likewise. * ld-s390/weakundef-2.dd: Likewise. Fixes: a63cc5f70ca6 ("Rewrite GOT accesses using larl if possible") Fixes: 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols") Fixes: 6f8b365b653d ("s390: Avoid reloc overflows on undefined weak symbols (cont)") 2025-10-16 GDB Administrator Automatic date update in version.in 2025-10-15 John David Anglin hppa64: Remove a couple of unnecessary NULL pointer checks 2025-10-15 John David Anglin bfd/ChangeLog: * elf64-hppa.c (allocate_global_data_opd): Remove hh check. (elf64_hppa_finalize_dlt): Likewise. 2025-10-15 Andrew Burgess gdb/testsuite: remove incorrect global variable accesses I noticed in gdb.replay/missing-thread.exp a reference to $testfile in a location where 'testfile' had not been made available via a use of 'global'. The uses looked like this: unsupported "$testfile (couldn't start gdbreplay)" I think there are three problems here, the $testfile is invalid because there's no 'global testfile' making the variable available. The use of $testfile is redundant anyway as 'unsupported' already adds the script name to the output line. The final text within parenthesis is bad style that's an important part of the output, but GDB test name style is that text in parenthesis is additional text that could be ignored, e.g. "(timeout)". Replace the above with just: unsupported "couldn't start gdbreplay" This same construct has been copied into multiple gdb.replay/ tests, so fix them all. There's no change to what is actually tested after this commit. 2025-10-15 John David Anglin hppa64: Fix addition of symbols to local dynamic table This fixes lookup failure in elf64_hppa_finalize_dynreloc. 2025-10-15 John David Anglin bfd/ChangeLog: * elf64-hppa.c (elf64_hppa_check_relocs): Record local dynamic symbol if a dynamic relocation is needed. (allocate_global_data_dlt) Fix typo. (allocate_dynrel_entries): Don't record symbol. (elf64_hppa_finalize_dynreloc): Assert dynindx is not -1. 2025-10-15 Jens Remus s390: Add tests for readelf --got-contents option Port tests from x86 commit 81e90cf63a10 ("readelf: Add --got-contents option") to s390 64-bit (s390x). ld/testsuite/ * ld-s390/binutils.exp: New file. * ld-s390/got-1.s: Likewise. * ld-s390/libgot_64-1a.rd: Likewise. * ld-s390/libgot_64-1b.rd: Likewise. * ld-s390/libgot_64-1c.rd: Likewise. * ld-s390/libgot_64-1d.rd: Likewise. 2025-10-15 Jens Remus gas: sframe: Represent .cfi_undefined RA as FRE without offsets In DWARF CFI an "undefined" register rule for the return address (RA) register indicates that there is no return address and the stack trace is complete. Represent DW_CFA_undefined as SFrame FRE without any offsets, so that a stack tracer implementation can use this as indication that an outermost frame has been reached and the stack trace is complete. This representation is backward compatible, as existing stack tracers should already deal with the case, that an SFrame FRE a so far invalid offset count of zero and stop the trace. include/ * sframe.h (SFRAME_V2_FRE_RA_UNDEFINED_P): New macro to test FRE info word for RA undefined (FRE without any offsets). binutils/ * NEWS: Mention SFrame can represent an undefined RA as FRE without any offsets. gas/ * gen-sframe.h (struct sframe_row_entry): Add ra_undefined_p flag. * gen-sframe.c (sframe_row_entry_new): Initialize ra_undefined_p flag to not set. (sframe_row_entry_initialize): Treat ra_undefined_p flag as sticky. (sframe_fre_set_ra_track): Reset ra_undefined_p flag. (sframe_xlate_do_restore): Reset ra_undefined_p flag to saved state. (sframe_xlate_do_same_value): Reset ra_undefined_p flag. (sframe_xlate_do_cfi_undefined): For RA set ra_undefined_p flag. (output_sframe_row_entry): Represent RA undefined as SFrame FRE without any offsets and FRE info word fields zeroed. * NEWS: Mention assembler represents .cfi_undefined RA in SFrame as FRE without any offsets. libsframe/ * doc/sframe-spec.texi (Changes from Version 1 to Version 2): Mention that a SFrame FRE without any offsets flag indicates an outermost frame with an undefined RA. (fre_offset_count): Document that a FRE offset count of zero indicates an outermost frame with an undefined RA. * sframe.c (sframe_get_fre_ra_undefined_p): Use macro SFRAME_V2_FRE_RA_UNDEFINED_P. (sframe_fre_get_fp_offset, sframe_fre_get_ra_offset): Do not return fixed FP/RA offset if RA undefined. * sframe-dump.c (dump_sframe_func_with_fres): Show FRE without any offsets as "RA undefined". gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: Run tests for .cfi_undefined RA on AArch64, s390x, and x86-64. * gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.d: Add test for .cfi_undefined RA on AArch64. * gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.s: Likewise. * as/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.d: Add test for .cfi_undefined RA on s390x. * gas/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.s: Likewise. * gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.d: Add test for .cfi_undefined RA on x86-64. * gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.s: Likewise. 2025-10-15 Jens Remus include: libsframe: Add API to get RA undefined SFrame FREs without any offsets will later be used to represent an undefined return address (RA) in SFrame. This API can then be used, for instance by libsframe when dumping SFrame stack trace information (e.g. in objdump and readelf), to test for RA undefined. Other users of libsframe need the same capability. include/ * sframe-api.h (sframe_fre_get_ra_undefined_p): New declaration. libsframe/ * libsframe.ver (sframe_fre_get_ra_undefined_p): List new API. * sframe.c (sframe_fre_get_ra_undefined_p): New definition. 2025-10-15 Jens Remus libsframe: s390: No further decode if sframe_get_fre_offset returns err SFrame FREs without any offsets will later be used to represent .cfi_undefined RA in SFrame. As a result the API to get the CFA offset can return an error value, if there are no offsets. Do not apply the s390x-specific decoding of CFA offset on the error return value. libsframe/ * sframe.c (sframe_fre_get_cfa_offset): Do not apply s390x- specific decoding to error return value. 2025-10-15 Jens Remus gas: ld: libsframe: Support for SFrame FDEs without any FREs Allow SFrame sections without any FREs, that can occur if they solely contain FDEs without any FREs. For FDEs without and FREs set the offset to the first FRE to zero. libsframe/ * sframe.c (sframe_encoder_write_sframe): Allow SFrame sections without any FREs. For FDEs without any FREs set the offset to the first FRE to zero. gas/ * gen-sframe.c (output_sframe_funcdesc): For FDEs without any FREs set the offset to the first FRE to zero. 2025-10-15 Matthieu Longo gdb: add experimental option --enable-py-limited-api Today, GDB links against the Python library using the unstable API. This approach causes portability issues of the generated GDB artifact. Indeed the built artifact is tighly coupled with the specific version of Python that it was compiled with. Using a slighly minor version of Python can cause unpredictable crashes at runtime due to ABI instability between the Python versions, even minor ones. The solution would consist in restricting the usage of Python functions to the limited C API controlled via Py_LIMITED_API that must be defined before the inclusion of . This patch does not aim at porting the whole GDB codebase to the Python limited C API, but rather enabling a development mode where developers can experiment with the Python limited C API, and fix issues. This development mode is accessible with the configure option --enable-py-limited-api which is set by default to 'no'. Note: the version of the Python limited API is currently set to 3.11 because of PyBuffer_FillInfo and PyBuffer_Release. This choice is not frozen, and could be reviewed later on depending on newly discovered issues during the migration. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey 2025-10-15 Matthieu Longo gdb: make Python conftest compatible with Python limited C API The current test to check the support of '--dynamic-list' linker flag uses PyRun_SimpleString (), which is part of the unstable API. As it is now, the test will systematically fail due to the undefined symbol rather than testing the import of ctypes. This patch replaces PyRun_SimpleString () by an equivalent code relying on the limited C API, and compatible with Python 3.4. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey 2025-10-15 GDB Administrator Automatic date update in version.in 2025-10-14 Simon Marchi gdb/linespec: make symbol_to_sal return an optional Return an optional, instead of a bool + the actual value by parameter. I think this makes it a bit easier to understand what's going on. Change-Id: Idf65f4a026cab6eebfb81c4efda406aeb65d0813 Approved-By: Tom Tromey 2025-10-14 Simon Marchi gdb/linespec: take some parameters by reference Change the `sal` parameter of add_sal_to_sals to be a reference. This will make things a bit cleaner in a following patch (and it would be a good change on its own anyway). Change the `sals` parameter to a reference as well, while at it, which trickles up to minsym_found. Change-Id: I348414308940c14fa6030bc41c52f507aa6d1c12 Approved-By: Tom Tromey 2025-10-14 Simon Marchi gdb: remove unnecessary use of symtab_and_line in create_sals_line_offset create_sals_line_offset uses a symtab_and_line essentially just to hold a line number and pass it down to decode_digits_list_mode. Change the local variable to be an int, and change decode_digits_list_mode to accept an int, instead of a symtab_and_line. I think this makes the code a bit simpler. Change-Id: I445d2473f042693c3a4f2693877408f85100cd1f Approved-By: Tom Tromey 2025-10-14 Simon Marchi gdb/symtab: declare variables on first use in skip_prologue_sal I'm currently looking at this function, and think it makes it easier to process if the variables are declared when actually used. I turned one while loop into a for, in order to be able to declare the loop variable in the for loop. Change-Id: I70258a94f39acb3d56e5b8e85cdfadc2f7687bc4 Approved-By: Tom Tromey 2025-10-14 Simon Marchi gdb/symtab: declare variables on first use in find_pc_sect_line I'm currently looking at this function, and think it makes it easier to process if the variables are declared when actually used. Change-Id: Ie950fc3a7241e55e66ae96a578f79df3a9b45c69 Approved-By: Tom Tromey 2025-10-14 Tom Tromey Fix use of "main" marker in gdb index Tom de Vries noticed that with .gdb_index, the "main" marker would sometimes seemingly be ignored. I tracked this down to an interaction between the rewritten reader and the "main"-finding code in cooked_index. With the ordinary DWARF scanner, a C "main" won't be marked as IS_MAIN; whereas with .gdb_index this can happen. In this case, the code thinks that C requires canonicalization (which is only true for types), and skips using the symbol. This patch fixes the problem and adds some comments explaining what is going on. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33441 2025-10-14 Tom de Vries Fix gdb.ada/extended-access.exp on riscv64-linux On riscv64-linux, I ran into: ... (gdb) print the_array.all^M Cannot access memory at address 0x0^M (gdb) FAIL: gdb.ada/extended-access.exp: print the_array.all ... The problem is that the_array.p_array is set by a dynamic relocation: ... 0000000000002010 : ... 0000000000002028 : ... 2028: R_RISCV_RELATIVE *ABS*+0x2010 ... which doesn't seem to get its value until we arrive in main. Fix this by running to main before trying to print the_array. Tested on riscv64-linux. Approved-By: Tom Tromey 2025-10-14 Tom de Vries [gdb/testsuite] Fix xfail in gdb.ada/variant_record_field.exp On ppc64-linux (debian 14) I run into: ... (gdb) print p_record^M $1 = (kind => five, i => ^M (gdb) gdb_do_cache: get_compiler_info_1 ( c ) get_compiler_info: gcc-15-2-0 gdb_do_cache: get_compiler_info_1 ( c ) FAIL: gdb.ada/variant_record_field.exp: print p_record ... The test-case contains an xfail for "[gcc_major_version] <= 14", which doesn't trigger because gcc has version 15.2.0, while gnatmake does have version 14.3.0: ... $ gcc --version gcc (Debian 15.2.0-4) 15.2.0 ... $ gnatmake --version GNATMAKE 14.3.0 ... Fix this by using "[gnat_version_compare < 15]" instead. Tested on ppc64-linux and x86_64-linux. Approved-By: Tom Tromey 2025-10-14 Lancelot SIX gdb/corelow: Fix use-after-free in gdb_read_core_file_mappings A recent refactor (fc8e5a565b3 -- gdb: make structured core file mappings processing global) in gdb/corelow.c:gdb_read_core_file_mappings introduced a use-after-free bug detected by address sanitizer. In this change, a cache is built which holds addresses to elements of a std::vector. However, as elements as inserted in the vector, the addresses in the cache should be invalidated, but are not, leading to the use-after-free issue. This patch proposes to store the index in the vector in the cache instead of the address of the element, solving the invalidation issue. An alternative approach could be to use a std::list which does not need invalidation of addresses/references/iterators as the container is grown. Change-Id: Ib57d87c5d0405ffa3b7d38557fb33f7283c5d063 Approved-By: Andrew Burgess 2025-10-14 Tom de Vries [gdb/build] Fix buildbreaker on x86_64-freebsd in gdb/fbsd-nat.c Following commit 1ad8737b3c5 ("gdb: change inf_threads_iterator to yield references"), we're running into a build breaker on x86_64-freebsd, in gdb/fbsd-nat.c. Fix this. Tested by completing a build on x86_64-freebsd and running the TUI test-cases. 2025-10-14 Tom de Vries [gdb/testsuite] Fix ERROR in gdb.tui/corefile-run.exp When running test-case gdb.tui/corefile-run.exp on x86_64-freebsd, we run into PR tdep/33176: ... PASS: gdb.tui/corefile-run.exp: load corefile rungdb/fbsd-nat.c:1381: internal-error: wait_1: \ Assertion `fbsd_inf != nullptr || pl.pl_flags & PL_FLAG_CHILD' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- ERROR: FIXME scroll ... Skip the ERROR by: - running the test-case twice, once with CLI and once with TUI, and - only running the TUI variant if the CLI one succeeds. While we're at it, add a KFAIL for the PR. Tested on x86_64-freebsd and x86_64-linux. 2025-10-14 Natanael Copa gcore: Remove bashisms and use POSIX sh - Switch script shebang to /bin/sh - Remove unnecessary `function` keywords - Replace bash arrays with simple scalar variables - Use $(uname -s) instead of bash specific $OSINFO Approved-By: Simon Marchi 2025-10-14 Tom Tromey Fix use-after-free when destroying objfile The recent patch to heap-allocate compunit_symtabs introduced a use-after-free that can occur when destroying an objfile. The bug here is that the objfile obstack is destroyed before compunit_symtabs; but the compunit_symtabs destructor refers to the symtabs, which are allocated on the obstack. This patch fixes the problem. This was reported using ASAN, but I reproduced it with valgrind and verified that this fixes the problem. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33435 2025-10-14 GDB Administrator Automatic date update in version.in 2025-10-13 Maciej W. Rozycki LD/PE: Remove remains of MIPS target support Support for ECOFF MIPS targets, including `mips*-*-pe*' among others, has been removed from GAS and LD with commit e8044f355dc9 ("Remove gas and ld support for MIPS ECOFF"), . However bits in PEI-format DLL support code have been left behind. Remove the relevant pieces then, originally from commit 344a211f9995 ("Add support for WinCE based toolchains."), including MIPS architecture parts and HIGHADJ relocation support in particular. Retain code for LOW relocation however, even though included with said commit, as it remains usable by ARM, i386 and x86-64 targets. Add test cases for LOW, HIGHLOW, and DIR64 relocations handled by code being modified. The MCore target currently fails to produce a .reloc image section owing to missing support, so XFAIL the HIGHLOW test. 2025-10-13 Maciej W. Rozycki LD/PE: Make arch identifiers enumeration constants Convert internal PE architecture identifiers from macros to enumeration constants so as to make any further updates less disruptive to code. Add a PE_ARCH_none dummy placeholder so as to start the numbering of actual architectures from 1 without the need to specify the numeric value for any of the constants. No functional change. Suggested by Richard Earnshaw. 2025-10-13 Tom de Vries [gdb/testsuite] Use expect_build_id_in_core_file a bit more Recent commit c1950dcc04c ("gdb/testsuite: fix failure from gdb.python/py-corefile.exp") introduced proc expect_build_id_in_core_file, which detects the problem that: ... ... some versions of the linker didn't place the build-id within the first page of an ELF. As a result, the Linux kernel would not include the build-id in the generated core file, ... ... Use this proc in a few more test-cases, to deal with the same problem. Tested on x86_64-linux, openSUSE Tumbleweed with ld 2.43.1. Approved-By: Andrew Burgess PR testsuite/33528 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33528 2025-10-13 Nick Clifton Add a position statement about LLM generated content Add note about how to obtain permission to upload new releases 2025-10-13 GDB Administrator Automatic date update in version.in 2025-10-12 Andrew Burgess gdb/remote: replace use of std::pair with an actual struct Commit: commit 5edcbe2277db05b77ebf53f9c30b6c889a8729bc Date: Mon Jul 24 17:35:54 2023 +0100 gdb: detect when gdbserver has no default executable set Introduced a use of std::pair as a data structure to hold some per program space information within the program space registry. It was pointed out during review of a later patch[1][2] that the code would be easier to understand if the std::pair was replaced with a struct with named fields. That is what this commit does. Replace the std::pair with a struct, and update all accesses to use the named fields. There should be no user visible changes after this commit. [1] https://inbox.sourceware.org/gdb-patches/69681489-d556-4496-9e3b-8273cab3d8f5@simark.ca [2] https://inbox.sourceware.org/gdb-patches/469655a7-2bcc-4f27-b2d7-3fa8808ca5b5@simark.ca Approved-By: Simon Marchi 2025-10-12 GDB Administrator Automatic date update in version.in 2025-10-11 Tom Tromey Return references from compunit_symtab iterator This changes the compunit_symtab iterator to return references rather than pointers, following the style of some other recent changes. Approved-By: Simon Marchi 2025-10-11 Tom Tromey Use std::unique_ptr in compunit_symtab Now that compunit_symtab can have a destructor, it can use std::unique_ptr rather than an explicit 'delete'. Approved-By: Simon Marchi 2025-10-11 Tom Tromey Allocate compunit_symtab on heap This patch changes compunit_symtab to be allocated on the heap, using 'new'. It also changes the container that holds these in the objfile. I chose to use an intrusive_list to store compunit_symtab because I think pointer stability is needed here. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33435 Approved-By: Simon Marchi 2025-10-11 Simon Marchi gdb/symtab: remove section parameter from find_function_start_sal All 2 callers of this overload pass NULL. Remove the parameter and pass nullptr explicitly to find_function_start_sal_1. Change-Id: Ie20e7c8ad980cd7af99b6ba9c23f4da19febc1bc 2025-10-11 GDB Administrator Automatic date update in version.in 2025-10-10 Jan Vrany gdb: introduce new function create_function_type While working on new Python API to create new function types I realized that there's no easy way to create a new function type and control where it is going to be allocated (whether in gdbarch's obstack or objfile's). Functions lookup_function_type and lookup_function_type_with_arguments always allocate at the same obstack as its return type. This is not sufficient for the new Python API - the user may use any type it can get hold of. For example, one may want to create a function returning arch-owned type and taking one argument of objfile-owned type. In that case we need to allocate the new type on that very objfile's obstack. This commit introduces new function - create_function_type - that takes type_allocator as first parameter, allowing caller to control the allocation. Existing functions (lookup_function_type and lookup_function_type_with_arguments) are reimplemented by means of new create_function_type. Approved-By: Tom Tromey 2025-10-10 Jan Beulich bfd/PE: make local array in _bfd_XXi_swap_scnhdr_out() static ... and const. There's no reason to have the compiler copy an anonymous .rodata object onto the stack. And there's also no reason to allow the array to be modifiable. 2025-10-10 Jan Beulich bfd/PE: respect SEC_ALLOC when deciding whether to force IMAGE_SCN_MEM_DISCARDABLE While in the common case sections like .reloc don't need to be accessed by a binary (that's the job of the loader), there are rare cases where the situation is different. Unconditionally forcing the discardable flag is therefore unhelpful. Avoid doing so when SEC_ALLOC is set, which would in particular be the case when .reloc isn't (solely) linker- generated. While adjusting the comment, drop the wrong (stale?) following sentence: .rsrc, as per its table entry, doesn't need to be writable. And commenting on it wanting to be readable would then need to be repeated for all other sections as well. 2025-10-10 Jan Beulich bfd / PE/COFF: permit SEC_READONLY and consolidate Without SEC_READONLY, even the default .text section would end up with the IMAGE_SCN_MEM_WRITE flag, which is clearly wrong. (Afaict the flag, oddly enough, doesn't affect the final linked binary, so there likely are more anomalies.) However, as suggested by Richard Earnshaw, PE's requirements are really target independent. Consolidate SEC_CODE, SEC_DATA, SEC_READONLY, SEC_LINK_ONCE, and SEC_LINK_DUPLICATES into target-independent code. Yet of course targets not using CREATE_*_COFF_TARGET_VEC() won't benefit. Note that in coff-arm.c the EXTRA_S_FLAGS conditional was also stale (leftover from EPOC removal), and hence can go away. 2025-10-10 Jan Beulich gas/SH: respect --no-pad-sections This is once again just so the target won't need excluding in a forthcoming new testcase, which requires no padding at the end of at least some of the sections. gas/SH: support BFD_RELOC_RVA in the PE/COFF case This is just so the target won't need excluding in a forthcoming new testcase, which uses the .rva directive. 2025-10-10 Jan Beulich ld/PE: respect --enable-reloc-section even when .reloc isn't created by default Even when !DLL_SUPPORT, an executable may still want to have base relocations created. Avoid doing so by default, though, to not alter prior behavior. With this, an xfail can (and actually should) go away (or else we end up with an XPASS). 2025-10-10 Jan Beulich ld/PE: adjust pe_detail_list[] M*Core uses pe-dll.c, but has no entry in the table. Add both big and little endian ones. Many of the entries aren't relevant when targeting PE+; move the #endif accordingly. The MIPS entry is actually questionable altogether: No mips*-*-* target uses pe-dll.c or pep-dll.c. As I lack sufficient knowledge of the target, introduction of jmp_mcore_bytes[] will need to be handled by someone else. 2025-10-10 Jan Beulich objdump: enable PE support for Interix This is just so the target won't need excluding in a forthcoming new testcase. Without doing so objdump would fail saying "option -P/--private not supported by this file". bfd/COFF: optionally pass BFD section into swap_scnhdr_out() hook _bfd_XXi_swap_scnhdr_out() will want to use the section's flags. Some call sites don't have a BFD section available, and hence pass NULL. Code using the parameter will therefore need to apply appropriate care. bfd / PE/COFF: avoid setting SEC_ALLOC when finding IMAGE_SCN_MEM_DISCARDABLE Before teaching _bfd_XXi_swap_scnhdr_out() to respect SEC_ALLOC when considering whether to force IMAGE_SCN_MEM_DISCARDABLE for a section, make sure we won't "invert" present wrong behavior when transforming an incoming object's section attributes to an outgoing one's (objcopy or "ld -r"): Right now, IMAGE_SCN_MEM_DISCARDABLE would appear out of the blue for certain sections. We don't want the opposite, though, i.e. we want avoid silently dropping IMAGE_SCN_MEM_DISCARDABLE when it's present for an incoming object's section. gas/COFF: extend use of SEC_ALLOC In line with bfd's styp_to_sec_flags(), set SEC_ALLOC for code/data sections. Tie the setting to SEC_LOAD, not avoid inadvertently producing a .bss-like section. 2025-10-10 Jan Beulich ld/PE: adjust .reloc and .edata section flags Both really want to be SEC_DATA, even if _bfd_XXi_swap_scnhdr_out() makes sure that IMAGE_SCN_CNT_INITIALIZED_DATA is set in the final section header. Otoh, .reloc - being IMAGE_SCN_MEM_DISCARDABLE at least by default - shouldn't have SEC_ALLOC set. In an early form of the patch I also dropped SEC_ALLOC for .reloc. While I've undone that, I think the then necessary testsuite adjustments still want retaining: 1) I can't explain why the removal of _both_ SEC_ALLOC and SEC_LOAD for .reloc causes ld-scripts/provide-8 to XPASS on PE targets. Placing a symbol outside of the image isn't well-defined in PE anyway though, so convert the xfail-s to notarget-s. 2) The ld-pe/pe-aarch64 fragility is now dealt with in a separate patch. 2025-10-10 Aditya Vidyadhar Kamath Fix AIX CI build break. Recently AIX internal CI is broken. The error is as follows: -------------------------------- aix-thread.c: In function 'void sync_threadlists(pid_t)': aix-thread.c:857:53: error: cannot convert 'thread_info' to 'thread_info*' in initialization 857 | for (struct thread_info *it : all_threads_safe ()) | ^ aix-thread.c: In lambda function: aix-thread.c:899:61: warning: declaration of 'thread' shadows a previous local [-Wshadow=compatible-local] 899 | thread = iterate_over_threads ([&] (struct thread_info *thread) ---------------------------------- This patch is similar to the commit https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_git_-3Fp-3Dbinutils-2Dgdb.git-3Ba-3Dcommitdiff-3Bh-3D675a17a8a5cde1d8be86536df2ae6366ef0ec759&d=DwIDAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=f-oUQ8ByG1nZ71OI9p76qywCPh7mxzU69hBYnkP9Nis&m=qpgW6gyN_lC_b0fBRhcWkqlvNDmUtHBTvyqGcCZxnuN6vnvJaehZ2WVuFVicJ9oD&s=UtdzAKmXnBH1ZTFOUTmFC9vTwxxralJIDjbYWsCsLYA&e= all_threads_safe() returns an all_threads_safe_range which is like an iterator to iterate for loops. AIX is adjusting its code in aix-thread.c for the same. After applying this patch, Sample test case output: ------------ gmake check RUNTESTFLAGS='gdb.threads/thread_events.exp CC_FOR_TARGET="/opt/freeware/bin/gcc" CXX_FOR_TARGET="/opt/freeware/bin/g++" CXXFLAGS_FOR_TARGET="-O0 -w -g -gdwarf -maix64" CFLAGS_FOR_TARGET="-O0 -w -g -gdwarf -maix64"' gmake check-single gmake[1]: Entering directory '/upstream_gdb/binutils-gdb/gdb/testsuite' rm -f *core* gdb.sum gdb.log === gdb tests === Schedule of variations: unix Running target unix Using /opt/freeware/share/dejagnu/baseboards/unix.exp as board description file for target. Using /opt/freeware/share/dejagnu/config/unix.exp as generic interface file for target. Using /upstream_gdb/binutils-gdb/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running /upstream_gdb/binutils-gdb/gdb/testsuite/gdb.threads/thread_events.exp ... === gdb Summary === /upstream_gdb/binutils-gdb/gdb/gdb version 18.0.50.20251010-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /upstream_gdb/binutils-gdb/gdb/data-directory -iex "set interactive-mode on" === gdb Summary === /upstream_gdb/binutils-gdb/gdb/gdb version 18.0.50.20251010-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /upstream_gdb/binutils-gdb/gdb/data-directory -iex "set interactive-mode on" gmake[1]: Leaving directory '/upstream_gdb/binutils-gdb/gdb/testsuite' Approved By: Ulrich Weigand 2025-10-10 Jan Beulich x86: introduce PadLock predicate By, at least for now, (ab)using the PrefixRepe attribute, the other two PadLock checks can be simplified. 2025-10-10 Jan Beulich x86: PadLock adjustments For one, all PadLock insns depend on CR4.FXSR to be enabled, which means they ought to be taking FXSR as a prereq. Furthermore none of them permits a REPNE prefix; such forms are documented to cause #UD. (This is mainly relevant for XSTORE, which doesn't include a REP prefix in its base encoding. For the others this merely is a change in what diagnostic is issued.) Finally it is documented that an operand size prefix also causes #UD. 2025-10-10 Jan Beulich bfd/ELF: don't lose trailing globals from SHF_MERGE sections _bfd_merged_section_offset() treats trailing symbols specially: That of the retained section will be assigned the section size, while all ones in replaced sections will be set to zero (which will then have output offset added, i.e. generally the size of the retained section). However, in neither case will the function change the section. Hence such trailing symbols, when not originating from the retained section, will appear to live in excluded sections, when they really belong to the sole retained one. Replace the section in all cases, and uniformly return section size. 2025-10-10 Alice Carlotti aarch64: Add support for FEAT_SSVE_BITPERM aarch64: Add support for FEAT_SSVE_FEXPA aarch64: Add support for FEAT_SME_MOP4 aarch64: Add support for FEAT_SME_TMOP 2025-10-10 Alice Carlotti aarch64: Remove incorrect disassembly constraint A check in print_insn_aarch64_word asserted that part of the encoding space couldn't contain any valid encodings, and then returned ERR_NYI ("Not Yet Implemented", perhaps?) for these values. However, some of the new FEAT_MOP4 instructions will trigger the assert. The check seems to be outdated, and is clearly no longer valid, so it can just be deleted. Additionally, there are no other assignments of ERR_NYI, so delete all remaining references to this error type. 2025-10-10 Alice Carlotti aarch64: Use constant fields in simple_index operands Update aarch64_{ins|ext}_simple_index to use constant fields, and swap the order of the index and regno fields, so that the regno occupies the last five bits. (Splitting/combining a variable length value and a fixed length value is easiest if the fixed length value occupies the least significant bits.) aarch64: Allow multiple fields for sve_aligned_reglist Update aarch64_{ins|ext}_sve_aligned_reglist to use constant fields instead of operand specific data for zero-extension/truncation. aarch64: Allow multiple fields in {ins|ext}_regno Adjust SME_PNd3/SME_PNg3 to use explicit FLD_CONST_1 bits. This allows the use of operand specific data to be eliminated here. 2025-10-10 Alice Carlotti aarch64: Extend aarch64_field to support constants Many instructions have constraints on the range of registers they can use. This means that some bits in the register number are fixed, and therefore aren't mapped to a field in the instruction encoding. Currently we use various adhoc rules to handle these fixed bits, but this doesn't handle all cases and we often have to write new code to support new combinations of permitted registers. This patch allows these constant bits to instead be specified in the same structure used to represent instruction fields. Uses of the new constant fields will be introduced in subsequent patches. 2025-10-10 GDB Administrator Automatic date update in version.in 2025-10-09 Tom Tromey Remove linespec.c:symtab_collector class linespec.c has a symtab_collector class that is readily replaced by a lambda. I think the result is more clear. I considered using the unordered_dense 'extract' method as well, to make the code a bit more efficient -- but it wasn't clear to me if the ordering of the vector mattered, and so I've just added a comment. Reviewed-By: Guinevere Larsen 2025-10-09 Tom Tromey Clean up iterate_over_symtabs After the "search via psyms" series, there's no need for iterate_over_symtabs to first check the expanded symtabs -- the callback will now be called for every relevant symtab, including ones that were already expanded before the search. Cleaning this up enables some other cleanups. In particular, iterate_over_some_symtabs is not needed in its current form, so here I've renamed it, made it static, and made it search just a single compunit symtab. While there I cleaned up the "invert" logic in objfile::map_symtabs_matching_filename. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30738 Reviewed-By: Guinevere Larsen 2025-10-09 Tom Tromey Remove an extraneous 'return' from void method cooked_index_functions::map_symbol_filenames returns 'void' but also does "return ... expression". While valid, this seems strange. This patch removes the unnecessary 'return'. Reviewed-By: Guinevere Larsen 2025-10-09 Tom Tromey Convert map_symbol_filenames to method This patch changes the free function map_symbol_filenames to be a method of program_space. This seems a bit cleaner, and also lets us hoist a use of the global into the callers. Reviewed-By: Guinevere Larsen 2025-10-09 Yodel Eldar doc/gdb.texinfo: Add EIO and ENOSYS errno values This patch adds the EIO and ENOSYS errno values supported by GDB's File-I/O to section E.14.9: Errno Values of the GDB manual [1] that were presumably inadvertently omitted; both can be seen in the enum fileio_error:gdbsupport/fileio.h and corresponding function host_to_fileio_error:gdbsupport/fileio.cc as FILEIO_{EIO,ENOSYS}. FILEIO_SUCCESS remains excluded from the manual, because its stated purpose (commit b872057a6) is to internally represent the absence of an error value from the remote, and it's not actually an error number. [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Errno-Values.html Approved-By: Simon Marchi Reviewed-By: Eli Zaretskii 2025-10-09 Alan Modra gas/macro.c getstring This code: if (in->ptr[idx] == '!') { idx++; sb_add_char (acc, in->ptr[idx++]); } and similar code in the other loop, blindly accessed the next element of the string buffer without first checking idx against in->len, leading to uninitialised accesses or buffer overruns. Fix that, and tidy the loops so that the function always returns the index one past the last char consumed. (It could return idx == in->len + 1). * macro.c (getstring): Don't access past end of input string buffer. Tidy loops. Don't return an index past in->len. 2025-10-09 Simon Marchi gdb/testsuite: make gdb.tui/gdb.sh work with dash gdb.tui/gdb.sh (used by test gdb.tui/tuiterm-2.exp) doesn't run well when /bin/sh is dash: $ bash testsuite/gdb.tui/gdb.sh foo^C $ dash testsuite/gdb.tui/gdb.sh footestsuite/gdb.tui/gdb.sh: 20: read: arg count shellcheck actually points it out: In testsuite/gdb.tui/gdb.sh line 20: read ^--^ SC3061 (warning): In POSIX sh, read without a variable is undefined. ^--^ SC2162 (info): read without -r will mangle backslashes. Fix the issue by passing the `_` dummy variable. Using that particular variable will not cause shellcheck to whine about it being unused. Also add `-r` to make it happy. Change-Id: Ida3eddbfa3473487743fc96615baf735b4773738 2025-10-09 GDB Administrator Automatic date update in version.in 2025-10-08 John David Anglin hppa64: Fix relocation handling for global data and a couple of thinkos This fixes relocation handling in situations where hh->owner and hh->sym_indx were not initialized. 2025-10-08 John David Anglin bfd/ChangeLog: PR binutils/6511 * elf64-hppa.c (global_sym_index): New from ia64. (elf64_hppa_check_relocs): Only set hh->eh.ref_regular if we have a regular definition. (elf64_hppa_check_relocs): Add missing NEED_DYNREL to need_entry assignment. (elf64_hppa_check_relocs): Stash symbol index and section earlier. (allocate_global_data_dlt): Initialize hh->owner and hh->sym_indx if not initialized. (allocate_global_data_opd): Likewise. Remove redundant checks for NULL hh. (allocate_dynrel_entries): Check for discarded hppa_info->other_rel_sec section. Add assert rent->sec->owner == hh->owner. (elf64_hppa_finalize_dynreloc): Check for discarded hppa_info->other_rel_sec section. (elf_hppa_final_link_relocate): Return bfd_reloc_ok if we have R_PARISC_NONE relocation. 2025-10-08 Tom de Vries [gdb/testsuite] Fix bp loc in gdb.server/fetch-exec-and-args.exp With test-case gdb.server/fetch-exec-and-args.exp, on aarch64-linux I run into: ... (gdb) break 28^M Breakpoint 1 at 0xfffff7fd7b8c: file ../sysdeps/aarch64/dl-start.S, line 30.^M (gdb) continue^M Continuing.^M ^M Breakpoint 1, _start () at ../sysdeps/aarch64/dl-start.S:30^M 30 mov x0, sp^M (gdb) PASS: $exp: packet=on: test_exec_and_arg_fetch: \ continue to breakpoint: run to breakpoint print argc^M No symbol "argc" in current context.^M (gdb) FAIL: $exp: packet=on: test_exec_and_arg_fetch: print argc ... The problem is that the "break 28" is not specific about the file. Fix this by setting the breakpoint on fetch-exec-and-args.c:28. Tested on aarch64-linux. PR testsuite/33522 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33522 2025-10-08 Tom de Vries [gdb/testsuite] Fix ERROR in expect_build_id_in_core_file With test-case gdb.python/py-corefile.exp I run into: ... PASS: $exp: test mapped files data: show-build-ids ERROR: tcl error sourcing gdb.python/py-corefile.exp. ERROR: bad option "0x1fa178": \ must be -nobackslashes, -nocommands, or -novariables while executing "subst 0x$offset + 0" ... Fix this using "[subst 0x$offset]" instead. Tested on x86_64-linux. 2025-10-08 Sébastien Darche gdb: add tests for per-inferior settings I am currently upstreaming some patches from ROCgdb that were made a few years ago. This series cleans up how the CLI and MI access parameters for multiple inferiors. A preceding patch (702991711a91 ("gdb: Have setter and getter callbacks for settings")) allowed for per-inferior getter/setter functions of some inferior-specific settings. Over the years a few changes were accepted upstream (cc09d372f664 ("gdb: make set/show args work with $_gdb_setting_str")) that implemented those capabilities. This patch adds a few tests to verify that those settings are properly set and accessed from the CLI, MI as well as the python interface. Co-Authored-By: Simon Marchi Change-Id: I7a5eab210c84d6a6782a32125f68bde34d9a2339 Approved-By: Andrew Burgess 2025-10-08 Sébastien Darche gdb: make deprecated_show_value_hack use its ui_file parameter If a setting does not provide a "show" function, we fall back to the deprecated_show_value_hack function to print the value in a generic way. The current version ignores the `file` parameter specifying the output file in favor of always using gdb_stdout. To make things consistent with how the values are printed using a regular show command, the proposed change makes the function use the ui_file parameter it receives (even though do_show_command passes gdb_stdout). Co-Authored-By: Simon Marchi Change-Id: I54028ed654a1fa4d955e6e46f979472c8d98ace9 Approved-By: Andrew Burgess 2025-10-08 Sébastien Darche gdb: do not recompute values for inferior parameters when showing them When calling the `show` command on a few inferior-specific settings (inferior-tty, args, cwd), GDB will recompute the values despite them being provided by a getter. For instance, When `show cwd` is called, `do_show_command` will query the value of the `cwd` through `get_inferior_cwd`, which already gets the per-inferior value. The current version seems to be a workaround from when settings could not provide a getter function and per-inferior settings could thus not be implemented properly, forcing the `show` implementation to recompute the value itself. The changes clean up the code and makes the show command trust the values it is being forwarded, as they will always be computed by the getter function. Co-Authored-By: Simon Marchi Change-Id: I3b25f61f9101d98a6df7d50cee50131aec7e25c9 Approved-By: Andrew Burgess 2025-10-08 Sébastien Darche gdb: use getter/setter command styles for "set tdesc filename" The target description filename command pair ("(set|get) tdesc filename") uses a rather indirect way to set the variable for the inferior, using a scratch variable to pass the value. While most other inferior-specific parameters were updated to the more direct getter/setter style functions, I believe this parameter was an oversight. This patch removes the intermediate string and directly accesses the tdesc filename for the current inferior. Co-Authored-By: Simon Marchi Change-Id: I2a87c65c9931ec91d15f854b32ac8279fe7077be Approved-By: Andrew Burgess 2025-10-08 Sébastien Darche [gdb/testsuite] fix gdb.server/server-kill.exp A test case in gdb.server/server-kill.exp attempts to query the server status after the server it is connected to has been killed. The connection is reset as expected, but the regex on the error message seems to be out-of-date. The test expects: Remote communication error. Target disconnected: Connection reset by peer. But a modern build of gdb yields : Remote communication error. Target disconnected: error while reading: Connection reset by peer. I presume this is due to change 0da23004a064 ("Change serial_readchar to throw") which added exceptions to the control flow handling instead of relying on perror(). The exception error string inserts "error while reading" to the perror message. The test appeared to fail intermittently, sometimes matching the first part of the regex ("Remote connection closed"). It now passes consistently. Change-Id: I3bf364b5d4b56de67f9ca30e9d636d3bb1be4119 Approved-by: Kevin Buettner 2025-10-08 Sébastien Darche [gdb/testsuite] fix gdb.multi/checkpoint-multi.exp without symbols The checkpoint-multi.exp test stops a program while it is sleeping using a call to the usleep() function from libc. The test checks whether the inferior is running by matching for "" (if the inferior is running) or a hex address followed by a function name, ideally, if the inferior is stopped. On most systems this works fine : (gdb) info checkpoints Id Active Target Id Frame * 1.0 y process 1546841 at 0x00007ffff7ceca7a, 1.1 n process 1547177 at 0x00005555555551f0, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/hello.c, line 51 2.0 y process 1547076 at 0x0000555555555243, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 46 2.1 n process 1547120 at 0x0000555555555285, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 61 I have found however that the output from `info checkpoints` is different on some systems with (stripped) versions of the libc without debug infos : (gdb) info checkpoints Id Active Target Id Frame * 1.0 y process 979642 at 0x00007ffff7e49687 1.1 n process 979647 at 0x00005555555551ac, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/hello.c, line 51 2.0 y process 979645 at 0x000055555555523b, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 46 2.1 n process 979646 at 0x0000555555555271, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 61 Where the frame can be found, but GDB cannot find the function. This fails the last two tests in checkpoint-multi.exp on those system, even though the behaviour is as expected. This patch removes the comma from the regex that matches with the frame number. The test now passes fine on the system. Change-Id: Iced4931d77f647046c87889455264cb169f480ff Approved-by: Kevin Buettner 2025-10-08 Sebastien Darche gdb: add Sébastien Darche to gdb/MAINTAINERS 2025-10-08 Simon Marchi gdb/python: cast to ui_file_style::intensity after validating value When GDB is built with undefined behavior sanitizer, gdb.python/py-style.exp fails because of this: $ ./gdb -q -nx --data-directory=data-directory -ex "python filename_style = gdb.Style('filename')" -ex "python filename_style.intensity = -3" /home/simark/src/binutils-gdb/gdb/python/py-style.c:239:11: runtime error: load of value 4294967293, which is not a valid value for type 'intensity' Fix it by casting the value to ui_file_style::intensity only after validating the raw value. Change-Id: I38eb471a9cb3bfc3bb8b2c88afa76b8025e4e893 Approved-By: Tom Tromey 2025-10-08 Andrew Burgess gdb/testsuite: fix failure from gdb.python/py-corefile.exp After commit: commit f69c1d03c4d6c68ae3f90facd63245426c028047 Date: Mon Aug 25 16:48:22 2025 +0100 gdb/python: add Corefile.mapped_files method Tom reported a failure: (gdb) check-build-ids Python Exception : build-id mismatch for /lib64/libc.so.6 Error occurred in Python: build-id mismatch for /lib64/libc.so.6 (gdb) FAIL: gdb.python/py-corefile.exp: test mapped files data: check-build-ids The discussion thread can be found here: https://inbox.sourceware.org/gdb-patches/de21b43c-e3bd-4354-aace-bd3f50c1c64c@suse.de There are a couple of problems. First, there is an issue where some versions of the linker didn't place the build-id within the first page of an ELF. As a result, the Linux kernel would not include the build-id in the generated core file, and so GDB cannot to find the build-id. In this patch I've added mitigation for this problem. I changed the 'check-build-ids' command (added via Python as part of the test) to 'show-build-ids'. The updated command prints a table containing the build-ids for each objfile as found via GDB's Progspace.objfiles, and via the Corefile.mapped_files. This table is then read by the TCL test script, and the build-ids are checked. If there's a difference, then GDB can analyse the on disk ELF and work out if the difference is due to the linker issue mentioned above. If it is, then the difference is ignored. In order to check for this linker issue I added a new helper proc to lib/gdb.exp, expect_build_id_in_core_file. The second problem with the original test is that it would consider separate debug files as files that should appear in the core file. There was Python code in the test that filtered the objfile list to disregard entries that would not appear in the core file, but this code needed extending to cover separate debug files. The final issue is that I'm only aware of GNU/Linux forcing the first page of every mapped ELF into the generated core files, so this test would likely fail on non-Linux systems. I've made the part of the test that relies on this behaviour Linux only. This change should resolve the FAIL that Tom reported. Giving Tom a Co-Author credit as he fixed the second issue, and helped a lot debugging the first issue. Co-Authored-By: Tom de Vries 2025-10-08 Tom Tromey Bump 'isort' version for pre-commit "pre-commit autoupdate" showed that there is a new version of isort available. This patch updates the config. No other changes were needed. 2025-10-08 Andrew Burgess gdb: remove program_space::core_bfd member function This commit removes the program_space::core_bfd member function, which was left in place as a temporary hack in the last commit in order to reduce the size of the last commit. In every place that 'current_program_space->core_bfd ()' was used I now call 'get_inferior_core_bfd (current_inferior ())'. I think there is further scope for improving things in the future, reducing the number of times we access the core file via global state, but doing that cleanup might be more involved than the clean up I've done up to this point. So I'm leaving that work for the future. But I think in some places, at the top level (e.g. user command functions), there's always going to be some cases where we just need to access the current global state, this is just the nature of the command handlers. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2025-10-08 Andrew Burgess gdb: move core file bfd from program_space into core_target This commit moves the 'gdb_bfd_ref_ptr cbfd' out of program_space and into core_target, where it is now called m_core_bfd. I believe this change makes sense as the core_target instance holds additional information that is parsed from the core file BFD, and so storing the parsed information separately from the BFD doesn't make much sense to me. To minimise the churn in this commit, I have retained the program_space::core_bfd member function as a temporary hack. This function forwards the request to the new function get_inferior_core_bfd. This works fine for now as program_space::core_bfd is, after this commit, only called on the current_program_space. If this all seems like a total hack, then it is, but don't worry too much, the next commit will clean this all up. I was tempted to make the new function get_inferior_core_bfd, a member function of the inferior class, inferior::core_bfd. In fact, that would have been my preferred change. However, the new function needs visibility of the core_target class, which, right now is private within the corelow.c file. This shouldn't be a problem, we could just declare the member function in inferior.h, and implement the function in corelow.c. But this would mean the implementation of inferior::core_bfd, would not live in inferior.c. Previously when I've implemented member functions outside their natural home (e.g. an inferior function not in inferior.c) I've received review feedback that this is not desirable. So, for now, I've gone with a free function. I also needed to change get_current_core_target, renaming it to get_core_target, and taking an inferior as an argument. Existing call sites are updated to pass 'current_inferior ()', but get_inferior_core_bfd passes something that might not be the current inferior. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2025-10-08 Andre Vieira aarch64, gas: Relax Armv9.6-A mandatory feature set Remove FPRCVT and SVE2p2 from the set of mandatory features for Armv9.6-A. 2025-10-08 Andrew Burgess gdb: fix for 'set suppress-cli-notifications on' missed case I noticed this behaviour: (gdb) info threads Id Target Id Frame 1 Thread 0xf7dbc700 (LWP 3161872) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6 * 2 Thread 0xf7dbbb40 (LWP 3161884) "thr" breakpt () at thr.c:19 (gdb) set suppress-cli-notifications on (gdb) thread 1 (gdb) thread 1 [Switching to thread 1 (Thread 0xf7dbc700 (LWP 3161872))] #0 0xf7eb2888 in clone () from /lib/libc.so.6 (gdb) I think that the second 'thread 1' should not produce any output just like the 'inferior' command, continuing in the same GDB session: (gdb) inferior 1 (gdb) Without suppress-cli-notifications we would see an inferior, thread, and frame being printed, but with suppress-cli-notifications set to on, we get no output. The difference in behaviours is that in inferior_command (inferior.c), we always call notify_user_selected_context_changed, even in the case where the inferior doesn't actually change. In thread_command (thread.c), we have some code that catches the thread not changed case, and calls print_selected_thread_frame. The notify_user_selected_context_changed function is only called if the thread actually changes. I did consider simply extending thread_command to check the global cli_suppress_notification.user_selected_context state and skipping the call to print_selected_thread_frame if suppression is on. However, I realised that calling print_selected_thread_frame actually introduces a bug. When the 'thread' command is used to select the currently selected thread, GDB still calls 'thread_selected'. And 'thread_select' always selects frame #0 within that thread, consider this session: (gdb) info threads Id Target Id Frame 1 Thread 0xf7dbc700 (LWP 723986) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6 * 2 Thread 0xf7dbbb40 (LWP 723990) "thr" breakpt () at thr.c:19 (gdb) bt #0 breakpt () at thr.c:19 #1 0x080491fd in thread_worker (arg=0xffff9514) at thr.c:31 #2 0xf7f7667e in start_thread () from /lib/libpthread.so.0 #3 0xf7eb289a in clone () from /lib/libc.so.6 (gdb) frame 3 #3 0xf7eb289a in clone () from /lib/libc.so.6 (gdb) thread 2 [Switching to thread 2 (Thread 0xf7dbbb40 (LWP 723990))] #0 breakpt () at thr.c:19 19 while (stop) (gdb) frame #0 breakpt () at thr.c:19 19 while (stop) (gdb) Notice that the frame resets back to frame #0. By only calling print_selected_thread_frame, and not calling notify_user_selected_context_changed, this means that GDB will fail to emit an MI async notification. It is this async notification which tells MI consumers that the frame has been reset to #0. And so, I think that the correct solution is, like with the 'inferior' command, to always call notify_user_selected_context_changed. This does mean that in some cases unnecessary MI notifications can be emitted, however, an MI consumer should be able to handle these. We could try to avoid these, but we would need to extend thread_command to check that neither the thread OR frame has changed after the call to thread_select, and right now, I'm not sure it's worth adding the extra complexity. I've rewritten the gdb.base/cli-suppress-notification.exp test to cover more cases, especially the reselecting the same thread case. And I've updated the gdb.mi/user-selected-context-sync.exp test to allow for the additional MI notifications that are emitted, and to check the frame reset case. While working on this change, I did wonder about calls to notify_user_selected_context_changed for frame related commands. In places we do elide calls to notify_user_selected_context_changed if the frame hasn't changed. I wondered if there were more bugs here? I don't think there are though. While changing the inferior will also change the selected thread, and the selected frame. And changing the thread will also change the selected frame. Changing the frame is the "inner most" context related thing that can be changed. There are no side effect changes that also need to be notified, so for these cases, I think we are fine. Also in infrun.c I fixed a code style issue relating to notify_user_selected_context_changed. It's not a functional change required by this commit, but it's related to this patch, so I'm including it here. Reviewed-By: Tankut Baris Aktemur Tested-By: Tankut Baris Aktemur Approved-By: Tom Tromey 2025-10-08 Hans-Peter Nilsson Maciej W. Rozycki cris: bfd: Default selected target to the configured target Whether targ_defvec is set to the best match for the configured target or some of the other supported targets usually doesn't matter, as the actual target being used, usually is set by some other mechanism, like an input object file. In some situations it matters though: it might be confusing to see --help output not showing the configured target first in the list of supported targets. Also, some corner cases risk running into bugs like PR33485, for cris-elf and cris-linux because cris_aout_vec is the default target where instead the bug-free behavior of cris_elf32_us_vec or cris_elf32_vec would be expected. The test just verifies that the target list emitted for the --help option has the expected target first. bfd: * config.bfd : Split into , , cases respectively setting targ_defvec per the target instead of always cris_aout_vec. binutils: * testsuite/binutils-all/cris: New directory intended for tests focused on behavior of the binutils programs, not the assembler or linker. * testsuite/binutils-all/cris/cris.exp: New file with run_dump_test loop. testsuite/binutils-all/cris/tgt-a.d, testsuite/binutils-all/cris/tgt-e.d, testsuite/binutils-all/cris/tgt-l.d: New tests. 2025-10-08 GDB Administrator Automatic date update in version.in 2025-10-07 Simon Marchi gdbsupport: make reference_to_pointer_iterator's constructor non-variadic For the same reason as the previous patches (making things easier to understand, at the cost of being more explicit), change reference_to_pointer_iterator's constructor to take an already built underlying iterator. There are no uses of this utility in the code base right now, so no callers to update. Change-Id: Ifadb4c3a5ee53a8d0eb6c0d79efcc92271492e8e Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdbsupport: remove variadicity from filtered_iterator constructor For the same reason as the previous patches (making things easier to understand, at the cost of being more explicit), remove filtered_iterator's variadic constructor, forcing the callers to pass already built underlying iterators. Change-Id: I1a9b6d43f3f087579b61b90b6f8f4128d66e19a1 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdbsupport: remove variadicity from basic_safe_iterator constructors Change the constructors to accept `Iterator` objects directly. This requires the callers to explicitly pass `Iterator` object (unless perhaps `Iterator` has a non-explicit one-argument constructor. The rationale is the same as the previous patch: make the code easier to follow and make it easier to fix build errors, at the expense of making callers more explicit. Change-Id: Icd2a4ef971456ca250f96227a9b83c935d619451 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdbsupport: remove variadicity from iterator_range constructor There are two ways to build an iterator_range: - Using the variadic constructor, where the arguments you pass are used to construct the "begin" underlying iterator. The "end" iterator is obtained by default-constructing the underlying iterator. - Using the other constructor, by explicitly providing the "begin" and "end" iterators. My experience is that using the variadic constructor is very confusing, especially when you have multiple layers of iterator wrappers. It's not obvious where the arguments you provide end up. When you have a compilation error, it is hard to decipher. I propose to remove the variadicity of the first constructor of iterator_range, and subsequently of the other iterator wrappers. This requires callers to be more verbose, explicitly instantiate all the layers. But since we only instantiate these iterator wrappers in factory functions, I think it's fine. If there is a compilation error, it will be much easier to find and fix the problem. Using the new one-argument constructor, it is still assumed that the end iterator can be obtained by default-constructing the underlying iterator type, which I think is fine and not too confusing. Change-Id: I54d6fdef18bcd7e308825064e0fc18fadd7ca717 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdb: change objfiles_iterator to yield references Same rationale as the previous patches. Change-Id: I4673cedaa902c9a327d24d73508b18cf60a2cd02 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdb: make lwp_info_iterator yield references Same rational as the previous patches. Change-Id: I36852ec0c94dc3a87e3af033ca5e55c6b0f708b1 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdb: change thread_step_over_list_iterator to yield references Same rationale as the previous patches. Change-Id: Ic46e2e6b81b17173f4137ff4a0970c84aab4de61 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdb: change all_threads_safe to yield references To be consistent with all_threads and the others, following the previous patch. Change-Id: I4ee4ff32b005fc5554a9d637725f10fca70cee14 Approved-By: Tom Tromey 2025-10-07 Simon Marchi gdb: change inf_threads_iterator to yield references When adding reference_to_pointer_iterator, I saw it as a temporary thing, to not have to do a codebase-wide change right away. Remove it from inf_threads_iterator and adjust all the users. It's very possible that I forgot to update some spots in the files I can't compile, but it will be very easy to fix if that happens. Change-Id: Iddc462fecfaafb6a9861d185b217bc714e7dc651 Approved-By: Tom Tromey 2025-10-07 Tom Tromey Remove 'sys' import from frame_filters.py pre-commit (really flake8) points out that a recent change to frame_filters.py left an unused import. This patch fixes the problem. 2025-10-07 Andrew Burgess gdb/python: make use of gdb.Style for shipped Python commands With the recent addition of the gdb.Style Python API, this commit goes through the gdb.Command sub-classes which we ship with GDB and adds some styling support. This adds 'title' style in a couple of places where we layout tables. And uses 'filename' style where we are printing filenames. While I was making these changes I've made a couple of related fixes. In 'info frame-filter', 'info missing-objfile-handlers', 'info pretty-printer', and 'info xmethod', we would sometimes print the gdb.Progspace.filename unconditionally, even though this field can sometimes be None. To better handle this case, I now check for None, and print '' instead. We already printed that same string for the program space name in at least one other case, so this change makes things a little more consistent. I don't format the '' string with the filename style, only if we have an actual filename does the string get formatted. The other fix I made was in 'maint info python-disassemblers'. Here I've added an extra space between the two columns in the output table. The two columns are 'Architecture' and 'Disassembler Name'. Given that one column contains a white space, it was rather confusing having a single space between columns. Luckily the tests don't depend on a single space, so nothing needs updating for this change. Additionally, in 'info frame-filter' I've updated the exception handling to use the gdb.warning function, rather than just printing a line of output. This means that should this case occur we get the neat little emoji. We have no tests that trigger this warning, and I couldn't figure out how to write one. In this end, I just hacked the Python code to raise an exception and checked the output looked reasonable. I suspect this warning might be a hard one to trigger! Approved-By: Tom Tromey 2025-10-07 Tom Tromey Ignore artificial fields in Ada A user found an unusual Ada situation that DWARF does not readily support. Consider this type: type Discrete_Typ is tagged null record; type Int_Typ (Is_Static : Boolean) is new Discrete_Typ with null record; type Signed_Int_Typ (Is_Static : Boolean) is new Int_Typ (Is_Static => Is_Static) with record case Is_Static is when True => Field : Integer; when others => null; end case; end record; Here, Signed_Int_Typ has a variant part where the discriminant is stored in a superclass. Anyway, this code caused gnat-llvm to crash. While fixing the crash, I decided to fix this by emitting an anonymous field in Signed_Int_Typ that represents the discriminant. This would allow member DIEs to refer to it -- which I suppose is possibly why DWARF specified that the discriminant should be a member of the variant (though I don't really know; this decision always seemed very strange to me). Making the field anonymous lead to the strange error: Type ... is not a structure or union type. ... which comes from lookup_struct_elt, which fails when an anonymous member of a structure has a non-composite type. This patch includes a fix for this issue. After fixing that, though I decided it would be better if the artificial discriminant were still given a name. So, this patch includes a change to ada_is_ignored_field to ignore artificial fields. Approved-By: Andrew Burgess 2025-10-07 Tom Tromey Remove some helper functions from DAP breakpoint code The DAP breakpoint code has some helper functions that don't really provide much value any more. This patch removes them. Approved-By: Andrew Burgess 2025-10-07 Tom Tromey Fix compile-ops.exp The recent change to change the parsing of location expressions in the test suite broke compile-ops.exp. I neglected to update that patch. This patch fixes the oversight. 2025-10-07 Alan Modra tidy coff-alpha.c Remove K&R required casts. Formatting fixes. Localise vars in alpha_ecoff_get_elt_at_filepos and tidy decompression loop. 2025-10-07 Tom de Vries [gdb/symtab] Improve invalid range check in create_addrmap_from_gdb_index When running test-case gdb.tui/tui-missing-src.exp with target board gold-gdb-index (and likewise fission and fission-dwp) on aarch64-linux, I run into: ... FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 () ... Looking at the gold-gdb-index case, the problem is caused by the address table of the .gdb_index section: ... Address table: 000000000040066c 0000000000400694 0 000000000040053f 0000000000400563 1 ... The address range for f2 is [0x400694, 0x4006b8), but the address table says it's [0x40053f, 0x400563). The address 0x40053f is not even in a section: ... [Nr] Name Type Address Off Size ES Flg Lk Inf Al ... [12] .plt PROGBITS 00000000004004b8 0004b8 000050 10 AX 0 0 8 [13] .text PROGBITS 0000000000400540 000540 000178 00 AX 0 0 64 ... but part of the hole [0x400508, 0x400540) in between .plt and .text. Detect this in the invalid range check in create_addrmap_from_gdb_index. Tested on aarch64-linux. Approved-By: Simon Marchi 2025-10-07 GDB Administrator Automatic date update in version.in 2025-10-06 Maciej W. Rozycki MIPS/BFD: Fix rightshift for remaining n32 reloc howtos Correct the rightshift amount for the R_MIPS_HIGHER, R_MIPS_HIGHEST and R_MIPS_CALL_HI16 RELA relocation howtos, missed with commit f38e9921479a ("MIPS HI16 and LO16 reloc howtos"). 2025-10-06 Maciej W. Rozycki MIPS/BFD: Account for VxWorks .got.plt references On VxWorks calls can refer directly to a .got.plt entry, in which case they won't have an entry in the regular GOT. It was missed with commit 6c42ddb92b90 ("MIPS GOT: Remove TLS GOT info from the symbol table"), , which revamped GOT entry bookkeeping, and consequently space for regular GOT entries is needlessly reserved and then not used, with extraneous null dynamic relocations attached, e.g.: Relocation section '.rela.dyn' at offset 0x1400 contains 11 entries: Offset Info Type Sym.Value Sym. Name + Addend 00080c0c 00000405 R_MIPS_HI16 00000000 __GOTT_BASE__ + 0 00080c10 00000406 R_MIPS_LO16 00000000 __GOTT_BASE__ + 0 00080c14 00000601 R_MIPS_16 00000000 __GOTT_INDEX__ + 0 0008141c 00000002 R_MIPS_32 80c5c 00081800 00000002 R_MIPS_32 80c5c 00081804 00000002 R_MIPS_32 81800 00081808 00000502 R_MIPS_32 00081808 dglobal + 0 0008180c 00000202 R_MIPS_32 00000000 dexternal + 0 00081428 00000a02 R_MIPS_32 00081c00 x + 0 00000000 00000000 R_MIPS_NONE 0 00000000 00000000 R_MIPS_NONE 0 Adjust regular GOT entry counting then to take .got.plt entries into account, removing a regression from the commit referred: mips-vxworks -FAIL: VxWorks shared library test 1 mipsel-vxworks -FAIL: VxWorks shared library test 1 2025-10-06 Maciej W. Rozycki MIPS/LD/testsuite: Adapt VxWorks segment matching for PR ld/20815 fix Adjust segment addresses in the program header dump to account for the inclusion of the program headers in the segment, removing a regression from commit 1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix readelf to report such invalid binaries."): mips-vxworks -FAIL: VxWorks executable test 2 (dynamic) mipsel-vxworks -FAIL: VxWorks executable test 2 (dynamic) 2025-10-06 Maciej W. Rozycki TIC6X/GAS: Work around array bounds compilation error Work around a compilation error: .../gas/config/tc-tic6x.c: In function 'tic6x_start_unwind_section': .../gas/config/tc-tic6x.c:4632:17: error: offset '16' outside bounds of constant string [-Werror=array-bounds] 4632 | text_name += strlen (".gnu.linkonce.t."); | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ observed with GCC 10. 2025-10-06 Maciej W. Rozycki IA-64/GAS: Work around format truncation compilation errors Work around compilation errors: .../gas/config/tc-ia64.c: In function 'declare_register_set': .../gas/config/tc-ia64.c:5375:41: error: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size 8 [-Werror=format-truncation=] 5375 | snprintf (name, sizeof (name), "%s%u", prefix, i); | ^~ .../gas/config/tc-ia64.c:5375:38: note: directive argument in the range [0, 4294967294] 5375 | snprintf (name, sizeof (name), "%s%u", prefix, i); | ^~~~~~ .../gas/config/tc-ia64.c:5375:7: note: 'snprintf' output 2 or more bytes (assuming 11) into a destination of size 8 5375 | snprintf (name, sizeof (name), "%s%u", prefix, i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ observed with GCC 10. Pick 16 for a round 64-bit stack frame size. 2025-10-06 Matthieu Longo aarch64: GICv5 hypervisor control system registers This patch adds support for hypervisor control registers on AArch64, available via the Generic Interrupt Controller v5 feature, and enabled via the +gcie flag. - ich_apr_el2 - ich_contextr_el2 - ich_hfgitr_el2 - ich_hfgrtr_el2 - ich_hfgwtr_el2 - ich_hppir_el2 (RO) - ich_ppi_activer[0,1]_el2 - ich_ppi_dvir[0,1]_el2 - ich_ppi_enabler[0,1]_el2 - ich_ppi_pendr[0,1]_el2 - ich_ppi_priorityr[0,15]_el2 - ich_vctlr_el2 - ich_vmcr_el2 2025-10-06 Matthieu Longo aarch64: GICv5 PPI system registers This patch adds support for PPI registers on AArch64, available via the Generic Interrupt Controller v5 feature, and enabled via the +gcie flag. - icc_ppi_cactiver[0,1]_el1 - icc_ppi_cpendr[0,1]_el1 - icc_ppi_enabler[0,1]_el1 - icc_ppi_hmr[0,1]_el1 (RO) - icc_ppi_priorityr[0,15]_el1 - icc_ppi_sactiver[0,1]_el1 - icc_ppi_spendr[0,1]_el1 Also, the new system register 'icc_ppi_priorityr8_el1' clashed with the encoding of 's3_0_c12_c15_0' used in a test for the generic syntax of system registers using mrs and msr. This patch replaces 's3_0_c12_c15_0' in the test by an unused encoding: s3_7_c0_c15_0. 2025-10-06 Matthieu Longo aarch64: GICv5 CPU interface system registers This patch adds support for 13 new AArch64 system registers for the CPU interface, which are enabled on using Generic Interrupt Controller v5 (+gcie flag) feature: - 7 R/W registers: ICC_APR_EL1, ICC_APR_EL3, ICC_CR0_EL1, ICC_CR0_EL3 ICC_ICSR_EL1, ICC_PCR_EL1, ICC_PCR_EL3. - 6 RO registers: ICC_DOMHPPIR_EL3, ICC_HAPR_EL1, ICC_HPPIR_EL1, ICC_HPPIR_EL3, ICC_IAFFIDR_EL1, ICC_IDR0_EL1. Note: the already-existing ID_AA64PFR2_EL1 register is required by the GICv5 feature. 2025-10-06 Saurabh Jha gas: aarch64: Add instructions for GICv5 Add new instructions from the Generic Interrupt Controller, GICv5, extension. These instructions are aliases to system instructions and are the following: * gic , * gicr , * gsb 2025-10-06 Saurabh Jha gas: aarch64: Add flag for GICv5 Generic Interrupt Controller v5, GICv5, adds new system registers and system instructions. These are enabled with the +gcie flag, where gcie stands for GICv5 (Generic Interrupt Controller) CPU Interrupt Extension. 2025-10-06 Indu Bhagat libsframe: testsuite: make test names unique Previous commit 4dc07bf6 missed making some of the testnames in encode-1 unique. libsframe/testsuite/ PR libsframe/33437 * libsframe.encode/encode-1.c: Update test name to ensure they are unique. 2025-10-06 Andrew Burgess gdb/python: add Corefile.mapped_files method Add a new Corefile.mapped_files method which returns a list of gdb.CorefileMappedFile objects. Each gdb.CorefileMappedFile object represents a file that was mapped into the process when the core file was created. A gdb.CorefileMappedFile has attributes: + filename -- A string, the name of the mapped file. + build_id -- A string or None, the build-id of the mapped file if GDB could find it (None if not). + is_main_executable -- A boolean, True if this mapping is the main executable. + regions -- A list containing the regions of this file that were mapped into the process. The 'regions' list is a list of gdb.CorefileMappedFileRegion objects, each of these objects has the following attributes: + start -- the start address within the inferior. + end -- the end address within the inferior. + file_offset -- the offset within the mapped file for this mapping. There are docs and tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Approved-By: Tom Tromey 2025-10-06 Andrew Burgess gdb: make structured core file mappings processing global In corelow.c, within core_target::build_file_mappings, we have code that wraps around a call to gdbarch_read_core_file_mappings and provides more structure to the results. Specifically, gdbarch_read_core_file_mappings calls a callback once for every region of every mapped file. The wrapper code groups all of the mappings for one file into an instance of 'struct mapped_file', this allows all of the mapped regions to be associated with the build-id and filename of a file. In the next commit I plan to make this information available via the Python API, and so I need to allow access to this structured wrapping outside of corelow.c. This commit renames 'struct mapped_file' to 'struct core_mapped_file' and moves the struct into gdbcore.h. Then a new global function gdb_read_core_file_mappings is created into which I move the code to build the structured data. Then corelow.c is updated to call gdb_read_core_file_mappings. This commit does not extend the Python API, that is for the next commit. There should be no user visible changes after this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Approved-By: Tom Tromey 2025-10-06 Andrew Burgess gdb/python: introduce gdb.Corefile API This commit starts adding some core file related features to the Python API. In this initial commit I've tried to keep the changes as small as possible for easy review. There's a new Python class gdb.Corefile, which represents a loaded core file. This API doesn't allow the user to create their own gdb.Corefile objects, a core file must be loaded using the 'core-file' command, then a gdb.Corefile object can be obtained by querying the inferior in which the core file was loaded. There's a new attribute gdb.Inferior.corefile, this is None when no core file is loaded, or contains a gdb.Corefile object if a core file has been loaded. Currently, the gdb.Corefile object has one attribute, and one method, these are: gdb.Corefile.filename -- the file name of the loaded core file. gdb.Corefile.is_valid() -- indicates if a gdb.Corefile object is valid or not. See notes below. A gdb.Corefile object is only valid while the corresponding core file is loaded into an inferior. Unloading the core file, or loading a different one will cause a gdb.Corefile object to become invalid. For example: (gdb) core-file /tmp/core.54313 ... snip ... (gdb) python core=gdb.selected_inferior().corefile (gdb) python print(core) (gdb) python print(core.is_valid()) True (gdb) core-file No core file now. (gdb) python print(core) (gdb) python print(core.is_valid()) False (gdb) In order to track changes to the core file, there is a new observable 'core_file_changed', which accounts for the changes in corelow.c, observable,c, and observable.h. Currently, this observable is not visible as a Python event. I chose to access the core file via the inferior even though the core file BFD object is actually stored within the program_space. As such, it might seem that the natural choice would be to add the attribute as gdb.Progspace.corefile. For background reading on my choice, please see: https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com This patch was never merged, it is still on my backlog, but the observation in that work is that some targets are not really shareable. For example, the core_target (corelow.c) stores information about the loaded core file within the target instance. As such, each target instance represents a single loaded core file. Except that the BFD part of the core file is stored in the program_space, which is a little weird. During review, Tom made the observation, that maybe we should investigate moving the core file BFD into the core_target. I'm inclined to agree with this as a direction of travel. All this leaves us with two observations: 1. Currently, loading a core file into an inferior, then using 'add-inferior' will try to share the core_target between inferiors. This is broken, and can trigger GDB crashes. The obvious fix, without reworking core_target, is just to prevent this sharing, making core_target per-inferior. 2. Having the core file information split between the core_target instance, and the BFD stored in the program_space is a little weird, and is really just historical. Planning for a future where the BFD is also stored in the core_target might be wise. So, if we imagine that the BFD is (one day) moved into the core_target, and that the core_target really becomes non-shareable, then it is, I think, clearer that the corefile attribute should live on the gdb.Inferior object, not the gdb.Progspace object. There's testing for all the functionality added in this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-06 Tom Tromey Make location expressions be code in DWARF assembler Currently the DWARF assembler implements manual parsing for location expressions. With a recent refactoring, this lead to the use of [subst] in a number of places. Following the same logic as the DW_AT_* change, this patch changes location expressions to simply be nested Tcl code. This avoids the need for subst and also allows more complex logic, should that ever be needed. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33402 2025-10-06 Tom Tromey Store the "uplevel" target in DWARF assembler This changes the DWARF assembler to store the desired "uplevel" frame in Dwarf::assemble. This frame is then used in the relevant "uplevel" invocations in the assembler. This is primarily useful for the next patch, but it also seems somewhat cleaner in general to me, as the implementation can now be refactored without worrying too much about introducing new stack frames. 2025-10-06 Tom Tromey More "return" cleanup in gdb.ada I found some more spots in gdb.ada where a "return" has a value but does not need one. This patch cleans these up. Most of these would be eliminated by the old "critical" idea, if I ever got around to finishing that... Approved-by: Kevin Buettner 2025-10-06 timurgol007 gdb: tidy RISC-V part in gdb/Makefile.in and gdb/configure.tgt I noticed that the length of line in gdb/configure.tgt was more than 80 lines, so I straightened it out. Also, in gdb/Makefile.in newly added file riscv-linux-canonicalize-syscall-gen.c was missed in ALLDEPFILES, so I added it there. And the last change: one more file riscv-linux-canonicalize-syscall-gen.o was not in alphabetical order. 2025-10-06 Alan Modra alpha-ecoff: check archive element size If we run out of file before decompression finishes, the archive is broken. Don't allow the buffer to be returned with uninitialised data. * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Return an error if the full element size can't be decompressed. 2025-10-06 Alan Modra vms-alpha: integer overflow image_offset takes values from section vma then increments when filling out section data. Avoid signed integer overflow. * vms-alpha.c (struct vms_private_data_struct): Make image_offset unsigned. 2025-10-06 Alan Modra segv in debug_write_type In commit 6c3458a8b7ee I claimed that u.kenum is always non-NULL, which is true for debug_make_enum_type, but not for enums made by debug_make_undefined_tagged_type. Fix that oversight PR 32829 * debug.c (debug_write_type): Handle NULL u.kenum. (debug_type_samep): Likewise. 2025-10-06 Alan Modra readelf reloc range check A fuzzed object file hit this sanitizer error. readelf.c:16764:9: runtime error: pointer index expression with base 0x6dd4491e1590 overflowed to 0xe7af96d4491e17a1 The same could occur in any of the IN_RANGE reloc checks, where the reloc address is calculated as "start + r_offset" then compared against "start" and "end". So don't do that. Compare r_offset against the memory size, first. * readelf.c (IN_RANGE): Delete. (in_range): New inline funcion. (target_specific_reloc_handling): Replace "end" param with "size". Update uses. Replace IN_RANGE with in_range. (apply_relocations): Delete "end" variable. Update target_specific_reloc_handling calls and replace IN_RANGE. Avoid pointer overflow. 2025-10-06 Alan Modra msp430: extended_dst disassembly This avoids a gcc-14.2 bug reporting an "error: null destination pointer" on an sprintf buffer that is not NULL. Don't ask me why this happens to work. * msp430-dis.c (msp430_singleoperand): Don't overprint op or comm for extended_dst. 2025-10-06 GDB Administrator Automatic date update in version.in 2025-10-05 Tom Tromey Rename "fp" in ctfread.c Earlier reviews pointed out that "fp" is a poor choice of name in ctfread.c. Nick suggested "dict" instead, so this patch makes this change. 2025-10-05 Tom Tromey Rework domain choices in ctfread.c Another patch I am working on induced some failures in CTF tests. Looking into this, I found that ctfread.c seems to largely work by accident. In particular, it often chooses the wrong domain for a symbol. In CTF, I believe there are 4 kinds of symbols: types, variables, functions, and "data objects" (which IIUC may be either a variable or a function). ctfread.c was examining the type-kind of a variable and sometimes treating one as a type. add_stt_entries and ctf_psymtab_add_stt_entries only ever used VAR_DOMAIN (but are called for functions, which should be in FUNCTION_DOMAIN). And ctf_psymtab_type_cb sometimes used VAR_DOMAIN, but is only called for types, and so should only ever use TYPE_DOMAIN or STRUCT_DOMAIN. This patch cleans all this up, based on my understanding of the situation. This passes the existing tests, and also works with my aforementioned yet-to-be-submitted patch as well. Finally, I renamed new_symbol because it is only used for type symbols. Acked-By: Simon Marchi 2025-10-05 Tom Tromey Fix name checks in ctfread.c I noticed that ctfread.c could create a symbol with the name "". This happens because a couple of spots check that a name is not NULL -- but libctf never returns such names. Instead check the string contents. I left the NULL checks in for robustness. Note that other spots in ctfread.c already do check the contents of the name. I changed these to avoid strlen and instead check the first character. Approved-By: Simon Marchi 2025-10-05 Tom Tromey Remove ctf_tid_key ctfread.c creates two per-objfile registry keys. However, one is sufficient. This patch combines the two. Approved-By: Simon Marchi 2025-10-05 Tom Tromey Remove unnecessary call to set_tid_type ctfread.c:read_typedef_type calls set_tid_type twice, but the second call is unnecessary. Approved-By: Simon Marchi 2025-10-05 Tom Tromey Stack allocate buildsym_compunit in ctfread.c ctfread.c uses raw "new" and "delete", but for an object that could just as easily be stack allocated. Approved-By: Simon Marchi 2025-10-05 Tom Tromey Remove ctf_per_tu_data::pss The field ctf_per_tu_data::pss is unused and can be removed. Approved-By: Simon Marchi 2025-10-05 Tom Tromey Use gdb::unordered_map in ctfread.c This changes ctfread.c to use gdb::unordered_map rather than hashtab. This simplifies the code. Approved-By: Simon Marchi 2025-10-05 Tom de Vries [gdb/testsuite, tclint] Fix lib/gdb.exp [gdb/testsuite, tclint] Fix lib/aarch64-scalable.exp [gdb/testsuite, tclint] Fix lib/aarch64.exp [gdb/testsuite, tclint] Fix lib/mi-support.exp [gdb/testsuite, tclint] Fix lib/dwarf.exp [gdb/testsuite, tclint] Fix lib/gen-perf-test.exp [gdb/testsuite, tclint] Fix lib/pascal.exp [gdb/testsuite, tclint] Fix lib/gdbserver-support.exp [gdb/testsuite, tclint] Fix lib/prelink-support.exp [gdb/testsuite, tclint] Fix lib/trace-support.exp [gdb/testsuite, tclint] Fix lib/future.exp [gdb/testsuite, tclint] Fix lib/perftest.exp [gdb/testsuite, tclint] Fix lib/selftest-support.exp [gdb/testsuite, tclint] Fix lib/cp-support.exp [gdb/testsuite, tclint] Fix lib/gdb-utils.exp [gdb/testsuite, tclint] Fix lib/check-test-names.exp [gdb/testsuite, tclint] Fix lib/rust-support.exp [gdb/testsuite, tclint] Fix lib/prompt.exp [gdb/testsuite, tclint] Fix lib/objc.exp [gdb/testsuite, tclint] Fix lib/jit-elf-helpers.exp [gdb/testsuite, tclint] Fix lib/go.exp [gdb/testsuite, tclint] Fix lib/gdbreplay-support.exp [gdb/testsuite, tclint] Fix lib/fortran.exp [gdb/testsuite, tclint] Fix lib/d-support.exp [gdb/testsuite, tclint] Fix lib/debuginfod-support.exp [gdb/testsuite, tclint] Fix lib/cache.exp [gdb/testsuite, tclint] Fix lib/gdb-guile.exp [gdb/testsuite, tclint] Fix lib/dtrace.exp [gdb/testsuite, tclint] Fix lib/completion-support.exp [gdb/testsuite, tclint] Fix lib/ada.exp 2025-10-05 Tom Tromey Fix some flake8 warnings "pre-commit run --all" shows some flake8 warnings coming from a recent patch. There was no real bug here, but this fix silences the warnings. 2025-10-05 Andrew Burgess gdb/python: extend gdb.write to support styled output It is already possible to produce styled output from Python by converting the gdb.Style to its escape code sequence, and writing that to the output stream. But this commit adds an alternative option to the mix by extending the existing gdb.write() function to accept a 'style' argument. The value of this argument can be 'None' to indicate no style change should be performed, this is the default, and matches the existing behaviour. Or the new 'style' argument can be a gdb.Style object, in which case the specified style is applied only for the string passed to gdb.write, after which the default style is re-applied. Using gdb.write with a style object more closely matches how GDB handles styling internally, and has the benefit that the user doesn't need to remember to restore the default style when they are done. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-05 Andrew Burgess gdb/python: new class gdb.StyleParameterSet Add a new helper class gdb.StyleParameterSet. This new class can be used to simplify creation of new style parameter sets. A style parameter set is the 'foreground', 'background', and (optionally), the 'intensity' settings, all grouped under a single prefix command. And example usage is: (gdb) python s = gdb.StyleParameterSet("my-style") (gdb) show style my-style style my-style background: The "my-style" style background color is: none style my-style foreground: The "my-style" style foreground color is: none style my-style intensity: The "my-style" style display intensity is: normal (gdb) Having created a gdb.StyleParameterSet, the object itself can be used to access a named style corresponding to the setting group, like this: (gdb) python print(s.style) (gdb) Of course, having access to the gdb.Style makes it easy to change the settings, or the settings can be adjusted via the normal CLI 'set' commands. As gdb.StyleParameterSet manages a set of parameters, and the gdb.Parameter class uses Parameter.value as the attribute to read the parameter's value, there is also StyleParameterSet.value, but this is just an alias for StyleParameterSet.style, that is, it allows the gdb.Style object to be read and written too. It is worth noting that this class only creates a single level of prefix command. As an example GDB has style 'disassembler mnemonic', where the 'disassembler' part is a group of related styles. If a user wanted to create: style my-style-group style-1 style-2 style-3 Where each of 'style-1', 'style-2', and 'style-3' will have the full set of 'foreground', 'background', and 'intensity', then the gdb.StyleParameterSet can be used to create the 'style-N' part, but the user will have to create the 'my-style-group' prefix themselves, possibly using gdb.ParameterPrefix, e.g.: gdb.ParameterPrefix("style my-style-group", gdb.COMMAND_NONE) gdb.StyleParameterSet("my-style-group style-1") gdb.StyleParameterSet("my-style-group style-2") gdb.StyleParameterSet("my-style-group style-3") Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-05 Andrew Burgess gdb/python: add gdb.Style class This commit adds a new gdb.Style class. This class represents a complete style within GDB. A complete style is a collection of foreground color, background color, and an intensity. A gdb.Style comes in two flavours, named, and unnamed. A named style is one that is based on an existing style within GDB. For example, we have 'set style filename ...', the name of this style is 'filename'. We also have 'set style disassembler mnemonic ...', the name of this style is 'disassembler mnemonic'. A named style is created by passing the name of the style, like this: (gdb) python s1 = gdb.Style("filename") (gdb) python s2 = gdb.Style("disassembler mnemonic") The other type of style is an unnamed style. An unnamed style is created using a foreground and background color, along with an intensity. Colors are specified using gdb.Color objects. An example of creating an unnamed style is: (gdb) python s3 = gdb.Style(foreground=gdb.Color('red'), background=gdb.Color('green'), intensity=gdb.INTENSITY_BOLD) We can see here an example of the new intensity constants that have been added in this commit, there is gdb.INTENSITY_NORMAL, gdb.INTENSITY_BOLD, and gdb.INTENSITY_DIM. All of the arguments are optional, the default for the colors is gdb.Color(), which will apply the terminal default, and the default intensity is gdb.INTENSITY_NORMAL. Having created a gdb.Style object there are two ways that it can be used to style GDB's output. The Style.escape_sequence() method returns the escape sequence needed to apply this style, this can be used as in: (gdb) python print(s1.escape_sequence() + "Filename Style") The problem with this approach is that it is the users responsibility to restore the style to the default when they are done. In the above example, all output after the escape sequence is printed, including the next GDB prompt, will be in the s1 (filename) style. Which is why the Style.apply method exists. This method takes a string and returns the same string with escape sequences added before and after. The before sequence switches to the style, while the after escape sequence restores the terminal default style. This can be used like: (gdb) python print(s1.apply("Filename Style")) Now only the 'Filename Style' text will be styled. The next GDB prompt will be in the default terminal style. Personally, I think the apply method is the more useful, but having 'escape_sequence' matches what gdb.Color offers, though if/when this patch is merged, I might propose a similar 'apply' type method for the gdb.Color class. The gdb.Style class has 'foreground', 'background', and 'intensity' attributes which, when read, return the obvious values. These attributes can also be written too. When writing to an attribute of an unnamed Style object then the Style object itself is updated, as you might expect. When writing to an attribute of a named Style then the style setting itself is updated as the following example shows: (gdb) python s1 = gdb.Style("filename") (gdb) python print(s1.foreground) green (gdb) show style filename foreground The "filename" style foreground color is: green (gdb) python s1.foreground=gdb.Color("red") (gdb) python print(s1.foreground) red (gdb) show style filename foreground The "filename" style foreground color is: red (gdb) We can see that a gdb.Style object is connected to the underlying style settings, it doesn't take a copy of the style settings at creation time. And the relationship works both ways. Continuing the above example: (gdb) set style filename foreground blue (gdb) python print(s1.foreground) blue (gdb) Here we see that changing the setting value causes the gdb.Style object to update. And this is what you would want. I imagine this being used in a Python extension to GDB, where a user might create global objects for some named styles, and then use these globals to format output from some custom commands. If a user of an extension changes a style setting then the extension wants to adapt to that change. Both the Style.escape_sequence and Style.apply methods take the global style enabled setting into consideration. If styling is disabled then Style.escape_sequence will return an empty string, and Style.apply will return an unmodified copy of the original string object (actually the input object with Py_INCREF applied). There is also support for representing a gdb.Style as a string: (gdb) python s1 = gdb.Style("filename") (gdb) python print(s1) (gdb) Unnamed styles are similar, but don't have a 'name' field. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-05 GDB Administrator Automatic date update in version.in 2025-10-04 H.J. Lu elf: Define ABI_64_P in elf-bfd.h Define ABI_64_P in elf-bfd.h to avoid duplications. * elf-bfd.h (ABI_64_P): New. * elfxx-mips.c (ABI_64_P): Removed. * elfxx-sparc.c (ABI_64_P): Likewise. * elfxx-tilegx.c (ABI_64_P): Likewise. * elfxx-x86.h (ABI_64_P): Likewise. 2025-10-04 Alan Modra opcodes: PR 33384 invalid disassembler option message This is the binutils fix for PR 33384. Here we are assuming that no const char* comma-separated option strings are passed in to disassemble_info.disassembler_options. That is true for current usage in gdb and binutils. In fact, there is only one place that passes a string in read-only memory, gdb/tdep-i386.c:disassembly_flavor, and that one is a single option. include/ * dis-asm.h (struct disassemble_info): Comment. (disassembler_options_cmp, next_disassembler_option), (FOR_EACH_DISASSEMBLER_OPTION): Delete. (for_each_disassembler_option): Declare. opcodes/ * disassemble.c (disassembler_options_cmp): Delete. (for_each_disassembler_option): New function. * arc-dis.c (parse_option): Replace disassembler_options_cmp with strcmp. (parse_cpu_option): Likewise. (parse_disassembler_options): Replace FOR_EACH_DISASSEMBLER_OPTION with for_each_disassembler_option, and extract loop body to.. (arc_parse_option): ..this new function. * arm-dis.c (parse_arm_disassembler_options): Delete, extracting loop body to.. (arm_parse_option): ..this new function. (print_insn): Use for_each_disassembler_option. * csky-dis.c (parse_csky_dis_options): Delete, extracting loop body to.. (parse_csky_option): ..this new function. (print_insn_csky): Use for_each_disassembler_option. * nfp-dis.c (parse_disassembler_options): Replace FOR_EACH_DISASSEMBLER_OPTION with for_each_disassembler_option, and extract loop body to.. (nfp_parse_option): ..this new function. Use opcodes_error_handler here rather than info->fprintf_func to print error. * ppc-dis.c (ppc_parse_cpu): Replace disassembler_options_cmp with strcmp. (struct ppc_parse_data): New. (powerpc_init_dialect): Adjust to use new struct. Replace FOR_EACH_DISASSEMBLER_OPTION with for_each_disassembler_option, and extract loop body to.. (ppc_parse_option): ..this new function. 2025-10-04 Alan Modra gdb: PR 33384 invalid disassembler option message This is the gdb part of fixing PR33384, where it is noted that an error in a disassembler option prints the rest of the comma separated option string rather than just the option in error. Removing FOR_EACH_DISASSEMBLER_OPTION seemed a good idea to me, as we then expose the strchr there which is useful in zero terminating the option, and in the case of arm-tdep.c, to replace strcspn. Also, if the option is zero terminated we don't need disassembler_options_cmp. Alternatively, you could do similarly to arm-tdep.c in disasm.c by changing the error message to use %.*s with a length found by strcspn. I rejected that smaller patch on the grounds that it makes for churn in message translation. I also prefer to see code using the standard string functions. Regression tested on x86_64-linux. Message behaviour tested on powerpc64le-linux and arm-linux-eabi. * arm-tdep.c (show_disassembly_style_sfunc): Don't use FOR_EACH_DISASSEMBLER_OPTION. Use strchr needed for loop control to size option len. * disasm.c (set_disassembler_options): Don't use FOR_EACH_DISASSEMBLER_OPTION. Overwrite comma in options with a zero. Replace disassembler_options_cmp with strcmp. 2025-10-04 Alan Modra mips gas: expression initialisation There is a make_expr_symbol in append_insn, which gets called from macro_build, which is all over the place. Many of these set up an expression without initialising all fields. Now the uninitialised fields should not be accessed in a properly functioning assembler, but I'm inclined to think anything copied ought to be initialised. * config/tc-mips.c (fix_loongson2f_jump, load_register), (add_got_offset, add_got_offset_hilo, macro_build_branch_likely), (macro, mips16_macro, s_cpload, s_cpsetup, s_cprestore) (s_cpreturn): Use structure initialiser to ensure all fields of expression are initialised. (load_address): Copy entire structure for the same reason. 2025-10-04 Alan Modra gas: more expression initialisation There are many more places that copy an uninitialised expressionS to a symbol via symbol_set_value_expression and make_expr_symbol. This patch focuses on general gas code that does that, and a few backends. Note that unlike the i386 case that oss-fuzz found, it is likely that the tc-alpha.c, tc-ppc.c and tc-tic54x.c changes are not fixing bugs, alpha and tic54x because they don't use X_md, ppc because it carefully handles X_md. Also, as an example an O_constant expression should only ever have its X_add_number field accessed, therefore the other fields can stay uninitialised. However, I think that copying uninitialised struct fields around is not good practice. If nothing else it can be confusing when examining symbols under gdb. I also replaced gen-sframe.c "#ifdef SFRAME_FRE_TYPE_SELECTION_OPT" with "if (SFRAME_FRE_TYPE_SELECTION_OPT)" so code in the false branches is compiled and thus less likely to bitrot. (As far as I can see, SFRAME_FRE_TYPE_SELECTION_OPT is always 1.) * cgen.c (expr_build_binary): Use structure initialiser to ensure all fields of expression are initialised. * config/obj-coff.c (obj_coff_val): Likewise. * config/tc-alpha.c (add_to_link_pool): Likewise. * config/tc-i386-intel.c (i386_intel_simplify): Likewise. * config/tc-mips.c (fix_loongson2f_jump, load_register), (load_address, add_got_offset, add_got_offset_hilo), (macro_build_branch_likely, macro, mips16_macro), (s_cpload, s_cpsetup, s_cprestore, s_cpreturn): Likewise. * config/tc-ppc.c (ppc_function): Likewise. * config/tc-tic54x.c (tic54x_field): Likewise. * dw2gencfi.c (output_cfi_insn): Likewise. * expr.c (expr_build_uconstant): Likewise. * read.c (s_mri_common): Likewise. * gen-sframe.c (create_fre_start_addr_exp), (create_func_info_exp, output_sframe_row_entry): Likewise. Don't conditionally compile via SFRAME_FRE_TYPE_SELECTION_OPT. * cgen.c (gas_cgen_parse_operand): Use md_expr_init_rest. * config/tc-microblaze.c (microblaze_s_weakext): Likewise. * ecoff.c (ecoff_directive_weakext, ecoff_stab): Likewise. * read.c (pseudo_set): Likewise. 2025-10-04 Alan Modra gas: initialisation of expressionS in operand() This patch removes clean_up_expression which runs just before operand() returns. clean_up_expression sets as yet uninitialised fields of expressionS. Well, it sets fields based on the value of X_op, trusting that others have been written, and has one notable exception: X_md is not initialised. Instead initialise expressionS fully inside operand(), which is called at the start of expr(), and introduce md_expr_init for the odd backends that want to mess with X_md. This is in response to an oss-fuzz report that read.c:pseudo_set calls expr() leaving exp.X_md uninitialised and can copy that to a symbol via symbol_set_value_expression. tc-i386-intel.c:565 is one place that later tests the uninitialised X_md. * config/tc-z80.h (md_expr_init, md_expr_init_rest): Define. * config/tc-microblaze.h: Likewise. * expr.c (clean_up_expression): Delete. (operand): Init expression early. (expr): Use md_expr_init_rest to init X_md when necessary. 2025-10-04 Alan Modra arc gas: don't use X_md as input to expression() tc-arc.c:tokenize_arguments tweaks expression() parsing, controlling whether arc_parse_name does anything by setting X_op and X_md in the expressionS argument passed to expression(). I want to change expr() to always fully initialise its result, and that means either a special expression initialiser for arc, or controlling arc_parse_name by some other means. Since arc_parse_name already tests "assembling_insn" and no other code does, change "assembling_insn" to directly control arc_parse_name. Doing it this way also stops a possible uninitialised access to right.X_op from expr() in arc_parse_name with current gas. The next patch in this series will also stop such uninitialised accesses. * config/tc-arc.c (assembling_insn): Update comment. (tokenize_arguments): Don't set X_op and X_md to control expression(), instead just use assembling_insn. (md_operand): Similarly. (arc_parse_name): Don't test X_op and X_md. (md_assemble): Don't set assembling_insn here. 2025-10-04 Tom de Vries [gdb] Fix assertion failure due to null frame PR gdb/33512 reports an assertion failure in test-case gdb.ada/access_to_packed_array.exp on i386-linux: ... (gdb) maint print symbols gdb/frame.c:3400: internal-error: reinflate: \ Assertion `m_cached_level >= -1' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: $exp: \ maint print symbols (GDB internal error) ... I haven't been able to reproduce the failure by running the test-case on x86_64-linux with target board unix/-m32, but I'm able to reproduce on x86_64-linux by using the exec attached to the PR: ... $ cat gdb.in file foo maint expand-symtabs maint print symbols $ gdb -q -batch -ex "set trace-commands on" -x gdb.in ... c_to: array (gdb/frame.c:3395: internal-error: reinflate: \ Assertion `m_cached_level >= -1' failed. ... The problem happens when trying to print variable c_to: ... <4>: Abbrev Number: 3 (DW_TAG_variable) DW_AT_name : c_to DW_AT_type : <0xf214> ... with type: ... <4>: Abbrev Number: 7 (DW_TAG_array_type) DW_AT_type : <0x9f39> <5>: Abbrev Number: 12 (DW_TAG_subrange_type) DW_AT_type : <0x9d6c> DW_AT_upper_bound : <0xf209> ... with upper bound: ... <4>: Abbrev Number: 89 (DW_TAG_variable) DW_AT_name : system__os_lib__copy_file__copy_to__TTc_toSP1___U DW_AT_type : <0x9d6c> DW_AT_artificial : 1 DW_AT_location : 1 byte block: 57 (DW_OP_reg7 (edi)) ... The backtrace at the point of the assertion failure is: ... (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff62a8e7f in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78 #2 0x00007ffff6257842 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff623f5cf in __GI_abort () at abort.c:79 #4 0x00000000010e7ac6 in dump_core () at gdb/utils.c:223 #5 0x00000000010e81b8 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) ( problem=0x2ceb0c0 , file=0x1ad5a90 "gdb/frame.c", line=3395, fmt=0x1ad5a08 "%s: Assertion `%s' failed.", ap=0x7fffffffc3c0) at gdb/utils.c:475 #6 0x00000000010e82ac in internal_verror ( file=0x1ad5a90 "gdb/frame.c", line=3395, fmt=0x1ad5a08 "%s: Assertion `%s' failed.", ap=0x7fffffffc3c0) at gdb/utils.c:501 #7 0x00000000019be79f in internal_error_loc ( file=0x1ad5a90 "gdb/frame.c", line=3395, fmt=0x1ad5a08 "%s: Assertion `%s' failed.") at gdbsupport/errors.cc:57 #8 0x00000000009b5c16 in frame_info_ptr::reinflate (this=0x7fffffffc878) at gdb/frame.c:3395 #9 0x00000000009b66f9 in frame_info_ptr::operator-> (this=0x7fffffffc878) at gdb/frame.h:290 #10 0x00000000009b4bd5 in get_frame_arch (this_frame=...) at gdb/frame.c:3075 #11 0x000000000081dd89 in dwarf_expr_context::fetch_result ( this=0x7fffffffc810, type=0x410d600, subobj_type=0x410d600, subobj_offset=0, as_lval=true) at gdb/dwarf2/expr.c:1006 #12 0x000000000081e2ef in dwarf_expr_context::evaluate (this=0x7fffffffc810, addr=0x7ffff459ce6b "W\aF\003", len=1, as_lval=true, per_cu=0x7fffd00053f0, frame=..., addr_info=0x7fffffffcc30, type=0x0, subobj_type=0x0, subobj_offset=0) at gdb/dwarf2/expr.c:1136 #13 0x0000000000877c14 in dwarf2_locexpr_baton_eval (dlbaton=0x3e99c18, frame=..., addr_stack=0x7fffffffcc30, valp=0x7fffffffcab0, push_values=..., is_reference=0x7fffffffc9b0) at gdb/dwarf2/loc.c:1604 #14 0x0000000000877f71 in dwarf2_evaluate_property (prop=0x3e99ce0, initial_frame=..., addr_stack=0x7fffffffcc30, value=0x7fffffffcab0, push_values=...) at gdb/dwarf2/loc.c:1668 #15 0x00000000009def76 in resolve_dynamic_range (dyn_range_type=0x3e99c50, addr_stack=0x7fffffffcc30, frame=..., rank=0, resolve_p=true) at gdb/gdbtypes.c:2198 #16 0x00000000009e0ded in resolve_dynamic_type_internal (type=0x3e99c50, addr_stack=0x7fffffffcc30, frame=..., top_level=true) at gdb/gdbtypes.c:2934 #17 0x00000000009e1079 in resolve_dynamic_type (type=0x3e99c50, valaddr=..., addr=0, in_frame=0x0) at gdb/gdbtypes.c:2989 #18 0x0000000000488ebc in ada_discrete_type_low_bound (type=0x3e99c50) at gdb/ada-lang.c:710 #19 0x00000000004eb734 in print_range (type=0x3e99c50, stream=0x30157b0, bounds_preferred_p=0) at gdb/ada-typeprint.c:156 #20 0x00000000004ebffe in print_array_type (type=0x3e99d10, stream=0x30157b0, show=1, level=9, flags=0x1bdcf20 ) at gdb/ada-typeprint.c:381 #21 0x00000000004eda3c in ada_print_type (type0=0x3e99d10, varstring=0x401f710 "c_to", stream=0x30157b0, show=1, level=9, flags=0x1bdcf20 ) at gdb/ada-typeprint.c:1015 #22 0x00000000004b4627 in ada_language::print_type ( this=0x2f949b0 , type=0x3e99d10, varstring=0x401f710 "c_to", stream=0x30157b0, show=1, level=9, flags=0x1bdcf20 ) at gdb/ada-lang.c:13681 #23 0x0000000000f74646 in print_symbol (gdbarch=0x3256270, symbol=0x3e99db0, depth=9, outfile=0x30157b0) at gdb/symmisc.c:545 #24 0x0000000000f737e6 in dump_symtab_1 (symtab=0x3ddd7e0, outfile=0x30157b0) at gdb/symmisc.c:313 #25 0x0000000000f73a69 in dump_symtab (symtab=0x3ddd7e0, outfile=0x30157b0) at gdb/symmisc.c:370 #26 0x0000000000f7420f in maintenance_print_symbols (args=0x0, from_tty=0) at gdb/symmisc.c:481 #27 0x00000000006c7fde in do_simple_func (args=0x0, from_tty=0, c=0x321e270) at gdb/cli/cli-decode.c:94 #28 0x00000000006ce65a in cmd_func (cmd=0x321e270, args=0x0, from_tty=0) at gdb/cli/cli-decode.c:2826 #29 0x0000000001005b78 in execute_command (p=0x3f48fe3 "", from_tty=0) at gdb/top.c:564 #30 0x0000000000966095 in command_handler ( command=0x3f48fd0 "maint print symbols") at gdb/event-top.c:613 #31 0x0000000001005141 in read_command_file (stream=0x3011a40) at gdb/top.c:333 #32 0x00000000006e2a64 in script_from_file (stream=0x3011a40, file=0x7fffffffe21f "gdb.in") at gdb/cli/cli-script.c:1705 #33 0x00000000006bb88c in source_script_from_stream (stream=0x3011a40, file=0x7fffffffe21f "gdb.in", file_to_open=0x7fffffffd760 "gdb.in") at gdb/cli/cli-cmds.c:706 #34 0x00000000006bba12 in source_script_with_search ( file=0x7fffffffe21f "gdb.in", from_tty=0, search_path=0) at gdb/cli/cli-cmds.c:751 #35 0x00000000006bbab2 in source_script (file=0x7fffffffe21f "gdb.in", from_tty=0) at gdb/cli/cli-cmds.c:760 #36 0x0000000000b835cb in catch_command_errors ( command=0x6bba7e , arg=0x7fffffffe21f "gdb.in", from_tty=0, do_bp_actions=false) at gdb/main.c:510 #37 0x0000000000b83803 in execute_cmdargs (cmdarg_vec=0x7fffffffd980, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd8c8) at gdb/main.c:606 #38 0x0000000000b84d79 in captured_main_1 (context=0x7fffffffdb90) at gdb/main.c:1349 #39 0x0000000000b84fe4 in captured_main (context=0x7fffffffdb90) at gdb/main.c:1372 #40 0x0000000000b85092 in gdb_main (args=0x7fffffffdb90) at gdb/main.c:1401 #41 0x000000000041a382 in main (argc=9, argv=0x7fffffffdcc8) at gdb/gdb.c:38 (gdb) ... The immediate problem is in dwarf_expr_context::fetch_result where we're calling get_frame_arch: ... switch (this->m_location) { case DWARF_VALUE_REGISTER: { gdbarch *f_arch = get_frame_arch (this->m_frame); ... with a null frame: ... (gdb) p this->m_frame.is_null () $1 = true (gdb) ... Fix this using ensure_have_frame in dwarf_expr_context::execute_stack_op for DW_OP_reg and DW_OP_regx, getting us instead: ... c_to: array (<>) of character; computed at runtime ... Tested on x86_64-linux. Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33512 2025-10-04 GDB Administrator Automatic date update in version.in 2025-10-03 Tom Tromey Clean up "return -1" in gdb.ada gdb tests historically used "return -1" for some kinds of failure, but there is no reason for the "-1". This patch removes this from the gdb.ada tests. 2025-10-03 Simon Marchi gdb: add array_view skip to gdb-gdb.gdb Change-Id: I1dd13b482224cbc851536dc8c2195889f77d1fcd 2025-10-03 Andrew Burgess gdb: detect when gdbserver has no default executable set This commit extends the use of the new qExecAndArgs packet (added in the previous commit) so that GDB now understands when it is connected to a remote server that doesn't have a default executable set. We don't do much with this information right now, other than produce more useful text for 'show remote exec-file'. Here I've connected to a gdbserver with no default executable set, this is with this patch in place: (gdb) target extended-remote | gdbserver --multi --once - (gdb) show remote exec-file The remote exec-file is unset, the remote has no default executable set. (gdb) file /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) run Starting program: /tmp/hello.x Running the default executable on the remote target failed; try "set remote exec-file"? (gdb) The important line is this one: The remote exec-file is unset, the remote has no default executable set. Without this patch we'd get: The remote exec-file is unset, the default remote executable will be used. The new message is clearer that there is no default executable set on the remote. In the future I plan to make use of this additional information, coupled with an understanding (via 'set sysroot') of when gdb and gdbserver share the same filesystem, to allow GDB to automatically use the current executable (e.g. loaded with the 'file' command) as the remote exec-file. But this is not part of this patch, or this patch series, just future planned work. Approved-By: Tom Tromey 2025-10-03 Andrew Burgess gdb/gdbserver: add new qExecAndArgs packet This commit adds a new remote protocol packet qExecAndArgs, and updates GDB to use it. When gdbserver is started a user can provide an executable and arguments, these are used (by the remote target) to start an initial inferior, this is the inferior to which GDB first connects. When GDB is connected in extended-remote mode, if the user does a 'run' without specifying a new 'remote exec-file' then the executable given on the gdbserver command line is reused to start the new inferior. Interestingly, the arguments given on the gdbserver command line are only used when starting the first inferior, subsequent inferiors will be passed an empty argument string by GDB. This might catch out a user, causing the rerun to behave differently than the first run. In this commit I will add a new qExecAndArgs packet, which I think will improve the experience in this area. The new qExecAndArgs packet is sent from GDB, and gdbserver replies with a packet that includes the executable filename and the arguments string that were used for starting the initial inferior. On the GDB side this information can be used to update GDB's state, the 'show remote exec-file' will reflect how gdbserver was started, and 'show args' will reflect the arguments used for starting the inferior. As a result of updating the args, if the user restarts the inferior, then this same argument string will be passed back to the remote target, and used for the new inferior. Thus, rerunning the inferior will behave just like the initial inferior, which I think is a good improvement. Finally, GDB will warn if the user has 'set remote exec-file' and then connects to a gdbserver that was started with some alternative filename, like this: (gdb) set remote exec-file /tmp/foo (gdb) target remote | gdbserver --once - /tmp/bar ... snip ... warning: updating 'remote exec-file' to '/tmp/bar' to match remote target ... snip ... I made the choice to have GDB update the remote exec-file setting to match the remote, as, after the 'target remote', we are connected to an inferior that is running /tmp/bar (in this case), so trying to hang onto the non-matching user supplied setting doesn't seem helpful. There is one case where I can see this choice being a problem, if a user does: (gdb) set remote exec-file /tmp/foo (gdb) target extended-remote | gdbserver --multi --once - /tmp/bar ... snip ... warning: updating 'remote exec-file' to '/tmp/bar' to match remote target ... snip ... (gdb) run In this case, prior to this patch, they would 'run' /tmp/foo, while after this patch, they will run /tmp/bar. I think it is unfortunate that I'm breaking this use case, but, I'm not _that_ sorry -- just start gdbserver with the correct executable, or even no executable, and the problem goes away. This last point is important, in extended-remote mode, it is possible to start gdbserver without specifying an executable, like this: $ gdbserver --multi --once :54321 In this case gdbserver doesn't start an initial inferior. When GDB connects the qExecAndArgs reply from gdbserver indicates that no information (executable or arguments) were set, and any existing information is retained, as in this session: (gdb) set sysroot (gdb) set remote exec-file /tmp/foo (gdb) set args a b c (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once - Remote debugging using | ./gdbserver/gdbserver --multi --once - Remote debugging using stdio (gdb) show remote exec-file The remote exec-file is "/tmp/foo". (gdb) show args Argument list to give program being debugged when it is started is "a b c". (gdb) This is the second time proposing this new packet. The first attempt can be found here: https://inbox.sourceware.org/gdb-patches/80d8b37d757033976b1a8ddd370c294c7aae8f8c.1692200989.git.aburgess@redhat.com The review feedback on this patch was that the inferior arguments should be passed back as a vector of individual strings. This makes sense, at the time that feedback was given, GDB would pass arguments to gdbserver as a vector of individual arguments, so it would seem sensible that gdbserver should adopt the same approach for passing arguments back to GDB. However, since then I have been working on how GDB passes the inferior arguments to gdbserver, fixing a lot of broken corner cases, which culminated in this patch: commit 8e28eef6cdcbd86ad61325ce1e6bd563b0fad1e1 Date: Thu Nov 23 18:46:54 2023 +0000 gdb/gdbserver: pass inferior arguments as a single string Though we do retain the vector of individual arguments behaviour for backward compatibility with old remote targets, the preferred approach now is for GDB to pass arguments to gdbserver as a single string. This removes the need for GDB/gdbserver to try and figure out what is the correct escaping to apply to the arguments, and fixes some argument passing corner cases. And so, now, I think it makes sense that gdbserver should also pass the arguments back to GDB as a single string. I've updated the documentation a little to (I hope) explain how gdbserver should escape things before passing them back to GDB (TLDR: no additional escaping should be added just for sending to GDB. The argument string should be sent to GDB as if it were being sent to the 'set args' GDB command). The main test for this new functionality is gdb.server/fetch-exec-and-args.exp, but I've also added a test gdb.replay/fetch-exec-and-args.exp, which allows me to test a corner case that isn't currently exercised by gdbserver, this is the case for sending pack inferior arguments, but no executable. The qExecAndArgs reply format is 'S;exec;args;' where 'exec' and 'args' are hex encoded strings. If 'args' is empty then this is perfectly valid, this just means there were no command line arguments. But what if 'exec' is empty? I needed to decide what to do in this case. The easiest choice is to treat empty 'exec' as the executable is not set. But currently, due to how gdbserver works, it is not possible to hit this case, so I used the gdbreplay testing framework to exercise this instead. There were a few supporting changes needed to write this test though. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-03 Andrew Burgess gdbserver: prevent assertion caused by passing empty program name While testing another patch I'm working on I discovered that passing an empty program name to gdbserver would trigger an assertion, like this: $ gdbserver --multi :54321 "" ../../gdb/gdbserver/../gdb/nat/fork-inferior.c:240: A problem internal to GDBserver has been detected. fork_inferior: Assertion `exec_file != nullptr' failed. User input, no matter how weird, shouldn't be triggering an assertion, so lets fix that. In extended mode, it is valid to start gdbserver without an executable name, like this: $ gdbserver --multi :54321 Here gdbserver doesn't start an inferior, and it is up to GDB to connect, and tell gdbserver what to run, and to then start it running. I did wonder if the empty string case should handled like the no executable name case, but then you get into the situation where the user can specify command line arguments without an inferior, like: $ gdbserver --multi :54321 "" a b c And while there's nothing really wrong with this, and I'm sure someone could come up with a use case for it. I'd like to propose that for now at least, we take the simple approach of not allowing an empty executable name, instead we should give an error, like this: $ gdbserver --multi :54321 "" No program to debug Exiting We can always relax this requirement in the future, and allow the empty executable with or without inferior arguments, if we decide there's a compelling reason for it. It would be simple enough to add this in the future, but once we add support for it, it's much harder to remove the feature in the future, so lets start simple. The non-extended remote case works much the same. It too triggers the assertion currently, and after this patch exits with the same error. Of course, the non-extended remote case never supported not having an inferior, if you did: $ gdbserver :54321 You'd be shown the usage text and gdbserver would exit. Approved-By: Tom Tromey 2025-10-03 GDB Administrator Automatic date update in version.in 2025-10-03 timurgol007 Enable process record testsuite for RISC-V When I ran GDB testsuite, I noticed that process record tests are not currently supported on RISC-V. This patch fixes it. Approved-By: Guinevere Larsen 2025-10-02 Indu Bhagat libsframe: testsuite: make test names unique Fix PR libsframe/33437 - libsframe test names are not unique The TEST () macro definition originally in plt-findfre-2.c, was being used to differentiate between multiple runs of the testcases. Adapt that definition a bit to allow for a variable number of arguments following the test condition: A test name format string may be used by macro users, such that the name of the tests are unique. Move the new variadic TEST macro definition in the testsuite's common header sframe-test.h, and use it throughout the testsuite. Reviewed-by: Jens Remus libsframe/testsuite/ PR libsframe/33437 * libsframe.decode/be-flipping.c: Use new TEST macro with suffix. * libsframe.decode/frecnt-1.c: Likewise. * libsframe.decode/frecnt-2.c: Likewise. * libsframe.encode/encode-1.c: Likewise. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.find/plt-findfre-1.c: Likewise. * libsframe.find/plt-findfre-2.c: Likewise. * sframe-test.h: Move the TEST macro definition to this testsuite header. 2025-10-02 H.J. Lu x86: Keep _GLOBAL_OFFSET_TABLE_ for .eh_frame Since x86 .eh_frame section may reference _GLOBAL_OFFSET_TABLE_, keep _GLOBAL_OFFSET_TABLE_ if there is dynamic section and the output .eh_frame section is non-empty. PR ld/33499 * elfxx-x86.c (_bfd_x86_elf_late_size_sections): Keep _GLOBAL_OFFSET_TABLE_ if there is dynamic section and the output .eh_frame section is non-empty. 2025-10-02 H.J. Lu x86: Disallow TLS relocation in non executable section Since TLS relocations are applied to executable machine instructions, disallow TLS relocation in non-SHT_PROGBITS, non-SHF_EXECINSTR section. PR ld/33451 PR ld/33502 * elf32-i386.c (elf_i386_tls_transition): Disallow TLS relocation in non-SHT_PROGBITS, non-SHF_EXECINSTR section. (elf_i386_scan_relocs): Likewise. * elf64-x86-64.c (elf_x86_64_tls_transition): Likewise. (elf_x86_64_scan_relocs): Likewise. * elfxx-x86.c (_bfd_x86_elf_link_report_tls_invalid_section_error): New. * elfxx-x86.h (_bfd_x86_elf_link_report_tls_invalid_section_error): Likewise. 2025-10-02 H.J. Lu x86: Check invalid symbol name Since bfd_elf_sym_name returns bfd_symbol_error_name for invalid symbol, name, return error if bfd_elf_sym_name returns bfd_symbol_error_name. PR ld/33501 * elf32-i386.c (elf_i386_scan_relocs): Return error for invalid symbol name. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. 2025-10-02 H.J. Lu elf: Use uint64_t for common symbol alignment warning Use uint64_t for common symbol alignment warning to avoid elflink.c:5548:12: runtime error: shift exponent 37 is too large for 32-bit type 'int' with invalid input in PR ld/33500. Now ld issues: ld: warning: alignment 137438953472 of common symbol `__afl_global_area_ptr' in pr33500.o is greater than the alignment (8) of its section *COM* instead of ld: warning: alignment 32 of common symbol `__afl_global_area_ptr' in pr33500.o is greater than the alignment (8) of its section *COM* PR ld/33511 * elflink.c (elf_link_add_object_symbols): Use uint64_t for common symbol alignment warning. 2025-10-02 Simon Marchi gdb/doc: trim trailing whitespaces My editor "accidentally" removed all trailing whitespaces from gdb.texinfo while doing a change. That was mostly just an annoyance but to avoid it happening again, I suggest removing them for good. I look at the difference in the output of "make html". The new output has some trailing whitespaces removed, but none of them seems to cause a semantic difference. Not sure about other formats like info or pdf though. Change-Id: I3f349b28c581af69703365fea07e7b93614c987c Approved-By: Eli Zaretskii 2025-10-02 Simon Marchi gdb: add more skips to gdb-gdb.gdb These are rather uninteresting constructors to step into. Change-Id: Ic22eca60eb03b1f81e0d9f304417659a2d982356 2025-10-02 Andrew Burgess gdb: add core file name to 'info inferiors' output This commit builds on the previous commit. In the future I am proposing to move the core file BFD from the program_space into the core_target. In the last commit I updated 'maint info program-spaces' to remove the core file name from the output. In this commit I'm adding the core file name to the 'info inferiors' output. My proposal is to add the core file as auxiliary information beneath an inferior's line in the 'info inferiors' output. We already do this vfork parent/child information. The alternative would be to add the core file as an additional column in the 'info inferiors' output, indeed, I did initially propose this: https://inbox.sourceware.org/gdb-patches/e3e040272a0f8f5fd826298331da4c19d01f3a5e.1757615333.git.aburgess@redhat.com But the problem with this is that the 'info inferiors' output can easily become very long, and the line wrapping gets very messy, making the output much harder to parse. The feedback on this initial approach wasn't super strong, so I'm trying the auxiliary information approach to see if this is liked more. The new output looks like this: (gdb) info inferiors Num Description Connection Executable * 1 process 54313 1 (core) /tmp/executable core file /tmp/core.54313 The only other option I can think of, if this approach is not liked, would be to add an entirely new command, 'info core-files', with output like: Num Core File * 1 /tmp/corefile.core The 'Num' column here would just be the inferior number again. In effect this new command is just splitting the 'info inferiors' into two commands. I extended gdb.base/corefile.exp to check the current output style, and updated the gdb.multi/multi-target-info-inferiors.exp test to take the new output into account. Approved-By: Tom Tromey 2025-10-02 Andrew Burgess gdb: remove core file name from 'maint info program-spaces' I'm currently working towards a goal of moving the core file BFD out of program_space and into core_target. I believe this is a good change to make as the core_target already holds a lot of state that is parsed from the core file BFD, so storing the parsed, structured, information in a different location to the original core file BFD doesn't make sense to me. In preparation for this change, the 'maint info program-spaces' command needs updating. Currently this command lists the name of the core file BFD that is loaded into each program space. Once the core file moves into core_target then the core file really becomes a property of the inferior. We could try to retain the existing output by looking up which inferior is active in a given program space, and find the core file that way, however, I don't like this plan because GDB does support shared program spaces, in theory, a target could exist where every inferior shares a single program space. Even on more common POSIX targets, after a vfork the parent and child share a program space. Now the vfork case clearly doesn't impact the core file case, and I don't know if GDB _actually_ supports any shared program space targets any more.... but still, I don't think we should try to retain the existing behaviour. So, this commit removes the core file name from the 'maint info program-spaces' output. The next commit will add the core file name back in a new home. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-10-02 Tom Tromey Introduce gdbsupport/cxx-thread.h and use it This introduces a new file, gdbsupport/cxx-thread.h, which provides stubs for the C++ threading functionality on systems that don't support it. On fully-working ports, this header just supplies a number of aliases in the gdb namespace. So, for instance, gdb::mutex is just an alias for std::mutex. For non-working ports, compatibility stubs are provided for the subset of threading functionality that's used in gdb. These generally do nothing and assume single-threaded operation. The idea behind this is to reduce the number of checks of CXX_STD_THREAD, making the code cleaner. Not all spots using CXX_STD_THREAD could readily be converted. In particular: * Unit tests * --config output * Code manipulating threads themselves * The extension interrupting handling code These all seem fine to me. Note there's also a check in py-dap.c. This one is perhaps slightly subtle: DAP starts threads on the Python side, but it relies on gdb itself being thread-savvy, for instance in gdb.post_event. Approved-By: Simon Marchi 2025-10-02 Tom Tromey Don't rely on deduction in run-on-main-thread.c This changes one spot in run-on-main-thread.c to use an explicit template argument, rather than relying on deduction. The deduction would otherwise fail with the next patch. 2025-10-02 Tom Tromey Remove two unused includes dwarf2/read.c no longer uses gdb::task_group, so the include isn't needed. Simon pointed out that the thread-pool.h include isn't needed either. Approved-By: Simon Marchi 2025-10-02 Andrew Burgess gdb: int to bool conversion in find_memory_regions API Perform int to bool conversion for find_memory_region_ftype function type. This function type is used in the find_memory_regions API, both target_find_memory_regions and target_find_memory_regions. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2025-10-02 H.J. Lu binutils/GCC: Quote ${COMPILER_FOR_TARGET} Replace if test x${COMPILER_FOR_TARGET} = x"\$(CC)"; then with if test x"${COMPILER_FOR_TARGET}" = x"\$(CC)"; then since COMPILER_FOR_TARGET may contain spaces when configuring GCC. * configure: Regenerated. config/ * clang-plugin.m4 (CLANG_PLUGIN_FILE_FOR_TARGET): Quote ${COMPILER_FOR_TARGET}. * gcc-plugin.m4 (GCC_PLUGIN_OPTION_FOR_TARGET): Likewise. 2025-10-02 GDB Administrator Automatic date update in version.in 2025-10-02 H.J. Lu Sync toplevel files from gcc commit bab1b2488e2a01b311d584bbecbc6834194e30ed Author: Nicolas Boulenguez Date: Sun Jun 22 19:23:11 2025 +0200 Ada: Introduce GNATMAKE_FOR_BUILD Makefile variable This gets rid of the hardcoded 'gnatmake' command used during the build. commit 79091220da796a4b60561a7bf2e9e8f5e5276bc4 Author: Kugan Vivekanandarajah Date: Tue Jun 10 09:19:37 2025 +1000 [AutoFDO] Fix profile bootstrap for x86_64 This patch fixes profile bootstrap for x86_64 by special caseing cpu_type for x86_64 as it shares AUTO_PROFILE from i386. commit fcb60292984fa7181ec91d7f81fd18549d1aaf39 Author: Kugan Vivekanandarajah Date: Thu May 29 08:47:19 2025 +1000 [AUTOFDO] Fix autogen remake issue Fix autogen issue introduced by commit commit 86dc974cf30f926a014438a5fccdc9d41e26282b commit 86dc974cf30f926a014438a5fccdc9d41e26282b Author: Kugan Vivekanandarajah Date: Mon May 26 11:41:59 2025 +1000 [AUTOFDO][AARCH64] Add support for profilebootstrap Add support for autoprofiledbootstrap in aarch64. This is similar to what is done for i386. Added gcc/config/aarch64/gcc-auto-profile for aarch64 profile creation. How to run: configure --with-build-config=bootstrap-lto make autoprofiledbootstrap commit dff727b2c28c52e90e0bd61957d15f907494b245 Author: Stephanos Ioannidis Date: Wed May 21 17:28:36 2025 -0600 [PATCH] configure: Always add pre-installed header directories to search path configure script was adding the target directory flags, including the '-B' flags for the executable prefix and the '-isystem' flags for the pre-installed header directories, to the target flags only for non-Canadian builds under the premise that the host binaries under the executable prefix will not be able to execute on the build system for Canadian builds. While that is true for the '-B' flags specifying the executable prefix, the '-isystem' flags specifying the pre-installed header directories are not affected by this and do not need special handling. This patch updates the configure script to always add the 'include' and 'sys-include' pre-installed header directories to the target search path, in order to ensure that the availability of the pre-installed header directories in the search path is consistent across non-Canadian and Canadian builds. When '--with-headers' flag is specified, this effectively ensures that the libc headers, that are copied from the specified header directory to the sys-include directory, are used by libstdc++. commit 6390fc86995fbd5239497cb9e1797a3af51d3936 Author: Rainer Orth Date: Tue Apr 22 13:47:17 2025 +0200 cobol: Restrict COBOL to supported Linux arches [PR119217] The COBOL frontend is currently built on all x86_64 and aarch64 hosts although the code contains some Linux/glibc specifics that break the build e.g. on Solaris/amd64. Tested on Linux/x86_64 and Solaris/amd64. commit 17ed44c96f6e5c0cc02d8cb29ff5943dd30ab3c1 Author: Iain Sandoe Date: Mon Mar 31 07:02:54 2025 +0100 config, toplevel, Darwin: Pass -B instead of -L to C++ commands. Darwin from 10.11 needs embedded rpaths to find the correct libraries at runtime. Recent increases in hardening have made it such that the dynamic loader will no longer fall back to using an installed libstdc++ when the (new) linked one is not found. This means we fail configure tests (that should pass) for runtimes that use C++. We can resolve this by passing '-B' to the C++ command lines instead of '-L' (-B implies -L on Darwin, but also causes a corresponding embedded rpath). commit dcb7009efc5358207d1b0612732a0608915a3ef7 Author: Richard Biener Date: Fri Mar 28 13:48:36 2025 +0100 bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir This adds gcc/cobol/parse.o to compare_exclusions and makes sure to ignore errors when copying generated files, like it's done when copying gengtype-lex.cc. commit 0fb10aca02852b2e8d78a78c07aa2f62aec6a07e Author: Iain Sandoe Date: Tue Mar 25 16:20:58 2025 +0000 toplevel, libcobol: Add dependency on libquadmath build [PR119244]. For the configuration of libgcobol to be correct for targets that need to use libquadmath for 128b FP support, we must be able to find the quadmath library (or not, for targets that have the support in libc). commit 70bc553e1b565d2e162894ea29a223b44e9133e3 Author: Iain Sandoe Date: Sun Mar 23 11:45:17 2025 +0000 toplevel, Makefile: Add missing CXX_FOR_TARGET export [PR88319]. Actually, the issue is not local to the libitm case, it currently affects any 'cxx=true' top-level configured target library. The issue is a missing export of CXX_FOR_TARGET. commit c650b557cb01f97bebb894aa68e5e74c2147c395 Author: Thomas Schwinge Date: Mon Jul 11 22:36:39 2022 +0200 GCN, nvptx: Don't default-disable libstdc++ build In addition to making libstdc++ itself available, this, via enabling 'build-gcc/*/libstdc++-v3/scripts/testsuite_flags', in particular also makes the standard C++ headers available to 'make check-gcc-c++'. With that, there are a lot of FAIL/UNRESOLVED -> PASS progressions, where we previously ran into, for example: FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for errors, line 6) FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for excess errors) Excess errors: [...]/gcc/testsuite/g++.dg/coroutines/coro.h:132:10: fatal error: cstdlib: No such file or directory Similarly, there are a lot of FAIL/UNRESOLVED -> UNSUPPORTED "progressions" due to 'sorry, unimplemented: exception handling not supported'. The 'make check-target-libstdc++-v3' results don't look too bad, either. This also reverts Subversion r221362 (Git commit d94fae044da071381b73a2ee8afa874b14fa3820) "No libstdc++ for nvptx", and commit 2f4f3c0e9345805160ecacd6de527b519a8c9206 "No libstdc++ for GCN". With libstdc++ now available, libgrust gets enabled, which we in turn again have to disable, for 'sorry, unimplemented: exception handling not supported' reasons. commit 09c2a0ab94e1e731433eb2687ad16a9c79617e14 Author: Jakub Jelinek Date: Tue Mar 11 14:34:01 2025 +0100 cobol: Fix up libgcobol configure [PR119216] Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change. Looking in more detail, the way e.g. libsanitizer/configure.tgt works is that it is sourced twice, once at toplevel and there it just sets UNSUPPORTED=1 for fully unsupported triplets, and then inside of libsanitizer/configure where it decides to include or not include the various sublibraries depending on the *_SUPPORTED flags. So, the following patch attempts to do the same for libgcobol as well. The BIULD_LIBGCOBOL automake conditional was unused, this patch guards it on LIBGCOBOL_SUPPORTED as well and guards with it toolexeclib_LTLIBRARIES = libgcobol.la Also, AM_CFLAGS has been changed to AM_CXXFLAGS as there are just C++ sources in the library. commit 6a3f9f30d93c376a8a5e98be888da14923b85e63 Author: Iain Sandoe Date: Tue Mar 11 09:56:18 2025 +0000 configure, Darwin: Require explicit selection of COBOL. By defult, Darwin does not have sufficient tools to build COBOL so we do not want to include it in --enable-languages=all since this will break regular testing of all supported languages. However, we do want to be able to build it on demand (where the build system has sufficiently new tools) and so do not want to disable it permanently. commit 45c281deb7a2e24a21f2f68a2a3652e30f27f953 Author: James K. Lowden Date: Mon Mar 10 16:04:49 2025 +0100 COBOL: config and build machinery commit ab35fc0d897011c6de075e000d1e0388e6359d4e Author: Thomas Schwinge Date: Wed Feb 19 09:30:45 2025 +0100 GCN, nvptx: Support '--enable-languages=all' ..., where "support" means that the build doesn't fail, but it doesn't mean that all target libraries get built and we get pretty test results for the additional languages. commit bc3597635a708cd91d742c91c6050829cfb4062a Author: David Malcolm Date: Fri Nov 29 18:13:22 2024 -0500 Rename "libdiagnostics" to "libgdiagnostics" "libdiagnostics" clashes with an existing soname in Debian, as per: https://gcc.gnu.org/pipermail/gcc/2024-November/245175.html Rename it to "libgdiagnostics" for uniqueness. I am being deliberately vague about what the "g" stands for: it could be "gnu", "gcc", or "gpl-licensed" as the reader desires. commit fc59a3995cb46c190c0efb0431ad204e399975c4 Author: Pierre-Emmanuel Patry Date: Wed May 3 18:43:10 2023 +0200 gccrs: Fix bootstrap build This commit fixes bootstrapping for future additions to libgrust/ commit 7a6906c8d80e437a97c780370a8fec4e00561c7b Author: Pierre-Emmanuel Patry Date: Mon Jun 12 10:51:49 2023 +0200 gccrs: Fix missing build dependency Fix the missing dependency between the gcc and libgrust. * Makefile.def: Synced from gcc. * Makefile.tpl: Likewise. * configure.ac: Likewise. * Makefile.in: Regenerated. * configure: Likewise. 2025-10-01 Richard Earnshaw toplevel: unify the GCC and GDB/binutils .editorconfig files Both GCC and GDB/binutils now have root editorconfig files. It would make sense to unify them as this sets the general tone for these projects. ChangeLog: * .editorconfig: Unify the GCC and GDB/binutils root config. 2025-10-01 Alan Modra Remove tic4x_scan always false condition The numeric check was always false, and correcting it to match the comment causes lots of testsuite failures. "tic4x" is a valid string. * cpu-tic4x.c (tic4x_scan): Remove always false condition. Fix comment. 2025-10-01 Timur Golubovich Rewrote riscv-canonicalize-gen.py using xml file Since catching-syscalls was added, there had been added files containing syscalls in xml format. As for now riscv-canonicalize-syscall-gen.py uses glibc for generating, it may be not so comfortable. I changed this script for reusing newly generated riscv-linux.xml file. Also, I renamed riscv64_canonicalize_syscall to riscv_linux_canonicalize_syscall as only 64 system is supported in linux. This will simplify the possible further generalization of this script to other architectures. Approved-By: Simon Marchi 2025-10-01 H.J. Lu elf: Don't read beyond .eh_frame section end PR ld/33500 * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Don't read beyond the .eh_frame section end. 2025-10-01 H.J. Lu binutils: Use AC_TRY_COMPILE to check target clang/gcc Use AC_TRY_COMPILE to check for the working target clang and gcc when configuring for cross tools. PR binutils/33503 * configure: Regenerated. config/ PR binutils/33503 * clang-plugin.m4 (CLANG_PLUGIN_FILE_FOR_TARGET): Use AC_TRY_COMPILE to check the target clang and replace clang_cv_is_clang with clang_target_cv_working. * gcc-plugin.m4 (GCC_PLUGIN_OPTION_FOR_TARGET): Use AC_TRY_COMPILE to check the target gcc. 2025-10-01 GDB Administrator Automatic date update in version.in 2025-09-30 Simon Marchi gdb/dwarf: use dynamic partitioning for DWARF CU indexing The DWARF indexer splits the work statically based on the unit sizes, attempting to give each worker thread about the same amount of bytes to process. This works relatively well with standard compilation. But when compiling with DWO files (-gsplit-dwarf), it's not as good. I see this when loading a relatively big program (telegram-desktop, which includes a lot of static dependencies) compiled with -gsplit-dwarf: Time for "DWARF indexing worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, -nan % CPU Time for "DWARF indexing worker": wall 0.001, user 0.000, sys 0.000, user+sys 0.000, 0.0 % CPU Time for "DWARF indexing worker": wall 0.001, user 0.001, sys 0.000, user+sys 0.001, 100.0 % CPU Time for "DWARF indexing worker": wall 0.748, user 0.284, sys 0.297, user+sys 0.581, 77.7 % CPU Time for "DWARF indexing worker": wall 0.818, user 0.408, sys 0.262, user+sys 0.670, 81.9 % CPU Time for "DWARF indexing worker": wall 1.196, user 0.580, sys 0.402, user+sys 0.982, 82.1 % CPU Time for "DWARF indexing worker": wall 1.250, user 0.511, sys 0.500, user+sys 1.011, 80.9 % CPU Time for "DWARF indexing worker": wall 7.730, user 5.891, sys 1.729, user+sys 7.620, 98.6 % CPU Note how the wall times vary from 0 to 7.7 seconds. This is undesirable, because the time to do that indexing step takes as long as the slowest worker thread takes. The imbalance in this step also causes imbalance in the following "finalize" step: Time for "DWARF finalize worker": wall 0.007, user 0.004, sys 0.002, user+sys 0.006, 85.7 % CPU Time for "DWARF finalize worker": wall 0.012, user 0.005, sys 0.005, user+sys 0.010, 83.3 % CPU Time for "DWARF finalize worker": wall 0.015, user 0.010, sys 0.004, user+sys 0.014, 93.3 % CPU Time for "DWARF finalize worker": wall 0.389, user 0.359, sys 0.029, user+sys 0.388, 99.7 % CPU Time for "DWARF finalize worker": wall 0.680, user 0.644, sys 0.035, user+sys 0.679, 99.9 % CPU Time for "DWARF finalize worker": wall 0.929, user 0.907, sys 0.020, user+sys 0.927, 99.8 % CPU Time for "DWARF finalize worker": wall 1.093, user 1.055, sys 0.037, user+sys 1.092, 99.9 % CPU Time for "DWARF finalize worker": wall 2.016, user 1.934, sys 0.082, user+sys 2.016, 100.0 % CPU Time for "DWARF finalize worker": wall 25.882, user 25.471, sys 0.404, user+sys 25.875, 100.0 % CPU With DWO files, the split of the workload by size doesn't work, because it is done using the size of the skeleton units in the main file, which is not representative of how much DWARF is contained in each DWO file. I haven't tried it, but a similar problem could occur with cross-unit imports, which can happen with dwz or LTO. You could have a small unit that imports a lot from other units, in which case the size of the units is not representative of the work to accomplish. To try to improve this situation, change the DWARF indexer to use dynamic partitioning, using gdb::parallel_for_each_async. With this, each worker thread pops one unit at a time from a shared work queue to process it, until the queue is empty. That should result in a more balance workload split. I chose 1 as the minimum batch size here, because I judged that indexing one CU was a big enough piece of work compared to the synchronization overhead of the queue. That can always be tweaked later if someone wants to do more tests. As a result, the timings are much more balanced: Time for "DWARF indexing worker": wall 2.325, user 1.033, sys 0.573, user+sys 1.606, 69.1 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.028, sys 0.568, user+sys 1.596, 68.6 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.068, sys 0.513, user+sys 1.581, 68.0 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.005, sys 0.579, user+sys 1.584, 68.1 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.070, sys 0.516, user+sys 1.586, 68.2 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.063, sys 0.584, user+sys 1.647, 70.8 % CPU Time for "DWARF indexing worker": wall 2.326, user 1.049, sys 0.550, user+sys 1.599, 68.7 % CPU Time for "DWARF indexing worker": wall 2.328, user 1.058, sys 0.541, user+sys 1.599, 68.7 % CPU ... Time for "DWARF finalize worker": wall 2.833, user 2.791, sys 0.040, user+sys 2.831, 99.9 % CPU Time for "DWARF finalize worker": wall 2.939, user 2.896, sys 0.043, user+sys 2.939, 100.0 % CPU Time for "DWARF finalize worker": wall 3.016, user 2.969, sys 0.046, user+sys 3.015, 100.0 % CPU Time for "DWARF finalize worker": wall 3.076, user 2.957, sys 0.118, user+sys 3.075, 100.0 % CPU Time for "DWARF finalize worker": wall 3.159, user 3.054, sys 0.104, user+sys 3.158, 100.0 % CPU Time for "DWARF finalize worker": wall 3.198, user 3.082, sys 0.114, user+sys 3.196, 99.9 % CPU Time for "DWARF finalize worker": wall 3.197, user 3.076, sys 0.121, user+sys 3.197, 100.0 % CPU Time for "DWARF finalize worker": wall 3.268, user 3.136, sys 0.131, user+sys 3.267, 100.0 % CPU Time for "DWARF finalize worker": wall 1.907, user 1.810, sys 0.096, user+sys 1.906, 99.9 % CPU In absolute terms, the total time for GDB to load the file and exit goes down from about 42 seconds to 17 seconds. Some implementation notes: - The state previously kept in as local variables in cooked_index_worker_debug_info::process_units becomes fields of the new parallel worker object. - The work previously done for each unit in cooked_index_worker_debug_info::process_units becomes the operator() of the new parallel worker object. - The work previously done at the end of cooked_index_worker_debug_info::process_units (including calling bfd_thread_cleanup) becomes the destructor of the new parallel worker object. - The "done" callback of gdb::task_group becomes the "done" callback of gdb::parallel_for_each_async. - I placed the parallel_indexing_worker struct inside cooked_index_worker_debug_info, so that it has access to parallel_indexing_worker's private fields (e.g. m_results, to push the results). It will also be possible to re-use it for skeletonless type units in a later patch. Change-Id: I5dc5cf8793abe9ebe2659e78da38ffc94289e5f2 Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: add async parallel_for_each version I would like to use gdb::parallel_for_each to implement the parallelism of the DWARF unit indexing. However, the existing implementation of gdb::parallel_for_each is blocking, which doesn't work with the model used by the DWARF indexer, which is asynchronous and callback-based. Add an asynchronouys version of gdb::parallel_for_each that will be suitable for this task. This new version accepts a callback that is invoked when the parallel for each is complete. This function uses the same strategy as gdb::task_group to invoke the "done" callback: worker threads have a shared_ptr reference to some object. The last worker thread to drop its reference causes the object to be deleted, which invokes the callback. Unlike for the sync version of gdb::parallel_for_each, it's not possible to keep any state in the calling thread's stack, because that disappears immediately after starting the workers. So all the state is kept in that same shared object. There is a limitation that the sync version doesn't have, regarding the arguments you can pass to the worker objects: it's not possibly to rely on references. There are more details in a comment in the code. It would be possible to implement the sync version of gdb::parallel_for_each on top of the async version, but I decided not to do it to avoid the unnecessary dynamic allocation of the shared object, and to avoid adding the limitations on passing references I mentioned just above. But if we judge that it would be an acceptable cost to avoid the duplication, we could do it. Add a self test for the new function. Change-Id: I6173defb1e09856d137c1aa05ad51cbf521ea0b0 Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: factor out work queue from parallel-for.h In preparation for a following patch that will re-use the shared work queue algorithm, move it to a separate class. Change-Id: Id05cf8898a5d162048fa8fa056fbf7e0441bfb78 Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: use iterator range in parallel_for_each interface I think it would be convenient for parallel_for_each to pass an iterator_range to the worker function, instead of separate begin and end parameters. This allows using a ranged for loop directly. Change-Id: I8f9681da65b0eb00b738379dfd2f4dc6fb1ee612 Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: add iterator_range::empty Add iterator_range::empty, indicating if the range is empty. This is used in the following patch. Change-Id: I1e6c873e635c2bb0ce5aaea2a176470970f6d7ac Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: use dynamic partitioning in gdb::parallel_for_each gdb::parallel_for_each uses static partitioning of the workload, meaning that each worker thread receives a similar number of work items. Change it to use dynamic partitioning, where worker threads pull work items from a shared work queue when they need to. Note that gdb::parallel_for_each is currently only used for processing minimal symbols in GDB. I am looking at improving the startup performance of GDB, where the minimal symbol process is one step. With static partitioning, there is a risk of workload imbalance if some threads receive "easier" work than others. Some threads sit still while others finish working on their share of the work. This is not desirable, because the gdb::parallel_for_each takes as long as the slowest thread takes. When loading a file with a lot of minimal symbols (~600k) in GDB, with "maint set per-command time on", I observe some imbalance: Time for "minsyms install worker": wall 0.732, user 0.550, sys 0.041, user+sys 0.591, 80.7 % CPU Time for "minsyms install worker": wall 0.881, user 0.722, sys 0.071, user+sys 0.793, 90.0 % CPU Time for "minsyms install worker": wall 2.107, user 1.804, sys 0.147, user+sys 1.951, 92.6 % CPU Time for "minsyms install worker": wall 2.351, user 2.003, sys 0.151, user+sys 2.154, 91.6 % CPU Time for "minsyms install worker": wall 2.611, user 2.322, sys 0.235, user+sys 2.557, 97.9 % CPU Time for "minsyms install worker": wall 3.074, user 2.729, sys 0.203, user+sys 2.932, 95.4 % CPU Time for "minsyms install worker": wall 3.486, user 3.074, sys 0.260, user+sys 3.334, 95.6 % CPU Time for "minsyms install worker": wall 3.927, user 3.475, sys 0.336, user+sys 3.811, 97.0 % CPU ^ ----´ The fastest thread took 0.732 seconds to complete its work (and then sat still), while the slowest took 3.927 seconds. This means the parallel_for_each took a bit less than 4 seconds. Even if the number of minimal symbols assigned to each worker is the same, I suppose that some symbols (e.g. those that need demangling) take longer to process, which could explain the imbalance. With this patch, things are much more balanced: Time for "minsym install worker": wall 2.807, user 2.222, sys 0.144, user+sys 2.366, 84.3 % CPU Time for "minsym install worker": wall 2.808, user 2.073, sys 0.131, user+sys 2.204, 78.5 % CPU Time for "minsym install worker": wall 2.804, user 1.994, sys 0.151, user+sys 2.145, 76.5 % CPU Time for "minsym install worker": wall 2.808, user 1.977, sys 0.135, user+sys 2.112, 75.2 % CPU Time for "minsym install worker": wall 2.808, user 2.061, sys 0.142, user+sys 2.203, 78.5 % CPU Time for "minsym install worker": wall 2.809, user 2.012, sys 0.146, user+sys 2.158, 76.8 % CPU Time for "minsym install worker": wall 2.809, user 2.178, sys 0.137, user+sys 2.315, 82.4 % CPU Time for "minsym install worker": wall 2.820, user 2.141, sys 0.170, user+sys 2.311, 82.0 % CPU ^ ----´ In this version, the parallel_for_each took about 2.8 seconds, representing a reduction of ~1.2 seconds for this step. Not life-changing, but it's still good I think. Note that this patch helps when loading big programs. My go-to test program for this is telegram-desktop that I built from source. For small programs (including loading gdb itself), it makes no perceptible difference. Now the technical bits: - One impact that this change has on the minimal symbol processing specifically is that not all calls to compute_and_set_names (a critical region guarded by a mutex) are done at the end of each worker thread's task anymore. Before this patch, each thread would compute the names and hash values for all the minimal symbols it has been assigned, and then would call compute_and_set_names for all of them, while holding the mutex (thus preventing other threads from doing this same step). With the shared work queue approach, each thread grabs a batch of of minimal symbols, computes the names and hash values for them, and then calls compute_and_set_names (with the mutex held) for this batch only. It then repeats that until the work queue is empty. There are therefore more small and spread out compute_and_set_names critical sections, instead of just one per worker thread at the end. Given that before this patch the work was not well balanced among worker threads, I guess that threads would enter that critical region at roughly different times, causing little contention. In the "with this patch" results, the CPU utilization numbers are not as good, suggesting that there is some contention. But I don't know if it's contention due to the compute_and_set_names critical section or the shared work queue critical section. That can be investigated later. In any case, what ultimately counts is the wall time, which improves. - One choice I had to make was to decide how many work items (in this case minimal symbols) each worker should pop when getting work from the shared queue. The general wisdom is that: - popping too few items, and the synchronization overhead becomes significant, and the total processing time increases - popping too many items, and we get some imbalance back, and the total processing time increases again I experimented using a dynamic batch size proportional to the number of remaining work items. It worked well in some cases but not always. So I decided to keep it simple, with a fixed batch size. That can always be tweaked later. - I want to still be able to use scoped_time_it to measure the time that each worker thread spent working on the task. I find it really handy when measuring the performance impact of changes. Unfortunately, the current interface of gdb::parallel_for_each, which receives a simple callback, is not well-suited for that, once I introduce the dynamic partitioning. The callback would get called once for each work item batch (multiple time for each worker thread), so it's not possible to maintain a per-worker thread object for the duration of the parallel for. To allow this, I changed gdb::parallel_for_each to receive a worker type as a template parameter. Each worker thread creates one local instance of that type, and calls operator() on it for each work item batch. By having a scoped_time_it object as a field of that worker, we can get the timings per worker thread. The drawbacks of this approach is that we must now define the parallel task in a separate class and manually capture any context we need as fields of that class. Change-Id: Ibf1fea65c91f76a95b9ed8f706fd6fa5ef52d9cf Approved-By: Tom Tromey 2025-09-30 Simon Marchi gdbsupport: re-work parallel_for_each test, again I started working on this patch because I noticed that this parallel_for_each test: /* Check that if there are fewer tasks than threads, then we won't end up with a null result. */ is not really checking anything. And then, this patch ended with several changes, leading to general refactor of the whole file. This test verifies, using std::all_of, that no entry in the intresults vector is nullptr. However, nothing ever adds anything to intresults. Since the vector is always empty, std::all_of is always true. This state probably dates back to afdd1366358c ("Back out some parallel_for_each features"), which removed the ability for parallel_for_each to return a vector of results. That commit removed some tests, but left this one in, I'm guessing as an oversight. One good idea in this test is to check that the worker never receives empty ranges. I think we should always test for that. I think it's also a good idea to test with exactly one item, that's a good edge case. To achieve this without adding some more code duplication, factor out the core functionality of the test in yet another test_one function (I'm running out of ideas for names). In there, check that the range received by the worker is not empty. Doing this pointed out that the worker is actually called with empty ranges in some cases, necessitating some minor changes in parallel-for.h. Then, instead of only checking that the sum of the ranges received by worker functions is the right count, save the elements received as part of those ranges (in a vector), and check that this vector contains each expected element exactly once. This should make the test a bit more robust (otherwise we could have the right number of calls, but on the wrong items). Then, a subsequent patch in this series changes the interface or parallel_for_each to use iterator_range. The only hiccup is that it doesn't really work if the "RandomIt" type of the parallel_for_each is "int". iterator_range::size wouldn't work, as std::distance doesn't work on two ints. Fix this in the test right away by building an std::vector to use as input. Finally, run the test with the default thread pool thread count in addition to counts 0, 1 an 3, currently tested. I'm thinking that it doesn't hurt to test parallel_for_each in the configuration that it's actually used with. Change-Id: I5adf3d61e6ffe3bc249996660f0a34b281490d54 Approved-By: Tom Tromey 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Further tclint fixing Currently stable tclint (v6.0.1) as used in pre-commit doesn't check code that is passed as arguments to commands specific to the gdb testsuite [1], like with_test_prefix: ... with_test_prefix foo { ... } ... I wrote a rudimentary tclint patch handling this, skipping the dwarf assembler procs. Fix the additional issues found. [1] https://github.com/nmoroze/tclint/issues/121 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Expand gdb/testsuite/lib in tclint.toml Replace gdb/testsuite/lib in the exclude list in tclint.toml with the files in it, while dropping the ones that are already tclint-clean. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.base Running tclint on the test-cases in gdb.base shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.arch Running tclint on the test-cases in gdb.arch shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.dwarf2 Running tclint on the test-cases in gdb.dwarf2 shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.mi Running tclint on the test-cases in gdb.mi shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.cp Running tclint on the test-cases in gdb.cp shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Fix gdb.trace Running tclint on the test-cases in gdb.trace shows a few problems. Fix these. 2025-09-30 Tom de Vries [gdb/testsuite, tclint] Document some tclint issues in tclint.toml While tclint-cleaning gdb testsuite directories I ran into a few issues, which I filed upstream. Mention them in gdb/tclint.toml. 2025-09-30 Tom de Vries [pre-commit] Set default_stages to pre-commit I realized I was seeing the newly added tclint check twice: ... $ touch gdb/testsuite/gdb.base/foo.exp $ git add gdb/testsuite/gdb.base/foo.exp $ git commit -a -m foo 2>&1 | grep tclint tclint..................................................................Passed tclint..............................................(no files to check)Skipped $ ... The hook is run once for stage pre-commit, and once for stage commit-msg. Since the hook doesn't specify a stage at which it's supposed to be run, it takes its default from default_stages, which defaults to all stages. Fix this by setting default_stages to pre-commit: ... $ git commit -a -m foo 2>&1 | grep tclint tclint..................................................................Passed $ ... The only hook sofar that needs a different stage than pre-commit is codespell-log, and it's not affected by this change because it has an explicit "stages: [commit-msg]" setting. Approved-By: Tom Tromey 2025-09-30 Tom Tromey Fix bug in gdb.lookup_type gdb.lookup_type accepts a 'block' argument, but in some cases does not use it. This can cause the wrong type to be returned. This patch fixes the problem by simply passing the block through. I have no idea why it worked the way it did, and there weren't any tests for the 'block' parameter. (I didn't look at git blame out of fear that it was my patch back in the day.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16942 2025-09-30 Tom de Vries [gdb/testsuite] Fix gdb.tui/pr30056.exp arrow right test On aarch64-linux, I run into: ... FAIL: gdb.tui/pr30056.exp: arrow right ... because while the intention is to observe the change from: ... | 20 main (void) | ... into: ... | 20 ain (void) | ... we're actually looking at another line. Fix this by looking at the contents of the entire source window. Tested on aarch64-linux and x86_64-linux. PR testsuite/33506 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33506 2025-09-30 Andrew Burgess gdb: some process_stratum_target should not be shared When multi-target support was added to GDB, an assumption was made that all process_stratum_target sub-classes could be shared by multiple inferiors. For things like the Linux and FreeBSD native targets, this is absolutely true (or was made true). But some targets were either not updated, or, due to design restrictions, cannot be shared. This patch adds a target_ops::is_shareable member function. When this returns false then this indicates that an instance of a particular target should only appear on a single target stack. It is fine for difference instances of a single target type to appear on different target stacks though. This is my second attempt at this patch. The first attempt can be found here: https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com The initial approach was to have all targets be shareable by default, and to then mark those targets which I knew were problematic. Specifically, the only target I was interested in was core_target, which cannot be shared (details below). During review Tom pointed out: I think there are a lot of other targets that can't be shared... remote-sim, all the trace targets, even I think windows-nat, since it isn't multi-inferior-capable yet. The suggestion was that the default should be that targets were NOT shareable, and we should then mark those targets which we know can be shared. That is the big change in this iteration of the patch. The core_target is still non-shareable. This target stores state relating to the open core file in the core_target and in the current inferior's program_space. After an 'add-inferior' command, if we share the core_target, the new inferior will have its own program_space, but will share the core_target with the original inferior. This leaves the new inferior in an unexpected state where the core BFD (from the new program_space) is NULL. Attempting to make use of the second inferior, e.g. to load a new executable, will (on x86 at least) cause GDB to crash as it is not expecting the core BFD to be NULL. I am working to move the core file BFD into core_target, at which point it might be possible to share the core_target, though I'm still not entirely sure this makes sense; loading a core file will in many cases, automatically set the executable in the program_space, creating a new inferior would share the core_target, but the new inferior's program space would not have the executable loaded. But I figure we can worry about this another day because .... As Tom pointed out in his review of V1, there are other targets that should be non-shareable (see quote above). In addition, I believe that the remote target can only be shared in some specific situations, the 'add-inferior' case is one where the 'remote' target should NOT be shared. The 'remote' (not 'extended-remote') target doesn't allow new inferior's to be started, you need to connect to an already running target. As such, it doesn't really make sense to allow a 'remote' target to be shared over an 'add-inferior' call, what would the user do with the new inferior? They cannot start a new process. They're not debugging the same process as the original inferior. This just leaves GDB in a weird state. However, 'remote' targets are a little weird in that, if the remote inferior forks, and GDB is set to follow both the parent and the child, then it does make sense to allow sharing. In this case the new inferior is automatically connected to the already running child process. So when we consider 'add-inferior' there are two things we need to consider: 1. Can the target be shared at all? The new target_ops::is_shareable function tells us this. 2. Can the target be used to start a new inferior? The existing target_ops::can_create_inferior function tells us this. If the process_stratum_target returns true for both of these functions then it is OK to share it across an 'add-inferior' call. If either returns false then the target should not be shared. When pushing a target onto an inferior's target stack, we only need to consider target_ops::is_shareable, only shareable targets should be pushed onto multiple target stacks. The new target_ops::is_shareable function returns true as its default, all the immediate sub-classes are shareable. However, this is overridden in process_stratum_target::is_shareable, to return false. All process_stratum_target sub-classes are non-shareable by default. Finally, linux_nat_target, fbsd_nat_target, and remote_target, are all marked as shareable. This leaves all other process_stratum_target sub-classes non-shareable. I did some very light testing on Windows, and I don't believe that this target supports multiple inferiors, but I could easily be wrong here. My windows testing setup is really iffy, and I'm not 100% sure if I did this right. But for the Windows target, and any of the others, if this commit breaks existing multi-inferior support, then the fix is as simple as adding an is_shareable member function that returns true. If the user tries to 'add-inferior' from an inferior with a non-shareable target, or the 'remote' target as it cannot start new inferiors, then they will get a warning, and the new inferior will be created without a connection. If the user explicitly asks for the new inferior to be created without a connection, then no warning will be given. At this point the user is free to setup the new inferior connection as they see fit. I've updated the docs, and added a NEWS entry for the new warning. In the docs for clone-inferior I've added reference to -no-connection, which was previously missing. Some tests needed fixing with this change, these were gdb.base/quit-live.exp, gdb.mi/mi-add-inferior.exp, gdb.mi/new-ui-mi-sync.exp, and gdb.python/py-connection-removed.exp. In all cases, when using the native-gdbserver board, these tests tried to create a new inferior, and expected the new inferior to start sharing the connection with the original inferior. None of these tests actually tried to run anything in the new inferior, if they did then they would have discovered that the new inferior wasn't really sharing a connection. All the tests have been updated to understand that for 'remote' connections (not 'extended-remote') the connection will not be shared. These fixes are all pretty simple. Approved-By: Tom Tromey 2025-09-30 Rainer Orth gas: Default to V8+ on 32-bit Solaris/SPARC While compilers default to v8plus on 32-bit Solaris/SPARC (gcc at least since 4.4 in 2009, cc since at least Stdio 9 in 2010), gas still uses a sparclite default. While this doesn't cause issue for gcc (it passes -Av8plus as necessary), it repeatedly lead to problems in the testsuite which has to be sprinkled with setting ASFLAGS accordingly since gas cannot assemble the gcc output by default. This patch switches the default to v8plus on Solaris to match gcc. I had to introduce a new arch value, v8plus-32, matching v9-64, to allow for this. I cannot reliably tell if other SPARC targets are similarly affected, so this patch restricts the change to Solaris. Tested on sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11. 2025-09-25 Rainer Orth gas: * config/tc-sparc.c (sparc_arch_table): Introduce v8plus-32. * configure.tgt (generic_target) : Set arch to v8plus-32 for 32-bit sparc. * testsuite/gas/sparc/v8plus.rd, testsuite/gas/sparc/v8plus.s: New test. * testsuite/gas/sparc/sparc.exp: Run it on sparc*-*-solaris2*. 2025-09-30 GDB Administrator Automatic date update in version.in 2025-09-29 Tom Tromey Bump version of 'black' for pre-commit I ran "pre-commit autoupdate" and it updated 'black'. I'm checking this in. The updated black didn't cause any formatting changes to the Python code. 2025-09-29 GDB Administrator Automatic date update in version.in 2025-09-28 Rainer Orth bfd: Fix build with -DDEBUG=2 When building with -DDEBUG=2, bfd doesn't compile: In file included from bfd/elfcode.h:2051, from bfd/elf32.c:23: bfd/elfcore.h: In function ‘_bfd_elf32_core_find_build_id’: bfd/elfcore.h:354:3: error: implicit declaration of function ‘elf_debug_file’; did you mean ‘elf_debug_section’? [-Wimplicit-function-declaration] 354 | elf_debug_file (&i_ehdr); | ^~~~~~~~~~~~~~ | elf_debug_section This happens because a guard in elfcore.h doesn't match the others. This patch fixes this, allowing the build to complete. Tested on amd64-pc-solaris2.11. 2025-09-15 Rainer Orth bfd: * elfcore.h [DEBUG]: Fix guard. 2025-09-28 GDB Administrator Automatic date update in version.in 2025-09-27 H.J. Lu binutils: Pass target plugin file to target ar/nm/ranlib There are 2 kinds of binutils tests: 1. Tests of binutils object files and libraries using the build tools, like CC, AR, NM and RANLIB. 2. Tests of binutils programs as the target tools, like CC_FOR_TARGET, AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET. Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for target ar/nm/ranlib. PR binutils/33483 * Makefile.in: Regenerated. * configure: Likewise. * Makefile.tpl (AR_FOR_TARGET): Add @AR_PLUGIN_OPTION_FOR_TARGET@. (NM_FOR_TARGET): Add @NM_PLUGIN_OPTION_FOR_TARGET@. (RANLIB_FOR_TARGET): Add @RANLIB_PLUGIN_OPTION_FOR_TARGET@. * configure.ac: Use CLANG_PLUGIN_FILE_FOR_TARGET and GCC_PLUGIN_OPTION_FOR_TARGET to set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and RANLIB_PLUGIN_OPTION_FOR_TARGET. AC_SUBST AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and RANLIB_PLUGIN_OPTION_FOR_TARGET. config/ PR binutils/33483 * clang-plugin.m4 (CLANG_PLUGIN_FILE_FOR_TARGET): New. * gcc-plugin.m4 (GCC_PLUGIN_OPTION_FOR_TARGET): Likewise. 2025-09-27 GDB Administrator Automatic date update in version.in 2025-09-27 Tom de Vries [gdb/testsuite] Drop tclsh dependency The test-case gdb.tui/tuiterm-2.exp uses a tcl script gdb.tcl that uses tclsh as its interpreter: ... #!/usr/bin/env tclsh ... I used tclsh because I assumed it was an existing dependency of dejagnu/expect, but apparently [1] that's not the case. IWBN to use some existing dependency instead. Using expect instead of tclsh also works on my system, but looking in /usr/bin/runtest I realized that someone might have a dejagnu setup with a custom expect indicated by setting an env var EXPECT. So to find expect we'd have to mimic whatever runtest is doing to find expect, or do: ... $ runtest --version -v | grep "Expect binary" ... using the appropriate runtest. That sounds non-trivial and fragile, so simply use a shell script with /bin/sh interpreter instead. Tested on x86_64-linux. Approved-By: Tom Tromey [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220736.html 2025-09-27 Tom de Vries [gdb/testsuite] Check spawn result in gdb.tui/tuiterm-2.exp Simon reported [1] that test-case gdb.tui/tuiterm-2.exp fails with an ERROR if tclsh is missing. Fix this by checking that spawning the gdb.tcl script succeeds. While we're at it, also add some missing cleanup related to the spawned process. Tested on x86_64-linux. Approved-By: Tom Tromey [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220736.html 2025-09-27 Tom de Vries [gdb/testsuite] Handle wrap mode unsupported in gdb.tui/wrap-line.exp When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, we run into some fails in the CLI part of the test-case because: ... (gdb) maint info screen ... Readline wrapping mode: unsupported (terminal is not Cursor Up capable) ... Fix this by requiring wrapping mode "readline" for that part of the test-case. Tested on x86_64-linux and msys2-ucrt64. Approved-By: Tom Tromey 2025-09-27 Tom de Vries [gdb/testsuite] Fix timeout in gdb.tui/wrap-line.exp When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, I run into a timeout here: ... set test "startup prompt" gdb_test_multiple "" $test { -re "^$gdb_prompt $" { pass "$test" } } ... due to running into "^[[6n(gdb) ". Fix this by allowing this, similar to how this was fixed in default_gdb_start by commit 7e1964f9c61 ("[gdb/testsuite] Set TERM to dumb by default"). Tested on x86_64-linux and msys2-ucrt64. Approved-By: Tom Tromey 2025-09-27 Tom de Vries [gdb/testsuite] Require allow_tui_tests in gdb.tui/tui-missing-src.exp When running test-case gdb.tui/tui-missing-src.exp on msys2-ucrt64, I run into an error due to some filename mismatch. I could try to fix this, but a bit later the test-case would bail out at Term::enter_tui because allow_tui_tests returns 0. Instead, fix this by adding an early require of allow_tui_tests. Tested on x86_64-linux and msys2-ucrt64. Approved-By: Tom Tromey 2025-09-27 Tom de Vries [gdb/testsuite] Declare TUI tests unsupported on msys2-ucrt64 I tried to run the TUI tests on msys2-ucrt64, and ran into: ... (gdb) tui enable^M Cannot enable the TUI when output is not a terminal^M (gdb) ... The TUI works fine in an msys2-ucrt64 terminal, it's just the testsuite setup that doesn't work. Fix this by bailing out for istarget *-*-mingw* in allow_tui_tests. Tested on x86_64-linux and msys2-ucrt64. Approved-By: Tom Tromey PR testsuite/33362 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33362 2025-09-27 Tom de Vries [gdb/testsuite] Improve gdb.tui/pr30056.exp Fix a few things I noticed while working on test-case gdb.tui/pr30056.exp: - unnecessary indentation due to save_vars - missing gdb_assert checking the result of Term::wait_for_region_contents - redundant comment "Uncomment this to simulate that PR cli/30498 is fixed" Tested on x86_64-linux. Approved-By: Tom Tromey 2025-09-27 Tom de Vries [gdb/testsuite] Remove wait in gdb.tui/pr30056.exp In test-case gdb.tui/pr30056.exp, we have: ... # Send arrow-right. send_gdb "\033\[C" # We need the arrow-right to be processed by readline, before we # send the following ^C. Waiting 1 ms seems to do that. after 1 ... Waiting for an effect by sleeping is fragile. The reason we're doing so is that we're waiting for an effect that is not visible: the arrow-right is meant to horizontally scroll the source window, but since there's no source, nothing happens. Fix this by using an executable in the test-case, with a source file containing a comment long enough to make horizontal scrolling possible. Fixing this means we no longer run into PR33371, so that PR will need its own test-case. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-09-26 Tom Tromey Use exec_and_log in next.py Some code in next.py avoids exec_and_log due to its exception behavior. Now that exec_and_log always forwards exceptions, this is easily fixed. 2025-09-26 Tom Tromey Always propagate exceptions in DAP This changes the DAP exec_and_log function to always transform an exception into a DAPException and propagate it. As the bug points out, we haven't always wrapped calls when appropriate. I think it's better to cause the request to fail by default; if any spot truly needs to ignore errors, that is readily done at the point of call. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33346 2025-09-26 Tom Tromey Remove Invoker class from DAP The Invoker used to be more convenient, before DAP requests were run on the gdb thread by default. Now it is barely used and easily replaced by a couple of lambdas. Fix minor bug in dap-support.exp Commit faee137249c8 refactored dap-support.exp, but accidentally left a reference to a variable that was renamed. I noticed this when an earlier version of this series provoked one of the errors in this code. 2025-09-26 oltolm dwarf: properly update all_comp_units_without_ranges in stash_comp_unit each->next_unit_without_ranges = file->all_comp_units_without_ranges; - file->all_comp_units_without_ranges = each->next_unit_without_ranges; The second line of this code is probably a bug because it does nothing. It was probably supposed to update "file->all_comp_units_without_ranges" to point to "each" - the new head of the list. 2025-09-26 Andrew Hanson include/aout/aout64.h: guard ARCH_SIZE with defined() Silence -Wundef when ARCH_SIZE is not defined by checking that it is defined before comparing its value. 2025-09-26 Andrew Hanson bfd: guard ARCH_SIZE uses to avoid -Wundef bfd/ * elf-bfd.h: Use `defined(ARCH_SIZE)` instead of testing ARCH_SIZE directly, to silence -Wundef when ARCH_SIZE is not defined. 2025-09-26 Andrew Hanson include/binary-io.h: guard O_BINARY usage with defined check include/ * binary-io.h: Fix -Wundef compiler warning when O_BINARY is not defined. Wrap the check to ensure portability across platforms. 2025-09-26 Jan Beulich Dwarf: adjust fetch_indirect{,_line}_string()'s return type As already is the case for fetch_indexed_string() and fetch_alt_indirect_string(), have them return a pointer to plain char, properly compatible with e.g. the %s format specifier that the return values are used with in several cases. This way no casts at call sites are necessary, and several (bogus) ones in the functions can be exchanged for just one each. Some other constification is needed elsewhere, now that const-ness isn't being cast away anymore. 2025-09-26 GDB Administrator Automatic date update in version.in 2025-09-25 Abhay Kandpal PowerPC: Fix typo in PowerPC note pseudo-section names The recent tidy-up commit 09e56f0515c3 ("Code tidy: bfd/elf.c: Tidy up core note handling code.") introduced regressions in the PowerPC core note handling. The pseudo-section names for TM_CVSX, TM_SPR, VSX and VMX notes were defined with an underscore instead of a hyphen, breaking GDB test cases. The same goes for one riscv and one s390 define. This patch restores the correct section names by using hyphens in the definitions, fixing 897 GDB test failures on PowerPC. bfd/ * elf.c: (NOTE_PSEUDO_SECTION_PPC_TM_CVSX), (NOTE_PSEUDO_SECTION_PPC_TM_SPR, NOTE_PSEUDO_SECTION_PPC_VSX), (NOTE_PSEUDO_SECTION_PPC_VMX, NOTE_PSEUDO_SECTION_RISCV_CSR), (NOTE_PSEUDO_SECTION_S390_CTRS): Use hyphens in section names instead of underscores. 2025-09-25 Andrew Burgess gdb/doc: be more verbose about .gdb_index changes in version 9 I had reason to read the docs relating to .gdb_index format, and ended up having to look at historical versions of the documentation in order to clarify exactly what changed with the introduction of version 9. Given that we claim versions 7, 8, and 9 are all still allowable index versions, I think our docs should make it clear what the current format is, but also what previous formats looked like. I did try to do the same for the changes from 7 to 8, but even after reading commit 796a7ff8234cfaa8a I'm still not entirely clear what changed. If I gain some insight in the future then there might be a follow on patch for that too. Approved-By: Eli Zaretskii 2025-09-25 Bruce McCulloch libctf: dump CTF array dimensions in the right order Before GCC PR114186, all looked good in the land of multidimensional arrays: you wrote int a[5][10]; and ctf_type_aname() et al would print it as int [5][10] Unfortunately this was two bugs in one. GCC was emitting the array as if it were int a[10][5], i.e. as this: a -> [10] -> [5] -> int rather than a -> [5] -> [10] -> int as it should be. libctf was hiding this by printing them in the wrong order, concealing the bug from anyone using objdump --ctf or anything but actual type graph traversal. Once this was fixed for GCC, the bug was visible in libctf: multidimensional arrays were printed backwards! (But this is just a print-time bug: the underlying bug, that something traversing the type graph would see the array in backwards order, was fixed by the fix to GCC.) Fix this libctf bug, printing the arrays the right way round. In a possibly futile attempt to retain some vestige of backwards compatibility, introduce a new bug-compat flag CTF_F_ARRNELEMS, which, if on, indicates that PR114186 is fixed and GCC is emitting array elements the right way round. (Unfortunately, the fix went in without this flag, so some GCCs will still emit CTF that will cause libctf to print them wrong, even with this fix -- but it's no wronger than it was before, and new GCC and new binutils, as well as GCC older than any fix for PR114186 and new binutils, will print things properly. Someone traversing the type graph will see things right after the GCC fix, wrong before it, and there isn't really any reliable way to tell which you have, though if CTF_F_ARRNELEMS is set, you definitely have a fixed GCC. The test checks for this, but it's not something we expect actual users to ever do -- CTF dict flags are an internal implementation detail with no user-visible API for a reason.) [nca: log message, test compat with older compilers] include/ * ctf.h (CTF_F_ARRNELEMS): New bug-compat flag. (CTF_F_MAX): Adjust. libctf/ PR libctf/32161 * ctf-decl.c (ctf_decl_push): Prepend if this is an array and the bug-compat flag is set. * ctf-dump.c (ctf_dump_header): Dump the new bug-compat flag. * testsuite/libctf-lookup/multidim-array*: New test. 2025-09-25 Nick Alcock libctf: fix querying of large structures After GCC PR 121411 is fixed, large structures (with offsets > 512MiB) are written correctly... but libctf cannot query them properly unless they are even bigger (> 4GiB), because it checks to see if the ctt_size is CTF_LSIZE_SENT to decide whether to use a ctf_lmember_t or a ctf_member_t to encode the structure members. But the structure member offsets are in *bits*, not bytes: the right value to check is CTF_LSTRUCT_THRESH, which is 1/8th the size. (Thanks to Martin Pirker for the diagnosis and fix.) Testing this is a bit fun, because we don't want to emit an error if the compiler is broken: but we cannot tell whether the compiler is broken using the existing lookup harness, because its input is passed through the linker (and thus the broken ld). So add another sort of link mode, "objects", which keeps the constituent object files around and passes both the final linker output and the object files that make it up to the lookup program. Our testcase can then check the linker input to see if the compiler is buggy, and only if it isn't check the linker output and fail if things aren't right. libctf/ PR libctf/33339 * ctf-types.c (ctf_struct_member): Check CTF_LSTRUCT_THRESH, not CTF_LSIZE_SENT. * testsuite/lib/ctf-lib.exp (run_lookup_test): New 'objects' link option. * testsuite/libctf-lookup/big-struct-corruption.*: New test. * testsuite/libctf-lookup/big-struct-ctf.c: New test input. 2025-09-25 H.J. Lu GDB: Regenerate configure for libtool.m4 change Regenerate aclocal.m4 and configure for libtool.m4 change. gdb/ PR binutils/33470 * aclocal.m4: Regenerated. * configure: Likewise. sim/ PR binutils/33470 * aclocal.m4: Regenerated. * configure: Likewise. 2025-09-25 H.J. Lu Binutils: Add clang LTO support to AR and RANLIB Detect the clang plugin file and and pass it to --plugin for ar and ranlib so that binutils can be built with clang LTO. bfd/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. binutils/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. gas/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. gprof/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. * testsuite/Makefile.in: Likewise. gprofng/ PR binutils/33470 * Makefile.am (ACLOCAL_AMFLAGS): Add -I ../config. * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. * gp-display-html/Makefile.in: Likewise. * libcollector/Makefile.in: Likewise. * libcollector/aclocal.m4: Likewise. * libcollector/configure: Likewise. * src/Makefile.in: Likewise. * libcollector/Makefile.am (ACLOCAL_AMFLAGS): Add -I ../../config. ld/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. libctf/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. libsframe/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. opcodes/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. 2025-09-25 H.J. Lu Binutils/GCC: Add clang LTO support to AR, NM and RANLIB Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to --plugin for ar, nm and ranlib so that binutils can be built with clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang. PR binutils/33470 * Makefile.in: Regenerated. * Makefile.tpl (NM): Add @NM_PLUGIN_OPTION@. * configure: Regenerated. * configure.ac: Include config/clang-plugin.m4. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set PLUGIN_OPTION. Set and subst NM_PLUGIN_OPTION. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use CLANG_PLUGIN_FILE and GCC_PLUGIN_OPTION. config/ PR binutils/33470 * clang-plugin.m4: New file. libbacktrace/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. libiberty/ PR binutils/33470 * aclocal.m4: Regenerated. * configure: Likewise. * configure.ac: Move GCC_PLUGIN_OPTION after GCC_NO_EXECUTABLES. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set PLUGIN_OPTION. Don't add the redundant --plugin option. zlib/ PR binutils/33470 * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. 2025-09-25 Alan Modra Re: elf: Disallow the empty global symbol name sparc64-linux-gnu +FAIL: selective2 sparc64-linux-gnu +FAIL: selective3 PR ld/33456 * elflink.c (elf_link_add_object_symbols): Move new check later to give the backend add_symbol_hook a chance to remove symbols with empty names. 2025-09-25 Alan Modra PR 33452 SEGV in bfd_elf_gc_record_vtentry Limit addends on vtentry relocs, otherwise ld might attempt to allocate a stupidly large array. This also fixes the expression overflow leading to pr33452. A vtable of 33M entries on a 64-bit host is surely large enough, especially considering that VTINHERIT and VTENTRY relocations are to support -fvtable-gc that disappeared from gcc over 20 years ago. PR ld/33452 * elflink.c (bfd_elf_gc_record_vtentry): Sanity check addend. 2025-09-25 GDB Administrator Automatic date update in version.in 2025-09-24 Andrew Burgess gdb/linux: consider ptrace_scope when building attach error message On GNU/Linux, if an attach fails, then we end up calling linux_ptrace_attach_fail_reason, which returns a string describing why the attach might have failed. This commit extends linux_ptrace_attach_fail_reason to check the current /proc/sys/kernel/yama/ptrace_scope setting. When this is set to a value greater than 0 attaching can be restricted in some cases. If I first set ptrace_scope to 1, like this: $ echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope Then use current master GDB to attach to a process, I see this: (gdb) attach 2476518 Attaching to process 2476518 ptrace: Operation not permitted. (gdb) With this patch applied the output becomes: (gdb) attach 2476518 Attaching to process 2476518 warning: the /proc/sys/kernel/yama/ptrace_scope setting of 1 might prevent attaching, see 'man 2 ptrace' ptrace: Operation not permitted. (gdb) In my (limited) experience, not every user is familiar with the ptrace_scope setting. Finding that attach just doesn't work often leads users to believe that the only way to have GDB attach to another process is to run GDB as root. Though that is a solution to the problem, my hope is that, by giving the users more information, they can make a more informed choice about which solution is right for them (e.g. run as root, change the setting, start the inferior directly under GDB, etc). This change also works for gdbserver. For example: (gdb) target extended-remote :54321 Remote debugging using :54321 (gdb) attach 2475389 Attaching to process 2475389 Attaching to process 2475389 failed: Cannot attach to process 2475389: \ Operation not permitted (1), the /proc/sys/kernel/yama/ptrace_scope \ setting of 1 might prevent attaching, see 'man 2 ptrace' (gdb) There's no test for this as testing would require adjusting a system wide setting. I've linked to a semi-related bug. It is discussing the same issue at least. This patch doesn't try to "fix" anything that the bug is talking about, it just makes it (I think) slightly clearer when the issue does arise. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31520 Approved-By: Pedro Alves Reviewed-By: Guinevere Larsen 2025-09-24 Timur Golubovich This commit adds support for catching syscalls on riscv It affects following files: - gdb/riscv-linux-tdep.c: a function to get syscall number. - gdbserver/linux-riscv-low.cc: syscall trapinfo function to enable catching syscalls on remote targets. - gdb/syscalls/riscv-linux.xml.in: a file with syscalls, generated from linux kernel sources using gdb/syscalls/update-linux-from-src.sh script. - gdb/syscalls/riscv-linux.xml: a file with syscalls, patched with group names gdb/syscalls/apply-defaults.xsl using xsltproc tool. - gdb/syscalls/update-linux.sh: set startyear to 2025 on riscv. - gdb/syscalls/update-linux-from-src.sh: riscv syscall table must be generated from kernel headers. - gdb/NEWS: catch-syscall feature is now available on riscv. - gdb/data-directory/Makefile.in: adding file with syscalls to Makefile. Approved-By: Tom Tromey 2025-09-24 Stephan Rohr gdb: resolve type to target_type in expression evaluation If an expression is evaluated with 'EVAL_AVOID_SIDE_EFFECTS', we're essentially interested in compatibility of the operands. If there is an operand of reference type, this would give us a memory value that would cause a failure if GDB attempts to access the contents. GDB fails to evaluate binary expressions for the following example: struct { int &get () { return x; }; int x = 1; } v_struct; The GDB output is: (gdb) print v_struct3.get () == 1 && v_struct3.get () == 2 Cannot access memory at address 0x0 (gdb) print v_struct3.get () == 1 || v_struct3.get () == 2 Cannot access memory at address 0x0 Likewise, GDB fails to resolve the type for some expressions: (gdb) ptype v_struct.get () type = int & (gdb) ptype v_struct.get () == 1 Cannot access memory at address 0x0 (gdb) ptype v_struct.get () + 1 Cannot access memory at address 0x0 (gdb) ptype v_struct.get () && 1 Cannot access memory at address 0x0 (gdb) ptype v_struct.get () || 1 Cannot access memory at address 0x0 (gdb) ptype !v_struct.get () Cannot access memory at address 0x0 (gdb) ptype v_struct.get () ? 2 : 3 Cannot access memory at address 0x0 (gdb) ptype v_struct.get () | 1 Cannot access memory at address 0x0 Expression evaluation uses helper functions such as 'value_equal', 'value_logical_not', etc. These helper functions do not take a 'noside' argument and if one of their value arguments was created from a function call that returns a reference type when noside == EVAL_AVOID_SIDE_EFFECTS, GDB attempts to read from an invalid memory location. Consider the following call stack of the 'ptype v_struct.get () + 1' command at the time of assertion when the memory error is raised: #0 memory_error (err=TARGET_XFER_E_IO, memaddr=0) at gdb/corefile.c:114 #1 read_value_memory (val=.., bit_offset=0, stack=false, memaddr=0, buffer=.. "", length=4) at gdb/valops.c:1075 #2 value::fetch_lazy_memory (this=..) at gdb/value.c:3996 #3 value::fetch_lazy (this=..) at gdb/value.c:4135 #4 value::contents_writeable (this=..) at gdb/value.c:1329 #5 value::contents (this=..) at gdb/value.c:1319 #6 value_as_mpz (val=..) at gdb/value.c:2685 #7 scalar_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1240 #8 value_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1489 #9 eval_op_add (expect_type=0x0, exp=.., noside=EVAL_AVOID_SIDE_EFFECTS, arg1=.., arg2=..) at gdb/eval.c:1333 #10 expr::add_operation::evaluate (this=.., expect_type=0x0, exp=.., noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/expop.h:1209 #11 expression::evaluate (this=.., expect_type=0x0, noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/eval.c:110 #12 expression::evaluate_type (this=..) at gdb/expression.h:242 'add_operation::evaluate' calls the helper 'eval_op_add' which attempts to read from the unresolved memory location. Convert to the target type to avoid such problems. The patch is implemented in 'expop.h' for the following reasons: * Support templated classes without explicit helpers, e.g., 'binop_operation' and 'comparison_operation'. * Stripping references in 'binop_promote' requires additional refactoring beyond this patch as we would need to carry on the 'noside' parameter. The above failures are resolved with the patch: (gdb) print v_struct.get () == 1 && v_struct3.get () == 2 $1 = false (gdb) print v_struct.get () == 1 || v_struct3.get () == 2 $2 = true (gdb) ptype v_struct.get () type = int & (gdb) ptype v_struct.get () == 1 type = bool (gdb) ptype v_struct.get () + 1 type = int (gdb) ptype v_struct.get () && 1 type = bool (gdb) ptype v_struct.get () || 1 type = bool (gdb) ptype !v_struct.get () type = bool (gdb) ptype v_struct.get () ? 2 : 3 type = int (gdb) ptype v_struct.get () | 1 type = int Co-Authored-By: Tankut Baris Aktemur Approved-By: Tom Tromey 2025-09-24 Tom de Vries [gdb/testsuite] Fix gdb.tui/tui-layout-asm-short-prog.exp on cygwin On x86_64-cygwin, I run into: ... Running tui-layout-asm-short-prog.exp ... gdb compile failed, tui-layout-asm-short-prog.S: Assembler messages: tui-layout-asm-short-prog.S:26: Error: \ junk at end of line, first unrecognized character is `-' === gdb Summary === # of untested testcases 1 ... This is due to this note in gdb.tui/tui-layout-asm-short-prog.S: ... .section .note.GNU-stack,"",@progbits ... The note can be easily skipped for cygwin, but after doing so, we run into a fail. The problem is that while the test-case tries to generate 5 nops: ... .rept 5 nop .endr ... in fact 16 nops are generated. The fail is not specific to x86_64-cygwin, if we do ".rept 16" on x86_64-linux, we get the same fail. Fix this by increasing the "large" scroll amounts from 13 to 15. Tested on x86_64-cygwin and x86_64-linux. 2025-09-24 Tom de Vries [gdb/testsuite, gdbserver] Fix typos Codespell noticed two new typos: ... $ pre-commit run --all-files codespell codespell................................................................Failed - hook id: codespell - exit code: 65 gdbserver/server.cc:4255: errror ==> error gdb/testsuite/gdb.replay/missing-thread.exp:87: Whn ==> When ... Fix these. 2025-09-24 GDB Administrator Automatic date update in version.in 2025-09-23 H.J. Lu elf: Return error on unsorted symbol table if not allowed Normally ELF symbol table should be sorted, i.e., local symbols precede global symbols. Irix 6 is an exception and its elf_bad_symtab is set to true. Issue an error if elf_bad_symtab is false and symbol table is unsorted. PR ld/33450 * elflink.c (set_symbol_value): Change return type to bool and return false on error. Issue an error on unsorted symbol table if not allowed. (elf_link_input_bfd): Return false if set_symbol_value reurns false. 2025-09-23 H.J. Lu elf: Disallow the empty global symbol name Reject the empty global symbol name, "". PR ld/33456 * elflink.c (elf_link_add_object_symbols): Disallow the empty global symbol name. 2025-09-23 Alice Carlotti aarch64: Reorder feature bits Group the architecture version bits at the start of the enum, and add a comment explaining the purpose of AARCH64_FEATURE_V8A. aarch64: Remove unused feature bits Many feature bits were unnecessarily added for features with no command line flags, and effectively acted as aliases of the architecture version bit they were linked to. The system register regating patch removed all uses of these feature bits, so we can just remove them. 2025-09-23 Alice Carlotti aarch64: Update system register gating Historically we have been inconsistent and overly restrictive in our choice of features to gate system register accesses. (Originally this gating was always applied, but now it is disabled unless the --menable-sysreg-checking option is specified). This patch updates these constraints, following the principle that we should only reject a system register access if it requires some architecture feature or version whose corresponding command line extension has not been enabled. The most common change in this patch concerns system registers that were: - part of a feature FEAT_X with no corresponding command line extension; - introduced in a newer architecture version ArmvX.Z; - permitted to be implemented from an earlier version ArmvX.Y. Previously these system registers tended to be gated on ArmvX.Z or left ungated, but following the above principle they are now gated on ArmvX.Y instead. 2025-09-23 Alice Carlotti aarch64: Remove CSRE system registers Most support for CSRE was removed from Binutils in 2021 after it was removed from the architecture. This patch removes the remaining system registers and test files. aarch64: Remove teecr32_el1 and teehbr32_el1 These system registers were removed from the architecture over a decade ago, so there's no need to continue supporting them. aarch64: Relax sysreg-1.d test expectations Accept any instruction address in each line - this will simplify the removal of instructions from this file in a later patch. aarch64: Add missing system registers This adds all of the system registers present in the 2025-03 release of the Architecture Registers spec (DDI0601) that were missing from Binutils. aarch64: Add FEAT_SRMASK system registers 2025-09-23 Alice Carlotti aarch64: Make spmzr_el0 write-only Remove all test cases that expect spmzr_el0 to be readable, and remove some redundant default macro values from armv9_5-a-sysregs.s while we're there. Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be the first test for the "reading from a write-only register" note. Also remove the recently added -menable-sysreg-checking option from this test, both to simplify the addition of spmzr_el0 to the test, and to verify that read/write diagnostics don't depend on that option. 2025-09-23 Alice Carlotti aarch64: Sort aarch64-sys-regs.def Fix obvious alphabetisation errors, and move s2pir_el2 and s2por_el1 to the start of the "s" section to match the ordering in the Arm ARM. 2025-09-23 Alice Carlotti aarch64: Remove F_ARCHEXT flag The flag is unnecessary, because we can just unconditionally check the features field every time. Having the information duplicated in two separate fields makes it harder to maintain, particularly in the context of the upcoming regating patch. The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now unused, so remove that as well. 2025-09-23 Tom Tromey Fix crash in f-typeprint.c I noticed a crash in f-typeprint.c that was hidden by an xfail: XFAIL: gdb.fortran/vla-array.exp: print variable length string array type (GDB internal error) (PRMS gcc/101826) I think this was introduced by commit 6594ca4a ("do not handle a NULL linebuffer in pager_file::puts") but not detected due to the xfail. It seems bad for an xfail to cover up a crash but I haven't investigated that. Meanwhile, this patch fixes the crash by checking for a NULL pointer when calling gdb_puts. Approved-by: Kevin Buettner 2025-09-23 Andrew Burgess gdb: crash if thread unexpectedly disappears from thread list A bug was reported to Red Hat where GDB was crashing with an assertion failure, the assertion message is: ../../gdb/regcache.c:432: internal-error: get_thread_regcache: Assertion `thread->state != THREAD_EXITED' failed. The backtrace for the crash is: #5 0x000055a21da8a880 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=problem@entry=0x55a21e289060 , file=, line=, fmt=, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:477 #6 0x000055a21da8aadf in internal_verror (file=, line=, fmt=, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:503 #7 0x000055a21dcbd055 in internal_error_loc (file=file@entry=0x55a21dd33b71 "../../gdb/regcache.c", line=line@entry=432, fmt=) at ../../gdbsupport/errors.cc:57 #8 0x000055a21d8baaa9 in get_thread_regcache (thread=thread@entry=0x55a258de3a50) at ../../gdb/regcache.c:432 #9 0x000055a21d74fa18 in print_signal_received_reason (uiout=0x55a258b649b0, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:9287 #10 0x000055a21d7daad9 in mi_interp::on_signal_received (this=0x55a258af5f60, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/mi/mi-interp.c:372 #11 0x000055a21d76ef99 in interps_notify (method=&virtual table offset 88, this adjustment 974682) at ../../gdb/interps.c:369 #12 0x000055a21d76e58f in interps_notify_signal_received (sig=, sig@entry=GDB_SIGNAL_TRAP) at ../../gdb/interps.c:378 #13 0x000055a21d75074d in notify_signal_received (sig=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:6818 #14 0x000055a21d755af0 in normal_stop () at ../../gdb/gdbthread.h:432 #15 0x000055a21d768331 in fetch_inferior_event () at ../../gdb/infrun.c:4753 The user is using a build of GDB with 32-bit ARM support included, and they gave the following description for what they were doing at the time of the crash: Suspended the execution of the firmware in Eclipse. The gdb was connected to JLinkGDBServer with activated FreeRTOS awareness JLink plugin. So they are remote debugging with a non-gdbserver target. Looking in normal_stop() we see this code: /* As we're presenting a stop, and potentially removing breakpoints, update the thread list so we can tell whether there are threads running on the target. With target remote, for example, we can only learn about new threads when we explicitly update the thread list. Do this before notifying the interpreters about signal stops, end of stepping ranges, etc., so that the "new thread" output is emitted before e.g., "Program received signal FOO", instead of after. */ update_thread_list (); if (last.kind () == TARGET_WAITKIND_STOPPED && stopped_by_random_signal) notify_signal_received (inferior_thread ()->stop_signal ()); Which accounts for the transition from frame #14 to frame #13. But it is the update_thread_list() call which interests me. This call asks the target (remote target in this case) for the current thread list, and then marks threads exited based on the answer. And so, if a (badly behaved) target (incorrectly) removes a thread from the thread list, then the update_thread_list() call will mark the impacted thread as exited, even if GDB is currently handling a signal stop event for that target. My guess for what's going on here then is this: 1. Thread receives a signal. 2. Remote target sends GDB a stop with signal packet. 3. Remote decides that the thread is going away soon, and marks the thread as exited. 4. GDB asks for the thread list. 5. Remote sends back the thread list, which doesn't include the event thread, as the remote things this thread has exited. 6. GDB marks the thread as exited, and then proceeds to try and print the signal stop event for the event thread. 7. Printing the signal stop requires reading registers, which requires a regache. We can only get a regcache for a non-exited thread, and so GDB raises an assertion. Using the gdbreplay test frame work I was able to reproduce this failure using gdbserver. I create an inferior with two threads, the main thread sends a signal to the second thread, GDB sees the signal arrive and prints this information for the user. Having captured the trace of this activity, I then find the thread list reply in the log file, and modify it to remove the second thread. Now, when I replay the modified log file I see the same assertion complaining about an attempt to get a regcache for an exited thread. I'm not entirely sure the best way to fix this. Clearly the problem here is a bad remote target. But, replies from a remote target should (in my opinion) not be considered trusted, as a consequence, we should not be asserting based on data coming from a remote. Instead, we should be giving warnings or errors and have GDB handle the bad data as best it can. This is the second attempt to fix this issue, my first patch can be seen here: https://inbox.sourceware.org/gdb-patches/062e438c8677e2ab28fac6183d2ea6d444cb9121.1747567717.git.aburgess@redhat.com In the first patch I was to checking in normal_stop, immediately after the call to update_thread_list, to see if the current thread was now marked as exited. However CI testing showed an issue with this approach; I was already checking for many different TARGET_WAITKIND_* kinds where the "is the current thread exited" question didn't make sense, and it turns out that the list of kinds in my first attempt was already insufficient. Rather than trying to just adding to the list, in this revised patch I'm proposing to move the "is this thread exited" check inside the block which handles signal stop events. Right now, the only part of normal_stop which I know relies on the current thread not being exited is the call to notify_signal_received, so before calling notify_signal_received I check to see if the current thread is now exited. If it is then I print a warning to indicate that the thread has unexpectedly exited and that the current command (continue/step/etc) has been cancelled, I then change the current event type to TARGET_WAITKIND_SPURIOUS. GDB's output now looks like this in all-stop mode: (gdb) continue Continuing. [New Thread 3483690.3483693] [Thread 3483690.3483693 exited] warning: Thread 3483690.3483693 unexpectedly exited after non-exit event [Switching to Thread 3483690.3483693] (gdb) The non-stop output is identical, except we don't switch thread (stop events never trigger a thread switch in non-stop mode). The include test makes use of the gdbreplay framework, and tests in all-stop and non-stop modes. I would like to do more extensive testing of GDB's state after the receiving the unexpected thread list, but due to using gdbreplay for testing, this is quite hard. Many commands, especially those looking at thread state, are likely to trigger additional packets being sent to the remote, which causes gdbreplay to bail out as the new packet doesn't match the original recorded state. However, I really don't think it is a good idea to change gdbserver in order to "fake" this error case, so for now, using gdbreplay is the best idea I have. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2366461 2025-09-23 Andrew Burgess gdbserver: better handling for missing argument values By passing ':' within the optstring to getopt_long, the getopt_long call will now return ':' for missing value errors and '?' for unknown argument errors, rather than returning '?' for all error types. We can now print a different error message for missing argument values. For example: $ gdbserver --debug-file :54321 /tmp/hello Missing argument value for: --debug-file Compared to: $ gdbserver --unknown :54321 ~/tmp/hello.x Unknown argument: --unknown Current HEAD gdbserver treats every error as the 'Unknown argument' error. While I was messing with the code that prints these error messages, I've wrapped then with _(...) to allow for internationalisation. Approved-By: Tom Tromey 2025-09-23 Andrew Burgess gdbserver: allow gnu style arguments to gdbserver Now that we use getopt_long for argument processing in gdbserver, it is relatively easy to support GNU style arguments, that is, arguments passed without an '=' between the argument and the value. As support for GNU style arguments is the default from getopt_long, the first part of this commit is to remove the code which deliberately disables the GNU argument support. With that done, we now need to consider optional arguments. In this case, getopt_long doesn't automatically grab the next word from ARGV to be the argument value, so I've added some code to do this. I've also tried to make this code a little smart. As the first argument passed to gdbserver that doesn't have a '--' at the start is the PORT number, the new code block I've added tries to spot if the argument value might be the port number. If it is, then we don't allow the port number to become the argument value, and instead, we pretend the argument value is missing. This seems to give better error messages. There are going to be UI changes in how gdbserver handles incorrect arguments after this commit. However, the behaviour for valid command lines should be unchanged. Approved-By: Tom Tromey 2025-09-23 Andrew Burgess gdb/i386/linux: fix possible register number conflict I noticed something that seemed really strange with the i386 register numbering. In i386-linux-tdep.h we setup I386_LINUX_ORIG_EAX_REGNUM based on I386_PKRU_REGNUM. However, in i386-tdep.h, enum i386_regnum ends like this: enum i386_regnum { ... I386_ZMM7H_REGNUM = I386_ZMM0H_REGNUM + 7, I386_PKRU_REGNUM, I386_PL3_SSP_REGNUM, I386_FSBASE_REGNUM, I386_GSBASE_REGNUM }; So I386_LINUX_ORIG_EAX_REGNUM will have the same value as I386_PL3_SSP_REGNUM. The I386_PL3_SSP_REGNUM was added in commit: commit 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4 AuthorDate: Fri Mar 29 16:38:50 2019 +0100 CommitDate: Fri Aug 29 17:02:09 2025 +0000 gdb, gdbserver: Add support of Intel shadow stack pointer register. And before that, I386_FSBASE_REGNUM and I386_GSBASE_REGNUM were added in commit: commit 1163a4b7a38a79ebd153dc5ee76ce93877d21dbd AuthorDate: Tue Mar 12 13:39:02 2019 -0700 CommitDate: Tue Mar 12 13:39:02 2019 -0700 Support the fs_base and gs_base registers on i386. So the SSP overlap is new, but the fs/gs base overlap has existed for years, so why did it not cause any problems? I think the explanation is that on i386, the fs/gs base are only used for FreeBSD, all the calls to i386_target_description that pass true for the segments argument are from fbsd files. As a result, its fine if there's numbering overlap between these i386 registers and some Linux specific i386 registers. OK, but what about the new SSP (shadow stack pointer) register? I think in this case we would see problems, if the shadow stack was supported for i386. Here's what the docs say: The ‘org.gnu.gdb.i386.pl3_ssp’ feature is optional. It should describe the user mode register ‘pl3_ssp’ which has 64 bits on amd64, 32 bits on amd64 with 32-bit pointer size (X32) and 32 bits on i386. Following the restriction of the Linux kernel, only GDB for amd64 targets makes use of this feature for now. And indeed, if we look for callers of x86_supply_ssp, which supplies the shadow stack pointer register, this is only called from amd64 specific code, either the native register fetching, or the core file loading. There's no calls from i386 code. And so, again, we have register number overlap, but we avoid any issues by not making use of these registers for i386 linux. Here's my question: Is this super clever design aimed at saving 12 bytes (3 * 4-byte registers) of space in the i386 regcache? Or is this an accident where we happen to have gotten lucky? If it's the first, then I really think there should be some comments explaining what's going on. If it's the second, then maybe we should fix this before it trips us up? This commit takes the second approach by doing the following: 1. In i386-tdep.h move all the *_NUM_REGS constants to be members of 'enum i386_regnum'. The I386_NUM_REGS value can be automatically calculated based off the (current) last enum entry, and the other *_NUM_REGS constants are calculated just as they previously were, but are moved to keep them all together. 2. In i386-linux-tdep.h, I386_LINUX_ORIG_EAX_REGNUM and I386_LINUX_NUM_REGS are moved into a new enum i386_linux_regnum, the name of which is inspired by i386_regnum with the addition of the linux tag. The first entry in this new enum starts from I386_NUM_REGS rather than I386_PKRU_REGNUM. The I386_LINUX_NUM_REGS will be calculated automatically by the compiler. 3. In amd64-linux-nat.c, I extend amd64_linux_gregset32_reg_offset so that it now has entries for the 3 registers that are no longer aliasing, this stops an assert from the end of the file triggering: gdb_assert (ARRAY_SIZE (amd64_linux_gregset32_reg_offset) == amd64_native_gregset32_num_regs); As I386_LINUX_NUM_REGS has now increased by 3. 4. Given (3) I wondered why there was no assert being triggered from the i386 code as i386_linux_gregset_reg_offset, in i386-linux-tdep.c is clearly also wrong now. So, In i386-linux-tdep.c I've added a new assertion at the end of the file. And then I've fixed i386_linux_gregset_reg_offset by adding the 3 new registers. With these changes made I believe that the register number for the $orig_eax register on i386 GNU/Linux targets should no longer be aliasing with the SSP register. For the reasons given above, I don't think this fixes any actual bugs, it's more just a, lets not have unnecessary, and undocumented, register number aliasing. This change is visible using 'maint print registers', check out the register number of $orig_eax before and after, it should now be +3 from where it was (changed from 72 to 75). I did worry briefly about gdbservers that might not support XML target descriptions and instead rely on a fixed GDB register numbering. Though, if I'm honest, I have very little sympathy for such gdbservers these days. Still, they could, potentially be tripped up by this change. However, this is not the first time in recent years that the value of I386_LINUX_ORIG_EAX_REGNUM has changed. This commit also adjusted the register number: commit 51547df62c155231530ca502c485659f3d2b66cb Date: Wed Feb 1 12:22:27 2017 +0100 Add support for Intel PKRU register to GDB and GDBserver. And I'm not aware of any bug reports that came from this, we certainly didn't feel the need to adjust the register number back again. So I'm guessing that this renumbering will also go without issue. Other than that, there should be no user visible changes after this commit. Reviewed-By: Christina Schimpe 2025-09-23 Pedro Alves Adjust gdb.base/memops-watchpoint.exp for native Windows On native Windows, I see: continue Continuing. Thread 1 hit Hardware watchpoint 2: -location a[28] Old value = 104 'h' New value = 0 '\000' 0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits ... two more of the same ... This fails for a few reasons: 1) thread_prefix_re The thread_prefix_re regexp doesn't handle the case of a thread with no name: set thread_prefix_re "(?:Thread $::decimal \[^\r\n\]* hit )?" ^ ^ Note how it expects two spaces between the thread number and the "hit" word. Fix it by dropping one of the spaces in the regexp. 2) libc vs msvcrt.dll This: -re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" { is expecting that the function exists in libc, which is not the case on Windows. Fix it by not expecting any particular library name. 3) endline consumed when it shouldn't All these patterns: -re ".*${function_re}.* \\(\\) at .*:$::decimal\r\n" { -re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" { -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" { ... consume the \r\n, and then do exp_continue, expecting that eventually the: -re -wrap "" { ... pattern matches. However, if the \r\n is already consumed, then -wrap doesn't work, because that expects "\r\n$gdb_prompt ". This wasn't noticed on Linux because there GDB prints at least one more line before the prompt: Old value = 104 'h' New value = 0 '\000' __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:171 warning: 171 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits ... Old value = 100 'd' New value = 114 'r' __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:272 272 in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits ... Fix it by expecting but not consuming the endlines. 4) msvcrt.dll implements memset with memmove Note how we are expecting a memset hit, but we get a memmove: 0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits We already handle memcpy implemented with memmove and vice versa. Fix it by handling memset implemented with memmove in the same way. With all these fixed, the test now passes cleanly on native Windows. It still passes cleanly on GNU/Linux. Change-Id: I1a8a448e3a94d1d6736aca817568b2c0408dc2dc 2025-09-23 Pedro Alves Adjust gdb.base/memops-watchpoint.exp for Cygwin/Windows When testing gdb.base/memops-watchpoint.exp on Cygwin, I see: ... continue Continuing. Thread 1 "memops-watchpoint" hit Hardware watchpoint 2: -location a[28] Old value = 104 'h' New value = 0 '\000' memset () at /usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/x86_64/memset.S:68 68 rep stosq (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits Etc. This fails on Windows because there all inferiors are multi-threaded (because both Windows and the Cygwin runtime spawn helper threads), so we always see the 'Thread N "foo" hit' prefix, which the testcase isn't expecting. Fix it by optionally expecting such the "Thread ... hit" prefix bit. Change-Id: Ia06eaf1e152f512f39324d04298e6784eca3e537 2025-09-23 Pedro Alves Simplify gdb.base/memops-watchpoint.exp gdb.base/memops-watchpoint.exp has the same code basically repeated three times. Simplify by refactoring the common code to a procedure. Modernize the gdb_test_multiple call a little bit while at it: use -wrap and $gdb_test_name. Change-Id: I42d9cbccf32760a2bc3dab2aa60412ad5a2ae291 2025-09-23 Pedro Alves Skip gdb.base/libsegfault.exp on Windows Running gdb.base/libsegfault.exp on Cygwin/MSYS2 causes badness. E.g. on Cygwin: $ make check-parallel TESTS="gdb.base/libsegfault.exp" ... Running /home/alves/gdb/src/gdb/testsuite/gdb.base/libsegfault.exp ... 0 [main] expect 6611 C:\cygwin64\bin\expect.exe: *** fatal error in forked process - error while loading shared libraries: libSegFault.so: cannot open shared object file: No such file or directory *** starting '"C:\cygwin64\bin\dumper.exe" -n "C:\cygwin64\bin\expect.exe" 8012' for pid 6611, tid 7992 *** continuing pid 6611 parent: sync byte write: broken pipe make[1]: *** [Makefile:320: check/gdb.base/libsegfault.exp] Error 255 make[1]: Target 'do-check-parallel' not remade because of errors. make[1]: Leaving directory '/home/alves/gdb/build-cygwin-testsuite' outputs/gdb.base/libsegfault/gdb.sum: no recognised summary line outputs/gdb.base/libsegfault/gdb.log: no recognised summary line make: *** [Makefile:260: check-parallel] Error 2 $ I.e., Expect's spawn fails, and that brings down the whole Expect process. The result is that in serial mode, the test run just stops. And in parallel mode we end up with incomplete gdb.sum/gdb.log files, which dg-extract-results.sh can't process. Since libSegFault.so is a glibc feature that doesn't exist on Cygwin/MSYS2, just skip the test there. Approved-by: Kevin Buettner Change-Id: I44bdbffa25a5d21c5019418b68776d334a57be26 2025-09-23 H.J. Lu elf: Don't match corrupt section header in linker input Don't swap in nor match corrupt section header in linker input to avoid linker crash later. PR ld/33457 * elfcode.h (elf_swap_shdr_in): Changed to return bool. Return false for corrupt section header in linker input. (elf_object_p): Reject if elf_swap_shdr_in returns false. 2025-09-23 GDB Administrator Automatic date update in version.in 2025-09-22 H.J. Lu elf: Don't read beyond .eh_frame section size PR ld/33464 * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Don't read beyond .eh_frame section size. 2025-09-22 Tom Tromey Update HFILES_NO_SRCDIR in gdb/Makefile.in I noticed a header file from dwarf2/ was missing from HFILES_NO_SRCDIR in gdb/Makefile.in. Looking more, I found many missing files. This patch adds them all and sorts the list -- using "sort", though, and not the advice at the top of Makefile.in that, IMO, seems hard to implement. This also removes some code from the 'tags' rule that I think is obsolete. 2025-09-22 Christina Schimpe gdb, testsuite: Fix argument unused warning with clang Since clang 19 we see: ~~ clang: warning: argument unused during compilation: '-nostartfiles' [-Wunused-command-line-argument]^M gdb compile failed, clang: warning: argument unused during compilation: '-nostartfiles' [-Wunused-command-line-argument] UNTESTED: gdb.arch/amd64-init-x87-values.exp: failed to prepare ~~ Fix this by only passing '-nostartfiles' when linking. Approved-By: Tom Tromey 2025-09-22 GDB Administrator Automatic date update in version.in 2025-09-21 Andrew Burgess gdb: new maintenance command to help debug remote argument issues Add a new maintenance command 'maint test-remote-args', this command takes an argument string and splits it using gdb::remote_args::split and then joins the result using gdb::remote_args::join and prints all of the results. This is useful for diagnosing problems with remote argument passing. This new command is identical to what the remote argument self-tests do, but while I was working on improving remote argument passing it was far easier to have a command that I could just throw example strings at, rather than having to add new selftests and recompile GDB. I ended up adding a couple of additional helper functions to the gdb::argv_vec class. Reviewed-By: Eli Zaretskii Tested-By: Guinevere Larsen Approved-By: Kevin Buettner 2025-09-21 GDB Administrator Automatic date update in version.in 2025-09-20 Tom Tromey Fix test in anonymous_struct_prefix I noticed a bad test in dwarf2/read.c:anonymous_struct_prefix: attr = dw2_linkage_name_attr (die, cu); const char *attr_name = attr->as_string (); if (attr == NULL || attr_name == NULL) return NULL; Here, if attr==NULL, this will crash before the test can be executed. This patch fixes the problem by hoisting the test. I'm checking this in as obvious. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.threads Running tclint on the test-cases in gdb.threads shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.python Running tclint on the test-cases in gdb.python shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite] Fix hardcoded constant in gdb.python/py-pp-maint.exp In test-case gdb.python/py-pp-maint.exp, I came across: ... gdb_test "disable pretty-printer global lookup_function_lookup_test" \ "1 printer disabled.*[expr $num_pp - 1] of $num_pp printers enabled" gdb_test "disable pretty-printer global pp-test;.*" \ "[expr 5] printers disabled.*0 of $num_pp printers enabled" ... The "[expr 5]" can simply be rewritten as "5", but instead use the construct used in the previous gdb_test: [expr {$num_pp - 1}], given that the numbers should match. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.btrace Running tclint on the test-cases in gdb.btrace shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.fortran Running tclint on the test-cases in gdb.fortran shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.reverse Running tclint on the test-cases in gdb.reverse shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Tom de Vries [gdb/testsuite, tclint] Fix gdb.guile Running tclint on the test-cases in gdb.guile shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-20 Simon Marchi gdb: make gcore-1.in and gstack-1.in shellcheck-clean Fix all the warnings pasted below, mostly by accepting shellcheck's suggestions. The only exception is $GDBARGS in gstack. There, we actually want the space-splitting, I suppose, so I chose to just ignore the warning on that line. In any case, I'm not looking to change the existing behavior in this patch. The warnings: $ shellcheck gstack-1.in gcore-1.in In gstack-1.in line 135: "$GDB" --quiet -nx $GDBARGS < Reviewed-By: Keith Seitz 2025-09-20 Simon Marchi gdb: fix long options with arguments in gcore-1.in and gstack-1.in Shellcheck 0.11.0 produces the same warning for gcore-1.in and gstack-1.in: In gcore-1.in line 74: OPTARG="${OPTARG#'$OPT'}" ^----^ SC2016 (info): Expressions don't expand in single quotes, use double quotes for that. In gstack-1.in line 67: OPTARG="${OPTARG#$OPT}" ^--^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns. The code in question exists to handle long option with arguments by hand, like `--foo=bar`, since that is not supported natively by getopts. At that line, OPTARG would contain `foo=bar`, OPT would contain `foo`, and we're trying to strip `$OPT` from the beginning of `$OPTARG`. For this to work, OPT needs to be expanded, and therefore needs double quotes (or no quotes at all, but then shellcheck complains). This bug is harmless right now because we don't use long options with arguments. I tested this by temporarily making gcore support -o|--output: o | output) prefix=$OPTARG ;; And verified that this works: $ ./gcore --output=salut 51286 ... Saved corefile salut.51286 ... Change-Id: I025be574699d67b18ada9d73ce8f2aa0c87d5a0d Reviewed-By: Sébastien Darche Reviewed-By: Keith Seitz 2025-09-20 GDB Administrator Automatic date update in version.in 2025-09-19 Pedro Alves New '--binary-output' command line option, fix gdb.mi/ testing on Windows MI testcases currently all fail on native Windows with: Running /c/gdb/src/gdb/testsuite/gdb.mi/mi-simplerun.exp ... ERROR: (timeout) GDB never initialized after 10 seconds. This is because when GDB is started in MI mode, it prints info to the terminal before -iex options are processed. I.e., before the "maint set console-translation-mode binary" command in gdb -nw -nx -q -iex "set height 0" -iex "set width 0" \ -iex "set interactive-mode on" \ -iex "maint set console-translation-mode binary" \ -i=mi ... is processed. This results in GDB printing early output with \r\r\n, like can be easily seen by passing --debug to runtest: expect: does "=thread-group-added,id="i1"\r\r\n=cmd-param-changed,param="width",value="4294967295"\r\r\n=cmd-param-changed,param="interactive-mode",value="on"\r\r\n(gdb) \r\n" (spawn_id exp10) match regular expression "~"GNU.*\r\n~".*[(]gdb[)] \r\n$"? Gate "~"GNU*\r\n~"*gdb? \r\n"? gate=no Fix this by adding a new Windows-only --binary-output command line option to GDB, which is processed much earlier than -iex, and making the testsuite pass that instead of "maint set console-translation-mode binary". Remove "maint set console-translation-mode" completely, since the only reason it existed was for the testsuite, and it was never included in any release. Reviewed-By: Eli Zaretskii Reviewed-By: Tom de Vries Change-Id: I4632707bb7c8ca573cffff9641ddeb33a0e150af 2025-09-19 Tom Tromey Change DAP condition for Ada exception catchpoint Currently, the gdb DAP implementation doesn't provide a way to filter based on the thrown Ada exception. There isn't really an ideal way to handle this in DAP: * Requiring an IDE to use an expression checking $_ada_exception exposes the IDE to any workarounds needed to get this correct (see ada-lang.c). * The setExceptionBreakpoint "filterOptions" field doesn't allow a special kind of condition to be set. (We could add one but we've generally avoided gdb-specific extensions.) * The "exceptionOptions" approach is under-documented. It could be used but it would have to be in a somewhat gdb-specific way anyway -- and this approach does not allow a separate condition that is an expression. So, after some internal discussion, we agreed that it isn't all that useful to have conditions on Ada exception catchpoints. This patch changes the implementation to treat the condition as an exception name here. 2025-09-19 Keith Seitz Correct bounds check when working around GAS DWARF 5 directory table bug Recent Go toolchains are causing GDB to crash on a relatively recent workaround for a GAS bug: commit a833790a626d9620319d0ca6aee23daa584d445c Date: Wed Nov 1 00:33:12 2023 +0100 [gdb/symtab] Work around gas PR28629 In the original GAS bug, the first directory table entry did not contain the current directory of the compilation. So the above commit added a workaround fix to prepend the second directory table entry. However recent Go toolchain compilations (specifically on aarch64) only output a single directory table entry. Looking at the workaround: if (lh->version == 5 && lh->is_valid_file_index (1)) { std::string dir = lh->include_dir_at (1); fnd.set_comp_dir (std::move (dir)); } `lh->is_valid_file_index (1)' is true, but since the directory table only has one entry, `include_dir_at (1)' returns nullptr. Consequently the std::string ctor will segfault. Since there are no guarantees that the file and directory tables are the same size, a better bounds check is to simply rely on `include_dir_at' to ensure a valid directory table entry. I have updated the workaround commit's test, gdb.dwarf2/dw2-gas-workaround.exp and tested on x86_64 and aarch64 RHEL 9 and Fedora 41. Approved-By: Andrew Burgess 2025-09-19 Tom de Vries [pre-commit] Update tclint to v6.0.1 Upstream tclint updated its stable release to v6.0.1. That version includes the pre-commit support that was missing in v0.6.0, which required us to use an unofficial repo [1]. Update tclint to v6.0.1. Tested by running: ... $ pre-commit run --all-files tclint tclint................................................................Passed ... [1] commit 7f6c7a5bb37 ("[pre-commit] Add tclint hook") 2025-09-19 Tom Tromey Handle Ada extended access thick pointers In Ada, sometimes an array is represented as a "thick" pointer -- a structure that holds a pointer to the array data and another pointer to the bounds structure. A new "extended access" feature is being added to GNAT which changes the shape of these objects. With the new feature, the bounds are inlined into the thick pointer. This patch changes gdb to understand this new feature. A test case is provided; it is written in C to avoid requiring a newer GNAT just for this test. Approved-By: Andrew Burgess 2025-09-19 Tom Tromey Handle optimized-out values in gdb.printing.make_visualizer This changes gdb.printing.make_visualizer to treat an optimized-out pointer as a scalar variable -- that is, one that does not advertise any children. This makes sense because such a pointer cannot be dereferenced. The test case checks this case, plus it ensures that synthetic pointers still continue to work. Approved-By: Andrew Burgess 2025-09-19 Guinevere Larsen gdb/riscv/record: remove possibility of recording an empty instruction When recording instructions in a riscv CPU, the function riscv_process_record works in 2 steps: first, it disassembles the current instruction and creates std::vectors with all the data that will be changed (in the "record" method), and then those get added to the history in a helper function. If the disassembly fails, the process_record function will add a new "end instruction" marker to the recorded history. And that is where the issue happens. Because the previous instruction must already have added an "end" marker and no new information has been added, since it was only disassembly, the end result is having an empty instruction in the history, which will be fully redundant. This commit just removes the end marker addition. Approved-By: Guinevere Larsen 2025-09-19 Richard Earnshaw ld: testsuite: fix duplicated names in ld-checks/over*.d ld-checks/over2.d uses the same test name as over.d. Fix this by adding disambiguation to the test name of over2.d. ld: testsuite: disambiguate sort_no tests. The two tests sort_no-1.d and sort_no-2.d have the same test name. They use the same options, but operate on different source files. Annotate the second test so that it has a unique name. ld: testsuite: Fix test name in sort_b_n_a-2.d This test was invoked with the option '--sort-section name' but the test name printed out was '--sort-section alignment'. Fix the name to match the option passed. 2025-09-19 Lulu Cai LoongArch: Use more appropriate assertions for the relocation of TLS LE PR ld/33427 Patches introduced in the GCC mainline: commit 8cad8f94b450be9b73d07bdeef7fa1778d3f2b96 Author: H.J. Lu Date: Fri Sep 5 15:40:51 2025 -0700 c: Update TLS model after processing a TLS variable Set a tentative TLS model in grokvardecl and update TLS mode with the default TLS access model after a TLS variable has been fully processed if the default TLS access model is stronger, triggered a linker error when building glibc using build-many-glibcs.py. See: https://sourceware.org/pipermail/binutils/2025-September/144225.html This fix uses more appropriate assertions. 2025-09-19 GDB Administrator Automatic date update in version.in 2025-09-18 Simon Marchi gdb/solib: pass lm_info, original_name and name to solib constructor These values are always known at construction time, so pass them to the constructor. Add constructors to some lm_info_* types when it's easy and it makes things cleaner. Change-Id: Ie2d751be276470c10c81792a93bf3ddafbcd4c33 Approved-By: Tom Tromey 2025-09-18 Simon Marchi gdb/solib-target: move name out of lm_info_target While writing patch "gdb/solib: pass lm_info, original_name and name to solib constructor", I fell into this trap: sos.emplace_back (std::move (info), info->name, info->name); This is incorrect, because info could be invalid by the time `info->name` gets evaluated. This trap was made possible by the fact that the name is kept into lm_info_target, but then moved out of it. lm_info_target::name is then no longer used. Add a new `target_library` type, used to carry the name and lm_info_target, while we parse the XML, until we build the struct solib objects. Change-Id: I0d745465021fca4da79659893562e1e9ffd04f57 Approved-By: Tom Tromey 2025-09-18 Hui Li gdb: LoongArch: Record correct frame base address (1) Description of Problem: The frame_base structure is defined in gdb/frame-base.h, a typical implementation of frame_base is return the same value for frame base, locals base and args base. When debugging following code on LoongArch, the outputs of locals base and args base are not equal to frame base address in frame base register. The frame base register is sp(r3) or fp(r22) on LoongArch. This problem only occurs when frame base register is sp, there is no problem when fp is used as frame base register. When using gcc option -fomit-frame-pointer or writing asm code without using fp, the frame base register is sp. $ cat test.c int main() { unsigned long a= 1, b = 1; a = 2; b = 2; return 0; } $ gcc -g -fomit-frame-pointer test.c -o test $ gdb test ... (gdb) start ... Temporary breakpoint 1, main () at test.c:4 4 unsigned long a= 1, b = 1; (gdb) disas Dump of assembler code for function main: 0x0000555555554740 <+0>: addi.d $sp, $sp, -16 => 0x0000555555554744 <+4>: li.w $t0, 1 0x0000555555554748 <+8>: st.d $t0, $sp, 8 0x000055555555474c <+12>: li.w $t0, 1 0x0000555555554750 <+16>: stptr.d $t0, $sp, 0 0x0000555555554754 <+20>: li.w $t0, 2 0x0000555555554758 <+24>: st.d $t0, $sp, 8 0x000055555555475c <+28>: li.w $t0, 2 0x0000555555554760 <+32>: stptr.d $t0, $sp, 0 0x0000555555554764 <+36>: move $t0, $zero 0x0000555555554768 <+40>: move $a0, $t0 0x000055555555476c <+44>: addi.d $sp, $sp, 16 0x0000555555554770 <+48>: ret End of assembler dump. (gdb) p $sp $1 = (void *) 0x7ffffffeb130 (gdb) info frame Stack level 0, frame at 0x7ffffffeb140: pc = 0x555555554744 in main (test.c:4); saved pc = 0x7ffff7e3d874 source language c. Arglist at 0x7ffffffeb140, args: Locals at 0x7ffffffeb140, Previous frame's sp is 0x7ffffffeb140 (2) Root Cause Analysis: When we use the info frame command, the addresses of previous frame's sp, arglist and locals will be printed, the arglist and locals addresses are calculated by member function of frame_base. Because LoongArch does not implement its own frame_base, a default_frame_base will be used, it will return stack address of the frame ID for frame base, locals base and args base. However, on LoongArch or other architectures, the frame base address does not always equal the stack address of the frame ID. (3) Solution: Implement loongarch_frame_base structure and loongarch_frame_base_address() to record the correct frame base address stored in sp or fp register. It can be calculated by subtracting the framebase_offset from the prev_sp recorded in loongarch_frame_cache. And locals base and args base here are equal to frame base. (4) Test: (gdb) p $sp $1 = (void *) 0x7ffffffeb130 (gdb) info frame Stack level 0, frame at 0x7ffffffeb140: pc = 0x555555554744 in main (test.c:4); saved pc = 0x7ffff7e3d874 source language c. Arglist at 0x7ffffffeb130, args: Locals at 0x7ffffffeb130, Previous frame's sp is 0x7ffffffeb140 This modification only change the output of the info frame command when sp is used as frame base register, and has no affect other functions of gdb on LoongArch. 2025-09-18 Rainer Orth Remove remnants of Solaris/PowerPC support When removing Solaris/PowerPC support, I missed a couple of references. This patch removes them. Tested with crosses to ppc-unknown-linux-gnu and powerpc-ibm-aix7. 2025-09-17 Rainer Orth * configure.ac : Remove. * configure: Regenerate. bfd: * config.bfd : Remove. gas: * configure.tgt : Remove. 2025-09-18 Tom Tromey Have gdb.ThreadExitedEvent inherit from gdb.ThreadEvent The documentation says that ThreadExitedEvent is derived from ThreadEvent, but the code does not actually implement this. This patch fixes the problem. I propose applying this to gdb 17 as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33444 Approved-By: Simon Marchi 2025-09-18 Tom Tromey Move isort config to pyproject.toml My understanding is that pyproject.toml is the "new" way to configure Python tools. Although setup.cfg can't yet be removed (flake8 has some issue with pyproject.toml), we can move the isort config here. Approved-By: Simon Marchi 2025-09-18 H.J. Lu ld: Don't use -mdirect-extern-access for LoongArch Don't check DIRECT_EXTERN_ACCESS_CFLAGS/NO_DIRECT_EXTERN_ACCESS_CFLAGS for LoongArch since -mdirect-extern-access on LoongArch works only without dynamic linker. PR ld/33409 * testsuite/config/default.exp (DIRECT_EXTERN_ACCESS_CFLAGS): Skip on LoongArch. (NO_DIRECT_EXTERN_ACCESS_CFLAGS): Likewise. 2025-09-18 H.J. Lu elf: Cache ".interp" section pointer in elf_link_hash_table Cache ".interp" section pointer in elf_link_hash_table so that a backend can use it to avoid calling bfd_get_linker_section. * elf-bfd.h (elf_link_hash_table): Add interp. * elf-m10300.c (_bfd_mn10300_elf_late_size_sections): Use the interp field in elf_link_hash_table. * elf32-arc.c (elf_arc_late_size_sections): Likewise. * elf32-arm.c (elf32_arm_late_size_sections): Likewise. * elf32-bfin.c (elf32_bfinfdpic_late_size_sections): Likewise. (bfin_late_size_sections): Likewise. * elf32-cr16.c (_bfd_cr16_elf_late_size_sections): Likewise. * elf32-cris.c (elf_cris_late_size_sections): Likewise. * elf32-csky.c (csky_elf_late_size_sections): Likewise. * elf32-frv.c (elf32_frvfdpic_late_size_sections): Likewise. * elf32-hppa.c (elf32_hppa_late_size_sections): Likewise. * elf32-lm32.c (lm32_elf_late_size_sections): Likewise. * elf32-m32r.c (m32r_elf_late_size_sections): Likewise. * elf32-m68k.c (elf_m68k_late_size_sections): Likewise. * elf32-metag.c (elf_metag_late_size_sections): Likewise. * elf32-nds32.c (nds32_elf_late_size_sections): Likewise. * elf32-or1k.c (or1k_elf_late_size_sections): Likewise. * elf32-ppc.c (ppc_elf_late_size_sections): Likewise. * elf32-s390.c (elf_s390_late_size_sections): Likewise. * elf32-score.c (s3_bfd_score_elf_late_size_sections): Likewise. * elf32-score7.c (s7_bfd_score_elf_late_size_sections): Likewise. * elf32-sh.c (sh_elf_late_size_sections): Likewise. * elf32-tic6x.c (elf32_tic6x_late_size_sections): Likewise. * elf32-tilepro.c (tilepro_elf_late_size_sections): Likewise. * elf32-vax.c (elf_vax_late_size_sections): Likewise. * elf32-xtensa.c (elf_xtensa_late_size_sections): Likewise. * elf64-alpha.c (elf64_alpha_late_size_sections): Likewise. * elf64-hppa.c (elf64_hppa_late_size_sections): Likewise. * elf64-ppc.c (ppc64_elf_late_size_sections): Likewise. * elf64-s390.c (elf_s390_late_size_sections): Likewise. * elfnn-aarch64.c (elfNN_aarch64_late_size_sections): Likewise. * elfnn-ia64.c (elfNN_ia64_late_size_sections): Likewise. * elfnn-kvx.c (elfNN_kvx_late_size_sections): Likewise. * elfnn-loongarch.c (loongarch_elf_late_size_sections): Likewise. * elfnn-riscv.c (riscv_elf_late_size_sections): Likewise. * elfxx-mips.c (_bfd_mips_elf_late_size_sections): Likewise. * elfxx-tilegx.c (tilegx_elf_late_size_sections): Likewise. * elflink.c (_bfd_elf_link_create_dynamic_sections): Cache the pointer to ".interp" section in the interp field in elf_link_hash_table. (bfd_elf_size_dynamic_sections): Use the interp field in elf_link_hash_table. * elfxx-sparc.c (UNDEFINED_WEAK_RESOLVED_TO_ZERO): Use the interp field in elf_link_hash_table. (_bfd_sparc_elf_late_size_sections): Likewise. Don't set interp. * elfxx-sparc.h (_bfd_sparc_elf_link_hash_table): Remove interp. * elfxx-x86.c (_bfd_x86_elf_link_symbol_references_local): Check htab->elf.interp instead of htab->interp. (_bfd_x86_elf_link_setup_gnu_properties): Use htab->elf.interp. * elfxx-x86.h (elf_x86_link_hash_table): Remove interp. 2025-09-18 Tom de Vries [gdb/testsuite, tclint] Fix gdb.opencl Running tclint on the test-cases in gdb.opencl shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-18 Tom de Vries [gdb/testsuite, tclint] Fix gdb.perf Running tclint on the test-cases in gdb.perf shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-18 Nick Clifton Updated and new translations for the binutils 2025-09-18 Jeremy Bryant * gdb/source.c: Comment on Emacs double slash processing feature 2025-09-18 Tom de Vries [gdb/testsuite] Two tclint.toml exclude list updates Because it's already tclint-clean, remove gdb.ctf from the exclude list in tclint.toml. While we're at it, divide the exclude list in two parts, TODO and IGNORE and move gdb.stabs to the IGNORE part because those tests are about to be removed. 2025-09-18 Tom de Vries [gdb/testsuite, tclint] Fix gdb.compile Running tclint on the test-cases in gdb.compile shows a few problems. While we're at it, likewise in lib/compile-support.exp Fix these. Tested on x86_64-linux (Fedora 42). 2025-09-18 Tom de Vries [pre-commit] Add tclint hook Add a pre-commit hook that enables tclint [1] (a Tcl linter) for the gdb testsuite. The pre-commit hook doesn't reference the official url, because that one doesn't have pre-commit support yet [2]. Instead, it uses a fork on my personal github account. The fork contains a tag v0.6.0-gdb, which is the official v0.6.0 release plus a commit adding a .pre-commit-hooks.yaml file. Given that this is a personal github account, I thought it would be safer to refer to the git SHA than to the tag. Also add a tclint configuration file gdb/tclint.toml. In the configuration file, we still ignore most dirs because they're not tclint-clean. Consequently, the tclint pre-commit check passes: ... $ pre-commit run --all-files -v tclint tclint........................Passed - hook id: tclint - duration: 0.25s $ ... PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403 Approved-By: Tom Tromey [1] https://github.com/nmoroze/tclint [2] https://github.com/nmoroze/tclint/issues/110 2025-09-18 GDB Administrator Automatic date update in version.in 2025-09-17 Thiago Jung Bauermann GDB: aarch64: Use GCS features to calculate hash of struct aarch64_features Luis noticed that when adding the gcs and gcs_linux members to struct aarch64_features in my Guarded Control Stack patch series, I neglected to modify struct hash::operator() to take them into account when computing its hash. This can cause GDB to use the wrong aarch64_features object during a debugging session. Regression tested on aarch64-linux-gnu. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33440 Suggested-by: Luis Machado Approved-By: Luis Machado 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.dap Running tclint on gdb.dap shows these warnings: ... bt-nodebug.exp:74:16: namespace eval received an argument with a \ substitution, unable to parse its arguments [command-args] eof.exp:33:1: expected braced word or word without substitutions in argument \ interpreted as script [command-args] eof.exp:34:1: expected braced word or word without substitutions in argument \ interpreted as script [command-args] ... The first one is for: ... set list_form [namespace eval ton::2list $last_ton] ... I don't think this can be fixed by rewriting into something similar, so ignore this. Likewise in lib/dap-support.exp. The second and third ones are for: ... catch "close -i $gdb_spawn_id" catch "wait -i $gdb_spawn_id" ... which can easily be fixed by using curly braces instead of double quotes, but doing so gets us: ... eof.exp:33:8: unrecognized argument for close: -i [command-args] ... This is because tclint doesn't have support for expect yet [1], so ignore this. While we're at it, fix some trailing whitespace in lib/dap-support. Approved-By: Tom Tromey [1] https://github.com/nmoroze/tclint/issues/118 2025-09-17 Andrew Burgess gdb: fix --args handling when inferior argument have dash After the commit: commit e5e76451fa82e0bc00599af96382b361c3d6ac32 Date: Fri Oct 22 07:19:29 2021 +0000 gdb/gdbserver: add a '--no-escape-args' command line option Inferior argument handling on the GDB command line was broken: $ gdb --args /bin/ls --foo ./gdb/gdb: unrecognized option '--foo' ./gdb/gdb: `--args' specified but no program specified Before the above patch the definition of the '--args' argument in the long_options array (in captured_main_1) was such that the getopt_long_only call would directly set the 'set_args' variable to true if '--args' was seen. This meant that, immediately after the getopt_long_only call, we could inspect set_args and break out of the argument processing loop if needed. After the above patch '--args' (and the new '--no-escape-args') no longer set set_args directly via the getopt_long_only call. Instead the getopt_long_only call returns an OPT_* enum value, which we then use in the following switch statement in order to set the set_args variable. What this means is that, immediately after the getopt_long_only call, set_args no longer (immediately) indicates if --args was seen. After the switch statement, when set_args has been updated, we go around the argument processing loop again and call getopt_long_only once more. This extra getopt_long_only call will, if it finds another argument that starts with a dash, update the global optind to point to this option. At this point things have gone wrong, GDB has now lost track of the argument containing the program name the user wanted us to start. This leads to GDB exiting with the above error. The solution is to move the check of set_args to either before the getopt_long_only call, or to after the switch statement. I chose to move it earlier as this keeps all the loop exiting checks near the beginning. I've added more tests that cover this issue. Approved-By: Luis Machado Tested-By: Luis Machado 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.ada Running tclint on the test-cases in gdb.ada shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.asm Running tclint on the test-cases in gdb.asm shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.disasm Running tclint on the test-cases in gdb.disasm shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.go Running tclint on the test-cases in gdb.go shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.gdb Running tclint on the test-cases in gdb.gdb shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.dlang Running tclint on the test-cases in gdb.dlang shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.ctf Running tclint on the test-cases in gdb.ctf shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.server some more Running tclint on the test-cases in gdb.server shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.debuginfod Running tclint on the test-cases in gdb.debuginfod shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.linespec Running tclint on the test-cases in gdb.linespec shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 Tom de Vries [gdb/testsuite, tclint] Fix gdb.multi Running tclint on the test-cases in gdb.multi shows a few problems. Fix these. Tested on x86_64-linux. 2025-09-17 GDB Administrator Automatic date update in version.in 2025-09-16 Tom de Vries [gdb/testsuite] Remove more uses of "eval" Remove some more uses of the Tcl "eval" proc. In most cases the {*} "splat" expansion is used instead. The exceptions are: - gdb.base/inferior-args.exp where we rewrite: set cmd [format "lappend item \{ '%c' '\\%c' \}" 34 34] eval $cmd into: lappend item [format { '%c' '\%c' } 34 34] - reset_vars in lib/check-test-names.exp where we simply drop an unnecessary eval Tested on x86_64-linux. Approved-By: Tom Tromey 2025-09-16 Richard Earnshaw ld: testsuite: arm: Fix duplicate test names. Rename some tests to avoid ambiguity in the test names. I've changed several of the Thumb2 BL testnames to more accurately reflect the nature of the tests (some omitted 'bad' even when testing for errors, but that then led to other naming conflicts...). 2025-09-16 timurgol007 gdb: fix record si error in baremetal gdb While I was debugging application using spike, openocd and baremetal gdb in record mode I encountered with gdb internal error. The reason was that minus_one_ptid had been passed to record_full_target::resume method. And in this function, the assert worked in target_thread_architecture. So I added a check before calling this function, that ptid is not minus_one_ptid. Actually, minus_one_ptid here doesn't mean that an error has occured, but it is just a define for RESUME_ALL. (gdb) record (gdb) si ../../gdb/process-stratum-target.c:32: internal-error: thread_architecture: Assertion `inf != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- ... 0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t ../../gdb/process-stratum-target.c:32 0x71463a _ZN22process_stratum_target19thread_architectureE6ptid_t ../../gdb/process-stratum-target.c:29 0x77131f _ZN18record_full_target6resumeE6ptid_ti10gdb_signal ../../gdb/record-full.c:1087 0x85a761 _Z13target_resume6ptid_ti10gdb_signal ../../gdb/target.c:2654 0x677aa9 do_target_resume ../../gdb/infrun.c:2631 0x6818b5 resume_1 ../../gdb/infrun.c:2984 0x6828a8 resume ../../gdb/infrun.c:2997 0x682b13 keep_going_pass_signal ../../gdb/infrun.c:9144 0x682fd9 proceed_resume_thread_checked ../../gdb/infrun.c:3580 ... --------------------- 2025-09-16 Richard Earnshaw binutils: testsuite: fix duplicate testnames in readelf.exp There are two places in readelf.exp where we generate duplicate testnames. The first is due to calling readelf_find_size twice with the same iteration index (2). This is fixed by using 4 for the second instance. The other is at the end of readelf_thin_archive_test. This test calls readelf_test before unconditionally passing. It happens to construct exactly the same test name as readelf test (might not be a coincidence), so we end up with a duplicate test. But it seems wrong anyway to 'pass' a test that readelf_test might have failed, so simply delete this duplicate pass entry. 2025-09-16 Tom Tromey Treat attributes as code in DWARF assembler The DWARF assembler treats the 'children' of a DIE as plain Tcl code, evaluating it in the parent context. I don't recall why, but when I wrote this code, I didn't do the same thing for the attributes. Instead, there I implemented a special syntax. I was looking at this today and wondered why I didn't just use ordinary evaluation as well. This patch implements this idea. Attributes are now evaluated as plain code. This is a bit less "magical", is slightly shorter due to lack of braces, and most importantly now allows comments in the attributes section. Note that some [subst {}] calls had to be added. This could be fixed by changing DWARF expressions to also be plain Tcl code. I think that would be a good idea, but I didn't want to tack it on here. This patch requires the full ("DW_AT_...") name for attributes. I did this to avoid any possibility of name clashes. I've long considered that my original decision to allow short names for tags and attributes was a mistake. It's worth noting that many existing tests already used the long names here. Most of this patch was written by script. The main changes are in dwarf.exp, but as noted, there were some minor fixups needed in some tests. Also, after committing, 'git show' indicated some whitespace issues, so I've gone through and "tabified" some things, which is why the patch might be otherwise larger than it should be. (This was discussed a bit during the v1 submission.) v1 was here: https://inbox.sourceware.org/gdb-patches/20250530183845.2179955-1-tromey@adacore.com/ In v2 I've rebased and fixed up various tests that either changed or were added since v1. Regression tested on x86-64 Fedora 41. Approved-By: Simon Marchi 2025-09-16 Richard Earnshaw gas: testsuite: aarch64: Resolve duplicate testrun names. These are all simple typos in the test names. gas: testsuite: aarch64: Remove duplicate test from sv2p1-5.d This test runs with the assembler options '-march=armv9.4-a' twice. Looking at the related tests in this set, this appears to be redundant rather than a typo, so remove the second run. 2025-09-16 Nick Clifton gas: Define comment_chars for non-ELF PowerPC targets 2025-09-16 Pedro Alves Fix gdb.base/gcorebg.exp and --program-prefix When GDB is configured with --program-prefix, we see: Running /home/pedro/gdb/src/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 The problem is here (with --program-prefix=prefix-), from gdb.log: gcore: GDB binary (/home/pedro/gdb/build-program-prefix/gdb/testsuite/../../gdb/prefix-gdb) not found FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished That is gcore (the script, not the GDB command) trying to run the installed GDB: if [ ! -f "$binary_path/@GDB_TRANSFORM_NAME@" ]; then echo "gcore: GDB binary (${binary_path}/@GDB_TRANSFORM_NAME@) not found" exit 1 fi ... "$binary_path/@GDB_TRANSFORM_NAME@" Change-Id: I6c60fba8768618eeba8d8d03b131dc756b57ee78 2025-09-16 Pedro Alves Fix nested gdb_caching_proc with args Commit d09eba07 ("Make get_compiler_info use gdb_caching_proc") regressed some tests when you run them in isolation (as this depends on the order the gdb_caching_proc procs' results are cached). E.g.: Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ... ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp. ERROR: tcl error code TCL WRONGARGS ERROR: wrong # args: should be "gdb_real__get_compiler_info_1 language" while executing "gdb_real__get_compiler_info_1" ("uplevel" body line 1) invoked from within "uplevel 2 $real_name" (procedure "gdb_do_cache_wrap" line 3) invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 98) invoked from within gdb.base/attach.exp triggers it too, for example. This is actually a latent problem in gdb_do_cache_wrap, introduced in: commit 71f1ab80f1aabd70bce526635f84c7b849e8a0f4 CommitDate: Mon Mar 6 16:49:19 2023 +0100 [gdb/testsuite] Allow args in gdb_caching_proc This change: # Call proc real_name and return the result, while ignoring calls to pass. -proc gdb_do_cache_wrap {real_name} { +proc gdb_do_cache_wrap {real_name args} { if { [info procs save_pass] != "" } { return [uplevel 2 $real_name] <<<<<<<<<<<<<<<<<<<<<<< HERE } @@ -31,7 +31,7 @@ proc gdb_do_cache_wrap {real_name} { rename pass save_pass rename ignore_pass pass - set code [catch {uplevel 2 $real_name} result] + set code [catch {uplevel 2 [list $real_name {*}$args]} result] Missed updating the line marked with HERE above, to pass down $args. So the case of a caching proc calling another caching proc with args isn't handled correctly. We could fix this by fixing the HERE line like so: - return [uplevel 2 $real_name] + return [uplevel 2 [list $real_name {*}$args]] However, we have with_override nowadays that we can use here which eliminates the duplicated logic, which was what was missed originally. A new test that exposes the problem is added to gdb.testsuite/gdb-caching-proc.exp. This also adds a new test to gdb.testsuite/with-override.exp that I think was missing, making sure that the inner foo override restores the outer foo override. Tested-By: Simon Marchi Change-Id: I8b2a7366bf910902fe5f547bde58c3b475bf5133 2025-09-16 Richard Earnshaw gas: testsuite: all: Avoid clashing names in err-sizeof.s The first junk test in this file was missing "junk" in the test name, which resulted in a duplicate test name when comparing with the real test on line 3. gas: testsuite: elf: avoid clashing mbind test names The section12b.d test has the wrong name, leading to a clash with the section 16b.d test. Fix that up. 2025-09-16 Richard Earnshaw binutils: testsuite: avoid dup names when using multiple as: directives binutils tests support running a test with distinct options to the assembler by allowing #as: #as: But results in both test runs using the same test name in the summary file. This causes confusion if one test fails but the other doesn't (and GCC's compare_tests script will diagnose this as an error). To fix the ambiguity append the appropriate optset to the test name. We only do this if a test has multiple runs in this way to avoid causing every test result name to change. 2025-09-16 Richard Earnshaw gas: testsuite: all: use unique test names for multibyte3 tests There are two tests of the mutibyte3 source file, with different options. As things stand this results in two distinct tests in the logs with the same name. Avoid this by adding the optional testname option to the second test. 2025-09-16 Rainer Orth Remove Solaris/PowerPC support Solaris/PowerPC was a shortlived Solaris port with limited hardware support. It was released with Solaris 2.5.1 back in 1996, with support removed again only a year later in Solaris 2.6. Since this is long obsolete, this patch removes the remains of the support. Tested by a cross to ppc-unknown-linux-gnu to ascertain the build didn't get broken. 2025-09-15 Rainer Orth bfd: * config.bfd : Remove. gas: * NEWS: Mention Solaris/PowerPC removal. * configure.ac : Remove. * configure: Regenerate. * configure.in: Regenerate. * configure.tgt : Remove. * config/tc-ppc.c (ppc_solaris_comment_chars): Remove. (ppc_eabi_comment_chars): Remove. (SOLARIS_P): Remove. (msolaris): Remove. (md_parse_option): Remove "solaris", "no-solaris" hangling. (md_show_usage): Likewise. (md_begin): Remove msolaris handling. * config/tc-ppc.h (ppc_comment_chars): Fix declaration. * stabs.c (s_stab_generic) [TC_PPC && OBJ_ELF]: Remove 4-arg .stabd support. * doc/as.texi (Overview, Target PowerPC options): Remove -msolaris, -mno-solaris. * doc/c-ppc.texi (PowerPC-Opts): Remove -msolaris, -mno-solaris. (PowerPC-Chars): Remove ! as line comment character. ld: * configure.tgt : Remove. 2025-09-16 Alan Modra gas/expr.h fixme * expr.h (expressionS): Adjust comments. Use ENUM_BITFIELD for X_op. (enum operatorT): Define. Delete gas/po/gas.es.po es.po is newer, and this file is wrongly named. 2025-09-16 GDB Administrator Automatic date update in version.in 2025-09-15 Pedro Alves Make get_compiler_info use gdb_caching_proc While running tests on Windows with: $ make check-parallel RUNTESTFLAGS="-v" I noticed that get_compiler_info was invoking the compiler over and over for each testcase, even though the result is supposed to be cached. This isn't normally very visible in gdb.log, because we suppress it there: # Run $ifile through the right preprocessor. # Toggle gdb.log to keep the compiler output out of the log. set saved_log [log_file -info] log_file ... I'm not sure it's a good idea to do that suppression, BTW. I was very confused when I couldn't find the compiler invocation in gdb.log, and it took me a while to notice that code. The reason get_compiler_info in parallel mode isn't hitting the cache is that in that mode each testcase runs under its own expect/dejagnu process, and the way get_compiler_info caches results currently doesn't handle that -- the result is simply cached in a global variable, which is private to each expect. So improve this by switching get_compiler_info's caching mechanism to gdb_caching_proc instead, so that results are cached across parallel invocations of dejagnu. On an x86-64 GNU/Linux run with "make check-parallel -j32", before the patch I get 2223 calls to get_compiler_info that result in a compiler invocation. After the patch, I get 7. On GNU/Linux, those compiler invocations don't cost much, but on Windows, they add up. On my machine each invocation takes around 500ms to 700ms. Here is one representative run: $ time x86_64-w64-mingw32-gcc \ /c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \ -fdiagnostics-color=never -E ... real 0m0.639s user 0m0.061s sys 0m0.141s This reference to a 'compiler_info' global: # N.B. compiler_info is intended to be local to this file. # Call test_compiler_info with no arguments to fetch its value. # Yes, this is counterintuitive when there's get_compiler_info, # but that's the current API. if [info exists compiler_info] { unset compiler_info } is outdated, even before this patch, as "compiler_info" is a local variable in get_compiler_info. Remove all that code. Since test_compiler_info now calls get_compiler_info directly, the "Requires get_compiler_info" comments in skip_inline_frame_tests and skip_inline_var_tests are no longer accurate. Remove them. test_compiler_info's intro comment is also outdated; improve it. Changing the return value of get_compiler_info to be the 'compiler_info' string directly instead of 0/-1 was simpler. It would be possible to support the current 0/-1 interface by making get_compiler_info_1 still return the 'compiler_info' string, and then having the get_compiler_info wrapper convert to 0/-1, and I considered doing that. But the only caller of get_compiler_info outside gdb.exp is gdb.python/py-event-load.exp, and it seems that one simply crossed wires with: commit 9704b8b4bc58f4f464961cca97d362fd33740ce8 gdb/testsuite: remove unneeded calls to get_compiler_info as the test as added at roughly the same time as that commit. So simply remove that call in gdb.python/py-event-load.exp, otherwise we get something like: ERROR: ------------------------------------------- ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp ERROR: expected boolean value but got "gcc-13-3-0" ERROR: tcl error code TCL VALUE NUMBER ERROR: tcl error info: expected boolean value but got "gcc-13-3-0" Approved-By: Tom Tromey Change-Id: Ia3d3dc34f7cdcf9a2013f1054128c62a108eabfb 2025-09-15 Simon Marchi gdbsupport: remove xmalloc in format_pieces Remove the use of xmalloc (and the arbitrary allocation size) in format_pieces. This turned out a bit more involved than expected, but not too bad. format_pieces::m_storage is a buffer with multiple concatenated null-terminated strings, referenced by format_piece::string. Change this to an std::string, while keeping its purpose (use the std::string as a buffer with embedded null characters). However, because the std::string's internal buffer can be reallocated as it grows, and I do not want to hardcode a big reserved size like we have now, it's not possible to store the direct pointer to the string in format_piece::string. Those pointers would become stale as the buffer gets reallocated. Therefore, change format_piece to hold an index into the storage instead. Add format_pieces::piece_str for the callers to be able to access the piece's string. This requires changing the few callers, but in a trivial way. The selftest also needs to be updated. I want to keep the test cases as-is, where the expected pieces contain the expected string, and not hard-code an expected index. To achieve this, add the expected_format_piece structure. Note that the previous format_piece::operator== didn't compare the n_int_args fields, while the test provides expected values for that field. I guess that was a mistake. The new code checks it, and the test still passes. Change-Id: I80630ff60e01c8caaa800ae22f69a9a7660bc9e9 Reviewed-By: Keith Seitz 2025-09-15 Simon Marchi gdbsupport: remove remaining alloca uses Remove the three remaining uses of alloca in gdbsupport. I only built-tested the Windows-only portion in pathstuff.cc. Change-Id: Ie588fa57f43de900d5f42e93a8875a7da462404b Reviewed-By: Keith Seitz 2025-09-15 Simon Marchi gdbsupport: format_pieces: declare variables when needed I think it makes the code slightly easier to understand. Change-Id: I49056728e43fbf37c2af8f3904a543c10e987bba Reviewed-By: Keith Seitz 2025-09-15 Richard Earnshaw arm: Rename some tests to avoid duplicate tests names A number of arm-specific tests print the same name. This can cause problems if one of those tests fails, since then comparing tests with GCC's compare_tests script can result in ambiguities in the changes summary. Avoid this by giving tests unique names. Still to do is where a test is run more than once (eg by having multiple '#as: ' lines). This will require a tweak to the framework. 2025-09-15 Dongyan Chen RISC-V: Add support for sdtrig and ssstrict extensions. This implements the sdtrig extension, version 1.0[1] and ssstrict extension, version 1.0[2]. [1]https://github.com/riscv/riscv-debug-spec/blob/main/Sdtrig.adoc [2]https://github.com/riscv/riscv-profiles/issues/173 bfd/ChangeLog: * elfxx-riscv.c: Added sdtrig and ssstrict v1.0, and imply rules. gas/ChangeLog: * NEWS: Updated for sdtrig and ssstrict. * testsuite/gas/riscv/imply.d: DItto. * testsuite/gas/riscv/imply.s: Ditto. * testsuite/gas/riscv/march-help.l: Ditto. 2025-09-15 GDB Administrator Automatic date update in version.in 2025-09-14 Tom Tromey Remove uses of "eval" from gdb testsuite This patch removes a lot of uses of the Tcl "eval" proc from the gdb test suite. In most cases the {*} "splat" expansion is used instead. A few uses of eval remain, primarily ones that were more complicated to untangle. In a couple of tests I also replaced some ad hoc code with string_to_regexp. Tested on x86-64 Fedora 40. Reviewed-By: Tom de Vries 2025-09-14 Andrew Burgess gdb: improve show text and help text for 'remote exec-file' The current behaviour for 'show remote exec-file' is this: (gdb) show remote exec-file (gdb) set remote exec-file /abc (gdb) show remote exec-file /abc (gdb) The first output, the blank line, is just GDB showing the default empty value. This output is not really inline with GDB's more full sentence style output, so in this commit I've updated things, the output is now: (gdb) show remote exec-file The remote exec-file is unset, the default remote executable will be used. (gdb) set remote exec-file /abc (gdb) show remote exec-file The remote exec-file is "/abc". (gdb) Which I think is more helpful to the user. I have also updated the help text for this setting. Previously we had a set/show header line, but no body text, now we have: (gdb) help show remote exec-file Show the remote file name for starting inferiors. This is the file name, on the remote target, used when starting an inferior, for example with the \"run\", \"start\", or \"starti\" commands. This setting is only useful when debugging a remote target, otherwise, this setting is not used. (gdb) Which I think is more helpful. Reviewed-By: Mark Wielaard Tested-By: Mark Wielaard Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-09-14 Andrew Burgess gdb: improve how 'remote exec-file' is stored and accessed This commit makes two related changes. The goal of the commit is to update the 'remote exec-file' setting to work correctly in a multi-inferior setup. To do this I have switched from the older style add_setshow_* function, which uses a single backing variable, to the newer style add_setshow_* functions that uses a get/set callback. The get/set callbacks now directly access the state held in the progspace which ensures that the correct value is always returned. However, the new get/set API requires that the get callback return a reference to the setting's value, which in this case needs to be a std::string. Currently the 'remote exec-file' setting is stored as a 'char *' string, which isn't going to work. And so, this commit also changes 'remote exec-file' to be stored as a std::string within the progspace. Now, when switching between multiple inferiors, GDB can correctly inform the user about the value of the 'remote exec-file' setting. Approved-By: Tom Tromey 2025-09-14 Andrew Burgess gdb: have remote_target::extended_remote_run take the exec filename Small refactor, have remote_target::extended_remote_run take the name of the executable to run rather than looking it up directly, the one caller of this function has already looked up the remote-exec filename. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2025-09-14 GDB Administrator Automatic date update in version.in 2025-09-13 Tom de Vries [gdb/testsuite] Fix test names in gdb.tui/{empty,new-layout}.exp Post-commit review [1] pointed out that this change in gdb.tui/empty.exp: ... - eval Term::check_box [list "box $boxno"] $box + Term::check_box [list "box $boxno"] {*}$box ... is incomplete because it leaves the "[list ...]" in place. Indeed, it changes the test name like this: ... -PASS: gdb.tui/empty.exp: src: 80x24: box 1 +PASS: gdb.tui/empty.exp: src: 80x24: {box 1} ... Fix this by dropping the "[list ...]". Likewise in gdb.tui/new-layout.exp. [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220863.html 2025-09-13 Indu Bhagat doc: sframe: add DRAFT marker for all outputs Add DRAFT marker to be emitted in the info, pdf and html outputs. This is done in two places: one in the @ifnottex block meant for PDF output and another in @titlepage block meant for info and html output. While at it, also add date to non-pdf outputs. The marker lines: @center @strong{*** DRAFT - NOT FOR DISTRIBUTION ***} should be removed before a release. libsframe/doc/ * sframe-spec.texi: Add marker for DRAFT. 2025-09-13 Simon Marchi gdb, gdbserver: fix typos Found by the codespell pre-commit hook. Change-Id: Iafadd9485ce334c069dc8dbdab88ac3fb5fba674 2025-09-13 GDB Administrator Automatic date update in version.in 2025-09-12 Ciaran Woodward gdb/tui: Fix build for older ncurses Older versions of ncurses (including the version that ships inside macos, and Centos 7) do not include the A_ITALIC macro. This patch simply hides any use of A_ITALIC behind a preprocessor guard. The result of this is that italics won't be rendered in the tui if ncurses isn't supported. We do have other options if we think it's important - for instance we could show italics as bold if italics aren't supported. From my understanding, that might be overthinking it - so I took the simplest approach here, just to fix the build. Those versions also define tgetnum as: int tgetnum(char *id); so attempting to compile for c++ results in the error: ISO C++ forbids converting a string constant to 'char*' [-Werror=write-strings] This is just a dated API issue, so a const cast resolves the issue. Approved-By: Tom Tromey 2025-09-12 Tom Tromey Fix 32-bit failure in array_long_idx.exp Testing on the AdaCore-internal equivalent to array_long_idx.exp showed that it failed on 32-bit targets. This patch fixes the problem by arranging to use types that aren't target-dependent. 2025-09-12 Andrew Burgess gdb: clear proceed status before starting a new inferior This patch fixes a bug when 'set schedule-multiple on' is in use and a second inferior is started using the 'run' command (or 'start' or 'starti'). This bug was reported as PR gdb/28777. The problem appears as the first inferior terminating with an unexpected SIGTRAP. The bug can be reproduced like this: gdb -ex 'set schedule-multiple on' \ -ex 'file /tmp/spin' \ -ex 'break main' \ -ex 'run' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file /tmp/spin' \ -ex 'break main' \ -ex 'run' The final 'run' can be replaced with 'start' or 'starti'. The output is different in the 'starti' case, but the cause is the same. For the 'run' and 'start' cases the final output is: Starting program: /tmp/spin Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists. In the 'starti' case the output is: Starting program: /tmp/spin Thread 2.1 "spin" stopped. Cannot remove breakpoints because program is no longer writable. Further execution is probably impossible. 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 What's happening is that GDB is failing to clear the previous proceed status from inferior 1 before starting inferior 2. Normally when schedule-multiple is off, this isn't a problem as 'run' only starts the new inferior, and the new inferior will have no previous proceed status that needs clearing. But when schedule-multiple is on, starting a new inferior, with 'run' and friends, will actually start all inferiors, including those that previous stopped at a breakpoint with a SIGTRAP signal. By failing to clear out the proceed status for those threads, when GDB restarts inferior 1 it arranges for the thread to receive the SIGTRAP, which is delivered, and, as GDB isn't expecting a SIGTRAP, is allowed to kill the process. Fix this by calling clear_proceed_status from run_command_1. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28777 2025-09-12 Andrew Burgess gdb: ensure thread state is updated when remote target starts up This patch fixes a bug that was exposed by a test added in the previous commit. After writing this patch I also discovered that this issue had been reported as PR gdb/27322. When 'maint set target-non-stop on' is in effect, then the remote targets will be running in non-stop mode. The previous commit revealed a bug where, in this mode, GDB can fail to copy the thread state from the target to the GDB frontend, this leaves the thread marked as running in the frontend, even though the thread is actually stopped. When this happens the user is no longer able to interrupt the thread (it's already stopped), nor can the user resume the thread (GDB thinks the threads is running). To reproduce the bug: gdb -q -ex 'maint set target-non-stop on' \ -ex 'set non-stop off' \ -ex 'set sysroot' \ -ex 'file /bin/ls' \ -ex 'run &' \ -ex 'add-inferior' \ -ex 'infer 2' \ -ex 'set sysroot' \ -ex 'target remote | gdbserver - ls' \ -ex 'info threads' The 'info threads' output will look something like: Id Target Id Frame 1.1 process 1746383 "ls" (running) * 2.1 Thread 1746389.1746389 "ls" 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 The thread 1.1 should be stopped. GDB is running in all-stop mode after all. The problem is that in remote_target::process_initial_stop_replies, there is a call to stop_all_threads, however, the changes in the thread state are never copied back to the GDB frontend. This leaves the threads stopped, but still marked running. Solve this by adding a scoped_finish_thread_state. This is similar to how scoped_finish_thread_state is used in run_command_1 when we start a new inferior running. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27322 2025-09-12 Andrew Burgess gdb: disable commit resumed in wait_for_inferior This patch proposes a fix for PR gdb/33147. The bug can be reproduced like this: gdb -q -ex 'file /bin/ls' \ -ex 'run &' \ -ex 'add-inferior' \ -ex 'infer 2' \ -ex 'set sysroot' \ -ex 'target remote | gdbserver - ls' Which will trigger an assertion failure: target.c:3760: internal-error: target_stop: Assertion `!proc_target->commit_resumed_state' failed. The problem is that target_stop is being called for a target when commit_resumed_state is true, the comment on process_stratum_target::commit_resumed_state is pretty clear: To simplify the implementation of targets, the following methods are guaranteed to be called with COMMIT_RESUMED_STATE set to false: - resume - stop - wait So clearly we're breaking a precondition of target_stop. In this example there are two target, the native target (inferior 1), and the remote target (inferior 2). It is the first, the native target, for which commit_resumed_state is set incorrectly. At the point target_stop is called looks like this: #11 0x00000000009a3c19 in target_stop (ptid=...) at ../../src/gdb/target.c:3760 #12 target_stop (ptid=...) at ../../src/gdb/target.c:3756 #13 0x00000000007042f2 in stop_all_threads (reason=, inf=) at ../../src/gdb/infrun.c:5739 #14 0x0000000000711d3a in wait_for_inferior (inf=0x2b90fd0) at ../../src/gdb/infrun.c:4412 #15 start_remote (from_tty=from_tty@entry=1) at ../../src/gdb/infrun.c:3829 #16 0x0000000000897014 in remote_target::start_remote_1 (this=this@entry=0x2c4a520, from_tty=from_tty@entry=1, extended_p=extended_p@entry=0) at ../../src/gdb/remote.c:5350 #17 0x00000000008976e7 in remote_target::start_remote (extended_p=0, from_tty=1, this=0x2c4a520) at ../../src/gdb/remote.c:5441 #18 remote_target::open_1 (name=, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:6312 #19 0x00000000009a815f in open_target (args=0x7fffffffa93c "| gdbserver - ls", from_tty=1, command=) at ../../src/gdb/target.c:838 For new inferiors commit_resumed_state starts set to false, for this reason, if we only start a remote inferior, then when wait_for_inferior is called commit_resumed_state will be false, and everything will work. Further, as target_stop is only called for running threads, if, when the remote inferior is started, all other threads (in other targets) are already stopped, then GDB will never need to call target_stop for the other targets, and so GDB will not notice that commit_resumed_state for those target is set to true. In this case though, as the first (native) inferior is left running in the background while the remote inferior is created, and because GDB is running in all-stop mode (so needs to stop all threads in all targets), then GDB does call target_stop for the other targets, and so spots that commit_resumed_state is not set correctly and asserts. The fix is to add scoped_disable_commit_resumed somewhere in the call stack. Initially I planned to add the scoped_disable_commit_resumed in `wait_for_inferior`, however, this isn't good enough. This location would solve the problem as described in the bug, but when writing the test I extended the problem to also cover non-stop mode, and this runs into a second problem, the same assertion, but triggered from a different call path. For this new case the stack looks like this: #1 0x0000000000fb0e50 in target_stop (ptid=...) at ../../src/gdb/target.c:3771 #2 0x0000000000a7f0ae in stop_all_threads (reason=0x1d0ff74 "remote connect in all-stop", inf=0x0) at ../../src/gdb/infrun.c:5756 #3 0x0000000000d9c028 in remote_target::process_initial_stop_replies (this=0x3e10670, from_tty=1) at ../../src/gdb/remote.c:5017 #4 0x0000000000d9cdf0 in remote_target::start_remote_1 (this=0x3e10670, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:5405 #5 0x0000000000d9d0d4 in remote_target::start_remote (this=0x3e10670, from_tty=1, extended_p=0) at ../../src/gdb/remote.c:5457 #6 0x0000000000d9e8ac in remote_target::open_1 (name=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1, extended_p=0) at ../../src/gdb/remote.c:6329 #7 0x0000000000d9d167 in remote_target::open (name=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1) at ../../src/gdb/remote.c:5479 #8 0x0000000000f9914d in open_target (args=0x7fffffffa931 "| gdbserver - /bin/ls", from_tty=1, command=0x35d1a40) at ../../src/gdb/target.c:838 So I'm now thinking that stop_all_threads would be the best place for the scoped_disable_commit_resumed. I did leave an assert in wait_for_inferior as, having thought about the assert some, I do still think the logic of it is true, and it doesn't hurt to leave it in place I think. However, it's not quite that simple, the test throws up yet another bug when we 'maint set target-non-stop on', but then 'set non-stop off'. This bug leaves a stopped thread marked as "(running)" in the 'info threads' output. I have a fix for this issue, but I'm leaving that for the next commit. For now I've just disabled part of the test in the problem case. I've also tagged this patch with PR gdb/27322. That bug was created before the above assert was added, but if you follow the steps to reproduce for that bug today you will hit the above assert. The actual issue described in PR gdb/27322 is fixed in the next patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27322 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33147 2025-09-12 Andrew Burgess gdb: ensure normal stop finishes the thread state of all threads This patch fixes a multi-target issue where the normal_stop function can fail to finish the thread state of threads from a non current target, this leaves the threads marked as running in GDB core, while the threads is actually stopped. For testing I used this test program: #include int main () { while (1) sleep (1); return 0; } Compile this to make '/tmp/spin', then the bug can be shown using this command: $ gdb -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'set sysroot' \ -ex 'target extended-remote | gdbserver --multi --once - /tmp/spin' \ -ex 'inferior 1' \ -ex 'continue&' \ -ex 'inferior 2' \ -ex 'search sleep' \ -ex 'break $_ inferior 2' \ -ex 'continue' \ -ex 'info threads' The interesting part of the output is: Id Target Id Frame 1.1 process 1610445 "spin" (running) * 2.1 Thread 1610451.1610451 "spin" main () at spin.c:7 (gdb) Notice that thread 1.1 is marked as running when it should be stopped. We can see that the thread is actually stopped if we try this: (gdb) inferior 1 [Switching to inferior 1 [process 1610445] (/tmp/spin)] [Switching to thread 1.1 (process 1610445)](running) (gdb) continue Cannot execute this command while the selected thread is running. (gdb) interrupt (gdb) info threads Id Target Id Frame * 1.1 process 1610445 "spin" (running) 2.1 Thread 1610451.1610451 "spin" main () at spin.c:7 (gdb) We can see the expected behaviour if both inferiors run on the same target, like this: $ gdb -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file /tmp/spin' \ -ex 'start' \ -ex 'inferior 1' \ -ex 'continue&' \ -ex 'inferior 2' \ -ex 'search sleep' \ -ex 'break $_ inferior 2' \ -ex 'continue' \ -ex 'info threads' The 'info threads' from this series of commands looks like this: Id Target Id Frame 1.1 process 1611589 "spin" 0x00007ffff7e951e7 in nanosleep () from /lib64/libc.so.6 * 2.1 process 1611593 "spin" main () at spin.c:7 (gdb) Now both threads are stopped as we'd expect. The problem is in normal_stop. The scoped_finish_thread_state uses user_visible_resume_target to select the target(s) over which GDB will iterate to find the threads to update. The problem with this is that when the ptid_t is minus_one_ptid, meaning all threads, user_visible_resume_target only returns nullptr, meaning all targets, when sched_multi is true. This dependency on sched_multi makes sense when _resuming_ threads. If we are resuming all threads, then when sched_multi (the schedule-multiple setting) is off (the default), all threads actually means all threads in the current inferior only. When sched_multi is true (schedule-multiple is on) then this means all threads, from all inferiors, which means GDB needs to consider every target. However, when stopping an inferior in all-stop mode (non_stop is false), then GDB wants to stop all threads from all inferiors, regardless of the sched_multi setting. What this means is that, when 'non_stop' is false, then we should be passing nullptr as the target selection to scoped_finish_thread_state. My proposal is that we should stop using user_visible_resume_target in the normal_stop function for the target selection of the scoped_finish_thread_state, instead we should manually figure out the correct target value and pass this in. There is precedent for this in GDB, see run_command_1, where 'finish_target' is calculated directly within the function rather than using user_visible_resume_target. After this commit, when using two different targets (native and remote) as in my first example above, both threads will be correctly stopped. 2025-09-12 Tom de Vries [gdb/testsuite] Remove use of then keyword some more Find uses of the then keyword: ... $ find gdb/testsuite/ -type f -name *.exp* | xargs grep "if.*then {" ... and remove them. See also commit d4c4542312c ("gdb/testsuite: remove use of then keyword from library files") and related commits. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.objc Running tclint on the test-cases in gdb.opt shows a problem. Fix it. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.opt Running tclint on the test-cases in gdb.opt shows a few problems. Fix these. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.pascal Running tclint on the test-cases in gdb.pascal shows a few problems. Fix these. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.rocm Running tclint on the test-cases in gdb.rocm shows a few problems: ... precise-memory-multi-inferiors.exp:33:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] precise-memory-multi-inferiors.exp:43:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] precise-memory-multi-inferiors.exp:55:5: expected braced word or word \ without substitutions in argument interpreted as expr [command-args] ... Fix these. The gdb.rocm test-cases are unsupported for me, so I can't test this. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.rust Running tclint on the test-cases in gdb.rust shows a few problems: ... modules.exp:37:1: expected braced word or word without substitutions in \ argument interpreted as expr [command-args] traits.exp:28:13: expected braced word or word without substitutions in \ argument interpreted as script [command-args] ... Fix these. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.server Running tclint on the test-cases in gdb.server shows a few problems: ... connect-with-no-symbol-file.exp:72:1: line has trailing whitespace \ [trailing-whitespace] exit-multiple-threads.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] extended-remote-restart.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] monitor-exit-quit.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] reconnect-ctrl-c.exp:54:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] server-exec-info.exp:24:1: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] stop-reply-no-thread.exp:73:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] /stop-reply-no-thread-multi.exp:81:5: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] ... Fix these. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix lib/tuiterm.exp Running tclint on lib/tuiterm.exp shows a few problems: ... $ tclint --ignore line-length gdb/testsuite/lib/tuiterm.exp tuiterm.exp:105:3: expression with substitutions should be enclosed by \ braces [unbraced-expr] tuiterm.exp:1576:28: unnecessary command substitution within expression \ [redundant-expr] tuiterm.exp:1582:25: unnecessary command substitution within expression \ [redundant-expr] ... Fix these. Tested on aarch64-linux. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.tui Running tclint on the test-cases in gdb.tui shows a few problems: ... $ ( cd gdb/testsuite/gdb.tui; tclint --ignore line-length *.exp ) compact-source.exp:58:28: expression with substitutions should be enclosed by \ braces [unbraced-expr] compact-source.exp:60:27: expression with substitutions should be enclosed by \ braces [unbraced-expr] compact-source.exp:68:32: expression with substitutions should be enclosed by \ braces [unbraced-expr] empty.exp:68:2: eval received an argument with a substitution, unable to \ parse its arguments [command-args] new-layout.exp:84:2: eval received an argument with a substitution, unable \ to parse its arguments [command-args] source-search.exp:33:25: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:40:21: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:44:14: expression with substitutions should be enclosed by \ braces [unbraced-expr] wrap-line.exp:62:40: expression with substitutions should be enclosed by \ braces [unbraced-expr] ... Fix these. Tested on aarch64-linux. 2025-09-12 Andrew Burgess gdb/gdbserver: pass inferior arguments as a single string GDB holds the inferior arguments as a single string. Currently when GDB needs to pass the inferior arguments to a remote target as part of a vRun packet, this is done by splitting the single argument string into its component arguments by calling gdb::remote_args::split, which uses the gdb_argv class to split the arguments for us. The same gdb_argv class is used when the user has asked GDB/gdbserver to start the inferior without first invoking a shell; the gdb_argv class is used to split the argument string into it component arguments, and each is passed as a separate argument to the execve call which spawns the inferior. There is however, a problem with using gdb_argv to split the arguments before passing them to a remote target. To understand this problem we must first understand how gdb_argv is used when invoking an inferior without a shell. And to understand how gdb_argv is used to start an inferior without a shell, I feel we need to first look at an example of starting an inferior with a shell. Consider these two cases: (a) (gdb) set args \$VAR (b) (gdb) set args $VAR When starting with a shell, in case (a) the user expects the inferior to receive a literal '$VAR' string as an argument, while in case (b) the user expects to see the shell expanded value of the variable $VAR. If the user does 'set startup-with-shell off', then in (a) GDB will strip the '\' while splitting the arguments, and the inferior will be passed a literal '$VAR'. In (b) there is no '\' to strip, so also in this case the inferior will receive a literal '$VAR', remember startup-with-shell is off, so there is no shell that can ever expand $VAR. Notice, that when startup-with-shell is off, we end up with a many to one mapping, both (a) and (b) result in the literal string $VAR being passed to the inferior. I think this is the correct behaviour in this case. However, as we use gdb_argv to split the remote arguments we have the same many to one mapping within the vRun packet. But the vRun packet will be used when startup-with-shell is both on and off. What this means is that when gdbserver receives a vRun packet containing '$VAR' it doesn't know if GDB actually had '$VAR', or if GDB had '\$VAR'. And this is a huge problem. We can address this by making the argument splitting for remote targets smarter, and I do have patches that try to do this in this series: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com That series was pretty long, and wasn't getting reviewed, so I'm pulling the individual patches out and posting them separately. This patch doesn't try to improve remote argument splitting. I think that splitting and then joining the arguments is a mistake which can only introduce problems. The patch in the above series which tries to make the splitting and joining "smarter" handles unquoted, single quoted, and double quoted strings. But that doesn't really address parameter substitution, command substitution, or arithmetic expansion. And even if we did try to address these cases, what rules exactly would we implement? Probably POSIX shell rules, but what if the remote target doesn't have a POSIX shell? The only reason we're talking about which shell rules to follow is because the splitting and joining logic needs to mirror those rules. If we stop splitting and joining then we no longer need to care about the target's shell. Clearly, for backward compatibility we need to maintain some degree of argument splitting and joining as we currently have; and that's why I have a later patch (see the series above) that tries to improve that splitting and joining a little. But I think, what we should really do, is add a new feature flag (as used by the qSupported packet) and, if GDB and the remote target agree, we should pass the inferior arguments as a single string. This solves all our problems. In the startup with shell case, we no longer need to worry about splitting at all. The arguments are passed unmodified to the remote target, that can then pass the arguments to the shell directly. In the 'startup-with-shell off' case it is now up to the remote target to split the arguments, though in gdbserver we already did this, so nothing really changes in this case. And if the remote target doesn't have a POSIX shell, well GDB just doesn't need to worry about it! Something similar to this was originally suggested in this series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ though this series didn't try to maintain backward compatibility, which I think is an issue that my patch solves. Additionally, this series only passed the arguments as a single string in some cases, I've simplified this so that, when GDB and the remote agree, the arguments are always passed as a single string. I think this is a little cleaner. I've also added documentation and some tests with this commit, including ensuring that we test both the new single string approach, and the fallback split/join approach. I've credited the author of the referenced series as co-author as they did come to a similar conclusion, though I think my implementation is different enough that I'm happy to list myself as primary author. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Co-Authored-By: Michael Weghorn Reviewed-By: Eli Zaretskii Tested-By: Guinevere Larsen Approved-by: Kevin Buettner 2025-09-12 Michael Weghorn gdb/gdbserver: add a '--no-escape-args' command line option This introduces a new '--no-escape-args' option for gdb and gdbserver. I (Andrew Burgess) have based this patch from work done in this series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ I have changed things slightly from the original series. I think this work is close enough that I've left the original author (Michael) in place and added myself as co-author. Any bugs introduced by my modifications to the original patch should be considered mine. I've also added documentation and tests which were missing from the originally proposed patch. When the startup-with-shell option is enabled, arguments passed directly as 'gdb --args ' or 'gdbserver ', are by default escaped so that they are passed to the inferior as passed on the command line, no globbing or variable substitution happens within the shell GDB uses to start the inferior. For gdbserver, this is the case since commit: commit bea571ebd78ee29cb94adf648fbcda1e109e1be6 Date: Mon May 25 11:39:43 2020 -0400 Use construct_inferior_arguments which handles special chars Only arguments set via 'set args ', 'run ', or through the Python API are not escaped in standard upstream GDB right now. For the 'gdb --args' case, directly setting unescaped args on gdb invocation is possible e.g. by using the "--eval-command='set args '", while this possibility does not exist for gdbserver. This commit adds a new '--no-escape-args' command line option for GDB and gdbserver. This option is used with GDB as a replacement for the current '--args' option, and for gdbserver this new option is a flag which changes how gdbserver handles inferior arguments on the command line. When '--no-escape-args' is used inferior arguments passed on the command line will not have escaping added by GDB or gdbserver. For gdbserver, using this new option allows having the behaviour from before commit bea571ebd78ee29cb94adf648fbcda1e109e1be6, while keeping the default behaviour unified between GDB and GDBserver. For GDB the --no-escape-args option can be used as a replacement for --args, like this: shell> gdb --no-escape-args my-program arg1 arg2 arg3 While for gdbserver, the --no-escape-args option is a flag, which can be used like: shell> gdbserver --no-escape-args --once localhost:54321 \ my-program arg1 arg2 arg3 Co-Authored-By: Andrew Burgess Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Reviewed-By: Eli Zaretskii Tested-By: Guinevere Larsen 2025-09-12 Rainer Orth libsframe: testsuite: Fix testsuite build on Solaris [PR33168] As reported in PR libsframe/33168, the libsframe tests don't build on Solaris. The failure is In file included from libsframe/testsuite/libsframe.decode/be-flipping.c:28: /usr/include/dejagnu.h:48:1: error: conflicting types for ‘wait’; have ‘void(void)’ 48 | wait (void) | ^~~~ In file included from /usr/include/stdlib.h:16, from libsframe/testsuite/libsframe.decode/be-flipping.c:21: /usr/include/sys/wait.h:85:14: note: previous declaration of ‘wait’ with type ‘pid_t(int *)’ {aka ‘long int(int *)’} 85 | extern pid_t wait(int *); | ^~~~ We have a combination of two factors here: * Solaris has and configure.ac predefines __EXTENSIONS__ due to the use of AC_USE_SYSTEM_EXTENSIONS. * This conflicts with 's definition void wait (void) { ... } While this version of wait was removed in upstream DejaGnu, the removal only happened after the latest release, 1.6.3. To avoid this, I've moved all testsuite includes into a new sframe-test.h, adding a workaround for the wait conflict. -Wall and -I$(srcdir) have been removed from AM_CPPFLAGS since they don't seem to be needed. To fix the Makefile fragment duplication, the local.mk files now use $(testsuite_LDADD) and $(testsuite_CPPFLAGS) throughout. Tested on {i386,amd64}-pc-solaris2.11, {sparc,sparcv9}-sun-solaris2.11, {x86_64,i686}-pc-linux-gnu, and amd64-pc-freebsd14.0. Coauthored-By: Alan Modra 2025-08-31 Rainer Orth Alan Modra libsframe: PR libsframe/33168 * testsuite/sframe-test.h: New file. * testsuite/libsframe.decode/be-flipping.c: Replace includes by sframe-test.h. * testsuite/libsframe.decode/frecnt-1.c: Likewise. * testsuite/libsframe.decode/frecnt-2.c: Likewise. * testsuite/libsframe.encode/encode-1.c: Likewise. * testsuite/libsframe.find/findfre-1.c: Likewise. * testsuite/libsframe.find/findfunc-1.c: Likewise. * testsuite/libsframe.find/plt-findfre-1.c: Likewise. * testsuite/libsframe.find/plt-findfre-2.c: Likewise. * Makefile.am (AM_CPPFLAGS): Remove -I$(srcdir). * Makefile.in: Regenerate. * testsuite/local.mk (testsuite_LDADD): New variable. (testsuite_CPPFLAGS): Likewise. * testsuite/libsframe.decode/local.mk: Use $(testsuite_LDADD), $(testsuite_CPPFLAGS). * testsuite/libsframe.encode/local.mk: Likewise. * testsuite/libsframe.find/local.mk: Likewise. 2025-09-12 Tom de Vries [gdb/testsuite, tclint] Fix gdb.testsuite Running tclint on the test-cases in gdb.testsuite shows a few problems: ... board-sanity.exp:47:38: line has trailing whitespace [trailing-whitespace] board-sanity.exp:83:1: line has trailing whitespace [trailing-whitespace] board-sanity.exp:95:38: line has trailing whitespace [trailing-whitespace] gdb-caching-proc-consistency.exp:66:2: expected braced word or word without \ substitutions in argument interpreted as expr [command-args] gdb-caching-proc-consistency.exp:117:12: eval received an argument with a \ substitution, unable to parse its arguments [command-args] with-override.exp:53:18: expression with substitutions should be enclosed by \ braces [unbraced-expr] with-override.exp:57:18: expression with substitutions should be enclosed by \ braces [unbraced-expr] ... Fix these. Tested on x86_64-linux. 2025-09-12 Tom de Vries [gdb/testsuite] Remove gdb.testsuite/lmap.exp Test-case gdb.testsuite/lmap.exp was added to test a local definition of lmap in lib/gdb.exp. That one has been removed in commit e447f3a122c ("Require Tcl 8.6.2"). Remove the unnecessary test-case. 2025-09-12 Nelson Chu RISC-V: Also, fixed more ld testcases for --with-arch and --with-abi Well these testcases cannot be fixed by .option norvc simply, that is because current linker needs to check mapping symbols before doing any rvc relaxations, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/393 Once we support the above features, we can revert this patch. 2025-09-12 Nelson Chu RISC-V: Fixed more testcases for --with-arch and --with-abi Same as cabae1c1c87d5f4ba28b7fdafe735b7c6207fb78 2025-09-12 GDB Administrator Automatic date update in version.in 2025-09-11 Tom Tromey Add Ada test case with long array indices This patch adds a test case to test that the previous two patches did their job. With the current gdb, this test fails: (gdb) print some_regular_access.all Value out of range. The bug here is that the array has an index type that is wider than 'int', which is perfectly acceptable in Ada. Note that this series doesn't quite go far enough: in Ada the index could be a 128-bit integer. This change would be more invasive; and in practice this doesn't really seem to come up much -- so I've deferred it. 2025-09-11 Tom Tromey Use LONGEST rather than int for array slices This patch started by removing the remaining calls to longest_to_int from ada-lang.c, then chasing down the callees to make sure they were also using LONGEST. This ended up with a small change to value_slice as well. Remove some uses of longest_to_int from ada-lang.c A few spots in ada-lang.c use longest_to_int -- but in a context where the value is immediately passed to a function accepting LONGEST. This patch removes the offending calls. It turned out to be easy to change find_struct_field as well, so I've included that in this patch. 2025-09-11 Tom de Vries [gdb/testsuite, tclint] Drop lreverse When running tclint with lib/future.exp, I get: ... $ tclint lib/future.exp $exp:756:5: redefinition of built-in command 'lreverse' [redefined-builtin] ... The code was added to handle pre-7.5 tcl versions without lreverse. Since we now require Tcl 8.6.2 (as per PR testsuite/33205), drop this. Tested by rerunning tclint. Approved-By: Simon Marchi PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403 2025-09-11 Tom de Vries [gdb/testsuite, tclint] Fix syntax error in gdb.base/dtrace-probe.exp When running tclint with gdb.base/dtrace-probe.exp I get: ... $ tclint gdb.base/dtrace-probe.exp $exp:67:45: syntax error: expected newline or semicolon, got ] ... due to these lines: ... 67 runto "-probe-dtrace test:two-locations"] 68 runto "-probe-dtrace test:two-locations"] ... Fix this by dropping the trailing ']'. Tested by rerunning tclint. Approved-By: Simon Marchi PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403 2025-09-11 Tom de Vries [gdb/testsuite, tclint] Fix unrecognized argument in gdb.trace/mi-traceframe-changed.exp When running tclint on gdb.trace/mi-traceframe-changed.exp, I get: ... $ tclint gdb.trace/mi-traceframe-changed.exp $exp:94:1: unrecognized argument for append: -1 [command-args] $exp:95:1: unrecognized argument for append: -1 [command-args] ... for these lines: ... 94 append testfile -1 95 append binfile -1 ... This seems harmless to me, but since tclint complains, fix this by quoting the -1 arguments. Tested by rerunning tclint. Approved-By: Simon Marchi PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403 2025-09-11 H.J. Lu x86: Copy non_got_ref_without_indirect_extern_access Copy non_got_ref_without_indirect_extern_access when copying indirect symbol for weak alias so that _bfd_x86_elf_adjust_dynamic_symbol will properly handle GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. bfd/ PR ld/33409 * elfxx-x86.c (_bfd_x86_elf_copy_indirect_symbol): Copy non_got_ref_without_indirect_extern_access. ld/ PR ld/33409 * testsuite/config/default.exp (NO_DIRECT_EXTERN_ACCESS_CFLAGS): New. * testsuite/ld-elf/shared.exp: Run PR ld/33409 tests. * testsuite/ld-elf/pr33409a.c: New file. * testsuite/ld-elf/pr33409b.c: Likewise. * testsuite/ld-elf/pr33409c.c: Likewise. 2025-09-11 H.J. Lu x86-64: Update R_X86_64_TPOFF32 error message Change R_X86_64_TPOFF32 error message from relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; replace local-exec with initial-exec TLS model to relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; local-exec is incompatible with -shared bfd/ PR ld/33408 * elf64-x86-64.c (elf_x86_64_need_pic): Suggest "replace local-exec with initial-exec TLS model" for R_X86_64_TPOFF32. ld/ PR ld/33408 * testsuite/ld-x86-64/tls-le-pic-1-x32.d: Updated. * testsuite/ld-x86-64/tls-le-pic-1.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.d: Likewise. 2025-09-11 Jiawei testsuite: RISC-V: Add '.option norvc' to ensure consistent results. Add `.option norvc` to several RISC-V tests to avoid compressed instruction generation. This ensures consistent disassembly and alignment behavior regardless of assembler default options. Discussion see: https://patchwork.sourceware.org/project/binutils/patch/20250910120916.1103023-1-jiawei@iscas.ac.cn/ gas/ChangeLog: * testsuite/gas/riscv/dis-partial-insn.s: Limit compressed. * testsuite/gas/riscv/no-relax-align.s: Ditto. * testsuite/gas/riscv/odd-padding.s: Ditto. * testsuite/gas/riscv/t_insns.s: Ditto. * testsuite/gas/riscv/tlsdesc.s: Ditto. 2025-09-11 Nelson Chu RISC-V: Remove ^M for odd-padding.s testcase 2025-09-11 Kevin Buettner Fix unwinding when restoring a register from one of a greater size When debugging functions where a callee-saved register is moved to a register of a larger size (e.g., a 64-bit general-purpose register to a 128-bit vector register), GDB would crash when the user issued the "return" command. For example: ldgr %f0, %r11 ; Move 64-bit general-purpose register (r11) ; to 128-bit vector register (f0) .cfi_register r11, f0 ; DW_CFA_register: r11 is stored in f0 ... lgdr %r11, %f0 ; Restore r11 from f0 .cfi_restore r11 ; DW_CFA_restore: r11 is restored to its original ; register (This example uses instructions and registers for the S390x architecture, where this bug was originally found.) If GDB is stopped in the "..." section and the user issues the "return" command, GDB crashes due to a buffer size mismatch during unwinding. Specifically, in frame_register_unwind in frame.c, a buffer the size of the original register (the 64-bit r11 in this example) has been allocated and GDB would like to use memcpy to copy the contents of the register where the original register was saved (the 128-bit f0) to the buffer for the original register. But, fortunately, GDB has an assertion which prevents this from happening: gdb_assert (buffer.size () >= value->type ()->length ()); This patch ensures that GDB uses the original register's type (e.g., r11's type) when unwinding, even if it was marked as saved to a differently typed/sized register (e.g., f0) via .cfi_register (DW_CFA_register). The fix adds a 'struct type *' parameter to value_of_register_lazy() to explicitly track the original register's type. The function frame_unwind_got_register is updated to pass the correct type for the original register. The call chain from frame_register_unwind to frame_unwind_got_register is shown by this backtrace: #0 frame_unwind_got_register (frame=..., regnum=13, new_regnum=128) at gdb/frame-unwind.c:300 #1 0x000000000135d894 in dwarf2_frame_prev_register (this_frame=..., this_cache=0x2204528, regnum=13) at gdb/dwarf2/frame.c:1187 #2 0x00000000014d9186 in frame_unwind_legacy::prev_register ( this=0x211f428 , this_frame=..., this_prologue_cache=0x2204528, regnum=13) at gdb/frame-unwind.c:401 #3 0x00000000014e1d12 in frame_unwind_register_value (next_frame=..., regnum=13) at gdb/frame.c:1263 #4 0x00000000014e16b8 in frame_register_unwind (next_frame=..., regnum=13, optimizedp=0x3ffffff813c, unavailablep=0x3ffffff8138, lvalp=0x3ffffff8134, addrp=0x3ffffff8128, realnump=0x3ffffff8124, buffer=...) at gdb/frame.c:1189 The register numbers shown above are for s390x. On s390x, S390_R11_REGNUM has value 13. Vector registers (like f0) are numbered differently from floating-point registers of the same name, leading to regnum 128 for f0 despite S390_F0_REGNUM being assigned a different value in s390-tdep.h. New test cases for aarch64 and x86_64 check for this on more popular architectures and also without dependency on a particular compiler to generate an unusual prologue in which a general purpose register is being moved to a vector register. In both cases, the test simulates the bug found on s390x where a 64-bit frame pointer was being moved to a much wider vector register. These test cases will cause an internal error on their respective architecture, but will pass with this fix in place. When tested on s390x linux (native), this change fixes 59 GDB internal errors and around 200 failures overall. This is the list of internal errors that no longer occur on s390x: FAIL: gdb.base/call-sc.exp: tc: return foo; return call-sc-tc (GDB internal error) FAIL: gdb.base/call-sc.exp: td: return foo; return call-sc-td (GDB internal error) FAIL: gdb.base/call-sc.exp: te: return foo; return call-sc-te (GDB internal error) FAIL: gdb.base/call-sc.exp: tf: return foo; return call-sc-tf (GDB internal error) FAIL: gdb.base/call-sc.exp: ti: return foo; return call-sc-ti (GDB internal error) FAIL: gdb.base/call-sc.exp: tl: return foo; return call-sc-tl (GDB internal error) FAIL: gdb.base/call-sc.exp: tld: return foo; return call-sc-tld (GDB internal error) FAIL: gdb.base/call-sc.exp: tll: return foo; return call-sc-tll (GDB internal error) FAIL: gdb.base/call-sc.exp: ts: return foo; return call-sc-ts (GDB internal error) FAIL: gdb.base/gnu_vector.exp: return from vector-valued function (GDB internal error) FAIL: gdb.base/return-3.exp: in foo: return (GDB internal error) FAIL: gdb.base/return-nodebug.exp: double: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: float: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: int: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: long-long: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: long: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: short: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return-nodebug.exp: signed-char: return from function with no debug info with a cast (GDB internal error) FAIL: gdb.base/return.exp: return value 5 (GDB internal error) FAIL: gdb.base/return.exp: return value 5.0 (GDB internal error) FAIL: gdb.base/return2.exp: return from char_func (GDB internal error) FAIL: gdb.base/return2.exp: return from double_func (GDB internal error) FAIL: gdb.base/return2.exp: return from float_func (GDB internal error) FAIL: gdb.base/return2.exp: return from int_func (GDB internal error) FAIL: gdb.base/return2.exp: return from long_func (GDB internal error) FAIL: gdb.base/return2.exp: return from long_long_func (GDB internal error) FAIL: gdb.base/return2.exp: return from short_func (GDB internal error) FAIL: gdb.base/return2.exp: return from void_func (GDB internal error) FAIL: gdb.base/sigstep.exp: return from handleri: leave handler (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-ti: return foo; return 2 structs-tc-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-tl: return foo; return 2 structs-tc-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tc-ts: return foo; return 2 structs-tc-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 1 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 2 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 3 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 4 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 5 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 6 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 7 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tc: return foo; return 8 structs-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=td-tf: return foo; return 2 structs-td-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=td: return foo; return 1 structs-td (GDB internal error) FAIL: gdb.base/structs.exp: types=tf-tc: return foo; return 2 structs-tf-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tf-td: return foo; return 2 structs-tf-td (GDB internal error) FAIL: gdb.base/structs.exp: types=tf: return foo; return 1 structs-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=tf: return foo; return 2 structs-tf (GDB internal error) FAIL: gdb.base/structs.exp: types=ti-tc: return foo; return 2 structs-ti-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=ti: return foo; return 1 structs-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=ti: return foo; return 2 structs-ti (GDB internal error) FAIL: gdb.base/structs.exp: types=tl-tc: return foo; return 2 structs-tl-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=tl: return foo; return 1 structs-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tl: return foo; return 2 structs-tl (GDB internal error) FAIL: gdb.base/structs.exp: types=tld: return foo; return 1 structs-tld (GDB internal error) FAIL: gdb.base/structs.exp: types=tll: return foo; return 1 structs-tll (GDB internal error) FAIL: gdb.base/structs.exp: types=ts-tc: return foo; return 2 structs-ts-tc (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo; return 1 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo; return 2 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo; return 3 structs-ts (GDB internal error) FAIL: gdb.base/structs.exp: types=ts: return foo; return 4 structs-ts (GDB internal error) I have tested this commit on Fedora Linux, with architectures s390x, x86_64, x86_64/-m32, aarch64, ppc64le, and riscv64, with no regressions found. This v2 version makes some changes suggested by Andrew Burgess: It adds an assert to frame_unwind_got_register() and always passes the type of REGNUM to value_of_register_lazy(). It also updates value.h's comment describing value_of_register_lazy(). In his approval message, Andrew requested some changes to the tests. Those have been made exactly as requested. Approved-By: Andrew Burgess 2025-09-11 GDB Administrator Automatic date update in version.in 2025-09-10 Tom Tromey Rename expand_symtabs_matching After this series, expand_symtabs_matching is now misnamed. This patch renames it, renames some associated types, and also fixes up some comments that I previously missed. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Remove enter_symbol_lookup The "enter_symbol_lookup" class was introduced to work around the lack of reentrancy in symbol lookup. There were two problems here: 1. The DWARF reader kept a mark bit on the dwarf2_per_cu_data object. This bit is gone now, replaced with a local mark vector. 2. Some spots in gdb first examined the expanded symbol tables, and then on failure expanded some symtabs and searched the newly expanded ones (skipping previousy-expanded ones). Fixing this has been the main point of this series. Now that both of these barriers are gone, I think enter_symbol_lookup can be removed. One proof of this idea is that, without the first fix mentioned above, py-symbol.exp regressed because gdbpy_lookup_static_symbols did not first ensure that the current language was set -- i.e., there was a latent bug in the enter_symbol_lookup patch anyway. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Make dw_expand_symtabs_matching_file_matcher static dw_expand_symtabs_matching_file_matcher is no longer needed outside of read.c, so it can be made static. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert lookup_symbol_in_objfile This converts lookup_symbol_in_objfile to the callback approach by removing the call to lookup_symbol_in_objfile_symtabs. (The latter is not removed as there are still other callers.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert lookup_symbol_via_quick_fns This converts lookup_symbol_via_quick_fns to the callback approach, merging the search loop and the call to expand_symtabs_matching. Note that this changes lookup_symbol_via_quick_fns to use a best_symbol_tracker. Before this patch there was a discrepancy here between the two search functions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Add best_symbol_tracker This adds a new best_symbol_tracker struct. This is used to implement the "best symbol" logic that is used sometimes in symtab.c. This approach makes it simpler and more efficient to track the "best" symbol when searching across multiple blocks. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Simplify block_lookup_symbol One loop in block_lookup_symbol is identical to the code in block_lookup_symbol_primary. This patch simplifies the former by having it call the latter. This removes an assert. However, note that the assert is not needed -- it does not check any invariant that must be maintained. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Pass lookup_name_info to block_lookup_symbol_primary This changes block_lookup_symbol_primary to accept a lookup_name_info. This follows the general trend of hoisting these objects to the outermost layer where they make sense -- somewhat reducing the cost of using them. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Simplify block_lookup_symbol_primary This simplifies block_lookup_symbol_primary by using block_iterator_range. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert linespec.c:iterate_over_all_matching_symtabs This converts linespec.c:iterate_over_all_matching_symtabs to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Remove objfile::expand_symtabs_for_function objfile::expand_symtabs_for_function only has a single caller now, so it can be removed. This also allows us to merge the expansion and searching phases, as done in other patches in this series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Simplify basic_lookup_transparent_type This patch changes basic_lookup_transparent_type to always work via the "quick" API -- that is, no separate search of the already-expanded symtabs is needed. This is more efficient when many CUs have already been expanded. It also makes the lookup more consistent, as the result is no longer dependent on the order in which CUs were previously expanded. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Remove expand_symtabs_matching The last caller of the global expand_symtabs_matching function has been changed, so now we can remove this function. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert ada-lang.c:map_matching_symbols This converts ada-lang.c:map_matching_symbols to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert ada_language_defn::collect_symbol_completion_matches This converts ada_language_defn::collect_symbol_completion_matches to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert ada_add_global_exceptions This converts ada_add_global_exceptions to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert gdbpy_lookup_static_symbols This changes gdbpy_lookup_static_symbols to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Convert default_collect_symbol_completion_matches_break_on This converts default_collect_symbol_completion_matches_break_on to the callback approach, merging the search loop and the call to expand_symtabs_matching. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Rewrite the .gdb_index reader This patch rewrites the .gdb_index reader to create the same data structures that are created by the cooked indexer and the .debug_names reader. This is done in support of this series; but also because, from what I can tell, the "templates.exp" change didn't really work properly with this reader. In addition to fixing that problem, this patch removes a lot of code. Implementing this required a couple of hacks, as .gdb_index does not contain all the information that's used by the cooked index implementation. * The index-searching code likes to differentiate between the various DWARF tags when matching, but .gdb_index lumps many things into a single "other" category. To handle this, we introduce a phony tag that's used so that the match method can match on multiple domains. * Similarly, .gdb_index doesn't distinguish between the type and struct domains, so another phony tag is used for this. * The reader must attempt to guess the language of various symbols. This is somewhat finicky. "Plain" (unqualified) symbols are marked as language_unknown and then a couple of hacks are used to handle these -- one in expand_symtabs_matching and another when recognizing "main". For what it's worth, I consider .gdb_index to be near the end of its life. While .debug_names is not perfect -- we found a number of bugs in the standard while implementing it -- it is better than .gdb_index and also better documented. After this patch, we could conceivably remove dwarf_scanner_base. However, I have not done this. Finally, this patch also changes this reader to dump the content of the index, as the other DWARF readers do. This can be handy when debugging gdb. Acked-By: Simon Marchi Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33316 2025-09-10 Tom Tromey Have expand_symtabs_matching work for already-expanded CUs Currently, gdb will search the already-expanded symtabs in one loop, and then also expand matching symtabs in another loop. However, this is somewhat inefficient -- when searching the already-expanded symtabs, all such symtabs are examined. However, the various "quick" implementations already know which subset of symtabs might have a match. This changes the contract of expand_symtabs_matching to also call the callback for an already-expanded symtab. With this change, and some subsequent enabling changes, the number of searched symtabs should sometimes be reduced. This also cuts down on the amount of redundant code. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30736 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Remove dwarf2_per_cu_data::mark This removes dwarf2_per_cu_data::mark, replacing it with a locally-allocated boolean vector. It also inverts the sense of the flag -- now, the flag is true when a CU should be skipped, and false when the CU should be further examined. Also, the validity of the flag is no longer dependent on 'file_matcher != NULL'. This patch makes the subsequent patch to searching a bit simpler, so I've separated it out. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16994 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16998 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Entries from anon-struct.exp not in cooked index g++ will sometimes use a typedef to give a name to an otherwise anonymous type for linkage purposes. gdb tries to handle this odd scenario, which is enforced by anon-struct.exp. It's difficult to detect this problem in the current tree, but the cooked index does not include an entry for these DIEs. This patch changes gdb to add these to the index. This is needed by subsequent changes in this series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32519 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Restore "ingestion" of .debug_str when writing .debug_names When I rewrote the .debug_names writer (commit 91a42a61), I changed the writer to not import .debug_str into the debug_str_lookup object. However, a later patch in this series needed this again. The issue here was that if a name occurs in the DWARF, and is also allocated, then there is a race, where the created index depends on which DIE is read first. This can cause index-file.exp failures. This patch restores the old approach, avoiding this problem. I also applied a couple of small cleanups to the class. And, I removed the old complaint from the "ingestion" function, as this was not necessary. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Put all CTF symbols in global scope The new approach to searching (solely via the quick API) is more sensitive to discrepancies between the partial and full readers. In CTF, there is some disagreement about which scope to use. CTF doesn't seem to really distinguish between the file and global scope, so this patch takes the simple approach of putting all CTF symbols into the global scope. This changes one test as well. It seems to me that the behavior here is arbitrary and the test is making unwarranted assumptions. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Fix index's handling of DW_TAG_imported_declaration Currently the full symbol reader puts DW_TAG_imported_declaration in TYPE_DOMAIN, in the global scope. This patch changes the cooked indexer to follow. Without this patch, a later patch in the series would cause nsalias.exp to regress. This also updates read-gdb-index.c to do something similar. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Ada import functions not in index The cooked index does not currently contain entries for Ada import functions. This means that whether or not these are visible to "break" depends on which CUs were previously expanded -- clearly a bug. This patch fixes the issue. I think the comments in the patch explain the fix reasonably well. Perhaps one to-do item here is to change GNAT to use DW_TAG_imported_declaration for these imports. This may eventually let us remove some of the current hacks. This version includes a fix from Simon to initialize the new member. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32511 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Emit some type declarations in .gdb_index If you run struct-decl.exp with the .gdb_index board, you will see that "the_type" is not emitted in the index. This would cause a failure in this series. The fix is to ensure that certain necessary type declarations are emitted. However, a naive fix here will regress stub-array-size.exp, where a type declaration and a type definition are both seen -- but the declaration is seen first and causes a failure. This is handled by adding some code (including a mild hack) to filter out type declarations when a corresponding type definition is seen. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Change ada_decode to preserve upper-case in some situations This patch is needed to avoid regressions later in the series. The issue here is that ada_decode, when called with wide=false, would act as though the input needed verbatim quoting. That would happen because the 'W' character would be passed through; and then a later loop would reject the result due to that character. Similarly, with operators=false the upper-case-checking loop would be skipped, but then some names that did need verbatim quoting would pass through. Furthermore I noticed that there isn't a need to distinguish between the "wide" and "operators" cases -- all callers pass identical values to both. This patch cleans up the above, consolidating the parameters and changing how upper-case detection is handled, so that both the operator and wide cases pass-through without issue. I've added new unit tests for this. Acked-By: Simon Marchi 2025-09-10 Tom Tromey Add another minor hack to cooked_index_entry::full_name This patch adds another minor hack to cooked_index_entry::full_name. In particular, if GNAT emits non-hierarchical names (still the default as the hierarchical series is blocked on one tricky problem), then a request to compute the "linkage-style" name will now just return the 'name' field. Without this tweak, this series would regress ada-cold-name.exp, because the search would look for "name.cold" but the index would return "name[cold]" as the "linkage" name (which would be wrong). This area is a bit difficult to unravel. The best plan here, IMO, is to change Ada to work like the other languages in gdb: store the natural name and do searches with that name. I think this is achievable, but I didn't want to try it here. I've updated the relevant bug (tagged below) to reflect this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32766 Acked-By: Simon Marchi 2025-09-10 Tom Tromey Skip some tests with "readnow" board This series pointed out a few tests that check that a particular index is in use. It seems to me that this does not really make sense when the "readnow" board is in use, as this actually skips index creation. The tests do pass today, but by accident. This patch adds the appropriate "require" line to the tests in question. Approved-By: Simon Marchi Acked-By: Simon Marchi 2025-09-10 Tom Tromey Remove support for .gdb_index < 7 This patch removes support for .gdb_index versions less than 7. See the patch that rewrites the reader to understand why this is needed. Approved-By: Simon Marchi Reviewed-By: Eli Zaretskii Acked-By: Simon Marchi 2025-09-10 Indu Bhagat gas: sframe: skip DW_CFA_GNU_args_size when safe to ignore Currently, gas warns and skips generating SFrame FDE when it sees: .cfi_escape 0x2e,XX From the documentation of DW_CFA_GNU_args_size: "The DW_CFA_GNU_args_size instruction takes an unsigned LEB128 operand representing an argument size. This instruction specifies the total of the size of the arguments which have been pushed onto the stack." With origins seemingly for VAX architecture, the usage of DW_CFA_GNU_args_size seems to have evolved. The purpose of DW_CFA_GNU_args_size is to adjust SP when performing stack unwinding for exception handling. For the purpose of stack tracing using SFrame, DW_CFA_GNU_args_size is safe to skip, especially when the CFA restoration is known to be FP based. A previous summary of the reasoning and intent was indicated here [1]. [1] https://sourceware.org/pipermail/binutils/2025-August/143829.html This fixes PR gas/33414 - sframe: handle DW_CFA_GNU_args_size in gas better gas/ PR gas/33414 * gen-sframe.c (sframe_xlate_do_escape_gnu_args_size): New definition. (sframe_xlate_do_cfi_escape): Handle DW_CFA_GNU_args_size. gas/testsuite/ PR gas/33414 * gas/cfi-sframe/cfi-sframe.exp: New test. * gas/cfi-sframe/cfi-sframe-common-12.d: New test. * gas/cfi-sframe/cfi-sframe-common-12.s: New test. * gas/cfi-sframe/cfi-sframe-x86_64-3.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-3.s: New test. 2025-09-10 Tom Tromey Fix var_arr_typedef.exp to preserve local variable This patch fixes var_arr_typedef.exp to preserve a local variable a bit better, protecting it from a gnat-llvm optimization. 2025-09-10 H.J. Lu x86-64: Fix misleading R_X86_64_TPOFF32 error message R_X86_64_TPOFF32 relocation of local-exec TLS model can only be used in executable, not in a shared library, even if the source code is compiled with -fPIC. Change the linker error message from relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC to relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; replace local-exec with initial-exec TLS model bfd/ PR ld/33408 * elf64-x86-64.c (elf_x86_64_need_pic): Suggest "replace local-exec with initial-exec TLS model" for R_X86_64_TPOFF32. (elf_x86_64_scan_relocs): Drop ABI_64_P check for R_X86_64_TPOFF32. ld/ PR ld/33408 * testsuite/ld-x86-64/tls-le-pic-1-x32.d: New file. * testsuite/ld-x86-64/tls-le-pic-1.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-1.s: Likewise. * testsuite/ld-x86-64/tls-le-pic-2-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-2.s: Likewise. * testsuite/ld-x86-64/tls-le-pic-3-x32.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.d: Likewise. * testsuite/ld-x86-64/tls-le-pic-3.s: Likewise. 2025-09-10 Matthieu Longo ld: fix segfault when linker script is not found ld previously crashed with a segmentation fault if the specified linker script could not be found. The issue seems to have been introduced recently by d048eee2910 [1]. This patch adds a check to ensure that a filename was found after searching the possible prefixes. If no filename was found, the function returns NULL, and ldfile_open_command_file_1() emits a proper fatal error message. This change prevents the crash and provides a clear diagnostic. A new generic test was also added to cover this error case. [1]: https://inbox.sourceware.org/binutils/20250812143757.3565482-1-hjl .tools@gmail.com/ 2025-09-10 H.J. Lu Revert "binutils: Require GNU tail for 'objdump -Wi' test" This reverts commit 897d8d7bba581e4c1614af5712b730b006f03407. 2025-09-10 H.J. Lu x86: Correct _bfd_x86_elf_copy_indirect_symbol comments Since commit eeb2f20a764bee3a6a1edb9872467d044aaad848 Author: H.J. Lu Date: Fri Sep 1 13:03:40 2017 -0700 x86: Add _bfd_x86_elf_adjust_dynamic_symbol replaced elf_i386_adjust_dynamic_symbol with _bfd_x86_elf_copy_indirect_symbol, correct the comments. * elfxx-x86.c (_bfd_x86_elf_copy_indirect_symbol): Replace elf_i386_adjust_dynamic_symbol with _bfd_x86_elf_copy_indirect_symbol in comments. 2025-09-10 Gopi Kumar Bulusu MicroBlaze: Update gdb/NEWS for GNU/Linux gdbserver target * gdb/NEWS : Add MicroBlaze gdbserver target Approved-by: Michael J. Eager 2025-09-10 Gopi Kumar Bulusu MicroBlaze: Update software breakpoint machine code as per MicroBlaze ISA This patch updates breakpoint instruction machine code to be inline with the specification in MicroBlaze ISA [1] * gdb/microblaze-tdep.h : Update MICROBLAZE_BREAKPOINT [1] https://docs.amd.com/r/en-US/ug984-vivado-microblaze-ref/brki 2025-09-10 Tom Tromey Change type_stack::insert to take gdbarch This changes type_stack::insert to take a gdbarch rather than an expr_builder. This is simpler and means that type_stack doesn't have to know anything about expression building; the parser-defs.h include can be removed. Approved-By: Simon Marchi 2025-09-10 Tom Tromey Make type_stack popping a bit safer This changes type_stack so that an element that has an argument can't be popped in isolation. The idea is to make type stack use a little safer, making it so that the stack can't end up in an invalid state. This also fixes up a few related comments. Approved-By: Simon Marchi 2025-09-10 Tom Tromey Make type_stack pushing a bit safer This changes type_stack to make pushing elements a bit safer: if an element requires an argument, these are now always pushed at the same time, rather than separately. This patch also adds a few comments to help document a bit better. Approved-By: Simon Marchi 2025-09-10 GDB Administrator Automatic date update in version.in 2025-09-09 Alan Modra readelf: tidy dump_relr_relocations A comment in display_relocations said "RELRS has been freed by dump_relr_relocations". Except that hadn't happened on all return paths. Tidy that by freeing relrs allocated in dump_relr_relocations in that function, and relrs allocated in display_relocation in that function. * readelf.c (dump_relr_relocations): Only free relrs allocated in this function. (display_relocations): Free relrs here, on error return paths too. 2025-09-09 Hannes Domani Fix gdb.Value.dynamic_type attribute gdb currently crashes if you try to get the dynamic_type from a gdb.Value of a POD struct: (gdb) py print(gdb.parse_and_eval('pod').dynamic_type) Fatal signal: Segmentation fault It happens because value_rtti_type() returns NULL for them, and this is not handled correctly. Fixed by using val->type() as a fallback in this case. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Use gnulib c-ctype module in gdb PR ada/33217 points out that gdb incorrectly calls the functions. In particular, gdb feels free to pass a 'char' like: char *str = ...; ... isdigit (*str) This is incorrect as isdigit only accepts EOF and values that can be represented as 'unsigned char' -- that is, a cast is needed here to avoid undefined behavior when 'char' is signed and a character in the string might be sign-extended. (As an aside, I think this API seems obviously bad, but unfortunately this is what the standard says, and some systems check this.) Rather than adding casts everywhere, this changes all the code in gdb that uses any API to instead call the corresponding c-ctype function. Now, c-ctype has some limitations compared to . It works as if the C locale is in effect, so in theory some non-ASCII characters may be misclassified. This would only affect a subset of character sets, though, and in most places I think ASCII is sufficient -- for example the many places in gdb that check for whitespace. Furthermore, in practice most users are using UTF-8-based locales, where these functions aren't really informative for non-ASCII characters anyway; see the existing workarounds in gdb/c-support.h. Note that safe-ctype.h cannot be used because it causes conflicts with readline.h. And, we canot poison the identifiers as this provokes errors from some libstdc++ headers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi 2025-09-09 Tom Tromey Use c-ctype.h (not safe-ctype.h) in gdb This changes gdb and related programs to use the gnulib c-ctype code rather than safe-ctype.h. The gdb-safe-ctype.h header is removed. This changes common-defs.h to include the c-ctype header, making it available everywhere in gdb. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi 2025-09-09 Tom Tromey Import the c-ctype module from gnulib This arranges to import the c-ctype module from gnulib. c-ctype is similar ot safe-ctype, but doesn't poison the APIs. This patch should not result in any functional changes, as nothing includes the new header yet. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi 2025-09-09 Guinevere Larsen gdb: fix build with newest clang The upstream build of GDB can fail on fedora rawhide, since the self check in regcache.c uses an unitialized variable to be compared, which now generates the following warning: binutils-gdb/gdb/regcache.c:1847:42: error: variable 'buf' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 1847 | SELF_CHECK (regcache->raw_compare (0, &buf, register_size (inf.arch (), 0))); This commit fixes that by initializing the variable to 0. Since the comment above that line would be changed, it was also reformatted so that it doesn't go beyond 80 columns. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Remove ada_binop_in_bounds ada_binop_in_bounds can be merged with its sole caller. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Remove ada_ternop_slice ada_ternop_slice can be merged with its sole caller. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Remove ada_equal_binop ada_equal_binop can be merged with its sole caller. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Remove ada_unop_in_range ada_unop_in_range can be merged with its sole caller. This change points out that one of the arguments was not needed. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Use ada_fvar_tracking in finish-var-size.exp commit a16f37e8 changed finish-var-size.exp to use have_fvar_tracking. However, in Ada tests, ada_fvar_tracking must be used instead. 2025-09-09 Andrew C Aitchison Correct -Ue output for nm, objdump and readelf ..., like PR33360 does for strings. 2025-09-09 Dmitry Klochkov nm: fix treating an ifunc symbol as a stab if '--ifunc-chars=--' is given If an ifunc symbol is processed in print_symbol(), a 'type' field of a 'syminfo' structure is set to any character specified by a user with an '--ifunc-chars' option. But afterwards the 'type' field is used to check whether a symbol is a stab in print_symbol_info_{bsd,sysv}() functions in order to print additional stab related data. If the 'type' field equals '-', a symbol is treated as a stab. If '--ifunc-chars=--' is given, all ifunc symbols will be treated as stab symbols and uninitialized stab related fields of the 'syminfo' structure will be printed which can lead to segmentation fault. To fix this, check if a symbol is a stab before override the 'type' field. Also, add a test case for this fix. PR binutils/32556 * nm.c (extended_symbol_info): Add is_stab. (print_symbol): Check if a symbol is a stab. (print_symbol_info_bsd): Use info->is_stab. (print_symbol_info_sysv): Use info->is_stab. * testsuite/binutils-all/nm.exp: Test nm --ifunc-chars=--. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32556 Fixes: e6f6aa8d184 ("Add option to nm to change the characters displayed for ifunc symbols") 2025-09-09 Alan Modra PR 33406 SEGV in dump_dwarf_section Trying to dump .sframe in a PE file results in a segfault accessing elf_section_data. * objdump (dump_sframe_section, dump_dwarf_section): Don't access elf_section_type without first checking the file is ELF. 2025-09-09 Nick Clifton objcopy: when an invalid bfd target string is used as a target option, print an error message that references the target string, not the file being copied 2025-09-09 Alan Modra objdump gcc_compiled and gcc2_compiled * objdump.c (remove_useless_symbols): Deal with gcc_compiled and gcc2_compiled here.. (compare_symbols): ..rather than here.. (disassemble_section): ..and here. Revert "objdump: Check the SEC_CODE bit for code" PR 33389 This reverts commit 6b27a220321ecead5435b170f1db02f1876cee08. 2025-09-09 Tom Tromey Change dwarf_record_line_1 to be a method This changes dwarf_record_line_1 to be a method of lnp_state_machine, simplifying it a bit. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Change dwarf_finish_line to be a method This changes dwarf_finish_line to be a method of lnp_state_machine, simplifying it a bit. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Add m_builder member to lnp_state_machine I noticed that several spots in lnp_state_machine fetch the CU's builder. Since this can't change over the lifetime of the object, it seemed nicer to simply cache it. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Change dwarf_record_line_p to be a method This changes dwarf_record_line_p to be a method of lnp_state_machine. This simplifies it, as it can refer to members of the object. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Boolify line-program.c This changes some code in line-program.c to use bool rather than int. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Move compute_include_file_name earlier I noticed that the compute_include_file_name intro comment was slightly wrong, and while looking at this, I also noticed that it has a single caller. This patch hoists it slightly so that a forward declaration isn't needed. Approved-By: Simon Marchi 2025-09-09 Tom Tromey Move lnp_state_machine to new file This patch moves lnp_state_machine and some supporting code to a new file, dwarf2/line-program.c. The main benefit of this is shrinking dwarf2/read.c a bit. Approved-By: Simon Marchi 2025-09-09 GDB Administrator Automatic date update in version.in 2025-09-08 Tom Tromey Use type-specific lookups in cp-support.c cp-support.c has code to substitute types for typedef names when canonicalizing a C++ name. I believe this code can use type-specific search domains; and doing this greatly speeds up some cases. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33081 2025-09-08 Tom Tromey Avoid symbol lookup for field names in C parser Currently, the C parser looks up any name it finds -- at lex time. However, in an expression like "obj->field", looking up the field name is wasteful, and can sometimes even yield pathological symtab expansion behavior. This patch arranges to avoid the name lookup in this case. (It would be nice to really clean up this area, but I'm not convinced it can readily be done in a yacc parser.) Some special code is required for the C++ construct where a qualified name is used, like "obj->type1::type2::field". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33081 2025-09-08 Tom Tromey Change how C parser looks up type tag names In an earlier version of this series, Simon noticed that something like "ptype struct type" was much slower. The deep problem here is the hack in best_symbol -- in this particular case the C parser is including SEARCH_VAR_DOMAIN, which means that a type is not "best". Fixing best_symbol would be good to do, but it's difficult and I already had many struggles getting this series to this point. So, rather than fix that, I elected to modify the parser. The key insight here is that the name lookup in classify_name is useless when a tag name is expected. This patch adds a flag so that this lookup is not done. (Incidentally, this kind of thing is much more straightforward in a recursive descent parser, something like classify_name would only be applied post-lexing where appropriate.) This change speeds up the lookup by avoiding the best_symbol hack, instead searching only for a type. Acked-By: Simon Marchi Reviewed-By: Guinevere Larsen 2025-09-08 Sergio Durigan Junior gdb: Add svr4-tls-tdep.o to list of objects of i*86 targets GDB currently fails to build from source on i386 if compiled with --enable-64-bit-bfd. This is happening because svr4-tls-tdep.o is missing from the gdb_target_obs variable, while amd64-linux-tdep.o is obviously there. Fix the problem by adding svr4-tls-tdep.o to the object list, but only when --enable-64-bit-bfd is provided. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33399 2025-09-08 Tom Tromey Change return value of _bfd_mmap_temporary _bfd_mmap_temporary will return MAP_FAILED in some cases, but only one caller was prepared for this. This caused a couple of issues in gdb. This patch chnages _bfd_mmap_temporary to always return NULL on failure. It also changes the logic to fall back to bfd_malloc if mmap fails. I took the opportunity to change some "(void *) -1" to MAP_FAILED where appropriate. Tested by "make check" in binutils, and also by applying a hack from bug 33354 to gdb and testing something approximating the original report. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32542 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33354 2025-09-08 Tom Tromey Require Tcl 8.6.2 This changes the gdb test suite to require Tcl 8.6.2. This allows the removal of some more compatibility code. I wrote this as a separate patch so make it simpler to drop if some platform only provides Tcl 8.5. According to research in the bug, though, it seems like this isn't likely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi 2025-09-08 Tom Tromey Rewrite tcl_version_at_least tcl_version_at_least can more easily be expressed using the built-in "package" command. Approved-By: Simon Marchi 2025-09-08 Tom Tromey Require Tcl 8.5 This patch changes the gdb test suite to require Tcl 8.5. It also removes the one pre-8.5 compatibility function. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi 2025-09-08 Alan Modra vms-alpha: sections array index sanity checks Adds a couple of missing bound checks. * vms-alpha.c (alpha_vms_fix_sec_rel): Sanity check relocation section index. (alpha_vms_bfd_final_link): Assert that section index is sane. 2025-09-08 Alan Modra vms-alpha: ehdr checks I noticed that _bfd_vms_slurp_ehdr wrongly used buf_size (rather than rec_size) when sanity checking. * vms-alpha.c (_bfd_vms_slurp_ehdr): Don't allow access to uninitialised buffer memory. Tidy code generally, using remaining record length for sanity checks. 2025-09-08 Alan Modra PR 33385 vms archives Commit 5c4ce239a3ab "Tidy bfdio to consistenly use containing archive" broke vms archive handling, which has some horrible hacks involving use of a special iovec for archive elements. Modify the generic archive handling code to not use the archive iovec when it differs from the element iovec. Also, various commits involving seek optimisation broke the vms archive handling, which needs to see a rewind on an archive element. * bfdio.c (bfd_read, bfd_write, bfd_tell, bfd_flush), (bfd_stat, bfd_seek, bfd_mmap): Do not use the archive bfd for IO when the archive and element iovec differ. * plugin.c (bfd_plugin_open_input), (bfd_plugin_close_file_descriptor): Likewise. * vms-lib.c (vms_lib_bopen): Force bfd_seek to call iovec seek. 2025-09-08 Alan Modra PR 33385 unsupported relocs Commit 96d3b80f5498 changed a couple of reloc functions to return false, and propagated the error. They previously did nothing, so revert to that sad state. * vms-alpha.c (alpha_vms_add_lw_reloc): Return true. (alpha_vms_add_qw_reloc): Likewise. 2025-09-08 Alan Modra PR 33385 DST handling Commit 816995444667, a fix for a fuzzer testcase resulting in a buffer overflow, broke reading of DST. DST is a special case where a first pass over the section just sizes it. Commit a3c0896d80d2, another buffer overflow fix, wrongly removed a line incrementing DST record length. * vms-alpha.c (image_write): Don't do bounds check for sections in memory without contents. (evax_bfd_print_dst): Add one to length. 2025-09-08 Alan Modra PR 33385 EOM Another PR 21813 modification. * vmd-alpha.c (_bfd_vms_slurp_eeom): Allow 10 byte EOM. Don't set has_transfer or access fields past 10 bytes unless the entire EEOM is there. 2025-09-08 Alan Modra PR 33385, Extended Image Header This modifies some of the PR 21813 fixes, allowing for smaller EIHD. Not knowing any better, I chose to use EIHD__C_LENGTH as the minimum length. include/ * vms/eihd.h (EIHD__C_LENGTH): Comment. bfd/ * vms-alpha.c (_bfd_vms_slurp_eihd): Remove size check duplicating that done by the caller of this function. (alpha_vms_object_p): Allow smaller EIHD. (evax_bfd_print_image): Likewise. Don't print fields past the record size. 2025-09-08 H.J. Lu binutils: Require GNU tail for 'objdump -Wi' test testsuite/binutils-all/objdump.exp has set got [remote_exec host "tail -n +4 tmpdir/objdump.out" "" "/dev/null" "tmpdir/objdump.tail"] But the default Solaris tail doesn't support "tail -n +4". Add ACX_PROG_GNU_TAIL to use GNU tail for 'objdump -Wi' test. Tested on Linux and Solaris. binutils/ PR binutils/33396 * Makefile.am (check-DEJAGNU): Also export TAIL. * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. * configure.ac: Add ACX_PROG_GNU_TAIL. * testsuite/binutils-all/objdump.exp: Require GNU tail for 'objdump -Wi' test and replace tail with $env(TAIL). config/ PR binutils/33396 * acx.m4 (ACX_PROG_GNU_TAIL): New. Reviewed-by: Collin Funk 2025-09-08 H.J. Lu objdump: Check the SEC_CODE bit for code If a shared library has $ readelf -D -sW x.so | grep _PROCEDURE_LINKAGE_TABLE_ 3: 00000000000002c0 0 OBJECT GLOBAL DEFAULT 5 _PROCEDURE_LINKAGE_TABLE_ $ Disassembler treats PLT0 as data: $ objdump -dw x.so x.so: file format elf64-x86-64 Disassembly of section .plt: 00000000000002c0 <_PROCEDURE_LINKAGE_TABLE_>: 2c0: ff 35 7a 01 10 00 ff 25 7c 01 10 00 0f 1f 40 00 .5z....%|.....@. 00000000000002d0 : 2d0: ff 25 7a 01 10 00 jmp *0x10017a(%rip) # 100450 2d6: 68 00 00 00 00 push $0x0 2db: e9 e0 ff ff ff jmp 2c0 <_PROCEDURE_LINKAGE_TABLE_> Disassembly of section .text: 00000000000002e0 : 2e0: e8 eb ff ff ff call 2d0 2e5: c3 ret Check the SEC_CODE bit on section for code. PR binutils/33389 * objdump.c (disassemble_section): Check SEC_CODE for code. 2025-09-08 Andrew Burgess gdb/testsuite: small fix for amd64-extended-prologue-analysis.exp I noticed I was sometimes getting this failure: FAIL: gdb.arch/amd64-extended-prologue-analysis.exp: offset \ initialization: ASM source: gdb_breakpoint: set breakpoint \ at *0x0000000000401151 The problem was introduced in commit: commit f9aa48dc545ef511e19f4dfab88a196b820fd2da Date: Thu Aug 28 11:50:13 2025 +0000 gdb, amd64: extend the amd64 prologue analyzer to skip register pushes A gdb_test_multiple exits early when processing the results of a 'disassemble' command, without waiting for the prompt to be seen. This can leave unhandled output in expect's input buffer, which will then throw off the next test. Update the gdb_test_multiple to wait for the prompt before declaring the test passed. After this I'm no longer seeing the above failure. There should be no change in what is tested after this commit. 2025-09-08 Jan Beulich x86: constrain and fix use of the "nojumps" .arch modifier As said by the paragraph of the description that isn't modified here (a few lines up), this was only ever supposed to be used with 16-bit architectures. Actually enforcing this allows code in md_estimate_size_before_relax() to move to a less frequently used code path. (For backwards compatibility, keep accepting "jumps" also with 32- or 64-bit architectures.) Repeat the constraint also in the 2nd paragraph of the doc on this subject. And while there also insert a missing insn in the related i386-Jumps section. Furthermore checking a global variable during late processing is wrong. We need to record the state in the fragment, and use that rather than the state of the variable at the end of parsing all input. Seeing that there's no testing of the functionality at all, add a testcase as well. 2025-09-08 Jan Beulich x86: make TC_FRAG_INIT() resolve to a function call This way we can avoid making various global variables non-static. Their set is to only ever grow, really. 2025-09-08 Jeffrey Knockel bfd: Add i386_pe_big_vec vector to win64 targets 251dae91074170036c1a76c5e5df1f45197d7feb added i386_pe_big_vec to win32 targets but did not add it to win64 ones. Adding i386_pe_big_vec vector to win64 targets fixes an issue where a 64-bit assembler on windows would fail to create bigobj files when operating with 32-bit word size. E.g., before this change, with a 64-bit toolchain: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 But after this change, the output file format is correctly bigobj: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-bigobj-i386 architecture: i386, flags 0x0000003d: HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 Although the above multilib compilation issue was the motivation for this patch, this change has other positive consequences, such as allowing the 64-bit windows build of objdump to disassemble pe-bigobj-i386 format object files, etc. 2025-09-08 Gopi Kumar Bulusu MicroBlaze: Add microblaze_get_next_pcs This patch enables software single stepping for gdbserver target Includes fix for Bug 33381 using core_addr_to_string_nz * gdb/microblaze-tdep.c: Add microblaze_get_next_pcs Approved-By: Simon Marchi 2025-09-08 GDB Administrator Automatic date update in version.in 2025-09-07 H.J. Lu ld: Limit "readelf --got-contents" tests Since "readelf --got-contents" tests use -melf_i386, -melf_x86_64 and -melf32_x86_64 emulations, limit theses tests to linker supporting those emulations, pass --rosegment to linker and output libgot-1-i386.so, libgot-1-x64.so, libgot-1-x32.so. PR ld/33350 * testsuite/ld-i386/binutils.exp: Limit tests to linker with -melf_i386 support, pass --rosegment to linker and output libgot-1-i386.so. * testsuite/ld-x86-64/binutils.exp: Limit -melf_x86_64 tests to linker with -melf_x86_64 support, limit -melf32_x86_64 tests to linker with -melf32_x86_64 support, pass --rosegment to linker and output libgot-1-x64.so/libgot-1-x32.so. 2025-09-07 H.J. Lu elf: Define more SHT_SUNW_XXX binutils/ * readelf.c (get_solaris_section_type): Use SHT_SUNW_XXX and add SHT_SUNW_phname and SHT_SUNW_symtabnsort. include/ * elf/common.h (SHT_SUNW_symtabnsort): New. (SHT_SUNW_ancillary): Likewise. (SHT_SUNW_capchain): Likewise. (SHT_SUNW_capinfo): Likewise. (SHT_SUNW_symsort): Likewise. (SHT_SUNW_tlssort): Likewise. (SHT_SUNW_LDYNSYM): Likewise. (SHT_SUNW_dof): Likewise. (SHT_SUNW_cap): Likewise. (SHT_SUNW_SIGNATURE): Likewise. (SHT_SUNW_ANNOTATE): Likewise. (SHT_SUNW_DEBUGSTR): Likewise. (SHT_SUNW_DEBUG): Likewise. (SHT_SUNW_verdef): Likewise. (SHT_SUNW_verneed): Likewise. (SHT_SUNW_versym): Likewise. 2025-09-07 Tom de Vries [gdb/testsuite] Error out on clean_restart Error out in proc clean_restart if the argument is an absolute filename. Likewise in proc mi_clean_restart. Tested on x86_64-linux. 2025-09-07 Sam James README: don't talk about libg++ Gone since 2001 or so. 2025-09-07 Sergio Durigan Junior gdb: Add i386-gnu-tdep to the list of objects for x86_64-*-gnu* When starting GDB on Hurd amd64, one will currently see the following warning: # gdb -q gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration of GDB. Attempting to continue with the default i386 settings. (gdb) This happens because, in gdb/configure.tgt, the "x86_64-*-gnu*" target is not pulling in the i386-gnu-tdep.o object, which means that only 64-bit debugging is currently supported. The fix here is to add i386-gnu-tdep.o to the gdb_target_obs for Hurd amd64. Suggested-by: Andrew Burgess Reported-by: Mark Wielaard Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33377 Approved-by: Kevin Buettner 2025-09-07 GDB Administrator Automatic date update in version.in 2025-09-06 Joel Brobecker Update gdb/NEWS after GDB 17 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. 2025-09-06 Joel Brobecker Bump version to 18.0.50.DATE-git. Now that the GDB 17 branch has been created, this commit bumps the version number in gdb/version.in to 18.0.50.DATE-git For the record, the GDB 17 branch was created from commit 46ada32fc979550ad4f46792b74c182bb7232aeb. 2025-09-06 H.J. Lu Update x86: Add GLIBC_ABI_GNU2_TLS version dependency commit 0d1e88f8bfb0e62f37bf8a89172cd91373ace5e6 Author: H.J. Lu Date: Fri Jul 4 08:39:03 2025 +0800 x86: Add GLIBC_ABI_GNU2_TLS version dependency added solaris2-x86-64.em to accommodate moving x86-64 specific extra emulation bits to elf-x86-64.em. Update emulparams/elf_x86_64_sol2.sh to use it. * emulparams/elf_x86_64_sol2.sh (EXTRA_EM_FILE): Set to "solaris2-x86-64". 2025-09-06 Alan Modra Re: tekhex test for commit bf0f85df1254 * testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): Correct isremote to is_remote. 2025-09-06 GDB Administrator Automatic date update in version.in 2025-09-05 Thiago Jung Bauermann bfd: configure.ac: Fix mention of flag to enable 64-bit BFD in comment It was changed back in 1994. Fixing because it misled me into using the wrong flag in a build. 2025-09-05 Tom Tromey Allow conversion of 128-bit integers to Python Currently, trying to convert a 128-bit integer from a gdb.Value to a Python integer will fail. This is surprising because Python uses bigints internally. The bug here is that valpy_long uses value_as_long, which fails for anything wider than LONGEST. This patch fixes the problem by using the recommended Python API. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366 Approved-By: Simon Marchi 2025-09-05 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.base, part 3 Fix fallout in gdb.base from erroring out on clean_restart . Tested on x86_64-linux. 2025-09-05 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.base, part 2 Manually fix the test-cases found by: ... $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'clean_restart[^;]*binfile' $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'prepare_for_testing.*bin' ... except for gdb.base/foll-vfork.exp and gdb.base/solib-overlap.exp. Tested on x86_64-linux. 2025-09-05 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.base, part 1 Run: ... $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $binfile$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${binfile}$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $::binfile$/\1clean_restart\n\1gdb_load $::binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${::binfile}$/\1clean_restart\n\1gdb_load $::binfile/' ... Revert the change in test-case gdb.base/foll-vfork.exp, which does 'set binfile $testfile'. Tested on x86_64-linux. The only modified test-case I was not able to test is gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this). The change in the test-case is trivial though. 2025-09-05 H.J. Lu readelf: Handle 0 sh_entsize of GOT sections Gold, lld and mold set sh_entsize to 0 on .got and .got.plt sections. If sh_entsize of GOT sections is 0, assume 8 for ELFCLASS64 and 4 for ELFCLASS32, except for x32 which uses 8. PR binutils/33368 * readelf.c (process_got_section_contents): Handle 0 sh_entsize of GOT sections. 2025-09-05 Gopi Kumar Bulusu Revert "MicroBlaze: Add microblaze_get_next_pcs" This reverts commit c6df5d79aac5c4a77c06314fd26c837470360f70. Causes buildbot failure. Bug 33381 2025-09-05 Andrew Burgess gdb: ensure bp_location::section is set correct to avoid an assert While reviewing and testing another patch I set a breakpoint on an gnu ifunc function, then restarted the inferior, and this assert triggered: ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed. The backtrace at the time of the assert is: #6 0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747 #7 0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=) at ../../src/gdb/objfiles.c:478 #8 0x0000000000c38da6 in std::default_delete::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81 #9 0x0000000000c3782a in std::unique_ptr >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:292 #10 0x0000000000caf1bd in owning_intrusive_list >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111 #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192 #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408 #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729 #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359 #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466 #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390 #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514 #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95 #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827 The function breakpoint_free_objfile is being called when an objfile representing a shared library is being unloaded ahead of the inferior being restarted, the function is trying to remove references to anything that could itself reference the objfile that is being deleted. The assert is making the claim that, for a bp_location, which has a single address, the objfile of the symtab associated with the location will be the same as the objfile associated with the section of the location. This seems reasonable to me now, as it did when I added the assert in commit: commit 5066f3680667ec0f2d1745847a2372d85973a1e7 Date: Mon Nov 11 21:45:17 2024 +0000 gdb: do better in breakpoint_free_objfile The bp_location::section is maintained, according to the comments in breakpoint.h, to aid overlay debugging (is that even used any more), and looking at the code, this does appear to be the case. The problem in the above case arises when we are dealing with an ifunc function. What happens is that we end up with a section from one objfile, but a symtab from a different objfile. This problem originates from minsym_found (in linespec.c). The user asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function. What this means is that gnu_ifunc is actually a resolver function that returns the address of the actual function to use. In this particular test case, the resolver function is in a shared library, and the actual function to use is in the main executable. So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with that name, and spots that this has type mst_text_gnu_ifunc. GDB then uses this to figure out the actual address of the function that will be run. GDB then creates the symtab_and_line using the _real_ address and the symtab in which that address lies, in our case this will all be related to the main executable objfile. But, finally, in minsym_found, GDB fills in the symtab_and_line's section field, and this is done using the section containing the original minimal_symbol, which is from the shared library objfile. The minimal symbol and section are then use to initialise the bp_location object, and this is how we end up in, what I think, is an unexpected state. So what to do about this? The symtab_and_line::msymbol field is _only_ set within minsym_found, and is then _only_ used to initialise the bp_location::msymbol field. The bp_location::msymbol field is _only_ used in the function set_breakpoint_location_function, and we only really care about the msymbol type, we check to see if it's an ifunc symbol or not. This allows us to set the name of the function correctly. The bp_location::section is used, as far as I can tell, extensively for overlay handling. It would seem to me, that this section should be the section containing the actual breakpoint address. If the question we're asking is, is this breakpoint mapped in or not? Then surely we need to ask about the section holding the breakpoint's address, and not the section holding some other code (e.g. the resolver function). In fact, in a memory constrained environment, you'd expect the resolver functions to get mapped out pretty early on, but while the actual functions might still be mapped in. Finally, symtab_and_line::section. This is mostly set using calls to find_pc_overlay. The minsym_found function is one of the few places where we do things differently. In the places where the section is used, it is (almost?) always used in conjunction with the symtab_and_line::pc to lookup information, e.g. calls to block_for_pc_sect, or find_pc_sect_containing_function. In all these cases, it appears to me that the assumption is that the section will be the section that contains the address. So, where does this leave us? I think what we need to do is update minsym_found to just use find_pc_overlay, which is how the symtab_and_line::section is set in most other cases. What this actually means in practise is that the section field will be set to NULL (see find_pc_overlay in symfile.c). But given that this is how the section is computed in most other cases, I don't see why it should be especially problematic for this case. In reality, I think this just means that the section is calculated via a call to find_pc_section when it's needed, as an example, see lookup_minimal_symbol_by_pc_section (minsyms.c). I do wonder if we should be doing better when creating the symtab_and_line, and insist that the section be calculated correctly at that point, but I really don't want to open that can of worms right now, so I think just changing minsym_found to "do it just like everyone else" should be good enough. I've extended the existing ifunc test to expose this issue, the updated test fails without this patch, and passes with. Approved-By: Simon Marchi 2025-09-05 Andrew Burgess gdb: pass core file to gdbarch_core_read_x86_xsave_layout Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates the gdbarch method 'gdbarch_core_read_x86_xsave_layout' to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::fetch_x86_xsave_layout. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-05 Andrew Burgess gdb: pass core file to gdbarch_core_thread_name method Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates the gdbarch method 'gdbarch_core_thread_name' to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::thread_name. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-05 Andrew Burgess gdb: pass core file through gdbarch API when loading shared libraries Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates two gdbarch methods: gdbarch_core_xfer_shared_libraries gdbarch_core_xfer_shared_libraries_aix to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::xfer_partial. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-05 Tom de Vries [gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-native When running test-case gdb.base/fileio.exp with host/target board local-remote-host-native I run into: ... gdb compile failed, fileio.c: In function 'test_open': :0:8: error: expected expression before '.' token fileio.c:89:15: note: in expansion of macro 'OUTDIR' ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR); ^~~~~~ ... Fix this by using: - quote_for_host to pass -DOUTDIR to the compilation, and - STRINGIFY to stringify OUTDIR in fileio.c. Tested on x86_64-linux, with target board unix and host/target board local-remote-host-native. 2025-09-05 Gopi Kumar Bulusu MicroBlaze: Add microblaze_get_next_pcs This patch enables software single stepping for gdbserver target * gdb/microblaze-tdep.c: Add microblaze_get_next_pcs Approved-By: Simon Marchi 2025-09-05 Tom de Vries [gdb/testsuite] Fix clean_restart in allow_aarch64_sme_tests Fix fallout on aarch64-linux with test-case gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on clean_restart . 2025-09-05 Tom de Vries [gdb/testsuite] Fix silent timeout in allow_aarch64_gcs_tests I noticed on M1 aarch64-linux that test-case gdb.testsuite/gdb-caching-proc-consistency.exp took a long time. I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests. This gdb_expect only handles the case that gcs support is detected: ... gdb_expect { -re ".*$inferior_exited_re normally.*${gdb_prompt} $" { verbose -log "\n$me: gcs support detected" set allow_gcs_tests 1 } } ... but in my case, I get: ... (gdb) run ^M Starting program: allow_aarch64_gcs_tests.x ^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M [Inferior 1 (process 3336556) exited with code 01]^M (gdb) ... so the gdb_expect times out quietly, taking 10 seconds. In the test-case, it does so 11 times. Fix this by adding a gdb_expect clause handling the "with code 01" case. Tested on aarch64-linux. PR testsuite/33378 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33378 2025-09-05 Jan Beulich x86: check reloc types for relaxable branches Bypassing _reloc() isn't a good idea, as there are various errors checked for there. For example 16-bit JMP or Jcc may not use the @plt form (resulting in a 32-bit relocation to be emitted for a 16-bit field), which so far we only reject for 16-bit CALL. In exchange this allows simplifying the setting up of the "reloc_type" local variable. x86: make reloc() usable during late phases of assembly Introduce a clone with extra parameters, to allow subsequent use from md_estimate_size_before_relax() (or elsewhere, should that turn out necessary). There flag_code cannot be used and location information needs to be provided for diagnostics. 2025-09-05 Simon Marchi gdb: run black on gdbarch_components.py Change-Id: Ifcf80faa240c7c235bfea4ddc79f0d6c39858c5e 2025-09-05 GDB Administrator Automatic date update in version.in 2025-09-04 Thiago Jung Bauermann GDB: aarch64-linux: Define HWCAP_GCS as unsigned long long value On platforms where long is 32 bits, this change fixes a build failure: /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c: In function ‘const target_desc* aarch64_linux_core_read_description(gdbarch*, target_ops*, bfd*)’: /home/linux/arm/gdb/src/gdb/arch/aarch64-gcs-linux.h:27:24: error: left shift count >= width of type [-Werror=shift-count-overflow] 27 | #define HWCAP_GCS (1UL << 32) | ~~~~^~~~~ /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c:1714:47: note: in expansion of macro ‘HWCAP_GCS’ 1714 | features.gcs = features.gcs_linux = hwcap & HWCAP_GCS; | ^~~~~~~~~ Suggested-by: Tom de Vries Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33372 2025-09-04 Andrew Burgess gdb/testsuite: revert recent changes to gdb.dap/scopes.exp After the previous commit, the changes to gdb.dap/scopes.exp from the commit: commit 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4 Date: Fri Mar 29 16:38:50 2019 +0100 gdb, gdbserver: Add support of Intel shadow stack pointer register. Are no longer needed, the test will now happily handle the shadow stack pointer being unavailable. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Christina Schimpe 2025-09-04 Andrew Burgess gdb/dap: check values are available before converting to int In VariableReference.to_object, we try to convert a gdb.Value to an int without checking if the value is actually available. This came to light in PR gdb/33345, after the x86 CET shadow stack patches were merged. If the x86 CET shadow stack register is available on the machine, but the shadow stack feature is not enabled at run time, then the register will show as "". As the register is of type 'void *', then in the DAP code we try to add a 'memoryReference' attribute with the value of the register formatted as hex. This will fail if the register is unavailable. To test this change you'll need: (a) a machine which support the shadow stack feature, and (b) to revert the changes from commit 63b862be762e1e6e7 in the file gdb.dap/scopes.exp. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Christina Schimpe 2025-09-04 Andrew Burgess gdb/python: add gdb.Value.is_unavailable attribute Add a new gdb.Value.is_unavailable attribute. This is similar to the existing Value.is_optimized_out attribute, but returns True if any part of the value is . The existing Value.is_optimized_out attribute returns true if any part of the value is optimized out, so I thought that Value.is_unavailable should work the same way. There's also a test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Eli Zaretskii Reviewed-By: Christina Schimpe 2025-09-04 Pawel Kupczak gdb, amd64: return after amd64_analyze_register_saves if current_pc reached Make sure the function bails out early if CURRENT_PC is reached, to avoid the call to amd64_analyze_stack_alloc. Reviewed-By: Guinevere Larsen Approved-By: Andrew Burgess 2025-09-04 Pawel Kupczak gdb, amd64: extend the amd64 prologue analyzer to skip stack alloc Following the previous patch (gdb, amd64: extend the amd64 prologue analyzer to skip register pushes), this patch extends the analyzer further to be able to skip stack space allocation as the next prologue part, for functions with a frame pointer. Implementation was based on the i386 counterpart, which already had that functionality. As of now, the stack allocation is not skipped. Examples below use C source listed below, compiled with gcc 11.4.0. ``` int foo (int n) { int ns[] = { 1, 4, 9, 16, 25 }; return ns[n]; } int main (int argc, char **argv) { return foo (argc); } ``` Compiling with "gcc -O0 -fno-omit-frame-pointer" we get: ``` (gdb) b foo Breakpoint 1 at 0x1151 (gdb) r ... Breakpoint 1, 0x0000555555555151 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555149 <+0>: endbr64 0x000055555555514d <+4>: push %rbp 0x000055555555514e <+5>: mov %rsp,%rbp => 0x0000555555555151 <+8>: sub $0x30,%rsp 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp) ... ``` With this patch, it gets skipped the same way register pushes are: ``` (gdb) b foo Breakpoint 1 at 0x1155 (gdb) r ... Breakpoint 1, 0x0000555555555155 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555149 <+0>: endbr64 0x000055555555514d <+4>: push %rbp 0x000055555555514e <+5>: mov %rsp,%rbp 0x0000555555555151 <+8>: sub $0x30,%rsp => 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp) ... ``` Reviewed-By: Guinevere Larsen Approved-By: Andrew Burgess 2025-09-04 Pawel Kupczak gdb, amd64: return after amd64_analyze_frame_setup if current_pc reached Make sure the function bails out early if CURRENT_PC is reached, to avoid the call to amd64_analyze_register_saves. Reviewed-By: Guinevere Larsen Approved-By: Andrew Burgess 2025-09-04 Pawel Kupczak gdb, amd64: extend the amd64 prologue analyzer to skip register pushes A typical function's prologue can consist of setting up a frame pointer, pushing registers onto the stack and allocating space on the stack. Current amd64 prologue analyzer would stop after the frame setup. This patch allows GDB to skip past register pushes, while also improving unwinding pushed registers, for functions with a frame pointer, without debug info and .cfi directives found in .eh_frame section that are used for unwinding. Skipping register pushes was also present for i386 targets before - the proposed changes are based on i386 implementation. It also improves the unwinding even if .cfi directives are present, because GDB can only unwind a register if it has reached a corresponding .cfi directive, which won't be there before the pushes. Additionally, at least gcc 11.4 and later by default doesn't emit necessary debug info, which GDB would try to use to find prologue's end. In that case, extended prologue analyzer would take effect. Using C source listed below as an example, compiled with gcc 11.4.0: ``` int __attribute__ ((noinline)) bar (int a) { return a + a; } int __attribute__ ((noinline)) foo (int a, int b, int c, int d, int e) { int x = bar (a) + bar (b) + bar (c) + bar (d) + bar (e); return x; } int main (int argc, char **argv) { return foo (1, 2, 3, 4, 5); } ``` Compiling with "gcc -O1 -fno-omit-frame-pointer -fno-asynchronous-unwind-tables", we get: ``` (gdb) b foo Breakpoint 1 at 0x1139 (gdb) r ... Breakpoint 1, 0x0000555555555139 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp => 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... (gdb) ni 0x000055555555513b in foo () (gdb) p $r15 $1 = 140737354125376 (gdb) p $r15=1234 $2 = 1234 (gdb) p $r15 $3 = 1234 (gdb) up #1 0x00005555555551b7 in main () (gdb) p $r15 $4 = 1234 ``` With the proposed changes, breakpoint gets past those register pushes: ``` (gdb) b foo Breakpoint 1 at 0x1142 (gdb) r ... Breakpoint 1, 0x0000555555555142 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx => 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... ``` Also, unwinding pushed registers now works: ``` ... Breakpoint 1, 0x0000555555555142 in foo () (gdb) disassemble Dump of assembler code for function foo: 0x0000555555555131 <+0>: endbr64 0x0000555555555135 <+4>: push %rbp 0x0000555555555136 <+5>: mov %rsp,%rbp 0x0000555555555139 <+8>: push %r15 0x0000555555555139 <+8>: push %r15 0x000055555555513b <+10>: push %r14 0x000055555555513d <+12>: push %r13 0x000055555555513f <+14>: push %r12 0x0000555555555141 <+16>: push %rbx => 0x0000555555555142 <+17>: sub $0x8,%rsp 0x0000555555555146 <+21>: mov %esi,%r15d ... (gdb) p $r15 $1 = 140737354125376 (gdb) p $r15=1234 $2 = 1234 (gdb) p $r15 $3 = 1234 (gdb) up #1 0x00005555555551b7 in main () (gdb) p $r15 $4 = 140737354125376 ``` Additionally a new test was added to verify this behavior. Reviewed-By: Guinevere Larsen Approved-By: Andrew Burgess 2025-09-04 Tom Tromey Don't require "Bss=" in qOffsets response The "Bss=" part of the qOffsets response is documented as being optional, but gdb in fact requires it. This patch fixes the bug. I couldn't find a straightforward way to test this. gdbserver does send 'Bss=' -- but this code is only enabled for a fairly specific setup: #if (defined(__UCLIBC__) \ && defined(HAS_NOMMU) \ && defined(PT_TEXT_ADDR) \ && defined(PT_DATA_ADDR) \ && defined(PT_TEXT_END_ADDR)) #define SUPPORTS_READ_OFFSETS #endif I also considered changing gdbserver to not send Bss=, but decided against this, reasoning that we may as well not break compatibility with older versions of gdb. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33319 Approved-By: Simon Marchi 2025-09-04 Guinevere Larsen gdb/testsuite: fix possible TCL errors in gdb.threads/threadcrash.exp The test gdb.threads/threadcrash.exp, among other things, creates a list of the threads seen in the order that the "thread apply all backtrace" would generate them, tests that this list is the same size as GDB's count of threads, and then loops over the list to check that each thread has the expected backtrace. A problem occurs because the loop iterates on GDB's internal count of threads, rather than the size of the list, but then attempts to acces the n-th element of the list. If the list size is smaller than GDB's internal thread count, it'll access past the end of the list and generate TCL errors. This commit fixes this by using the list's length instead. Approved-By: Tom Tromey 2025-09-04 Andrew Burgess gdb: remove most global core file accesses from fbsd-tdep.c This commit removes many places in fbsd-tdep.c where we access the current core file via current_program_space, and replaces these accesses with a function argument that is passed in. There are still two uses of 'current_program_space->core_bfd ()' in the file, these will be addressed in future work (not in this series though). There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-04 Andrew Burgess gdb: pass core file to gdbarch_core_xfer_siginfo Another patch that aims to remove 'current_program_space->core_bfd ()' from GDB. This time I'm passing the core file BFD as an argument to the gdbarch method gdbarch_core_xfer_siginfo. In corelow.c the core file is being passed, this does introduce a new instance of 'current_program_space->core_bfd ()', but this is OK. My long term plan is to move the core bfd into core_target, in which case the call to gdbarch_core_xfer_siginfo will have access to the core bfd as a member variable. For now though, this patch moves the accesses via global state up the call stack, and consolidates the two calls from fbsd-tdep.c and linux-tdep.c into the one call in corelow.c. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-04 Andrew Burgess gdb: remove most global core file accesses from record-full.c This commit continues my ongoing work to reduce the number of global accesses to the current core file BFD in GDB. The global accesses I'm working on removing look like 'current_program_space->core_bfd ()'. This commit targets record-full.c. All global accesses are removed except for two in record_full_open, which is used to implements the two commands 'target record-full' and 'record full restore'. All other global accesses to the core file are removed by passing the core file through as an argument from this one top level function. As I followed the code through I noticed that record_full_restore, which currently includes this check: if (current_program_space->core_bfd () == nullptr) return; could never actually be called without a core file being set. As the argument is now 'struct bfd &', then there is no longer an option for the incoming argument to be NULL, and the above check is removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-04 Andrew Burgess gdb: remove some dead code from core_target_open In core_target_open we call target_preopen which pops all targets above the file_stratum, this will include the core_target, if the core target is currently loaded. Currently, the core file BFD is stored in the program_space of an inferior. The only way to set the core file BFD is by creating a core_target (in core_target_open). And when a core_target is closed the core file BFD within the program_space is reset to nullptr (see core_target::close and core_target::clear_core, both in corelow.c). What this means is that, if there is no core_target loaded then there will be no core file BFD in the program_space. And in core_target_open, after the call to target_preopen, there will be no core_target loaded, and thus, no core file BFD in the program_space. There is currently code in core_target_open which checks to see if there is a core file BFD set in the current program space. For the reasons given above, I believe this is dead code and can be removed. I've added some asserts to validate my assumptions. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/*.exp Fix clean_restart in gdb.arch/*.exp. The fixed test-cases are supported on archs sh, ia64, mips, pa and sparc. I haven't tested these. 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/powerpc*.exp Fix clean_restart in gdb.arch/powerpc*.exp. Likewise in gdb.arch/ppc*.exp, gdb.arch/altivec*.exp, gdb.arch/e500*.exp and gdb.arch/vsx*.exp. Tested on ppc64le-linux. The following test-cases only run on 32-bit ppc: - gdb.arch/e500-abi.exp - gdb.arch/e500-prologue.exp - gdb.arch/e500-regs.exp - gdb.arch/powerpc-aix-prologue.exp - gdb.arch/powerpc-prologue.exp - gdb.arch/powerpc-prologue-frame.exp - gdb.arch/powerpc-trap.exp so these haven't been tested. 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/thumb*.exp Fix clean_restart in gdb.arch/thumb*.exp. Likewise in test-case gdb.arch/pr25124.exp. Tested on arm-linux, target boards unix/-marm and unix/-mthumb. 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/arm*.exp Fix clean_restart in gdb.arch/arm*.exp. Tested on: - arm-linux, target boards unix/-marm and unix/-mthumb - aarch64-linux 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/aarch64*.exp Fix clean_restart in gdb.arch/aarch64*.exp. Tested on aarch64-linux, M1 system. There's a large number (44) of unsupported, for the following reasons: - allow_aarch64_gcs_tests - allow_aarch64_mops_tests - allow_aarch64_sve_tests / target does not support SVE - memory tagging unsupported Consequently, we mostly use the simple substitution: ... clean_restart $binfile -> clean_restart gdb_load $binfile ... 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/i386*.exp Fix clean_restart in gdb.arch/i386*.exp. Tested on x86_64-linux, with target board unix/-m32 and gcc 15. The only unsupported test-case is gdb.arch/i386-avx512.exp, which isn't changed by this commit. 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.arch/amd64*.exp Fix clean_restart in gdb.arch/amd64*.exp. Tested on x86_64-linux, with kernel version 6.16.3. The only unsupported test-case is gdb.arch/amd64-lam.exp, which isn't changed by this commit. 2025-09-04 Nelson Chu RISC-V: Don't generate R_RISCV_RELATIVE if symbol referenced section is SH_ABS It's werid if it's absolute symbol but have a relative reloc for got entry under pie. So don't generate relative reloc if symbol referenced section is SH_ABS. However, x86 allows the absolute symbol defined in linker script has a relative reloc, not sure if risc-v needs this or not. RISC-V: Don't overwrite got entry to zero for IRELATIVE/RELATIVE relocation Even the final result is correct since we encode the relocation into r_addend, so glibc won't need to get the content of got entry when resolving relative relocation, it still werid that finish_dynamic_symbol cleans what we filled in the relocate_section. 2025-09-04 Nelson Chu RISC-V: Fixed missed GOT relocation against a symbol that has a defined value SImilar to aarch64, commit eac4eb8ecb26 There are two problems when GOT relocation against a symbol that has a defined value, 1. Pesudo la with pic and pseudo lga lost the relocations. 2. %got_pcrel_hi generates R_RISCV_GOT_HI20 with addend, which is wrong since commit 50331d64f108. The solution is to use deferred_expression for GOT relocation. Maybe other relocations also have same problem and need the deferred_expression, but we can add in the future patches. 2025-09-04 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.ada Fix clean_restart in the test-cases in gdb.ada. Tested on x86_64-linux with gcc 14. 2025-09-04 GDB Administrator Automatic date update in version.in 2025-09-03 Andrew C Aitchison PR 33360, Correct strings -Ue output 2025-09-03 Alan Modra mips: remove unnecessary obstack_finish It isn't necessary to call obstack_finish before obstack_free of an unwanted string. * config/tc-mips.c (mips_parse_arguments): Replace obstack_finsih with obstack_base. 2025-09-03 Tom de Vries gdb/testsuite] Fix clean_restart in gdb.compile Fix clean_restart in the test-cases in gdb.compile. Tested on x86_64-linux, fedora rawhide. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.cp Fix clean_restart in the test-cases in gdb.cp. Tested on x86_64-linux. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.debuginfod Fix clean_restart in the test-cases in gdb.debuginfod. Tested on x86_64-linux. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.disasm Fix clean_restart in the test-cases in gdb.disasm. The changed test-cases: - gdb.disasm/am33.exp - gdb.disasm/hppa.exp - gdb.disasm/mn10300.exp - gdb.disasm/sh3.exp are unsupported for me, but the changes are trivial. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.dwarf2 Fix clean_restart in the test-cases in gdb.dwarf2. Tested on x86_64-linux using gcc-14. Tested these test-cases on x86_64-linux with target board unix/-m32: - gdb.dwarf2/valop.exp - gdb.dwarf2/callframecfa.exp - gdb.dwarf2/implptr.exp - gdb.dwarf2/watch-notconst.exp - gdb.dwarf2/pieces.exp - gdb.dwarf2/pieces-optimized-out.exp Tested these test-cases on x86_64-linux with target board fission-dwp: - gdb.dwarf2/dwp-symlink.exp - gdb.dwarf2/dwp-sepdebug.exp Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a too strict home directory check, see PR testsuite/33364. 2025-09-03 H.J. Lu readelf: Don't change the symbol table 1. Update dump_relr_relocations not to change the symbol table. 2. Update count_relr_relocations and dump_relr_relocations not to retrieve the same data twice. binutils/ PR binutils/33328 * readelf.c (count_relr_relocations): Add an argument to return the retrieved data and remove the FIXME in comments. (dump_relr_relocations): Add an argument for the retrieved data. Retrieve the data if needed. Don't change the symbol table and remove the FIXME in comments. (display_relocations): Get the data from count_relr_relocations and pass it to dump_relr_relocations call. (process_relocs): Pass NULL to dump_relr_relocations. ld/ PR binutils/33328 * testsuite/ld-i386/dt-relr-2.d: New file. * testsuite/ld-i386/dt-relr-2.s: Likewise. * testsuite/ld-x86-64/dt-relr-2-x32.d: Likewise. * testsuite/ld-x86-64/dt-relr-2.d: Likewise. * testsuite/ld-x86-64/dt-relr-2.s: Likewise. * testsuite/ld-i386/i386.exp: Run dt-relr-2. * testsuite/ld-x86-64/x86-64.exp: Run dt-relr-2 and dt-relr-2-x32. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.fortran Fix clean_restart in the test-cases in gdb.fortran. Tested on x86_64-linux, with gcc 14. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.gdb Fix clean_restart in the test-cases in gdb.gdb. Tested on x86_64-linux. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.guile Fix clean_restart in the test-cases in gdb.guile. Tested on x86_64-linux. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.linespec Fix clean_restart in the test-cases in gdb.linespec. Tested on x86_64-linux. 2025-09-03 Tom de Vries [gdb/testsuite] Fix mi_clean_restart in gdb.mi Fix mi_clean_restart in the test-cases in gdb.mi. Tested on x86_64-linux. Also tested test-case gdb.mi/mi-dprintf.exp with target boards native-gdbserver and native-extended-gdbserver. Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't test the trivial change in that test-case. 2025-09-03 Tom de Vries [gdb/testsuite] Fix mi_clean_restart in gdb.trace Fix mi_clean_restart in the test-cases in gdb.trace. Tested on x86_64-linux, with target boards unix, native-gdbserver and native-extended-gdbserver. 2025-09-03 Tiezhu Yang gdb: LoongArch: Restrict breakpoint outside of atomic sequence We can't put a breakpoint in the middle of a ll/sc atomic sequence, so look for the end of the sequence and put the breakpoint there, it has been handled in the commit 208b57e53ed9 ("gdb: LoongArch: Deal with atomic sequence"). Especially, maybe there is a conditional branch instruction in the middle of a ll/sc atomic sequence, its destination address may be current pc + 4 which is inside the atomic sequence, it should not put a breakpoint in its destination address in this case, this has been handled in the commit a4242dc3f5fa ("gdb: LoongArch: Improve the handling of atomic sequence"). Additionally, if there is a conditional branch instruction in the middle of a ll/sc atomic sequence, its destination address may be not current pc + 4 but still inside the atomic sequence, it should not put a breakpoint in its destination address in this case. So in order to avoid putting a breakpoint in the middle of a ll/sc atomic sequence in any case, just look for the start and end of the sequence, and restrict the breakpoint outside of the atomic sequence. 2025-09-03 Tiezhu Yang gdb: LoongArch: Add and use cond_branch_destination_address() In the current loongarch_deal_with_atomic_sequence(), it is just a loop through a ll/sc atomic instruction sequence, the instructions before the condition branch are not actually executed, thus the condition register value is not proper to determine the destination address. Add a new function cond_branch_destination_address() to calculate the destination address of a condition branch instruction under an assumed true condition, then only put a breakpoint at this address when it is outside of the ll/sc atomic instruction sequence. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.multi Fix clean_restart in the test-cases in gdb.multi. Tested on x86_64-linux. 2025-09-03 H.J. Lu x86: Check plt_got_offset for lazy IBT PLT Lazy IBT PLT entries look like static const bfd_byte elf_i386_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] = { 0xf3, 0x0f, 0x1e, 0xfb, /* endbr32 */ 0x68, 0, 0, 0, 0, /* pushl immediate */ 0xe9, 0, 0, 0, 0, /* jmp relative */ 0x66, 0x90 /* xchg %ax,%ax */ }; static const bfd_byte elf_x86_64_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] = { 0xf3, 0x0f, 0x1e, 0xfa, /* endbr64 */ 0x68, 0, 0, 0, 0, /* pushq immediate */ 0xe9, 0, 0, 0, 0, /* jmpq relative */ 0x66, 0x90 /* xchg %ax,%ax */ }; They only have unsigned int plt_reloc_offset; /* ... offset into relocation table. */ and don't have unsigned int plt_got_offset; /* ... address of this symbol in .got. */ We should use plt_reloc_offset, not plt_got_offset, to check IBT PLT. PR binutils/33358 * elf32-i386.c (elf_i386_get_synthetic_symtab): Check plt_reloc_offset for lazy IBT PLT. * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise. 2025-09-03 H.J. Lu readelf: Run --got-contents only on ET_DYN/ET_EXEC files Update "readelf --got-contents" to skip on non-ET_DYN/ET_EXEC files. * readelf.c (process_got_section_contents): Skip if not ET_DYN/ET_EXEC files. * testsuite/binutils-all/readelf-got.d: Removed. * testsuite/binutils-all/readelf.exp: Don't run readelf-got. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.objc Fix clean_restart in the test-cases in gdb.objc. Tested on x86_64-linux, using 'lappend options "nowarnings"' in gdb_compile_shlib_pthreads. See also PR testsuite/24807. 2025-09-03 H.J. Lu readelf: Call qsort only if all_relocations_count > 1 Don't call qsort if all_relocations_count < 1. PR binutils/33351 * readelf.c (process_got_section_contents): Call qsort only if all_relocations_count > 1. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.opencl/callfuncs.exp In test-case gdb.opencl/callfuncs.exp I noticed: ... clean_restart [standard_testfile $testfile] ... This doesn't have the desired effect of starting gdb with $testfile because standard_testfile doesn't return anything. Fix this by using "clean_restart $testfile". While we're at it: - move standard_testfile to the start of the file - drop the redundant 'set testfile "callfuncs"' - use standard_testfile .cl to properly define $srcfile - use $srcfile instead of $testfile.cl Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33363 2025-09-03 Guinevere Larsen gdb/testsuite: Fix gdb.base/gcore-memory-usage with address sanitizer The test gdb.base/gcore-memory-usage is meant to show that the memory requirements of GDB's gcore command don't grow with the memory usage of the inferior. It was using hardcoded values for memory, but the values were too small when building GDB with address sanitizer. This commit fixes one of the failures by increasing the limit on the first gcore call. But, rather than just increasing the hardcoded limit for the second call, we instead save the amount of memory used in the first call and ensure that the second call doesn't use more memory than the first. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148 Approved-By: Tom de Vries 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.opt Fix clean_restart in the test-cases in gdb.opt. Tested on x86_64-linux using gcc 14. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.perf Fix clean_restart in the test-cases in gdb.perf. Tested on x86_64-linux using check-perf. 2025-09-03 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.python Fix clean_restart in the test-cases in gdb.python. Tested on x86_64-linux. 2025-09-03 Alan Modra Disable eh_frame optimisation if code detected in .eh_frame Fuzzers stress the assembler in ways no sane programmer would ever do. One x86 oss-fuzz testcase (cleaned up a litte) was: .sect .debug_frame call x .long x,0 .space 1 .long 0,0 The call insn leaves the frag data corresponding to a CIE uninitialised until later in assembly, leading to reports of uninitialised data access in ehopt.c:check_eh_frame. Hack around this problem by noticing an insn has been assembled in dwarf2_emit_insn. The existing frag has_code can't be used as that leads to alignment complaints, so add a new segment_info flag. * subsegs.h (struct segment_info_struct): Move bss and hadone later. Rename hadone to stab_seen. Add insn_seen bitfield. * dwarf2dbg.c (dwarf2_emit_insn): Set insn_seen. * ehopt.c (check_eh_frame): Disable optimisation if insn_seen. * stabs.c (s_stab_generic): Adjust for hadone rename. 2025-09-03 Alan Modra frag_alloc use of obstack_alloc Avoid the alignment hackery necessary when obstack_alloc is used. obstack_alloc expands to obstack_blank plus obstack_finish, and the latter call is where alignment of the tail of the obstack happens. The docs say obstack_alloc "is invoked almost like malloc", which implies a fixed size allocation and you don't need other obstack calls in its use. So I think trying to use obstack_alloc in frag_alloc was always a poor choice. * frags.c (frag_alloc): Replace obstack_alloc with obstack_blank. 2025-09-03 Alan Modra Explain frag alignment hacks "the weird alignment hackery" comment doesn't help anyone understand the code. Explain what is going on. Replace the zero length obstack_alloc with obstack_finish, which by inspection of obstack.h is all the zero length alloc does. * frags.c (frag_alloc): Comment. Replace zero length obstack_alloc with obstack_finish. (frag_new): Remove unnecessary obstack_finish. * write.c (compress_frag, compress_debug): Likewise. 2025-09-03 Alan Modra make frag fr_type a bitfield For better packing of struct frag. * frags.h (struct frag ): Use ENUM_BITFIELD. 2025-09-03 Alan Modra tidy tilegx and tilepro MAX_MEM_FOR_RS_ALIGN_CODE These weren't wrong, but should use the BUNDLE_SIZE macros, in case they ever change. * config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use TILEGX_BUNDLE_SIZE_IN_BYTES. * config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use TILEPRO_BUNDLE_SIZE_IN_BYTES. 2025-09-03 Alan Modra visium MAX_MEM_FOR_RS_ALIGN_CODE Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for the "fix" amount emitted by visium_handle_align. This didn't show up as a problem due to frag alignment hiding the error, until I started messing with struct frag. * config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Correct. 2025-09-03 Alan Modra csky disassembler leak * csky-dis.c (parse_csky_dis_options): Free copy of options. 2025-09-03 GDB Administrator Automatic date update in version.in 2025-09-03 Abhay Kandpal PowerPC: Vector Instructions for Deeply Compressed Weight for AI (RFC02691) opcodes/ * ppc-opc.c: (VXSEL5, VXSEL4, VXSEL3, VXSEL2, UIMM1): New defines. (powerpc_opcodes): : New instructions. gas/ * gas/testsuite/gas/ppc/future.s: Add new testcases. * gas/testsuite/gas/ppc/future.d: Likewise. 2025-09-02 Simon Marchi gdb/remote: call target_pre_inferior in remote_target::remote_add_inferior Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in program_space"), and with the previous patch applied ("gdb/remote: use scoped_restore_current_program_space in remote_unpush_target"), we get this failure: $ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" In gdb.log: (gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 0, follow-child 1: disconnect target extended-remote localhost:2348 Remote debugging using localhost:2348 /home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed. When connecting to a remote that has one or more inferior already running, the remote target (the GDB-side code) tries to re-use existing GDB inferiors that are unused. The problem is that the program space of the inferior that gets re-used unexpectedly has its solib_ops set. I think that the problem is that when connecting to a remote target that has multiple inferiors, target_pre_inferior only gets called for the currently selected (client-side) inferior. It happens here: #0 target_pre_inferior () at /home/smarchi/src/wt/amd/gdb/target.c:2454 #1 0x0000559c832a350a in target_preopen (from_tty=1) at /home/smarchi/src/wt/amd/gdb/target.c:2510 #2 0x0000559c82e1b8f1 in remote_target::open_1 (name=0x50200006eb58 ":2345", from_tty=1, extended_p=1) at /home/smarchi/src/wt/amd/gdb/remote.c:6171 #3 0x0000559c82e18a5d in extended_remote_target::open (name=0x50200006eb58 ":2345", from_tty=1) at /home/smarchi/src/wt/amd/gdb/remote.c:5446 #4 0x0000559c8329a43e in open_target (args=0x50200006eb58 ":2345", from_tty=1, command=0x512000072c40) at /home/smarchi/src/wt/amd/gdb/target.c:839 I think that target_pre_inferior should be called for the other inferiors that gain execution as a result of connecting to the remote target, to make sure inferior or program space-specific data from previous executions gets cleared. target_pre_inferior is what clears any previous solib_ops. It is possible to observe the problem by adding this print in target_pre_inferior: printf (">>> target_pre_inferior called for inferior %d\n", current_inferior ()->num); Then, starting a gdbserver: $ gdbserver --multi localhost:2345 Then, this gdb command that starts two remote inferiors, disconnects (leaving gdbserver and the inferiors running), then reconnects: $ ./gdb -nx --data-directory=data-directory -q \ -ex 'set sysroot /' \ -ex 'target extended-remote :2345' \ -ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'set remote exec-file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'b main' \ -ex r \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'run' \ -ex 'inferior 1' \ -ex 'disconnect' \ -ex 'echo About to reconnect\n' \ -ex 'target extended-remote :2345' >>> target_pre_inferior called for inferior 1 Remote debugging using :2345 Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart... Breakpoint 1 at 0x11fc: file /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c, line 50. >>> target_pre_inferior called for inferior 1 Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart Breakpoint 1, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50 50 pid = fork (); [New inferior 2] Added inferior 2 on connection 1 (extended-remote :2345) [Switching to inferior 2 [] ()] Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart... >>> target_pre_inferior called for inferior 2 Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart Thread 2.1 "extended-remote" hit Breakpoint 1.2, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50 50 pid = fork (); [Switching to inferior 1 [process 2591936] (/home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart)] [Switching to thread 1.1 (Thread 2591936.2591936)] #0 main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50 50 pid = fork (); Ending remote debugging. About to reconnect >>> target_pre_inferior called for inferior 1 Remote debugging using :2345 main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50 50 pid = fork (); We can see that target_pre_inferior is only called for inferior 1 when reconnecting (after the "About to reconnect" message). After adding the call to target_pre_inferior in remote_add_inferior, we get (just the last bit): About to reconnect >>> target_pre_inferior called for inferior 1 Remote debugging using :2345 >>> target_pre_inferior called for inferior 1 >>> target_pre_inferior called for inferior 2 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... (No debugging symbols found in /lib/x86_64-linux-gnu/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) main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50 50 pid = fork (); The duplicate calls to target_pre_inferior for inferior 1 are due to the existing call in target_preopen. It might be possible to get rid of it: with the call I added in remote_target::remote_add_inferior, I presume it's now unnecessary for the remote target to have the call in target_preopen as well. But since target_preopen is used by other targets, I prefer to leave it there to be safe, for the moment. Calling target_pre_inferior multiple times should not be a problem, as it should be idempotent. However, once I added that, test gdb.server/stop-reply-no-thread.exp started failing, with this in the logs: target remote localhost:2347 Remote debugging using localhost:2347 Remote 'g' packet reply is too long (expected 560 bytes, got 820 bytes): 000000... It became apparent that the new call to target_pre_inferior would wipe a previously fetched target description. I fixed that by adding calls to target_find_description in two callers of remote_add_inferior. I'm not 100% sure of what I'm doing here, but it seems somewhat correct that when we map a remote inferior to an existing client-side inferior, we wipe out any previous target description (which would have been left by a previous execution) and fetch a new one. The other call to remote_add_inferior is in extended_remote_target::attach, where there is already a call to target_find_description shortly after. Change-Id: I85426bfff286a67d5fb74bbf978df80060ee6deb 2025-09-02 Simon Marchi gdb/remote: use scoped_restore_current_program_space in remote_unpush_target Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in program_space"), this fails with an internal error: $ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" In gdb.log: (gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 1, follow-child 0: disconnect target extended-remote localhost:2347 Remote debugging using localhost:2347 /home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed. The issue is that remote_unpush_target uses scoped_restore_current_inferior to save the context, which only restores the current inferior on exit. But it then uses switch_to_inferior_no_thread, which switches the inferior and the program space. The program space is therefore left unrestored. This can leave the current inferior and current program space out of sync. With two inferiors, let's say we enter with current inferior == 1 and current program space == 1. When calling switch_to_inferior_no_thread for inferior 2, we set the current inferior to 2 and current program space to 2. On exit, only the original inferior is restored, so we end up with current inferior == 1 and current program space == 2. The problem can be observed manually by starting two remote inferiors and disconnecting while inferior 1 is selected: $ ./gdb -nx --data-directory=data-directory -q \ -ex 'set sysroot /' \ -ex 'target extended-remote | gdbserver --multi --once -' \ -ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'set remote exec-file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'b main' \ -ex r \ -ex 'add-inferior' \ -ex 'inferior 2' \ -ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \ -ex 'run' \ -ex 'inferior 1' \ -ex 'disconnect' Then, connecting top-gdb to that gdb, we see the inconsistency: (top-gdb) p current_inferior_.m_obj.num $1 = 1 (top-gdb) p current_program_space.num $2 = 2 When the test tries to connect to a remote target again, GDB maps the remote inferior to inferior 1, but tries to set the solib_ops of program space 2, which already has an solib_ops set, causing the internal error. Fix this by using scoped_restore_current_program_space in addition to scoped_restore_current_inferior. With this patch applied, we get: (top-gdb) p current_inferior_.m_obj.num $1 = 1 (top-gdb) p current_program_space.num $2 = 1 With this patch, we then hit another internal error, fixed by the following patch. Change-Id: If916f581a223d6611f7f23a9cbbf1825d2cdd0ba Reviewed-By: Guinevere Larsen 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.replay Fix clean_restart in the test-case in gdb.replay. Tested on x86_64-linux, with target boards unix, native-gdbserver and native-extended-gdbserver. 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.reverse Fix clean_restart in the test-cases in gdb.reverse. Tested on: - x86_64-linux, target boards unix and unix/-m32 - aarch64-linux - ppc64le-linux - s390x-linux 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.rocm Fix clean_restart in the test-cases in gdb.rocm. Since these test-cases are unsupported for me, do the simple substitution: ... clean_restart $binfile -> clean_restart gdb_load $binfile ... 2025-09-02 H.J. Lu readelf: Report if no GOT section found Update "readelf --got-contents" to report if no GOT section found. * readelf.c (process_got_section_contents): Report if no GOT section found. * testsuite/binutils-all/readelf-got.d: New file. * testsuite/binutils-all/readelf.exp: Run readelf-got. 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.server Fix clean_restart in the test-cases in gdb.server. Tested on x86_64-linux. 2025-09-02 Richard Earnshaw arm: rework fix for PR gas/15273 PR gas/15273 The apparent intent of the original code added in https://sourceware.org/pipermail/binutils/2012-August/078044.html was to emit an error message if the instruction was obsolete and only to emit a deprecation warning if an error hadn't already been emitted. However, when the insn has not yet been obsoleted, the code would generate a warning with a (null) message body if the selected CPU was 'any'. The previous fix for this bug was to remove the support for the obsoletion message entirely, which was probably the wrong approach. A better fix is to only call check_obsolete if obs_msg is non-null; we can use this as a proxy for the instruction not being obsolete on any architecture. While we are here, fix an incorrect capitalization in the deprecation message ('This' to 'this'). 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.testsuite Fix clean_restart in the test-cases in gdb.testsuite. Tested on x86_64-linux. 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.threads Fix clean_restart in the test-cases in gdb.threads. Tested on x86_64-linux. 2025-09-02 Pedro Alves Fix host_file_normalize_mingw Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map: ... /bin C:/msys64/usr/bin /c C: / C:/msys64 ... and ran into the problem that host_file_normalize didn't translate: ... /home/user/gdb/build/gdb/testsuite/temp/n/x ... into: ... C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x ... The problem is that host_file_normalize_mingw mishandles a file/directory under the root mount point. A simpler reproducer is "/foo". If we add that as a test to gdb.testsuite/mount-point-map.exp, we see: input: /foo expected: C:/msys64/foo/ got: /foo FAIL: gdb.testsuite/mount-point-map.exp: /foo For a mount point that ends in /, this line in host_file_normalize_mingw: } elseif {[string index $filename $mount_len] eq "/"} { ... is always false, because the character at $mount_len is the one _after_ the slash. Notice that the "/" mount point is the only one that ends in "/". This is even if you try to create one explicitly with a trailing /. On MSYS2: $ mount c:/foo /foo/ mount: warning - /foo/ does not exist. $ mount C:/foo on /foo type ntfs (binary,user) ... So fix this by special casing the "/" mount point. And then... while playing with fixing this, I noticed I had done something strange with this case: if {[string length $filename] == $mount_len} { return "$win_filename/" The intent was to append the slash when the mount is a drive letter, like 'cygpath -ma' does: $ cygpath -ma /c C:/ Other cases do not get a trailing slash: $ cygpath -ma /c/foo C:/foo I think this is because on Windows, every drive letter has a current directory, and really "C:" means "current directory of drive letter C:", not "root of C:". Resolving it to "C:/" makes it unambiguous. However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix <-> Windows path conversion'). The original version of that patch when I posted it to the mailing list only supported drive mounts, which turned out incorrect, and then I generalized it to work with all mount points before it was merged. In the process, I inadvertently made the code append the slash whenever the input filename matches a mount exactly, any mount. I also now noticed that TCL's "file normalize" on Linux always removes the trailing slash, and since host_file_normalize is an abstraction for it, I think host_file_normalize_mingw should do the same. Likewise for duplicate slashes, "file normalize" gets rid of them. Fix all this in host_file_normalize_mingw, and add corresponding tests to gdb.testsuite/mount-point-map.exp. I smoke tested this here with a few of the testcases that required tweaking in the patch that added host_file_normalize, like gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass. Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and msys2-ucrt64, and it passed in both cases. Change-Id: I852a8662f0cb8b0ee4e683e9b157618cf6955477 2025-09-02 Tom de Vries Add gdb.testsuite/mount-point-map.exp Proc host_file_normalize is structured like this: ... proc host_file_normalize {filename} { if {[ishost *-*-mingw*]} { ... } return [file normalize $filename] ... so a testcase exercising the mingw specific part can only be run on a mingw host. Factor out a new proc host_file_normalize_mingw, which can be used on any host platform. Add testcase gdb.testsuite/mount-point-map.exp, exercising host_file_normalize_mingw. Tested on aarch64-linux, x86-64-linux, msys2-ucrt64, and msys2-mingw. Co-Authored-By: Pedro Alves Change-Id: Ia130de5c12c940852b6367c422d04896863bfc02 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.trace Fix clean_restart in the test-cases in gdb.trace. Tested on x86_64-linux, with target boards unix, native-gdbserver and native-extended-gdbserver. 2025-09-02 Tom de Vries [gdb/testsuite] Fix clean_restart in gdb.tui Fix clean_restart in the test-cases in gdb.tui. Tested on x86_64-linux. 2025-09-02 Haochen Jiang x86/testsuite: Adjust unused FRED and MOVRS tests [PR33348] The tests mentioned in PR33348 needs different care. For FRED tests, we could simply remove them since there are no operands and the tests are the same as AT&T Syntax. For MOVRS tests, we allowed suffixes for AT&T suffixes although we could tell the difference according to register operand to align with legacy mov. Thus, the suffixes tests are needed for AT&T Syntax while not needed for Intel Syntax. Adjust them accordingly. gas/ChangeLog: PR ld/33348 * testsuite/gas/i386/x86-64-movrs-suffix.d: Describe the test with more precise. * testsuite/gas/i386/x86-64-movrs-suffix.s: Remove Intel Syntax part. * testsuite/gas/i386/x86-64.exp: Add MOVRS suffix tests. * testsuite/gas/i386/x86-64-fred-intel.d: Removed. * testsuite/gas/i386/x86-64-movrs-suffix-intel.d: Ditto. 2025-09-02 Lulu Cai LoongArch: Fix incorrect display of FDEs address ranges when using objdump -Wf When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to help `objdump` correctly compute the address ranges of the FDEs. Apply the same modification to BFD_RELOC_LARCH_64_PCREL. 2025-09-02 GDB Administrator Automatic date update in version.in 2025-09-01 acazuc aarch64: Fix -i option for aarch64-gen Only the long option --gen-idx was recognized to generate aarch64-tbl-2.h 2025-09-01 Alan Modra Re: readelf: Add --got-contents option The cris ld testsuite uses readelf -a. The extra output now means that a number of tests fail. Fix that by not using -a, but rather the options corresponding to output checked in the dump files. * testsuite/ld-cris/tls-local-63.d: Replace -a option with -r -s. Remove now unnecessary #... and superfluous unwind message. * testsuite/ld-cris/tls-local-64.d: Likewise. * testsuite/ld-cris/tls-und-38.d: Likewise. * testsuite/ld-cris/tls-und-42.d: Likewise. * testsuite/ld-cris/tls-und-46.d: Likewise. * testsuite/ld-cris/tls-und-50.d: Likewise. * testsuite/ld-cris/weakref3.d: Replace -a with -S -r -s, and remove unwind message. * testsuite/ld-cris/weakref4.d: Likewise. 2025-09-01 Tom de Vries [gdb] Fix handling of aborted inferior call PR gdb/33069 reports the following behavior: ... $ gdb -q ls -ex starti -ex "b *1" Reading symbols from ls... (No debugging symbols found in ls) Starting program: /usr/bin/ls Program stopped. 0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2 Breakpoint 1 at 0x1 (gdb) p (int)strlen("abc") Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x1 Command aborted. An error occurred while in a function called from GDB. Evaluation of the expression containing the function (malloc@plt) will be abandoned. When the function is done executing, GDB will silently stop. [1]+ Stopped gdb -q ls -ex starti -ex "b *1" $ fg gdb -q ls -ex starti -ex "b *1" (gdb) ... with gdb being unresponsive to further input. PR gdb/33068 reports a similar problem, but using gdbserver, and in that case gdb doesn't go into the background, but is likewise unresponsive. This is a regression since commit b1c0ab20809 ("gdb: avoid double stop after failed breakpoint condition check"), and consequently since release gdb 14.1. The commit changed this in run_inferior_call: ... if (current_ui->prompt_state == PROMPT_BLOCKED) - current_ui->unregister_file_handler (); - else - current_ui->register_file_handler (); + { + if (call_thread->thread_fsm ()->finished_p ()) + async_disable_stdin (); + else + async_enable_stdin (); + } ... which means current_ui->register_file_handler is no longer called in the current_ui->prompt_state == PROMPT_NEEDED case. Fix this by: - restoring this behavior, fixing the unresponsiveness, and - adding target_terminal::ours alongside it, fixing the problem that gdb goes into the background. Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for the unresponsiveness issue. The problem of gdb going into the background did not reproduce in the test-case. Tested on x86_64-linux. Reviewed-By: Keith Seitz Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33068 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33069 2025-09-01 GDB Administrator Automatic date update in version.in 2025-08-31 Rainer Orth ld: Move Solaris/sparcv9 TEXT_START_ADDR to elf64_sparc_sol2.sh While looking at the Solaris versions of the program header p_vaddr and p_align values of the text and data segments, I noticed that the Solaris/sparcv9 version of TEXT_START_ADDR is defined in a shared file. Since there's a Solaris/sparcv9 specific file now (ld/emulparams/elf64_sparc_sol2.sh), it seems cleaner to move it there. Tested on {sparcv9,sparc}-sun-solaris2.11 and {sparc64,sparc}-unknown-linux-gnu. 2025-07-29 Rainer Orth ld: * emulparams/elf64_sparc.sh (TEXT_START_ADDR): Move ... * emulparams/elf64_sparc_sol2.sh (TEXT_START_ADDR): ... here. 2025-08-31 Simon Marchi gdbsupport: remove unecessary template on iterator_range constructor This is a copy-pasto. Change-Id: I947772f6a694b33e393762dbf2931ebe2031c1c5 2025-08-31 GDB Administrator Automatic date update in version.in 2025-08-30 Simon Marchi gdb: fix include guard in arch/aarch64-gcs-linux.h Fix: $ gdb/check-include-guards.py gdb/arch/aarch64-gcs-linux.h gdb/arch/aarch64-gcs-linux.h:20: wrong symbol in ifndef Change-Id: I7586d5c22abe11501f59439df2b4a73bff7d201e 2025-08-30 Simon Marchi gdb/testsuite: run black on gdb.base/inline-frame-cycle-unwind.py Change-Id: Ib15ecd6c03fce9d50a0121bbcb910e2fa05cc5f9 gdb/testsuite: remove leftover debug print Change-Id: Ifb1dab85891200cadb4b4f59661450a03b0c6abd 2025-08-30 Simon Marchi gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic linker") regressed test gdb.base/break-probes.exp with the native-gdbserver board: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ... FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited) FAIL: gdb.base/break-probes.exp: call (int) foo(23) In the logs, we see this: Stopped due to shared library event: Inferior unloaded target:/lib64/ld-linux-x86-64.so.2 Inferior loaded target:/lib64/ld-linux-x86-64.so.2 When we should see this: Stopped due to shared library event (no libraries added or removed) In the unexpected output, GDB claims that the inferior unloaded and then loaded the dynamic linker. This is obviously not true. Commit d33a66a31134 changed the svr4_same function to consider the debug bases the solibs come from. Two solibs with the same inferior address but different debug base (such as the multiple solibs representing the dynamic linker in all the namespaces) now compare unequal. That commit also introduced a mechanism to update the debug base of an existing solib (more precisely, field lm_info_svr4::debug_base) when that value becomes known. The solib for the dynamic linker view in the default namespace starts with a debug base of 0, and is then changed to have the real debug base address later on. With the particular code path taken when connecting to a remote target, nothing triggers the update of the debug base of the dynamic linker solib initially created with a debug base of 0. So when svr4_solib_ops::current_sos returns a list with an solib for the dynamic linker with the real debug base value, the core sees this as an unload and a load. This happens specifically when debuggin remotely, because, svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which doesn't do any svr4_solib_ops::default_debug_base call. In local, we don't take that branch, which leads us to a call to default_debug_base. The way I propose to fix it is to add a call to svr4_solib_ops::default_debug_base at the beginning of svr4_solib_ops::current_sos. The rationale to put it there is that if the core is requesting a fresh list of libraries, and then compare that list with what it had previously, then we better make sure that the core's list has received the debug base update, if one is needed. Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6 Approved-by: Kevin Buettner 2025-08-30 GDB Administrator Automatic date update in version.in 2025-08-29 Thiago Jung Bauermann GDB: doc: Document Linux AArch64 support for Guarded Control Stacks Add NEWS entry and new sections to the "Configuration-Specific Information" and "Standard Target Features" parts of the manual. Reviewed-By: Eli Zaretskii Approved-By: Luis Machado 2025-08-29 Thiago Jung Bauermann GDB: aarch64-linux: Support unwinding the GCSPR The GCSPR is almost always updated implicitly by the hardware, so the compiler doesn't generate DWARF unwind information for it. Therefore add an unwinding function that calculates the value of the GCSPR in the previous frame based on its value in this frame. Some sanity checking is done by confirming that the calculated value is within a Guarded Control Stack memory area. This function is the same as amd64_linux_dwarf2_prev_ssp, written by Christina Schimpe to unwind Intel's SSP register. The gdb.arch/aarch64-gcs-return.exp testcase is lightly adapted from gdb.arch/amd64-shadow-stack-cmds.exp. Reviewed-By: Christina Schimpe Approved-By: Luis Machado 2025-08-29 Thiago Jung Bauermann GDB: aarch64-linux: Implement GCS support in displaced stepping When doing displaced step on a branch and link instruction with the Guarded Control Stack enabled, it's necessary to manually push and pop the GCS entry for the function call since GDB writes a simple branch instruction rather than a branch and link instruction in the displaced step buffer. The testcase exercises GCS with displaced stepping by putting the breakpoint on the bl instruction to force GDB to copy it to the displaced stepping buffer. In this situation GDB needs to manually manage the Guarded Control Stack. Reviewed-By: Christina Schimpe Approved-By: Luis Machado 2025-08-29 Thiago Jung Bauermann GDB: aarch64-linux: GCS support in Linux signals The signal frame can have a GCS context, so teach GDB how to use it. Also, there's a new SEGV sigcode when the inferior does an illegal memory access in the Guarded Control Stack, so display a message when that is the case. Reviewed-By: Christina Schimpe Approved-By: Luis Machado 2025-08-29 Thiago Jung Bauermann GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support Add the org.gnu.gdb.aarch64.gcs feature with the GCSPR register, and the org.gnu.gdb.aarch64.gcs.linux feature with "registers" to represent the Linux kernel ptrace and prctl knobs that enable and lock specific GCS functionality. This code supports GCS only in Linux userspace applications, so the GCSPR that is exposed is the one at EL0. Also, support for calling inferior functions is enabled by adding an implementation for the shadow_stack_push gdbarch method. If for some reason a target description contains the org.gnu.gdb.aarch64.gcs feature but not the org.gnu.gdb.aarch64.gcs.linux feature then GCS support is disabled and GDB continues the debugging session. Features that need GCS support (for example, calling inferior functions) will not work and the inferior will get a segmentation fault signal instead. There's a testcase for this scenario but it only checks the native debugging case, even though in practice this problem would only occur in remote debugging with a broken stub or gdbserver. I tested manually with a gdbserver hacked to send a broken target description and it worked as described. Testcases gdb.arch/aarch64-gcs.exp, gdb.arch/aarch64-gcs-core.exp and gdb.arch/aarch64-gcs-wrong-tdesc.exp are included to cover the added functionality. Reviewed-By: Christina Schimpe Approved-By: Luis Machado 2025-08-29 Simon Marchi gdb/objfiles: use filtered_iterator as objfile::section_iterator objfile::section_iterator looks like a good candidate to be implemented with filtered_iterator. Following the enhancements to filtered_iterator in the previous patch, it's pretty straighforward. I removed the non-const version of objfile::sections, because it didn't seem useful to have the two methods returning the exact same type and value. Having just the const version achieves the same thing. Change-Id: I2f29c2fb3f95605cb816cc1ff8935c10e0496052 Approved-By: Tom Tromey 2025-08-29 Simon Marchi gdbsupport: make filtered_iterator work with pointers It's currently not possible to use filtered_iterator with a pointer as the base iterator type. This patch makes it possible. The indended usage is: Foo array[12]; Foo *begin = array; Foo *end = array + ARRAY_SIZE (array); filtered_iterator (begin, end); Here are the things that needed changing: - Give filtered_iterator a constructor where the caller provides already constructed begin and end iterators. filtered_iterator currently assumes that default-constructing a BaseIterator will produce a valid "end" iterator. This is not the case if BaseIterator is a pointer. The caller needs to pass in the end of the array / region to iterate on as the end. - Typedefs of member types like wouldn't work: typedef typename BaseIterator::value_type value_type; The compiler would complain that it's not possible to apply `::` to type `BaseIterator` (aka `Foo *`). Use std::iterator_traits to fix it [1]. - Similarly, the compiler would complain about the use of `BaseIterator::operator*` in the return type of `filtered_iterator::operator*`. Fix this by using `decltype(auto)` as the return type. This lets the compiler deduce the return type from the return statement. Unlike `auto`, `decltype(auto)` perfectly preserves the "cvref-ness" of the deduced return type. If the return expression yields a `Foo &`, then the function will return a `Foo &` (which is what we want), whereas it would return a `Foo` if we used just `auto`. Improve the filtered_iterator unit tests to run the same tests but with pointers as iterators. Because the filtered_iterator objects are initialized differently in the two scenarios, I chose to copy the existing code and adapt it. It would probably be possible to add a layer of abstraction to avoid code duplication, but it would end up more complicated and messy. If we ever add a third scenario, we can revisit that. [1] https://en.cppreference.com/w/cpp/iterator/iterator_traits.html Change-Id: Id962ffbcd960a705a82bc5eb4808b4fe118a2761 Approved-By: Tom Tromey 2025-08-29 Christina Schimpe gdb: Enable displaced stepping with shadow stack on amd64 linux. Currently, if displaced stepping is active and the single stepped instruction is a call instruction, the return address atop the stack is the address following the copied instruction. However, to allow normal program execution it has to be the address following the original instruction. Due to that reason, the return address is corrected in amd64_displaced_step_fixup and i386_displaced_step_fixup. For programs that are shadow-stack enabled we see a control-protection exception, as the address on the shadow stack does not match the address atop the stack. Fix this by correcting the shadow stack top address as well. Approved-By: Andrew Burgess Approved-By: Luis Machado Reviewed-By: Eli Zaretskii 2025-08-29 Christina Schimpe gdb, gdbarch: Introduce gdbarch method to get the shadow stack pointer. This patch is required by the following commit "gdb: Enable displaced stepping with shadow stack on amd64 linux." Reviewed-By: Thiago Jung Bauermann Approved-By: Luis Machado Approved-By: Andrew Burgess 2025-08-29 Christina Schimpe gdb: Implement amd64 linux shadow stack support for inferior calls. This patch enables inferior calls to support Intel's Control-Flow Enforcement Technology (CET), which provides the shadow stack feature for the x86 architecture. Following the restriction of the linux kernel, enable inferior calls for amd64 only. Reviewed-by: Thiago Jung Bauermann Reviewed-By: Eli Zaretskii Approved-By: Luis Machado Approved-By: Andrew Burgess 2025-08-29 Christina Schimpe gdb, gdbarch: Enable inferior calls for shadow stack support. Inferior calls in GDB reset the current PC to the beginning of the function that is called. As no call instruction is executed the new return address needs to be pushed to the shadow stack and the shadow stack pointer needs to be updated. This commit adds a new gdbarch method to push an address on the shadow stack. The method is used to adapt the function 'call_function_by_hand_dummy' for inferior call shadow stack support. Reviewed-By: Thiago Jung Bauermann Approved-By: Luis Machado Approved-By: Andrew Burgess 2025-08-29 Christina Schimpe gdb: Handle shadow stack pointer register unwinding for amd64 linux. Unwind the $pl3_ssp register. We now have an updated value for the shadow stack pointer when moving up or down the frame level. Note that $pl3_ssp can become unavailable when moving to a frame before the shadow stack enablement. In the example below, shadow stack is enabled in the function 'call1'. Thus, when moving to a frame level above the function, $pl3_ssp will become unavaiable. Following the restriction of the linux kernel, implement the unwinding for amd64 linux only. Before this patch: ~~~ Breakpoint 1, call2 (j=3) at sample.c:44 44 return 42; (gdb) p $pl3_ssp $1 = (void *) 0x7ffff79ffff8 (gdb) up 55 call2 (3); (gdb) p $pl3_ssp $2 = (void *) 0x7ffff79ffff8 (gdb) up 68 call1 (43); (gdb) p $pl3_ssp $3 = (void *) 0x7ffff79ffff8 ~~~ After this patch: ~~~ Breakpoint 1, call2 (j=3) at sample.c:44 44 return 42; (gdb) p $pl3_ssp $1 = (void *) 0x7ffff79ffff8 (gdb) up 55 call2 (3); (gdb) p $pl3_ssp $2 = (void *) 0x7ffff7a00000 (gdb) up 68 call1 (43i); (gdb) p $pl3_ssp $3 = ~~~ As we now have an updated value for each selected frame, the return command is now enabled for shadow stack enabled programs, too. We therefore add a test for the return command and shadow stack support, and for an updated shadow stack pointer after a frame level change. Reviewed-By: Thiago Jung Bauermann Approved-By: Luis Machado Approved-By: Andrew Burgess 2025-08-29 Christina Schimpe gdb: amd64 linux coredump support with shadow stack. Intel's Control-Flow Enforcement Technology (CET) provides the shadow stack feature for the x86 architecture. This commit adds support to write and read the shadow-stack node in corefiles. This helps debugging return address violations post-mortem. The format is synced with the linux kernel commit "x86: Add PTRACE interface for shadow stack". As the linux kernel restricts shadow stack support to 64-bit, apply the fix for amd64 only. Co-Authored-By: Christina Schimpe Reviewed-By: Thiago Jung Bauermann Approved-By: Luis Machado Approved-By: Andrew Burgess --- The code and testcase are lightly adapted from: [PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html 2025-08-29 Christina Schimpe gdb, gdbserver: Add support of Intel shadow stack pointer register. This patch adds the user mode register PL3_SSP which is part of the Intel(R) Control-Flow Enforcement Technology (CET) feature for support of shadow stack. For now, only native and remote debugging support for shadow stack userspace on amd64 linux are covered by this patch including 64 bit and x32 support. 32 bit support is not covered due to missing Linux kernel support. This patch requires fixing the test gdb.base/inline-frame-cycle-unwind which is failing in case the shadow stack pointer is unavailable. Such a state is possible if shadow stack is disabled for the current thread but supported by HW. This test uses the Python unwinder inline-frame-cycle-unwind.py which fakes the cyclic stack cycle by reading the pending frame's registers and adding them to the unwinder: ~~~ for reg in pending_frame.architecture().registers("general"): val = pending_frame.read_register(reg) unwinder.add_saved_register(reg, val) return unwinder ~~~ However, in case the python unwinder is used we add a register (pl3_ssp) that is unavailable. This leads to a NOT_AVAILABLE_ERROR caught in gdb/frame-unwind.c:frame_unwind_try_unwinder and it is continued with standard unwinders. This destroys the faked cyclic behavior and the stack is further unwinded after frame 5. In the working scenario an error should be triggered: ~~~ bt 0 inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:49^M 1 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M 2 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M 3 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M 4 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M 5 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 ~~~ To fix the Python unwinder, we simply skip the unavailable registers. Also it makes the test gdb.dap/scopes.exp fail. The shadow stack feature is disabled by default, so the pl3_ssp register which is added with my CET shadow stack series will be shown as unavailable and we see a TCL error: ~~ >>> {"seq": 12, "type": "request", "command": "variables", "arguments": {"variablesReference": 2, "count": 85}} Content-Length: 129^M ^M {"request_seq": 12, "type": "response", "command": "variables", "success": false, "message": "value is not available", "seq": 25}FAIL: gdb.dap/scopes.exp: fetch all registers success ERROR: tcl error sourcing /tmp/gdb/testsuite/gdb.dap/scopes.exp. ERROR: tcl error code TCL LOOKUP DICT body ERROR: key "body" not known in dictionary while executing "dict get $val body variables" (file "/tmp/gdb/testsuite/gdb.dap/scopes.exp" line 152) invoked from within "source /tmp/gdb/testsuite/gdb.dap/scopes.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /tmp/gdb/testsuite/gdb.dap/scopes.exp" invoked from within "catch "uplevel #0 source $test_file_name" msg" UNRESOLVED: gdb.dap/scopes.exp: testcase '/tmp/gdb/testsuite/gdb.dap/scopes.exp' aborted due to Tcl error ~~ I am fixing this by enabling the test for CET shadow stack, in case we detect that the HW supports it: ~~~ # If x86 shadow stack is supported we need to configure GLIBC_TUNABLES # such that the feature is enabled and the register pl3_ssp is # available. Otherwise the reqeust to fetch all registers will fail # with "message": "value is not available". if { [allow_ssp_tests] } { append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" } ~~~ Reviewed-by: Thiago Jung Bauermann Reviewed-By: Eli Zaretskii Approved-By: Luis Machado Approved-By: Andrew Burgess 2025-08-29 Christina Schimpe gdb, gdbserver: Use xstate_bv for target description creation on x86. The XSAVE function set is organized in state components, which are a set of registers or parts of registers. So-called XSAVE-supported features are organized using state-component bitmaps, each bit corresponding to a single state component. The Intel Software Developer's Manual uses the term xstate_bv for a state-component bitmap, which is defined as XCR0 | IA32_XSS. The control register XCR0 only contains a state-component bitmap that specifies user state components, while IA32_XSS contains a state-component bitmap that specifies supervisor state components. Until now, XCR0 is used as input for target description creation in GDB. However, a following patch will add userspace support for the CET shadow stack feature by Intel. The CET state is configured in IA32_XSS and consists of 2 state components: - State component 11 used for the 2 MSRs controlling user-mode functionality for CET (CET_U state) - State component 12 used for the 3 MSRs containing shadow-stack pointers for privilege levels 0-2 (CET_S state). Reading the CET shadow stack pointer register on linux requires a separate ptrace call using NT_X86_SHSTK. To pass the CET shadow stack enablement state we would like to pass the xstate_bv value instead of xcr0 for target description creation. To prepare for that, we rename the xcr0 mask values for target description creation to xstate_bv. However, this patch doesn't add any functional changes in GDB. Future states specified in IA32_XSS such as CET will create a combined xstate_bv_mask including xcr0 register value and its corresponding bit in the state component bitmap. This combined mask will then be used to create the target descriptions. Reviewed-By: Thiago Jung Bauermann Approved-By: Luis Machado 2025-08-29 Christina Schimpe gdb: Sync up x86-gcc-cpuid.h with cpuid.h from gcc 14 branch. This is required for a later commit which requires "bit_SHSTK". Reviewed-by: Thiago Jung Bauermann Approved-By: Tom Tromey Approved-By: Luis Machado 2025-08-29 Christina Schimpe gdbserver: Add assert in x86_linux_read_description. On x86 the PTRACE_GETREGSET request is currently only used for the xstate regset. The size of the xstate regset is initialized to 0 such that it can be reset to the appropriate size once we know it is supported for the current target in x86_linux_read_description. However, this configuration would not just affect the xstate regset but any regset with PTRACE_GETREGSET request that is added in the future. The new regset would be misconfigured with the xstate regset size. To avoid this we add an assert for unsupported regsets and check explicitly for the note type of the register set. Reviewed-by: Thiago Jung Bauermann Approved-By: Luis Machado 2025-08-29 Christina Schimpe gdbserver: Add optional runtime register set type. Some register sets can be activated and deactivated by the OS during the runtime of a process. One example register is the Intel CET shadow stack pointer. This patch adds a new type of register set to handle such cases. We shouldn't deactivate these regsets and should not show a warning if the register set is not active but supported by the kernel. However, it is safe to deactivate them, if they are unsupported by the kernel. To differentiate those scenarios we can use the errno returned by the ptrace call. Reviewed-by: Thiago Jung Bauermann Approved-By: Luis Machado 2025-08-29 Christina Schimpe gdb, testsuite: Extend core_find procedure to save program output. From: Thiago Jung Bauermann The change comes from ARM's GCS series: [PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support. We need it for testing coredump files, too. So include it in this patch series. Abridged-by: Christina Schimpe Approved-By: Luis Machado Approved-By: Andrew Burgess --- This is the patch mentioned above: https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html Minus everything except for the change in gdb.exp's corefind procedure. 2025-08-29 Simon Marchi gdb/objfiles: make objfile::sections yield references I wrote this as a preparatory patch while attempting to make objfile::section_iterator use filtered_iterator. It turned out not so easy, so I have put it aside for now. But now I have this patch, so I thought I'd send it by itself. Since the `obj_section *` yielded by the iterator can't be nullptr, I think it makes sense for the iterator to yield references instead. Just like you would get if you iterated on an std::vector. Change-Id: I7bbee50ed52599e64c4f3b06bdbbde597feba9aa 2025-08-29 Tom de Vries [gdb/testsuite] Fix overlapping CUs in gdb.dwarf2/dw2-linkage-name-trust.exp When running test-case gdb.dwarf2/dw2-linkage-name-trust.exp with target board cc-with-gdb-index, I get: ... (gdb) file dw2-linkage-name-trust^M Reading symbols from dw2-linkage-name-trust...^M warning: .gdb_index address table has a range (0x4006ac - 0x4006cc) that \ overlaps with an earlier range, ignoring .gdb_index^M (gdb) delete breakpoints^M ... Fix this by compiling with nodebug. Tested on aarch64-linux. Approved-By: Tom Tromey PR testsuite/33315 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315 2025-08-29 Tom de Vries [gdb/testsuite] Fix overlapping CUs in gdb.dwarf2/dw2-entry-points.exp When running test-case gdb.dwarf2/dw2-entry-points.exp with target board cc-with-gdb-index, I get: ... (gdb) file dw2-entry-points^M Reading symbols from dw2-entry-points...^M warning: .gdb_index address table has a range (0x40066c - 0x4006e4) that \ overlaps with an earlier range, ignoring .gdb_index^M (gdb) delete breakpoints^M ... Fix this by copying function bar_helper to barso_helper, and using it where appropriate. Tested on aarch64-linux. Approved-By: Tom Tromey PR testsuite/33315 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33315 2025-08-29 Andrew Burgess gdb: use kill() in gdbpy_interrupt for hosts with signal support For background, see this thread: https://inbox.sourceware.org/gdb-patches/20250612144607.27507-1-tdevries@suse.de Tom describes the issue clearly in the above thread, here's what he said: Once in a while, when running test-case gdb.base/bp-cmds-continue-ctrl-c.exp, I run into: ... Breakpoint 2, foo () at bp-cmds-continue-ctrl-c.c:23^M 23 usleep (100);^M ^CFAIL: $exp: run: stop with control-c (unexpected) (timeout) FAIL: $exp: run: stop with control-c ... This is PR python/32167, observed both on x86_64-linux and powerpc64le-linux. This is not a timeout due to accidental slowness, gdb actually hangs. The backtrace at the hang is (on cfarm120 running AlmaLinux 9.6): ... (gdb) bt #0 0x00007fffbca9dd94 in __lll_lock_wait () from /lib64/glibc-hwcaps/power10/libc.so.6 #1 0x00007fffbcaa6ddc in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/glibc-hwcaps/power10/libc.so.6 #2 0x000000001067aee8 in __gthread_mutex_lock () at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:749 #3 0x000000001067afc8 in __gthread_recursive_mutex_lock () at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:811 #4 0x000000001067b0d4 in std::recursive_mutex::lock () at /usr/include/c++/11/mutex:108 #5 0x000000001067b380 in std::lock_guard::lock_guard () at /usr/include/c++/11/bits/std_mutex.h:229 #6 0x0000000010679d3c in set_quit_flag () at gdb/extension.c:865 #7 0x000000001066b6dc in handle_sigint () at gdb/event-top.c:1264 #8 0x00000000109e3b3c in handler_wrapper () at gdb/posix-hdep.c:70 #9 #10 0x00007fffbcaa6d14 in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/glibc-hwcaps/power10/libc.so.6 #11 0x000000001067aee8 in __gthread_mutex_lock () at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:749 #12 0x000000001067afc8 in __gthread_recursive_mutex_lock () at /usr/include/c++/11/ppc64le-redhat-linux/bits/gthr-default.h:811 #13 0x000000001067b0d4 in std::recursive_mutex::lock () at /usr/include/c++/11/mutex:108 #14 0x000000001067b380 in std::lock_guard::lock_guard () at /usr/include/c++/11/bits/std_mutex.h:229 #15 0x00000000106799cc in set_active_ext_lang () at gdb/extension.c:775 #16 0x0000000010b287ac in gdbpy_enter::gdbpy_enter () at gdb/python/python.c:232 #17 0x0000000010a8e3f8 in bpfinishpy_handle_stop () at gdb/python/py-finishbreakpoint.c:414 ... What happens here is the following: - the gdbpy_enter constructor attempts to set the current extension language to python using set_active_ext_lang - set_active_ext_lang attempts to lock ext_lang_mutex - while doing so, it is interrupted by sigint_wrapper (the SIGINT handler), handling a SIGINT - sigint_wrapper calls handle_sigint, which calls set_quit_flag, which also tries to lock ext_lang_mutex - since std::recursive_mutex::lock is not async-signal-safe, things go wrong, resulting in a hang. The hang bisects to commit 8bb8f834672 ("Fix gdb.interrupt race"), which introduced the lock, making PR python/32167 a regression since gdb 15.1. Commit 8bb8f834672 fixes PR dap/31263, a race reported by ThreadSanitizer: ... WARNING: ThreadSanitizer: data race (pid=615372) Read of size 1 at 0x00000328064c by thread T19: #0 set_active_ext_lang(extension_language_defn const*) gdb/extension.c:755 #1 scoped_disable_cooperative_sigint_handling::scoped_disable_cooperative_sigint_handling() gdb/extension.c:697 #2 gdbpy_interrupt gdb/python/python.c:1106 #3 cfunction_vectorcall_NOARGS Previous write of size 1 at 0x00000328064c by main thread: #0 scoped_disable_cooperative_sigint_handling::scoped_disable_cooperative_sigint_handling() gdb/extension.c:704 #1 fetch_inferior_event() gdb/infrun.c:4591 ... Location is global 'cooperative_sigint_handling_disabled' of size 1 at 0x00000328064c ... SUMMARY: ThreadSanitizer: data race gdb/extension.c:755 in \ set_active_ext_lang(extension_language_defn const*) ... The problem here is that gdb.interrupt is called from a worker thread, and its implementation, gdbpy_interrupt races with the main thread on some variable. The fix presented here is based on the fix that Tom proposed, but fills in the missing Mingw support. The problem is basically split into two: hosts that support unix like signals, and Mingw, which doesn't support signals. For signal supporting hosts, I've adopted the approach that Tom suggests, gdbpy_interrupt uses kill() to send SIGINT to the GDB process. This is then handled in the main thread as if the user had pressed Ctrl+C. For these hosts no locking is required, so the existing lock is removed. However, everywhere the lock currently exists I've added an assert: gdb_assert (is_main_thread ()); If this assert ever triggers then we're setting or reading the quit flag on a worker thread, this will be a problem without the mutex. For Mingw, the current mutex is retained. This is fine as there are no signals, so no chance of the mutex acquisition being interrupted by a signal, and so, deadlock shouldn't be an issue. To manage the complexity of when we need an assert, and when we need the mutex, I've created 'struct ext_lang_guard', which can be used as a RAII object. This object either performs the assertion check, or acquires the mutex, depending on the host. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32167 Co-Authored-By: Tom de Vries Approved-By: Tom Tromey 2025-08-29 H.J. Lu readelf: Add --got-contents option Add --got-contents option to readelf, inspired by the -G option on Solaris, to display contents of GOT sections: $ readelf --got-contents libfoo.so Global Offset Table '.got' contains 1 entry: Index: Address Reloc Sym. Name + Addend/Value 0: 000000200340 R_X86_64_GLOB_DAT foo + 0 Global Offset Table '.got.plt' contains 4 entries: Index: Address Reloc Sym. Name + Addend/Value 0: 000000200348 200220 1: 000000200350 0 2: 000000200358 0 3: 000000200360 R_X86_64_JUMP_SLO bar + 0 When --got-content options are used: 1. Allocate an array, all_relocations, to hold all relocations. 2. Update dump_relr_relocations and dump_relocations to scan relocations and cache them in all_relocations. Don't display relocations if not requested. 3. Add process_got_section_contents to display contents of GOT sections by matching the GOT entry offset against the cached relocations. 4. Update process_mips_specific to only display the GOT related contents for --got-contents. binutils/ * NEWS: Mention "readelf --got-contents". * readelf.c (do_got_section_contents): New. (elf_relocation): Likewise. (all_relocations_root): Likewise. (all_relocations): Likewise. (all_relocations_count): Likewise. (update_all_relocations): Likewise. (dump_relr_relocations): Add a bool argument to indicate if relocations should be displayed. Populate all_relocations if do_got_section_contents is true. (dump_relocations): Likewise. (long_option_values): Add OPTION_GOT_CONTENTS. (options): Add --got-contents. (usage): Show --got-contents. (parse_args): Support --got-contents. (display_relocations): Add a bool argument, dump_reloc, to indicate if relocations should be displayed. Call update_all_relocations. Pass dump_reloc to dump_relr_relocations and dump_relocations. (process_relocs): Check do_got_section_contents. Handle do_got_section_contents for dynamic relocations. (process_section_contents): Pass true to display_relocations. (process_mips_specific): Add a bool argument, dump_got, to indicate if only the GOT related contents should be displayed. Display all MIPS specific information if dump_got is false. (elf_relocation_cmp): New. (display_elf_relocation_at): Likewise. (process_got_section_contents): Likewise. (process_object): Call process_got_section_contents. * doc/binutils.texi: Document --got-contents. ld/ * testsuite/ld-i386/binutils.exp: New file. * testsuite/ld-i386/got-1.s: Likewise. * testsuite/ld-i386/libgot-1a.rd: Likewise. * testsuite/ld-i386/libgot-1b.rd: Likewise. * testsuite/ld-i386/libgot-1c.rd: Likewise. * testsuite/ld-i386/libgot-1d.rd: Likewise. * testsuite/ld-x86-64/binutils.exp: Likewise. * testsuite/ld-x86-64/got-1.s: Likewise. * testsuite/ld-x86-64/libgot-1a-x32.rd: Likewise. * testsuite/ld-x86-64/libgot-1a.rd: Likewise. * testsuite/ld-x86-64/libgot-1b-x32.rd: Likewise. * testsuite/ld-x86-64/libgot-1b.rd: Likewise. * testsuite/ld-x86-64/libgot-1c-x32.rd: Likewise. * testsuite/ld-x86-64/libgot-1c.rd: Likewise. * testsuite/ld-x86-64/libgot-1d-x32.rd: Likewise. * testsuite/ld-x86-64/libgot-1d.rd: Likewise. 2025-08-29 Jan Beulich ld: drop bogus %F format modifiers Support for %F was dropped in 6d74c1f313df ("PR 32603 followup, remove %F from einfo"). 2025-08-29 H. Peter Anvin (Intel) x86: add "udb" opcode (permanent official #UD in 64-bit mode) The opcode D6 has been officially reserved as a single-byte permanent undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is already the behavior of all known 64-bit implementations; this is thus merely an official statement of forward compatibility and the assignment of a mnemonic. This will be documented in the next version of the Intel Software Developer's Manual; in the meantime I DO speak officially for Intel on this issue. The x86 Advisory Council has ratified this decision, and so it is expected to be honored across vendors, but I obviously cannot make any official statement on any other vendor's behalf. I am covered by the Intel-FSF copyright assignment for binutils. 2025-08-29 GDB Administrator Automatic date update in version.in 2025-08-28 Simon Marchi gdb/gdb-gdb.gdb.in: skip gdb::ref_ptr<.*>::get I think it's uninteresting to step into gdb::ref_ptr::get, so add a skip entry for it. I am adding just one to get the party started, but there are certainly more like this that we could skip. Change-Id: Ib074535c96a62137de63bbe58ff168a1e913688f Approved-By: Tom Tromey 2025-08-28 Simon Marchi gdb/testsuite: use gdb_test_no_output when dumping in gdb.base/dump.exp I don't know if this is true on all platforms, but from what I can see on Linux, the dump commands don't output anything. Use gdb_test_no_output, which should be a bit more robust than checking for some specific error patterns. Change-Id: Idc82298c4752ba7808659dfea2f8324c8a97052d Approved-By: Tom Tromey 2025-08-28 Christian Walther Fix documentation of -list-[target-]features results The manual claims that the -list-features and -list-target-features MI commands return their result in a field named "result". The field is actually named "features", and always has been since the introduction of these commands in 084344d and c6ebd6c. See mi_cmd_list_features and mi_cmd_list_target_features in gdb/mi/mi-main.c. Approved-By: Tom Tromey 2025-08-28 Christina Schimpe testsuite: add untested in case OS corefile is not found Even though the core_find proc will log a warning, it's better to log "untested" and then terminate the test. This will help to avoid silently skipped tests, when running the testsuite. Most of the tests already do that. This patch adds the missing ones. Approved-By: Luis Machado 2025-08-28 Tom Tromey Bump flake8 version "pre-commit autoupdate" pointed out that a newer version of flake8 has been released. This patch applies the update. No code changes were needed. Approved-By: Simon Marchi 2025-08-28 Andrew Burgess gdb/python: check return from final PyObject_New in py-disasm.c In this commit: commit dbd05b9edcf760a7001985f89bc760358a3c19d7 Date: Wed Aug 20 10:45:09 2025 +0100 gdb/python: check return value of PyObject_New in all cases I missed a call to PyObject_New in python/py-disasm.c, which this commit addresses. Unlike the previous commit, the call to PyObject_New in py-disasm.c is contained within the scoped_disasm_info_object class, which makes it harder to check for NULL and return. So in this commit I've rewritten the scoped_disasm_info_object class, moving the call to PyObject_New out into gdbpy_print_insn, which is the only place that scoped_disasm_info_object was being used. As scoped_disasm_info_object is no longer responsible for creating the underlying Python object, I figured that I might as well move the initialisation of that object out of scoped_disasm_info_object too. With that done, the scoped_disasm_info_object now has just one task, invalidating the existing disasm_info_object at the end of the scope. So I renamed scoped_disasm_info_object to scoped_invalidate_disasm_info, which reflects its only task. I made a couple of other small adjustments that were requested during review, these are both in the same code area: updating disasm_info_fill to take an object reference rather than a pointer, and removing the local variable insn_disas_obj from gdbpy_print_insn, and inline its value at the one place it was used. There should be no user visible changes after this commit. Except for the PyObject_New call, which now has proper error checking. But in the working case, nothing should have changed. Approved-By: Simon Marchi 2025-08-28 Simon Marchi gdb/objfiles: add comment explaining when obj_section::the_bfd_section is nullptr Change-Id: Iae17492f468efba7b76463a6ff8526171e412040 Reviewed-By: Tom de Vries 2025-08-28 Tom de Vries [gdb/testsuite] Use build_executable in gdb.tui/tui-missing-src.exp While looking at test-case gdb.tui/tui-missing-src.exp I noticed that gdb_compile is used to compile multiple sources: ... if { [gdb_compile "${srcfiles}" "${binfile}" \ executable {debug additional_flags=-O0}] != "" } { ... meaning there are no separate compile and link steps, as is required for fission [1]. Fix this by using build_executable instead. Tested on aarch64-linux. [1] https://gcc.gnu.org/wiki/DebugFission 2025-08-28 timurgol007 gdb/record: Support wfi, sfence.vma, sret and mret instructions in risc-v During testing of bare-metal applications on QEMU for RISC-V, it was discovered that the instructions wfi, sfence.vma, sret, and mret were not supported. This patch introduces support for these instructions. Additionally, it wraps fetch_instruction function in a try-catch block to gracefully handle errors that may occur when attempting to read invalid address. Reviewed-By: Guinevere Larsen Approved-By: Andrew Burgess 2025-08-28 Tom de Vries [gdb/testsuite] Fix require dwarf2_support check in some test-cases, some more The Linaro CI reported a regression in test-case gdb.dwarf2/macro-source-path-clang14-dw4.exp due to recent commit 81e5a23c7b8 ("[gdb/testsuite] Fix require dwarf2_support check in some test-cases"). The problem is that the "require dwarf2_support" in its new location doesn't work because proc dwarf2_support is not defined. I didn't notice this because I tested all gdb.dwarf2 test-cases together, and a different test-case had already imported the proc. Fix this by moving load_lib dwarf.exp earlier. Tested on x86_64-linux. 2025-08-28 H.J. Lu readelf: Update "-D -r" to dump DT_RELR 1. Update dump_relr_relocations to take relr_size, relr_entsize and relr_offset, instead of a pointer to Elf_Internal_Shdr, as function arguments. 2. Update process_relocs to call dump_relr_relocations if relocation type is reltype_relr. binutils/ PR binutils/33328 * readelf.c (dump_relr_relocations): Replace a pointer to Elf_Internal_Shdr argument with relr_size, relr_entsize and relr_offset. (display_relocations): Update the dump_relr_relocations call. (process_relocs): Call dump_relr_relocations if relocation type is reltype_relr. ld/ PR binutils/33328 * testsuite/ld-i386/dt-relr-1c.d: New file. * testsuite/ld-i386/dt-relr-1d.d: Likewise. * testsuite/ld-x86-64/dt-relr-1c-x32.d: Likewise. * testsuite/ld-x86-64/dt-relr-1c.d: Likewise. * testsuite/ld-x86-64/dt-relr-1d-x32.d: Likewise. * testsuite/ld-x86-64/dt-relr-1d.d: Likewise. * testsuite/ld-i386/i386.exp: Run PR binutils/33328 tests. * testsuite/ld-x86-64/x86-64.exp: Likewise. 2025-08-28 GDB Administrator Automatic date update in version.in 2025-08-27 Simon Marchi gdb/testsuite: get real executable in gdb.gdb/index-file.exp Similar to a previous patch, if the gdb executable is in fact a libtool wrapper, we need to get the path to the real executable to load it in the top-level gdb. With this change, the test runs on Cygwin, although I do see two failures: FAIL: gdb.gdb/index-file.exp: debug_names files are identical FAIL: gdb.gdb/index-file.exp: debug_str files are identical Change-Id: Ie06d1ece67e61530e5b664e65b5ef0edccaf6afa Reviewed-By: Keith Seitz 2025-08-27 Simon Marchi gdb/testsuite: turn thread events off in selftests When running gdb.gdb/selftest.exp on Cygwin, the test eventually times out on this command: (gdb) PASS: gdb.gdb/selftest.exp: printed version as pointer continue Continuing. [New Thread 4804.0x1728] [New Thread 4804.0x2f24] [New Thread 4804.0x934] [New Thread 4804.0x23a8] [New Thread 4804.0x2cf4] [New Thread 4804.0x1408] [New Thread 4804.0x2c90] [New Thread 4804.0xc58] [New Thread 4804.0x1d40] [New Thread 4804.0x1824] GNU gdb (GDB) 17.0.50.20250530-git Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) [New Thread 4804.0x2c64] [New Thread 4804.0x23c4] [New Thread 4804.0x2814] [Thread 4804.0x1200 exited with code 0] [Thread 4804.0x293c exited with code 0] [Thread 4804.0x2c9c exited with code 0] FAIL: gdb.gdb/selftest.exp: xgdb is at prompt (timeout) The problem is the new thread notification, and the fact that the test expects the prompt to be the last thing in the buffer. To avoid the thread events interfering with the test, disable them, they are not useful here. With this patch, gdb.gdb/selftest.exp mostly runs fine on Cygwin, the only remaining problem appears to be: (gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process signal SIGINT Continuing with signal SIGINT. PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process, top GDB message FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process, bottom GDB message (timeout) Change-Id: I0b1df0503c1961c042c8de559b4d223c5d3cb95c Reviewed-By: Keith Seitz 2025-08-27 Simon Marchi gdb/testsuite: use libtool to launch selftests When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which happens to be a PE executable). The real executable is at gdb/.libs/gdb.exe. The "does gdb have debug info test" that _selftest_setup does is bogus, because it loads the libtool wrapper (which doesn't have debug info), doesn't see any debug info, and thus the test is skipped. The "correct" way to deal with libtool wrappers is to run the shell command you want to run under `libtool --mode=execute`. That will replace any path resembling to a libtool wrapper with the real executable path. But it will also add to the environment the library paths necessary for this executable to find the libraries it needs. Therefore, modify the `do_self_tests` proc to: - run the top-level GDB commands under `libtool --mode=execute` - pass the path to the inferior GDB on the command-line of the top-level, so that it gets replaced with the real executable's path However, the "file" command was previously used to detect the presence of debug info in the GDB executable. It's not easy to implement this check when loading the executable directly on the command line. So, add a separate proc, _selftest_check_executable_debug_info, that spawns a temporary GDB and does the debug info check through the file command. This proc uses libtool to obtain the path to the real executable. When building, we use the bundled libtool.m4 at the top of the tree. This means that the libtool system package, and therefore the libtool binary, might not be available. Check for the presence of the libtool binary first, and only do the conversion if it is found. If it is not found, the test should still work on platforms that don't require the conversion. With this commit, the test runs on Cygwin, even though there are failures later. Change-Id: Ie7b712cdc84671a5a017655a7e41687ff23f906c Reviewed-By: Keith Seitz 2025-08-27 Simon Marchi gdb/testsuite: do not copy gdb executable in self tests In the ROCm-GDB testing process, we hit a problem that is a combination of these 3 factors: 1. In the downstream ROCm-GDB packages, the gdb executable is built with a relative RUNPATH: 0x000000000000001d (RUNPATH) Library runpath: [${ORIGIN}/../lib] This is done so that the installation is relocatable (the whole ROCm directory can be copied around) and things still work. For instance, the rocgdb executable needs to be able to find the libraries it needs, such as `librocm-dbgapi.so.0`. The relative runpath allows that. 2. For testing, we run the testsuite against the gdb executable installed from one of those packages. It is possible to ./configure the testsuite directory on its own, and then do: $ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb" 3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test to the standard output directory, before trying to debug it. The problem is that the gdb executable under test that has been copied can't find the libraries it needs. With this patch, I propose that we don't copy the gdb executable, but debug it in place instead. The comment removed in this patch says "in case this OS doesn't like to edit its own text space", and has been there since forever in some form. But it's not clear if there is a host OS (where we intend to run this test) that needs this nowadays. I would bet that there isn't. If there is in fact a GDB host OS (where we intend to run this test) that needs it, we can reinstate the copying, but as an opt-in operation. Another situation where this change helps is on Windows, where gdb/gdb.exe is a libtool wrapper (the real executable is at gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything useful. The next patch does further changes to account for the libtool wrapper case. I tested on Linux and Cygwin, more testing would be welcome. Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d Reviewed-By: Keith Seitz 2025-08-27 Simon Marchi gdb/testsuite: remove function parameter from do_self_tests The function to stop at is always main. Remove the parameter and hard-code main in _selftest_setup. Change-Id: Ibbbf598203b1658305eb6bc631d029652c10edac Reviewed-By: Keith Seitz 2025-08-27 Simon Marchi gdb/testsuite: namespace procs in lib/selftest-support.exp Rename some procs in lib/selftest-support.exp that are only used internally, to make it a bit clearer that they are just internal helpers. Change-Id: Icd399ac42698209fbc8e798bf43a7d8464aa848c Reviewed-By: Keith Seitz 2025-08-27 Tom Tromey Fix formatting of gdbarch_components.py pre-commit pointed out that gdbarch_components.py had a minor formatting issue, according to the official version of 'black'. This patch corrects the oversight. 2025-08-27 Alan Modra objcopy "strip without global symbol" test This binutils test fails with -fsanitize. NOSANITIZE_CFLAGS isn't available in the binutils testsuite, and importing it over from ld requires a huge amount of tcl code to be moved. So I chose to simply add -fno-sanitize=all if -fsanitize= is seem in CFLAGS. * testsuite/binutils-all/objcopy.exp (objcopy_test_without_global_symbol): Add -fno-sanitize=all to flags if -fsanitize= is found in CFLAGS_FOR_TARGET. Tidy use of objfile. 2025-08-27 Alan Modra tekhex test for commit bf0f85df1254 * testsuite/binutils-all/tek2.obj: Change to a 3 byte data file that triggers tekhex error fixed by commit bf0f85df1254. * testsuite/binutils-all/ar.exp: Adjust to suit. * testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): New proc. 2025-08-27 Alan Modra objcopy "Unable to recognise the format of the input file" This bogus error comes up when trying something like objcopy -O binary .../binutils/testsuite/binutils-all/tek2.obj xxx This is an annoying message, as HJ said in https://sourceware.org/pipermail/binutils/2002-August/021354.html and removed it for some cases, eg. I can make it go away by specifying -I tekhex. The message is also untrue, as objcopy does in fact know the format of the input file. I think the message should be limited to ELF input files that are being handled by the elf64-little, elf64-big, elf32-little or elf32-big targets, due to libbfd being compiled with limited target support. I'm also changing the message a litle. * objcopy.c (copy_object): Change "Unable to recognise format" message to "Unable to recognise architecture" and only report this error for ELF objects lacking their proper target support. * testsuite/binutils-all/x86-64/x86-64.exp: Update to suit. 2025-08-27 Alan Modra Revert part of commit 8e885fece150 After commit 5e83077d552e we no longer choose a "plugin" target in objcopy so ibfd->target_defaults can again be used to test whether the user supplied a target. PR 33230 * objcopy.c (copy_file): Revert change adding a target_defaulted variable and passing down to.. (copy_archive, copy_object): ..here. Remove target_defaulted parameter. Use ibfd->target_defaulted. 2025-08-27 Andrew Burgess gdb/testsuite: work around empty substring bug in expect There is a bug in expect, see: https://sourceforge.net/p/expect/patches/26/ which causes empty substring matches from a regexp to instead return the complete input buffer. To reproduce this bug, try this command: expect -c 'spawn sh -c "echo -n -e \"abc\""; \ expect -re "(a?)(a)(bc)"; \ puts "\n"; \ for { set i 1 } { $i < 4 } { incr i } { \ puts -nonewline "($i): \""; \ puts -nonewline $expect_out($i,string); \ puts "\"" \ }' For a working expect the output looks like: spawn sh -c echo -n -e "abc" abc (1): "" (2): "a" (3): "bc" But for a broken expect the output looks like: spawn sh -c echo -n -e "abc" abc (1): "abc" (2): "a" (3): "bc" Notice that (1) is now returning the complete input buffer rather than the empty string, this is wrong. This is not the first time this bug has impacted GDB's testsuite, this commit seems to be working around the same problem: commit e579b537353cd91cb8fac1eaeb69901d4936766f Date: Sat Aug 16 20:32:37 2025 +0200 [gdb/testsuite] Fix TUI tests on freebsd I recently pushed this commit: commit 3825c972a636852600b47c242826313f4b9963b8 Date: Wed Jun 18 15:02:29 2025 +0100 gdb: allow gdb.Color to work correctly with pagination Which added gdb.python/py-color-pagination.exp. Bug PR gdb/33321 was then created as the test was failing on some hosts. Turns out, this is same expect bug. The fix presented here is the same as for e579b537353cd91cb8, avoid using optional regexp substrings at the start of a regexp, and instead use two separate regexp patterns. With this change in place, the test now passes on all hosts. There's no change in what is being tested after this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33321 Approved-By: Tom de Vries 2025-08-27 Tom de Vries [gdb/testsuite] Fix gdb.server/non-existing-program.exp on msys2-ucrt64 On msys2-ucrt64, with test-case gdb.server/non-existing-program.exp I get: ... (gdb) quit^M gdb_caching_proc allow_xml_test caused gdb_exit to be called gdb_caching_proc allow_xml_test marked as called gdb_caching_proc get_mount_point_map marked as called builtin_spawn gdbserver stdio non-existing-program^M Error creating process "non-existing-program " (error 2): \ The system cannot find the file specified.^M^M Exiting^M^M FAIL: gdb.server/non-existing-program.exp: gdbserver exits cleanly ... This happens because this regexp fails to match: ... # This is what we get on Windows. -re "Error creating process\r\n\r\nExiting\r\n" { ... Fix this by updating the regexp. Tested on x86_64-w64-mingw32 (msys2-ucrt64). 2025-08-27 Tom de Vries [gdb/testsuite] Add have_startup_shell Say we disable startup-with-shell, we get: ... (gdb) run `echo 8`^M Starting program: a2-run `echo 8`^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M usage: factorial ^M [Inferior 1 (process 10787) exited with code 01]^M (gdb) FAIL: gdb.base/a2-run.exp: run "a2-run" with shell (timeout) ... Fix this by only doing this test if startup-with-shell is supported. This fixes the test-case on msys2-ucrt64, where startup-with-shell is not supported. Likewise in other test-cases. Tested on x86_64-linux. 2025-08-27 Tom de Vries [gdb/testsuite] Add missing require {!is_remote host} I ran test-case gdb.python/py-color-pagination.exp with make-check-all.sh and noticed failures when using remote host. So I grepped to find all test-cases using with_ansi_styling_terminal and ran them with host/target board local-remote-host-native. Fix the failing test-cases using require {!is_remote host}. Tested on x86_64-linux. 2025-08-27 H.J. Lu x86: Don't put R_386_TLS_DESC/R_X86_64_TLSDESC in .rel.plt/.rela.plt Since lazy tlsdesc relocation has data races: https://sourceware.org/bugzilla/show_bug.cgi?id=27137 put R_386_TLS_DESC and R_X86_64_TLSDESC relocation in .rela.tls/.rel.tls section, instead of .rel.plt/.rela.plt section. Tested with glibc/i686 and glibc/x86-64 compiled with -mtls-dialect=gnu2 as well as GCC 16 configured with --with-tls=gnu2. bfd/ PR ld/28387 * elf32-i386.c (elf_i386_relocate_section): Put R_386_TLS_DESC in rel_tls_desc instead of elf.srelplt. * elf64-x86-64.c (elf_x86_64_relocate_section): Put R_X86_64_TLSDESC in rel_tls_desc instead of elf.srelplt. * elfxx-x86.c (elf_x86_allocate_dynrelocs): Use rel_tls_desc, instead of elf.srelplt, for GOT_TLS_GDESC_P. (_bfd_elf_x86_get_reloc_section): New function. (_bfd_x86_elf_late_size_sections): Use rel_tls_desc, instead of elf.srelplt, for GOT_TLS_GDESC_P. Remove next_tls_desc_index. (_bfd_x86_elf_link_setup_gnu_properties): Allocate .rela.tls/.rel.tls section for rel_tls_desc. * elfxx-x86.h (elf_x86_link_hash_table): Add rel_tls_desc. Remove next_tls_desc_index. (_bfd_elf_x86_get_reloc_section): New. (elf_backend_get_reloc_section): Likewise. ld/ PR ld/28387 * emulparams/elf32_x86_64.sh (OTHER_GOT_RELOC_SECTIONS): New. * emulparams/elf_i386.sh (OTHER_GOT_RELOC_SECTIONS): Likewise. * emulparams/elf_x86_64.sh (OTHER_GOT_RELOC_SECTIONS): Likewise. * testsuite/ld-i386/i386.exp: Run pr28387. * testsuite/ld-i386/pr17057.d: Adjusted * testsuite/ld-i386/tlsdesc.rd: Likewise. * testsuite/ld-i386/tlsdesc2.d: Likewise. * testsuite/ld-i386/tlsgdesc.rd: Likewise. * testsuite/ld-x86-64/tlsdesc.pd: Likewise. * testsuite/ld-x86-64/tlsdesc.rd: Likewise. * testsuite/ld-x86-64/tlsdesc2.d: Likewise. * testsuite/ld-x86-64/tlsgdesc.rd: Likewise. * testsuite/ld-i386/pr28387.d: New file. * testsuite/ld-i386/pr28387.s: Likewise. * testsuite/ld-x86-64/pr28387-x32.d: Likewise. * testsuite/ld-x86-64/pr28387.d: Likewise. * testsuite/ld-x86-64/pr28387.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr28387 and pr28387-x32. 2025-08-27 GDB Administrator Automatic date update in version.in 2025-08-26 Andrew Burgess gdb/python: return gdbpy_ref<> from gdbpy_create_ptid_object Update gdbpy_create_ptid_object (python/py-infthread.c) to return a gdbpy_ref<> rather than a 'PyObject *'. This reduces the chances that a caller will leak an object, though no such memory leaks are fixed in this commit, this is just a code improvement patch. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-08-26 Andrew Burgess gdb: use existing argument more in rename_vmcore_idle_reg_sections In corelow.c, in the function rename_vmcore_idle_reg_sections, the argument ABFD holds the core file bfd pointer. When this function is called current_program_space->core_bfd() is passed as the argument value. Within this function, we sometimes use the function argument, and sometimes access current_program_space->core_bfd() directly. This is confusing, and unnecessary. Lets not do that. I've renamed the argument to cbfd (for Core file BFD), and then updated the function to make use of this argument throughout. This reduces the number of accesses to global state, which is, I think, a good thing. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-08-26 Andrew Burgess gdb: more current_program_space->core_bfd() removal This commit changes the signature of the gdbarch_core_info_proc method so that it takes a 'struct bfd *' as an extra argument. This argument is used to pass through the core file bfd pointer. Now, in corelow.c, when calling gdbarch_core_info_proc, we can pass through current_program_space->core_bfd() as the argument. Within the implementations, (Linux and FreeBSD) we can use this argument rather than having to access the core file through current_program_space. This reduces the use of global state, which I think is a good thing. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-08-26 Andrew Burgess gdb: use current_program_space->core_bfd() a little less The function linux_read_core_file_mappings is passed an argument CBFD, which is the BFD for the core file. In core_target::build_file_mappings, where the function is called, we pass current_program_space->core_bfd() as the argument. However, in linux_read_core_file_mappings, in some places we use the CBFD argument, and in other places we directly use current_program_space->core_bfd(). This is confusing, and unnecessary. Lets not do that. Standardise on just using CBFD. This removes some references to global state in favour of passing the global state in as an argument, I think this is a good thing. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-08-26 Tom de Vries [gdb/tdep] Add XOP support in amd64_get_insn_details Implement support for XOP instructions [1] in amd64_get_insn_details. The encoding scheme is documented here [2]. Essentially it's a variant of the VEX3 encoding scheme, with: - 0x8f as the first byte instead of 0xc4, and - an opcode map >= 8. The changes are roughly the same as the XOP part of an earlier submission [3], hence the tag. The only real difference is that that patch proposed to implement xop_prefix_p using: ... return pfx[0] == 0x8f && (pfx[1] & 0x38); ... which tries to resolve the conflict between the XOP prefix (starts with 0x8f) and the POP instruction (opcode 0x8f) by detecting that it's not a POP instruction. Instead, use the way AMD has resolved this conflict in the specification, by checking for opcode map >= 8: ... gdb_byte m = pfx[1] & 0x1f; return pfx[0] == 0x8f && m >= 8; ... Tested on x86_64-linux. Co-Authored-By: Jan Beulich Reviewed-By: Klaus Gerlicher [1] https://en.wikipedia.org/wiki/XOP_instruction_set [2] https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/43479.pdf [3] https://sourceware.org/pipermail/gdb-patches/2019-February/155347.html 2025-08-26 Andrew Burgess gdb/python: fix an unlikely memory leak I noticed a possible memory leak in gdbpy_create_ptid_object, in py-infthread.c. We create a Tuple, and hold the reference in a 'PyObject*' local. If we then fail to create any of the tuple contents we perform an early exit, returning nullptr, this will leak the Tuple object. Currently, we create the Tuple as the first action in the function, but we don't really need the tuple until the end of the function. In this commit I have: 1. Moved creation of the Tuple until the end of the function, just before we need it. 2. Stored the Tuple reference in a gdbpy_ref<>. This is not strictly needed any more, but is (I think) good practice as future changes to the function will not need to worry about releasing the Tuple object. 3. Taken the opportunity to replace a NULL with nullptr in this function. 4. Inlined the local variable declarations to the point of first use. There should be no user visible changes after this commit. No tests as I have no idea how to make gdb_py_object_from_longest (and friends) fail, and so trigger the memory leak. I suspect we'd never actually see this leak in the real world, but it doesn't hurt to clean these things up. Approved-By: Simon Marchi 2025-08-26 Hui Li gdb: LoongArch: Improve loongarch_scan_prologue for correct backtrace (1) Description of Problem: When debugging the following code, the execution result of the backtrace command is incorrect. $ cat test.S .text .globl fun1 .type fun1, @function fun1: or $r12,$r0,$r0 or $r4,$r12,$r0 jr $r1 .globl fun .type fun, @function fun: addi.d $r3,$r3,-16 st.d $r1,$r3,8 bl fun1 or $r12,$r4,$r0 or $r4,$r12,$r0 ld.d $r1,$r3,8 addi.d $r3,$r3,16 jr $r1 .globl main .type main, @function main: addi.d $r3,$r3,-16 st.d $r1,$r3,8 bl fun nop ld.d $r1,$r3,8 addi.d $r3,$r3,16 jr $r1 $ gcc test.S -o test $ gdb test ... (gdb) b fun1 Breakpoint 1 at 0x748 (gdb) r Breakpoint 1, 0x0000555555554748 in fun1 () (gdb) bt #0 0x0000555555554748 in fun1 () #1 0x0000555555554758 in fun () #2 0x0000555555554758 in fun () #3 0x0000555555554758 in fun () .... --Type for more, q to quit, c to continue without paging (2) Root Cause Analysis: The return address of fun() in r1(ra) is saved on the stack: addi.d $r3,$r3,-16 st.d $r1,$r3,8 The bl instruction in fun () will call the fun1 () and save the value of pc+4 to r1(ra). bl fun1 or $r12,$r4,$r0 Because registers such as fp and ra saved in the stack of the sub-function are not recorded in current code. When trace back fun() to main(), the pc of the previous frame to be read from ra register instead of the saved location on the stack. At this time, the value of ra register in fun() is already the address of the next instruction after the bl. So it is impossible to trace back to the main(). (3) Solution: Record the location of ra, fp, s0 to s8 on the stack to ensure the correct execution of backtrace. (4) Test: $ gdb test ... (gdb) b fun1 Breakpoint 1 at 0x748 (gdb) r Breakpoint 1, 0x0000555555554748 in fun1 () (gdb) bt #0 0x0000555555554748 in fun1 () #1 0x0000555555554758 in fun () #2 0x0000555555554778 in main () 2025-08-26 Hui Li gdb: LoongArch: Improve loongarch_scan_prologue to record stack information (1) Description of Problem: When debugging the following code, the execution result of nexti command is incorrect. $ cat test.S .text .globl fun .type fun, @function fun: or $r12,$r0,$r0 or $r4,$r12,$r0 jr $r1 .globl main .type main, @function main: addi.d $r3,$r3,-16 st.d $r1,$r3,8 bl fun or $r12,$r4,$r0 or $r4,$r12,$r0 ld.d $r1,$r3,8 addi.d $r3,$r3,16 jr $r1 $ gcc test.S -o test $ gdb test ... (gdb) set disassemble-next-line on (gdb) start ... Temporary breakpoint 1, 0x0000555555554754 in main () => 0x0000555555554754 : 57ffefff bl -20 # 0x555555554740 (gdb) ni 0x0000555555554740 in fun () => 0x0000555555554740 : 0015000c move $t0, $zero (2) Root Cause Analysis: In the internal execution flow of the ni command, a single-step will be executed first. After that, it will enter process_event_stop_test (), some conditions are judged in this function. if ((get_stack_frame_id (frame) != ecs->event_thread->control.step_stack_frame_id) && get_frame_type (frame) != SIGTRAMP_FRAME && ((frame_unwind_caller_id (frame) == ecs->event_thread->control.step_stack_frame_id) && ((ecs->event_thread->control.step_stack_frame_id != outer_frame_id) || (ecs->event_thread->control.step_start_function != find_pc_function (ecs->event_thread->stop_pc ()))))) { ... if (ecs->event_thread->control.step_over_calls == STEP_OVER_ALL) ... else insert_step_resume_breakpoint_at_caller (frame); } Here, it will be judged whether a sub-function has been called based on whether the frame id before the single step is not equal to the current frame id and whether there is a calling relationship. If a sub-function is called at this time and the current operation is nexti, it will not stop immediately. Instead, insert_step_resume_breakpoint_at_caller() will be called to complete the execution of the sub-function and then stop. In above debugging examples, the executable program being debugged is compiled from an asm source file that does not contain dwarf information. Therefore, the frame id of the function is calculated by loongarch_frame_unwind rather than dwarf2_frame_unwind. However, loongarch_scan_prologue() has not yet recorded stack information in loongarch_frame_cache, this will cause problems in some operations related to the frame id information. (3) Solution: Improve loongarch_scan_prologue() to record the stack information in loongarch_frame_cache. And improve the loongarch_frame_unwind_stop_reason() through the information recorded in loongarch_frame_cache. (4) Test: After this patch: $ gdb test (gdb) set disassemble-next-line on (gdb) start Temporary breakpoint 1, 0x0000555555554754 in main () => 0x0000555555554754 : 57ffefff bl -20 # 0x555555554740 (gdb) ni 0x0000555555554758 in main () => 0x0000555555554758 : 0015008c move $t0, $a0 (gdb) ni 0x000055555555475c in main () => 0x000055555555475c : 00150184 move $a0, $t0 2025-08-26 Hui Li gdb: LoongArch: Refactor member functions of loongarch_frame_unwind In the current code, loongarch_frame_unwind is a LoongArch prologue unwinder, it contains the required member functions, but they do not calculate a valid frame id through prologue of a function frame. Refactor these functions and use loongarch_frame_cache to record the information of the function frame. No functional change intended. gdb: LoongArch: Add the definition of loongarch_frame_cache Add the definition of loongarch_frame_cache for loongarch_frame_unwind, this is preparation for later patch on LoongArch. 2025-08-26 Klaus Gerlicher amd64-tdep: need_modrm = 1 for VEX/EVEX instructions, except vzeroall/vzeroupper VEX and EVEX-encoded instructions generally require a ModR/M byte, with the notable exception of vzeroall and vzeroupper (opcode 0x77), which do not use ModR/M. This change sets need_modrm = 1 for VEX instructions, and adds an exception for instructions where *insn == 0x77, following Intel’s SDM. EVEX has no exceptions and thus always sets need_modrm to 1. Additionally, the legacy twobyte_has_modrm table cannot be used for VEX and EVEX instructions, as these encodings have different requirements and exceptions. The logic is now explicit for VEX/EVEX handling. Add vpblendw to selftest amd64_insn_decode. The Intel SDM says the following: 1. Intel® 64 and IA-32 Architectures Software Developer’s Manual Section 2.2.1.2 — Instruction Prefixes "The VEX prefix is a multi-byte prefix that replaces several legacy prefixes and opcode bytes. The VEX prefix is not an opcode; it is a prefix that modifies the instruction that follows." Section 2.2.1.3 — Opcode Bytes "The opcode byte(s) follow any instruction prefixes (including VEX). The opcode specifies the operation to be performed." Section 2.2.2 — Instruction Format "If a VEX prefix is present, it is processed as a single prefix, and the opcode bytes follow immediately after the VEX prefix." Source: Intel® SDM Vol. 2A, Section 2.2.1.2 and 2.2.2 (See Vol. 2A, PDF pages 2-4, 2-5, and 2-7) 2. ModRM Byte Requirement Intel® SDM Vol. 2A, Table 2-2 — VEX Prefix Encoding "Most VEX-encoded instructions require a ModRM byte, except for a few instructions such as VZEROALL and VZEROUPPER." Source: Intel® SDM Vol. 2A, Table 2-2 (See Vol. 2A, PDF page 2-13) Approved-By: Tom de Vries 2025-08-26 Tom de Vries [gdb/testsuite] Fix require dwarf2_support check in some test-cases On x86_64-freebsd, I ran into trouble with test-case gdb.dwarf2/macro-source-path-clang14-dw4.exp (and similar), and I managed to reproduce the problem on x86_64-linux by making dwarf2_support return 0. The failure looks like: ... UNSUPPORTED: $exp: require failed: dwarf2_support UNRESOLVED: $exp: testcase aborted due to invalid command name: do_test ERROR: tcl error sourcing $exp. ... I fixed a similar problem in commit 3e488d8ccd0 ("[gdb/testsuite] Fix gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh"). Fix this by moving "require dwarf2_support" from gdb.dwarf2/macro-source-path.exp.tcl to the files including it. Tested on x86_64-linux. 2025-08-26 Jan Beulich ld/PE: don't emit relocations for weak absolute symbols First we should check the flag alone, not the entire flags value matching BSF_WEAK. And then using "else if()" is inappropriate here: A weak symbol can very well also be absolute, and hence wouldn't want a relocation emitted despite being defined. 2025-08-26 Jan Beulich ld/ELF: explicitly place .note.gnu.property x86 gas may produce .note.gnu.property by default. Hence the default linker script would better also deal with that section, rather than causing diagnostics when using --orphan-handling=. Replace all mis- spellings that have accumulated. To avoid needlessly relaxing expectations for two tests when run for PPC 64-bit ELF targets, suppress the linker generating EH frame data there. 2025-08-26 Jan Beulich ld: entry size and merge/strings attributes propagation While commit 9c0adb10c7fc ("elf: Clear entsize when clearing SEC_MERGE|SEC_STRINGS") addressed the particular issue reported in PR ld/33291, it didn't go quite far enough to deal with related aspects as well: As indicated in other recent commits, the three properties can be largely independent (ELF generally being the target here): Entry size doesn't require either of merge/strings, and strings also doesn't require merge. Commit 98e6d3f5bd4e ("gas/ELF: allow specifying entity size for arbitrary sections") uncovered issues with ld's handling. Zap entry size when it doesn't match between input sections. In that case SEC_MERGE and SEC_STRINGS also need to be removed, as their underlying granularity is lost. Then deal with SEC_MERGE and SEC_STRINGS separately. Otoh record entry size from the first input independent of SEC_MERGE. 2025-08-26 Vladimir Mezentsev MAINTAINERS: Remove my email address My position was eliminated and I don't have access to my oracle email account. You need a new gprofng maintainer. 2025-08-26 GDB Administrator Automatic date update in version.in 2025-08-25 Kevin Buettner Fix tekhex format related gdb.base/dump.exp failures On s390x, a big-endian machine, I'm seeing these test failures: FAIL: gdb.base/dump.exp: array as memory, tekhex; file restored ok FAIL: gdb.base/dump.exp: array as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: array as value, tekhex; file restored ok FAIL: gdb.base/dump.exp: array as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: array copy, tekhex; file restored ok FAIL: gdb.base/dump.exp: array copy, tekhex; value restored ok FAIL: gdb.base/dump.exp: array partial, tekhex; file restored ok FAIL: gdb.base/dump.exp: array partial, tekhex; value restored ok FAIL: gdb.base/dump.exp: dump array as memory, tekhex FAIL: gdb.base/dump.exp: dump array as value, tekhex FAIL: gdb.base/dump.exp: dump struct as memory, tekhex FAIL: gdb.base/dump.exp: dump struct as value, tekhex FAIL: gdb.base/dump.exp: reload array as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload array as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload struct as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: reload struct as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct as memory, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct as memory, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct as value, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct as value, tekhex; value restored ok FAIL: gdb.base/dump.exp: struct copy, tekhex; file restored ok FAIL: gdb.base/dump.exp: struct copy, tekhex; value restored ok It turns out that there's a subtle bug in move_section_contents in bfd/tekhex.c. The bug is that when attempting to write a buffer that starts with a zero byte, the function will return false, an error condition, without writing anything. But it also doesn't set bfd_error, so GDB ends up displaying whatever the last unrelated error was, e.g.: warning: writing dump file '.../intstr1.tekhex' (No such file or directory) When I investigated this, the bfd error was set during failure to open a separate debug file for the test case, which is totally unrelated to this problem. The reason this fails on big endian machines is that the test case writes out structs and arrays of int initialized to small values. On little endian machines, the small integer is the first byte, so the error doesn't occur. On big endian machines, a zero byte occurs first, triggering the error. On the GDB side of things, I've made a one line change to the test case to cause the error to also happen on little endian machines. I simply shift value of the first field in the struct left by 16 bits. That leaves at least one zero byte on both sides of the non-zero part of the int. I shifted it by 16 because, for a moment, there was a question in my mind about what would happen with a second zero byte, but it turns out that it's not a problem. On the bfd side of things, take a look at move_section_contents() and find_chunk() in tekhex.c. The scenario is this: we enter move_section_contents with locationp pointing at a character buffer whose first byte is zero. The 'get' parameter is false, i.e. we're writing, not reading. The other critical fact is that the abfd->tdata.tekhex_data->data is NULL (0). I'm going to go through the execution path pretty much line by line with commentary below the line(s) just executed. char *location = (char *) locationp; bfd_vma prev_number = 1; /* Nothing can have this as a high bit. */ I can't say that the comment provides the best explanation about what's happening, but the gist is this: later on, chunk_number will have it's low bits masked away, therefore no matter what it is, it can't possibly be equal to prev_number when it's set to 1. struct data_struct *d = NULL; BFD_ASSERT (offset == 0); for (addr = section->vma; count != 0; count--, addr++) { Set d to NULL and enter the loop. /* Get high bits of address. */ bfd_vma chunk_number = addr & ~(bfd_vma) CHUNK_MASK; bfd_vma low_bits = addr & CHUNK_MASK; Use CHUNK_MASK, which is 0x1fff, to obtain the chunk number, i.e. whatever's left after masking off the low 13 bits of addr, and low_bits, which are the low 13 bits of addr. chunk_number matters for understanding this bug, low_bits does not. Remember that no matter what addr is, once you mask off the low 13 bits, it can't be equal to 1. bool must_write = !get && *location != 0; !get is true, *location != 0 is false, therefore the conjunction is false, and furthermore must_write is false. I.e. even though we are writing, we don't transfer zero bytes to the chunk - this is why must_write is false. (The reason this works is that a chunk, once allocated, is zero'd as part of the allocation using bfd_zalloc. Therefore we can skip transferring zero bytes and, if enough of them are skipped one after another, chunk allocation simply doesn't happen. That's a good thing.) if (chunk_number != prev_number || (!d && must_write)) For the reason provided above, chunk_number != prev_number is true. The other part of the disjunction doesn't matter since the first part is true. This means that the if-block is entered. /* Different chunk, so move pointer. */ d = find_chunk (abfd, chunk_number, must_write); find_chunk is entered with must_write set to false. Now, remember where we left off here, because we're going to switch to find_chunk. static struct data_struct * find_chunk (bfd *abfd, bfd_vma vma, bool create) { (Above 3 lines indented to distinguish code from commentary.) When we enter find_chunk, create is false because must_write was false. struct data_struct *d = abfd->tdata.tekhex_data->data; d is set to NULL since abfd->tdata.texhex_data->data is NULL (one of the conditions for the scenario). vma &= ~CHUNK_MASK; while (d && (d->vma) != vma) d = d->next; d is NULL, so the while loop doesn't execute. if (!d && create) ... d is NULL so !d is true, but create is false, so the condition evaluates to false, meaning that the if-block is skipped. return d; find_chunk returns NULL, since d is NULL. Back in move_section_contents: if (!d) return false; d is NULL (because that's what find_chunk returned), so move_section_contents returns false at this point. Note that find_section_contents has allocated no memory, nor even tried to transfer any bytes beyond the first (zero) byte. This is a bug. The key to understanding this bug is to observe that find_chunk can return NULL to indicate that no chunk was found. This is especially important for the read (get=true) case. But it can also be NULL to indicate a memory allocation error. I toyed around with the idea of using a different value to distinguish these cases, i.e. something like (struct data_struct *) -1, but although bfd contains plenty of code where -1 is used to indicate various interesting conditions for scalars, there's no prior art where this is done for a pointer. Therefore the idea was discarded in favor of modifying this statement: if (!d) return false; to: if (!d && must_write) return false; This works because, in find_chunk, the only way to return a NULL memory allocation error is for must_write / create to be true. When it is true, if bfd_zalloc successfully allocates a chunk, then that (non-NULL) chunk will be returned at the end of the function. When it fails, it'll return NULL early. The point is that when bfd_zalloc() fails and returns NULL, must_write (in move_section_contents) / create (in find_chunk) HAD to be true. That provides us with an easy test back in move_section_contents to distinguish a memory-allocation-NULL from a block-not-found-NULL. The other NULL return case happens when the end of the function is reached when either searching for a chunk to read or attempting to find a chunk to write when abfd->tdata.tekhex_data->data is NULL. But for the latter case, must_write was false, which does not (now, with the above fix) trigger the early return of false. (Alan Modra approved the bfd/tekhex.c change.) Approved-By: Simon Marchi (GDB) 2025-08-25 Simon Marchi gdb: fix indentation in objfiles.c Change-Id: I3d39ee767a3b2b743b3a90386fb30a6703e9733e 2025-08-25 Xi Ruoyao gdb: LoongArch: Handle newly added llsc instructions We can't put a breakpoint in the middle of a ll/sc atomic sequence, handle the instructions sc.q, llacq.{w/d}, screl.{w/d} newly added in the LoongArch Reference Manual v1.10 so a ll/sc atomic sequence using them won't loop forever being debugged. 2025-08-25 GDB Administrator Automatic date update in version.in 2025-08-24 Alan Modra PR 33302, Symbols truncated on i386pep target Commit 012d44268695 effectively made peXXigen.c _bfd_XXi_swap_aux_out always use the COFF E_FILNMLEN of 14. The problem was that the auxent x_fname field was defined in include/coff/external.h using a length of 14. Later, E_FILNMLEN is redefined to 18 in coff/pe.h. This no doubt falsely tripped memory checking tools. AUXESZ is 18, so no actual buffer overrun. This patch defines x_fname as an 18 char field, the full auxent, and uses E_FILNMLEN when accessing. PR 33302 include/ * coff/external.h (union external_auxent): Make x_fname AUXESZ chars. bfd/ * coffswap.h (coff_swap_aux_in): Correct #error message. (coff_swap_aux_out): Likewise. Use E_FILNMLEN when copying to ext field. * peXXigen.c (_bfd_XXi_swap_aux_in): Add #error. Style fix. (_bfd_XXi_swap_aux_out): Add #error. Don't use sizeof, use E_FILNMLEN when copying to ext field. gas * testsuite/gas/pe/long_file_symbol.d, * testsuite/gas/pe/long_file_symbol.s: New test. * testsuite/gas/pe/pe.exp: Run it. Reported-By: Frediano Ziglio 2025-08-24 Alan Modra Tidy include/coff/external.h and internal.h Mostly whitespace fixes and wrap of long comment lines, removal of block comments and moving a few defines around. Nothing much to see here, but AUXESZ before union external_auxent is needed by the next patch. * coff/external.h: Whitespace fixes, wrap long comment lines, remove header style comments. Move some defines. (E_FILNMLEN): Remove #ifndef. (_ETEXT): Don't define. (SYMENT, AUXENT): Don't define, make them typedefs. * coff/internal.h: Whitespace fixes, wrap long comment lines, remove header style comments. Move some defines. (signed): Don't define. 2025-08-24 Alan Modra bfd/pe*.c including bfd/coff*.c The model of a coff-.c file providing older COFF support, with a pe-.c file defining some macros then including the coff-.c file to provide PE support has been followed by a number of architectures. Some of them have PE specific code in their coff-.c files, unconditionally compiled. ie. they are not for old COFF support, and there was no reason to follow the model. They now get an error if they are compiled stand-alone rather than being included from pe-.c or pei-.c. * coff-aarch64.c (COFF_WITH_peAArch64): Don't define here. (COFF_WITH_PE): Error if not defined. * coff-ia64.c (COFF_WITH_PE): Error if not defined. * coff-loongarch64.c (COFF_WITH_peLoongArch64): Don't define here. (COFF_WITH_PE): Error if not defined. * coff-mcore.c (COFF_WITH_PE): Error if not defined. * coff-riscv64.c (COFF_WITH_PE): Error if not defined. * pei-aarch64.c: Remove duplicate includes. * pei-loongarch64.c: Likewise. * pei-riscv64.c: Likewise. * pei-x86_64.c: Likewise. 2025-08-24 Andrew Burgess gdb: allow gdb.Color to work correctly with pagination This commit allows gdb.Color objects to be used to style output from GDB commands written in Python, and the styled output should work correctly with pagination. There are two parts to fixing this: First, GDB needs to be able to track the currently applied style within the page_file class. This means that style changes need to be achieved with calls to pager_file::emit_style_escape. Now usually, GDB does this by calling something like fprintf_styled, which takes care to apply the style for us. However, that's not really an option here as a gdb.Color isn't a full style, and as the gdb.Color object is designed to be converted directly into escape sequences that can then be printed, we really need a solution that works with this approach. However pager_file::puts already has code in place to handle escape sequences. Right now all this code does is spot the escape sequence and append it to the m_wrap_buffer. But in this commit I propose that we go one step further, parse the escape sequence back into a ui_file_style object in pager_file::puts, and then we can call pager_file::emit_style_escape. If the parsing doesn't work then we can just add the escape sequence to m_wrap_buffer as we did before. But wait, how can this work if a gdb.Color isn't a full style? Turns out that's not a problem. We only ever emit the escape sequence for those parts of a style that need changing, so a full style that sets the foreground color will emit the same escape sequence as a gdb.Color for the foreground. When we convert the escape sequence back into a ui_file_style, then we get a style with everything set to default, except the foreground color. I had hoped that this would be all that was needed. But unfortunately this doesn't work because of the second problem... ... the implementation of the Python function gdb.write() calls gdb_printf(), which calls gdb_vprintf(), which calls ui_file::vprintf, which calls ui_out::vmessage, which calls ui_out::call_do_message, and finally we reach cli_ui_out::do_message. This final do_message function does this: ui_file *stream = m_streams.back (); stream->emit_style_escape (style); stream->puts (str.c_str ()); stream->emit_style_escape (ui_file_style ()); If we imagine the case where we are emitting a style, triggered from Python like this: gdb.write(gdb.Color('red').escape_sequence(True)) the STYLE in this case will be the default ui_file_style(), and STR will hold the escape sequence we are writing. After the first change, where pager_file::puts now calls pager_file::emit_style_escape, the current style of STREAM will have been updated. But this means that the final emit_style_escape will now restore the default style. The fix for this is to avoid using the high level gdb_printf from gdb.write(), and instead use gdb_puts instead. The gdb_puts function doesn't restore the default style, which means our style modification survives. There's a new test included. This test includes what appears like a pointless extra loop (looping over a single value), but this makes sense given the origin of this patch. I've pulled this commit from a longer series: https://inbox.sourceware.org/gdb-patches/cover.1755080429.git.aburgess@redhat.com I want to get this bug fix merged before GDB 17 branches, but the longer series is not getting reviews, so for now I'm just merging this one fix. Once the rest of the series gets merged, I'll be extending the test, and the loop (mentioned above) will now loop over more values. 2025-08-24 GDB Administrator Automatic date update in version.in 2025-08-24 H.J. Lu x86: Distinguish no PLT build and run test names Change no PLT build and run test names from PASS: No PLT (dynamic 1a) ... PASS: No PLT (dynamic 1a) to PASS: Build no PLT (dynamic 1a) ... PASS: Run no PLT (dynamic 1a) in ld.log. * testsuite/ld-i386/no-plt.exp (run_cc_link_tests): Change "No PLT" to "Build no PLT" in no PLT build test names. (run_ld_link_exec_tests): Change "No PLT" to "Run no PLT" in no PLT run test names. * testsuite/ld-x86-64/no-plt.exp (run_cc_link_tests): Change "No PLT" to "Build no PLT" in no PLT build test names. (run_ld_link_exec_tests): Change "No PLT" to "Run no PLT" in no PLT run test names. 2025-08-23 Tom Tromey Update comment in rust-parse.c I noticed an out-of-date comment in rust-parse.c. 2025-08-23 H.J. Lu x86-64: Use the GOT indirection in no-plt-check1.S There is cmpq %rax, func_p(%rip) in no-plt-check1.S which requires copy relocation when func_p, a function pointer, is defined in a shared library. Use the GOT indirection to access func_p movq func_p@GOTPCREL(%rip), %rdx cmpq %rax, (%rdx) to remove copy relocation to support PIE without copy relocation. PR ld/33237 * testsuite/ld-x86-64/no-plt-check1.S: Use the GOT indirection to access func_p. * testsuite/ld-x86-64/no-plt-1a.dd: Adjusted. * testsuite/ld-x86-64/no-plt-1b.dd: Likewise. * testsuite/ld-x86-64/no-plt-1a.dd: Likewise. * testsuite/ld-x86-64/no-plt-1b.dd: Likewise. * testsuite/ld-x86-64/no-plt-1c.dd: Likewise. * testsuite/ld-x86-64/no-plt-1d.dd: Likewise. * testsuite/ld-x86-64/no-plt-1e.dd: Likewise. * testsuite/ld-x86-64/no-plt-1f.dd: Likewise. * testsuite/ld-x86-64/no-plt-1g.dd: Likewise. 2025-08-23 Indu Bhagat libsframe: use offsets to FDE and FRE sub-sections In SFrame format, the SFrame FDEs begin at an offset 'sfh_fdeoff' from the end of the SFrame header. Similarly, the SFrame FREs begin at an offset 'sfh_freoff' from the end of the SFrame header. While the GNU assembler generates these subsections such that sfd_fdeoff is zero, the correct way to decode the SFrame section (conforming with the specification) is to use both sfh_fdeoff and sfh_freoff in sframe_decode. libsframe/ * sframe.c (sframe_decode): Use offsets to SFrame FDE and FRE sub-sections as applicable. 2025-08-23 Tom de Vries [gdb/testsuite] Require cooked index in two test-cases After running the testsuite with target board cc-with-gdb-index I ran found failures in test-cases: - gdb.dwarf2/backward-spec-inter-cu.exp - gdb.dwarf2/forward-spec-inter-cu.exp Fix this by requiring a cooked index. Tested on x86_64-linux. 2025-08-23 Tom de Vries [gdb/symtab] Turn complaints in create_addrmap_from_gdb_index into warnings Rather than issuing a complaint, which is off by default, warn when returning false in create_addrmap_from_gdb_index, informing the user that the .gdb_index was ignored, and why. Tested on aarch64-linux. 2025-08-23 Tom de Vries [gdb/symtab] Detect overlapping ranges in create_addrmap_from_gdb_index In create_addrmap_from_gdb_index, use the return value of addrmap_mutable::insert_empty to detect overlapping ranges. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-08-23 Tom de Vries [gdb] Make addrmap_mutable::set_empty return bool Function addrmap_mutable::set_empty has the follow behavior (shortened comment): ... /* In the mutable address map MAP, associate the addresses from START to END_INCLUSIVE that are currently associated with NULL with OBJ instead. Addresses mapped to an object other than NULL are left unchanged. */ void set_empty (CORE_ADDR start, CORE_ADDR end_inclusive, void *obj); ... Change the return type to bool, and return true if the full range [START, END_INCLUSIVE] is mapped to OBJ. Tested on x86_64-linux. Approved-By: Simon Marchi 2025-08-23 Tom de Vries [gdb/symtab] Bail out of create_addrmap_from_gdb_index on error Currently, in create_addrmap_from_gdb_index, when finding an incorrect entry in the address table of a .gdb_index section: - a (by default silent) complaint is made, - the entry is skipped, and - the rest of the entries is processed. This is the use-what-you-can approach, which make sense in general. But in the case that the .gdb_index section is incorrect while the other debug info is correct, this approach prevents gdb from building a correct cooked index (assuming there's no bug in gdb that would cause an incorrect index to be generated). Instead, bail out of create_addrmap_from_gdb_index on finding errors in the address table. I wonder about the following potential drawback of this approach: in the case that the .gdb_index section is incorrect because the debug info is incorrect, this approach rejects the .gdb_index section and spents time rebuilding a likewise incorrect index. But I'm not sure if this is a real problem. Perhaps gdb will refuse to generate such an index, in which case this is a non-issue. Tested on aarch64-linux. Approved-By: Simon Marchi 2025-08-23 Sam James gas: add --enable-default-sframe configure option SFrames make the most sense when userland as a whole is built with them, so add a --enable-default-sframe configure flag to facilitate distributors and vendors doing that. The primary motivation for a configure-time flag is that we don't support SFrame for 32-bit x86 but some packaging uses the same flags (with some added on top) for multilib builds (to support old binaries like games), and simply adding `-Wa,--gsframe` to the standard build flags isn't an option (*). That aside, I believe it'll be helpful for testing and eventual adoption in any case. In summary, combined with the recent --gsframe=[yes|no] support (**): * Configured with --enable-default-sframe and nothing is passed => SFrames (previously no SFrames) * Configured with --enable-default-sframe and --gsframe=yes is passed => SFrames (no change from before) * Configured with --enable-default-sframe and --gsframe=no is passed => No SFrames (no change from before) * Configured with --enable-default-sframe and --gsframe is passed => SFrames (no change from before) * Configured with --disable-default-sframe and nothing is passed => No SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe=yes is passed => SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe=no is passed => No SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe is passed => SFrames (no change from before) I've introduced a sframe_as_bad macro on Indu's suggestion. A following patch uses its sibling sframe_as_warn heavily and having symmetry plus the macro as a form of documentation of intent seems useful. (*) It gets added to multilib builds too and then we hit the `.sframe not supported for target` error in gas/dw2gencfi.c. (**) I've verbosely listed --gsframe=yes but it's the same as --gsframe. gas/ PR gas/33126 * as.c (enum gen_sframe_option): Initialize if DEFAULT_SFRAME. * config.in (DEFAULT_SFRAME): New. * configure: Regenerate. * configure.ac: Add --enable-default-sframe. * doc/as.texi: Document --enable-default-sframe. * dw2gencfi.c (cfi_finish): Don't warn if SFrames are enabled by default but unavailable for this target. * gen-sframe.h (sframe_as_bad): New macro. 2025-08-23 GDB Administrator Automatic date update in version.in 2025-08-23 Aaron Griffith gdb/doc: qSearch:memory packets use escaped binary patterns The `qSearch:memory` packet uses hex encoding for the address and length arguments, but the search-pattern argument uses escaped binary. Approved-By: Eli Zaretskii 2025-08-22 Simon Marchi gdb/testsuite: fix pattern in gdb.base/dlmopen-ns-ids.exp I forgot one spot when updating the "info shared" header from NS to "Linker NS", fix that. This fixes the following failure: FAIL: gdb.base/dlmopen-ns-ids.exp: check no duplicates: info sharedlibrary At the same time, fix a couple of things I found when looking at this code again. One is bad indentation, the other is an unnecessary parameter. Change-Id: Ibbc2062699264dde08fd3ff7c503524265c73b0c 2025-08-22 Pedro Alves MSYS2+MinGW testing: Unix <-> Windows path conversion On an MSYS2 system, I have: # which tclsh /mingw64/bin/tclsh # which tclsh86 /mingw64/bin/tclsh86 # which tclsh8.6 /usr/bin/tclsh8.6 # which expect /usr/bin/expect The ones under /usr/bin are MSYS2 programs (linked with msys-2.0.dll). I.e., they are really Cygwin (unix) ports of the programs. The ones under /mingw64 are native Windows programs (NOT linked with msys-2.0.dll). You can check that with CYGWIN/MSYS2 ldd. The MSYS2/Cygwin port of TCL (and thus expect) does not treat a file name that starts with a drive letter as an absolute file name, while the native/MinGW port does. Vis: # cat file-join.exp puts [file join c:/ d:/] # /mingw64/bin/tclsh.exe file-join.exp d:/ # /mingw64/bin/tclsh86.exe file-join.exp d:/ # /usr/bin/expect.exe file-join.exp c:/d: # /usr/bin/tclsh8.6.exe file-join.exp c:/d: When running the testsuite under MSYS2 to test mingw32 (Windows native) GDB, we use MSYS2 expect (there is no MinGW port of expect AFAIK). Any TCL file manipulation routine will thus not consider drive letters special, and just treats them as relative file names. This results in several cases of the testsuite passing to GDB broken file names, like: "C:/foo/C:/foo/bar" or: "/c/foo/C:/foo/bar" E.g., there is a "file join" in standard_output_file that results in this: (gdb) file C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2 C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2: No such file or directory. (gdb) ERROR: (info_sources_2) No such file or directory delete breakpoints The bad "file join" comes from clean_restart $binfile, where $binfile is an absolute host file name (thus has a drive letter), clean_restart doing: set binfile [standard_output_file ${executable}] return [gdb_load ${binfile}] and standard_output_file doing: # If running on MinGW, replace /c/foo with c:/foo if { [ishost *-*-mingw*] } { set dir [exec sh -c "cd ${dir} && pwd -W"] } return [file join $dir $basename] Here, BASENAME was already an absolute file name that starts with a drive letter, but "file join" treated it as a relative file name. Another spot where we mishandle Unix vs drive letter file names, is in the "dir" command that we issue when starting every testcase under GDB. We currently always pass the file name as seen from the build machine (i.e., from MSYS2), which is a Unix file name that native Windows GDB does not understand, resulting in: (gdb) dir /c/gdb/src/gdb/testsuite/gdb.rocm warning: /c/gdb/src/gdb/testsuite/gdb.rocm: No such file or directory Source directories searched: /c/gdb/src/gdb/testsuite/gdb.rocm;$cdir;$cwd This patch introduces a systematic approach to handle all this, by introducing the concepts of build file names (what DejaGnu sees) vs host file names (what GDB sees). This patches implements that in the following way: 1) - Keep standard_output_file's host-side semantics standard_output_file currently converts the file name to a Windows file name, using the "cd $dir; pwd -W" trick. standard_output_file is used pervasively, so I think it should keep the semantics that it returns a host file name. Note there is already a preexisting host_standard_output_file procedure. The difference to standard_output_file is that host_standard_output_file handles remote hosts, while standard_output_file assumes the build and host machines share a filesystem. The MSYS2 Unix path vs MinGW GDB drive letter case fall in the "shared filesystem" bucket. An NFS mount on the host at the same mount point as on the build machine falls in that bucket too. 2) - Introduce build_standard_output_file In some places, we are calling standard_output_file to find the build-side file name, most often just to find the standard output directory file name, and then immediately use that file name with TCL file manipulation procedures, to do some file manipulation on the build machine. clean_standard_output_dir is an example of such a case. That code path is responsible for this bogus 'rm -rf' in current MSYS2 testing: Running /c/gdb/src/gdb/testsuite/gdb.base/break.exp ... Executing on build: rm -rf /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-tests... For these cases, add a variant of standard_output_file called build_standard_output_file. The main difference to standard_output_file is that it doesn't do the "cd $dir; pwd -W" trick. I.e., it returns a path on the build machine. 3) Introduce host_file_sanitize In some cases, we read an absolute file name out of GDB's output, and then want to compare it against some other file name. The file name may originally come from the DWARF, and sometimes may have forward slashes, and other times, it may have backward slashes. Or the drive letter may be uppercase, or it may be lowercase. To make comparisons easier, add a new host_file_sanitize procedure, that normalizes slashes, and uppercases the drive letter. It does no other normalization. Particularly, it does not turn a relative file name into an absolute file name. It's arguable whether GDB itself should do this sanitization. I suspect it should. I personally dislike seeing backward slashes in e.g., "info shared" output, or worse, mixed backward and forward slashes. Still, I propose starting with a testsuite adjustment that moves us forward, and handle that separately. I won't be surprised if we need the new routine for some cases even if we adjust GDB. 4) build_file_normalize / host_file_normalize In several places in the testsuite, we call "file normalize" on some file name. If we pass it a drive-letter file name, that TCL procedure treats the passed in file name as a relative file name, so produces something like /c/foo/C:/foo/bar.txt. If the context calls for a build file name, then the "file normalize" call should produce /c/foo/bar.txt. If OTOH we need a host file name, then it should produce "C:/foo/bar.txt". Handle this by adding two procedures that wrap "file normalize": - build_file_normalize - host_file_normalize Initialy I implemented them in a very simple way, calling into cygpath: proc build_file_normalize {filename} { if { [ishost *-*-mingw*] } { return [exec cygpath -ua $filename] } else { return [file normalize $filename] } } proc host_file_normalize {filename} { if { [ishost *-*-mingw*] } { return [exec cygpath -ma $filename] } else { return [file normalize $filename] } } "cygpath" is a utility that comes OOTB with both Cygwin and MSYS2, that does Windows <-> Cygwin file name conversion. This works well, but because running the testsuite on Windows is so slow, I thought of trying to avoid or minimize the cost of calling an external utility ("cygpath"). On my system, calling into cygpath takes between 200ms to 350ms, and these smallish costs (OK, not so small!) can creep up and compound an already bad situation. Note that the current call to "cd $dir; pwd -W" has about the same cost as a "cygpath" call (though a little bit cheaper). So with this patch, we actually don't call cygpath at all, and no longer use the "cd $dir; pwd -W" trick. Instead we run the "mount" command once, and cache the mapping (via gdb_caching_proc) between Windows file names and Unix mount points, and then use that mapping in host_file_normalize and build_file_normalize, to do the Windows <=> Unix file name conversions ourselves. One other small advantage here is that this approach works the same for 'cygwin x mingw' testing [1], and 'msys x mingw' testing, while "pwd -W" only works on MSYS2. So I think the end result is that we should end up faster (or less slow) than the current state. (No, I don't have actual timings for the effect over a whole testsuite run.) 5) Introduce host_file_join For the "file join" call done from within standard_output_file (and probably in future other places), since that procedure works with host file names, add a new host_file_join procedure that is a wrapper around "file join" that is aware of Windows drive letters. ====== With the infrastructure described above in place, the "dir" case is fixed by simply calling host_file_normalize on the directory name, before passing it to GDB. That turns: (gdb) dir /c/gdb/src/gdb/testsuite/gdb.base warning: /c/gdb/src/gdb/testsuite/gdb.base: No such file or directory Source directories searched: /c/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd Into: (gdb) dir C:/gdb/src/gdb/testsuite/gdb.base Source directories searched: C:/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd Running the testsuite on GNU/Linux reveals that that change requires tweaks to gdb.guile/scm-parameter.exp and gdb.python/py-parameter.exp, to run the expected directory by host_file_normalize too, so that it matches the directory we initially pass GDB at startup time. Without that fix, there could be a mismatch if the GDB sources path has a symlink component, which now gets resolved by the host_file_normalize call. The theory is that most standard_output_file uses will not need to be adjusted. I grepped for "file normalize" and "file join", to find cases that might need adjustment, and fixed those that required fixing. The fixes are included in this patch, to make it easier to reason about the overall change. E.g., in gdb.base/fullname.exp, without the fix, we get: Running /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp ... ERROR: tcl error sourcing /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp. ERROR: tcl error code NONE ERROR: C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/fullname/tmp-fullname.c not a subdir of /c/msys2/home/alves/gdb/build-testsuite In gdb.base/source-dir.exp, we have several issues. E.g., we see the "/c/foo/c:/foo" problem there too: dir /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs warning: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs: No such file or directory Source directories searched: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs;$cdir;$cwd (gdb) PASS: gdb.base/source-dir.exp: setup source path search directory ... Executing on host: x86_64-w64-mingw32-gcc \ -fno-stack-protector \ /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/macro-source-path/cwd/macro-source-path.c ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... and we need to handle Unix file names that we pass to the compiler (on the build side), vs file names that GDB prints out (the host side). Similarly in the other testcases. I haven't yet tried to do a full testsuite run on MSYS2, and I'm quite confident there will be more places that will need similar adjustment, but I'd like to land the infrastructure early, so that the rest of the testsuite can be adjusted incrementally, and others can help. Change-Id: I664dbb86d0efa4fa8db405577bea2b4b4a96a613 2025-08-22 Simon Marchi gdb/copyright.py: print notice about files that print copyright at runtime During the last new year process, it seems that we forgot to update the copyright notices printed by the various programs (see 713b99a9398 "gdb, gdbserver: update copyright years in copyright notices"). Change gdb/copyright.py to print a message about this. For a procedure that happens once a year, this seems sufficient to me, but if someone wants to automate it I won't object. While at it, change the formatting of the previous message, to match the formatting of the first message (making it end with a colon). Change-Id: I330f566221d102bab0a953bc324127f2466dd5cf Approved-By: Tom Tromey 2025-08-22 Pedro Alves testsuite: Introduce gdb_watchdog (avoid unistd.h/alarm) There are a good number of testcases in the testsuite that use alarm() as a watchdog that aborts the test if something goes wrong. alarm()/SIG_ALRM do not exist on (native) Windows, so those tests fail to compile there. For example, testing with x86_64-w64-mingw32-gcc, we see: Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ... gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c: In function 'main': C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:17:3: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration] 17 | alarm (60); | ^~~~~ While testing with a clang configured to default to x86_64-pc-windows-msvc, which uses the C/C++ runtime headers from Visual Studio and has no unistd.h, we get: Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ... gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:8:10: fatal error: 'unistd.h' file not found 8 | #include | ^~~~~~~~~~ Handle this by adding a new testsuite/lib/gdb_watchdog.h header that defines a new gdb_watchdog function, which wraps alarm on Unix-like systems, and uses a timer on Windows. This patch adjusts gdb.base/attach.c as example of usage. Testing gdb.base/attach.exp with clang/x86_64-pc-windows-msvc required a related portability tweak to can_spawn_for_attach, to not rely on unistd.h on Windows. gdb.rocm/mi-attach.cpp is another example adjusted, one which always runs with clang configured as x86_64-pc-windows-msvc on Windows (via hipcc). Approved-by: Kevin Buettner Change-Id: I3b07bcb60de039d34888ef3494a5000de4471951 2025-08-22 Pedro Alves Automatically handle includes in testsuite/lib/ Instead of manually calling lappend_include_file in every testcase that needs to include a file in testsuite/lib/, handle testsuite/lib/ includes automatically in gdb_compile. As an example, gdb.base/backtrace.exp is adjusted to no longer explicitly call lappend_include_file for testsuite/lib/attributes.h. Tested on x86-64 GNU/Linux with both: $ make check RUNTESTFLAGS=" \ --host_board=local-remote-host-native \ --target_board=local-remote-host-native \ HOST_DIR=/tmp/foo/" \ TESTS="gdb.base/backtrace.exp" and: $ make check TESTS="gdb.base/backtrace.exp" and confirming that the testcase still compiles and passes cleanly. Also ran full testsuite on x86-64 GNU/Linux in normal mode. Approved-by: Kevin Buettner Change-Id: I5ca77426ea4a753a995c3ad125618c02cd952576 2025-08-22 Simon Marchi gdb/solib-svr4: fix wrong namespace id for dynamic linker When running a program that uses multiple linker namespaces, I get something like: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-ns-ids -ex "tb 50" -ex r -ex "info shared" -batch ... From To NS Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 0 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7e93000 0x00007ffff7f8b000 0 Yes /usr/lib/libm.so.6 0x00007ffff7ca3000 0x00007ffff7e93000 0 Yes /usr/lib/libc.so.6 0x00007ffff7fb7000 0x00007ffff7fbc000 1 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so 0x00007ffff7b77000 0x00007ffff7c6f000 1 Yes /usr/lib/libm.so.6 0x00007ffff7987000 0x00007ffff7b77000 1 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 1 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fb2000 0x00007ffff7fb7000 2 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so 0x00007ffff788f000 0x00007ffff7987000 2 Yes /usr/lib/libm.so.6 0x00007ffff769f000 0x00007ffff788f000 2 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 1! Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fad000 0x00007ffff7fb2000 3 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/dlmopen-ns-ids/dlmopen-lib.so 0x00007ffff75a7000 0x00007ffff769f000 3 Yes /usr/lib/libm.so.6 0x00007ffff73b7000 0x00007ffff75a7000 3 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 1! Yes /usr/lib/ld-linux-x86-64.so.2 Some namespace IDs for the dynamic linker entries (ld-linux) are wrong (I placed a ! next to those that are wrong). The dynamic linker is special: it is loaded only once (notice how all ld-linux entries have the same addresses), but it is visible in all namespaces. It is therefore listed separately in all namespaces. The problem happens like this: - for each solib, print_solib_list_table calls solib_ops::find_solib_ns to get the namespace ID to print - svr4_solib_ops::find_solib_ns calls find_debug_base_for_solib - find_debug_base_for_solib iterates on the list of solibs in all namespaces, looking for a match for the given solib. For this, it uses svr4_same, which compares two SOs by name and low address. Because there are entries for the dynamic linker in all namespaces, with the same low address, find_debug_base_for_solib is unable to distinguish them, and sometimes returns the wrong namespace. To fix this, save in lm_info_svr4 the debug base address that this lm/solib comes from, as a way to distinguish two solibs that would be otherwise identical. The code changes are: - Add a constructor to lm_info_svr4 accepting the debug base. Update all callers, which sometimes requires passing down the debug base. - Modify find_debug_base_for_solib to return the debug base directly from lm_info_svr4. - Modify svr4_same to consider the debug base value of the two libraries before saying they are the same. While at it, move the address checks before the name check, since they are likely less expensive to do. - Modify svr4_solib_ops::default_debug_base to update the debug base of existing solibs when the default debug base becomes known. I found the last point to be necessary, because when running an inferior, we list the shared libraries very early (before the first instruction): #0 svr4_solib_ops::current_sos (this=0x7c1ff1e09710) #1 0x00005555643c774e in update_solib_list (from_tty=0) #2 0x00005555643ca377 in solib_add (pattern=0x0, from_tty=0, readsyms=1) #3 0x0000555564335585 in svr4_solib_ops::enable_break (this=0x7c1ff1e09710, info=0x7d2ff1de8c40, from_tty=0) #4 0x000055556433c85c in svr4_solib_ops::create_inferior_hook (this=0x7c1ff1e09710, from_tty=0) #5 0x00005555643d22cb in solib_create_inferior_hook (from_tty=0) #6 0x000055556337071b in post_create_inferior (from_tty=0, set_pspace_solib_ops=true) #7 0x00005555633726a2 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) #8 0x0000555563372b35 in run_command (args=0x0, from_tty=0) At this point, the dynamic linker hasn't yet filled the DT_DEBUG slot, which normally points at the base of r_debug. Since we're unable to list shared libraries at this point, we go through svr4_solib_ops::default_sos, which creates an solib entry for the dynamic linker. At this point, we have no choice but to create it with a debug base of 0 (or some other value that indicates "unknown"). If we left it as-is, then it would later not be recognized to be part of any existing namespace and that would cause problems down the line. With this change, the namespaces of the dynamic linker become correct. I was not sure if the code in library_list_start_library was conflating debug base and lmid. The documentation says this about the "lmid" field in the response of a qxfer:libraries-svr4:read packet: lmid, which is an identifier for a linker namespace, such as the memory address of the r_debug object that contains this namespace’s load map or the namespace identifier returned by dlinfo (3). When I read "lmid", I typically think about "the namespace identifier returned by dlinfo (3)". In library_list_start_library, we use the value of the "lmid" attribute as the debug base address. This is the case even before this patch, since we do: solist = &list->solib_lists[lmid]; The key for the solib_lists map is documented as being the debug base address. In practice, GDBserver uses the debug base address for the "lmid" field, so we're good for now. If the remote side instead used "the namespace identifier returned by dlinfo (3)" (which in practice with glibc are sequential integers starting at 0), I think we would be mostly fine. If we use the qxfer packet to read the libraries, we normally won't use the namespace base address to do any memory reads, as all the information comes from the XML. There might be some problems however because we treat the namespace 0 specially, for instance in svr4_solib_ops::update_incremental. In that case, we might need a different way of indicating that the remote side does not give namespace information than using namespace 0. This is just a thought for the future. I improved the existing test gdb.base/dlmopen-ns-ids.exp to verify that "info sharedlibrary" does not show duplicate libraries, duplicate meaning same address range, namespace and name. Change-Id: I84467c6abf4e0109b1c53a86ef688b934e8eff99 Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib-svr4: centralize fetching of default debug base When running an inferior, solib_ops_svr4::current_sos is called very early, at a point where the default debug base is not yet accessible. The inferior is stopped at its entry point, before the dynamic linker had the time to fill the DT_DEBUG slot. It only becomes available a little bit later. In a following patch, I will want to do some action when the debug base becomes known (namely, update the debug base in the previously created lm_info_svr4 instances). For this reason, add the svr4_solib_ops::default_debug_base method to centralize where we fetch the default debug base. I will then be able to add my code there, when detecting the debug base changes. This patch brings the following behavior change: since all svr4_solib_ops entry points now use svr4_solib_ops::default_debug_base to get the debug base value, they will now all re-fetch the value from the inferior. Previously, this was not done consistently, only in two spots. It seems to me like it would be good to be consistent about that, because we can't really predict which methods will get called in which order in all scenarios. Some internal methods still access svr4_info::default_debug_base directly, because it is assumed that their caller would have used svr4_solib_ops::default_debug_base, updating the value in svr4_info::default_debug_base if necessary. Change-Id: Ie08da34bbb3ad6fd317c0e5802c5c94d8c7d1ce5 Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb: make iterate_over_objfiles_in_search_order methods of program_space and solib_ops Change the "iterate over objfiles in search order" operation from a gdbarch method to methods on both program_space and solib_ops. The first motivation for this is that I want to encapsulate solib-svr4's data into svr4_solib_ops (in a subsequent series), instead of it being in a separate structure (svr4_info). It is awkward to do so as long as there are entry points that aren't the public solib_ops interface. The second motivation is my project of making it able to have multiple solib_ops per program space (which should be the subject of said subsequent series), to better support heterogenousa systems (like ROCm, with CPU and GPU in the same inferior). When we have this, when stopped in GPU code, it won't make sense to ask the host's architecture to do the iteration, as the logic could be different for the GPU architecture. Instead, program_space::iterate_over_objfiles_in_search_order will be responsible to delegate to the various solib_ops using a logic that is yet to be determined. I included this patch in this series (rather than the following one) so that svr4_solib_ops::iterate_over_objfiles_in_search_order can access svr4_solib_ops::default_debug_base, introduced in a later patch in this series. default_iterate_over_objfiles_in_search_order becomes the default implementation of solib_ops::iterate_over_objfiles_in_search_order. As far as I know, all architectures using svr4_iterate_over_objfiles_in_search_order also use solib_ops_svr4, so I don't expect this patch to cause behavior changes. Change-Id: I71f8a800b8ce782ab973af2f2eb5fcfe4e06ec76 Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb: rename svr4_same_1 -> svr4_same_name This makes it a bit clearer that it compares shared libraries by name. While at it, change the return type to bool. Change-Id: Ib11a931a0cd2e00bf6ae35c5b6e0d620298d46cb Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib-svr4: add get_lm_info_svr4 Add this function, as a shortcut of doing the more verbose: auto *li = gdb::checked_static_cast (*solib.lm_info); Change-Id: I0206b3a8b457bdb276f26b354115e8f44416dfcf Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib: save program space in solib_ops In some subsequent patches, solib_ops methods will need to access the program space they were created for. We currently access the program space using "current_program_space", but it would better to remember the program space at construction time instead. Change-Id: Icf2809435a23c47ddeeb75e603863b201eff2e58 Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib: adjust info linker-namespaces/sharedlibrary format I would like to propose some minor changes to the format of "info linker namespaces" and "info sharedlibrary", to make it a bit tidier and less chatty. Here are the current formats (I replaced empty lines with dots, so that git doesn't collapse them): (gdb) info linker-namespaces There are 3 linker namespaces loaded There are 5 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 0x00007ffff7e94000 0x00007ffff7f8c000 Yes /usr/lib/libm.so.6 0x00007ffff7ca4000 0x00007ffff7e94000 Yes /usr/lib/libc.so.6 0x00007ffff7fad000 0x00007ffff7fb2000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fa8000 0x00007ffff7fad000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so . . There are 6 libraries loaded in linker namespace [[1]] Displaying libraries for linker namespace [[1]]: From To Syms Read Shared Object Library 0x00007ffff7fb7000 0x00007ffff7fbc000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fb2000 0x00007ffff7fb7000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7b79000 0x00007ffff7c71000 Yes /usr/lib/libm.so.6 0x00007ffff7989000 0x00007ffff7b79000 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7f99000 0x00007ffff7f9e000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so . . There are 5 libraries loaded in linker namespace [[2]] Displaying libraries for linker namespace [[2]]: From To Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fa3000 0x00007ffff7fa8000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7f9e000 0x00007ffff7fa3000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7891000 0x00007ffff7989000 Yes /usr/lib/libm.so.6 0x00007ffff76a1000 0x00007ffff7891000 Yes /usr/lib/libc.so.6 (gdb) info sharedlibrary From To NS Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 [[0]] Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7e94000 0x00007ffff7f8c000 [[0]] Yes /usr/lib/libm.so.6 0x00007ffff7ca4000 0x00007ffff7e94000 [[0]] Yes /usr/lib/libc.so.6 0x00007ffff7fb7000 0x00007ffff7fbc000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fb2000 0x00007ffff7fb7000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7b79000 0x00007ffff7c71000 [[1]] Yes /usr/lib/libm.so.6 0x00007ffff7989000 0x00007ffff7b79000 [[1]] Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fad000 0x00007ffff7fb2000 [[0]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fa8000 0x00007ffff7fad000 [[0]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7fa3000 0x00007ffff7fa8000 [[2]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7f9e000 0x00007ffff7fa3000 [[2]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7891000 0x00007ffff7989000 [[2]] Yes /usr/lib/libm.so.6 0x00007ffff76a1000 0x00007ffff7891000 [[2]] Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7f99000 0x00007ffff7f9e000 [[1]] Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so Here is what I would change: - I find that the [[...]] notation used everywhere is heavy and noisy. I understand that this is the (proposed) notation for specifying a namespace id in an expression. But I don't think it's useful to print those brackets everywhere (when it's obvious from the context that the number is a namespace id). I would remove them from the messages and from the tables. - I find these lines a bit too verbose: There are X libraries loaded in linker namespace [[Y]] Displaying libraries for linker namespace [[Y]]: I think they can be condensed to a single line, without loss of information (I think that printing the number of libs in each namespace is not essential, but I don't really mind, so I left it there). - I would add an empty line after the "There are N linker namespaces loaded" message, to visually separate it from the first group. I would also finish that line with a period. - There are two empty lines between each group I think that one empty line is sufficient to do a visual separation. Here's how it looks with this patch: (gdb) info linker-namespaces There are 3 linker namespaces loaded. 5 libraries loaded in linker namespace 0: From To Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7e94000 0x00007ffff7f8c000 Yes /usr/lib/libm.so.6 0x00007ffff7ca4000 0x00007ffff7e94000 Yes /usr/lib/libc.so.6 0x00007ffff7fad000 0x00007ffff7fb2000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fa8000 0x00007ffff7fad000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 6 libraries loaded in linker namespace 1: From To Syms Read Shared Object Library 0x00007ffff7fb7000 0x00007ffff7fbc000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fb2000 0x00007ffff7fb7000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7b79000 0x00007ffff7c71000 Yes /usr/lib/libm.so.6 0x00007ffff7989000 0x00007ffff7b79000 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7f99000 0x00007ffff7f9e000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so 5 libraries loaded in linker namespace 2: From To Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fa3000 0x00007ffff7fa8000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7f9e000 0x00007ffff7fa3000 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7891000 0x00007ffff7989000 Yes /usr/lib/libm.so.6 0x00007ffff76a1000 0x00007ffff7891000 Yes /usr/lib/libc.so.6 (gdb) info shared From To Linker NS Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 0 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7e94000 0x00007ffff7f8c000 0 Yes /usr/lib/libm.so.6 0x00007ffff7ca4000 0x00007ffff7e94000 0 Yes /usr/lib/libc.so.6 0x00007ffff7fb7000 0x00007ffff7fbc000 1 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fb2000 0x00007ffff7fb7000 1 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7b79000 0x00007ffff7c71000 1 Yes /usr/lib/libm.so.6 0x00007ffff7989000 0x00007ffff7b79000 1 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 1 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7fad000 0x00007ffff7fb2000 0 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7fa8000 0x00007ffff7fad000 0 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7fa3000 0x00007ffff7fa8000 2 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so 0x00007ffff7f9e000 0x00007ffff7fa3000 2 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so 0x00007ffff7891000 0x00007ffff7989000 2 Yes /usr/lib/libm.so.6 0x00007ffff76a1000 0x00007ffff7891000 2 Yes /usr/lib/libc.so.6 0x00007ffff7fc6000 0x00007ffff7fff000 1 Yes /usr/lib/ld-linux-x86-64.so.2 0x00007ffff7f99000 0x00007ffff7f9e000 1 Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so Change-Id: Iefad340f7f43a15cff24fc8e1301f91d3d7f0278 Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib: don't check filename when checking for duplicate solib On Arch Linux, I get: FAIL: gdb.base/dlmopen-ns-ids.exp: reopen a namespace The symptom observed is that after stepping over the last dlmopen of the test, "info sharedlibrary" does not show the library just opened. After digging, I found that when stepping over that dlmopen call, the shlib event breakpoint (that GDB inserts in glibc to get notified of dynamic linker activity) does not get hit. I then saw that after the previous dlclose, the shlib event breakpoints were suddenly all marked as pending: (gdb) maintenance info breakpoints Num Type Disp Enb Address What -1 shlib events keep n -1.1 y- The root cause of this problem is the fact that the dynamic linker path specified in binaries contains a symlink: $ readelf --program-headers /bin/ls | grep "Requesting program interpreter" [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] $ ls -l /lib64 lrwxrwxrwx 1 root root 7 May 3 15:26 /lib64 -> usr/lib $ realpath /lib64/ld-linux-x86-64.so.2 /usr/lib/ld-linux-x86-64.so.2 As a result, the instances of the dynamic linker in the non-base namespace have the real path instead of the original path: (gdb) info sharedlibrary From To NS Syms Read Shared Object Library 0x00007ffff7fc6000 0x00007ffff7fff000 [[0]] Yes /lib64/ld-linux-x86-64.so.2 ... 0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2 ... 0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2 ... 0x00007ffff7fc6000 0x00007ffff7fff000 [[1]] Yes /usr/lib/ld-linux-x86-64.so.2 Notice that all instances of the dynamic loader have the same address range. This is expected: the dynamic loader is really loaded just once in memory, it's just that it's visible in the various namespaces, so listed multiple times. Also, notice that the last three specify namespace 1... seems like a separate bug to me (ignore it for now). The fact that the paths differ between the first one and the subsequent ones is not something we control: we receive those paths as-is from the glibc link map. Since these multiple solib entries are really the same mapping, we would expect this code in solib_read_symbols to associate them to the same objfile: /* Have we already loaded this shared object? */ so.objfile = nullptr; for (objfile *objfile : current_program_space->objfiles ()) { if (filename_cmp (objfile_name (objfile), so.name.c_str ()) == 0 && objfile->addr_low == so.addr_low) { so.objfile = objfile; break; } } But because the filenames differ, we end up creating two different objfiles with the same symbols, same address ranges, etc. I would guess that this is not a state we want. When the dlclose call closes the last library from the non-base namespace, the dynamic linker entry for that namespace is also removed. From GDB's point of view, it just looks like an solib getting unloaded. In update_solib_list, we have this code to check if the objfile behind the solib is used by other solibs, and avoid deleting the objfile if so: bool still_in_use = (gdb_iter->objfile != nullptr && solib_used (current_program_space, *gdb_iter)); /* Notify any observer that the shared object has been unloaded before we remove it from GDB's tables. */ notify_solib_unloaded (current_program_space, *gdb_iter, still_in_use, false); /* Unless the user loaded it explicitly, free SO's objfile. */ if (gdb_iter->objfile != nullptr && !(gdb_iter->objfile->flags & OBJF_USERLOADED) && !still_in_use) gdb_iter->objfile->unlink (); Because this is the last solib to use that objfile instance, the objfile is deleted. In the process, disable_breakpoints_in_unloaded_shlib (in breakpoint.c) is called. The breakpoint locations for the shlib event breakpoints get marked as "shlib_disabled", which then causes them (I suppose) to not get inserted and be marked as pending. And then, when stepping on the subsequent dlmopen call, GDB misses the load of the new library. It seems clear to me that, at least, the duplicate objfile detection in solib_read_symbols needs to be fixed. Right now, to conclude that an solib matches an existing objfile, it checks that: - the two have equivalent paths (filename_cmp) - the two have the same "low" address In this patch, I remove the filename check. This makes it such that all the solibs for dynamic linker entries will share the same objfile. This assumes that no two different solibs / objfiles will have the same low address. At first glance, it seems like a reasonable assumption to make, but I don't know if there are some corner cases where this is not true. To fix my specific case, I could change the code to resolve the symlinks and realize that these are all the same file. But I don't think it would work in a general way. For example, if debugging remotely and using the target: filesystem, we would need to resolve the symlink on the target, and I don't think we can do that today (there is no readlink/realpath operation in the target file I/O). With this patch, gdb.base/dlmopen-ns-ids.exp passes cleanly: # of expected passes 44 Change-Id: I3b60051085fb9597b7a72f50122c1104c969908e Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/solib-svr4: make "lmid" XML attribute optional When connecting to a GDBserver 12, which doesn't have support for non-default linker namespaces and the "lmid" attribute in the qxfer:libraries-svr4:read response, I get: (gdb) c Continuing. ⚠️ warning: while parsing target library list (at line 1): Required attribute "lmid" of not specified Given the code in library_list_start_library, I understand that the "lmid" attribute is meant to be optional. Mark it as optional in the attribute descriptions, to avoid this warning. Change-Id: Ieb10ee16e36bf8a771f944006e7ada1c10f6fbdc Reviewed-By: Guinevere Larsen 2025-08-22 Simon Marchi gdb/testsuite: handle dynamic linker path with symlink in dlmopen tests On my Arch Linux system*, the dynamic linker path specified in ELF binaries contains a symlink: $ readelf --program-headers /bin/ls | grep "Requesting program interpreter" [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] $ ls -l /lib64 lrwxrwxrwx 1 root root 7 May 3 15:26 /lib64 -> usr/lib $ realpath /lib64/ld-linux-x86-64.so.2 /usr/lib/ld-linux-x86-64.so.2 Because of this, some dlmopen tests think that the dynamic linker doesn't appear multiple times, when it in fact does (under two different names), and some parts of the test are disabled: UNSUPPORTED: gdb.base/dlmopen.exp: test_solib_unmap_events: multiple copies of the dynamic linker not found Make the tests compute the real path of the dynamic linker and accept that as valid path for the dynamic linker. With this patch, I go from # of expected passes 92 to # of expected passes 98 * On my Ubuntu 24.04 system, the dynamic linker appears to be a symlink too, but the glibc is too old to show the dynamic linker in the non-default namespace. Change-Id: I03867f40e5313816bd8a8401b65713ddef5d620e Reviewed-By: Guinevere Larsen 2025-08-22 Rainer Orth ld: testsuite: Only xfail "shared (non PIC)" etc. on 64-bit Solaris Once the ld-shared tests run on both Solaris/SPARC and x86, two tests XPASS on 32-bit Solaris, both SPARC and x86 (pre-existing on SPARC, newly revealed on x86): XPASS: shared (non PIC) XPASS: shared (PIC main, non PIC so) Consequently, this patch restricts xfailing them to 64-bit Solaris. There now remain 1 (32-bit) or 3 (64-bit) XFAILs. I've checked the reasons and found all comments in shared.exp are wrong: * The common one (SPARC and x86, 32 and 64-bit) is XFAIL: shared (non PIC, load offset) The error is always the same: ld.so.1: shnp: fatal: tmpdir/shnp.so: unknown file type Running shnp under truss reveals 26170: openat(AT_FDCWD, "tmpdir/shnp.so", O_RDONLY) = 3 26170: mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFFFF7F5D0058, 0xFFFFFFFF7FFFE8A0, 0x00000000) Err#48 ENOTSUP which can be traced in the mmapobj(2) implementation to the requirement that a shared object's p_vaddr needs to be 0, which in this test is intentionally not the case. * The other two XFAIL's are 64-bit only and for another reason: XFAIL: shared (non PIC) XFAIL: shared (PIC main, non PIC so) On sparcv9, shnp execution fails: ld.so.1: shnp: fatal: relocation error: R_SPARC_H44: file tmpdir/shnp.so: symbol shlibvar2: value 0x3fffffffb9c does not fit On amd64, shmpnp.so fails to link: ld/tmpdir/ld/collect-ld: tmpdir/sh1np.o: relocation R_X86_64_32S against symbol `shlib_shlibvar1' can not be used when making a shared object; recompile with -fPIC ld/tmpdir/ld/collect-ld: failed to set dynamic section sizes: bad value In both cases, this happens with -z text, too, so the comments are bogus. Instead, the issue that the code needs to be PIC. So I'm updating the comments accordingly. Tested on sparc{v9,}-sun-solaris2.11 and {amd64,i386}-pc-solaris2.11. 2025-07-30 Rainer Orth ld: * testsuite/ld-shared/shared.exp (shared (non PIC)): Update comment. xfail on 64-bit Solaris only. (shared (PIC main, non PIC so)): Likewise. (shared (non PIC, load offset)): Update comment. 2025-08-22 Rainer Orth ld: testsuite: Enable ld-shared tests on Solaris/x86 The ld-shared tests are run on Solaris/SPARC only for no apparent reason. This patch enables them on Solaris in general. It leaves two XPASSes on 32-bit Solaris (both SPARC and x86), which I'll address in a followup. Tested on {amd64,i386}-pc-solaris2.11 and sparc{v9,}-sun-solaris2.11. 2025-07-25 Rainer Orth ld: * testsuite/ld-shared/shared.exp: Enable on *-*-solaris2* rather than sparc*-*-solaris2* only. 2025-08-22 Jan Beulich MAINTAINERS: move Jim Wilson to Past Maintainers ..., effectively yielding IA-64 maintainer-less, as per his request: https://sourceware.org/pipermail/binutils/2025-August/143393.html https://sourceware.org/pipermail/binutils/2025-August/143491.html Jim - thanks much for your past work. 2025-08-22 Jan Beulich gas: make as_tsktsk() output more as_warn()-like The lack of a uniform "Warning: " prefix can be irritating. Re-use as_warn_internal(), by moving the warning count increment into the pre- existing callers (where the flag_no_warnings checks also are). At the same time keep the listing_warning() invocation at its place - listings certainly should have such warnings reproduced as well. While there also drop the unnecessary forward declarations of static functions. 2025-08-22 Jan Beulich ld/aarch64: prune a PE/COFF test Expecting ___tls_end__ there is entirely random, when there are multiple symbols all at the same address. Help objdump to pick the intended symbol, by making it global and giving it a type. 2025-08-22 Lulu Cai LoongArch: Improve the reliability of test cases Fix PR ld/31101 In some distributions, GCC enables --as-needed by default, which may prevent linking to necessary dynamic libraries and cause test failures. When tests require the host GCC, use the --no-as-needed option and place the necessary dynamic libraries after the object files. This prevents test failures and improves the test case reliability. 2025-08-22 Alan Modra Don't run cfi-commit-10 test on 32-bit targets 2025-08-22 GDB Administrator Automatic date update in version.in 2025-08-21 Andrew Burgess gdb/python: check return value of PyObject_New in all cases I spotted a few cases where the return value of PyObject_New was not being checked against nullptr, but we were dereferencing the result. All fixed here. The fixed functions can now return NULL, so I checked all the callers, and I believe there will handle a return of NULL correctly. Assuming calls to PyObject_New never fail, there should be no user visible changes after this commit. No tests here as I don't know how we'd go about causing a Python object allocation to fail. Approved-By: Simon Marchi 2025-08-21 GDB Administrator Automatic date update in version.in 2025-08-21 H.J. Lu elf: Clear entsize when clearing SEC_MERGE|SEC_STRINGS When generating an output from input SEC_MERGE|SEC_STRINGS sections with different entsizes, we clear the SEC_MERGE|SEC_STRINGS bits. We also need to clear entsize. PR ld/33291 * ldlang.c (lang_add_section): Clearing entsize when clearing SEC_MERGE|SEC_STRINGS. * testsuite/ld-elf/pr33291.d: New file. * testsuite/ld-elf/pr33291a.s: Likewise. * testsuite/ld-elf/pr33291b.s: Likewise. 2025-08-20 H.J. Lu i386: Add GLIBC_ABI_GNU_TLS version dependency On Linux/i386, programs and shared libraries compiled with -mtls-dialect=gnu may fail silently at run-time against glibc without the GNU TLS run-time fix for: https://sourceware.org/bugzilla/show_bug.cgi?id=32996 The glibc version tag, GLIBC_ABI_GNU_TLS, has been added to indicate that glibc has the working GNU TLS run-time: commit ed1b7a5a489ab555a27fad9c101ebe2e1c1ba881 Author: H.J. Lu Date: Mon Jul 28 12:16:11 2025 -0700 i386: Add GLIBC_ABI_GNU_TLS version [BZ #33221] Add the --gnu-tls-tag option to x86-64 ELF linker to add the GLIBC_ABI_GNU_TLS version dependency in output programs and shared libraries when linking against glibc if input relocatable object files call ___tls_get_addr. The output will fail to load and run at run-time against glibc which doesn't define the GLIBC_ABI_GNU_TLS version. Add the --enable-gnu-tls-tag configure option to enable --gnu-tls-tag by default. If unspecified, linker will add the GLIBC_ABI_GNU_TLS version dependency if input call ___tls_get_addr and libc.so defines the GLIBC_ABI_GNU2_TLS version. bfd/ PR ld/33287 * elf-linker-x86.h (elf_linker_x86_params): Add gnu_tls_version_tag. * elf32-i386.c (elf_backend_add_glibc_version_dependency): Add GLIBC_ABI_GNU_TLS support. * elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Set has_tls_get_addr_call to 1 if ___tls_get_addr is used. * elfxx-x86.h (elf_x86_link_hash_table): Add has_tls_get_addr_call. ld/ PR ld/33287 * Mention --gnu-tls-tag, --no-gnu-tls-tag and --enable-gnu-tls-tag. * config.in: Regenerated. * configure: Likewise. * configure.ac: Add --enable-gnu-tls-tag. * ld.texi: Document --gnu-tls-tag and --enable-gnu-tls-tag. * ldlex.h (option_values): Add OPTION_GNU_TLS_VERSION_TAG and OPTION_NO_GNU_TLS_VERSION_TAG. * emultempl/elf-i386-glibc.em (elf_i386_glibc_before_parse): Initialize params.gnu_tls_version_tag. (PARSE_AND_LIST_LONGOPTS_386): New. (PARSE_AND_LIST_OPTIONS_386): Likewise. (PARSE_AND_LIST_ARGS_CASES_386): Likewise. (PARSE_AND_LIST_LONGOPTS): Append $PARSE_AND_LIST_LONGOPTS_386. (PARSE_AND_LIST_OPTIONS): Append $PARSE_AND_LIST_OPTIONS_386. (PARSE_AND_LIST_ARGS_CASES): Append $PARSE_AND_LIST_ARGS_CASES_386. * testsuite/ld-i386/gnu-tls-1.s: Likewise. * testsuite/ld-i386/gnu-tls-1a.rd: Likewise. * testsuite/ld-i386/gnu-tls-1b.rd: Likewise. * testsuite/ld-i386/i386.exp: Run PR ld/33287 tests. 2025-08-20 H.J. Lu x86-64: Add GLIBC_ABI_DT_X86_64_PLT version dependency On Linux/x86-64, programs and shared libraries created with -z mark-plt have the GLIBC_2.36 version tag dependency since -z mark-plt uses the r_addend field of the R_X86_64_JUMP_SLOT relocation to store the offset of the indirect branch instruction. Glibc versions which don't have the commit added to 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 won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. If glibc versions defines GLIBC_ABI_DT_X86_64_PLT version tag with commit 399384e0c8193e31aea014220ccfa24300ae5938 Author: H.J. Lu Date: Thu Aug 14 07:03:20 2025 -0700 x86-64: Add GLIBC_ABI_DT_X86_64_PLT [BZ #33212] to indicate inclusion of the commit: 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 we can add GLIBC_ABI_DT_X86_64_PLT version tag dependency, instead of GLIBC_2.36 version tag dependency. PR ld/33213 * elf-bfd.h (_bfd_elf_link_add_glibc_version_dependency): Change return type to bool. * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): Add GLIBC_ABI_DT_X86_64_PLT version tag dependency, instead of, GLIBC_2.36 version tag dependency, for -z mark-plt if libc.so defines GLIBC_ABI_DT_X86_64_PLT version tag. * elflink.c (_bfd_elf_link_add_glibc_version_dependency): Change return type to bool. Return false if elf_link_add_glibc_verneed returns false. 2025-08-20 H.J. Lu x86: Add GLIBC_ABI_GNU2_TLS version dependency On Linux/x86, programs and shared libraries compiled with -mtls-dialect=gnu2 may fail silently at run-time against glibc without the GNU2 TLS run-time fixes for: https://sourceware.org/bugzilla/show_bug.cgi?id=31501 https://sourceware.org/bugzilla/show_bug.cgi?id=31372 A version tag, GLIBC_ABI_GNU2_TLS, has been added to glibc to indicate that glibc has the working GNU2 TLS run-time. Add the --gnu2-tls-tag option to i386/x86-64 ELF linker to add the GLIBC_ABI_GNU2_TLS version dependency in output programs and shared libraries when linking against glibc if input relocatable object files have R_386_TLS_DESC_CALL or R_X86_64_TLSDESC_CALL relocation. The output will fail to load and run at run-time against glibc which doesn't define the GLIBC_ABI_GNU2_TLS version. Add the --enable-gnu2-tls-tag configure option to enable --gnu2-tls-tag by default. If unspecified, linker will add the GLIBC_ABI_GNU2_TLS version dependency if input object files have R_386_TLS_DESC_CALL or R_X86_64_TLSDESC_CALL relocation and libc.so defines the GLIBC_ABI_GNU2_TLS version. Update elf_link_add_glibc_verneed to properly add the GLIBC_2.36 version dependency when -z mark-plt -z nopack-relative-relocs passed to x86-64 ELF linker. bfd/ PR ld/33130 * elf-bfd.h (_bfd_elf_link_add_glibc_version_dependency): Add a pointer to bool argument. * elf-linker-x86.h (elf_linker_x86_params): Add gnu2_tls_version_tag. * elf32-i386.c (elf_i386_scan_relocs): Set has_tls_desc_call to 1 for R_386_TLS_DESC_CALL. (elf_i386_add_glibc_version_dependency): New. Undef before FreeBSD support. * elf64-x86-64.c (elf_x86_64_scan_relocs): Set has_tls_desc_call to 1 for R_X86_64_TLSDESC_CALL. (elf_x86_64_add_glibc_version_dependency): Add GLIBC_ABI_GNU2_TLS version dependency if GLIBC_ABI_GNU2_TLS dependency isn't disabled and has_tlsdesc_call isn't 0. (elf_backend_add_glibc_version_dependency): Undef before FreeBSD support and redefine for elf32-x86-64. * elflink.c (elf_link_add_glibc_verneed): Changed to return bool. Remove the pointer to elf_find_verdep_info argument. Add a pointer to bool argument, auto_version. Return true if linked against glibc. Otherwise return false. If the version dependency is added, set *auto_version to true. If *auto_version is true, add the version dependency only if libc.so defines the version. (_bfd_elf_link_add_glibc_version_dependency): Add a pointer to bool argument and pass it to elf_link_add_glibc_verneed. (_bfd_elf_link_add_dt_relr_dependency): Pass NULL to _bfd_elf_link_add_glibc_version_dependency. * elfxx-x86.h (elf_x86_link_hash_table): Add has_tls_desc_call. ld/ PR ld/33130 * NEWS: Mention --gnu2-tls-tag, --no-gnu2-tls-tag and --enable-gnu2-tls-tag. * config.in: Regenerated. * configure: Likewise. * configure.ac: Add --enable-gnu2-tls-tag. * ld.texi: Document --gnu2-tls-tag/--no-gnu2-tls-tag. * ldlex.h (option_values): Add OPTION_GNU2_TLS_VERSION_TAG and OPTION_NO_GNU2_TLS_VERSION_TAG. * emulparams/elf32_x86_64.sh (EXTRA_EM_FILE): Changed to "elf-x86-64-glibc". * emulparams/elf_i386.sh (EXTRA_EM_FILE): Set to "elf-i386-glibc". * emulparams/elf_i386_fbsd.sh (EXTRA_EM_FILE): New. Set to "elf-x86". * emulparams/elf_i386_haiku.sh (EXTRA_EM_FILE): Likewise. * emulparams/elf_x86_64.sh (EXTRA_EM_FILE): Likewise. * emulparams/elf_x86_64_fbsd.sh (EXTRA_EM_FILE): New. Set to "elf-x86-64". * emulparams/elf_x86_64_haiku.sh (EXTRA_EM_FILE): Likewise. * (EXTRA_EM_FILE): Likewise. * (EXTRA_EM_FILE): Likewise. * emultempl/elf-i386-glibc.em: New file. * emultempl/elf-x86-64-glibc.em: Likewise. * emultempl/elf-x86-64.em: Likewise. * emultempl/elf-x86-glibc.em: Likewise. * emultempl/elf-x86.em (elf_x86_64_before_parse): Removed. (LDEMUL_BEFORE_PARSE): Likewise. (elf_x86_64_before_allocation): Likewise. (LDEMUL_BEFORE_ALLOCATION): Likewise. * emultempl/solaris2-x86-64.em: New file. * testsuite/ld-i386/gnu2-tls-1.s: Likewise. * testsuite/ld-i386/gnu2-tls-1a.rd: Likewise. * testsuite/ld-i386/gnu2-tls-1b.rd: Likewise. * testsuite/ld-x86-64/gnu2-tls-1.s: Likewise. * testsuite/ld-x86-64/gnu2-tls-1a.rd: Likewise. * testsuite/ld-x86-64/gnu2-tls-1b.rd: Likewise. * testsuite/ld-x86-64/mark-plt-2.rd: Likewise. * testsuite/ld-x86-64/mark-plt-2.s: Likewise. * testsuite/ld-i386/i386.exp: Run GLIBC_ABI_GNU2_TLS tests. * testsuite/ld-x86-64/x86-64.exp: Likewise. 2025-08-20 H.J. Lu ld: Compile some tests with -mdirect-extern-access When GCC enables -mno-direct-extern-access by default, some tests fail without -mdirect-extern-access. Define DIRECT_EXTERN_ACCESS_CFLAGS to compile these tests with -mdirect-extern-access. Also pass "-z noindirect-extern-access" to linker to support the C library compiled with -mno-direct-extern-access. PR ld/33267 * testsuite/config/default.exp (DIRECT_EXTERN_ACCESS_CFLAGS): New. * testsuite/ld-elf/linux-x86.exp: Compile some tests with $DIRECT_EXTERN_ACCESS_CFLAGS. * testsuite/ld-elfvers/vers.exp (need_direct_extern_access): New for i?86. Compile tests with $need_direct_extern_access. * testsuite/ld-i386/i386.exp: Compile some tests with $DIRECT_EXTERN_ACCESS_CFLAGS. * testsuite/ld-ifunc/ifunc.exp (need_direct_extern_access): New for i?86. Compile tests with $need_direct_extern_access. * testsuite/ld-shared/shared.exp (need_direct_extern_access): New for i?86. Compile tests with $need_direct_extern_access. * testsuite/ld-srec/srec.exp (CFLAGS_FOR_TARGET_TEST): Add $DIRECT_EXTERN_ACCESS_CFLAGS. (CXXFLAGS_FOR_TARGET_TEST): Likewise. * testsuite/ld-vsb/vsb.exp (need_direct_extern_access): New for i?86. Compile tests with $need_direct_extern_access. * testsuite/ld-x86-64/x86-64.exp: Compile some tests with $DIRECT_EXTERN_ACCESS_CFLAGS and link some tests with "-Wl,-z,noindirect-extern-access". Co-Authored-By: Sam James 2025-08-20 Guinevere Larsen gdb: rework _active_linker_namespaces variable This commit reworks the _active_linker_namespaces convenience variable following Simon's feedback here: https://sourceware.org/pipermail/gdb-patches/2025-August/219938.html This patch implements the renaming to _linker_namespace_count (following the standard set by _inferior_thread_count) and makes the convenience variable more resilient in the multi-inferior case by providing a new function, solib_linker_namespace_count, which counts gets the count of namespaces using the solib_ops of the provided program_space Approved-By: Simon Marchi 2025-08-20 Simon Marchi gdb/amd-dbgapi: make get_amd_dbgapi_inferior_info return a reference This function can't return a NULL pointer, so make it return a reference instead. Change-Id: I0970d6d0757181291b300bd840037a48330a7fbb 2025-08-20 Gopi Kumar Bulusu gdb/MAINTAINERS - ADD Gopi Kumar Bulusu gopi@sankhya.com 2025-08-20 Nelson Chu RISC-V: PR33216, Fixed gcc testcases failed for commit 28520d7 I made a stupid mistake in the commit 28520d7, allow to assemble slli/srli/srai with 0 immediate to hint c.slli/c.srli/c.srai. These hints will be regared as illegal instruction for gdb and qemu, so at least I got following gcc testcases failed, === g++: Unexpected fails for rv64gc lp64d medlow === FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test === gfortran: Unexpected fails for rv64gc lp64d medlow === FAIL: gfortran.dg/leadz_trailz_2.f90 -O0 execution test === gcc: Unexpected fails for rv64gc lp64d medlow === FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test So we should just allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate. gas/ PR 33216 * testsuite/gas/riscv/c-zero-imm.d: Only allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate. * testsuite/gas/riscv/c-zero-imm.s: Likewise. opcodes/ PR 33216 * riscv-opc.c (match_slli_as_c_slli): Added back. (match_srxi_as_c_srxi): Likewise. (riscv_opcodes): Only allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate. 2025-08-20 Alan Modra Remove cloudabi support Apparently the cloudabi project is dead. The cloudabi support branded object files with ELFOSABI_CLOUDABI but other than that didn't do much. 2025-08-20 Pietro Monteiro Remove autoconf macro AC_HEADER_STDC Stop using AC_HEADER_STDC since it is no longer supported in autoconf 2.72+. We require a C++ compiler that supports c++17, it's probably safe to assume that the C compiler fully supports C89. Approved-By: Simon Marchi 2025-08-20 GDB Administrator Automatic date update in version.in 2025-08-20 Alan Modra Re: gas: testsuite: fix regression in cfi-common-10.d Just match what the test is actually trying to verify, to fix more regressions. 2025-08-19 Simon Marchi gdb: remove unused includes in inferior.h gdbsupport/common-inferior.h was needed by a few .c files, so move it there. Change-Id: Ia3ab8c30b529a1eda09862c8faea9e8c1c8123b5 2025-08-19 Indu Bhagat gas: testsuite: fix regression in cfi-common-10.d A previous commit 09292f4ae2c introduced the new test cfi-common-10.d. The testcase needs some adjustments for it to be useful on a variety of targets. 2025-08-19 Andrew Burgess gdb: remove some unnecessary watchpoint_addr_within_range overrides While looking at the watchpoint code, I realised that AArch64, ARM, and Loongarch all override watchpoint_addr_within_range with an implementation that is the same as the default (but with the logic written slightly differently). Compare the deleted functions to default_watchpoint_addr_within_range in target.c. The only other targets that override watchpoint_addr_within_range are ppc_linux_nat_target and remote_target, in both cases the implementation is different to the default. Lets remove these unnecessary overrides, and just use the default. There should be no user visible changes after this commit. Approved-By: Simon Marchi 2025-08-19 Nick Clifton Add tests of the linker's --errror-execstack and --error-rwx-segments options 2025-08-19 Simon Marchi gdb: rename address_class -> location_class The enum address_class and related fields and methods seem misnamed to me. Generalize it to "location_class". The enumerators in address_class are already prefixed with LOC, so the new name seems logical to me. Rename related fields and methods as well. Plus, address_class could easily be mistaken for other unrelated things named "address class" in GDB or DWARF. Tested by rebuilding. Change-Id: I0dca3738df412b350715286c608041b08e9b4d82 Approved-by: Kevin Buettner 2025-08-19 Simon Marchi gdb: rename gdbarch_software_single_step -> gdbarch_get_next_pcs I spotted this while reviewing a patch adding a new gdbarch_software_single_step implementation. I find the name "software_single_step" a bit misleading or unclear. It makes it sounds as if the function executed a single step. In reality, this function returns the possible next PCs for current instructions. We have a similar concept in GDBserver: linux_process_target::low_get_next_pcs. I like that name, it's clear and straight to the point. Rename gdbarch_software_single_step to gdbarch_get_next_pcs. I find this name more indicative of what happens. There is some code for ARM shared between GDB and GDBserver to implement both sides, also called "get next pcs", so I think it all fits well together. Tested by rebuilding. Change-Id: Ide74011a5034ba11117b7e7c865a093ef0b1dece Approved-by: Kevin Buettner Acked-by: Luis Machado 2025-08-19 Rainer Orth ld: testsuite: Mark vers26b3 unsupported on x86_64 After enabling the ld-elfvers tests on Solaris/x86, one of them FAILs on Solaris/amd64 only: FAIL: vers26b3 /ld-new: tmpdir/vers26b3.o: relocation R_X86_64_32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC ./ld-new: failed to set dynamic section sizes: bad value The error is strange: vers26b3.o *was* compiled with -fPIC and repeating the link with /bin/ld just works. However, the resulting vers26b3.so fails to load: $ ldd -r tmpdir/vers26b3.so [...] ld.so.1: vers26b3.so.ld: fatal: relocation error: R_AMD64_32: file tmpdir/vers26b3.so.ld: symbol foo: value 0x7fff34d00830 does not fit When running the test on Linux/x86_64, it fails with the same ld message as above, so the test is marked unsupported for both Linux/x86_64 and Solaris/amd64. Tested on {amd64,i386}-pc-solaris2.11 and {x86_64,i686}-pc-linux-gnu. 2025-07-31 Rainer Orth ld: * testsuite/ld-elfvers/vers.exp (vers26b3): Mark unsupported on Linux/x86_64 and Solaris/amd64. 2025-08-19 Rainer Orth Add missing ChangeLog. 2025-08-19 Rainer Orth ld: testsuite: Fix ld-elfvers tests on Solaris All ld-elfvers tests FAIL on Solaris/SPARC, always with the same failure mode: FAIL: vers1 ./ld-new: _etext: undefined version: vers1.so ./ld-new: _end: undefined version: vers1.so ./ld-new: _edata: undefined version: vers1.so ./ld-new: failed to set dynamic section sizes: bad value This is due to the use of --no-undefined-version, the error being emitted by bfd/elflink.c (bfd_elf_size_dynamic_sections). The affected symbols are mandated by the Solaris ABI in versioned shared objects and are generated by ld/emultempl/solaris2.em (elf_solaris2_before_allocation). The check in bfd_elf_size_dynamic_sections fails since for the base version (vers1.so), both symver and script are 0: vers1.so pattern = "_etext", literal = 1, symver = 0, script = 0, mask = 1 Given that those symbols are generated internally by ld, it seems sensible to set script = 1 for them. This patch does just that, at the same time enabling the tests for Solaris/x86. Not doing this before looks like an oversight: there's no difference between SPARC and x86 in this regard. This introduces one failure on Solaris/amd64 (vers26b3), which I'll address in a followup. Tested no {sparc,sparcv9}-sun-solaris2.11, {i386,amd64}-pc-solaris2.11, and {x86_64,i686}-pc-linux-gnu. 2025-07-25 Rainer Orth ld: * emultempl/solaris2.em (elf_solaris2_before_allocation): Mark global symbols as generated by linker script. * testsuite/ld-elfvers/vers.exp: Enable on *-*-solaris2* rather than sparc*-*-solaris2* only. 2025-08-19 Andrew Burgess gdb/testsuite: fix invalid assumption about TUI src window Fix a failing test introduced by this commit: commit e53b88b40ed38651b50f954dfe76066822094c15 Date: Wed Aug 13 15:29:38 2025 +0100 gdb: fix forward/reverse search, when no lines are printed The TUI test added in this commit assumed that the opening '{' of main would be the first statement line (in DWARF terms), and so, would be the initial focus of the TUI src window. This is true for some targets (e.g. x86), but not others (e.g. AArch64), and so gdb.tui/source-search.exp was seen failing on at least some AArch64 targets. Fix this by adding a 'list' command to the test, which forces the initial window contents to be as needed for the rest of the test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33290 Approved-By: Tom de Vries 2025-08-19 H.J. Lu elf: Prune empty generic properties Prune empty generic properties before discarding empty property note section and leave processor specific properties to the backend. bfd/ PR ld/33292 * elf-properties.c (elf_prune_empty_properties): New function. (_bfd_elf_link_setup_gnu_properties): Call elf_prune_empty_properties before discarding empty property note section. Move indirect_extern_access processing before elf_prune_empty_properties call. ld/ PR ld/33292 * testsuite/ld-x86-64/pr33292-x32.d: New file. * testsuite/ld-x86-64/pr33292.d: Likewise. * testsuite/ld-x86-64/pr33292.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run PR ld/33292 tests. 2025-08-19 Rainer Orth bfd: Fix Solaris/x86 ELF_MAXPAGESIZE I noticed that the alignment of the .text and .data sections on Solaris/x86 doesn't match what /bin/ld does: gld uses the original i386 psABI default of 0x1000, while Solaris has moved to larger values as can be seen both in the Oracle Solaris 11.4 Linkers and Libraries Guide, ch. 15, Program Loading and Dynamic Linking, p. 15-6 and the system headers () that have while the Solaris/SPARC values are already correct. To fix this, on i386 it's sufficient to redefine ELF_MAXPAGESIZE. On x86_64, unlike i386, ELF_COMMONPAGESIZE is hardcoded as 0x1000, the default, so setting ELF_MAXPAGESIZE has no effect on ELF_P_ALIGN. Setting ELF_COMMONPAGESIZE to ELF_MAXPAGESIZE, too, fixes that and brings both target in sync. ELF_MACHINE_CODE is just set to the original value again, so it's removed. Tested on {i386,amd64}-pc-solaris2.11, {i686,x86_64}-pc-linux-gnu, and amd64-pc-freebsd14.0. 2025-07-29 Rainer Orth bfd: * elf32-i386.c (ELF_MAXPAGESIZE): Redefine. (ELF_MAXPAGESIZE): Restore previous value. * elf64-x86-64.c (ELF_COMMONPAGESIZE): Define as ELF_MAXPAGESIZE. (ELF_MAXPAGESIZE): Redefine (ELF_MAXPAGESIZE): Restore previous value. (ELF_MACHINE_CODE): Remove. 2025-08-19 Indu Bhagat binutils: dwarf: fix display of large cfa_offset eh_frame textual dump was not correct when the cfa_offset is a large value. The reason is that the dumping code generally assumes the cfa_offset is an 'int'. cfa_offset values can be updated by various DWARF opcodes, like: - DW_CFA_def_cfa, DW_CFA_def_cfa_offset which bring unsigned leb128 cfa_offset - DW_CFA_def_cfa_sf, DW_CFA_def_cfa_offset_sf which bring signed leb128 cfa_offset Internally, the routines in dwarf.c keep the value as 'uint64_t cfa_offset'. That size of the datatype is expected to work for most of the real-world cases. Care, however, needs to be taken when it comes to the signedness of the value. Fix the buggy behavior by adding an additional field to track whether the value of cfa_offset is signed or unsigned and display accordingly for "frames-interp" output. The display of cfa_offset had issues in both "frames-interp" output (objdump -WF or do_debug_frames_interp) and the "frames" output. Add two new tests: cfi-common-10.s uses a large positive cfa_offset (with "frames output), and cfi-x86_64-2.s uses a negative cfa_offset (with "frames-interp" output). ChangeLog: * binutils/dwarf.c (frame_display_row): Update format string based on signedness. (display_debug_frames): Track signedness. Also fix display of cfa_offset using PRIu64 or PRId64 as applicable. * gas/testsuite/gas/cfi/cfi.exp: Add two new tests. * gas/testsuite/gas/cfi/cfi-common-10.d: New test. * gas/testsuite/gas/cfi/cfi-common-10.s: New test. * gas/testsuite/gas/cfi/cfi-x86_64-2.d: New test. * gas/testsuite/gas/cfi/cfi-x86_64-2.s: New test. 2025-08-19 H.J. Lu Limit BFD_SUPPORTS_PLUGINS check to plugin.h and targets.c Minimize the BFD_SUPPORTS_PLUGINS check to make code more readable and maintainable by: 1. Update bfd/plugin.h to define plugin functions as static inline if BFD_SUPPORTS_PLUGINS is 0. 2. Remove BFD_SUPPORTS_PLUGINS check from all bfd and binutils files except plugin.h and targets.c. 3. Replace the remaining BFD_SUPPORTS_PLUGINS checks with a function so that plugin availability is checked at run time. bfd/ * archive.c: Include plugin.h unconditionally. (_bfd_compute_and_write_armap): Remove the BFD_SUPPORTS_PLUGINS check. * bfd-in.h (bfd_plugin_enabled): New. * bfd-in2.h: Regenerated. * elflink.c: Include plugin.h unconditionally. (elf_link_is_defined_archive_symbol): Remove the BFD_SUPPORTS_PLUGINS check. * format.c: Include plugin.h unconditionally. (bfd_set_lto_type): Remove the BFD_SUPPORTS_PLUGINS check. (bfd_check_format_matches): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. Replace plugin_vec with bfd_plugin_vec. Remove the BFD_SUPPORTS_PLUGINS check. * plugin.c (bfd_plugin_target_p): Removed. * plugin.h (bfd_plugin_vec): New. (bfd_plugin_target_p): Likewise. (bfd_plugin_set_program_name): New. Static inline function if BFD_SUPPORTS_PLUGINS is 0. (bfd_plugin_open_input): Likewise. (bfd_plugin_set_plugin): Likewise. (bfd_link_plugin_object_p): Likewise. (register_ld_plugin_object_p): Likewise. (bfd_plugin_close_file_descriptor): Likewise. (bfd_plugin_vec): Likewise. (bfd_plugin_target_p): Likewise. * xtensa-dynconfig.c (xtensa_load_config): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. ar/ * ar.c: Include plugin.h unconditionally. (plugin_target): Removed. (usage): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. (ranlib_usage): Likewise. (decode_options): Likewise. (ranlib_main): Likewise. (main): Call bfd_plugin_set_program_name unconditionally. * nm.c: Include plugin.h unconditionally. (plugin_target): Removed. (usage): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. (filter_symbols): Remove the BFD_SUPPORTS_PLUGINS check. (display_rel_file): Likewise. (main): Call bfd_plugin_set_program_name unconditionally. Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. * objcopy.c: Include plugin.h unconditionally. (strip_usage): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. (copy_archive): Remove the BFD_SUPPORTS_PLUGINS check. Replace BFD_SUPPORTS_PLUGINS with the bfd_plugin_enabled call. (copy_file): Likewise. (strip_main): Likewise. ld/ * ldfile.c: Include plugin.h unconditionally. (ldfile_try_open_bfd): Remove the BFD_SUPPORTS_PLUGINS check. * ldlang.c: Include plugin.h unconditionally. (plugin_insert): Remove the BFD_SUPPORTS_PLUGINS check. (plugin_undefs): Likewise. (open_input_bfds): Likewise. (lang_check): Likewise. (lang_gc_sections): Likewise. (find_next_input_statement): Likewise. (lang_process): Likewise. * ldlang.h (lang_input_statement_flags): Likewise. * ldlex.h (option_values): Likewise. * ldmain.c: Include plugin.h unconditionally. (ld_cleanup): Remove the BFD_SUPPORTS_PLUGINS check. (main): Likewise. (add_archive_element): Likewise. * lexsup.c: Include plugin.h unconditionally. (ld_options): Remove the BFD_SUPPORTS_PLUGINS check. (parse_args): Replace the BFD_SUPPORTS_PLUGINS check with the bfd_plugin_enabled call. Remove the BFD_SUPPORTS_PLUGINS check. (help): Append " (ignored)" to plugin options if bfd_plugin_enabled return false. * libdep_plugin.c: Remove the BFD_SUPPORTS_PLUGINS check. * plugin.c: Likewise. * testplug.c: Likewise. * testplug2.c: Likewise. * testplug3.c: Likewise. * testplug4.c: Likewise. Co-Authored-By: Alan Modra 2025-08-19 Alan Modra Re: windres: don't exit so much on errors in read_coff_rsrc oss-fuzz found that I missed some error paths in commit 9e68cae4fd. This fix prevents reads of a NULL pointer in sort_resources. * rescoff.c (read_coff_res_dir): Check return of recursive calls and read_coff_data_entry calls. Pass failures up the call chain. 2025-08-19 GDB Administrator Automatic date update in version.in 2025-08-18 H.J. Lu ld: Properly override compiler flags in tests Some tests need to be compiled with additional flags. When binutils is built and compiled with CC="gcc -fsanitize=address,undefined" CXX="g++ -fsanitize=address,undefined" some linker tests fail to disable address sanitizer options since proc default_ld_compile has set ccexe $cc set ccparm [string first " " $cc] set ccflags "" if { $ccparm > 0 } then { set ccflags [string range $cc $ccparm end] set ccexe [string range $cc 0 $ccparm] set cc $ccexe } ... set cmd "$cc $flags $ccflags -c $source -o $object" Compiler flags in $CC and $CXX will be the last ones. Add CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST to use them in proc default_ld_compile set cflag_test "" set cxxflag_test "" if {[string match "*++*" $ccexe]} { append flags " $CXXFLAGS_FOR_TARGET" set cflag_test "$CXXFLAGS_FOR_TARGET_TEST" } else { append flags " $CFLAGS_FOR_TARGET" set cflag_test "$CFLAGS_FOR_TARGET_TEST" } ... set cmd "$cc $flags $ccflags $cflag_test -c $source -o $object" so that they will be the last flags passed to compiler. Also update run_ld_link_exec_tests and run_cc_link_tests to make CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST the last flags passed to compiler. * testsuite/config/default.exp (CFLAGS_FOR_TARGET_TEST): New. (CXXFLAGS_FOR_TARGET_TEST): Likewise. * testsuite/ld-elf/dwarf.exp (CFLAGS_FOR_TARGET): Renamed to ... (CFLAGS_FOR_TARGET_TEST): This. * testsuite/ld-elf/shared.exp: Save, append and restore CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST for $build_tests. Save, append and restore CFLAGS_FOR_TARGET_TEST, instead of CFLAGS_FOR_TARGET, for $dlopen_run_tests. * testsuite/ld-plugin/plugin.exp (CFLAGS_FOR_TARGET): Renamed to ... (CFLAGS_FOR_TARGET_TEST): This. * testsuite/ld-shared/shared.exp (CFLAGS_FOR_TARGET): Renamed to ... (CFLAGS_FOR_TARGET_TEST): This. * testsuite/ld-srec/srec.exp (CFLAGS_FOR_TARGET): Renamed to ... (CFLAGS_FOR_TARGET_TEST): This. (CXXFLAGS_FOR_TARGET): Renamed to ... (CXXFLAGS_FOR_TARGET_TEST): This. * testsuite/lib/ld-lib.exp (default_ld_compile): Append CFLAGS_FOR_TARGET_TEST/CXXFLAGS_FOR_TARGET_TEST to compiler flags. (run_ld_link_exec_tests): Append CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST to compiler. (run_cc_link_tests): Likewise. 2025-08-18 Nick Clifton Fix compile time warning when building with Clang. PR 33282 2025-08-18 Tom de Vries [gdb/testsuite] Fix gdb.tui/tui-mode-switch.exp on aarch64 On aarch64-linux, occasionally I run into these warnings: ... PASS: gdb.tui/tui-mode-switch.exp: set style enabled off WARNING: timeout in accept_gdb_output PASS: gdb.tui/tui-mode-switch.exp: no boo WARNING: timeout in accept_gdb_output ... The first in more detail: ... Box Dump (40 x 1) @ (0, 11): 11 b(gdb) b WARNING: timeout in accept_gdb_output ... Fix this by waiting for a prompt after leaving TUI before sending "b". Also, while we're at it generate a few more passes. Tested on aarch64-linux. 2025-08-18 H.J. Lu ld: Set the is_linker_input field Set the is_linker_input field when adding object only section. * ldlang.c (cmdline_add_object_only_section): Set the is_linker_input field. 2025-08-18 Rainer Orth ld: testsuite: Fix no-plt tests on Solaris/i386 Several no-plt tests FAIL on 32-bit Solaris/x86: FAIL: Build libno-plt-1b.so FAIL: No PLT (dynamic 1a) FAIL: No PLT (dynamic 1b) FAIL: No PLT (dynamic 1c) FAIL: No PLT (PIE 1e) FAIL: No PLT (PIE 1f) FAIL: No PLT (PIE 1g) The failure mode is always similar, e.g. ../binutils/objdump -dwrj.text tmpdir/libno-plt-1b.so > dump.out regexp_diff match failure regexp "^ +[a-f0-9]+: 8b 80 ([0-9a-f]{2} ){4}[ ]+mov +-0x[a-f0-9]+\(%eax\),%eax$" line " 4aa: 8b 80 14 00 00 00 mov 0x14(%eax),%eax" regexp_diff match failure regexp "^ +[a-f0-9]+: ff a0 ([0-9a-f]{2} ){4}[ ]+jmp +\*-0x[0-9a-f]+\(%eax\)$" line " 4ca: ff a0 14 00 00 00 jmp *0x14(%eax)" i.e. there's a positive offset from the GOT instead of the expected negative one. AFAICS that's because there are additional GOT entries on the Solaris side (printed with elfdump -G since there seems to be no support for that in either readelf or objdump): * Solaris/i386: Global Offset Table Section: .got index addr value pending relocation [0] 0x15f4 0x1514 [1] 0x15f8 0 [2] 0x15fc 0 [3] 0x1600 0x3a6 R_386_JMP_SLOT __cxa_finalize [4] 0x1604 0 R_386_GLOB_DAT _ITM_deregisterTMCloneTable [5] 0x1608 0 R_386_GLOB_DAT func * Linux/i686: Global Offset Table Section: .got index addr value pending relocation [0] 0x3fe0 0 R_386_GLOB_DAT _ITM_deregisterTMCloneTable [1] 0x3fe4 0 R_386_GLOB_DAT __cxa_finalize [2] 0x3fe8 0 R_386_GLOB_DAT __gmon_start__ [3] 0x3fec 0 R_386_GLOB_DAT func This patch fixes this by making the sign optional in affected cases. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. 2025-07-25 Rainer Orth ld: * testsuite/ld-i386/libno-plt-1b.dd: Allow for positive GOT offsets. * testsuite/ld-i386/no-plt-1a.dd: Likewise. * testsuite/ld-i386/no-plt-1b.dd: Likewise. * testsuite/ld-i386/no-plt-1c.dd: Likewise. * testsuite/ld-i386/no-plt-1e.dd: Likewise. * testsuite/ld-i386/no-plt-1f.dd: Likewise. * testsuite/ld-i386/no-plt-1g.dd: Likewise. 2025-08-18 Alice Carlotti gas: Record file name in macro locations This allows the correct file name to be used when emitting messages for lines within a macro. The line numbers were already set and displayed correctly, which resulted in mismatched file names and line numbers. PR 32738 2025-08-18 Alice Carlotti gas: Improve file name in messages header Message output from gas is prefixed with a line of the form: path/file.s: Assembler messages: Don't use the file name from the first message for this header. Instead, use the source file name specified in the command line. 2025-08-18 Alan Modra Don't choose plugin target in binutils/ Instead make bfd_check_format try the plugin target first when the user hasn't supplied a target. bfd/ * format.c (bfd_check_format_matches): Try for a plugin target match first. * targets.c (bfd_find_target): Don't specially treat "plugin". binutils/ * ar.c (plugin_target): Delete. (open_inarch): Don't set target of archive elements. (replace_members): Use target rather than plugin_target when opening replacement or additional files. * arsup.c (plugin_target): Delete. Replace all uses with NULL. (ar_open): Don't set element target. * bucomm.h (set_plugin_target): Delete. * nm.c (plugin_target): Delete. (display_archive): Don't set element target. (display_file): Alway use target when opening file. * objcopy.c (copy_archive): Don't use plugin target for output elements. * NEWS: Mention stricter target checking. 2025-08-18 Nick Clifton Fix typo in recent update to elf.c's core note handling code. PR 33282 2025-08-18 H.J. Lu ld: Issue an error if group nested too deeply If a linker script has a group nested too deeply by mistake, issue an error instead of hanging forever without outputting any error message. PR ld/33265 * ldlang.c (MAX_NESTED_GROUP_DEPTH): New. (open_input_bfds): Add a pointer argument for the nested group count. Increment the count before the while loop and decrement it after the loop. Issue an error if the nested group count >= MAX_NESTED_GROUP_DEPTH when processing input statement. (lang_process): Update open_input_bfds calls. (cmdline_emit_object_only_section): Likewise. * testsuite/ld-scripts/libpr33265-1.a: New file. * testsuite/ld-scripts/libpr33265-2.a: Likewise. * testsuite/ld-scripts/libpr33265-3a.a: Likewise. * testsuite/ld-scripts/libpr33265-3b.a: Likewise. * testsuite/ld-scripts/libpr33265-3c.a: Likewise. * testsuite/ld-scripts/pr33265-1.d: Likewise. * testsuite/ld-scripts/pr33265-2.d: Likewise. * testsuite/ld-scripts/pr33265-3.d: Likewise. * testsuite/ld-scripts/script.exp: Run PR ld/33265 tests. 2025-08-18 GDB Administrator Automatic date update in version.in 2025-08-17 Indu Bhagat libsframe: testsuite: use SFrame V2 specific APIs Use sframe_encoder_add_funcdesc_v2 instead of sframe_encoder_add_funcdesc. Similarly, use sframe_decoder_get_funcdesc_v2 instead of sframe_decoder_get_funcdesc. sframe_encoder_add_funcdesc, and sframe_decoder_get_funcdesc were first added for SFrame V1. For the purpose of these testcases, the two V2 APIs are (almost) functionally equivalent. In future, we may want to make sframe_encoder_add_funcdesc and sframe_decoder_get_funcdesc internal to libsframe only. Using the V2 named APIs is better for clarity as well. libsframe/testsuite/ * libsframe.encode/encode-1.c: Use V2 named APIs instead. * libsframe.find/findfre-1.c: Likewise. * libsframe.find/findfunc-1.c: Likewise. * libsframe.decode/be-flipping.c: Likewise. * libsframe.decode/frecnt-1.c: Likewise. * libsframe.decode/frecnt-2.c: Likewise. 2025-08-17 Indu Bhagat libsframe: testsuite: reduce usage of magic numbers from encode-1.c Previously, some of the libsframe tests were updated to reduce the usage of magic numbers. This patch makes encode-1.c follow similar coding style as other tests, reducing the number of magic constants. libsframe/testsuite/ * libsframe.encode/encode-1.c: Avoid magic numbers. 2025-08-17 Alan Modra Sanity check windows resource version len oss-fuzz generated a total length field of 32, when the header was 40 bytes. Subtracting gave -8ul for the remaining length.. I think we should be sanity checking the total length given in the header against the remaining buffer length and the size of the header each time get_version_header is called. Possibly vallen should be sanity checked inside get_version_header too, but I'll leave that to someone else. PR 27686 * resbin.c (bin_to_res_version): Correct error message arg. Move len vs. buffer length sanity check.. (get_version_header): ..to here. Also sanity check len against off. 2025-08-17 Rainer Orth ld: testsuite: Fix several CTF tests on 32-bit SPARC Several ld CTF tests FAIL on 32-bit SPARC, e.g. FAIL: Arrays (conflicted) The failure mode is always the same: ./tmpdir/array-char-conflicting-1.s: Assembler messages: ./tmpdir/array-char-conflicting-1.s:89: Error: Architecture mismatch on "return %i7+8". ./tmpdir/array-char-conflicting-1.s:89: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.) The problem is that gcc emits v8plus code by default, and thus invokes as with -xarch=v8plus (equivalent to -Av8plus), while the testcase lacks the latter. Fixed by setting ASFLAGS to match. Tested on sparc-sun-solaris2.11, sparc-unknown-linux-gnu, sparcv9-sun-solaris2.11, and sparc64-unknown-linux-gnu. 2025-07-25 Rainer Orth ld: * testsuite/ld-ctf/ctf.exp (ASFLAGS): Append -Av8plus on sparc-*-*. 2025-08-17 Tom de Vries [gdb/testsuite] Use regexp to match $_gdb_{major,minor} Every time we update the gdb version number, test-case gdb.base/default.exp needs updating because it matches the values of convenience variables $_gdb_{major,minor} using hardcoded expected values: ... {$_gdb_major = 17} \ {$_gdb_minor = 1} \ ... I'm assuming the values were hardcoded because gdb_test_list_exact was used. Since the previous patch, that's not longer the case, so use regexps instead, getting rid of this annoyance [1]. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2019-October/160935.html 2025-08-17 Alan Modra buffer overflow in process_sht_group_entries An oss-fuzz testcase with a SHT_GROUP section named .debug managed to break objcopy --compress-debug-sections. The underlying problem is that SEC_DEBUGGING is set by section name tests, thus the SHT_GROUP section gets compressed. The compressed section data is smaller than the original section sh_size, and process_sht_group_entries tries to look at sh_size worth of entries. The patch fixes this mess by simply not setting SEC_DEBUGGING on SHT_GROUP sections. Note that it isn't correct to restrict SEC_DEBUGGING to SHT_PROGBITS sections, as that will break processor/os special sections for debug. eg. SHT_MIPS_DEBUG. * elf.c (_bfd_elf_make_section_from_shdr): Don't set SEC_DEBUGGING on SEC_GROUP sections no matter their name. 2025-08-17 Tom de Vries [gdb/testsuite] Handle remote host in some test-cases I ran test-case gdb.base/default.exp with make-check-all.sh, and noticed a FAIL with host/target board local-remote-host-native: ... FAIL: $exp: show convenience ($_colorsupport = "monochrome" not found) ... The problem is that part of the test-case relies on "setenv TERM dumb", and setenv, which is a tcl command (which runs on build), only has effect in gdb (which runs on host), if build == host, in other words, local host. I grepped for test-cases using setenv, and ran them with the host/target board, and fixed the FAILs I saw. All FAILs have the same cause as I described above, except for proc test_data_directory in gdb.python/py-parameter.exp, which handles files assuming local host. I chose to leave it that way, and bail out but add a comment. Implementationwise, the change to test-case gdb.base/default.exp is the most intrusive: it replaces a use of proc gdb_test_list_exact with a use of proc gdb_get_lines_no_pass, because it allows specifying a regexp match. In the process, I found out gdb_test_list_exact has a bug, filed as PR33038. Because of this bug, I had to add matching of convenience variable $_tbl. Tested on x86_64-linux. 2025-08-17 GDB Administrator Automatic date update in version.in 2025-08-16 Tom de Vries [gdb/testsuite] Fix TUI tests on freebsd While re-testing the TUI tests on x86_64-freebsd, I found that commit 06a53717f7c ("[gdb/testsuite] Handle unrecognized escape sequences better in tuiterm") broke most test-cases. Fix this by rewriting this gdb_test_multiple clause: ... -re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" { ... into: ... -re "^($re_csi_cmd)" { ... -re "^($re_csi_args*)($re_csi_cmd)" { ... -re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" { ... Tested on x86_64-linux and x86_64-freebsd. 2025-08-16 Tom de Vries [gdb/testsuite] Handle unrecognized escape sequences better in tuiterm When encountering an unrecognized escape sequence in Term::accept_gdb_output, a warning is issued: ... WARNING: timeout in accept_gdb_output ... and 0 is returned. Subsequent calls run into the same problem, so matching doesn't progress. Consequently, figuring out what the unrecognized escape sequence actually is depends on analyzing gdb's output as echoed into gdb.log. In the test added in this commit, gdb (well, a script gdb.tcl emulating gdb) outputs escape sequence "ESC ( B", which doesn't show up in recognizable form in gdb.log: ... foo^M^M ... and as mentioned the tuiterm screen only show: ... foo ... because matching doesn't progress beyond the unrecognized sequence. Fix this by rewriting accept_gdb_output to match gdb output using a phased approach that echoes unmatched escape sequences, giving us instead on the tuiterm screen: ... foo^[(B ... [ Since "ESC ( B" is now supported, the test-case has been updated to use "ESC ( % 5" instead. ] Tested on x86_64-linux. PR testsuite/33218 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33218 2025-08-16 Tom de Vries [gdb/testsuite] Move setting of Term::_last_char to Term::_insert The variable Term::_last_char is meant to represent the last char inserted by Term::_insert, but setting it is done alongside the only call to _insert in lib/tuiterm.exp: ... _insert $expect_out(0,string) variable _last_char set _last_char [string index $expect_out(0,string) end] ... Fix this by moving the setting of _last_char to inside _insert. Tested on x86_64-linux. 2025-08-16 Alan Modra Make bfd_check_format better respect given target bfd_check_format currently does not take much notice of the target set in its abfd arg, merely checking that target first if target_defaulted is false. As the comment says this was due to complications with archive handling which I think was fixed in commit f832531609d0. It should now be possible to just check the given target, except for linker input files. This will speed checking the target of the first file in archives, which is done in the process of matching archive targets. This will no doubt expose some misuse of target options, as found in the binutils "efi app" tests. The stricter checking also exposed some errors. Cris targets gave "FAIL: objcopy decompress debug sections in archive (reason: unexpected output)" "FAIL: objcopy decompress debug sections in archive with zlib-gabi (reason: unexpected output)" without the bfd_generic_archive_p fix. cris has a default target of cris-aout which doesn't match objects for any of the cris-elf or cris-linux targets. The problem here was that checking the first object file in archives didn't match but a logic error there meant bfd_error_wrong_object_format wasn't returned as it should be. There was also a possibility of bfd_error_wrong_object_format persisting from one target check to the next. bfd/ * archive.c (bfd_generic_archive_p): Correct object in archive target test. * format.c (bfd_check_format_matches_lto): Try to match given target first even when target_defaulted is set. Don't try other targets if !target_defaulted except for linker input. Clear bfd_error before attempted target matches. * targets.c (bfd_find_target): Set target_defaulted for plugin target. binutils/ * bucomm.h (set_plugin_target): Set target_defaulted. * testsuite/binutils-all/aarch64/pei-aarch64-little.d: Don't wrongly specify both input and output target, just specify output. * testsuite/binutils-all/loongarch64/pei-loongarch64.d: Likewise. * testsuite/binutils-all/riscv/pei-riscv64.d: Likewise. 2025-08-16 GDB Administrator Automatic date update in version.in 2025-08-15 Alan Modra archives and plugin target Automatically choosing "plugin" for the archive target when plugins are enabled can result in making archives as specified by the plugin target vec, ie. COFF style archives (also used by most ELF binutils targets). This is wrong for aix, hpux, vms, aout, macho and possibly other targets, if compatibility with target system archives matters. This patch removes archive support entirely from the plugin target. That means an archive will never get past bfd_check_format with a target of plugin_vec, even if it is opened using "plugin". Instead, archives will have their elements opened using the plugin target selected is such a way that the plugin target will be tried first in bfd_check_format and then continue to try other targets if that fails. The patch tries to avoid opening archives using "plugin" because that is guaranteed to fail the first target check in bfd_check_format, but mm.c still does so, and nested archives will also be opened using "plugin". The patch also fixes poor arsup.c plugin support. bfd/ * plugin.c (plugin_vec): Remove archive support. * configure.ac: Remove plugin archive warning, and don't disable plugins by default on anything but aout targets. * configure: Regenerate. binutils/ * bucomm.h (set_plugin_target): New inline function. * ar.c: Remove unneeded forward declarations. (open_inarch): Don't use "plugin" if defaulting target when opening an archive, use "plugin" when opening elements. (replace_members): Use "plugin" when opening replacement or additional elements. * arsup.c: Remove unneeded forward declarations. (plugin_target): New. (ar_open): Don't open archives using "plugin", use it when opening elements. (ar_addmod): Use plugin_target. (ar_replace): Use plugin_target when opening replacement or additional elements. (ar_extract): Don't bfd_openr. * nm.c (display_archive): Open archive elements using the "plugin" target. 2025-08-15 H.J. Lu objcopy.c: Re-indent slim LTO IR comment Re-indent slim LTO IR comment in commit 9b383903e73cd01f2fbe9728d0c31fea765ba8d6 Author: H.J. Lu Date: Tue Aug 12 12:02:08 2025 -0700 strip: Treat slim GCC/LLVM IR objects the same PR binutils/33271 * objcopy.c (copy_file): Re-indent slim LTO IR comment. 2025-08-15 Indu Bhagat gas: sframe: const ptrs for args and local vars where applicable Use const pointers for function arguments and local vars where applicable. 'cfi_insn' contains the DWARF CFI instruction data which, for the purpose of SFrame generation, is read-only. Similarly, some getter APIs and output related APIs now document their argument as read-only. While at it, also remove the ATTRIBUTE_UNUSED from argument xlate_ctx in sframe_xlate_do_register () because the argument is indeed conditionally used. 2025-08-15 Nick Clifton Code tidy: bfd/elf.c: T|idy up core note handling code. 2025-08-15 Tom de Vries [gdb/testsuite] Add gdb.tui/tui-mode-switch.exp Add test-case gdb.tui/tui-mode-switch.exp, a regression test for PR tui/30523. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30523 2025-08-15 Tom de Vries [gdb/testsuite] Add Term::with_term Add Term::with_term that allows us to override the default TERM used in tuiterm: ... Term::with_term xterm { Term::clean_restart 12 40 } ... [gdb/testsuite] Add Term::_esc_0x3d and Term::_esc_0x3e Add support for: - DECKPAM (Application Keypad) ESC = - DECKPNM (Normal Keypad) ESC > [gdb/testsuite] Add Term::_esc_0x28_B and Term::_esc_0x28_0 Add support for: - Designate G0 Character Set, USASCII ESC ( B - Designate G0 Character Set, DEC Special Character and Line Drawing Set ESC ( 0 [gdb/testsuite] Add Term::_csi_r Add support for: - Set Scrolling Region (DECSTBM) CSI r [gdb/testsuite] Add Term::_csi_t Add support for: - Window manipulation (XTWINOPS) CSI t [gdb/testsuite] Add Term::_csi_0x3f_l and Term::_csi_0x3f_h Add support for: - DECSET CSI ? h - DECRST CSI ? l [gdb/testsuite] Add Term::_csi_h and Term::_csi_l Add support for: - Set Mode (SM) CSI h - Reset Mode (RM) CSI l 2025-08-15 Tom de Vries [gdb/tui] Clear readline buffer on switching to TUI Consider the following scenario. We start gdb and type foo: ... $ gdb -q (gdb) foo ^ ... Then we switch to TUI using C-x C-a, and switch back using the same key combination. We get back the same, but with the cursor after the prompt: ... (gdb) foo ^ ... Typing b gives us: ... (gdb) boo ❌️ No default breakpoint address now. (gdb) ... which means gdb didn't see "boo" here, just "b". So while "foo" is part of the readline buffer when leaving CLI, it's not upon returning to CLI, but it is still on screen, which is confusing. Fix this by using rl_clear_visible_line in tui_rl_switch_mode to clear the readline buffer when leaving CLI. This only reproduces for me with TERM=xterm. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30523 2025-08-15 Andrew Burgess gdb: fix forward/reverse search, when no lines are printed This commit continues the theme of the previous commit, restoring the behaviour of forward-search and reverse-search to what it was before GDB 10, but adds tests to guard the behaviour. I believe this restored behaviour is inline with the documentation of the two search commands. This time, I'm looking at what happens when no source lines end up being printed. This can happen for two reasons, a request is made to list a line number outside the file, or, a request is made to list a reverse series of lines (e.g. line 100 to line 50). Before GDB 10, a 'list' command that resulted in no lines being printed would not change the notion of the last line listed. As a result a future forward or reverse search would continue from the previous last line. As an example, here's current master branch behaviour: (gdb) list 50 45 /* Line 45 */ 46 /* Line 46 */ 47 /* Line 47 */ 48 /* Line 48 */ 49 /* Line 49 */ 50 /* Line 50 */ 51 /* Line 51 */ 52 /* Line 52 */ 53 /* Line 53 */ 54 /* Line 54 */ (gdb) list 1000 Line number 995 out of range; long-file.c has 101 lines. (gdb) forward-search Line Expression not found (gdb) But on GDB 9, the forward-search instead acts like this: (gdb) forward-search Line 55 /* Line 55 */ (gdb) Similarly, reverse-search reports "Expression not found" on master, but would return line 53 on GDB 9. The reverse-search result for master might be a little surprising, surely, if we tried to list line 1000, then every line before that should be searched. The problem is that last_line_listed ends up being set to 995 (which is 1000 minus half the listsize). Then, when the reverse-search kicks in GDB tried to read line 994, fails, and abandons the search. This problem was introduced with commit: commit 8b7fcda2744145f2380af01c9db8e11986f7af6d Date: Sun Dec 22 14:58:22 2019 +0100 Fix search in TUI This commit wants last_line_listed updated so that the search functions would work correctly (see notes below) when GDB is in TUI mode. Without this commit last_line_listed would never be updated in TUI mode, and so every search would effectively start from the beginning of the file. The fix I propose is to delay updating the current_source_location until the source code has been printed successfully. That is, just before we leave print_source_lines_base, after a successful print. This update happens inside the 'if (noprint)' block, a the return here isn't really considered an error condition, this is a specific choice _not_ to print the source code. However, in the 'if (stopline <= line)' block, the current_source_location is not updated, that's because this 'if' represents an error condition. The last_line_listed is also updated at the end of the function still, which is the path taken in CLI mode when source lines are actually printed. I've added some CLI tests to confirm the forward/reverse search behaviour. And I've also added some TUI tests to check search works within the TUI. The TUI tests cover more than just the fix for this issue. There is one slight issue with the TUI. At this point you should definitively go read the previous commit. OK, so, the forward and reverse searches are supposed to search from the last line listed. The previous commit fixed this for CLI mode, but for the TUI the last_line_listed is _still_ being set to the first line displayed. The problem is that print_source_lines_base doesn't know the size of the TUI src window, and so, doesn't know what the last line listed will be, and so cannot set last_line_listed correctly. This indicates to me that setting last_line_listed from the core GDB code is likely the wrong approach, or, at least, the way it is done now is the wrong approach. Currently the 'list' command converts the arguments into a set of lines to be printed based on the CLI environment, e.g. using the 'listsize' if necessary. But the 'listsize' doesn't make sense for the TUI, where the src window height really overrides the 'listsize'. The list command then calls the core GDB print_source_lines function to do the printing, but for the TUI we don't actually print anything, we just update the internal state (including last_line_listed) and are done. I think that the current interpreter, CLI or TUI, needs to get involved in the 'list' command implementation much sooner. This would allow, for example, the CLI to use 'listsize' and the TUI to use the src window height. It might then be up to the interpreter to track the last line listed maybe? I mention all this only to acknowledge this issue. The problem existed before this commit, and continues to exist after this commit. I'm not proposing to fix this problem right now. The TUI forward/reverse search continue to work as well as they have since commit 8b7fcda2744. Approved-By: Tom Tromey 2025-08-15 Andrew Burgess gdb: fix forward and reverse search commands to match documentation The forward-search and reverse-search commands were broken by this commit: commit a75cd9a2c129dfc086cbe570ef9cff9b84570bbd Date: Thu Nov 14 16:11:15 2019 -0700 Add observable to watch current source symtab while builds on the work in this commit: commit 1dd588507782591478882a891f64945af9e2b86c Date: Thu Aug 1 09:34:40 2019 -0600 Make current_source_* per-program-space both of these commits went into GDB 10. The documentation for these commands is pretty clear: 'forward-search REGEXP' 'search REGEXP' The command 'forward-search REGEXP' checks each line, starting with the one following the last line listed, for a match for REGEXP. It lists the line that is found. You can use the synonym 'search REGEXP' or abbreviate the command name as 'fo'. 'reverse-search REGEXP' The command 'reverse-search REGEXP' checks each line, starting with the one before the last line listed and going backward, for a match for REGEXP. It lists the line that is found. You can abbreviate this command as 'rev'. Both searches should start searching based on the last line listed. But currently: (gdb) list 3 1 int 2 main (void) 3 { 4 /* Line 4 */ 5 /* Line 5 */ 6 /* Line 6 */ 7 /* Line 7 */ 8 /* Line 8 */ 9 /* Line 9 */ 10 /* Line 10 */ (gdb) forward-search Line 4 /* Line 4 */ (gdb) This should have found line 11. And for reverse-search: (gdb) list 3 1 int 2 main (void) 3 { 4 /* Line 4 */ 5 /* Line 5 */ 6 /* Line 6 */ 7 /* Line 7 */ 8 /* Line 8 */ 9 /* Line 9 */ 10 /* Line 10 */ (gdb) reverse-search Line Expression not found (gdb) The reverse-search should have returned line 9. This new behaviour started with the above commits in GDB 10. On GDB 9 we see behaviour that matches the documentation. Where the forward and reverse searches start from is controlled by a global, last_line_listed, found in source.c. Before commit 1dd588507782, in print_source_lines_base, the last_line_listed variable was updated as each source line was printed, and it was updated with the current line being printed. After commit 1dd588507782, the current symtab and line are moved into a current_source_location object, but the symtab and line member variables are public. The last_line_listed is still set based on the value held in the current_source_location object, and this object is updated each time around the source printing loop. So despite the restructure, the logic, and behaviour, is unchanged. After commit a75cd9a2c129, the member variables of current_source_location are now private. The source printing loop in print_source_lines_base uses a local variable, new_lineno, to track the current source line number, and updates the current_source_location at the end of print_source_lines_base. However, last_line_listed is still updated inside the loop, using the original line value within current_source_location, which is no longer being updated each time around the loop. As a result, last_line_listed is now just the first line listed! This didn't show up in testing because, as far as I can tell, the last_line_listed is _only_ used for forward and reverse searching, and the testing for these commands is minimal. In this commit I move the setting of last_line_listed outside of the source printing loop, this only needs to be updated once, when we have finished printing the source lines. I've also done a couple of other cleanups in the same area, I moved 'buf' a local variable into the most inner scope where it is required, and I converted the 'while' loop into a 'for' loop, moving the increment out of the loop body. There's now a test which does some more detailed checks of the forward and reverse search commands. Approved-By: Tom Tromey 2025-08-15 Jan Beulich bfd/TIC4x: correct COFF swapping functions for mixed-endianness binaries Commit 3fa785190a4f ("Altered the CREATE_xxx_COFF_TARGET_VEC macro arguments") pretty clearly screwed up the data swapping functions in the new CREATE_BIGHDR_COFF_TARGET_VEC() macro. Since the flaw went unnoticed, and since the correction doesn't cause any testsuite fallout, it further seems pretty clear that all of this is entirely untested and largely unused. x86/APX: drop AMX-TRANSPOSE promoted insns They were dropped from spec version 007. 2025-08-15 Jan Beulich bfd/ELF/PPC: make ppc_build_one_stub()'s stub_str[] static There's no reason to have the compiler materialize objects onto the stack. In fact we can save some space and a level of indirection (and hence relocation entries in the final binary) by converting to an array of char[12] or larger. Pick char[16] for easier / faster calculations. 2025-08-15 Jan Beulich gas/ELF: allow specifying entity size for arbitrary sections The spec doesn't tie entity size to just SHF_MERGE and SHF_STRINGS sections. Introduce a new "section letter" 'E' to allow recording (and checking) of entity size even without 'M' or 'S'. gas/ELF: adjust bad section letter diagnostic Being told of a problem with .section when .pushsection was used can be irritating, especially when several of them are on the same line. 2025-08-15 Jan Beulich gas/ELF: re-work SHF_GNU_* handling Indicate to obj_elf_parse_section_letters() whether to recognize GNU- specific flags by conditionally passing NULL in place of a pointer to the GNU attributes. This way wrong use of d and R can be diagnosed just like any other use of unrecognized letters. Furthermore adjust the md_elf_section_letter() interface: Have targets merely return the extra letters they support. There's no point having them customize the entire diagnostic. Even more so that additions in common code would then reflecting in every target's diagnostic as well, which - as can be seen - wasn't always properly done. There's also no reason for wrong letters to be a fatal error; switch to as_bad() while making other adjustments there. While making the target specific adjustments, also drop IA-64's dead handling of 'o' (SHF_LINK_ORDER), which has been covered by common code for a long time. Also re-arrange the switch() in obj_elf_parse_section_letters() to be alphabetically sorted again. 2025-08-15 Jan Beulich gas/ELF: drop bogus check for ELFOSABI_STANDALONE obj_elf_parse_section_letters() checking for that ABI, when the checking at the bottom of obj_elf_section() and the logic in _bfd_elf_final_write_processing() don't, makes no sense. Either STANDALONE is meant to be GNU-ish, or it is not, I would think. Drop the one inconsistent check. If it was not GNU-ish (as the other two locations suggest), what did the section23b testcase actually mean to check? The numeric attribute value 0x200000 has an entirely unknown (or more precisely, OS-defined, which we may or may not know of) meaning then, so ought to be accepted. If it was GNU-ish, the other testcase, elf/section23a, would want running for those targets as well, and the testcase in question would still be wrong to have. Hence that testcase is removed, and section23a is renamed to just section23. 2025-08-15 Jan Beulich bfd: have objcopy retain unknown ELF section flags Silently zapping them is certainly wrong. When they're not replaced due to user request, simply keeping them may not always be correct (we don't know what such a flag means, after all), but is certainly at least closer to having the output object still represent what the input object had. This introduces new binutils/ testsuite failures, but only for two targets where most of the tests there fail anyway (amdgcn-elf and nfp-elf), due to there not being an assembler available. 2025-08-15 H.J. Lu strip: Treat slim GCC/LLVM IR objects the same Slim LLVM IR object is a standalone file whose first 4 bytes are 'B', 'C', 0xc0, 0xde. GCC IR object is regular ELF object with sections whose names start with .gnu.lto_.* or .gnu.debuglto_.*. GCC IR object uses a .gnu.lto_.lto. section to encode the LTO bytecode information: struct lto_section { int16_t major_version; int16_t minor_version; unsigned char slim_object; /* Flags is a private field that is not defined publicly. */ uint16_t flags; }; In slim GCC IR object, the slim_object field is non-zero. Strip should treat slim GCC/LLVM IR objects the same. Since strip won't change slim LLVM IR objects, it should leave slim GCC IR object unchanged even when asked to remove all IR objects: 1. Set the lto_type field to lto_slim_ir_object for slim LLVM IR object. 2. Always copy slim IR object as unknown object. bfd/ PR binutils/33271 * format.c (bfd_set_lto_type): Set the lto_type field to lto_slim_ir_object for slim LLVM IR object. binutils/ PR binutils/33271 * objcopy.c (lto_sections_removed): Removed. (copy_archive): Always copy slim IR object as unknown object. (copy_file): Likewise. (strip_main): Updated. ld/ PR binutils/33271 * testsuite/ld-plugin/lto-binutils.exp: Don't check if fat IR is available when running slim IR tests. * testsuite/ld-plugin/strip-1a-s-all.nd: Expect full symbol list. 2025-08-15 GDB Administrator Automatic date update in version.in 2025-08-14 Pietro Monteiro config: Update obsolete autoconf macro Change AC_TRY_LINK to AC_LINK_IFELSE in config/dejagnu.m4. Reviewed-by: Indu Bhagat 2025-08-14 Tom de Vries [gdb/testsuite] Fix gdb.base/dlmopen.exp on native-gdbserver With test-case gdb.base/dlmopen.exp and target board native-gdbserver, I get: ... (gdb) info breakpoints 3^M Num Type Disp Enb Address What^M 3 breakpoint keep y 0x00007ffff7fc8000 ^M stop only if (0) (target evals)^M (gdb) FAIL: $exp: test_solib_unmap_events: check b/p status ... The problem is that the regexp doesn't allow for the "(target evals)" part: ... -re -wrap "$bpnum\\s+breakpoint\\s+keep\\s+y\\s+$::hex\\s*\[^\r\n\]+\r\n\\s+stop o nly if \\(0\\)" { ... Fix this by updating the regexp. While we're at it: - rewrite the regexp using multiline, string_to_regexp, join and string cat to make it more readable, and - remove the redundant failure clause from the same gdb_test_multiple. Tested on x86_64-linux using make-check-all.sh. Approved-By: Tom Tromey 2025-08-14 Tom de Vries [gdb/testsuite] Fix gdb.tui/basic.exp on native-extended-gdbserver With test-case gdb.tui/basic.exp and target board native-extended-gdbserver I get: ... status line: 'extended-r No process (asm) In: L?? PC: ?? ' FAIL: gdb.tui/basic.exp: status window: reverse ... because the regexp: ... gdb_assert { [regexp "^<.*>exec" $status] == 1 } \ ... tries to match: ... status line: 'exec No process (asm) In: L?? PC: ?? ' ... Fix this by updating the regexp to allow both exec and extended-r. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-08-14 Simon Marchi gdb, gdbserver: update copyright years in copyright notices The copyright notices printed by these programs still use year 2024. Update to 2025. It seems like a trivial patch to me, but I am posting it for review, in case there's something wrong in the new-year process that caused them to be missed, in which case we should address that too. Change-Id: I7d9541bb154b8000e66cfead4e4228e33c49f18b Approved-by: Kevin Buettner 2025-08-14 Simon Marchi gdb/testsuite: update some copyright years I ran gdb/copyright.py and these were changed. Change-Id: If0cfb538eff45cbb51863b963405002689512285 2025-08-14 Simon Marchi gdb/dwarf: clear per_bfd::num_{comp,type}_units on error Commit bedd6a7a44 ("gdb/dwarf: track compilation and type unit count") causes this internal error: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/debug-names-duplicate-cu/debug-names-duplicate-cu -ex "save gdb-index -dwarf-5 /tmp" -batch warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names. /home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed. This is visible when running this test: $ make check TESTS="gdb.dwarf2/debug-names-duplicate-cu.exp" RUNTESTFLAGS="--target_board=cc-with-debug-names" ... Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/debug-names-duplicate-cu.exp ... gdb compile failed, warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names. /home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed. ... === gdb Summary === # of untested testcases 1 However, it's easy to miss because it only causes an "UNTESTED" to be recorded, not a FAIL or UNRESOLVED. This is because the problem happens while trying to create the .debug_names index, as part of the test case compilation. The problem is: when we bail out from using .debug_names because we detect it is inconsistent with the units in .debug_info, we clear per_bfd->all_units, to destroy all units previously created, before proceeding to read the units with an index. However, we don't clear per_bfd->num_{comp,type}_units. As a result, per_bfd->all_units contains one unit, while per_bfd->num_comp_units is 2. Whenever we clear per_bfd->all_units, we should also clear per_bfd->num_{comp,type}_units. While at it, move this logic inside a scoped object. I added an assertion in finalize_all_units to verify that the size of per_bfd->all_units equals per_bfd->num_comp_units + per_bfd->num_type_units. This makes the problem (if omitting the fix) visible when running gdb.dwarf2/debug-names-duplicate-cu.exp with the unix (default) target board: ERROR: Couldn't load debug-names-duplicate-cu into GDB (GDB internal error). FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type (GDB internal error) FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type, check type is valid === gdb Summary === # of expected passes 1 # of unexpected failures 2 # of unresolved testcases 1 I considered changing the code to build a local vector of units first, then move it in per_bfd->all_units on success, that would avoid having to clean it up on error. I did not do it because it's a much larger change, but we could consider it. Change-Id: I49bcc0cb4b34aba3d882b27c8a93c168e8875c08 Approved-By: Tom Tromey 2025-08-14 Tom de Vries [gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp on native-gdbserver With test-case gdb.base/condbreak-multi-context.exp on target board native-gdbserver, I run into: ... (gdb) continue Continuing. gdb/ax-gdb.c:542: internal-error: gen_var_ref: \ LOC_CONST_BYTES symbols are not supported A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- FAIL: $exp: start_before=true: scenario_1: run until A::func (GDB internal error) Resyncing due to internal error. 0x64cfa9 gdb_internal_backtrace_1 gdb/bt-utils.c:122 0x64d047 _Z22gdb_internal_backtracev gdb/bt-utils.c:175 0x10cfdf1 internal_vproblem gdb/utils.c:423 0x10d020b _Z15internal_verrorPKciS0_P13__va_list_tag gdb/utils.c:503 0x19a6b4e _Z18internal_error_locPKciS0_z gdbsupport/errors.cc:57 0x5b76f9 gen_var_ref gdb/ax-gdb.c:541 0x5b9565 gen_static_field gdb/ax-gdb.c:1460 0x5b91c9 gen_struct_ref_recursive gdb/ax-gdb.c:1357 0x5b93f8 gen_struct_ref gdb/ax-gdb.c:1427 0x5bba0d _Z17gen_expr_structopP10expression10exp_opcodePN4expr9operationEPKcP10agent_exprP9axs_value gdb/ax-gdb.c:2253 0x678d94 _ZN4expr22structop_ptr_operation14do_generate_axEP10expressionP10agent_exprP9axs_valueP4type gdb/expop.h:1089 0x5b9ab6 _ZN4expr9operation11generate_axEP10expressionP10agent_exprP9axs_valueP4type gdb/ax-gdb.c:1602 0x5bb905 _Z14gen_expr_binopP10expression10exp_opcodePN4expr9operationES4_P10agent_exprP9axs_value gdb/ax-gdb.c:2233 0x69815c _ZN4expr24usual_ax_binop_operationIL10exp_opcode14EXadL_Z13eval_op_equalP4typeP10expression6nosideS1_P5valueS8_EEE14do_generate_axES5_P10agent_exprP9axs_valueS3_ gdb/expop.h:1291 0x5b9ab6 _ZN4expr9operation11generate_axEP10expressionP10agent_exprP9axs_valueP4type gdb/ax-gdb.c:1602 0x5bc034 _Z17gen_eval_for_exprmP10expression gdb/ax-gdb.c:2396 0x5f16b6 parse_cond_to_aexpr gdb/breakpoint.c:2582 0x5f18a5 build_target_condition_list gdb/breakpoint.c:2640 0x5f2698 insert_bp_location gdb/breakpoint.c:2970 0x5f3916 insert_breakpoint_locations gdb/breakpoint.c:3400 0x60c1dd update_global_location_list gdb/breakpoint.c:11771 0x5f3421 _Z18insert_breakpointsv gdb/breakpoint.c:3293 0xaa0972 keep_going_pass_signal gdb/infrun.c:9131 0xa91b23 proceed_resume_thread_checked gdb/infrun.c:3579 0xa92490 _Z7proceedm10gdb_signal gdb/infrun.c:3780 0xa72b9b _Z10continue_1i gdb/infcmd.c:639 0xa72e4b continue_command gdb/infcmd.c:730 0x6c01d1 do_simple_func gdb/cli/cli-decode.c:95 0x6c683a _Z8cmd_funcP16cmd_list_elementPKci gdb/cli/cli-decode.c:2827 0xff11a9 _Z15execute_commandPKci gdb/top.c:565 0x959e0a _Z15command_handlerPKc gdb/event-top.c:613 0x95a3e7 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE gdb/event-top.c:849 0x102b645 tui_command_line_handler gdb/tui/tui-interp.c:101 0x959548 gdb_rl_callback_handler gdb/event-top.c:288 0x1186dfd rl_callback_read_char readline/readline/callback.c:302 0x95925a gdb_rl_callback_read_char_wrapper_sjlj gdb/event-top.c:197 0x95934a gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:240 0x9593c9 gdb_rl_callback_read_char_wrapper gdb/event-top.c:252 0x1071253 stdin_event_handler gdb/ui.c:154 0x19a7c80 handle_file_event gdbsupport/event-loop.cc:551 0x19a825b gdb_wait_for_event gdbsupport/event-loop.cc:672 0x19a711c _Z16gdb_do_one_eventi gdbsupport/event-loop.cc:263 0x6ce4e3 _ZN6interp12do_one_eventEi gdb/interps.h:87 0xb74717 start_event_loop gdb/main.c:402 0xb748b6 captured_command_loop gdb/main.c:467 0xb7638f captured_main gdb/main.c:1345 0xb76438 _Z8gdb_mainP18captured_main_args gdb/main.c:1364 0x41a411 main gdb/gdb.c:38 ... This reproduces with gcc 7, not with gcc 8 or later. Fix this by throwing an error instead of asserting, getting us instead: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2.2, A::func (this=$hex) at condbreak-multi-context.cc:31^M 31 void func () {}^M (gdb) PASS: $exp: start_before=true: scenario_1: run until A::func ... Tested on x86_64-linux. Approved-By: Simon Marchi PR gdb/32012 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32012 2025-08-14 Guinevere Larsen gdb: modernize get_frame_pc_if_available The convenience function get_frame_pc_if_available would take a pointer to a variable that should be set if available, and would return a boolean indicating whether that action was successful or not. Now that GDB supports C++17 features, this indirection of a pointer and returning boolean is unnecessary, since the function can return an optional, and code that calls it can check if the optional contains a value. This commit makes that modernization. It should have no visible effects. Approved-By: Tom Tromey 2025-08-14 Tom de Vries [gdb/testsuite] Remove useless indentation in lib/tuiterm.exp In lib/tuiterm.exp we have: ... namespace eval Term { variable ... ... } ... with everything within the namespace (which is basically the entire file) indented, which wastes screen space and makes editing more involved. We could maybe fix this by moving the "namespace eval Term" to tuiterm_env, but I don't think it's a good idea to move it out of the file. Another idea is to have the file include itself, wrapped in the namespace: ... if { ![info exists Term::_in_namespace] } { namespace eval Term { # Read the rest of this file, wrapped in this namespace. variable _in_namespace set _in_namespace 1 source $::srcdir/lib/tuiterm.exp unset _in_namespace return } } variable ... ... but this was considered unnecessarily complex. Fix this in the style of lib/ton.tcl and lib/completion-support.exp: - only declare the variables in the namespace, and - define the procs using a Term:: prefix. As a side-effect, this works around an emacs bug that makes editing lib/tuiterm.exp in its current form problematic because the auto-indentation keeps removing required indentation of all but the first proc [1]. Tested on x86_64-linux. [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01674.html 2025-08-14 Guinevere Larsen gdb, configure: Add enable-binary-file-format option for configure GDB has support for many binary file formats, some which might be very unlikely to be found in some situations (such as the XCOFF format in an x86 system). This commit introduces the option for a user to choose which formats GDB will support at build configuration time. This is especially useful to avoid possible security concerns with readers that aren't expected to be used at all, as they are one of the simplest vectors for an attacker to try and hit GDB with. This change can also reduce the size of the final binary, if that is a concern. This commit adds a switch to the configure script allowing a user to only enable selected file formats, called --enable-binary-file-formats. The default behavior when the switch is omitted is to compile all file formats, keeping the original behavior of the script. At the time of this commit, the valid options for this option are: dbx, coff (which includes coff-pe), xcoff, mips, elf, macho and all. All is treated especially, activating all supported readers. A few targets may require specific binary file format support, as they directly call functions defined by the file reader. Specifically, windows targets require coff support, and rs6000 aix and lynx178 targets require xcoff support. Considering that those formats are the main - or only - one available in those targets, I believe it makes sense to re-enable those readers. If that happens, the script will emit the following warning: FOO is required to support one or more requested targets. Adding it Users aren't able to force the disabling of those formats, since GDB will not compile without those readers. Ideally we'd like to be able to disable even those formats, in case a user wants to build GDB only to examine remote files for example, but the current infrastructure for the file format readers doesn't allow us to do it. Mach-O and elf support are also dependent on BFD support being compiled in. In case one of those was requested and BFD does not support them, the following error is emitted: FOO was requested, but BFD does not support it. Finally, this configure switch is also printed by the "show configuration" command in GDB. Reviewed-By: Eli Zaretskii Approved-By: Tom Tromey 2025-08-14 Indu Bhagat bfd: sframe: fix PR ld/33199 Fix PR ld/33199 SEGV in _bfd_x86_elf_create_sframe_plt Currently, the selection for sframe_plt was not being done (and simply set to NULL) for the case when !normal_target, causing SEGV on Solaris. Initialize sframe_plt to init_table->sframe_lazy_plt when lazy_plt is true, and NULL otherwise. This is in line with htab->non_lazy_plt being set to NULL for !normal_target. bfd/ PR ld/33199 * elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Setup sframe_plt for !normal_target. 2025-08-14 Andrew Burgess bfd: support for NT_386_TLS notes In a later commit I'd like to add support to GDB for including the NT_386_TLS note in the core files that GDB creates (using 'gcore' command). To achieve this we need some standard boilerplate code added to bfd. The only part of this patch which I think needs consideration is the name I selected for the pseudo section to hold the note contents when a core file is loaded. I chose '.reg-i386-tls'. The '.reg' prefix is the standard used by most other pseudo sections, and the '-i386-tls' suffix seemed to match the note name, though I added the 'i' to 'i386', instead of just using '.reg-386-tls'. I thought 'i386' seemed clearer. There's no test included here, but when I merge the NT_386_TLS creation to GDB it will depend on this and act as a test. I plan to post that work to the GDB list once this patch is merged. 2025-08-14 H.J. Lu ld: Use stat to check if linker script appears multiple times Use stat, instead of strcmp, to check if the same linker script file appears multiple times for $ ld -L... -T ././/script.t -T script.t ... Although ././/script.t and script.t access the same file, but their filenames are different. strcmp won't work here. Copy gnulib/import/same-inode.h to include since the gnulib directory isn't included in the binutils tarball. include/ PR ld/24576 * same-inode.h: New file. Copied from gnulib/import/same-inode.h. ld/ PR ld/24576 * ldfile.c: Include "same-inode.h". (ldfile_find_command_file): Change the second argument from bool to enum script_open_style. Check if the same linker script file appears multiple times by using stat, instead using strcmp. (ldfile_open_command_file_1): Don't check if the same linker script file appears multiple times here. * testsuite/ld-scripts/pr24576-1.d: Adjusted. * testsuite/ld-scripts/pr24576-2.d: New. * testsuite/ld-scripts/script.exp: Run pr24576-2. 2025-08-14 Tom de Vries [gdb/testsuite] Disable CLI styling by default in Term::prepare_tui On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to match the output of the file command, for which I submitted a patch [1]. However, after switching to TERM=ansiw for bsd, I could no longer reproduce the problem. Investigation showed that the difference was caused by CLI styling. A command: ... (gdb) file ... gives an output: ... Reading symbols from ... (gdb) ... On x86_64-linux, with CLI styling I get: ... Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m... ... After disabling CLI styling using "set style enabled off", I simply get: ... Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main... ... and run into the same failure as on x86_64-freebsd. The extra csi sequence "^[[32m" causes an additional matching attempt in Term::wait_for, and the way we're currently matching relies on this: ... send_gdb "file [standard_output_file $testfile]\n" gdb_assert { [Term::wait_for "Reading symbols from"] } "file command" ... Make the TUI testsuite more stable and matching more simple by disabling CLI styling by default, and: - fix the resulting fallout in test-cases gdb.tui/main.exp and gdb.tui/new-layout.exp, and - re-enable CLI styling in the one test-case that needs it: gdb.tui/tui-disasm-styling.exp. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2025-June/218942.html 2025-08-14 Alan Modra Recognise ECOFF armap in bfd_slurp_armap Recognise ECOFF archives and reject them so that the ecoff archive support has a chance to handle the archive. Also use memcmp rather than startswith (strncmp) as we know the string length. * archive.c (bfd_slurp_armap): Recognize ECOFF armap. Use memcmp to match names, and tidy buffer sizes. 2025-08-14 Alan Modra objcopy/strip of IR files and is_strip_input This tidies objcopy/strip handling of IR objects, in the process of removing the unnecessary is_strip_input flag. The first thing I noticed when looking at is_strip_input code was that the abfd->my_archive test in bfd_check_format_matches meant that plugins were disabled when reading archive elements. We can instead disable plugins by setting bfd_no_plugin, so there doesn't seem to be a need for is_strip_input in objcopy.c:copy_archive. This isn't exactly the same, because bfd_no_plugin prevents the plugin target recognising archive elements in the bfd_check_format_matches loop over all targets as well as just the first !target_defaulted test. But that turns out to be fine. IR code is handled in copy_archive as for other unknown format files. In fact, the only need for the plugin target when copying archives is when reading symbols for the archive map. I've made that plain by moving the plugin target override and commenting on why it is really needed. So on to plain object files. Here, IR code is also copied unchanged, so there doesn't seem a need for the plugin target there either. It isn't quite so simple though, because the objcopy/strip code handling object files wants to verify the format of the object file. Allowing objcopy/strip to copy unknown format files would be a change in behaviour (and results in mmix testsuite fails, ld-mmix/b-badfil1 and others). However, always excluding the plugin target results in a fail of tests added in commit c2729c37f10a. So I've enabled a plugin format check only for files that are otherwise unrecognised, and commented why this is done. I question the need to objcopy LLVM bytecode files. bfd/ * bfd.c (struct bfd): Delete. * format.c (bfd_check_format_matches): Delete is_strip_input special case code. * bfd-in2.h: Regenerate. binutils/ * objcopy.c (copy_archive): Don't set is_strip_input. Always set bfd_plugin_no when reading elements. Enable plugins when opening copied elements. (check_format_object): Delete. (copy_file): Don't enable plugin target here. Don't set is_strip_input. Set bfd_plugin_no. Move bfd_core handling code earlier to remove goto. Enable plugin for llvm bytecode. Copy slim IR files as unknown objects. 2025-08-14 Alan Modra Correct readelf thin archive test If we have an existing archive, the test may fail due to it being the wrong format. Also, downloading bintest.thin.a from a remote host (before creating it!) is wrong. * testsuite/binutils-all/readelf.exp (readelf_thin_archive_test): Don't remote_download bintest.thin.a. Delete lib before creating. 2025-08-14 Tom de Vries [gdb/testsuite] Make prompt matching in Term::wait_for more strict On x86_64-freebsd, I run into: ... Box Dump (80 x 24) @ (0, 0): 0 (gdb) maint info screen 1 Number of characters gdb thinks are in a line is 90. 2 Number of characters readline reports are in a line is 89. 3 Number of characters curses thinks are in a line is 90. 4 Number of characters environment thinks are in a line is 90 (COLUMNS). 5 Number of lines gdb thinks are in a page is 40. 6 Number of lines readline reports are in a page is 40. 7 Number of lines curses thinks are in a page is 40. 8 Number of lines environment thinks are in a page is 40 (LINES). 9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column 10 . 11 (gdb) tui disable 12 (gdb) tui disable 13 (gdb) maint info screen 14 15 16 17 18 19 20 21 22 23 FAIL: gdb.tui/resize-2.exp: again: curses width 80 ... The problem is that the prompt matching in Term::wait for is not strict enough. It will accept a line: ... (gdb) foo ... as long as the cursor is pointing just after the prompt, like so: ... (gdb) foo ^ ... Fix this by also checking that the line is empty. Tested on x86_64-linux. 2025-08-14 Tom de Vries [gdb/testsuite] Stop on main in gdb.gdb/{python-helper,selftest}.exp With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into: ... UNTESTED: gdb.gdb/selftest.exp: \ Cannot set breakpoint at captured_main, skipping testcase. UNTESTED: gdb.gdb/python-helper.exp: \ Cannot set breakpoint at captured_main, skipping testcase. ... I don't know why we're trying to stop in captured_main. Stopping in main also works, and main is more likely to be present in an lto build. Fix this by using main instead. This requires us to update the expected file name from main.c to gdb.c in selftest_setup. After doing so, we get: ... XFAIL: gdb.gdb/selftest.exp: \ run until breakpoint at main (line numbers scrambled?) XFAIL: gdb.gdb/python-helper.exp: \ run until breakpoint at main (line numbers scrambled?) ... because main is reported to be in run-on-main-thread.c instead of gdb.c: . Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M ... This is due to picking the last line entry for pc == 0x455e40 that has is_stmt == true: ... File name Line number Starting address View Stmt gdb/gdb.c: gdb.c 25 0x455e40 x gdb.c 30 0x455e40 1 x gdb/run-on-main-thread.c: run-on-main-thread.c 116 0x455e40 2 x run-on-main-thread.c 120 0x455e40 3 x gdb/gdb.c: gdb.c 25 0x455e40 4 /usr/include/c++/15/bits/std_thread.h: std_thread.h 366 0x455e4b ... While we're at it, update the corresponding gdb_test_multiple in selftest_setup using multi_line and -wrap. Tested on x86_64-linux. 2025-08-14 Tom de Vries [gdb/testsuite] Make ^C cancel i-search PR cli/21690 reports the following: say we start gdb: ... $ gdb -q (gdb) ... and press ^R for reverse-i-search: ... (reverse-i-search)`': ... Pressing the p key has the effect of showing both the pressed key and a matching entry, which happens to be up: ... (reverse-i-search)`p': up ... Now we press ^C to cancel the search: ... (reverse-i-search)`p': u❌️ Quit (gdb) ... and type "down". We expected to get: ... (gdb) down ... but instead we get: ... (failed reverse-i-search)`pdown': ... So we're stuck in reverse-i-search, until we use the workaround of ^G. The same problem happened with python [1], was reported upstream [2], and fixed in cpython commit d6990d221b0 ("Issue #24266: Cancel history search mode with Ctrl+C in Readline 7") using rl_callback_sigcleanup. Fix this likewise in quit using rl_callback_sigcleanup, a new callback function in readline 7.0: ... i. rl_callback_sigcleanup: a new application function that can clean up and unset any state set by readline's callback mode. Intended to be used after a signal. ... giving us instead: ... $ gdb (gdb) u❌️ Quit (gdb) down ... Remove the corresponding kfail in gdb.tui/pr30056.exp. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21690 [1] https://bugs.python.org/issue24266 [2] https://lists.gnu.org/archive/html/bug-readline/2015-05/msg00014.html 2025-08-14 Nelson Chu RISC-V: PR33216, Allow c.slli, c.srai, c.srli with 0 immediate as a hint The original patch, e6f372ba661bb0d8eec1e22a6dc1ad9937336e4d Since recently c.slli64, c.srai64, and c.srli64 have been removed from the riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed as hints, https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093 So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with 0 immediate. Passed rv32/64-elf/linux binutils testcases. gas/ PR 33216 * testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64, c.srai64, and c.srli64 with 0 immediate as a hint. * testsuite/gas/riscv/c-zero-imm.s: Likewise. * testsuite/gas/riscv/zca.d: Likewise. opcodes/ PR 33216 * riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64, and c.srli64 with 0 immediate as a hint. 2025-08-14 GDB Administrator Automatic date update in version.in 2025-08-13 Tom Tromey Refine range check in create_addrmap_from_gdb_index PR symtab/33247 points out that this check in create_addrmap_from_gdb_index: if (lo > hi) { complaint (_(".gdb_index address table has invalid range (%s - %s)"), hex_string (lo), hex_string (hi)); ... should probably use ">=" instead. Reading a bit further the reason seems obvious: mutable_map.set_empty (lo, hi - 1, index->units[cu_index]); Here if lo==hi, then this will insert a "reversed" range into the addrmap. Apparently some LLVM tool can erroneously create a .gdb_index like this. No test because it seems like more trouble to write than it's worth. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33247 Approved-By: Simon Marchi 2025-08-13 Tom Tromey Remove cast from captured_main captured_main takes a 'void *', but then immediately casts it to the correct type. There's no reason for this any more, the caller passes in the correct type. This patch cleans this up. Tested by rebuilding. 2025-08-13 Pietro Monteiro gnulib: Update obsolete autoconf macros Remove AM_PROG_CC_STDC, the correct macro AC_PROG_CC is already being used. Update AC_OUTPUT (file list, [cmd list]) by adding the file list to the previous AC_CONFIG_FILES and using AC_CONFIG_COMMANDS to output the command list. Approved-By: Tom Tromey 2025-08-13 GDB Administrator Automatic date update in version.in 2025-08-12 Tom de Vries [gdb/tui] Make tui_disassemble more efficient Function tui_disassemble (with addr_size parameter) has two modes of operation: - addr_size != nullptr, and - addr_size == nullptr. I noticed that for the addr_size == nullptr case, more than necessary is done. Fix this by using continue and null_stream. While we're at it, eliminate the unnecessary variables new_size and orig_pc. Tested on x86_64-linux. Approved-By: Andrew Burgess 2025-08-12 Tom de Vries [gdb/tdep] Handle M1 ldp in aarch64_stopped_data_address In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice, two adjacent 8-byte vars are written. For aarch64, we use a single stp instruction for that. If we do the same in function read_size8twice for two adjacent 8-byte var reads using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang: ... (gdb) continue^M Continuing.^M FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout) FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit ... The same problem was observed for stp in PR tdep/29423, fixed by commit 9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64"). See that commit for an explanation of the hang. That commit introduced max_access_size in aarch64_stopped_data_address: ... The access size also can be larger than that of the watchpoint itself. For instance, the access size of an stp instruction is 16. So, if we use stp to store to address p, and set a watchpoint on address p + 8, the reported ADDR_TRAP can be p + 8 (observed on RK3399 SOC). But it also can be p (observed on M1 SOC). Checking for this situation introduces the possibility of false positives, so we only do this for hw_write watchpoints. */ const CORE_ADDR max_access_size = type == hw_write ? 16 : 8; ... If we say that hangs are worse than false positives, then we should also fix this case. Fix this by setting max_access_size to 16 for all watchpoint types. Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC. Approved-By: Luis Machado 2025-08-12 Tom de Vries [gdb/testsuite] Extend gdb.base/watchpoint-unaligned.exp Extend the part of gdb.base/watchpoint-unaligned.exp handling write_size8twice to also check read hardware watchpoints. Tested on x86_64-linux. Approved-By: Luis Machado 2025-08-12 Tom de Vries [gdb/testsuite] Improve gdb.base/watchpoint-unaligned.exp Improve the part of gdb.base/watchpoint-unaligned.exp handling write_size8twice: - move the code into a proc - use -wrap - use $decimal more often - don't use gdb_test_multiple $test $test - add comments - start test when entering write_size8twice function, instead of main - finish test when leaving write_size8twice function, instead of main - add insn in between: - insn triggering watchpoint, and - insn triggering breakpoint to ensure that the watchpoint triggers before the breakpoint, and add a comment explaining this. Tested on x86_64-linux. 2025-08-12 Tom Tromey Change type::fields to return an array_view This patch changes type::fields to return an array_view of the fields, then fixes up the fallout. More cleanups would be possible here (in particular in the field initialization code) but I haven't done so. The main motivation for this patch was to make it simpler to iterate over the fields of a type. Regression tested on x86-64 Fedora 41. Approved-By: Simon Marchi 2025-08-12 H.J. Lu x86: Always treat protected symbols as local Since linker never generates dynamic relocation for protected symbol in: __attribute__((visibility("protected"))) int my_data; int * func (void) { return &my_data; } we should always treat protected symbols as local. bfd/ PR ld/33260 * elfxx-x86.h (COPY_INPUT_RELOC_P): Always treat protected symbols as local. ld/ PR ld/33260 * testsuite/ld-i386/i386-export-class.rd: Updated. * testsuite/ld-i386/i386-export-class.xd: Likewise. * testsuite/ld-i386/i386.exp: Run pr33260-2. * testsuite/ld-i386/pr33260-2.d: New file. * testsuite/ld-i386/pr33260-2.s: Likewise. * testsuite/ld-i386/pr33260.d: Remove "-z indirect-extern-access". * testsuite/ld-x86-64/pr33260-x32.d: Likewise. * testsuite/ld-x86-64/pr33260.d: Likewise. * testsuite/ld-x86-64/pr33260-2-x32.d: New file. * testsuite/ld-x86-64/pr33260-2.d: Likewise. * testsuite/ld-x86-64/pr33260-2.s: Likewise. * testsuite/ld-x86-64/x86-64-64-export-class.rd: Updated. * testsuite/ld-x86-64/x86-64-x32-export-class.rd: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr33260-2 and pr33260-2-x32. 2025-08-12 Tom Tromey Avoid scopes.exp failure on certain architectures A buildbot pointed out that my changes to gdb.dap/scopes.exp caused a test failure. The new code iterates over all the registers, fetching their children (when possible). The failure comes because this code failed to consider that a register might have "indexed" children, which I believe can occur when a register is vector-like. This patch fixes the problem by arranging to fetch indexed children when indicated. 2025-08-12 GDB Administrator Automatic date update in version.in 2025-08-11 H.J. Lu i386: Add Linux/x86-64 support to export-class.exp Add Linux/x86-64 support to export-class.exp by passing --32 to assembler and passing -melf_i386 to linker. * testsuite/ld-i386/export-class.exp: Run for Linux/x86-64. Pass --32 to assembler. Pass -melf_i386 to linker. 2025-08-11 H.J. Lu ld: Add a test for PR ld/24576 PR ld/24576 * testsuite/ld-scripts/pr24576-1.d: New. * testsuite/ld-scripts/script.exp: Run pr24576-1. 2025-08-11 Tom Tromey Emit DAPException when too many variable children are reqeusted PR dap/33228 points out a failure that occurs when the DAP client requests more children of a variable than actually exist. Currently, gdb throws a somewhat confusing exception. This patch changes this code to throw a DAPException instead, resulting in a more ordinary and readable failure. The spec seems to be silent on what to do in this case. I chose an exception on the theory that it's easier to be strict now and lift the restriction later (if needed) than vice versa. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228 2025-08-11 Tom Tromey Do not allow DAP clients to dereference "void *" While investigating a different bug, I noticed that the DAP code would report a "void *"-typed register as having children -- however, requesting the children of this register would fail. The issue here is that a plain "void *" can't be dereferenced. This patch changes the default visualizer to treat a "void *" as a scalar. This adds a new test; but also arranges to examine all the returned registers -- this was the first thing I attempted and it seemed reasonable to have a test that double-checks that all the registers really can be dereferenced as appropriate. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228 2025-08-11 GDB Administrator Automatic date update in version.in 2025-08-10 GDB Administrator Automatic date update in version.in 2025-08-09 H.J. Lu x86: Treat protected symbols with indirect external access as local If all external symbol accesses are indirect, we can treat protected symbols as local since there will be no copy relocation for data and external function pointer access will go through GOT, instead of PLT. No PLT slot should be used for external function pointer in executable. bfd/ PR ld/33260 * elfxx-x86.h (COPY_INPUT_RELOC_P): Treat protected symbols with indirect external access as local. ld/ PR ld/33260 * testsuite/ld-i386/i386.exp: Run PR ld/33260 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/pr33260.d: New file. * testsuite/ld-i386/pr33260.s: Likewise. * testsuite/ld-x86-64/pr33260-x32.d: Likewise. * testsuite/ld-x86-64/pr33260.d: Likewise. * testsuite/ld-x86-64/pr33260.s: Likewise. 2025-08-09 GDB Administrator Automatic date update in version.in 2025-08-08 Sam James binutils: add ia64 marker in name of testranges-ia64 Otherwise, the same test appears twice, once with PASS, once with UNSUPPORTED on non-ia64. Just add '(ia64)' to the name so binutils.log is clearer. * testsuite/binutils-all/testranges-ia64.d (#name): Add suffix. 2025-08-08 H.J. Lu run_lto_binutils_test: Pass $plug_opt to nm Pass $plug_opt to nm when setting dump_prog to nm to load plugin. PR binutils/21479 * testsuite/ld-plugin/lto-binutils.exp (run_lto_binutils_test): Pass $plug_opt to nm. 2025-08-08 Keith Seitz should_validate_memtags: Do not dereference references should_validate_memtags uses value_as_address to evalute whether an address for a value is tagged. The comments for that function simply say, "Extract a value as a C pointer." While that sounds innoncuous, that function calls coerce_array, which will dereference any references. This is not what is desired here. This can be demonstrated on an MTE-enabled host, such as aarch64- based Ampere (example taken from tests introduced in this patch): (gdb) p b.get_foo () Could not validate memory tag: Value can't be converted to integer. $2 = (const foo &) @0xffffffffed88: {m_a = 42} While the command completes, gdb didn't actually attempt to evaluate any memory tags. Fix this by using unpack_pointer instead. Tested on x86_64 Fedora 40 and aarch64 RHEL 9.6. 2025-08-08 Tom de Vries [gdb/testsuite] Fix gdb.tui/basic.exp for TERM=ansis With test-case gdb.tui/basic.exp and TERM=ansis, I run into (with some logging added): ... status line: 'exec No process (asm) In: L?? PC: ?? ' FAIL: gdb.tui/basic.exp: status window: reverse ... The status window uses ncurses attribute standout, which can differ between different terminal settings. Fix this by making the matching less strict. Tested on x86_64-linux. 2025-08-08 Tom de Vries [gdb/testsuite] Fix gdb.tui/main-2.exp for TERM=ansis When running test-case gdb.tui/main-2.exp with TERM=ansis, I get: ... screen line 6: 'B+> 21 return 0; ' FAIL: gdb.tui/main-2.exp: highlighted line in middle of source window ... The test tries to check the highlighting of the source line, but also gets the part with the line number, which makes it more complicated to parse. Fix this by getting just the part with the source line: ... screen line 6: ' return 0; \ ' ... Tested on x86_64-linux. 2025-08-08 Tom de Vries [gdb/testsuite] Initial TERM=ansis support in tuiterm While investigating using TERM=ansiw for freebsd, I also came across TERM=ansis which unlike ansiw is present on both linux and freebsd. Add initial support for TERM=ansi in tuiterm: - handle ansis in Term::_have_bw - add Term::_csi_x to support (well, ignore) DECREQTPARM (Request Terminal Parameters) This is sufficient to make the TUI testsuite pass on x86_64-freebsd. 2025-08-08 Tom de Vries [gdb/testsuite] Fix gdb.tui/tui-layout-asm-short-prog.S compilation The test-case gdb.tui/tui-layout-asm-short-prog.exp uses an assembly file gdb.tui/tui-layout-asm-short-prog.S that it compiles using -nostdlib and -nostartfiles. However, on x86_64-linux the resulting executable still has dependencies on libm and libc: ... $ ldd outputs/gdb.tui/tui-layout-asm-short-prog/tui-layout-asm-short-prog linux-vdso.so.1 (0x00007ffddf3ec000) libm.so.6 => /lib64/libm.so.6 (0x00007f8b13406000) libc.so.6 => /lib64/libc.so.6 (0x00007f8b13000000) /lib64/ld-linux-x86-64.so.2 (0x00007f8b1350f000) ... due -lm being added by default_target_compile. On x86_64-freebsd, using -nostdlib and -nostartfiles in combination with -lm causes the compilation to fail. Fix this by using -static as well. Tested on x86_64-linux and x86_64-freebsd. 2025-08-08 Tom de Vries [gdb/testsuite] Fix gdb.base/exprs.exp for gdb build with byacc On x86_64-freebsd, with test-case gdb.base/exprs.exp I get: ... (gdb) print 23 yydebug: state 0, reading 257 (INT) yydebug: state 0, shifting to state 1 yydebug: state 1, reducing by rule 94 (exp : INT) yydebug: after reduction, shifting from state 0 to state 59 yydebug: state 59, reading 0 (end-of-file) yydebug: state 59, reducing by rule 7 (exp1 : exp) yydebug: after reduction, shifting from state 0 to state 60 yydebug: state 60, reducing by rule 1 (start : exp1) yydebug: after reduction, shifting from state 0 to state 58 $220 = 23 (gdb) FAIL: gdb.base/exprs.exp: print with debugging ... The test fails because it's not finding the string "Starting parse". In this case, the .y files are processed used byacc. I suppose the testcase matches the case that bison is used. Fix this by grepping for something more generic: shift or Shift. Tested on x86_64-linux and x86_64-freebsd. 2025-08-08 Jan Beulich bfd/ELF/Arm: make various arrays static / const There's no reason to have the compiler materialize objects onto the stack. And there's also no reason to allow comb[] and name_table[] to be modifiable. bfd/ELF/RISC-V: make one local array static and several const There's no reason for riscv_all_supported_ext[] to appear in libbfd.so's dynamic symbol table. There's also no reason for various pieces of data to live in .data, when .data.rel.ro or even .rodata can do. bfd/ELF: make three local arrays static ... and const. There's no reason to have the compiler copy anonymous objects onto the stack. And there's also no reason to allow the arrays to be modifiable. Arm: parse_neon_type() weaknesses The custom parsing done there and in one of its callers allowed various bogus constructs to be accepted. Insist on a non-zero leading digit when parsing numbers, don't lose upper bits, and insist on proper separation of operands. opcodes/aarch64: shrink aarch64_ext_ldst_reglist()'s data[] The values are all pretty small; one is even a boolean. No point in wasting 32 bits for every one of the fields. opcodes/aarch64: rename fields[] To be a fair global name space citizen, give it an aarch64_ prefix. In two cases, drop a variable that's used only once. 2025-08-08 Tom de Vries [gdb/testsuite] Add gdb.base/color-prompt.exp After updating the documentation in commit cf03713dd1c ("[gdb/cli] Document \001 and \002 usage for set prompt"), I started to wonder if I could reproduce the CLI issue described in PR cli/28887 using the TUI. That turned out not to be the case, but I noticed handling of the markers in tui_puts and tui_puts_internal, and no test-case exercising this, so I decided to add this. After doing so in gdb.tui/color-prompt.exp, I realized I could use the same code to test the CLI case. Add test-case gdb.base/color-prompt.exp that shares code with gdb.tui/color-prompt.exp in gdb.tui/color-prompt.exp.tcl. For the CLI case, I was hoping to reproduce the behaviour described in the PR, but it didn't trigger. FTR, I manually reproduced the behaviour and used script to record it. I observed the following sequence after the C-a: - ^M (CR) : go to start of line - ^[[K (EL) : erase line - ^M (CR) : go to start of line - ^[[31m(gdb) ^[[0m : output prompt - some long command : output text - ^M (CR) : go to start of line - ^[[C, 15 times (CUF): cursor forward 15 times giving me: ... (gdb) some long command ^ ... Perhaps we'll trigger this on some other os, or once we start using a different TERM value. Tested on x86_64-linux. 2025-08-08 Tom de Vries [gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi In ppc64_sysv_abi_return_value I came across this if clause: ... /* Small character arrays are returned, right justified, in r3. */ if (valtype->code () == TYPE_CODE_ARRAY && !valtype->is_vector () && valtype->length () <= 8 && valtype->target_type ()->code () == TYPE_CODE_INT && valtype->target_type ()->length () == 1) ... I decided to write a test-case to try and trigger this. AFAIU, in C/C++, we're not allowed to return an array, so I wrote an Ada test-case instead, with a function returning this type: ... type T is new String (1 .. 4); ... After doing so I realized that the clause above is not triggering because valtype->target_type ()->code () == TYPE_CODE_CHAR. Fix this by allowing both TYPE_CODE_INT and TYPE_CODE_CHAR. Then I realized that the specific "small character array" handling comes from the v1 abi. Add a check for this as well. Tested on ppc64le-linux, with v2 abi. Approved-By: Simon Marchi 2025-08-08 GDB Administrator Automatic date update in version.in 2025-08-07 H.J. Lu ldlang.c: Don't include "elf-bfd.h" twice * ldlang.c: Don't include "elf-bfd.h" twice. 2025-08-07 Alan Modra Move struct plugin_data_struct to plugin.c It isn't needed anywhere except plugin.c. The typedef can disappear. Also make a forward declaraion for ld_plugin_input_file in plugin.h so that this header can be used without first including plugin-api.h. bfd/ * plugin.h (struct ld_plugin_input_file): Forward declare. (struct plugin_data_struct): Move to.. * plugin.c: ..here. (add_symbols): Size plugin_data without using type. * archive.c: Don't include plugin-api.h. * elflink.c: Likewise. * format.c: Likewise. binutils/ * ar.c: Don't include plugin-api.h or ansidecl.h. Only include plugin.h when BFD_SUPPORTS_PLUGINS. * nm.c: Don't include plugin-api.h. Only include plugin.h when BFD_SUPPORTS_PLUGINS. * objcopy.c: Likewise. ld/ * ldfile.c: Don't include plugin-api.h. * ldmain.c: Likewise. 2025-08-07 Pietro Monteiro Update obsolete autoconf macros bfd/ * bfd.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. binutils/ * configure.ac: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. gas/ * acinclude.m4: Replace AC_TRY_LINK with AC_LINK_IFELSE. Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. gprof/ * configure.ac: Replace AC_OUTPUT(file list) with AC_CONFIG_FILES([file list])\nAC_OUTPUT. libctf/ * configure.ac: Replace AC_TRY_LINK with AC_LINK_IFELSE. opcodes/ * configure.ac: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. 2025-08-07 Christina Schimpe gdb: change default initialization for register numbers on x86 As defined by the enums amd64_regnum and i386_regnum the register numbering starts at 0. Defaults for register numbers are currently set to 0 which seems to be the wrong default. Set them to -1 instead. Configure the right register number if we find out it's supported in i386_gdbarch_init. Similarly we don't have to set the num_*regname* variables to 0 in i386_gdbarch_init, as it's already assigned to 0 by default. Approved-By: Andrew Burgess Approved-By: Simon Marchi 2025-08-07 Matthieu Longo libiberty: sync with gcc Import the following commits from GCC as of r16-3056-gca2169c65bd169: 0d0837df697 libiberty: disable logging of list content for doubly-linked list tests 2025-08-07 Xi Ruoyao LoongArch: Fix symbol size after relaxation There's a logic error in loongarch_relax_perform_deletes: when there's not any delete operation of which the start address is strictly smaller than the symbol address, splay_tree_predecessor() will return nullptr and the symbol size will be unchanged even if some bytes of it are removed. Make the logic more complete to fix this issue. Also factor out the symbol size adjustment logic into a function to avoid code bloating. Tested-by: WANG Xuerui 2025-08-07 GDB Administrator Automatic date update in version.in 2025-08-06 Tom Tromey Revert "Call target_can_do_single_step from maybe_software_singlestep" This reverts commit 14de1447c9c52c1bfc52588f8652836f66ac6c47. An automated tester said that this patch caused a regression on aarch64: FAIL: gdb.arch/aarch64-atomic-inst.exp: Step through the ldxr/stxr sequence (timeout) I looked into it a bit yesterday but couldn't see an obvious problem; and it's somewhat of a pain to try to debug it at the moment. Tom de Vries also noticed this and filed it in bugzilla. So, I'm backing the patch out until I can port the failing test to the AdaCore internal test suite in order to find out what went wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33255 2025-08-06 H.J. Lu strip: Don't treat fat IR objects as plugin object Fat IR objects contains both regular sections and IR sections. After commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d Author: H.J. Lu Date: Sun May 4 05:12:46 2025 +0800 strip: Add GCC LTO IR support "strip --strip-debug" no longer strips debug sections in fat IR objects since fat IR objects are recognized as plugin object and copied as unknown objects. Add a is_strip_input field to bfd to indicate called from strip. Update bfd_check_format_matches not to treat archive member nor standalone fat IR object as IR object so that strip can remove debug and IR sections in fat IR object. For archive member, it is copied as an unknown object if the plugin target is in use or it is a slim IR object. For standalone fat IR object, it is copied as non-IR object. bfd/ PR binutils/33246 * archive.c: Include "plugin-api.h" and "plugin.h" if plugin is enabled. (_bfd_compute_and_write_armap): Don't complain plugin is needed when the plugin target is in use. * bfd-in2.h: Regenerated. * bfd.c (bfd): Add is_strip_input. * format.c (bfd_set_lto_type): If there is .llvm.lto section, set LTO type to lto_fat_ir_object. (bfd_check_format_matches): Don't set LTO type when setting format. When called from strip, don't treat archive member nor standalone fat IR object as an IR object. * plugin.c (bfd_plugin_get_symbols_in_object_only): Copy LTO type derived from input sections. nm/ PR binutils/33246 * nm.c (filter_symbols): Don't complain plugin is needed when the plugin target is in use. (display_rel_file): Likewise. * objcopy.c (copy_archive): Set the BFD is_strip_input field of archive member to 1 to indicate called from strip. Also copy slim IR archive member as unknown object. (copy_file): Set the BFD is_strip_input field of input bfd to 1 to indicate called from strip. (strip_main): Keep .gnu.debuglto_* sections unless all GCC LTO sections will be removed. ld/ PR binutils/33246 * testsuite/ld-plugin/lto-binutils.exp (run_pr33246_test): New. Run binutils/33246 tests with GCC and Clang. * testsuite/ld-plugin/pr33246.c: New file. 2025-08-06 GDB Administrator Automatic date update in version.in 2025-08-06 Alan Modra Remove bfd_check_format_lto Tidy changes to bfd_check_format_matches made by commit 9b854f169df9 which added a bfd_plugin_specified_p test and commit f752be8f916e which added an lto_sections_removed arg. Both of these changes are unnecessary if plugin_format is set to bfd_plugin_no before calling bfd_check_format. bfd_plugin_no will prevent the plugin object_p function from returning a match (and in the first case from a segfault when loading plugins while a plugin is running). The plugin object_p function already protected itself from recursive calls by setting bfd_plugin_no before loading a plugin, but commit 9b854f169df9 opened new bfds so they were unprotected. It isn't strictly necessary to test for bfd_plugin_no in bfd_check_format_matches but I kept the check to minimise functional changes. Close inspection of the patch will notice I've added an is_linker_input test too. That also isn't strictly necessary, I think, but the match_count test was for the linker. See commit 999d6dff80fa. PR 12291 PR 12430 PR 13298 PR 33198 bfd/ * format.c (bfd_check_format_lto): Revert to bfd_check_format. (bfd_check_format_matches_lto): Revert to bfd_check_format_matches. Correct comments. Manage both the lto_sections_removed and bfd_plugin_specified_p cases by testing for bfd_plugin_no. * plugin.c (bfd_plugin_get_symbols_in_object_only): Set plugin_format to bfd_plugin_no before checking new bfds. (try_load_plugin): Comment setting bfd_plugin_no. (bfd_plugin_specified_p): Delete. * plugin.h (bfd_plugin_specified_p): Delete. * bfd-in2.h: Regenerate. binutils/ * objcopy.c (copy_archive): Replace bfd_check_format_lto calls with bfd_check_format using plugin_format set to bfd_plugin_no. (check_format_object): New function. (copy_file): Use it. 2025-08-05 Tom Tromey Use '.rs' extension for Rust in gdb_simple_compile While trying out gccrs, I noticed that gdb_simple_compile does not use the ".rs" extension for Rust sources. This patch fixes the problem, which lets gccrs get a little further in the test suite. 2025-08-05 Tom Tromey Do not include cleanups.h from common-defs.h Most code doesn't use cleanups any more, so remove the include of cleanups.h from common-defs.h, and then only include that file where it is truly needed. Approved-By: Simon Marchi 2025-08-05 Jannik Hartung [UI/TUI] Add support for italic and underline ANSI escape sequences The ANSI escape sequence translation layer in TUI mode strips italic or underlined text modes silently. You cannot output text formatted like that using `TuiWindow.write` in Python at the moment. Parse the ANSI escape sequences for italic and underlined text into the `ui_file_style` structure and apply it to the TUI window when applying styles, similar to preserving the bold/dim state already. A script like this shows italic and underlined text correctly now. ```python import gdb class TestTUIWindow: _tui_window: gdb.TuiWindow def __init__(self, tui_window: gdb.TuiWindow) -> None: self._tui_window = tui_window self._tui_window.title = "colors test" def render(self) -> None: self._tui_window.write(""" \x1b[4mThis is underlined.\x1b[24m And normal text. \x1b[3mThis is italic.\x1b[23m And normal text. """, True) gdb.register_window_type("colortest", TestTUIWindow) ``` And launching it with ``` source the_above_script.py tui new-layout test colortest 1 cmd 1 layout test ``` Approved-By: Tom Tromey 2025-08-05 GDB Administrator Automatic date update in version.in 2025-08-04 Tom de Vries [gdb/testsuite] Fix gdb.base/style.exp on freebsd On x86_64-freebsd, with test-case gdb.base/style.exp I run into: ... (gdb) print $_colorsupport $1 = "monochrome" (gdb) FAIL: $exp: colorsupport_8color: color support is 8 color ... Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of TERM=ansi for bsd, getting us instead: ... (gdb) print $_colorsupport $1 = "monochrome,ansi_8color" (gdb) PASS: $exp: colorsupport_8color: color support is 8 color ... Tested on x86_64-freebsd. 2025-08-04 Tom Tromey Disabling hardware single step in gdbserver This patch gives gdbserver the ability to omit the 's' reply to 'vCont?'. This tells gdb that hardware single-step is definitely not supported, causing it to fall back to using software single-step. This is useful for testing the earlier change to maybe_software_singlestep. Approved-By: Andrew Burgess 2025-08-04 Tom Tromey Call target_can_do_single_step from maybe_software_singlestep When the PikeOS osabi sniffer was added, Pedro suggested that a target could omit stepping from its vCont? reply packet to tell gdb that software single-step must be used: https://sourceware.org/legacy-ml/gdb-patches/2018-09/msg00312.html This patch implements this idea by moving the call to target_can_do_single_step into maybe_software_singlestep. I've also removed some FIXME comments from gdbarch_components.py, and slightly updated the documentation for gdbarch_software_single_step. I think these comments are somewhat obsolete now that target_can_do_single_step exists -- the current approach isn't exactly what the comments intended, but on the other hand, it exists and works. Following review comments from Andrew, this version changes record-full to use maybe_software_singlestep, and then combines maybe_software_singlestep with insert_single_step_breakpoint. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440 2025-08-04 Jannik Hartung gdb: Add myself to gdb/MAINTAINERS 2025-08-04 Alan Modra windres PR 33244 testcase Make the windres testing both parse .rc files to binary and back again. It's not possible to compare against the original .rc file unfortunately, but at least this checks for the segfault fixed by commit 891d1654d731. PR 33244 * testsuite/binutils-all/windres/psql.rc: New file. * testsuite/binutils-all/windres/windres.exp: Do a -J res -O rc conversion too. Correct verbose message. 2025-08-04 GDB Administrator Automatic date update in version.in 2025-08-03 GDB Administrator Automatic date update in version.in 2025-08-02 Alan Modra Re: resbin: don't pass NULL as printf %s arg Commit c6c8d0b82175 went completely the wrong way. "key" needs to be NULL as that reads a different type of data. PR 33244 * resbin.c (get_version_header): Don't pass a NULL key on to toosmall. (bin_to_res_version): Restore NULL key cases. 2025-08-02 GDB Administrator Automatic date update in version.in 2025-08-01 Jan Vrany gdb/MAINTAINERS: Update my email address 2025-08-01 H.J. Lu gprof: Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh Both tst-gmon-gprof.sh and tst-gmon-gprof-l.sh generate gmon.out and process it. Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh to avoid the race condition. * testsuite/Makefile.am (tst-gmon-gprof-l.out): Depend on tst-gmon-gprof.out. * testsuite/Makefile.in: Regenerated. 2025-08-01 Andrew Burgess gdbserver: switch to using getopt_long for argument processing Update gdbserver to use getopt_long for argument processing. This turned out to be easier than I expected. Interesting parts of this patch are: I pass '+' as the OPTSTRING to getopt_long, this prevents getopt_long from reordering the contents of ARGV. This is needed so that things like this will work: gdbserver :54321 program --arg1 --arg2 Without the '+', getopt_long will reorder ARGV, moving '--arg1' and '--arg2' forward and handling them as arguments to gdbserver. Because of this (not reordering) and to maintain backward compatibility, we retain a special case to deal with '--attach' which can appear after the PORT, like this: gdbserver :54321 --attach PID I did consider adding a warning to this special case, informing the user that placing --attach after the PORT was deprecated, but in the end I didn't want to really change the behaviour as part of this commit, so I've left that as an optional change for the future. The getopt_long function supports two value passing forms, there is '--option=value', and also '--option value'. Traditionally, gdbserver only supports the first of these. To maintain this behaviour, after the call to getopt_long, I spot if '--option value' was used, and if so, modify the state so that it seems that no value was passed, and that 'value' is the next ARGV entry to be parsed. We could, possibly, remove this code in the future, but that would be a functional change, which is not something I want in this commit. Handling of "-" for stdio connection has now moved out of the argument processing loop as '-' isn't considered a valid option by getopt_long, this is an improvement as all PORT handling is now in one place. I've tried as much as possible to leave user visible functionality unchanged after this commit, and as far as I can tell from testing, nothing has changed. Approved-By: Tom Tromey 2025-08-01 Andrew Burgess gdbserver: exit with code 1 after missing packet name When using the command: $ gdbserver --disable-packet gdbserver lists all the packets that can be disabled, and then exits. I think that this output is a helpful error message that is printed when the user has forgotten to entry a packet name. We get similar output if we run the command: $ gdbserver --disable-packet=foo where gdbserver tells us that 'foo' is invalid, and then lists the packets that we can use. The difference is that, in the first case, gdbserver exits with a code of 0, and in the second, gdbserver exits with a code of 1. I think both these cases should exit with a code of 1. With the exception of '--help' and '--version', where we are asking gdbserver to print some message then exit (which are, and should exit with a code of 0), in all other cases where we do an early exit, I think this is an indication that the user has done something wrong (entered and invalid argument, or missed an argument value), and gdbserver should exit with a non-zero exit code to indicate this. This commit updates the exit code in the above case from 0 to 1. Approved-By: Tom Tromey 2025-08-01 Andrew Burgess gdbserver: convert locals to `bool` in captured_main Within gdbserver/server.cc, in captured_main, convert some locals to bool. Move the declaration of some locals into the body of the function. There should be no user visible changes after this commit. Approved-By: Tom Tromey 2025-08-01 Jan Beulich opcodes/x86: make i386_mnem[] static With the tables no longer being part of libopcodes (but rather being compiled directly into gas), this table doesn't need exposing anymore. The declaration cannot be avoided, though, as the first use of the array sits ahead of its definition (in i386-tbl.h). opcodes/riscv: make riscv_options[] const There's no reason to allow the array to be modifiable. In fact the compiler is able to infer this, placing the array in .data.rel.ro, but let's make it explicit. opcodes/ppc: make ppc_opts[] static const There's no reason to allow the array to be modifiable, nor for it to be globally visible. 2025-08-01 Jan Beulich opcodes/aarch64: convert print_sme_za_list()'s zan[] / zan_v[] Merge them into a single array of struct type. There's further no reason to have the compiler materialize such objects on the stack. And there's also no reason to allow the array(s) to be modifiable. Finally, given how short the strings are, there's little point using more space to store pointers to them (on 64-bit hosts; the situation is a little better on 32-bit ones). While there also correct indentation in adjacent code, and avoid open- coding ARRAY_SIZE(). 2025-08-01 Jan Beulich opcodes/aarch64: make aarch64_opnd_qualifiers[] static const There's no reason to allow the array to be modifiable, nor for it to be globally visible. opcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static const There's no reason to have the compiler materialize such an object onto the stack. And there's also no reason to allow the array to be modifiable. gas: check section size against entry size If a section has a non-zero entry size, its total size would generally better be a multiple of the entry size. Warn if that's not the case. 2025-08-01 Luis Machado Update my e-mail Update some entries in the gdb/MAINTAINERS file. 2025-08-01 Simon Marchi gdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset) This patch started as a fix for PR 29518 ("GDB doesn't handle DW_FORM_ref_addr DIE references correctly with .debug_types sections") [1], but the scope has expanded a bit to fix the problem more generally, after I spotted a few issues related to the order of all_units. The first version of this patch is here [2]. PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously find a type unit. The obvious problem is that the dwarf2_find_containing_comp_unit function searches the whole all_units vector (containing both comp and type units), when really it should just search the compilation units. A simple solution would be to make it search the all_comp_units view (which is removed in a patch earlier in this series). I then realized that in DWARF 5, since type units are in .debug_info (versus .debug_types in DWARF 4), type units can be interleaved with comp type in the all_units vector. That would make the all_comp_units and all_type_units views erroneous, and dwarf2_find_containing_comp_unit could still return something wrong. In v1, I added a sort in finalize_all_units to make sure all_units is in the order that dwarf2_find_containing_comp_unit expects: - comp units from the main file - type units from the main file - comp units from the dwz file - type units from the dwz file (not actually supported, see PR 30838) Another problem I spotted is that the .gdb_index reader creates units in this order: - comp units from .gdb_index from main file - comp units from .gdb_index from dwz file - type units from .gdb_index from main file This isn't the same order as above, so it would need the same sort step. Finally, I'm not exactly sure if and when it happens, but it looks like lookup_signatured_type can be called at a later time (after the initial scan and creation of dwarf2_per_cu object creation), when expanding a symtab. And that could lead to the creation of a new type unit (see function add_type_unit), which would place the new type unit at the end of the all_units vector, possibly screwing up the previous order. To handle all this in a nice and generic way, Tom Tromey proposed to change the all_units order, so that units are sorted by section, then section offset. This is what this patch implements. The sorting is done in finalize_all_units. This works well, because when looking up a unit by section offset, the caller knows which section the unit is in. Passing down a (section, section offset) tuple makes it clear and unambiguous what unit the caller is referring to. It should help eliminate some bugs where the callee used the section offset in the wrong section. Passing down the section along with the section offset replaces the "is_dwz" flag passed to dwarf2_find_containing_comp_unit and a bunch of other functions in a more general way. dwarf2_find_containing_comp_unit can now legitimately find and return type units even though it should be needed (type units are typically referred to by signature). But I don't think there is harm for this function to be more generic than needed. I therefore I renamed it to dwarf2_find_containing_unit. The sort criterion for "section" can be anything, as long as we use the same for sorting and searching. In this patch, I use the pointer to dwarf2_section_info, because it's easy. The downside is that the actual order depends on what the memory allocator decided to return, so could change from run to run, or machine to machine. Later, I might change it so that sections are ordered based on their properties, making the order stable across the board. This logic is encapsulated in the all_units_less_than function, so it's easy to change. The .debug_names reader can no longer rely on the order of the all_units vector for its checks, since all_units won't be the same order as found in the .debug_names lists. In fact, even before, it wasn't: this check assumed that .debug_info had all CUs before TUs, and that the index listed them in the exact same order. When I build a file with gcc and "-gdwarf-5 -fdebug-types-section", type units appear first in .debug_info. This caused GDB to reject a .debug_names index that is had produced: $ GDB="./gdb -nx -q --data-directory=data-directory" /home/smarchi/src/binutils-gdb/gdb/contrib/gdb-add-index.sh -dwarf-5 hello.so $ ./gdb -nx -q --data-directory=data-directory hello.so Reading symbols from hello.so... ⚠️ warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names. To make it work, add a new dwarf2_find_unit function that allows looking up a unit by start address (unlike dwarf2_find_containing_unit, which can find by any containing address), and make the .debug_names reader use it. It might make the load time of .debug_names a bit longer (the build and check step is now going to be O(n*log(n)) instead of O(n) where n is the number of units, or something like that), but I think it's important to be correct here. This patch adds a test (gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to replicate the problem as shown by PR 29518. gdb.base/varval.exp needs a small change, because an error message changes (for the better, I think) gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no longer rejects a .debug_names index which lists CUs in a different order than .debug_info. Given the change I did to the .debug_names reader, explained above, I don't think this is a problem anymore (GDB can accept an index like that). I also don't think that DWARF 5 mandates that CUs are in ascending order. Delete this test. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29518 [2] https://inbox.sourceware.org/gdb-patches/20250218193443.118139-1-simon.marchi@efficios.com/ Change-Id: I45f982d824d3842ac1eb73f8cce721a0a24b5faa Approved-By: Tom Tromey 2025-08-01 Simon Marchi gdb/dwarf: sort units when writing index The order of all_units can't be relied on when writing the CU and TU lists to .gdb_index or .debug_names. Both the .gdb_index and .debug_names writers expect that all_units contains comp units followed by type units. As of this commit, when reading a DWARF 5 .debug_info, the all_units vector is ordered based on the order the units appear in .debug_info, where type units can be interleaved with comp units. It probably worked fine with DWARF 4, where type units were in a section of their own (.debug_types). They were read after comp units, and therefore after them in the all_units vector. Change the writers to use a common function that splits the units in two lists (comp units and type units). Sort both lists by section offset. This is more than required, but it should help produce a stable and predictable output. Change-Id: I5a22e2e354145e3d6b5b2822dc2a3af2f9d6bb76 Approved-By: Tom Tromey 2025-08-01 Simon Marchi gdb/dwarf: make .gdb_index reader use its own list of units The .gdb_index reader currently uses per_bfd::all_units when translating a numerical index (as found in an index entry) to a dwarf2_per_cu. The order of per_bfd::all_units is going to change in a subsequent patch, so the indices as found in the index won't map to the right unit in all_units. Change the .gdb_index reader to maintain its own vector, with the units in the same order as found in the .gdb_index header. This is similar to what the .debug_names reader does. But unlike .debug_names, .gdb_index treats the CUs and TUs as a single list, as far as the numerical indices are concerned, so we only need a single list here (versus two for .debug_names). Change-Id: I235e9b99bf02fc160dfcdaa610c9aca471f298a7 Approved-By: Tom Tromey 2025-08-01 Simon Marchi gdb/dwarf: move index unit vectors to .debug_names reader and use them The all_comp_units_index_cus and all_comp_units_index_tus vectors contain the CU and TU lists as found in the .debug_names list. 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, 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_unit method, with the assumption that dwarf2_per_bfd::all_units has comp units before type units. This is not the case: the .debug_names reader creates the units in dwarf2_per_bfd::all_units using the create_all_units function, which creates the units in the order found in .debug_info, where type units can be interleaved with comp units. Since those vectors are specific to the .debug_names reader, move them to the mapped_debug_names_reader struct. Then, update the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to actually use them. Change-Id: Ie7db81f4442f634ac6d02280a60c6c671bcd22a5 Approved-By: Tom Tromey 2025-08-01 Simon Marchi gdb/dwarf: remove all_{comp,type}_units views In DWARF 5, type units appear in the .debug_info section, interleaved with comp units, and the order in all_units reflects that. The all_comp_units and all_type_units views are wrong in that case (all_comp_units contains some type units, and vice-versa). It would be possible to manually sort all_units to ensure that type units follow comp units, but this series takes the approach of sorting the units by section and section offset. Remove those views, and replace their uses with num_comp_units and num_type_units. It appears that the views were only used to know the number of each kind. The finalize_all_units function is now empty, but I am keeping it because a subsequent patch adds a call to std::sort in there to sort the all_units vector. Change-Id: I42a65b6f1b6192957b55cea0e2eaff097e13a33b Approved-By: Tom Tromey 2025-08-01 Simon Marchi gdb/dwarf: track compilation and type unit count A subsequent commit will remove the all_comp_units and all_type_units array views, since it's not possible to assume that that all_units vector is segmented between comp and type units. Some callers still need to know the number of each kind, so track that separately. Change-Id: I712fbdfbf10b333c431b688b881cc0987e74f688 Approved-By: Tom Tromey 2025-08-01 Alan Modra ia64 assembler warning breaks ld tests The "Warning: Explicit stops are ignored in auto mode" results in failures of a number of run_ld_link_tests because the compiler is run using -S and then the resulting .s file assembled without suppplying -x to gas. Fix that problem by adding -x to ASFLAGS for ia64, and tweak the binutils link-order test since the source is used in a ld test too. ld/ * testsuite/config/default.exp: Set ASFLAGS to "-x" for ia64. Remove unnecessary "global". binutils/ * testsuite/binutils-all/link-order.s: Provide explicit stop. * testsuite/binutils-all/objcopy.exp: Pass "-x" when building link-order test for ia64. 2025-08-01 Alan Modra ld-elf/shared libpr23161c and pr23161c tests If I understand these tests correctly it is to ensure that _end, _edata and __bss_start are not made dynamic. The dynamic reloc tests are not really necessary. (We dropped them from pr23161a and pr23161b tests a while ago without removing the -r from readelf invocation.) Dropping the reloc tests allows them to run for more targets. * testsuite/ld-elf/pr23161c.rd: Rewrite. * testsuite/ld-elf/pr23161d.rd: Delete. * testsuite/ld-elf/shared.exp (pr23161a, pr23161b): Remove -r from readelf check. (libpr23161c.so, pr23161c): Likewise, and check expected readelf output using the new pr23161c.rd. 2025-08-01 GDB Administrator Automatic date update in version.in 2025-07-31 Tom Tromey Don't nest double quotes in tuiterm.exp I found a line in tuiterm.exp that causes Emacs paren-matching to go awry. This patch fixes the problem by changing some apparent nested double quotes (which I think isn't really possible in Tcl but this seems to be the intent) to be more correct; which fixes the Emacs issue as well. Approved-By: Tom de Vries 2025-07-31 Sam James zlib: import zlib-1.3.1 [PR32933] As done just now on the GCC side in r16-2677-g7a79219383c83c, import zlib-1.3.1. 2025-07-31 H.J. Lu strip: Treat "default" output_target as unspecified Treat output target as unspecified if it is set to "default". binutils/ PR binutils/33230 * objcopy.c (copy_file): Treat "default" output_target as unspecified. binutils/testsuite/ PR binutils/33230 * binutils-all/x86-64/x86-64.exp (run_pr33230_test): New. Run binutils/33230 tests with readelf if supported. 2025-07-31 Tom de Vries [gdb/testsuite] Fix gdb.gdb/python-helper.exp with gdb built with -flto With a gdb build with gcc 7.5.0 and "-O2 -flto=auto -g", I run into: ... (outer-gdb) PASS: gdb.gdb/python-helper.exp: print varobj_table print inferior_list $5 = {m_front = 0x212e830, m_back = 0x2e39aa0} (outer-gdb) FAIL: gdb.gdb/python-helper.exp: print inferior_list ... The problem is that the type of inferior_list: ... (outer-gdb) what inferior_list^M type = intrusive_list^M (outer-gdb) ... is not descriptive enough to trigger the pretty pretter. Note that with a gdb build with -O0, we'd get instead: ... (outer-gdb) what inferior_list^M type = intrusive_list > (outer-gdb) ... Fix this by detecting this situation, and declaring the test unsupported. Tested on x86_64-linux. 2025-07-31 H.J. Lu strip: Don't check target_defaulted in input BFD The target_defaulted field in BFD is set to true if the target isn't specified. After commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d Author: H.J. Lu Date: Sun May 4 05:12:46 2025 +0800 strip: Add GCC LTO IR support the target is set to "plugin" if BFD supports plugin when the target isn't specified nor default. Update strip to check the input target, instead of the target_defaulted field in input BFD. PR binutils/33230 * objcopy.c (copy_object): Add a bool argument, target_defaulted, to indicate if the input target isn't specified nor default. Check it instead of ibfd->target_defaulted. (copy_archive): Add a bool argument, target_defaulted, and pass it to copy_object. (copy_file): Set target_defaulted to true if the input target isn't specified and pass it to copy_archive and copy_object. * testsuite/binutils-all/x86-64/pr33230.obj.bz2: New file. * testsuite/binutils-all/x86-64/x86-64.exp: Run PR binutils/33230 tests. 2025-07-31 GDB Administrator Automatic date update in version.in 2025-07-30 Alan Modra PR 33229 nds32 gas segfaults on gcc output Commit 1ac26e9f7ac2 replaced ISSPACE with is_whitespace, but the former returns true on EOL while the latter does not. Sprinkle is_end_of_stmt tests to fix this bug. The same segfault can be triggered by a ".relax_hint" with no following instructions. Fix that too. * config/tc-nds32.c (nds32_lookup_pseudo_opcode): Use is_end_of_stmt along with is_whitespace. (nds32_relax_relocs, nds32_relax_hint, nds32_flag), (ict_model: Likewise. (nds32_elf_append_relax_relocs): Return on no opcode. * testsuite/gas/nds32/nds32.exp: Find .d files automatically. * testsuite/gas/nds32/pr33229.d, * testsuite/gas/nds32/pr33229.s: New test. 2025-07-30 GDB Administrator Automatic date update in version.in 2025-07-29 Alan Modra ppc _bfd_clear_contents ppc32 isn't susceptible to the PR33223 segfault, but could hit a _bfd_clear_contents segfault with a carefully crafted invalid object. * elf32-ppc.c (ARRAY_SIZE): Define. (ppc_elf_howto_init): Use ARRAY_SIZE. (ppc_elf_reloc_name_lookup): Likewise. (ppc_elf_info_to_howto): Likewise, and consolidate error handling. (ppc_elf_check_relocs): Guard against segfaults caused by a NULL howto passed to _bfd_clear_contents. Use ARRAY_SIZE. 2025-07-29 Alan Modra PR 33223 ppc64: segfault on unknown relocation Bounds check accesses to ppc64_elf_howto_table and don't dereference a NULL howto. I think this catches all cases where that might happen. PR 33223 bfd/ * elf64-ppc.c (ppc64_elf_info_to_howto): Consolidate error handling. (ppc64_elf_check_relocs): Tidy error messages. (ppc64_elf_relocate_section): Don't segfault when attempting to report an unsupported relocation. Don't pass a NULL howto to _bfd_clear_contents. ld/ * testsuite/ld-powerpc/elfv2-2so.d: Adjust to suit error message change. 2025-07-29 Rainer Orth ld: testsuite: Enable ld-elfweak tests on Solaris/x86 The ld-elfweak tests are currently only enabled on Solaris/SPARC for no apparent reason. Enabling them on Solaris in general lets them all PASS on both amd64-pc-solaris2.11 and i386-pc-solaris2.11. 2025-07-25 Rainer Orth ld: * testsuite/ld-elfweak/elfweak.exp: Enable on *-*-solaris2* rather than sparc*-*-solaris2* only. 2025-07-29 GDB Administrator Automatic date update in version.in 2025-07-28 Rainer Orth ld: testsuite: Fix "PR ld/28138 (build only)" on Solaris The FAIL: PR ld/28138 (build only) test FAILs on Solaris: ld/tmpdir/ld/collect-ld: plugin framework: out of file descriptors. Try using fewer objects/archives ld/tmpdir/ld/collect-ld: cannot find -lgcc: Too many open files [...] I found that the test PASSes when using ulimit -n 21 instead of the current 20. Looking with strace/truss, on Linux/i686 the following files are opened: 301543 openat(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 5 301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 5 301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 6 301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 6 301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 7 301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 7 301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 8 301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 8 301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 9 301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 9 301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 10 301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 10 301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 11 301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 11 301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 12 301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 12 301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 13 301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 13 301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 3 301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 3 301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 4 301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 5 while on Solaris/i386 there are a couple more: 27726: openat64(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4 27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 5 27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 6 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 6 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 7 27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 7 27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 8 27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 8 27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 9 27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 9 27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 10 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 10 27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 11 27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 11 27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 12 27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 12 27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 13 27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 13 27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 14 27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 14 27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 15 27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 15 27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 16 27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 16 27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 17 27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 17 27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 18 27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 18 27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 19 27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) = 19 27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) Err#24 EMFILE While it seems weird that the same files are opened twice for reading, it's no wonder that 20 fds aren't enough on Solaris. To avoid this, I've raised the limit to 25, hoping that this will be enough on more targets. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. 2025-07-25 Rainer Orth ld: * testsuite/ld-plugin/lto.exp (PR ld/28138 test): Raise fd limit to 25. 2025-07-28 Rainer Orth Add forgotten ChangeLog entry for commit 7c1c13e896c76879bcf3fb29332e0a59918bc9e0. 2025-07-28 Rainer Orth ld: testsuite: Skip "Run with libpr19553c.so" test on Solaris The FAIL: Run with libpr19553c.so test FAILs on Solaris (32 and 64-bit, sparc and x86): Running: tmpdir/pr19553c > tmpdir/pr19553c.out diff tmpdir/pr19553c.out /vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elf/pr19553c.out 1c1 < pr19553b --- > pr19553c child process exited abnormally The test uses .symver, resulting in versioned symbols which the Solaris ld.so.1 doesn't support and never will. Running it with LD_DEBUG=all shows 26493: 1: symbol=foo; lookup in file=tmpdir/pr19553c [ ELF ] 26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553c.so [ ELF ] 26493: 1: symbol=foo; skipping entry in file=tmpdir/libpr19553c.so, index[7], version=FOO, due to GNU version hidden bit 26493: 1: symbol=foo; continuing lookup in file=tmpdir/libpr19553c.so [ ELF ] 26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553b.so [ ELF ] 26493: 1: binding file=tmpdir/pr19553c to file=tmpdir/libpr19553b.so: symbol 'foo' so this patch skips the test. 2025-07-25 Rainer Orth ld: * testsuite/ld-elf/indirect.exp (Run with libpr19553c.so): Skip on *-*-solaris2*. 2025-07-28 Tom Tromey Avoid timeouts with gnat-llvm in gdb.ada/operator_call.exp While working on gnat-llvm, gdb.ada/operator_call.exp has many timeouts. This happens because gnat-llvm's DWARF output is still incomplete, and so gdb emits an unexpected error in this test. This patch improves the test by having it recognize this output and issue a failure rather than a timeout. This greatly speeds up testing. 2025-07-28 Nick Alcock libctf: link: rejig lazy opening to not need weak symbols The ctf_link_add_ctf API function has a 'lazy opening' feature whereby, if you pass in the file but not a CTF archive, the archive is opened as late as possible during links. This is valuable mostly in cu-mapped links (a feature not accessible via GNU ld), where it ensures that, rather than eventually needing memory for the original link inputs, the smushed-together cu-mapped intermediate outputs, *and* the final output, we only need enough memory for the smushed- together outputs, the final output, and one input, since the inputs can be closed immediately after they are smushed together. (In GNU ld, the feature is useless because it loads all sections into memory anyway.) The lazy-opening feature uses libctf's ctf_open function, which uses BFD: so it is not available in libctf-nobfd -- except that I thought I had a cunning trick, and used a weak symbol so that if you linked libctf-nobfd into your program and then also linked in bfd, the feature stayed enabled. This is silly -- if your program is licensed such that you can link in BFD, you can just link in libctf.so and not bother with libctf-nobfd.so in the first place. Worse, the weak symbol usage broke MacOS builds, since MacOS's system compiler uses a different means of introducing weak symbols. We could test for and use it, but this is the only place in libctf to use weak symbols at all, and the feature of lazy-opening with libctf-nobfd is so marginal we might as well drop it: it's almost certain there are zero users, certainly fewer users than users of MacOS with the system compiler. While we're at it, simplify things by deleting the never-implemented feature (not exposed in the API) to allow linking together raw buffers of CTF data. If we need it we can bring it back, but all it's doing right now is complicating the code to no end at all. libctf/ PR libctf/33194 * ctf-link.c (ctf_open): Delete weak pragma. (ctf_link_add): Fuse with... (ctf_link_add_ctf): ... this function. Drop BUF, N args and corresponding unimplemented feature warnings. Only check NOBFD to see whether lazy loading is available, not PIC as well. (ctf_link_lazy_open): Likewise. 2025-07-28 Matthieu Longo gas: add missing header guard in tc-.h files This patch adds missing header guards in some of the tc-.h, and merely comments on the corresponding #endif for others. The patch does not aim at being exhaustive, it only touched the files relevant for [1]. [1]: https://inbox.sourceware.org/binutils/20250711112913.2453285-1-matthieu.longo@arm.com/ 2025-07-28 GDB Administrator Automatic date update in version.in 2025-07-27 Nick Clifton Update release documentation following 2.45 release 2025-07-27 GDB Administrator Automatic date update in version.in 2025-07-26 Indu Bhagat 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-26 GDB Administrator Automatic date update in version.in 2025-07-25 Alan Modra PR 33214 sparc LDM/STM/LDMA/STMA etc. FAIL on Solaris/SPARC Delete code in compare_opcodes preferencing 1+i over i+1 and 1,i over i,1. Instead simply make the sort stable, by keeping the original table order. 2025-07-25 Tom de Vries [gdb/tui] Fix shell command terminal settings In bash I have the following terminal settings: ... $ stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 ... and then in gdb using the shell command likewise: ... (gdb) shell stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 (gdb) ... and likewise using a shell session: ... (gdb) shell $ stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 $ ... But in TUI, we get different settings (removed runaway indentation for readability): ... (gdb) shell sttyspeed 38400 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel iutf8 -onlcr -icanon -echo (gdb) ... and consequently the shell is not really usable. This is PR tui/18215. The easiest way to fix this is to just temporarily leave TUI while in the shell, leaving the output of the commands in CLI mode, but that's a bit confusing. Fix this (as suggested in the PR) by restoring the initial terminal settings while in the shell command, such that also in TUI we have: ... (gdb) shell sttyspeed 38400 baud; line = 0; -brkint -imaxbel iutf8 (gdb) ... Tested on x86_64-linux. Reported-By: Doug Evans Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18215 2025-07-25 Pedro Alves gdb: Convert gdb/mingw-hdep.c to INIT_GDB_FILE I noticed that my MinGW GDB did not have the "maint set console-translation-mode" command, even though the code to register it is in gdb/mingw-hdep.c. The problem is that gdb/mingw-hdep.c is not using INIT_GDB_FILE. This fixes it. Change-Id: I3aa305c517e100d4733b391a110a1b20b89fdb7f 2025-07-25 Guinevere Larsen gdb: use the location_completer for the list command The "location_completer" function has been available for a long time, but it was seemingly never used as the completer for the list function. A quick check through git history shows that a similar completer was available for the "edit" command but wasn't added to "list" with no reasoning for it. I think "list" should use the location_completer, as it is more aware of the locspec grammar. Approved-By: Tom Tromey 2025-07-25 Simon Marchi gdb: fix copyright year in svr4-tls-tdep.c Change-Id: Ia03b286d9544a209197e58e59e752dc3d2715359 2025-07-25 Simon Marchi gdb: fix copyright year in solib-frv.h My mistake, I forgot to update this when merging my patch series. Change-Id: I67691c962d91221bd9a684febd7296b4b9b5999f 2025-07-25 Simon Marchi gdb/dwarf: apply DW_AT_bit_offset when DW_AT_data_member_location is constant block Since commit 420d030e88 ("Handle field with dynamic bit offset"), I see: $ make check TESTS="gdb.trace/unavailable-dwarf-piece.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d y FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d z The first FAIL is: p/d x $4 = {a = 0, b = , c = , d = , e = , f = , g = , h = , i = , j = 0} (gdb) FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x When we should see: p/d x $4 = {a = 0, b = , c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0} (gdb) PASS: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x The structure we print is: 0x0000004f: DW_TAG_structure_type DW_AT_name [DW_FORM_string] ("t") DW_AT_byte_size [DW_FORM_sdata] (3) DW_AT_decl_file [DW_FORM_udata] (0) DW_AT_decl_line [DW_FORM_udata] (1) 0x00000055: DW_TAG_member DW_AT_name [DW_FORM_string] ("a") DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char") DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x0) 0x0000005f: DW_TAG_member DW_AT_name [DW_FORM_string] ("b") DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char") DW_AT_byte_size [DW_FORM_sdata] (1) DW_AT_bit_size [DW_FORM_sdata] (1) DW_AT_bit_offset [DW_FORM_sdata] (7) DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x1) ... The particularity of field "b" (and the following ones, not shown here) is that they have: - a DW_AT_data_member_location of expression form, but that GDB reduces to a constant - a DW_AT_bit_offset What I think happens is that the code path taken in this particular scenario never ends up using the DW_AT_bit_offset value. Fix it by calling apply_bit_offset_to_field, like what is done when data_member_location_attr is using a constant form. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33136 Change-Id: I18e838e6c56a548495d3af332aeff3051188eaa9 Approved-By: Tom Tromey 2025-07-25 Simon Marchi gdb/dwarf: rename some variables in handle_member_location For legibility, use more specific names for attribute variables and don't reuse them for different attributes. Change-Id: I98d8bb32fc64b5f6357fbc88f6fe93f2ddc8ef7c Approved-By: Tom Tromey 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 Indu Bhagat 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/ PR gas/33175 * dw2gencfi.c (cfi_finish): Check state of flag_gen_sframe to determine whether any SFrame section is generated. * as.h (enum gen_sframe_option): New definition. * as.c (parse_args): Keep track of whether the flag is explicitly enabled or disabled gas/testsuite/ PR gas/33175 * gas/cfi-sframe/cfi-sframe-common-1.d: Remove redundant --gsframe. * gas/cfi-sframe/cfi-sframe.exp: Add new test. * gas/cfi-sframe/cfi-sframe-common-1c.d: New test. No SFrame section if explicit --gsframe=no. * gas/cfi-sframe/cfi-sframe-common-1c.s: New test. 2025-07-25 Indu Bhagat 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-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. 2025-07-25 Alan Modra PR 33210 NULL pointer arithmetic in coffcode.h Fix ubsan "runtime error: applying zero offset to null pointer". 2025-07-25 GDB Administrator Automatic date update in version.in 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". 2025-07-24 Tom de Vries [gdb/testsuite] Add Term::get_string_with_attrs in tuiterm While reading a gdb.log for test-case gdb.tui/main-2.exp, I noticed that this line was somewhat hard to read: ... screen line 6: '|B+> 21 return 0; |' ... because of the border attributes. Then I realized that the test-case is only interested in the text between the borders, so I added a proc Term::get_string_with_attrs that allows me to drop the borders, getting us instead: ... screen line 6: 'B+> 21 return 0; ' ... Tested on aarch64-linux. 2025-07-24 Tom de Vries [gdb/testsuite] Use TERM=ansiw in tuiterm for bsd TERM=ansi is different on freebsd and linux. Consequently, many TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) fail on freebsd. One of the problems is that send_gdb "\r\n" is needed instead of send_gdb "\n". This is because gdb_send "layout regs\n" translates to "layout regs", which evidently missing the carriage return part. While we can work around this, there are other problems. There is no color support, and the cursor keys fail to scroll the source window. So I went looking for an alternative to TERM=ansi on freebsd, and came across TERM=ansiw. Using this didn't work out of the box, but with the fixes in this series it now does. I also briefly looked at TERM=ansis, which is interesting because it's available on both linux and freebsd, but ansiw is a better choice for now. I've filed PR33179 to document what I learned, with the aim to eventually follow up and address two test-case failures with TERM=ansis on linux. Tested on x86_64-freebsd. 2025-07-24 Tom de Vries [gdb/testsuite] Log on return in Term::_log_cur Proc Term::_log_cur logs the cursor update of code in its body argument: ... proc _ctl_0x08 {} { _log_cur "Backspace" { variable _cur_col if {$_cur_col > 0} { incr _cur_col -1 } } } ... giving us for instance: ... +++ Backspace, cursor: (2, 0) -> (2, 0) ... But if we rewrite the code to use a return: ... if { $_cur_col == 0 } { return } incr _cur_col -1 ... and the return is triggered, the log message disappears. Fix this by wrapping the "uplevel $body" in a catch: ... - uplevel $body + set code [catch {uplevel $body} result] ... Tested on aarch64-linux. 2025-07-24 GDB Administrator Automatic date update in version.in 2025-07-24 Pietro Monteiro gold: configury: fix obsolete macros Running `autoreconf -vf -Wall' in the gold directory shows errors about the use of obsolete macros. This patch fix the issues with macros used directly by configure.ac. However, it doesn't fix all warnings. There are autoconf warnings about macros from files in config and one automake warning about a target being shadowed. It cuts a lot of the noise down and makes an upgrade to autoconf 2.71+ easier. https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html#index-AC_005fOUTPUT-2133 gold/ChangeLog: * aclocal.m4: Regenerate. * configure: Regenerate. * configure.ac: Replace AM_CONFIG_HEADER by AC_CONFIG_HEADERS. Replace AC_OUTPUT(file list) by AC_CONFIG_FILES([file list])\nAC_OUTPUT. Approved-by: Alan Modra 2025-07-23 Tom de Vries [gdb/testsuite] Fix Term::_csi_m with no args When calling Term::_csi_m with no args, default behaviour needs to be applied, which is equivalent to "Term::_csi_m 0" [1]. However, while "Term::_csi_m 0" works, as well as 'Term::_csi_m ""', calling Term::_csi_m with no args has no effect. Fix this by implementing the default behaviour in Term::_csi_m. Tested on aarch64-linux. Approved-By: Tom Tromey [1] https://vt100.net/docs/vt510-rm/SGR.html 2025-07-23 Tom de Vries [gdb/testsuite] Handle auto_left_margin in tuiterm The terminal capability bw (aka as auto_left_margin) controls whether a backspace at the start of a line wraps to the last column of the previous line. For tuiterm, we use TERM=ansi, and on linux at least that capability is off. Consequently the current implementation of Term::_ctl_0x08 doesn't wrap. Add this capability in Term::_ctl_0x08, and add a unit test. Tested on aarch64-linux. Approved-By: Tom Tromey 2025-07-23 Simon Marchi gdbserver: use reference in range for loop The armhf buildbot fails to build GDB, with: ../../binutils-gdb/gdbserver/server.cc: In function ‘void handle_general_set(char*)’: ../../binutils-gdb/gdbserver/server.cc:1021:23: error: loop variable ‘’ creates a copy from type ‘const std::pair >’ [-Werror=range-loop-construct] 1021 | for (const auto [thread, options] : set_options) | ^~~~~~~~~~~~~~~~~ ../../binutils-gdb/gdbserver/server.cc:1021:23: note: use reference type to prevent copying 1021 | for (const auto [thread, options] : set_options) | ^~~~~~~~~~~~~~~~~ | & I did not use a reference on purpose, because the pair is very small. I don't see the problem when building on amd64, I presume it is because the pair is considered too big to copy on a 32-bit architecture, but not on a 64-bit architecture. In any case, fix it by adding a reference. Change-Id: I8e95235d6e53f032361950cf6e0c7d46b082f951 2025-07-23 Tom de Vries [gdb/testsuite] Handle Horizontal Position Absolute in tuiterm I ran the tui testsuite on freebsd with TERM=ansiw, and investigated the first failure, in test-case gdb.tui/tui-init-source.exp. The problem turned out to be the lack of handling a Horizontal Position Absolute [1] sequence "^[[80`" in tuiterm. Add Term::_csi_`, forwarding to Term::_csi_G which handles Cursor Horizontal Absolute [2]. Tested on x86_64-linux. Approved-By: Tom Tromey [1] https://vt100.net/docs/vt510-rm/HPA.html [2] https://vt100.net/docs/vt510-rm/CHA.html 2025-07-23 Tom de Vries [gdb/testsuite] Fix Cursor Horizontal Absolute clipping I looked at the tuiterm implementation of Cursor Horizontal Absolute: ... proc _csi_G {args} { set arg [_default [lindex $args 0] 1] _log_cur "Cursor Horizontal Absolute ($arg)" { variable _cur_col variable _cols set _cur_col [expr {min ($arg - 1, $_cols)}] } } ... and noticed a problem with the clipping behavior. If we have say $_cols == 80, and we do _csi_G 81 we get $_cur_col == 80, while $_cur_col is zero-based and should be in the 0..79 range. Fix this by using: ... set _cur_col [expr {min ($arg, $_cols)} - 1] ... which gets us $_cur_col == 79. Add two boundary tests to gdb.tui/tuiterm.exp. Tested on x86_64-linux. Approved-By: Tom Tromey 2025-07-23 Simon Marchi gdb, gdbserver: use structured bindings in a few places I wanted to change one of these, so I searched for more similar instances, while at it. I think this looks a bit tidier, over unpacking the pairs by hand. Change-Id: Ife4b678f7a6aed01803434197c564d2ab93532a7 Approved-By: Tom Tromey 2025-07-23 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. 2025-07-23 Nick Alcock libctf: don't run tests requiring deduplicating linker unless one is in use Before now, we were relying on gcc -B to repoint GCC at our freshly-built linker, and assuming we could use this to run tests that do linker dedup. This is, alas, not reliable (building --with-ld=/an/absolute/path bypasses -B searches for the linker), and we would like the libctf tests in particular to not fail if the compiler uses a linker that cannot deduplicate (simply skipping such tests). Add a new testsuite function that tries to link one of the lookup tests' testcases (which is known to produce conflicting types, i.e. a dict with per-translation-unit children) and then does an objdump and greps it for signs of the per-translation-unit children. If there are none, the linker probably just concatenated the sections: i.e., it is not a linker that can deduplicate CTF. libctf/ PR libctf/33162 * testsuite/config/default.exp (objdump): Introduce. (OBJDUMPFLAGS): Likewise. * testsuite/lib/ctf-lib.exp (check_ctf_linker_dedup): New. * testsuite/libctf-lookup/lookup.exp: Use it. * testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise. * testsuite/libctf-regression/regression.exp: Likewise. 2025-07-23 Rainer Orth libctf: exclude always-emitted Solaris symbols from the symtypetab If we're skipping _BEGIN_ and _END_ we should certainly skip all the other ABI-required always-emitted symbols given in ld/emultempl/solaris2*em as well. (This fixes a couple of diagnostics tests, but that's just because the tests are quite sensitive to CTF section sizes, and introducing any symtypetab entries for those tests perturbs those.) Some of these are usually STT_NOTYPE, but not always: if programs already emitted the symbol they might end up with any type, in particular STT_OBJECT, and appear in the symtypetabs. [nca: added commit log, added more symbols] libctf/ PR libctf/33162 * ctf-serialize.c (ctf_symtab_skippable): Skip more always-emitted Solaris symbols. 2025-07-23 Nick Alcock libctf: get libctf-nobfd.ver from the right place with Solaris ld We generate de-commented version scripts for Solaris ld (whose -z gnu-version-script linker option does not support comments), but after we switched to generating libctf-nobfd.ver itself, we failed to adjust this code to pick it up from the new location. libctf/ PR libctf/33161 * configure.ac: Fix libctf-nobfd.ver path on Solaris. * configure: Regenerated. 2025-07-23 Rainer Orth libctf: do not use mmap on Solaris 11 Writable mmaps and read are inconsistent with each other on Solaris 11.4, which breaks archive writing. Simply assert that Solaris 2.11 doesn't have mmap, falling back to read(): the archive format is being bumped shortly, to one with completely different writeout code, so this workaround need not stay for long. [nca: added commit log] libctf/ PR libctf/29292 * configure.ac: Turn off mmap on Solaris 2.11. * configure: Regenerated. 2025-07-23 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. 2025-07-23 GDB Administrator Automatic date update in version.in 2025-07-22 Tom de Vries [gdb/testsuite] Modernize gdb.base/command-line-input.exp Modernize test-case gdb.base/command-line-input.exp using clean_restart, multi_line and string_to_regexp. Tested on x86_64-linux. Approved-By: Andrew Burgess 2025-07-22 Tom de Vries [gdb/cli] Clear line buffer on ^C Gdb has the ability to gather input over several lines [1], for instance this: ... (gdb) print 1 $1 = 1 (gdb) ... can also be typed as: ... (gdb) print\ 1 $2 = 1 (gdb) ... Furthermore, if we type a command but change our mind, we can abort using ^C and start over using a fresh gdb prompt [2]: ... (gdb) print 1❌️ Quit (gdb) echo 1\n 1 (gdb) ... Now say we type a multi-line command but abort it, we get: ... (gdb) print\ 1❌️ Quit (gdb) echo 1\n ❌️ Undefined command: "printecho". Try "help". (gdb) ... Using "set trace-commands on", we can see what happened: ... +printecho 1\n .. Gdb has prepended the first line of the cancelled multi-line command to the following command. Fix this by clearing current_ui->line_buffer on catching a gdb_exception in start_event_loop. Tested on x86_64-linux. Approved-By: Andrew Burgess PR cli/33063 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33063 [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Output.html [2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Quitting-GDB.html 2025-07-22 Guinevere Larsen gdb: Remove redundant parameter for filename completion As I was working on an unrelated patch, I noticed that all calls to make_source_files_completion_list had both parameters of the function call being the same pointer. I think we can remove that redundancy and make that call with just one parameter. Approved-By: Andrew Burgess 2025-07-22 Simon Marchi gdb/solib-svr4: fix indent Change-Id: I63f78f359f55ec15fb3296a1a9ce28c9d01d663b gdb: use skip_spaces in info_linker_namespace_command Change-Id: I02c7daed3740e319ee27d3512a2b941f666b103b Approved-By: Andrew Burgess 2025-07-22 Simon Marchi gdb: fix formatting in solib.c I found these two small nits while working in this file. Change-Id: Ibdaa57262f3fe363b039fbad746e285fa7b52f8b Approved-By: Andrew Burgess 2025-07-22 Nick Clifton Updated translations for various sub-directories Remove steps for adding .dirstamp when creating pre-release tarball 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. 2025-07-22 Shiven Kashyap Fix failing test: i386-avx-reverse Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure: ''' FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd ''' This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself got broadcast to xmm15 (and thus to ymm15). This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'): ''' asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0)); ^ ''' and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register. Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match. Tested on x86-64 Linux. Approved-By: Guinevere Larsen 2025-07-22 Nelson Chu RISC-V: Don't allocate dynamic relocation if it's section was discarded 2025-07-22 Nelson Chu RISC-V: Fix the assert fail when linking discarded sections under -pie for got Considering the following case, % cat tmp.s .option pic .text .global _start _start: nop .section .discard.s, "ax" la x1, _start % cat tmp.ld OUTPUT_ARCH(riscv) ENTRY(_start) SECTIONS { /DISCARD/ : { *(.discard.*) } . = 0x10000; .text : { *(.text) } . = 0x20000; .got : { *(.got) *(.got.plt)} . = 0x30000; .data : { *(.data) *(.data.*) } } % riscv64-unknown-linux-gnu-as tmp.s -o tmp.o % riscv64-unknown-linux-gnu-ld -pie -Ttmp.ld tmp.o riscv64-unknown-linux-gnu-ld: BFD (GNU Binutils) 2.44.50.20250624 assertion fail binutils-gdb/bfd/elfnn-riscv.c:3638 This happens when pie and the input sections, which refers to the global symbol by got, are all discarded. Since referenced sections are all discarded, we won't go into relocate_section for those sections, the got entry also won't be initialized. Therefore, we will get assert fail when adding the RELATIVE reloc in the finish_dynamic_symbol. After seeing other target codes, there are two root causes as follows, 1. risc-v may call bfd_elf_link_record_dynamic_symbol in the allocate_dynrelocs for not only undefweak symbols. 2. risc-v is missing the code to add RELATIVE to R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is not undefined weak under pic and pie. If we call bfd_elf_link_record_dynamic_symbol, then the global symbol will be forced to dynamic, so the h->dynindx will forced to be a number rather than -1, even it should be -1. Once h->dynindx != -1 and pic/pie, it will go into finish_dynamic_symbol and insert RELATIVE/64 relocs for the got entry; For the above case there are two issues, 1. The global symbol _start is forced to be dynamic in the allocate_dynrelocs. when pie and all the referenced section are discarded, it won't go into relocate_section to initialize the got entry, so it will cause assert fail when adding RELATIVE reloc in the finish_dynamic_symbol. The assert fail represents another problem - if we don't initialize the got entry in the relocate_section under pie, which means we don't need to go into the finish_dynamic_symbol and don't need a RELATIVE reloc for the got entry, it should be NONE reloc. 2. Without linking any discarded section, it originally forces every RELATIVE relocs added for every got by the finish_dynamic_symbol. Even The final result looks correct under pie (genearte a RELATIVE reloc for got entry), not sure if it may cause other problems for some special cases, excpet the above one. Therefore, this patch try to fix the above assert fail, and also clarify the behavior of the allocate_dynrelocs which should only call bfd_elf_link_record_dynamic_symbol for undefweak symbols, and add the missing code to generate RELATIVE reloc to R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is not undefined weak under pic and pie. Passed the gcc/binutils regressions of riscv-gnu-toolchain at least. 2025-07-22 Nelson Chu RISC-V: Indent and reorder backend define functions for bfd/elfnn-riscv.c 2025-07-22 GDB Administrator Automatic date update in version.in 2025-07-21 Simon Marchi gdb: remove unused includes Remove a bunch of includes reported as unused by clangd. Change-Id: I3f05f98a298036fadf1acce4ddc198405ec056ee 2025-07-21 Simon Marchi gdb/solib-svr4: remove an unnecessary static cast The type is already lm_info_svr4. Change-Id: Id681eb1685462610b202c76147739ac885555f6b 2025-07-21 Richard Earnshaw aarch64: Use an enum to refer to indices in the opcode table The indices into the auto-generated tables for opcodes are relatively unstable. Adding a new opcode can permute the code significantly. But most of this churn is down to changes in the index values. To minimize this use enumerated constants. While the index values change, the enumeration names will need to do so far less often, so most of the changes in the generated code become localized to the addition (occasionally removal) of opcodes. This change also makes the state-change comments unnecessary. The enumeration names contain the same information (and more), so these are simply deleted. The enumeration values are placed in a new header file, aarch64-tbl-2.h, so aarch64-gen gains a new option to build this header and the Makefile rules are adjusted accordingly. 2025-07-21 Richard Earnshaw aarch64: use an enumeration for operand indices. The generated aarch64 operand tables use index values into an array. But if the table of operands is modified by inserting a new operand into the middle of the table, *all* the index values can change, leading to a lot of churn in the generated output. include/opcode/aarch64.h already provides an enumeration for the operands, so make use of that instead of printing out the raw index values. 2025-07-21 Richard Earnshaw aarch64: Fix operand name MOPS_WB_Rd -> MOPS_WB_Rn This field was misnamed in aarch64_opcode_table. It previously didn't matter too much as the name field only appeared in dumps. But it doesn't match the enum in include/opcode/aarch64.h and we will shortly start to rely on that. aarch64: minor code cleanups to aarch64-gen.c Fix some overly-long lines. 2025-07-21 Simon Marchi gdb/solib-svr4: remove unused svr4_solib_ops method declarations These method declarations are unused, remove them. I guess that when writing a previous patch, changed some free functions to be methods, then changed my mind, and forgot to remove the declarations. Change-Id: I7452bb773af0f32c4aae2fe6a4fc663ec65c3f15 2025-07-21 H.J. Lu Remove NaCl/arm target support NaCl has been deprecated: https://developer.chrome.com/docs/native-client/migration/ It is now in the process of being removed from llvm: https://github.com/llvm/llvm-project/pull/133661 Remove NaCl/arm target support from bfd, binutils, gas and ld. bfd/ * Makefile.am (BFD32_BACKENDS): Remove elf-nacl.lo. (BFD32_BACKENDS_CFILES): Remove elf-nacl.c. (SOURCE_HFILES): Remove elf-nacl.h. * Makefile.in: Regenerated. * config.bfd: Add *-*-nacl* to obsolete targets. Remove *-*-nacl* targets. * configure.ac: Remove nacl target vectors. * elf-bfd.h (elf_target_os): Remove is_nacl. * elf-nacl.c: Removed. * elf-nacl.h: Likewise. * elf32-arm.c: Don't include "elf-nacl.h". (elf32_arm_nacl_plt0_entry): Removed. (elf32_arm_nacl_plt_entry): Likewise. (elf32_arm_stub_long_branch_arm_nacl): Likewise. (elf32_arm_stub_long_branch_arm_nacl_pic): Likewise. (arm_movw_immediate): Likewise. (arm_movt_immediate): Likewise. (arm_nacl_put_plt0): Likewise. (elf32_arm_nacl_link_hash_table_create): Likewise. (elf32_arm_nacl_modify_segment_map): Likewise. (elf32_arm_nacl_final_write_processing): Likewise. (elf32_arm_nacl_plt_sym_val): Likewise. (elf32_arm_stub_cmse_branch_thumb_only): Remove long_branch_arm_nacl and long_branch_arm_nacl_pic entries. (arm_type_of_stub): Updated. (elf32_arm_create_or_find_stub_sec): Likewise. (arm_stub_required_alignment): Likewise. (elf32_arm_allocate_plt_entry): Likewise. (elf32_arm_populate_plt_entry): Likewise. (elf32_arm_finish_dynamic_sections): Likewise. (elf32_arm_output_plt_map_1): Likewise. (elf32_arm_output_arch_local_syms): Likewise. Remove elf32_arm_nacl_bed. * targets.c: Remove NaCl target vectors. * bfd-in2.h: Regenerated. * configure: Likewise. * po/SRC-POTFILES.in: Likewise. binutils/ * NEWS: Mention NaCl target support removal. * testsuite/lib/binutils-common.exp: Remove NaCl target support. gas/ * NEWS: Mention NaCl target support removal. * configure.tgt: Likewise. * config/tc-arm.c: Remove NaCl target support. * testsuite/gas/arm/any-armv8m.d: Likewise. * testsuite/gas/arm/any-cmse-main.d: Likewise. * testsuite/gas/arm/any-cmse.d: Likewise. * testsuite/gas/arm/any-idiv.d: Likewise. * testsuite/gas/arm/arch4t-eabi.d: Likewise. * testsuite/gas/arm/arch4t.d: Likewise. * testsuite/gas/arm/armv8m.base-idiv.d: Likewise. * testsuite/gas/arm/armv9-a_arch.d: Likewise. * testsuite/gas/arm/attr-abi-hardfp-use-0.d: Likewise. * testsuite/gas/arm/attr-abi-hardfp-use-1.d: Likewise. * testsuite/gas/arm/attr-abi-hardfp-use-2.d: Likewise. * testsuite/gas/arm/attr-abi-hardfp-use-3.d: Likewise. * testsuite/gas/arm/attr-any-armv4t.d: Likewise. * testsuite/gas/arm/attr-any-thumbv6.d: Likewise. * testsuite/gas/arm/attr-arch-assumption.d: Likewise. * testsuite/gas/arm/attr-cpu-directive.d: Likewise. * testsuite/gas/arm/attr-default.d: Likewise. * testsuite/gas/arm/attr-empty-string.d: Likewise. * testsuite/gas/arm/attr-ext-fpv5-d16.d: Likewise. * testsuite/gas/arm/attr-ext-fpv5.d: Likewise. * testsuite/gas/arm/attr-ext-idiv.d: Likewise. * testsuite/gas/arm/attr-ext-mp.d: Likewise. * testsuite/gas/arm/attr-ext-neon-fp16.d: Likewise. * testsuite/gas/arm/attr-ext-neon-vfpv3.d: Likewise. * testsuite/gas/arm/attr-ext-neon-vfpv4.d: Likewise. * testsuite/gas/arm/attr-ext-sec.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3-d16-fp16.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3-d16.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3-fp16.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3xd-fp.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv3xd.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv4-d16.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv4-sp-d16.d: Likewise. * testsuite/gas/arm/attr-ext-vfpv4.d: Likewise. * testsuite/gas/arm/attr-march-all.d: Likewise. * testsuite/gas/arm/attr-march-armv1.d: Likewise. * testsuite/gas/arm/attr-march-armv2.d: Likewise. * testsuite/gas/arm/attr-march-armv2a.d: Likewise. * testsuite/gas/arm/attr-march-armv2s.d: Likewise. * testsuite/gas/arm/attr-march-armv3.d: Likewise. * testsuite/gas/arm/attr-march-armv3m.d: Likewise. * testsuite/gas/arm/attr-march-armv4.d: Likewise. * testsuite/gas/arm/attr-march-armv4t.d: Likewise. * testsuite/gas/arm/attr-march-armv4txm.d: Likewise. * testsuite/gas/arm/attr-march-armv4xm.d: Likewise. * testsuite/gas/arm/attr-march-armv5.d: Likewise. * testsuite/gas/arm/attr-march-armv5t.d: Likewise. * testsuite/gas/arm/attr-march-armv5te.d: Likewise. * testsuite/gas/arm/attr-march-armv5tej.d: Likewise. * testsuite/gas/arm/attr-march-armv5texp.d: Likewise. * testsuite/gas/arm/attr-march-armv5txm.d: Likewise. * testsuite/gas/arm/attr-march-armv6-m+os.d: Likewise. * testsuite/gas/arm/attr-march-armv6-m.d: Likewise. * testsuite/gas/arm/attr-march-armv6.d: Likewise. * testsuite/gas/arm/attr-march-armv6j.d: Likewise. * testsuite/gas/arm/attr-march-armv6k+sec.d: Likewise. * testsuite/gas/arm/attr-march-armv6k.d: Likewise. * testsuite/gas/arm/attr-march-armv6kt2.d: Likewise. * testsuite/gas/arm/attr-march-armv6kz.d: Likewise. * testsuite/gas/arm/attr-march-armv6kzt2.d: Likewise. * testsuite/gas/arm/attr-march-armv6s-m.d: Likewise. * testsuite/gas/arm/attr-march-armv6t2.d: Likewise. * testsuite/gas/arm/attr-march-armv6z.d: Likewise. * testsuite/gas/arm/attr-march-armv6zk.d: Likewise. * testsuite/gas/arm/attr-march-armv6zkt2.d: Likewise. * testsuite/gas/arm/attr-march-armv6zt2.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a+idiv.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a+mp.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a+sec+virt.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a+sec.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a+virt.d: Likewise. * testsuite/gas/arm/attr-march-armv7-a.d: Likewise. * testsuite/gas/arm/attr-march-armv7-m.d: Likewise. * testsuite/gas/arm/attr-march-armv7-r+mp.d: Likewise. * testsuite/gas/arm/attr-march-armv7-r.d: Likewise. * testsuite/gas/arm/attr-march-armv7.d: Likewise. * testsuite/gas/arm/attr-march-armv7a.d: Likewise. * testsuite/gas/arm/attr-march-armv7em.d: Likewise. * testsuite/gas/arm/attr-march-armv7m.d: Likewise. * testsuite/gas/arm/attr-march-armv7r.d: Likewise. * testsuite/gas/arm/attr-march-armv7ve.d: Likewise. * testsuite/gas/arm/attr-march-armv8-a+crypto.d: Likewise. * testsuite/gas/arm/attr-march-armv8-a+fp.d: Likewise. * testsuite/gas/arm/attr-march-armv8-a+rdma.d: Likewise. * testsuite/gas/arm/attr-march-armv8-a+simd.d: Likewise. * testsuite/gas/arm/attr-march-armv8-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8-r+crypto.d: Likewise. * testsuite/gas/arm/attr-march-armv8-r+fp.d: Likewise. * testsuite/gas/arm/attr-march-armv8-r+simd.d: Likewise. * testsuite/gas/arm/attr-march-armv8-r.d: Likewise. * testsuite/gas/arm/attr-march-armv8_1-a+simd.d: Likewise. * testsuite/gas/arm/attr-march-armv8_1-m.main.d: Likewise. * testsuite/gas/arm/attr-march-armv8_4-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8_5-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8_6-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8_7-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8_9-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_1-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_4-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_5-a.d: Likewise. * testsuite/gas/arm/attr-march-armv8m.base.d: Likewise. * testsuite/gas/arm/attr-march-armv8m.main.d: Likewise. * testsuite/gas/arm/attr-march-armv8m.main.dsp.d: Likewise. * testsuite/gas/arm/attr-march-iwmmxt.d: Likewise. * testsuite/gas/arm/attr-march-iwmmxt2.d: Likewise. * testsuite/gas/arm/attr-march-xscale.d: Likewise. * testsuite/gas/arm/attr-mcpu.d: Likewise. * testsuite/gas/arm/attr-mfpu-arm1020e.d: Likewise. * testsuite/gas/arm/attr-mfpu-arm1020t.d: Likewise. * testsuite/gas/arm/attr-mfpu-arm1136jf-s.d: Likewise. * testsuite/gas/arm/attr-mfpu-arm1136jfs.d: Likewise. * testsuite/gas/arm/attr-mfpu-neon-fp16.d: Likewise. * testsuite/gas/arm/attr-mfpu-neon.d: Likewise. * testsuite/gas/arm/attr-mfpu-softvfp+vfp.d: Likewise. * testsuite/gas/arm/attr-mfpu-softvfp.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfp.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfp10-r0.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfp10.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfp3.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfp9.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpv2.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpv3-d16.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpv3.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpv4-d16.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpv4.d: Likewise. * testsuite/gas/arm/attr-mfpu-vfpxd.d: Likewise. * testsuite/gas/arm/attr-names.d: Likewise. * testsuite/gas/arm/attr-non-null-terminated-string.d: Likewise. * testsuite/gas/arm/attr-order.d: Likewise. * testsuite/gas/arm/attr-override-cpu-directive.d: Likewise. * testsuite/gas/arm/attr-override-mcpu.d: Likewise. * testsuite/gas/arm/bl-local-2.d: Likewise. * testsuite/gas/arm/bl-local-v4t.d: Likewise. * testsuite/gas/arm/blx-local.d: Likewise. * testsuite/gas/arm/branch-reloc.d: Likewise. * testsuite/gas/arm/directives.d: Likewise. * testsuite/gas/arm/got_prel.d: Likewise. * testsuite/gas/arm/mapdir.d: Likewise. * testsuite/gas/arm/mapmisc.d: Likewise. * testsuite/gas/arm/mapsecs.d: Likewise. * testsuite/gas/arm/mapshort-eabi.d: Likewise. * testsuite/gas/arm/mov-highregs-any.d: Likewise. * testsuite/gas/arm/mov-lowregs-any.d: Likewise. * testsuite/gas/arm/note-march-armv2.d: Likewise. * testsuite/gas/arm/note-march-armv2a.d: Likewise. * testsuite/gas/arm/note-march-armv3.d: Likewise. * testsuite/gas/arm/note-march-armv3m.d: Likewise. * testsuite/gas/arm/note-march-armv4.d: Likewise. * testsuite/gas/arm/note-march-armv4t.d: Likewise. * testsuite/gas/arm/note-march-armv5.d: Likewise. * testsuite/gas/arm/note-march-armv5t.d: Likewise. * testsuite/gas/arm/note-march-armv5te.d: Likewise. * testsuite/gas/arm/note-march-iwmmxt.d: Likewise. * testsuite/gas/arm/note-march-iwmmxt2.d: Likewise. * testsuite/gas/arm/note-march-xscale.d: Likewise. * testsuite/gas/arm/pr12198-1.d: Likewise. * testsuite/gas/arm/pr12198-2.d: Likewise. * testsuite/gas/arm/thumb-eabi.d: Likewise. * testsuite/gas/arm/thumb.d: Likewise. * testsuite/gas/arm/thumbrel.d: Likewise. * config/te-nacl.h: Removed. ld/ * Makefile.am (ALL_EMULATION_SOURCES): Remove earmelf_nacl.c and and earmelfb_nacl.c. Remove NaCl dep files. * NEWS: Mention NaCl target support removal. * configure.tgt: Remove NaCl target support. * Makefile.in: Regenerated. * configure: Likewise. * po/BLD-POTFILES.in: Likewise. * emulparams/armelf_nacl.sh: Removed. * emulparams/armelfb_nacl.sh: Likewise. * emulparams/elf_nacl.sh: Likewise. * testsuite/ld-arm/farcall-arm-nacl-pic.d: Likewise. * testsuite/ld-arm/farcall-arm-nacl.d: Likewise. * testsuite/ld-arm/farcall-data-nacl.d: Likewise. * testsuite/ld-arm/farcall-thumb2-purecode-consecutive-veneer.d: Adjusted. * testsuite/ld-arm/arm-elf.exp: Remove NaCl target support. * testsuite/ld-arm/cortex-a8-far.d: Likewise. * testsuite/ld-arm/non-contiguous-arm3.d: Likewise. * testsuite/ld-arm/non-contiguous-arm6.d: Likewise. * testsuite/ld-elf/binutils.exp: Likewise. * testsuite/ld-elf/build-id.exp: Likewise. * testsuite/ld-elf/ehdr_start-missing.d: Likewise. * testsuite/ld-elf/ehdr_start-shared.d: Likewise. * testsuite/ld-elf/ehdr_start-userdef.d: Likewise. * testsuite/ld-elf/ehdr_start-weak.d: Likewise. * testsuite/ld-elf/ehdr_start.d: Likewise. * testsuite/ld-elf/elf.exp: Likewise. * testsuite/ld-elf/export-class.exp: Likewise. * testsuite/ld-elf/fatal-warnings-1a.d: Likewise. * testsuite/ld-elf/fatal-warnings-1b.d: Likewise. * testsuite/ld-elf/orphan-region.d: Likewise. * testsuite/ld-elf/package-note.exp: Likewise. * testsuite/ld-elf/pr16322.d: Likewise. * testsuite/ld-elf/pr16498a.d: Likewise. * testsuite/ld-elf/pr16498b.d: Likewise. * testsuite/ld-elf/pr19162.d: Likewise. * testsuite/ld-elf/pr22269a.d: Likewise. * testsuite/ld-elf/pr22269b.d: Likewise. * testsuite/ld-elf/pr22393-1a.d: Likewise. * testsuite/ld-elf/pr22393-1b.d: Likewise. * testsuite/ld-elf/pr22393-1c.d: Likewise. * testsuite/ld-elf/pr22393-1d.d: Likewise. * testsuite/ld-elf/pr22393-1e.d: Likewise. * testsuite/ld-elf/pr22393-1f.d: Likewise. * testsuite/ld-elf/pr22393-2a.rd: Likewise. * testsuite/ld-elf/pr22393-2b.rd: Likewise. * testsuite/ld-elf/pr23900-1-32.rd: Likewise. * testsuite/ld-elf/pr23900-1-64.rd: Likewise. * testsuite/ld-elf/pr23900-1.d: Likewise. * testsuite/ld-elf/pr23900-2a.d: Likewise. * testsuite/ld-elf/pr23900-2b.d: Likewise. * testsuite/ld-elf/pr30508.d: Likewise. * testsuite/ld-elf/pr30907-1.d: Likewise. * testsuite/ld-elf/pr30907-2.d: Likewise. * testsuite/ld-elf/pr32341.d: Likewise. * testsuite/ld-elf/shared.exp: Likewise. * testsuite/ld-elf/tls.exp: Likewise. * testsuite/ld-elf/tls_common.exp: Likewise. * testsuite/ld-elfvers/vers.exp: Likewise. * testsuite/ld-elfvsb/elfvsb.exp: Likewise. * testsuite/ld-elfweak/elfweak.exp: Likewise. * testsuite/ld-gc/gc.exp: Likewise. * testsuite/ld-ifunc/binutils.exp: Likewise. * testsuite/ld-pie/pie.exp: Likewise. * testsuite/ld-plugin/lto-binutils.exp: Likewise. * testsuite/ld-plugin/lto.exp: Likewise. * testsuite/ld-scripts/rgn-at3.d: Likewise. * testsuite/ld-shared/shared.exp: Likewise. * testsuite/ld-size/size.exp: Likewise. 2025-07-21 H.J. Lu gold: Remove NaCl target support NaCl has been deprecated: https://developer.chrome.com/docs/native-client/migration/ It is now in the process of being removed from llvm: https://github.com/llvm/llvm-project/pull/133661 Remove NaCl target support from gold. * Makefile.am (CCFILES): Remove nacl.cc. (HFILES): Remove nacl.h. * Makefile.in: Regenerated. * aarch64.cc: Don't include nacl.h. * arm.cc: Don't include nacl.h. (Target_arm_nacl): Removed. (Output_data_plt_arm_nacl): Likewise. (target_selector_arm): Replace Target_arm_nacl with Target_selector_arm. * i386.cc: Don't include nacl.h. (Output_data_plt_i386_nacl): Removed. (Target_i386_nacl): Likewise. (target_selector_i386): Replace Target_selector_i386_nacl with Target_selector_i386. * mips.cc: Don't include nacl.h. (Target_mips_nacl): Removed. (Target_selector_mips_nacl): Likewise. (target_selector_mips32): Replace Target_selector_mips_nacl with Target_selector_mips. (target_selector_mips32el): Likewise. (target_selector_mips64): Likewise. (target_selector_mips64el): Likewise. * nacl.cc: Removed. * nacl.h: Likewise. * x86_64.cc: Don't include nacl.h. (Output_data_plt_x86_64_nacl): Removed. (Target_x86_64_nacl): Likewise. (target_selector_x86_64): Replace Target_x86_64_nacl with Target_selector_x86_64. (target_selector_x32): Likewise. * po/POTFILES.in: Regenerated. 2025-07-21 GDB Administrator Automatic date update in version.in 2025-07-20 GDB Administrator Automatic date update in version.in 2025-07-19 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-19 Tom de Vries [gdb/cli] Document \001 and \002 usage for set prompt PR cli/28887 reports the following problem when using a custom prompt. First, we set up the custom prompt (with ^ marking the position of the blinking cursor on the line above): ... $ gdb -q -ex "set prompt \033[31mgdb$ \033[0m" gdb$ ^ ... Then we type some string, and enter it into the command history: ... gdb$ some long command ❌️ Undefined command: "some". Try "help". gdb$ ^ ... We use C-p to fetch the previous command: ... gdb$ some long command ^ ... Sofar, so good. Finally, we use C-a which should move the cursor to just after the prompt, but instead we get: ... gdb$ some long command ^ ... This is fixed by using \001 and \002: ... (gdb) set prompt \001\033[31m\002gdb$ \001\033[0m\002 ... aka as RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE [1]. Add an example to the documentation showing the use of these markers. The added example is the equivalent of the "\[\e[0;34m\](gdb)\[\e[0m\]" example documented at gdb.prompt.substitute_string that can be used with "set extended-prompt". While working on this, I noticed that "show prompt" doesn't show back the original string, using '\e' instead of '\033': ... gdb$ show prompt Gdb's prompt is "\001\e[31m\002gdb$ \001\e[0m\002". ... and that the shown string can't be used as an argument to "set prompt": ... gdb$ set prompt \001\e[31m\002gdb$ \001\e[0m\002 e[31mgdb$ e[0m ... I've filed this as PR cli/33184. Approved-By: Eli Zaretskii [1] https://tiswww.case.edu/php/chet/readline/readline.html 2025-07-19 Tom de Vries [gdb/testsuite] Restructure gdb.base/backtrace-through-cu-nodebug.exp I noticed that the test names in test-case gdb.base/backtrace-through-cu-nodebug.exp are a bit inconsistent: ... PASS: $exp: no-cfi: maint frame-unwinder disable ARCH PASS: $exp: verify no-filters unwind fail without CFI PASS: $exp: maint flush register-cache PASS: $exp: verify unwind fail without CFI PASS: $exp: cfi: maint frame-unwinder disable ARCH PASS: $exp: Verify unwinding works based only on CFI information ... There's both a no-cfi prefix, and "without CFI". Fix this by using proc_with_prefix, getting us a consistent prefix: ... PASS: $exp: no-cfi: maint frame-unwinder disable ARCH PASS: $exp: no-cfi: verify no-filters unwind fail PASS: $exp: no-cfi: maint flush register-cache PASS: $exp: no-cfi: verify unwind fail PASS: $exp: cfi: maint frame-unwinder disable ARCH PASS: $exp: cfi: Verify unwinding works ... While we're at it, use multi_line to make a regexp more readable. Tested on aarch64-linux. Reviewed-By: Keith Seitz 2025-07-19 Tom de Vries [gdb/testsuite] Fix gdb.base/backtrace-through-cu-nodebug.exp without python support With a gdb build without python support, and test-case gdb.base/backtrace-through-cu-nodebug.exp I run into: ... (gdb) bt^M Required frame unwinder may have been disabled, \ see 'maint info frame-unwinders'^M (gdb) FAIL: $exp: verify unwind fail without CFI ... With a gdb build with python support we have instead: ... (gdb) bt^M Python Exception : \ Required frame unwinder may have been disabled, \ see 'maint info frame-unwinders'^M (gdb) PASS: $exp: verify unwind fail without CFI ... but if I change the "bt" into "bt -no-filters" I get the same FAIL and corresponding output. So there are two scenarios here. In the first: - the bt command is called - frame #0 is printed - trying to get the next frame fails and an error is thrown, aborting the backtrace - the error is caught and printed In the second: - the bt command is called - the frame filter is applied - doing so triggers the same error, which is caught and printed by gdbpy_apply_frame_filter, returning EXT_LANG_BT_NO_FILTERS - frame #0 is printed - getting the next frame fails, and the backtrace stops It seems worthwhile to exercise both scenarios if possible, so add a "bt -no-filters" test. Fix the FAIL by updating the regexp to allow both scenarios. Tested on aarch64-linux. Reviewed-By: Keith Seitz 2025-07-19 Tom de Vries [gdb/testsuite] Fix gdb.multi/pending-bp.exp without python support With a gdb build without python support and test-case gdb.multi/pending-bp.exp, I run into: ... (gdb) python bp=[b for b in gdb.breakpoints() if b.number == 5][0]^M Python scripting is not supported in this copy of GDB.^M (gdb) FAIL: $exp: py_test_toggle_thread: find Python gdb.Breakpoint object ... Fix this by requiring python support for part of the test-case. Tested on aarch64-linux. Reviewed-By: Keith Seitz 2025-07-19 Tom de Vries [gdb/testsuite] Fix gdb.base/break-dbg.exp without xml support With a gdb build without xml support and test-case gdb.base/break-dbg.exp, I run into: ... (gdb) catch syscall^M warning: Can not parse XML syscalls information; \ XML support was disabled at compile time.^M Catchpoint 11 (any syscall)^M (gdb) FAIL: $exp: catch syscall ... Fix this by updating the regexp. Tested on aarch64-linux. Reviewed-By: Keith Seitz 2025-07-19 Alan Modra Re: RELOC_AGAINST_DISCARDED_SECTION zero size reloc sections Update the testsuite, so that is_generic ELF targets still do the linkonce1 test (as linkonce3). 2025-07-19 GDB Administrator Automatic date update in version.in 2025-07-19 Alan Modra RELOC_AGAINST_DISCARDED_SECTION zero size reloc sections For some reason the initial implementation (commit 0672748ac053) of this macro didn't allow discarding of all relocs in a section, perhaps because doing so would require a testsuite change. This patch allows zero size relocation sections to result, and adjusts the testsuite. i386, x86_64, ppc and ppc64 code that avoids a memmove is also changed to allow zero size reloc sections, and arc fixed to actually adjust the reloc section header. 2025-07-18 Tom de Vries [gdb/testsuite] Fix gdb.arch/amd64-disp-step-self-call.exp on freebsd On x86_64-freebsd, with test-case gdb.arch/amd64-disp-step-self-call.exp, I run into: ... (gdb) continue Continuing. Program received signal SIGBUS, Bus error. Object-specific hardware error. 0x000000080051492c in alarm () from /lib/libc.so.7 (gdb) FAIL: $exp: continue to breakpoint: test_call ... The behaviour is not specific to gdb, it can be reproduced by running the test-case executable: ... $ ./outputs/gdb.arch/amd64-disp-step-self-call/amd64-disp-step-self-call Bus error (core dumped) $ ... The bus error happens when executing this instruction in alarm: ... 0000000000093910 : ... 9392c: 0f 29 45 d0 movaps %xmm0, -0x30(%rbp) ... because $rbp is not 16-byte aligned. This can be fixed by adding the missing frame setup instructions at the start of main in amd64-disp-step-self-call.S: ... main: + pushq %rbp + movq %rsp, %rbp ... Instead, fix this by moving main from the assembly file to the c file, which has the same effect. Also remove the done label, which looks like a copy-past left-over. Instead, add an unreachable function and use it where appropriate. Do the same for i386 case (which makes the source files identical for the amd64 and i386 case, but I decided to leave it like that). Tested on x86_64-freebsd and x86_64-linux. 2025-07-18 Andrew Burgess gdb/testsuite: mark the start of each gdb.in.* log file Emit a line in the gdb.log file each time a new gdb.in.NUM command log is started. The gdb.log line includes the full filename for the new gdb.in.NUM file. This change will make it trivial to go from a FAIL in the gdb.log file to the gdb.in.NUM file that (should) reproduce the failure. When I encounter a failing test one of my first steps is usually to identify the gdb.in.NUM file and try re-running it to see if that reproduces the failure. Some tests create many very similar gdb.in.NUM files, so finding the exact one can sometimes be difficult. With this patch that task is now trivial. There should be no change in what is tested after this commit. Approved-By: Simon Marchi 2025-07-18 H.J. Lu ld: Limit PR ld/25617 tests to glibc targets Since PR ld/25617 tests expects glibc specific features, limit PR ld/25617 tests to glibc targets. PR ld/33169 * testsuite/ld-elf/no-section-header.exp: Return if not glibc targets. 2025-07-18 Alan Modra Fix more unused variable warnings Fix unused variable warnings 2025-07-18 Alan Modra asan: undefined shift .bundle_align_mode 32 nop read.c:776:26: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' Avoid this by using wider types in the expressions. 2025-07-18 Alan Modra visium: use RELOC_AGAINST_DISCARDED_SECTION The initial visium support added in commit d924db559be9 didn't make use of RELOC_AGAINST_DISCARDED_SECTION, and so lacked code to remove relocations in debug sections. METAG_RELOC_AGAINST_DISCARDED_SECTION Delete this macro which duplicates RELOC_AGAINST_DISCARDED_SECTION, and instead add an rnone parameter to the standard version. 2025-07-18 GDB Administrator Automatic date update in version.in 2025-07-17 Tom de Vries [gdb/testsuite] Use pagination_prompt var more often In some test-cases, matching the pagination prompt is split up to address a matching race but that's no longer necessary, thanks to commit c3f814a1433 ("Fix paginate-*.exp races"). Fix this by using the pagination_prompt variable. Tested on x86_64-linux. Approved-By: Andrew Burgess 2025-07-17 Tom de Vries [gdb/testsuite] Require minimum width in gdb.base/style.exp In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling, which: - determines a "desired width" by parsing the output of "info files", - sets width to the "desired width", and - runs "info files" again. The "desired width" on my system is 88, but if I override it to 65, I run into: ... (gdb) info files^M Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M --Type for more, q to quit, c to continue without paging--^M ^MFAIL: gdb.base/style.exp: check pagination prompt styling (timeout) ... with make target check, and with check-read1 into: ... (gdb) info files^M Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M --Type for more, q to quit, c to continue without paging--^M ^M^[[A^M Native process:^M Using the running image of child process 6179.^M --Type for more, q to quit, c to continue without paging--ERROR: Window too small. UNRESOLVED: gdb.base/style.exp: check pagination prompt styling ... This is caused by the following. The size of the pagination prompt is 64: ... 1 2 3 4 5 6 1234567890123456789012345678901234567890123456789012345678901234 --Type for more, q to quit, c to continue without paging-- ... and because we have TERM=ansi and width == 65, readline wraps at 64: ... (gdb) maint info screen Number of characters gdb thinks are in a line is 65. Number of characters readline reports are in a line is 64. ... In other words, readline wraps when printing the pagination prompt. This causes some unusual output, and the test is not prepared to handle this. Fix this by requiring that desired_width is at least + 2. Tested on x86_64-linux. Approved-By: Andrew Burgess PR testsuite/33167 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33167 2025-07-17 Tom de Vries [gdb/testsuite] Fix regexp in gdb.base/style.exp In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling, which: - determines a "desired width" by parsing the output of "info files", - sets width to the "desired width", and - runs "info files" again. The "desired width" on my system is 88, but if I override it to 66, I run into: ... FAIL: gdb.base/style.exp: check pagination prompt styling ... due to the test classifying this line as a bad line: ... $hex - $hex is .init_array in --Type for more, ... ... This is due to a bug in this regexp: ... # For lines that don't match this pattern, we cannot comment on # where the style reset should occur, so lets just claim the line # is fine. if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in " $str] } { return true } ... which is supposed to determine whether the line needs to contain a style reset. For aforementioned line, the regexp matches, so the test concludes that the line should have a style reset, and because it hasn't, it classifies it as a bad line. Fix this by making the regexp more strict: ... if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in \033" $str] } { ... Tested on x86_64-linux. Approved-By: Andrew Burgess 2025-07-17 Tom de Vries [gdb/testsuite] Stabilize test name in gdb.base/style.exp With test-case gdb.base/style.exp, I get: ... PASS: gdb.base/style.exp: set width 88 ... The 88 is not a constant, it's a variable: ... gdb_test_no_output "set width $desired_width" ... which is calculated by parsing the output of "info files". When running with target board unix/-m32, I get instead: ... PASS: gdb.base/style.exp: set width 67 ... Stabilize the test name by using instead: ... PASS: gdb.base/style.exp: set width to desired width ... Tested on x86_64-linux. Approved-By: Andrew Burgess 2025-07-17 Marek Pikuła gdb/risc-v: fix ISA string detection for disassembly Commit 3f61a38 introduced a regression where the ISA string was no longer detected based on the ELF header. The mechanism was changed from directly referencing `abfd` to using `disassembler_info->section`, which was not properly initialized for RISC-V. The previous implementation ignored the object in scope, leading to issues such as failing to decode RVV instructions when a library was compiled as `rv64gcv` and the main application as `rv64gc`. This patch resolves both problems by initializing `disassembler_info->section` with the object currently in scope, ensuring correct ISA string detection during disassembly. Approved-By: Andrew Burgess 2025-07-17 Simon Marchi gdb: fix formatting in solib.c Change-Id: I7ae1ca4a822ecc2805025fac59a22af5d2a41166 2025-07-17 Sam James binutils: drop unused note_size, contents, old variables GCC trunk recently had improvements to its -Wunused-but-set-variable which picked up that contents and hence note_size & old aren't used at all in the end. * objcopy.c (merge_gnu_build_notes): Drop unused 'note_size', 'contents', and 'old' variables. 2025-07-17 Sam James bfd: drop unused elt_no GCC trunk recently had improvements to its -Wunused-but-set-variable which picked up that elt_no isn't used at all in the end. * archive.c (_bfd_compute_and_write_armap): Drop unused elt_no. 2025-07-17 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. 2025-07-17 Alan Modra readelf v850 notes This patch was prompted by a clang warning: readelf.c:23317:37: warning: pointer comparison always evaluates to false [-Wtautological-compare] 23317 | || inote.namedata + inote.namesz < inote.namedata) | ^ Use the same sanity checks as used by process_notes_at. (See commit 5396a86e4396). While we are at it, print all the v850 note info in one place to properly handle error conditions. 2025-07-17 GDB Administrator Automatic date update in version.in 2025-07-16 Simon Marchi gdb: remove unused includes in break-*.c These are reported as unused by clangd. Change-Id: I80871e08b9d29c540f61d6ea91904197faf92065 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]. 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. 2025-07-16 Haochen Jiang x86: Decouple AMX-AVX512 from AVX10.2 and imply AVX512F In ISE058, the AVX10.2 imply is removed from AMX-AVX512. This leads to re-consideration on the imply for AMX-AVX512. Since it is using zmm register and using zmm register only, we need to at least imply AVX512F. AVX512VL is not needed since it is not using xmm/ymms. On the other hand, if we imply AVX10.1 for AMX-AVX512, disabling avx10.1 will lead to disabling AMX-AVX512. This would be a surprise for users. Based on the two reasons above, the patch is decoupling AMX-AVX512 from AVX10.2 and imply AVX512F. opcodes/ChangeLog: * i386-gen.c: Imply AVX512F instead of AVX10.2. * i386-init.h: Regenerated. 2025-07-16 GDB Administrator Automatic date update in version.in 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 PR 33153 2025-07-15 H.J. Lu gas: Re-indent case OPTION_SFRAME: PR gas/33125 * gas/as.c (parse_args): Re-indent case OPTION_SFRAME: 2025-07-15 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. 2025-07-15 Sam James Revert "gas: support --gsframe=no" This reverts commit e6b2368b9556ea6298a1f0de97baeabf1b5b18fd. I made a last minute style change and oopsed it. 2025-07-15 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. 2025-07-15 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. 2025-07-15 GDB Administrator Automatic date update in version.in 2025-07-14 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. 2025-07-14 Simon Marchi gdb/amd64-linux-tdep: add missing space Change-Id: I4e15eae9791329f71321a9b00d682e22dd6e2f6d 2025-07-14 Nick Clifton Updated Ukranian translation for the opcodes sub-directory More updates to the 'how to make a release' documentation Updated Ukranian translation for the binutils sub-directory Updated Spanish translation for the gas sub-directory 2025-07-14 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 2025-07-14 Alan Modra gas deferrred diags leak asan complains when running the gas all/cond-diag test. * read.c (deferred_diag_head, deferred_diag_tail): Renamed from deferred_diags and last_deferred_diag, making the tail pointer a deferred_diag**. (s_errwarn_if): Simplify appending to list. Free unused diag on error. (evaluate_deferred_diags): Free list. 2025-07-14 Alan Modra Delete AM_PO_SUBDIRS invocation These aren't needed since commit 862776f26a59. 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-14 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. 2025-07-14 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. 2025-07-14 GDB Administrator Automatic date update in version.in 2025-07-13 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. 2025-07-13 Nick Clifton Fix compile time warning message about optarg parameter shadowing global variable Updates to how-to-make-a-release document after creating the 2.45 branch Update version number on mainline 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]--- transfer too big, truncated ---