diff --git a/ChangeLog.git b/ChangeLog.git new file mode 100644 index 00000000000..36ddbc8504e --- /dev/null +++ b/ChangeLog.git @@ -0,0 +1,321663 @@ +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] Handle missing curses in gdb.python/py-missing-debug.exp" + This reverts commit 29c70787112e01cd52b53bf14bdcacb0a11e0725. + + After the previous commit 29c70787112e01cd52 should no longer be + needed as the curses dependency has been removed. + +2024-09-10 Andrew Burgess + + gdb/python: avoid depending on the curses library + The commit: + + commit 29c70787112e01cd52b53bf14bdcacb0a11e0725 + Date: Sun Sep 8 07:46:09 2024 +0200 + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + + Highlighted that in some cases we might be running on a system with an + older version of Python (earlier than 3.7), and on a system for which + the curses library has not been installed. + + In these circumstances the gdb.missing_debug module will not load as + it uses curses to provide isalnum() and isascii() functions. + + To avoid this problem I propose that we copy the isalnum() and + isascii() from the Python curses library. These functions are + basically trivial and removing the curses dependency means GDB will + work in more cases without increasing its dependencies. + + I did consider keeping the uses of curses and only having the function + definitions be a fallback for when the curses library failed to load, + but this felt like overkill. The function definitions are both tiny + and I think "obvious" given their specifications, so I figure we might + as well just use our own definitions if they are not available as + builtin methods on the str class. + + For testing I changed this line: + + if sys.version_info >= (3, 7): + + to + + if sys.version_info >= (3, 7) and False: + + then reran gdb.python/py-missing-debug.exp, there were no failures. + + Approved-By: Tom de Vries + +2024-09-10 Tom de Vries + + [gdb/testsuite] Fix gdb.xml/tdesc-regs.exp on riscv64 + When running test-case gdb.xml/tdesc-regs.exp on riscv64-linux, I get: + ... + (gdb) set tdesc file single-reg.xml^M + warning: Architecture rejected target-supplied description^M + (gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml + UNSUPPORTED: gdb.xml/tdesc-regs.exp: register tests + ... + + The FAIL and UNSUPPORTED are produced here: + ... + # If no core registers were specified, assume this target does not + # support target-defined registers. Verify that we get a warning if + # we try to use them. This not only tests the warning, but also + # reminds maintainers to add test support when they add the feature. + + if {[string equal ${core-regs} ""]} { + gdb_test "set tdesc file $single_reg_xml" \ + "warning: Target-supplied registers are not supported.*" \ + "set tdesc file single-reg.xml" + unsupported "register tests" + return 0 + } + ... + + The test-case contains target-specific setting of the core-regs variable, and + adding this for riscv64 bypasses this code and makes the test-case pass. + + However, without that change, the test-case shouldn't produce a FAIL since + gdb isn't doing anything wrong. + + Fix this by producing instead: + ... + PASS: $exp: set tdesc file single-reg.xml + UNSUPPORTED: $exp: register tests (missing architecture-specific core-regs setting) + ... + + Tested on riscv64-linux. + +2024-09-10 Tom de Vries + + [gdb/build] Fix unused var in corelow.c + On x86_64-linux, with gcc 7.5.0 and CFLAGS/CXXFLAGS="-O0 -g -Wall" I ran into + a build breaker: + ... + gdb/corelow.c: In member function ‘void mapped_file_info::add(const char*, const char*, const char*, std::vector&&, const bfd_build_id*)’: + gdb/corelow.c:1822:27: error: unused variable ‘it’ [-Werror=unused-variable] + const auto [it, inserted] + ^ + ... + + Fix this by dropping the variable it. + + Tested on x86_64-linux. + + Reviewed-By: Lancelot Six + +2024-09-10 H.J. Lu + + bfd: Pass true to ld_plugin_object_p + Since linker calls bfd_plugin_object_p, which calls ld_plugin_object_p, + only for command-line input objects, pass true to ld_plugin_object_p so + that the same input IR file won't be included twice if the new LTO hook, + LDPT_REGISTER_CLAIM_FILE_HOOK_V2 isn't used. + + PR ld/32153 + * plugin.c (bfd_plugin_object_p): Pass true to ld_plugin_object_p. + +2024-09-10 GDB Administrator + + Automatic date update in version.in + +2024-09-09 Tom Tromey + + Move enum size check into ada_identical_enum_types_p + Currently, the callers of ada_identical_enum_types_p must check that + both enum types have the same number of members. In another series + I'm working on, it was convenient to move this check into the callee + instead; and I broke this patch out to make that series a little + simpler. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Minor cleanup to ada_identical_enum_types_p + This moves the declaration of 'i' into the 'for' loops in + ada_identical_enum_types_p. This is just a trivial cleanup. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Boolify ada_identical_enum_types_p + This changes ada_identical_enum_types_p to return bool rather than + int. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Fix some comments in dwarf2/cooked-index.h + This fixes a couple of comments in dwarf2/cooked-index.h. + + The comment by cooked_index_entry::canonical mentions C++, but this + field can also be different from 'name' in other situations. Rather + than enumerate the cases here (which doesn't seem important), make the + text a little less specific. + + Also, cooked_index_entry::write_scope doesn't document its "for_main" + parameter -- and it is misnamed in the prototype as well. + + Reviewed-By: Tom de Vries + +2024-09-09 Tom Tromey + + Refactor cooked_index_shard::handle_gnat_encoded_entry + This changes cooked_index_shard::handle_gnat_encoded_entry to modify + the incoming entry itself, and to return void rather than a new name. + this simplifies the caller a little, which is convenient for a + different series I am working on. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Ignore DW_TAG_padding in tag_is_type + DW_TAG_padding isn't a real tag -- it doesn't appear in the DWARF + standard, only in include/dwarf2.def as a placeholder. So, remove it + from dwarf2/tag.h:tag_is_type. + + Reviewed-By: Tom de Vries + +2024-09-09 Jens Remus + + s390: Align opcodes to lower-case + opcodes/ + * s390-opc.txt (rdp): Change opcode to lower-case. + +2024-09-09 Jens Remus + + s390: Document syntax to omit base register operand + Document the s390-specific assembler syntax introduced by commit + aacf780bca29 ("s390: Allow to explicitly omit base register operand in + assembly") to omit the base register operand B in D(X,B) and D(L,B) by + coding D(X,) and D(L,). + + While at it document the alternative syntax to omit the index register + operand X in D(X,B) by coding D(,B) instead of D(B). + + gas/ + * doc/c-s390.texi (s390 Operands): Document syntax to omit base + register operand. + + Fixes: aacf780bca29 ("s390: Allow to explicitly omit base register operand in assembly") + +2024-09-09 Andrew Burgess + + gdb/NEWS: group general news items together + I noticed that the list of general NEWS items seemed to have gotten + mixed up a bit in the NEWS file. This commit just moves things around + so that the general items all appear at the start of the 'Changes + since GDB 15' section. I've not changed any of the actual content. + +2024-09-09 Lulu Cai + + LoongArch: Fixed precedence of expression operators in instructions + The precedence of the operators "+" and "-" in the current loongarch + instruction expression is higher than "<<" and ">>", which is different + from the explanation in the user guide. + + We modified the precedence of "<<" and ">>" to be higher than "+" and "-". + +2024-09-09 GDB Administrator + + Automatic date update in version.in + +2024-09-08 Andrew Burgess + + gdb: fix use of out of scope temporary variable in break-cond-parse.c + The commit: + + commit c6b486755e020095710c7494d029577ca967a13a + Date: Thu Mar 30 19:21:22 2023 +0100 + + gdb: parse pending breakpoint thread/task immediately + + Introduce a use bug where the value of a temporary variable was being + used after it had gone out of scope. This was picked up by the + address sanitizer and would result in this error: + + (gdb) maintenance selftest create_breakpoint_parse_arg_string + Running selftest create_breakpoint_parse_arg_string. + ================================================================= + ==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768 + READ of size 1 at 0x7fbb08046511 thread T0 + #0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr >*, int*, int*, int*, std::unique_ptr >*, bool*) ../../src/gdb/break-cond-parse.c:496 + #1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582 + #2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649 + #3 0x12cfebc in void std::__invoke_impl(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61 + #4 0x12cc8ee in std::enable_if, void>::type std::__invoke_r(void (*&)()) /usr/include/c++/13/bits/invoke.h:111 + #5 0x12c81e5 in std::_Function_handler::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290 + #6 0x18bb51d in std::function::operator()() const /usr/include/c++/13/bits/std_function.h:591 + #7 0x4193ef9 in selftests::run_tests(gdb::array_view, bool) ../../src/gdbsupport/selftest.cc:100 + #8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172 + ... etc ... + + The problem was caused by three lines like this one: + + thread_info *thr + = parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok); + + After parsing the thread-id TMPTOK would be left pointing into the + temporary string which had been created on this line. When on the + next line we did this: + + gdb_assert (*tmptok == '\0'); + + The value of *TMPTOK is undefined. + + Fix this by creating the std::string earlier in the scope. Now the + contents of the string will remain valid when we check *TMPTOK. The + address sanitizer issue is now resolved. + +2024-09-08 Tom de Vries + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + On a system with python 3.6, module gdb.missing_debug imports module curses, + so when running test-case gdb.python/py-missing-debug.exp on a system without + that module installed, we run into: + ... + (gdb) source py-missing-debug.py^M + Python Exception : Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + Error occurred in Python: Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + (gdb) FAIL: gdb.python/py-missing-debug.exp: source python script + ... + + Fix this by issuing UNSUPPORTED instead, and bailing out. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31576 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31576 + +2024-09-08 GDB Administrator + + Automatic date update in version.in + +2024-09-07 Andrew Burgess + + gdb: only insert thread-specific breakpoints in the relevant inferior + This commit updates GDB so that thread or inferior specific + breakpoints are only inserted into the program space in which the + specific thread or inferior is running. + + In terms of implementation, getting this basically working is easy + enough, now that a breakpoint's thread or inferior field is setup + prior to GDB looking for locations, we can easily use this information + to find a suitable program_space and pass this to as a filter when + creating the sals. + + Or we could if breakpoint_ops::create_sals_from_location_spec allowed + us to pass in a filter program_space. + + So, this commit extends breakpoint_ops::create_sals_from_location_spec + to take a program_space argument, and uses this to filter the set of + returned sals. This accounts for about half the change in this patch. + + The second set of changes starts from breakpoint_set_thread and + breakpoint_set_inferior, this is called when the thread or inferior + for a breakpoint changes, e.g. from the Python API. + + Previously this call would never result in the locations of a + breakpoint changing, after all, locations were inserted in every + program space, and we just use the thread or inferior variable to + decide when we should stop. Now though, changing a breakpoint's + thread or inferior can mean we need to figure out a new set of + breakpoint locations. + + To support this I've added a new breakpoint_re_set_one function, which + is like breakpoint_re_set, but takes a single breakpoint, and just + updates the locations for that one breakpoint. We only need to call + this function if the program_space in which a breakpoint's thread (or + inferior) is running actually changes. If the program_space does + change then we call the new breakpoint_re_set_one function passing in + the program_space which should be used to filter the new locations (or + nullptr to indicate we should set locations in all program spaces). + This filter program_space needs to propagate down to all the re_set + methods, this accounts for the remaining half of the changes in this + patch. + + There were a couple of existing tests that created thread or inferior + specific breakpoints and then checked the 'info breakpoints' output, + these needed updating. These were: + + gdb.mi/user-selected-context-sync.exp + gdb.multi/bp-thread-specific.exp + gdb.multi/multi-target-continue.exp + gdb.multi/multi-target-ping-pong-next.exp + gdb.multi/tids.exp + gdb.mi/new-ui-bp-deleted.exp + gdb.multi/inferior-specific-bp.exp + gdb.multi/pending-bp-del-inferior.exp + + I've also added some additional tests to: + + gdb.multi/pending-bp.exp + + I've updated the documentation and added a NEWS entry. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: don't set breakpoint::pspace in create_breakpoint + I spotted this code within create_breakpoint: + + if ((type_wanted != bp_breakpoint + && type_wanted != bp_hardware_breakpoint) || thread != -1) + b->pspace = current_program_space; + + this code is only executed when creating a pending breakpoint, and + sets the breakpoint::pspace member variable. + + The above code gained the 'thread != -1' clause with this commit: + + commit cc72b2a2da6d6372cbdb1d14639a5fce84e1a325 + Date: Fri Dec 23 17:06:16 2011 +0000 + + Introduce gdb.FinishBreakpoint in Python + + While the type_wanted checks were added with this commit: + + commit f8eba3c61629b3c03ac1f33853eab4d8507adb9c + Date: Tue Dec 6 18:54:43 2011 +0000 + + the "ambiguous linespec" series + + Before this breakpoint::pspace was set unconditionally. + + If we look at how breakpoint::pspace is used today, some breakpoint + types specifically set this field, either in their constructors, or in + a wrapper function that calls the constructor. So, the watchpoint + type and its sub-class set this variable, as does the catchpoint type, + and all it's sub-classes. + + However, code_breakpoint doesn't specifically set this field within + its constructor, though some sub-classes of + code_breakpoint (ada_catchpoint, exception_catchpoint, + internal_breakpoint, and momentary_breakpoint) do set this field. + + When I examine all the places that breakpoint::pspace is used, I + believe that in every place where it is expected that this field is + set, the breakpoint type will be one that specifically sets this + field. + + Next, I observe two problems with the existing code. + + First, the above code is only hit for pending breakpoints, there's no + equivalent code for non-pending breakpoints. This opens up the + possibility of GDB entering non-consistent states; if a breakpoint is + first created pending and then later gets a location, the pspace field + will be set, while if the breakpoint is immediately non-pending, then + the pspace field will never be set. + + Second, if we look at how breakpoint::pspace is used in the function + breakpoint_program_space_exit, we see that when a program space is + removed, any breakpoint with breakpoint::pspace set to the removed + program space, will be deleted. This makes sense, but does mean we + need to ensure breakpoint::pspace is only set for breakpoints that + apply to a single program space. + + So, if I create a pending dprintf breakpoint (type bp_dprintf) then + the breakpoint::pspace variable will be set even though the dprintf is + not really tied to that one program space. As a result, when the + matching program space is removed the dprintf is incorrectly removed. + + Also, if I create a thread specific breakpoint, then, thanks to the + 'thread != -1' clause the wrong program space will be stored in + breakpoint::pspace (the current program space is always used, which + might not be the program space that corresponds to the selected + thread), as a result, the thread specific breakpoint will be deleted + when the matching program space is removed. + + If we look at commit cc72b2a2da6d which added the 'thread != -1' + clause, we can see this change was entirely redundant, the + breakpoint::pspace is also set in bpfinishpy_init after + create_breakpoint has been called. As such, I think we can safely + drop the 'thread != -1' clause. + + For the other problems, I'm proposing to be pretty aggressive - I'd + like to drop the breakpoint::pspace assignment completely from + create_breakpoint. Having looked at how this variable is used, I + believe that it is already set elsewhere in all the cases that it is + needed. Maybe this code was needed at one time, but I can't see how + it's needed any more. + + There's tests to expose the issues I've spotted with this code, and + there's no regressions in testing. + +2024-09-07 Andrew Burgess + + gdb: parse pending breakpoint thread/task immediately + The initial motivation for this commit was to allow thread or inferior + specific breakpoints to only be inserted within the appropriate + inferior's program-space. The benefit of this is that inferiors for + which the breakpoint does not apply will no longer need to stop, and + then resume, for such breakpoints. This commit does not make this + change, but is a refactor to allow this to happen in a later commit. + + The problem we currently have is that when a thread-specific (or + inferior-specific) breakpoint is created, the thread (or inferior) + number is only parsed by calling find_condition_and_thread_for_sals. + This function is only called for non-pending breakpoints, and requires + that we know the locations at which the breakpoint will be placed (for + expression checking in case the breakpoint is also conditional). + + A consequence of this is that by the time we figure out the breakpoint + is thread-specific we have already looked up locations in all program + spaces. This feels wasteful -- if we knew the thread-id earlier then + we could reduce the work GDB does by only looking up locations within + the program space for which the breakpoint applies. + + Another consequence of how find_condition_and_thread_for_sals is + called is that pending breakpoints don't currently know they are + thread-specific, nor even that they are conditional! Additionally, by + delaying parsing the thread-id, pending breakpoints can be created for + non-existent threads, this is different to how non-pending + breakpoints are handled, so I can do this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break foo thread 99 + Function "foo" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (foo thread 99) pending. + (gdb) r + Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + Error in re-setting breakpoint 1: Unknown thread 99. + [Inferior 1 (process 3329749) exited normally] + (gdb) + + GDB only checked the validity of 'thread 99' at the point the 'foo' + location became non-pending. In contrast, if I try this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break main thread 99 + Unknown thread 99. + (gdb) + + GDB immediately checks if 'thread 99' exists. I think inconsistencies + like this are confusing, and should be fixed if possible. + + In this commit the create_breakpoint function is updated so that the + extra_string, which contains the thread, inferior, task, and/or + condition information, is parsed immediately, even for pending + breakpoints. + + Obviously, the condition still can't be validated until the breakpoint + becomes non-pending, but the thread, inferior, and task information + can be pulled from the extra-string, and can be validated early on, + even for pending breakpoints. The -force-condition flag is also + parsed as part of this early parsing change. + + There are a couple of benefits to doing this: + + 1. Printing of breakpoints is more consistent now. Consider creating + a conditional breakpoint before this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc if (0)) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18 + stop only if (0) + (gdb) + + And after this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc + stop only if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18 + stop only if (0) + (gdb) + + Notice that the display of the condition is now the same for the + pending and non-pending breakpoints. + + The same is true for the thread, inferior, or task information in + thread, inferior, or task specific breakpoints; this information is + displayed on its own line rather than being part of the 'What' + field. + + 2. We can check that the thread exists as soon as the pending + breakpoint is created. Currently there is a weird difference + between pending and non-pending breakpoints when creating a + thread-specific breakpoint. + + A pending thread-specific breakpoint only checks its thread when it + becomes non-pending, at which point the thread the breakpoint was + intended for might have exited. Here's the behaviour before this + commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo thread 2) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2948835) exited] + Error in re-setting breakpoint 2: Unknown thread 2. + [Inferior 1 (process 2948832) exited normally] + (gdb) + + Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.' + line, this was triggered when GDB tried to make the breakpoint + non-pending, and GDB discovers that the thread no longer exists. + + Compare that to the behaviour after this commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2949243) exited] + Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list. + [Inferior 1 (process 2949240) exited normally] + (gdb) + + Now the behaviour for pending breakpoints is identical to + non-pending breakpoints, the thread specific breakpoint is removed + as soon as the thread the breakpoint is associated with exits. + + There is an additional change; when the pending breakpoint is + created prior to this patch we see this line: + + Breakpoint 2 (foo thread 2) pending. + + While after this patch we get this line: + + Breakpoint 2 (foo) pending. + + Notice that 'thread 2' has disappeared. This might look like a + regression, but I don't think it is. That we said 'thread 2' + before was just a consequence of the lazy parsing of the breakpoint + specification, while with this patch GDB understands, and has + parsed away the 'thread 2' bit of the spec. If folk think the old + information was useful then this would be trivial to add back in + code_breakpoint::say_where. + + As a result of this commit the breakpoints 'extra_string' field is now + only used by bp_dprintf type breakpoints to hold the printf format and + arguments. This string should always be empty for other breakpoint + types. This allows some cleanup in print_breakpoint_location. + + In code_breakpoint::code_breakpoint I've changed an error case into an + assert. This is because the error is now handled earlier in + create_breakpoint. As a result we know that by this point, the + extra_string will always be nullptr for anything other than a + bp_dprintf style breakpoint. + + The find_condition_and_thread_for_sals function is now no longer + needed, this was previously doing the delayed splitting of the extra + string into thread, task, and condition, but this is now all done in + create_breakpoint, so find_condition_and_thread_for_sals can be + deleted, and the code that calls this in + code_breakpoint::location_spec_to_sals can be removed. With this + update this code would only ever be reached for bp_dprintf style + breakpoints, and in these cases the extra_string should not contain + anything other than format and args. + + The most interesting changes are all in create_breakpoint and in the + new file break-cond-parse.c. We have a new block of code early on in + create_breakpoint that is responsible for splitting the extra_string + into its component parts by calling create_breakpoint_parse_arg_string + a function in the new break-cond-parse.c file. This means that some + of the later code can be simplified a little. + + The new break-cond-parse.c file implements the splitting up the + extra_string and finding all the parts, as well as some self-tests for + the new function. + + Finally, now we know all the breakpoint details, these can be stored + within the breakpoint object if we end up creating a deferred + breakpoint. Additionally, if we are creating a deferred bp_dprintf we + can parse the extra_string to build the printf command. + + The implementation here aims to maintain backwards compatibility as + much as possible, this means that: + + 1. We support abbreviations of 'thread', 'task', and 'inferior' in + some places on the breakpoint line. The handling of abbreviations + has (before this patch) been a little weird, so this works: + + (gdb) break *main th 1 + + And creates a breakpoint at '*main' for thread 1 only, while this + does not work: + + (gdb) break main th 1 + + In this case GDB will try to find the symbol 'main th 1'. This + weirdness exists before and after this patch. + + 2. The handling of '-force-condition' is odd, if this flag appears + immediately after a condition then it will be treated as part of the + condition, e.g.: + + (gdb) break main if 0 -force-condition + No symbol "force" in current context. + + But we are fine with these alternatives: + + (gdb) break main if 0 thread 1 -force-condition + (gdb) break main -force-condition if 0 + + Again, this is just a quirk of how the breakpoint line used to be + parsed, but I've maintained this for backward compatibility. During + review it was suggested that -force-condition should become an + actual breakpoint flag (i.e. only valid after the 'break' command + but before the function name), and I don't think that would be a + terrible idea, however, that's not currently a trivial change, and I + think should be done as a separate piece of work. For now, this + patch just maintains the current behaviour. + + The implementation works by first splitting the breakpoint condition + string (everything after the location specification) into a list of + tokens, each token has a type and a value. (e.g. we have a THREAD + token where the value is the thread-id string). The list of tokens is + validated, and in some cases, tokens are merged. Then the values are + extracted from the remaining token list. + + Consider this breakpoint command: + + (gdb) break main thread 1 if argc == 2 + + The condition string passed to create_breakpoint_parse_arg_string is + going to be 'thread 1 if argc == 2', which is then split into the + tokens: + + { THREAD: "1" } { CONDITION: "argc == 2" } + + The thread-id (1) and the condition string 'argc == 2' are extracted + from these tokens and returns back to create_breakpoint. + + Now consider this breakpoint command: + + (gdb) break some_function if ( some_var == thread ) + + Here the user wants a breakpoint if 'some_var' is equal to the + variable 'thread'. However, when this is initially parsed we will + find these tokens: + + { CONDITION: "( some_var == " } { THREAD: ")" } + + This is a consequence of how we have to try and figure out the + contents of the 'if' condition without actually parsing the + expression; parsing the expression requires that we know the location + in order to lookup the variables by name, and this can't be done for + pending breakpoints (their location isn't known yet), and one of the + points of this work is that we extract things like thread-id for + pending breakpoints. + + And so, it is in this case that token merging takes place. We check + if the value of a token appearing immediately after the CONDITION + token looks valid. In this case, does ')' look like a valid + thread-id. Clearly, in this case ')' does not, and so me merge the + THREAD token into the condition token, giving: + + { CONDITION: "( some_var == thread )" } + + Which is what we want. + + I'm sure that we might still be able to come up with some edge cases + where the parser makes the wrong choice. I think long term the best + way to work around these would be to move the thread, inferior, task, + and -force-condition flags to be "real" command options for the break + command. I am looking into doing this, but can't guarantee if/when + that work would be completed, so this patch should be reviewed assume + that the work will never arrive (though I hope it will). + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: create new is_thread_id helper function + This is a refactoring commit that splits the existing parse_thread_id + function into two parts, and then adds a new is_thread_id function. + + The core of parse_thread_id is split into parse_thread_id_1, which is + responsible for actually parsing a thread-id. Then parse_thread_id is + responsible for taking a parsed thread-id and validating that it + references an actually existing inferior thread. + + The new is_thread_id function also uses parse_thread_id_1, but doesn't + actually check that the inferior thread exists, instead, this new + function simply checks that a string looks like a thread-id. + + This commit does not add a use for is_thread_id, this will be added in + the next commit. + + This is a refactoring commit, there should be no user visible changes + after this commit. + +2024-09-07 Andrew Burgess + + gdb: add another overload of startswith + We already have one overload of the startswith function that takes a + std::string_view for both arguments. A later patch in this series is + going to be improved by having an overload that takes one argument as + a std::string_view and the other argument as a plain 'char *'. + + This commit adds the new overload, but doesn't make use of it (yet). + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: make breakpoint_debug_printf global + This commit makes breakpoint_debug_printf available outside of + breakpoint.c. In a later commit I'll want to use this macro from + another file. + + This is just a refactor, there should be no user visible changes after + this commit. + +2024-09-07 Tom Tromey + + Remove tui_refresh_cmd_win + tui_refresh_cmd_win is no longer needed and can be replaced with a + call to the refresh_window method. + + Remove tui_wrefresh + This removes tui_wrefresh, moving the code into refresh_window. We + remove tui_norefresh_window as well, because now the command window's + refresh_window has to do what tui_wrefresh previously did. + +2024-09-07 Tom Tromey + + Rename tui_suppress_output + This patch renames tui_suppress_output to the more descriptive + tui_batch_rendering. This code was never really correct, and was + based on a misunderstanding of the curses API. The updated comments + describe the intended use of this class. + + This also removes the erroneous tui_win_info::no_refresh. + wnoutrefresh does not prevent any output; rather, it copies from one + curses buffer to another but (unlike woutrefresh) without then + flushing to the screen. + + tui_batch_rendering now works in the correct way: calling doupdate in + the destructor of the outermost instance, thus batching all screen + output until that point. + + The patch adds instantiations of tui_batch_rendering to various spots, + to make sure it is active when refreshing. + +2024-09-07 Tom Tromey + + Clean up refreshing in TUI register window + This patch rearranges the TUI register window code a bit, removing a + call to tui_wrefresh and hoisting the calls to refresh_window to "more + outer" spots. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-07 Andrew Burgess + + gdb: 'target ...' commands now expect quoted/escaped filenames + This commit changes the 'target ...' commands that accept a filename + to take a quoted or escaped filename rather than a literal filename. + + What this means in practice is that if you are specifying a filename + that contains no white space or quote characters, then nothing should + change, e.g.: + + target exec /path/to/some/file + + works both before and after this commit. + + However, if a user wishes to specify a file containing white space + then either the entire filename needs to be quoted, or the special + white space needs to be escaped. Before this patch a user could + write: + + target exec /path/to a file/containing spaces + + But after this commit the user would have to choose one of: + + target exec "/path/to a file/containing spaces" + + or + + target exec /path/to\ a\ file/containing\ spaces + + Obviously this is a potentially breaking change. The benefit of + making this change is consistency. Commands that take multiple + arguments (one of which is a filename) or in the future, commands that + take filename options, will always need to use quoted/escaped + filenames, so converting all unquoted filename commands to use quoting + or escaping makes the UI more consistent. + + Additionally (though this is probably not a common problem), GDB + strips trailing white space from commands that the user enters. As + such it is not possible to reference any file that ends in white space + unless the quoting / escaping style is used. Though I suspect very + few users run into this problem! + + The downside obviously is that this is a UI breaking change. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: allow quoted filenames for commands that have custom completion + This commit changes how GDB processes command arguments for the + following commands: + + compile file + maint print c-tdesc + save gdb-index + + After this commit these commands will now expect their single filename + argument to be (optionally) quoted if it contains any special + characters (e.g. whit space or quotes). + + If the filename does not contain any special characters then nothing + changes. As an example: + + (gdb) save gdb-index /path/to/some/directory/ + + will work before and after this patch. However, if the directory + name contains a white space then before this patch a user would write: + + (gdb) save gdb-index /path/to some/directory/ + + But this will now fail as GDB will consider this as two arguments, + '/path/to' and 'some/directory/'. To pass this single directory name + a user must now do one of these: + + (gdb) save gdb-index "/path/to some/directory/" + (gdb) save gdb-index '/path/to some/directory/' + (gdb) save gdb-index /path/to\ some/directory/ + + This brings these commands into line with commands like 'file' and + 'symbol-file', which have supported quoted filenames for a while. + + The motivation for this change is to make handling of filename + arguments consistent throughout GDB. We can't move to all commands + taking non-quoted filenames as the non-quoted style only allows for a + single argument. Additionally, the non-quoted style doesn't allow for + filenames that end in white space (though this is probably pretty + rare). So, if we want to have consistency the only choice is to move + towards supporting quote filenames. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: add remove-symbol-file command completion + The 'remove-symbol-file' command doesn't currently offer command + completion. This commit addresses this. + + The 'remove-symbol-file' uses gdb_argv to split its command arguments, + this means that the filename the command expects can be quoted. + + However, the 'remove-symbol-file' command is a little weird in that it + also has a '-a' option, if this option is passed then the command + expects not a filename, but an address. + + Currently the remove_symbol_file_command function splits the command + args using gdb_argv, checks for a '-a' flag by looking at the first + argument value, and then expects the filename or address to occupy a + single entry in the gdb_argv array. + + The first thing I do is handle the '-a' flag using GDB's option + system. I model this option as a flag_option_def (a boolean option). + + I've dropped the use of gdb_argv and instead use the new(ish) function + extract_single_filename_arg, which was added a couple of commits back, + to parse the filename argument (when '-a' is not given). + + If '-a' is given the the remove-symbol-file command expects an address + rather than a filename. As we previously split the arguments using + gdb_argv this meant the address needed to appear as a single + argument. So a user could write: + + (gdb) remove-symbol-file 0x1234 + + Or they could write: + + (gdb) remove-symbol-file some_function + + Both of these would work fine. But a user could not write: + + (gdb) remove-symbol-file some_function + 0x1000 + + As only the 'some_function' part would be processed. Now the user + could do this: + + (gdb) remove-symbol-file "some_function + 0x1000" + + By enclosing the address expression in quotes this would be handled as + a single argument. However, this is a little weird, that's not how + commands like 'print' or 'x' work. Also this functionality was + neither documented, or tested. + + And so, in this commit, by removing the use of gdb_argv I bring the + 'remove-symbol-file' command inline with GDB's other commands that + take an expression, the quotes are no longer needed. + + Usually in a completer we call 'complete_options', but don't actually + capture the option values. But for remove-symbol-file I do. This + allows me to spot when the '-a' option has been given, I can then + complete the rest of the command line as either a filename or an + expression. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: extend completion of quoted filenames to work in brkchars phase + Up to this point filename completion for possibly quoted filenames has + always been handled during the second (non-brkchars) phase of + completion. This works fine for commands that only want to complete + on a single filename argument. + + In a later commit though I need to perform completion of a quoted + filename argument during the first (brkchars) phase of completion. + This will allow me to add a custom completer that completes both + command options and arguments for a command (remove-symbol-file) that + takes a possibly quoted filename argument. + + This commit doesn't add the remove-symbol-file completer, this commit + is just about putting support for that in place. + + To achieve this I've added the new function + advance_to_filename_maybe_quoted_complete_word_point, which is unused + in this commit. I've then had to extend some other functions in order + to extract the quoting state during the brkchars phase. + + As this commit doesn't use the new functionality, the important thing + at this point is that I've not regressed the existing filename + completion (or any of the other completion). The next commit in this + series will make use of the new functionality, and will include + tests. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: new extract_single_filename_arg helper function + This commit is in preparation for the next few commits, this commit + adds a new function extract_single_filename_arg. + + This new function will be used to convert GDB commands that expect a + single filename argument to have these commands take a possibly quoted + or escaped string. + + There's no use of the new function in this commit, for that see the + following commits. + +2024-09-07 Andrew Burgess + + gdb: implement readline rl_directory_rewrite_hook callback + Implement the readline rl_directory_rewrite_hook callback function, + this is used when readline needs to offer completions from within a + directory. The important thing is that this function should remove + any escaping, this allows GDB to correctly offer completions in + situations like this: + + (gdb) file /tmp/directory\ with\ spaces/ + + Note the escaping in 'directory\ with\ spaces'. Without the + rl_directory_rewrite_hook callback readline will try to open a + directory literally called '/tmp/directory\ with\ spaces' which + obviously doesn't exist. + + There are tests added to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: improve gdb_rl_find_completion_word for quoted words + The function gdb_rl_find_completion_word is very similar to the + readline function _rl_find_completion_word, but was either an older + version of that function, or was trimmed when copying to remove code + which was considered unnecessary. + + We maintain this copy because the _rl_find_completion_word function is + not part of the public readline API, and we need to replicate the + functionality of that function as part of the 'complete' command. + + Within gdb_rl_find_completion_word when looking for the completion + word, if we don't find a unclosed quoted string (which would become + the completion word) then we scan backwards looking for a word break + character. For example, given: + + (gdb) complete file /tmp/foo + + There is no unclosed quoted string so we end up scanning backwards + from the end looking for a word break character. In this case the + space after 'file' and before '/tmp/foo' is found, so '/tmp/foo' + becomes the completion word. + + However, given this: + + (gdb) complete file /tmp/foo\" + + There is still no unclosed quoted string, however, when we can + backwards the '"' (double quotes) are treated as a word break + character, and so we end up using the empty string as the completion + word. + + The readline function _rl_find_completion_word avoids this mistake by + using the rl_char_is_quoted_p hook. This function will return true + for the double quote character as it is preceded by a backslash. An + earlier commit in this series supplied a rl_char_is_quoted_p function + for the filename completion case, however, gdb_rl_find_completion_word + doesn't call rl_char_is_quoted_p so this doesn't help for the + 'complete' case. + + In this commit I've copied the code to call rl_char_is_quoted_p from + _rl_find_completion_word into gdb_rl_find_completion_word. + + This half solves the problem. In the case: + + (gdb) complete file /tmp/foo\" + + We do now try to complete on the string '/tmp/foo\"', however, when we + reach filename_completer we call back into readline to actually + perform filename completion. However, at this point the WORD variable + points to a string that still contains the backslash. The backslash + isn't part of the actual filename, that's just an escape character. + + Our expectation is that readline will remove the backslash when + looking for matching filenames. However, readline contains an + optimisation to avoid unnecessary work trying to remove escape + characters. + + The readline variable rl_completion_found_quote is set in the readline + function gen_completion_matches before the generation of completion + matches. This variable is set to true (non-zero) if there is (or + might be) escape characters within the completion word. + + The function rl_filename_completion_function, which generates the + filename matches, only removes escape characters when + rl_completion_found_quote is true. When GDB generates completions + through readline (e.g. tab completion) then rl_completion_found_quote + is set correctly. + + But when we use the 'complete' command we don't pass through readline, + and so gen_completion_matches is never called and + rl_completion_found_quote is not set. In this case when we call + rl_filename_completion_function readline doesn't remove the escapes + from the completion word, and so in our case above, readline looks for + completions of the exact filename '/tmp/foo\"', that is, the filename + including the backslash. + + To work around this problem I've added a new flag to our function + gdb_rl_find_completion_word which is set true when we find any quoting + or escaping. This matches what readline does. + + Then in the 'complete' function we can set rl_completion_found_quote + prior to generating completion matches. + + With this done the 'complete' command now works correctly when trying + to complete filenames that contain escaped word break characters. The + tests have been updated accordingly. + +2024-09-07 Andrew Burgess + + gdb: apply escaping to filenames in 'complete' results + Building on the mechanism added in the previous commit(s), this commit + applies escaping to filenames in the 'complete' command output. + Consider a file: /tmp/xxx/aa"bb -- that is a filename that contains a + double quote, currently the 'complete' command output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa"bb + + Notice that the double quote in the output is not escaped. If we + passed this same output back to GDB then the double quote will be + treated as the start of a string. + + After this commit then the output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa\"bb + + The double quote is now escaped. If we feed this output back to GDB + then GDB will treat this as a single filename that contains a double + quote, exactly what we want. + + To achieve this I've done a little refactoring, splitting out the core + of gdb_completer_file_name_quote, and then added a new call from the + filename_match_formatter function. + + There are updates to the tests to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: add match formatter mechanism for 'complete' command output + This commit solves a problem that existed prior to the previous + commit, but the previous commit made more common. + + When completing a filename with the 'complete' command GDB will always + add a trailing quote character, even if the completion is a directory + name, in which case it would be better if the trailing quote was not + added. Consider: + + (gdb) complete file '/tmp/xx + file '/tmp/xxx/' + + The completion offered here is really only a partial completion, we've + completed up to the end of the next directory name, but, until we have + a filename then the completion is not finished and the trailing quote + should not be added. + + This would match the readline behaviour, e.g.: + + (gdb) file '/tmp/xx + (gdb) file '/tmp/xxx/ + + In this case readline completes the directory name, but doesn't add + the trailing quote character. + + Remember that the 'complete' command is intended for tools like + e.g. emacs in order that they can emulate GDB's standard readline + completion when implementing a CLI of their own. As such, not adding + the trailing quote in this case matches the readline behaviour, and + seems like the right way to go. + + To achieve this, I've added a new function pointer member variable + completion_result::m_match_formatter. This contains a pointer to a + callback function which is used by the 'complete' command to format + each result. + + The default behaviour of this callback function is to just append the + quote character (the character from before the completion string) to + the end of the completion result. This matches the current behaviour. + + However, for filename completion we override the default value of + m_match_formatter, this new function checks if the completion result + is a directory or not. If the completion result is a directory then + the closing quote is not added, instead we add a trailing '/' + character. + + The code to add a trailing '/' character already exists within the + filename_completer function. This is no longer needed in this + location, instead this code is moved into the formatter callback. + + Tests are updated to handle the changes in functionality, this removes + an xfail added in the previous commit. + +2024-09-07 Andrew Burgess + + gdb: simplify completion_result::print_matches + Simplify completion_result::print_matches by removing one of the code + paths. Now, every time we call ::print_matches we always add the + trailing quote. + + Previously, when using the 'complete' command, if there was only one + result then trailing quote was added in ::build_completion_result, but + when we had multiple results the trailing quote was added in + ::print_matches. As a consequence, ::print_matches had to understand + not to add the trailing quote for the single result case. + + After this commit we don't add the trailing quote in + ::build_completion_result, instead ::print_matches always adds the + trailing quote, which makes ::print_matches simpler. + + However, there is a slight problem. When completion is being driven + by readline, and not by the 'complete' command, we still need to + manually add the trailing quote in the single result case, and as the + printing is done by readline we can't add the quote at the time of + printing, and so, in ::build_completion_result, we still add the + trailing quote, but only when completion is being done for readline. + + And this does cause a small problem. When completing a filename, if + the completion results in a directory name then, when using the + 'complete' command, GDB should not be adding a trailing quote. For + example, if we have the file /tmp/xxx/foo.c, then what we should see + is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/ + + But what we actually see after this commit is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/' + + Previously we didn't get the trailing quote in this case, as when + there is only a single result, the quote was added in + ::build_completion_result, and for filename completion, GDB didn't + know what the quote character was in ::build_completion_result, so no + quote was added. Now that the trailing quote is always added in + ::print_matches, and GDB does know the quote character at this point, + so we are now getting the trailing quote, which is not correct. + + This is a regression, but really, GDB is now broken in a consistent + way, if we create the file /tmp/xxa/bar.c, then previously if we did + this: + + (gdb) complete file '/tmp/xx + file '/tmp/xxa/' + file '/tmp/xxx/' + + Notice how we get the trailing quote in this case, this is the before + patch behaviour, and is also wrong. + + A later commit will fix things so that the trailing quote is not added + in this filename completion case, but for now I'm going to accept this + small regression. + + This change in behaviour caused some failures in one of the completion + tests, I've tweaked the test case to expect the trailing quote as part + of this commit, but will revert this in a later commit in this series. + + I've also added an extra test for when the 'complete' command does + complete to a single complete filename, in which case the trailing + quote is expected. + +2024-09-07 Andrew Burgess + + gdb: move display of completion results into completion_result class + This commit moves the printing of the 'complete' command results out + of the 'complete_command' function. The printing is now done in a new + member function 'completion_result::print_matches'. At this point, + this is entirely a refactor. + + The motivation for this refactor is how 'complete' should print the + completion of filename arguments. In some cases the filename results + need to have escaping added to the output. This escaping needs to be + done immediately prior to printing the result as adding too early will + result in multiple 'complete' results potentially being sorted + incorrectly. See the subsequent commits for more details. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-09-07 Andrew Burgess + + gdb: improve escaping when completing filenames + This improves quoting and escaping when completing filenames for + commands that allow filenames to be quoted and escaped. + + I've struggled a bit trying to split this series into chunks. There's + a lot of dependencies between different parts of the completion + system, and trying to get this working correctly is pretty messy. + + This first step is really about implementing 3 readline hooks: + + rl_char_is_quoted_p + - Is a particular character quoted within readline's input buffer? + rl_filename_dequoting_function + - Remove quoting characters from a filename. + rl_filename_quoting_function + - Add quoting characters to a filename. + + See 'info readline' for full details, but with these hooks connected + up, readline (on behalf of GDB) should do a better job inserting + backslash escapes when completing filenames. + + There's still a bunch of stuff that doesn't work after this commit, + mostly around the 'complete' command which of course doesn't go + through readline, so doesn't benefit from all of these new functions + yet, I'll add some of this in a later commit. + + Tab completion is now slightly improved though, it is possible to + tab-complete a filename that includes a double or single quote, either + in an unquoted string or within a string surrounded by single or + double quotes, backslash escaping is used when necessary. + + There are some additional tests to cover the new functionality. + +2024-09-07 Andrew Burgess + + gdb: deprecated filename_completer and associated functions + Following on from the previous commit, this commit marks the old + unquoted filename completion related functions as deprecated. + + The aim of doing this is to make it more obvious to someone adding a + new command that they should not be using the older unquoted style + filename argument handling. + + I split this change from the previous to make for an easier review. + This commit touches more files, but is _just_ function renaming. + Check out gdb/completer.{c,h} for what has been renamed. All the + other files have just been updated to use the new names. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: split apart two different types of filename completion + Unfortunately we have two different types of filename completion in + GDB. + + The majority of commands have what I call unquoted filename + completion, this is for commands like 'set logging file ...', 'target + core ...', and 'add-auto-load-safe-path ...'. For these commands + everything after the command name (that is not a command option) is + treated as a single filename. If the filename contains white space + then this does not need to be escaped, nor does the filename need to + be quoted. In fact, the filename argument is not de-quoted, and does + not have any escaping removed, so if a user does try to add such + things, they will be treated as part of the filename. As an example: + + (gdb) target core "/path/that contains/some white space" + + Will look for a directory calls '"' (double quotes) in the local + directory. + + A small number of commands do de-quote and remove escapes from + filename arguments. These command accept what I call quoted and + escaped filenames. Right now these are the commands that specify the + file for GDB to debug, so: + + file + exec-file + symbol-file + add-symbol-file + remove-symbol-file + + As an example of this in action: + + (gdb) file "/path/that contains/some white space" + + In this case GDB would load the file: + + /path/that contains/some white space + + Current filename completion always assumes that filenames can be + quoted, though escaping doesn't work in completion right now. But the + assumption that quoting is allowed is clearly wrong. + + This commit splits filename completion into two. The existing + filename_completer is retained, and is used for unquoted filenames. A + second filename_maybe_quoted_completer is added which can be used for + completing quoted filenames. + + The filename completion test has been extended to cover more cases. + As part of the extended testing I need to know the character that + should be used to separate filenames within a path. For this TCL 8.6+ + has $::tcl_platform(pathSeparator). To support older versions of TCL + I've added some code to testsuite/lib/gdb.exp. + + You might notice that after this commit the completion for unquoted + files is all done in the brkchars phase, that is the function + filename_completer_handle_brkchars calculates the completions and + marks the completion_tracker as using a custom word point. The reason + for this is that we don't want to break on white space for this + completion, but if we rely on readline to find the completion word, + readline will consider the entire command line, and with no white + space in the word break character set, readline will end up using the + entire command line as the word to complete. + + For now at least, the completer for quoted filenames does generate its + completions during the completion phase, though this is going to + change in a later commit. + +2024-09-07 Andrew Burgess + + gdb: unify build-id to objfile lookup code + There are 3 places where we currently call debuginfod_exec_query to + lookup an objfile for a given build-id. + + In one of these places we first call build_id_to_exec_bfd which also + looks up an objfile given a build-id, but this function looks on disk + for a symlink in the .build-id/ sub-directory (within the + debug-file-directory). + + I can't think of any reason why we shouldn't call build_id_to_exec_bfd + before every call to debuginfod_exec_query. + + So, in this commit I have added a new function in build-id.c, + find_objfile_by_build_id, this function calls build_id_to_exec_bfd, + and if that fails, then calls debuginfod_exec_query. + + Everywhere we call debuginfod_exec_query is updated to call the new + function, and in locate_exec_from_corefile_build_id, the existing call + to build_id_to_exec_bfd is removed as calling find_objfile_by_build_id + does this for us. + + One slight weird thing is in core_target::build_file_mappings, here we + call find_objfile_by_build_id which returns a gdb_bfd_ref_ptr for the + opened file, however we immediately reopen the file as "binary". The + reason for this is that all the bfds opened in ::build_file_mappings + need to be opened as "binary" (see the function comments for why). + + I did consider passing a target type into find_objfile_by_build_id, + which could then be forwarded to build_id_to_exec_bfd and used to open + the BFD as "binary", however, if you follow the call chain you'll end + up in build_id_to_debug_bfd_1, where we actually open the bfd. Notice + in here that we call build_id_verify to double check the build-id of + the file we found, this requires that the bfd not be opened as + "binary". + + What this means is that we always have to first open the bfd using the + gnutarget target type (for the build-id check), and then we would have + to reopen it as "binary". There seems little point pushing the reopen + logic into find_objfile_by_build_id, so we just do this in the + ::build_file_mappings function. + + I've extended the tests to cover the two cases which actually changed + in this commit. + +2024-09-07 Andrew Burgess + + gdb: improve shared library build-id check for core-files + When GDB opens a core file, in 'core_target::build_file_mappings ()', + we collection information about the files that are mapped into the + core file, specifically, the build-id and the DT_SONAME attribute for + the file, which will be set for some shared libraries. + + We then cache the DT_SONAME to build-id information on the core file + bfd object in the function set_cbfd_soname_build_id. + + Later, when we are loading the shared libraries for the core file, we + can use the library's file name to look in the DT_SONAME to build-id + map, and, if we find a matching entry, we can use the build-id to + validate that we are loading the correct shared library. + + This works OK, but has some limitations: not every shared library will + have a DT_SONAME attribute. Though it is good practice to add such an + attribute, it's not required. A library without this attribute will + not have its build-id checked, which can lead to GDB loading the wrong + shared library. + + What I want to do in this commit is to improve GDB's ability to use + the build-ids extracted in core_target::build_file_mappings to both + validate the shared libraries being loaded, and then to use these + build-ids to potentially find (via debuginfod) the shared library. + + To do this I propose making the following changes to GDB: + + (1) Rather than just recording the DT_SONAME to build-id mapping in + set_cbfd_soname_build_id, we should also record, the full filename to + build-id mapping, and also the memory ranges to build-id mapping for + every memory range covered by every mapped file. + + (2) Add a new callback solib_ops::find_solib_addr. This callback + takes a solib object and returns an (optional) address within the + inferior that is part of this library. We can use this address to + find a mapped file using the stored memory ranges which will increase + the cases in which a match can be found. + + (3) Move the mapped file record keeping out of solib.c and into + corelow.c. Future commits will make use of this information from + other parts of GDB. This information was never solib specific, it + lived in the solib.c file because that was the only user of the data, + but really, the data is all about the core file, and should be stored + in core_target, other parts of GDB can then query this data as needed. + + Now, when we load a shared library for a core file, we do the + following lookups: + + 1. Is the exact filename of the shared library found in the filename + to build-id map? If so then use this build-id for validation. + + 2. Find an address within the shared library using ::find_solib_addr + and then look for an entry in the mapped address to build-id map. + If an entry is found then use this build-id. + + 3. Finally, look in the soname to build-id map. If an entry is + found then use this build-id. + + The addition of step #2 here means that GDB is now far more likely to + find a suitable build-id for a shared library. Having acquired a + build-id the existing code for using debuginfod to lookup a shared + library object can trigger more often. + + On top of this, we also create a build-id to filename map. This is + useful as often a shared library is implemented as a symbolic link to + the actual shared library file. The mapped file information is stored + based on the actual, real file name, while the shared library + information holds the original symbolic link file name. + + If when loading the shared library, we find the symbolic link has + disappeared, we can use the build-id to file name map to check if the + actual file is still around, if it is (and if the build-id matches) + then we can fall back to use that file. This is another way in which + we can slightly increase the chances that GDB will find the required + files when loading a core file. + + Adding all of the above required pretty much a full rewrite of the + existing set_cbfd_soname_build_id function and the corresponding + get_cbfd_soname_build_id function, so I have taken the opportunity to + move the information caching out of solib.c and into corelow.c where + it is now accessed through the function core_target_find_mapped_file. + + At this point the benefit of this move is not entirely obvious, though + I don't think the new location is significantly worse than where it + was originally. The benefit though is that the cached information is + no longer tied to the shared library loading code. + + I already have a second set of patches (not in this series) that make + use of this caching from elsewhere in GDB. I've not included those + patches in this series as this series is already pretty big, but even + if those follow up patches don't arrive, I think the new location is + just as good as the original location. + + Rather that caching the information within the core file BFD via the + registry mechanism, the information used for the mapped file lookup is + now stored within the core_file target directly. + +2024-09-07 Andrew Burgess + + gdb/corefile: improve file backed mapping handling + This commit improves how GDB handles file backed mappings within a + core file, specifically, this is a restructuring of the function + core_target::build_file_mapping. + + The primary motivation for this commit was to put in place the + infrastructure to support the next commit in this series, but this + commit does itself make some improvements. + + Currently in core_target::build_file_mapping we use + gdbarch_read_core_file_mappings to iterate over the mapped regions + within a core file. + + For each region a callback is invoked which is passed details of the + mapping; the file the mapping is from, the offset into the file, and + the address range at which the mapping exists. We are also passed the + build-id for the mapped file in some cases. + + We are only told the build-id for the mapped region which actually + contains the ELF header of the mapped file. Other regions of the same + mapped ELF will not have the build-id passed to the callback. + + Within core_target::build_file_mapping, in the per-region callback, we + try to find the mapped file based on its filename. If the file can't + be found, and if we have a build-id then we'll ask debuginfod to + download the file. + + However we find the file, we cache the opened bfd object, which is + good. Subsequent mappings from the same file will not have a build-id + set, but by that point we already have a cached open bfd object, so + the lack of build-id is irrelevant. + + The problem with the above is that if we find a matching file based on + the filename, then we accept that file, even if we have a build-id, + and the build-id doesn't match. + + Currently, the mapped region processing is done in a single pass, we + call gdbarch_read_core_file_mappings, and for each mapping, as we see + it, we create the data structures needed to represent that mapping. + + In this commit, I will change this to a two phase process. In the + first phase the mappings are grouped together based on the name of the + mapped file. At the end of phase one we have a 'struct mapped_file', + a new struct, for each mapped file. This struct associates an + optional build-id with a list of mapped regions. + + In the second phase we try to find the file using its filename. If + the file is found, and the 'struct mapped_file' has a build-id, then + we'll compare the build-id with the file we found. This allows us to + reject on-disk files which have changed since the core file was + created. + + If no suitable file was found (either no file found, or a build-id + mismatch) then we can use debuginfod to potentially download a + suitable file. + + NOTE: In the future we could potentially add additional sanity + checks here, for example, if a data-file is mapped, and has no + build-id, we can estimate a minimum file size based on the expected + mappings. If the file we find is not big enough then we can reject + the on-disk file. But I don't know how useful this would actually + be, so I've not done that for now. + + Having found (or not) a suitable file then we can create the data + structures for each mapped region just as we did before. + + The new functionality here is the extra build-id check, and the + possibility of rejecting an on-disk file if the build-id doesn't + match. + + This change could have been done within the existing single phase + approach I think, however, in the next approach I need to have all the + mapped regions associated with the expected build-id, and the new two + phase structure allows me to do that, this is the reason for such an + extensive rewrite in this commit. + + There's a new test that exercises GDB's ability to find mapped files + via the build-id, and this downloading from debuginfod. + +2024-09-07 Andrew Burgess + + gdb/corefile: don't pretend unavailable sections are readable + When GDB opens a core file the bfd library processes the core file and + creates sections within the bfd object to represent each of the + segments within the core file. + + GDB then creates two target_section lists, m_core_section_table and + m_core_file_mappings, these, along with m_core_unavailable_mappings, + are used by GDB to implement core_target::xfer_partial; this is the + function used when GDB tries to read memory from a core file inferior. + + The m_core_section_table list represents sections within the core file + itself. The sections in this list can be split into two groups based + on whether the section has the SEC_HAS_CONTENTS flag set or not. + + Sections (from the core file) that have the SEC_HAS_CONTENTS flag had + their contents copied into the core file when the core file was + created. These correspond to writable sections within the original + inferior (the inferior for which the core file was created). + + Sections (from the core file) that do not have the SEC_HAS_CONTENTS + flag will not have had their contents copied into the core file when + it was created. These sections correspond to read-only sections + mapped from a file (possibly the initial executable, or possibly some + other file) in the original inferior. The expectation is that the + contents of these sections can still be found by looking in the file + that was originally mapped. + + The m_core_file_mappings list is created when GDB parses the mapped + file list in the core file. Every mapped region will be covered by + entries in the m_core_section_table list (see above), but for + read-only mappings the entry in m_core_section_table will not have the + SEC_HAS_CONTENTS flag set. As GDB parses the mapped file list, if the + file that was originally mapped can be found, then GDB creates an + entry in the m_core_file_mappings list which represents the region + of the file that was mapped into the original inferior. + + However, GDB only creates entries in m_core_file_mappings if it is + able to find the correct on-disk file to open. If the file can't be + found then an entry is added to m_core_unavailable_mappings instead. + + If is the handling m_core_unavailable_mappings which I think is + currently not completely correct. + + When a read lands within an m_core_unavailable_mappings region we + currently forward the read to the exec file stratum. The reason for + this is this: when GDB read the mapped file list, if the executable + file could not be found at the expected path then mappings within the + executable will end up in the m_core_unavailable_mappings list. + + However, the user might provide the executable to GDB from a different + location. If this happens then forwarding the read to the exec file + stratum might give a result. + + But, if the exec file stratum does not resolve the access then + currently we continue through ::xfer_partial, the next step of which + is to handle m_core_section_table entries that don't have the + SEC_HAS_CONTENTS flag set. Every m_core_unavailable_mappings entry + will naturally have an m_core_section_table without the + SEC_HAS_CONTENTS flag set, and so we treat the unavailable mapping as + zero initialised memory and return all zeros. + + It is this fall through behaviour that I think is wrong. If a read + falls in an unavailable region, and the exec file stratum cannot help, + then I think the access should fail. + + To achieve this goal I have removed the xfer_memory_via_mappings + helper function and moved its content inline into ::xfer_partial. + Now, if an access is within an m_core_unavailable_mappings region, and + the exec file stratum doesn't help, we immediately return with an + error. + + The reset of ::xfer_partial is unchanged, I've extended some comments + in the area that I have changed to (I hope) explain better what's + going on. + + There's a new test that covers the new functionality, an inferior maps + a file and generates a core file. We then remove the mapped file, + load the core file and try to read from the mapped region. The + expectation is that GDB should give an error rather than claiming that + the region is full of zeros. + +2024-09-07 Xin Wang + + Not append rela for absolute symbol + LoongArch: Not append rela for absolute symbol + + Use la.global to get absolute symbol like la.abs. + la.global put address of a global symbol into a got + entry and append a rela for it, which will be used + to relocate by dynamic linker. Dynamic linker should + not relocate for got entry of absolute symbol as it + stores symval not symbol's address. + +2024-09-07 Xin Wang + + Add macros to get opcode of instructions approriately + LoongArch: Add macros to get opcode and register of instructions appropriately + + Currently, we get opcode of an instruction by manipulate the binary with + it's mask, it's a bit of a pain. Now a macro is defined to do this and a + macro to get the RD and RJ registers which is applicable to most instructions + of LoongArch are added. + +2024-09-07 GDB Administrator + + Automatic date update in version.in + +2024-09-06 Vladimir Mezentsev + + Rename gp-* man pages to gprofng-* man pages + gprofng/ChangeLog + 2024-09-05 Vladimir Mezentsev . + + * doc/gp-archive.texi: Rename to doc/gprofng-archive.texi. + * doc/gp-collect-app.texi: Rename to doc/gprofng-collect-app.texi. + * doc/gp-display-html.texi: Rename to doc/gprofng-display-html.texi. + * doc/gp-display-src.texi: Rename to doc/gprofng-display-src.texi. + * doc/gp-display-text.texi: Rename to doc/gprofng-display-text.texi. + * doc/gp-macros.texi: Add new macros. + * doc/gprofng.texi: Rename man pages. + * doc/gprofng_ug.texi: Likewise. + * doc/Makefile.am: Likewise. + * doc/Makefile.in: Rebuild. + +2024-09-06 Tom Tromey + + Fix 'catch exception' with -flto + A user noticed that when an Ada program (including the runtime) is + compiled with -flto, then "catch exception" does not work -- even + though setting the equivalent breakpoint by hand does work. + + Looking into this, it turns out that GCC puts the exception functions + from the Ada runtime into a CU that uses the C language, not Ada. + Then, when trying to look up the relevant symbol, + lookup_name_info::search_name_hash uses the "verbatim" form of the + symbol name (like "<__gnat_debug_raise_exception>") rather than the + "<>"-less form, causing the symbol not to be found. + + This patch fixes the problem in two steps. + + First, lookup_name_info::search_name_hash is changed to use the same + hack that language_defn::get_symbol_name_matcher uses. That is, when + the current language is Ada, verbatim-mode lookups are special-cased. + (This is a bit unfortunate; perhaps a better long term approach would + be to promote verbatim mode to a fundamental mode of + lookup_name_info.) + + Second, although the above fixes the problem in the Ada language mode, + the code still fails in other languages. However, due to the way + these lookups are coded in ada-lang.c, I think it makes sense to + temporarily set the current language to Ada in + create_ada_exception_catchpoint. + + Tested on x86-64 Fedora 38. + + A new test case that mimics the -flto scenario is included. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-06 Tom Tromey + + Clear Ada symbol cache + This patch changes "maint flush symbol-cache" to also flush the + Ada-specific symbol cache. This can be helpful when working on the + Ada code. + + Approved-By: Tom de Vries + +2024-09-06 Tom Tromey + + Test -fgnat-encodings=all in tagged_access.exp + While working on a longer series, I needed to make sure this + particular test kept working with -fgnat-encodings=all, so this patch + adds it to the test. + + Introduce and use foreach_gnat_encoding + gnat-llvm does not support the -fgnat-encodings flag. This patch + prepares gdb's Ada tests to handle this situation by introducing a new + foreach_gnat_encoding. A subsequent patch may change this to support + gnat-llvm; meanwhile this is a little cleaner anyway. + +2024-09-06 Bernd Edlinger + + Fix the build-id option for GCC default configuration + It is possible that the compiler is configured to do + so automatically, but at least for GCC the configure option + --enable-linker-build-id is not enabled by default. + So the option -Wl,--build-id should be used regardless + of which compiler is used. + + Approved-By: Tom de Vries + +2024-09-06 Shahab Vahedi + + bfd: Fix GCC warning when CFLAGS="-Og" is used + This patch initializes the "op" variable in skip_cfa_op() function + of bfd/elf-eh-frame.c to "0" at its declaration point to avoid the + "maybe-uninitialized" warning. + + Building binutils on a system with GCC version 13.2.0 and a configure + command that sets the optimization level to "-Og" leads to a build + failure because of a warning being treated as an error: + --------------------------------------------------------------------- + $ ./configure CFLAGS="-Og" + $ make + ... + CC elf-eh-frame.lo + /src/gdb/bfd/elf-eh-frame.c: In function 'skip_cfa_op': + /src/gdb/bfd/elf-eh-frame.c:354:33: error: 'op' may be used + uninitialized [-Werror=maybe-uninitialized] + 354 | switch (op & 0xc0 ? op & 0xc0 : op) + | ~~~~~~~~~~~~~~~~~~~~~~^~~~ + /src/gdb/bfd/elf-eh-frame.c:348:12: note: 'op' was declared here + 348 | bfd_byte op; + | ^~ + cc1: all warnings being treated as errors + ... + --------------------------------------------------------------------- + + The relevant code snippet related to this warning looks like: + --------------------------------------------------------------------- + static inline bool + read_byte (bfd_byte **iter, bfd_byte *end, unsigned char *result) + { + if (*iter >= end) + return false; + *result = *((*iter)++); + return true; + } + + static bool + skip_cfa_op (bfd_byte **iter, bfd_byte *end,...) + { + bfd_byte op; + + if (!read_byte (iter, end, &op)) + return false; + + switch (op & 0xc0 ? op & 0xc0 : op) + ... + } + --------------------------------------------------------------------- + + This warning probably happens because "-Og" results in GCC not + inlining the "read_byte()" function. Therefore, GCC treats its + invocation inside "skip_cfa_op()" like a black box and that ends + in the aforementioned warning. + + Acknowledgement: + Lancelot Six -- for coming with the idea behind this fix. + Jan Beulich -- for reviewing. + + bfd/ChangeLog: + * elf-eh-frame.c (skip_cfa_op): Initialize the "op" variable. + +2024-09-06 Jan Beulich + + x86/APX: use D for 2-operand CFCMOVcc + There's no need to have 30 redundant templates when we can easily take + care of the operand swapping like we do for various other insns. + + x86/APX: optimize certain reg-only CFCMOVcc forms + Along the lines of 2513312930b2 ("x86/APX: apply NDD-to-legacy + transformation to further CMOVcc forms") these can similarly be + converted to the shorter legacy-encoded CMOVcc. + + bfd/PE: correct SizeOfImage calculation + We don't really want to align the last section's size to object + alignment (when that section may itself not be aligned as much), we want + image size to be a multiple thereof. + + x86: templatize VNNI templates + Reduce redundancy, in preparation of the addition of further counterparts + for AVX10.2. + +2024-09-06 GDB Administrator + + Automatic date update in version.in + +2024-09-05 Mark Harmstone + + bfd/pdb: fix -Wmaybe-uninitialized warning + Initialize stream0_start to fix spurious -Wmaybe-uninitialized warning + on some versions of gcc. + +2024-09-05 Alan Modra + + PR32136, Use-of-uninitialized-memory in evax_bfd_print_image + PR 32136 + * vms-alpha.c (evax_bfd_print_image): Sanity check various string + lengths. + +2024-09-05 Thiago Jung Bauermann + + gdbserver: aarch64: Fix expedited registers list + Since this commit: + + commit a8651ef51822f91ec86d0d5caffbf2e50b174c23 + CommitDate: Fri Jun 14 14:47:38 2024 +0100 + + gdb/aarch64: prevent crash from in process agent + + gdbserver isn't sending expedited registers with its stop reply packets + anymore. The problem is with how the constructor of the + expedited_registers std::vector is called: + + The intent of the expedited_registers initialization in + aarch64_linux_read_description is to create a vector with capacity for 6 + elements, but that's not how the std::vector constructor works. + + Instead it creates a vector pre-populated with 6 elements initialized + with the default value for the type of the elements, and thus the first + 6 elements are null pointers. The actual expedited registers are added + starting at the 7th element. + + This causes init_target_desc to consider that the expedite_regs list is + empty, since it stops checking at the first nullptr element. The end + result is that gdbserver doesn't send any expedited registers to GDB in + its stop replies. + + Fix by not specifying an element count when declaring the vector. + + Tested for regressions on aarch64-linux-gnu native-extended-remote. + + Approved-By: Andrew Burgess + +2024-09-05 Lulu Cai + + LoongArch: Fixed ABI v1.00 TLS dynamic relocation generation bug + Commit "b67a17aa7c0c478a" modified the logic of allocating dynamic + relocation space for TLS GD/IE, but only modified the logic of + generation dynamic relocations for TLS GD/IE in ABI v2.00. When + linking an object file of ABI v1.00 with bfd ld of ABI v2.00, it + will cause an assertion failure. + + Modified the dynamic relocation generation logic of TLS GD/IE + in ABI v1.00 to be consistent with ABI v2.00. + +2024-09-05 GDB Administrator + + Automatic date update in version.in + +2024-09-04 Vladimir Mezentsev + + Fix 32097 Warnings when building gprofng with Clang + gprofng/ChangeLog + 2024-09-03 Vladimir Mezentsev . + + PR gprofng/32097 + * common/hwcdrv.c: Fix -Wempty-body warnings. + * common/hwcentry.h: Fix -Wdeprecated-non-prototype warnings. + * common/hwctable.c: Fix -Wdeprecated-non-prototype warnings. + * libcollector/collector.c: Likewise. + * libcollector/collector.h: Likewise. + * libcollector/collectorAPI.c: Likewise. + * libcollector/dispatcher.c: Likewise. + * libcollector/iotrace.c: Likewise. + * libcollector/libcol_util.c: Fix -Wunused-but-set-variable warnings. + * libcollector/libcol_util.h: Remove unused declarations. + * libcollector/linetrace.c: Fix -Wdeprecated-non-prototype warnings. + * src/BaseMetricTreeNode.h: Fix -Wunused-private-field warnings. + * src/Dbe.cc: Fix -Wself-assign warnings. + * src/DbeSession.cc: Fix -Wunused-but-set-variable warnings. + * src/Disasm.cc: Fix -Wunused-const-variable warnings. + * src/Experiment.cc: Fix -Wunused-private-field warnings. + * src/HashMap.h: Fix -Wself-assign warnings. + * src/IOActivity.h: Fix -Wunused-private-field warnings. + * src/collctrl.cc: Fix -Wself-assign, -Wparentheses-equality warnings. + * src/collctrl.h: Fix -Wunused-private-field warnings. + * src/collector_module.h: Fix -Wdeprecated-non-prototype warnings. + * src/gp-display-src.cc: Fix -Wunused-private-field warnings. + * src/gp-print.h: Fix -Wheader-guard warnings. + * src/hwc_intel_icelake.h: Fix -Winitializer-overrides warnings. + * src/util.cc: Fix -Wunused-but-set-variable warnings. + +2024-09-04 Tom Tromey + + Improve comments in dwarf2/parent-map.h + I noticed that the comments for class parent_map aren't very clear. + This patch attempts to fix this, and also clarifies a point on + parent_map_map::add_map. + + Approved-By: Simon Marchi + +2024-09-04 Andrew Burgess + + gdb: reformat Python file with black + Fix formatting of a Python file added in commit: + + commit a92e943014f5e8d6a2eaccaf8a725941ac47a121 + Date: Wed Aug 14 15:16:46 2024 +0100 + + gdb: implement ::re_set method for catchpoint class + + No functional change after this commit. + +2024-09-04 Andrew Burgess + + libiberty: sync with gcc + This syncs binutils-gdb/libiberty with gcc/libiberty up to GCC commit + 64028d626a50410dbf29. This picks up the follow 3 GCC commits: + + ea238096883 (gcc-delete-unused-func) libiberty/argv.c: remove only_whitespace + 5e1d530da87 (gcc-buildargv) libiberty/buildargv: handle input consisting of only white space + a87954610f5 libiberty/buildargv: POSIX behaviour for backslash handling + +2024-09-04 Andrew Burgess + + gdb: implement ::re_set method for catchpoint class + It is possible to attach a condition to a catchpoint. This can't be + done when the catchpoint is created, but can be done with the + 'condition' command, this is documented in the GDB manual: + + You can also use the 'if' keyword with the 'watch' command. The + 'catch' command does not recognize the 'if' keyword; 'condition' is the + only way to impose a further condition on a catchpoint. + + A GDB crash was reported against Fedora GDB where a user had attached + a condition to a catchpoint and then restarted the inferior. When the + catchpoint was hit GDB would immediately segfault. I was able to + reproduce the failure on upstream GDB: + + (gdb) file ./some/binary + (gdb) catch syscall write + (gdb) run + ... + Catchpoint 1 (returned from syscall write), 0x00007ffff7b594a7 in write () from /lib64/libc.so.6 + (gdb) condition 1 $_streq((char *) $rsi, "foobar") == 0 + (gdb) run + ... + Fatal signal: Segmentation fault + ... + + What happened here is that on the system in question we had debug + information available for both the main application and also for + libc. + + When the condition was attached GDB was stopped inside libc and as the + debug information was available GDB found a reference to the 'char' + type (for the cast) inside libc's debug information. + + When the inferior is restarted GDB discards all of the objfiles + associated with shared libraries, and this includes libc. As such the + 'char' type, which is objfile owned, is discarded and the reference to + it from the catchpoint's condition expression becomes invalid. + + Now, if it were a breakpoint instead of a catchpoint, what would + happen is that after the shared library objfiles had been discarded + we'd call the virtual breakpoint::re_set method on the breakpoint, and + this would update the breakpoint's condition expression. This is + because user breakpoints are actually instances of the code_breakpoint + class and the code_breakpoint::re_set method contains the code to + recompute the breakpoint's condition expression. + + However, catchpoints are instances of the catchpoint class which + inherits from the base breakpoint class. The catchpoint class does + not override breakpoint::re_set, and breakpoint::re_set is empty! + + The consequence of this is that catchpoint condition expressions are + never recomputed, and the dangling pointer to the now deleted, objfile + owned type 'char' is left around, and, when the catchpoint is hit, the + invalid pointer is used when GDB tries to evaluate the condition + expression. + + In this commit I have implemented catchpoint::re_set. This is pretty + simple and just recomputes the condition expression as you'd expect. + If the condition doesn't evaluate then the catchpoint is marked as + disabled_by_cond. + + I have also made breakpoint::re_set pure virtual. With the addition + of catchpoint::re_set every sub-class of breakpoint now implements the + ::re_set method, and if new sub-classes are added in the future I + think that they _must_ implement ::re_set in order to avoid this + problem. As such falling back to an empty breakpoint::re_set doesn't + seem helpful. + + For testing I have not relied on stopping in libc and having libc + debug information available, this doesn't seem like a good idea for + the GDB testsuite. Instead I create a (rather pointless) condition + check that uses a type defined only within a shared library. When the + inferior is restarted the catchpoint will temporarily be marked as + disabled_by_cond (due to the type not being available), but once the + shared library is loaded again the catchpoint will be re-enabled. + Without the fixes above then the same crashing behaviour can be + observed. + + One point of note: the dangling pointer of course exposes undefined + behaviour, with no guarantee of a crash. Though a crash is what I + usually see I have see GDB throw random errors from the expression + evaluation code, and once, I saw no problem at all! If you recompile + GDB with the address sanitizer, or run under valgrind, then the bug + will be exposed every time. + + After fixing this bug I checked bugzilla and found PR gdb/29960 which + is the same bug. I was able to reproduce the bug before this commit, + and after this commit GDB is no longer crashing. + + Before: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + [Inferior 1 (process 1101855) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) run + Starting program: /tmp/hello.x + + Fatal signal: Segmentation fault + ... + + And after: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + Args: ( 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 ) + [Inferior 1 (process 1102373) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) r + Starting program: /tmp/hello.x + Error in testing condition for breakpoint 1: + Attempt to extract a component of a value that is not a structure. + + Catchpoint 1 (call to syscall write), 0x00007ffff7eb94a7 in write () + from /lib64/libc.so.6 + (gdb) ptype write + type = () + (gdb) + + Notice we get the error now when the condition fails to evaluate. + This seems reasonable given that 'write' will be a function, and + indeed the final 'ptype' shows that it's a function, not a struct. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29960 + + Reviewed-By: Tom de Vries + +2024-09-04 Christophe Lyon + + Revert "contrib: Add autoregen.py" + This reverts commit e1ad04ad6cd43fb5a876d787da5ac29f72a9c7e5. + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/riscv-tdesc-regs.exp + On riscv64-linux, with test-case gdb.arch/riscv-tdesc-regs.exp I get: + ... + (gdb) info registers fflags^M + fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers fflags + info registers frm^M + frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers frm + ... + + The FAILs are produced by: + ... + foreach reg {fflags frm} { + gdb_test_multiple "info registers $reg" "" { + -re "^info registers $reg\r\n" { + exp_continue + } + + -wrap -re "^Invalid register `$reg`" { + fail $gdb_test_name + } + + -wrap -re "^$reg\\s+\[^\r\n\]+" { + pass $gdb_test_name + } + } + } + ... + + The first clause is meant to consume the command. + + The '^' char was updated to mean "consume command", so that clause no longer + works since it now attempts to consume the command twice. + + Also, it's unnecessary because the following clauses start with ^. + + Then, the second clause is unnecessary because there's a default clause + producing the FAIL. + + Fix this by simplifying to: + ... + foreach reg {fflags frm} { + gdb_test "info registers $reg" "^$reg\\s+\[^\r\n\]+" + } + ... + + Tested on riscv64-linux. + + Approved-By: Andrew Burgess + +2024-09-04 Christophe Lyon + + arm: Do not insert stubs needing Arm code on Thumb-only cores. + We recently fixed a bug in libgcc + (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360) + where a symbol was missing a %function .type decoration. + + This meant the linker would silently pick the wrong type of 'farcall + stub', involving Arm-mode instructions on Thumb-only CPUs. + + This patch emits an error instead, and warns in some other cases, to + encourage users to add the missing '.type foo,%function' directive. + + In practice: in arm_type_of_stub() we no longer try to infer which + stub to use if the destination is of unknown type and the CPU is + Thumb-only; so we won't lie to elf32_arm_size_stubs() which does not + check branch_type. + + If branch_type is ST_BRANCH_TO_ARM but the CPU is Thumb-only, we now + convert it to ST_BRANCH_TO_THUMB only if the destination is of + absolute type. This is to support the case where the destination of + the branch is defined by the linker script (see thumb-b-lks-sym.s and + thumb-bl-lks-sym.s testcases for instance). + + The motivating case is covered by the new farcall-missing-type + testcase, where we now emit an error message. We do not emit an error + when branch_type is ST_BRANCH_UNKNOWN and the CPU supports Arm-mode: a + lot of legacy code (e.g. newlib's crt0.S) lacks the corresponding + '.type foo, %function' directives and even a (too verbose) warning + could be perceived as a nuisance. + + Existing testcases where such a warning would trigger: + arm-static-app.s (app_func, app_func2) + arm-rel32.s (foo) + arm-app.s (app_func) + rel32-reject.s () main) + fix-arm1176.s (func_to_branch_to) + but this list is not exhaustive. + + For the sake of clarity, the patch replaces occurrences of + sym.st_target_internal = 0; with + sym.st_target_internal = ST_BRANCH_TO_ARM; + + enum arm_st_branch_type is defined in include/elf/arm.h, and relies on + ST_BRANCH_TO_ARM==0, as sym.st_target_internal is also initialized to + 0 in other target-independent parts of BFD code. (For instance, + swapping the ST_BRANCH_TO_ARM and ST_BRANCH_TO_THUMB entries in the + enum definition leads to 'interesting' results...) + + Regarding the testsuite: + * new expected warning for thumb-b-lks-sym and thumb-bl-lks-sym + * new testcase farcall-missing-type to check the new error case + * attr-merge-arch-2b.s, branch-futures (and bfs-1.s) updated to avoid + a diagnostic + + Tested on arm-eabi and arm-pe with no regression. + +2024-09-04 Christophe Lyon + + contrib: Add autoregen.py + This script is a copy of the current script used by Sourceware's + autoregen buildbots. + + It is intended as a helper to regenerate files managed by autotools + (autoconf, automake, aclocal, ....), as well as the toplevel + Makefile.in which is created by autogen. + + Other files can be updated when using maintainer-mode, but this is not + covered by this script. + + 2024-04-19 Christophe Lyon + + contrib/ + * autoregen.py: New script. + +2024-09-04 Shahab Vahedi + + MAINTAINERS: Update my email address + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linux + With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into: + ... + (gdb) break bar_label^M + Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M + (gdb) continue^M + Continuing.^M + ^M + Breakpoint 2, bar () at dw2-lines.c:29^M + 29 foo (2);^M + (gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\) + ... + + The pass is incorrect because the continue lands at line 29 with "foo (2)" + instead of line line 27 with "foo (1)". + + A minimal version is: + ... + $ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label" + Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29. + ... + where: + ... + 000004ec : + 4ec: b580 push {r7, lr} + 4ee: af00 add r7, sp, #0 + + 000004f0 : + 4f0: 2001 movs r0, #1 + 4f2: f7ff fff1 bl 4d8 + + 000004f6 : + 4f6: 2002 movs r0, #2 + 4f8: f7ff ffee bl 4d8 + ... + + So, how does this happen? In short: + - skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec, + - thumb_analyze_prologue returns 0x4f2 + (overshooting by 1 insn, PR tdep/31981), and + - skip_prologue_sal decides that we're mid-line, and updates to 0x4f6. + + However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue + use the line info to skip the prologue? + + The answer is that the line info starts at bar_label, not at bar. + + Fixing that allows us to work around PR tdep/31981. + + Likewise in gdb.dwarf2/dw2-line-number-zero.exp. + + Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to + checking quality of architecture-specific prologue analysis, without being + written in an architecture-specific way. + + If fails on arm-linux for both marm and mthumb: + ... + FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much) + FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much) + ... + and passes for: + - x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie} + - aarch64-linux. + + Tested on arm-linux. + +2024-09-04 Mark Harmstone + + bfd/pdb: fix bitmap generation in pdb_write_bitmap + MSVC 2022 is more pedantic than MSVC 2019 when it comes to loading PDB + files in readonly mode, and was rejecting PDB files generated by binutils + because of their invalid free-space bitmaps. It's unknown what would + have happened if you tried to use MS tools to modify a PDB created by + binutils, but it probably would have led to a corrupted file. + + This patch fixes pdb_write_bitmap so we generate files that MSVC will accept. + + Specifically there were three things we were doing wrong: + + - We weren't including the superblock (block 0) + + - We were setting bits in bytes backwards (MSB to LSB, rather than LSB to MSB) + + - We should have been marking the contents of stream 0 as free. This is + because, as the comment says, it's intended to be used for the + directory for the previous write, to allow atomic updates. + +2024-09-04 GDB Administrator + + Automatic date update in version.in + +2024-09-03 Tom de Vries + + [gdb] Fix typos + Fix a few typos. + + unconditionaly -> unconditionally + gratuitiously -> gratuitously + configureable -> configurable + represention -> representation + distiguished -> distinguished + breakpointer -> breakpoint + asssignments -> assignments + architectual -> architectural + compatibity -> compatibility + adjustement -> adjustment + unexcepted -> unexpected + propogated -> propagated + consistant -> consistent + succeding -> succeeding + higlight -> highlight + detachs -> detach + + Tested by rebuilding on x86_64-linux. + + Approved-By: Simon Marchi + +2024-09-03 Mary Bennett + + RISC-V: Add support for XCVsimd extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvsimd` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): Add custom operands. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVsimd as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvsimd. + * testsuite/gas/riscv/x-cv-simd.d: New test. + * testsuite/gas/riscv/x-cv-simd.s: New test. + * testsuite/gas/riscv/x-cv-simd-fail.d: New test. + * testsuite/gas/riscv/x-cv-simd-fail.l: New test. + * testsuite/gas/riscv/x-cv-simd-fail.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVsimd. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVsimd. + (enum riscv_insn_class): Add the XCVsimd instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add custom operands. + * riscv-opc.c: Add XCVsimd instructions. + +2024-09-03 GDB Administrator + + Automatic date update in version.in + +2024-09-02 Haochen Jiang + + Support ymm rounding control for Intel AVX10.2 + In the patch, in order to support ymm rounding for AVX10.2, we derive + evex attribute for all cases instead of only for rc_none to encode U bit. + Also changed some bad_opcode return due to the share of U bit with APX_F. + + gas/ChangeLog: + + * config/tc-i386.c + (cpu_flags_match): Handle AVX10_2. + (build_evex_prefix): Handle U bit. Derive evex attribute + for all cases. + (check_VecOperands): Handle AVX10.2 and ymm roundings. + * doc/c-i386.texi: Document .avx10.2. + * testsuite/gas/i386/i386.exp: Run AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-rounding-intel.d: New test. + * testsuite/gas/i386/avx10_2-rounding-inval.l: Ditto. + * testsuite/gas/i386/avx10_2-rounding-inval.s: Ditto. + * testsuite/gas/i386/avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/avx10_2-rounding.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (struct instr_info): Add U bit. + (get_valid_dis386): Handle U bit. + * i386-gen.c (isa_dependencies): Add AVX10.2. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-opc.h (CpuAVX10_2): New. + (i386_cpu_flags): Add cpuavx10_2. + * i386-opc.tbl: Add rounding to old entries which do not + permit rounding previously. Also eliminate the redundant + RegXMM for vcvtps2uqq. + * i386-tbl.h: Regenerated. + +2024-09-02 GDB Administrator + + Automatic date update in version.in + +2024-09-01 GDB Administrator + + Automatic date update in version.in + +2024-08-31 H.J. Lu + + x86: Fix comment typos in TLS relocation check + R_386_TLS_IE is used only in + + movl foo@indntpoff, %eax + movl foo@indntpoff, %reg + addl foo@indntpoff, %reg + + R_386_TLS_DESC_CALL and R_X86_64_TLSDESC_CALL are used only in + + call *x@tlscall(%[er]ax) + + * elf32-i386.c (elf_i386_check_tls_transition): Use foo@indntpoff + in comments for R_386_TLS_IE check. + (elf_i386_tls_transition): Use @tlscall in comments for + R_386_TLS_DESC_CALL check. + * elf64-x86-64.c (elf_x86_64_tls_transition): Use @tlscall in + comments for R_X86_64_TLSDESC_CALL check. + +2024-08-31 H.J. Lu + + gold: Always resolve non-default weak undefined to 0 + Non-default weak undefined symbols in executable and shared library are + always resolved to 0 at runtime and don't need dynamic relocation. + + Tested on i686, x86-64, powerpc64le and aarch64. + + PR gold/32071 + * symtab.cc (Symbol::final_value_is_known): Always resolve + non-default weak undefined symbol in executable and shared library + to 0 at runtime. + * symtab.h (Symbol::needs_dynamic_reloc): Return false for + non-default weak undefined symbol in executable and shared library. + * testsuite/Makefile.am: Add weak_undef_test_3 and + weak_undef_test_4 tests. + * testsuite/Makefile.in: Regenerated. + * testsuite/weak_undef_lib_4.c: New file. + * testsuite/weak_undef_test_3.c: Likewise. + * testsuite/weak_undef_test_4.c: Likewise. + +2024-08-31 Tom de Vries + + [gdb/testsuite] Handle unsupported catch syscall + On riscv64-linux, I run into: + ... + Expecting: ^(catch syscall[^M + ]+)?((&.*)*.*~"Catchpoint 5 .*\\n".*=breakpoint-created,bkpt=\{number="5",type="catchpoint".*\}.*\n\^done[^M + ]+[(]gdb[)] ^M + [ ]*) + catch syscall^M + &"catch syscall\n"^M + &"The feature 'catch syscall' is not supported on this architecture yet.\n"^M + ^error,msg="The feature 'catch syscall' is not supported on this architecture yet."^M + (gdb) ^M + FAIL: gdb.mi/mi-breakpoint-changed.exp: test_insert_delete_modify: catch syscall (unexpected output) + ... + + Fix this by: + - factoring out proc supports_catch_syscall out of gdb.base/catch-syscall.exp, + and + - using it in gdb.mi/mi-breakpoint-changed.exp. + + Tested on x86_64-linux and riscv64-linux. + + Approved-By: Andrew Burgess + +2024-08-31 GDB Administrator + + Automatic date update in version.in + +2024-08-30 Andrew Burgess + + gdb: remove duplicate check in disable_breakpoints_in_freed_objfile + I spotted that we have a duplicate condition check in the function + disable_breakpoints_in_freed_objfile. + + Lets remove it. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-08-30 Simon Marchi + + gdb/dwarf2: cleanup includes + Cleanup includes in dwarf2/*. + + 1. Add the necessary includes so that clangd reports no errors when + opening header files. This ensures that header files include what + they use. + + 2. Remove all includes reported as unused by clangd (except + gdb-safe-ctype.h, which I think does some magic that affects what + follows). + + Built-tested --enable-threading at "yes" and "no", since there are some + portions of code gated by `#ifdef CXX_STD_THREAD`. + + Change-Id: I21debffcd7c2caf90f08e1e0fbba3ce30422d042 + Approved-By: Tom Tromey + +2024-08-30 Tom Tromey + + Minor formatting fix in breakpoint.c + I noticed a spot in breakpoint.c that doesn't follow gdb's formatting + rules: the return type is on the same line as the method name. + +2024-08-30 Tom Tromey + + Fix regexp quoting in gdb.ada test cases + I noticed that some gdb.ada tests used regular expressions like: + + "Continuing\..*$inferior_exited_re.*" \ + + Here, the "\." should either be "." or "\\." -- "\." is not really + meaningful. + + This patch fixes all the cases of this I could find in gdb.ada. In + one test (fun_renaming.exp), using "\\." would result in failures, and + here I rewrote the tests to use -wrap. + + Approved-By: Andrew Burgess + +2024-08-30 H.J. Lu + + x86: Check invalid TLS descriptor call + TLS descriptor call, + + call *x@tlsdesc(%rax) + + or + + call *x@tlsdesc(%eax) + + calls _dl_tlsdesc_return which expects that RAX/EAX points to the TLS + descriptor. Update x86 linker to issue an error with or without TLS + transition. + + bfd/ + + PR ld/32123 + * elf32-i386.c (elf_i386_check_tls_transition): Move + R_386_TLS_DESC_CALL to ... + (elf_i386_tls_transition): Here. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Move. + R_X86_64_TLSDESC_CALL check to ... + (elf_x86_64_tls_transition): Here. + + ld/ + + PR ld/32123 + * testsuite/ld-i386/i386.exp: Run tlsgdesc3. + * testsuite/ld-i386/tlsgdesc3.d: New file. + * testsuite/ld-x86-64/tlsdesc5.d: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsdesc5. + +2024-08-30 Jan Beulich + + x86: replace conditional operators used to calculate booleans + The boolean expressions themselves are fine to use there. + + x86/APX: drop %SW disassembler macro again + Not the least due to its extremely rare use I didn't really like that + macro's introduction. Adjust swap_operand() accordingly instead. + +2024-08-30 Jan Beulich + + x86: limit RegRex64 use + The special property really only applies to the "extended" byte regs + having legacy word/dword counterparts. + + While touching involved code also drop redundant byte checks from a + conditional in establish_rex(): The other remaining RegRex64 uses only + exist on registers which can't be used as register operands anyway. + Hence RegRex64 as an attribute of a (valid) register operand implies + that it's a byte reg. + +2024-08-30 Jan Beulich + + gas: properly check for ELF in LISTING_NODEBUG handling + While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h + including obj-elf.h for obscure reasons), there still need to be IS_ELF + checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code + checking for ->debugging being true doesn't need such extra checks, as + the field can only ever be true when IS_ELF. + + On the same basis reduce #ifdef-ary in debugging_pseudo(). + + Also move the field (into what on 64-bit architectures is a 32-bit gap) + and put it inside an OBJ_ELF conditional, too. + + While there further switch int to bool in related code. + +2024-08-30 Jan Beulich + + gas: generated code/data listing output vs .endr and alike + These ending directives are swallowed by buffer_and_nest() and hence + aren't seen by read_a_source_file(). Thus they also weren't announced to + the listing subsystem. That was, when macro expansions are included, + thus misguided to associate possible output resulting from the first + line of the construct being expanded with both the .endr and that first + line (i.e. showing it twice). + +2024-08-30 Nicolás Ortega Froysa + + gdb/doc: fix typo in 'watch' command + * gdb/breakpoint.c (watch_option_defs): Fix typo. + +2024-08-30 Lulu Cai + + LoongArch: LoongArch64 allows relocations to use 64-bit addends + Relocations using 64-bit addends allow larger constant offset address + calculations to be fused. + +2024-08-30 GDB Administrator + + Automatic date update in version.in + +2024-08-29 Andrew Burgess + + gdb: reject inserting breakpoints between functions + When debugging ROCm code, you might have something like this: + + __global__ void kernel () + { + ... + // break here + ... + } + + int main () + { + // Code to call `kernel` + } + + ... where kernel is a function compiled to execute on the GPU. It does + not exist in the host x86-64 program that runs the main function, and + GDB doesn't know about that function until it is called, at which point + the runtime loads the corresponding code object and GDB learns about the + code of the "kernel" function. Before the GPU code object is loaded, + from the point of view of GDB, you might as well have blank lines + instead of the "kernel" function. The DWARF in the host program doesn't + describe anything at these lines. + + So, a common problem that users face is: + + - Start GDB with the host binary + - Place a breakpoint by line number at the "break here" line + - At this point, GDB only knows about the host code, the lines of the + `kernel` function are a big void. + - GDB finds no code mapped to the "break here" line and searches for + the first following line that has code mapped to it. + - GDB finds that the line with the opening bracket of the `main` + function (or around there) has code mapped to it, places breakpoint + there. + - User runs the program. + - The programs hits the breakpoint at the start of main. + - User is confused, because they didn't ask for a breakpoint in main. + + If they continue, the code object eventually gets loaded, GDB reads the + debug info from it, re-evaluates the breakpoint locations, and at this + point the breakpoint is placed at the expected location. + + The goal of this patch is to get rid of this annoyance. + + A case similar to the one shown above can actually be simulated without + GPU-specific code: using a single source file to generate a library and + an executable loading that library (see the new test + gdb.linespec/line-breakpoint-outside-function.c for an example). Before + the library is loaded, trying to place a breakpoint in the library code + results in the breakpoint "drifting" down to the main function. + + To address this problem, make it so that when a user requests a + breakpoint outside a function, GDB makes a pending breakpoint, rather + than placing a breakpoint at the next line with code, which happens to + be in the next function. When the GPU kernel or shared library gets + loaded, the breakpoint resolves to a location in the kernel or library. + + Note that we still want breakpoints placed inside a function to + "drift" down to the next line with code. For example, here: + + 9 + 10 void foo() + 11 { + 12 int x; + 13 + 14 x++; + + There is probably no code associated to lines 10, 12 and 13, but the + user can still reasonably expect to be able to put a breakpoint there. + In my experience, GCC maps the function prologue to the line with the + opening curly bracket, so the user will be able to place a breakpoint + there anyway (line 11 in the example). But I don't really see a use + case to put a breakpoint above line 10 and expect to get a breakpoint in + foo. So I think that is a reasonable behavior change for GDB. + + This is implemented using the following heuristic: + + - If a breakpoint is requested at line L but there is no code mapped to + L, search for a following line with associated code (this already + exists today). + - However, if: + + 1. the found location falls in a function symbol's block + 2. the found location's address is equal the entry PC of that + function + 3. the found location's line is greater that the requested line + + ... then we don't place a breakpoint at the found location, we will + end up with a pending breakpoint. + + Change the message "No line X in file..." to "No compiled code for line + X in file...". There is clearly a line 9 in the example above, so it + would be weird to say "No line 9 in file...". What we mean is that + there is no code associated to line 9. + + All the regressions that I found this patch to cause were: + + 1. tests specifically this behavior where placing a breakpoint before + a function results in a breakpoint on that function, in which case I + removed the tests or changed them to expect a pending breakpoint + 2. linespec tests expecting things like "break -line N garbage" to + error out because of the following garbage, but we now got a + different error because line N now doesn't resolve to something + anymore. For example, before: + + (gdb) break -line 3 if foofoofoo == 1 + No symbol "foofoofoo" in current context. + + became + + (gdb) break -line 3 if foofoofoo == 1 + No line 3 in the current file. + + These tests were modified to refer to a valid line with code, so + that we can still test what we intended to test. + + Notes: + + - The CUDA compiler "solves" this problem by adding dummy function + symbols between functions, that are never called. So when you try to + insert a breakpoint in the not-yet-loaded kernel, the breakpoint + still drifts, but is placed on some dummy symbol. For reasons that + would be too long to explain here, the ROCm compiler does not do + that, and it is not a desirable option. + + - You can have constructs like this: + + void host_function() + { + struct foo + { + static void __global__ kernel () + { + // Place breakpoint here + } + }; + + // Host code that calls `kernel` + } + + The heuristic won't work then, as the breakpoint will drift somewhere + inside the enclosing function, but won't be at the start of that + function. So a bogus breakpoint location will be created on the host + side. I don't think that people are going to use this kind of + construct often though, so we can probably ignore it (or at least it + shouldn't prevent making the more common case better). + + ROCm doesn't support passing a lambda kernel function to + hipLaunchKernelGGL (the function used to launch kernels on the + device), but if it eventually does, there will be the same + problem. + + I think that to properly support this, we will need some DWARF + improvements to be able to say "there is really nothing at these + lines" in the line table. + + Co-Authored-By: Simon Marchi + Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6 + +2024-08-29 Andrew Burgess + + gdb/doc: move NEWS entry to the correct place + In commit: + + commit 3055e3d2f13bb84db90b9c19d427c362053775d2 + Date: Tue May 21 15:58:02 2024 +0100 + + gdb: add GDB side target_ops::fileio_stat implementation + + I managed to place a NEWS entry in the wrong place. I put the entry + in 'Changes in GDB 15' rather than 'Changes since GDB 15'. This + commit moves the entry to the correct place. + +2024-08-29 Simon Marchi + + gdb: include gdbsupport/gdb_obstack.h in addrmap.h + This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h. + This fixes an error shown when editing addrmap.h with clangd, and makes + it so addrmap.h includes what it uses. + + Change-Id: I0b0c8d26638e2150fcb65c601098ed9df5a8945a + +2024-08-29 Simon Marchi + + gdb: remove unused includes in linespec.c + Remove some includes reported as unused by clangd. + + Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df + +2024-08-29 Alan Modra + + get_type_abbrev_from_form tidy + * dwarf.c (get_type_abbrev_from_form): Make uvalue param a + uint64_t. Localise variables. Don't bother clearing *data_return + and *addrev_num_return for a NULL return value. + +2024-08-29 Alan Modra + + ld testsuite output files + In many cases the output of one run_cc_link_tests test is used as + input for another test. I hit a case where some system change caused + errors when compiling object files, but the old .so output from a + previous test run was still there, and then was used in following + tests. + + * testsuite/lib/ld-lib.exp (run_ld_link_tests): Delete output + file before building. + (run_ld_link_exec_tests, run_cc_link_tests): Likewise. + +2024-08-29 Alan Modra + + PR32093, -Walloc-size warning in ctf-hash.c + PR 32093 + * ctf-hash.c (ctf_dynhash_create_sized, ctf_hashtab_insert): Avoid + -Walloc-size warning. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix another regexp in gdb.threads/stepi-over-clone.exp + On openSUSE Tumbleweed, I run into: + ... + (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls + continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), __clone3 () at clone3.S:62^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating another (see commit 8fbf220321d) regexp to also recognize + __clone3. + + Tested on x86_64-linux. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.arch/i386-disp-step-self-call.exp + Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get: + ... + (gdb) x/1wx 0xffffc4f8^M + 0xffffc4f8: 0x08048472^M + (gdb) PASS: $exp: check return address was updated correctly + ... + but sometimes I run into: + ... + (gdb) x/1wx 0xffffc5c8^M + 0xffffc5c8: 0x0804917e^M + (gdb) FAIL: $exp: check return address was updated correctly + ... + + The problem is that here: + ... + set next_insn_addr 0x[format %08X $next_insn_addr] + gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \ + "check return address was updated correctly" + ... + we're trying to match string 0x0804917e against regexp 0x0804917E due to using + "%08X" as format string. + + We only run into this problem if the address contains letters, which apparently + usually isn't the case. + + Fix this by using "%08x" instead as format string. + + Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp. + + Tested on x86_64-linux. + + PR testsuite/32121 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32121 + +2024-08-29 GDB Administrator + + Automatic date update in version.in + +2024-08-28 Tom Tromey + + Don't check dwarf2_name in process_enumeration_scope + I noticed that process_enumeration_scope checks the result of + dwarf2_name. However, this isn't needed, because new_symbol does the + same check. This patch removes the unnecessary code. + + Reviewed-by: Keith Seitz + +2024-08-28 Jiaying Song + + dlltool: file name too long + During the execution of the command: i686-w64-mingw32-dlltool + --input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe + An error occurred: + i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s + + Due to the path length exceeding the Linux system's file name length + limit (NAME_MAX=255), the temporary file name generated by the + i686-w64-mingw32-dlltool command becomes too long to open. To address + this, a new temporary file name prefix is generated using tmp_prefix = + prefix_encode ("d", getpid()), ensuring that the file name does not + exceed the system's length limit. + + Reviewed-by: Alan Modra + +2024-08-28 H.J. Lu + + x86: Report expected register for elf_x86_tls_error_indirect_call + Since R_386_TLS_DESC_CALL can only be used with + + call *variable@TLSCALL(%eax) + + and R_X86_64_TLSDESC_CALL can only be used with + + call *variable@TLSCALL(%rax) + + update TLS transition error report to display the expected register in + indirect CALL. + + bfd/ + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize + the ax_register field. + (_bfd_x86_elf_link_report_tls_transition_error): Report the + expected register in elf_x86_tls_error_indirect_call error. + * elfxx-x86.h (elf_x86_link_hash_table): Add ax_register. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/tlsgdesc2.d: Updated. + * testsuite/ld-i386/tlsgdesc2.s: Change jmp to call via ECX. + * testsuite/ld-x86-64/tlsdesc4.d: Updated. + * testsuite/ld-x86-64/tlsdesc4.s: Change jmp to call via RCX. + +2024-08-28 H.J. Lu + + gold: Force a PC-relative reference to .LC0 + Force a PC-relative reference to .LC0 with: + + __asm__ (".dc.a .LC0 - ."); + + for all targets. + + Tested on x86, powerpc64le and aarch64. + + * testsuite/discard_locals_relocatable_test.c: Force a PC-relative + reference to .LC0. + +2024-08-28 H.J. Lu + + gold: Disable &no_such_symbol_ != NULL check when GOT in use + Since this test: + + if (&no_such_symbol_ != NULL) + { + fprintf(stderr, "FAILED weak undef test 4: %s\n", + "&no_such_symbol_ is not NULL"); + status = 1; + } + + always fails when GOT is used and aarch64 always uses GOT, disable it + for aarch64 and PIC. + + PR gold/32112 + * testsuite/weak_undef_test.cc (main): Disable the + &no_such_symbol_ != NULL check for aarch64 and PIC. + +2024-08-28 Alan Modra + + dlltool.c formatting + Mostly whitespace fixes, some removal of excess parens. + + Re: x86: Allow R_386_TLS_LE_32 with KMOVD + Adjust the new test to pass on i686-pc-elf where it failed due to not + matching the _start address. + +2024-08-28 H.J. Lu + + gold: Use asm for GCC 9 and older in PR gold/31830 tests + Since GCC 9 and older fail to compile PR gold/31830 tests: + + $ gcc -S testsuite/ver_test_pr31830_b.c -o /tmp/x.s + testsuite/ver_test_pr31830_b.c:3:1: warning: ‘__symver__’ attribute directive ignored [-Wattributes] + void __collector_foo_2_2(void) {} + ^~~~ + + use asm statement, instead of symver attribute, for GCC 9 and older. + + PR gold/31830 + * testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm + statement, instead of symver attribute, for GCC 9 and older. + symver attribute with __asm__. + * testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise. + +2024-08-28 H.J. Lu + + gold: Remove duplicated rules for ifuncmain[12457]picstatic + When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports: + + Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic' + Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic' + Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic' + Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic' + Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic' + Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic' + Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic' + Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic' + Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic' + Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic' + + due to duplicated rules for ifuncmain[12457]picstatic: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@HAVE_STATIC_TRUE@@IFUNC_STATIC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + Make rules for ifuncmain[12457]picstatic independent of HAVE_STATIC and + IFUNC_STATIC: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + PR gold/32116 + * testsuite/Makefile.am (ifuncmain1picstatic): Make it independent + of HAVE_STATIC and IFUNC_STATIC. + (ifuncmain2picstatic): Likewise. + (ifuncmain4picstatic): Likewise. + (ifuncmain5picstatic): Likewise. + (ifuncmain7picstatic): Likewise. + * testsuite/Makefile.in: Regenerated. + +2024-08-28 H.J. Lu + + x86: Report invalid TLS operator + Report invalid TLS operator, instead of relocation. + + PR gas/28595 + * config/tc-i386.c (gotrel): Replace int with unsigned int. + (i386_assemble): Report invalid TLS operator. + * testsuite/gas/i386/inval-tls.l: updated. + * testsuite/gas/i386/x86-64-inval-tls.l: Likewise. + +2024-08-28 Guinevere Larsen + + gdb/testsuite: fix gdb.btrace/non-stop.exp end of history check + The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the + warnings when GDB reaches the end of the recorded history, and updated + tests to expect the new messages. The pattern used for + gdb.btrace/non-stop.exp, however, was too broad and could cause the + following test result: + + ... + (gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0 + FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout) + ... + + This happens because the pattern looks like one of these 2: + "Reached end of recorded.*Backwards execution.*" + "Reached end of recorded.*Following forward.*" + + What seems to have happened is that all the output came at once, and + most of it was consumed by the first '.*' pattern when checking for + thread 0, so there was no output left for checking thread 1. This commit + fixes that by making the expected outputs more exact. + + I also fixed the whitespace errors in gdb_cont_to_no_history_backwards + that pre-dated the commit above, since I was already touching that proc. + + Approved-By: Tom de Vries + +2024-08-28 Andrew Burgess + + gdb/testsuite: add no-delete-breakpoints option to 'runto' proc + New 'no-delete-breakpoints' option for the 'runto' proc. This option + disables the delete_breakpoints call early on in this proc. + + There are a couple of places in the testsuite where I have used: + + proc no_delete_breakpoints {} {} + + with_override delete_breakpoints no_delete_breakpoints { + if {![runto_main]} { + return + } + } + + In order to avoid the deleting all breakpoints when I call + runto_main. I was about to add yet another instance of this pattern + and I figured that it's time to do this properly. + + This commit adds the new option to 'runto' which causes the + delete_breakpoints call to be skipped. + + And, we now forward any arguments from 'runto_main' through to + 'runto', this means I can now just do: + + if {![runto_main no-delete-breakpoints]} { + return + } + + which I think is cleaner and easier to understand. + + I've updated the two tests I found that use the old with_override + approach. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-08-28 Andrew Burgess + + gdb: add 'maint info blocks' command + While reviewing a patch I wanted to understand which blocks existed at + a given address. + + The 'maint print symbols' command does provide some of this + information, but that command displays all blocks within a given + symtab. If I want to know which blocks are at a given address I have + to figure that out for myself based on the output of 'maint print + symbols' ... and I'm too lazy for that! + + So this command lists just those blocks at a given address, along with + information about the blocks type. This new command doesn't list the + symbols within each block, for that my expectation is that you'd cross + reference the output with that of 'maint print symbols'. + + The new command format is: + + maintenance info blocks + maintenance info blocks ADDRESS + + This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is + not given. Blocks are listed starting at the global block, then the + static block, and then the progressively narrower scoped blocks. + + For each block we list the internal block pointer (which allows easy + cross referencing with 'maint print symbols'), the inferior address + range, along with other useful information. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: Add 'maint info inline-frames' command + While reviewing a patch I wanted to view GDB's inline frame state. I + don't believe there's currently a maintenance command to view this + information, so in this commit I've added one. + + The new command is: + + maintenance info inline-frames + maintenance info inline-frames ADDRESS + + The command lists the inline frames that start at ADDRESS, or at the + current $pc if no ADDRESS is given. The command also displays the + "outer" function in which the inline functions are present. + + An example of the command output: + + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 1 + bar + > foo + main + (gdb) + + This tells us that function 'main' called 'foo' which called 'bar'. + The functions 'foo' and 'bar' are both inline and both start at the + address 0x401137. Currently GDB considers the inferior to be stopped + in frame 'foo' (note the '>' marker), this means that there is 1 + skipped frame (function 'bar'). + + The function 'main' is the outer function. The outer function might + not start at 0x401137, it is simply the function that contains the + inline functions. + + If the user does a 'step' then GDB will not actually move the inferior + forward, but will instead simply tell the user that the inferior + entered 'bar'. The output of 'maint info inline-frames' will change + like this: + + (gdb) step + bar () at inline.c:6 + 6 ++global_counter; + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 0 + > bar + foo + main + (gdb) + + Now GDB is in function 'bar' and there are no skipped frames. + + I have renamed skipped_symbols to function symbols within the + inline_state class. We are now going to carry the "outer" + function (the function that contains all the inlined functions) within + this list (as the last entry), so the old name didn't really make + sense. As a consequence of this rename I've updated some comments. + + I've changed stopped_by_user_bp_inline_frame to take a symbol rather + than a block. Previously we just used the block to access the + associated function symbol. After this commit we can just pass in the + function symbol directly, so lets do that. + + New function gather_inline_frames contains some of the logic pulled + from skip_inline_frames. This new function builds the list of all + symbols of inlined functions that start at a given $pc value and also + the "outer" function that contains all of the inlined functions. + + In skip_inline_frames I've split the loop logic into two. The loop to + build the function symbol list has moved to gather_inline_frames. The + loop to figure out how many of the inlined functions we are skipping + remains in skip_inline_frames and uses the result of calling + gather_inline_frames. + + In inline_skipped_symbol there are some minor updates to the comment, + and I've tweaked one of the asserts now that the function symbols list + also contains the "outer" function (a <= becomes <). + + The maintenance_info_inline_frames function is now and implements the + new maintenance command. + + And _initialize_inline_frame is updated to register the new command. + + I've added a basic test for the new command. Please excuse the file + name for the new test, in the next commit I'll be adding additional + tests and at that point the file name will make sense. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: make symbols const in struct inline_state + Make the inline_state::skipped_symbols a vector of 'const symbol *', + adding the const qualifier. + + There's only a couple of places this leaks into the rest of GDB and in + both places its fine for the symbol to become const. + + There should be no functional change after this commit. + + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + Revert "gdb: remove inline_frame::skipped_frames" + This reverts commit 713e89012e43c83a6c1bb957c43ff58e5433336c. + + Having inline_state::skipped_frames back will make a later patch in + this series easier. + +2024-08-28 GDB Administrator + + Automatic date update in version.in + +2024-08-27 H.J. Lu + + x86: Report invalid TLS relocation name + Get TLS relocation name from its lex_got entry when reporting invalid + instructions with TLS relocations. + + PR gas/28595 + * config/tc-i386.c (gotrel): Moved from ... + (lex_got): There. + (i386_assemble): Get invalid TLS relocation name from its lex_got + entry when reporting TLS relocation error. + +2024-08-27 H.J. Lu + + x86: Allow R_386_TLS_LE_32 with KMOVD + Since there is no TLS IE transition, allow R_386_TLS_LE_32 with KMOVD. + + gas/ + + PR gas/28595 + * config/tc-i386.c (i386_assemble): Remove BFD_RELOC_386_TLS_LE_32 + from TLS code check. + * testsuite/gas/i386/inval-tls.s: Remove foo@tpoff(%eax). + * testsuite/gas/i386/inval-tls.l: Updated. + + ld/ + + PR gas/28595 + * testsuite/ld-i386/i386.exp: Run tlsle1. + * testsuite/ld-i386/tlsle1.d: New file. + * testsuite/ld-i386/tlsle1.s: Likewise. + +2024-08-27 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.exp + In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to + DWARF Error") I changed the dwarf error prefix, but failed to update test-case + gdb.dwarf2/dw2-inter-cu-error.exp. + + Fix this by updating the corresponding regexp in the test-case. + + Tested on x86_64-linux. + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_SET_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error + It was suggested here [1] that the canonical prefix for dwarf errors + should not be "Dwarf Error: ", given that the canonical spelling is DWARF + instead of Dwarf. + + Fix this by using "DWARF Error: " instead. + + Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single + location. + + Tested on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html + +2024-08-27 Tom de Vries + + [gdb/symtab] Use DWARF_ERROR_PREFIX + Result of: + ... + $ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/* + ... + and manually fixing indentation. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Add gdb/dwarf2/error.h + Add a new header file gdb/dwarf2/error.h, containing macros: + - DWARF_ERROR, and + - DWARF_ERROR_PREFIX. + + The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Use [in module %s] notation more consistently in dwarf errors + In gdb/dwarf2/read.c, I found a few strings "in module %s": + ... + $ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '[' + "DIE at %s in module %s"), + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + error (_("Dwarf Error: DIE at %s referenced in module %s " + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + ... + that are not using the commonly used "[in module %s]" notation. Fix these. + + In one case, the string was also used in the middle rather than at the end of + the message, so fix that as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Jiawei + + RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions. + This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'. + All disassemble instructions use the sreg format. + + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + gas/ChangeLog: + PR 32036 + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/zcmp-mv.d: New test. + * testsuite/gas/riscv/zcmp-mv.s: New test. + + include/ChangeLog: + PR 32036 + * opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode. + (MASK_CM_MVA01S): New mask. + (MATCH_CM_MVSA01): New opcode. + (MASK_CM_MVSA01): New mask. + (DECLARE_INSN): New declarations. + * opcode/riscv.h (OP_MASK_SREG1): New mask. + (OP_SH_SREG1): New operand code. + (OP_MASK_SREG2): New mask. + (OP_SH_SREG2): New operand code. + (X_A0): New reg number. + (X_A1): Ditto. + (X_S7): Ditto. + (RISCV_SREG_0_7): New macro function. + + opcodes/ChangeLog: + PR 32036 + * riscv-dis.c (riscv_zcmp_get_sregno): New function. + (print_insn_args): New operators. + * riscv-opc.c (match_sreg1_not_eq_sreg2): New match function. + +2024-08-27 GDB Administrator + + Automatic date update in version.in + +2024-08-26 Vladimir Mezentsev + + Disable gprofng build for *musl* + I disable gprofng until gprofng is ported to musl. + + gprofng/ChangeLog + 2024-08-22 Vladimir Mezentsev . + + PR gprofng/30779 + PR gprofng/29593 + PR gprofng/29477 + * configure.ac: Disable gprofng build for *musl*. + * configure: Rebuild. + +2024-08-26 Tom Tromey + + Simplify ada_identical_enum_types_p + This patch changes ada_identical_enum_types_p to reuse the field names + that are computed earlier in the loop. This is a simple cleanup, but + also is useful for a larger change that I'm working on. + + Tested on x86-64 Fedora 38. + +2024-08-26 Mark Harmstone + + ld/PDB: handle pointers to members + If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an + LF_POINTER entry's attributes, there's a few extra bytes on the end that + we weren't accounting for. + + Change handle_type so that we remap the containing_class field if it's + present, and add a test for this. + +2024-08-26 William Ferreira + + gdb: imply --once if connecting via stdio + Currently, gdbserver hangs after stdin is closed while it tries to + write: "Remote side has terminated connection. GDBserver will reopen + the connection." This hang disappears if --once is also given. Since + the stdin connection won't ever reopen if it's closed, it's safe to + assume --once is desired. + + The gdb.server/server-pipe.exp test was also updated to reflect this + change. There is now a second disconnect at the end of the proc, + with a tighter-than-normal timeout to catch if the command hangs as + it used to. + + Co-Authored-By: Guinevere Larsen + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796 + + Approved-By: Andrew Burgess + +2024-08-26 Guinevere Larsen + + Change message when reaching end of reverse history. + In a record session, when we move backward, GDB switches from normal + execution to simulation. Moving forward again, the emulation continues + until the end of the reverse history. When the end is reached, the + execution stops, and a warning message is shown. This message has been + modified to indicate that the forward emulation has reached the end, but + the execution can continue as normal, and the recording will also continue. + + Before this patch, the warning message shown in that case was the same as + in the reverse case. This meant that when the end of history was reached in + either backward or forward emulation, the same message was displayed: + + "No more reverse-execution history." + + This message has changed for these two cases. Backward emulation: + + "Reached end of recorded history; stopping. + Backward execution from here not possible." + + Forward emulation: + + "Reached end of recorded history; stopping. + Following forward execution will be added to history." + + The reason for this change is that the initial message was deceiving, for + the forward case, making the user believe that forward debugging could not + continue. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224 + Reviewed-By: Markus T. Metzger (btrace) + Approved-By: Guinevere Larsen + +2024-08-26 Lulu Cai + + LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE + If the symbol defined by PROVIDE in the link script is not in SECTION, + the symbol is placed in the ABS section. The linker considers that + symbols in the ABS section do not need to calculate PC relative offsets. + + Symbols in ABS sections should calculate PC relative offsets normally + based on relocations. + +2024-08-26 Felix Willgerodt + + gdb, btrace: Fix clang build + Simon pointed out to me that there are some failures when building with clang, + that were caused by my commit + + commit d894edfcc40e63be9b6efa0950c1752f249f16e5 + Author: Felix Willgerodt + Date: Mon Feb 18 13:49:25 2019 +0100 + + btrace: Introduce auxiliary instructions. + + The errors are: + + CXX btrace.o + gdb/btrace.c:1203:11: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1203 | return {(CORE_ADDR) insn.ip, (gdb_byte) insn.size, + | ^~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1218:21: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1218 | btrace_insn insn {btinfo->aux_data.size () - 1, 0, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1323:34: error: variable 'bfun' is uninitialized when used here [-Werror,-Wuninitialized] + 1323 | handle_pt_aux_insn (btinfo, bfun, *ptw_string, pc); + | ^~~~ + gdb/btrace.c:1236:35: note: initialize the variable 'bfun' to silence this warning + 1236 | struct btrace_function *bfun; + | ^ + | = nullptr + 3 errors generated. + make[1]: *** [Makefile:1961: btrace.o] Error 1 + + This fixes those errors and switches two casts to C++ casts while we + are at it. + + Approved-By: Simon Marchi + +2024-08-26 Alan Modra + + PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt + Since bfd_section for .strtab isn't set, print the section index + instead. Also, don't return NULL on this error as that results in + multiple mmap/read of the string table. (We could return NULL if we + arranged to set sh_size zero first, but just what we do with fuzzed + object files is of no concern, and terminating the table might make a + faulty object file usable.) + + PR 32109 + * elf.c (bfd_elf_get_str_section): Remove outdated comment, and + tweak shstrtabsize test to suit. Don't use string tab bfd_section + in error message, use index instead. Don't return NULL on + unterminated string section, terminate it. + (_bfd_elf_get_dynamic_symbols): Similarly terminate string table + section. + +2024-08-26 GDB Administrator + + Automatic date update in version.in + +2024-08-25 Dmitry Neverov + + Recognize -2 as a tombstone value in .debug_line + Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone + value -1 used by lld (https://reviews.llvm.org/D81784). The + referenced lld commit also uses the tombstone value -2 for + pre-DWARF-v5 + (https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7). + + If not handled, -2 breaks the pc step range calculation and triggers + the assertion: + + gdb/infrun.c:2794: internal-error: resume_1: Assertion + `pc_in_thread_step_range (pc, tp)' failed. + + This commit adds -2 tombstone value and handles it in the same way as -1. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727 + Approved-By: Tom Tromey + +2024-08-25 GDB Administrator + + Automatic date update in version.in + +2024-08-24 GDB Administrator + + Automatic date update in version.in + +2024-08-23 Aaron Merey + Tom de Vries + + gdb/dwarf2: Check for null abbrev_info ptr + A corrupt debuginfo file can result in a null abbrev_info pointer + being passed to cooked_indexer::scan_attributes. This pointer + is set to nullptr by peek_die_abbrev when an abbrev of 0 is found. + + There is no check for whether the abbrev pointer is null and + SIGSEGV occurs when attempting to dereference the pointer. + + An abbrev of 0 normally indicates that the corresponding DIE is a + null entry, but scan_attributes expects a non-null DIE. + + Fix this by throwing an error in cooked_indexer::scan_attributes + when peek_die_abbrev returns a nullptr in order to avoid + scan_attributes calling itself with a null abbrev. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 + Approved-By: Tom Tromey + +2024-08-23 Jan Beulich + + x86: simplify SAE checking + To determine whether SAE (with or without StaticRounding) is permitted + there's no need to iterate over all operands. Even less so starting at + the front (thus needlessly inspecting immediate operands as well). + Leverage the pattern across all relevant templates and check only the + last two operands, and also only for non-512 ones (besides the non-LIG + case that was already checked for). + + gas: update lex_type[] also for .mri directives + Doing this just from read_begin(), i.e. merely based on command line + options, can't be sufficient (assuming it's really relevant). + +2024-08-23 Jan Beulich + + RISC-V: process rs_align_code also when relaxing + riscv_handle_align() runs after all input was processed. Whether + relaxation is enabled for any particular piece of code is not recorded + anywhere. (This issue was even "worked around" in a gas testcase, which + is adjusted accordingly.) Furthermore, as demonstrated by an ld + testcase, tail padding in an object file's executable sections depended + on whether relaxation was enabled at the end of assembly: NOPs were + emitted only when relaxation was off; zeroes were emitted with + relaxation enabled. (It could probably be either way, but it should be + independent of relaxation state at the end of assembly. Except of course + write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(), + explicitly says "proper nop-filling".) + + While re-indenting, drop the "odd_padding" variable. It's used exactly + once, and having the actual expression right in the if() is imo helping + readers to understand what the intentions are. + + While touching the ld testcase, also tighten the expectations for the + addresses of the two symbols: The last two digits have to have fixed + values. + +2024-08-23 GDB Administrator + + Automatic date update in version.in + +2024-08-22 H.J. Lu + + lto: Add a test for PR ld/32083 + Add a test for PR ld/32083 and xfail the test for GCC without the fix: + + commit a98dd536b1017c2b814a3465206c6c01b2890998 + Author: H.J. Lu + Date: Wed Aug 21 07:25:25 2024 -0700 + + Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook + + PR ld/32083 + * testsuite/ld-plugin/common-2a.c: New file. + * testsuite/ld-plugin/common-2b.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run PR ld/32083 test. + +2024-08-22 Tom de Vries + + [gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists + With the test-case included in this patch, we run into: + ... + $ gdb -q -batch $exec + Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \ + [in module $exec] + ... + + The debug info consists of two CUs: + ... + Compilation Unit @ offset 0xb2: + Length: 0x25 (32-bit) + Version: 4 + Abbrev Offset: 0x6c + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_low_pc : 0x4004a7 + DW_AT_high_pc : 0x4004b2 + DW_AT_specification: <0xe8> + <1>: Abbrev Number: 3 (DW_TAG_subprogram) + DW_AT_name : main + <1>: Abbrev Number: 0 + Compilation Unit @ offset 0xdb: + Length: 0xf (32-bit) + Version: 4 + Abbrev Offset: 0x86 + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_specification: <0xd4> + <1>: Abbrev Number: 0 + ... + where: + - DIE 0xbf in CU@0xb2 contains an inter-CU reference to + - DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to + - DIE 0xd4 back in CU@0xb2. + + The dwarf error is caused by this bit of code in + cooked_indexer::ensure_cu_exists: + ... + if (per_cu == m_per_cu) + return reader; + ... + + The dwarf error happens as follows: + - a cutu_reader A is created for CU@0xb2 + - using cutu_reader A, the cooked index reader starts indexing dies, with + m_per_cu set to CU@0xb2 + - while indexing it scans the attributes of DIE 0xbf and encounters the + inter-CU reference to DIE 0xe8 + - it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for + CU@0xdb and returns it + - using cutu_reader B, it continues scanning attributes of DIE 0xe8 and + encounters the inter-CU reference to DIE 0xd4 + - it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered + and cutu_reader B is returned + - using cutu_reader B, it continues scanning attributes of DIE 0xd4 + - this goes wrong because: + - the attributes of the DIE are encoded using the abbreviation table at + offset 0x6c, while + - the decoding is done using cutu_reader B which uses the abbreviation table + at offset 0x86. + + Fix this by removing the problematic if clause. + + Since cutu_reader A is not preserved in m_index_storage, + cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate + cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving + the cutu_reader A as well in m_index_storage. + + Tested on x86_64-linux and aarch64-linux. + + PR symtab/32081 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081 + + Approved-By: Tom Tromey + Reported-By: Andreas Schwab + +2024-08-22 Tom de Vries + + [gdb] Add const to catch gdb_exception + I did a review of lines containing "catch (gdb_exception" and found a few + where we can add const. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb/python] Eliminate catch(...) in type_to_type_object + In type_to_type_object we have: + ... + try + { + if (type->is_stub ()) + type = check_typedef (type); + } + catch (...) + { + /* Just ignore failures in check_typedef. */ + } + ... + + The catch is supposed to ignore gdb_exception_error, but it ignores any + exception. + + Fix that by only ignoring gdb_exception_error, and handling + gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Add & in catch in svr4_handle_solib_event + In svr4_handle_solib_event I noticed: + ... + catch (const gdb_exception_error) + ... + + This seems to be the only place were we do this, elsewhere we have: + ... + catch (const gdb_exception_error &) + ... + + I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's + necessary given that it's an unnamed const parameter, but I suppose it can't + hurt either. + + Add the '&' here as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Eliminate catch(...) in get_test_insn + In get_test_insn in gdb/disasm-selftests.c, we find this code: + ... + try + { + kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc); + insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen); + } + catch (...) + { + continue; + } + ... + + The catch is there to catch memory errors, but it swallows all exceptions, including + gdb_exception_quit and gdb_exception_forced_quit. + + Fix this by limiting the catch to gdb_exception_error. + + Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp. + + Approved-By: Tom Tromey + +2024-08-22 Sam James + + gprofng: testsuite: fix 'wrapper' typo + gprofng/ChangeLog + * testsuite/config/default.exp: Fix 'wrapper' typo. + +2024-08-22 GDB Administrator + + Automatic date update in version.in + +2024-08-21 Simon Marchi + + gdb: some global_block improvements + Some refactors around struct global_block, all in one patch because they + all tie in together and are relatively trivial. + + - Make block::global_block() and blockvector::global_block() return + `global_block *`, instead of `block *`. There is no cost in doing + so, and it's a bit more precise. Callers of these methods that need + a `global_block *` won't need to cast themselves. + + - Add some block::as_global_block methods, as a way to get a + `global_block *` from a `block *` when you know it's a global block. + This is basically a static cast with an assert. + + - Move set_compunit_symtab to global_block, since it requires the + block to be a global block anyway. Rename to just `set_compunit` (I + think that compunit_symtab should just be renamed compunit...). + + - Move the get_block_compunit_symtab free function to be a method of + global_block. + + - Make global_block::compunit_symtab private and rename. + + - Simplify initialize_block_iterator. + + Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d + Approved-By: Tom Tromey + +2024-08-21 Tom Tromey + + Do not assume ELF in dwarf2/read.c + dwarf2/read.c has this code: + + else if (elf_section_data (sectp)->this_hdr.sh_size + > bfd_get_file_size (abfd)) + + This assumes that the BFD is an ELF, which is an invalid assumption. + A user noticed that this can sometimes cause a crash. + + This patch fixes the problem by changing this code to use + bfd_section_size_insane. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104 + Reviewed-By: Tom de Vries + Reviewed-by: Keith Seitz + +2024-08-21 GDB Administrator + + Automatic date update in version.in + +2024-08-20 Andrew Burgess + + gdb/testsuite: track nested caching proc calls + It was pointed out in this email: + + https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com + + that this commit: + + commit 0726729d344fecf98f8d138e688e77201cc3cece + Date: Mon Jun 3 13:56:54 2024 +0100 + + gdb/testsuite: track if a caching proc calls gdb_exit or not + + had broken some AArch64 tests. + + What is going on is that there are two caching procs: + + allow_aarch64_sme_tests + aarch64_initialize_sme_information + + the allow_aarch64_sme_tests proc makes a call to + aarch64_initialize_sme_information, but + aarch64_initialize_sme_information is also called from other + non-caching procs, like aarch64_supports_sme_svl. + + Both of the caching procs mentioned above compile and run a helper + program, and both of them call gdb_exit. + + After the above commit, the first call to any caching proc, the body + of which calls gdb_exit, will result in a gdb_exit call even if the + body is not executed and the result is fetched from the cache. + + What was observed is that in the first test script + allow_aarch64_sme_tests is called, the body of this caching proc is + run which calls gdb_exit. Then allow_aarch64_sme_tests calls + aarch64_initialize_sme_information, the body of which is run and + gdb_exit is called again. The results from both procs are added to + the cache. + + In the next test script allow_aarch64_sme_tests is called. This + results in a cache hit, but gdb_exit is also called as this is the + first call in this second test script. + + Later in the test script aarch64_supports_sme_svl is called which + calls aarch64_initialize_sme_information. As this is the first call + to aarch64_initialize_sme_information in this second test + script (remember the body of allow_aarch64_sme_tests was never run) + then gdb_exit is called. This call to gdb_exit is new after the above + commit and is unexpected. + + I think the idea behind the above commit is still sound. If the call + to allow_aarch64_sme_tests was removed from the second test script + then we would want the extra gdb_exit call as this would expose a real + bug in the test. The problem is that after the above commit the + nested nature of the caching proc calls becomes important: a call to + allow_aarch64_sme_tests should mean that we've also called + aarch64_initialize_sme_information, and that relationship isn't + currently captured. + + So in this commit I'm adding another field to the global + gdb_data_cache (in lib/cache.exp). This new field is 'also_called'. + For every caching proc we populate this field with a list of names, + these are the names of any nested caching procs that are called when + the body of a caching proc is executed. + + Now when we get a cache hit in gdb_data_cache we mark every proc in + the 'also_called' list as having been called. This means that further + calls to these procs will no longer trigger a gdb_exit call. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-08-20 Tom Tromey + + Fix Windows regression + commit cb9f919f ("gdb: add program_space parameter to + lookup_minimal_symbol_text") caused a crash on Windows. In this + function, section can be nullptr, but it is unconditionally + dereferenced by the change introduced by the patch. + + I tested this using the AdaCore internal test suite. + + v2: always use current_program_space, reverting to be behavior before + cb9f919f. + + Approved-By: Simon Marchi + +2024-08-20 Tom Tromey + + Use SEARCH_FUNCTION_DOMAIN when looking for Ada exception symbols + While working on another bug, I noticed that the Ada code to find + exception symbols uses SEARCH_VFT. This will find variables and types + -- but only functions are needed here. This patch changes the code to + use SEARCH_FUNCTION_DOMAIN. + + Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo + installed, to ensure the exception-related tests work. + + Reviewed-by: Keith Seitz + +2024-08-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13 + When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output) + ... + + In contrast, with python 3.12 I have: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n"^M + &" raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + PASS: gdb.python/py-mi-cmd.exp: -pycmd exp + ... + + To make it easier to understand what we're looking at, let's take this out of + the mi interpreter context and use the cli interpreter: + ... + $ gdb -q -batch -ex "set trace-commands on" -x gdb.in + +set python print-stack full + +source py-mi-cmd.py + +python pycmd1('-pycmd') + +python pycmd1.invoke (pycmd1, ["exp"]) + Traceback (most recent call last): + File "", line 1, in + File "py-mi-cmd.py", line 76, in invoke + raise gdb.GdbError() + gdb.GdbError + gdb.in:4: Error in sourced command file: + Error occurred in Python. + ... + + Interestingly, this is what we're seeing with both python 3.12 and 3.13. + + The difference between the python versions is that: + - with python 3.12 each line is printed by itself, and + - with python 3.13 two particular lines are printed toghether. + + With the cli interpreter, that makes no difference, because the '\n' is + interpreted. + + But with the mi interpreter, that causes a difference in output because the + '\n' is not interpreted, but rather printed literally. + + Fix this by accepting the new output in addition to the old one. + + Tested on aarch64-linux. + + Reviewed-by: Thiago Jung Bauermann + + PR testsuite/31913 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913 + +2024-08-20 Vladimir Mezentsev + + gprofng: add hardware counters for Appliedmicro processor + gprofng/ChangeLog + 2024-08-15 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Appliedmicro processor. + * common/hwctable.c: Add the hwc table for Appliedmicro processor. + * src/hhwc_arm64_amcc.h: New file. + * src/collctrl.cc (read_int): Use strtol instead of atoi. + +2024-08-20 GDB Administrator + + Automatic date update in version.in + +2024-08-19 Indu Bhagat + + gas: ginsn: x86: pacify Wmaybe-uininitialized compiler warning + Fix PR binutils/32091 + + After commit d56083b5047b8e7cc9eda2f867bd2b75724920a1, some gcc versions + may warn about unintialized usage of ginsn_func. Albeit false positive, + adapt the code to escape the warning. + + gas/config/ + * tc-i386-ginsn.c (x86_ginsn_indirect_branch): Early exit if + unexpected args. + +2024-08-19 Andreas Schwab + + Fix m68k OS ABI sniffer + Do not override the generic OS ABI sniffer. + + Fixes: 3eba3a011a8 ("Various m68k fixes for gdb") + +2024-08-19 Tom Tromey + + Ensure gdb.ada/multiarray.exp runs in both modes + gdb.ada/multiarray.exp has a loop that looks like it should run the + test in both 'all' and 'minimal' encodings mode. However, the body of + the loop doesn't actually use the 'flags' variable. This was an + oversight in the original commit. + +2024-08-19 Nick Clifton + + Remove Walter Lee as maintainer for Tile Gx and Tile Pro + +2024-08-19 Andrew Burgess + + gdb: fix a target: prefix issue in find_separate_debug_file + Following on from the previous commit, this commit fixes the two KFAIL + in gdb.base/sysroot-debug-lookup.exp when not using the + native-extended-gdbserver board. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What I think we need to do is this: if the sysroot has a target: + prefix, and the target filesystem is local to GDB, then we should + strip the target: prefix from the sysroot, just as we do when opening + a file (see gdb_bfd_open in gdb_bfd.c). + + Now, when we make the child_path() call neither the sysroot nor + CANON_DIR will have a target: prefix, the child_path() call will + succeed, and GDB will correctly find the debug information. + + There is just one remaining issue, the last path we look in when + searching for debug information is built by starting with the sysroot, + then adding the debug directory, see this line: + + debugfile = path_join (target_prefix_str, root.c_str (), + debugdir.get (), base_path, debuglink); + + The target_prefix_str is set to target: if DIR has a target: prefix, + and DIR should have a target: prefix if the file we're looking for was + opened with a target: prefix. However, in our case the file was in a + local filesystem so GDB stripped the prefix off. + + The sysroot however, does have the target: prefix, and the test is + expecting to see GDB look within a file with the target: prefix. + + Given that the above line is about looking within a sub-directory of + the sysroot, I think we should not be stripping the target: prefix off + the sysroot path (as we do when building ROOT), instead, we should, in + this case, not use TARGET_PREFIX_STR, and instead just use GDB's + sysroot as it is (in this case with the target: prefix). + + With these fixes in place I now see no failures when using the 'unix', + 'native-gdbserver', or 'native-extended-gdbserver' boards with this + test, and the KFAILs can be removed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + +2024-08-19 Andrew Burgess + + gdb: avoid '//' in filenames when searching for debuginfo + I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added + recently actually had a KPASS when run with the + native-extended-gdbserver board. This was an oversight when adding + the test. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What happens in the native-extended-gdbserver case is that GDB doesn't + see the target filesystem as local. Now the filename retains the + target: prefix, which means that in the child_path() call both the + sysroot and the CANON_DIR have a target: prefix, and so the + child_path() call succeeds. This allows GDB to progress, try some + additional paths, and then find the debug information. + + So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect + the test to succeed when using the native-extended-gdbserver protocol. + + This leaves one KFAIL when using the native-extended-gdbserver board, + we find the debug information but (apparently) find it in the wrong + file. What's happening is that when GDB builds the filename for the + debug information we end up with a '//' string as a directory + separator, the test regexp only expects a single separator. + + Instead of just fixing the test regexp, I've updated the path_join + function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to + appear in the argument list after the first argument. This means it's + now possible to do this: + + auto result = path_join ("/a/b/c", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + Additionally I've changed path_join so that it avoids adding + unnecessary directory separators. In the above case when the two + paths were joined GDB only added a single separator between 'c' and + 'd'. But additionally, if we did this: + + auto result = path_join ("/a/b/c/", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + We'd still only get a single separator. + + With these changes to path_join I can now make use of this function in + find_separate_debug_file. With this done I now have no KFAIL when + using the native-extended-gdbserver board. + + After this commit we still have 2 KFAIL when not using the + native-gdbserver and unix boards, these will be addressed in the next + commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Reviewed-By: Keith Seitz + +2024-08-19 Guinevere Larsen + + gdb: Fix printing frame when reversing out of a recursive call with clang + Commit bf2813aff8f2988ad3d53e819a0415abf295c91f introduced some logic to + not refresh the step frame id if it detects that the inferior is reverse + stepping out of a recursive call, so that we would still print frame + information once the inferior stops. + + However, that logic was overly specific, and wouldn't be hit for + inferiors compiled with clang because clang adds line table entries that + aren't statements, making process_event_stop_test go through a different + branch on the relevant if statement. + + Fix this by not making the code that detects "reversing out of a + recursion" an else clause to the previous if, but a standalone if block. + + Approved-by: Kevin Buettner + +2024-08-19 GDB Administrator + + Automatic date update in version.in + +2024-08-18 Tom de Vries + + [gdb] Prune inferior after switching inferior + Usually with test-case gdb.python/py-progspace-events.exp I get: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 4116] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M + 28 { /* Nothing. */ }^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + step^M + FreeProgspaceEvent: ^M + do_parent_stuff () at py-progspace-events.c:41^M + 41 ++global_var;^M + (gdb) PASS: gdb.python/py-progspace-events.exp: step + ... + + But occasionally I run into the following FAIL: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + (gdb) FreeProgspaceEvent: ^M + FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout) + ... + + This is caused by a race between the handling of an event, and the + "inferior 1" command. + + In the passing case, the event is handled first. During which prune_inferiors + is called, but it can't remove inferior 2, because it's still the current one. + + In the failing case, the "inferior 1" command is handled first. Then during + handling of the event, prune_inferiors is called, and it can remove inferior 2 + because it's no longer the current one. + + This looks like a test-case issue to me, but ISTM that we can do better: by + calling prune_inferiors asap, at the end of the "inferior 1" command, we + stabilize the moment when the inferior is removed: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + FreeProgspaceEvent: ^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + ... + + This also allows us to simplify the test-case by removing the step command, + which is no longer required to trigger the pruning of the inferior. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR gdb/31440 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440 + +2024-08-18 GDB Administrator + + Automatic date update in version.in + +2024-08-17 Nick Clifton + + Update release readme after making 2.43.1 release + +2024-08-17 GDB Administrator + + Automatic date update in version.in + +2024-08-16 Tom Tromey + + Fix DAP failure when fetching global variables + The relatively new "globals" scope code in DAP has a fairly obvious + bug -- the fetch_one_child method should return a tuple with two + elements, but instead just returns the variable's value. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029 + Reviewed-By: Tom de Vries + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linux + With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into: + ... + (gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada + print pck.fp1_var^M + $1 = 0.3125^M + (gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var + ... + + The problem is that the thumb prologue analyzer overshoot, setting the + breakpoint for main after line 49: + ... + 46 int + 47 main (void) + 48 { + 49 pck__fp1_var++; + ... + and consequently we see the value of pck.fp1_var after line 49 instead of + before line 49. This is PR tdep/31981. + + Work around this by removing line 49 and all similar subsequent lines, which + turn out to be dead code. + + Approved-By: Luis Machado + + Tested on arm-linux. + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-single-step-kernel-helper.exp + On arm-linux I run into: + ... + (gdb) p *kernel_user_helper_version^M + Cannot access memory at address 0xffff0ffc^M + (gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version + ... + + What the test-case is trying to do, is to access a special address in the arm + linux kernel [1] using ptrace, which doesn't seem to work. + + This is with kernel version 6.1.55. Perhaps this used to work, but the kernel + was modified to be more strict with respect to access to this special address. + + Fix this by making the inferior access that special address instead. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR testsuite/32070 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070 + + [1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt + +2024-08-16 Felix Willgerodt + + gdb: Fix gdb.python/py-record-btrace.exp test + My previous patch + + commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD) + Author: Felix Willgerodt + Date: Mon Feb 25 15:30:29 2019 +0100 + + python: Add clear() to gdb.Record. + + exposed a clear function for btrace data in python and added some tests + for it. That caused a regression (PR 32086) when recording with bts. + + This is reproducible even without my patch, when adding + "maintenance btrace clear" to the test. + + When comparing the instructions that get recorded in both cases, the traces + are almost identical, just that the first 3 instructions are missing. + + Before clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555163 : movl $0x0,-0x4(%rbp) + 2 0x000055555555516a : movl $0x0,-0x8(%rbp) + 3 0x0000555555555171 : jmp 0x555555555184 + 4 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 5 0x0000555555555188 : jle 0x555555555173 + 6 0x0000555555555173 : mov -0x8(%rbp),%eax + 7 0x0000555555555176 : mov %eax,%edi + ... + + After clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 2 0x0000555555555188 : jle 0x555555555173 + 3 0x0000555555555173 : mov -0x8(%rbp),%eax + 4 0x0000555555555176 : mov %eax,%edi + ... + + The GDB manual describes this behaviour already: + + maint btrace clear + Discard the branch trace data. The data will be fetched anew and + the branch trace will be recomputed when needed. + + This implicitly truncates the branch trace to a single branch trace + buffer. When updating branch trace incrementally, the branch trace + available to GDB may be bigger than a single branch trace buffer. + + The test with BTS is updating the recorded trace incrementally. After the + clear, the buffer of raw trace data available is not enough to recompute the + whole trace as it was before the clear(), and the first 3 instructions are + missing. + + As increasing the buffer size for BTS didn't help, I propose to fix the test + by moving the testing of clear to the end of the test. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086 + +2024-08-16 Jan Beulich + + gas: don't open-code LEX_*NAME + ... except in read.c's definition of lex_type[], where readbility would + otherwise suffer. + + opcodes/cgen: drop trailing whitespace also for cris + While 919b75f7e289 ("Trailing space in opcodes/ generated files") took + care of permanently zapping trailing whitespace, 547112801156 + ("opcodes: cris: move desc & opc files from sim/") then didn't enhance + the newly added code accordingly. + +2024-08-16 GDB Administrator + + Automatic date update in version.in + +2024-08-15 H.J. Lu + + Revert "Arm: correct macro use in gas testsuite" + This reverts commit cfa18744d435b55bbbbc5ef1ae1df67e84aa1777. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "bfin: correct macro use in gas testsuite" + This reverts commit a1b7023447d19d70bc36d71b7627f457dbfae5ce. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "ia64: correct macro use in gas testsuite" + This reverts commit 2231ac9b9e88191178001d0ae5845e292acb2a56. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "MIPS: correct macro use in gas and ld testsuites" + This reverts commit c0e9aca554e33e900efbd6425c1830f0a20012f5. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 Tom Tromey + + Add another constructor to scoped_restore_current_language + While working on something else, I noticed that this is relatively + common: + + scoped_restore_current_language save; + set_language (something); + + This patch adds a second constructor to + scoped_restore_current_language to simplify this idiom. + + Reviewed-By: Tom de Vries + +2024-08-15 Dimitar Dimitrov + + gas: pru: Fix trailing whitespace handling + With commit 6ae8a30d44f016cafb46a75843b5109316eb1996, arguments followed + by a C-style comment ended up with a trailing space. That extra space + character confused the PRU register name matching, leading to spurious + errors about unrecognized registers. This affected existing code like + newlib's setjmp.s for pru. + + Fix by stripping the trailing whitespace for any argument. + + Even with 6ae8a30d44f016cafb46a75843b5109316eb1996 reverted, this patch + is safe to be applied. + + Successfully regression-tested with GCC and newlib testsuites for pru-unknown-elf. + +2024-08-15 H.J. Lu + + lto: Don't include unused LTO archive members in output + When plugin_object_p is called by elf_link_is_defined_archive_symbol to + check if a symbol in archive is a real definition, set archive member + plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO + archive members in linker output. When plugin_object_p is called as + known used, call plugin claim_file if plugin_format is bfd_plugin_unknown + or bfd_plugin_yes_unused. + + To get the proper support for archives with LTO common symbols with GCC, + the GCC fix for + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 + + is needed. + + bfd/ + + PR ld/32083 + * archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused + the same as bfd_plugin_yes. + * elflink.c (elf_link_is_defined_archive_symbol): Likewise. + * bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused. + * plugin.c (try_claim): Try claim_file_v2 first. + * bfd-in2.h: Regenerated. + + ld/ + + PR ld/32083 + * plugin.c (plugin_call_claim_file): Add an argument to return + if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used. + (plugin_object_p): When KNOWN_USED is false, we call plugin + claim_file if plugin_format is bfd_plugin_unknown and set + plugin_format to bfd_plugin_yes_unused on LTO object. When + KNOWN_USED is true, we call plugin claim_file if plugin_format + is bfd_plugin_unknown or bfd_plugin_yes_unused. + +2024-08-15 Vladimir Mezentsev + + gprofng: fix typo in src/collctrl.cc + gprofng/ChangeLog + 2024-08-13 Vladimir Mezentsev + + * src/collctrl.cc (read_cpuinfo): Fix typo. + +2024-08-15 GDB Administrator + + Automatic date update in version.in + +2024-08-14 Tom Tromey + + Log gdb version and configuration in DAP + I think it would be useful for gdb's DAP logs to come with the version + and configuration information. This might make debugging some bug + reports a little simpler. + +2024-08-14 Tom Tromey + + Notify Python when breakpoint symbol changes + A DAP user noticed that breakpoints set by address were never updated + to show their location after the DAP launch request. It turns out + that gdb does not emit the breakpoint-modified event when this sort of + breakpoint is updated. + + This patch changes gdb to notify the breakpoint-modified observer when + a breakpoint location's symbol changes. This in turn causes the DAP + event to be emitted. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Fix failure with C++ exceptions in DAP + While working on earlier patches, I noticed that the DAP C++ exception + test had some strange results in the log. Digging into this, I found + that while the Ada catchpoints emit a "bkptno" field in the MI result, + the C++ ones do not -- but the DAP code was relying on this. + + This patch fixes the problem by changing which field is examined, and + then updates the tests to verify this. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Make DAP instruction breakpoints unverified + Currently, when a DAP client uses setInstructionBreakpoints, the + resulting breakpoints are created as "verified", even though there is + no symbol file and thus the breakpoint can't possibly have a source + location. + + This patch changes the DAP code to assume that all breakpoints are + unverified before launch. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Introduce exec_mi_and_log for DAP + This adds a new exec_mi_and_log function that wraps gdb.execute_mi and + logs the command. This can be handy when debugging DAP. + + Reviewed-by: Keith Seitz + +2024-08-14 H.J. Lu + + ld: Add an LTO test for common symbol override + Linker checks if a symbol in an archive member is a real definition, not + common, before including the archive member in the link output so that + only a real definition in archive will override the common symbol in + object file. Add an LTO test to verify that a real definition in archive + overrides the common symbol in object file. + + * testsuite/ld-plugin/common-1.c: New file. + * testsuite/ld-plugin/definition-1.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run common tests. + +2024-08-14 Tom Tromey + + Remove unnecessary default argument from initialize_block_iterator + I noticed that initialize_block_iterator has a default value for one + of its arguments, but this is not needed as this function has a single + caller that always passes all arguments. This patch removes the + default. Tested by rebuilding. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix DT_RELR and relaxation interaction + Due to the way BFD implements DT_RELR as a part of relaxation, if in a + relax trip size_relative_relocs has changed the layout, when + relax_section runs only the vma of the section being relaxed is + guaranteed to be updated. Then bad thing can happen. For example, when + linking an auxilary program _freeze_module in the Python 3.12.4 building + system (with PGO + LTO), before sizing the .relr.dyn section, the vma of + .text is 30560 and the vma of .rodata is 2350944; in the final + executable the vma of .text is 36704 and the vma of .rodata is 2357024. + The vma increase is expected because .relr.dyn is squashed somewhere + before .text. But size_relative_relocs may see the state in which .text + is at 36704 but .rodata "is" still at 2350944. Thus the distance + between .text and .rodata can be under-estimated and overflowing + R_LARCH_PCREL20_S2 reloc can be created. + + To avoid this issue, if size_relative_relocs is updating the size of + .relr.dyn, just supress the normal relaxation in this relax trip. In + this situation size_relative_relocs should have been demending the next + relax trip, so the normal relaxation can happen in the next trip. + + I tried to make a reduced test case but failed. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix assertion failure with DT_RELR + In the DT_RELR implementation I missed a code path emiting relative + reloc entries. Then the already packed relative reloc entries will be + (unnecessarily) pushed into .rela.dyn but we've not allocated the space + for them, triggering an assertion failure. + + Unfortunately I failed to notice the issue until profiled bootstrapping + GCC with LTO and -Wl,-z,pack-relative-relocs. The failure can be easily + triggered by linking a "hello world" program with -fprofile-generate and + LTO: + + $ PATH=$HOME/ld-test:$PATH gcc hw.c -fprofile-generate -Wl,-z,pack-relative-relocs -flto + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + collect2: error: ld returned 1 exit status + + And the reduced test case is just incredibly simple (included in the + patch) so it seems I'm just stupid enough to fail to detect it before. + Let's fix it now anyway. + +2024-08-14 Jan Beulich + + gas: correct .irpc handling with empty string + Following 69cab370cf66 ("gas: adjust handling of quotes for .irpc") the + closing quote was mistakenly treated as the first quoted character. + +2024-08-14 Jan Beulich + + x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding + When VexVVVV handling was re-worked, .insn broke: When an opcode + extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is + already occupied, matching what c8866e3ec5e2 ("x86: Drop using + extension_opcode to encode vvvv register") did. + + While adding (bad) POP2 forms, also slightly adjust existing ones: + No need to use XMM registers, and no need to specify %r8 when really + %rax is meant twice (EVEX.vvvv not really being the culprit there, or + else EVEX.V' would also have needed mentioning). + +2024-08-14 Felix Willgerodt + + btrace: Extend ptwrite event decoding. + Call the ptwrite filter function whenever a ptwrite event is decoded. + The returned string is written to the aux_data string table and a + corresponding auxiliary instruction is appended to the function segment. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace, python: Enable ptwrite filter registration. + By default GDB will be printing the hex payload of the ptwrite package as + auxiliary information. To customize this, the user can register a ptwrite + filter function in python, that takes the payload and the PC as arguments and + returns a string which will be printed instead. Registering the filter + function is done using a factory pattern to make per-thread filtering easier. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, linux: Enable ptwrite packets. + Enable ptwrite in the PT config, if it is supported by the kernel. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, gdbserver: Add ptwrite to btrace_config_pt. + This enables gdb and gdbserver to communicate about ptwrite support. If + ptwrite support would be enabled unconditionally, GDBs with older libipt + versions would break. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + python: Add clear() to gdb.Record. + This function allows to clear the trace data from python, forcing to + re-decode the trace for successive commands. + This will be used in future ptwrite patches, to trigger re-decoding when + the ptwrite filter changes. + + Reviewed-By: Eli Zaretskii + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + python: Introduce gdb.RecordAuxiliary class. + Auxiliary instructions are no real instructions and get their own object + class, similar to gaps. gdb.Record.instruction_history is now possibly a + list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary + objects. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Handle stepping and goto for auxiliary instructions. + Print the auxiliary data when stepping. Don't allow to goto an auxiliary + instruction. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record function-call-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the function-call-history. Printing is + active by default, it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record instruction-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the instruction-history. Printing is active by default, + it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Introduce auxiliary instructions. + Auxiliary instructions are pseudo instructions pointing to auxiliary data. + This auxiliary data can be printed in all commands displaying (record + function-call-history, record instruction-history) or stepping through + (stepi etc.) the execution history, which will be introduced in the next + commits. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Andrew Burgess + + gdb: remove unnecessary code relating to limited-length arrays + While reviewing this commit: + + commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528 + Date: Tue Aug 6 19:34:18 2024 +0200 + + Mark unavailable bytes of limited-length arrays when allocating contents + + I spotted that there was some code in value::record_latest relating to + limited-length arrays which appeared redundant. The code was added + with the first introduction on limited-length arrays in commit: + + commit a0c07915778486a950952139d27c01d4285b02b4 + Date: Fri Feb 10 23:49:19 2023 +0000 + + GDB: Introduce limited array lengths while printing values + + The code in question is in value::record_latest. When the value being + recorded is lazy we need to fetch its value before adding it to the + history list. The code I spotted checks to see if the value is lazy, + if we currently have array limiting in effect, and if we do sets + m_limited_length to max_value_size before finally calling fetch_lazy. + + The first thing fetch_lazy does is call allocate_contents to setup the + value's buffer, and in allocate_contents we perform the same set of + checks: if the value is an array, and array length limiting is in + effect then only allocate max_value_size buffer for the contents. + + In ::allocate_contents the `if` condition check is spread out between + ::allocate_contents and ::set_limited_array_length, but I'm certain + it's checking the same condition. + + As such the checks and m_limited_length adjustment in ::record_latest + is redundant and can be removed. + + Out of curiosity I went back to the original a0c07915778486a commit + and removed the same block of code from record_latest_value (as + value::record_latest was called back then) and non of the tests added + by commit a0c07915778486a failed. I think this block of code was + never needed. + + Anyway, I removed the unnecessary code and retested and there are no + regressions. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-08-14 GDB Administrator + + Automatic date update in version.in + +2024-08-13 H.J. Lu + + elf: Never set non_ir_ref_regular for debug reference + Never set non_ir_ref_regular for debug reference since references in + debug sections shouldn't impact LTO output. + + * elflink.c (elf_link_add_object_symbols): Don't check strip for + references in debug sections when setting non_ir_ref_regular. + +2024-08-13 Gerlicher, Klaus + + gdb/gdbarch: fix a dot-space-space in generated files + This is a very small patch to straighten out dot-space-space in these + comments in the gdbarch generated files: + + - /* Skip verify of short_bit, invalid_p == 0 */ + + /* Skip verify of short_bit, invalid_p == 0. */ + + There is no functional change after this commit. + + Approved-By: Andrew Burgess + +2024-08-13 Alan Modra + + gas macro arg1 test + A number of targets pad out the data section, and there are targets + that have 2 or 4 octets per byte. And some even that don't have '#' + as a line comment char. tic6x-elf fails the test with "Error: too + many positional arguments". + + * testsuite/gas/macros/arg1.s: Pad out data section. Use C style + comments. + * testsuite/gas/macros/arg1.d: Adjust to suit. Don't run on + multi-octet per byte targes. xfail tic6x. + +2024-08-13 Alan Modra + + PR32072 dlltool.c initializer-string is too long + PR 32072 + * dlltool.c: Delete unneeded forward function declaraions. + Make buffers used by dlltmp static. + (prefix_encode): Avoid warning. Use stpcpy. + +2024-08-13 GDB Administrator + + Automatic date update in version.in + +2024-08-12 Vladimir Mezentsev + + gprofng: specify the heap data collection range + Extend the -H option: + -H {off|on|N1[-N2]} disable , or enable heap tracing, or + specify the heap data collection range. + The default is "-H off". + + gprofng/ChangeLog + 2024-08-08 Vladimir Mezentsev + + * libcollector/heaptrace.c: Read the range in the -H option. + Do not collect data if the allocated memory is out of range. + * src/collctrl.h (heaptrace_mode): Define as char * value. + * src/envsets.cc: Updated since heaptrace_mode is changed. + * src/collctrl.cc: Accept the extended -H option. + * src/gp-collect-app.cc: Accept the extended -H option. + Remove unused code. + +2024-08-12 Dimitar Dimitrov + + sim: pru: Fix test case assembly with latest GAS + After the recent change in GAS [1], macro arguments must be quoted or + grouped with parenthesis. Add the necessary parenthesis in order to fix + assembly errors like: + mul.s:31: Error: too many positional arguments + + [1] https://sourceware.org/pipermail/binutils/2024-July/136053.html + +2024-08-12 Tom Tromey + + Simplify typename_concat + This patch simplifies typename_concat, changing the return type and + removing the obstack allocation code. The latter is possible because + the only caller using this mode uses the name when creating a new + type, and 'new_type' copies the string to the appropriate obstack + anyway. It also changes typename_concat to use 'concat'. This change + lets us remove a mildly fragile macro as well. + + Approved-By: Simon Marchi + +2024-08-12 H.J. Lu + + gas: Add macro tests for PR gas/32073 + 1. Add a macro test for expression argument with inner white spaces and + a white space before argument added by C preprocessor. + 2. Add a x86-64 specific macro test. + + PR gas/32073 + * testsuite/gas/i386/x86-64-macro-1.d: New file. + * testsuite/gas/i386/x86-64-macro-1.s: Likewise. + * testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1. + * testsuite/gas/macros/arg1.d: New file. + * testsuite/gas/macros/arg1.s: Likewise. + * testsuite/gas/macros/macros.exp: Run arg1. + +2024-08-12 H.J. Lu + + Revert "gas: have scrubber retain more whitespace" + This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996. + + This fixes PR gas/32073. + +2024-08-12 H.J. Lu + + Revert "gas: drop scrubber states 14 and 15" + This reverts commit 7dd0dfbde7ee31167a3b2e192a575493d26b7b0a. + + This is a prerequisite for the PR gas/32073 fix. + +2024-08-12 Simon Marchi + + pre-commit: autoupdate + Run `pre-commit autoupdate`. + + Change-Id: I6623a61b7d1e827360854e825d84c5608a68e07b + +2024-08-12 Bernd Edlinger + + [gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled + There are a couple of ways that readline wrapping can be disabled: + - using "set horizontal-scroll-mode on" in INPUTRC, + - using a TERM setting like TERM=dumb, and + - building gdb with stub-termcap. + + Using a trigger patch in default_gdb_init that adds + "set horizontal-scroll-mode on" to INPUTRC: + ... + - setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"] + + setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"] + ... + we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in + PR testsuite/31201 (which was reported for the stub-termcap case): + ... + WARNING: timeout in accept_gdb_output + Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1): + 0 Quit + 1 <89012345678901234567890123456789W + 2 + ... + 23 + FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap + ... + + Fix this by accepting the horizontal-scroll-mode style output. We do + this only when in CLI mode though, when in TUI wrapping works as before + because it doesn't rely on readline. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201 + +2024-08-12 Simon Marchi + + gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0 + amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards + incompatible changes. Adjust the amd-dbgapi target code accordingly. + Given that the AMD GPU port in upstream GDB today is of limited use + (it's still missing important pieces), we don't really care about + supporting amd-dbgapi versions other than the latest stable one, so no + effort is made to keep compatibility with versions 6.1.2 and older. + + The changes are: + + - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to + AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists + but is deprecated), use the latter. + + - In the callbacks structure, the get_os_pid callback was replaced with + client_process_get_info, which is more general and extensible. + Convert our get_os_pid to a new, equivalent, client_process_get_info + callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE + query, but just return "not available". + + - The xfer_global_memory callback was added to the callbacks structure, + add that new callback. + + - Update configure.ac to check for amd-dbgapi >= 0.75.0. + + Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 + Approved-By: Lancelot Six + Reviewed-By: Alexandra Petlanova Hajkova + +2024-08-12 Simon Marchi + + gdb: pass inferior to gdbarch_update_p + Make the current inferior reference bubble up one level. I think this + makes it clearer what gdbarch_update_p, which is update the passed + inferior's architecture (although the function name could probably be + better). + + When gdbarch_find_by_info, it is possible for the new architecture's + init callback to be called. I have not audited all of them (there are + just too many), it's possible that some of them do care about the + current inferior, for some reason (for instance, if one of them makes a + target call). If so, they should be changed too. + + Change-Id: I89f012188d7fdca395a830f4b013743565f26847 + +2024-08-12 Simon Marchi + + gdb: pass inferior to target_current_description + Make the current inferior reference bubble up one level. + + Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd + +2024-08-12 Simon Marchi + + gdb: change names of enumerations in enum flags selftest + When reading this test (in the context of PR 31331), I had trouble + understanding the tests, because of the abbreviated names. I would + prefer if the names were a bit more explicit, like this. + + Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf + +2024-08-12 Simon Marchi + + gdb, gdbsupport: use `using` in enum flags code + I think that `using` is easier to read than `typedef`, and it's the + modern C++ thing anyway. + + Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2 + +2024-08-12 Simon Marchi + + gdbsupport: remove C enum flags fallback + This might have been useful during the C -> C++ conversion (not sure), + but it doesn't appear useful today. I don't see when enum-flags.h would + be used in a C context. + + Change-Id: I6c7ed655757248a62a1bf6615995f42e8aa2b4bd + +2024-08-12 Simon Marchi + + gdb/NEWS: announce removal of QNX Neutrino support + QNX Neutrino support was removed here [1], but I forgot to mention in in + NEWS. + + [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=36fb20fa93484b104d91e42e38930ee8629192ab + + Change-Id: I8db7957acdd0be3c1e0b751c7c245870c4cd7101 + Approved-By: Eli Zaretskii + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_text + Make the current program space reference bubble up one level. Use a + program space from the context whenever that makes sense. + + Change-Id: Id3b0bf4490178d71a9aecdbf404b9287c22b30f5 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_linkage + Make the current_program_space reference bubble up one level. + + Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to get_symbol_leading_char + Make the current_program_space references bubble up one level. In this + case, I think it makes sense to use m_objfile's program space. + + Change-Id: Ibecb89b5e8a0363328240f1675d0fb95ff99c99a + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol + >From what I can see, lookup_minimal_symbol doesn't have any dependencies + on the global current state other than the single reference to + current_program_space. Add a program_space parameter and make that + current_program_space reference bubble up one level. + + Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove lookup_bound_minimal_symbol + Now that lookup_minimal_symbol has default values for sfile and objf, + calling lookup_bound_minimal_symbol is identical to calling + lookup_minimal_symbol without sfile and objf. Remove + lookup_bound_minimal_symbol, replace call sites with + lookup_minimal_symbol. + + Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: make lookup_minimal_symbol objf and sfile parameters optional + Most calls to lookup_minimal_symbol don't pass a value for sfile and + objf. Make these parameters optional (have a default value of + nullptr). And since passing a value to `objf` is much more common than + passing a value to `sfile`, swap the order so `objf` comes first, to + avoid having to pass a nullptr value to `sfile` when wanting to pass a + value to `objf`. + + Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: drop struct keyword when using bound_minimal_symbol + This is a simple find / replace from "struct bound_minimal_symbol" to + "bound_minimal_symbol", to make things shorter and more consisten + througout. In some cases, move variable declarations where first used. + + Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove find_and_open_solib so_list method + Now that the nto port is removed, this is unused. + + Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8 + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdbsupport: remove #ifndef REALTIME_LO in signals.cc + REALTIME_LO was only possibly previously defined in config/nm-nto.h, + which is now removed. So we can remove the #ifndef protecting against a + redefinition of REALTIME_LO in gdbsupport/signals.cc. + + Change-Id: I021b9518ceaa6223bd480ff1e07e9a978b0b241e + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: remove QNX Neutrino support + Remove the support for the QNX Neutrino OS (tdep and native bits). This + has been unmaintained for years, and we don't have a way to see if it + works (or even builds, for the native parts). Without somebody actively + maintaining it, this is just a burden for developers, especially that + this port does a few weird unique things that require reasoning about + when doing big change. + + Support for GDBserver was removed in 2020, commit 613f149a90d6 + ("gdbserver: remove support for Neutrino"). + + Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: rename target-delegates.c to target-delegates-gen.c + Following this suggestion: + + https://inbox.sourceware.org/gdb-patches/2a0520ec-ccfe-4fc3-b051-7b8c60294de5@efficios.com/T/#md537792a1871addf153f3e406224f9baf025414a + + Change-Id: I30988c46505f130ca16155891958f92621cada97 + Approved-By: John Baldwin + Approved-By: Andrew Burgess + +2024-08-12 GDB Administrator + + Automatic date update in version.in + +2024-08-11 GDB Administrator + + Automatic date update in version.in + +2024-08-10 H.J. Lu + + ld: Add PR ld/32067 tests + Add PR ld/32067 tests with the compiler driver since the -plugin option + is needed to trigger this --oformat binary bug. + + PR ld/32067 + * testsuite/ld-i386/i386.exp: Run PR ld/32067 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/start.s: Add .note.GNU-stack section. + * testsuite/ld-x86-64/pr32067.s: New file. + +2024-08-10 Alan Modra + + PR32067, ld -Wl,--oformat,binary crash in _bfd_elf_link_keep_memory + The direct fix for this segfault is to test for a non-NULL bed in + _bfd_elf_link_keep_memory, but also there isn't much point in running + code for LTO if the output is binary. + + PR 32067 + * elflink.c (_bfd_elf_link_keep_memory): Test for non-NULL bed. + (elf_link_add_object_symbols): Don't run the loop setting + non_ir_ref_regular if the output hash table is not ELF. + +2024-08-10 GDB Administrator + + Automatic date update in version.in + +2024-08-09 Bernd Edlinger + + Fix test failure when TUI is not enabled + This adds a missing allow_tui_tests guard. + + When tui is not enabled this test case does + typically fail: + + FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui + + Approved-By: Tom de Vries + +2024-08-09 Stephan Rohr + + gdb: adjust the default place of 'list' to main's prologue + The 'list' command prints around the 'main' function if the current + source location is not set. The prologue of 'main' is skipped and the + first real line of 'main' is offset by 'lines_to_print - 1'. This is + incorrect, the location should be defaulted to main's prologue without + applying offsets (similar to 'list main'). Printing around the selected + line is then done in 'list_around_line'. + + The patch also fixes an issue if the list command is used before the + program is started. For example, with the following code: + + 26 static void attribute ((used)) ambiguous_fun (void) {} + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + GDB offsets the relevant line by 'lines_to_print - 1' and then by another + 'lines_to_print / 2' and prints: + + (gdb) list + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + + With this patch, GDB correctly prints: + + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + Approved-By: Andrew Burgess + +2024-08-09 Jan Beulich + + gas: drop scrubber states 14 and 15 + While sadly 5262831592fb doesn't say anything on why these would have + been needed, the latest with the removal of most of the opcode vs + operands distinction in the scrubber these shouldn't be needed anymore. + The implementation was a little questionable anyway, in moving back to + states expecting labels, when clearly labels shouldn't really be + following predicates (in practice, due to another bug, at least ia64 + permits such). + +2024-08-09 Jan Beulich + + gas: have scrubber retain more whitespace + According to the description of the state machine, the expectation + appears to be that (leaving aside labels) any insn mnemonic or + directive would be followed by a comma separated list of operands. That + may have been true very long ago, but the latest with the advent of more + elaborate macros this isn't rhe case anymore. Neither macro parameters + in macro definitions nor macro arguments in macro invocations are + required to be separated by commas. Hence whitespace serves a crucial + role there. Plus even without "real" macros issues exist, in e.g. + + .irp n, ... + insn\n\(suffix) operand1, operand2 + .endr + + Whitespace following the closing parenthesis would have been removed + (ahead of even processing the .irp), as the "opcode" was deemed to have + ended earlier already. + + Therefore, squash the distinction between "opcode" and operands, i.e. + fold state 10 back into state 3. Also drop most of the distinction + between "symbol chars" and "relatively normal" ones. Not entirely + unexpectedly this results in the need to skip whitespace in a few more + places in arch-specific code (and quite likely more changes are needed + for insn forms not covered by the testsuite). + + As a result the D10V special case is no longer necessary. + + In config/tc-sparc.c also move a comment to be next to the code being + commented. + + In opcodes/cgen-asm.in some further cleanup is done, following the local + var adjustments. + +2024-08-09 Jan Beulich + + MIPS: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + aarch64: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + Arm: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + m32r: move scrubber override to target header + Other than LEX_IS_* settings, such #define-s don't belong into the + common source file. + + Arm: respect line separators for .symver scrubber special case + Directives end at "line" (really: statement) separators, not just at + new-line chars. + + gas: respect CR_EOL also for scrubbing + While apparently intended to be only externally controlled (e.g. via + specifying CFLAGS at make invocation), we should still keep scrubber and + lexer in sync in this regard. There's one place which imo was previously + wrong already, but would go further wrong and hence is being adjusted + right here: An .mri directive can be terminated by any kind of "line" + (really: statement) separators. + + gas: have scrubber also respect quoted labels + For the handling of ':' elsewhere in the scrubber to be correct with + regard to labels, the state after parsing a string found at the start of + a line must match that after finding a symbol character at the start of + a line. (Things are largely okay when there's whitespace ahead of the + label: Whitespace after the colon then is retained rather than dropped + for typical targets like x86, but read.c will know to deal with that.) + +2024-08-09 Nelson Chu + + RISC-V: PR32014, .option directives shuoldn't affect elf attribute. + The .option arch/rvc/norvc/push/pop directives can only take effect for a + small/large specific code region, so they are not file-level architecture + setting. They should only affect the mapping symbols only rather than the + file-level elf architecture attribute. Otherwise, the elf architecture + attribute will appear to missing some extensions when -flto merges files + with different .option architecture settings. + + gas/ + PR 32014 + * config/tc-riscv.c (file_arch_str): New const char *, rather than the + arch_str in the riscv_rps_as.subset_list, it's file-level so only be + affected by .attribute arch directive. + (riscv_reset_subsets_list_arch_str): Renamed to riscv_set_arch_str, and + also can handle both file_arch_str and arch_str in subset_list, just + give the pointer address as the input. + (riscv_set_arch): Called by -march and .attribute arch, so set both + file_arch_str and arch_str in subset_list. + (s_riscv_option): Updated .option arch/rvc/norvc/push/pop that only + set the arch_str in subset_list. + (riscv_write_out_attrs): Output elf architecture attribute according to + file_arch_str. Freed file_arch_str. + * doc/c-riscv.texi: Added destrbution that .option directives shouldn't + affect the elf attribute settings. + * testsuite/gas/riscv/option-arch.s: From option-arch-01/02/03 merged. + * testsuite/gas/riscv/option-arch-dis.d: Likewise, for dis-assembler. + * testsuite/gas/riscv/option-arch-attr.d: Likewise, to check readelf -A. + +2024-08-09 GDB Administrator + + Automatic date update in version.in + +2024-08-08 Richard Henderson + + gas: sparc: Fix faligndatai assembly and disassembly + The first operand is a general register, not an fp register; + the third operand is encoded into RS2, not RS3; + the second operand must match the destination operand. + +2024-08-08 Tom de Vries + + [gdb/python] Fix handling of ^C during disassembly + Inspired by the trigger patch I used here [1], I tried this in + gdbpy_print_insn: + ... + /* Call into the registered disassembler to (possibly) perform the + disassembly. */ + + set_quit_flag (); + PyObject *insn_disas_obj = (PyObject *) disasm_info; + gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (), + insn_disas_obj, + ... + and with test-case gdb.python/py-disasm-exec.exp ran into: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: Python Exception : ^M + ^M + unknown disassembler error (error = -1)^M + (gdb) + ... + + This is incorrect, the KeyboardInterrupt should propagate and interrupt the + command. + + Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in + gdbpy_print_insn, giving us instead: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: ^M + Quit^M + (gdb) + ... + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + [1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html + +2024-08-08 Tom de Vries + + [gdb] Handle ^C during disassembly + In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while + disassembling. + + I managed to reproduce this on aarch64-linux in a Leap 15.5 container using + this trigger patch: + ... + gdb_disassembler_memory_reader::dis_asm_read_memory + (bfd_vma memaddr, gdb_byte *myaddr, unsigned int len, + struct disassemble_info *info) noexcept + { + + set_quit_flag (); + return target_read_code (memaddr, myaddr, len); + } + ... + and a simple gdb command line calling the disassemble command: + ... + $ gdb -q -batch a.out -ex "disassemble main" + ... + + The following scenario leads to the fatal error: + - the disassemble command is executed, + - set_quit_flag is called in + gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a + user pressed ^C, + - target_read_code calls QUIT, which throws a + gdb_exception_quit, + - the exception propagation mechanism reaches c code in libopcodes and a fatal + error triggers because the c code is not compiled with -fexception. + + Fix this by: + - wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in + catch_exceptions (which consequently needs moving to a header file), and + - reraising the caught exception in default_print_insn using QUIT. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025 + +2024-08-08 GDB Administrator + + Automatic date update in version.in + +2024-08-07 Jan Beulich + + score: drop TC_ALPHA code + I can't see how that could ever have come into play. + +2024-08-07 Jan Beulich + + gas: drop dead VMS code from command line handling + The only time 'v' was overridden, allowing for an optional value, was + when OBJ_VMS support still existed (until a little less than 20 years + ago). Drop the respective leftovers. + + With that OPTION_VERBOSE also becomes redundant and hence is being + dropped. + +2024-08-07 Jan Beulich + + VAX: drop OBJ_VMS leftovers + OBJ_VMS support was dropped almost 20 years ago (e330299ed5ee). Drop + respective code from tc-vax.c as well. + + While there, make adjustments for OBJ_ELF as well: -K was dropped over + 20 years ago (530556a951f5), yet left in md_shortopts. OPTION_PIC isn't + really necessary either; 'k' can be used instead. And then the ELF + options available weren't displayed by md_show_usage(). + +2024-08-07 Jan Beulich + + gas: improve unrecognized command line option diagnostic + Printing optc with %c makes sense only when optc is actually a + character. Add logic to also deal with unrecognized long options, + rejected by md_parse_option() rather than get_opt_long_only(). Also + quote the reproduced strings, such that possible included whitespace + can be recognized. + +2024-08-07 Nelson Chu + + gas/NEWS: Moved RISC-V Zimop/Zcmop changes into 2.43 section due to backport. + +2024-08-07 Alan Modra + + loongarch ld testsuite xpasses + Some tests started passing with commit 3a83f0342e54. However, + supporting a changed ld output format is not so simple, and the change + to the loongarch_elf_hash_table macro needs further changes to the + rest of the code. It is true that some uses of + loongarch_elf_hash_table do not need to check the type of the hash + table, but others like loongarch_elf_relax_section do need to check. + bfd_relax_section is called in lang_size_sections using the input bfd, + not the output bfd. If the input bfd may be of different type to the + output, then the hash table type must be checked before accessing + elements of the hash table. This patch corrects + loongarch_elf_relax_section. I haven't checked all the uses of the + hash table throughout the loongarch backend. + + bfd/ + * elfnn-loongarch.c (loongarch_elf_relax_section): Don't relax + unless the hash table is loongarch_elf_link_hash_table. + Move variable declarations. Formatting. + ld/ + * testsuite/ld-elf/pr21884.d: Don't xfail loongarach. + * testsuite/ld-unique/pr21529.d: Likewise. + +2024-08-07 GDB Administrator + + Automatic date update in version.in + +2024-08-06 Hannes Domani + + Mark unavailable bytes of limited-length arrays when allocating contents + Using 'output' to print arrays larger than max-value-size, with only + repeating elements, can cause gdb to crash: + ``` + $ cat a.c: + char a[1000000]; + + int main() + { + return a[0]; + } + $ gdb -q a + (gdb) print a + $1 = {0 '\000' , } + (gdb) output a + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + Using 'print' works, because value::record_latest sets the unavailable + bytes of the value when it's added to the value history. + But 'outout' doesn't do that, so the printing tries to access more bytes + than are available. + + The original problem in PR32015 was about using 'print' of a dynamic + array in a D program. + Here the crash happens because for 'print' the value was a struct with + length/ptr fields, which is converted in d-valprint.c into an array. + So value::record_latest didn't have a chance to mark the unavailable + bytes in this case. + + To make sure the unavailable bytes always match the contents, this fixes + it by marking the unavailable bytes immediately after the contents are + allocated. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015 + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-08-06 Indu Bhagat + + gas: scfi: replace verbose expressions with local vars + Replace the scattered and repeated uses of verbose expressions with + variables. E.g., + ginsn_get_src_reg (src1) -> src1_reg + ginsn_get_src_type (src1) -> src1_type + etc. + + This hopefully makes the logic bit more maintainable. While at it, + include minor adjustments to make few checks in gen_scfi_ops () more + precise: + - When getting imm value from src operand, ensure the src type is + GINSN_SRC_IMM, + - When getting reg from src operand, ensure the src type is checked + too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate). + + On the other hand, the changes in verify_heuristic_traceable_reg_fp () + and verify_heuristic_traceable_stack_manipulation () are purely + mechanical. + + gas/ + * scfi.c (verify_heuristic_traceable_reg_fp): Add new local + vars and reuse them. + (verify_heuristic_traceable_stack_manipulation): Likewise. + (gen_scfi_ops): Likewise. Additionally, make some conditionals + more precise. + +2024-08-06 Hau Hsu + + RISC-V: map zext.h to pack/packw if Zbkb is enabled + The `zext.h` is zero-extend halfword instruction that belongs to Zbb. + Currently `zext.h` falls back to 2 shifts if Zbb is not enabled. However, the + encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which + belongs to Zbkb. The instructions pack the low halves of rs1 and rs2 into rd. + When rs2 is zero (x0), they behave like zero-extend instruction, and the + encoding are exactly the same as zext.h. + + Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled, + instead of 2 shifts. This reduces one instruction. + + This patch does this by making `zext.h` also available for Zbkb. + + opcodes/ + * riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use + `ZBB_OR_ZBKB` instruction class. + + gas/ + * testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to + pack/packw encoding. + * testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise. + * testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise. + +2024-08-06 Mary Bennett + + RISC-V: Add support for XCvBitmanip extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvbitmanip` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvbitmanip. + * testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.s: New Test. + + include/opcode/ChangeLog: + * riscv-opc.h: Add corresponding MATCH and MASK macros for + XCVbitmanip. + * riscv.h: Add corresponding EXTRACT and ENCODE macros for + XCVbitmanip. + (enum riscv_insn_class): Add the XCVbitmanip instruction class. + + opcodes/ChangeLog: + * riscv-dis.c (print_insn_args): Add custom operands `Xc6` and `Xc7`. + * riscv-opc.c: Add XCvBitmanip instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zcmop extension + This implements the Zcmop (Compressed Zimop) extension, as of version 1.0. + + View detailed information in: + + + The Zcmop extension requires the Zca extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zcmop. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zcmop.d: New test. + * testsuite/gas/riscv/zcmop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zcmop. + (MATCH_C_MOP_1, MATCH_C_MOP_3, MATCH_C_MOP_5, MATCH_C_MOP_7, + MATCH_C_MOP_9, MATCH_C_MOP_11, MATCH_C_MOP_13, MATCH_C_MOP_15): Define. + (MASK_C_MOP_1, MASK_C_MOP_3, MASK_C_MOP_5, MASK_C_MOP_7, + MASK_C_MOP_9, MASK_C_MOP_11, MASK_C_MOP_13, MASK_C_MOP_15): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZCMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zcmop instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zimop extension + This implements the Zimop (May-Be-Operations) extension, as of version 1.0. + + View detailed information in: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zimop + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zimop.d: New test. + * testsuite/gas/riscv/zimop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zimop. + (MATCH_MOP_R_0, MATCH_MOP_R_1, MATCH_MOP_R_2, MATCH_MOP_R_3, + MATCH_MOP_R_4, MATCH_MOP_R_5, MATCH_MOP_R_6, MATCH_MOP_R_7, + MATCH_MOP_R_8, MATCH_MOP_R_9, MATCH_MOP_R_10, MATCH_MOP_R_11, + MATCH_MOP_R_12, MATCH_MOP_R_13, MATCH_MOP_R_14, MATCH_MOP_R_15, + MATCH_MOP_R_16, MATCH_MOP_R_17, MATCH_MOP_R_18, MATCH_MOP_R_19, + MATCH_MOP_R_20, MATCH_MOP_R_21, MATCH_MOP_R_22, MATCH_MOP_R_23, + MATCH_MOP_R_24, MATCH_MOP_R_25, MATCH_MOP_R_26, MATCH_MOP_R_27, + MATCH_MOP_R_28, MATCH_MOP_R_29, MATCH_MOP_R_30, MATCH_MOP_R_31, + MATCH_MOP_RR_0, MATCH_MOP_RR_1, MATCH_MOP_RR_2, MATCH_MOP_RR_3, + MATCH_MOP_RR_4, MATCH_MOP_RR_5, MATCH_MOP_RR_6, MATCH_MOP_RR_7): Define. + (MASK_MOP_R_0, MASK_MOP_R_1, MASK_MOP_R_2, MASK_MOP_R_3, MASK_MOP_R_4, + MASK_MOP_R_5, MASK_MOP_R_6, MASK_MOP_R_7, MASK_MOP_R_8, MASK_MOP_R_9, + MASK_MOP_R_10, MASK_MOP_R_11, MASK_MOP_R_12, MASK_MOP_R_13, + MASK_MOP_R_14, MASK_MOP_R_15, MASK_MOP_R_16, MASK_MOP_R_17, + MASK_MOP_R_18, MASK_MOP_R_19, MASK_MOP_R_20, MASK_MOP_R_21, + MASK_MOP_R_22, MASK_MOP_R_23, MASK_MOP_R_24, MASK_MOP_R_25, + MASK_MOP_R_26, MASK_MOP_R_27, MASK_MOP_R_28, MASK_MOP_R_29, + MASK_MOP_R_30, MASK_MOP_R_31, MASK_MOP_RR_0, MASK_MOP_RR_1, + MASK_MOP_RR_2, MASK_MOP_RR_3, MASK_MOP_RR_4, MASK_MOP_RR_5, + MASK_MOP_RR_6, MASK_MOP_RR_7): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZIMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zimop instructions. + +2024-08-06 GDB Administrator + + Automatic date update in version.in + +2024-08-05 Simon Marchi + + gdb: rename gdbarch.c to gdbarch-gen.c + For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind + if all generated files had the `-gen` suffix. + + Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428 + Approved-By: John Baldwin + +2024-08-05 Jan Beulich + + gas: maintain line numbers correctly after #APP / #NO_APP + Maintaining line numbers correctly both inside the region and past it + requires special care. The SB produced there is somewhat different from + that produced for e.g. macro expansions, and hence also needs treating + differently: In particular we aren't doing anything resembling macro + expansion here. + + The new testcase may be a little misplaced in macros/, but that's where + all the other #APP / #NO_APP ones are. + +2024-08-05 Jan Beulich + + gas: generalize / tighten #APP / #NO_APP recognition + For one '#' may not be in line_comment_chars[] in the first place. Look + for just it when it is (these "directives" are akin to C preprocessor + directives after all), but accept any other line comment character + otherwise (in read.c further requiring a match on the counterpart + "directive"). + + Then, when in the middle of a file, the constructs should be all on + their own on a line. There needs to be a newline ahead of them and + after them. + + Finally '\n' may not be the only end-of-line character. Accept any (but + not end-of-statement ones) in read.c, while making sure in input-file.c + there is one in the first place - merely any kind of whitespace isn't + good enough. + +2024-08-05 Jan Beulich + + gas: recognize #APP at start-of-physical-line only + It's not valid to recognize it after mere line separators (often + semicolon) or after labels, let alone after tc_unrecognized_line() + perhaps having parsed off parts of a line. It shouldn't even be + preceded by whitespace, aiui. + + However, keep ignoring line comments as before, for backwards + compatibility. + +2024-08-05 Tom de Vries + + [gdb] Notice when stepping into different file + Consider the following test-case: + ... + $ cat -n test.c + 1 int var; + 2 + 3 int + 4 foo (void) + 5 { + 6 var = 1; + 7 #include "test.h" + 8 } + 9 + 10 int + 11 main () + 12 { + 13 return foo (); + 14 } + $ cat -n test.h + 1 return 1; + $ gcc test.c -g + ... + + When stepping through the test-case, gdb doesn't make it explicit that line 1 + is not in test.c: + ... + Temporary breakpoint 1, main () at test.c:13 + 13 return foo (); + (gdb) step + foo () at test.c:6 + 6 var = 1; + (gdb) n + 1 return 1; + (gdb) + 8 } + (gdb) + ... + which makes it easy to misinterpret the output. + + This is with the default "print frame-info" == auto, with documented + behaviour [1]: + ... + stepi will switch between source-line and source-and-location depending on the + program counter. + ... + + What is actually implemented is that source-line is used unless stepping into + or out of a function. + + The problem can be worked around by using + "set print frame-info source-and-location", but that's a bit verbose. + + Instead, change the behaviour of "print frame-info" == auto to also use + source-and-location when stepping into another file, which gets us: + ... + (gdb) n + foo () at test.h:1 + 1 return 1; + ... + + Tested on x86_64-linux. + + Reviewed-By: Kevin Buettner + Reviewed-By: Kévin Le Gouguec + + PR gdb/32011 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo + +2024-08-05 mengqinggang + + LoongArch: Add support for OUTPUT_FORMAT("binary") + In binary output format, loongarch_elf_hash_table return NULL and result + in segment fault. + + When ld output binary file, it seems that elf related functions should + not be called. But loongarch_elf_relax_section be called and + loongarch_elf_hash_table cause segment fault. + + Just redefined loongarch_elf_hash_table and always return + link_info->hash. + + The tests of binutils, glibc and gcc is ok. + + 0 loongarch_elf_relax_section () + 1 0x000055555557ab28 in lang_size_sections_1 () + 2 0x000055555557a16c in lang_size_sections_1 () + 3 0x000055555557b0a8 in one_lang_size_sections_pass () + 4 0x000055555557b478 in lang_size_sections () + 5 0x000055555557e65c in lang_relax_sections () + 6 0x000055555559f9c8 in ldelf_map_segments () + 7 0x000055555559783c in gldelf64loongarch_after_allocation () + 8 0x000055555558dac0 in ldemul_after_allocation () + 9 0x000055555557f6c0 in lang_process () + 10 0x0000555555585314 in main () + +2024-08-05 GDB Administrator + + Automatic date update in version.in + +2024-08-04 Nick Clifton + + Update release-README after completing the 2.43 release. + +2024-08-04 GDB Administrator + + Automatic date update in version.in + +2024-08-03 H.J. Lu + + LTO: Restore the wrapper symbol check for standard function + Call unwrap_hash_lookup to restore the wrapper symbol check for standard + function since reference to standard function may not show up in LTO + symbol table: + + [hjl@gnu-tgl-3 pr31956-3]$ nm foo.o + 00000000 T main + U __real_malloc + 00000000 T __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ lto-dump -list foo.o + Type Visibility Size Name + function default 0 malloc + function default 0 __real_malloc + function default 3 main + function default 5 __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ make + gcc -O2 -flto -Wall -c -o foo.o foo.c + gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o + /usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main': + :(.text.startup+0xa): undefined reference to `__wrap_malloc' + collect2: error: ld returned 1 exit status + make: *** [Makefile:22: x] Error 1 + [hjl@gnu-tgl-3 pr31956-3]$ + + Also add a test to verify that the unused wrapper is removed. + + PR ld/31956 + * plugin.c (get_symbols): Restore the wrapper symbol check for + standard function. + * testsuite/ld-plugin/lto.exp: Run the malloc test and the + unused test. + * testsuite/ld-plugin/pr31956c.c: New file. + * testsuite/ld-plugin/pr31956d.c: New file. + * testsuite/ld-plugin/pr31956d.d: New file. + +2024-08-03 GDB Administrator + + Automatic date update in version.in + +2024-08-02 Simon Marchi + + gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extension + Now that all known uses of VLAs within GDB are removed, remove the + `-Wno-vla-cxx-extension` (which was used to silence clang warnings) and + add `-Wvla`, such that any use of a VLA will trigger a warning. + + Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 + Reviewed-By: Keith Seitz + +2024-08-02 Simon Marchi + + gdb: remove uses of VLA + Remove uses of VLAs, replace with gdb::byte_vector. There might be more + in files that I can't compile, but it's difficult to tell without + actually compiling on all platforms. + + Many thanks to the Linaro pre-commit CI for helping find some problems + with an earlier iteration of this patch. + + Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e + Reviewed-by: Keith Seitz + +2024-08-02 Guinevere Larsen + + gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robust + Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not + actually compiling the test with some debuginfo in the relevant part, + and while fixing I noticed that the base assumption of the "some" case + was wrong, GDB would select some symtab as a default location and the + test would always fail. This fix makes printing the default location + only be tested when there is no debuginfo. + + When testing with no debuginfo, if a system had static libc debuginfo, + the test would also fail. To add an extra layer of robustness to the + test, this rewrite also strips any stray debuginfo from the executable. + The test would only fail now if it runs in a system that can't handle + stripped debuginfo and has static debuginfo pre-installed. + + Reported-By: Tom de Vries + Reported-By: Thiago Jung Bauermann + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721 + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2024-08-02 Simon Marchi + + gdb: remove inline_frame::skipped_frames + While reviewing [1], it occurred to me that having both the + skipped_frames counter and the skipped_syms vector is redundant. When + stepping into an inline frame, we can just pop the last element. + + [1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a + + Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198 + Approved-By: Andrew Burgess + +2024-08-02 Nick Clifton + + Updated Bulgarian translation for the binutils/ directory + +2024-08-02 Aapo Rantalainen + + Fix typo in --help output of the strings program. + PR 31940 + +2024-08-02 Guinevere Larsen + + gdb/testsuite: fix gdb.python/py-framefilter-invalidarg.exp with clang + The final test of gdb.python/py-framefilter-invalidarg.exp expected that + the the backtrace only printed the source file name. However, when using + clang, gdb will always print the full path to the file, which would + cause the test to fail. This commit introduces a regexp that optionally + matches paths, preprended to the file name, which fixes the clang + failure without introducing gcc failures. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: extend XFAIL to gdb.fortran/entry-point.exp to clang too + The test gdb.fortran/entry-point.exp already has an XFAIL when trying to + set a breakpoint in mod::mod_foo because gcc puts that subprogram in the + wrong scope in the debug information. Clang's debug information looks + the same as gcc's, so the test to setup the xfail has been extended to + also include clang. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: add build-id compile flag to tests that expect it + Clang doesn't add build-id information by default, unlike gcc. This + means that tests that rely on build-id being available and don't + explicitly add it to the compilation options will fail with clang. + This commit fixes the fails in gdb.python/py-missing-debug.exp, + gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp + and gdb.server/solib-list.exp + + Approved-By: Andrew Burgess + +2024-08-02 Jan Beulich + + gas: drop unnecessary use of tc_comment_chars + The override is necessary only when a target needs other than an array + of const char. + + For cris drop redundant sibling declarations at the same time. + +2024-08-02 Jan Beulich + + gas: correctly deal with line comments when not preprocessing + Internal naming of functions / data as well as commentary mixes lines + and statements. It is presumably this confusion which has led to the + wrong use of ignore_rest_of_line() when dealing with line comments in + read_a_source_file(). We shall not (silently) produce different output + depending on whether -f is passed (for suitable input). + + Introduce two new helper macros, intended to be used in favor of open- + coded accesses to is_end_of_line[]. To emphasize the difference, convert + ignore_rest_of_line() right away, including adjustments to its comments. + + Since most targets have # in line_comment_chars[], add a target- + independent test for that, plus an x86-only one also checking for non-# + to work as intended. + +2024-08-02 GDB Administrator + + Automatic date update in version.in + +2024-08-01 Indu Bhagat + + gas: ginsn: minor improvements in ginsn_dst_print and ginsn_src_print + Keep the two symmetrical looking. Makes sense to perform the sanity + checks similarly too. + + gas/ + * ginsn.c (ginsn_src_print): Buffer up result of snprintf and + add sanity checks on the value. + (ginsn_dst_print): Use switch case instead. + +2024-08-01 Indu Bhagat + + gas: ginsn: do not emit an unnecessary trailing comma in textual dump + For ginsns with less than 2 source operands or no destination operands, + the current textual dump contains a superfluous comma, like the relevant + testcases show. + + Adjust the code a bit to not emit the lone trailing comma. Also, adjust + the aarch64 and x86_64 testcases. + + gas/ + * ginsn.c (ginsn_src_print): Do not use a trailing comma when + printing the src of ginsn. + (ginsn_print): Check the strlen and prefix a comma before the + src string. + + gas/testsuite/ + * gas/scfi/aarch64/ginsn-cofi-1.l: Adjust the expected textual + dump of the ginsn. + * gas/scfi/x86_64/ginsn-cofi-1.l: Likewise. + +2024-08-01 Indu Bhagat + + gas: x86: ginsn: handle previously missed indirect call and jmp ops + Some flavors of indirect call and jmp instructions were not being + handled earlier, leading to a GAS error (#1): + (#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI" + + Not handling jmp/call (direct or indirect) ops is an error (as shown + above) because SCFI needs an accurate CFG to synthesize CFI correctly. + Recall that the presence of indirect jmp/call, however, does make the + CFG ineligible for SCFI. In other words, generating the ginsns for them + now, will eventually cause SCFI to bail out later with an error (#2) + anyway: + (#2) "Error: untraceable control flow for func 'XXX'" + + The first error (#1) gives the impression of missing functionality in + GAS. So, it seems cleaner to synthesize a GINSN_TYPE_JUMP / + GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with + the error as expected. + + The handling for these indirect jmp/call instructions is similar, so + reuse the code by carving out a function for the same. + + Adjust the testcase to include the now handled jmp/call instructions as + well. + + gas/ + * config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New + function. + (x86_ginsn_new): Refactor out functionality to above. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output. + * gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of + jmp/call opcodes. + +2024-08-01 Hui Li + + gdb: LoongArch: Add show-debug-regs maintenance command + This patch register the command "maint set show-debug-regs on/off" + and make it settable by the user. If show-debug-regs is enabled, + the debug register values are shown when GDB inserts or removes a + hardware breakpoint or watchpoint. This is helpful for the use and + development of hardware watchpoints. + + With this patch, the effect of this maintenance command as follows: + + lihui@bogon:~$ cat test.c + int a = 0; + int main() + { + a = 1; + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + lihui@bogon:~$ gdb test + ... + (gdb) watch a + Hardware watchpoint 1: a + (gdb) maint set show-debug-regs on + (gdb) r + Starting program: /home/lihui/test + ... + ... + + prepare_to_resume thread 41525 + ... + insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1 + ... + remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x0, ctrl=0x00000000, ref.count=0 + + Hardware watchpoint 1: a + + Old value = 0 + New value = 1 + main () at test.c:5 + 5 return 0; + (gdb) + +2024-08-01 Alan Modra + + skip_attr_bytes assertion (data) <= (end) fail + get_type_abbrev_from_form is lax in not limiting data for a uleb to + the current CU, because DW_FORM_ref_addr allows access to other CU's + data. This can lead to an assertion fail when skipping or reading + attributes in get_type_signedness. + + * dwarf.c (get_type_abbrev_from_form): Limit uleb data to map end + for ref_addr, cu_end otherwise. + +2024-08-01 Gustavo Romero + + gdb: AArch64: Support MTE on baremetal + This commit moves aarch64_linux_memtag_matches_p, + aarch64_linux_set_memtags, aarch64_linux_get_memtag, and + aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag + function used by them), along with the setting of the memtag granule + size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available + on baremetal targets. Since the aarch64-linux-tdep.c layer inherits + these hooks from aarch64-tdep.c, there is no effective change for + aarch64-linux targets. + + Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were + moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h} + files. + + Tested-By: Luis Machado + Approved-By: Luis Machado + Reviewed-By: Eli Zaretskii + +2024-08-01 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13 + On fedora rawhide, with python 3.13, I run into: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + this function got an unexpected keyword argument 'invalid'^M + Error occurred in Python: \ + this function got an unexpected keyword argument 'invalid'^M + (gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + A passing version with an older python version looks like: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + 'invalid' is an invalid keyword argument for this function^M + Error occurred in Python: \ + 'invalid' is an invalid keyword argument for this function^M + (gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + Fix this by accepting the updated error message. + + Tested on aarch64-linux. + + PR testsuite/31912 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912 + +2024-08-01 Lulu Cai + + LoongArch: Fix ld FAIL test cases + To avoid differences in C library paths on different systems + use gcc instead of ld to perform the test. + + Problems caused by adding options to different distributions + will not be fixed. + +2024-08-01 Mark Harmstone + + ld/PDB: handle empty LF_FIELDLIST types + Empty structs in C++ lead to empty LF_FIELDLIST types in the .debug$T + section, but we were mistakenly rejecting these as invalid. Allow + CodeView types of two bytes, and add a test for this. + +2024-08-01 GDB Administrator + + Automatic date update in version.in + +2024-07-31 Nick Alcock + + libctf: fix ctf_archive_count return value on big-endian + This failed to properly byteswap its return value. + + The ctf_archive format predates the idea of "just write natively and + flip on open", and byteswaps all over the place. It's too easy to + forget one. The next revision of the archive format (not versioned, + so we just tweak the magic number instead) should be native-endianned + like the dicts inside it are. + + libctf/ + * ctf-archive.c (ctf_archive_count): Byteswap return value. + +2024-07-31 Nick Alcock + + libctf: dump: fix small leak + If you asprintf something and then use it only as input to another asprintf, + it helps to free it afterwards. + + libctf/ + * ctf-dump.c (ctf_dump_header): Free the flagstr after use. + (ctf_dump): Make a NULL return slightly clearer. + +2024-07-31 Nick Alcock + + libctf: fix ref leak of names of newly-inserted non-root-visible types + A bug in ctf_dtd_delete led to refs in the string table to the + names of non-root-visible types not being removed when the DTD + was. This seems harmless, but actually it would lead to a write + down a pointer into freed memory if such a type was ctf_rollback()ed + over and then the dict was serialized (updating all the refs as the + strtab was serialized in turn). + + Bug introduced in commit fe4c2d55634c700ba527ac4183e05c66e9f93c62 + ("libctf: create: non-root-visible types should not appear in name tables") + which is included in binutils 2.35. + + libctf/ + * ctf-create.c (ctf_dtd_delete): Remove refs for all types + with names, not just root-visible ones. + +2024-07-31 Nick Alcock + + libctf: clean up hashtab error handling mess + The dict and archive opening code in libctf is somewhat unusual, because + unlike everything else, it cannot report errors by setting an error on the + dict, because in case of error there isn't one. They get passed an error + integer pointer that is set on error instead. + + Inside ctf_bufopen this is implemented by calling ctf_set_open_errno and + passing it a positive error value. In turn this means that most things it + calls (including init_static_types) return zero on success and a *positive* + ECTF_* or errno value on error. + + This trickles down to ctf_dynhash_insert_type, which is used by + init_static_types to add newly-detected types to the name tables. This was + returning the error value it received from a variety of functions without + alteration. ctf_dynhash_insert conformed to this contract by returning a + positive value on error (usually OOM), which is unfortunate for multiple + reasons: + + - ctf_dynset_insert returns a *negative* value + - ctf_dynhash_insert and ctf_dynset_insert don't take an fp, so the value + they return is turned into the errno, so it had better be right, callers + don't just check for != 0 here + - more or less every single caller of ctf_dyn*_insert in libctf other than + ctf_dynhash_insert_type (and there are a *lot*, mostly in the + deduplicator) assumes that ctf_dynhash_insert returns a negative value + on error, even though it doesn't. In practice the only possible error is + OOM, but if OOM does happen we end up with a nonsense error value. + + The simplest fix for this seems to be to make ctf_dynhash_insert and + ctf_dynset_insert conform to the usual interface contract: negative + values are errors. This in turn means that ctf_dynhash_insert_type + needs to change: let's make it consistent too, returning a negative + value on error, putting the error on the fp in non-negated form. + + init_static_types_internal adapts to this by negating the error return from + ctf_dynhash_insert_type, so the value handed back to ctf_bufopen is still + positive: the new call site in ctf_track_enumerator does not need to change. + + (The existing tests for this reliably detect when I get it wrong. + I know, because they did.) + + libctf/ + * ctf-hash.c (ctf_dynhash_insert): Negate return value. + (ctf_dynhash_insert_type): Set de-negated error on the dict: + return negated error. + * ctf-open.c (init_static_types_internal): Adapt to this change. + +2024-07-31 Nick Alcock + + libctf, include: add ctf_dict_set_flag: less enum dup checking by default + The recent change to detect duplicate enum values and return ECTF_DUPLICATE + when found turns out to perturb a great many callers. In particular, the + pahole-created kernel BTF has the same problem we historically did, and + gleefully emits duplicated enum constants in profusion. Handling the + resulting duplicate errors from BTF -> CTF converters reasonably is + unreasonably difficult (it amounts to forcing them to skip some types or + reimplement the deduplicator). + + So let's step back a bit. What we care about mostly is that the + deduplicator treat enums with conflicting enumeration constants as + conflicting types: programs that want to look up enumeration constant -> + value mappings using the new APIs to do so might well want the same checks + to apply to any ctf_add_* operations they carry out (and since they're + *using* the new APIs, added at the same time as this restriction was + imposed, there is likely to be no negative consequence of this). + + So we want some way to allow processes that know about duplicate detection + to opt into it, while allowing everyone else to stay clear of it: but we + want ctf_link to get this behaviour even if its caller has opted out. + + So add a new concept to the API: dict-wide CTF flags, set via + ctf_dict_set_flag, obtained via ctf_dict_get_flag. They are not bitflags + but simple arbitrary integers and an on/off value, stored in an unspecified + manner (the one current flag, we translate into an LCTF_* flag value in the + internal ctf_dict ctf_flags word). If you pass in an invalid flag or value + you get a new ECTF_BADFLAG error, so the caller can easily tell whether + flags added in future are valid with a particular libctf or not. + + We check this flag in ctf_add_enumerator, and set it around the link + (including on child per-CU dicts). The newish enumerator-iteration test is + souped up to check the semantics of the flag as well. + + The fact that the flag can be set and unset at any time has curious + consequences. You can unset the flag, insert a pile of duplicates, then set + it and expect the new duplicates to be detected, not only by + ctf_add_enumerator but also by ctf_lookup_enumerator. This means we now + have to maintain the ctf_names and conflicting_enums enum-duplication + tracking as new enums are added, not purely as the dict is opened. + Move that code out of init_static_types_internal and into a new + ctf_track_enumerator function that addition can also call. + + (None of this affects the file format or serialization machinery, which has + to be able to handle duplicate enumeration constants no matter what.) + + include/ + * ctf-api.h (CTF_ERRORS) [ECTF_BADFLAG]: New. + (ECTF_NERR): Update. + (CTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): Likewise. + + libctf/ + * ctf-impl.h (LCTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_track_enumerator): Declare. + * ctf-dedup.c (ctf_dedup_emit_type): Set it. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link): Likewise. + (ctf_link_write): Likewise. + * ctf-subr.c (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): New function. + * ctf-open.c (init_static_types_internal): Move enum tracking to... + * ctf-create.c (ctf_track_enumerator): ... this new function. + (ctf_add_enumerator): Call it. + * libctf.ver: Add the new functions. + * testsuite/libctf-lookup/enumerator-iteration.c: Test them. + +2024-07-31 Nick Alcock + + include, libctf: improve ECTF_DUPLICATE error message + It applies to enums now, so it should mention them. + + include/ + * ctf-api.h (_CTF_ERRORS) ECTF_DUPLICATE]: Mention enums. + +2024-07-31 Nick Alcock + + libctf: link: remember to turn off the LCTF_LINKING flag after ctf_link_write + We set this flag at the top of ctf_link_write (to tell ctf_serialize, way + down under the archive file writing functions, to do the various link- time + serialization things like symbol filtering and the like), but we never + remember to clear it except on error. This is probably bad if you want to + serialize the dict yourself directly in the future after linking it (which + is... definitely a *possible* use of the API, if rather strange). + + libctf/ + * ctf-link.c (ctf_link_write): Clear LCTF_LINKING before exit. + +2024-07-31 Nick Alcock + + libctf: link: fix error handling + We were calling the wrong error function if opening failed, causing leaks. + + libctf/ + * ctf-link.c (ctf_link_deduplicating_per_cu): Fix error handling. + +2024-07-31 Nick Alcock + + libctf, open: Fix enum error handling path + This new error-handling path was not properly initializing the + fp's errno. + + libctf/ + * ctf-open.c (init_static_types_internal): Set errno properly. + +2024-07-31 Nick Alcock + + libctf, subr: don't mix up errors and warnings + ctf_err_warn() was debug-logging warnings as if they were errors and vice + versa. + + libctf/ + * ctf-subr.c (ctf_err_warn): Fix debugging thinko. + +2024-07-31 Nick Alcock + + libctf: fix dynset insertion + libctf's dynsets are a straight wrapper around libiberty hashtab, storing + the key directly in the hashtab slot. However, we'd often like to be able + to store 0 and 1 (HTAB_EMPTY_ENTRY and HTAB_DELETED_ENTRY) in there, so we + move them out of the way and replace them with huge unlikely values + instead. Unfortunately we failed to do this replacement in one place, so + insertion of 0 or 1 ended up misinforming the hashtab machinery that an + entry was empty or deleted when it wasn't. + + libctf/ + * ctf-hash.c (ctf_dynset_insert): Call key_to_internal properly. + +2024-07-31 Nick Alcock + + libctf: dedup: tiny tweaks + Drop an unnecessary variable, and fix a buggy comment. + + No effect on generated code. + + libctf/ + * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Drop unnecessary + variable. + (ctf_dedup_rwalk_output_mapping): Fix comment. + +2024-07-31 Nick Alcock + + libctf: improve ECTF_NOPARENT error message + This erorr doesn't just indicate that there is no parent dictionary + (that's routine, and true of all dicts that are parents themselves) + but that a parent is *needed* but wasn't found. + + include/ + * ctf-api.h (_CTF_ERRORS) [ECTF_NOPARENT]: Improve error message. + + ld/ + * testsuite/ld-ctf/diag-parname.d: Adjust. + +2024-07-31 Nick Alcock + + libctf: fix CTF dict compression + Commit 483546ce4f3 ("libctf: make ctf_serialize() actually serialize") + accidentally broke dict compression. There were two bugs: + + - ctf_arc_write_one_ctf was still making its own decision about + whether to compress the dict via direct ctf_size comparison, which is + unfortunate because now that it no longer calls ctf_serialize itself, + ctf_size is always zero when it does this: it should let the writing + functions decide on the threshold, which they contain code to do which is + simply not used for lack of one trivial wrapper to write to an fd and + also provide a compression threshold + + - ctf_write_mem, the function underlying all writing as of the commit + above, was calling zlib's compressBound and avoiding compression if this + returned a value larger than the input. Unfortunately compressBound does + not do a trial compression and determine whether the result is + compressible: it just adds zlib header sizes to the value passed in, so + our test would *always* have concluded that the value was incompressible! + Avoid by simply always compressing if the raw size is larger than the + threshold: zlib is quite clever enough to avoid actually compressing + if the data is incompressible. + + Add a testcase for this. + + libctf/ + * ctf-impl.h (ctf_write_thresholded): New... + * ctf-serialize.c (ctf_write_thresholded): ... defined here, + a wrapper around... + (ctf_write_mem): ... this. Don't check compressibility. + (ctf_compress_write): Reimplement as a ctf_write_thresholded + wrapper. + (ctf_write): Likewise. + * ctf-archive.c (arc_write_one_ctf): Just call + ctf_write_thresholded rather than trying to work out whether + to compress. + * testsuite/libctf-writable/ctf-compressed.*: New test. + +2024-07-31 Nick Alcock + + libctf: fix linking of non-root-visible types + If you deduplicate non-root-visible types, the resulting type should still + be non-root-visible! We were promoting all such types to root-visible, and + re-demoting them only if their names collided (which might happen on + cu-mapped links if multiple compilation units with conflicting types are + fused into one child dict). + + This "worked" before now, in that linking at least didn't fail (if you don't + mind having your non-root flag value destroyed if you're adding + non-root-visible types), but now that conflicting enumerators cause their + containing enums to become conflicted (enums which might have *different + names*), this caused the linker to crash when it hit two enumerators with + conflicting values. + + Not testable in ld because cu-mapped links are not exposed to ld, but can be + tested via direct creation of libraries and calls to ctf_link directly. + (This also tests the ctf_dump non-root type printout, which before now + was untested.) + + libctf/ + * ctf-dedup.c (ctf_dedup_emit_type): Non-root-visible input types + should be emitted as non-root-visible output types. + * testsuite/libctf-writable/ctf-nonroot-linking.c: New test. + * testsuite/libctf-writable/ctf-nonroot-linking.lk: New test. + +2024-07-31 Nick Alcock + + libctf, dump: correctly dump non-root-visible types + The flag test when dumping non-root-visible tyeps was doubly wrong: the + flags word is a *bitfield* containing CTF_ADD_ROOT as one possible + value, so needs | and & testing, not just ==, and CTF_ADD_NONROOT is 0, + so cannot be tested for this way: one must check for the non-presence of + CTF_ADD_ROOT. + + libctf/ + * ctf-dump.c (ctf_dump_format_type): Fix non-root flag test. + +2024-07-31 Nick Alcock + + libctf, string: split the movable refs out of the ref list + In commit 149ce5c263616e65 we introduced the concept of "movable" refs, + which are refs that can be moved in batches, to let us maintain valid ref + lists even when adding refs to blocks of memory that can be realloced (which + is any type containing a vlen which can expand, like names contained within + enum or struct members). Movable refs need a backpointer to the movable + refs dynhash for this dict; since non-movable refs are very common, we tried + to save memory by having a slightly bigger struct for moveable refs with a + backpointer in it, and casting appropriately, indicating which sort of ref + we were dealing with via a flag on the atom. + + Unfortunately this doesn't work reliably, because you can perfectly well + have a string ("foo", say) which has both non-movable refs (say, an external + symbol and a variable name) and movable refs (say, a structure member name) + to the same atom. Indicate which struct we're dealing with with an atom + flag and suddenly you're casting a ctf_str_atom_ref to a + ctf_str_atom_ref_movable (which is bigger) and dereferencing random memory + off the end of it and interpreting it as a backpointer to the movable refs + dynhash. This is unlikely to work well. + + So bite the bullet and split refs into two separate lists, one for movable + refs, one for immovable refs. It means some annoying code duplication, but + there's not very much of it, and it means we can keep the movable refs + hashtab (which in turn means we don't have to do linear searches to find all + relevant refs when moving refs, which in turn means that + structure/union/enum member additions remain amortized O(n) time, not + O(n^2). + + Callers can now purge movable and non-movable refs independently of each + other. We don't use this yet, but a use is coming. + + libctf/ + * ctf-impl.h (CTF_STR_ATOM_MOVABLE): Delete. + (struct ctf_str_atom) [csa_movable_refs]: New. + (struct ctf_dict): Adjust comment. + (ctf_str_purge_refs): Add MOVABLE arg. + * ctf-string.c (ctf_str_purge_movable_atom_refs): Split out of... + (ctf_str_purge_atom_refs): ... this. + (ctf_str_free_atom): Call it. + (ctf_str_purge_one_atom_refs): Likewise. + (aref_create): Adjust accordingly. + (ctf_str_move_refs): Likewise. + (ctf_str_remove_ref): Remove movable refs too, including + deleting the ref from ctf_str_movable_refs. + (ctf_str_purge_refs): Add MOVABLE arg. + (ctf_str_update_refs): Update movable refs. + (ctf_str_write_strtab): Check, and purge, movable refs. + +2024-07-31 Nick Alcock + + libctf, dedup: drop unnecessary arg from ctf_dedup() + The PARENTS arg is carefully passed down through all the layers of hash + functions and then never used for anything. (In the distant past it was + used for cycle detection, but the algorithm eventually committed doesn't + need to do cycle detection...) + + The PARENTS arg is still used by ctf_dedup_emit(), but even there we can + loosen the requirements and state that you can just leave entries + corresponding to dicts with no parents at zero (which will be useful + in an upcoming commit). + + libctf/ + * ctf-dedup.c (ctf_dedup_hash_type): Drop PARENTS arg. + (ctf_dedup_rhash_type): Likewise. + (ctf_dedup): Likewise. + (ctf_dedup_emit_struct_members): Mention what you can do to + PARENTS entries for parent dicts. + * ctf-impl.h (ctf_dedup): Adjust accordingly. + * ctf-link.c (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link_deduplicating): Likewise. + +2024-07-31 Nick Alcock + + libctf: we do in fact support foreign-endian old versions + The worry that caused this to not be supported was because we don't + bother endian-flipping version-related fields before checking them. + But they're all unsigned chars anyway, and don't need any flipping at + all. + + This should be supported and should already work. Enable it. + + libctf/ + * ctf-open.c (ctf_bufopen): Don't prohibit foreign-endian + upgrades. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Fix trailing-text-in-parentheses duplicates + Fix all trailing-text-in-parentheses duplicates exposed by previous patch. + + Tested on x86_64-linux and aarch64-linux. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Detect trailing-text-in-parentheses duplicates + When using a duplicate test name: + ... + fail foo + fail foo + ... + we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo + DUPLICATE: $exp: foo + ... + + But when we do: + ... + fail foo + fail "foo (timeout)" + ... + we get only: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + ... + + Trailing text between parentheses prefixed with a space is interpreted as + extra information, and not as part of the test name [1]. + + Consequently, "foo" and "foo (timeout)" do count as duplicate test names, + which should have been detected. This is PR testsuite/29772. + + Fix this in CheckTestNames::_check_duplicates, such that we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + DUPLICATE: $exp: foo (timeout) + ... + + [ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't + know whether that covers all required cases, due to the fact that those are + not unambiguousely specified. It might be possible to reverse-engineer that + information by reading or running the "regression analysis tools" mentioned on + the wiki page [1], but I haven't been able to. Regardless, the current regexp + covers a large amount of cases, which IMO should be sufficient to be + acceptable. ] + + Doing so shows many new duplicates in the testsuite. + + A significant number of those is due to using a message which is a copy of the + command: + ... + gdb_test "print (1)" + ... + + Fix this by handling those cases using test names "gdb-command" and + "gdb-command. + + Fix the remaining duplicates manually (split off as follow-up patch for + readability of this patch). + + Tested on x86_64-linux and aarch64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772 + + [1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages + +2024-07-31 Tom de Vries + + [gdb/testsuite] Add gdb.python/py-disasm-{exec,obj}.exp + I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a + s390x machine, but when running with target board unix/-m31 I saw that the + required libraries were missing, so I couldn't generate an executable. + + However, I realized that I did have an object file, and the test-case should + mostly also work with an object file. + + I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and + included it from two new minimal test-case wrappers: + - gdb.python/py-disasm-exec.exp, and + - gdb.python/py-disasm-obj.exp + where the former uses an executable as before, and the latter uses an object + file. + + Using an object file required changing the info.read_memory calls in + gdb.python/py-disasm.py: + ... + - info.read_memory(1, -info.address + 2) + + info.read_memory(1, -info.address - 1) + ... + because reading from address 2 succeeds. Using address -1 instead does + generate the expected gdb.MemoryError. + + Tested on x86_64-linux. + +2024-07-31 Tom de Vries + + [gdb/exp] Fix gdb.fortran/intrinsics.exp fail on arm + When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get: + ... + (gdb) p cmplx (4,4,16)^M + /home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \ + Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error) + ... + + The problem is that 16-byte floats are unsupported: + ... + $ gfortran test.f90 + test.f90:2:17: + + 2 | REAL(kind=16) :: foo = 1 + | 1 + Error: Kind 16 not supported for type REAL at (1) + ... + and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with + code TYPE_CODE_ERROR. + + Fix this by bailing out asap when encountering such a type. + + Without this patch we're able to do the rather useless: + ... + (gdb) ptype real*16 + type = real*16 + (gdb) ptype real_16 + type = real*16 + ... + but with this patch we get: + ... + (gdb) ptype real*16 + unsupported kind 16 for type real*4 + (gdb) ptype real_16 + unsupported type real*16 + ... + + Tested on arm-linux. + + PR fortran/30537 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537 + +2024-07-31 Jan Beulich + + x86: move ginsn stuff + This had been badly inserted between md_assemble() and its helpers + anyway. Follow what was done for Arm64 and move the code to its own + file, #include-d as appropriate. + + gas/doc: adjust an @xref + Old doc tools warn about there not being a . or , following; satisfy + those tools by shortening the line and adding a full stop. + +2024-07-31 Alan Modra + + fix the framework error + Running the testsuite for an x86_64-w64-mingw32 target using the + Ubuntu package gcc-mingw-w64-x86-64 version 13.2.0-6ubuntu1+26.1 + results in a number of messages: + ERROR: can't decipher gcc version number, fix the framework! + + Someone in their wisdom decided this compiler should advertise itself + with a version of 13-win32, breaking the ld testsuite version checks. + (It is also configured using --with-as=/usr/bin/x86_64-w64-mingw32-as + --with-ld=/usr/bin/x86_64-w64-mingw32-ld which renders the -B flag + inoperative for testing the newly built gas and ld. You'd need to + install binutils over the top of the Ubuntu versions before testing, a + rather unsatisfactory process.) + + * testsuite/lib/ld-lib.exp (at_least_gcc_version): Use + preprocessor test of __GNUC__ and __GNUC_MINOR__ rather than + output of gcc --version. Correct removal of -Wl options. + +2024-07-31 GDB Administrator + + Automatic date update in version.in + +2024-07-30 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some more + When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie), + I run into: + ... + Expecting: ^(-var-create A_String_Access \* A_String_Access[ + ]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[ + ]+[(]gdb[)] + [ ]*) + -var-create A_String_Access * A_String_Access + ^error,msg="Cannot access memory at address 0x4" + (gdb) + FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) + ... + + This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite] + Fix regexp in gdb.ada/mi_var_access.exp"). + + The problem in both cases is that we're printing an uninitialized variable, + and consequently we can run into various error messages during printing. + + Fix this as in the other commit, by accepting the error message. + + Tested on arm-linux. + +2024-07-30 Simon Marchi + + gdb: don't call macro_bcache with nullptr + Since commit b1da98a74656 ("gdb: remove use of alloca in + new_macro_definition"), if cached_argv is empty, we call macro_bcache + with a nullptr data. This ends up caught by UBSan deep down in the + bcache code: + + $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow + Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + /home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null + + The backtrace: + + #1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750 + #2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195 + #3 0x0000555564b49222 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158 + #4 0x0000555564b481fa in macro_bcache (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117 + #5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573 + #6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777 + #7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816 + #8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203 + + This can be reproduced by running gdb.base/macscp.exp. Avoid calling + macro_bcache if the macro doesn't have any arguments. + + Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d + +2024-07-30 Vladimir Mezentsev + + gprofng: 32018 Compilation of binutils 2.43 failed on CentOS 6 + strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7. + In this case, we may not use our CALL_UTIL macro for strchr. + Use __collector_strchr instead of "CALL_UTIL (strchr)". + + gprofng/ChangeLog + 2024-07-28 Vladimir Mezentsev + + PR 32018 + * libcollector/hwprofile.c (open_experiment): Use __collector_strchr. + +2024-07-30 Tom de Vries + + [gdb/symtab] Emit malformed macro definition complaint once + Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the + .debug_macro section. + + For one malformed macro definition, I get two identical complaints: + ... + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + ... + + Fix this by bailing out after the first one. + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-07-30 Simon Marchi + + gdb: remove use of alloca in new_macro_definition + Replace alloca with std::vector. + + Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c + Approved-By: Tom de Vries + +2024-07-30 Simon Marchi + + gdb: use std::string vector for macro definition + Use std::vector when defining macros, to avoid the manual + memory management. + + With the use of std::vector, the separate `int argc` parameter is no + longer needed, we can use the size of the vector instead. However, for + some functions, this parameter had a dual function. For object-like + macros, it was interpreted as a `macro_special_kind` enum. For these + functions, remove `argc`, but add a new `special_kind` parameter. + + Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5 + Approved-By: Tom de Vries + +2024-07-30 Andrew Burgess + + gdb/doc: move @anchor off @item line + When building the GDB info manual I see this warning: + + gdb.texinfo:41447: warning: @anchor should not appear on @item line + + And indeed line 41447 looks like this: + + @item @anchor{maint info breakpoints}maint info breakpoints + + I propose moving the @anchor{...} part to the previous line which + silences the warning. + + Approved-By: Eli Zaretskii + +2024-07-30 Lulu Cai + + gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.43 + +2024-07-30 GDB Administrator + + Automatic date update in version.in + +2024-07-29 Alexandra Hájková + + Add a test for the gcore script + It also tests the gcore script being run without its accessible + terminal. + + This test was written by Jan Kratochvil a long time ago. I modernized + the test making it use various procs from lib/gdb.exp, reorganizing it + and added some comments. + + Modify the gcore script to make it possible to pass the --data-directory to + it. This prevents a lot of these warnings: + + Python Exception : module 'gdb' has no attribute + '_handle_missing_debuginfo' + + Tested by using make check-all-boards. + + Co-Authored-By: Jan Kratochvil + + Reviewed-By: Eli Zaretskii + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0 + When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we + run into: + ... + (gdb) save gdb-index index_1^M + Error while writing index for `xgdb': No debugging symbols^M + (gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file + ... + + Fix this by instead emitting an unsupported, and bailing out. + + Tested on aarch64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.exp + When running test-case gdb.threads/leader-exit-attach.exp with target board + native-extended-gdbserver I run into: + ... + (gdb) KFAIL: $exp: attach (PRMS: gdb/31555) + print $_inferior_thread_count^M + $1 = 0^M + (gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554) + ... + + The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc + ("Fix "attach" failure handling with GDBserver"), and consequently the PR is + closed. + + Fix this by removing the corresponding kfail. + + Tested on x86_64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1 + With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into: + ... + (gdb) attach 18591^M + Attaching to program: leader-exit-attach, process 18591^M + warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555) + ^M + ptrace: Operation not permitted.^M + (gdb) FAIL: $exp: get valueof "$_inferior_thread_count" + ... + + The problem is that the gdb_test_multiple in the test-case doesn't consume the + prompt in all clauses: + ... + gdb_test_multiple "attach $testpid" "attach" { + -re "Attaching to process $testpid failed.*" { + # GNU/Linux gdbserver. Linux ptrace does not let you attach + # to zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "warning: process $testpid is a zombie - the process has already terminated.*" { + # Native GNU/Linux. Linux ptrace does not let you attach to + # zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" { + pass $gdb_test_name + set attached 1 + } + } + ... + + Fix this by using -wrap in the first two clauses. + + While we're at it, also use -wrap in the third clause. + + Tested on x86_64-linux. + +2024-07-29 Nick Clifton + + Updated translations for the bfd, binutils, gas, ld and opcodes directories + +2024-07-29 Alan Modra + + Fixes to "PR 31728 testcases" + This brings us down to just these fails for the set of targets I + usually test when making testsuite changes. + aarch64-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-ld + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool + + The aarch64 one is likely due to the target missing support somewhere. + It is fairly new, I haven't investigated. The arm-pe fails are due to + arm-pe being a target that adds underscores to symbol names (see + config.bfd) whereas dlltool thinks it does not (see + dlltool.c:asm_prefix). arm-wince-pe on the other hand doesn't add + underscores. I would guess the right fix for dlltool is to get this + symbol info from bfd using bfd_get_target_info. + + Note I'm not very happy about the creative use of ld_after_inputfile + in symbols-ordinals-hints-imports-ld.d, which is likely to break with + some future run_dump_test change. + +2024-07-29 Pali Rohár + + PR 31728 testcases + +2024-07-29 Alan Modra + + PR32032 dwp segfaults on hello world binary + Fixing the segfault is easy with this bandaid, but further work is + needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header. + At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id. + + PR 32032 + * dwp.cc (Dwp_output_file::finalize): Return immediately on + no output file. + +2024-07-29 GDB Administrator + + Automatic date update in version.in + +2024-07-28 Andrew Burgess + + gdb/testsuite: track if a caching proc calls gdb_exit or not + After a recent patch review I asked myself why can_spawn_for_attach + exists. This proc currently does some checks, and then calls + can_spawn_for_attach_1 which is an actual caching proc. + + The answer is that can_spawn_for_attach exists in order to call + gdb_exit the first time can_spawn_for_attach is called within any test + script. + + The reason this is useful is that can_spawn_for_attach_1 calls + gdb_exit. If the user calls can_spawn_for_attach_1 directly then a + problem might exist. Imagine a test written like this: + + gdb_start + + if { [can_spawn_for_attach_1] } { + ... do stuff that assumes GDB is running ... + } + + If this test is NOT the first test run, and if an earlier test calls + can_spawn_for_attach_1, then when the above test is run the + can_spawn_for_attach_1 call will return the cached value and gdb_exit + will not be called. + + But, if the above test IS the first test run then + can_spawn_for_attach_1 will not return the cached value, but will + instead compute the cached value, a process that ends up calling + gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited + and the test might fail if it is written assuming that GDB is + running. + + So can_spawn_for_attach was added which ensures that we _always_ call + gdb_exit the first time can_spawn_for_attach is called within a single + test script, this ensures that in the above case, even if the above is + not the first test script run, gdb_exit will still be called. This + ensures consistent behaviour and avoids some hidden bugs in the + testsuite. + + The split between can_spawn_for_attach and can_spawn_for_attach_1 was + introduced in this commit: + + commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f + Date: Mon May 6 14:27:09 2024 +0200 + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + + However, I observe that can_spawn_for_attach is not the only caching + proc that calls gdb_exit. Why does can_spawn_for_attach get special + treatment when surely the same issue exists for any other caching proc + that calls gdb_exit? + + I think a better solution is to move the logic from + can_spawn_for_attach into cache.exp and generalise it so that it + applies to all caching procs. + + This commit does this by: + + 1. When the underlying caching proc is executed we track calls to + gdb_exit. If a caching proc calls gdb_exit then this information + is stored in gdb_data_cache (using a ',exit' suffix), and also + written to the cache file if appropriate. + + 2. When a cached value is returned from gdb_do_cache, if the + underlying proc would have called gdb_exit, and if this is the + first use of the caching proc in this test script, then we call + gdb_exit. + + When storing the ',exit' value into the on-disk cache file, the flag + value is stored on a second line. Currently every cached value only + occupies a single line, and a check is added to ensure this remains + true in the future. + + To track calls to gdb_exit I eventually settled on using TCL's trace + mechanism. We already make use of this in lib/gdb.exp so I figure + this is OK to use. This should be fine, so long as non of the caching + procs use 'with_override' to replace gdb_exit, or do any other proc + replacement to change gdb_exit, however, I think that is pretty + unlikely. + + One issue did come up in testing, a FAIL in gdb.base/break-interp.exp, + prior to this commit can_spawn_for_attach would call gdb_exit before + calling the underlying caching proc. After this call we call gdb_exit + after calling the caching proc. + + The underlying caching proc relies on gdb_exit having been called. To + resolve this issue I just added a call to gdb_exit into + can_spawn_for_attach. + + With this done can_spawn_for_attach_1 can be renamed to + can_spawn_for_attach, and the existing can_spawn_for_attach can be + deleted. + +2024-07-28 Andrew Burgess + + gdb/testsuite: restructure gdb_data_cache (lib/cache.exp) + In the next commit I want to add more information to + gdb_data_cache (see lib/cache.exp). Specifically I want to track if + the underlying function of a caching proc calls gdb_exit or not. + + Currently gdb_data_cache is an associative array, the keys of which + are the name of the caching proc. + + In this commit I add a ',value' suffix to the gdb_data_cache keys. In + the next commit I'll add additional entries with a different suffix. + + There should be no noticable changes after this commit, this is just a + restructuring. + +2024-07-28 GDB Administrator + + Automatic date update in version.in + +2024-07-27 Tom de Vries + + [gdb/tdep] Fix arm thumb2 hw breakpoint + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + This may or may not be a kernel bug. + + Work around this by first using an inoffensive address bpts[i].address & ~0x7. + + Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on + target board native-gdbserver/mthumb. + + While we're at it: + - use arm_hwbp_control_is_initialized in + arm_linux_nat_target::low_prepare_to_resume, + - handle the !arm_hwbp_control_is_initialized case explicitly, + - add missing '_()' in arm_target::low_prepare_to_resume, + - make error messages identical between arm_target::low_prepare_to_resume and + arm_linux_nat_target::low_prepare_to_resume, + - factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to + make the implementation more readable. + + Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in + gdb.base/hbreak.exp") by simply reverting the commit. + + Tested on arm-linux. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-07-27 GDB Administrator + + Automatic date update in version.in + +2024-07-26 YunQiang Su + + microMIPS: Add MT ASE instruction set support + Add the MT ASE instruction operand types and encodings to the microMIPS + opcode table and enable the assembly of these instructions in GAS from + MIPSr2 onwards. Update the binutils and GAS testsuites accordingly. + + References: + + "MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for + the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number: + MD00768, Revision 1.12, July 16, 2013 + + Co-Authored-By: Maciej W. Rozycki + +2024-07-26 Nick Clifton + + Fix "Untranslated plural in readelf.c" + PR 32002 + +2024-07-26 Andrew Burgess + + gdb/testsuite: fix build-id compile option when used with clang + It was pointed out in this message: + + https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com + + That the test gdb.base/build-id-seqno.exp I added recently was FAILing + when using Clang as the compiler. + + The problem was that I had failed to add 'build-id' as a compile + option in the call to build_executable within the test script. For + GCC this is fine as build-ids are included by default. For Clang + though this meant the build-id was not included and the test would + fail. + + So I added build-id to the compiler options.... and the test still + didn't pass! Now the test fails to compile and I see this error from + the compiler: + + gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \ + input unused [-Wunused-command-line-argument] + + It turns out that the build-id compile option causes our gdb.exp to + add the '-Wl,--build-id' option into the compiler flags, which means + its used when building the object file AND during the final link. + However this option is unnecessary when creating the object file and + Clang warns about this, which causes the build to fail. + + The solution is to change gdb.exp, instead of adding the build-id + flags like this: + + lappend new_options "additional_flags=-Wl,--build-id" + + we should instead add them like: + + lappend new_options "ldflags=-Wl,--build-id" + + Now the flag is only appended during the link phase and Clang is + happy. The gdb.base/build-id-seqno.exp test now passes with Clang. + + The same problem (adding to additional_flags instead of ldflags) + exists for the no-build-id compile option, so I've fixed that too. + + While investigating this I also spotted two test scripts, + gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were + setting ldflag directly rather than using the build-id compile option + so I've updated these two tests to use the compile option which I + think is neater. + + I've checked that all these tests still pass with both GCC and Clang. + + There should be no changes in what is actually tested after this + commit. + + Approved-By: Simon Marchi + +2024-07-26 Jan Beulich + + gas: correct sb_add_char() 2nd parameter type + It's entirely unclear why size_t was used there; my only guess is copy- + and-paste from another of the functions. + +2024-07-26 Jan Beulich + + gas: drop scrubber state -2 + Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring + that we wouldn't get bogus state transitions: For example, when we're in + states 0 or 1, a comment should be no different from whitespace + encountered in those states. Plus for e.g. x86 this results in such + comments now truly being converted to a blank, as mandated by + documentation. Both aspects apparently were a result of blindly (and + wrongly) moving to state 3 _before_ consuming the "ungot" blank. + + Also amend a related comment elsewhere. + + In the new testcase the .irp is to make visible in the listing all the + whitespace that the scrubber inserts / leaves in place. + +2024-07-26 Jan Beulich + + x86: accept whitespace around prefix separator + ... and prediction suffix comma. Other than documented /**/ comments + currently aren't really converted to a single space, at least not for + x86 in its most common configurations. That'll be fixed subsequently, at + which point blanks may appear where so far none were expected. + Furthermore not permitting blanks around these separators wasn't quite + logical anyway - such constructs are composite ones, and hence + components ought to have been permitted to be separated by whitespace + from the very beginning. Furthermore note how, due to the scrubber being + overly aggressive in removing whitespace, some similar construct with a + prefix were already accepted. + + Note how certain other checks in parse_insn() can be simplified as a + result. + + While there for the prediction suffix also make checks case-insensitive + and check for a proper trailing separator. + +2024-07-26 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to BMI2 ones + ..., as those leave EFLAGS untouched anyway. That's a shorter encoding, + available as long as no eGPR is in use anywhere. + +2024-07-26 Alan Modra + + Remove srcdir from x86 testcase "source:" lines + It's wrong to have ${srcdir} in run_dump_test "source:" lines, as + run_dump_test adds $srcdir/$subdir/ to the line passed to the shell + except when the source path starts with "./". The tests work + currently because the shell expands ${srcdir} to an empty string. + + PR 31728 + * testsuite/ld-i386/code16.d: Correct "source:". + * testsuite/ld-x86-64/code16.d: Likewise. + * testsuite/ld-x86-64/rela.d: Likewise. + +2024-07-26 Alan Modra + + ARM print_insn_mve assertion + This corrects objdump -d -m armv8.1-m.main output for a testcase found + by oss-fuzz, .inst 0xee2fee79, which hits an assertion. + + Obviously the switch case constants should be binary, not hex. + Correcting that is enough to cure this assertion, but I don't see any + point in singling out the invalid case 0b10. In fact, it is just plain + wrong to print "undefined instruction: size equals zero undefined + instruction: size equals two". + + I also don't see the need for defensive programming here as is done + elsewhere in checking that "value" is in range before indexing + mve_vec_sizename. There is exactly one MVE_VSHLL_T2 entry in + mve_opcodes. It is easy to verify that "value" is only two bits. + +2024-07-26 GDB Administrator + + Automatic date update in version.in + +2024-07-25 Simon Marchi + + gdb/amdgpu: remove unused includes + Remove two includes reported as unused by clangd. + + Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e + +2024-07-25 H.J. Lu + + x86: Add missing newlines in TLS transition error messages + Change TLS transition error messages from + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV onlyld: final link failed: bad value + + to + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV only + ld: final link failed: bad value + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): + Add missing newlines. + +2024-07-25 H.J. Lu + + x86: Improve TLS transition error check + Provide detailed TLS transition errors when unsupported instructions are + used. Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF when performing TLS transition. + + bfd/ + + PR ld/32017 + * elf32-i386.c (elf_i386_check_tls_transition): Return different + enums for different errors. + (elf_i386_tls_transition): Change argument from r_symndx to sym. + Call _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_i386_scan_relocs): Pass isym instead of r_symndx to + elf_i386_tls_transition. + (elf_i386_relocate_section): Pass sym instead of r_symndx to + elf_i386_tls_transition. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Return + different enums for different errors. + (elf_x86_64_tls_transition): Change argument from r_symndx to sym. + Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF. Call + _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_x86_64_scan_relocs): Pass isym instead of r_symndx to + elf_x86_64_tls_transition. + (elf_x86_64_relocate_section): Pass sym instead of r_symndx to + elf_x86_64_tls_transition. + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): New. + * elfxx-x86.h (elf_x86_tls_error_type): Likewise. + (_bfd_x86_elf_link_report_tls_transition_error): Likewise. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/i386.exp: Run tlsgdesc1 and tlsgdesc2. + * testsuite/ld-i386/tlsie2.d: Updated. + * testsuite/ld-i386/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsie4.d: Likewise. + * testsuite/ld-i386/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie2.d: Likewise. + * testsuite/ld-x86-64/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsgdesc1.d: New file. + * testsuite/ld-i386/tlsgdesc1.s: Likewise. + * testsuite/ld-i386/tlsgdesc2.d: Likewise. + * testsuite/ld-i386/tlsgdesc2.s: Likewise. + * testsuite/ld-x86-64/tlsdesc3.d: Likewise. + * testsuite/ld-x86-64/tlsdesc3.s: Likewise. + * testsuite/ld-x86-64/tlsdesc4.d: Likewise. + * testsuite/ld-x86-64/tlsdesc4.s: Likewise. + * testsuite/ld-x86-64/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie5.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsie5, tlsdesc3 and + tlsdesc4. + +2024-07-25 Nick Clifton + + Add /usr/lib32 to the native search paths for FreeBSD systems. + PR 31395 + +2024-07-25 GDB Administrator + + Automatic date update in version.in + +2024-07-24 Tom Tromey + + Remove redundant macro definitions from remote.c + I happened to notice that a few macros are defined twice in remote.c. + This patch removes one copy. Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-07-24 Tom de Vries + + [gdb/exp] Fix ptype $_creal/$_cimag + Consider test.c, compiled with -g: + ... + __complex__ float cf = 1 + 2i; + int main (void) { return 0; } + ... + + The values of cf and its components are: + ... + $ gdb -q a.out + Reading symbols from a.out... + (gdb) p cf + $1 = 1 + 2i + (gdb) p $_creal(cf) + $2 = 1 + (gdb) p $_cimag(cf) + $3 = 2 + ... + and their respective types are: + ... + (gdb) ptype $1 + type = complex float + (gdb) ptype $2 + type = float + (gdb) ptype $3 + type = float + ... + + Now let's try that again, using ptype directly: + ... + (gdb) ptype cf + type = complex float + (gdb) ptype $_creal(cf) + type = int + (gdb) ptype $_cimag(cf) + type = int + ... + + The last two types should have been float, not int. + + Fix this by extending the internal function handlers creal_internal_fn and + cimag_internal_fn with the noside parameter, such that we get instead: + ... + (gdb) ptype $_creal(cf) + type = float + (gdb) ptype $_cimag(cf) + type = float + ... + + Tested on x86_64-linux. + + Reviewed-By: Keith Seitz + + PR exp/31816 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816 + +2024-07-24 Tom de Vries + + [gdb/exp] Allow internal function to indicate return type + Currently an internal function handler has this prototype: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, + void *cookie, int argc, struct value **argv); + ... + + Also allow an internal function with a handler with an additional + "enum noside noside" parameter: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, void *cookie, + int argc, struct value **argv, enum noside noside); + ... + + In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's + expected to return some value with the correct return type. + + At least, provided it can do so without side effects, otherwise it should + throw an error. + + No functional changes. + + Tested on x86_64-linux and aarch64-linux. + + Reviewed-By: Keith Seitz + +2024-07-24 Nick Clifton + + BFD: Add .relro_padding to list of special sections + +2024-07-24 Andrew Burgess + + gdb/testsuite: ensure gdb_get_worker_threads succeeds + Sometimes, if I'm testing on a loaded machine, the + gdb.gdb/index-file.exp test will timeout during some early steps, + which then cases a TCL error to be thrown later in the test script. + + Dejagnu then reports this error once the test run has completed, which + can be pretty noisy, and isn't really very helpful. + + The underlying problem is that if GDB takes too long to load the + executable (which is GDB itself in this test) then GDB will still be + busy loading the executable when dejagnu moves on and call + gdb_get_worker_threads. The gdb_get_worker_threads call itself times + out as GDB is _still_ busy loading the executable, and so + gdb_get_worker_threads returns the string "UNKNOWN". + + Later we try to perform arithmetic on the worker thread count, which + results in errors when we try to do 'UNKNOWN / 2'. + + I propose that after calling gdb_get_worker_threads, we check if the + result was UNKNOWN. If it was then we should report an UNRESOLVED and + abandon the test, this avoids the later TCL errors. + +2024-07-24 Andrew Burgess + + opcodes/x86: fix minor missed styling case + I noticed that the x86 instruction: + + sar $1,%rsi + + would fail to style the '$0x1' as an immediate. This commit fixes + that case. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Handle address class annotation for s390x in some test-cases + On s390x-linux, I ran into: + ... + (gdb) ptype crash^M + type = class crash {^M + ^M + public:^M + crash(int (class {...}::*)(class {...} * const @mode32));^M + }^M + (gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash + ... + + The problem is that the test-case doesn't expect the address class annotation + @mode32. + + The test-case uses a .S file, with the address size hard-coded to 4 bytes, and + that's something that is annotated with @mode32 on s390x (which uses 8 byte + addresses). + + Fix this by allowing the annotation in the regexp. + + Likewise in two other test-cases. + + Tested on s390-linux and x86_64-linux. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/m-static.exp on arm + With test-case gdb.cp/m-static.exp on arm-linux, I get: + ... + (gdb) ptype test5.single_constructor^M + type = class single_constructor {^M + ^M + public:^M + single_constructor(void);^M + ~single_constructor(void);^M + } *(single_constructor * const)^M + (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor + ... + + The test-case expects: + - no empty line before "public:", and + - no "~single_constructor(void)", but "~single_constructor()" + + The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same + for gcc and clang"). + + The failing test is in a part only enabled for is_aarch32_target == 1, so it + looks like it was left behind. + + I'm assuming the same happened for the other difference. + + Fix this by updating the regexps to match the observed output. + + Tested on arm-linux. + + Approved-By: Andrew Burgess + +2024-07-24 Nelson Chu + + RISC-V: PR32001, Untranslated "internal:" prefix for error message. + bfd/ + PR 32001 + * elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated + "internal:" prefix for error message. + +2024-07-24 GDB Administrator + + Automatic date update in version.in + +2024-07-23 Tom Tromey + + Add returnValue scope to DAP + The DAP spec recently changed to add a new scope for the return value + from a "stepOut" request. This new scope uses the "returnValue" + presentation hint. See: + + https://github.com/microsoft/debug-adapter-protocol/issues/458 + + This patch implements this for gdb. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945 + Reviewed-By: Eli Zaretskii + +2024-07-23 Tom Tromey + + Refine the 'define' documentation + A while ago, an AdaCore user reported some difficulties with the + 'define' command. While some of these difficulties are intrinsic, or + at least difficult to change, it seemed sensible to document a couple + of the typical problems -- and to make the text describing argument + substitution a bit more prominent. + + Approved-By: Eli Zaretskii + +2024-07-23 Simon Marchi + + gdb/solib-frv: move lm_info object to solib + I noticed that the lm_info_frv objects created in frv_current_sos are + never moved to the solib object. This bug was introduced in 8971d2788e + ("gdb: link so_list using intrusive_list"), which mistakenly removed the + line + + sop->lm_info = std::move (li); + + ... probably due so a bad merge conflict resolution. + + Re-add this line. + + If merged in master, I would cherry-pick this to gdb-15-branch. + + Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005 + Approved-By: Andrew Burgess + +2024-07-23 Tom de Vries + + [gdb/testsuite] Add xfail in gdb.base/hbreak.exp + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + I'm not sure if this is simply unsupported or if there's a kernel bug of some + sort, but I don't see what gdb can do about this. + + Tentatively mark this as xfail. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + +2024-07-23 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linux + On arm-linux, I run into: + ... + PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me + Expecting: ^(-stack-list-arguments 1[^M + ]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|)"})?\]},.*[^M + ]+[(]gdb[)] ^M + [ ]*) + -stack-list-arguments 1^M + ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M + (gdb) ^M + FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) + ... + + The problem is that the test-case expects a level 3 frame, but there is none. + + This can be reproduced using cli bt: + ... + $ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \ + -ex "b task_switch.break_me" \ + -ex run \ + -ex bt + Breakpoint 1 at 0x34b4: file task_switch.adb, line 57. + + Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \ + at task_switch.adb:57 + 57 null; + #0 task_switch.break_me () at task_switch.adb:57 + #1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51 + #2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + ... + + The purpose of the test-case is printing the frame at level 1, so I don't + think we should bother about the presence of the frame at level 3. + + Fix this by allowing the backtrace to stop at level 2. + + Tested on arm-linux. + + Approved-By: Luis Machado + Approved-By: Andrew Burgess + +2024-07-23 Pali Roh?r + + Improve objdump's display of PE header information. + PR 31953 + +2024-07-23 GDB Administrator + + Automatic date update in version.in + +2024-07-22 Simon Marchi + + gdb/unittests/intrusive-list: remove unnecessary local objects + These objects are not used. + + Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f + +2024-07-22 Simon Marchi + + gdb/solib: pass program space to solib_used + Make the current program space reference bubble up one level. + + Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123 + +2024-07-22 Andrew Burgess + + gdb/remote: remove an out of date comment + A comment above an `if` check was accidentally left in place after + this commit: + + commit ddb3f3d89cf62df6be3cb9e110504def19625160 + Date: Tue Mar 19 12:34:34 2024 +0100 + + Add "error_message+" feature to qSupported + + The comment relates to how 'E.msg' style remote replies are not + supported by every packet, but after the above commit they are + supported in all cases (that call packet_check_result), and the + comment should have been removed. + +2024-07-22 Andrew Burgess + + gdb/testsuite: fix minor typo in a comment + Fix 'text' to 'test' in a test comment. + +2024-07-22 GDB Administrator + + Automatic date update in version.in + +2024-07-21 Alan Modra + + Don't trim trailing newline in run_host_cmd + Testcases like ld-elf/pr19719a.c that + printf ("PASS\n"); + on success ought to see the whole output for "string match". + Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last + newline to match. For most of the testsuite it doesn't matter whether + the trailing newline is present or not, and there are only a few cases + where we need to remove it. + + * testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away + output trailing newline. Do string trim for gcc/ld version checks. + * testsuite/config/default.exp (plug_so): Do string trim output of + run_host_cmd. + * testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust + string match to include trailing newline. + * testsuite/ld-i386/i386.exp (undefined_weak): Likewise. + * testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise. + * testsuite/ld-plugin/libdep.exp (run_test): Likewise. + * testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise. + * testsuite/ld-pe/pdb-strings.d, + * testsuite/ld-pe/pdb-syms1-globals.d, + * testsuite/ld-pe/pdb-syms1-records.d, + * testsuite/ld-pe/pdb-syms1-symbols1.d, + * testsuite/ld-pe/pdb-syms1-symbols2.d, + * testsuite/ld-pe/pdb-syms2-symbols1.d, + * testsuite/ld-pe/pdb-types1-hashlist.d, + * testsuite/ld-pe/pdb-types1-skiplist.d, + * testsuite/ld-pe/pdb-types1-typelist.d, + * testsuite/ld-pe/pdb-types2-hashlist.d, + * testsuite/ld-pe/pdb-types2-skiplist.d, + * testsuite/ld-pe/pdb-types2-typelist.d, + * testsuite/ld-pe/pdb-types3-hashlist.d, + * testsuite/ld-pe/pdb-types3-skiplist.d, + * testsuite/ld-pe/pdb-types3-typelist.d, + * testsuite/ld-pe/pdb1-publics.d, + * testsuite/ld-pe/pdb1-sym-record.d, + * testsuite/ld-pe/pdb2-section-contrib.d, + * testsuite/ld-pe/pdb3-c13-info1.d, + * testsuite/ld-pe/pdb3-c13-info2.d, + * testsuite/ld-pe/pdb3-source-info.d: Add trailing newline. + +2024-07-21 Andrew Burgess + + gdb/testsuite: Add missing 'require allow_gdbserver_tests' + The commit: + + commit 22836ca88591ac7efacf06d5b6db191763fd8aba + Date: Tue May 21 09:57:49 2024 +0100 + + gdb: check for multiple matching build-id files + + Was missing a 'require allow_gdbserver_tests' in a gdbserver test. + Add it now. + +2024-07-21 Tom de Vries + + [gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.exp + When running test-case gdb.dap/rust-slices.exp on aarch64-linux + (debian 12/bookworm), I run into: + ... + {"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success + FAIL: gdb.dap/rust-slices.exp: three scopes + PASS: gdb.dap/rust-slices.exp: scope is locals + PASS: gdb.dap/rust-slices.exp: locals presentation hint + PASS: gdb.dap/rust-slices.exp: three vars in scope + ... + + The test-case expects three scopes due to a rust compiler issue: + ... + # There are three scopes because an artificial symbol ends up in the + # DWARF. See https://github.com/rust-lang/rust/issues/125126. + gdb_assert {[llength $scopes] == 3} "three scopes" + ... + but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't + have this issue. + + Fix this by allowing two or three scopes, and changing the test name to + "two scopes". + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31983 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983 + +2024-07-21 GDB Administrator + + Automatic date update in version.in + +2024-07-20 Mark Harmstone + + ld/testsuite: add missing definition to PDB test + The file pdb-syms1a.s was missing a definition for T_VOID, which was + causing some types not to be deduplicated. It also meant that the test + couldn't be run against LLVM's lld, which throws an error for this. + + This particular test only tests the symbols stream, not the types + stream, which is why the deduplication doesn't result in a change in the + file size. + +2024-07-20 Mark Harmstone + + ld/PDB: use correct hashing algorithm in add_globals_ref + add_globals_ref was hashing using CRC32 rather than the hashing + algorithm used for symbols, which meant that windbg was unable to put + breakpoints against unmangled names. + +2024-07-20 H.J. Lu + + Correct version for binutils 2.43 NEWS entries. + Change 2.42 to 2.43 for binutils 2.43 NEWS entries. + + binutils/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + + ld/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + +2024-07-20 Andrew Burgess + + gdb: remove tracepoint_probe_create_sals_from_location_spec + The tracepoint_probe_create_sals_from_location_spec function just + forwards all its arguments to + bkpt_probe_create_sals_from_location_spec, and is only used in one + place. + + Lets delete tracepoint_probe_create_sals_from_location_spec and + replace it with bkpt_probe_create_sals_from_location_spec. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: remove breakpoint_re_set_one + During a later patch I wanted to reset a single breakpoint, so I + called breakpoint_re_set_one. However, this is not the right thing to + do. If we look at breakpoint_re_set then we see that there's a whole + bunch of state that needs to be preserved prior to calling + breakpoint_re_set_one, and after calling breakpoint_re_set_one we + still need to call update_global_location_list. + + I could just update the comment on breakpoint_re_set_one to make it + clearer how the function should be used -- or more likely to warn that + the function should only be used as a helper from breakpoint_re_set. + + However, breakpoint_re_set_one is only 3 lines long. So I figure it + might actually be easier to just fold breakpoint_re_set_one into + breakpoint_re_set, then there's no risk of accidentally calling + breakpoint_re_set_one when we shouldn't. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: don't display inferior list for pending breakpoints + I noticed that in the 'info breakpoints' output, GDB sometimes prints + the inferior list for pending breakpoints, this doesn't seem right to + me. A pending breakpoint has no locations (at least, as far as we + display things in the 'info breakpoints' output), so including an + inferior list seems odd. + + Here's what I see right now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo inf 1 + (gdb) + + It's the 'inf 1' at the end of the line that I'm objecting too. + + To trigger this behaviour we need to be in a multi-inferior debug + session. The breakpoint must have been non-pending at some point in + the past, and so have a location assigned to it. + + The breakpoint becomes pending again as a result of a shared library + being unloaded. When this happens the location itself is marked + pending (via bp_location::shlib_disabled). + + In print_one_breakpoint_location, in order to print the inferior list + we check that the breakpoint has a location, and that we have multiple + inferiors, but we don't check if the location itself is pending. + + This commit adds that check, which means the output is now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo + (gdb) + + Which I think makes more sense -- indeed, the format without the + inferior list is what we display for a pending breakpoint that has + never had any locations assigned, so I think this change in behaviour + makes GDB more consistent. + +2024-07-20 Nick Clifton + + Update after creating 2.43 branch + + Change version to 2.43.50 + + Add markers for 2.43 branch/release + +2024-07-20 Alan Modra + + Re: binutils: Add a test for strip with build notes + The new test wasn't being run, and failed due to relocations against + .gnu.build.attributes being stripped by default strip behaviour. + We probably should be keeping these relocations, but I haven't made + that change here. + BTW, the new test fails on ia64-hpux but that's just a repeat of the + existing note-5 fail. + + PR 31999 + * testsuite/binutils-all/strip-16.d: strip with --strip-unneeded + and --merge-notes. + * testsuite/binutils-all/objcopy.exp: Run the new test. Sort + other strip tests. + +2024-07-20 H.J. Lu + + binutils: Add a test for strip with build notes + Add a test for strip with build notes. + + PR binutils/31999 + * testsuite/binutils-all/strip-16.d: New. + +2024-07-20 Alan Modra + + PR31999 strip [.gnu.build.attributes]: failed + PR 31999 + * objcopy.c (merge_gnu_build_notes): Always set *new_size. + +2024-07-20 GDB Administrator + + Automatic date update in version.in + +2024-07-19 Simon Marchi + + gdb-gdb.py: strip typedefs in intrusive_list printer assertion + When debugging gdb itself and trying to print a intrusive_list that has + more than one element, I get: + + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator + node_ptr = self._as_node_ptr(elem_ptr) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr + assert elem_ptr.type.code == gdb.TYPE_CODE_PTR + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + AssertionError + + This is because node_ptr is a typedef + (intrusive_list_base_iterator::pointer). Add a call to strip_typedefs + to get to the real type. + + Enhance gdb.gdb/python-helper.exp with a test that would have caught + this bug. + + Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700 + Approved-By: Andrew Burgess + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Replace "y" microMIPS operand code with "x" + Replace the "y" microMIPS operand code, used with ALNV.PS only, with "x" + so as to make "y" available for microMIPS MT use. + + MIPS/opcodes: Mark MT thread context move assembly idioms as aliases + A number of instructions in the regular MIPS opcode table are assembly + idioms for the MT thread context move MFTR and MTTR instructions, so + mark them as aliases accordingly. Add suitable test cases, which also + cover the PAUSE assembly idiom. + + MIPS/opcodes: Mark PAUSE as an alias + PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in + the regular MIPS opcode table, matching the microMIPS opcode table. A + test case will be supplied separately. + + MIPS/GAS/testsuite: Run the MT ASE test across architectures + Verify that MT ASE instructions assemble and disassemble correctly + across the compatible architectures. + + MIPS/opcodes: Reorder coprocessor moves alphabetically + A number of coprocessor move encodings have been randomly sprinkled over + the regular MIPS and microMIPS opcode tables rather than where they'd be + expected following the alphabetic order. Fix the ordering, taking into + account precedence where it has to be observed for correct disassembly. + No functional change. + + MIPS/opcodes: Make AL a shorthand for INSN2_ALIAS + Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS + opcode tables, just as with the MIPS16 opcode table, and use it + throughout. No functional change. + + MIPS/opcodes: Rename the AL membership shorthand to ALX + Make room for AL as a shorthand for INSN2_ALIAS with the regular MIPS + opcode table, just as with the MIPS16 opcode table. No functional + change. + +2024-07-19 YunQiang Su + + MIPS/opcodes: Remove the regular MIPS "+t" operand code + The semantics of the regular MIPS "+t" operand code is exactly the same + as that of the "E" operand code, so replace the former with the latter + in the single MFTC0 instruction with implicit 'sel' == 0 encoding where + it's used, matching the encoding with explicit 'sel' as well as other + instructions. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Output thread context registers numerically with MFTR/MTTR + We print MFTR and MTTR instructions' thread context register operand in + disassembly using the ABI name the register number would correspond to + should the targeted register be a general-purpose register. + + However in most cases it is wrong, because general-purpose registers are + only referred when the 'u' and 'sel' operands are 1 and 0 respectively. + And even in these cases the MFGPR and MTGPR aliases take precedence over + the corresponding generic instruction encodings, so you won't see the + valid case to normally trigger. + + Conversely decoding the thread context register operand numerically is + always valid, so switch to using it. Adjust test coverage accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros + As from commit ab90248154ba ("Add structures to describe MIPS + operands"), , + the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros + has been removed. + + Similarly as from commit c3c0747817f4 ("Use operand structures for + MIPS16"), , + the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed. + + And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"), + , none of the + OP_OP macros are used anymore. + + Discard all the unused macros then and only keep the small subset that + is still referred. This simplifies maintenance and removes the need to + keep the artificial arrangement where some regular MIPS and microMIPS + macros expand to 0 and are kept for compatibility with the opposite ISA + mode only, as it used to be required before the commit referred. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Correct documentation for R6 operand types + The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which + is the target register rather than the source register. Additionally + the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand + of the BOVC/BNVC and the BEQC/BNEC instructions respectively. Also the + "-x" operand type does not permit 'rs' to be the same as 'rt'. + + Correct inline documentation in opcode/mips.h accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Exclude $0 from "-x" R6 operand type + The "-x" operand type is used for the reverse encoding of the BOVC and + BNVC instructions, where 'rs' and 'rt' have been supplied as the second + and the first operand respectively rather than the order the instruction + expects. + + In this case we require the register associated with the "-x" operand to + have a higher number than the register associated with the preceding "t" + operand, which precludes the use of $0. The case where 'rs' and 'rt' + both refer to the same register is handled by the straight encoding of + the BOVC and BNVC instructions, which come in the opcode table ahead of + the corresponding reverse encoding. + + Therefore clear the ZERO_OK flag for the "-x" operand. No need for an + extra test case as the encodings involved are already covered by "r6" + and its associated GAS tests. + +2024-07-19 Jan Beulich + + Sparc: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + TilePro: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate (and far less intrusive) here. + + MIPS: correct macro use in gas and ld testsuites + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + former appears more appropriate here, as the macro parameters already + have ":req". + + ia64: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate here. + + bfin: drop _ASSIGN_BANG + A few testcases demonstrate that "=!" isn't supposed to be an + individual token, since "= !" is used in a number of places. So far + lexing that to a single token worked because of the scrubber being + overly aggressive in removing whitespace. As that's going to change, + replace uses by separate ASSIGN and BANG. + + bfin: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter really isn't an option here. + + Arm: correct macro use in gas testsuite + The way the inner macro invocations are written doesn't quite work as + expected (and would actually break subsequently): Due to overly + aggressive removal of whitespace by the scrubber, the incoming \sym and + \offset arguments actually get concatenated; an empty 3rd argument is + being passed to ldrtest2. That just so happened to work as intended; any + use of \offset alone would have exposed the problem. Quote the 3rd + argument, thus retaining enough whitespace to be independent of scrubber + internals. + + gas: adjust impossible/bogus M68K/MRI special case when scrubbing + State 1 is uniformly handled further up. And it is highly questionable + that in state 10 (i.e. after having seen not only a possible label, but + also an opcode), which is about to go away anyway, a line comment char + could still be meant to take effect. With the state checking dropped, + the immediately preceding logic can then also be simplified. + +2024-07-19 Jan Beulich + + gas: consistently drop trailing whitespace when scrubbing + From especially the checks for the two separator forms it appears to + follow that the construct being touched is about trailing whitespace. In + such a case, considering that for many targets ordinary and line comment + chars overlap, take into account that line comment chars override + ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually + depends on that ordering, and also accounts for this overriding). + + Plus of course IS_NEWLINE() would better also be consulted. Note also + that the DOUBLESLASH_LINE_COMMENTS change should generally have no + effect just yet; it's a prereq for a later change but better fits here. + + Leave respective comments as well, and update documentation to correct + which comment form is actually replaced by a single blank (i.e. neither + the ones starting with what {,tc_}comment_chars[] has nor the ones + starting with what line_comment_chars[] has). + +2024-07-19 Jan Beulich + + gas: drop tic6x scrubber special case + Two successive PUT() without a state change in between can't be right: + The first PUT() may take the "goto tofull" path, leading to the + subsequent character being processed later in the previously set state + (1 in this case), rather than the state we were in upon entry to the + switch() (13 in this case). + + However, the original purpose of that logic appears to be to not mistake + "|| ^" for "||^". This effect, sadly, looks to not have been achieved. + Therefore drop the special case altogether; something that actually + achieves the (presumably) intended effect may then be introduced down + the road. + +2024-07-19 Jan Beulich + + gas: pre-init the scrubber's lex[] + While we can't - unlike an old comment suggests - do this fully, we can + certainly do part of this at compile time. + + Since it's adjacent, also drop the unnecessary forward declaration of + process_escape(). + +2024-07-19 Jan Beulich + + x86: accept whitespace inside curly braces + Other than documented /**/ comments currently aren't really converted to + a single space, at least not for x86 in its most common configurations. + That'll be fixed subsequently, at which point blanks may appear where so + far none were expected. Furthermore not permitting blanks immediately + inside curly braces wasn't quite logical anyway - such constructs are + composite ones, and hence components ought to have been permitted to be + separated by whitespace from the very beginning. + + With this we also don't care anymore whether the scrubber would remove + whitespace around curly braces, so move them from extra_symbol_chars[] + to operand_special_chars[]. + + Note: The new testcase doesn't actually exercise much (if any) of the + added code. It is being put in place to ensure that subsequently, when + that code actually comes into play, behavior remains the same. + +2024-07-19 Jan Beulich + + x86: undo '{' being a symbol-start character + Having it that way has undue side effects, in permitting not only + pseudo-prefixes to be parsed correctly, but also permitting odd symbol + names which ought to be possible only when quoted. Borrow what other + architectures do: Put in place an "unrecognized line" hook to parse off + any pseudo prefixes, while using the "start of line" hook to reject ones + not actually followed by an insn. For that parsing re-use parse_insn() + in yet a slightly different mode (dealing with only pseudo-prefixes). + + With that, pp may no longer be cleared from init_globals(), but instead + needs clearing after a line was fully processed. Since md_assemble() has + pretty many return paths, convert that into a local helper, with a + trivial wrapper around it. + + Similarly pp may no longer be updated (by check_register()) when + processing anything other than insn operands. To be able to (easily) + recognize the case, clear current_templates.start when done with an insn + (or with .insn). + +2024-07-19 Jan Beulich + + x86: split pseudo-prefix state from i386_insn + Subsequently we will want to update that ahead of md_assemble(), with + that function needing to take into account such earlier updating. + Therefore it'll want resetting separately from i. + +2024-07-19 Jan Beulich + + x86/APX: add CMPcc/CTESTcc cases to noreg64 tests + This was missed when support for the insns was added. Just like for + DATA16, in + + rex64 neg (%rax) + rex64 neg (%r16) + rex64 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the prefix. + +2024-07-19 zhangxianting + + bfin: free the allocated memory + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of multiplication macros + Provide 'mul' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split mul test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit multiplication macro verification, by + splitting the 'mul' test into two parts respectively, and run them + across all the compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the mul macro test across architectures + The multiplication macros expand differently based on the ISA chosen, so + run the 'mul' macro test across compatible architectures, adopting the + 'mul-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of division macros + Provide 'div' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split div test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit division macro verification, by splitting + the 'div' test into two parts respectively, and run them across all the + compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the div macro test across architectures + The division macros expand differently depending on the ISA selected, so + run the 'div' macro test across compatible architectures, adopting the + 'div-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS: Handle --trap command-line option dynamically + We have an ISA check for the '--trap' command-line option that reports + its incompatibility with the MIPS I architecture. It doesn't prevent + trap instructions from being enabled though, so when attempt is made to + emit one in an expansion of one of the division or multiplication macros + an assertion failure triggers: + + .../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages: + .../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1 + .../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero + .../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064. + Please report this bug. + + The same assertion failure triggers without an earlier error message + when the initial ISA is compatible with the '--trap', however at the + time an attempt is made to emit a trap instruction from a division or + multiplication macro the ISA has been changed by a '.set' pseudo-op to + an incompatible one. + + With the way the situations are mishandled it seems unlikely that anyone + relies on the current semantics and a sane approach is to decide on the + fly according to the currently selected ISA as to whether to emit trap + or breakpoint instructions in the case where '--trap' has been used. + + Change our code to do so then and clarify that in the manual, which is + not explicit about how '--trap' is handled with a changing ISA. Mention + the change in NEWS too since it's a applies to a user option. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Add R10000 CPU architecture + Add a fully interlocked MIPS IV CPU so that we can have coverage for + MIPS IV instruction sequences with and without instruction separation + required for a HI/LO data anti-dependency. + + MIPS/GAS/testsuite: Reorder R5900 CPU architecture definition + The R5900 CPU architecture is based on MIPS III, so move it ahead of + MIPS IV CPU architecture definitions. No functional change. + +2024-07-19 Indu Bhagat + + gas: aarch64: testsuite: add new tests for SCFI + Similar to the x86_64 testcases, some .s files contain the corresponding + CFI directives. This helps in validating the synthesized CFI by running + those tests with and without the --scfi=experimental command line + option. + + GAS issues some diagnostics, enabled by default, with + --scfi=experimental. The diagnostics have been added with an intent to + help user correct inadvertent errors in their hand-written asm. An + error is issued when GAS finds that input asm is not amenable to + accurate CFI synthesis. The existing scfi-diag-*.s tests in the + gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics + already: + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + - (#4) "Error: untraceable control flow for func 'XXX'" + + In the newly added aarch64 testsuite, further tests for additional + diagnostics have been added: + - scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic: + (#5) "Warning: SCFI: ignored probable save/restore op with reg offset" + + Additionally, some testcases are added to showcase the (currently) + unsupported patterns, e.g., scfi-unsupported-1.s + mov x16, 4384 + sub sp, sp, x16 + + gas/testsuite/: + * gas/scfi/README: Update comment to include aarch64. + * gas/scfi/aarch64/scfi-aarch64.exp: New file. + * gas/scfi/aarch64/ginsn-arith-1.l: New test. + * gas/scfi/aarch64/ginsn-arith-1.s: New test. + * gas/scfi/aarch64/ginsn-cofi-1.l: New test. + * gas/scfi/aarch64/ginsn-cofi-1.s: New test. + * gas/scfi/aarch64/ginsn-ldst-1.l: New test. + * gas/scfi/aarch64/ginsn-ldst-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test. + * gas/scfi/aarch64/scfi-cb-1.d: New test. + * gas/scfi/aarch64/scfi-cb-1.l: New test. + * gas/scfi/aarch64/scfi-cb-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-1.d: New test. + * gas/scfi/aarch64/scfi-cfg-1.l: New test. + * gas/scfi/aarch64/scfi-cfg-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-2.d: New test. + * gas/scfi/aarch64/scfi-cfg-2.l: New test. + * gas/scfi/aarch64/scfi-cfg-2.s: New test. + * gas/scfi/aarch64/scfi-cfg-3.d: New test. + * gas/scfi/aarch64/scfi-cfg-3.l: New test. + * gas/scfi/aarch64/scfi-cfg-3.s: New test. + * gas/scfi/aarch64/scfi-cfg-4.l: New test. + * gas/scfi/aarch64/scfi-cfg-4.s: New test. + * gas/scfi/aarch64/scfi-cond-br-1.d: New test. + * gas/scfi/aarch64/scfi-cond-br-1.l: New test. + * gas/scfi/aarch64/scfi-cond-br-1.s: New test. + * gas/scfi/aarch64/scfi-diag-1.l: New test. + * gas/scfi/aarch64/scfi-diag-1.s: New test. + * gas/scfi/aarch64/scfi-diag-2.l: New test. + * gas/scfi/aarch64/scfi-diag-2.s: New test. + * gas/scfi/aarch64/scfi-diag-3.l: New test. + * gas/scfi/aarch64/scfi-diag-3.s: New test. + * gas/scfi/aarch64/scfi-ldrp-1.d: New test. + * gas/scfi/aarch64/scfi-ldrp-1.l: New test. + * gas/scfi/aarch64/scfi-ldrp-1.s: New test. + * gas/scfi/aarch64/scfi-ldrp-2.d: New test. + * gas/scfi/aarch64/scfi-ldrp-2.l: New test. + * gas/scfi/aarch64/scfi-ldrp-2.s: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.d: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.l: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.s: New test. + * gas/scfi/aarch64/scfi-strp-1.d: New test. + * gas/scfi/aarch64/scfi-strp-1.l: New test. + * gas/scfi/aarch64/scfi-strp-1.s: New test. + * gas/scfi/aarch64/scfi-strp-2.d: New test. + * gas/scfi/aarch64/scfi-strp-2.l: New test. + * gas/scfi/aarch64/scfi-strp-2.s: New test. + * gas/scfi/aarch64/scfi-unsupported-1.l: New test. + * gas/scfi/aarch64/scfi-unsupported-1.s: New test. + * gas/scfi/aarch64/scfi-unsupported-2.l: New test. + * gas/scfi/aarch64/scfi-unsupported-2.s: New test. + +2024-07-19 Indu Bhagat + + gas: aarch64: add experimental support for SCFI + For synthesizing CFI (SCFI) for hand-written asm, the SCFI machinery in + GAS works on the generic GAS insns (ginsns). This patch adds support in + the aarch64 backend to create ginsns for a subset of the supported + machine instructions. The subset includes the minimal necessary + instructions to ensure SCFI correctness: + + - Any potential register saves and unsaves. Hence, process instructions + belonging to a variety of iclasses involving str, ldr, stp, ldp. + - Any change of flow instructions. This includes all conditional and + unconditional branches, call (bl, blr, etc.) and return. + - Most importantly, any instruction that could affect the two registers + of interest: REG_SP, REG_FP. This set includes all pre-indexed and + post-indexed memory operations, with writeback, on the stack. This + set must also include other instructions (e.g., arithmetic insns) + where the destination register is one of the afore-mentioned registers. + + With respect to callee-saved registers in Aarch64, FP/Advanced SIMD + registers D8-D15 are included along with the relevant GPRs. Calculating + offsets for loads and stores especially for Q registers needs special + attention here. + + As an example, + str q8, [sp, #16] + On big-endian: + STR Qn stores as a 128-bit integer (MSB first), hence, should record + D8 as being saved at sp+24 rather than sp+16. + On little-endian: + should record D8 as being saved at sp+16 + + D8-D15 are the low 64 bits of Q8-Q15, and of Z8-Z15 if SVE is used; + hence, they remain "interesting" for SCFI purposes in such cases. A CFI + save slot always represents the low 64 bits, regardless of whether a + save occurs on D, Q or Z registers. Currently, the ginsn creation + machinery can handle D and Q registers on little-endian and big-endian. + + Apart from creating ginsn, another key responsibility of the backend is + to make sure there are safeguards in place to detect and alert if an + instruction of interest may have been skipped. This is done via + aarch64_ginsn_unhandled () (similar to the x86 backend). This function + , hence, is also intended to alert when future ISA changes may otherwise + render SCFI results incorrect, because of missing ginsns for the newly + added machine instructions. + + At this time, becuase of the complexities wrt endianness in handling Z + register usage, skip sve_misc opclass altogether for now. The SCFI + machinery will error out (using the aarch64_ginsn_unhandled () code + path) though if Z register usage affects correctness. + + The current SCFI machinery does not currently synthesize the + PAC-related, aarch64-specific CFI directives: .cfi_b_key_frame. The + support for this is planned for near future. + + SCFI is enabled for ELF targets only. + + gas/ + * config/tc-aarch64-ginsn.c: New file. + * config/tc-aarch64.c (md_assemble): Include tc-aarch64-ginsn.c + file. Invoke aarch64_ginsn_new. + * config/tc-aarch64.h (TARGET_USE_GINSN): Define for SCFI + enablement. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): New definition. + (REG_FP): Likewise. + (REG_LR): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (aarch64_scfi_callee_saved_p): New declaration. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: enforce checks on subclass flags in aarch64-gen.c + Enforce some checks on the newly added subclass flags: + - If a subclass is set of one insn of an iclass, every insn of that + iclass must have non-zero subclass field. + - For all other iclasses, the subclass bits are zero for all insns. + + include/ + * opcode/aarch64.h (enum aarch64_insn_class): Identify the + maximum iclass enum value. + + opcodes/ + * aarch64-gen.c (iclass_has_subclasses_p): New array of bool. + (read_table): Enforce checks on subclass flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: denote subclasses for insns of iclass dp_2src + For detecting irg, add a subclass to identify it in the set of + instructions of iclass dp_2src. + + opcodes/ + * aarch64-tbl.h: Add subclass flag F_DP_TAG_ONLY for irg insn. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of uncond branches + Use the two new subclass flags: F_BRANCH_CALL, F_BRANCH_RET, to indicate + call to and return from subroutine respectively. + + opcodes/ + * aarch64-tbl.h: Use the new F_BRANCH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of arithmetic insns + Use the three new subclass flags: F_ARITH_ADD, F_ARITH_SUB, + F_ARITH_MOV, to indicate add, sub and mov ops respectively. + + These flags for subclasses will later be used for SCFI purposes to + create appropriate ginsns. At this time, only those iclasses relevant + to SCFI have the new subclass flags specified. + + For addg and subg insns, F_SUBCLASS_OTHER is more suitable because these + operations do more than just simple add or sub. + + opcodes/ + * aarch64-tbl.h: Use the new F_ARITH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of ldst insns + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass + of ldst_* is a load or a store. + + At the moment, specify subclasses for only those iclasses relevant to + SCFI: ldst_imm9, ldst_pos, ldstpair_indexed, ldstpair_off and + ldstnapair_offs. + + Some insns are best tagged with F_SUBCLASS_OTHER rather than F_LDST_LOAD + or F_LDST_STORE: + - stg* ops (as they store tag only), + - prfm, + - ldpsw, ldrsw (32-bit loads with signed extended value. Not useful + for restore operations in context of SCFI.) + - Use F_SUBCLASS_OTHER for all QL_LDST_R8 and QL_LDST_R16 operands. + Also use F_SUBLASS_OTHER for strb/ldrb, strh/ldrh opcodes. + These are not full loads and stores and cannot be allowed for + register save / restore for the purpose of SCFI. + + opcodes/ + * aarch64-tbl.h: Use the new F_LDST_* flags. + +2024-07-19 Indu Bhagat + + include: opcodes: aarch64: define new subclasses + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass of + ldst_* is a load or a store. Similarly, whether a particular arithmetic + insn is an add or sub or mov, etc. + + This patch defines new flags to demarcate the insns. Also provide an + access function for subclass lookup. + + Later, we will enforce (in aarch64-gen.c) that if an iclass has at least + one instruction with a non-zero subclass, all instructions of the iclass + must have a non-zero subclass information. If none of the defined + subclasses are applicable (or not required for SCFI purposes), + F_SUBCLASS_OTHER can be used for such instructions. + + include/ + * opcode/aarch64.h (F_SUBCLASS): New flag. + (F_SUBCLASS_OTHER): Likewise. + (F_LDST_LOAD): Likewise. + (F_LDST_STORE): Likewise. + (F_ARITH_ADD): Likewise. + (F_ARITH_SUB): Likewise. + (F_ARITH_MOV): Likewise. + (F_BRANCH_CALL): Likewise. + (F_BRANCH_RET): Likewise. + (F_DP_TAG_ONLY): Likewise. + (aarch64_opcode_subclass_p): New definition. + +2024-07-19 Indu Bhagat + + gas: scfi: make scfi_state_restore_reg function more precise + When the SCFI machinery detects that a register has been restored from + stack, it makes some state changes in the SCFI state object. + + Prior to the patch, scfi_state_restore_reg () was setting a value of + (reg, CFI_IN_REG) for (base, state) respectively. This was causing + issues in the cmp_scfi_state () function: + - The default state of all (callee-saved) regs at the beginning of + function is set to (0, CFI_UNDEFINED). + - If a register is saved and restored on some control path, the state + of reg is (reg, CFI_IN_REG) on that path. + - On another control path where the register was perhaps not + used (or saved/restored on stack) remains (0, CFI_UNDEFINED). + - The two states should be treated equal, however, at the point in + program after the register has been restored. + + Fix this by resetting the state to (0, CFI_UNDEFINED) in + scfi_state_restore_reg (). + + A testcase (scfi-cfg-4.s) for this is added in a subsequent commit. + + gas/ + * scfi.c (scfi_state_restore_reg): Reset to 0, CFI_UNDEFINED + for base, state. + +2024-07-19 GDB Administrator + + Automatic date update in version.in + +2024-07-18 Matthieu Longo + + gas: minor reformatting in command line help and doc + - help message: add a comma between the short and long option + - as doc: + - brief summary of how to invoke gas: separate [-w] [-x] on a new line as those + two options have nothing to do with the warning options. + - reordering of the warning options to have the same order as the listing. + - no-warn option description: change an "and" to a "or", as it is either the short + or long option to use, but not both at the same time. + - remove trailing whitespaces. + +2024-07-18 Andrew Burgess + + gdb: check for multiple matching build-id files + Within the debug-file-directory GDB looks for the existence of a + .build-id directory. + + Within the .build-id directory GDB looks for files with the form: + + .build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug + + which contain the debug information for the objfile with the build-id + ff4b4142d62b399499844924d53e33d4028380db. + + There appear to be two strategies for populating the .build-id + directory. Ubuntu takes the approach of placing the actual debug + information in this directory, so + 4b4142d62b399499844924d53e33d4028380db.debug is an actual file + containing the debug information. + + Fedora, RHEL, and SUSE take a slightly different approach, placing the + debug information elsewhere, and then creating symlinks in the + .build-id directory back to the original debug information file. The + actual debug information is arranged in a mirror of the filesystem + within the debug directory, as an example, if the debug-file-directory + is /usr/lib/debug, then the debug information for /bin/foo can be + found in /usr/lib/debug/bin/foo.debug. + + Where this gets interesting is that in some cases a package will + install a single binary with multiple names, in this case a single + binary will be install with either hard-links, or symlinks providing + the alternative names. + + The debug information for these multiple binaries will then be placed + into the /usr/lib/debug/ tree, and again, links are created so a + single file can provide debug information for each of the names that + binary presents as. An example file system might look like this (the + [link] could be symlinks, but are more likely hard-links): + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + + In the .build-id tree though we have a problem. Do we have a single + entry that links to one of the .debug files? This would work; a user + debugging any of the binaries will find the debug information based on + the build-id, and will get the correct information, after all the + .debug files are identical (same file linked together). But there is + one problem with this approach. + + Sometimes, for *reasons* it's possible that one or more the linked + binaries might get removed, along with its associated debug + information. I'm honestly not 100% certain under what circumstances + this can happen, but what I observe is that sometime a single name for + a binary, and its corresponding .debug entry, can be missing. If this + happens to be the entry that the .build-id link is pointing at, then + we have a problem. The user can no longer find the debug information + based on the .build-id link. + + The solution that Fedora, RHEL, & SUSE have adopted is to add multiple + entries in the .build-id tree, with each entry pointing to a different + name within the debug/ tree, a sequence number is added to the + build-id to distinguish the multiple entries. Thus, we might end up + with a layout like this: + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + .build-id/ + a3/ + 4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ] + + With current master GDB, debug information will only ever be looked up + via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if + 'foo' and its corresponding 'foo.debug' are ever removed, then master + GDB will fail to find the debug information. + + Ubuntu seems to have a much better approach for debug information + handling; they place the debug information directly into the .build-id + tree, so there only ever needs to be a single entry for any one + build-id. I wonder if/how they handle the case where multiple names + might share a single .debug file, if one of those names is then + uninstalled, how do they know the .debug file should be retained or + not ... but I assume that problem either doesn't exist or has been + solved. + + Anyway, for a while Fedora has carried a patch that handles the + build-id sequence number logic. What's presented here is inspired by + the Fedora patch, but has some changes to fix some issues. + + I'm aware that this is a patch that applies to only some (probably a + minority) of distros. However, the logic is contained to only a + single function in build-id.c, and isn't too complex, so I'm hoping + that there wont be too many objections. + + For distros that don't have build-id sequence numbers there should be + no impact. The sequence number approach still leaves the first file + without a sequence number, and this is the first file that GDB (after + this patch) checks for. The new logic only kicks in if the + non-sequence numbered first file exists, but is a symlink to a non + existent file; in this case GDB checks for the sequence numbered files + instead. + + Tests are included. + + There is a small fix needed for gdb.base/sysroot-debug-lookup.exp, + after this commit GDB now treats a target: sysroot where the target + file system is local to GDB the same as if the sysroot had no target: + prefix. The consequence of this is that GDB now resolves a symlink + back to the real filename in the sysroot-debug-lookup.exp test where + it didn't previously. As this behaviour is inline with the case where + there is no target: prefix I think this is fine. + +2024-07-18 Andrew Burgess + + gdbserver: add gdbserver support for vFile::stat packet + After the previous two commits, this commit adds support for the + vFile::stat packet to gdbserver. This is pretty similar to the + handling for vFile::fstat, but instead calls 'lstat'. + + There's still no users of target_fileio_stat in GDB, that will come in + a later commit. + +2024-07-18 Andrew Burgess + + gdb: add GDB side target_ops::fileio_stat implementation + This commit adds the GDB side of target_ops::fileio_stat. There's an + implementation for inf_child_target, which just calls 'lstat', and + there's an implementation for remote_target, which sends a new + vFile:stat packet. + + The new packet is documented. + + There's still no users of target_fileio_stat as I have not yet added + support for vFile::stat to gdbserver. If these packets are currently + sent to gdbserver then they will be reported as not supported and the + ENOSYS error code will be returned. + + Reviewed-By: Eli Zaretskii + +2024-07-18 Andrew Burgess + + gdb: add target_fileio_stat, but no implementations yet + In a later commit I want target_fileio_stat, that is a call that + operates on a filename rather than an open file descriptor as + target_fileio_fstat does. + + This commit adds the initial framework for target_fileio_stat, I've + added the top level target function and the virtual target_ops methods + in the target_ops base class. + + At this point no actual targets override target_ops::fileio_stat, so + any attempts to call this function will return ENOSYS error code. + +2024-07-18 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Added "APX_F is fully supportted" to gas/NEWS. + +2024-07-18 GDB Administrator + + Automatic date update in version.in + +2024-07-17 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-pseudo-unwind.exp with unix/mthumb + When running test-case gdb.arch/arm-pseudo-unwind.exp with target board + unix/mthumb, we run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Program received signal SIGILL, Illegal instruction.^M + 0x00400f38 in ?? ()^M + (gdb) FAIL: $exp: continue to breakpoint: continue to callee + ... + + The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode + using additional_flags=-marm, but that's overridden by using target board + unix/mthumb. + + This causes function main to be in thumb mode, and consequently function + caller (which is called from main) is is executed as if it's in thumb mode, + while it's actually in arm mode. + + Fix this by adding an intermediate function caller_trampoline in + arm-pseudo-unwind.c, and hardcoding it to arm mode using + __attribute__((target("arm"))). + + Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp. + + Tested on arm-linux. + + Approved-By: Luis Machado + +2024-07-17 Indu Bhagat + + gas: scfi: testsuite: refresh the README + Update some stale text in the README. Add few more notes to guide + future maintenance of the testsuite. + + gas/testsuite/ + * gas/scfi/README: Update text. + +2024-07-17 GDB Administrator + + Automatic date update in version.in + +2024-07-16 Simon Marchi + + gdb, gdbserver, gdbsupport: use [[noreturn]] instead of ATTRIBUTE_NORETURN + C++ 11 has a built-in attribute for this, no need to use a compat macro. + + Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875 + Reviewed-by: Lancelot Six + +2024-07-16 Simon Marchi + + gdb: fix indentation in remote.c + Change-Id: If344acdf703fdd3892f73f75fc891d5473808b79 + +2024-07-16 Simon Marchi + + gdb: add ATTRIBUTE_NORETURN to remote_unpush_target + My IDE (well, clangd) suggested this. It doesn't hurt to have it. + + Change-Id: If6001983c17dbed3dceebac3078c8deb12c04d6b + +2024-07-16 Tom de Vries + + [gdb/testsuite] Simplify gdb.base/complex-parts.exp + I noticed a lot of escaping in test-case gdb.base/complex-parts.exp. + + Make the test-case more readable by using: + - string_to_regexp, and + - {} instead of "". + + Tested on x86_64-linux and aarch64-linux. + +2024-07-16 GDB Administrator + + Automatic date update in version.in + +2024-07-15 Simon Marchi + + gdb: pass program space to overlay_invalidate_all + Make the current program space bubble up one level. + + Change-Id: I5ac1e3290ad266730465cd60aa3672d45ffa6475 + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::make + Make the current program space reference bubble up one level. + + Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::objfile + Make the current program space reference bubble up one level. + + Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address + Make the current program space reference bubble up one level. + + Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address_query + Make the current program space bubble up one level. + + Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfiles_changed + Make the current program space reference bubble up one level. + + Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to get_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to have_{full,partial}_symbols + Make the current program space reference bubble up one level. + + Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: bool-ify a few functions in objfiles.{c,h} + Change return types to bool, and make a few stylistic adjustments. + + Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to clear_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: make `program_space::free_all_objfiles` use `this` + Use `this` instead of `current_program_space`. Presumably, the method + wants to check the solibs of "this" program space, not the current + global program space (although they are likely always the same at the + moment). + + Change-Id: Iaf0534f36bfd47c04c53ed0657da332bdb8fb906 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to no_shared_libraries + Make the current program space reference bubble up one level. Pass + `current_program_space` everywhere, except in some cases where we can + get the pspace another way, and it's relatively obvious that it's the + same as the current program space. + + Change-Id: Id86b79f1e44f92a398f49d137d57457174dfa96d + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: split no_shared_libraries, command vs implementation + The `no_shared_libraries` function is currently used to implement the + `nosharedlibrary` command, but it also used internally by other + functions. This does not make a very good internal API. + + Add the `no_shared_libraries_command` function to implement the CLI + command. Remove the unused parameters from `no_shared_libraries`. + + Remove the `from_tty` parameter of `target_pre_inferior`, since it's now + unused. + + Change-Id: I4fcba5ee1e0f7d250aab1a7b62b9ea16265fe962 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile_purge_solibs + Make the current program space reference bubble up one level. + + Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: use objfile::pspace in objfile::unlink + I think it would make sense to use objfile::pspace instead of the + current program space here. It reduces the risks of calling this + method with the wrong current program space set. + + Change-Id: Id4f3644719f232640c83a1c7f4aa92eaa6af6c5c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: remove some trivial uses of current_program_space + It is obvious that pspace is the same as current_program_space in these + cases, due to the set_current_program_space call just above. The rest + of the functions probably care about the current program space though, + so leave the set_cset_current_program_space calls there. + + Change-Id: I3c300decbf2c2fe5f25aa7f697ebcb524432394f + +2024-07-15 Hannes Domani + + Fix loading a saved recording + Currently you get this assertion failure if you try to execute the + inferior after loading a saved recording, when no recording was done + earlier in the same gdb session: + ``` + $ gdb -q c -ex "record restore test.rec" + Reading symbols from c... + [New LWP 26428] + Core was generated by `/tmp/c'. + Restored records from core file /tmp/test.rec. + (gdb) c + Continuing. + ../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ``` + + The change in step-precsave.exp triggers this bug, since now the + recording is loaded in a new gdb session, where + record_full_resume_ptid was never set. + + The fix is to simply set record_full_resume_ptid when resuming a loaded + recording. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971 + Approved-By: Guinevere Larsen + +2024-07-15 Simon Marchi + + gdb: make objfile::pspace private + Rename to m_pspace, add getter. An objfile's pspace never changes, so + no setter is necessary. + + Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626 + +2024-07-15 Szabolcs Nagy + + aarch64: Fix --no-apply-dynamic-relocs for RELR + The option only makes sense for RELA relative relocs where the + addend is present, not for RELR relative relocs. + + Fixes bug 31924. + +2024-07-15 Nick Clifton + + Synchronize config.[sub|guess] with the latest versions from the config project. + +2024-07-15 GDB Administrator + + Automatic date update in version.in + +2024-07-14 John David Anglin + + hppa: Fix handling of relocations that apply to data + Commit d125f9675372b1ae01ceb1893c06ccb27bc7bf22 introduced a bug + in handling relocations for data. The R_PARISC_DIR32 relocation + operates on 32-bit data and not instructions. The HOWTO table + needs to be used to determine the format of relocations that apply + to data. The R_PARISC_SEGBASE relocation is another special case + as it only changes segment base. + + This was noticed in Debian cmor package build. + + 2024-07-14 John David Anglin + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Use HOWTO table to + determine reload format for relocations that apply to data. + +2024-07-14 GDB Administrator + + Automatic date update in version.in + +2024-07-13 Maciej W. Rozycki + + Revert "MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64" + This reverts commit d49f2dd78b08efa4e1ee51f5df5058846c2eb4fa. It was + applied unapproved. + + Revert "MIPS/GAS: Omit LI 0 for condition trap" + This reverts commit bfa257b407270d1c808b31fbd97da779e0fd20d2. It was + applied unapproved. + +2024-07-13 Lulu Cai + + LoongArch: Fix dwarf3 test cases from XPASS to PASS + In the past, the .align directive generated a label that did not match + the regular expression, and we set it to XFAIL. + But now it matches fine so it becomes XPASS. We fix it with PASS. + +2024-07-13 GDB Administrator + + Automatic date update in version.in + +2024-07-12 Sam James + + libiberty: sync with gcc + This imports the following commits from GCC as of r15-1722-g7682d115402743: + ca2f7c84927f libiberty: Invoke D demangler when --format=auto + 94792057ad4a Fix up duplicated words mostly in comments, part 1 + 20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957]. + 52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen + 53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size + 65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal + +2024-07-12 Jens Remus + + s390: Avoid reloc overflows on undefined weak symbols (cont) + This complements and reuses logic from Andreas Krebbel's commit + 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols"). + + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0 or a + a trapping insn. + + This prevents the PLT32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative + addressing to avoid relocation overflows. + + ld/ + * testsuite/ld-s390/s390.exp: Add new test. + * testsuite/ld-s390/weakundef-2.s: New test. + * testsuite/ld-s390/weakundef-2.dd: Likewise. + + Reported-by: Alexander Gordeev + Suggested-by: Ilya Leoshkevich + Suggested-by: Andreas Krebbel + +2024-07-12 Jens Remus + + s390: Do not replace brcth referencing undefined weak symbol + Branch Relative on Count High (brcth) is a conditional branch relative + instruction. It is not guaranteed that it only appears within loops + that sooner or later will take the branch. It may very well be used to + check a condition that will prevent the branch from ever being taken. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Do not replace brcth + referencing undefined weak symbol with a trap. + + ld/ + * testsuite/ld-s390/weakundef-1.s: Update test case accordingly. + * testsuite/ld-s390/weakundef-1.dd: Likewise. + + Fixes: 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols") + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 zero instructions. + This patch adds support for following sme2.1 zero instructions and + the spec is available here [1]. + + 1. ZERO (single-vector). + 2. ZERO (double-vector). + 3. ZERO (quad-vector). + + The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler + for most of the sme and sve instructions. But for few of the sme2.1 + zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory. + To address this a bit "F_VG_REQ" is introduced in this patch, on setting + F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept + instruction operand only having VECTOR GROUP symbols. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 movaz instructions. + This patch adds support for following sme2.1 movaz instructions and + the spec is available here [1]. + + 1. MOVAZ (array to vector, two registers). + 2. MOVAZ (array to vector, four registers). + 3. MOVAZ (tile to vector, single). + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 luti2 and luti4 instructions. + This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is + available here [1] + + 1. LUTI2 (two registers) strided. + 2. LUTI2 (four registers) strided. + 3. LUTI4 (two registers) strided. + 4. LUTI4 (four registers) strided. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Jan Beulich + + x86: drop unnecessary \() from bundle tests + ':' isn't permitted in macro parameter names, hence this separator + construct isn't necessary at the end of labels. Drop its use in such + cases, for being potentially confusing (and hampering readability, even + if only a little). + +2024-07-12 Jan Beulich + + x86/APX: remove two inconsistencies + As indicated in earlier discussion, permitting GOTTPOFF uniformly for + all legacy non-SIMD insns while at the same time restricting to just + certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns + "equal" to their legacy original ones. Doing that adjustment prevents + another inconsistency, too: In + + data16 neg (%rax) + data16 neg (%r16) + data16 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the data size prefix. + + While there also add the missing CMP and TEST cases to the test case + being modified. + +2024-07-12 Jan Beulich + + x86/APX: correct TEST/CTESTcc with 1st operand being a memory one + While they properly inherited D and C, code processing the reversal of + operands wasn't updated accordingly (and "reversed" operands also + weren't tested anywhere). + +2024-07-12 YunQiang Su + + MIPS/GAS: Omit LI 0 for condition trap + MIPSr6 removes condition trap instructions with imm, so we expand + the instruction like "tne $2,IMM" to + li $at,IMM + tne $2,$at + While if IMM is 0, we can use + tne $2,$zero + only. + +2024-07-12 YunQiang Su + + MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64 + the ABI section of the triple explicitly asks for N64, + and in fact GCC also does so. + + It can fix the test failure: + FAIL: libdep test: did not get expected output from the linker + with Debian's mipsisa64r6el-linux-gnuabi64 toolchain. + +2024-07-12 Matthieu Longo + + aarch64: disable feature b16b16 + Feature b16b16 is currently incomplete and requires re-work. + + Disable the command line option for b16b16, and mark the associated + tests as XFAIL. + +2024-07-12 Vladimir Mezentsev + + gprofng: add release notes for 2.43 + ChangeLog + 2024-07-10 Vladimir Mezentsev . + + * binutils/NEWS (gprofng): Add release notes for 2.43 + +2024-07-12 Alan Modra + + Re: base64: Add support for targets with byte size > octet size. + Three extra octets are now expected with the latest change to base64.s. + They happened to be covered by patterns allowing for zero padding at + the end of the section, but we don't want to allow fewer octets than + expected. + + PR 31964 + * testsuite/gas/all/base64.d: Adjust. + +2024-07-12 GDB Administrator + + Automatic date update in version.in + +2024-07-11 Nick Clifton + + base64: Add support for targets with byte size > octet size. + PR 31964 + +2024-07-11 Jan Beulich + + gas: don't open-code IS_WHITESPACE() / IS_NEWLINE() + Better be consistent in use of the wrapper macros, which imo also helps + readability. + +2024-07-11 Jan Beulich + + gas: multi-byte warning adjustments + First input_scrub_next_buffer()'s invocation was wrong, leading to input + only being checked from the last newline till the end of the current + buffer. Correcting the invocation, however, leads to duplicate checking + unless -f (or the #NO_APP equivalent thereof) is in effect. Move the + invocation to input_file_give_next_buffer(), to restrict it accordingly. + + Then, when macros contain multi-byte characters, warning about them + again in every expansion isn't useful. Suppress such warnings from + sb_scrub_and_add_sb(). + +2024-07-11 Jan Beulich + + gas: there's no scrubber state 12 + Apparently (beyond what's [easily] visible in git history) when this was + added there was confusion about scrubber states vs lex[] contents. For + the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve + to 12) alone is sufficient. "state" is never set to 12, and it being 12 + also isn't handled anywhere. + +2024-07-11 Kévin Le Gouguec + + gdb: add testcase for invalid record display + More of a DWARF-generation non-regression test; fixed on the GCC side + with 2024-06-03 "Implement wrap-around arithmetics in DWARF + expressions" (f3d6d60d2ae). + + Approved-By: Tom Tromey + +2024-07-11 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Update gas/NEWS for Intel APX. + +2024-07-11 Tsukasa OI + + RISC-V: Add platform property/capability extensions + RISC-V Profiles document defines number of "extensions" that indicate + certain platform properties/capabilities just like 'Zkt' extension from the + RISC-V cryptography extensions. + + This commit defines 20 platform property/capability extensions as defined + in the RISC-V Profiles documentation. + + The only exception: 'Ssstateen' extension is defined separately because it + defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension. + + This is based on the ratified version of RISC-V Profiles: + + + [Definition] + + "Main memory regions": + Main memory regions (in contrast to I/O or vacant memory regions) with + both the cacheability and coherence PMAs. + + [New Unprivileged Extensions] + + 1. 'Ziccif' + "Main memory regions" support instruction fetch and any instruction + fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN) + are atomic. + 2. 'Ziccrse' + "Main memory regions" provide the eventual success guarantee for + LR/SC sequence (RsrvEventual). + 3. 'Ziccamoa' + "Main memory regions" support all currently-defined AMO operations + including swap, logical and arithmetic operations (AMOArithmetic). + 4. 'Za64rs' + For LR/SC instructions, reservation sets are contiguous, naturally + aligned and at most 64-bytes in size. + 5. 'Za128rs' + Likewise, but reservation sets are at most 128-bytes in size. + 6. 'Zicclsm' + Misaligned loads / stores to "main memory regions" are supported. + Those include both regular scalar and vector accesses but does not + include AMOs and other specialized forms of memory accesses. + 7. 'Zic64b' + Cache blocks are (exactly) 64-bytes in size and naturally aligned. + + [New Privileged Extensions] + + 1. 'Svbare' + "satp" mode Bare is supported. + 2. 'Svade' + Page-fault exceptions are raised when a page is accessed when A bit is + clear, or written when D bit is clear. + 3. 'Ssccptr' + "Main memory regions" support hardware page-table reads. + 4. 'Sstvecd' + "stvec" mode Direct is supported. When "stvec" mode is Direct, + "stvec.BASE" is capable of holding any valid 4-byte aligned address. + 5. 'Sstvala' + "stval" is always written with a nonzero value whenever possible as + specified in the Privileged Architecture documentation + (version 20211203: see section 4.1.9). + 6. 'Sscounterenw' + For any "hpmcounter" that is not read-only zero, the corresponding bit + in "scounteren" is writable. + 7. 'Ssu64xl' + "sstatus.UXL" is capable of holding the value 0b10 + (UXLEN==64 is supported). + 8. 'Shcounterenw' + Similar to 'Sscounterenw' but the same rule applies to "hcounteren". + 9. 'Shvstvala' + Similar to 'Sstvala' but the same rule applies to "vstval". + 10. 'Shtvala' + "htval" is written with the faulting guest physical address as long as + permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala'). + 11. 'Shvstvecd' + Similar to 'Sstvecd' but the same rule applies to "vstvec". + 12. 'Shvsatpa' + All translation modes supported in "satp" are also supported in "vsatp". + 13. 'Shgatpa' + For each supported virtual memory scheme SvNN supported in "satp", the + corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare + is also supported. + + [Implications] + + (Due to reservation set size constraints) + - 'Za64rs' -> 'Za128rs' + + (Due to the fact that a privileged "extension" directly refers a CSR) + - 'Svbare' -> 'Zicsr' + - 'Sstvecd' -> 'Zicsr' + - 'Sstvala' -> 'Zicsr' + - 'Sscounterenw' -> 'Zicsr' + - 'Ssu64xl' -> 'Zicsr' + + (Due to the fact that a privileged "extension" indirectly depends on CSRs) + - 'Svade' -> 'Zicsr' + + (Due to the fact that a privileged "extension" is a hypervisor property) + - 'Shcounterenw' -> 'H' + - 'Shvstvala' -> 'H' + - 'Shtvala' -> 'H' + - 'Shvstvecd' -> 'H' + - 'Shvsatpa' -> 'H' + - 'Shgatpa' -> 'H' + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Updated for property + and capability extensions. + (riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm, + ziccrse, za64rs and za128rs extensions. + (riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala, + shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala, + sstvecd, ssu64xlm svade and svbare extensions. + gas/ + * testsuite/gas/riscv/imply.d: Updated for property and capability + extensions. + * testsuite/gas/riscv/imply.s: Likewise. + * testsuite/gas/riscv/march-help.l: Likewse. + +2024-07-11 Alan Modra + + Re: Add support for a .base64 pseudo-op to gas + Fixes a failure on rx-elf where the standard data section isn't .data. + run_dump_test has machinery to translate .data in both options and + expected results for objdump, but not for readelf -x. + + PR 31964 + * testsuite/gas/all/base64.d: Dump .data with objdump. Run on + all targets. + +2024-07-11 Jinyang He + + LoongArch: Not alloc dynamic relocs if symbol is absolute + The absolute symbol should be resolved to const when link to dso or exe. + Alloc dynamic relocs will cause extra space and R_LARCH_NONE finally. + +2024-07-11 GDB Administrator + + Automatic date update in version.in + +2024-07-11 H.J. Lu + + x86-64: Skip -z mark-plt tests on MUSL + Skip -z mark-plt tests, which are specific to glibc, on MUSL. + + PR ld/31970 + * ld/testsuite/ld-x86-64/x86-64.exp: Skip -z mark-plt tests on + MUSL. + +2024-07-10 Yixuan Chen + + RISC-V:[gprofng] Minimal support gprofng for riscv. + ChangeLog: Add target riscv to --enable-gprofng. + + 2024-07-04 Yixuan Chen + + * configure: Add riscv. + * configure.ac: Add riscv. + + gprofng/ChangeLog: Minimal support gprofng for riscv. + + 2024-07-04 Yixuan Chen + + * gprofng/common/core_pcbe.c (core_pcbe_init): Add RISC-V vendor conditon. + (defined): Add riscv. + * gprofng/common/cpuid.c (defined): Add risc-v hwprobe. + * gprofng/common/gp-defs.h (TOK_A_RISCV): Add riscv. + (defined): Add riscv. + (ARCH_RISCV): Add riscv. + * gprofng/common/hwc_cpus.h: Add RISC-V vendor. + * gprofng/common/hwcfuncs.h (HW_INTERVAL_TYPE): Remove useless defination. + * gprofng/configure: Add riscv. + * gprofng/configure.ac: Add riscv. + * gprofng/libcollector/hwprofile.h (ARCH): Add RISC-V register. + (CONTEXT_PC): Add RISC-V register. + (CONTEXT_FP): Add RISC-V register. + (CONTEXT_SP): Add RISC-V register. + (SETFUNCTIONCONTEXT): + * gprofng/libcollector/libcol_util.c (__collector_util_init): Fix libc open condition. + * gprofng/libcollector/libcol_util.h (ARCH): Add RISC-V. + * gprofng/libcollector/unwind.c (ARCH): Add RISC-V register. + (GET_PC): Add RISC-V register. + (GET_SP): Add RISC-V register. + (GET_FP): Add RISC-V register. + (FILL_CONTEXT): + * gprofng/src/DbeSession.cc (ARCH): Add RISC-V. + * gprofng/src/Disasm.cc (Disasm::disasm_open): Add RISC-V. + * gprofng/src/Experiment.cc (Experiment::ExperimentHandler::startElement): Add RISC-V. + * gprofng/src/checks.cc (ARCH): Add RISC-V. + * gprofng/src/collctrl.cc (defined): Set risc-v cpu frequency to 1000MHz as default for now, will fix when I find a better method to get cpu frequency. + (read_cpuinfo): Add "mvendorid" condition according to risc-v /proc/cpuinfo file content. + * gprofng/src/dbe_types.h (enum Platform_t): Add RISC-V. + +2024-07-10 Nick Clifton + + Add support for a .base64 pseudo-op to gas + PR 31964 + +2024-07-10 Clément Chigot + + libsframe: remove runstatedir in Makefile.in + The regeneration was made with Ubuntu automake which has this runstatedir + additional variable, compared to the usual automake. + + libsframe: accept --target configure option + Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was + ignored. This could prevent libsframe.a to be installed in some cases, + the host fetching its canonical value while the target isn't. Both + having a different value, INSTALL_LIBBFD would be false. + +2024-07-10 GDB Administrator + + Automatic date update in version.in + +2024-07-09 H.J. Lu + + elf: Add glibc version dependency only if needed + There is no need to add a needed glibc version if the glibc base version + includes the needed glibc version. + + PR ld/31966 + * elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base. + Skip if the glibc base version includes the needed glibc version. + (_bfd_elf_link_add_glibc_version_dependency): Initialize + glibc_minor_base to INT_MAX and pass it to + elf_link_add_glibc_verneed. + +2024-07-09 Vladimir Mezentsev + + gprofng: add hardware counters for Intel Ice Lake processor + gprofng/ChangeLog + 2024-07-07 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Intel Ice Lake processor. + * common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel. + Set config1 in perf_event_attr. Remove the use of memset. + * common/core_pcbe.c (core_pcbe_get_eventnum): Return 0. + * common/hwcentry.h: Add config1. + * src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1. + * common/hwcfuncs.c (process_data_descriptor): Set config1. + * common/hwctable.c: Add the hwc table for Intel Ice Lake processor. + * src/hwc_intel_icelake.h: New file. + +2024-07-09 Indu Bhagat + + doc: sframe: add appendix for generating stack traces + Add an appendix to provide a rough outline to show how to generate stack + traces using the SFrame format. Such content should hopefully aid the + reader assimmilate the information in the specification. + + libsframe/ + * doc/sframe-spec.texi: Add new appendix. + +2024-07-09 Indu Bhagat + + include: sframe: update code comments around SFrame FRE stack offsets + This also amends the incorrect comment: + offset3 (intrepreted as FP = CFA + offset2) + + If RA tracking is enabled, the offset to recover FP is at the third + index. The SFrame format (V2) has assumption that if FP is saved on + stack, RA must have been saved as well. This is true for the currently + supported arch Aarch64. For AMD64, RA tracking per SFrame FRE is not + necessary. + + In future, when extending support for more architectures, this will + likely need to be revisited. + + include/ + * sframe.h: Make the comments clearer by enumerating what + happens per-ABI. + +2024-07-09 Indu Bhagat + + doc: sframe: segregate the ABI/arch-specific components + The recipe to interpret the SFrame FRE stack offsets is + ABI/arch-specific. + + Although, there is other information in the specification that is + ABI-specific (like pauth_key usage in AArch64), those pieces of + information are now assimmilated in the SFrame specification in a way + that it is fairly difficult to carve then out into a ABI/arch-specific + section without confusing the readers. + + For future though, the specification must strive to keep the generic + parts and ABI/arch-specific parts clearly laid out in separate sections. + + libsframe/ + * doc/sframe-spec.texi: Reorder and adapt the contents. + +2024-07-09 H.J. Lu + + LTO: Properly check wrapper symbol + Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper + symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO. + + Note: Calling unwrap_hash_lookup to check for the wrapper symbol works + only when there is a definition for the wrapped symbol since references + to the wrapped symbol have been redirected to the wrapper symbol. + + bfd/ + + PR ld/31956 + * linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol + for wrapper symbol. + + include/ + + PR ld/31956 + * bfdlink.h (bfd_link_hash_entry): Add wrapper_symbol. + + ld/ + + PR ld/31956 + * plugin.c (get_symbols): Set wrap_status to wrapper if + wrapper_symbol is set. + * testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests. + * testsuite/ld-plugin/pr31956a.c: New file. + * testsuite/ld-plugin/pr31956b.c: Likewise. + +2024-07-09 GDB Administrator + + Automatic date update in version.in + +2024-07-08 srinath + + aarch64: Add support for sve2p1 pmov instruction. + This patch adds support for followign SVE2p1 instruction, spec is available here [1]. + + 1. PMOV (to vector) + 2. PMOV (to predicate) + + Both pmov (to vector) and pmov (to predicate) have destination scalable vector + register and source scalable vector register respectively as an operand with no + suffix and optional index. To handle this case we have added 8 new operands in + this patch. + + AARCH64_OPND_SVE_Zn0_INDEX, /* Zn[index], bits [9:5]. */ + AARCH64_OPND_SVE_Zn1_17_INDEX, /* Zn[index], bits [9:5,17]. */ + AARCH64_OPND_SVE_Zn2_18_INDEX, /* Zn[index], bits [9:5,18:17]. */ + AARCH64_OPND_SVE_Zn3_22_INDEX, /* Zn[index], bits [9:5,18:17,22]. */ + AARCH64_OPND_SVE_Zd0_INDEX, /* Zn[index], bits [4:0]. */ + AARCH64_OPND_SVE_Zd1_17_INDEX, /* Zn[index], bits [4:0,17]. */ + AARCH64_OPND_SVE_Zd2_18_INDEX, /* Zn[index], bits [4:0,18:17]. */ + AARCH64_OPND_SVE_Zd3_22_INDEX, /* Zn[index], bits [4:0,18:17,22]. */ + + Since the index of the operand is optional, the index part is + dropped in disassembly in both the cases of "no index" or "zero index". + + As per spec: PMOV {[]}, .D + PMOV .D, {[]} + + Example1: + Assembly: pmov z5[0], p6.d + Disassembly: pmov z5, p6.d + + Assembly: pmov z5, p6.d + Disassembly: pmov z5, p6.d + + Example2: + Assembly: pmov p4.b, z5[0] + Disassembly: pmov p4.b, z5 + + Assembly: pmov p4.b, z5 + Disassembly: pmov p4.b, z5 + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 Srinath Parvathaneni + + aarch64: Add support for sve2p1 tbxq instruction. + This patch adds support for SVE2p1 "tbxq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 zipq[1-2] instructions. + This patch adds support for SVE2p1 "zipq1" and "zipq2" instructions, spec is + available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 uzpq[1-2] instructions. + This patch adds support for SVE2p1 "uzpq1" and "uzpq2" instructions, spec is + available here [1] + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 tblq instruction. + This patch adds support for SVE2p1 "tblq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 orqv instruction. + This patch adds support for SVE2p1 "orqv" instruction, spec available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 GDB Administrator + + Automatic date update in version.in + +2024-07-07 GDB Administrator + + Automatic date update in version.in + +2024-07-06 Alan Modra + + Re: LoongArch: Add DT_RELR support + Fix commit d89ecf33ab testsuite breakage. + + * testsuite/lib/binutils-common.exp (supports_dt_relr): Correct. + +2024-07-06 Alan Modra + + objcopy bfd_map_over_sections and global status + This patch started life as a relatively simple change to fix some + unimportant objcopy memory leaks, but expanded into a larger patch + when I was annoyed by the awkwardness of passing data when using + bfd_map_over_sections. A simple loop over sections is much more + convenient, and we really don't need the abstraction layer. Sections + in a list isn't going to disappear any time soon. + + The patch also removes use of the global "status" variable by all but + the top-level functions called from main. + + * objcopy.c (filter_symbols): Return success as a bool. Pass + symcount as a pointer, updated on return. + (merge_gnu_build_notes): Similarly return a bool and add newsize + param with updated smaller section size. + (setup_bfd_headers): Return bool success rather than setting + "status" on failure. + (setup_section): Likewise. + (copy_relocations_in_section, copy_section): Likewise, and adjust + params. + (mark_symbols_used_in_relocations): Likewise, and free memory + on failure path. Don't call bfd_fatal. + (get_sections): Delete function. + (copy_object): Don't use bfd_map_over_sections, instead use a + loop allowing easy detection of failure status. Free memory on + error paths. + (copy_archive): Return bool success rather than setting "status" + on failure. + (copy_file): Set "status" here. + * testsuite/binutils-all/strip-13.d: Adjust to suit. + +2024-07-06 GDB Administrator + + Automatic date update in version.in + +2024-07-05 Matthieu Longo + + aarch64: add Debug Feature Register 2 (ID_AA64DFR2_EL1) + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add STEP2 feature and its associated registers + AArch64 defines new registers for the feature step2 (Enhanced Software Step + Extension). step2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add SPMU2 feature and its associated registers + AArch64 defines new registers for the feature spmu2 (System Performance + Monitors Extension version 2). spmu2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add E3DSE feature and its associated registers + AArch64 defines new registers for the feature e3dse (Delegated SError + exceptions for EL3): vdisr_el3 and vdisr_el3. e3dse is an Armv9.5-A + feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Lingling Kong + + x86-64: Fix support for APX NF TLS IE with 2 operands + Added the restriction in assemble for APX TLS IE that the destination + can only be a register. + + gas/ + + * config/tc-i386.c (md_assemble): Added stricter restrictions + for APX TLS IE. + +2024-07-05 Jan Beulich + + RISC-V: avoid use of match_opcode() in riscv_insn_types[] + As of 27b33966b18e ("RISC-V: disallow x0 with certain macro-insns") the + .match_func field may be NULL for entries used for assembly only, which + is the case for the entire table. With .match and .mask both zero the + function would only ever succeed anyway. Save almost a hundred base + relocations in the final executable by using NULL instead. + + aarch64: fix build with old glibc + As was pointed out several times before, old glibc declares index(), + resulting in warnings from -Wshadow, in turn failing the build due to + -Werror. + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR tests + Most tests are ported from AArch64. + + The relr-addend test is added to make sure the addend (link-time address) + is correctly written into the relocated section. Doing so is not + strictly needed for RELA, but strictly needed for RELR). + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR support + The logic is same as a71d87680110 ("aarch64: Add DT_RELR support"). + + As LoongArch does not have -z dynamic-undefined-weak, we don't need to + consider UNDEFWEAK_NO_DYNAMIC_RELOC. + + The linker relaxation adds another layer of complexity. When we delete + bytes in a section during relaxation, we need to fix up the offset in + the to-be-packed relative relocations against this section. + +2024-07-05 Xi Ruoyao + + LoongArch: Make protected function symbols local for -shared + On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols + as preemptible. See the comment above LARCH_REF_LOCAL for detailed + explanation. + +2024-07-05 Xi Ruoyao + + LoongArch: Fix bad reloc with mixed visibility ifunc symbols in shared libraries + With a simple test case: + + .globl ifunc + .globl ifunc_hidden + .hidden ifunc_hidden + .type ifunc, %gnu_indirect_function + .type ifunc_hidden, %gnu_indirect_function + + .text + .align 2 + ifunc: ret + ifunc_hidden: ret + + test: + bl ifunc + bl ifunc_hidden + + "ld -shared" produces a shared object with one R_LARCH_NONE (instead of + R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc". + It's because the indices in .plt and .rela.plt mismatches for + STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a + STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of + loongarch_elf_finish_dynamic_symbol. Fix the issue by reordering .plt + so the indices no longer mismatch. + +2024-07-05 Xi Ruoyao + + LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64 + We were converting R_LARCH_32 to R_LARCH_RELATIVE for ELFCLASS64: + + $ cat t.s + .data + x: + .4byte x + .4byte 0xdeadbeef + $ as/as-new t.s -o t.o + $ ld/ld-new -shared t.o + $ objdump -R + a.out: file format elf64-loongarch + + DYNAMIC RELOCATION RECORDS + OFFSET TYPE VALUE + 00000000000001a8 R_LARCH_RELATIVE *ABS*+0x00000000000001a8 + + But this is just wrong: at runtime the dynamic linker will run + *(uintptr *)&x += load_address, clobbering the next 4 bytes of data + ("0xdeadbeef" in the example). + + If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected + by the Glibc dynamic linker anyway. And it does not make too much sense + to modify Glibc to support it. So we can just reject it like x86_64: + + relocation R_X86_64_32 against `.data' can not be used when making a + shared object; recompile with -fPIC + + or RISC-V: + + relocation R_RISCV_32 against non-absolute symbol `a local symbol' + can not be used in RV64 when making a shared object + +2024-07-05 Cui, Lili + + x86: Correct position of ".s" for CCMPcc in disassembler + Added new macro %SW to CCMPcc to print ".s" after the mnemonic. + + Before: + ccmpbl {dfv=}.s %edx,%eax + + After: + ccmpbl.s {dfv=} %edx,%eax + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-pseudos-apx.d: Add tests for CCMPcc. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %SW for CCMPcc swap operands. + * i386-dis.c (struct dis386): Added %SW. + (putop): Handle %SW. + +2024-07-05 Cui, Lili + + x86: Add {load}/{store} tests for apx instructions. + gas/ChangeLog: + + * testsuite/gas/i386/x86-64.exp: Add {load}/{store} tests for apx + instructions. + * testsuite/gas/i386/x86-64-pseudos-apx.d: New test. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + +2024-07-05 GDB Administrator + + Automatic date update in version.in + +2024-07-04 Sun Sunny + + RISC-V: Fix BFD_RELOC_RISCV_PCREL_LO12_S patch issue + In commit dff565fcca8137954d6ad571ef39f6aec5c0429c, the fixups + for PCREL_LO12_I and PCREL_LO12_S were mixed, so the "IMM" + field were applied to incorrect position, this caused incorrect + src registers to be encoded. + + gas/ + * config/tc-riscv.c (md_apply_fix): Fix PCREL_LO12_S issue. + * testsuite/gas/riscv/ixup-local.s: Updated for PCREL_LO12_S cases. + * testsuite/gas/riscv/fixup-local-relax.d: Likewise. + * testsuite/gas/riscv/fixup-local-norelax.d: Likewise. + +2024-07-04 Lifang Xia + + RISC-V: hash with segment id and pcrel_hi address while recording pcrel_hi + When the same address across different segments (sections) needs to be + recorded, it will overwrite the slot, leading to a memory leak. To ensure + uniqueness, the segment (section) ID needs to be included in the hash key + calculation. + + gas/ + * config/tc-riscv.c (riscv_pcrel_hi_fixup): New "const asection *sec". + (riscv_pcrel_fixup_hash): make sec->id and e->adrsess as the + hash key. + (riscv_pcrel_fixup_eq): Check sec->id at first. + (riscv_record_pcrel_fixup): New member "sec". + (md_apply_fix) : Likewise. + (md_apply_fix) : Likewise. + +2024-07-04 Andre Vieira + + mve: Fix encoding for vcvt[bt] single-half float conversion instructions + The encoding was previously not taking into account that the Quad vector + registers were being encoded using their Q-register numbers rather than their + D-register equivalent (multiply by 2). + + gas/ + + * config/tc-arm.c (do_neon_cvttb_1): Use Q-register vector number + rather than their D-register equivalent. + + gas/testsuite/ + + * gas/arm/mve-vcvt-3.d: Correct expected values in test. + +2024-07-04 Jens Remus + + gas: Validate SFrame RA tracking and fixed RA offset + Verify all architectures participating in SFrame generation do define + the mandatory SFrame return address (RA) tracking predicate function + sframe_ra_tracking_p. Do so by explicitly not testing for the macro + SFRAME_FRE_RA_TRACKING as otherwise required. + + Verify that architectures not using SFrame RA tracking specify a valid + fixed RA offset. + + gas/ + * gen-sframe.c (output_sframe_internal): Validate SFrame + RA tracking and fixed RA offset. + +2024-07-04 Jens Remus + + gas: Test predicate whether SFrame RA tracking is used + The existence of the macro SFRAME_FRE_RA_TRACKING only ensures the + existence of the macro SFRAME_CFA_RA_REG and the predicate function + sframe_ra_tracking_p. It does not indicate whether SFrame RA tracking + is actually used. + + Test the return value of the SFrame RA tracking predicate function + sframe_ra_tracking_p to determine whether RA tracking is used. + + This aligns the logic in functions get_fre_num_offsets and + output_sframe_row_entry to the one used in all other places. + + gas/ + * gen-sframe.c (get_fre_num_offsets, output_sframe_row_entry): + Test predicate to determine whether SFrame RA tracking is used. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies SP register + Neither ".cfi_offset SP, ", ".cfi_register SP, ", nor + ".cfi_val_offset SP, " alter the tracking information to recover + the stack pointer (SP). Doing so would need an explicit .cfi_def_cfa, + which SFrame tracks. + + The stack pointer (SP) register contents on entry can be reconstructed + from the SFrame CFA tracking information using information from the + current and initial SFrame FREs of the SFrame FDE: + + 1. Compute CFA from the current CFA base register (SP or FP) and CFA + offset from the SFrame CFA tracking information from the SFrame FRE + for the current instruction address: + + CFA = + + + 2. Compute SP from the current CFA and the CFA offset from the SFrame + CFA tracking information from the initial SFrame FRE of the FDE: + + SP = CFA - + + While at it add comments to the processing of .cfi_offset and + .cfi_val_offset that the SP can be reconstructed from the CFA tracking + information. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies SP register. + (sframe_xlate_do_offset,sframe_xlate_do_val_offset): Add comment + that this is likewise. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking + Do not skip SFrame FDE if .cfi_register specifies RA register without + RA tracking being actually used. Without RA tracking the register + contents can always be restored from the stack using the fixed + RA offset from CFA. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies RA register without RA tracking + being used. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if .cfi_window_save + CFI opcode DW_CFA_AARCH64_negate_ra_state is multiplexed with + DW_CFA_GNU_window_save. Process DW_CFA_AARCH64_negate_ra_state on + AArch64. Skip generation of SFrame FDE otherwise with the following + warning message: + + skipping SFrame FDE; .cfi_window_save + + gas/ + * gen-sframe.c: Skip SFrame FDE if .cfi_window_save. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if FP without RA on stack + The SFrame format cannot represent the frame pointer (FP) being saved + on the stack without the return address (RA) also being saved on the + stack, if RA tracking is used. + + A SFrame FDE is followed by 1-3 offsets with the following information: + + Without RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the frame pointer (FP) + + With RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the return address (RA) + 3. Optional: Offset to CFA to restore the frame pointer (FP) + + When RA tracking is used and a FDE is followed by two offsets the + SFrame format does not provide any information to distinguish whether + the second offset is the RA or FP offset. SFrame assumes the offset to + be the RA offset, which may be wrong. + + Therefore skip generation of SFrame FDE information and print the + following warning, if RA tracking is used and the FP is saved on the + stack without the RA being saved as well: + + skipping SFrame FDE; FP without RA on stack + + gas/ + * gen-sframe.c (sframe_do_fde): Skip SFrame FDE if FP without RA + on stack, as the SFrame format cannot represent this case. + +2024-07-04 Jens Remus + + gas: User readable warnings if SFrame FDE is not generated + The following generic warning message, which is printed whenever the + assembler skips generation of SFrame FDE, is not very helpful for the + user: + + skipping SFrame FDE; CFI insn (0x) + + Whenever possible print meaningful warning messages, when the assembler + skips generation of SFrame FDE: + + - skipping SFrame FDE; non-SP/FP register in .cfi_def_cfa + - skipping SFrame FDE; non-SP/FP register in + .cfi_def_cfa_register + - skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register + in effect + - skipping SFrame FDE; {FP|RA} register in .cfi_val_offset + - skipping SFrame FDE; {SP|FP|RA} register in in .cfi_register + - skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE + state + - skipping SFrame FDE; non-default RA register + + gas/ + * gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): New macro for + invalid SFrame FRE CFA base register value of -1. + * gen-sframe.c: User readable warnings if SFrame FDE is not + generated. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update generic SFrame test + case to updated warning message texts. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + +2024-07-04 Jens Remus + + gas: Refactor SFrame CFI opcode DW_CFA_register processing + Refactor SFrame processing of CFI opcode DW_CFA_register into a separate + function. This harmonizes the CFI opcode processing. + + While at it reword the comment on CFI opcodes that are not processed. + + This is a purely mechanical change. + + gas/ + * gen-sframe.c (sframe_do_cfi_insn, sframe_xlate_do_register): + Refactor SFrame CFI opcode DW_CFA_register processing. + +2024-07-04 Jens Remus + + gas: Warn if SFrame FDE is skipped due to non-default return column + Print a warning message if SFrame FDE is skipped due to a non-default + DWARF return column (i.e. return address (RA) register number). This + may be caused by the use of CFI directive .cfi_return_column with a + non-default return address (RA) register number in the processed + assembler source code. + + Warning: skipping SFrame FDE due to non-default DWARF return column + + gas/ + * gen-sframe.c: Warn if SFrame FDE is skipped due to non-default + DWARF return column. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-3.d: Update test case to expect + for new warning message when SFrame FDE is skipped due to + a non-default DWARF return column. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if CFI specifies non-FP/SP base register + Do not generate SFrame FDE if DWARF CFI directives .cfi_def_cfa or + .cfi_def_cfa_register specify a CFA base register number other than + the architecture-specific stack-pointer (SP) or frame-pointer (FP) + register numbers. + + This also causes the assembler to print a warning message, so that + skipping of the SFrame FDE does not occur silently. + + Update the generic ld SFrame test case to be architecture independent. + Do not use CFI directive .cfi_def_cfa, as the specified CFA base + register number is not a valid SP/FP register number on all + architectures. An invalid SP/FP register number will now cause the + assembler to print a warning message and skip SFrame FDE generation. + Remove the offending CFI directive, that cannot be coded architecture- + independent, as the test case requires SFrame information to be + generated. This was reported by the Linaro-TCWG-CI for AArch64. + + gas/ + * gen-sframe.c: Skip SFrame generation if CFI specifies + non-FP/SP base register. + + ld/testsuite/ + * ld-sframe/discard.s: Update generic SFrame test case to be + architecture independent. + +2024-07-04 Jens Remus + + gas: Print DWARF call frame insn name in SFrame warning message + SFrame generation prints the DWARF call frame instruction opcode in + hexadecimal. Leverage get_DW_CFA_name to additionally print the + DWARF call frame instruction name in human readable form, while also + respecting fake CFI types. Use "(unknown)", if the DWARF call frame + instruction name is not known. + + While at it use the terminology "instruction" for these DW_CFA_*, as + suggested by Indu. + + This changes the following assembler SFrame generation warning message + as follows: + + Old: + Warning: skipping SFrame FDE due to DWARF CFI op 0x + + New: + Warning: skipping SFrame FDE; CFI insn (0x) + + gas/ + * gen-sframe.c (sframe_get_cfi_name): New function to get the + DWARF call frame instruction name for a DWARF call frame + instruction opcode. + (sframe_do_cfi_insn): Use sframe_get_cfi_name to print the + DWARF call frame instruction name for the DWARF call frame + instruction opcode in the warning message. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update expected SFrame + warning message text for DWARF call frame insn name. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Display SFrame fixed RA offset as 'f' in dump + For the SFrame FRE frame-pointer (FP) offset from CFA a 'u' is displayed + if it is unavailable. + + For the SFrame FRE return-address (RA) offset from CFA a 'u' was + displayed if the ABI uses a fixed RA offset from CFA. By chance a + 'u' was also displayed if the RA offset is unavailable, as the string + buffer was not initialized after formatting the FP offset. Note that it + could not occur that the FP offset was erroneously displayed as RA + offset, as the SFrame format cannot have a FRE with FP offset without + RA offset. + + For the FRE RA offset display 'f' if the ABI uses a fixed RA offset + from CFA. Display a 'u' if it is unavailable. + + libsframe/ + * sframe-dump.c: Display SFrame fixed RA offset as 'f' in dump. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-4.d: Test for RA displayed + either as 'u' (if RA tracking) or as 'f' (fixed RA offset if no + RA tracking). + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for RA displayed + as 'f' (fixed RA offset), as x86-64 does not use RA tracking. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for RA displayed as 'f' (fixed + RA offset), as x86-64 does not use RA tracking. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Dump SFrame CFA fixed FP and RA offsets + The SFrame format allows architectures to specify fixed offsets from the + CFA, if any, from which the frame pointer (FP) and/or return address + (RA) may be recovered. These offsets are stored in the SFrame header. + + For instance the SFrame generation in the assembler for x86 AMD64 + specifies a fixed offset from the CFA, from which the return address + (RA) may be recovered. + + When dumping the SFrame header, for instance in readelf/objdump with + option --sframe, do also dump the specified fixed offsets from the CFA, + if any, from which the frame pointer (FP) and return address (RA) may + be recovered. + + Update the common SFrame test case verification patterns to allow for + the optional dumping of the CFA fixed FP/RA offsets. Update the x86- + specific SFrame and SCFI test case verification patterns to require a + CFA fixed RA offset of -8. + + libsframe/ + * sframe-dump.c: Dump CFA fixed FP and RA offsets. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for fixed + RA offset. + * gas/cfi-sframe/common-empty-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Test for SFrame fixed + RA offset. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for SFrame fixed RA offset. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + gas: Enhance arch-specific SFrame configuration descriptions + Explicitly mention "SFrame" in the descriptions for the architecture- + specific SFrame configuration macros, variables, and functions. + + Use the term "frame pointer" (FP) instead of "base pointer". This aligns + with the terminology used in the SFrame specification. Additionally it + helps not to confuse "base-pointer register" with the term "BASE_REG" + used in the specification to denote either the SP or FP register. + + Specify what the SFRAME_CFA_*_REG register numbers are used for: + - SP (stack pointer): CFA tracking + - FP (frame pointer): CFA and FP tracking + - RA (return address): RA tracking + + Align the descriptions for definitions in the source files to the + declarations in the header files. + + gas/ + * config/tc-aarch64.h: Enhance architecture-specific SFrame + configuration descriptions. + * config/tc-aarch64.c: Likewise. + * config/tc-i386.h: Likewise. + * config/tc-i386.c: Likewise. + +2024-07-04 Jens Remus + + x86: Remove unused SFrame CFI RA register variable + gas/ + * config/tc-i386.c (x86_sframe_cfa_ra_reg): Remove. + +2024-07-04 Cui, Lili + + Support APX CFCMOV + The CMOVcc instruction proposed by EVEX has four different forms, + corresponding to the four possible combinations of EVEX.ND and EVEX.NF + values. + + In the encoder part, when the CFCMOV template supports EVEX_NF, it means that + it requires EVEX.NF to be 1. + + In the decoder part, CFCMOV_Fixup is used to reverse source and destination + operands in the 2-operand case. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Set NF bit for cfcmov + when the insn template supports EVEX_NF. + * testsuite/gas/i386/x86-64-apx-inval.l: Add invalid tests for cfcmov. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add tests for cfcmov and cmov. + * testsuite/gas/i386/x86-64-apx-cfcmov-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add cfcmov instructions. + * i386-dis.c (CFCMOV_Fixup): Special handling of cfcmov. + (putop): Print 'cf' for cfcmov instructions. + * i386-opc.h (EVEX_NF): New. + * i386-opc.tbl: Add cfcmov instructions. + * i386-mnem.h: Regerated. + * i386-tbl.h: Regerated. + +2024-07-04 GDB Administrator + + Automatic date update in version.in + +2024-07-03 Nelson Chu + + RISC-V: Tidy and complete testing of all architecture imply rules. + gas/ + * testsuite/gas/riscv/imply.s: New testcase for all imply cases. + * testsuite/gas/riscv/imply.d: Likewise. + * testsuite/gas/riscv/march-imply-i.s: Renamed to + imply-zicsr-zifencei.s. + * testsuite/gas/riscv/march-imply-i2p0-02.d: Renamed to + imply-zicsr-zifencei-i2p0-misa-spec-2p2.d. + * testsuite/gas/riscv/march-imply-i2p1-01.d/l: Renamed to + imply-zicsr-zifencei-i2p1-misa-spec-20191213.d. + * testsuite/gas/riscv/march-imply-i2p0-01.d: Removed. + Combined into new imply testcase. + * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise. + * testsuite/gas/riscv/march-imply-a.d: Likewise. + * testsuite/gas/riscv/march-imply-b.d: Likewise. + * testsuite/gas/riscv/march-imply-f.d: Likewise. + * testsuite/gas/riscv/march-imply-g.d: Likewise. + * testsuite/gas/riscv/march-imply-h.d: Likewise. + * testsuite/gas/riscv/march-imply-q.d: Likewise. + * testsuite/gas/riscv/march-imply-smcsrind.d: Likewise. + * testsuite/gas/riscv/march-imply-smstateen.d: Likewise. + * testsuite/gas/riscv/march-imply-unsupported.d: Likewise. + * testsuite/gas/riscv/march-imply-v.d: Likewise. + * testsuite/gas/riscv/march-imply-zcd.d: Likewise. + * testsuite/gas/riscv/march-imply-zcf.d: Likewise. + +2024-07-03 Alan Modra + + Avoid possible signed overflow in decode_local_label_name + Matches what both fb_label_name and dollar_label_name use. + + * symbols.c (decode_local_label_name): Use unsigned variables. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed typo of `.insn cj' format + gas/ + * doc/c-riscv.texi: Fixed typo of `.insn cj' format. + +2024-07-03 Lingling Kong + + x86-64: Support APX NF TLS IE with 2 operands + Support APX NF TLS IE with 2 operands.Verify it with ld and gold. + + gas/ + + * config/tc-i386.c (md_assemble): Allow APX NF TLS IE with + 2 operands. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add APX NF TLS IE + tests with 2 operands. + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add APX NF TLS IE tests with + 2 operands. + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add APX NF TLS IE tests + with 2 operands. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed syntax of `.option arch' when reseting whole architecture + gas/ + * doc/c-riscv.texi: Fixed syntax of `.option arc'h when reseting whole + architecture. Don't need the `=' before ISA. + +2024-07-03 GDB Administrator + + Automatic date update in version.in + +2024-07-02 Tom Tromey + + Accept unnamed array in gdb.ada/limited-length.exp + Some compiler changes I'm working on cause a regression in + gdb.ada/limited-length.exp -- with the changes, the array type is + nameless and so is not mentioned in the max-value-size error message. + + Because the array type is nameless in the source code, this seems like + an improvement to me, and so this patch changes the test to accept + either form. + +2024-07-02 Aditya Vidyadhar Kamath + + Use lwp field in ptid for AIX. + Currently in AIX, the private data is used to maintain the kernel thread ID. + + This is a patch to trim the need to have another field in the private data of a thread in AIX. + + We want to use the lwp field to represent the kernel thread ID to match or + make things similar to the Linux targets. + +2024-07-02 konglin1 + + x86-64: Verify that TLS IE works with APX NF + Verify that + + {nf} add %reg1, foo@gottpoff(%rip), %reg2 + {nf} add foo@gottpoff(%rip), %reg, %reg2 + + work correctly with ld and gold. + + gas/ + + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + for APX NF tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + + Co-Authored-By: H.J. Lu + +2024-07-02 GDB Administrator + + Automatic date update in version.in + +2024-07-01 H.J. Lu + + ld: Move foo before delete in dl5.cc + * testsuite/ld-elf/dl5.cc (main): Move foo before delete. + +2024-07-01 Claudiu Zissulescu + + MAINTAINERS: Update my e-mail address + +2024-07-01 Xi Ruoyao + + LoongArch: Remove unused code in ld test suite + These seems some left over from MIPS code and they do not make any + sense for LoongArch. + +2024-07-01 Alan Modra + + PR31941 objcopy --globalize-symbol + I think FILE symbols are special, and I can't see why anyone would + want them to be made global. The fact that no one has reported this + bug since commit 7b4a0685e80a in 2005 supports that claim. + + PR 31941 + * objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to + be made global. + +2024-07-01 GDB Administrator + + Automatic date update in version.in + +2024-06-30 H.J. Lu + + ld: Avoid folding new and delete pairs + GCC 15 may fold new and delete pairs, like + + A *bb = new A[10]; + delete [] bb; + bb = new (std::nothrow) A [10]; + delete [] bb; + + as shown in + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712 + + Avoid folding new and delete pairs by adding a function call between new + and delete. + + * testsuite/ld-elf/dl5.cc: Include "dl5.h". + (A): Removed. + Call foo between new and delete. + * testsuite/ld-elf/dl5.h: New file. + * testsuite/ld-elf/new.cc: Include "dl5.h". + (foo): New function. + +2024-06-30 Marcus Nilsson + + objcopy: Allow making symbol global and weak on same invocation + Previously objcopy had to be run twice in order to make a local symbol + weak, first once to globalize it, and once again to mark it as weak. + + * objcopy.c (filter_symbols): Weaken symbols after making + local/global changes. + * testsuite/binutils-all/symbols-5.d, + * testsuite/binutils-all/symbols-5.s: New test. + +2024-06-30 Alan Modra + + tweak latest vms-alpha.c change + It's that tiny bit nicer to have the "len" expression in order of + the components in the buffer. + + Assertion `(data) <= (end)' failed in read_bases + * dwarf.c (skip_attribute): Don't increment data past end. + Use SKIP_{S,U}LEB rather than READ_{S,U}LEB. + +2024-06-30 Alan Modra + + Re: Rewrite SHT_GROUP handling + Some more error tweaks. Report a zero entry as "invalid entry.." + rather than "unknown type..", and allow a section to be mentioned + twice in a group. + + * elf.c (process_sht_group_entries): Tweak error messages, and + allow a duplicate index in a group without reporting an error. + +2024-06-30 GDB Administrator + + Automatic date update in version.in + +2024-06-29 Sam James + + ld: pass -g for ld-elf tests + The "DWARF parse during linker error" and "Build warn libbar.so" tests + require debug information. + + configure defaults to "-O2 -g" but if overriding *FLAGS when building + tests, this might be lost. Explicitly pass -g given these tests require + it. + + Originally reported downstream in Gentoo at https://bugs.gentoo.org/934149. + + ld/ + * testsuite/ld-elf/dwarf.exp: Pass -g for "DWARF parse during linker error". + * testsuite/ld-elf/shared.exp: Ditto for "Build warn libbar.so". + +2024-06-29 GDB Administrator + + Automatic date update in version.in + +2024-06-28 Claudio Bantaloukas + + aarch64: Add support for Armv9.5-A architecture + The new -march=armv9.5-a flag enables access to the + mandatory cpa, lut and faminmax extensions. + Existing test cases for features are extended to verify they + work without additional flags. + +2024-06-28 Jan Beulich + + ld/doc: drop stray blank + Old enough tools demand no blank between @option and the opening figure + brace. Re-wrap the paragraph as well while at it. + +2024-06-28 Lulu Cai + + LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files + R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38. + We do not check this relocation to prevent broken links with old object + files. + +2024-06-28 Jan Beulich + + x86/APX: apply NDD-to-legacy transformation to further CMOVcc forms + With both sources being registers, these insns are almost commutative; + the only extra adjustment needed is inversion of the encoded condition. + + x86/APX: extend TEST-by-imm7 optimization to CTESTcc + The same properties apply there. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL + ..., for differing only in the resulting EFLAGS, which are left + untouched anyway. That's a shorter encoding, available as long as + certain constraints on operands are met; see code comments. (SHL-by-1 + forms may then be subject to further optimization that was introduced + earlier.) + + Note that kind of as a side effect this also converts multiplication by + 1 to shift by 0, which is a plain move or even no-op anyway. That could + be further shrunk (as could be presence of shifts/rotates by 0 in the + original code as well as a fair set of other {nf}-form insns), yet the + expectation (for now) is that people won't write such code in the first + place. + +2024-06-28 Jan Beulich + + x86-64: restrict by-imm31 optimization + Avoid changing the encoding when there's no size gain: If there's a REX + or REX2 prefix anyway and the base opcode wouldn't be changed, dropping + just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case + in the same big conditional.) + + While there also pull out the .qword check: For the 2-register-operands + case whether that's done on the 1st or 2nd operand doesn't matter. Due + to reduction in necessary parentheses this improves readability a tiny + bit. + +2024-06-28 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to LEA + ..., as that leaves EFLAGS untouched anyway. That's a shorter encoding, + available as long as certain constraints on operand size and registers + are met; see code comments. + + Note that this requires deferring to derive encoding_evex from {nf} + presence, as in optimize_encoding() we want to avoid touching the insns + when {evex} was also used. + + Note further that this requires want_disp32() to now also consider the + opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still + report the original mnemonic (or else things can get confusing). While + there, correct adjacent mis-indentation. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form rotate-by-width-less-1 + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS.CF, for the NF variants the immediate can be got rid of in that + case by switching to a 1-bit rotate in the opposite direction. + + x86/APX: optimize {nf} forms of ADD/SUB with specific immediates + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS, for the NF variants we can safely replace ones using 0x80 by the + respectively other insn while negating the immediate, saving 3 immediate + bytes (just 1 though for 16-bit operand size). Similarly we can replace + ones using 1 / -1 by INC/DEC (eliminating the immediate). + + gas: .irp/.irpc are macro-like + ... for the purposes of get_line_sb() and _find_end_of_line(): They + support \@ just like macros do, and hence the special casing there also + needs applying. + +2024-06-28 Nelson Chu + + RISC-V: Shrink the riscv_implicit_subsets table. + Allow to add implicit extensions by using the syntax of `.option arch, +-', so + that the table is shrinked and more readable. + + bfd/ + * elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT + parameter. + (check_implicit_for_i): Likewise. + (riscv_implicit_subsets): Shrink the table by allowing the syntax of + `.option arch, +-' for implicit extensions. + (riscv_update_subset1): New function, called from riscv_update_subset + or riscv_parse_add_implicit_subsets. It basically does the same thing + as riscv_update_subset function before. + (riscv_parse_add_implicit_subsets): Updated. + (riscv_update_subset): Updated. + +2024-06-28 Nelson Chu + + RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc. + When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel + relocation to absolutly access if possible at the relocate stage. We used to + encode the target address into r_sym of R_RISCV_HI20 if it is converted from + R_RISCV_PCREL_HI20. But that may cause segfault if --emit-relocs is set, + since r_sym becomes an address rather than a symbol index. Although the + relocate result is correct, it does not meet the definition, so may cause + unexpected behaviors. + + This patch encodes the target address into r_addend, rather than r_sym, if + riscv_zero_pcrel_hi_reloc converts the relocation. Besdies, since the + corresponding pcrel_lo relocation are also changed to absolutly access, + we should also update them to R_RISCV_LO12_I/S. + + bfd/ + PR 27180 + * elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to + inform corresponding pcrel_lo that the pcrel_hi relocation was already + converted to hi20 relocation. + (riscv_record_pcrel_hi_reloc): Likewise, record `absolute'. + (riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc, + since we may need to convert it from pcrel_lo to lo relocation. + (riscv_record_pcrel_lo_reloc): Likewise. Convert pcrel_lo to lo + relocation if corresponding pcrel_hi was converted to hi relocation. + (riscv_zero_pcrel_hi_reloc): Encode target absolute address into + r_addend rather than r_sym. Clear the `addr' to avoid duplicate + relocate in the perform_relocation. + (riscv_elf_relocate_section): Updated. + ld/ + PR 27180 + * testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase. + Segfault without applying this patch. + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + +2024-06-28 Jiawei + + RISC-V: Add Zabha extension CAS instructions. + This patch update the cas instruction in Zabha extension [1], + when both Zabha and Zacas extension enabled. + + [1] https://github.com/riscv/riscv-zabha/tags + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): New extension case. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New instructions. + * testsuite/gas/riscv/zabha.d: Ditto. + * testsuite/gas/riscv/zabha.s: Ditto. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOCAS_B): New opcodes. + (MASK_AMOCAS_B): Ditto. + (MATCH_AMOCAS_H): Ditto. + (MASK_AMOCAS_H): Ditto. + (DECLARE_INSN): New instructions. + * opcode/riscv.h (enum riscv_insn_class): New class case. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-06-28 GDB Administrator + + Automatic date update in version.in + +2024-06-27 H.J. Lu + + Set BFD_DECOMPRESS when reading build-id debuglink + We should set BFD_DECOMPRESS to decompress sections unless dumping the + section contents when reading build-id debuglink. + + PR binutils/31925 + * objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress + sections unless dumping the section contents. + * testsuite/binutils-all/objdump.exp (test_build_id_debuglink): + Add a compress option. + Run test_build_id_debuglink with none and zlib. + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_tilde_expand + Like the previous commit, add two overloads of gdb_tilde_expand, one + takes std::string and other takes gdb::unique_xmalloc_ptr. Make + use of these overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_abspath + Add two overloads of gdb_abspath, one which takes std::string and one + which takes gdb::unique_xmalloc_ptr, then make use of these + overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Pali Roh?r + + Improve comments describing the Import Directory Table + PR 31728 + +2024-06-27 Nick Clifton + + Fix new libdep test so that if the plugin cannot be located the test fails gracefully. + +2024-06-27 Alan Modra + + Re: Rewrite SHT_GROUP handling + There is no need to loop over the headers twice. Remove that leftover + from the previous scheme. Also, the previous scheme silently ignored + a section being mentioned in two or more SHT_GROUP sections. + + * elf.c (process_sht_group_entries): Prevent sections from + belonging to two groups. + (_bfd_elf_setup_sections): Process groups in a single loop + over headers. + +2024-06-27 GDB Administrator + + Automatic date update in version.in + +2024-06-27 Alan Modra + + Rewrite SHT_GROUP handling + This patch delays setting up elf_next_in_group, elf_sec_group and + elf_group_name when reading ELF object files until after all ELF + sections have been processed by bfd_section_from_shdr. This is simpler + and more robust than the current scheme of driving the whole process + on detecting a section with SHF_GROUP set. + + * elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr, + num_group and group_search_offset. + * elf.c (Elf_Internal_Group): Delete. + (setup_group): Delete function. + (IS_VALID_GROUP_SECTION_HEADER): Delete macro. + (is_valid_group_section_header), + (process_sht_group_entries): New functions. + (_bfd_elf_setup_sections): Handle group sections here.. + (_bfd_elf_make_section_from_shdr): ..rather than here. + (bfd_section_from_shdr): Don't check SHT_GROUP validity here. + +2024-06-26 Nick Clifton + + Revert: 35fd2ddeb1d90f1750401cfb6d01fe055656b88d + PR 20814 + +2024-06-26 Tom de Vries + + [gdb/testsuite] Minor cleanup in gdb.base/bg-execution-repeat.exp + Simplify a gdb_test_multiple in test-case gdb.base/bg-execution-repeat.exp + using "gdb_test -no-prompt-anchor". + + Suggested-By: Guinevere Larsen + + Tested on x86_64-linux. + +2024-06-26 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp + I ran into the following test failure with test-case + gdb.base/bg-execution-repeat.exp: + ... + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command + ^M + Breakpoint 2, foo () at bg-execution-repeat.c:23^M + 23 return 0; /* set break here */^M + print 1^M + $1 = 1^M + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted + FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout) + ... + + The failure can be easily reproduced by adding a sleep 5 here: + ... + + sleep 5 + gdb_test "print 1" " = 1" "input still accepted" + ... + + There's a race in the test-case, between: + - the command handled in the foreground: the "print 1" command, and + - the command handled in the background: the continue command. + + The current way of dealing with this is by putting the inferior to sleep for 5 + seconds: + ... + foo (); + sleep (5); + foo (); + ... + with the aim that the "print 1" command will win the race. + + This method is both slow and unreliable. + + Fix this by making the inferior wait till the "print 1" command is done. + + This reduces running time from ~11s to ~1s. + + I also verified that the test-case still triggers on the original problem by + applying this gdb/infcmd.c patch: + ... + -strip_bg_char (const char *args, int *bg_char_p) + +strip_bg_char (const char *_args, int *bg_char_p) + { + - const char *p; + + char *args = const_cast(_args); + + char *p; + + if (args == nullptr || *args == '\0') + { + @@ -210,6 +211,7 @@ strip_bg_char (const char *args, int *bg_char_p) + p--; + while (p > args && isspace (p[-1])) + p--; + + *p = '\0'; + ... + + Tested on x86_64-linux, with make-check-all.sh. + + PR testsuite/31794 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31794 + + Reviewed-By: Guinevere Larsen + +2024-06-26 Indu Bhagat + + doc: sframe: small improvements for readability + Update some of the content to make the specification document hopefully + clearer: + - Fix some typos. + - Use Title case consistently for headings. + - Update text around detection of foreign endianness. + - Split the structure field "Name" in each table to two separate + colunms for additional attention: "Type" and "Name". + - Rename "SFrame endianness" section to "SFrame magic number and + endianness" + - Update text around provisions for extending SFrame for future + ABIs/architectures. Make it clear by tagging all provisions with an + explicit index item "Provisions for future ABIs". + - Add a paragraph on sort order of SFrame FDEs. + - Add a statement for SFRAME_F_FRAME_POINTER flag. + - Add a statement to assert that SFrame version 1 is now obsolete and + should not be used. + + libsframe/ + * doc/sframe-spec.texi: Small improvements for readability. + +2024-06-26 GDB Administrator + + Automatic date update in version.in + +2024-06-26 Victor Do Nascimento + + aarch64: FP8 scale and convert - Implement minor improvements + Following feedback received shortly after the initial commit of the + aarch64 instructions for scaling and converting fp8 instructions, this + patch addresses the issues raised in the relevant feedback. + + This includes the following changes: + + * Standardize all FP8 qualifier-set names. This has resulted in the + renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B + to QL_V2_HB_FULL. + + * Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new + standardized qualifier-set names mentioned above and, in the case of + the "fcvtn" entries, also add a leading 0 to their opcode values so + they are given as 8 hexadecimal digits in length to ensure + consistency in formatting relative to other entries in the table. + + * Revise the added test-cases so that when checking operand fields in + the disassembled binaries, all bits for these fields get tested to + ensure they can be toggled on/off by the relevant operand arguments. + +2024-06-25 Flavio Cruz + + Hurd port: update interface to match upstream and fix warnings. + We have recently updated the interface for raising exceptions to use + long [1] and updated mach_port_t to be "unsigned int". This patches fixes + those problems and will help us port GDB to Hurd x86_64. + + Tested on Hurd i686 and x86_64. + + [1] https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/mach/exc.defs + + Approved-By: Simon Marchi + +2024-06-25 Jens Remus + + aarch64: Treat operand ADDR_SIMPLE as address with base register + The AArch64 instruction table (aarch64-tbl.h) defines the operand + ADDR_SIMPLE as "address with base register (no offset)". During assembly + it is correctly encoded as address with base register (addr.base_regno) + in parse_operands. In warn_unpredictable_ldst it is erroneously treated + as register number (reg.regno). + + This resolves the assembler test case "Diagnostics Quality" to + erroneously fail when changing the union in struct aarch64_opnd_info + from union to struct for debugging purposes. + + gas/ + * config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with + base register. + +2024-06-25 Jens Remus + + aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + Rt_IN_SYS_ALIASES as register number. During assembly it is correctly + encoded as register number (reg.regno) in parse_operands. During + disassembly it is first correctly decoded as register number (reg.regno) + in aarch64_ext_regno called by aarch64_extract_operand, but then + erroneously treated as immediate value (imm.value) in + aarch64_print_operand. + + This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31919 + * aarch64-opc.c: Treat operand Rt_IN_SYS_ALIASES as register + number. + + Bug: https://sourceware.org/PR31919 + Fixes: 72476aca8f58 ("aarch64: add Branch Record Buffer extension instructions") + +2024-06-25 Andrew Burgess + + gdb/doc: the all-doc build target should build .... all docs + I noticed that the 'all-doc' build target doesn't build all the doc + formats, 'man' and 'html' are missing. + + This commit updates 'all-doc' so that all formats are built. + + This doesn't change the default 'all' target, which is the default + target used when building GDB itself, the 'all' target continues to + just build the 'info' docs. + + There should be no difference in the actual generated output after + this commit, I'm just changing what gets built. + + Approved-By: Tom Tromey + +2024-06-25 Andrew Burgess + + gdb/doc: fix cannot create directory error when building dvi/pdf + After this commit: + + commit 0700386f142f0b0d3d0021995970a1b41c36cc92 (gdb-tmp-c) + Date: Wed May 8 19:12:57 2024 +0100 + + gdb/doc: fix parallel build of pdf and dvi files + + When building the dvi or pdf targets you'd get errors like this: + + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory + + fixed by ensuring the directory is created before calling texi2dvi. + +2024-06-25 Nick Clifton + + Updated Russian translation for the bfd/ sub-directory + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix FEAT_B16B16 sve2 instruction constraints. + This patch adds missing contraints to FEAT_B16B16 sve2 instructions + bfclamp, bfmla and bfmls and add negative tests for all the bfloat + instructions. + + The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.* + to maintain consistency in the testsuite. + + The bfloat16-1-invalid.* tests are modified so that "selected + processor does not support" is generated by the assembler, since + +b16b16 is not passed in the command line. + + The bfloat16-2-invalid.* testcase includes the wrong operands + bfloat16 tests. + +2024-06-25 Srinath Parvathaneni + + aarch64: Add extra tests for sve2p1 min max instructions. + This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv, + sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and + fminqv" instructions. + + The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase + without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands + for sve2p1 instructions. + +2024-06-25 Srinath Parvathaneni + + arch64: Fix the wrong constraint used for sve2p1 instructions. + The current implementation for the following SVE2p1 instructions add a + constraint in aarch64_opcode_table[] array, so that these instruction + might be immediately preceded in program order by a MOVPRFX instruction. + + As per the spec these instruction does not immediately preceded in + program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC + macro is replaced with SVE2p1_INSN macro for the entries of these + instructions in aarch64_opcode_table[] array. + + List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv, + eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 ld[1-4]/st[1-4]q instruction operands. + This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q + as mentioned below, for the issues reported here. + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + 1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as + predicated instructions and this issue is fixed in this patch by replacing + "SVE2p1_INSNC" with "SVE2p1_INSN" macro. + 2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed + by replacing "SVE_Zt" with "SVE_ZtxN". + 3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in + this patch. + 4) In ld1q/st1q the index in the second argument is optional and if index + is xzr and is skipped in the assembly, the index field is ignored by the + disassembler. + + Fixing above mentioned issues helps with following: + 1) ld1q and st1q first register operand accepts enclosed figure braces. + 2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping + sequence of vector registers. + + For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector + registers are added along with short-form of operands for non-wrapping sequence. + + I have added test using following logic: + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #0, MUL VL] //raw insn encoding (all zeroes) + ld2q {Z31.Q, Z0.Q}, p0/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of (low value) + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of (high value) + ld2q {Z31.Q, Z0.Q}, p7/Z, [x30, #-16, MUL VL] // encoding of all fields (all ones) + ld2q {Z30.Q, Z31.Q}, p1/Z, [x3, #-2, MUL VL] // random encoding. + + For all the above form of instructions the hyphenated form is preferred for + disassembly if there are more than two registers in the list, and the register + numbers are monotonically increasing in increments of one. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 extq instruction operands. + This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands + count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th + argument an 4-bit unsigned immediate of extq instruction. The instruction encoding + is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately + precede in program order by a MOVPRFX instruction. Also removed the unused operand + AARCH64_OPND_SVE_Zm_imm4. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 dupq instruction operands. + This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way + 2nd operand does the encoding and decoding using the [] value. + + dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index + inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter) + and aarch64_ext_sve_index_imm (extractor) is removed in this patch. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Enable mandatory feature bits for v9.4-A. + This patch fixes the mandatory feature bits in v9.4-a architectures, + by enabling FEAT_SVE2p1 for Armv9.4-A architecture by default. + +2024-06-25 Nick Clifton + + Revert 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c + PR 20880 + + Fix calculation of space remaining in buffer when printing the contents of a DST__K_RECBEG type debug symbol for the VMS Alpha port. + PR 31873 + +2024-06-25 Schimpe, Christina + + gdb: use alternative for demangled name for non-demangeable linkage names + In case a DIE contains a linkage name which cannot be demangled and + a source language name (DW_AT_NAME) exists then we want to display this name + instead of the non-demangeable linkage name. + + dwarf2_physname returns the linkage name in case the linkage name + cannot be demangled. Before this patch we always set the returned physname + as demangled name. This patch changes this by comparing the value + of physname with the linkage name. Now after this change in case it is equals + to the linkage name and if DW_AT_NAME exists then this is set as the demangled + name otherwise like before still linkage name is used. + + For the reproducer, using the test source file added in this change: + "gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c" + + Here is an example of the DWARF where wrong linkage name is emitted by the + compiler for the "func_demangled_test" function: + + subprogram { + {MACRO_AT_range {func_demangled_test}} + {linkage_name "_FUNC_WRONG_MANGLED__"} + {name "func_demangled_test"} + {external 1 flag} + } + subprogram { + {MACRO_AT_range {main}} + {external 1 flag} + {name main} + {main_subprogram 1 flag} + } + + Before this change for a function having both DIEs DW_AT_name and + DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace + command shows following: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + (gdb) backtrace + \#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + \#1 0x000055555555514a in main () + + After the change now GDB shows the name emitted by DW_AT_NAME: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in func_demangled_test () + (gdb) backtrace + \#0 0x0000555555555131 in func_demangled_test () + \#1 0x000055555555514a in main () + + A new test is added to verify this change. + + Approved-By: Tom Tromey + +2024-06-25 Szabolcs Nagy + + aarch64: Add DT_RELR tests for ILP32 ABI + + aarch64: Add DT_RELR support for ILP32 ABI + Extend the 64bit DT_RELR support to work on 32bit ELF too. For this + only a few changes were needed in the sizing and creation of the + relr relocations. + +2024-06-25 Tom de Vries + + [gdb/symtab] Remove dead code in parse_macro_definition + In parse_macro_definition, there's a loop: + ... + for (p = body; *p; p++) + if (*p == ' ' || *p == '(') + break; + ... + whose post-condition is: + ... + gdb_assert (*p == ' ' || *p == '(' || *p == '\0'); + ... + + Consequently, in the following: + ... + if (*p == ' ' || *p == '\0') + + else if (*p == '(') + + else + + ... + BODY3 is dead code. + + Remove it, and get rid of unnecessary indentation by using an early-exit: + .... + if (*p == ' ' || *p == '\0') + { + + return; + } + + gdb_assert (*p == '('); + + ... + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-06-25 GDB Administrator + + Automatic date update in version.in + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware breakpoint + LoongArch defines hardware watchpoint functions for fetch operations. + After the software configures the watchpoints for fetch, the processor + hardware will monitor the access addresses of the fetch operations and + trigger a watchpoint exception when the watchpoint setting conditions + are met. + + Hardware watchpoints for fetch operations is used to implement hardware + breakpoint function on LoongArch. Refer to the following document for + hardware breakpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + No hardware breakpoint support in the target. + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8. + (gdb) c + Continuing. + start test + a = 1 + + Breakpoint 2, main () at test.c:8 + 8 printf("end test\n"); + (gdb) c + Continuing. + end test + [Inferior 1 (process 25378) exited normally] + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware watchpoint + LoongArch defines hardware watchpoint functions for load/store + operations. After the software configures the watchpoints for + load/store, the processor hardware will monitor the access + addresses of the load/store operations and trigger watchpoint + exception when the watchpoint setting conditions are met. + + After this patch, watch/rwatch/awatch command are supported. Refer to the + following document for hardware watchpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Target does not support this type of hardware watchpoint. + ... + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Hardware access (read/write) watchpoint 2: a + (gdb) c + Continuing. + start test + + Hardware access (read/write) watchpoint 2: a + + Old value = 0 + New value = 1 + main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + + Hardware access (read/write) watchpoint 2: a + + Value = 1 + 0x00000001200006e0 in main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + a = 1 + end test + [Inferior 1 (process 22250) exited normally] + +2024-06-24 Hannes Domani + + Fix gdb.lookup_type for function-local types + Looking for a type defined locally in a function doesn't work + any more since the introduction of TYPE_DOMAIN: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Python Exception : No type named main()::Local. + Error occurred in Python: No type named main()::Local. + ``` + + cp_search_static_and_baseclasses was simply missing a check for + SEARCH_TYPE_DOMAIN, now it works again: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Local + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922 + Approved-By: Tom Tromey + +2024-06-24 Andrew Carlotti + + aarch64: Add SME FP8 multiplication instructions + This includes: + - FEAT_SME_F8F32 (+sme-f8f32) + - FEAT_SME_F8F16 (+sme-f8f16) + + The FP16 addition/subtraction instructions originally added by + FEAT_SME_F16F16 haven't been added to Binutils yet. They are also + required to be enabled if FEAT_SME_F8F16 is present, so they are + included in this patch. + +2024-06-24 Andrew Carlotti + + aarch64: Add FP8 Neon and SVE multiplication instructions + This includes all the instructions under the following features: + - FEAT_FP8FMA (+fp8fma) + - FEAT_FP8DOT4 (+fp8dot4) + - FEAT_FP8DOT2 (+fp8dot2) + - FEAT_SSVE_FP8FMA (+ssve-fp8fma) + - FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4) + - FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2) + +2024-06-24 Andrew Carlotti + + aarch64: Add support for virtual features + These features will be used to gate instructions that can be enabled by + either of two (or more) different sets of command line feature flags. + + This patch add a postprocessing step to the feature parsing code to + set the value of the virtual bits. + +2024-06-24 Andrew Carlotti + + aarch64: Move struct definition towards its usage + +2024-06-24 Tom Tromey + + Prefer htab_traverse_noresize + A few spots in gdb were using htab_traverse. IMO this is almost never + useful and htab_traverse_noresize should be preferred. + +2024-06-24 Tom Tromey + + Remove hashtab_obstack_allocate + I think that hashtabs should never be obstack-allocated. In the past + this was convenient sometimes, because any new data structure needed a + corresponding cleanup. However, with the switch to C++, resource + management has become much simpler; for example, a local variable can + simply be of type htab_up rather than hashtab_t, and the problem is + solved. + + This patch removes hashtab_obstack_allocate to try to prevent this + anti-pattern from being used again. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the call site hash table + The call site hash table is the last hash table using obstack + allocation. In one large (non-public) test case, these hash tables + take a substiantial amount of memory. Some of this memory is wasted + -- whenever the hash table is resized, the old table is not freed. + + This patch fixes the problem by changing this hash table to be + heap-allocated. This means that resizing will no longer "leak" + memory. + +2024-06-24 Tom Tromey + + Add compunit_symtab::forget_cached_source_info + It seemed cleaner to me for compunit_symtab to have a + forget_cached_source_info method, then for the objfile to know how to + do this. + + Make symtab members private + This rearranges symtab so that the private members appear at the end, + and then adds the "private" keyword. + + Rename symtab::fullname + This renames symtab::fullname to m_fullname and adds new accessor + methods. + + Don't obstack-allocate the CU dependency hash table + The CU dependency hash table is obstack-allocated, but there's no need + to do this. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the DIE hash + The DIE hash table is currently allocated on an obstack. There's no + need to do this, and I think it's better to simply heap-allocate the + hash table. + + This patch implements this. I also removed store_in_ref_table as + well, inlining it into its sole caller, as I think this is clearer. + +2024-06-24 Harmen Stoppels + + libdep plugin: fix bugs in parser and drop escaping + PR ld/31906 + * libdep_plugin.c (str2vec): Fix bug where null byte was not copied on memmove during quote handling and escaping, causing repeat of the last character in the last argument. + Fix buffer overflow in **res when arguments were separated by `\t` instead of ` `. + Remove handling of the escape character `\`, as it made it impossible to specify paths containing `\` + -- the implementation merely dropped `\`, and was affected by the memmove bug, so this should not be breaking; just single and double quotes are sufficient to deal with white space and quote characters, there is no need for escaping. + Handle syntax errors on unterminated quotes. + Make the parser linear time instead of quadratic. + +2024-06-24 Nick Clifton + + Updated Spanish translations for the bfd and binutils sub-directories + + ld: Improve the documentation describing the -o option. + PR 31761 + +2024-06-24 saurabh.jha@arm.com + + gas, aarch64: Add SME2 lutv2 extension + Introduces instructions for the SME2 lutv2 extension for AArch64. They + are documented in the following document: + + * ARM DDI0602 + + For both luti4 instructions, we introduced an operand called + SME_Znx2_BIT_INDEX. We use the existing function parse_vector_reg_list + for parsing but modified that function so that it can accept operands + without qualifiers and rejects instructions that have operands with + qualifiers but are not supposed to have operands with qualifiers. + For disassembly, we modified print_register_list so that it could + accept register lists without qualifiers. + + For one luti4 instruction, we introduced a SME_Zdnx4_STRIDED. It is + similar to SME_Ztx4_STRIDED and we could use existing code for parsing, + encoding, and disassembly. + + For movt instruction, we introduced an operand called SME_ZT0_INDEX2_12. + This is a ZT0 register with a bit index encoded in [13:12]. It is + similar to SME_ZT0_INDEX. + + We also introduced an iclass named sme_size_12_b so that we can encode + size bits [13:12] correctly when only 'b' is allowed as qualifier. + +2024-06-24 Martin Simmons + + Include needed unordered_map header + Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level + configure options --with-python=/usr/local/bin/python3.9 gives this error: + + CXX ada-exp.o + ./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std' + std::unordered_map> + ~~~~~^ + 1 error generated. + + This change fixes it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918 + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of pdf and dvi files + When building with 'make -j20 -C gdb/doc all-doc' I often see problems + caused from trying to build some dvi files in parallel with some pdf + files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and + stabs.pdf; and annotate.dvi and annotate.pdf. + + The problem is that building these files create temporary files in the + local directory. There's already a race here that two make threads + might try to create these files at the same time. + + But it gets worse, to avoid issues where a failed build could leave + these temporary files in a corrupted state, and so prevent the next + build from succeeding, the recipe for each of these files deletes all + the temporary files first, this obviously causes problems if some + other thread has already started the build and is relying on these + temporary files. + + To work around this problem I propose we start using the --build and + --build-dir options for texi2dvi (which is the same tool used to + create the pdf files). These options were added in texinfo 4.9 which + was released in June 2007. We already require using a version of + texinfo after 4.9 (I tried to build with 4.13 and the doc build failed + as some of the texinfo constructs were not understood), so this patch + has not changed the minimum required version at all. + + The --build flag allows the temporary files to be placed into a + sub-directory, and the --build-dir option allows us to control the + name of that sub-directory. + + What we do is create a unique sub-directory for each target that + invokes texi2dvi, all of the unique sub-directories are created within + a single directory texi2dvi_tmpdir, and so after a complete doc build, + we are left with a build tree like this: + + build/gdb/doc/ + '-- texi2dvi_tmpdir/ + |-- annotate_dvi/ + |-- annotate_pdf/ + |-- gdb_dvi/ + |-- gdb_pdf/ + |-- stabs_dvi/ + '-- stabs_pdf/ + + I've left out all the individual files that live within these + directories for simplicity. + + To avoid corrupted temporary files preventing a future build to + complete, each recipe deletes its associated sub-directory from within + texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh + start each time. + + And the mostlyclean target deletes texi2dvi_tmpdir/ and all its + sub-directories, ensuring that everything is cleaned up. + + For me, with this fix in place, I can now run 'make -j20 -C gdb/doc + all-doc' without seeing any build problems. + + Approved-By: Pedro Alves + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of refcard related targets + There are two problems we encounter when trying to build the refcard + related target in parallel, i.e.: + + $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf + + These problems are: + + (1) The refcard.dvi and refcard.pdf targets both try and generate the + tmp.sed and sedref.tex files. If two make threads end up trying + to create these files at the same time then the result is these + files become corrupted. + + I've fixed this by creating a new rule that creates sedref.tex, + both refcard.dvi and refcard.pdf now depend on this, and make will + build sedref.tex just once. The tmp.sed file is now generated as + refcard.sed, this is generated and deleted as a temporary file + within the sedref.tex recipe. + + (2) Having created sedref.tex the recipes for refcard.dvi and + refcard.pdf both run various LaTeX based tools with sedref.tex as + the input file. The problem with this is that these tools all + rely on creating temporary files calls sedref.*. + + If the refcard.dvi and refcard.pdf rules run at the same time then + these temporary files clash and overwrite each other causing the + build to fail. + + We already copy the result file in order to rename it, our input + file is sedref.tex which results in an output file named + sedref.dvi or sedref.pdf, but we actually want refcard.dvi or + refcard.pdf. So within the recipe for refcard.dvi I copy the + input file from sedref.tex to sedref_dvi.tex. Now all the temp + files are named sedref_dvi.* and the output is sedref_dvi.dvi, I + then rename this new output file to refcard.dvi. + + I've done the same thing for refcard.pdf, but I copy the input + to sedref_pdf.tex. + + In this way the temp files no longer clash, and both recipes can + safely run in parallel. + + After this commit I was able to reliably build all of the refcard + targets in parallel. There should be no change in the final file. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: also look in srcdir when running TEXI2POD + In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke + texi2pod.pl, which process the .texinfo files. This also handles the + 'include' directives within the .texinfo files. + + Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag + to add search directories for resolving 'include' directives within + .texinfo files. + + When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes + GDBvn.texi. + + When building from a git checkout the gdb-cfg.texi files and + GDBvn.texi files will be created in the build directory, which is + where texi2pod.pl is invoked, so the files will be found just fine. + + However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the + source tree, along with the generated manual (.1 and .5) files. + + So when building a release, what normally happens is that we spot that + the .1 and .5 man files are up to date, and don't run the recipe to + regenerate these files. + + However, if we deliberately touch the *.texinfo files in a release + source tree, and then try to rebuild the man files, we'll get an error + like this: + + make: Entering directory '/tmp/release-build/build/gdb/doc' + TEXI2POD gdb.1 + cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make: *** [Makefile:664: gdb.1] Error 2 + make: Leaving directory '/tmp/release-build/build/gdb/doc' + + The problem is that texi2pod.pl doesn't know to look in the source + tree for the GDBvn.texi file. + + If we compare this to the recipe for creating (for example) gdb.dvi, + which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi + command line, which allows texi2dvi to find GDBvn.texi in the source + tree. + + In this commit I add a similar -I option to the texi2pod.pl command + line. After this, given a GDB release, it is possible to edit (or + just touch) the gdb.texinfo file and rebuild the man pages, the + GDBvn.texi will be picked up from the source tree. + + If however a dependency for GDBvn.texi is changed in a release tree + then GDBvn.texi will be regenerated into the build directory and this + will be picked up in preference to the GDBvn.texi in the source tree, + just as you would want. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: allow for version.subst in the source tree + In a git checkout of the source code we don't have a version.subst + file in the gdb/doc directory. When building the GDB docs the + version.subst file is generated on demand (we have a recipe for that). + + However, in a release tar file we do include a copy of the + version.subst file in the source tree, as a result the version.subst + recipe will not be run. + + If, in a release build, we force the running of any recipe that + depends on version.subst then we run into a problem. For example, + slightly confusingly, if we 'touch gdb/doc/version.subst' within the + unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' + in the build tree, we'll see: + + make: Entering directory '/tmp/build/build/gdb/doc' + GEN GDBvn.texi + sed: can't read version.subst: No such file or directory + make: Leaving directory '/tmp/build/build/gdb/doc' + + The problem is that every reference to version.subst in GDB's Makefile + assumes that the version.subst file will always be in the build + directory. + + Handily version.subst is always the first dependency in every recipe + that uses that file. As such we can replace references to + version.subst with $<, make will expand this to the location where the + dependency was found. + + In the case of the man page generation, the reference to version.subst + is hidden inside POD2MAN. It seemed a little confusing adding a use + of $< within POD2MAN, so I've moved the use into the recipe, which I + think is clearer. + + I've also added comments for the two rules that I've modified to + explain our use of $<. + + After this change it is possible to rebuild the man pages even when + version.subst is located in the source tree. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: merge rules for building .1 and .5 man pages + We have two rules, one each for building the .1 and .5 man pages. The + only actual difference is that one rule passes --section=1 and the + other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5 + respectively. + + I figure by using the suffix from the target of the rule we can + combine these two rules into one. + + I use: + + $(subst .,,$(suffix $@)) + + This gets the suffix from the target, either '.1' or '.5', and the + 'subst' removes the '.' leaving '1' or '5'. + + Now that I'm not using a static pattern rule for building the man + pages, the advice in the 'make' documentation is to not use $*, so + I've moved away from that to instead use $(basename $@), e.g. for + 'gdbinit.5' this gives 'gdbinit', which is what we want. + + There should be no difference in what is created after this change. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: don't try to copy GDBvn.texi from the source tree + The build recipe for gdb.dvi and gdb.pdf contains instructions for + copying the GDBvn.texi file from the source tree into the build + directory if the GDBvn.texi file doesn't already exist in the build + directory. + + The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi, + and we have a recipe for building GDBvn.texi. + + What's happening here is this: + + - In a git checkout of the source tree there is no GDBvn.texi in the + source tree, the GDBvn.texi dependency will trigger a rebuild of + GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf. + + - In a release tar file we do include a copy of GDBvn.texi. This + file will appear to be up to date, and so no copy of GDBvn.texi is + created within the build directory. Now when building gdb.dvi + and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from + the source tree into the build directory. + + However, copying GDBvn.texi from the source directory is completely + unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and + pass '-I $(srcdir)' as an argument, this means that texi2dvi will look + in the $(srcdir) to find included files, including GDBvn.texi. + + As such I believe we can remove the code that copies GDBvn.texi from + the source tree into the build tree. + + I've tested with a release build; creating a release with: + + ./src-release gdb + + Then in an empty directory, unpacking the resulting .tar file, + creating a parallel build directory and doing the usual configure, + make, and 'make install'. + + Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked + source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf + and dvi files, this works fine without having to either build or copy + GDBvn.texi into the build directory. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/i386: fix tdesc rejection issue for targets without PTRACE_GETREGSET + After the x86 target description changes that I committed recently, + the first commit in the series being: + + commit 8a29222b85f28a2201db50a34ac4144f961311db + Date: Sat Jan 27 10:40:35 2024 +0000 + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + + and the last commit in the series being: + + commit 646d754d14c2fe70a492a893506a74b0463b6ae8 + Author: Andrew Burgess + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + The sourceware buildbot highlighted a regression on i386. On the GDB + side we'd see this: + + Remote debugging using :54321 + warning: Architecture rejected target-supplied description + Remote connection closed + (gdb) + + while on the gdbserver side we'd see this: + + $ ./gdbserver/gdbserver --once :54321 ~/empty + Process /srv/aburgess/empty created; pid = 31406 + Listening on port 54321 + Remote debugging from host ::1, port 39488 + ../../src/gdbserver/regcache.cc:272: A problem internal to GDBserver has been detected. + Unknown register st0 requested + Aborted (core dumped) + + When I tried to reproduce this regression on my local i386 VM the + issue would not reproduce. + + I eventually tracked the problem down to x86_linux_tdesc_for_tid in + gdb/nat/x86-linux-tdesc.c. In this function we have this line: + + /* Check if PTRACE_GETREGSET works. */ + if (ptrace (PTRACE_GETREGSET, tid, + (unsigned int) NT_X86_XSTATE, &iov) < 0) + { + ... handle failure ... + } + else + { + ... handle success ... + } + + The problem is that on my VM the PTRACE_GETREGSET feature is + supported, while on sourceware's buildbot machine this feature is not + supported. + + I did a quick search and it seems like the 'xsave' feature in + /proc/cpuinfo might be the indicator for whether PTRACE_GETREGSET is + supported or not, and indeed my machine has the 'xsave' feature while + the sourceware machine does not. + + The point of divergence then is this ptrace call, on my machine the + call succeeds and we extract the xcr0 value from the iov vector, while + on the sourceware machine the ptrace call fails and we use a default + xcr0 value of 0. + + This xcr0 value is then passed to i386_linux_read_description at the + end of x86_linux_tdesc_for_tid. + + In gdb/arch/i386-linux-tdesc.c we find i386_linux_read_description + which does some caching but calls i386_create_target_description to + actually create the target descriptions when needed. The xcr0 value + is masked to only the bits that are interesting, but given a value of + 0 we'll just pass 0 through to i386_create_target_description. + + In gdb/arch/i386.c we find i386_create_target_description which checks + the xcr0 bits and builds the target description. What we can see is + that if no bits are set in the xcr0 value then no features will be + added to the created target description. This featureless target + description is then transmitted back to GDB, which is then rejected + due to lack of essential core registers. + + So, how did things work prior to the above commit series? There are + three places of interest, on the GDB side there is + x86_linux_nat_target::read_description and + i386_linux_core_read_description. Then on the gdbserver side there is + x86_linux_read_description. + + All of these locations have a call to i386_linux_read_description + followed by a check if the return value was nullptr. If we do get + back nullptr then we perform another call to + i386_linux_read_description with a default xcr0 value. + + Looking in i386_linux_read_description we see a specific check for + xcr0 being 0 in which case we return nullptr. + + And so, prior to the above series, if xcr0 was 0 due to + PTRACE_GETREGSET being unavailable we'd use a default xcr0 value. + + After the above series this is no longer the case, the 'xcr0 == 0' + check has been removed from i386_linux_read_description and the + calling code is streamlined to remove the use of default xcr0 values. + + The fix I propose here is to setup the default xcr0 value at the point + where we find that PTRACE_GETREGSET is unavailable. The default value + used is X86_XSTATE_SSE_MASK. This is the default used in + x86_linux_nat_target::read_description (for GDB) and in + x86_linux_read_description (for gdbserver). The above commit series + already fixed i386_linux_core_read_description to ensure that the + correct default xcr0 value was used, this case is a little special in + that it uses different defaults depending on which sections are + present in the core file, so that case always needed to be handled + differently. + + The choice of X86_XSTATE_SSE_MASK corresponds to the default used for + i386 before the above series was committed. This mask includes the + X87 and SSE bits only, neither of these bits are checked for on amd64 + or x32, so this default doesn't change the behaviour on these targets. + + By setting the default xcr0 value at this early stage we ensure that + the cached xcr0 value on the gdbserver side is correct. This is + critical as this cached xcr0 value is passed through to the in process + agent (IPA). If we leave the cached xcr0 value as 0 and apply the + defaults later in the series we also have to encode the knowledge of + the default into the IPA, this just means we have the default encoded + in multiple locations, which seems like a bad idea. The approach used + in this patch means the default is present in just one location. + + This commit should fix the i386 regressions seen on the sourceware + buildbot. + + In addition to the fix in nat/x86-linux-tdesc.c I've also fixed the + layout of the declaration of x86_linux_tdesc_for_tid in the header + file. + + Approved-By: Felix Willgerodt + +2024-06-24 GDB Administrator + + Automatic date update in version.in + +2024-06-23 Andrew Carlotti + + aarch64: Enable +cssc for armv8.9-a + FEAT_CSSC is mandatory in the architecture from Armv8.9. + +2024-06-23 GDB Administrator + + Automatic date update in version.in + +2024-06-22 Simon Marchi + + gdb/testsuite: analyze-racy-logs.py cleanup + - Add type annotations + - Use a raw string in one spot (where we call re.sub), to avoid an + "invalid escape sequence" warning. + - Remove unused "os" import. + + Change-Id: I0149cbb73ad2b05431f032fa9d9530282cb01e90 + Reviewed-By: Guinevere Larsen + +2024-06-22 GDB Administrator + + Automatic date update in version.in + +2024-06-21 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.threads/stepi-over-clone.exp + On fedora rawhide, I ran into: + ... + (gdb) continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), 0x000000000042097d in __clone3 ()^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating a regexp to also recognize __clone3. + + Tested on x86_64-linux. + + Tested-By: Guinevere Larsen + +2024-06-21 Pedro Alves + + [gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux + When running test-case gdb.base/watchpoint-running on ppc64le-linux (and + similar on arm-linux), we get: + ... + (gdb) watch global_var^M + warning: Error when detecting the debug register interface. \ + Debug registers will be unavailable.^M + Watchpoint 2: global_var^M + (gdb) FAIL: $exp: all-stop: hardware: watch global_var + FAIL: $exp: all-stop: hardware: watchpoint hit (timeout) + ... + + The problem is that ppc_linux_dreg_interface::detect fails to detect the + hardware watchpoint interface, because the calls to ptrace return with errno + set to ESRCH. + + This is a feature of ptrace: if a call is done while the tracee is not + ptrace-stopped, it returns ESRCH. + + Indeed, in the test-case "watch global_var" is executed while the inferior is + running, and that triggers the first call to ppc_linux_dreg_interface::detect. + + And because the detection failure is cached, subsequent attempts at setting + hardware watchpoints will also fail, even if the tracee is ptrace-stopped. + + The way to fix this is to make sure that ppc_linux_dreg_interface::detect is + called when we know that the thread is ptrace-stopped, which in the current + setup is best addressed by using target-specific post_attach and + post_startup_inferior overrides. However, as we can see in + aarch64_linux_nat_target, that causes code duplication. + + Fix this by: + - defining a new target hook low_init_process, called from + linux_init_ptrace_procfs, which is called from both + linux_nat_target::post_attach and linux_nat_target::post_startup_inferior, + - adding implementations for ppc_linux_nat_target and arm_linux_nat_target + that detect the hardware watchpoint interface, + - replacing the aarch64_linux_nat_target implementations of post_attach and + post_startup_inferior with a low_init_process implementation. + + Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Luis Machado + + PR tdep/31834 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834 + PR tdep/31705 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705 + +2024-06-21 Jan Beulich + + x86: optimize {,V}PEXTR{D,Q} with immediate of 0 + Such are equivalent to simple moves, which are up to 3 bytes shorter to + encode (and perhaps also cheaper to execute). + +2024-06-21 Jan Beulich + + x86: optimize left-shift-by-1 + These can be replaced by adds when acting on a register operand. + + While for the scalar forms there's no gain in encoding size, ADD + generally has higher throughput than SHL. EFLAGS set by ADD are a + superset of those set by SHL (AF in particular is undefined there). + + For the SIMD cases the transformation also reduced code size, by + eliminating the 1-byte immediate from the resulting encoding. Note + that this transformation is not applied by gcc13 (according to my + observations), so would - as of now - even improve compiler generated + code. + +2024-06-21 Jan Beulich + + x86/APX: fix disassembly of byte register operands + Like for REX/REX2, EVEX-prefixed insns access the low bytes of all + registers; %ah...%bh are inaccessible. Reflect this correctly in output, + by leveraging REX machinery we already have to this effect. + + x86: %riz, %rip, and %eip don't require REX + While these can't be used as register operands, they can be used for + memory operand addressing. Such uses do not prevent conversion: The + RegRex64 checks in check_Rex_required() for base and index registers + were simply wrong. They specifically also aren't needed for byte + registers, as those won't pass i386_index_check() anyway. + + x86: don't suppress errors when optimizing + Blindly ignoring any mnemonic suffix can't be quite right: Bad suffix / + operand combinations still want flagging. Simply avoid optimizing in + such situations. + +2024-06-21 Jan Beulich + + gas: terminate buffer SB in do_repeat() + PR gas/31903 + + While elsewhere having realized that "one" doesn't point to a nul- + terminated string, it somehow didn't occur to me that the pre-existing + strstr() could have been wrong, and hence I blindly added a new use of + the function. Add the (already prior to 1e3c814459d8 ["gas: extend \+ + support to .rept"]) missing call to sb_terminate(), leveraging that to + simplify the other two places where the lack of nul termination was + previously worked around. + +2024-06-21 Feng Wang + + RISC-V: Remove implicit enablement of Zvknha from Zvkn. + Accroding to the Crypto spec, the Zvkned,Zvknhb,Zvkb and Zvkt are + included in the Zvkn. So the Zvknha should be removed from Zvkn. + + bfd/ChangeLog: + + * elfxx-riscv.c: Remove zvknha from zvkn. + +2024-06-21 GDB Administrator + + Automatic date update in version.in + +2024-06-20 Tom Tromey + + Handle "info symbol" in Rust language mode + When I changed the Rust parser to handle 128-bit ints, this + inadvertently broke some other gdb commands. For example, "info + symbol 0xffffffffffffffff" now fails, because the resulting value is + 128 bits, but this is rejected by extract_integer. + + This patch fixes the problem by changing extract_integer to allow + over-long integers as long as the high bytes are either 0, or (for + signed types) 0xff. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565 + Approved-By: Andrew Burgess + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-address.exp on arm + When running test-case gdb.python/py-format-address.exp on arm-linux, I get: + ... + (gdb) python print("Got: " + gdb.format_address(0x103dd))^M + Got: 0x103dd
^M + (gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \ + result should have an offset + ... + + What is expected here is: + ... + Got: 0x103dd ^M + ... + + Main starts at main_addr: + ... + (gdb) print /x &main^M + $1 = 0x103dc^M + ... + and we obtained next_addr 0x103dd by adding 1 to it: + ... + set next_addr [format 0x%x [expr $main_addr + 1]] + ... + + Adding 1 to $main_addr results in an address for a thumb function starting at + address 0x103dc, which is incorrect because main is an arm function (because + I'm running with target board unix/-marm). + + At some point during the call to format_addr, arm_addr_bits_remove removes + the thumb bit, which causes the +1 offset to be dropped, causing the FAIL. + + Fix this by using the address of the breakpoint on main, provided it's not at + the very start of main. + + Tested on arm-linux. + + PR testsuite/31452 + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31452 + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.base/watchpoint-unaligned.exp + When running test-case gdb.base/watchpoint-unaligned.exp on ppc64le-linux, we + get: + ... + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(4) + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(7) + ... + + Fix this by using foreach_with_prefix. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.opt/inline-cmds.exp + With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into: + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker + ... + + Fix this by issuing less passes. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/huge.exp + With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I + ran into a number of duplicates: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + DUPLICATE: gdb.fortran/huge.exp: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Fix this by wrapping the compile in a with_test_prefix, getting us instead: + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Tested on x86_64-linux. + +2024-06-20 Alan Modra + + Revert "Remove LIBINTL_DEP" + This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. + The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext. + +2024-06-20 Alan Modra + + Remove LIBINTL_DEP + The intl directory in the source no longer exists. LIBINTL_DEP is + thus always empty. Remove references to it. + + config/ + * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. + bfd/ + * Makefile.in: Regenerate. + * configure: Regenerate. + binutils/ + * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gas/ + * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gdb/ + * Makefile.in (INTL_DEPS): Don't set or reference. + * configure: Regenerate. + gdbserver/ + * Makefile.in (INTL_DEPS): Don't set or reference. + gdbsupport/ + * Makefile.in: Regenerate. + * configure: Regenerate. + gold/ + * Makefile.am (deps_var): Remove LIBINTL_DEP. + (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. + * Makefile.in: Regenerate. + * configure: Regenerate. + * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. + * testsuite/Makefile.in: Regenerate. + gprof/ + * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + ld/ + * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + libctf/ + * Makefile.in: Regenerate. + * configure: Regenerate. + opcodes/ + * configure.ac (BUILD_LIBS): Remove LIBINTL. + (BUILD_LIB_DEPS): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + +2024-06-20 Xi Ruoyao + + LoongArch: TLS IE needs only one dynamic reloc + As the comment in the code says, TLS_IE needs only one dynamic reloc. + But commit b67a17aa7c0c ("LoongArch: Fix the issue of excessive + relocation generated by GD and IE") has incorrectly allocated the space + for two dynamic relocs, causing libc.so to contain 8 R_LARCH_NONE. + + Adjust tlsdesc-dso.d for the offset changes and add two tests to ensure + there are no R_LARCH_NONE with TLS. + +2024-06-20 GDB Administrator + + Automatic date update in version.in + +2024-06-20 H.J. Lu + + ld: Remove JANSSON_LIBS from ld_new_DEPENDENCIES + Remove JANSSON_LIBS from ld_new_DEPENDENCIES since ld_new_DEPENDENCIES + should only contain binutils dependencies. + + PR ld/31909 + * Makefile.am (ld_new_DEPENDENCIES): Remove JANSSON_LIBS. + * Makefile.in: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/build] Redo poisoning of PyObject_CallMethod + In commit 764af878259 ("[gdb/python] Add typesafe wrapper around + PyObject_CallMethod") I added poisoning of PyObject_CallMethod: + ... + /* Poison PyObject_CallMethod. The typesafe wrapper gdbpy_call_method should be + used instead. */ + template + PyObject * + PyObject_CallMethod (Args...); + ... + + The idea was that subsequent code would be forced to use gdbpy_call_method + instead of PyObject_CallMethod. + + However, that caused build issues with gcc 14 and python 3.13: + ... + /usr/bin/ld: python/py-disasm.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, unsigned int, long long)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x384f): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, unsigned int, long long>(_object*, char*, char*, unsigned int, long long)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x1235): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int>(_object*, char*, char*, int)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int, int, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x12b0): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int, int, int>(_object*, char*, char*, int, int, int)' + collect2: error: ld returned 1 exit status + ... + + Fix this by poisoning without using templates. + + Tested on x86_64-linux. + +2024-06-19 Tom de Vries + + [gdb/symtab] Fix target type of complex long double on arm + When running test-case gdb.base/complex-parts.exp on arm-linux, I get: + ... + (gdb) p $_cimag (z3)^M + $6 = 6.5^M + (gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3) + ptype $^M + type = double^M + (gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $ + ... + + Given that z3 is a complex long double, the test-case expects the type of the + imaginary part of z3 to be long double, but it's double instead. + + This is due to the fact that the dwarf info doesn't specify an explicit target + type: + ... + <5b> DW_AT_name : z3 + <60> DW_AT_type : <0xa4> + ... + <1>: Abbrev Number: 2 (DW_TAG_base_type) + DW_AT_byte_size : 16 + DW_AT_encoding : 3 (complex float) + DW_AT_name : complex long double + ... + and consequently we're guessing in dwarf2_init_complex_target_type based on + the size: + ... + case 64: + tt = builtin_type (gdbarch)->builtin_double; + break; + case 96: /* The x86-32 ABI specifies 96-bit long double. */ + case 128: + tt = builtin_type (gdbarch)->builtin_long_double; + break; + ... + + For arm-linux, complex long double is 16 bytes, so the target type is assumed + to be 8 bytes, which is handled by the "case 64", which gets us double + instead of long double. + + Fix this by searching for "long" in the name_hint parameter, and using long + double instead. + + Note that base types in dwarf are not allowed to contain references to other + types, and the complex types are base types, so the missing explicit target + type is standard-conformant. + + A gcc PR was filed to add this as a dwarf extension ( + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ). + + Tested on arm-linux. + +2024-06-19 Nick Alcock + + libctf: fix testsuite bugs revealed by -Wall + Most of these are harmless, but some of the type confusions and especially + a missing ctf_strerror() on an error path were actual bugs that could + have resulted in test failures crashing rather than printing an error + message. + + libctf/ + * testsuite/libctf-lookup/enumerator-iteration.c: Fix type + confusion, signedness confusion and a missing ctf_errmsg(). + * testsuite/libctf-regression/libctf-repeat-cu-main.c: Return 0 from + the test function. + * testsuite/libctf-regression/open-error-free.c: Fix signedness + confusion. + * testsuite/libctf-regression/zrewrite.c: Remove unused label. + +2024-06-19 Lancelot SIX + + gdb/python/python-internal.h: avoid uninitialized constexpr + The following recent change introduced a regression when building using + clang++: + + commit 764af878259768bb70c65bdf3f3285c2d6409bbd + Date: Wed Jun 12 18:58:49 2024 +0200 + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + + The error message is: + + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + CXX python/py-block.o + 1 error generated. + make[2]: *** [Makefile:1959: python/py-arch.o] Error 1 + make[2]: *** Waiting for unfinished jobs.... + In file included from ../../gdb/python/py-auto-load.c:25: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + make[2]: *** [Makefile:1959: python/py-auto-load.o] Error 1 + In file included from ../../gdb/python/py-block.c:23: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + + This patch fixes this by changing gdbpy_method_format to be a templated + struct, and only have its specializations define the static constexpr + member "format". This way, we avoid having an uninitialized constexpr + expression, regardless of it being instantiated or not. + + Reviewed-By: Tom de Vries + Change-Id: I5bec241144f13500ef78daea30f00d01e373692d + +2024-06-19 Cui, Lili + + x86: Remove the secondary encoding for ctest. + There are two encodings for each opcode F6/F7 in ctest, but the second one + is never used, so remove it to reduce the size of opcode_tbl.h. + + opcodes/ChangeLog: + + * i386-opc.tbl: Removed the secondary insn template for ctest. + * i386-tbl.h: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x + On s390x-linux, I run into: + ... + (gdb) p (short []) s1^M + $3 = {0, 1, 0, }^M + (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + while this is expected: + ... + (gdb) p (short []) s1^M + $3 = {1, 0, 0, }^M + (gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + + The type of s1 is: + ... + (gdb) ptype s1 + type = struct S { + myint a; + myushort b; + } + ... + so the difference is due the fact that viewing an int as two shorts gives + different results depending on the endianness. + + Fix this by allowing both results. + + Tested on x86_64-linux and s390x-linux. + + Approved-By: Tom Tromey + +2024-06-19 Tom de Vries + + [gdb/testsuite] Add string cat for tcl version < 8.6.2 + I noticed that we started using "string cat", which has been available since + tcl version 8.6.2. + + Add a local implementation for use with older tcl versions. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-06-19 Tom de Vries + + [gdb/tdep] Simplify ARM_LINUX_JB_PC_EABI + In commit 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI"), in absense of + osabi settings for newlib and uclibc for arm, I chose a best-effort approach + using ifdefs. + + Post-commit review [1] pointed out that this may be causing more problems than + it's worth. + + Fix this by removing the ifdefs and simply defining ARM_LINUX_JB_PC_EABI to 1. + + Rebuild on x86_64-linux with --enable-targets=all. + + Fixes: 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI") + + [1] https://sourceware.org/pipermail/gdb-patches/2024-June/209779.html + +2024-06-19 GDB Administrator + + Automatic date update in version.in + +2024-06-18 Tom de Vries + + [gdb/build] Add GPL header comment to gdb/features/feature_to_c.awk + Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh") + factored out new file gdb/features/feature_to_c.awk out of + gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add + this now. + + Tested on x86_64-linux. + +2024-06-18 Nick Alcock + + libctf, include: new functions for looking up enumerators + Three new functions for looking up the enum type containing a given + enumeration constant, and optionally that constant's value. + + The simplest, ctf_lookup_enumerator, looks up a root-visible enumerator by + name in one dict: if the dict contains multiple such constants (which is + possible for dicts created by older versions of the libctf deduplicator), + ECTF_DUPLICATE is returned. + + The next simplest, ctf_lookup_enumerator_next, is an iterator which returns + all enumerators with a given name in a given dict, whether root-visible or + not. + + The most elaborate, ctf_arc_lookup_enumerator_next, finds all + enumerators with a given name across all dicts in an entire CTF archive, + whether root-visible or not, starting looking in the shared parent dict; + opened dicts are cached (as with all other ctf_arc_*lookup functions) so + that repeated use does not incur repeated opening costs. + + All three of these return enumerator values as int64_t: unfortunately, API + compatibility concerns prevent us from doing the same with the other older + enum-related functions, which all return enumerator constant values as ints. + We may be forced to add symbol-versioning compatibility aliases that fix the + other functions in due course, bumping the soname for platforms that do not + support such things. + + ctf_arc_lookup_enumerator_next is implemented as a nested ctf_archive_next + iterator, and inside that, a nested ctf_lookup_enumerator_next iterator + within each dict. To aid in this, add support to ctf_next_t iterators for + iterators that are implemented in terms of two simultaneous nested iterators + at once. (It has always been possible for callers to use as many nested or + semi-overlapping ctf_next_t iterators as they need, which is one of the + advantages of this style over the _iter style that calls a function for each + thing iterated over: the iterator change here permits *ctf_next_t iterators + themselves* to be implemented by iterating using multiple other iterators as + part of their internal operation, transparently to the caller.) + + Also add a testcase that tests all these functions (which is fairly easy + because ctf_arc_lookup_enumerator_next is implemented in terms of + ctf_lookup_enumerator_next) in addition to enumeration addition in + ctf_open()ed dicts, ctf_add_enumerator duplicate enumerator addition, and + conflicting enumerator constant deduplication. + + include/ + * ctf-api.h (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): Likewise. + (ctf_arc_lookup_enumerator_next): Likewise. + + libctf/ + * libctf.ver: Add them. + * ctf-impl.h (ctf_next_t) : New. + * ctf-util.c (ctf_next_copy): Copy it. + (ctf_next_destroy): Destroy it. + * ctf-lookup.c (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): New. + * ctf-archive.c (ctf_arc_lookup_enumerator_next): New. + * testsuite/libctf-lookup/enumerator-iteration.*: New test. + * testsuite/libctf-lookup/enum-ctf-2.c: New test CTF, used by the + above. + +2024-06-18 Nick Alcock + + include: libctf: comment improvements + Describe a bit more clearly what effects a type being non-root- + visible has. More consistently use the term non-root-visible + rather than hidden. Document ctf_enum_iter. + + include/ + * ctf-api.h (ctf_enum_iter): Document. + (ctf_type_iter): Hidden, not non-root. Mention that + parent dictionaries are not traversed. + +2024-06-18 Nick Alcock + + libctf: make the ctf_next ctn_fp non-const + This was always an error, because the ctn_fp routinely has errors set on it, + which is not something you can (or should) do to a const object. + + libctf/ + * ctf-impl.h (ctf_next_) : Make non-const. + +2024-06-18 Nick Alcock + + libctf: prohibit addition of enums with overlapping enumerator constants + libctf has long prohibited addition of enums with overlapping constants in a + single enum, but now that we are properly considering enums with overlapping + constants to be conflciting types, we can go further and prohibit addition + of enumeration constants to a dict if they already exist in any enum in that + dict: the same rules as C itself. + + We do this in a fashion vaguely similar to what we just did in the + deduplicator, by considering enumeration constants as identifiers and adding + them to the core type/identifier namespace, ctf_dict_t.ctf_names. This is a + little fiddly, because we do not want to prohibit opening of existing dicts + into which the deduplicator has stuffed enums with overlapping constants! + We just want to prohibit the addition of *new* enumerators that violate that + rule. Even then, it's fine to add overlapping enumerator constants as long + as at least one of them is in a non-root type. (This is essential for + proper deduplicator operation in cu-mapped mode, where multiple compilation + units can be smashed into one dict, with conflicting types marked as + hidden: these types may well contain overlapping enumerators.) + + So, at open time, keep track of all enums observed, then do a third pass + through the enums alone, adding each enumerator either to the ctf_names + table as a mapping from the enumerator name to the enum it is part of (if + not already present), or to a new ctf_conflicting_enums hashtable that + tracks observed duplicates. (The latter is not used yet, but will be soon.) + + (We need to do a third pass because it's quite possible to have an enum + containing an enumerator FOO followed by a type FOO: since they're processed + in order, the enumerator would be processed before the type, and at that + stage it seems nonconflicting. The easiest fix is to run through the + enumerators after all type names are interned.) + + At ctf_add_enumerator time, if the enumerator to which we are adding a type + is root-visible, check for an already-present name and error out if found, + then intern the new name in the ctf_names table as is done at open time. + + (We retain the existing code which scans the enum itself for duplicates + because it is still an error to add an enumerator twice to a + non-root-visible enum type; but we only need to do this if the enum is + non-root-visible, so the cost of enum addition is reduced.) + + Tested in an upcoming commit. + + libctf/ + * ctf-impl.h (ctf_dict_t) : Augment comment. + : New. + (ctf_dynset_elements): New. + * ctf-hash.c (ctf_dynset_elements): Implement it. + * ctf-open.c (init_static_types): Split body into... + (init_static_types_internal): ... here. Count enumerators; + keep track of observed enums in pass 2; populate ctf_names and + ctf_conflicting_enums with enumerators in a third pass. + (ctf_dict_close): Free ctf_conflicting_enums. + * ctf-create.c (ctf_add_enumerator): Prohibit addition of duplicate + enumerators in root-visible enum types. + + include/ + * ctf-api.h (CTF_ADD_NONROOT): Describe what non-rootness + means for enumeration constants. + (ctf_add_enumerator): The name is not a misnomer. + We now require that enumerators have unique names. + Document the non-rootness of enumerators. + +2024-06-18 Nick Alcock + + libctf: suppress spurious failure of malloc-counting tests under valgrind + The libctf-regression/open-error-free.c test works by interposing malloc + and counting mallocs and frees across libctf operations. This only + works under suitably-interposable mallocs on systems supporting + dlsym (RTLD_NEXT, ...), so its operation is restricted to glibc + systems for now, but also it interacts badly with valgrind, which + interposes malloc itself. Detect a running valgrind and skip the test. + + Add new facilities allowing libctf lookup tests to declare themselves + unsupported, by printing "UNSUPPORTED: " and then some meaningful + message instead of their normal output. + + libctf/ + * configure.ac: Check for . + * config.h.in: Regenerate. + * configure: Likewise. + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add support for + UNSUPPORTED tests. + * testsuite/libctf-regression/open-error-free.c: When running + under valgrind, this test is unsupported. + +2024-06-18 Nick Alcock + + libctf: fix dict leak on archive-wide symbol lookup error path + If a lookup fails for a reason unrelated to a lack of type data for this + symbol, we return with an error; but we fail to close the dict we opened + most recently, which is leaked. + + libctf/ + * ctf-archive.c (ctf_arc_lookup_sym_or_name): Close dict. + +2024-06-18 Nick Alcock + + libctf: don't leak enums if ctf_add_type fails + If ctf_add_type failed in the middle of enumerator addition, the + destination would end up containing the source enum type and some + but not all of its enumerator constants. + + Use snapshots to roll back the enum addition as a whole if this happens. + Before now, it's been pretty unlikely, but in an upcoming commit we will ban + addition of enumerators that already exist in a given dict, making failure + of ctf_add_enumerator and thus of this part of ctf_add_type much more + likely. + + libctf/ + * ctf-create.c (ctf_add_type_internal): Roll back if enum or + enumerator addition fails. + +2024-06-18 Nick Alcock + + libctf: dedup: enums with overlapping enumerators are conflicting + The CTF deduplicator was not considering enumerators inside enum types to be + things that caused type conflicts, so if the following two TUs were linked + together, you would end up with the following in the resulting dict: + + 1.c: + enum foo { A, B }; + + 2.c: + enum bar { A, B }; + + linked: + + enum foo { A, B }; + enum bar { A, B }; + + This does work -- but it's not something that's valid C, and the general + point of the shared dict is that it is something that you could potentially + get from any valid C TU. + + So consider such types to be conflicting, but obviously don't consider + actually identical enums to be conflicting, even though they too have (all) + their identifiers in common. This involves surprisingly little code. The + deduplicator detects conflicting types by counting types in a hash table of + hash tables: + + decorated identifier -> (type hash -> count) + + where the COUNT is the number of times a given hash has been observed: any + name with more than one hash associated with it is considered conflicting + (the count is used to identify the most common such name for promotion to + the shared dict). + + Before now, those identifiers were all the identifiers of types (possibly + decorated with their namespace on the front for enumerator identifiers), but + we can equally well put *enumeration constant names* in there, undecorated + like the identifiers of types in the global namespace, with the type hash + being the hash of each enum containing that enumerator. The existing + conflicting-type-detection code will then accurately identify distinct enums + with enumeration constants in common. The enum that contains the most + commonly-appearing enumerators will be promoted to the shared dict. + + libctf/ + * ctf-impl.h (ctf_dedup_t) : Extend comment. + * ctf-dedup.c (ctf_dedup_count_name): New, split out of... + (ctf_dedup_populate_mappings): ... here. Call it for all + * enumeration constants in an enum as well as types. + + ld/ + * testsuite/ld-ctf/enum-3.c: New test CTF. + * testsuite/ld-ctf/enum-4.c: Likewise. + * testsuite/ld-ctf/overlapping-enums.d: New test. + * testsuite/ld-ctf/overlapping-enums-2.d: Likewise. + +2024-06-18 Nick Alcock + + libctf: doc: fix ctf_stype_t typedef string in spec + +2024-06-18 Nick Alcock + + include: fix libctf ECTF_NOENUMNAM error message + ECTF_NOENUMNAM is emitted when enumerator constant names don't exist. + Call them that, not 'enum elements'. + + include/ + * ctf-api.h (ECTF_NOENUMNAM): fix error message. + +2024-06-18 Nick Alcock + + libctf: strtab corruption when strings are added to ctf_open()ed dicts + ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed + to return a strtab offset. These offsets are "provisional": the ref + mechanism records the address of the location in which the ref is stored and + modifies it when the strtab is finally written out. Provisional refs in new + dicts start at 0 and go up via strlen() as new refs are added: this is fine, + because the strtab is empty and none of these values will overlap any + existing string offsets (since there are none). Unfortunately, when a dict + is ctf_open()ed, we fail to set the initial provisional strtab offset to a + higher value than any existing string offset: it starts at zero again! + It's a shame that we already *have* strings at those offsets... + + This is all fixed up once the string is reserialized, but if you look up + newly-added strings before serialization, you get corrupted partial string + results from the existing ctf_open()ed dict. + + Observed (and thus regtested) by an upcoming test (in this patch series). + + Exposed by the recently-introduced series that permits modification of + ctf_open()ed dicts, which has not been released anywhere. Before that, + any attempt to do such things would fail with ECTF_RDONLY. + + libctf/ + * ctf-string.c (ctf_str_create_atoms): Initialize + ctf_str_prov_offset. + +2024-06-18 Jan Beulich + + readelf: rename recently added testsuite files + Files named *.0 are somewhat odd for testsuite expectations. Rename the + one such file to *.r with a suitable base name suffix, and have its + sibling follow suit in this latter regard. + +2024-06-18 Nelson Chu + + RISC-V: Fixed typo from smscrind to smcsrind in riscv_implicit_subsets. + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Fixed type from smscrind to + smcsrind. + gas/ + * testsuite/gas/riscv/march-imply-smcsrind.d: New testcase. It fails + without applying this patch. + +2024-06-18 Nick Clifton + + Ensure that the text segment is aligned on disk when using --rosegment. + +2024-06-18 Felix Willgerodt + Nils-Christian Kempke + + gdb: rename offset to high bits in ymm registers + The xsave_ymm_avx512_offset data structure contains the xsave + offset to the upper 128 bits of a ymm register. Similarly, for zmm this + offset is described by xsave_avx512_zmm_h_offset, h indicating the + high bits. This commit renames the xsave_ymm_avx512_offset to + xsave_ymm_h_avx512_offset - as well as the associated define from + XSAVE_YMM_AVX512_ADDR to XSAVE_YMM_H_AVX512_ADDR - to make this + more consistent. + + Note, that the regnum defines already included the 'h' for ymm, like + I387_YMM16H_REGNUM and I387_YMMH_AVX512_END_REGNUM. + + Approved-By: Andrew Burgess + +2024-06-18 Nelson Chu + + RISC-V: Updated gas/NEWS and gas/doc/c-riscv.texi for vendor extensions. + gas/ + * NEWS: Updated for XCvMem, XCvBi, XCvElw, XSfCease. + * doc/c-riscv.texi: Minor typo for XCv* extensions. + +2024-06-18 Hau Hsu + + RISC-V: Add SiFive cease extension v1.0 + Add SiFive cease extension, + https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf + + This aligns LLVM: + * https://llvm.org/docs/RISCVUsage.html + * https://github.com/llvm/llvm-project/pull/83896 + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_supported_vendor_x_ext): Add support for + 'xsfcease'. + (riscv_multi_subset_supports): Handle INSN_CLASS_XSFCEASE. + (riscv_multi_subset_supports_ext): Handle INSN_CLASS_XSFCEASE. + + gas/ChangeLog: + + * doc/c-riscv.texi: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/sifive-insns.d: Add test case for 'sf.cease'. + * testsuite/gas/riscv/sifive-insns.s: Likewise. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_SF_CEASE, MASK_SF_CEASE): Define match and + mask encoding for 'sf.cease'. + * opcode/riscv.h (INSN_CLASS_XSFCEASE): Add new instruction class for + 'xsfcease'. + + opcodes/ChangeLog: + + * riscv-opc.c (riscv_opcodes): Add opcode entry for 'sf.cease'. + +2024-06-18 Gianluca Guida + + RISC-V: Support Zacas extension. + https://github.com/riscvarchive/riscv-zacas/releases/tag/v1.0 + + The Zacas extension introduce compare-and-swap instructions to operate + on 32-bit, 64-bit and 128-bit (RV64 only) data values. + + It introduces three new instructions: + - amocas.w (32-bit CAS) + - amocas.d (64-bit CAS) + - amocas.q (128-bit CAS, RV64 only) + + Like other AMOs in the A extension, Zacas instructions have '.aq', + '.rl' and '.aqrl' variations. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): 'A' implied by 'Zacas'. + (riscv_supported_std_z_ext): Add 'Zacas' extension. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): + Handle INSN_CLASS_ZACAS case. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zacas-32.d: New test (RV32). + * testsuite/gas/riscv/zacas-fail-32.d: Likewise. + * testsuite/gas/riscv/zacas-64.d: New test (RV64). + * testsuite/gas/riscv/zacas-fail-64.d: Likewise. + * testsuite/gas/riscv/zacas.s: New test source. + * testsuite/gas/riscv/zacas-fail.s: Likewise. + * testsuite/gas/riscv/zacas-fail-32.l: New file. + * testsuite/gas/riscv/zacas-fail-64.l: Likewise. + + include/ChangeLog: + + * include/opcode/riscv.h (INSN_CLASS_ZACAS): New definition. + * include/opcode/riscv-opc.h (MATCH_AMOCAS_W, MASK_AMOCAS_W) + (MATCH_AMOCAS_D, MASK_AMOCAS_D, MATCH_AMOCAS_Q, MASK_AMOCAS_Q): + Likewise. + (amocas_w, amocas_d, amocas_q): Declare instructions. + + opcodes/ChangeLog: + + * riscv-opc.c (match_rs2_rd_even): New function. + (amocas_w, amocas_d, amocas_q, amocas_w.aq) + (amocas_d.aq, amocas_q.aq, amocas_w.rl, amocas_d.rl, amocas_q.rl) + (amocas_w.aqrl, amocas_d.aqrl, amocas_q.aqrl): Add instructions. + +2024-06-18 Cui, Lili + + x86: Fix typo in i386-dis-evex-mod.h + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Used MOD_EVEX_MAP4_F8_P_1/MOD_EVEX_MAP4_F8_P_3 + instead of MOD_EVEX_MAP4_F8_P1/MOD_EVEX_MAP4_F8_P3. + +2024-06-18 Cui, Lili + + Remove %ME and used %NE for movbe. + %ME is added specifically for movbe. Now with %NE, we can use + MOD table + %NE to indicate whether a {evex} prefix is needed. + + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Added movbe. + * i386-dis-evex.h: Let movbe go through the mod table. + * i386-dis.c (struct dis386): Removed %ME. + (putop): Removed case ME. + +2024-06-18 Cui, Lili + + Support APX CCMP and CTEST + CCMP and CTEST are two new sets of instructions for conditional CMP + and TEST, SCC and OSZC flags are given as suffixes of CCMP or CTEST + in the instruction mnemonic, e.g.: + + ccmp { dfv=sf , cf , of } %eax, %ecx + + also add + + {evex} cmp/test %eax, %ecx + + as an alias for ccmpt. + + For the encoder part, add function check_Scc_OszcOperation to parse + '{ dfv=of , sf, sf, cf}', store scc in the lower 4 bits of base_opcode, + and adjust base_opcode to its normal meaning in install_template. + + For the decoder part, add 'SC' and 'DF' macros to add scc and oszc flags + suffixes. + + gas/ChangeLog: + + * config/tc-i386.c (OSZC_CF): New. + (OSZC_ZF): Ditto. + (OSZC_SF): Ditto. + (OSZC_OF): Ditto. + (set_oszc_flags): Set oszc flags and report error for using the same oszc flags twice. + (check_Scc_OszcOperations): Handle SCC OSZC flags. + (install_template): Add scc and oszc_flags. + (build_apx_evex_prefix): Encode SCC and oszc flags bits. + (parse_insn): Handle check_Scc_OszcOperations. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add ivalid test case. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add test for ccmp and ctest. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.d: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-reg.h: Add ccmp and ctest. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct instr_info): add scc. + (struct dis386): Add new micro 'NE','SC' and'DF'. + (get_valid_dis386): Get scc value and move MAP4 invalid check to print_insn. + (putop): Handle %NE, %SC and %DF. + * i386-opc.h (SCC): New. + * i386-opc.tbl: Add ccmp/ctest and evex format for cmp/test. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-06-18 Lulu Cai + + LoongArch: add .option directive + In some cases we may want to use different options only for certain + assembly, so the .option directive is added to control the assembler + options. + + .option can accept 4 parameters: + + push + pop + Pushes or pops the current option stack. They limit the scope of + option changes so that they do not affect other parts of the assembly + file. + + relax + norelax + Enables or disables relaxation. + +2024-06-18 GDB Administrator + + Automatic date update in version.in + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Make a copy of none.s before operating on it as output + The "Output file must be distinct from input" test in gas/all/gas.exp + operates on none.s as output. Should the test fail it may happen that + GAS will delete the output file requested in which case none.s will be + removed. Since the test operates directly on the source tree it will be + clobbered as a result. It has actually been observed in the field in + the form of intermittent: + + FAIL: gas/all/none + + regressions in a parallel run of many configurations. + + Prevent this from happening by copying none.s first to the test object + directory and operating on it instead. It does not prevent the file + from being removed should the test fail, but the source tree won't be + clobbered in that case. + + A nice side effect is that syntactically different paths will now be + used in this test for the input and the output file each, so coverage + will extend to verifying that a file is checked against itself even if + referred to via different paths. Previously "$srcdir/$subdir/none.s" + was used for both paths and now "tmpdir/none.s" is referred to directly + and via a relative path from "$srcdir/$subdir" respectively. + + I note that we have no previous use of the UNRESOLVED test result in the + GAS testsuite, but it seems the correct one should copying none.s fail, + as this is an unexpected situation that requires a human intervention + and the test proper has not been evaluated. + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Add a helper for paths outside the source dir + Implement a helper to construct a relative path from $srcdir/$subdir, + where `gas_run' operates, to an arbitrary place in the filesystem, for + example a file in the test object directory. + +2024-06-17 Maciej W. Rozycki + + binutils/testsuite: Add a helper for relative path construction + Implement a helper to construct a relative path between two locations in + the filesystem, for example to make a path from the source to the object + directory for the case where a tool has been set up to look at a given + path and there is a need to point it elsewhere, but an absolute path + will not work. The helper works on normalized paths internally, so the + result is correct even in the presence of symlinks as intermediate path + components. + + So given "/path/to/src/gas/testsuite/gas/all" as the FROM argument and + then "/path/to/obj/gas/testsuite/tmpdir/none.s" as the TO argument the + helper will return "../../../../../obj/gas/testsuite/tmpdir/none.s" in + the absence of symlinks. + +2024-06-17 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/array-{indices,repeat}.exp + When running test-case gdb.fortran/array-indices.exp on a system without + fortran compiler, I run into a duplicate: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp + ... + + Fix this by adding a with_test_prefix at the toplevel. + + Likewise in gdb.fortran/array-repeat.exp. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-17 Alan Modra + + PR31898 bug in processing DW_RLE_startx_endx + PR 31898 + * dwarf.c (display_debug_rnglists_list): Correct fetch of "end" + indexed address. Remove excess parens. + +2024-06-17 Alan Modra + + Error messages emitted during bfd_check_format_matches + Error/warning messages are only printed for the target that + successfully matched, which makes sense for warnings, but not so much + for errors where the errors cause no target to match. I noticed this + when looking at the pr20520 testcase again with objdump, which just + reports "file format not recognized" omitting the five "SHT_GROUP + section [index n] has no SHF_GROUP sections" messages. They are + omitted because multiple ELF targets match the object file. This is + going to be true for all ELF objects due to at least the proper ELF + target and the generic ELF target matching. + + * format.c (print_and_clear_messages): Print messages if all + targets with messages have exactly the same set of messages. + +2024-06-17 GDB Administrator + + Automatic date update in version.in + +2024-06-16 Tom Tromey + + Make tui_register_info::highlight private + This changes tui_register_info::highlight to be private, renaming it + to m_highlight. + +2024-06-16 GDB Administrator + + Automatic date update in version.in + +2024-06-15 Tom Tromey + + Remove a call to fflush + This TUI code calls fflush on stdout, but I don't believe this is + useful in gdb. + +2024-06-15 Tom de Vries + + [gdb/build] Cleanup gdb/features/feature_to_c.sh + Clean up script gdb/features/feature_to_c.sh by: + - fixing shellcheck warnings, + - moving an embedded awk script out of the file, reducing the amount of + escaping in the awk script, making it more readable and maintainable, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up lib/dg-add-core-file-count.sh + Fix shellcheck warnings in script lib/dg-add-core-file-count.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up formatting in gdb/contrib/cc-with-tweaks.sh + In emacs, on gdb/contrib/cc-with-tweaks.sh, do: + - M-x whitespace-cleanup, + - M-x mark-whole-buffer and M-x indent-region, and + - and undo the unwanted changes in the header comment. + + Only whitespace changes. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/cc-with-tweaks.sh + Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/expect-read1.sh + Clean up script gdb/contrib/expect-read1.sh by: + - fixing shellcheck warnings, + - using mktemp (which takes TMPDIR into account) instead of a hardcoded + "/tmp/expect-read1.$$.so", + - adding comments, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 GDB Administrator + + Automatic date update in version.in + +2024-06-14 H.J. Lu + + x86: Add -z isa-level-report=[none|all|needed|used] + Add -z isa-level-report=[none|all|needed|used] to the x86 ELF linker to + report needed and used x86-64 ISA levels. + + bfd/ + + PR ld/31868 + * elf-linker-x86.h (elf_x86_isa_level_report): New. + (elf_linker_x86_params): Add isa_level_report. + * elfxx-x86.c (report_isa_level): New. + (_bfd_x86_elf_link_setup_gnu_properties): Check + -z isa-level-report=[none|all|needed|used] to report needed and + used x86-64 ISA level. + + ld/ + + PR ld/31868 + * NEWS: Mention -z isa-level-report=[none|all|needed|used]. + * ld.texi: Document -z isa-level-report=[none|all|needed|used]. + * emulparams/elf32_x86_64.sh: Source x86-64-level-report.sh. + * emulparams/elf_i386.sh: Likewise. + * emulparams/elf_x86_64.sh: Likewise. + * emulparams/x86-64-level-report.sh: New file. + * testsuite/ld-i386/pr31868a.d: Likewise. + * testsuite/ld-i386/pr31868b.d: Likewise. + * testsuite/ld-i386/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868a-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868a.d: Likewise. + * testsuite/ld-x86-64/pr31868a.l: Likewise. + * testsuite/ld-x86-64/pr31868a.s: Likewise. + * testsuite/ld-x86-64/pr31868b-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868b.d: Likewise. + * testsuite/ld-x86-64/pr31868b.l: Likewise. + * testsuite/ld-x86-64/pr31868b.s: Likewise. + * testsuite/ld-x86-64/pr31868c-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868c.l: Likewise. + * testsuite/ld-i386/i386.exp: Run PR ld/31868 tests. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + +2024-06-14 H.J. Lu + + ld: Align --no-error-execstack help output + * lexsup.c (elf_static_list_options): Align --no-error-execstack + help output. + +2024-06-14 Tom Tromey + + Simplify ada_lookup_encoded_symbol + This patch simplifies ada_lookup_encoded_symbol by having it return + its result, rather than returning void and having an out parameter. + + Introduce language_defn::lookup_symbol_local + This introduces the new method language_defn::lookup_symbol_local, and + then changes lookup_symbol_local to use it. This removes an explicit + language check from this function, and makes it easier for other + languages to hook into this code. + + Remove an unnecessary null check from lookup_local_symbol + lookup_local_symbol checks whether 'function' is null before calling + block::inlined_p, but this is not necessary. + + Simplify lookup_local_symbol + This simplifies lookup_local_symbol a little, by having it check + whether the current block is the static or global block, instead of + first searching for the static block. + +2024-06-14 Tom Tromey + + Examine template symbols in lookup_local_symbol + This changes lookup_local_symbol to directly examine any attached + template symbols, rather than gating this lookup on the use of C++ or + Fortran. As mentioned in an earlier patch, these objects are not + necessarily C++-specific, and doing the search generically seems + better. + + This also renames cp_lookup_symbol_imports_or_template now that the + "template" part has been removed. + +2024-06-14 Tom Tromey + + Move search_symbol_list to symtab.c + This moves search_symbol_list to symtab.c and exports it. It will be + useful in a later patch. + + Rename is_cplus_template_function + This patch renames is_cplus_template_function to is_template_function. + There is nothing C++-specific about this code, and the code in the + DWARF reader that creates these objects is not C++-specific. In fact + this may already be used by Rust (though I didn't check). + +2024-06-14 Matthieu Longo + + aarch64: add SPMU system registers missed in f01ae0392ed + +2024-06-14 Andrew Burgess + + gdb/aarch64: prevent crash from in process agent + Since this commit: + + commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d + Date: Wed May 18 13:32:04 2022 -0700 + + Use aarch64_features to describe register features in target descriptions. + + There has been an issue with how aarch64 target descriptions are + cached within gdbserver, and specifically, how this caching impacts + the in process agent (IPA). + + The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is + part of the IPA, this function is a constructor function, i.e. is + called as part of the global initialisation process. We can't + guarantee the ordering of when this function is called vs when other + global state is initialised. + + Now initialize_tracepoint_ftlib calls initialize_tracepoint, which + calls initialize_low_tracepoint, which for aarch64 calls + aarch64_linux_read_description. + + The aarch64_linux_read_description function lives in + linux-aarch64-tdesc.cc and after the above commit, depends on a + std::unordered_map having been initialized. + + Prior to the above commit aarch64_linux_read_description used a global + C style array, which obviously requires no runtime initialization. + + The consequence of the above is that any inferior linked with the IPA + (for aarch64) will experience undefined behaviour (access to an + uninitialized std::unordered_map) during startup, which for me + manifests as a segfault. + + I propose fixing this by moving the std::unordered_map into the + function body, but leaving it static. The map will now be initialized + the first time the function is called, which removes the undefiend + behaviour. + + The same problem exists for the expedited_registers global, however + this global can just be made into a function local instead. The + expedited_registers variable is used to build a pointer list which is + then passed to init_target_desc, however init_target_desc copies the + values it is given so expedited_registers does not need to live longer + than its containing function. + + On most of the AArch64 machines I have access too tracing is not + supported, and so the gdb.trace/*.exp tests that use the IPA just exit + early reporting unsupported. I've added a test which links an + inferior with the IPA and just starts the inferior. No tracing is + performed. This exposes the current issue even on hosts that don't + support tracing. After this patch the test passes. + +2024-06-14 Nick Clifton + + Regenerate configure files in ld sub-directory + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into the + gdb/arch/ directory and combine them so we have just a single copy of + each. Then GDB, gdbserver, and the in-process-agent (IPA) will link + against these shared functions. + + One curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, there is some + additional configuration that is performed as each target description + is created, to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + An alternative approach that avoids adding x86_linux_post_init_tdesc + would be to have x86_linux_tdesc_for_tid return a non-const target + description, then in x86_target::low_arch_setup we could inspect the + target description to figure out if it is 64-bit or not, and modify + the target description as needed. In the end I think that adding the + x86_linux_post_init_tdesc function is the simpler solution. + + The contents of gdbserver/linux-x86-low.cc have moved to + gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h + has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to + some updates in the #includes in the gdbserver/ directory. + + This commit also changes how target descriptions are cached. + Previously both GDB and gdbserver used static C-style arrays to act as + the tdesc cache. This was fine, except for two problems. Either the + C-style arrays would need to be placed in x86-linux-tdesc-features.c, + which would allow us to use the x86_linux_*_tdesc_count_1() functions + to size the arrays for us, or we'd need to hard code the array sizes + using separate #defines, which we'd then have to keep in sync with the + rest of the code in x86-linux-tdesc-features.c. + + Given both of these problems I decided a better solution would be to + just switch to using a std::unordered_map to act as the cache. This + will resize automatically, and we can use the xcr0 value as the key. + + At first inspection, using xcr0 might seem to be a problem; after all + the {i386,amd64}_create_target_description functions take more than + just the xcr0 value. However, this patch is only for x86/Linux + targets, and for x86/Linux all of the other flags passed to the tdesc + creation functions have constant values and so are irrelevant when we + consider tdesc caching. + + For testing I've done the following: + + - Built on x86-64 GNU/Linux for all targets, and just for the native + target, + + - Build on i386 GNU/Linux for all targets, and just for the native + target, + + - Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the + native target, and for targets x86_64-*-linux and i386-*-linux. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring earlier in this series the shared + x86_linux_tdesc_for_tid function was added into nat/x86-linux-tdesc.c. + However, this function still relies on amd64_linux_read_description + and i386_linux_read_description which are implemented separately for + both gdbserver and GDB. Given that at their core, all these functions + do is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + Despite using the same {amd64,i386}_create_target_description + functions in both GDB and gdbserver to create the target descriptions, + on the gdbserver side we cache target descriptions based on a reduced + set of xcr0 feature bits. + + What this means is that, in theory, different xcr0 values can map to + the same cache entry, which could result in the wrong target + description being used. + + However, I'm not sure if this can actually happen in reality. Within + gdbserver we already split the target description cache based on i386, + amd64, and x32. I suspect within a given gdbserver session we'll only + see at most one target description for each of these. + + The cache conflicting problem is caused by xcr0_to_tdesc_idx, which + maps an xcr0 value to a enum x86_linux_tdesc value, and there are only + 7 usable values in enum x86_linux_tdesc. + + In contrast, on the GDB side there are 64, 32, and 16 cache slots for + i386, amd64, and x32 respectively. + + On the GDB side it is much more important to cache things correctly as + a single GDB session might connect to multiple different remote + targets, each of which might have slightly different x86 + architectures. + + And so, if we want to merge the target description caching between GDB + and gdbserver, then we need to first update gdbserver so that it + caches in the same way as GDB, that is, it needs to adopt a mechanism + that allows for the same number of cache slots of each of i386, amd64, + and x32. In this way, when the caching is shared, GDB's behaviour + will not change. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use, the IPA having first generated every possible target + description. + + Interestingly, there is certainly a bug here which results from only + having 7 values in enum x86_linux_tdesc. As multiple possible target + descriptions in gdbserver map to the same enum x86_linux_tdesc value, + then, when the enum x86_linux_tdesc value is sent to the IPA there is + no way for gdbserver to know that the IPA will select the correct + target description. This bug will get fixed by this commit. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach of sending a target + description index made perfect sense. However since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think that passing an index was probably a bad idea. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use, the target description was + not generated until the index arrived. + + However, the above commit fixed an issue where we can't call malloc() + within (certain parts of) the IPA (apparently), so instead we now + pre-compute _every_ possible target description within the IPA. The + index is only used to lookup which of the (many) pre-computed target + descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + I did look at how a process might derive its own xcr0 value, but I + don't believe this is actually that simple, so for now I've just + doubled down on the index passing approach. + + While reviewing earlier iterations of this patch there has been + discussion about the possibility of removing the IPA from GDB. That + would certainly make all of the code touched in this patch much + simpler, but I don't really want to do that as part of this series. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so, and that's what I've + assumed in this commit. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of xcr0 features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + choose the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they cache target descriptions + using the same set of xcr0 features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series have done. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit(s) can merge the GDB and + gdbserver versions of these functions. + + Notes On The Implementation + --------------------------- + + Previously, within gdbserver, target descriptions were cached within + arrays. These arrays were sized based on enum x86_linux_tdesc and + xcr0_to_tdesc_idx returned the array (cache) index. + + Now we need different array lengths for each of i386, amd64, and x32. + And the index to use within each array is calculated based on which + xcr0 bits are set and valid for a particular target type. + + I really wanted to avoid having fixed array sizes, or having the set + of relevant xcr0 bits encoded in multiple places. + + The solution I came up with was to create a single data structure + which would contain a list of xcr0 bits along with flags to indicate + which of the i386, amd64, and x32 targets the bit is relevant for. By + making the table constexpr, and adding some constexpr helper + functions, it is possible to calculate the sizes for the cache arrays + at compile time, as well as the bit masks needed to each target type. + + During review it was pointed out[1] that possibly the failure to check + the SSE and X87 bits for amd64/x32 targets might be an error, however, + if this is the case then this is an issue that existed long before + this patch. I'd really like to keep this patch focused on reworking + the existing code and try to avoid changing how target descriptions + are actually created, mostly out of fear that I'll break something. + + [1] https://inbox.sourceware.org/gdb-patches/MN2PR11MB4566070607318EE7E669A5E28E1B2@MN2PR11MB4566.namprd11.prod.outlook.com + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things mostly the GDB way, some changes are + needed to allow for the sharing; we now take some pointers for where + the shared code can cache the xcr0 and xsave layout values. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are + left where they are. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Reviewed-By: Felix Willgerodt + Acked-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb: move xcr0 == 0 check into i386_linux_core_read_description + Currently, in i386_linux_core_read_description, if GDB fails to + extract an xcr0 value from the core file, then we will have a default + zero value for the xcr0 variable, we still call the + i386_linux_read_description function, which checks for this zero value + and returns nullptr. + + Back in i386_linux_core_read_description we spot the nullptr return + value from i386_linux_read_description and call + i386_linux_read_description again, but this time passing a default + value for xcr0. + + In the next commit I plan to rework i386_linux_read_description, and + in so doing I will remove the check for xcr0 == 0, this is inline with + how the amd64 code is written. + + However, this means that the 'xcr0 == 0' check needs to move up the + stack to i386_linux_core_read_description, again, this brings the i386 + code into line with the amd64 code. + + This is just a refactor in preparation for the next commit, there + should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim sharing the x86 Linux + target description creation code between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes (gdbserver relies on reading the file being debugged, and + extracting similar information from the file headers). + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code can be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb: move have_ptrace_getregset declaration into gdb/nat directory + In a later commit I want to access have_ptrace_getregset from a .c + file in the nat/ directory. To achieve this I need access to the + declaration of have_ptrace_getregset. + + Currently have_ptrace_getregset is declared (and defined) twice, once + in GDB and once in gdbserver. + + This commit moves the declaration into nat/linux-nat.h, but leaves the + two definitions where they are. Now, in my later commit, I can pull + in the declaration from nat/linux-nat.h. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory + The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is + running on a kernel that supports the GETFPXREGS ptrace request. + + Currently this global is declared twice (once in GDB and once in + gdbserver), I think it makes sense to move this global into the nat/ + directory, and have a single declaration and definition. + + While moving this variable I have converted it to a tribool, as that + was what it really was, if even used the same numbering as the tribool + enum (-1, 0, 1). Where have_ptrace_getfpxregs was used I have updated + in the obvious way. + + However, while making this change I noticed what I think is a bug in + x86_linux_nat_target::read_description and x86_linux_read_description, + both of these functions can be called multiple times, but in both + cases we only end up calling i386_linux_read_description the first + time through in the event that PTRACE_GETFPXREGS is not supported. + This is because initially have_ptrace_getfpxregs will be + TRIBOOL_UNKNOWN, but after the ptrace call fails we set + have_ptrace_getfpxregs to TRIBOOL_FALSE. The next time we attempt to + read the target description we'll skip the ptrace call, and so skip + the call to i386_linux_read_description. + + I've not tried to address this preexisting bug in this commit, this is + purely a refactor, there should be no user visible changes after this + commit. In later commits I'll merge the gdbserver and GDB code + together into the nat/ directory, and after that I'll try to address + this bug. + + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit moves the definition into gdbsupport/x86-xstate.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 GDB Administrator + + Automatic date update in version.in + +2024-06-13 Tom Tromey + + Add gdbpy_call_method overloads for gdbpy_ref<> + This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>. + This is just a small convenience. + + Reviewed-By: Tom de Vries + +2024-06-13 Tom Tromey + + Return gdbpy_ref<> from gdbpy_call_method + This changes gdbpy_call_method to return a gdbpy_ref<>. This is + slightly safer because it makes it simpler to correctly handle + reference counts. + + Reviewed-By: Tom de Vries + +2024-06-13 Nick Clifton + + Adjust linker tests that are sensitive to --rosegment + +2024-06-13 Tom de Vries + + [gdb/testsuite] Add gdb.base/fission-macro.exp + Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT + macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc + produces a usable dwarf-5 32-bit .debug_macro.dwo section. + + Add a test-case excercising this. + + Tested on x86_64-linux. + + Tested test-case using a current gcc trunk build, and gcc 14. + +2024-06-13 Tom de Vries + + [gdb/testsuite] Fix kfail number in gdb.base/watchpoint-running.exp + Test-case gdb.base/watchpoint-running.exp reports the following kfail: + ... + KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111) + ... + but the referenced gdb PR doesn't exist. + + Fix this by using an actual PR. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833 + +2024-06-13 Nick Clifton + + Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. + PR 30907 + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Rework INSN_* flags into a consistent block + For historic reasons we have ended up with a random set of discontiguous + bit assignments for INSN_* flags within `membership' and `exclusions' + members of `mips_opcode'. Some of the bits were previously used for ASE + assignments and have been reused in a disorganised fashion since `ase' + has been split off as a member on its own. It makes them hard to track + and maintain, and to see how many we still have available for future + assignments. + + Therefore reorder the flags using consecutive bits and matching the + order used with the switch statement in `cpu_is_member'. + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Update INSN_CHIP_MASK for INSN_ALLEGREX + An update has been missed with commit df18f71b565c ("Add MIPS Allegrex + CPU as a MIPS2-based CPU") for INSN_CHIP_MASK to include INSN_ALLEGREX. + Fix it. + +2024-06-13 GDB Administrator + + Automatic date update in version.in + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_STOKEN macro + This removes the LS_TOKEN_STOKEN macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_KEYWORD macro + This removes the LS_TOKEN_KEYWORD macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STREAM macro + This removes the PARSER_STREAM macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_EXPLICIT macro + This removes the PARSER_EXPLICIT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_RESULT macro + This removes the PARSER_RESULT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STATE macro + This removes the PARSER_STATE macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom de Vries + + [gdb/testsuite] Fix error in gdb.server/server-kill-python.exp + With test-case gdb.server/server-kill-python.exp, I sometimes run into: + ... + builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \ + -data-directory data-directory^M + kill^M + (gdb) kill^M + file server-kill-python^M + The program is not being run.^M + (gdb) ERROR: Couldn't load server-kill-python into GDB. + ... + + The problem is that the spawn produces a prompt, but it's not explicitly + consumed. + + This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify + gdb.server/server-kill-python.exp"). + + Fix this by consuming the initial prompt. + + PR testsuite/31819 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819 + Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp" + +2024-06-12 Tom Tromey + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + In gdb/python/py-tui.c we have code like this: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll", + "i", num_to_scroll, nullptr)); + ... + + The nullptr is superfluous, the format string already indicates that there's + only one method argument. + + OTOH, passing no method args does use a nullptr: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render", + nullptr)); + ... + + Furthermore, choosing the right format string chars can be tricky. + + Add a typesafe wrapper around PyObject_CallMethod that hides these + details, such that we can use the more intuitive: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll", + num_to_scroll)); + ... + and: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render")); + ... + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Tom Tromey + +2024-06-12 Claudio Bantaloukas + + aarch64: add Branch Record Buffer extension instructions + The FEAT_BRBE extension provides two aliases of sys: + - brb iall (Invalidates all Branch records in the Branch Record Buffer) + - brb inj (Injects the Branch Record held in BRBINFINJ_EL1, + BRBSRCINJ_EL1, and BRBTGTINJ_EL1 into the Branch Record Buffer) + + This patch adds: + - the feature option "brbe" that must be added for the aliases to be available + - a new operand flag AARCH64_OPND_Rt_IN_SYS_ALIASES that warns in a comment + when Rt is set to the non default value 0b11111 (it is constrained + unpredictable whether the instruction is undefined or behaves as if the Rt + field is set to 0b11111). + - a new operand flag AARCH64_OPND_BRBOP that encodes and decodes Op2 values + from bit 5 + - support for the two brb aliases above + + See: + - https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/BRB--Branch-Record-Buffer--an-alias-of-SYS-?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-INJ--Branch-Record-Injection-into-the-Branch-Record-Buffer?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-IALL--Invalidate-the-Branch-Record-Buffer?lang=en + +2024-06-12 Hannes Domani + + Allow calling of user-defined function call operators + Currently it's not possible to call user-defined function call + operators, at least not without specifying operator() directly: + ``` + (gdb) l 1 + 1 struct S { + 2 int operator() (int x) { return x + 5; } + 3 }; + 4 + 5 int main () { + 6 S s; + 7 + 8 return s(23); + 9 } + (gdb) p s(10) + Invalid data type for function to be called. + (gdb) p s.operator()(10) + $1 = 15 + ``` + + This now looks if an user-defined call operator is available when + trying to 'call' a struct value, and calls it instead, making this + possible: + ``` + (gdb) p s(10) + $1 = 15 + ``` + + The change in operation::evaluate_funcall is to make sure the type + fields are only used for function types, only they use them as the + argument types. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213 + Approved-By: Tom Tromey + +2024-06-12 Alexandra Hájková + + Add "error_message+" feature to qSupported + Add a new 'error_message' feature to the qSupported packet. When GDB + supports this feature then gdbserver is able to send + errors in the E.errtext format for the qRcmd and m packets. + + Update qRcmd packet and m packets documentation as qRcmd newly + accepts errors in a E.errtext format. + Previously these two packets didn't support E.errtext style errors. + + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2024-06-12 A. Wilcox + + PR 31882 libctf: test suite incorrect format specifiers + +2024-06-12 Jiawei + + RISC-V: Support S[sm]csrind extension csrs. + This patch supports RISC-V Smcsrind/Sscsrind privilege extension csrs. + Reuse csr 'smselect/siselect', 'mireg/sireg' and 'vsiselect,vsireg' csrs + in Smaia/Ssaia extension. + + bfd/ChangeLog: + + * elfxx-riscv.c: New extensions. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (enum riscv_csr_class): New extensions. + (riscv_csr_address): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New csrs. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extensions. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MIREG2): New csr. + (CSR_MIREG3): Ditto. + (CSR_MIREG4): Ditto. + (CSR_MIREG5): Ditto. + (CSR_MIREG6): Ditto. + (CSR_SIREG2): Ditto. + (CSR_SIREG3): Ditto. + (CSR_SIREG4): Ditto. + (CSR_SIREG5): Ditto. + (CSR_SIREG6): Ditto. + (CSR_VSIREG2): Ditto. + (CSR_VSIREG3): Ditto. + (CSR_VSIREG4): Ditto. + (CSR_VSIREG5): Ditto. + (CSR_VSIREG6): Ditto. + (DECLARE_CSR): Ditto. + +2024-06-12 GDB Administrator + + Automatic date update in version.in + +2024-06-11 Andrew Burgess + + gdb: convert separate-debug-file to new(ish) debug scheme + Convert 'set/show debug separate-debug-file' to the new debug scheme. + Though I'm not sure if we can really call it "new" any more! + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: warn of slow remote file reading only after a successful open + While working on a later patch in this series, I noticed that GDB + would print the message: + + Reading /path/to/file from remote target... + + Even when /path/to/file doesn't exist on the remote target. + + GDB does indeed try to open /path/to/file, but I'm not sure we really + need to tell the user unless we actually manage to open the file, and + plan to read content from it. + + If we consider how GDB probes for separate debug files, we can attempt + to open multiple possible files, most of them will not exist. When we + are native debugging we don't bother telling the user about each file + we're checking for, we just announce any file we finally use. + + I think it makes sense to do a similar thing for remote files. + + So, in remote_target::remote_hostio_open(), I'd like to move the block + of code that prints the above message to after the open call has been + made, and we should only print the message if the open succeeds. + + Now GDB only tells the user about files that we actually open and read + from the remote. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: avoid duplicate search in build_id_to_bfd_suffix + In build_id_to_bfd_suffix we look in each debug-file-directory for a + file matching the required build-id. + + If we don't find one then we add the sysroot and perform the search + again. + + However, the default sysroot is 'target:', and for a native target + this just means to search on the local machine. So by default, if the + debug information is not present, then we end up searching each + location twice. + + I think we only need to perform the "with sysroot" check if either: + + 1. The sysroot is something other than 'target:'. If the user has + set it to '/some/directory' then we should check this sysroot. Or if + the user has set it to 'target:/some/other_directory', this is also + worth checking. + + 2. If the sysroot is 'target:', but the target's filesystem is not + local (i.e. the user is connected to a remote target), then we should + check using the sysroot as this will be looking on the remote + machine. + + There's no tests for this as the whole point here is that I'm removing + duplicate work. No test regressions were seen though. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb/fileio: fix errno for packets where an attachment is expected + In remote.c lives remote_target::remote_hostio_send_command(), which + is used to handle sending a fileio packet to the remote, and for + parsing the reply packet. + + Some commands, e.g. open, pwrite, close, send some arguments to the + remote, and then get back a single integer return value. + + Other commands though, e.g. pread, readlink, fstat, send some + arguments and get back an integer return value and some additional + data. This additional data is called the attachment. + + Except, we only get the attachment if the command completes + successfully. For example, calling readlink with a non existent path + will result in a return packet: 'F-1,2' with no attachment. This is + as expected. + + Within remote_hostio_send_command we call remote_hostio_parse_result, + this parses the status code (-1 in our example above) and + then parses the errno value (2 in our example above). + + Back in remote_hostio_parse_result we then hit this block: + + /* Make sure we saw an attachment if and only if we expected one. */ + if ((attachment_tmp == NULL && attachment != NULL) + || (attachment_tmp != NULL && attachment == NULL)) + { + *remote_errno = FILEIO_EINVAL; + return -1; + } + + Which ensures that commands that expect an attachment, got an + attachment. + + The problem is, we'll only get an attachment if the command + succeeded. If it didn't, then there is no attachment, and that is as + expected. + + As remote_hostio_parse_result always sets the returned error number to + FILEIO_SUCCESS unless the packet contained an actual error + number (e.g. 2 in our example above), I suggest we should return early + if remote_hostio_parse_result indicates an error packet. + + I ran into this issue while working on another patch. In that patch I + was checking the error code returned by a remote readlink call and + spotted that when I passed an invalid path I got EINVAL instead of + ENOENT. This patch fixes this issue. + + Unfortunately the patch I was working on evolved, and my need to check + the error code went away, and so, right now, I have no way to reveal + this bug. But I think this is an obviously correct fix, and worth + merging even without a test. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix cast types for opencl + The bitshift tests for opencl have these failures: + + print /x (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8 + print (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8 + + Apparently opencl doesn't have the 'signed' modifier for types, only + the 'unsigned' modifier. + Even 'char' is guaranteed to be signed if no modifier is used, so + this changes the casts to match this logic. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix 64-bit shifts where long only has 32-bit size + On systems where long has 32-bit size you get these failures: + + print 1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff + print 1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff + print -1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff + print -1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff + + Fixed by changing the number-of-bits variable to ULONGEST. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix too-large or negative right shift of negative numbers + As seen in these test failures: + + print -1 >> -1 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1 + print -4 >> -2 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2 + + Fixed by restoring the logic from before the switch to gmp. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix right shift of negative numbers + PR31590 shows that right shift of negative numbers doesn't work + correctly since GDB 14: + + (gdb) p (-3) >> 1 + $1 = -1 + + GDB 13 and earlier returned the correct value -2. + And there actually is one test that shows the failure: + + print -1 >> 1 + $84 = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1 + + The problem was introduced with the change to gmp functions in + commit 303a881f87. + It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which + always rounds toward zero, and the gmp docu says this: + + For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple + bitwise right shifts. + For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift + treating n as two's complement the same as the bitwise logical functions + do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude. + + So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it + does right shifts for both positive and negative numbers. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590 + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Restore bitshift.exp tests + Commit cdd4206647 unintentionally disabled all tests of bitshift.exp, + so it actually just does this: + + Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ... + PASS: gdb.base/bitshift.exp: complete set language + + === gdb Summary === + + # of expected passes 1 + + It changed the 'continue' of unsupported languages to 'return', and + since ada is the first language and is unsupported, no tests were run. + + This changes it back to 'continue', and the following patches fix + the regressions that were introduced since then unnoticed. + + Approved-By: Tom Tromey + +2024-06-11 Kilian Kilger + + fix division by zero in target_read_string() + Under certain circumstances, a floating point exception in + target_read_string() can happen when the type has been obtained + by a call to stpy_lazy_string_elt_type(). In the latter function, + a call to check_typedef() has been forgotten. This makes + type->length = 0 in this case. + +2024-06-11 Tom Tromey + + Remove useless call to wnoutrefresh + This call to wnoutrefresh is not useful. It's based on the + misunderstanding that wnoutrefresh somehow prevents display, whereas + actually what it does is copy from one curses buffer to another. + + I'm working on a larger patch to clean up this area, but this + particular call can be removed immediately without consequence. + + Approved-By: Andrew Burgess + +2024-06-11 Tom Tromey + + Remove extract_long_unsigned_integer + The function extract_long_unsigned_integer is unused, so remove it. + Tested by rebuilding. + + Approved-By: Andrew Burgess + +2024-06-11 Alan Modra + + support_dt_relr aarch64 + Tweak commit db335d7e0a so that support_dt_relr returns false for + aarch64*-*-*ilp32. + +2024-06-11 Ciaran Woodward + + Fix printing strings on macOS Sonoma + On macOS sonoma, printing a string would only print the first + character. For instance, if there was a 'const char *s = "foobar"', + then the 'print s' command would print '$1 = "f"' rather than the + expected '$1 = "foobar"'. + + It seems that this is due to Apple silently replacing the version + of libiconv they ship with the OS to one which silently fails to + handle the 'outbytesleft' parameter correctly when using 'wchar_t' + as a target encoding. + + This specifically causes issues when using iterating through a + string as wchar_iterator does. + + This bug is visible even if you build for an old version of macOS, + but then run on Sonoma. Therefore this fix in the code applies + generally to macOS, and not specific to building on Sonoma. Building + for an older version and expecting forwards compatibility is a + common situation on macOS. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853 + +2024-06-11 David Guillen Fandos + + MIPS/opcodes: Add MIPS Allegrex DBREAK instruction + This complements the debug instruction set and uses the same encoding as + the VR5400/VR5500 devices. + + MIPS/opcodes: Exclude trap instructions for MIPS Allegrex + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-11 Alan Modra + + PR31872, Segfault in objdump (elf_slurp_reloc_table_from_section) + This one was triggered by trying to dump an AMDGPU object. + elf64-amdgcn.c lacks support for objdump relocation handling. + + PR 31872 + * elfcode.h (elf_slurp_reloc_table_from_section): Don't segfault + on NULL elf_info_to_howto_rel. + +2024-06-11 GDB Administrator + + Automatic date update in version.in + +2024-06-10 Ilya Leoshkevich + + IBM zSystems: Rewrite l(g)rl @GOTENT to larl for --no-pie + Regtested on s390x-redhat-linux. + + Rewriting l(g)rl @GOTENT to larl is unnecessarily guarded by + bfd_link_pic(). There were no use cases for this in the past, but + since recently the Linux Kernel on s390x is compiled with -fPIE + and linked with --no-pie. Remove the unnecessary bfd_link_pic() + check. + + bfd/ChangeLog: + + * elf32-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + * elf64-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lgrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + + ld/ChangeLog: + + * testsuite/ld-s390/s390.exp: Hook up the new tests. + * testsuite/ld-s390/gotreloc_31-no-pie-1.dd: New test. + * testsuite/ld-s390/gotreloc_64-no-pie-1.dd: New test. + +2024-06-10 Tom Tromey + + Make global_symbol_searcher::filenames private + This patch renames global_symbol_searcher::filenames and makes it + private, adding a new method to append a filename to the vector. This + also cleans up memory management here, removing an alloca from rbreak, + and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor + of having global_symbol_searcher manage the memory itself. + + Regression tested on x86-64 Fedora 38. + +2024-06-10 Tom de Vries + + [gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long long + If in gdb/python/python-internal.h, we pretend to have a platform that doesn't + support long long: + ... + -#ifdef HAVE_LONG_LONG + +#if 0 + ... + I get on arm-linux: + ... + (gdb) placement_candidate() + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: Python Exception : \ + Buffer returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: memory source api: second disassembler pass + ... + + The problem is that gdb_py_longest is typedef-ed to long, but the + corresponding format character GDB_PY_LL_ARG is defined to "L", meaning + "long long" [1]. + + Fix this by using "l", meaning long instead. Likewise for GDB_PY_LLU_ARG. + + Tested on arm-linux. + + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Tom de Vries + + [gdb/python] Fix gdb.python/py-disasm.exp on arm-linux + After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop: + ... + nop {0} + ... + we run into: + ... + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: add r11, sp, #0^M + 0x004004e0 <+8>: nop {0}^M + => 0x004004e4 <+12>: Python Exception : Buffer \ + returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test + ... + + This is caused by this code in gdbpy_disassembler::read_memory_func: + ... + gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj, + "read_memory", + "KL", len, offset)); + ... + where len has type "unsigned int", while "K" means "unsigned long long" [1]. + + Fix this by using "I" instead, meaning "unsigned int". + + Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means + "long long". + + Fix this by using type gdb_py_longest for offset, in combination with format + character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory. + + Tested on arm-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Matthieu Longo + + aarch64: warn on unpredictable results for new rcpc3 instructions + The previous patch for the feature rcpc3 introduced 4 new operations + (ldiapp, stilp, ldapr, stlr). + The specification mentions some cases of inputs causing unpredictable + results. gas currently fails to diagnose them, and does not emit + warnings. Even if the instruction encoding is valid, the developer + probably wants to know for those cases that the instruction won't have + the expected effect. + - ldiapp & stilp: + * unpredictable load pair transfer with register overlap + * unpredictable transfer with writeback + - ldapr & stlr: + * unpredictable transfer with writeback + + This patch also completes the existing relevant tests. + +2024-06-10 Maciej W. Rozycki + + Revert "MIPS/Allegrex: Exclude trap instructions" + This reverts commit a2e71b281a9365872451a157767e03a2e89ddaad. + + Revert "MIPS/Allegrex: Enable dbreak instruction" + This reverts commit c41020942b94ea7c5a58de4fed644826e8f0b509. + +2024-06-10 Tom de Vries + + [gdb/python] Note that python 3.6 assumes long long support + Starting with python 3.6, support for platforms without long long support + has been removed [1]. + + HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility, + so stop relying on them. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://github.com/python/cpython/issues/72148 + +2024-06-10 Alan Modra + + PR31873, buffer overflow in evax_bfd_print_dst + PR 31873 + * vms-alpha.c (evax_bfd_print_dst): Sanity check len against + dst_size. + +2024-06-10 Rostislav Krasny + + src-release.sh: don't take untracked files into account in the uncommitted changes check + +2024-06-10 David Guillen Fandos + + MIPS/Allegrex: Enable dbreak instruction + + MIPS/Allegrex: Exclude trap instructions + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-10 Jan Beulich + + x86/APX: convert ZU to operand constraint + Extremely rarely used attributes are inefficient when represented by a + separate attribute. Convert it to an operand constraint, as already + suggested during review. The collision with RegKludge is pretty simple + to resolve. + +2024-06-10 Jan Beulich + + x86: disassembler macro for condition code + Both CMPccXADD and APX'es {,CF}CMOVcc have almost identical entries + replicated 16 times each. Fold those to just one each by introducing a + %CC macro. (Note that the recording of ->condition_code in print_insn() + is merely for completeness for now; it's not used as long as only + VEX/EVEX encodings would consume it.) + + This then also renders condition codes printed consistent across all + respective insns; CMPxxXADD had a number of outliers so far. + +2024-06-10 Jan Beulich + + x86/APX: support extended SETcc form + As indicated during review, spelling/readability-wise + + setz %eax + + is easier than + + setzuz %al + + _and_ properly specifies the full register that's being modified. Permit + that form to be used, even if the spec writers are unwilling to formally + mention it. + + While there also correct the non-ZU EVEX form: That ought to also permit + memory operands. + +2024-06-10 Simon Marchi + + gdb: re-add necessary includes in tui/tui-win.c + Commit 9102a6c15c75 ("gdb/tui: cleanup includes") broke + gdb.python/tui-window.exp on Linux: + + Running /data/vries/gdb/src/gdb/testsuite/gdb.python/tui-window.exp ... + WARNING: timeout in accept_gdb_output + WARNING: timeout in accept_gdb_output + FAIL: gdb.python/tui-window.exp: Window was updated + + and caused a build failure on AIX: + + CXX tui/tui-win.o + tui/tui-win.c: In function 'void tui_sigwinch_handler(int)': + tui/tui-win.c:532:3: error: 'mark_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 532 | mark_async_signal_handler (tui_sigwinch_token); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + tui/tui-win.c: At global scope: + tui/tui-win.c:538:1: error: variable or field 'tui_async_resize_screen' declared void + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:538:26: error: 'gdb_client_data' was not declared in this scope + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~ + tui/tui-win.c: In function 'void tui_initialize_win()': + tui/tui-win.c:579:36: error: 'tui_async_resize_screen' was not declared in this scope + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:579:7: error: 'create_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + gmake: *** [Makefile:1947: tui/tui-win.o] Error 1 + + On Linux, the removal of the signal.h include causes the `#ifdef + SIGWINCH` sections to become inactive. The code builds, but then the + TUI fails to react to terminal size changes. When we add back the + inclusion of signal.h, then we see the same build error as on AIX. + + On AIX, I suppose that the SIGWINCH define is still seen by some other + transitive include. + + When I go back to before 9102a6c15c75, I don't see async-event.h and + signal.h being marked as unneeded by clangd, so I'm not sure why I + removed them in the first place... I'll be more careful in the future + (files with #ifdef/#ifndef can be tricky w.r.t. determining necessary + includes). + + So, re-add the inclusion of signal.h and async-event.h + + Change-Id: I3ed385c2dc1726ade2118a5186ea7cccffd12635 + Reported-By: Aditya Kamath1 + Reported-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865 + +2024-06-10 Tom de Vries + + [gdb/testsuite] Don't use set auto-solib-add off + In test-case gdb.mi/mi-var-child-f.exp, we have: + ... + mi_gdb_test "-gdb-set auto-solib-add off" "\\^done" + mi_runto prog_array + mi_gdb_test "nosharedlibrary" ".*\\^done" + ... + + This was added to avoid a name clash between the array variable as defined in + gdb.mi/array.f90 and debug info in shared libraries, and used in other places + in the testsuite. + + The same workaround is also used to ignore symbols from shared libraries when + excercising for instance a command that prints all symbols. + + However, this approach can cause problems for targets like arm that require + symbol info for some libraries like ld.so and libc to fully function. + + While absense of debug info for shared libraries should be handled gracefully + (which does need fixing, see PR31817), failure to do so should not result + in failures in unrelated test-cases. + + Fix this by removing "set auto-solib-add off". + + This ensures that we don't run into PR31817, while the presence of + nosharedlibrary still ensures that in the rest of the test-case we're not + bothered by shared library symbols. + + Likewise in other test-cases. + + Approved-by: Kevin Buettner + + Tested on arm-linux. + +2024-06-10 Jan Beulich + + gas: extend \+ support to .rept + PR gas/31752 + + While not quite as macro-like as .irp / .irpc, this perhaps benefits from + supporting \+ even more than those: It allows, where desired, to get away + without maintaining an explicit count variable in source code. + + Keep .rep (and custom per-arch uses of s_rept() / do_repeat()) behavior + unaltered. + +2024-06-10 Jan Beulich + + x86/APX: add missing CPU requirement to imm+rm forms of insns + This was overlooked when the form was added by dd74a603376e ("Support + APX NF"). + +2024-06-10 Clément Chigot + + ld-aarch64: check support before launching dt_relr tests + Not all aarch64 targets supports dt_relr as this requires some + mechanisms on the OS side. + + Adjust support_dt_relr helper and use it in aarch64-elf.exp. + +2024-06-10 GDB Administrator + + Automatic date update in version.in + +2024-06-09 Alan Modra + + regen sim/frv files for copyright update + +2024-06-09 Matthieu Longo + + autoupdate: regen after replacing obsolete macros + +2024-06-09 Matthieu Longo + + autoconf: delete obsolete unused m4 file + config/uintmax_t.m4 contains only one function: jm_AC_TYPE_UINTMAX_T. + After a grep, I could not find any usage of it. + + jm_AC_TYPE_UINTMAX_T seems to be an old implementation of the officially + suppported AC_TYPE_UINTMAX_T. + Doc: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/ + autoconf-2.72/autoconf.html#index-AC_005fTYPE_005fUINTMAX_005fT-1 + + config/stdint.m4 seems to have taken over. The usage of + AC_REQUIRE([AC_TYPE_UINTMAX_T]) is not garded or inside a function, so it + will also automatically be run for the configure.ac files using + AC_CONFIG_MACRO_DIRS([../config]) instead of m4_include([../config/stdint.m4]). + + It seems that people replaced jm_AC_TYPE_UINTMAX_T occurences by + AC_TYPE_UINTMAX_T, and forgot to delete uintmax_t.m4. + Deleting the file and regenerating the build scripts results in no diff, + so it looks safe to delete it from the repository. + +2024-06-09 Matthieu Longo + + autoupdate: add square brackets around arguments of AC_INIT + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2 + + autoupdate: add square brackets around argument of AC_PREREQ + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fPREREQ-1 + + autoupdate: replace old version of AC_INIT by the new one + - old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3 + + autoupdate: replace obsolete macros AC_CONFIG_HEADER + - AC_CONFIG_HEADER by AC_CONFIG_HEADERS + https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER + + autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM + - AC_CANONICAL_SYSTEM by: + * AC_CANONICAL_HOST where host, and host_alias are needed + * AC_CANONICAL_TARGET where target_alias is needed + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1 + + autoupdate: replace obsolete macros AC_PROG_LIBTOOL + - AC_PROG_LIBTOOL by LT_INIT + https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#index-LT_005fINIT + + autoupdate: replace obsolete macros AC_AIX, AC_MINIX, and AC_GNU_SOURCE + - AC_AIX, AC_MINIX, and AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fAIX + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fMINIX-1 + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fGNU_005fSOURCE-1 + + autoupdate: replace obsolete macros AC_HELP_STRING + - AC_HELP_STRING by AS_HELP_STRING + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fHELP_005fSTRING-1 + Except for the ifdef in lib-prefix.m4, make the defun of AC_LIB_ARG_WITH + unconditional. + +2024-06-09 H.J. Lu + + gold: Properly remove the versioned symbol + When the versioned symbol foo is removed from the shared library, the + ".symver foo,foo@VER" directive provides binary compatibility for foo@VER. + In this case, the unversioned symbol foo should be hidden and shouldn't + generate a multiple definition error. + + PR gold/31830 + * resolve.cc (Symbol_table::resolve): Move symbol version handling + to ... + * symtab.cc (Symbol_table::add_from_object): Here. If the hidden + version from .symver is the same as the default version from the + unversioned symbol, don't make the unversioned symbol the default + versioned + symbol. + * testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr31830.sh. + (check_DATA): ver_test_pr31830_a.syms and ver_test_pr31830_b.syms. + (ver_test_pr31830_a.syms): New. + (ver_test_pr31830_b.syms): Likewise. + (ver_test_pr31830_a.so): Likewise. + (ver_test_pr31830_b.so): Likewise. + * testsuite/Makefile.in: Regenerated. + * testsuite/ver_test_pr31830.script: New file. + * testsuite/ver_test_pr31830.sh: Likewise. + * testsuite/ver_test_pr31830_a.c: Likewise. + * testsuite/ver_test_pr31830_b.c: Likewise. + * testsuite/ver_test_pr31830_lto.c: Likewise. + * testsuite/ver_test_pr31830_lto.sh: Likewise. + +2024-06-09 GDB Administrator + + Automatic date update in version.in + +2024-06-08 Tom Tromey + + Fix typo in warning in gdb/configure + Eli pointed out that "babeltrace" is misspelled in a warning in + gdb/configure. This patch fixes the typo. + +2024-06-08 Eli Zaretskii + + gdb: Avoid compilation warning in gcore.c. + See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html + for the details. + + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove get_exec_file + I believe that the get_exec_file function is unnecessary, and the code + can be simplified if we remove it. + + Consider for instance when you "run" a program on Linux with native + debugging. + + 1. run_command_1 obtains the executable file from + `current_program_space->exec_filename ()` + 2. it passes it to `run_target->create_inferior()`, which is + `inf_ptrace_target::create_inferior()` in this case, which then + passes it to `fork_inferior()` + 3. `fork_inferior()` then has a fallback, where if the passed exec file + is nullptr, it gets its from `get_exec_file()`. + 4. `get_exec_file()` returns `current_program_space->exec_filename ()` + - just like the things we started with - or errors out if the + current program space doesn't have a specified executable. + + If there's no exec filename passed in step 1, there's not going to be + any in step 4, so it seems pointless to call `get_exec_file()`, we could + just error out when `exec_file` is nullptr. But we can't error out + directly in `fork_inferior()`, since the error is GDB-specific, and that + function is shared with GDBserver. + + Speaking of GDBserver, all code paths that lead to `fork_inferior()` + provide a non-nullptr exec file. + + Therefore, to simplify things: + + - Make `fork_inferior()` assume that the passed exec file is not + nullptr, don't call `get_exec_file()` + - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace, + nto-procfs, procfs) to error out when the exec file passed to their + create_inferior method is nullptr. Some targets are fine with a + nullptr exec file, so we can't check that in `run_command_1()`. + - Add the `no_executable_specified_error()` function, which re-uses the + error message that `get_exec_file()` had. + - Change some targets (go32-nat, nto-procfs) to not call + `get_exec_file()`, since it's pointless for the same reason as in the + example above, if it returns, it's going the be the same value as the + `exec_file` parameter. Just rely on `exec_file`. + - Remove the final use of `get_exec_file()`, in `load_command()`. + - Remove the `get_exec_file()` implementations in GDB and GDBserver and + remove the shared declaration. + + Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove dead code in nto-procfs.c + `get_exec_file()` never returns nullptr, so remove some dead code that + check for a nullptr return. + + Change-Id: I9eff2a013d602588aaf4477a22cf45f2bc417c6a + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: replace `get_exec_file (0)` calls with `current_program_space->exec_filename ()` + Calls of `get_exec_file (0)` are equivalent to just getting the exec + filename from the current program space. I'm looking to remove + `get_exec_file`, so replace these uses with + `current_program_space->exec_filename ()`. + + Remove the `err` parameter of `get_exec_wrapper` since all the calls + that remain pass 1, meaning to error out if no executable is specified. + + Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: make progspace::exec_filename private, add getter / setter + Just like the title says... I think this makes things a bit clearer, for + instance where the exec filename is set. It also makes the read call + sites a bit nicer, avoiding the `.get ()`. + + Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: cleanup includes + Remove includes reported as unused by clangd. Then, add any includes + necessary to get rid of errors (includes possibly relying on previous + includes).. + + I didn't remove the includes of gdb-safe-ctypes.h, because it appears to + do some some preprocessor magic, redefining standard macros. I'm afraid + that removing these includes could change the behavior unintentionally. + + Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: add IWYU export pragams to gdb_curses.h + It seems like gdb_curses.h is included whenever we want to access + ncurses functionality, instead of including directly ncurses.h. As a + result, clangd often erroneously shows that gdb_curses.h inclusions are + unused. + + By adding those pragmas, clangd (and the include-what-you-use tool) + understands that gdb_curses.h is a valid provider for whatever these + ncurses.h files provide. + + Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: change some macros to functions + Change the `TUI_*` macros to access known windows to functions. Define + them in their respective files, because trying to define them in + tui-data.h would end up causing include cycles. + + This makes static analysis (detection of unused include files in this + case) more accurate, and I think in general we should avoid hiding + code behind macros if not necessary. + + Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af + Approved-By: Tom Tromey + +2024-06-08 GDB Administrator + + Automatic date update in version.in + +2024-06-07 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp + Test behaviour of watchpoints triggered by MOPS instructions. This test + is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS + instructions rather than whatever instructions are used in the libc's + implementation of memset/memcpy/memmove. + + There's a separate watched variable for each set of instructions so that + the testcase can test whether GDB correctly identified the watchpoint + that triggered in each case. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Add record support for MOPS instructions. + There are two kinds of MOPS instructions: set instructions and copy + instructions. Within each group there are variants with minor + differences in how they read or write to memory — e.g., non-temporal + read and/or write, unprivileged read and/or write and permutations of + those — but they work in the same way in terms of the registers and + regions of memory that they modify. + + The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS + instructions are recorded and correctly reversed. Not all variants of the + copy and set instructions are tested, since there are many and the record + and replay target processes them in the same way. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Disable displaced single-step for MOPS instructions + The AArch64 MOPS (Memory Operation) instructions provide a standardised + instruction sequence to perform a memset, memcpy or memmove. A sequence is + always composed of three instructions: a prologue instruction, a main + instruction and an epilogue instruction. As an illustration, here are the + implementations of these memory operations in glibc 2.39: + + (gdb) disassemble/r + Dump of assembler code for function __memset_mops: + => 0x0000fffff7e8d780 <+0>: d503201f nop + 0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1 + 0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1 + 0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1 + 0x0000fffff7e8d794 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memcpy_mops: + => 0x0000fffff7e8c580 <+0>: d503201f nop + 0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2! + 0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2! + 0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2! + 0x0000fffff7e8c594 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memmove_mops: + => 0x0000fffff7e8d180 <+0>: d503201f nop + 0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2! + 0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2! + 0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2! + 0x0000fffff7e8d194 <+20>: d65f03c0 ret + End of assembler dump. + + The Arm Architecture Reference Manual says that "the prologue, main, and + epilogue instructions are expected to be run in succession and to appear + consecutively in memory". Therefore this patch disables displaced stepping + on them. + + The testcase verifies that MOPS sequences are correctly single-stepped. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Tom de Vries + + [gdb/tdep] Fix ARM_LINUX_JB_PC_EABI + In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1 + since glibc 2.20. + + See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and + setjmp."). + + Update it, allowing us to run into the gdb/26967 kfail. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR arm/tdep + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089 + +2024-06-07 Alan Modra + + Re: Yet another ecoff fuzzed object fix + In commit 6fc018e9e593 I replaced the fdr_ptr csym check against the + header isymMax count with a check against bfd symcount. In fact, both + checks are needed. The isymMax check sanity checks accesses against + the external sym array, the symcount one against the internal array. + + * ecoff.c (_bfd_ecoff_slurp_symbol_table): Reinstate fdr_ptr + csym check against isymMax. + +2024-06-07 Szabolcs Nagy + + aarch64: Test DT_RELR with discarded sections + +2024-06-07 Szabolcs Nagy + + aarch64: Fix DT_RELR support with discarded sections + In case of discarded sections, via /DISCARD/ or .gnu.linkonce, + relr relocation accounting was wrong. This broke building linux. + + The issue was that the *_relocate_section logic was copied to + record_relr_non_got_relocs to find the relative relocs that can + be packed, however *_relocate_section is not called on sections + that are discarded, while record_relr_non_got_relocs is called + for all input sections. The fix is to filter out the discarded + sections with the same logic that is used to count non-GOT + relocs in *_late_size_sections for local symbols earlier. + Use the discarded_section helper in both cases to clarify the + intent and handle all corner-cases consistently. + + GOT relocations are affected too if all sections are discarded + that reference the GOT entry of a particular symbol, however + this can cause unused GOT entries independently of DT_RELR, and + the only difference with DT_RELR is that a relative reloc may be + emitted instead of a R_AARCH64_NONE for the unused GOT entry + which is acceptable. A proper fix would require redoing the GOT + refcounting after we know the discarded sections, see bug 31850. + +2024-06-07 Tom de Vries + + [gdb/testsuite] Fix gdb.fortran/array-bounds.exp on arm + When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into: + ... + (gdb) print &foo^M + $1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo + print &bar^M + $2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar + ... + + This is due to gcc PR debug/54934. + + The test-case contains a kfail for this, which is only activated for + x86_64/i386. + + Fix this by enabling the kfail for all ilp32 targets. + + Also: + - change the kfail into an xfail, because gdb is not at fault here, and + - limit the xfail to the gfortran compiler. + + Tested on arm-linux. + +2024-06-07 GDB Administrator + + Automatic date update in version.in + +2024-06-06 Andrew Burgess + + gdb/doc: use POD2MAN5 when appropriate + In commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + I rewrote the rules for building the man pages. While doing this I + accidentally switched from using MAN2POD5 to MAN2POD1 for generating + the file gdbinit.5. + + Restore use of MAN2POD5 where appropriate. + +2024-06-06 Johan Sternerup + + DAP: Handle "stepOut" request in outermost frame + Previously a "stepOut" request when in the outermost frame would result + in a sucessful response even though gdb internally would reject the + associated "finish" request, which means no stoppedEvent would ever be + sent back to the client. Thus the client would believe the inferior was + still running and as a consequence reject subsequent "next" and "stepIn" + requests from the user. + + The solution is to execute the underlying finish command as a background + command, i.e. `finish &`. If we're in the outermost frame an exception + will be raised immediately, which we can now capture and report back to + the client as success=False so then the absence of a `stopped` event is + no longer a problem. + + We also make use of the `defer_stop_event` option to prevent a stop + event from reaching the client until the response has been sent. + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow gdb exception in exec_and_log to propagate + This allows a request to specify that any gdb exception raised in + exec_and_log within the gdb thread to be propagated back to the DAP + thread (using the Canceller object as the orchestrator). + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow for deferring stop events from gdb thread + The existing `send_event_later()` method allows commands processed on + the DAP thread to queue an event for execution until after the response + has been sent to the client. + + We now introduce a corresponding method for use by the gdb thread. This + method `send_event_maybe_later()` will queue the event just like + `send_event_later()`, but only if it has been configured to do so by a + new @request option `defer_stop_events`. As the name implies the + functionality is currently only used for handling stop events. + + Approved-By: Tom Tromey + +2024-06-06 Richard Earnshaw + + arm: fix testsuite fallout on arm-elf and arm-nto from FPA removal + Removing FPA means that in some cases we default to 'no-fpu' in the + assembler when previously we would have picked FPA-format floating + numbers. This patch fixes the testsuite fallout on a couple of + targets that are affected by this change. Where possible we do this + by adding an option to set the floating-point format, but for bad-bss + we just skip the test. + +2024-06-06 Nick Clifton + + Updated Spanish translation for the bfd/ directory + +2024-06-06 Andrew Burgess + + opcodes/riscv: prevent future use of disassemble_info::fprintf_func + The previous commit removed a use of disassemble_info::fprintf_func + which had been added to the RISC-V disassembler after the disassembler + had been switched to use ::fprintf_styled_func, for styled output. + + To prevent future mistakes, I propose adding a #define to rename + fprintf_func to something which does not exist. If this had been in + place then the before the previous commit libopcodes would have failed + to compile, like this: + + ../../src/opcodes/riscv-dis.c: In function ‘print_reg_list’: + ../../src/opcodes/riscv-dis.c:229:7: error: ‘disassemble_info’ {aka ‘struct disassemble_info’} has no member named ‘please_use_fprintf_styled_func_instead’ + 229 | info->fprintf_func (info->stream, "%s", riscv_gpr_names[X_RA]); + | ^~ + + If this commit is accepted then I'll follow up with another commit + that adds the same #define to every disassembler that has been + converted to use styled output. + + As the RISC-V disassembler is now fully styled, this commit should + make no difference at all. + +2024-06-06 Andrew Burgess + + opcodes/riscv: add styling support to print_reg_list + I noticed that some unstyled output had crept into the risc-v + disassembler in this commit: + + commit 9132c8152b899a1683bc886f8ba76bedadb48aa1 + Date: Tue Feb 27 11:48:11 2024 +0800 + + RISC-V: Support Zcmp push/pop instructions. + + this commit adds styling support. The risc-v disassembler is now once + again, fully styled. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfwma extension + This implements the Zvfbfwma extension, as of version 1.0. + View detailed information in: + + + 1 In spec: "Zvfbfwma requires the Zvfbfmin extension and the Zfbfmin extension." + 1.1 In Embedded Processor: Zvfbfwma -> Zvfbfmin -> Zve32f + 1.2 In Application Processor: Zvfbfwma -> Zvfbfmin -> V + 1.3 In both scenarios, there are: Zvfbfwma -> Zfbfmin + + 2 Depending on different usage scenarios, the Zvfbfwma extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies in + scenario of Embedded Processor. This is consistent with the processing + strategy in Zvfbfmin. In scenario of Application Processor, it is + necessary to explicitly indicate the dependent 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfwma. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfwma.d: New test. + * testsuite/gas/riscv/zvfbfwma.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFWMACCBF16_VF): Define. + (MASK_VFWMACCBF16_VF): Ditto. + (MATCH_VFWMACCBF16_VV): Ditto. + (MASK_VFWMACCBF16_VV): Ditto. + (DECLARE_INSN): New declarations for Zvfbfwma. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFWMA + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfwma instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfmin extension + This implements the Zvfbfmin extension, as of version 1.0. + View detailed information in: + + + Depending on different usage scenarios, the Zvfbfmin extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies + in scenario of Embedded Processor. In scenario of Application + Processor, it is necessary to explicitly indicate the dependent + 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfmin.d: New test. + * testsuite/gas/riscv/zvfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFNCVTBF16_F_F_W): Define. + (MASK_VFNCVTBF16_F_F_W): Ditto. + (MATCH_VFWCVTBF16_F_F_V): Ditto. + (MASK_VFWCVTBF16_F_F_V): Ditto. + (DECLARE_INSN): New declarations for Zvfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFMIN + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfmin instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zfbfmin extension + This implements the Zfbfmin extension, as of version 1.0. + + View detailed information in: + + + 1 The Zfbfmin extension depend on 'F', and the FLH, FSH, FMV.X.H, and + FMV.H.X instructions as defined in the Zfh extension. + + 2 The Zfhmin extension includes the following instructions from the Zfh + extension: FLH, FSH, FMV.X.H, FMV.H.X... View detailed information in: + + + 3 Zfhmin extension depend on 'F'. + + 4 Simply put, just make Zfbfmin dependent on Zfhmin. + + Perhaps in the future, we could propose making the FLH, FSH, FMV.X.H, and + FMV.H.X instructions an independent extension to achieve precise dependency + relationships for the Zfbfmin. + + 5 For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zfbfmin.d: New test. + * testsuite/gas/riscv/zfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_FCVT_BF16_S): Define. + (MASK_FCVT_BF16_S): Ditto. + (MATCH_FCVT_S_BF16): Ditto. + (MASK_FCVT_S_BF16): Ditto. + (DECLARE_INSN): New declarations for Zfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZFBFMIN. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zfbfmin instructions. + +2024-06-06 Alan Modra + + Re: aarch64: Add some DT_RELR ld tests + aarch64-elf fails these tests due to .rela.dyn being at a different + address to that expected, and due to the symbol table being different. + Unexpected symbol numbering results in a mismatch of reloc r_info + field, but these are shown decoded so the raw field doesn't really add + anything to the test. + + * testsuite/ld-aarch64/relr-align.d: Accept any address for + .relr.dyn section. Don't match raw r_info field. + * testsuite/ld-aarch64/relr-data-shared.d: Likewise. + * testsuite/ld-aarch64/relr-got-shared.d: Likewise. + * testsuite/ld-aarch64/relr-text-shared.d: Likewise. + +2024-06-06 GDB Administrator + + Automatic date update in version.in + +2024-06-05 Richard Earnshaw + + NEWS: arm: note that FPA support has been removed + + arm: minor documentation cleanup given removal of FPA + The use in the documentation of .save for an FPA instruction is no-longer + relevant, so remove it. + + arm: remove disassembly support for the FPA co-processor + Remove the FPA support from the disassembler. This entails a couple + of testsuite fixes where we were (probably incorrectly) disassembling + a generic co-processor instruction using the legacy FPA opcodes. + + arm: remove FPA instructions from assembler + These can no-longer be generated as the options to reach them have now + gone. So remove the parsing support for FPA instructions. + + arm: remove options to select the FPA + Remove the command-line options to choose the FPA (or FPE - an + emulated FPA). From this point on it should be impossible to assemble + the old FPA instructions. + + arm: change default FPUs from FPA to none + Change the cases where the default FPU was FPA to none. This should + ensure that any code that used settings to pick the floating-point + order will not silently produce a different output. The options that + explicitly set the FPA remain for the moment. + +2024-06-05 Richard Earnshaw + + arm: redirect fp constant data directives through a wrapper + Assembler directives such as .float, or .double are handled by generic + code, but on Arm, their output can vary depeding on the type of FPU + begin targetted. When we remove FPA support we don't want to silently + generate different code for processors that previously defaulted to + the FPA, so redirect these directives through a wrapper function that + checks the FPU is enabled; we use the legacy -mno-fpu in the test to + catch this. + + Also fix a few tests so that they won't start to fail on targets (eg + arm-wince-pe) where there is no default format for the FPU and we pick + this from the default processor type. + +2024-06-05 Richard Earnshaw + + arm: adjust FPU selection logic + The logic here seems to be overly complex, so simplify it a bit. One + particular problem was that using the legacy -mno-fpu option was not + working properly, as this has all the feature bits set to zero causing + the code to then pick a different FPU as the default. Fix this by + only selecting an FPU as a fallback if the code has not otherwise + selected one: there was only one route by which this could happen. + + This patch is really a pre-cursor to the following one where we want + to make no-fpu internally a fall-back position for some legacy + processors where previously we would have dropped back to the FPA. + +2024-06-05 Richard Earnshaw + + arm: default to softvfp on armv6 or later cores + From armv6 onwards a lot of cores started to come with a physical VFP + implementation; but many still did not and in some cases there are + both variants. For the cores that lacked a physical VFP we would fall + back to FPU_NONE if the platform/ABI did not mandate something else. + To make matters worse, FPU_NONE is internal state used to imply + soft-fpa (ie a mixed-endian double format), so any use of .double in + hand-written assembly is almost certainly generating incorrect output. + + That's undesirable, all these cores should really default to a softvfp + model. + +2024-06-05 Richard Earnshaw + + arm: rename FPU_ARCH_VFP to FPU_ARCH_SOFTVFP + FPU_ARCH_VFP has always meant VFP floating-point format (natural FP + word order) but without any VFP instructions. But the name + FPU_ARCH_VFP is potentially confusing. This patch just changes the + name to make the meaning clearer. + + arm: remove FPA related tests + Remove various tests of the FPA instruction set and relocation support. + +2024-06-05 Nick Clifton + + Fix illegal memory access when bfd_get_section_contents is called with a NULL section pointer. + PR 31843 + +2024-06-05 Nelson Chu + + RISC-V: Tidy vendor core-v extension gas testcases + 1. Combined testcases into one if they use same extention name. + 2. Likewise for the fail testcases. + 3. Renamed with x-cv prefix, just like what other vendors did. + + gas/ + * testsuite/gas/riscv/cv-alu-*: Combined and renamed to + x-cv-alu. Likewise for fail testcases, to x-cv-alu-fail*. + * testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to + x-cv-bi and x-cv-bi-fail. + * testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to + x-cv-elw and x-cv-elw-fail. + * testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to + x-cv-mac and x-cv-mac-fail. + * testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to + x-cv-mem and x-cv-mem-fail. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVmem extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * doc/c-riscv.texi: Note XCVmem as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-mem-fail-march.d: New test. + * testsuite/gas/riscv/cv-mem-fail-march.l: New test. + * testsuite/gas/riscv/cv-mem-fail-march.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test. + * testsuite/gas/riscv/cv-mem-lbpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbrr.d: New test. + * testsuite/gas/riscv/cv-mem-lbrr.s: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbupost.d: New test. + * testsuite/gas/riscv/cv-mem-lbupost.s: New test. + * testsuite/gas/riscv/cv-mem-lburr.d: New test. + * testsuite/gas/riscv/cv-mem-lburr.s: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhrr.d: New test. + * testsuite/gas/riscv/cv-mem-lhrr.s: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhupost.d: New test. + * testsuite/gas/riscv/cv-mem-lhupost.s: New test. + * testsuite/gas/riscv/cv-mem-lhurr.d: New test. + * testsuite/gas/riscv/cv-mem-lhurr.s: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwrr.d: New test. + * testsuite/gas/riscv/cv-mem-lwrr.s: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbrr.d: New test. + * testsuite/gas/riscv/cv-mem-sbrr.s: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-shpost.d: New test. + * testsuite/gas/riscv/cv-mem-shpost.s: New test. + * testsuite/gas/riscv/cv-mem-shrr.d: New test. + * testsuite/gas/riscv/cv-mem-shrr.s: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-swpost.d: New test. + * testsuite/gas/riscv/cv-mem-swpost.s: New test. + * testsuite/gas/riscv/cv-mem-swrr.d: New test. + * testsuite/gas/riscv/cv-mem-swrr.s: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvmem string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVmem. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVmem. + (enum riscv_insn_class): Add the XCVmem instruction class. + + opcodes/ChangeLog: + + * riscv-opc.c: Add XCVmem instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVbi extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + Nazareno Bruschi + Lin Sinan + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + gas/ChangeLog: + + * config/tc-riscv.c (validate_riscv_insn): Add the necessary + operands for the extension. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbi as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-bi-beqimm.d: New test. + * testsuite/gas/riscv/cv-bi-beqimm.s: New test. + * testsuite/gas/riscv/cv-bi-bneimm.d: New test. + * testsuite/gas/riscv/cv-bi-bneimm.s: New test. + * testsuite/gas/riscv/cv-bi-fail-march.d: New test. + * testsuite/gas/riscv/cv-bi-fail-march.l: New test. + * testsuite/gas/riscv/cv-bi-fail-march.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvbi string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add disassembly for new operand. + * riscv-opc.c: Add XCVbi instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVelw extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvelw` instruction + class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + + * doc/c-riscv.texi: Note XCVelw as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-elw-fail.d: New test. + * testsuite/gas/riscv/cv-elw-fail.l: New test. + * testsuite/gas/riscv/cv-elw-fail.s: New test. + * testsuite/gas/riscv/cv-elw-fail-march.d: New test. + * testsuite/gas/riscv/cv-elw-fail-march.l: New test. + * testsuite/gas/riscv/cv-elw-fail-march.s: New test. + * testsuite/gas/riscv/cv-elw-pass.d: New test. + * testsuite/gas/riscv/cv-elw-pass.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvelw string. + + opcodes/ChangeLog: + + * riscv-opc.c: (riscv_opcode) Add event load instructions. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + instruction opcode macros. + * opcode/riscv.h (riscv_insn_class): Add INSN_CLASS_XCVELW. + +2024-06-05 Andrew Burgess + + gdb/testsuite: remove trailing \r from rust_llvm_version result + I noticed that the value returned by rust_llvm_version had a trailing + carriage return. I don't think this is causing any problems right + now, but looking at the code I don't think this was the desired + behaviour. + + The current code runs 'rustc --version --verbose', splits the output + at each '\n' and then loops over every line looking for the line that + contains the LLVM version. + + There are two problems here. First, at the end of each captured line + we have '\r\n', so when we split the lines on '\n', each of the lines + will still end with a '\r' character. + + Second, though we loop over the lines, when we try to compare the line + contents we actually compare the unsplit full output. Luckily this + still finds the match, but this renders the loop over lines redundant. + + This commit makes two fixes: + + 1. I use regsub to convert all '\r\n' sequences to '\n'; now when we + split on '\n' the lines will not end in '\r'. + + 2. Within the loop over lines block I now check the line contents + rather than the unsplit full output; now we capture a value + without a trailing '\r'. + + There's only one test (gdb.rust/simple.exp) that uses + rust_llvm_version, and it doesn't care if there's a trailing '\r' or + not, so this change should make no difference there. + + Approved-By: Tom Tromey + +2024-06-05 Andrew Burgess + + gdb: more filename styling in remote.c and target.c + I spotted a few more places where we could apply filename styling in + remote.c and target.c. Other than the styling, there should be no + user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-05 GDB Administrator + + Automatic date update in version.in + +2024-06-04 Tom Tromey + + Return global scope from DAP scopes request + A co-worker requested that the DAP code emit a scope for global + variables. It's not really practical to do this for all globals, but + it seemed reasonable to do this for globals coming from the frame's + compilation unit. For Ada in particular, this is convenient as it + exposes package-scoped variables. + + Reviewed-By: Eli Zaretskii + +2024-06-04 Tom Tromey + + Convert DAP disassemble code to use Block hashing + This changes the DAP disassemble code to use the new Block hashing, + storing the already-visited blocks in a set rather than a list. + +2024-06-04 Tom Tromey + + Memoize gdb.Block and make them hashable + In subsequent patches, it's handy if gdb.Block is hashable, so it can + be stored in a set or a dictionary. However, doing this in a + straightforward way is not really possible, because a block isn't + truly immutable -- it can be invalidated. And, while this isn't a + real problem for my use case (in DAP the maps are only used during a + single stop), it seemed error-prone. + + This patch instead takes the approach of using the gdb.Block's own + object identity to allow hashing. This seems fine because the + contents don't affect the hashing. In order for this to work, though, + the blocks have to be memoized -- two requests for the same block must + return the same object. + + This also allows (actually, requires) the simplification of the + rich-compare method for blocks. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-04 Tom Tromey + + Put "source" into DAP scope + I noticed a FIXME comment in the DAP code about adding a "source" + field to a scope. This is easy to implement; I don't know why I + didn't do this originally. + + Remove a couple unnecessary casts + After the previous bcache change, a couple of casts in objfiles.h are + now redundant. + +2024-06-04 Tom Tromey + + Make bcache more type-safe + The bcache uses memcpy to make copies of the data passed to it. In + C++, this is only safe for trivially-copyable types. + + This patch changes bcache to require this property, and slightly + changes the API to make it easier to use when copying a single object. + It also makes the new 'insert' template methods return the correct + type. + +2024-06-04 Tom Tromey + + Some constification in psymtab + This patch changes some spots in psymtab.[ch] to use 'const'. This is + just preparation for a subsequent patch. Note that psymbols are + conceptually const, and since they were changed to be + objfile-indepdendent, they are truly never modified -- which is what + makes this patch reasonably short. + + Rely on std::uncaught_exceptions + std::uncaught_exceptions is a C++17 feature, so I think we can remove + this conditional code from inferior.h. + +2024-06-04 Dmitry Neverov + + Add myself to gdb/MAINTAINERS + +2024-06-04 Rostislav Krasny + + src-release.sh: fix adjusting files permissions and cleaning + PR 31800 + +2024-06-04 Andrew Burgess + + gdb/testsuite: tests for debug lookup within the sysroot + Add tests for looking up debug information within the sysroot via both + build-id and gnu_debuglink. + + I wanted to ensure that the gnu_debuglink test couldn't make use of + build-ids, so I added the 'no-build-id' flag to gdb_compile. + + As these tests rely on setting the sysroot, if I'm running a + dynamically linked executable, GDB will try to find all shared + libraries within the sysroot. This would mean I'd have to figure out + and copy all shared libraries the executable uses, certainly possible, + but a bit of a pain. + + So instead, I've just compiled the test executable as a static binary. + Now there are no shared library dependencies. + + I can now split the debug information out from the test binary, and + place it within the sysroot. When GDB is started and the executable + loaded, we can check that GDB is finding the debug information within + the sysroot. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Approved-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/testsuite: make gdb_gnu_strip_debug consistent + While writing a test I realised that the default behaviour of + gdb_gnu_strip_debug doesn't match its comment. + + The comment says that the function takes a FILENAME, and splits the + file into FILENAME.stripped and FILENAME.debug, leaving FILENAME + unchanged. The comment says that a .gnu_debuglink will be added to + FILENAME.stripped. + + However, this is not true, FILENAME.stripped is created, with no debug + information. FILENAME.debug is created containing the debug + information. + + But, when adding the .gnu_debuglink we take FILENAME.stripped as the + input, and then overwrite FILENAME with the output. As a result, + FILENAME.stripped does not include a .gnu_debuglink, while FILENAME + contains the .gnu_debuglink and no debug information! + + The users of gdb_gnu_strip_debug can be split into two groups, those + who are using the .gnu_debuglink, these tests are all written assuming + that FILENAME is updated. + + Then there are some tests that only rely on gdb_gnu_strip_debug's + ability to split out the debug information, these tests are then going + to do a lookup based on the build-id, these tests don't require the + .gnu_debuglink. These tests use the FILENAME.stripped output file. + + This all seems too confused to me. + + As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I + propose that we just make that the actual, advertised behaviour of + this proc. + + So now, gdb_gnu_strip_debug will take FILENAME, and will split the + debug information out into FILENAME.debug. The debug information will + then be stripped from FILENAME, and by default a .gnu_debuglink will + be added to FILENAME pointing to FILENAME.debug. + + I've updated the two tests that actually relied on FILENAME.stripped + to instead just use FILENAME. + + One of the tests was doing a build-id based lookup, but was still + allowing the .gnu_debuglink to be added to FILENAME, I've updated this + test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops + the .gnu_debuglink from being added. + + All of the tests that call gdb_gnu_strip_debug still pass for me. + + Acked-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/Makefile.in: silence recipe for creating .deps/ directories + When building in a fresh directory we'll see some output like this: + + /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps + mkdir -p -- arch/.deps + /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps + mkdir -p -- cli/.deps + /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps + mkdir -p -- dwarf2/.deps + ... etc ... + + this commit uses silent-rules.mk to silence this output, now we'll + see: + + GEN arch/.deps + GEN cli/.deps + GEN dwarf2/.deps + ... etc ... + + The recipe that currently generates these directories uses + mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs + is deprecated and 'install-sh -d' should be used instead. This + silences the 'mkdir -p -- ...' part of the output. + + There should be no change in what is actually built after this commit. + + Approved-By: Tom Tromey + +2024-06-04 mengqinggang + + LoongArch: Disable linker relaxation if set the address of section or segment + If set the address of section or segment, the offset from pc to symbol + may become bigger and cause overflow. + +2024-06-04 mengqinggang + Jinyang He + + LoongArch: Make align symbol be in same section with alignment directive + R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only + created at the first time to handle alignment directive. This means that + all other sections may use this symbol. If the section of this symbol is + discarded, there may be problems. Search it in its own section. + + Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c. + + Reported-by: WANG Xuerui + Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t + +2024-06-04 Richard Earnshaw + + arm: testsuite: fix msdos line endings in tests + A couple of the tests in the testsuite were at some point in the past + committed with DOS-style CRLF line endings. This potentially causes + email problems if the tests are touched in the middle of a large patch + series so convert them to standard Un*x line endings. + +2024-06-04 GDB Administrator + + Automatic date update in version.in + +2024-06-03 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen4 + ChangeLog + 2024-06-01 Vladimir Mezentsev + + * common/hwctable.c: Add the hwc table for AMD Zen4. + * src/hwc_amd_zen4.h: New file. + * src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H. + +2024-06-03 Tom Tromey + + Remove one call to can_box from TUI + This removes a call to can_box from + tui_source_window_base::show_source_content. can_box will always + return true here. + + Approved-By: Andrew Burgess + +2024-06-03 Tom Tromey + + Fix deprecation text + I noticed one spot where deprecate_cmd is called with a second + argument that is not a command name. This patch fixes the problem. + + Regression tested on x86-64 Fedora 38. + +2024-06-03 Hannes Domani + + Enable call of overloaded subscript operator from python + If you try to use the overloaded subscript operator of a class + in python, it fails like this: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Cannot subscript requested type. + Error while executing Python code. + + This simply checks if such an operator exists, and calls it + instead, making this possible: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + 102 'f' + + Approved-By: Tom Tromey + +2024-06-03 Hannes Domani + + Allow calling of convenience functions with python + As mentioned in PR13326, currently when you try to call a + convenience function with python, you get this error: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). + Error while executing Python code. + + So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as + well, making this possible: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + 0 + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-06-03 Mark Wielaard + + src-release.sh: Use -T0 for xz compression + Use parallel compression to create the xz archive. + + On my machine (using 4 cores) this reduces the time to create + binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds. + + xz has supported -T0 since version 5.2.0 (released 2014-12-21). + +2024-06-03 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.tui/resize-2.exp + When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run + into: + ... + tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable + ^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout) + ... + + The test-case does "Term::resize 24 80 0" while having the settings of an + earlier "Term::resize 40 90", so both dimensions change. + + When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc: + - calls stty to change one dimension, + - waits for the message (enabled by "maint set tui-resize-message on") + confirming the resize has happened, + - calls stty to change the other dimension, and again + - waits for the message confirming the resize has happened. + + Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the + message is not printed, so stty is called twice, and afterwards we check for + the results of the two resizes, which is the test that is failing. + + The problem is that not waiting for a response after each stty call opens up + the possibility of the responses being merged. + + Fix this by calling Term::resize twice, changing one dimension at a time, and + waiting for a single prompt redisplay after each one. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + PR testsuite/31822 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822 + +2024-06-03 GDB Administrator + + Automatic date update in version.in + +2024-06-02 Tom Tromey + + Fix typo in tui-data.h + I noticed a typo in a comment in tui-data.h. + +2024-06-02 GDB Administrator + + Automatic date update in version.in + +2024-06-01 GDB Administrator + + Automatic date update in version.in + +2024-05-31 Kevin Buettner + + [gdb/testsuite] New test: gdb.base/errno.exp + Printing the value of 'errno' from GDB is sometimes problematic. The + situation has improved in recent years, though there are still + scenarios for which "print errno" doesn't work. + + The test, gdb.base/errno.exp, introduced by this commit, tests whether + or not GDB can print errno using a binary compiled in the following + different ways: + + - default: no switches aside from -g (and whatever else is added by the + testing framework) + - macros: macro info is included in the debuginfo; this is enabled by + using -g3 when using gcc or clang + - static: statically linked binary + - static-macros: statically linked binary w/ macro definitions included + in debuginfo + - pthreads: libpthread linked binary + - pthreads-macros: libpthread linked binary w/ macro definitions included + in debuginfo + - pthreads-static: Statically linked against libpthread + - pthreads-static-macros: Statically linked against libpthread w/ macro + definitions + + For each of these, the test also creates a corefile, then loads the + corefile and attempts to print errno again. + + Additionally, the test checks that a "masking" errno declared as a + local variable will print correctly. + + On Linux, if the machine is missing glibc debuginfo (or you have + debuginfod disabled), it's likely you'll see: + + (gdb) print errno + 'errno' has unknown type; cast it to its declared type + + But if you add a cast, the value of errno is often available: + + (gdb) print (int) errno + $1 = 42 + + The test detects this situation along with several others and does + 'setup_xfail' for tests that will almost certainly fail. It could be + argued that some of these ought to be KFAILs due to deficiencies in + GDB, but I'm not entirely certain which, if any, are fixable yet. + + On Fedora 39, without glibc debuginfo, there are no failures, but + I do see the following XFAILS: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Fedora 39, with glibc debug info, but without libc.a (for static + linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED + tests. + + So, even when testing in less than ideal conditions, either due to lack + of glibc debuginfo or lack of a libc to link against to make a static + binary, there are no failures. + + With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40, + Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs: + + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On FreeBSD 13.1, the total number of XFAILs are fewer, and could be + even better still if it had debug info for glibc: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + Starting with glibc-2.34, most of the pthreads library has been + incorporated into libc, so finding thread-local variables using + libthread_db is possible for several scenarios in which it previously + wasn't. But, prior to this, accessing errno for the default scenario + was a problem. This is borne out by running this new test on Fedora + 34, which uses glibc-2.33: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + In the v3 version of this test, Tom de Vries tested on openSUSE Leap + 15.5 and found a number of cases which showed a FAIL instead of an + XFAIL. The v4 version of this test fixed those problems. On Leap + 15.5, which uses glibc-2.31, with glibc debug info, I now see: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Leap 15.5, with glibc debuginfo missing, the results are a little + worse: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + The v5 version of this test fixed failures when testing with + check-read1. (Thanks to Linaro CI for finding these.) I revised the + regular expressions being used so that the failures were eliminated, + but the results mentioned above have not changed. + + The v6 version of this test fixes some nits pointed out by both Tom + de Vries and Pedro Alves. One of Pedro's suggestions was to rename the + test from check-errno.exp to errno.exp, so in v5, the name has + changed. Tom also noticed that there were failures when using + --target_board=native-extended-gdbserver. For v6, I've tested on 10 + different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o + static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o + glibc debuginfo, and Fedora 34) using "make check" and "make check-read1" + using target boards "unix", "native-extended-gdbserver", and + "native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for + a total of 12 distinct test runs on each machine. I've also tested the + native-only cases on FreeBSD. (Attempting to test against gdbserver + on FreeBSD resulted in hangs while running the test suite.) + + The v7 version of this test simplifies the REs used in the uses of + gdb_test_multiple by adding -wrap and removing parts of the REs which + match the GDB prompt. In cases where there was a leading '.*', those + were removed too. Thanks to Pedro for explaining how to use -wrap. + + So, bottom line, this test does not introduce any new failures on the + platforms on which I've tested, but the XFAILs are certainly unfortunate. + Some aren't fixable - e.g. when attempting to make a function call while + debugging a core file - but I think that some of them are. I'm using + this new test case as a starting point for investigating problems with + printing errno. + + Co-Authored-By: Jan Kratochvil + Approved-By: Tom de Vries + +2024-05-31 Claudio Bantaloukas + + aarch64, testsuite: avoid regexes in opcode field + Some dejagnu files use regexes rather than specific encodings. This + change replaces them with the explicit encodings we expect. + + Tested against aarch64-unknown-linux-gnu and aarch64-none-elf. + +2024-05-31 saurabh.jha@arm.com + + gas, aarch64: Fixes in texi and tests following faminmax and lut changes + Making two cleanups that came out of the comments from my previous + patches: + 1. Fixing `c-aarch64.texi` file so that the AArch64 architecture + extensions are ordered alphabetically. + 2. Fixing faminmax test cases so that they follow the existing test + conventions. + +2024-05-31 Tom Tromey + + Move dwarf2_per_bfd::index_addrmap to mapped_gdb_index + dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader, + so this field can be moved to mapped_gdb_index instead. Then, + cooked_index_functions::find_per_cu can be removed in favor of a + method on the index object. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821 + Approved-By: Simon Marchi + +2024-05-31 Szabolcs Nagy + + aarch64: Add some DT_RELR ld tests + +2024-05-31 Szabolcs Nagy + + aarch64: Add DT_RELR support + The logic to decide if an input relocation for a symbol becomes a + particular kind of output relocation is one of the hard to maintain + parts of the bfd ld backend, since it is partially repeated across + + elfNN_aarch64_check_relocs (where dynamic relocations are counted per + symbol and input section), + + elfNN_aarch64_late_size_sections (where relocation sections are sized + and GOT offsets assigned), + + elfNN_aarch64_relocate_section (where most relocations are applied and + output to a relocation section), + + elfNN_aarch64_finish_dynamic_symbol (where some of the GOT + relocations are applied and output). + + The DT_RELR support adds another layer to this complexity: after the + output relocation sections are sized, so all dynamic relocations are + accounted (in elfNN_aarch64_late_size_sections), we scan the symbols + and input relocations again to decide which ones become relative + relocations that can be packed. The sizes of the relocation sections + are updated accordingly. This logic must be consistent with the code + that applies the relocs later so each relative relocation is emitted + exactly once: either in .rela.* or packed in .relr.dyn. + + Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that + may be called repeatedly whenever the layout changes since an address + change can affect the size of the packed format. Then the final content + is emitted in elfNN_aarch64_finish_relative_relocs, that is called + after the layout is final and before relocations are applied and + emitted. These hooks are only called if DT_RELR is enabled. + + We only pack relative relocs that are known to be aligned in the output + during .relr.dyn sizing, the potentially unaligned relative relocs are + emitted normally (in .rela.*, not packed), because the format requires + aligned addresses. + +2024-05-31 Jan Beulich + + x86: reduce check_{byte,word,long,qword}_reg() overhead + These run after template matching. Therefore it is quite pointless for + them to check all operands, when operand sizes matching across operands + is already known. Exit the loops early in such cases. + + In check_byte_reg() also drop a long-stale part of a comment. + +2024-05-31 Felix Willgerodt + Nils-Christian Kempke + + gdb, amd64: remove unused forward declarations + These structs are not referenced anywhere anymore and seemed to have been + missed at some point when their usage was removed. + + Approved-By: Tom Tromey + +2024-05-31 Felix Willgerodt + + gdb, doc: Fix AVX-512 documentation. + org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the + docs yet. Fix that. + + In addition the documentation describes xmm registers with an `h` + (e.g. xmm16h). I am assuming that we follow the register xml files here, + which don't have the h suffix. So this removes that as well. + + Approved-By: Eli Zaretskii + +2024-05-31 Simon Marchi + + gdb: remove unused includes in utils.h + Remove some includes reported as unused by clangd. Add some includes in + other files that were previously relying on the transitive include. + + Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e + +2024-05-31 GDB Administrator + + Automatic date update in version.in + +2024-05-30 Simon Marchi + + gdb: remove unused includes in symfile.c + Remove some includes reported as unused by clangd. + + Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6 + +2024-05-30 Simon Marchi + + gdb: remove unused includes in breakpoint.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d + +2024-05-30 Nick Clifton + + Update binutils release documentation to include using the -z option when invoking src-release.sh + +2024-05-30 Mark Wielaard + + src-release.sh: Support zstd compression + +2024-05-30 Simon Marchi + + .gitignore: ignore .vscode + +2024-05-30 GDB Administrator + + Automatic date update in version.in + +2024-05-29 Andrew Burgess + + gdb/doc: don't have .pod targets separate to man page targets + While preparing the new release it was discovered that commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + was causing problems. Given a release tar file, an attempt to build + and install GDB would give an error like this: + + [...] + TEXI2POD gdb.pod + cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make[5]: *** [Makefile:663: gdb.pod] Error 2 + + The problem here is how the man pages are built, and how they are + distributed within a release. + + Within the development (git) tree, the man page files are not part of + the source tree, these files are built as needed. Within a release + tar file though, the man pages are included. The idea being that a + user can build and install GDB, including getting the man pages, + without having to install the tools needed to generate the man pages. + + The man pages are generated in a two step process. First the .texi + file is processed with texi2pod to create a .pod file, then this .pod + file is processed to create the .1 or .5 man file. + + Prior to the above commit these two steps were combined into a single + recipe, this meant that when a user performed a build/install from a + release tree all of the dependencies, as well as the final result, + were all present in the source tree, and so nothing needed to be + rebuilt. + + However, the above commit split the two steps apart. Now we had a + separate rule for building the .pod files, and the .1/.5 man page + files depended on the relevant .pod file. + + As the .pod files are not shipped in a GDB release, this meant that + one of the dependencies of the man page files was now missing. As a + result if a user tried to install from a release tree a rebuild of the + .pod files would be attempted, and if that succeeded then building the + man pages would follow that. + + Unfortunately, building the .pod files would fail as the GDBvn.texi + file, though present in the source tree, was not present in the build + tree, which is where it is needed for the .pod file generation to + work. + + To fix this, I propose merging the .pod creation and the .1/.5 man + page creation back into a single recipe. Having these two steps split + is probably the "cleaner" solution, but makes it harder for us to + achieve our goal of shipping the prebuilt man page files. I've added + a comment explaining what's going on (such a comment would have + prevented this mistake having been made in the first place). + + One possibly weird thing here is that I have left both an + ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S) + recipes. This is 100% not going to break anything, these just print + two different progress messages while executing the recipes, but I'm + not sure if this is considered poor style or not. Maybe we're only + supposed to have a single ECHO_* per recipe? + + Anyway, even if this is poor style, I figure it really is just a style + thing. We can tweak this later as needed. Otherwise, this commit + should fix the current issue blocking the next GDB release. + + Approved-By: Tom Tromey + +2024-05-29 Szabolcs Nagy + + readelf: Use section names for displaying RELR relocs + In some cases using section names instead of symbol names for + displaying an address is more useful. + + If the symbol falls outside the section where the address is + then likely it is not useful to display the address relative to. + + And if symbols are stripped from a binary then printing the + section that contains the address is more useful than printing + . + +2024-05-29 Szabolcs Nagy + + readelf: Fix symbol display for RELR relocs + Filter symbols before binary searching for the right symbol to display + for a given address, such that only displayable symbols are present and + at most one per address. + + The current logic does not handle multiple symbols for the same address + well if some of them are empty, the selected symbol is not stable with + respect to an unrelated symbol table change and on aarch64 often mapping + symbols are displayed which is not useful. + + Filtering solves these problems at the cost of a linear scan of the + sorted symbol table. + + The heuristic to select the best symbol likely could be improved, this + patch aims to improve symbol display for RELR without complex logic + such that the output is useful and stable for ld tests. + +2024-05-29 Jan Beulich + + x86/Intel: warn about undue mnemonic suffixes + Except for very few insns mnemonic suffixes aren't permitted in Intel + syntax. Warn about such for now, indicating that they will be outright + refused down the road. + + While fiddling with testcases to address fallout, drop a few things + which should never have been tested as valid Intel syntax. + + Also add a previously missing line to simd-suffix.d. + +2024-05-29 Jan Beulich + + x86/Intel: SHLD/SHRD have dual meaning + Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode + an L suffix may be used, we need to be consistent with this. + + Take the easy route, despite that still leading to an anomaly which is + also visible from the new testcase: + + shld eax, ecx, 1 + shld eax, ecx, cl + + can mean two things with APX: SHL with a D suffix in NDD EVEX encoding, + or the traditional SHLD in legacy encoding. + +2024-05-29 Alan Modra + + PR31796, Internal error in write_function_pdata at obj-coff-seh + PR31796 is the result of lack of aarch64 support in obj-coff-seh.c. + Nick fixed this with commit 73c8603c3f. Make the seh support + consistently warn in future if some archictecture is missing, rather + than giving internal errors. + + PR 31796 + * config/obj-coff-seh.c (verify_target): New function. + (obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc), + (obj_coff_seh_endprologue): Use it. + +2024-05-29 GDB Administrator + + Automatic date update in version.in + +2024-05-28 Dimitar Dimitrov + + ld: pru: Increase the default memory region sizes + The default memory region sizes for PRU were set somewhat arbitrarily to + the sizes of the most popular BeagleBone board with AM33x SoC. But the + PRU toolchain documentation has always instructed to use SoC-specific + spec files to override the defaults and set the correct memory sizes [1]. + + The small default memory sizes can cause IMEM memory region overflow + even for simple printf("Hello world") programs, as usually done by + Autotools checks. The stdio is simply too big to fit in 8K + instruction memory. This can confuse the check and lead to wrong + feature selection during configure [2]. + + Fix by bumping the default DMEM and IMEM memory sizes. + + There is no need to backport this patch. Issue was caught with a + feature-rich newlib build used for daily CI. The release builds of the + PRU toolchain use stripped newlib configuration, which does not overflow + the IMEM region, even for 8K. + + [1] https://github.com/dinuxbg/gnuprumcu + [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 + +2024-05-28 Tom Tromey + + Make tui_win_info::make_window non-virtual + Nothing overrides tui_win_info::make_window, so remove the "virtual". + Tested by rebuilding. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add SVE2 lut extension + Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions use new SVE2 vector operands. They are called + SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have + 1 bit, 2 bit, and 3 bit indices respectively. + + The lsb and width of these new operands are the same as many existing + operands but the convention is to give different names to fields that + serve different purpose so we introduced new fields in aarch64-opc.c + and aarch64-opc.h. + + We made a design choice for the second operand of the halfword variant of + luti4 with two register tables. We could have either defined a new operand, + like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With + the new operand, we would need to implement constraints on register + lists based on either operand or opcode flag. With existing operand, we + could just existing constraint checks using opcode flag. We chose + the second approach and went with SVE_ZnxN and added opcode flag to + enforce lengths of vector register list operands. This way, we can reuse + the existing constraint check logic. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add AdvSIMD lut extension + Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions needed definition of some new operands. We will first + discuss operands for the third operand of the instructions and then + discuss a vector register list operand needed for the second operand. + + The third operands are vectors with bit indices and without type + qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12 + and they have 1 bit, 2 bit, and 3 bit indices respectively. For these + new operands, we defined new parsing case branch. The lsb and width of + these operands are the same as many existing but the convention is to + give different names to fields that serve different purpose so we + introduced new fields in aarch64-opc.c and aarch64-opc.h for these new + operands. + + For the second operand of these instructions, we introduced a new + operand called LVn_LUT. This represents a vector register list with + stride 1. We defined new inserter and extractor for this new operand and + it is encoded in FLD_Rn. We are enforcing the number of registers in the + reglist using opcode flag rather than operand flag as this is what other + SIMD vector register list operands are doing. The disassembly also uses + opcode flag to print the correct number of registers. + +2024-05-28 Tom Tromey + + Use bool in thread_events + This changes target_ops::thread_events and target_thread_events to use + 'bool'. The callers were already doing this. + + Tested by rebuilding. + + Approved-By: Simon Marchi + +2024-05-28 Nick Clifton + + Fix typo in assembler documentation + + Fix: internal error in write_function_pdata at obj-coff-seh + PR 31796 + + Updated Spanish translation for the BFD sub-directory. + +2024-05-28 Richard Earnshaw + + opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions + The autogenerated files in opcodes use spaces for indentation. + Changing that would be a lot of work to little benefit, so add a local + override to the white-space rules, so patches apply cleanly. + +2024-05-28 Nick Clifton + + Add new ELF section and segment types to readelf. + +2024-05-28 Javier Mora + + RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi + The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the + bit arrangement of the simm20 immediate that belongs to the J type; + It should be just `simm20[19:0]`. The current behavior of `gas` matches + the proposed documentation change. + + Additionally, the opcode is called `opcode6` despite of having 7 bits. + Rename it to `opcode7`. + + gas/ + * doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7. + +2024-05-28 GDB Administrator + + Automatic date update in version.in + +2024-05-27 Tom Tromey + + Re-run make-target-delegates.py + I re-ran make-target-delegates.py and discovered that the tree was out + of sync. This patch corrects the problem. + +2024-05-27 Nelson Chu + + RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc. + This was originally reported by Hau Hsu . + + Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d + + We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt + in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64. + This just like what did in the riscv_elf_finish_dynamic_symbol. + + bfd/ + * elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use + riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the + riscv_elf_relocate_section when handling ifunc data reloc. + ld/ + * testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed. + * testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed. + +2024-05-27 Nelson Chu + + RISC-V: Segment fault for kernel purgatory when linking. + This was originally reported by Ard Biesheuvel . + + The followings are reproduce steps, + https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u + + The segment fault happens in the riscv_elf_finish_dynamic_sections when the + output got section is an ABS. Refer to MIPS code, they added an extra + bfd_is_abs_section check to avoid ABS got, so this seems the right and easier + way to go in the short-term. + + bfd/ + * elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize + and fill the got entries only when the got isn't an ABS section, and + the size of got is larger than zero. The similar goes for gotplt, + except we already reported error when the gotplt is an ABS. + +2024-05-27 mengqinggang + + LoongArch: Fix relaxation overflow caused by ld -z separate-code + ld -z separate-code let .text and .rodata in two different but read only + segment. If the symbol and pc in two segment, the offset from pc to + symbol need to consider segment alignment. + + Add a function 'loongarch_two_sections_in_same_segment' to determine + whether two sections are in the same segment. + +2024-05-27 GDB Administrator + + Automatic date update in version.in + +2024-05-26 Joel Brobecker + + Update gdb/NEWS after GDB 15 branch creation. + This commit a new section for the next release branch, and renames + the section of the current branch, now that it has been cut. + +2024-05-26 Joel Brobecker + + Bump version to 16.0.50.DATE-git. + Now that the GDB 15 branch has been created, + this commit bumps the version number in gdb/version.in to + 16.0.50.DATE-git + + For the record, the GDB 15 branch was created + from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd. + + Also, as a result of the version bump, the following changes + have been made in gdb/testsuite: + + * gdb.base/default.exp: Change $_gdb_major to 16. + +2024-05-26 GDB Administrator + + Automatic date update in version.in + +2024-05-25 H.J. Lu + + ld: Document -pie -Ttext-segment=ORG generates ET_EXEC + This is the v2 patch I am checking in. + + H.J. + +2024-05-25 GDB Administrator + + Automatic date update in version.in + +2024-05-24 Alan Modra + + Re: LoongArch: gas: Adjust DWARF CIE alignment factors + Adjust the gas testsuite to suit commit de203ed568f6. + + * testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d: + Expect data alignment of -8. Tidy. + +2024-05-24 Jan Beulich + + gas: extend \+ support to .irp / .irpc + PR gas/31752 + + These are effectively macro-like, without any separate macro definition. + They already support \@, so they would better also support \+. This + allows, where desired, to get away without maintaining an explicit count + variable in source code. + + With this the recently introduced testcase doesn't need any xfails + anymore. + +2024-05-24 Jan Beulich + + gas: adjust handling of quotes for .irpc + The present handling of inner double quotes can lead to very strange + diagnostics. Follow one of the two possible interpretations of the doc: + @dots{} referring to possibly multiple white space separated + @var{values}, each of which may be quoted. The original implementation, + prior to 465e5617233f ("PR gas/3856"), hints at the other possible + interpretation: When quoted there's only a single @var{values}, with + inner quotes taken as ordinary characters. That, however, seems overall + less useful to me. + + While touching the documentation, mirror the (inverse) spelling + correction (@section line inconsistent with actual description) to .irp + as well. + +2024-05-24 Jan Beulich + + x86: simplify VexVVVV_SRC2 handling for the XOP case + As already suggested during review, rather than having an extra + conditional in build_modrm_byte() (a code path used for quite a few + more insns, including even certain GPR ones), adjust the attribute in + the installed template to properly describe things with operands + swapped. + +2024-05-24 Jan Beulich + + x86: simplify / consolidate check_{word,long,qword}_reg() + These run after template matching. Therefore operands are already known + to match the template in use. With the loop bodies skipping anything not + a GPR in the actual operands, there's therefore no need to check the + template's operand type for permitting Reg or Accum. + + At the same time bring the three functions in sync for the "byte" part + of the logic, as far as checking the template for other sizes (qword + specifically) goes. Plus drop a stale comment from check_qword_reg(), + when all three are now behaving the same in this regard. + +2024-05-24 Jan Beulich + + x86: correct VCVT{,U}SI2SD + Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly + omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]), + to avoid emitting bad or arbitrarily guessed instructions. Interestingly + check_{long,qword}_suffix() don't help here, which perhaps is another + indication that the way they work right now isn't quite appropriate. + + Sadly correcting just the templates breaks operand ambiguity detection, + since so far that worked from a single template permitting more than one + suffix. Here we have ambiguity though which can now be noticed only when + taking all (matching) templates together. Therefore we need to determine + further matching templates (see code comments for constraints), to then + accumulate permitted suffixes across all of them. + +2024-05-24 Tom de Vries + + [gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp + When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run + regularly into PR26286: + ... + (gdb) continue^M + Continuing.^M + [LWP ... exited]^M + ... + [LWP ... exited]^M + ^M + Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M + The program no longer exists.^M + (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 + ... + + Add a kfail for this, such that we have: + ... + (gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 (PRMS: threads/26286) + ... + + Reviewed-By: Thiago Jung Bauermann + + Tested on x86_64-linux. + +2024-05-24 GDB Administrator + + Automatic date update in version.in + +2024-05-23 Felix Willgerodt + + gdb, testsuite: Fix return value in gdb.base/foll-fork.exp + In a remote testing setup, I saw this error: + + ~~~ + (gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main + ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp. + ERROR: expected boolean value but got "" + while executing + "if { ![check_fork_catchpoints] } { + untested "follow-fork not supported" + return + }" + (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434) + invoked from within + "source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + ("uplevel" body line 1) + invoked from within + "uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + invoked from within + "catch "uplevel #0 source $test_file_name"" + Remote debugging from host 172.0.1.3, port 37766 + Killing process(es): 1171 + Quit + ~~~ + + The actual reason for this were some connection problems. Though the + function check_fork_catchpoints shouldn't return an empty string, especially + as it promises to always return 0 or 1. Fix that. + + Approved-By: Tom Tromey + +2024-05-23 Thiago Jung Bauermann + + gdb/testsuite: Restore libc_has_debug_info's less strict behaviour + The code that was factored out from gdb.base/relativedebug.exp assumed that + libc has debug info and only determined that it doesn't if it saw a specific + message from GDB to that effect. In the process of factoring it into a + require predicate, I made it stricter by trying to make a specific + determination of whether or not debug info is available. + + Pedro noticed that "It'll disable the testcase on systems that link with + their libc statically (even if has debug info), or systems that name their + libc something else." Which is something I hadn't considered. + + This patch returns libc_has_debug_info to the original behaviour. + + Also, remove a verbose message that is redundant with the $message + variable. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700 + Approved-By: Tom Tromey + +2024-05-23 GDB Administrator + + Automatic date update in version.in + +2024-05-22 Alan Modra + + libctf testsuite compilation failure + * testsuite/libctf-regression/open-error-free.c (main): Correct + format length modifier. + +2024-05-22 Tom Tromey + + Default dwarf_synchronous to true + Unfortunately the background DWARF reading series introduced a number + of races, as repored by thread sanitizer. This patch changes gdb to + disable this feature for the time being -- in particular for the gdb + 15 release. + + I've filed a bug and linked all the known races to it. Once those are + fixed we can re-enable this feature by default. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751 + +2024-05-22 Indu Bhagat + + restore build with --enable-maintainer-mode + A build with --enable-maintainer-mode is currently failing with: + + make[4]: *** No rule to make target '/gas/config/te-ia64aix.h', + needed by '/gas/po/gas.pot'. Stop. + make[4]: Leaving directory '<$OBJ>/gas/po' + make[3]: *** [Makefile:1695: all-recursive] Error 1 + ... + + As config/te-ia64aix.h is now removed, remove the corresponding fragment + from the makefile. + + gas/ + * Makefile.am: Remove config/te-ia64aix.h. + * Makefile.in: Regenerate. + * po/POTFILES.in: Regenerate. + +2024-05-22 Matthieu Longo + + aarch64: fix incorrect encoding for system register pmsdsfr_el1 + This patch fixes a mistake in the encoding of the system register + pmsdsfr_el1. + + Reference: + https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en + +2024-05-22 Cui, Lili + + Support APX zero-upper + This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc. + Since the spec only recommends one form of setzu, I won't be adding + setreg32/reg64 support in this patch. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Handle ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.d: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~ + PREFIX_EVEX_MAP4_4F. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct dis386): Add new micro 'ZU'. + (putop): Handle %ZU. + * i386-gen.c: Added ZU. + * i386-opc.h: Ditto. + * i386-opc.tbl: Added new templates to support ZU. + +2024-05-22 Cui, Lili + + X86: Remove "i.rex" to eliminate extra conditional branch + Resulting code will do better without the extra conditional branch. + Remove "i.rex" to eliminate extra conditional branch. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Remove i.rex. + +2024-05-22 Vladimir Mezentsev + + gprofng: use StringBuilder to create long messages + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * src/collctrl.cc: Use StringBuilder to create messages. + Remove unused variables and arrays. + * src/collctrl.h: Remove unused variables. + +2024-05-22 Vladimir Mezentsev + + gprofng: Remove hardware counter tables for unsupported hardware (Sparc) + ChangeLog + 2024-05-20 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwctable.c: Remove hardware counter tables for Sparc machines. + +2024-05-22 Vladimir Mezentsev + + gprofng: remove memset() in libcollector + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * libcollector/collector.c: Use static initialization instead of memset. + * libcollector/dispatcher.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/synctrace.c: Likewise. + +2024-05-22 Cui, Lili + + Add check for 8-bit old registers in EVEX format + Since APX supports EVEX from legacy instructions, we need to check + the 8-bit old registers in EVEX format. And add test cases for it. + + gas/ChangeLog: + + * config/tc-i386.c (md_assemble): Add invalid check for old byte + registers in EVEX format. + * testsuite/gas/i386/x86-64-apx-inval.l: Add new test. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + +2024-05-22 Cui, Lili + + x86: Split REX/REX2 old registers judgment. + Split "REX/REX2 old register checking" and "add empty rex prefix" + into two separate branches. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Split the judgments. + +2024-05-22 GDB Administrator + + Automatic date update in version.in + +2024-05-21 Indu Bhagat + + gas: ginsn: remove unnecessary buffer allocation and free + A previous commit 80ec235 fixed the memory leaks, but brought to light + that the code should ideally make consistent use of snprintf and not + allocate/free more buffers than necessary. + + gas/ + * ginsn.c (ginsn_dst_print): Use snprintf consistently. + +2024-05-21 Srinath Parvathaneni + + aarch64: Fix the hyphenated disassembly comment. + This patch fixes the following comment. + + - /* The hyphenated form is preferred for disassembly if there are + - more than two registers in the list, and the register numbers + are monotonically increasing in increments of one. */ + + + /* The hyphenated form is preferred for disassembly if there is + + more than one register in the list, and the register numbers + are monotonically increasing in increments of one. */ + +2024-05-21 Tom Tromey + + Clarify documentation for pretty_printer.child + An Ada pretty-printer had a bug where its 'child' method returned a + gdb.Value rather than a tuple. Kévin suggested that the documentation + for this method could be improved to clarify this. + + Reviewed-By: Kévin Le Gouguec + Approved-By: Eli Zaretskii + +2024-05-21 Jan Beulich + + gas: drop remnants of ia64-*-aix* + With BFD not supporting that target anymore, GAS can't possibly support + it either. + + ld: silence makeinfo warnings + Older tool versions (4.12 in my case) demand . or , after @xref{}; + arrange for this to be the case. + +2024-05-21 Nick Alcock + + include, libctf: improve documentation + Some review comments came in after I pushed the last lot of ctf-api.h + comment improvements. They were good, so I've incorporated them. + Mostly: better _next iterator usage info, better info on ctf_*open + functions, and better info on ctf_type_aname and ctf_type_name_raw. + + include/ + * ctf-api.h: improve documentation. + +2024-05-21 GDB Administrator + + Automatic date update in version.in + +2024-05-20 Kévin Le Gouguec + + gdb: Fix Windows build after #include shuffle + Without this patch, the build chokes on: + + ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic' + 384 | std::atomic m_debug_event_pending { false }; + | ^~~~~~~~~~~~~~~~~~~~~ + In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33, + from […gcc tree…]/include/c++/13.2.1/memory:81, + from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23, + from ../../src/gdb/../gdbsupport/common-utils.h:26, + from ../../src/gdb/../gdbsupport/common-defs.h:199, + from ./../../src/gdb/defs.h:26, + from : + […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic' + 174 | struct atomic; + | ^~~~~~ + make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1 + + Presumably windows-nat.c relied on objfiles.h including , + which was undone in 2024-05-16 "gdb: remove unused includes in + objfiles.{c,h}" (f617661c110). + +2024-05-20 Luca Boccassi + + readelf: add pretty printing for FDO Dlopen Metadata note + +2024-05-20 Nick Clifton + + Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh + PR 31726 + +2024-05-20 Tom de Vries + + [gdb/testsuite] Fix can_spawn_for_attach_1 consistency check + When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with + target board native-gdbserver, we run into: + ... + (gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp. + ERROR: gdbserver does not support attach 4827 without extended-remote + while executing + "error "gdbserver does not support $command without extended-remote"" + (procedure "gdb_test_multiple" line 51) + invoked from within + "gdb_test_multiple "attach $test_pid" "can spawn for attach" { + -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." { + # Not permitte..." + (procedure "gdb_real__can_spawn_for_attach_1" line 27) + invoked from within + "gdb_real__can_spawn_for_attach_1" + ... + + The problem is that: + - can_spawn_for_attach_1 is a helper function for can_spawn_for_attach, + designed to be called only from that function, and + - can_spawn_for_attach_1 is a gdb_caching_proc, and consequently + test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls + can_spawn_for_attach_1 directly. + + Fix this by copying the early-outs from can_spawn_for_attach to + can_spawn_for_attach_1. + + Tested on x86_64-linux. + + Reported-By: Simon Marchi + Reviewed-By: Alexandra Petlanova Hajkova + +2024-05-20 Claudio Bantaloukas + + aarch64: Add support for the fpmr system register + +2024-05-20 Georg-Johann Lay + + Include .rodata size in avr-objdump -P mem-usage. + PR 31687 + + Let avr-objdump show .note.gnu.avr.deviceinfo + PR 31704 + +2024-05-20 Sung-hun Kim + + RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa + The DWARF specification (especially, DWARF4 and 5 [1,2]) states that + DW_CFA_def_cfa_register cannot be used as the first CFI operation. + It said DW_CFA_def_cfa_register as follows: + + ... This operation is valid only if the current CFA rule is defined + to use a register and offset. + + So, DW_CFA_def_cfa_register can be used after that other definition + operation such as DW_CFA_def_cfa is called. However, the current gas + code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV. + + In the libgcc, the unwinding function does not care about it, so it can + unwind the call stack. However, on the third party library such as + libunwindstack in Android, it causes a fatal error. + + This patch changes the initial CFI operation to DW_CFA_def_cfa with + offset 0. It works as same as the previous one, but it does not have + any limitation so it satisfies the DWARF spec. This change resolves + the compatibility issue while preserving the original behaviour. + + [1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf + [2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf + + Reviewed-By: Andrew Burgess + Approved-By: Nelson Chu + + gas/ + PR 31733 + config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use + DW_CFA_def_cfa rather than DW_CFA_def_cfa_register. + +2024-05-20 GDB Administrator + + Automatic date update in version.in + +2024-05-19 GDB Administrator + + Automatic date update in version.in + +2024-05-18 Tom Tromey + + Remove unnecessary block from execute_fn_to_ui_file + I noticed that execute_fn_to_ui_file has an extra, unnecessary block. + This patch removes it. + +2024-05-18 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen3 + Historically, we have used several APIs (perfctr, libcpc, perf_event_open) for profiling. + For each hardware we have several tables of hardware counters. + Some information is duplicated in these tables. + Some of the information is no longer used. + I did not touch the existing hwc tables. + I added a new hwc table for an AMD Zen3 machine. + + ChangeLog + 2024-05-16 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c (core_pcbe_get_events): Add new argument. + * common/hwc_cpus.h: New constants for AMD hardware. + * common/hwcdrv.c: Add new argument to hwcdrv_get_descriptions. + Clean up the code. + * common/hwcdrv.h: Likewise. + * common/hwcfuncs.c (hwcdrv_get_descriptions): Add new argument. + * common/hwctable.c: Add the hwc table for AMD Zen3. + * src/hwc_amd_zen3.h: New file. + * common/opteron_pcbe.c: Add new argument to opt_pcbe_get_events. + * src/collctrl.cc: Remove unused variable. + * src/collctrl.h: Likewise. + +2024-05-18 Vladimir Mezentsev + + gprofng: remove old interface with libcpc + interface with libcpc was used on Solaris. + gprofng doesn't support profiling on Solaris. + I removed this old code and other unused macros and variables. + + gprofng/ChangeLog + 2024-04-29 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwcdrv.c: remove old interface with libcpc. + * common/hwcdrv.h: Likewise. + * common/hwcentry.h: Likewise. + * common/hwcfuncs.c: Likewise. + * common/hwcfuncs.h: Likewise. + * common/hwctable.c: Likewise. + * src/Dbe.cc: Likewise. + * src/collctrl.cc: Likewise. + +2024-05-18 GDB Administrator + + Automatic date update in version.in + +2024-05-17 Indu Bhagat + + bfd: sframe: minor code adjustments and fix typos + bfd/ + * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use local + variable. + (_bfd_x86_elf_size_dynamic_sections): Fix typos. + +2024-05-17 Tom Tromey + + Remove gdb_stdtargerr + This patch removes gdb_stdtargerr. There doesn't seem to be a need + for this -- it is always the same as stdtarg, and (I believe) has been + for many years. + + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Don't allow new-ui to start the TUI + The TUI can't really work properly with new-ui, at least not as + currently written. This patch changes new-ui to reject an attempt. + Attempting to make a DAP ui this way is also now rejected. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Inline some ui_out methods + I noticed a few ui_out methods that are just trivial wrappers. This + patch moves these to ui-out.h, as it seems like they should be + inlineable. + + Approved-By: Andrew Burgess + +2024-05-17 Dmitry Neverov + + gdb/symtab: use symbol name matcher for all segments in a qualified name + +2024-05-17 Dmitry Neverov + + gdb/symtab: compute match_type outside the loop + It will be used for all segments in a qualified name, + not only the last one. + + Approved-By: Tom Tromey + +2024-05-17 Dmitry Neverov + + gdb/symtab: reuse last segment lookup name info by creating it outside the loop + +2024-05-17 Dmitry.Neverov + + gdb/symtab: check name matches before expanding a CU + The added check fixes the case when an unqualified lookup + name without template arguments causes expansion of many CUs + which contain the name with template arguments. + + This is similar to what dw2_expand_symtabs_matching_symbol does + before expanding the CU. + + In the referenced issue the lookup name was wxObjectDataPtr and many + CUs had names like wxObjectDataPtr. This caused + their expansion and the lookup took around a minute. The added check + helps to avoid the expansion and makes the symbol lookup to return in + a second or so. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520 + +2024-05-17 Nick Alcock + + include, libctf: add a bunch of documentation to ctf-api.h + Hopefully this library is no longer quite so much a "you have to look + in the source to understand anything" library. + + No semantic changes, though some functions have been moved around for + clarity. + + include/ + ctf-api.h: Add comments. + +2024-05-17 Nick Alcock + + libctf: fix leak of entire dict when dict opening fails + Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount + loops") ctf_dict_close has only freed anything if the refcount on entry + to the function is precisely 1. >1 obviously just decrements the + refcount, but the linker machinery can sometimes cause freeing to recurse + from a dict to another dict and then back to the first dict again, so + we interpret a refcount of 0 as an indication that this is a recursive call + and we should just return, because a caller is already freeing this dict. + + Unfortunately there is one situation in which this is not true: the bad: + codepath in ctf_bufopen entered when opening fails. Because the refcount is + bumped only at the very end of ctf_bufopen, any failure causes + ctf_dict_close to be entered with a refcount of zero, and it frees nothing + and we leak the entire dict. + + The solution is to bump the refcount to 1 right before freeing... but this + codepath is clearly delicate enough that we need to properly validate it, + so we add a test that uses malloc interposition to count allocations and + frees, creates a dict, writes it out, intentionally corrupts it (by setting + a bunch of bytes after the header to a value high enough that it is + definitely not a valid CTF type kind), then tries to open it again and + counts the malloc/free pairs to make sure they're matched. (Test run only + on *-linux-gnu, because malloc interposition is not a thing you can rely + upon working everywhere, and this test is not arch-dependent so if it + passes on one arch it can be assumed to pass on all of them.) + + libctf/ + * ctf-open.c (ctf_bufopen): Bump the refcount on failure. + * testsuite/libctf-regression/open-error-free.*: New test. + +2024-05-17 Nick Alcock + + libctf: test: add wrapper + This .lk option lets you run the lookup program via a wrapper executable. + For example, to run under valgrind and check for leaks (albeit noisily + because of the libtool shell script wrapper): + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add wrapper. + +2024-05-17 Nick Alcock + + libctf: test: add host + This .lk option lets you execute particular tests only on specific host + architectures. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add host. + +2024-05-17 Nick Alcock + + libctf: test: add lookup_link + This .lk option lets you link the lookup program with extra libraries + in addition to -lctf. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add lookup_link. + +2024-05-17 Nick Alcock + + libctf: ctf_archive_iter: fix tiny leak + If iteration fails because opening a dict has failed, ctf_archive_next does + not destroy the iterator, so the caller can keep going and try to open other + dicts further into the archive. ctf_archive_iter just returns, though, so + it should free the iterator rather than leaking it. + + libctf/ + * ctf-archive.c (ctf_archive_iter): Don't leak the iterator on + failure. + +2024-05-17 Nick Alcock + + libctf: failure to open parent dicts that exist should be an error + CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et + al) attempts to be helpful and auto-open and import any needed parent dict + in the same archive. But if this fails, the error is not reported but + simply discarded, and you silently get back a dict with no parent, that + *you* suddenly have to remember to import. + + This is not helpful behaviour: if the parent is corrupted or we run out of + memory or something, the caller is going to want to know! Split it in two: + if the dict cites a parent that doesn't exist at all (a lot of historic + dicts name "PARENT" as their parent, even when they're not even children, or + perhaps the parent dict is stored separately and you plan to manually + associate it), we skip it as now, but if the import fails with an actual + error other than ECTF_ARNNAME, return the error and fail the open. + + libctf/ + * ctf-archive.c (ctf_arc_import_parent): Return failure if + parent opening fails for reasons other thnn nonexistence. + (ctf_dict_open_sections): Adjust. + +2024-05-17 Nick Alcock + + libctf: typos + Some functions were renamed without the comments catching up. + + libctf/ + * ctf-open.c (upgrade_types_v1): Fix comment typos. + +2024-05-17 Jan Beulich + + aarch64: correct SVE2.1 ld2q (scalar plus scalar) + It's opcode was wrong, as was e.g. easily visible from the inappropriate + testcase expectation. + + aarch64: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) + Like their byte, half, word, and doubleword counterparts their + immediates are multiples of 3 / 4 respectively. + +2024-05-17 mengqinggang + + LoongArch: gas: Adjust DWARF CIE alignment factors + Set DWARF2_CIE_DATA_ALIGNMENT (data alignment factors) to -8. + It helps to save space. + + Data Alignment Factor + A signed LEB128 encoded value that is factored out of all offset + instructions that are associated with this CIE or its FDEs. This value + shall be multiplied by the register offset argument of an offset + instruction to obtain the new offset value. + +2024-05-17 GDB Administrator + + Automatic date update in version.in + +2024-05-16 Indu Bhagat + + gas: sframe: fix typo to use FP instead of BP + gas/ + * gen-sframe.c (output_sframe_internal): Use BP instead of FP. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Add missing terminator in Dwarf::_macro_unit + When printing complaints with one of the execs from test-case + gdb.dwarf2/macro-source-path.exp, we run into: + ... + $ gdb -q -batch \ + -iex "set complaints 100" \ + macro-source-path-clang14-dw4-absolute-cwd-32 \ + -ex "p main" + During symbol reading: debug info runs off end of .debug_macro section \ + [in module macro-source-path-clang14-dw4-absolute-cwd-32] + $1 = {int ()} 0x4004b7
+ ... + and readelf complains more specifically: + ... + Contents of the .debug_macro section: + + Offset: 0 + Version: 5 + Offset size: 4 + Offset into .debug_line: 0xe3 + + DW_MACRO_define - lineno : 0 macro : ONE 1 + DW_MACRO_define_strp - lineno : 0 macro : THREE 3 + DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c + DW_MACRO_define - lineno : 1 macro : TWO 2 + DW_MACRO_end_file + readelf: Error: .debug_macro section not zero terminated + ... + + Fix this by adding the missing terminator in Dwarf::_macro_unit. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused includes in objfiles.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a + +2024-05-16 Ijaz, Abdul B + + gdb, testsuite: Handle unused compiler option fdiagnostics-color=never. + The 'univeral_compile_options' in gdb.exp file only verifies the support + of '-fdiagnostics-color=never' for the "C" source file. So while running + tests with assembly source file (.s), many of them are not able to run + on icx/clang compilers because '-fdiagnostics-color=never' option is not + supported. This problem is not seen for the ".S" assembly source files so + these files are not handled separately. After this change, this function + is split into multiple functions to check the support for different type + of sources individually. + + Before this change, in the case of clang and ICX compiler, this error is + shown for assembly source files (.s): + + ''' + icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o + amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300) + + icx: warning: argument unused during compilation: '-fdiagnostics-color=never' + [-Wunused-command-line-argument] + + gdb compile failed, icx: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + + UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare + ''' + + Similarly this error is shown for the clang compiler: + + ''' + clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 + -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s + + clang: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + ''' + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: define type aliases for `fork_inferior()` callbacks + The `fork_inferior()` function accepts multiple callbacks, making its + signature a bit hard to read. Define some type aliases to make it a bit + clearer. Use function view for all, while at it. + + Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: initialize packet_result::m_textual_err_msg + When building GDB with -O2 and --enable-ubsan, I get some random errors + in the packet_result self test: + + /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool' + + This happens because packet_result::m_textual_err_msg is uninitialized + when using the second constructor. When such a packet_result object + gets copied, an invalid value for m_textual_err_msg (a bool field) is + loaded, which triggers ubsan. + + Avoid this by initializing m_textual_err_msg. + + Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused include in infcmd.c + clangd reports this header as unused. + + Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b + +2024-05-16 Simon Marchi + + gdb: remove unused includes from progspace.{c,h} + Remove some include files reported as unused by clangd. + + Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a + +2024-05-16 Simon Marchi + + gdb: bump black version to 24.4.2 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I79c221af1b2192f866a344ab17d6199b137371cb + +2024-05-16 Simon Marchi + + gdb: move lm_info to solib in dsbt_current_sos + Commit 8971d2788e79 ("gdb: link so_list using intrusive_list") + mistakenly removed the line that moves the lm_info unique pointer to + sop->lm_info, probably due to a bad conflict resolution. Restore that + line. + + Unfortunately, this code is only used for TI C66, which is not widely + tested (if used at all). + + Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb + Approved-By: Tom Tromey + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sme2 insn variants + Add the SME2 variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+sme2+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + Multi-vector floating-point convert from FP8 to + BFloat16 (in-order): + ----------------------------------------------- + + - bf1cvt { .H-.H }, .B + - bf2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved BFloat16: + ----------------------------------------------- + + - bf1cvtl { .H-.H }, .B + - bf2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from BFloat16 + to packed FP8 format: + ------------------------------------------------- + + - bfcvt .B, { .H-.H } + + Multi-vector floating-point convert from FP8 to + half-precision (in-order): + ----------------------------------------------- + + - f1cvt { .H-.H }, .B + - f2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved half-precision: + ----------------------------------------------- + + - f1cvtl { .H-.H }, .B + - f2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from half-precision + to packed FP8 format: + ------------------------------------------------------- + + fcvt_2h + + Multi-vector floating-point convert from single-precision + to packed FP8 format: + --------------------------------------------------------- + fcvt_4s + + Multi-vector floating-point convert from single-precision + to interleaved FP8 format: + --------------------------------------------------------- + + - fcvtn .B, { .S-.S } + + Multi-vector floating-point adjust exponent by vector: + ------------------------------------------------------ + + - fscale { .H-.H }, { .H-.H }, + .H + - fscale { .S-.S }, { .S-.S }, + .S + - fscale { .D-.D }, { .D-.D }, + .D + + Multi-vector floating-point adjust exponent: + -------------------------------------------- + + - fscale { .H-.H }, { .H-.H }, + { .H - .H } + - fscale { .S-.S }, { .S-.S }, + { .S - .S } + - fscale { .D-.D }, { .D-.D }, + { .D - .D } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sve2 insn variants + Add the SVE2 variant of the FP8 convert and scale instructions, + enabled at assembly-time using the `+sve2+fp8' architectural + extension flag. More specifically, support is added for the + following instructions: + + FP8 convert to BFloat16 (bottom/top): + ------------------------------------- + + - bf1cvt Z.H, Z.B + - bf2cvt Z.H, Z.B + - bf1cvtlt Z.H, Z.B + - bf2cvtlt Z.H, Z.B + + FP8 convert to half-precision (bottom/top): + ------------------------------------------- + + - f1cvt Z.H, Z.B + - f2cvt Z.H, Z.B + - f1cvtlt Z.H, Z.B + - f2cvtlt Z.H, Z.B + + BFloat16/half-precision convert, narrow and + interleave to FP8: + ------------------------------------------- + + - bfcvtn Z.B, { Z1.H - Z2.H } + - fcvtn Z.B, { Z1.H - Z2.H } + + Single-precision convert, narrow and interleave + to FP8 (bottom/top): + ----------------------------------------------- + + - fcvtnb Z.B, { Z1.S - Z2.S } + - fcvtnt Z.B, { Z1.S - Z2.S } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - Add advsimd insn variants + Add the advanced SIMD variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + FP8 convert to BFloat16 (vector): + --------------------------------- + + - bf1cvtl V.8H, V.8B + - bf2cvtl V.8H, V.8B + - bf1cvtl2 V.8H, V.16B + - bf2cvtl2 V.8H, V.16B + + FP8 convert to half-precision (vector): + --------------------------------------- + + - f1cvtl V.8H, V.8B + - f2cvtl V.8H, V.8B + - f1cvtl2 V.8H, V.16B + - f2cvtl2 V.8H, V.16B + + Single-precision to FP8 convert and narrow (vector): + ---------------------------------------------------- + + - fcvtn V.8B, V.4S, V.4S + - fcvtn2 V.16B, V.4S, V.4S + + Half-precision to FP8 convert and narrow (vector): + -------------------------------------------------- + + - fcvtn V.8B, V.4H, V.4H + - fcvtn V.16B, V.8H, V.8H + + Floating-point adjust exponent by vector: + ----------------------------------------- + + - fscale V.4H, V.4H, V.4H + - fscale V.8H, V.8H, V.8H + - fscale V.2S, V.2S, V.2S + - fscale V.4S, V.4S, V.4S + - fscale V.2d, V.2d, V.2d + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add feature flags and related structures + +2024-05-16 Pedro Alves + + Stop 'configure --enable-threading' if std::thread doesn't work + Currently, if you configure gdb with explicit --enable-threading, but + then configure detects std::thread does not work, configure silently + disables threading support and continues configuring. + + This patch makes that scenario cause a configuration error, like so: + + $ /home/pedro/gdb/src/configure --enable-threading && make + ... + configure: error: std::thread does not work; disable threading + make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 + make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' + make: *** [Makefile:1041: all] Error 2 + $ + + Additionally, if you don't explicitly pass --enable-threading, and + std::thread does not work, we will now get a warning (and the build + continues): + + $ /home/pedro/gdb/src/configure && make + ... + configure: WARNING: std::thread does not work; disabling threading + ... + + This is similar to how we handle --enable-tui and missing curses. The + code and error/warning messages were borrowed from there. + + Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 + Approved-By: Tom Tromey + +2024-05-16 Matthieu Longo + + aarch64: add SPMU feature and its associated registers + +2024-05-16 Nick Clifton + + Move assembler "IRP \+" test into a separate file. Add XFAILs for targets that do not support it. + +2024-05-16 Richard Earnshaw + + arm: remove incorrect handling of FP bignums in move_or_literal_pool + This hunk of code in move_or_literal_pool just looks wrong, but I + can't find a testcase that will tickle it to prove it. It looks a bit + like it was intended to catch cases where a bignum contained a + floating-point value, but there were a number of problems with it. + + - It tested X_add_number == -1, but an FP bignum is indicated by any + value <= 0. + - It converted the floating-point value to extended precision, but + that's not used on Arm beyond the legacy FPA code. No attempt was + made to match the FP value to the intended memory/mov operation. + + Since I can't construct a viable testcase, I've just removed the existing + code and made the function error out in this case: this seems more sensible + than generating wrong code or trying to write something more complex that + can't be tested anyway. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assembly + Add support for DW_MACRO_define_strp in dwarf assembly, and use it in + test-case gdb.dwarf2/macro-source-path.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Alan Modra + + Fix FAIL: macros altmacro + spu-elf and z80-coff fail this test due to "def" being a pseudo-op. + tic30-unknown-coff fails it due to '#' not starting comments. + + * testsuite/gas/macros/altmacro.s: Use /* */ comments. Rename + DEF to EDF. + +2024-05-16 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Fangrui Song + + gas: Fix \+ expansion for .irp and .irpc + .irp and .irpc receive a null macro_entry. \+ causes a crash after the + recent \+ support. Restore the previous behavior. + +2024-05-15 Andrew Carlotti + + aarch64: Add sysreg features to +d128 dependencies + We should revisit sysreg feature enablement and dependencies in future, but + this change should help until then. + + OK for master? + +2024-05-15 Andrew Carlotti + + aarch64: Add simd dependency to +sha2 + This matches the existing behaviour in GCC and LLVM, and also the current + documentation. + + OK for master? + +2024-05-15 Matthieu Longo + + aarch64: testsuite: share test utils macros and use them + This patch rewrites assembly tests to use utils macros declared in + sysreg-test-utils.inc. Some tests were adapted to use the new macro + rw_sys_reg. + + aarch64: testsuite: reorder write and read to match macro order + This patch aims at grouping write and read for a same system register + one after another so that the diff for the macro replacement does not + generate too much noise. + + aarch64: testsuite: use same regs for read and write tests + This patch aims at making easier to replacement of read and write + instructions to system registers by a macro that will use the same + registers for read and write. + + aarch64: testsuite: replace instruction addresses by regex + This patch removes the instruction addresses from the objdump's expected + output (.d files). The intended benefit from this clean-up is to allow to + swap lines around more easilly, and removes the noise of patches that add, + remove or reorder instructions. + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix handling of DW_MACRO_define_strx in dwo file + When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we + run into: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by passing the correct dwo argument to a + fetch_indexed_string call. + + That works fine for readelf -w, with with readelf -wm we have: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by doing load_debug_section_with_follow for + str_dwo / str_index_dwo sections instead of str / str_index sections when + handling .debug_macro.dwo. + + PR 31735 + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix printing of dwarf4 .debug_str_offsets.dwo + When compiling a hello world with dwarf4 split dwarf: + ... + $ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA + ... + we have in a-hello.s these three initial entries in .debug_str_offsets: + ... + .section .debug_str_offsets.dwo,"e",@progbits + .4byte 0 // indexed string 0x0: short int + .4byte 0xa // indexed string 0x1: /home/vries/binutils + .4byte 0x1f // indexed string 0x2: main + ... + but "readelf -ws a.out" starts at the third entry: + ... + Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo): + + Length: 0x30 + Index Offset [String] + 0 00000000 main + ... + + This is a regression since commit 407115429b3 ("Modified changes for + split-dwarf and dwarf-5."), which introduced a variable + debug_str_offsets_hdr_len in display_debug_str_offsets. + + Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case. + + PR 31734 + +2024-05-15 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Joseph Faulls + + RISC-V: Search for mapping symbols from the last one found + With previous behaviour, multiple mapping symbols within the same + function would result in all the mapping symbols being searched. + This could slow down disassembly dramatically. + + Multiple mapping symbols within a function can be a result of encoding + instructions as data, like sometimes seen in random instruction + generators. + + opcodes/ChangeLog: + + * riscv-dis.c (riscv_search_mapping_symbol): Use last mapping + symbol if it exists. + +2024-05-14 Tom Tromey + + Add spaceship operator to cp-name-parser.y + While debugging gdb, I saw this: + + During symbol reading: unexpected demangled name 'operator<=>, std::chrono::duration >' + + This happens because cp-name-parser.y does not handle the spaceship + operator. This patch implements this. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow function types as template parameters in name canonicalizer + This adds function types as template parameters in the C++ name + canonicalizer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Implement C++14 numeric separators + C++14 allows the use of the apostrophe as a numeric separator; that + is, "23000" and "23'000" represent the same number. This patch + implements this for gdb's C++ parser and the C++ name canonicalizer. + + I did this unconditionally for all C variants because I think it's + unambiguous. + + For the name canonicalizer, there's at least one compiler that can + emit constants with this form, see bug 30845. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ canonicalization of hex literals + Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to + different things. I think it's nicer for them to be the same. + Differences between types can be done using suffixes like "ll" and "u" + -- it's not really possible to implement C++ rules in the + canoncalizer, because no gdbarch is available. Possibly gdb should + even drop the type here and just represent all integers the same way + in names. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Remove some unnecessary allocations from cpname_state::parse_number + cpname_state::parse_number allocates nodes for various types and then + only uses one of them. This patch reduces the number of allocations + by not performing the unnecessary ones. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ name canonicalizations of character literals + The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should + canonicalize to the same string, but currently they do not -- the + former remains unchanged and the latter is transformed to + "void C<(char)'\001'>::m()". + + This patch fixes the bug and also adds some unit tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Change storage of demangle_component + This changes demangle_component objects to be stored on the obstack + that is part of demangle_info. It also arranges for a demangle_info + object to be kept alive by cp_merge_demangle_parse_infos. This way, + other data on the obstack can be kept while an "outer" demangle_info + needs it. + + Acked-By: John Baldwin + +2024-05-14 Tom Tromey + + Clean up demangle_parse_info + This changes demangle_parse_info to use inline initializers and to + remove some manual memory management. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow initialization functions in .y files + If you add an initialization function to a .y file, it will not show + up in init.c, because if the yacc output is in the build tree, it + won't be found. + + This patch changes the Makefile to be more robust in this situation. + +2024-05-14 Tom Tromey + + Remove test code from cp-name-parser.y + This removes the current test 'main' from cp-name-parser.y. There + aren't any tests using this, and nowadays it would be better as a unit + test. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Disallow trailing whitespace in docstrings + This patch changes the docstring self-test to verify that there is no + trailing whitespace at the end of lines. A few existing docstrings + had to be updated. + +2024-05-14 Tom Tromey + + Remove fflush call from tui_refresh_cmd_win + tui_refresh_cmd_win calls fflush, but there's a comment explaining + that the reason for the call is unknown. This patch removes the call. + I don't think it can be useful, since gdb doesn't generally use stdout + in this way -- only through ui_file. + +2024-05-14 Andrew Burgess + + gdb/doc: don't delete *.pod files too early + When doing 'make -C gdb/doc man' to build the man pages, I noticed + that the outputs were being rebuilt each time the make command was + rerun, even when the input files hadn't changed. + + This was caused by this commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + Which split the generation of the .pod file from the actual creation + of the man page file. Prior to this split it was OK to delete the + .pod file at the end of the recipe, the rule depending on the .texi + input file, and output was the .1 or .5 man page file. + + Now however, with the split, the man page creation depends on the .pod + file, if we delete this after creating the .1 or .5 man page file then + the next time we run 'make' the .pod file is missing and is + regenerated, which in turn triggers the regeneration of the man page + file. + + Fix this by leaving the .pod file around, and only cleaning up these + files in the 'mostlyclean' target. + + Which leads to a second problem, the POD_FILE_TMPS is not created + correctly, so we don't actually clean up the .pod files! This too is + fixed in this commit. + + After this commit running 'make -C gdb/doc man' will build the manual + pages the first time, and each subsequent run will do nothing. + + Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. + + Approved-By: Tom Tromey + +2024-05-14 Andrew Burgess + + gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flags + While working on another patch I needed to pass -Wl,-soname,NAME as a + compiler flag. I initially looked for other tests that did this, and + found a few examples, so I copied what they did. + + But when I checked the gdb.log file I noticed that we were actually + getting -Wl,-soname passed twice. + + I tracked the repeated option to 'proc gdb_compile_shlib_1' in + lib/gdb.exp. It turns out that we always add -Wl,-soname when + compiling a shared library. + + Here's an example of a build command from gdb.base/prelink.exp: + + builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ + /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \ + -fdiagnostics-color=never -shared -g \ + -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \ + -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so + + Notice that '-Wl,-soname,prelink.so' is repeated. + + I believe that all of the places where tests add '-Wl,-soname,NAME' as + a build option, are unnecessary. + + In this commit I propose we remove them all. + + As part of this change I've switched from calling gdb_compile_shlib + directly, to instead call build_executable and adding the 'shlib' + flag. + + I've tested with gcc and clang and see no changes in the test results + after this commit. All the compile commands still have -Wl,-soname + added, but now it's only added once, from within lib/gdb.exp. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-05-14 Pali Roh?r + + Improve objdump -p output of PE Import and Export Tables + PR 31738 + +2024-05-14 Jason Merrill + + Adjust C++ destructor type tests + In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge" + parameter from destructors of classes with no virtual bases; Linaro's CI + informed me that the gdb testsuite needs to be adjusted to match. + + Teested against GCC 13.2 and GCC 15 trunk. + + Approved-by: Kevin Buettner + +2024-05-14 Nick Clifton + + Fix gas's 'macro count' test for various targets + +2024-05-14 Aditya Vidyadhar Kamath + + Fix Segmentation Fault in AIX during multi process debugging. + Due to the recent commit in aix-thread.c, we see a segmentation fault + in AIX while debugging multiple process involving multiple threads. + + One example is a thread that can fork. The GDB output in AIX for the same is + + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 67110997)] + [New Thread 515 (tid 127404289)] + [New inferior 2 (process 16580940)] + Hello from Parent! + [process 16580940 exited] + [New inferior 3 (process 14549318)] + Hello from Parent! + [process 14549318 exited] + Fatal signal: Segmentation fault + ----- Backtrace ----- + + This is because in sync_threadlists () in aix-thread.c there when we + delete threads in unknown state we iterate through all the threads. + + When we have one or more threads with the same user thread ID but of different + process then we delete a wrong thread. Since we just check only the pdtid + in in_queue_threads.count (priv->pdtid) == 0 this happened. + + This patch is a fix for the same. + + The output after we apply this patch is: + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 75565441)] + [New Thread 515 (tid 63244397)] + [New inferior 2 (process 10813892)] + Hello from Parent! + [New inferior 3 (process 19005888)] + Hello from Parent! + + Thread 1.1 received signal SIGINT, Interrupt. + 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) info threads + Id Target Id Frame + * 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + 1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + 3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) q + A debugging session is active. + +2024-05-14 Richard Earnshaw + + arm: update documentation for removal of the Maverick extension + Finally, update the documentation and add a NEWS item. + + arm: remove Maverick support from BFD. + Remove the handling of Maverick from BFD. Where appropriate we handle + legacy code by mapping ep9312 onto Armv4t. + +2024-05-14 Richard Earnshaw + + arm: opcodes: remove Maverick disassembly. + Remove the patterns to match Maverick co-processor instructions from + the disassembly tables. + + This required fixing a couple of tests in the assembler testsuite + where we, probably incorrectly, disassembled generic co-processor + instructions as a Maverick instruction (it particularly made no sense + to do this for Armv6t2 in Thumb state). + +2024-05-14 Richard Earnshaw + + arm: binutils: drop Maverick support. + Remove the decoding of the Maverick flag from readelf. + + arm: remove Maverick support from the assembler. + Delete all the Maverick instructions and register handling from the + assembler. We continue to recognize -mcpu=ep9312, but treat it as an + alias for arm920t. We no-longer recognize -mfpu=maverick. + + arm: remove tests for Maverick FPU extensions + Before removing the code itself, remove the tests that will no-longer + apply. + +2024-05-14 GDB Administrator + + Automatic date update in version.in + +2024-05-13 Nick Clifton + + Add new assembler macro pseudo-variable \+ which counts the number of times a macro has been invoked. + +2024-05-13 GDB Administrator + + Automatic date update in version.in + +2024-05-12 GDB Administrator + + Automatic date update in version.in + +2024-05-11 Tom de Vries + + [gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp + When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide + container, I run into: + ... + temp/$pid/static-libc.c: In function 'main': + temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function + returning void [-Wreturn-mismatch] + 2 | void main (void) { return 0; } + | ^ + ... + UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link + ... + + Fix this by changing the return type to int. + + Tested on x86_64-linux. + +2024-05-11 GDB Administrator + + Automatic date update in version.in + +2024-05-10 Tom Tromey + + Change gdbarch_inner_than to return bool + A recent patch from Andrew pointed out that gdbarch_inner_than returns + 'int', while it should really return 'bool'. + + Approved-By: Pedro Alves + +2024-05-10 Tom Tromey + + Remove tui_refresh_all + This removes tui_refresh_all. There is only a single caller, + tui_refresh_all_win, so inlining the code there simplifies gdb at no + cost. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-05-10 Tom Tromey + + Add symbol, line, and location to DAP disassemble result + The DAP spec allows a number of attributes on the resulting + instructions that gdb currently does not emit. A user requested some + of these, so this patch adds the 'symbol', 'line', and 'location' + attributes. While the spec lets the implementation omit 'location' in + some cases, it was simpler in the code to just always emit it, as then + no extra tracking was needed. + + Implement tp_richcompare for gdb.Block + I noticed that two gdb.Block objects will never compare as equal with + '=='. This patch fixes the problem by implementing tp_richcompare, as + was done for gdb.Frame. + + Simplify DAP make_source callers + A couple callers of make_source call basename by hand. Rather than + add another caller like this, I thought it would be better to put this + ability into make_source itself. + + Remove FIXME from DAP + This patch removes one of the few DAP "FIXME" comments. This + particular comment is already covered by PR dap/31036. + +2024-05-10 Tom Tromey + + Pass stream to remote_console_output + I noticed that remote_target::rcmd did not pass its ui_file argument + down to remote_console_output. This patch fixes this oversight. + + Tested-By: Ciaran Woodward + Approved-By: Andrew Burgess + +2024-05-10 Nick Clifton + + Add --section-ordering command line option to the bfd linker. + +2024-05-10 Alan Modra + + Re: PR31692, objdump fails .debug_info size check + The fuzzers found a hole. bfd_section_size_insane doesn't check + !SEC_HAS_CONTENTS sections against file size for obvious reasons, + which allows fuzzed debug sections to be stupidly large. Real debug + sections of course always have contents. + + PR 31692 + * objdump.c (load_specific_debug_section): Don't allow sections + without contents. + +2024-05-10 Andrew Burgess + + gdb: add gdbarch_stack_grows_down function + In another patch I'm working on I needed to ask: does the stack grow + down, or grow up? + + Looking around I found in infcall.c some code where we needed to ask + the same question, what we do there is ask: + + gdbarch_inner_than (gdbarch, 1, 2) + + which should do the job. However, I don't particularly like copying + this, it feels like we're asking something slightly different that + just happens to align with the question we're actually asking. + + I propose adding a new function `gdbarch_stack_grows_down`. This is + not going to be a gdbarch method that can be overridden, instead, this + will just call the gdbarch_inner_than function. We already have some + gdbarch methods like this, checkout arch-utils.c for examples. + + I think it's now clearer what we're actually doing. + + A new self-test ensures that all architectures have a stack that + either grows down, or grows up. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-10 Nick Clifton + + Add missing \n to the end of warning messages in dwarf.c. + PR 31722 + +2024-05-10 Pedro Alves + + gdb sim testing, set gdb_protocol to "sim" + Bernd reported that when testing with riscv-unknown-elf target using + the simulator, before commit c7a2ee649115 ("gdb_is_target_native -> + gdb_protocol_is_native"), he had: + + PASS: gdb.base/load-command.exp: probe for target native + PASS: gdb.base/load-command.exp: check initial value of the_variable + PASS: gdb.base/load-command.exp: manually change the_variable + PASS: gdb.base/load-command.exp: check manually changed value of the_variable + PASS: gdb.base/load-command.exp: reload: re-load binary + PASS: gdb.base/load-command.exp: reload: check initial value of the_variable + + and now: + + UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command + + The problem is that the sim board/config isn't setting gdb_protocol + anywhere, so gdb_protocol_is_native returns true. + + This commit fixes it by making gdb/testsuite/config/sim.exp set + gdb_protocol to "sim". + + Reported-by: Bernd Edlinger + Tested-by: Bernd Edlinger + Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a + +2024-05-10 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup) + In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register + more robust") I added this code in unwind_infopy_add_saved_register: + ... + if (value->optimized_out () || !value->entirely_available ()) + ... + which may throw c++ exceptions. + + This needs to be caught and transformed into a python exception. + + Fix this by using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") + +2024-05-10 GDB Administrator + + Automatic date update in version.in + +2024-05-09 Bernd Edlinger + + sim: riscv: Fix build issue due to recent binutils commit + The commit c144f6383379 removed INSN_CLASS_A and + added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead, + which broke the build of the sim for riscv targets. + + Fix that by using the new INSN_CLASS types. + + Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.") + + Approved-By: Tom Tromey + +2024-05-09 Eli Zaretskii + + Fix typo in gdb/README. + Patch from Tiezhu Yang . + +2024-05-09 Andrew Burgess + + gdb: convert address_in_mem_range to mem_range::contains + Replace the global function address_in_mem_range with the member + function mem_range::contains. The implementation of the function + doesn't change. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Andrew Burgess + + gdb: add a new build_id_equal function + Add two versions of a new function build_id_equal which can be used to + compare build-ids, then make use of these functions in GDB. It seems + better to have a specific function for the task of comparing build-ids + rather than having a length check followed by a memcmp call. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Vladimir Mezentsev + + Fix hard-coded bash path in gprofng + When running 'make check', the default gprofng test suite creates a + shell script for which it used a hardcoded shebang of '/usr/bin/bash' + this script would not run if bash is in a different location, like + /bin/bash + + This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the + installation path of bash is detected at configuration time. The + configuration is propagated to the runtest command line where it is + needed. + +2024-05-09 GDB Administrator + + Automatic date update in version.in + +2024-05-08 Andrew Burgess + + gdb/doc: use silent-rules.mk in the Makefile + Make use of silent-rules.mk when building the GDB docs. + + During review it was requested that there be more specific rules than + just reusing the general 'GEN' rule everywhere in the doc/ directory, + so I've added: + + ECHO_DVIPS = @echo " DVIPS $@"; + ECHO_TEX = @echo " TEX $@"; + ECHO_PDFTEX = @echo " PDFTEX $@"; + ECHO_TEXI2DVI = @echo " TEXI2DVI $@"; + ECHO_MAKEHTML = @echo " MAKEHTML $@"; + ECHO_TEXI2POD = @echo " TEXI2POD $@"; + ECHO_TEXI2MAN = @echo " TEXI2MAN $@"; + ECHO_MAKEINFO = @echo " MAKEINFO $@"; + + Then I've made use of these new silent rules and added lots of uses of + SILENT to reduce additional clutter. + + As the man page generation is done in two phases, first the creation + of a .pod file, then the creation of the final man page file, I've + restructured the man page rules. Previously we had one rule for each + of the 5 man pages. I now have one general rule that will generate + all of the 5 .pod files, then I have two rules that convert the .pod + files into the final man pages. + + I needed two rules for the man page generation as some man pages match + %.1 and some match %.5. I could combine these by using the GNU Make + .SECONDARYEXPANSION extension, but I think having two rules like this + is probably clearer, and the duplication is minimal. + + Cleaning up the temporary .pod files is now moved into the + 'mostlyclean' target rather than being done as soon as the man page is + created. + + I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like + SILENT_FLAG, but is set to '-q' when in silent mode, this can be used + with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to + mean: only report errors. + + As with the rest of the GDB makefiles, I've only converted the + "generation" rules to use silent-rules.mk, the install / uninstall + rules are left unchanged. + + When looking at the 'diststuff' target, which generates the info and + man pages, I noticed the recipe for this rule just deleted a temporary + file. As that temporary file is already cleaned up as part of the + 'clean' rule I've removed the deletion from the 'diststuff' target. + + There are still a few "generation" targets that produce output, there + seems to be no flag to silence the 'tex' and 'pdftex' commands which + some recipes use, I've not worried about these for now, e.g. the + refcard.dvi and refcard.pdf targets still produce some output. + + Luckily, when doing a 'make all' in the gdb/ directory, we only build + the info docs by default, and those rules are now nice and silent, so + a complete GDB build is now looking nice and quiet by default. + + While working on this patch I noticed that 'make -j all-doc' doesn't + work (reliably), this is a preexisting bug in the way that dvi/pdf + targets are generated. For example gdb.dvi and gdb.pdf both use the + texi2dvi tool, which relies on temporary files to hold state. If both + these rules run in parallel then one (or both) of the recipes will + fail. + + Luckily, the default docs target (all), which is what gets run when we + do 'make all' in the gdb/ directory, doesn't build the dvi and pdf + targets, so we're OK in that case. + + I've not tried to fix this problem in this commit as it already + existed, and I don't want to do too much in one commit. I mention it + only because I ran into this issue while testing this commit. + +2024-05-08 Guinevere Larsen + + gdb: Change "list ." command's error when no debuginfo is available + Currently, when a user tries to list the current location, there are 2 + different error messages that can happen, either: + + (gdb) list . + No symbol table is loaded. Use the "file" command. + or + (gdb) list . + No debug information available to print source lines. + + The difference here is if gdb can find any symtabs at all or not, which + is not something too important for end-users - and isn't informative at + all. This commit changes it so that the error always says that there + isn't debug information available, with these two variants: + + (gdb) list . + Insufficient debug info for showing source lines at current PC (0x55555555511d). + or + (gdb) list . + Insufficient debug info for showing source lines at default location. + + The difference now is if the inferior has started already, which is + controlled by the user and may be useful. + + Unfortunately, it isn't as easy to differentiate if the symtab found for + other list parameters is correct, so other invocations, such as "list +" + still retain their original error message. + + Co-Authored-By: Simon Marchi + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-05-08 Andrew Burgess + + gdb: more filename styling + I spotted a few places in solib.c and build-id.c where we could apply + file name styling. + + Other than the extra styling, there should be no user visible changes + after this commit. + + Approved-By: Tom Tromey + +2024-05-08 Tom de Vries + + [gdb/testsuite] Add gdb.tui/reread.exp + Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because + all_objfiles_removed triggers tui_display_main"). + + When building with address sanitizer, and reverting the commit it triggers the + heap-use-after-free. + + Tested on aarch64-linux. + + PR symtab/31697 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + +2024-05-08 Aditya Vidyadhar Kamath + + Fix AIX thread exit events not being reported and UI to show kernel thread ID. + In AIX when a thread exits we were not showing that a thread exit event happened + and GDB continued to keep the terminated threads. + + If we have terminated threads then the UI on info threads command will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o) + 2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.) + + If we see the frame is not getting displayed correctly. + + The reason for the same is that in AIX we were not managing thread states. In particular we do not know + when a thread terminates. + + The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit. + + This patch is a fix to the same. + + Also certain UI is changed. + + On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information. + + [New Thread 258 (tid 32178533)] + [New Thread 515 (tid 30343651)] + [New Thread 772 (tid 33554909)] + [New Thread 1029 (tid 24969489)] + [New Thread 1286 (tid 18153945)] + [New Thread 1543 (tid 30736739)] + [Thread 258 (tid 32178533) exited] + [Thread 515 (tid 30343651) exited] + [Thread 772 (tid 33554909) exited] + [Thread 1029 (tid 24969489) exited] + [Thread 1286 (tid 18153945) exited] + [Thread 1543 (tid 30736739) exited] + + and info threads will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + + Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well. + +2024-05-08 Tom Tromey + + Fix typo in binutils manual + I happened to notice that the binutils manual has a typo in the name + of a command-line option. + +2024-05-08 H.J. Lu + + ld: Add PR ld/31710 tests + PR ld/31710 + * testsuite/ld-elf/wrap.exp: Run ld/31710 tests. + * testsuite/ld-elf/wrap2.h: New file. + * testsuite/ld-elf/wrap2a.c: Likewise. + * testsuite/ld-elf/wrap2b.c: Likewise. + +2024-05-08 H.J. Lu + + ld: Run --wrap tests only if supported + Run --wrap tests with shared library only if -shared is supported. + + * testsuite/ld-elf/wrap.exp: Run --wrap tests with shared library + only if -shared is supported. + +2024-05-08 Nick Clifton + + Fix RELOC_FOR_GLOBAL_SYMBOLS macro so that it can cope with user defined symbols that start with __wrap_. + PR 31710 + +2024-05-08 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust + On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register + from non-FreeBSD target descriptions") I ran into: + ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \ + backtrace when the unwind is broken at frame 5 + ... + + What happens is the following: + - the TestUnwinder from inline-frame-cycle-unwind.py calls + gdb.UnwindInfo.add_saved_register with reg == tpidruro and value + "", + - pyuw_sniffer calls value->contents ().data () to access the value of the + register, which throws an UNAVAILABLE_ERROR, + - this causes the TestUnwinder unwinder to fail, after which another unwinder + succeeds and returns the correct frame, and + - the test-case fails because it's counting on the TestUnwinder to succeed and + return an incorrect frame. + + Fix this by checking for !value::entirely_available as well as + valued::optimized_out in unwind_infopy_add_saved_register. + + Tested on x86_64-linux and arm-linux. + + Approved-By: Andrew Burgess + + PR python/31437 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437 + +2024-05-08 Nelson Chu + + RISC-V: Support B, Zaamo and Zalrsc extensions. + * https://github.com/riscv/riscv-b/tags + Added standard B extension back, which implies Zba, Zbb and Zbs extensions. + + * https://github.com/riscv/riscv-zaamo-zalrsc/tags + Splited standard A extension into two new extensions, Zaamo and Zalrsc. + The A extension implies Zaamo and Zalrsc extensions. + + Not sure if we need to do the similar check as i and zicsr/zifencei. + + Passed riscv[32|64]-[elf/linux] binutils testcases. + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules + for A and B extensions. The A implies Zaamo and Zalrsc, the + B implies Zba, Zbb and Zbs. + (riscv_supported_std_ext): Supported B extension with v1.0. + (riscv_supported_std_z_ext): Supported Zaamo and Zalrsc with v1.0. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): Updated. + include/ + * opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_A, Added + INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC. + opcodes/ + * riscv-opc.c (riscv_opcodes): Splited standard A extension into two + new extensions, Zaamo and Zalrsc. + gas/ + * testsuite/gas/riscv/march-imply-a.d: New testcase. + * testsuite/gas/riscv/march-imply-b.d: New testcase. + * testsuite/gas/riscv/attribute-01.d: Updated. + * testsuite/gas/riscv/attribute-02.d: Updated. + * testsuite/gas/riscv/attribute-03.d: Updated. + * testsuite/gas/riscv/attribute-04.d: Updated. + * testsuite/gas/riscv/attribute-05.d: Updated. + * testsuite/gas/riscv/attribute-10.d: Updated. + * testsuite/gas/riscv/mapping-symbols.d: Updated. + * testsuite/gas/riscv/march-imply-g.d: Updated. + * testsuite/gas/riscv/march-imply-unsupported.d: Updated. + * testsuite/gas/riscv/march-ok-reorder.d: Updated. + ld/ + * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Updated. + +2024-05-08 GDB Administrator + + Automatic date update in version.in + +2024-05-07 Hannes Domani + + Fix heap-use-after-free because all_objfiles_removed triggers tui_display_main + Since gdb-10 there is a heap-use-after free happening if starting the + target in TUI triggers a re-reading of symbols. + + It can be reproduced with: + + $ gdb -q -batch a.out -ex "tui enable" -ex "shell touch a.out" -ex start + + ==28392== Invalid read of size 1 + ==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503) + ==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641) + ==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473) + ==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150) + ==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958) + ==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970) + ==28392== by 0x77120F: select_source_symtab() (source.c:319) + ==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401) + ==28392== by 0x807558: tui_display_main() (tui-winsource.c:55) + ==28392== by 0x7937B5: clear_symtab_users(enum_flags) (functional:2464) + ==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd + ==28392== at 0x4A0A430: free (vg_replace_malloc.c:446) + ==28392== by 0x936B63: _obstack_free (obstack.c:280) + ==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735) + ==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575) + ==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552) + ==28392== by 0x5D3A50: command_line_handler(std::unique_ptr >&&) (event-top.c:788) + ==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259) + ==28392== by 0x857B3F: rl_callback_read_char (callback.c:290) + ==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195) + ==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234) + + The problem is that tui_display_main is called by the all_objfiles_removed + hook, which tries to access the symbol cache. + This symbol cache is actually stale at this point, and would have been + flushed immediately afterwards by that same all_objfiles_removed hook. + + It's not possible to tell the hook to call the observers in a specific + order, but in this case the tui_all_objfiles_removed observer is actually + not needed, since it only calls tui_display_main, and a 'main' can only + be found if objfiles are added, not removed. + + So the fix is to simply remove the tui_all_objfiles_removed observer. + + The clearing of the source window (if symbols were removed by e.g. 'file' + without arguments) still works, since this is done by the + tui_before_prompt observer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + Approved-By: Tom Tromey + +2024-05-07 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While rebasing this series[1] past this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + I worried that there could be other paths that might result in an xcr0 + value which has X86_XSTATE_MPX set in x32 mode. As everyone + eventually calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this will uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this, but the author of commit 4bb20a6244b7091 did test this + series with that assert in place and didn't see any problems. + + [1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + + Approved-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver/ipa/x86: remove unneeded declarations + Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no + longer needed. These are: + + 1. 'init_registers_amd64_linux' - the comment claims this function + is auto generated, but I don't believe that this is still the case. + Also the function is not used in this file, + + 2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any + more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but + neither are used in this file, so lets remove the declaration. + + The amd64 in-process-agent still builds fine after this commit. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-05-07 Pedro Alves + + gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch + The code in gdb.base/watchpoint-running.exp that is trying to skip + testing with hardware watchpoints also skips testing with software + watchpoints if hardware watchpoints aren't supported by the target. + This fixes it. + + Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba + +2024-05-07 Pedro Alves + + Remove gdb.base/watchpoint-running.exp leftover + Remove accidentally leftover commented-out line from + gdb.base/watchpoint-running.exp. + + Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697 + +2024-05-07 Lancelot SIX + + gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lock + A recent commit refactored with_rocm_gpu_lock: + + commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e + Date: Sat May 4 10:41:09 2024 +0200 + + [gdb/testsuite] Factor out proc with_lock + + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + This causes regressions in gdb.rocm/*.exp (as well as in downstream + rocgdb). The issue can be reproduced in the following minimal test: + + load_lib rocm.exp + set foo hello + with_rocm_gpu_lock { + verbose -logs $foo + } + + The issue is that the body to execute under the lock is executed in the + context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of + in the context of the "original" caller. + + This patch adjusted with_rocm_gpu_lock to account for the new extra + frame in the call stack between the caller of with_rocm_gpu_lock and + where the code execution is triggered. + + Approved-By: Tom de Vries + + Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe + +2024-05-07 Lulu Cai + + LoongArch: Fix ld test failures caused by using instruction aliases + Different versions of objdump may take different forms of output + for instructions. Use -M no-aliases to avoid the failure of ld + test cases caused by objdump using aliases. + +2024-05-07 GDB Administrator + + Automatic date update in version.in + +2024-05-06 Bernd Edlinger + + Fix build issues with mingw toolchain + With a x86_64-pc-mingw32 toolchain there is a build issue + whether or not the --disable-threading option is used. + The problem happens because _WIN32_WINNT is defined to 0x501 + before #include which makes the compilation abort + due to missing support for __gthread_cond_t in std_mutex.h, + which is conditional on _WIN32_WINNT >= 0x600. + + Fix the case when --disable-threading is used, by only + including in gdb/complaints.c when STD_CXX_THREAD + is defined. + + Additionally make the configure script try to #include + to automatically select --disable-threading when the header file + is not able to compile. + + Approved-By: Tom Tromey + +2024-05-06 Tom de Vries + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + When running the testsuite on a system with kernel.yama.ptrace_scope set to 1, + we run into attach failures. + + Fix this by recognizing "ptrace: Operation not permitted" in + can_spawn_for_attach. + + Tested on aarch64-linux and x86_64-linux. + + Approved-By: Pedro Alves + +2024-05-06 Tom de Vries + + [gdb/exp] Redo cast handling for indirection + In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I + introduced the behaviour that even though we have: + ... + (gdb) p *a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + we get: + ... + (gdb) p (char)*a_loc () + $1 = 97 'a' + ... + + In other words, the unknown return type of a_loc is inferred from the cast, + effectually evaluating: + ... + (gdb) p (char)*(char *)a_loc () + ... + + This is convient for the case that errno is defined as: + ... + #define errno (*__errno_location ()) + ... + and the return type of __errno_location is unknown but the macro definition is + known, such that we can use: + ... + (gdb) p (int)errno + ... + instead of + ... + (gdb) p *(int *)__errno_location () + ... + + However, as Pedro has pointed out in post-commit review [1], this makes it + harder to reason about the semantics of an expression. + + For instance, this: + ... + (gdb) p (long long)*a_loc ()" + ... + would be evaluated without debug info as: + ... + (gdb) p (long long)*(long long *)a_loc ()" + ... + but with debug info as: + ... + (gdb) p (long long)*(char *)a_loc ()" + ... + + Fix this by instead simply erroring out for this case: + ... + (gdb) p (char)*a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + + Tested on x86_64-linux. + + Approved-By: Pedro Alves + + [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html + +2024-05-06 Cui, Lili + + x86: Drop using extension_opcode to encode vvvv register + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + extension_opcode to encode the vvvv register. + * testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases. + * testsuite/gas/i386/x86-64-sse2avx.s: Diito. + + opcodes/ChangeLog: + + * i386-opc.tbl: Added DstVVVV to some extension_opcode instructions. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Drop SwapSources + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + SWAP_SOURCES to encode the vvvv register. + + opcodes/ChangeLog: + + * i386-opc.h (SWAP_SOURCES): Dropped. + (NO_DEFAULT_MASK): Adjusted the value. + (ADDR_PREFIX_OP_REG): Ditto. + (DISTINCT_DEST): Ditto. + (IMPLICIT_STACK_OP): Ditto. + (VexVVVV_SRC2): New. + * i386-opc.tbl: Dropped SwapSources and replaced its VexVVVV + with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Use vexvvvv as the switch state to encode the vvvv register + Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV. + Src1VVVV means using VEX.vvvv encodes the first source register + operand. The old logic did not check vexvvvv first, which made the + logic here very complicated. + + gas/ChangeLog: + + * config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV. + (build_modrm_byte): Used vexvvvv to encode the vvvv register. + (s_insn): Replaced 1 with Src1VVVV. + + opcodes/ChangeLog: + + * i386-opc.h (VexVVVV_DST): Adjusted the value. + (Src1VVVV): New. + * i386-opc.tbl: Replaced part VexVVVV with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 GDB Administrator + + Automatic date update in version.in + +2024-05-05 GDB Administrator + + Automatic date update in version.in + +2024-05-04 Hannes Domani + + Fix heap-use-after-free in index-cached with --disable-threading + If threads are disabled, either by --disable-threading explicitely, or by + missing std::thread support, you get the following ASAN error when + loading symbols: + + ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 + READ of size 1 at 0x614000002128 thread T0 + #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 + #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 + #2 0x1705e39 in std::function::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 + #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 + + 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) + freed by thread T0 here: + #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 + #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 + #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 + #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 + + It's happening because cooked_index_worker::wait always returns true in + this case, which tells cooked_index::wait it can delete the m_state + cooked_index_worker member, but cooked_index_worker::write_to_cache tries + to access it immediately afterwards. + + Fixed by making cooked_index_worker::wait only return true if desired_state + is CACHE_DONE, same as if threading was enabled, so m_state will not be + prematurely deleted. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 + Approved-By: Tom Tromey + +2024-05-04 Tom Tromey + + Remove dwarf2_per_objfile::adjust + All the calls to dwarf2_per_objfile::adjust have been removed, so we + can remove this function entirely. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261 + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_attribute_value + Currently, read_attribute_value calls dwarf2_per_objfile::adjust on + any address. This seems wrong, because the address may not even be in + the text section. + + Luckily, this call is also not needed, because read_func_scope calls + 'relocate', which does the same work. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_call_site_scope + read_call_site_scope does not need to call 'adjust', because in + general the call site is not a symbol address, but rather just the + address of some particular call. + +2024-05-04 Tom Tromey + + Remove more calls to dwarf2_per_objfile::adjust + As with the previous patch, this patch removes some calls to + dwarf2_per_objfile::adjust. These calls are not needed by the cooked + indexer, as it does not create symbols or look up symbols by address. + + The call in dwarf2_ranges_read is similarly not needed, as it is only + used to update an addrmap; and in any case I believe this particular + call is only reached by the indexer. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from ranges readers + dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an + address, leaving the result unrelocated. However, this adjustment is + only needed for text-section symbols -- it isn't needed for any sort + of address mapping. Therefore, these calls can be removed from + read_addrmap_from_aranges and create_addrmap_from_gdb_index. + + Approved-By: Andrew Burgess + +2024-05-04 Alan Modra + + bus error with fuzzed archive element + * libbfd.c (bfd_mmap_local): Sanity check rsize against actual + file offset and size, not an archive element offset and size. + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing (check//% case) + Make target check//% is the gdb variant of a similar gcc make target [1]. + + When running tests using check//%: + ... + $ cd build/gdb + $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp + ... + we get: + ... + $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum + 2427 + $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum + 2423 + ... + + The problem is that there are two portnum files used in parallel. + + Fix this by: + - creating a common lockdir build/gdb/testsuite.lockdir for make target + check//%, + - passing this down to the runtests invocations using variable GDB_LOCK_DIR, + and + - using GDB_LOCK_DIR in lock_dir. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31632 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 + + [1] https://gcc.gnu.org/install/test.html + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check-parallel -j2 TESTS=gdb.server/*.exp + ... + we run into: + ... + Running gdb.server/abspath.exp ... + PORTNUM: 2345 + ... + and: + ... + Running gdb.server/bkpt-other-inferior.exp ... + PORTNUM: 2345 + ... + + This is because the test-cases are run in independent runtest invocations. + + Fix this by handling the parallel case in get_portnum using: + - a file $objdir/cache/portnum to keep the portnum variable, and + - a file $objdir/cache/portnum.lock to serialize access to it. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Move gpu-parallel.lock to cache dir + The lock directory returned by lock_dir is currently $objdir. + + It seems possible to leave a stale lock file that blocks progress in a + following run. + + Fix this by using a directory that is guaranteed to be initially empty when + using GDB_PARALLEL, like temp or cache. + + In gdb/testsuite/README I found: + ... + cache in particular is used to share data across invocations of runtest + ... + which seems appropriate, so let's use cache for this. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc lock_dir + In lib/rocm.exp we have: + ... + set gpu_lock_filename $objdir/gpu-parallel.lock + ... + + This decides both the lock file name and directory. + + Factor out a new proc lock_dir that decides on the directory, leaving just: + ... + set gpu_lock_filename gpu-parallel.lock + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc with_lock + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Make portnum a persistent global + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check TESTS=gdb.server/*.exp + ... + we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2345 + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + ... + + So, while get_portnum does return increasing numbers in a single test-case, it + restarts at each test-case. + + This is a regression since the introduction of persistent globals. + + Fix this by using "gdb_persistent_global portnum", such that we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + PORTNUM: 2351 + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc get_portnum + In gdbserver_start, we have some code that determines what port number to use: + ... + # Port id -- either specified in baseboard file, or managed here. + if [target_info exists gdb,socketport] { + set portnum [target_info gdb,socketport] + } else { + # Bump the port number to avoid conflicts with hung ports. + incr portnum + } + ... + + Factor this out into a new proc get_portnum. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 GDB Administrator + + Automatic date update in version.in + +2024-05-03 Pedro Alves + + Adjust gdb_continue_to_end for Windows + On Cygwin, supposely single-threaded programs are always + multi-threaded, due to the extra threads spawned by the Cygwin + runtime. Because of that, any gdb_continue_to_end call that doesn't + specify "allow_extra" fails, like so: + + (gdb) PASS: gdb.base/langs.exp: show language at main + continue + Continuing. + [Thread 16140.0x1fbc exited with code 0] + [Thread 16140.0x2458 exited with code 0] + [Thread 16140.0x3494 exited with code 0] + [Inferior 1 (process 16140) exited normally] + (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited) + + Similarly, with this simple program compiled with MinGW: + + $ cat ~/sleeper.c + #include + + int main () + { + Sleep (2000); + return 0; + } + + and with a MinGW GDB, I see: + + (gdb) start + ... + (gdb) info threads + Id Target Id Frame + * 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5 + 2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll + (gdb) c + Continuing. + [Thread 15292.0x3850 exited with code 0] + [Inferior 1 (process 15292) exited normally] + (gdb) + + This commit adjusts gdb_continue_to_end to expect the thread exited + messages, on Cygwin and MinGW. + + Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 + Approved-By: Andrew Burgess + +2024-05-03 Mark Wielaard + + [gdb/build] Fix gdbserver/linux-aarch64-low.cc build + Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + removed the last use of i in gdbserver/linux-aarch64-low.cc + (aarch64_target::low_stopped_data_address). Breaking the build on + aarch64 with: + + gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?: + gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable] + 557 | int pid, i; + | ^ + cc1plus: all warnings being treated as errors + + Fix this by removing the variable i completely. + + Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + +2024-05-03 Tom de Vries + + [gdb/testsuite] Use save_vars to restore GDBFLAGS + There's a pattern of using: + ... + set saved_gdbflags $GDBFLAGS + set GDBFLAGS "$GDBFLAGS ..." + + set GDBFLAGS $saved_gdbflags + ... + + Simplify this by using save_vars: + ... + save_vars { GDBFLAGS } { + set GDBFLAGS "$GDBFLAGS ..." + + } + ... + + Tested on x86_64-linux. + +2024-05-03 Tom de Vries + + [gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0 + INTERNAL_GDBFLAGS contains: + - -quiet + - -iex "set width 0" + - -iex "set height 0" + + There are test-cases that add these once more. + + Clean this up. + + Tested on x86_64-linux. + + PR testsuite/31649 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649 + +2024-05-03 Tom de Vries + + [gdb/testsuite] Update INTERNAL_GDBFLAGS example + In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added + -q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS + example in gdb/testsuite/README. + + Fix this by adding the -q there as well. + +2024-05-03 Tom de Vries + + [gdb/exp] Fix cast handling for indirection + Consider a test-case compiled without debug info, containing: + ... + char a = 'a'; + + char * + a_loc (void) + { + return &a; + } + ... + + We get: + ... + (gdb) p (char)*a_loc () + Cannot access memory at address 0x10 + ... + + There's a bug in unop_ind_base_operation::evaluate that evaluates + "(char)*a_loc ()" the same as: + ... + (gdb) p (char)*(char)a_loc () + Cannot access memory at address 0x10 + ... + + Fix this by instead evaluating it the same as: + ... + (gdb) p (char)*(char *)a_loc () + $1 = 97 'a' + ... + + Tested on x86_64-linux. + + PR exp/31693 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693 + +2024-05-03 Jan Beulich + + x86: tidy templates + Some of them no longer need a separate vvvv attribute, thus allowing + them to be simplified. For the situation is slightly different: + None of the remaining uses make use of vvvv anymore. + + x86/APX: further extend SSE2AVX coverage + Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is + in use, {evex} should be respected, too. So far this is the case only + for insns where eGPR-s can come into play. Extend coverage to insns with + only %xmm register and possibly immediate operands. + +2024-05-03 Jan Beulich + + x86/APX: extend SSE2AVX coverage + Legacy encoded SIMD insns are converted to AVX ones in that mode. When + eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where + available; there are quite a few which can't be converted). + + Note that LDDQU is represented as VMOVDQU32 (and the prior use of the + sse3 template there needs dropping, to get the order right). + + Note further that in a few cases, due to the use of templates, AVX512VL + is used when AVX512F would suffice. Since AVX10 is the main reference, + this shouldn't be too much of a problem. + +2024-05-03 Jan Beulich + + x86: zap value-less Disp8MemShift from non-EVEX templates + In order to allow to continue to use templatized SSE2AVX templates when + enhancing those to also cover eGPR usage, Disp8MemShift wants using to + deviate from what general template attributes supply. That requires + using Disp8MemShift in a way also affecting non-EVEX templates, yet + having this attribute set would so far implicitly mean EVEX encoding. + Recognize the case and instead zap the attribute if no other attribute + indicates EVEX encoding. + + No change in generated tables. + +2024-05-03 GDB Administrator + + Automatic date update in version.in + +2024-05-02 Tom Tromey + + Fix regression on aarch64-linux gdbserver + Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64") + fixed a watchpoint bug in gdb -- but did not touch the corresponding + code in gdbserver. + + This patch moves the gdb code into gdb/nat, so that it can be shared + with gdbserver, and then changes gdbserver to use it, fixing the bug. + + This is yet another case where having a single back end would prevent + bugs. + + I tested this using the AdaCore internal gdb testsuite. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + Approved-By: Luis Machado + +2024-05-02 Alan Modra + + PR31692, objdump fails .debug_info size check + PR 31692 + * objdump.c (load_specific_debug_section): Replace bfd_get_size + check with bfd_section_size_insane. Call free_debug_section + after printing error messages. Set section->start NULL when + freeing. + +2024-05-02 Tom de Vries + + [gdb/symtab] Work around PR gas/29517, dwarf2 case + In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a + workaround for PR gas/29517. + + The problem is present in gas version 2.39, and fixed in 2.40, so the + workaround is only active for gas version == 2.39. + + However, the problem in gas is only fixed for dwarf version >= 3, which + supports DW_TAG_unspecified_type. + + Fix this by also activating the workaround for dwarf version == 2. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR symtab/31689 + https://sourceware.org/bugzilla/show_bug.cgi?id=31689 + +2024-05-02 GDB Administrator + + Automatic date update in version.in + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in get_compiler_info + When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board + local-remote-host and target board remote-gdbserver-on-localhost, I get: + ... + $ ls build/gdb/testsuite + cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile + outputs site.bak site.exp temp + ... + + The file compiler.i is there because get_compiler_info uses: + ... + set ppout "$outdir/compiler.i" + ... + + The file is a temporary, and as such belongs in a temp dir. Fix this by using + standard_temp_file, moving the file to build/gdb/testsuite/temp//compiler.i. + + Tested on x86_64-linux. + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.exp + After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have: + ... + $ ls build/gdb/testsuite + cache config.status gdb.log lib outputs site.exp + config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp + ... + + The file gdb-index-nodebug.gdb-index doesn't belong there. + + It happens to be there because we do: + ... + set index_file ${testfile}.gdb-index + set cmd "save gdb-index [file dirname ${index_file}]" + ... + which results in: + ... + (gdb) save gdb-index . + ... + + The intention was possibly to use $binfile instead of $testfile, but using + that wouldn't work for remote host. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-05-01 GDB Administrator + + Automatic date update in version.in + +2024-04-30 Nelson Chu + + RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown. + bfd/ + PR 29823 + * elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function. + (elf_backend_obj_attrs_handle_unknown): Defined to + riscv_elf_obj_attrs_handle_unknown. + +2024-04-30 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.base/memops-watchpoint.exp + Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove. + These functions are frequently optimized with specialized instructions + that favor larger memory access operations, so make sure GDB behaves + correctly in their presence. + + There's a separate watched variable for each function so that the testcase + can test whether GDB correctly identified the watchpoint that triggered. + + Also, the watchpoint is 28 bytes away from the beginning of the buffer + being modified, so that large memory accesses (if present) are exercised. + + PR testsuite/31484 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484 + + Approved-by: Kevin Buettner + +2024-04-30 Thiago Jung Bauermann + + gdb/nat/linux: Fix attaching to process when it has zombie threads + When GDB attaches to a multi-threaded process, it calls + linux_proc_attach_tgid_threads () to go through all threads found in + /proc/PID/task/ and call attach_proc_task_lwp_callback () on each of + them. If it does that twice without the callback reporting that a new + thread was found, then it considers that all inferior threads have been + found and returns. + + The problem is that the callback considers any thread that it hasn't + attached to yet as new. This causes problems if the process has one or + more zombie threads, because GDB can't attach to it and the loop will + always "find" a new thread (the zombie one), and get stuck in an + infinite loop. + + This is easy to trigger (at least on aarch64-linux and powerpc64le-linux) + with the gdb.threads/attach-many-short-lived-threads.exp testcase, because + its test program constantly creates and finishes joinable threads so the + chance of having zombie threads is high. + + This problem causes the following failures: + + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted on (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the inferior (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted off (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout) + ERROR: breakpoints not deleted + + The iteration number is random, and all tests in the subsequent iterations + fail too, because GDB is stuck in the attach command at the beginning of + the iteration. + + The solution is to make linux_proc_attach_tgid_threads () remember when it + has already processed a given LWP and skip it in the subsequent iterations. + + PR testsuite/31312 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312 + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Factor linux_proc_get_stat_field out of linux_common_core_of_thread + The new function will be used in a subsequent patch to read a different + stat field. + + The new code is believed to be equivalent to the old code, so there + should be no change in GDB behaviour. The only material change was to + use std::string and string_printf rather than a fixed char array to + build the path to the stat file. + + Also, take the opportunity to move the function's documentation comment to + the header file, to conform with GDB practice. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread + The code and comment reference stat fields by made-up indexes. The + procfs(5) man page, which describes the /proc/PID/stat file, has a numbered + list of these fields so it's more convenient to use those numbers instead. + + This is currently an implementation detail inside the function so it's + not really relevant with the code as-is, but a future patch will do some + refactoring which will make the index more prominent. + + Therefore, make this change in a separate patch so that it's simpler to + review. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 GDB Administrator + + Automatic date update in version.in + +2024-04-29 Pedro Alves + + gdb/Cygwin: Fix attach pid error message + On Cygwin, with "attach PID": + + - GDB first tries to interpret PID as a Windows native PID, and tries + to attach to that. + + - if the attach fails, GDB then tries to interpret the PID as a + Cygwin PID, and attach to that. + + If converting the user-provided PID from a Cygwin PID to a Windows PID + fails, you get this: + + (gdb) attach 12345 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + + Note "process 0". + + With the fix in this commit, we'll now get: + + (gdb) attach 12345 + Can't attach to process 12345 (error 2: The system cannot find the file specified.) + + I noticed this while looking at gdb.log after running + gdb.base/attach.exp on Cygwin. + + Change-Id: I05b9dc1f3a634a822ea49bb5c61719f5e62c8514 + Approved-By: Luis Machado + +2024-04-29 Andrew Burgess + + gdb/doc: document how filename arguments are formatted + In the following commits I intend to improve GDB's filename + completion. However, how filenames should be completed is a little + complex because GDB is not consistent with how it expects filename + arguments to be formatted. + + This commit documents the current state of GDB when it comes to + formatting filename arguments. + + Currently GDB will not correctly complete filenames inline with this + documentation; GDB will either fail to complete, or complete + incorrectly (i.e. the result of completion will not then be accepted + by GDB). However, later commits in this series will fix completion. + + Approved-By: Eli Zaretskii + +2024-04-29 Nick Clifton + + Fix initiali state of DWARF v5 line number table in BFD library + PR 30783 + +2024-04-29 Andrew Burgess + + gdb/remote: fix qRcmd error handling + This commit: + + commit 3623271997a5c0d79609aa6a1f35ef61b4469054 + Date: Tue Jan 30 15:55:47 2024 +0100 + + remote.c: Use packet_check_result + + Introduced a bug in the error handling of the qRcmd packet. Prior to + this commit if a packet had status PACKET_OK then, if the packet + contained the text "OK" we considered the packet handled. But, if the + packet contained any other content (that was not an error message) + then the content was printed to the user. + + After the above commit this was no longer the case, any non-error + packet that didn't contain "OK" would be treated as an error. + + Currently, gdbserver doesn't exercise this path so it's not possible + to write a simple test for this case. When gdbserver wishes to print + output it sends back an 'O' string output packet, these packets are + handled earlier in the process. Then once gdbserver has finished + sending output an 'OK' packet is sent. + + Approved-By: Tom Tromey + +2024-04-29 Nick Clifton + + Fix building Loongarch BFD with a 32-bit compiler + +2024-04-29 GDB Administrator + + Automatic date update in version.in + +2024-04-28 GDB Administrator + + Automatic date update in version.in + +2024-04-27 Tom Tromey + + Fix typo in TUI comment + tui_win_info::make_visible has a mildly misleading comment -- it says + "visible" where "invisible" is meant. This patch fixes it. + + Remove two unneeded forward declarations + I noticed a couple of forward declarations in the TUI that aren't + needed -- the declarations aren't used in the header files in which + they appear. This patch removes these. + +2024-04-27 Tom de Vries + + [gdb/remote] Fix abort on REMOTE_CLOSE_ERROR + When running test-case gdb.server/connect-with-no-symbol-file.exp on + aarch64-linux (specifically, an opensuse leap 15.5 container on a + fedora asahi 39 system), I run into: + ... + (gdb) detach^M + Detaching from program: target:connect-with-no-symbol-file, process 185104^M + Ending remote debugging.^M + terminate called after throwing an instance of 'gdb_exception_error'^M + ... + + The detailed backtrace of the corefile is: + ... + (gdb) bt + #0 0x0000ffff75504f54 in raise () from /lib64/libpthread.so.0 + #1 0x00000000007a86b4 in handle_fatal_signal (sig=6) + at gdb/event-top.c:926 + #2 + #3 0x0000ffff74b977b4 in raise () from /lib64/libc.so.6 + #4 0x0000ffff74b98c18 in abort () from /lib64/libc.so.6 + #5 0x0000ffff74ea26f4 in __gnu_cxx::__verbose_terminate_handler() () + from /usr/lib64/libstdc++.so.6 + #6 0x0000ffff74ea011c in ?? () from /usr/lib64/libstdc++.so.6 + #7 0x0000ffff74ea0180 in std::terminate() () from /usr/lib64/libstdc++.so.6 + #8 0x0000ffff74ea0464 in __cxa_throw () from /usr/lib64/libstdc++.so.6 + #9 0x0000000001548870 in throw_it (reason=RETURN_ERROR, + error=TARGET_CLOSE_ERROR, fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:203 + #10 0x0000000001548920 in throw_verror (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:211 + #11 0x0000000001548a00 in throw_error (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed") + at gdbsupport/common-exceptions.cc:226 + #12 0x0000000000ac8f2c in remote_target::readchar (this=0x233d3d90, timeout=2) + at gdb/remote.c:9856 + #13 0x0000000000ac9f04 in remote_target::getpkt (this=0x233d3d90, + buf=0x233d40a8, forever=false, is_notif=0x0) at gdb/remote.c:10326 + #14 0x0000000000acf3d0 in remote_target::remote_hostio_send_command + (this=0x233d3d90, command_bytes=13, which_packet=17, + remote_errno=0xfffff1a3cf38, attachment=0xfffff1a3ce88, + attachment_len=0xfffff1a3ce90) at gdb/remote.c:12567 + #15 0x0000000000ad03bc in remote_target::fileio_fstat (this=0x233d3d90, fd=3, + st=0xfffff1a3d020, remote_errno=0xfffff1a3cf38) + at gdb/remote.c:12979 + #16 0x0000000000c39878 in target_fileio_fstat (fd=0, sb=0xfffff1a3d020, + target_errno=0xfffff1a3cf38) at gdb/target.c:3315 + #17 0x00000000007eee5c in target_fileio_stream::stat (this=0x233d4400, + abfd=0x2323fc40, sb=0xfffff1a3d020) at gdb/gdb_bfd.c:467 + #18 0x00000000007f012c in ::operator()(bfd *, + void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400, + sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955 + #19 0x00000000007f015c in ::_FUN(bfd *, void *, + stat *) () at gdb/gdb_bfd.c:956 + #20 0x0000000000f9b838 in opncls_bstat (abfd=0x2323fc40, sb=0xfffff1a3d020) + at bfd/opncls.c:665 + #21 0x0000000000f90adc in bfd_stat (abfd=0x2323fc40, statbuf=0xfffff1a3d020) + at bfd/bfdio.c:431 + #22 0x000000000065fe20 in reopen_exec_file () at gdb/corefile.c:52 + #23 0x0000000000c3a3e8 in generic_mourn_inferior () + at gdb/target.c:3642 + #24 0x0000000000abf3f0 in remote_unpush_target (target=0x233d3d90) + at gdb/remote.c:6067 + #25 0x0000000000aca8b0 in remote_target::mourn_inferior (this=0x233d3d90) + at gdb/remote.c:10587 + #26 0x0000000000c387cc in target_mourn_inferior ( + ptid=) + at gdb/target.c:2738 + #27 0x0000000000abfff0 in remote_target::remote_detach_1 (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6421 + #28 0x0000000000ac0094 in remote_target::detach (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6436 + #29 0x0000000000c37c3c in target_detach (inf=0x22fce540, from_tty=1) + at gdb/target.c:2526 + #30 0x0000000000860424 in detach_command (args=0x0, from_tty=1) + at gdb/infcmd.c:2817 + #31 0x000000000060b594 in do_simple_func (args=0x0, from_tty=1, c=0x231431a0) + at gdb/cli/cli-decode.c:94 + #32 0x00000000006108c8 in cmd_func (cmd=0x231431a0, args=0x0, from_tty=1) + at gdb/cli/cli-decode.c:2741 + #33 0x0000000000c65a94 in execute_command (p=0x232e52f6 "", from_tty=1) + at gdb/top.c:570 + #34 0x00000000007a7d2c in command_handler (command=0x232e52f0 "") + at gdb/event-top.c:566 + #35 0x00000000007a8290 in command_line_handler (rl=...) + at gdb/event-top.c:802 + #36 0x0000000000c9092c in tui_command_line_handler (rl=...) + at gdb/tui/tui-interp.c:103 + #37 0x00000000007a750c in gdb_rl_callback_handler (rl=0x23385330 "detach") + at gdb/event-top.c:258 + #38 0x0000000000d910f4 in rl_callback_read_char () + at readline/readline/callback.c:290 + #39 0x00000000007a7338 in gdb_rl_callback_read_char_wrapper_noexcept () + at gdb/event-top.c:194 + #40 0x00000000007a73f0 in gdb_rl_callback_read_char_wrapper + (client_data=0x22fbf640) at gdb/event-top.c:233 + #41 0x0000000000cbee1c in stdin_event_handler (error=0, client_data=0x22fbf640) + at gdb/ui.c:154 + #42 0x000000000154ed60 in handle_file_event (file_ptr=0x232be730, ready_mask=1) + at gdbsupport/event-loop.cc:572 + #43 0x000000000154f21c in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:693 + #44 0x000000000154dec4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:263 + #45 0x0000000000910f98 in start_event_loop () at gdb/main.c:400 + #46 0x0000000000911130 in captured_command_loop () at gdb/main.c:464 + #47 0x0000000000912b5c in captured_main (data=0xfffff1a3db58) + at gdb/main.c:1338 + #48 0x0000000000912bf4 in gdb_main (args=0xfffff1a3db58) + at gdb/main.c:1357 + #49 0x00000000004170f4 in main (argc=10, argv=0xfffff1a3dcc8) + at gdb/gdb.c:38 + (gdb) + ... + + The abort happens because a c++ exception escapes to c code, specifically + opncls_bstat in bfd/opncls.c. Compiling with -fexceptions works around this. + + Fix this by catching the exception just before it escapes, in stat_trampoline + and likewise in few similar spot. + + Add a new template catch_exceptions to do so in a consistent way. + + Tested on aarch64-linux. + + Approved-by: Pedro Alves + + PR remote/31577 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577 + +2024-04-27 GDB Administrator + + Automatic date update in version.in + +2024-04-26 Pedro Alves + + Improve target.h & target_ops & xfer_partial descriptions + Working backwards in terms of motivation for the patch: + + - When accessing memory via the xfer_partial interface, the process + that we're accessing is indicated by inferior_ptid. This can be + either the same process as current inferior, or a fork child which + does not exist in the inferior list. This is not documented + currently. This commit fixes that. + + - For target delegation to work, we must always make the inferior we + want to call the target method on, the current inferior. This + wasn't documented, AFAICT, so this commit fixes that too. I put + that in the intro comment to target_ops. + + - I actually started writing a larger intro comment to target_ops, as + there was seemingly none, which I did find odd. However, I then + noticed the description closer to the top of the file. I missed it + the first time, because for some reason, that intro comment is no + longer at the top of the file, as #includes etc. have been added + above it over the years. This commit fixes that too, by moving that + intro comment to the top. + + Change-Id: Id21f5462947f2a0f6f3ac0c42532df62ba355914 + Approved-By: Simon Marchi + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579) + Old RHEL systems have a kernel that does not support writing memory + via /proc/pid/mem. On such systems, we fallback to accessing memory + via ptrace. That has a few downsides described in the "Accessing + inferior memory" section at the top of linux-nat.c. + + The target_xfer interface for memory access uses inferior_ptid as + sideband argument to indicate which process to access. Memory access + is process-wide, it is not thread-specific, so inferior_ptid is + sometimes pointed at a process-wide ptid_t for the memory access + (i.e., a ptid that looks like {pid, 0, 0}). That is the case for any + code that uses scoped_restore_current_inferior_for_memory, for + example. + + That is what causes the issue described in PR 31579, where thread_db + calls into the debugger to read memory, which reaches our + ps_xfer_memory function, which does: + + static ps_err_e + ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr, + gdb_byte *buf, size_t len, int write) + { + scoped_restore_current_inferior_for_memory save_inferior (ph->thread->inf); + + ... + ret = target_read_memory (core_addr, buf, len); + ... + } + + If linux_nat_target::xfer_partial falls back to inf_ptrace_target with + a pid-ptid, then the ptrace code will do the ptrace call targeting + pid, the leader LWP. That may fail with ESRCH if the leader is + currently running, or zombie. That is the case in the scenario in + question, because thread_db is consulted for an event of a non-leader + thread, before we've stopped the whole process. + + Fix this by having the ptrace fallback code try to find a stopped LWP + to use with ptrace. + + I chose to handle this in the linux-nat target instead of in common + code because (global) memory is a process-wide property, and this + avoids having to teach all the code paths that use + scoped_restore_current_inferior_for_memory to find some stopped thread + to access memory through, which is a ptrace quirk. That is + effectively what we used to do before we started relying on writable + /proc/pid/mem. I'd rather not go back there. + + To trigger this on modern kernels you have to hack linux-nat.c to + force the ptrace fallback code, like so: + + --- a/gdb/linux-nat.c + +++ b/gdb/linux-nat.c + @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object, + poke would incorrectly write memory to the post-exec address + space, while the core was trying to write to the pre-exec + address space. */ + - if (proc_mem_file_is_writable ()) + + if (0 && proc_mem_file_is_writable ()) + + With that hack, I was able to confirm that the fix fixes hundreds of + testsuite failures. Compared to a test run with pristine master, the + hack above + this commit's fix shows that some non-stop-related tests + fail, but that is expected, because those are tests that need to + access memory while the program is running. (I made no effort to + temporarily pause an lwp if no ptrace-stopped lwp is found.) + + Change-Id: I24a4f558e248aff7bc7c514a88c698f379f23180 + Tested-By: Hannes Domani + Approved-By: Andrew Burgess + +2024-04-26 Pedro Alves + + Fix gdb.base/attach.exp --pid test skipping on native-extended-gdbserver + When testing with the native-extended-gdbserver board, + gdb.base/attach.exp shows a couple failures, like so: + + Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ... + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread) + + From gdb.log: + + builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build + /gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260 + Don't know how to attach. Try "help target". + (gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + + There is a check for [isnative] to skip the test on anything but + target native, but that is the wrong check. native-extended-gdbserver + is "isnative". Fix it by using a gdb_protocol check instead. + + Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Eliminate gdb_is_target_remote / gdb_is_target_native & friends + After the previous patches, gdb_is_target_remote, + gdb_is_target_native, and mi_is_target_remote aren't used anywhere. + This commit eliminates them, along with now unnecessary helpers. + + Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_remote -> gdb_protocol_is_remote + This is similar to the previous patch, but for gdb_protocol_is_remote. + + gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint + print target-stack", which is unnecessary when checking whether + gdb_protocol is "remote" or "extended-remote" would do. Checking + gdb_protocol is more efficient, and can be done before starting GDB + and running to main, unlike gdb_is_target_remote/mi_is_target_remote. + + This adds a new gdb_protocol_is_remote procedure, and uses it in place + of gdb_is_target_remote/mi_is_target_remote throughout. + + There are no uses of gdb_is_target_remote/mi_is_target_remote left + after this. Those will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_native -> gdb_protocol_is_native + gdb_is_target_native uses "maint print target-stack", which is + unnecessary when checking whether gdb_protocol is empty would do. + Checking gdb_protocol is more efficient, and can be done before + starting GDB and running to main, unlike gdb_is_target_native. + + This adds a new gdb_protocol_is_native procedure, and uses it in place + of gdb_is_target_native. + + At first, I thought that we'd end up with a few testcases needing to + use gdb_is_target_native still, especially multi-target tests that + connect to targets different from the default board target, but no, + actually all uses of gdb_is_target_native could be converted. + gdb_is_target_native will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdbserver: Fix vAttach response when attaching is not supported + handle_v_attach calls attach_inferior, which says: + + "return -1 if attaching is unsupported, 0 if it succeeded, and call + error() otherwise." + + So if attach_inferior return != 0, we have the unsupported case, + meaning we should return the empty packet instead of an error. + + In practice, this shouldn't trigger, as vAttach support is supposed to + be reported via qSupported. But it doesn't hurt to be pedantic here. + + Change-Id: I99cce6fa678f2370571e6bca0657451300956127 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "attach" failure handling with GDBserver + This fixes the same issue as the previous patch, but for "attach" + instead of "run". + + If attaching to a process with "attach" (vAttach packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + Here's an example: + + On the GDB side: + + ... + (gdb) tar extended-remote :9999 + ... + Remote debugging using :9999 + (gdb) attach 1 + Attaching to process 1 + Attaching to process 1 failed + (gdb) + + On the GDBserver side: + + $ gdbserver --once --multi :9999 + Listening on port 9999 + Remote debugging from host 127.0.0.1, port 37464 + gdbserver: Cannot attach to process 1: Operation not permitted (1) + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vAttach, and continue + connected to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_attach. + + Note we now let pid == 0 pass down to attach_inferior. That is so we + get a useful textual error message to report to GDB. + + This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought + it would be useful to add a new testcase specifically for this + scenario, in case gdb.base/attach.exp is ever split and stops trying + to attach again after a failed attach, with the same GDB session. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + + Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Improve vRun error reporting + After the previous commit, if starting the inferior process with "run" + (vRun packet) fails, GDBserver reports an error using the "E." textual + error packet. On the GDB side, however, GDB doesn't yet do anything + with the textual error string. This commit improves that. + + This makes remote debugging output the same as native output, when + possible, another small step in the "local/remote parity" project. + + E.g., before, against GNU/Linux GDBserver: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + + After, against GNU/Linux GDBserver (same as native): + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + During startup program exited with code 126. + + To know whether we have a textual error message, extend packet_result + to carry that information. While at it, convert packet_result to use + factory methods, and change its std::string parameter to a plain const + char *, as that it always what we have handy to pass to it. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "run" failure handling with GDBserver + If starting the inferior process with "run" (vRun packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + E.g., with the testcase program added by this commit, we see: + + On GDB side: + + ... + (gdb) tar extended-remote :999 + ... + Remote debugging using :9999 + (gdb) r + Starting program: + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + (gdb) + + On GDBserver side: + + $ gdbserver --once --multi :9999 + Remote debugging from host 127.0.0.1, port 34344 + bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied + bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied + gdbserver: During startup program exited with code 126. + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vCont, and continue connected + to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_run. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Windows: Fix run/attach hang after bad run/attach + On Cygwin, gdb.base/attach.exp exposes that an "attach" after a + previously failed "attach" hangs: + + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited + attach 0 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited + attach 10644 + FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout) + + The problem is that windows_nat_target::attach always returns success + even if the attach fails. When we return success, the helper thread + begins waiting for events (which will never come), and thus the next + attach deadlocks on the do_synchronously call within + windows_nat_target::attach. + + "run" has the same problem, which is exposed by the new + gdb.base/run-fail-twice.exp testcase added in a following patch: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.) + (gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1 + run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout) + + The problem here is the same, except that this time it is + windows_nat_target::create_inferior that returns the incorrect result. + + This commit fixes both the "attach" and "run" paths, and the latter + both the Cygwin and MinGW paths. The tests mentioned above now pass + on Cygwin. Confirmed the fixes manually for MinGW GDB. + + Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Document "E.MESSAGE" RSP errors + For many years, GDB has accepted a "E.MESSAGE" error reponse, in + addition to "E NN". For many packets, GDB strips the "E." before + giving the error message to the user. For others, GDB does not strip + the "E.", but still understands that it is an error, as it starts with + "E", and either prints the whole string, or ignores it and just + mentions an error occured (same as for "E NN"). + + This has been the case for as long as I remember. Now that I check, I + see that it's been there since 2006 (commit a76d924dffcb, also here: + https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html). + All along, I actually thought it was documented. Turns out it wasn't. + + This commit documents it, in the new "Standard Replies" section, near + where we document "E NN". + + The original version of this 3-patch documentation series was a single + CodeSourcery patch that documented the textual error as + "E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded. But I + think the ship has sailed for that. GDBserver has been sending error + messages with more than one "." for a long while, and with no binary + encoding. Still, I've preserved the "Co-Authored-By" list of the + original larger patch. + + The 'qRcmd' and 'm' commands are exceptions and do not accept this + reply format. The top of the "Standard Replies" section already says: + + "All commands support these, except as noted in the individual + command descriptions." + + So this adds a note to the description of 'qRcmd' and 'm', explicitly + stating that they do not support this error reply format. + + Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Centralize documentation of error and empty RSP responses + Currently, for each packet, we document the "E NN" response (error), + and the empty response (unsupported). This patch centralizes that in + a new "Standard Replies" section. + + In the "Packets", "General Query Packets", "Tracepoint Packets" + sections, Remove explicit mention of empty and error replies, except + when they provide detail not covered in Standard Replies. + + Note this hunk: + + -@item E @var{NN} + -@var{NN} is errno + + and this one: + + -@item E00 + -The request was malformed, or @var{annex} was invalid. + - + -@item E @var{nn} + -The offset was invalid, or there was an error encountered reading the data. + -The @var{nn} part is a hex-encoded @code{errno} value. + + were really documenting things that don't really work that way. + + The first is the documentation of the "m" packet. GDB does _not_ + interpret the NN as an errno. It can't, in fact, because the + remote/target errno numbers have nothing to do with GDB/host errno + numbers in a cross debugging scenario. + + The second hunk above is from the documentation of qXfer. Again, GDB + does not give any interpretation to the NN error code at all. Nor + does GDBserver. And again, an errno number can't be interpreted in a + cross debugging scenario. + + Change-Id: I973695c80809cdb5a5e8d5be8b78ba4d1ecdb513 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Document conventions for describing packet syntax + This comment documents conventions for describing packet syntax in the + Overview section. + + Change-Id: I96198592601b24c983da563d143666137e4d0a4e + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Bernd Edlinger + + Remove unnecessary get_current_frame calls from infrun.c + Since the frame variable is now a frame_info_ptr, the issue + with the dangling frame pointer is apparently no longer there. + + So remove the re-fetch code and the corresponding meanwhile + misleading comments. + + Approved-By: Tom Tromey + +2024-04-26 Andrew Burgess + + gdb: Add a SECURITY.txt document for GDB + This commit adds a SECURITY document to GDB. The idea behind this + document is to define what security expectations a user can reasonably + have when using GDB. In addition the document specifies which bugs + GDB developers consider a security bug, and which are just "normal" + bugs. + + Discussion for the creation of this initial version can be found here: + + https://inbox.sourceware.org/gdb-patches/877cmvui64.fsf@redhat.com/ + + Like any part of GDB, this is not intended as the absolute final + version, instead this is a living document, and this is just a + reasonable starting point from which we can iterate. + + For now I've added this document as a text file but I am considering + merging this document into the manual at a later date, and having the + SECURITY.txt file just say "Read the manual" + + Approved-By: Tom Tromey + +2024-04-26 Sébastien Michelland + + gdb: specify sh pointer register types + This patch fixes a pretty funny issue on sh targets that occurred + because $pc (and similar registers) were typed as int. When $pc is in + the upper half of the address space (i.e. kernel code on sh), `x/i $pc' + would resolve to a negative value. At least in the case of a remote + target with an Xfer memory map, this leads to a spurious "cannot access + memory" error as negative addresses are out of bounds. + + (gdb) x/i $pc + 0x8c202c04: Cannot access memory at address 0x8c202c04 + (gdb) x/i 0x8c202c04 + => 0x8c202c04 : mov.l @r1,r10 + + The issue is fixed by specifying pointer types for pc and other pointer + registers. Code pointer registers on sh include pc, pr (return address + of a call), vbr (interrupt handler) and spc (return address after + interrupt). Data pointers include r15 (stack pointer) and gbr (base + register for a few specific addressing modes). + + Change-Id: I043a058f7cbc6494f380dc0461616a9f3e0d87e0 + Approved-By: Simon Marchi + +2024-04-26 Jan Beulich + + objcopy: check input flavor before setting PE/COFF section alignment + coff_section_data() and elf_section_data() use the same underlying + field. The pointer being non-NULL therefore isn't sufficient to know + that pei_section_data() can validly be used on the incoming object. + Apparently in 64-bit-host builds the resulting memory corruption is + benign, whereas in 32-bit-host builds a segmentation fault occurs upon + de-referencing pei_section_data()'s return value. + +2024-04-26 GDB Administrator + + Automatic date update in version.in + +2024-04-25 Carl Love + + Fix end_sequence addresses for dw2-lines.exp + The patch: + + From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001 + From: Tom de Vries + Date: Wed, 17 Apr 2024 12:55:00 +0200 + Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses + + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + + + + The regression failure on PowerPC is due to the change in file + dw2-lines.exp, + + - DW_LNE_set_address bar_label_5 + + DW_LNE_set_address "$main_start + $main_len" + + The label bar_label_5 is in function bar, not function main. The new + set address should have been $bar_start + $bar_len. + +2024-04-25 David Faust + + bpf: fix calculation when deciding to relax branch + In certain cases we were calculating the jump displacement incorrectly + when deciding whether to relax a branch. This meant for some branches, + such as a very long backwards conditional branch, relaxation was not + done when it should have been. The result was to error later, because + the actual jump displacement was too large to fit in the original + instruction. + + This patch fixes up the displacement calculation so that those branches + are correctly relaxed and no longer result in an error. In addition, it + changes md_convert_frag to install fixups for the JAL instructions in + the resulting relaxations rather than encoding the displacement value + directly. + + gas/ + * config/tc-bpf.c (relaxed_branch_length): Correct displacement + calculation when relaxing. + (md_convert_frag): Likewise. Install fixups for JAL + instructions resulting from relaxation. + * testsuite/gas/bpf/jump-relax-ja-be.d: Correct and expand test. + * testsuite/gas/bpf/jump-relax-ja.d: Likewise. + * testsuite/gas/bpf/jump-relax-ja.s: Likewise. + * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.s: Likewise. + +2024-04-25 Simon Marchi + + gdb: add type annotations to ada-unicode.py + Add type annotations to ada-unicode.py, just enough to make pyright + happy: + + $ pyright --version + pyright 1.1.359 + $ pyright ada-unicode.py + 0 errors, 0 warnings, 0 informations + + Introduce a `Range` class instead of using separate variables and + tuples, to make the code and type annotations a bit cleaner. + + When running ada-unicode.py, I get a diff for ada-casefold.h, but I get + the same diff before and after this patch, so that is a separate issue. + + Change-Id: I0d8975a57f9fb115703178ae197dc6b6b8b4eb7a + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove gdbcmd.h + Most files including gdbcmd.h currently rely on it to access things + actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make + things easy, replace all includes of gdbcmd.h with includes of + cli/cli-cmds.h. This might lead to some unused includes of + cli/cli-cmds.h, but it's harmless, and much faster than going through + the 170 or so files by hand. + + Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move style_set_list/style_show_list declarations to cli/cli-style.h + They are defined in cli/cli-style.c. + + Change-Id: Ic478a3985ff0fd773bd7ba85bb144c6e914d0be6 + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove unused print_command_line and print_command_lines declarations + There is no corresponding definition for print_command_line. + + There is already a declaration for print_command_lines in + cli/cli-script.h (the implementation is in cli/cli-script.c). + + Change-Id: Ic9e67ed04703306d614383ead14e2b2b059b2a8e + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move execute function declarations from gdbcmd.h to top.h + These functions are implemented in top.c, move their declarations to + top.h. + + Change-Id: I8893ef91d955156a6530734fefe8002d78c3e5fc + Approved-By: Tom Tromey + +2024-04-25 Jinyang He + + LoongArch: gas: Simplify relocations in sections without code flag + Gas should not emit ADD/SUB relocation pairs for label differences + if they are in the same section without code flag even relax enabled. + Because the real value is not be affected by relaxation and it can be + compute out in assembly stage. Thus, correct the `TC_FORCE_RELOCATION + _SUB_SAME` and the label differences in same section without code + flag can be resolved in fixup_segment(). + +2024-04-25 Lulu Cai + + LoongArch: Add bad static relocation check and output more information to user + Absolute address symbols cannot be used with -shared. + We output more information to the user than just BFD_ASSETR. + + LoongArch: The symbol got type can only be obtained after initialization + When scanning relocations and determining whether TLS type transition is + possible, it will try to obtain the symbol got type. If the symbol got + type record has not yet been allocated space and initialized, it will + cause ld to crash. So when uninitialized, the symbol is set to GOT_UNKNOWN. + +2024-04-25 GDB Administrator + + Automatic date update in version.in + +2024-04-24 Thiago Jung Bauermann + + gdb/testsuite: Add libc_has_debug_info require helper + Factor the test for libc debug info out of gdb.base/relativedebug.exp to + a new procedure. + + Also, change the "info sharedlibrary" test to explicitly detect when + libc has debug info. + + Approved-by: Kevin Buettner + +2024-04-24 Ciaran Woodward + + gdb/doc: Fix incorrect information in RSP doc + The 'PacketSize' attribute of the qSupported packet was + documented to be the maximum size of the packet including + the frame and checksum bytes, however this is not how it + was treated in the code. In reality, PacketSize is the + maximum size of the data in the RSP packets, not including + the framing or checksum bytes. + + For instance, GDB's remote.c treats it as the maximum + number of data bytes. See remote_read_bytes_1, where the + size of the request is capped at PacketSize/2 (for + hex-encoding). + + Also see gdbserver's server.cc, where the internal buffer + is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize. + In gdbserver's case, the buffer is not used for any of the + framing or checksum characters. (I am not certain where the -1 + comes from. I think it comes from back when there were no + binary packets, so packets were treated as strings with + null terminators). + + It also seems like gdbservers in the wild treat it in + this way: + + Embocosm doc: + https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#id3078000 + + A quick glance over openocd's gdb_server.c gdb_put_packet_inner() + function shows that the internal buffer also excludes the framing + and checksum. + + Likewise, qEmu's gdbstub.c allocates PacketSize bytes for + the internal packet contents, and PacketSize+4 for the + full frame. + + Reviewed-By: Eli Zaretskii + Approved-By: Pedro Alves + +2024-04-24 Bernd Edlinger + + Handle two-linetable function in find_epilogue_using_linetable + Consider the following test-case: + ... + $ cat hello.c + int main() + { + printf("hello "); + #include "world.inc" + $ cat world.inc + printf("world\n"); + return 0; + } + $ gcc -g hello.c + ... + + The line table for the compilation unit, consisting just of + function main, is translated into these two gdb line tables, one for hello.c + and one for world.inc: + ... + compunit_symtab: hello.c + symtab: hello.c + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 3 0x400557 0x400557 Y + 1 4 0x40055b 0x40055b Y + 2 END 0x40056a 0x40056a Y + + compunit_symtab: hello.c + symtab: world.inc + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 1 0x40056a 0x40056a Y + 1 2 0x400574 0x400574 Y + 2 3 0x400579 0x400579 Y + 3 END 0x40057b 0x40057b Y + ... + + The epilogue of main starts at 0x400579: + ... + 400579: 5d pop %rbp + 40057a: c3 ret + ... + + Now, say we have an epilogue_begin marker in the line table at 0x400579. + + We won't find it using find_epilogue_using_linetable, because it does: + ... + const struct symtab_and_line sal = find_pc_line (start_pc, 0); + ... + which gets us the line table for hello.c. + + Fix this by using "find_pc_line (end_pc - 1, 0)" instead. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + PR symtab/31622 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622 + +2024-04-24 Bernd Edlinger + + Fix an out of bounds array access in find_epilogue_using_linetable + An out of bounds array access in find_epilogue_using_linetable causes random + test failures like these: + + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $fn_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: check frame-id matches + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: bt 2 + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: up + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $sp_value == $::main_sp + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $::main_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: [string equal $fid $::main_fid] + + Here the read happens below the first element of the line + table, and the test failure depends on the value that is + read from there. + + It also happens that std::lower_bound returns a pointer exactly at the upper + bound of the line table, also here the read value is undefined, that happens + in this test: + + FAIL: gdb.dwarf2/dw2-epilogue-begin.exp: confirm watchpoint doesn't trigger + + Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table") + + Co-Authored-By: Tom de Vries + + PR symtab/31268 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268 + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp for remote host + With test-case gdb.threads/threadcrash.exp using host board local-remote-host + and target board remote-gdbserver-on-localhost I run into: + ... + (gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash + gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M + Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M + (gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore + UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file + ... + + The problem is that the gcore command tries to save a file on a remote host, + but the filename is a location on build. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp with glibc debuginfo + After installing glibc debuginfo, I ran into: + ... + FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \ + $thread_count == [llength $test_list] + ... + + This happens because the clause: + ... + -re "^\r\n${hs}main$hs$eol" { + ... + which is intended to match only: + ... + #1 in main () at threadcrash.c:423^M + ... + also matches "remaining" in: + ... + #1 in __GI___nanosleep (requested_time=, remaining=) at \ + nanosleep.c:27^M + ... + + Fix this by checking for "in main" instead. + + Tested on x86_64-linux. + +2024-04-24 Nick Clifton + + Update readelf's display of RELR sections to include the number of locations relocated + +2024-04-24 Simon Marchi + + gdb: include extract-store-integer.h in charset.c when PHONY_ICONV + When building on a system where "phony iconv" is used (NetBSD in this + case, not sure why), I get: + + CXX charset.o + /home/smarchi/src/binutils-gdb/gdb/charset.c: In function 'size_t phony_iconv(int, const char**, size_t*, char**, size_t*)': + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: error: 'extract_unsigned_integer' was not declared in this scope + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: note: suggested alternative: 'btrace_insn_number' + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + btrace_insn_number + + Add the necessary include. + + Change-Id: I10b967584645961c86167a8395d88929a42bef03 + +2024-04-24 Alan Modra + + PPC maintainers + I'm retiring from IBM, and Geoff hasn't been active for a very long + time. + + * MAINTAINERS (ppc): Remove myself and Geoff Keating. Add + Geoff to past maintainers. + +2024-04-24 Alan Modra + + buffer overflow in libctf tests + * testsuite/libctf-regression/gzrewrite.c (main): Don't overflow + "a" buffer in "after adding types" check. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-24 GDB Administrator + + Automatic date update in version.in + +2024-04-23 Simon Marchi + + gdb: adjust copyright years of extract-store-integer.{c,h} + The contents of these files was copied from defs.h and findvar. Copy + over the copyright years (1986-2024). + + Change-Id: Idfb0f255fbcfda7e107e9a82804cece3d81ed5fc + +2024-04-23 Claudio Bantaloukas + + arm: Fix MVE vmla encoding + +2024-04-23 Olivier Hainque + + bfd: Remove duplicate word in elf-vxworks.c + PR ld/31652 + * elf-vxworks.c (elf_vxworks_emit_relocs): Drop duplicate word. + +2024-04-23 H.J. Lu + + objcopy.c: Fix bfd_copy_private_symbol_data on 32-bit hosts + Use long with bfd_copy_private_symbol_data to fix + + .../binutils/objcopy.c: In + function ‘copy_object’: + .../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare] + 3383 | for (i = 0; i < symcount; i++) + | ^ + + on 32-bit hosts. + + PR binutils/14493 + * objcopy.c (copy_object): Use long with + bfd_copy_private_symbol_data. + +2024-04-23 Simon Marchi + + gdb: move symbol_file_command declaration to symfile.h + Move it out of defs.h, the corresponding definition is in symfile.c. + + Change-Id: I984666c3bcd213f8574e9ec91462e1d61f77f16b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove enum precision_type + It is unused. + + Change-Id: Ic49a3ef03c21b209594cd567ae80b5441606bef6 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move annotation_level declaration/definition to annotate.{h,c} + The declaration of annotation_level is currently in defs.h, while the + definition is in stack.c. I don't really understand why that variable + would live in stack.c, it seems completely unrelated. Move it to + annotate.c, and move the declaration to annotate.h. + + Change-Id: I6cf8e9bd20e83959bdf5ad58dd008b6e1187d7d8 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move a bunch of quit-related things to event-top.{c,h} + Move some declarations related to the "quit" machinery from defs.h to + event-top.h. Most of the definitions associated to these declarations + are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, + that are defined in utils.c. For consistency, move these two + definitions to event-top.c. + + Include "event-top.h" in many files that use these things. + + Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change type of quit_flag to bool + Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change return type of check_quit_flag to bool + Change the return type of the check_quit_flag function to bool. Update + a few related spots. + + Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move declarations of check_quit_flag and set_quit_flag to extension.h + Move them out of defs.h, to extension.h, since the implementations are + in extension.c. + + Change-Id: Ie7321468bd7fecc684d70b09f72c3ee8ac75d8f4 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove unused include in infrun.c + Remove the gdbcmd.h, which is reported as unused by clangd. Add + cli/cli-cmds.h instead, to get access to `cmdlist` and friends. + + Change-Id: Ic0c60d2f6d3618f1bd9fd80b95ffd7c33c692a04 + +2024-04-23 Waqar Hameed + + objdump: Round ASCII art lines in jump visualization + +2024-04-23 Simon Marchi + + gdb/dwarf2/read.c: remove pessimizing std::move + When building with this clang: + + $ c++ --version + FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) + + I see: + + $ gmake + CXX dwarf2/read.o + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] + std::move (thread_storage.release_parent_map ())); + ^ + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: note: remove std::move call here + std::move (thread_storage.release_parent_map ())); + ^~~~~~~~~~~ ~ + + The compiler seems right, there is not need to std::move the result of + `release_parent_map ()`, it's already going to be an rvalue. Remove the + std::move. + + The issue isn't FreeBSD-specific, I see it on Linux as well when + building hwith clang, I just noticed it on a FreeBSD build first. + + Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: bump black version to 24.4.0 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I977781fa6cc924c398cc3b9d9954dc0fbb95d082 + +2024-04-23 Alan Modra + + PR31667, objcopy/strip corrupts solaris binaries + Using want_p_paddr_set_to_zero in commit 45d92439aebd was wrong. Even + solaris targets don't have want_p_paddr_set_to_zero, but we should + handle them at least somewhat reasonably. + + PR 31667 + * elf.c (IS_SECTION_IN_INPUT_SEGMENT): Remove bed arg, add + paddr_valid. Don't use bed->want_p_paddr_set_to_zero. + (INCLUDE_SECTION_IN_SEGMENT): Likewise. + (rewrite_elf_program_header): Adjust to suit. + +2024-04-23 Alan Modra + + ignore some symbols in elf.c:swap_out_syms + The reason behind this patch was noticing that generic ELF targets + fail to remove "bar" in the recently committed ld-elf/undefweak-1 + test. (Despite that, those targets pass the test due to it being too + strict when matching symbols. "bar" gets turned into a local weak + defined absolute symbol.) + + swap_out_syms currently drops local section syms that are defined in + discarded sections. Extend that to also drop other symbols in + discarded sections too, even global symbols. The linker goes to quite + a lot of effort to ensure globals in discarded section take a + definition from the kept linkonce or comdat group section. So the + global sym change should only affect cases where something is quite + wrong about the set of linkonce or comdat group sections. However + that change to elf_map_symbols meant we dropped _DYNAMIC_LINK / + _DYNAMIC_LINKING for mips, a global absolute symbol given STT_SECTION + type for some reason. That problem is fixed by reverting the pr14493 + change which is no longer needed due to a) BSF_SECTION_SYM_USED on + x86, and b) fixing objcopy to use copy_private_symbol_data. + + bfd/ + PR 14493 + * elf.c (ignore_sym): Rename from ignore_section_sym. Return + true for any symbol without a section or in a discarded section. + Revert pr14493 change. + (elf_map_symbols): Tidy. Use ignore_sym on all symbols. + (swap_out_syms): Tidy. + ld/ + * testsuite/ld-elf/undefweak-1.rd: Match any "bar". + +2024-04-23 Alan Modra + + xfail undefweak-1 test for alpha + ".set" has a different meaning on alpha. Changing it to ".equ" runs + into ".equ" having a different meaning on hppa, and changing it to "=" + runs into trouble on bfin. + + * testsuite/ld-elf/elf.exp (undefweak-1): xfail on alpha, + don't xfail for genelf. + +2024-04-23 Alan Modra + + use copy_private_symbol_data in objcopy + osympp appearing twice here is not a bug. + + PR 14493 + * objcopy.c (copy_object): Run the symbols through + bfd_copy_private_symbol_data. + +2024-04-23 Alan Modra + + copy_private_symbol_data + bfd_copy_private_symbol_data is a bfd function that appeared in + commit 89665c8562da a long time ago, but seemingly wasn't used + anywhere until Jan added it to gas/symbols.c in commit 6a2b6326c21e. + + The function is used to modify ELF symbol st_shndx for symbols defined + in odd sections like .symtab, so that they get the corresponding + section st_shndx in an output file. This patch fixes some bitrot in + the function. After commit c03551323c04 which introduced + output_elf_obj_tdata, elf_strtab_sec and elf_shstrtab_sec will + segfault if used on an input bfd. + + PR 14493 + * elf.c (_bfd_elf_copy_private_symbol_data): Don't use + elf_strtab_sec and elf_shstrtab_sec. + +2024-04-23 Simon Marchi + + gdb: don't include gdbsupport/array-view.h in defs.h + Nothing in defs.h actually uses this. Everything that I (and the + buildbot) can compile still compiles, so I guess that all users of + array_view already include it one way or another. Worst case, if this + causes some build failure, the fix will be one #include away. + + Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: don't include hashtab.h in defs.h + Nothing in defs.h actually uses this. + + Add some includes for some spots using things from hashtab.h. Note that + if the GDB build doesn't use libxxhash, hashtab.h is included by + gdbsupport/common-utils.h, so all files still see hashtab.h. It puzzled + me for some time why I didn't see build failures in my build (which + didn't use libxxhash) but the buildbot gave build failures (it uses + libxxhash). + + Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move RequireLongest to gdbsupport/traits.h + Move it out of defs.h. + + Change-Id: Ie1743d41a57f81667650048563e66073c72230cf + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move store/extract integer functions to extract-store-integer.{c,h} + Move the declarations out of defs.h, and the implementations out of + findvar.c. + + I opted for a new file, because this functionality of converting + integers to bytes and vice-versa seems a bit to generic to live in + findvar.c. + + Change-Id: I524858fca33901ee2150c582bac16042148d2251 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: remove extract_long_unsigned_integer + It is unused. + + Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move `enum compile_i_scope_types` to compile/compile.h + Move it out of defs.h, adjust the includes here and there. + + Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move two declarations out of defs.h + Move declarations of initialize_progspace and initialize_inferiors to + progspace.h and inferior.h, respectively. + + Change-Id: I62292ffda429861b9f27d8c836a56d161dfa548d + Approved-By: John Baldwin + +2024-04-23 GDB Administrator + + Automatic date update in version.in + +2024-04-22 Thiago Jung Bauermann + + gdb/testsuite: Use default gdb_expect timeout in runto + runto uses a hard-coded timeout of 30s in its invocation of gdb_expect. + This is normally fine, but for very a slow system (e.g., an emulator) it + may not be enough time for GDB to reach the intended breakpoint. + + gdb_expect can obtain a timeout value from user-configurable variables + when it's not given one explicitly, so use that mechanism instead since + the user will have already adjusted the timeout variable to account for + the slow system. + + Approved-By: Tom Tromey + +2024-04-22 Andrew Burgess + + gdb: fix unknown variable typo in c-exp.y + Fix 'val' -> 'value' typo in c-exp.y which was breaking the build. + Introduced in commit: + + commit e6375bc8ebbbc177c79f08e9616eb0b131229f65 + Date: Wed Apr 17 16:17:33 2024 -0600 + + Remove some alloca uses + +2024-04-22 Victor Do Nascimento + + aarch64: Fix coding style issue in `aarch64-dis.c' + Fix integer value being returned from boolean function, as introduced + in `aarch64: Remove asserts from operand qualifier decoders [PR31595]'. + +2024-04-22 Tom Tromey + + Use std::vector in event-loop.cc + In my occasional and continuing campaign against realloc, this patch + changes event-loop.cc to use std::vector to keep track of pollfd + objects. Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + Approved-By: John Baldwin + +2024-04-22 Cui, Lili + + x86/APX: Add invalid check for APX EVEX.X4. + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Added invalid check for APX + X4. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added invalid + testcase. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (get_valid_dis386): Added invalid check for APX X4. + +2024-04-22 GDB Administrator + + Automatic date update in version.in + +2024-04-21 Tom Tromey + + Remove a couple of VLAs + I found a couple of spots where VLAs are in use but where they can + easily be removed. + + In one spot, adding 'const' is enough -- and is already done in + similar code elsewhere in the file. + + In another spot, one of two arrays will be used, so making the buffer + large enough for both works. + + Approved-By: John Baldwin + +2024-04-21 Tom Tromey + + Remove some alloca uses + A few spots (mostly in the parsers) use alloca to ensure that a string + is terminated before passing it to a printf-like function (mostly + 'error'). However, this isn't needed as the "%.*s" format can be used + instead. + + This patch makes this change. + + In one spot the alloca is dead code and is simply removed. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-04-21 GDB Administrator + + Automatic date update in version.in + +2024-04-20 mengqinggang + + LoongArch: Add -mignore-start-align option + Ignore .align at the start of a section may result in misalignment when + partial linking. Manually add -mignore-start-align option without partial + linking. + + Gcc -falign-functions add .align 5 to the start of a section, it causes some + error message mismatch. Set these testcases to xfail on LoongArch target. + +2024-04-20 Alan Modra + + Error compiling libctf-regression test + Seen on 64-bit targets. + ERROR: compilation of lookup program .../libctf-regression/gzrewrite.c failed + + * testsuite/libctf-regression/gzrewrite.c (main): Use %zu to + print size_t values. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-20 GDB Administrator + + Automatic date update in version.in + +2024-04-19 Simon Marchi + + gdb: add target_debug_printf and target_debug_printf_nofunc + Add the `target_debug_printf` and `target_debug_printf_nofunc` macros + and use them when outputting debug messages depending on `targetdebug`. + I opted for `target_debug_printf_nofunc` to follow the current style + where the function name is already printed, along with the arguments. + + Modify the debug printfs in the `debug_target` methods (generated by + `make-target-delegates.py`) to use `target_debug_printf_nofunc` as well. + + This makes the "target" debug prints integrate nicely with the other + debug prints that use the "new" debug print system: + + [infrun] proceed: enter + [infrun] follow_fork: enter + [target] -> multi-thread->record_will_replay (...) + [target] <- multi-thread->record_will_replay (-1, 0) = false + [target] -> multi-thread->supports_multi_process (...) + [target] <- multi-thread->supports_multi_process () = true + [infrun] follow_fork: exit + ... + + Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make regcache::debug_print_register return a string + Rename the method to `register_debug_string`. + + This makes it easier to introduce `target_debug_printf` in a subsequent + patch. + + Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make debug_target use one-liners + Turn the debug prints in debug_target's method to be one liners. For + instance, change this: + + gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ()); + gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog); + gdb_puts (") = ", gdb_stdlog); + target_debug_print_ptid_t (result); + gdb_puts ("\n", gdb_stdlog); + + into this: + + gdb_printf (gdb_stdlog, + "<- %s->wait (%s, %s, %s) = %s\n", + this->beneath ()->shortname (), + target_debug_print_ptid_t (arg0).c_str (), + target_debug_print_target_waitstatus_p (arg1).c_str (), + target_debug_print_target_wait_flags (arg2).c_str (), + target_debug_print_ptid_t (result).c_str ()); + + This makes it possible for a subsequent patch to turn this gdb_printf + call into a `target_debug_printf` call. + + Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make target debug functions return std::string + Change the functions in target-debug.h to return string representations + in an std::string, such that they don't need to know how the printing + part is done. This also helps the following patch that makes the debug + prints in debug_target one-liners. + + Update target-delegates.c (through make-target-delegates.py) to do the + printing. + + Add an overload of gdb_puts to avoid using `.c_str ()`. + + Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: fix include for gdb_signal in target/waitstatus.h + clangd tells me that the gdb_signals.h include in target/waitstatus.h is + unused. This include was probably to give access to `enum gdb_signal`, + but this is in fact defined in gdb/signals.h. Change the include to + gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were + relying on the transitive include. + + Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6 + +2024-04-19 Simon Marchi + + gdb: convert target debug macros to functions + Convert all the macros to static functions. Some macros were unused, + and now that they are functions, got flagged by the compiler, so I + omitted them. + + No behavior change expected. + + Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: add includes in target-debug.h + Editing target-debug.h with clangd shows a bunch of errors. Add some + includes to fix that (make target-debug.h include what it uses). + + Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376 + +2024-04-19 Nick Alcock + + libctf: do not include undefined functions in libctf.ver + libctf's version script is applied to two libraries: libctf.so, + and libctf-nobfd.so. The latter library is a subset of the former + which does not link to libbfd and does not include a few public + entry points that use it (found in libctf-open-bfd.c). This means + that some of the symbols in this version script only exist in one + of the libraries it's applied to. + + A number of linkers dislike this: before now, only Solaris's linker + caused serious problems, introducing NOTYPE-typed symbols when such + things were found, but now LLD has started to complain as well: + + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined + + Rather than adding more and more whack-a-mole fixes for every + linker we encounter that does this, simply exclude such symbols + unconditionally, using the same trick we used to use for Solaris. + (Well, unconditionally if we can use version scripts with this + linker at all, which is not always the case.) + + Thanks to Nicholas Vinson for the original report and a fix very + similar to this one (but not quite identical). + + libctf/ + + * configure.ac: Always exclude libctf symbols from + libctf-nobfd's version script. + * configure: Regenerated. + +2024-04-19 Nicholas Vinson + + libctf: Remove undefined functions from ver. map + Starting with ld.lld-17, ld.lld is invoked with the option + --no-undefined-version enabled by default. Furthermore, The functions + ctf_label_set() and ctf_label_get() are not defined. Their inclusion in + libctf/libctf.ver causes ld.lld-17 to fail emitting the following error + messages: + + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined + + This patch fixes the issue by removing the symbol names from + libctf/libctf.ver. + + [nca: fused in later commit that marked ctf_arc_open as libctf + only as well. Added ChangeLog entry.] + + + libctf/ + * libctf.ver: drop nonexistent label functions: mark + ctf_arc_open as libctf-only. + +2024-04-19 Nick Alcock + + libctf: don't pass errno into ctf_err_warn so often + The libctf-internal warning function ctf_err_warn() can be passed a libctf + errno as a parameter, and will add its textual errmsg form to the passed-in + error message. But if there is an error on the fp already, and this is + specifically an error and not a warning, ctf_err_warn() will print the error + out regardless: there's no need to pass in anything but 0. + + There are still a lot of places where we do + + ctf_err_warn (fp, 0, EFOO, ...); + return ctf_set_errno (fp, 0, EFOO); + + I've left all of those alone, because fixing it makes the code a bit longer: + but fixing the cases where no return is involved and the error has just been + set on the fp itself costs nothing and reduces redundancy a bit. + + libctf/ + + * ctf-dedup.c (ctf_dedup_walk_output_mapping): Drop the errno arg. + (ctf_dedup_emit): Likewise. + (ctf_dedup_type_mapping): Likewise. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_close_inputs): Likewise. + (ctf_link_deduplicating_one_symtypetab): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + * ctf-lookup.c (ctf_lookup_symbol_idx): Likewise. + * ctf-subr.c (ctf_assert_fail_internal): Likewise. + +2024-04-19 Nick Alcock + + libctf: fix leak in test + This purely serves to make it easier to interpret valgrind output. + No functional effect. + + libctf/ + * testsuite/libctf-lookup/conflicting-type-syms.c: Free everything. + +2024-04-19 Nick Alcock + + libctf: add rewriting tests + Now there's a chance of it actually working, we can add more tests for + the long-broken dict read-and-rewrite cases. This is the first ever + test for the (rarely-used, unpleasant, and until recently completely + broken) ctf_gzwrite function. + + libctf/ + + * testsuite/libctf-regression/gzrewrite*: New test. + * testsuite/libctf-regression/zrewrite*: Likewise. + +2024-04-19 Nick Alcock + + libctf: fix a debugging typo + libctf/ + + * ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo. + +2024-04-19 Nick Alcock + + libctf: make ctf_lookup of symbols by name work in more cases + In particular, we don't need a symbol table if we're looking up a + symbol by name and that type of symbol has an indexed symtypetab, + since in that case we get the name from the symtypetab index, not + from the symbol table. + + This lets you do symbol lookups in unlinked object files and unlinked + dicts written out via libctf's writeout functions. + + libctf/ + + * ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups + by index even when there is no symtab. + +2024-04-19 Nick Alcock + + libctf: improve handling of type dumping errors + When dumping a type fails with an error, we want to emit a warning noting + this: a warning because it's not fatal and we can continue. But warnings + don't automatically print out the ctf_errno (because not all cases causing + warnings set the errno at all), so we must do it at warning-emission time or + lose track of what's gone wrong. + + libctf/ + + * ctf-dump.c (ctf_dump_format_type): Dump the underlying error on + type dump failure. + +2024-04-19 Nick Alcock + + libctf: fix tiny dumping error + Without this, you might get things like this in the output: + + Flags: 0xa (CTF_F_NEWFUNCINFO, , CTF_F_DYNSTR) + + Note the spurious comma. + + libctf/ + * ctf-dump.c (ctf_dump_header): Fix comma emission. + +2024-04-19 Nick Alcock + + libctf: make ctf_serialize() actually serialize + ctf_serialize() evolved from the old ctf_update(), which mutated the + in-memory CTF dict to make all the dynamic in-memory types into static, + unchanging written-to-the-dict types (by deserializing and reserializing + it): back in the days when you could only do type lookups on static types, + this meant you could see all the types you added recently, at the small, + small cost of making it impossible to change those older types ever again + and inducing an amortized O(n^2) cost if you actually wanted to add + references to types you added at arbitrary times to later types. + + It also reset things so that ctf_discard() would throw away only types you + added after the most recent ctf_update() call. + + Some time ago this was all changed so that you could look up dynamic types + just as easily as static types: ctf_update() changed so that only its + visible side-effect of affecting ctf_discard() remained: the old + ctf_update() was renamed to ctf_serialize(), made internal to libctf, and + called from the various functions that wrote files out. + + ... but it was still working by serializing and deserializing the entire + dict, swapping out its guts with the newly-serialized copy in an invasive + and horrible fashion that coupled ctf_serialize() to almost every field in + the ctf_dict_t. This is totally useless, and fixing it is easy: just rip + all that code out and have ctf_serialize return a serialized representation, + and let everything use that directly. This simplifies most of its callers + significantly. + + (It also points up another bug: ctf_gzwrite() failed to call ctf_serialize() + at all, so it would only ever work for a dict you just ctf_write_mem()ed + yourself, just for its invisible side-effect of serializing the dict!) + + This lets us simplify away a bunch of internal-only open-side functionality + for overriding the syn_ext_strtab and some just-added functionality for + forcing in an existing atoms table, without loss of functionality, and lets + us lift the restriction on reserializing a dict that was ctf_open()ed rather + than being ctf_create()d: it's now perfectly OK to open a dict, modify it + (except for adding members to existing structs, unions, or enums, which + fails with -ECTF_RDONLY), and write it out again, just as one would expect. + + libctf/ + + * ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos. + (ctf_type_sect_size): Add static type sizes too. + (ctf_serialize): Return the new dict rather than updating the + existing dict. No longer fail for dicts with static types; + copy them onto the start of the new types table. + (ctf_gzwrite): Actually serialize before gzwriting. + (ctf_write_mem): Improve forced (test-mode) endian-flipping: + flip dicts even if they are too small to be compressed. + Improve confusing variable naming. + * ctf-archive.c (arc_write_one_ctf): Don't bother to call + ctf_serialize: both the functions we call do so. + * ctf-string.c (ctf_str_create_atoms): Drop serializing case + (atoms arg). + * ctf-open.c (ctf_simple_open): Call ctf_bufopen directly. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Delete/rename to ctf_bufopen: no + longer bother with syn_ext_strtab or forced atoms table, + serialization no longer needs them. + * ctf-create.c (ctf_create): Call ctf_bufopen directly. + * ctf-impl.h (ctf_str_create_atoms): Drop atoms arg. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Likewise. + (ctf_serialize): Adjust. + * testsuite/libctf-lookup/add-to-opened.c: Adjust now that + this is supposed to work. + +2024-04-19 Nick Alcock + + libctf: rethink strtab writeout + This commit finally adjusts strtab writeout so that repeated writeouts, or + writeouts of a dict that was read in earlier, only sorts the portion of the + strtab that was newly added. + + There are three intertwined changes here: + + - pull the contents of strtabs from newly ctf_bufopened dicts into the + atoms table, so that future additions will reuse the existing offset etc + rather than adding new identical strings + - allow the internal ctf_bufopen done by serialization to contribute its + existing atoms table, so that existing atoms can be used for the + remainder of the open process (like name table construction): this atoms + table currente gets thrown away in the mass reassignment done later in + ctf_serialize in any case, but it needs to be there during the open. + - rewrite ctf_str_write_strtab so that a) it uses iterators rather than + ctf_*_iter, reducing pointless structures which serve no other purpose + than to implement ordinary variable scope, but more clunkily, and b) + retains the existing strtab on the front of the new one, with its sort + retained, rather than resorting, so all existing already-written strtab + offsets remain valid across the call. + + This latter change finally permits repeated serializations, and + reserializations of ctf_open()ed dicts, to work, but for now we keep the + code that prevents that because serialization is about to change again in a + way that will make it more obvious that doing such things is safe, and we + can take it out then. + + (There are also some smaller changes like moving the purge of the refs table + into ctf_str_write_strtab(), since that's where the changes happen that + invalidate it, rather than doing it in ctf_serialize(). We also prohibit + something that has never worked, opening a dict and then reporting symbols + to it via ctf_link_add_strtab() et al: you must do that to newly-created + dicts which have had stuff ctf_link()ed into them. This is very unlikely + ever to be a problem in practice: linkers just don't do that sort of thing.) + + libctf/ + + * ctf-create.c (ctf_create): Add (temporary) atoms arg. + * ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New. + (ctf_str_create_atoms): Adjust. + (ctf_str_write_strtab): Likewise. + (ctf_simple_open_internal): Likewise. + * ctf-open.c (ctf_simple_open_internal): Add atoms arg. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Initialize just enough of an + atoms table: pre-init from the atoms arg if supplied. + (ctf_simple_open): Adjust. + * ctf-serialize.c (ctf_serialize): Constify the strtab. + Move ref list purging into ctf_str_write_strtab. + Initialize the new dict with the old dict's atoms table. + Accept the new strtab from ctf_str_write_strtab. + Adjust for addition of ctf_dynstrtab. + * ctf-string.c (ctf_strraw_explicit): Improve comments. + (ctf_str_create_atoms): Prepopulate from an existing atoms table, + or alternatively pull in all strings from the strtab and turn + them into atoms. + (ctf_str_free_atoms): Free the dynstrtab and its strtab. + (struct ctf_strtab_write_state): Remove. + (ctf_str_count_strtab): Fold this... + (ctf_str_populate_sorttab): ... and this... + (ctf_str_write_strtab): ... into this. Prepend existing strings + to the strtab rather than resorting them (and wrecking their + offsets). Keep the dynstrtab updated. Update refs for all + atoms with refs, whether or not they are strings newly added + to the strtab. + +2024-04-19 Nick Alcock + + libctf: replace 'pending refs' abstraction + A few years ago we introduced a 'pending refs' abstraction to fix one + problem: serializing a dict, then changing it would tend to corrupt the dict + because the strtab sort we do on strtab writeout (to improve compression + efficiency) would modify the offset of any strings that sorted + lexicographically earlier in the strtab: so we added a new restriction that + all strings are added only at serialization time, and maintained a set of + 'pending' refs that were added earlier, whose offsets we could update (like + other refs) at writeout time. + + This was in hindsight seriously problematic for maintenance (because + serialization has to traverse all strings in all datatypes in the entire + dict), and has become impossible to sustain now that we can read in existing + dicts, modify them, and reserialize them again. We really don't want to + have to dig through the entire dict we jut read in just in order to dig out + all its strtab offsets, then *change* it, just for the sake of a sort that + adds a frankly trivial amount of compression efficiency. + + Sorting *is* still worthwhile -- but it sacrifices very little to only sort + newly-added portions of the strtab, reusing older portions as necessary. + As a first stage in this, discard the whole "pending refs" abstraction and + replace it with "movable" refs, which are exactly like all other refs + (addresses containing the strtab offset of some string, which are updated + wiht the final strtab offset on serialization) except that we track them in + a reverse dict so that we can move the refs around (which we do whenever we + realloc() a buffer containing a bunch of structure members or something when + we add members to the structure). + + libctf/ + + * ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add + a movable ref. + (ctf_add_member_offset): Likewise. + * ctf-util.c (ctf_realloc): Delete. + * ctf-serialize.c (ctf_serialize): No longer use it. Adjust to + new fields. + * ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs. + (ctf_str_free_atom): Free freeable atoms' strings. + (ctf_str_create_atoms): Create the movable refs dynhash if needed. + (ctf_str_free_atoms): Destroy it. + (CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous + reversion). Add new flag. + (aref_create): New, populate movable refs if need be. + (ctf_str_add_ref_internal): Switch back to flags, update refs + directly for nonprovisional strings (with already-known fixed offsets); + create refs via aref_create. Allocate strings only if not within an + mmapped strtab. + (ctf_str_add_movable_ref): New. + (ctf_str_add): Adjust to CTF_STR_* reintroduction. + (ctf_str_add_external): LIkewise. + (ctf_str_move_refs): New, move refs via ctf_str_movable_refs + backpointer. + (ctf_str_purge_refs): Drop ctf_str_num_refs. + (ctf_str_update_refs): Fix indentation. + * ctf-impl.h (struct ctf_str_atom_movable): New. + (struct ctf_dict.ctf_str_num_refs): Drop. + (struct ctf_dict.ctf_str_movable_refs): New. + (ctf_str_add_movable_ref): Declare. + (ctf_str_move_refs): Likewise. + (ctf_realloc): Drop. + +2024-04-19 Nick Alcock + + Revert "libctf: do not corrupt strings across ctf_serialize" + This reverts commit 986e9e3aa03f854bedacef7fac38fe8f009a416c. + + (We do not revert the testcase -- it remains valid -- but we are + taking a different, less complex and more robust approach.) + + This also deletes the pending refs abstraction without (yet) + replacing it, so some tests will fail for a commit or two. + +2024-04-19 Nick Alcock + + libctf: rename ctf_dict.ctf_{symtab,strtab} + These two fields are constantly confusing because CTF dicts contain both + a symtypetab and strtab, but these fields are not that: they are the + symtab and strtab from the ELF file. We have enough string tables now + (internal, external, synthetic external, dynamic) that we need to at + least name them better than this to avoid getting totally confused. + Rename them to ctf_ext_symtab and ctf_ext_strtab. + + libctf/ + + * ctf-dump.c (ctf_dump_objts): Rename ctf_symtab -> ctf_ext_symtab. + * ctf-impl.h (struct ctf_dict.ctf_symtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + (struct ctf_dict.ctf_strtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + * ctf-lookup.c (ctf_lookup_symbol_name): Adapt. + (ctf_lookup_symbol_idx): Adapt. + (ctf_lookup_by_sym_or_name): Adapt. + * ctf-open.c (ctf_bufopen_internal): Adapt. + (ctf_dict_close): Adapt. + (ctf_getsymsect): Adapt. + (ctf_getstrsect): Adapt. + (ctf_symsect_endianness): Adapt. + +2024-04-19 Nick Alcock + + libctf: fix a comment typo + ctf_update has been called ctf_serialize for years now. + + libctf/ + + * ctf-impl.h: Fix comment typo. + +2024-04-19 Nick Alcock + + libctf: delete LCTF_DIRTY + This flag was meant as an optimization to avoid reserializing dicts + unnecessarily. It was critically necessary back when serialization was + done by ctf_update() and you had to call that every time you wanted any + new modifications to the type table to be usable by other types, but + that has been unnecessary for years now, and serialization is only done + once when writing out, which one would naturally assume would always + serialize the dict. Worse, it never really worked: it only tracked + newly-added types, not things like added symbols which might equally + well require reserialization, and it gets in the way of an upcoming + change. Delete entirely. + + libctf/ + + * ctf-create.c (ctf_create): Drop LCTF_DIRTY. + (ctf_discard): Likewise. + (ctf_rollback): Likewise. + (ctf_add_generic): Likewise. + (ctf_set_array): Likewise. + (ctf_add_enumerator): Likewise. + (ctf_add_member_offset): Likewise. + (ctf_add_variable_forced): Likewise. + * ctf-link.c (ctf_link_intern_extern_string): Likewise. + (ctf_link_add_strtab): Likewise. + * ctf-serialize.c (ctf_serialize): Likewise. + * ctf-impl.h (LCTF_DIRTY): Likewise. + (LCTF_LINKING): Renumber. + +2024-04-19 Nick Alcock + + libctf: fix a comment + A mistaken "not" in ctf_err_warn made it seem like we only extracted + error messages if this was not an error. + + libctf/ + + * ctf-subr.c (ctf_err_warn): Fix comment. + +2024-04-19 Nick Alcock + + libctf: support addition of types to dicts read via ctf_open() + libctf has long declared deserialized dictionaries (out of files or ELF + sections or memory buffers or whatever) to be read-only: back in the + furthest prehistory this was not the case, in that you could add a + few sorts of type to such dicts, but attempting to do so often caused + horrible memory corruption, so I banned the lot. + + But it turns out real consumers want it (notably DTrace, which + synthesises pointers to types that don't have them and adds them to the + ctf_open()ed dicts if it needs them). Let's bring it back again, but + without the memory corruption and without the massive code duplication + required in days of yore to distinguish between static and dynamic + types: the representation of both types has been identical for a few + years, with the only difference being that types as a whole are stored in + a big buffer for types read in via ctf_open and per-type hashtables for + newly-added types. + + So we discard the internally-visible concept of "readonly dictionaries" + in favour of declaring the *range of types* that were already present + when the dict was read in to be read-only: you can't modify them (say, + by adding members to them if they're structs, or calling ctf_set_array + on them), but you can add more types and point to them. (The API + remains the same, with calls sometimes returning ECTF_RDONLY, but now + they do so less often.) + + This is a fairly invasive change, mostly because code written since the + ban was introduced didn't take the possibility of a static/dynamic split + into account. Some of these irregularities were hard to define as + anything but bugs. + + Notably: + + - The symbol handling was assuming that symbols only needed to be + looked for in dynamic hashtabs or static linker-laid-out indexed/ + nonindexed layouts, but now we want to check both in case people + added more symbols to a dict they opened. + + - The code that handles type additions wasn't checking to see if types + with the same name existed *at all* (so you could do + ctf_add_typedef (fp, "foo", bar) repeatedly without error). This + seems reasonable for types you just added, but we probably *do* want + to ban addition of types with names that override names we already + used in the ctf_open()ed portion, since that would probably corrupt + existing type relationships. (Doing things this way also avoids + causing new errors for any existing code that was doing this sort of + thing.) + + - ctf_lookup_variable entirely failed to work for variables just added + by ctf_add_variable: you had to write the dict out and read it back + in again before they appeared. + + - The symbol handling remembered what symbols you looked up but didn't + remember their types, so you could look up an object symbol and then + find it popping up when you asked for function symbols, which seems + less than ideal. Since we had to rejig things enough to be able to + distinguish function and object symbols internally anyway (in order + to give suitable errors if you try to add a symbol with a name that + already existed in the ctf_open()ed dict), this bug suddenly became + more visible and was easily fixed. + + We do not (yet) support writing out dicts that have been previously read + in via ctf_open() or other deserializer (you can look things up in them, + but not write them out a second time). This never worked, so there is + no incompatibility; if it is needed at a later date, the serializer is a + little bit closer to having it work now (the only table we don't deal + with is the types table, and that's because the upcoming CTFv4 changes + are likely to make major changes to the way that table is represented + internally, so adding more code that depends on its current form seems + like a bad idea). + + There is a new testcase that tests much of this, in particular that + modification of existing types is still banned and that you can add new + ones and chase them without error. + + libctf/ + + * ctf-impl.h (struct ctf_dict.ctf_symhash): Split into... + (ctf_dict.ctf_symhash_func): ... this and... + (ctf_dict.ctf_symhash_objt): ... this. + (ctf_dict.ctf_stypes): New, counts static types. + (LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR. + (LCTF_RDWR): Deleted. + (LCTF_DIRTY): Renumbered. + (LCTF_LINKING): Likewise. + (ctf_lookup_variable_here): New. + (ctf_lookup_by_sym_or_name): Likewise. + (ctf_symbol_next_static): Likewise. + (ctf_add_variable_forced): Likewise. + (ctf_add_funcobjt_sym_forced): Likewise. + (ctf_simple_open_internal): Adjust. + (ctf_bufopen_internal): Likewise. + * ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with. + (ctf_create): Migrate a bunch of initializations into bufopen. + Force recreation of name tables. Do not forcibly override the + model, let ctf_bufopen do it. + (ctf_static_type): New. + (ctf_update): Drop LCTF_RDWR check. + (ctf_dynamic_type): Likewise. + (ctf_add_function): Likewise. + (ctf_add_type_internal): Likewise. + (ctf_rollback): Check ctf_stypes, not LCTF_RDWR. + (ctf_set_array): Likewise. + (ctf_add_struct_sized): Likewise. + (ctf_add_union_sized): Likewise. + (ctf_add_enum): Likewise. + (ctf_add_enumerator): Likewise (only on the target dict). + (ctf_add_member_offset): Likewise. + (ctf_add_generic): Drop LCTF_RDWR check. Ban addition of types + with colliding names. + (ctf_add_forward): Note safety under the new rules. + (ctf_add_variable): Split all but the existence check into... + (ctf_add_variable_forced): ... this new function. + (ctf_add_funcobjt_sym): Likewise... + (ctf_add_funcobjt_sym_forced): ... for this new function. + * ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts + with any stypes. + (ctf_link_add_strtab): Likewise. + (ctf_link_shuffle_syms): Likewise. + (ctf_link_intern_extern_string): Note pre-existing prohibition. + * ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check. + (ctf_lookup_variable): Split out looking in a dict but not + its parent into... + (ctf_lookup_variable_here): ... this new function. + (ctf_lookup_symbol_idx): Track whether looking up a function or + object: cache them separately. + (ctf_symbol_next): Split out looking in non-dynamic symtypetab + entries to... + (ctf_symbol_next_static): ... this new function. Don't get confused + by the simultaneous presence of static and dynamic symtypetab entries. + (ctf_try_lookup_indexed): Don't waste time looking up symbols by + index before there can be any idea how symbols are numbered. + (ctf_lookup_by_sym_or_name): Distinguish between function and + data object lookups. Drop LCTF_RDWR. + (ctf_lookup_by_symbol): Adjust. + (ctf_lookup_by_symbol_name): Likewise. + * ctf-open.c (init_types): Rename to... + (init_static_types): ... this. Drop LCTF_RDWR. Populate ctf_stypes. + (ctf_simple_open): Drop writable arg. + (ctf_simple_open_internal): Likewise. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Populate fields only used for writable dicts. + Drop LCTF_RDWR. + (ctf_dict_close): Cater for symhash cache split. + * ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR. + * ctf-types.c (ctf_variable_next): Drop LCTF_RDWR. + * testsuite/libctf-lookup/add-to-opened*: New test. + +2024-04-19 Nick Alcock + + libctf: fix name lookup in dicts containing base-type bitfields + The intent of the name lookup code was for lookups to yield non-bitfield + basic types except if none existed with a given name, and only then + return bitfield types with that name. Unfortunately, the code as + written only does this if the base type has a type ID higher than all + bitfield types, which is most unlikely (the opposite is almost always + the case). + + Adjust it so that what ends up in the name table is the highest-width + zero-offset type with a given name, if any such exist, and failing that + the first type with that name we see, no matter its offset. (We don't + define *which* bitfield type you get, after all, so we might as well + just stuff in the first we find.) + + Reported by Stephen Brennan . + + libctf/ + + * ctf-open.c (init_types): Modify to allow some lookups during open; + detect bitfield name reuse and prefer less bitfieldy types. + * testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test. + +2024-04-19 Nick Alcock + + libctf: remove static/dynamic name lookup distinction + libctf internally maintains a set of hash tables for type name lookups, + one for each valid C type namespace (struct, union, enum, and everything + else). + + Or, rather, it maintains *two* sets of hash tables: one, a ctf_hash *, + is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the + other, a ctf_dynhash *, is meant for lookups in ctf_create()d dicts. + + This distinction was somewhat valuable in the far pre-binutils past when + two different hashtable implementations were used (one expanding, the + other fixed-size), but those days are long gone: the hash table + implementations are almost identical, both wrappers around the libiberty + hashtab. The ctf_dynhash has many more capabilities than the ctf_hash + (iteration, deletion, etc etc) and has no downsides other than starting + at a fixed, arbitrary small size. + + That limitation is easy to lift (via a new ctf_dynhash_create_sized()), + following which we can throw away nearly all the ctf_hash + implementation, and all the code to choose between readable and writable + hashtabs; the few convenience functions that are still useful (for + insertion of name -> type mappings) can also be generalized a bit so + that the extra string verification they do is potentially available to + other string lookups as well. + + (libctf still has two hashtable implementations, ctf_dynhash, above, + and ctf_dynset, which is a key-only hashtab that can avoid a great many + malloc()s, used for high-volume applications in the deduplicator.) + + libctf/ + + * ctf-create.c (ctf_create): Eliminate ctn_writable. + (ctf_dtd_insert): Likewise. + (ctf_dtd_delete): Likewise. + (ctf_rollback): Likewise. + (ctf_name_table): Eliminate ctf_names_t. + * ctf-hash.c (ctf_dynhash_create): Comment update. + Reimplement in terms of... + (ctf_dynhash_create_sized): ... this new function. + (ctf_hash_create): Remove. + (ctf_hash_size): Remove. + (ctf_hash_define_type): Remove. + (ctf_hash_destroy): Remove. + (ctf_hash_lookup_type): Rename to... + (ctf_dynhash_lookup_type): ... this. + (ctf_hash_insert_type): Rename to... + (ctf_dynhash_insert_type): ... this, moving validation to... + * ctf-string.c (ctf_strptr_validate): ... this new function. + * ctf-impl.h (struct ctf_names): Extirpate. + (struct ctf_lookup.ctl_hash): Now a ctf_dynhash_t. + (struct ctf_dict): All ctf_names_t fields are now ctf_dynhash_t. + (ctf_name_table): Now returns a ctf_dynhash_t. + (ctf_lookup_by_rawhash): Remove. + (ctf_hash_create): Likewise. + (ctf_hash_insert_type): Likewise. + (ctf_hash_define_type): Likewise. + (ctf_hash_lookup_type): Likewise. + (ctf_hash_size): Likewise. + (ctf_hash_destroy): Likewise. + (ctf_dynhash_create_sized): New. + (ctf_dynhash_insert_type): New. + (ctf_dynhash_lookup_type): New. + (ctf_strptr_validate): New. + * ctf-lookup.c (ctf_lookup_by_name_internal): Adapt. + * ctf-open.c (init_types): Adapt. + (ctf_set_ctl_hashes): Adapt. + (ctf_dict_close): Adapt. + * ctf-serialize.c (ctf_serialize): Adapt. + * ctf-types.c (ctf_lookup_by_rawhash): Remove. + +2024-04-19 Nick Alcock + + libctf: don't leak the symbol name in the name->type cache + This cache replaced a cache of symbol index->ctf_id_t. That cache was + just an array, so it could get away with just being free()d, but the + ctfi_symnamedicts cache that replaced it is a full dynhash with a + dynamically-allocated string as the key. As such, it needs freeing with + ctf_dynhash_destroy(), not just free(), or we leak parts of the + underlying hashtab, and all the keys. + + libctf/ChangeLog: + + * ctf-archive.c (ctf_arc_flush_caches): Fix leak. + +2024-04-19 Nick Alcock + + binutils, objdump: Add --ctf-parent-section + This lets you examine CTF where the parent and child dicts are in entirely + different sections, rather than in a CTF archive with members with different + names. The linker doesn't emit ELF objects structured like this, but some + third-party linkers may; it's also useful for objcopy-constructed files + in some cases. + + (This is what the objdump --ctf-parent option used to do before commit + 80b56fad5c99a8c9 in 2021. The new semantics of that option are much more + useful, but that doesn't mean the old ones are never useful at all, so let's + bring them back.) + + (I was specifically driven to add this by DTrace's obscure "ctypes" and + "dtypes" options, which dump its internal, dynamically-generated dicts out + to files for debugging purposes: there are two, one the parent of the other. + Since they're in two separate files rather than a CTF archive and we have no + tools that paste files together into archives, objdump wouldn't show them -- + and even pasting them together into an ELF executable with objcopy didn't + help, since objdump had no options that could be used to look in specific + sections for the parent dict. With --ctf-parent-section, this sort of + obscure use case becomes possible again. You'll never need it for the + output of the normal linker.) + + binutils/ + + * doc/ctf.options.texi: Add --ctf-parent-section=. + * objdump.c (dump_ctf): Implement it. + (dump_bfd): Likewise. + (main): Likewise. + +2024-04-19 Gustavo Romero + + gdb: Document qIsAddressTagged packet + This commit documents the qIsAddressTagged packet. + + Reviewed-by: Eli Zaretskii + Approved-By: Eli Zaretskii + +2024-04-19 Gustavo Romero + + gdb/testsuite: Add unit tests for qIsAddressTagged packet + Add unit tests for testing qIsAddressTagged packet request creation and + reply checks. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Add qIsAddressTagged packet + This commit adds a new packet, qIsAddressTagged, allowing GDB remote + targets to use it to query the stub if a given address is tagged. + + Currently, the memory tagging address check is done via a read query, + where the contents of /proc//smaps is read and the flags are + inspected for memory tagging-related flags that indicate the address is + in a memory tagged region. + + This is not ideal, for example, for QEMU stub and other cases, such as + on bare-metal, where there is no notion of an OS file like 'smaps.' + Hence, the introduction of qIsAddressTagged packet allows checking + if an address is tagged in an agnostic way. + + The is_address_tagged target hook in remote.c attempts to use the + qIsAddressTagged packet first for checking if an address is tagged and + if the stub does not support such a packet (reply is empty) it falls + back to using the current mechanism that reads the contents of + /proc//smaps via vFile requests. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Introduce is_address_tagged target hook + This commit introduces a new target hook, target_is_address_tagged, + which is used instead of the gdbarch_tagged_address_p gdbarch hook in + the upper layer (printcmd.c). + + This change enables easy specialization of memory tagging address + check per target in the future. As target_is_address_tagged continues + to utilize the gdbarch_tagged_address_p hook, there is no change in + behavior for all the targets that use the new target hook (i.e., the + remote.c, aarch64-linux-nat.c, and corelow.c targets). + + Just the gdbarch_tagged_address_p signature is changed for convenience, + since target_is_address_tagged takes the address to be checked as a + CORE_ADDR type. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Use passed gdbarch instead of calling current_inferior + In do_examine function, use passed gdbarch when checking if an address + is tagged instead of calling current_inferior()->arch() to make the code + more localized and help modularity by not calling a current_* function, + which disguises the use of a global state/variable. There is no change + in the code behavior. + + Suggested-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from memtag_matches_p + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if + an address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_memtag_matches_p is always + called from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that + already points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, gdbarch_memtag_matches_p is called only after + should_validate_memtags is called, which checks the address at its end; + + b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only + after gdbarch_tagged_address_p is called directly. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Move MTE address check out of set_memtag + Remove check in parse_set_allocation_tag_input as it is redundant: + currently the check happens at the end of parse_set_allocation_tag_input + and also in set_memtag (called after parse_set_allocation_tag_input). + + After it, move MTE address check out of set_memtag and add this check to + the upper layer, before set_memtag is called. + + This is a preparation for using a target hook instead of a gdbarch hook + on MTE address checks. + + Approved-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from get_memtag + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an + address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_get_memtag is always called + from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already + points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag + hook) is called but only after should_validate_memtags, which calls + gdbarch_tagged_address_p; + + b) in do_examine, aarch64_linux_get_memtag is also called only after + gdbarch_tagged_address_p is directly called; + + c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags + matching or not -- after the initial check via direct call to + gdbarch_tagged_address_p; + + d) in memory_tag_print_tag_command, address is checked directly via + gdbarch_tagged_address_p before gdbarch_get_memtag is called. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Alan Modra + + Re: elf: Strip unreferenced weak undefined symbols + PR ld/31652 + * elflink.c (_bfd_elf_link_output_relocs): Don't segfault + on NULL rel_hash. + +2024-04-19 H.J. Lu + + elf: Strip unreferenced weak undefined symbols + Linker will resolve an undefined symbol only if it is referenced by + relocation. Unreferenced weak undefined symbols serve no purpose. + Weak undefined symbols appear in the dynamic symbol table only when they + are referenced by dynamic relocation. Mark symbols with relocation and + strip undefined weak symbols if they don't have relocation and aren't + in the dynamic symbol table. + + bfd/ + + PR ld/31652 + * elf-bfd.h (elf_link_hash_entry): Add has_reloc. + * elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc. + * elflink.c (_bfd_elf_link_output_relocs): Likewise. + (elf_link_output_extsym): Strip undefined weak symbols if they + don't have relocation and aren't in the dynamic symbol table. + + ld/ + + PR ld/31652 + * testsuite/ld-elf/elf.exp: Run undefweak tests. + * testsuite/ld-elf/undefweak-1.rd: New file. + * testsuite/ld-elf/undefweak-1a.s: Likewise. + * testsuite/ld-elf/undefweak-1b.s: Likewise. + * testsuite/ld-x86-64/weakundef-1.nd: Likewise. + * testsuite/ld-x86-64/weakundef-1a.s: Likewise. + * testsuite/ld-x86-64/weakundef-1b.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run undefweak tests. + +2024-04-19 Alan Modra + + memory leak in bfd/dwarf2.c + * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free + dwarf_addr_buffer and dwarf_str_offsets_buffer. + +2024-04-19 Alan Modra + + mmix disassemble memory leak + It's a once-off and of no consequence, but fix it anyway. The mmix + caonoicalize_syms array is an array of pointers. Freeing it won't + lose symbol names. + + * mmix-dis.c (initialize_mmix_dis_info): Free syms. + +2024-04-19 GDB Administrator + + Automatic date update in version.in + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake + On SLE-11, with an older dejagnu version, I ran into: + ... + Running gdb.ada/mi_prot.exp ... + UNRESOLVED: gdb.ada/mi_prot.exp: \ + testcase aborted due to invalid command name: gdb_find_gnatmake + ERROR: tcl error sourcing gdb.ada/mi_prot.exp. + ERROR: invalid command name "gdb_find_gnatmake" + while executing + "::gdb_tcl_unknown gdb_find_gnatmake" + ("uplevel" body line 1) + invoked from within + "uplevel 1 ::gdb_tcl_unknown $args" + (procedure "::unknown" line 5) + invoked from within + "gdb_find_gnatmake" + (procedure "gnatmake_version_at_least" line 2) + invoked from within + ... + + Proc gdb_find_gnatmake is actually a backup for find_gnatmake: + ... + if {[info procs find_gnatmake] == ""} { + rename gdb_find_gnatmake find_gnatmake + ... + so gnatmake_version_at_least should use find_gnatmake instead. + + For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we + don't run into this error. + + For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to + find_gnatmake, and we do run into the error. + + It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it + seems something legitimate to use. Maybe we should use future_ or gdb_future_ + prefix instead to make this more clear, but I've left that alone for now. + + Fix this by: + - triggering the same error with a recent dejagnu by removing + gdb_find_gnatmake unless used (and likewise for other procs in future.exp), + and + - using find_gnatmake in gnatmake_version_at_least. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31647 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647 + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use allocator_may_return_null=1 in two test-cases + Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw + MemoryError in inferior.read_memory if malloc fails") introduced + AddressSanitizer allocation-size-too-big errors in the two test-cases + affected by this commit. + + Fix this by suppressing the error in the two test-cases using + allocator_may_return_null=1. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html + +2024-04-18 Simon Marchi + + gdbsupport: constify some return values in print-utils.{h,cc} + There is no reason the callers of these functions need to change the + returned string, so change the `char *` return types to `const char *`. + + Update a few callers to also use `const char *`. + + Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 + Approved-By: Tom Tromey + +2024-04-18 Nick Clifton + + HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets. + PR 30743 + +2024-04-18 Will Hawkins + + Add DW_TAG_compile_unit DIE to Dummy CUs + Dummy CUs help detect errors and are very helpful. However, the DWARF + spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to + the header. This patch adds that. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650 + + Approved-By: Tom de Vries + Tested-By: Tom de Vries + +2024-04-18 Alan Modra + + Re: Fix address violations when reading corrupt VMS records + Fixes error reports about the length of EEOM records produced by gas. + + PR 21618 + * vms-alpha.c (evax_bfd_print_emh): Don't read subtyp if short + record. Consolidate error messages. + (evax_bfd_print_eeom): Allow length 10 record. + +2024-04-18 Alan Modra + + alpha_vms_get_section_contents vs. fuzzed files + This patch is in response to an oss-fuzz report regarding + use-of-uninitialized-value in bfd_is_section_compressed_info from + section contents provided by alpha_vms_get_section_contents. That + hole is covered by using bfd_zalloc rather than bfd_alloc. + + The rest of the patch is mostly a tidy. In a function returning + section contents, I tend to prefer a test on the section properties + over a test on file properties. That's why I've changed the file + flags test to one on section filepos and flags before calling + _bfd_generic_get_section_contents. Also, fuzzed objects can easily + have sections with file backing in relocatable objects, or sections + without file backing in images. Possible confusion is avoided by + testing each section. + + Note that we are always going to run into out-of-memory with fuzzed + alpha-vms object files due to sections with contents via ETIR records. + eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a + 32-bit repeat count. So section contents can be very large from a + relatively small file. I'm inclined to think that an out-of-memory + error is fine for such files. + + * vms-alpha.c (alpha_vms_get_section_contents): Handle sections + with non-zero filepos or without SEC_HAS_CONTENTS via + _bfd_generic_get_section_contents. Zero memory allocated for + sections filled by ETIR records. + +2024-04-18 Alan Modra + + Tidy objdump opb expressions + I don't think any of these can overflow, but since all of the + expressions I'm editing here are inside a while loop with condition + addr_offset < stop_offset, this change makes it more obvious that they + can't overflow. + + * objdump.c (disassemble_bytes): Calculate octet expressions + involving both addr_offset and stop_offset by first + subtracting addr_offset from stop_offset. + +2024-04-18 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Tom Tromey + + Remove a copy from c-exp.y:parse_number + parse_number copies its input string, but there is no need to do this. + This patch removes the copy. + + Regression tested on x86-64 Fedora 38. + + Reviewed-by: Keith Seitz + +2024-04-17 Pedro Alves + + gdb/Windows: Fix detach while running + While testing a WIP Cygwin GDB that supports non-stop, I noticed that + gdb.threads/attach-non-stop.exp exposes that this: + + (gdb) attach PID& + ... + (gdb) detach + + ... hangs. + + And it turns out that it hangs in all-stop as well. This commits + fixes that. + + After "attach &", the target is set running, we've called + ContinueDebugEvent and the process_thread thread is waiting for + WaitForDebugEvent events. It is the equivalent of "attach; c&". + + In windows_nat_target::detach, the first thing we do is + unconditionally call windows_continue (for ContinueDebugEvent), which + blocks in do_synchronously, until the process_thread sees an event out + of WaitForDebugEvent. Unless the inferior happens to run into a + breakpoint, etc., then this hangs indefinitely. + + If we've already called ContinueDebugEvent earlier, then we shouldn't + be calling it again in ::detach. + + Still in windows_nat_target::detach, we have an interesting issue that + ends up being the bulk of the patch -- only the process_thread thread + can call DebugActiveProcessStop, but if it is blocked in + WaitForDebugEvent, we need to somehow force it to break out of it. + The only way to do that, is to force the inferior to do something that + causes WaitForDebugEvent to return some event. + + This patch uses CreateRemoteThread to do it, which results in + WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT. We then + terminate the injected thread before it has a chance to run any + userspace code. + + Note that Win32 functions like DebugBreakProcess and + GenerateConsoleCtrlEvent would also inject a new thread in the + inferior. I first used DebugBreakProcess, but that is actually more + complicated to use, because we'd have to be sure to consume the + breakpoint event before detaching, otherwise the inferior would likely + die due a breakpoint exception being raised with no debugger around to + intercept it. + + See the new break_out_process_thread method. + + So the fix has two parts: + + - Keep track of whether we've called ContinueDebugEvent and the + process_thread thread is waiting for events, or whether + WaitForDebugEvent already returned an event. + + - In windows_nat_target::detach, if the process_thread thread is + waiting for events, unblock out of its WaitForDebugEvent, before + proceeding with the actual detach. + + New test included. Passes cleanly on GNU/Linux native and gdbserver, + and also passes cleanly on Cygwin and MinGW, with the fix. Before the + fix, it would hang and fail with a timeout. + + Tested-By: Hannes Domani + Reviewed-By: Tom Tromey + Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905 + +2024-04-17 Pedro Alves + + gdb+gdbserver/Linux: Remove USE_SIGTRAP_SIGINFO fallback + It's been over 9 years (since commit faf09f0119da) since Linux GDB and + GDBserver started relying on SIGTRAP si_code to tell whether a + breakpoint triggered, which is important for non-stop mode. When that + then-new code was added, I had left the then-old code as fallback, in + case some architectured still needed it. Given AFAIK there haven't + been complaints since, this commit finally removes the fallback code, + along with USE_SIGTRAP_SIGINFO. + + Change-Id: I140a5333a9fe70e90dbd186aca1f081549b2e63d + +2024-04-17 Tom Tromey + + Use section name in DWARF error message + A bug points out that a certain error message in read_str_index uses a + hard-coded section name. This patch changes it to use + dwarf2_section_info::get_name instead, like the other errors in the + function. + + No test because it didn't seem worthwhile. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31639 + Approved-By: Simon Marchi + +2024-04-17 Simon Marchi + + gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extension + When building with clang 18, I see: + + CXX aarch64-linux-tdep.o + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] + 1299 | gdb_byte za_zeroed[za_bytes]; + | ^~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here + 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); + | ^ + + Since we are using VLAs right now, that warning doesn't make sense for + us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to + enable. If we ever choose to disallow VLAs, we can remove that flag. + + Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c + +2024-04-17 Matt Wozniski + + Fix include guard typo + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645 + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: minor clean, remove some unneeded arguments + I spotted that the two functions: + + record_full_open_1 + record_full_core_open_1 + + both took two arguments, neither of which are used. + + I stumbled onto this while reviewing how filename_completer is used. + The 'record full restore' command uses filename_completer and invokes + the cmd_record_full_restore function. + + The cmd_record_full_restore function calls core_file_command and then + record_full_open, which then calls one of the above functions. + + As 'record full restore' takes a filename, this is passed to + cmd_record_full_restore, which forwards the filename to both + core_file_command and record_full_open. However, record_full_open + never actually uses the filename that is passed in. + + The record_full_open function is also used for 'target record-full'. + + I propose that record_full_open should no longer expect to see any + user supplied arguments passed in (it doesn't use any). In fact, I've + added a check that if we do get any user supplied arguments we'll + throw an error. + + Now that we know record_full_open isn't being passed any user + arguments we can stop passing the arguments to record_full_open_1 and + record_full_core_open_1, this will make no user visible difference as + these arguments were not used. + + It is possible that a user was previously doing: + + (gdb) target record-full blah blah blah + + And this previously would work fine, the 'blah blah blah' was + ignored. Now this will give an error. Other than this case there + should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: add an assert in cmd_record_start + The 'record' command is both a prefix command AND an alias for 'target + record-full'. As it is a prefix command, if a user types: + + (gdb) record blah + + Then GDB will look for, and try to invoke the 'blah' sub-command. + This will either succeed (if blah is found) or throw an error (if blah + is not found). + + As such, the only way to invoke the 'record' command is like: + + (gdb) record + + It is impossible to pass arguments to the 'record' command. As we + know this is true then we can assert this in cmd_record_start. + + I added this assert because initially I was going to try forwarding + ARGS from cmd_record_start to the 'target record-full' command, but + then I realised passing arguments to 'record' was impossible. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: remove unnecessary use of filename_completer + Spotted that the 'record' command has its completer set to + filename_completer. The problem is that 'record' is a prefix command, + as such, its completer is hard-coded to complete on sub-commands. The + attempt to use filename_completer is irrelevant. + + The 'record' command is itself a command though, that is, a user can + do this: + + (gdb) record + + which is really just an alias for: + + (gdb) target record-full + + Nowhere does cmd_record_start (which is called when 'record' is used) + expect a filename, and 'target record-full' doesn't expect a filename + either. + + So lets just drop the line which sets filename_completer as the + completer for 'record'. + + Approved-By: Tom Tromey + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require DW_LNE_end_sequence + The dwarf standard requires that every line number program sequence ends + with a DW_LNE_end_sequence instruction. + + Enforce this in the dwarf assembler for the last sequence in a line number + program (we have no means to enforce this for earlier sequences), and fix a + few test-case that don't have it. + + Tested on aarch64-linux. + + PR testsuite/31618 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix end_sequence addresses + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + File name Line number Starting address View Stmt + ... + map-to-same-line.c 54 0x4102ac x + map-to-same-line.c - 0x4102c4 + ... + + Fix this by ending the line table at $main_end. + + Likewise in a few other test-cases, found using: + ... + $ find gdb/testsuite/ -type f \ + | xargs grep -B1 DW_LNE_end_sequence \ + | grep set_address \ + | egrep -v "_end|_len" + ... + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNS_copy + No address update before a DW_LNS_copy might mean an incorrect dwarf + assembly test-case. + + Try to catch such incorrect dwarf assembly test-cases by: + - requiring an explicit address update for each DW_LNS_copy, and + - handling the cases where an update is indeed not needed, by adding + "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNE_end_sequence + With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence + entry with the same address as the line entry before it: + ... + File name Line number Starting address View Stmt + + dw2-epilogue-begin.c 44 0x4101e8 x + dw2-epilogue-begin.c 47 0x4101ec x + dw2-epilogue-begin.c - 0x4101ec + ... + and consequently the line entry is removed by gdb: + ... + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PRO EPI + 0 20 0x00000000004101a8 0x00000000004101a8 Y Y Y + 1 27 0x00000000004101b0 0x00000000004101b0 Y + 2 32 0x00000000004101b8 0x00000000004101b8 Y Y + 3 34 0x00000000004101c0 0x00000000004101c0 Y Y + 4 35 0x00000000004101c8 0x00000000004101c8 Y + 5 40 0x00000000004101d4 0x00000000004101d4 Y Y + 6 44 0x00000000004101e8 0x00000000004101e8 Y + 7 END 0x00000000004101ec 0x00000000004101ec Y + ... + + This is a common mistake in dwarf assembly test-cases. + + Fix this by: + - requiring an address update for each DW_LNE_end_sequence, and + - fixing the test-cases where that triggers an error. + + I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in + this case I worked around it using "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + + PR testsuite/31592 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592 + +2024-04-17 Aditya Vidyadhar Kamath + + Fix max-depth test case for AIX. + In AIX, if in the main program the global variables are unused then the linker optimises + these variables and the dwarf will not have proper address to the same. Hence we cannot access these + variables. + + This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well. + +2024-04-17 Victor Do Nascimento + + aarch64: Remove asserts from operand qualifier decoders [PR31595] + Given that the disassembler should never abort when decoding + (potentially random) data, assertion statements in the + `get_*reg_qualifier_from_value' function family prove problematic. + + Consider the random 32-bit word W, encoded in a data segment and + encountered on execution of `objdump -D '. + + If: + + (W & ~opcode_mask) == valid instruction + + Then before `print_insn_aarch64_word' has a chance to report the + instruction as potentially undefined, an attempt will be made to have + the qualifiers for the instruction's register operands (if any) + decoded. If the relevant bits do not map onto a valid qualifier for + the matched instruction-like word, an abort will be triggered and the + execution of objdump aborted. + + As this scenario is perfectly feasible and, in light of the fact that + objdump must successfully decode all sections of a given object file, + it is not appropriate to assert in this family of functions. + + Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for + handling invalid qualifier-associated values and re-purpose the + assertion conditions in qualifier-retrieving functions to be the + predicate guarding the returning of the calculated qualifier type. + If the predicate fails, we return this new qualifier and allow the + caller to handle the error as appropriate. + + As these functions are called either from within + `aarch64_extract_operand' or `do_special_decoding', both of which are + expected to return non-zero values, it suffices that callers return + zero upon encountering `AARCH64_OPND_QLF_ERR'. + + Ar present the error presented in the hypothetical scenario has been + encountered in `get_sreg_qualifier_from_value', but the change is made + to the whole family to keep the interface consistent. + + Bug: https://sourceware.org/PR31595 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix gdbserver pid in gdb.server/server-kill-python.exp + The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for + remote target") intended to addresss the problem that this command: + ... + set gdbserver_pid [exp_pid -i $server_spawn_id] + ... + does not return the pid of the gdbserver for remote target, but rather the one + of the ssh client session. + + To fix this, it added another way of getting the gdbserver_pid. + + For the trivial case of non-remote target, the PID found by either method + should be identical, but if we compare those by adding + "puts [exec ps -p $gdbserver_pid]" we get: + ... + PID TTY TIME CMD + 31711 pts/8 00:00:00 gdbserver + PID TTY TIME CMD + 31718 pts/8 00:00:00 server-kill-pyt + ... + + The problem is that while the gdbserver PID is supposed to be read from the + result of "gdb.execute ('p server_pid')" in the python script, instead it's + taken from: + ... + Process server-kill-python created; pid = 31718^M + ... + + Fix this by moving the printing of the gdbserver PID out of the python script. + + Also double-check the two methods against each other, in the cases that they + should match. + + Tested on x86_64-linux. + + PR testsuite/31633 + https://sourceware.org/bugzilla/show_bug.cgi?id=31633 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Simplify gdb.server/server-kill-python.exp + In test-case gdb.server/server-kill-python.exp we have: + ... + if {[gdb_spawn_with_cmdline_opts \ + "-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} { + fail "spawn" + return + } + ... + + I reproduced the problem by reverting the fix at the commit adding both the + fix and the test-case, and the reproduced the same problem using: + ... + (gdb) source $host_file1 + ... + so there doesn't seem to be a specific need to source the python file using + "-ex". + + Simplify the test-case by sourcing the python file using send_gdb. + + This also allow us to simplify the python script. + + Tested on x86_64-linux. + +2024-04-17 Hu, Lin1 + + Add W table for USER_MSR under MAP4. + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Modify MOD_EVEX_MAP4_F8_P1, + MOD_EVEX_MAP4_F8_P3. + * i386-dis-evex-w.h (EVEX_W_MAP4_F8_P1_M_1): New. + (EVEX_W_MAP4_F8_P3_M_1): Ditto. + * i386-dis.c (vex_w_table): Add EVEX_W_MAP4_F8_P1_M_1, + EVEX_W_MAP4_F8_P3_M_1. + * i386-opc.tbl: Remove redundant '|'. + +2024-04-17 H.J. Lu + + elf: Skip the archive if the symbol isn't referenced + Also skip the archive if the symbol isn't referenced by a regular object. + + bfd/ + + PR ld/31644 + * elflink.c (elf_link_add_archive_symbols): Also skip the archive + if the symbol isn't referenced by a regular object. + + ld/ + + PR ld/31644 + * testsuite/ld-plugin/lto.exp: Run PR ld/31644 tests. + * testsuite/ld-plugin/pr31644a.c: New test. + * testsuite/ld-plugin/pr31644b.c: Likewise. + * testsuite/ld-plugin/pr31644c.c: Likewise. + +2024-04-17 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Alan Modra + + ARC e_flags vs. objcopy + While the patch that Nick reverted in commit 3f6a060c7543 was in the + source, "FAIL: objcopy executable (pr25662)" was seen on ARC. The + failure was triggered by the .ARC.attributes section being removed by + the linker script. When a file lacking this section is copied by + objcopy, e_flags from the input is copied to the output (in this case + the value 0x406), but arc_elf_final_write_processing then logical-ors + in 0x300 when Tag_ARC_ABI_osver is not found. + + * elf32-arc.c (arc_elf_final_write_processing): Don't ignore + existing e_flags for objcopy. + +2024-04-17 Alan Modra + + libctf warnings + Seen with every compiler I have if using -fno-inline: + home/alan/src/binutils-gdb/libctf/ctf-create.c: In function ‘ctf_add_encoded’: + /home/alan/src/binutils-gdb/libctf/ctf-create.c:555:3: warning: ‘encoding’ may be used uninitialized [-Wmaybe-uninitialized] + 555 | memcpy (dtd->dtd_vlen, &encoding, sizeof (encoding)); + + Seen with gcc-4.9 and probably others at lower optimisation levels: + home/alan/src/binutils-gdb/libctf/ctf-serialize.c: In function 'symtypetab_density': + /home/alan/src/binutils-gdb/libctf/ctf-serialize.c:211:18: warning: 'sym' may be used uninitialized in this function [-Wmaybe-uninitialized] + if (*max < sym->st_symidx) + + Seen with gcc-4.5 and probably others at lower optimisation levels: + /home/alan/src/binutils-gdb/libctf/ctf-types.c:1649:21: warning: 'tp' may be used uninitialized in this function + /home/alan/src/binutils-gdb/libctf/ctf-link.c:765:16: warning: 'parent_i' may be used uninitialized in this function + + Also with gcc-4.5: + In file included from /home/alan/src/binutils-gdb/libctf/ctf-endian.h:25:0, + from /home/alan/src/binutils-gdb/libctf/ctf-archive.c:24: + /home/alan/src/binutils-gdb/libctf/swap.h:70:0: warning: "_Static_assert" redefined + /usr/include/sys/cdefs.h:568:0: note: this is the location of the previous definition + + * swap.h (_Static_assert): Don't define if already defined. + * ctf-serialize.c (symtypetab_density): Merge two + CTF_SYMTYPETAB_FORCE_INDEXED blocks. + * ctf-create.c (ctf_add_encoded): Avoid "encoding" may be used + uninitialized warning. + * ctf-link.c (ctf_link_deduplicating_open_inputs): Avoid + "parent_i" may be used uninitialized warning. + * ctf-types.c (ctf_type_rvisit): Avoid "tp" may be used + uninitialized warning. + +2024-04-16 Tom Tromey + + Avoid cache race in bfd_check_format_matches + Running the gdb test suite with the thread sanitizer enabled shows a + race when bfd_check_format_matches and bfd_cache_close_all are called + simultaneously on different threads. + + This patch fixes this race by having bfd_check_format_matches + temporarily remove the BFD from the file descriptor cache -- leaving + it open while format-checking proceeds. + + In this setup, the BFD client is responsible for closing the BFD again + on the "checking" thread, should that be desired. gdb does this by + calling bfd_cache_close in the relevant worker thread. + + An earlier version of this patch omitted the "possibly_cached" helper + function. However, this ran into crashes in the binutils test suite + involving the archive-checking abort in bfd_cache_lookup_worker. I do + not understand the purpose of this check, so I've simply had the new + function work around it. I couldn't find any comments explaining this + situation, either. I suspect that there may still be races related to + this case, but I don't think I have access to the platforms where gdb + deals with archives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + +2024-04-16 Tom Tromey + + Thread-safety improvements for bfd_check_format_matches + A gdb bug found that bfd_check_format_matches has some data races when + called from multiple threads. + + In particular, it changes the BFD error handler, which is a global. + It also has a local static variable ("in_check_format") that is used + for recursion detection. And, finally, it may emit warnings to the + per-xvec warning array, which is a global. + + This patch removes all the races here. + + The first part of patch is to change _bfd_error_handler to directly + handle the needs of bfd_check_format_matches. This way, the error + handler does not need to be changed. + + This change lets us use the new per-thread global + (error_handler_messages, replacing error_handler_bfd) to also remove + the need for in_check_format -- a single variable suffices. + + Finally, the global per-xvec array is replaced with a new type that + holds the error messages. The outermost such type is stack-allocated + in bfd_check_format_matches. + + I tested this using the binutils test suite. I also built gdb with + thread sanitizer and ran the test case that was noted as failing. + Finally, Alan sent me the test file that caused the addition of the + xvec warning code in the first place, and I confirmed that "nm-new" + has the same behavior on this file both before and after this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + Co-Authored-By: Alan Modra + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/backward-spec-inter-cu.exp + Add another regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/forward-spec-inter-cu.exp + Add a regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Correctly handle DIE parent computations + Tom de Vries pointed out that the combination of sharding, + multi-threading, and per-CU "racing" means that sometimes a cross-CU + DIE reference might not be correctly resolved. However, it's + important to handle this correctly, due to some unfortunate aspects of + DWARF. + + This patch implements this by arranging to preserve each worker's DIE + map through the end of index finalization. The extra data is + discarded when finalization is done. This approach also allows the + parent name resolution to be sharded, by integrating it into the + existing entry finalization loop. + + In an earlier review, I remarked that addrmap couldn't be used here. + However, I was mistaken. A *mutable* addrmap cannot be used, as those + are based on splay trees and restructure the tree even during lookups + (and thus aren't thread-safe). A fixed addrmap, on the other hand, is + just a vector and is thread-safe. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Introduce class parent_map for DIE range map + This changes the DIE range map from a raw addrmap to a custom class. + A new type is used to represent the ranges, in an attempt to gain a + little type safety as well. + + Note that the new code includes a map-of-maps type. This is not used + yet, but will be used in the next patch. + + Co-Authored-By: Tom de Vries + +2024-04-16 Tom Tromey + + Add move operators for addrmap + A subsequent patch needs to move an addrmap. This patch adds the + necessary support. It also changes addrmap_fixed to take a 'const' + addrmap_mutable. This is fine according to the contract of + addrmap_mutable; but it did require a compensating const_cast in the + implementation. + +2024-04-16 Tom Tromey + + Change handling of DW_TAG_enumeration_type in DWARF scanner + Currently the DWARF scanner will enter enumeration constants into the + same namespace as the DW_TAG_enumeration_type itself. This is the + right thing to do, but the implementation may result in strange + entries being added to the addrmap that maps DIE ranges to entries. + + This came up when debugging an earlier version of this series; and + while I don't think this should impact the current series, it seems + better to clean this up anyway. + + In the new code, rather than pass the "wrong" scope down through + recursive calls to the scanner, the correct scope is always passed, + and then the parent handling is done when creating the enumerator + entry. + +2024-04-16 Tom de Vries + + [gdb/symtab] Refactor condition in scan_attributes + In scan_attributes there's code: + ... + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr + && *parent_entry == nullptr) + ... + else if (*parent_entry == nullptr) + ... + ... + that uses the "*parent_entry == nullptr" condition twice. + + Make this somewhat more readable by factoring out the condition: + ... + if (*parent_entry == nullptr) + { + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr) + ... + else + ... + } + ... + + This also allows us to factor out "form_addr (origin_offset, origin_is_dwz)". + + Tested on x86_64-linux. + +2024-04-16 Nick Clifton + + Fix test for sections with different VMA<->LMA relationships so that it only applies to allocated sections, and only sections in the same segment are checked. + PR 31450 + +2024-04-16 Simon Marchi + + gdb/make-target-delegates.py: don't handle "void" in parse_argtypes + I suppose this was needed when we had `void` in declarations of methods + with no parameters. If so, we no longer need it. There are no changes + in the generated file. + + Change-Id: I0a2b398408aa129634e2d73097a038f7f80db4b4 + Approved-By: John Baldwin + +2024-04-16 Eli Zaretskii + + Remove excess whitespace from doc strings of some commands + I've noticed that doc strings of some commands, like "set cwd" + and "set inferior-tty", have some excess whitespace, which + makes them display with unexpected indentation, at least in a + Windows command prompt window. This patch fixes that. + + * gdb/linux-nat.c (_initialize_linux_nat): + * gdb/riscv-tdep.c (riscv_insn): + * gdb/top.c (quit_force): + * gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace. + +2024-04-16 Nick Clifton + + Remove accidental commit of an experimental change + +2024-04-16 Tom de Vries + + [gdb/python] Throw MemoryError in inferior.read_memory if malloc fails + PR python/31631 reports a gdb internal error when doing: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + utils.c:709: internal-error: virtual memory exhausted. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ... + + Fix this by throwing a python MemoryError, such that we have instead: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + Python Exception : + Error occurred in Python. + (gdb) + ... + + Likewise for DAP. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631 + +2024-04-16 H.J. Lu + + x86: Fix a memory leak in md_assemble + Fix a memory leak in md_assemble where copy may be cleared and may be + the same as copy: + + if (copy && !mnem_suffix) + { + line = copy; + copy = NULL; + no_match: + + * config/tc-i386.c (md_assemble): Properly free the xstrdup + memory. + +2024-04-16 H.J. Lu + + gas: Free unused memory in scfi_ops_cleanup + * scfi.c (scfi_ops_cleanup): Free op->op_data and head. + +2024-04-16 Fangrui Song + + Simplify readelf's RELR relocation display. + +2024-04-16 Nick Clifton + + Gas Doc: Update example of how .altmacro affects the interpretation of macro arguments. + PR 31255 + +2024-04-16 Simon Cook + + Remove debug printout from 9dd918142787246ea7ed53494d9cbc6b51486133 + +2024-04-16 GDB Administrator + + Automatic date update in version.in + +2024-04-15 Tom Tromey + + Fix crash in gdb_rl_callback_handler + commit bdcd50f9 ("Strip trailing newlines from input string") + introduced a crash in eof-exit.exp. This patch fixes the problem by + adding a NULL check in the appropriate spot. + + Regression tested on x86-64 Fedora 38. I'm checking this in. + +2024-04-15 Tom Tromey + + Remove 'copy_names' parameter from add_using_directive + I noticed that add_using_directive's 'copy_names' parameter is only + used by a single caller. This patch removes the parameter and changes + that caller to copy the names itself. I chose to use intern here + since I suspect the names may well be repeated in a given objfile. + + Approved-By: John Baldwin + +2024-04-15 John Baldwin + + gdb: Add Felix Willgerodt as the x86 architecture maintainer + This includes both the i386 and x86-64 architectures. + +2024-04-15 Nick Clifton + + Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments. + PR 31527 + +2024-04-15 Tom Tromey + + Change printf attribute to fix clang build + commit e8cd90f0 ("Rewrite gdb_bfd_error_handler") broke the clang + build. + + The problem here is that print_error_callback isn't marked as being + printf-like, but it calls string_file::vprintf, triggering: + + ../../binutils-gdb/gdb/gdb_bfd.c:1202:18: error: format string is not a string literal [-Werror,-Wformat-nonliteral] + + This patch applies the attribute to this function. + + It also removes the attribute from gdb_bfd_error_handler, because that + function is no longer really printf-like. + +2024-04-15 Vijay Shankar + + When mapping sections to segments ensure that we do not add sections whose VMA->LMA relationship does not match the relationship of earlier sections in the segment. + PR 31540 + +2024-04-15 Tom Tromey + + Avoid complaint warning on mingw + The mingw build currently issues a warning: + + ./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes] + + This patch fixes the problem as suggested by Simon: + + https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html + + ...that is, by changing the warning interceptor to a class with a + single 'warn' method. + + Approved-By: Simon Marchi + +2024-04-15 Tom Tromey + + Strip trailing newlines from input string + A co-worker noticed a strange situation where "target remote" would + fail due to a trailing newline in the address part of the command. + Eventually he tracked this down to the fact that he was pasting the + command into the terminal, and due to bracketed paste mode, the + newline was being preserved by readline. + + It seems to me that we basically never want a trailing newline on a + gdb command, so this patch removes it when handling the readline + result. + + Co-Authored-By: Kévin Le Gouguec + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-15 Christophe Lyon + + gprofng: Fix dvi documentation build rule + This patch fixes 'install-dvi'. + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix confusion with c.jal vs. c.addiw + There was apparently a confusion which cpu model uses + compressed JAL and which ADDIW. Fixed that in execute_c, + case MATCH_C_JAL | MATCH_C_ADDIW. + + Fixes 3224e32fb84f ("sim: riscv: Add support for compressed integer instructions") + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Make stack 16-byte aligned + Various gcc test cases fail due to the stack + alignment of 16 bytes is expected by gcc, + causing issues mostly with vararg functions, + e.g. + + FAIL: gcc.c-torture/execute/nest-align-1.c -O0 execution test + FAIL: gcc.c-torture/execute/nest-stdar-1.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-12.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-15.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-16.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-17.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-20.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-26.c -O0 execution test + ... + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix PC at gdb breakpoints + The uncompressed EBREAK instruction does not work + correctly this way, and the comment saying that + GDB expects us to step over EBREAK is just wrong. + The PC was always 4 bytes too high, which skips one + instruction at break and step over commands, and + causes complete chaos. The compressed EBREAK was + already implemented correctly. + + Tested by using gdb's "target sim" and single-stepping. + + Approved-By: Andrew Burgess + +2024-04-15 Lulu Cai + + LoongArch: ld:Report an error when seeing an unrecognized relocation + If we generate an object file using an assembler with the new + relocations added, and then linking those files with an older + linker, the link will still complete and the linked file will + be generated. + In this case we should report an error instead of continuing + the linking process. + +2024-04-15 GDB Administrator + + Automatic date update in version.in + +2024-04-14 GDB Administrator + + Automatic date update in version.in + +2024-04-13 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Pedro Alves + + Fix setting watchpoints when current thread is running + Currently, when the current thread is running, you can print global + variables. However, if you try to set a watchpoint on the same + globals, GDB errors out, complaining that the selected thread is + running. Like so: + + (gdb) c& + Continuing. + (gdb) p global + $1 = 1098377287 + (gdb) watch global + Selected thread is running. + + This patch makes setting the watchpoint work. You'll now get: + + (gdb) c& + Continuing. + (gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)] + [New Thread 0x7ffff756d640 (LWP 434994)] + p global + $1 = 88168 + (gdb) watch global + Hardware watchpoint 2: global + (gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)] + + Thread 2 "function0" hit Hardware watchpoint 2: global + + Old value = 185420 + New value = 185423 + int_return () at threads.c:39 + 39 } + + The problem is that update_watchpoint calls get_selected_frame + unconditionally. We can skip it if the watchpoint expression is only + watching globals. + + This adds a testcase that exercises both all-stop and non-stop, and + also software and hardware watchpoints. It is kfailed for software + watchpoints, as those require another fix not handled by this patch + (the sw watchpoint doesn't fire because GDB doesn't force the + running-free thread to switch to single-stepping). + + Change-Id: I68ca948541aea3edd4f70741f272f543187abe40 + +2024-04-12 Pedro Alves + + New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) + Add a new testcase for exercising attaching to a process after its + main thread has exited. + + This is not possible on Linux, the kernel does not allow attaching to + a zombie task, so the test is kfailed there. It is possible however + on Windows at least, and was the scenario addressed by the Windows + backend fix in + https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html, + nowadays PR threads/8153, back in 2003. + + Passes cleanly on Cygwin. + KFAILed on GNU/Linux native and gdbserver. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555 + Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b + +2024-04-12 Pedro Alves + + Cygwin/testsuite: Avoid infinite hang + On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp + testcase hits a sequence of cascading FAILs: + + (gdb) run + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 12672.0x318c] + [New Thread 12672.0x2844] + [New Thread 12672.0x714] + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout) + frame + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout) + list + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout) + + And the test program never makes progress. + + ... and at this point, Cygwin is completely stuck. I can't run any + other Cygwin program. + + However, if we run the test program outside DejaGnu, we see something + different: + + (gdb) b add + Function "add" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (add) pending. + (gdb) r + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 10968.0x834] + [New Thread 10968.0x29a4] + [New Thread 10968.0x16b8] + [New Thread 10968.0xf9c] + [Switching to Thread 10968.0x16b8] + + Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 ) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304 + 1304 se = sigs + pack.si.si_signo; + (gdb) + + Ah, the test wanted to run to a global "add" function, but managed to + stop at an internal Cygwin method called "add". And stopping there + deadlocks everything Cygwin in the system. (I believe some + cygwin1.dll mechanisms use cross-process synchronization or + communication, we're probably blocking something like that.) + + Fix this by using "break -q". The tests FAIL because we don't support + follow-fork for Cygwin, but at least we no longer deadlock the + machine. + + Approved-by: Kevin Buettner + Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9 + +2024-04-12 Andrew Burgess + + gdb/data-directory: silence output from mkinstalldirs script + After my recent changes the data-directory build now uses + silent-rules.mk to reduce the output. + + One problem that remains was the use of mkinstalldirs by stamp-python + and stamp-guile for creating some directories, the mkinstalldirs + prints some messages, so we're left with output like this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I was looking at adding a --silent option to the mkinstalldirs script, + however, when I took a look at the automake package (which is where + mkinstalldirs comes from) it turns out that mkinstalldirs is + deprecated, at the advice is to use 'install-sh -d' instead. + + Just like we carry mkinstalldirs in the top-level directory, we also + carry install-sh, and a version of install-sh which supports the -d + flag. + + And best of all, 'install-sh -d' doesn't appear to print any of the + information messages to stdout that mkinstalldirs does, so if we + switch to use that, we get a quieter build. + + There should be no changes in what is built after this commit + + Approved-By: Tom Tromey + +2024-04-12 Nick Clifton + + Update description of macro keyword argument assignment in assembler documentation. + PR 31255 + +2024-04-12 H.J. Lu + + gas: Fix memory leaks in gen-sframe.c + * gen-sframe.c (sframe_xlate_ctx_cleanup): Call XDELETE on + xlate_ctx->cur_fre. + (create_sframe_all): Call XDELETE on xlate_ctx after use. + +2024-04-12 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Alan Modra + + Re: Fix null pointer dereference in process_debug_info() + read_bases has a potential null-pointer deref too, and without a + debug_info_p there isn't any point in calling read_bases. + + * dwarf.c (process_debug_info): Don't call read_bases when + debug_info_p is NULL. + +2024-04-11 Nick Clifton + + Improve readelf's display of RELR relocs. + + Add -j/--display-section option to readelf. + +2024-04-11 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang + When running test-case gdb.threads/access-mem-running-thread-exit.exp with + clang, we run into: + ... + (gdb) print global_var = 555^M + No symbol "global_var" in current context.^M + (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \ + access mem (write to global_var, inf=2, iter=1) + ... + + The problem is that clang removes the unused variable. + + Fix this in the same way as done in commit b4f767131f7 + ("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the + variable. + + Tested on x86_64-linux with gcc and clang. + +2024-04-11 H.J. Lu + + gas: Fix a CFI label name memory leak in scfi.c + CFI label name can be freed only after use. + + * scfi.c (handle_scfi_dot_cfi): Free CFI label name after use. + * scfidw2gen.c (scfi_process_cfi_label): Add a comment. Remove + TODO on freeing CFI label name. + +2024-04-11 H.J. Lu + + gas: Fix memory leaks in ginsn.c + Free buffer memory after use in ginsn.c. + + * ginsn.c (ginsn_dst_print): Free buffer after use. + (ginsn_print): Likewise. + +2024-04-11 Tankut Baris Aktemur + + gdb: fix format in remote.c + Fix space-before-parenthesis format at three spots in remote.c. + +2024-04-11 Alan Modra + + Remove bfdwin.c + In commit b86d3af60ffc and 0ab0435fe672 I fixed SIGBUS errors found by + oss-fuzz now that --with-mmap defaults to enabled. It turns out there + are further problems with the aout mmap code: aout_read_minisymbols + returns the external symbol array, which is later freed by nm.c. If + the array is mmaped you can't free it. Now this could be fixed by + making aout minisymbols an array of pointers, but I figure there's not + much point in expending effort on that. So delete the aout mmap + support along with bfdwin.c and get_section_contents_in_window. + +2024-04-11 Alan Modra + + asan: heap buffer overflow elf_link_add_to_first_hash + Seen on mmix. + mmix +FAIL: ld-misc/defsym1 + mmix +FAIL: sysroot-prefix common plain -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path, quoted + mmix +FAIL: sysroot-prefix common full-path, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, unquoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, unquoted + + ==3746597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070000007a0 at pc 0x56d87b0d1a40 bp 0x7fffb1629bf0 sp 0x7fffb1629be0 + READ of size 8 at 0x6070000007a0 thread T0 + #0 0x56d87b0d1a3f in elf_link_add_to_first_hash /home/alan/src/binutils-gdb/bfd/elflink.c:4312 + + mmix uses bfd_link_generic_hash_table. + + * elflink.c (_bfd_elf_archive_symbol_lookup): Dont use first_hash + unless the hash table is bfd_link_elf_hash_table. + (elf_link_add_archive_symbols): Likewise. + +2024-04-11 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: shift exponent 255 is too large for 64-bit type + + I should have known oss-fuzz wouldn't be satisfied so easily. The pef + format allows quite silly section alignments in object files. + + * objcopy.c (setup_section): Limit shift exponent when checking + vma and lma for alignment. + +2024-04-11 H.J. Lu + + x86-64: Use long NOPs for Intel Core processors + Use long NOPs for Intel Core processors since they are faster than + multiple NOPs. Don't use them for 64-bit processors by default since + Intel Atom processors can only decode 4 prefixes in 1 cycle. + + * config/tc-i386.c (alt64_9): New. + (alt64_10): Likewise. + (alt64_11): Likewise. + (alt64_12): Likewise. + (alt64_13): Likewise. + (alt64_14): Likewise. + (alt64_15): Likewise. + (alt64_patt): Likewise. + (i386_generate_nops): Use alt64_patt for Intel Core processors + in 64-bit mode. + * testsuite/gas/i386/x86-64-nops-1-core2.d: Expect long NOPs. + * testsuite/gas/i386/x86-64-nops-4-core2.d: Likewise. + * testsuite/gas/i386/ilp32/x86-64-nops-1-core2.d: Replace + ../x86-64-nops-1.d with ../x86-64-nops-1-core2.d. + * testsuite/gas/i386/ilp32/x86-64-nops-4-core2.d: Replace + ../x86-64-nops-4.d with ../x86-64-nops-4-core2.d. + +2024-04-11 H.J. Lu + + mmap: Fix a memory leak in _bfd_mmap_read_temporary + Return malloced memory in *mmap_base so that _bfd_munmap_readonly_temporary + will free it. + + * libbfd.c (_bfd_mmap_read_temporary): Return malloced memory + in *mmap_base. + +2024-04-11 H.J. Lu + + elf: Fix a memory leak in _bfd_elf_add_dynamic_entry + Normally, the section contents is allocated by bfd_alloc which is freed + when the object is closed. But the .dynamic section contents is allocated + by bfd_realloc, which should be freed by calling free. Add a dynamic + field to elf_link_hash_table for the .dynamic section and free its + contents in _bfd_elf_link_hash_table_free. + + * elf-bfd.h (elf_link_hash_table): Add dynamic. + * elflink.c (_bfd_elf_link_create_dynamic_sections): Set the + dynamic field in elf_link_hash_table. + (_bfd_elf_add_dynamic_entry): Use hash_table->dynamic. + (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise. + (bfd_elf_add_dt_needed_tag): Likewise. + (elf_finalize_dynstr): Likewise. + (_bfd_elf_link_hash_table_free): Free htab->dynamic->contents. + (bfd_elf_final_link): Use htab->dynamic. + * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use + htab->elf.dynamic. + +2024-04-11 Alan Modra + + Segfault in _bfd_delete_bfd with USE_MMAP + Any of the calls to _bfd_delete_bfd in bfd_fopen will hit this. + + * opncls.c (_bfd_delete_bfd): Check for non-NULL xvec before + accessing flavour. + +2024-04-11 GDB Administrator + + Automatic date update in version.in + +2024-04-10 Indu Bhagat + + gas: scfi: bugfixes for SCFI state propagation + There are two state propagation functions in SCFI machinery - forward + and backward flow. The patch addresses two issues: + - In forward_flow_scfi_state (), the state being compared in forward flow + must be that at the exit of a prev bb and that at the entry of the + next bb. The variable holding the state to be compared was + previously (erroneously) stale. + - In cmp_scfi_state (), the assumption that two different control + flows, leading to the same basic block, cannot have a mismatched + notion of CFA base register, is not true. Remove the assertion and + instead return err if mismatch. + + Fixing these issues helps correctly synthesize CFI, when previously + SCFI was erroring out for an otherwise valid input asm. + + gas/ + * scfi.c (cmp_scfi_state): Remove assertion and return mismatch + in return value as applicable. + (forward_flow_scfi_state): Update state object to be the same as + the exit state of the prev bb before comparing. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-5.d: New test. + * gas/scfi/x86_64/scfi-cfg-5.l: New test. + * gas/scfi/x86_64/scfi-cfg-5.s: New test. + +2024-04-10 Indu Bhagat + + gas: gcfg: add_bb_at_ginsn must return root_bb + A GCFG (ginsn control flow graph) is created for SCFI purposes in GAS. + The existing GCFG creation process was ignoring some paths. + + add_bb_at_ginsn () is a recursive function which should return the root + of the added basic blocks. This property was being violated in some + traversals, e.g., where a taken path involving a sequence of a few basic + blocks eventually culminated in a GINSN_TYPE_RETURN instruction. This + patch fixes the issue by keeping an explicit variable root_bb to + memorize the bb to be returned. + + Next, find_or_make_bb () must either create or find the bb with the + first ginsn as the provided ginsn. Add a few assertions to ensure + health of the cfg creation process. + + Note that the testcase, in its current shape, is not fit for catching + regressions for the issue at hand. Although the testcase does exercise + the updated code path, the testcase passes even without the current fix, + because the added edge in this specific testcase does not alter the + synthesized CFI. (The missing edge is the fallthrough edge of the + conditional branch "jne .L13" in the testcase.) + + Using a manual gcfg_print (), one can see the missing edge without the + fix. Lets keep the testcase for now, until there is a better way to + test the GCFG for this issue (e.g., either by dumping the GCFG in + textual format, or a case when the missing edge does cause wrong + synthesized CFI). + + gas/ + * ginsn.c (bb_add_edge): Fix a code comment. + (find_bb): Likewise. + (find_or_make_bb): Add new assertions to ensure health of cfg + creation process. + (add_bb_at_ginsn): Keep reference to the root_bb and return it. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-4.d: New test. + * gas/scfi/x86_64/scfi-cfg-4.l: New test. + * gas/scfi/x86_64/scfi-cfg-4.s: New test. + +2024-04-10 Christophe Lyon + + gdb, gdbserver: Add missing install-dvi Makefile target + For some reason install-dvi is missing although other targets of the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + + Fix what looks like another oversight: include 'pdf' in 'all-doc' in + gdb/doc/Makefile.in. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-10 Nick Clifton + + readelf: Add -j/--display-section command line option. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP to avoid the sanitizer + configure check failure. + + bfd/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + binutils/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + ld/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libctf/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libsframe/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid + the sanitizer configure check failure. + + config/ + + * mmap.m4 (GCC_AC_FUNC_MMAP): New. + * no-executables.m4 (AC_FUNC_MMAP): Renamed to GCC_AC_FUNC_MMAP. + Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + + libiberty/ + + * Makefile.in (aclocal_deps): Add $(srcdir)/../config/mmap.m4. + * acinclude.m4: Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + * aclocal.m4: Regenerated. + * configure: Likewise. + + zlib/ + + * acinclude.m4: Include ../config/mmap.m4. + * Makefile.in: Regenerated. + * configure: Likewise. + +2024-04-10 Alan Modra + + Re: ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + Don't use CC_FOR_TARGET in the bootstrap test, a silly idea aiming at + consistency that made things worse. The objects being linked were + built using $CC, so $CC should be used to link. + + * testsuite/ld-bootstrap/bootstrap.exp: Revert last change. + +2024-04-10 GDB Administrator + + Automatic date update in version.in + +2024-04-09 Tom Tromey + + Rewrite gdb_bfd_error_handler + This patch rewrites gdb_bfd_error_handler to use 'bfd_print_error' to + generate the text of the warning, and then emits it using 'warning'. + The current code in the tree is a bit wrong because it may do the + wrong thing when BFD uses ones of its printf extensions. + + This also adds locking to increment_bfd_error_count. This is + important now that some BFD operations can be done on worker threads. + + This approach makes it simpler for worker threads to intercept any + messages. + + Regression tested on x86-64 Fedora 38. + +2024-04-09 Jens Remus + + aarch64: Treat operand "SME list of ZA tiles" as immediate (PR 31561) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + "SME list of ZA tiles" (SME_list_of_64bit_tiles) as immediate. During + assembly it is correctly encoded as immediate value (imm.value) in + parse_operands. During disassembly it is first correctly decoded as + immediate value (imm.value) in aarch64_ext_imm called by + aarch64_extract_operand, but then erroneously treated as register + number (reg.regno) in aarch64_print_operand. + + This resolves the assembler test case "SME extension (ZERO)" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31561 + * aarch64-opc.c: Treat operand "SME list of ZA tiles" as + immediate. + + Bug: https://sourceware.org/PR31561 + Acked-by: Nick Clifton + +2024-04-09 Jens Remus + + s390: Flag conditional branch relative insns as condjump + Flag conditional branch relative (extended) mnemonics clij* and clgij* + as "condjump" for jump visualization in disassembly. They were missed + to be flagged as such in commit c5306fed7d40 ("s390: Support for jump + visualization in disassembly"). + + opcodes/ + * s390-opc.txt: Flag conditional branch relative instructions + clij* and clgij* as condjump for jump visualization in + disassembly. + + Acked-by: Nick Clifton + +2024-04-09 H.J. Lu + + bfd: Define pagesize variables only for mmap + Define _bfd_pagesize, _bfd_pagesize_m1 and _bfd_minimum_mmap_size only + if HAVE_MMAP is defined. + + * libbfd-in.h (_bfd_pagesize): Declare only if HAVE_MMAP is + defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + * libbfd.c (_bfd_pagesize): Define only if HAVE_MMAP is defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Replace _bfd_pagesize with + getpagesize. + +2024-04-09 Alex Coplan + + arm: Fix disassembly of MVE vq[r]shr[u]n + This patch fixes the disassembly of vq[r]shr[u]n insns so that the + shift immediate is properly decoded. See the description of the + previous patch for an example of the incorrect disassembly. + + As part of this patch we also fix the mve-vqrshrn.d test which was + testing for the incorrect disassembly of the immediates. The + disassembly now matches the assembled instructions in that test. + + Finally we add an mve-vqshrn test which tests the non-rounding variants + of those insns, whose encoding we fixed with the previous patch in this + series. + +2024-04-09 Alex Coplan + + arm: Fix encoding of MVE vqshr[u]n + As it stands, these insns are incorrectly encoded as vqrshr[u]n. + Concretely, the problem can be seen as follows: + + $ cat t.s + vqrshrnb.s16 q0,q0,#8 + vqshrnb.s16 q0,q0,#8 + $ gas/as-new t.s -march=armv8.1-m.main+mve -o t.o + $ binutils/objdump -d t.o -m armv8.1-m.main + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <.text>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + + Here we assemble these two instructions to the same opcode. The + encoding of the first is the correct, while the encoding of the second + is incorrect, and the bottom bit should be clear, see the Armv8-M ARM: + https://developer.arm.com/documentation/ddi0553/latest/ + + There is an additional problem here in that the disassembly of the + immediate is incorrect. llvm-objdump shows the correct disassembly + here: + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <$t>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + + Note that we defer adding a test for the correct encoding of these insns + until the next patch which fixes the disassembly issue. + +2024-04-09 Alex Coplan + + arm: Refactor condition for print_mve_shift_n + This is intended to have no functional change, but refactors the + condition guarding the call to print_mve_shift_n in arm-dis.c ahead of a + later patch which adds additional insns to the set of those whose + shift immediate is disassembled using print_mve_shift_n. + +2024-04-09 Jiawei + + RISC-V: Support Zcmp push/pop instructions. + Support zcmp extension push/pop/popret and popret zero instructions. + The `reg_list' is a list containing 1 to 13 registers, we can use: + "{ra}, {ra, s0}, {ra, s0-s1}, {ra, s0-s2} ... {ra, s0-sN}" + to present this feature. + + Passed gcc/binutils regressions of riscv-gnu-toolchain. + + Most of work was finished by Sinan Lin. + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subset): Imply zca for zcmp. + (riscv_supported_std_z_ext): Added zcmp with version 1.0. + (riscv_parse_check_conflicts): Zcmp conflicts with d/zcd. + (riscv_multi_subset_supports): Handle zcmp. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (regno_to_reg_list): New function, used to map + register to reg_list number. + (reglist_lookup): Called reglist_lookup_internal. Return false if + reg_list number is zero, which is an invalid value. + (reglist_lookup_internal): Parse register list, and return the last + register by regno_to_reg_list. + (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zcmp-push-pop-fail.d: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.l: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.s: New test. + * testsuite/gas/riscv/zcmp-push-pop.d: New test. + * testsuite/gas/riscv/zcmp-push-pop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH/MASK_CM_PUSH): New macros for zcmp. + (MATCH/MASK_CM_POP): Ditto. + (MATCH/MASK_CM_POPRET): Ditto. + (MATCH/MASK_CM_POPRETZ): Ditto. + (DECLARE_INSN): New declarations for zcmp. + * opcode/riscv.h (EXTRACT/ENCODE/VALID_ZCMP_SPIMM): Handle spimm + operand for zcmp. + (OP_MASK_REG_LIST): Handle operand for zcmp register list. + (OP_SH_REG_LIST): Ditto. + (ZCMP_SP_ALIGNMENT): New argument, used in riscv_get_sp_base. + (X_S0, X_S1, X_S2, X_S10, X_S11): New register numbers. + (enum riscv_insn_class): Added INSN_CLASS_ZCMP. + (extern riscv_get_sp_base): Added. + + opcodes/ChangeLog: + + * riscv-dis.c (print_reg_list): New function, used to get zcmp + reg_list field. + (riscv_get_spimm): New function, used to get zcmp sp adjustment + immediate. + (print_insn_args): Handle new operands for zcmp. + * riscv-opc.c (riscv_get_sp_base): New function, used by gas and + objdump. Get sp base adjustment. + (riscv_opcodes): Added zcmp instructions. + +2024-04-09 mengqinggang + + LoongArch: ld: Move .got .got.plt before .data and protect .got with relro + Move .got .got.plt before .data so .got can be protected with -zrelro. + And the first two entries of .got.plt (_dl_runtime_resolve and link map) + are placed within the relro region. + +2024-04-09 Hu, Lin1 + + Support {evex} pseudo prefix for decode evex promoted insns without egpr32. + This patch is based on APX NF patch and also adds test cases for Checking 64-bit insns not sizeable through + register operands with evex. + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Added no-egpr testcases for movbe. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Added tests. + * testsuite/gas/i386/noreg64-evex.d: New test. + * testsuite/gas/i386/noreg64-evex.e: Ditto. + * testsuite/gas/i386/noreg64-evex.s: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.d: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %ME to movbe. + * i386-dis.c : Added %XE to evex_from_vex instructions to output {evex}. + (struct dis386): New %ME. + (putop): Handle %ME and output {evex} for evex_from_legacy instructions. + * Return early when the instruction name is (bad). + +2024-04-09 Alan Modra + + Remove dead code in bfdwin.c + All of bfdwin.c is wrapped in USE_MMAP. There isn't any point in + HAVE_MMAP tests inside USE_MMAP. + + * bfdwin.c (bfd_free_window, bfd_get_file_window): Delete + HAVE_MMAP conditionals. + +2024-04-09 Alan Modra + + ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + The idea here is build tests without sanitizer flags, so they don't + fail due to many not using the compiler to link and thus result in + undefined symbols, since libasan is not supplied. We definitely do not + want a compiler to perform linking in most cases, and it's complicated + to supply libasan (and would possibly disturb testcase output). + + * testsuite/config/default.exp (CFLAGS_FOR_TARGET), + (CXXFLAGS_FOR_TARGET): Append NOSANITIZE_CFLAGS. + * testsuite/ld-bootstrap/bootstrap.exp: Use CC_FOR_TARGET and + CFLAGS_FOR_TARGET throughout. + +2024-04-09 GDB Administrator + + Automatic date update in version.in + +2024-04-08 H.J. Lu + + ld: Add PR ld/31615 tests + PR ld/31615 + * testsuite/ld-plugin/lto.exp: Run ld/31615 tests. + * testsuite/ld-plugin/pr31615.ver: New file. + * testsuite/ld-plugin/pr31615a.c: Likewise. + * testsuite/ld-plugin/pr31615b.c: Likewise. + * testsuite/ld-plugin/pr31615c.c: Likewise. + * testsuite/ld-plugin/pr31615d.c: Likewise. + +2024-04-08 Alexandra Hájková + + remote.c: Make packet_ok return struct packet_result + This allows the error message stored in a packet_result to be easily + printed in the calling function. + + Approved-By: Andrew Burgess + +2024-04-08 Alexandra Hájková + + remote.c: Use packet_check_result + when processing the GDBserver reply to qRcmd packet. + Print error message or the error code. + Currently, when qRcmd request returns an error, + GDB just prints: + + Protocol error with Rcmd + + After this change, GDB will also print the error code: + + Protocol error with Rcmd: 01. + + Add an accept_msg argument to packet_check result. qRcmd + request (such as many other packets) does not recognise + "E.msg" form as an error right now. We want to recognise + "E.msg" as an error response only for the packets where + it's documented. + + Also use packet_check result in remote_read_bytes_1. + + Approved-By: Andrew Burgess + +2024-04-08 Andrew Burgess + + gdb/configure: realign the AC_ARG_ENABLE(sim, ....) block + Following the suggestion in this review comment: + + https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca + + this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added + additional [...] quoting in a couple of places, which is inline with + how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac + file. + + There should be no change in how GDB configures or builds after this + commit. + +2024-04-08 Andrew Burgess + + gdb/build: apply silent-rules.mk to the data-directory Makefile.in + This commit makes use of gdb/silent-rules.mk in the data-directory + Makefile.in. I've only updated the rules that actually generate + things, I've not touched the install or uninstall rules, this matches + gdb/Makefile.in. + + I've not managed to completely silence all of the recipe output, the + mkinstalldirs command outputs some diagnostic text which looks like + this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I have a patch for mkinstalldirs that fixes this (by adding a new + --silent command line flag), but that patch needs to be submitted to + automake, then an updated mkinstalldirs sync'd to the gcc repository, + and then copied into the binutils-gdb repository... so I'm leaving + that for a future project. + + Then the guild compiler also emits some diagnostic output, which looks + like this: + + GEN stamp-guile + mkdir -p -- ./guile/. + mkdir -p -- ./guile/gdb + wrote `./gdb.go' + wrote `gdb/experimental.go' + wrote `gdb/iterator.go' + wrote `gdb/printing.go' + wrote `gdb/support.go' + wrote `gdb/types.go' + + The 'wrote' lines are from the guild compiler. The only way to + silence these would be to redirect stdout to /dev/null I think. I did + prototype this, but wasn't 100% convinced about that part of the + patch, so I've decided to leave that for another day. + + I did need to add a new SILENT_ECHO variable to silent-rules.mk, this + is set to a suitable 'echo' command to use within recipes. When we + are in silent mode then I use the 'true' command, while in verbose + mode we actually use 'echo'. + + So, other than the issues outlined above, the output when building the + data-directory is now greatly reduced, and more inline with the output + when building in the gdb/ directory. + + There should be no change in what is actually built after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/configure: use AC_MSG_NOTICE not a direct echo call + After the recent commits, I noticed that GDB's configure script would + still emit two lines even when run in silent mode. If you touch + gdb/Makefile.in and then run 'make all' in the gdb/ build directory + you'll see this: + + GEN config.status + enable_sim = no + enableval = no + + Obviously the 'no' might be 'yes' depending on how you actually + configured GDB. + + This is caused by two direct invocations of 'echo' in GDB's + configure.ac script. + + In this commit I replace these calls with use of AC_MSG_NOTICE + instead. Now when configure is run with the --silent command line + option these lines will not be printed. + + There should be no changes in the built GDB after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: Print 'GEN' message, and pass SILENT_FLAG more + The targets that use config.status to regenerate themselves don't + currently follow the silent rules that the rest of GDB's Makefile + does. For example, touch the gdb/gcore.in file and then 'make all' in + the gdb/ directory prints: + + /bin/sh config.status gcore + config.status: creating gcore + + In this commit I make use of the silent-rules.mk mechanism for these + targets, now we get: + + GEN gcore + + Which matches the rest of our Makefile. Obviously, if you pass 'V=1' + to the build then you'll get the old output back. + + There's no change in what is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add some missing config.status dependencies + I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py, + and gdb-gdb.gdb the rules all use the config.status script, but don't + have a dependency on the config.status target. This means we might + fail to regenerate these targets in a case where config.status, or one + of its dependencies changes. + + Two other targets that use config.status do correctly have a + dependency on config.status. + + Fixed in this commit by adding the missing dependencies. + + There should be no changes in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: rewrite dependencies for config.status target + I noticed something weird, the rule for the config.status target looks + like this: + + config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh + $(SHELL) config.status --recheck + + What bothered me is that 'configure' is specified as being in + $(srcdir), while all of the other files are not, even though those + files are in the same $(srcdir) as the configure script. + + However, I tried touching one of those files, and the config.status + rule does trigger! + + This is thanks to the VPATH variable, which is set to $(srcdir), so + make looks in $(srcdir) for any dependencies. + + However, this inconsistency bothers me. Better, I think, to add the + $(srcdir) prefix to each of these files. + + I also spotted that the configure script also includes the files + ../bfd/config.bfd, yet that is missing from the include list, so in + this commit I plan to add this as a dependency. + + The configure script also pulls in two TCL and TK related files: + + . ${TCL_BIN_DIR}/tclConfig.sh + . ${TK_BIN_DIR}/tkConfig.sh + + However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently + visible in GDB's Makefile, so I'm not planning to add these + dependencies at this time. + + In this commit I add a new variable config_status_deps which holds the + list of all the dependencies for config.status, with the $(srcdir) + prefix included, and then I use this in the config.status rule. + + After this commit config.status will regenerate if config.bfd changes, + which it wouldn't before, but nothing else changes. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add gcore to the 'all' target dependency list + The gcore script is initially generated by the configure process, just + like gdb-gdb.gdb and gdb-gdb.py. However if the gdb/gcore.in input + source is modified then 'make all' in the gdb/ directory does not + regenerate the gcore script. + + This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their + input is updated then 'make all' will regenerate these files. + + The difference is that for gdb-gdb.* there is an explicit dependency + between the 'all' target and the generated file, this dependency is + missing for gcore. + + This commit adds the dependency. Now, if gcore.in is changed, running + 'make all' will regenerate the gcore script. + + There is no change in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Simon Marchi + + gdb: ignore -Wregister instead of -Wdeprecated-register + When building GDB on Centos 7 (which has flex 2.5.37) and Clang, I get: + + $ make ada-exp.o + YACC ada-exp.c + LEX ada-lex.c + CXX ada-exp.o + In file included from /home/smarchi/src/binutils-gdb/gdb/ada-exp.y:1179: + :1106:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] + 1106 | register yy_state_type yy_current_state; + | ^~~~~~~~ + + In ada-lex.l, we already use `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER`, + which for Clang translates to ignoring `-Wdeprecated-register` [1]. I think + that was produced when compiling as C++11, but now that we always compile as + C++17, Clang produces a `-Wregister` error [2]. + + For GCC, `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` already translates to + ignoring `-Wregister`. So, rename + `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` to `DIAGNOSTIC_IGNORE_REGISTER` + and ignore `-Wregister` for Clang too. + + [1] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wdeprecated-register + [2] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wregister + + include/ChangeLog: + + * diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Rename + to... + (DIAGNOSTIC_IGNORE_REGISTER): ... this. Ignore `-Wregister` + instead of `-Wdeprecated-register`. + + Change-Id: I8a4a51c7222c68577fa22ecacdddfcba32d9dbc5 + +2024-04-08 Alan Modra + + Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 + Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be + created, resulting in _bfd_generic_link_add_one_symbol never + returning. Fix that. Note that the MIND case handles two types of + redefinition. For a new indirect symbol we'll have string non-NULL. + For a new def, string will be NULL. So moving the string comparison + earlier would work. However, we've already looked up inh in the first + case so can dispense with name comparisons. Either way, for a new def + we'll get to the defweak test and possibly cycle. Which is what we + want here. + + PR 31615 + PR 26978 + * linker.c (_bfd_generic_link_add_one_symbol ): Test for + exactly matching indirect symbols before cycling on a defweak. + +2024-04-08 GDB Administrator + + Automatic date update in version.in + +2024-04-07 Cui, Lili + + Support APX NF + For the case when NDD and NF are both 0 in evex-promoted format, + we will fully support and test it in another patch. + + gas/ChangeLog: + + * NEWS: Support Intel APX NF. + * config/tc-i386.c (enum i386_error): Add unsupported_nf. + (struct _i386_insn): Add has_nf. + (is_apx_evex_encoding): Ditto. + (build_apx_evex_prefix): Encode the NF bit. + (md_assemble): Handle unsupported_nf. + (parse_insn): Handle Prefix_NF and report bad for illegal combination. + (can_convert_NDD_to_legacy): Replace i.tm.opcode_modifier.nf with i.has_nf. + (match_template): Support D for APX_F insns and check NF support. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add bad test for NF bit. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add apx nf tests. + * testsuite/gas/i386/x86-64-apx-nf-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-nf.d: Ditto. + * testsuite/gas/i386/x86-64-apx-nf.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Add %NF to the instructions that support APX NF and + add new instruction imul, popcnt, tzcnt and lzcnt to EVEX table. + * i386-dis-evex-reg.h: Ditto. + * i386-dis.c (struct instr_info): Add nf. + (struct dis386): Add "NF" for EVEX.NF. + (get_valid_dis386): Set ins->vex.nf and report bad-nf for illegal case. + (print_insn): Handle ins.vex.nf. + (putop): Handle "%NF". + * i386-opc.h (Prefix_NF): New. + * i386-opc.tbl: Added new entries to support full APX NF instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Regenerated. + +2024-04-07 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Call bfd_malloc instead xmalloc + * elflink.c (elf_link_add_object_symbols): Call bfd_malloc + instead of xmalloc. + +2024-04-06 H.J. Lu + + Revert "x86: Restore APX shift-double instructions with omitted shift count" + This reverts commit c2d698fe03a6092d58a07de96068b87836daced0. + + GCC 14 has been changed to use explicit shift count in shift-double + instructions by the commit: + + 06a7e7514af x86: Use explicit shift count in double-precision shifts + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Remove tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Remove APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-06 Alan Modra + + Don't have first_hash entries of strings that can be freed. + Seen running "LTO 1" under valgrind. + ==1443263== Invalid read of size 1 + ==1443263== at 0x484CFE4: strcmp (vg_replace_strmem.c:939) + ==1443263== by 0x56E16C: bfd_hash_lookup (hash.c:564) + ==1443263== by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316) + ==1443263== by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + ==1443263== Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd + ==1443263== at 0x484810F: free (vg_replace_malloc.c:974) + ==1443263== by 0x8D4D87: objalloc_free_block (objalloc.c:248) + ==1443263== by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + + PR ld/31482 + PR ld/31489 + * elflink.c (elf_link_add_to_first_hash): Add "copy" param. + (elf_link_add_object_symbols): Flag that name must be copied + when appending version string to symbol name. + +2024-04-06 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Use elf_link_first_hash_entry for first_hash + Add elf_link_first_hash_entry and use it for first_hash. Free first_hash + before freeing the main hash table. + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Change first_hash to + bfd_hash_table. + * elflink.c (elf_link_first_hash_entry): New. + (elf_link_first_hash_newfunc): Likewise. + (elf_link_add_to_first_hash): Updated. + (elf_link_add_object_symbols): Initialize first_hash with + elf_link_first_hash_newfunc. + (elf_link_add_object_symbols): Updated. + (elf_link_add_archive_symbols): Likewise. + (_bfd_elf_link_hash_table_free): Free first_hash before freeing + the main hash table. + +2024-04-05 H.J. Lu + + elf: Always honor the first definition in shared object and archive + GCC doesn't put builtin function symbol references, which are defined in + the shared C library, in the IR symbol table. When linker rescans shared + objects and archives for newly added symbol references generated from the + IR inputs, it skips definitions of the builtin functions in shared + objects and archives. + + Add first_hash to elf_link_hash_table to track unreferenced definitions + defined first in shared objects and archives. Always use them to resolve + any references. + + bfd/ + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Add first_hash. + * elflink.c (elf_link_add_to_first_hash): New function. + (elf_link_add_object_symbols): Initialize first_hash for an IR + input. Always use the first definition in shared object. Add + the first unreferenced dynamic definition to first_hash. + (_bfd_elf_archive_symbol_lookup): Add the first unreferenced + definition to first_hash.. + (elf_link_add_archive_symbols): Use the symbol definition in + archive if symbol is defined first in this archive. + (_bfd_elf_link_hash_table_free): Also free first_hash. + + ld/ + + PR ld/31482 + PR ld/31489 + * testsuite/ld-plugin/lto.exp: Add PR ld/31482 and PR ld/31489 + tests. + * testsuite/ld-elf/pr31482a-no-lto.c: New file. + * testsuite/ld-elf/pr31482b-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482c-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482d-no-lto.c: Likewise. + * testsuite/ld-plugin/pass1.out: Likewise. + * testsuite/ld-plugin/pr31482a.c: Likewise. + * testsuite/ld-plugin/pr31482b.c: Likewise. + * testsuite/ld-plugin/pr31482c.c: Likewise. + +2024-04-05 Zhiqing Xiong + + Add support for Windows network paths to the UNC support in _bfd_real_open(). + PR 31527 + +2024-04-05 Christophe Lyon + + Add missing install-dvi and install-ps Makefie targets. + For some reason, these targets are missing although others from the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + +2024-04-05 H.J. Lu + + bfd: Munmap readonly memory after bfd_free_cached_info + Munmap readonly memory after bfd_free_cached_info which may use munmapped + readonly memory. + + PR ld/31608 + * opncls.c (_bfd_delete_bfd): Munmap readonly memory after + bfd_free_cached_info. + +2024-04-05 GDB Administrator + + Automatic date update in version.in + +2024-04-04 H.J. Lu + + bfd_mmap_local: Check offset and size + Update bfd_mmap_local to return NULL if filesize < offset or filesize - + offset < rsize. + + * libbfd.c (bfd_mmap_local): Validate offset and size against + the file size. + +2024-04-04 H.J. Lu + + bfd: Handle bmmap failure in _bfd_mmap_read_temporary + iovec->bmmap may return MAP_FAILED, which happens in GDB on objects with + iovec == opncls_iovec. Update _bfd_mmap_read_temporary to handle + iovec->bmmap failure. + + * libbfd.c (_bfd_mmap_read_temporary): Handle iovec->bmmap + failure. + +2024-04-04 H.J. Lu + + x86: Restore APX shift-double instructions with omitted shift count + Restore APX shift-double instructions with omitted shift count since + they are generated by GCC as shown in: + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Add tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Restore APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-04 Tom Tromey + + Add flake8 and isort to .pre-commit-config.yaml + This adds flake8 and isort to .pre-commit-config.yaml. This way, they + will automatically be run on commit. + + I chose the most recent available versions after verifying that they + don't cause any reports or changes in the current tree. + + Internally at AdaCore, we also use a few flake8 plugins as well, so + perhaps that's another avenue for investigation. + + v2: Also update the various file-selection clauses to pick up + gdb-gdb.py.in; include the isort change made to this file; and finally + add a comment about the exclusions from flake8. + + Approved-By: Simon Marchi + +2024-04-04 Bernd Edlinger + + Fix a test failure in gdb.threads/stepi-over-clone.exp + When the XML support was disabled at compile time, + the test case gdb.threads/stepi-over-clone.exp fails + with lots of time-outs, which can be annoying. + This makes the test case unsupported instead. + + Approved-By: Tom Tromey + +2024-04-04 Alan Modra + + MIPS HI16 and LO16 reloc howtos + All the HI16 reloc howtos should have a rightshift of 16, and all the + LO16 relocs shouldn't complain on overflow. This was correct for + R_MIPS_LO16 and R_MIPS_LO16 (at least on the howto_table_rel entries), + and corresponding MIPS16, MICROMIPS and MIPS64 relocs, but not on many + other HI16 and LO16 relocs. + + While we're at it, fix the HIGHER and HIGHEST rightshift too. + + These changes are necessary to support addends outside the range + [0,32767] when those addends are stored in section contents. Note + that some of the reloc howtos changed here will always have zero + addends (GOT_HI16, CALL_HI16). Those don't really need changing, but + use what is clearly correct for hi16 relocs anyway. + + PR 19977 + * elf32-mips.c: Correct rightshift for HI16, HIGHER and HIGHEST + reloc howtos. Correct complain_on_overflow for LO16 relocs. + * elf64-mips.c: Likewise. + * elfn32-mips.c: Likewise. + +2024-04-04 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: left shift of 1 by 31 places cannot be represented in type 'int' + + * objcopy.c (setup_section): Avoid undefined behaviour when + checking vma and lma for alignment. + +2024-04-04 Nandakumar Edamana + + dlltool: replace unchecked malloc with xmalloc + +2024-04-04 Alan Modra + + Memory corruption with USE_MMAP + mips64-linux-gnuabi64 +FAIL: GOT page 4 (two files) + mipsel-linux-gnu +FAIL: GOT page 4 (two files) + mipsisa32el-linux-gnu +FAIL: GOT page 4 (two files) + mips-linux-gnu +FAIL: GOT page 4 (two files) + powerpc64-freebsd +FAIL: relocatable relaxing large + powerpc64le-linux-gnu +FAIL: relocatable relaxing large + powerpc64-linux-gnu +FAIL: relocatable relaxing large + powerpc-eabisim +FAIL: relocatable relaxing large + powerpc-eabivle +FAIL: relocatable relaxing large + powerpc-freebsd +FAIL: relocatable relaxing large + powerpcle-elf +FAIL: relocatable relaxing large + powerpc-linux-gnu +FAIL: relocatable relaxing large + + * elflink.c (bfd_elf_final_link): Heed bed->use_mmap when + sizing buffers, not just USE_MMAP. + +2024-04-04 Alan Modra + + Re: USE_MMAP fuzzed object file attacks + I committed a broken patch. + + * aoutx.h (aout_get_external_symbols): Remove wrong #else and + unneeded casts. + * pdp11.c (aout_get_external_symbols): Likewise. + +2024-04-04 Alan Modra + + Fix uninitialised variable errors + Commit c6291d749aec introduced a number of errors, found by clang. + + elf.c:456:7: error: variable 'alloc_ext_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (_bfd_mul_overflow (symcount, extsym_size, &amt)) + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elf.c:464:7: error: variable 'alloc_extshndx_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (bfd_seek (ibfd, pos, SEEK_SET) != 0 + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:2837:11: error: variable 'alloc1_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (internal_relocs == NULL) + ^~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:12595:16: error: variable 'ext_size' set but not used [-Werror,-Wunused-but-set-variable] + size_t ext_size = 0; + + * elf.c (bfd_elf_get_elf_syms): Fix use of uninitialised variables. + * elflink.c (_bfd_elf_link_info_read_relocs): Likewise. + (bfd_elf_final_link): Fix set but not used warning. + +2024-04-04 Alan Modra + + USE_MMAP fuzzed object file attacks + If mmap is used without sanity checking, then we'll get a SIGBUS if + an access is done to the mmap'd memory corresponding to a page past + end of file. + + * aoutx.h (aout_get_external_symbols): Check that mmap regions + are within file contents. Catch stringsize overflow. + (some_aout_object_p): Don't clear already zeroed fields. Tidy. + * pdp11.c: As for aoutx.h. Copy some fixes too. + +2024-04-04 GDB Administrator + + Automatic date update in version.in + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_link_m[un]map_section_contents + To copy input section contents, add _bfd_elf_link_mmap_section_contents + and _bfd_elf_link_munmap_section_contents to mmap in the input sections. + + * elf-bfd.h (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elf.c (elf_mmap_section_contents): New. + (_bfd_elf_mmap_section_contents): Use it. + (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elflink.c (elf_link_input_bfd): Call + _bfd_elf_link_mmap_section_contents instead of + bfd_get_full_section_contents. Call + _bfd_elf_link_munmap_section_contents to munmap the section + contents. + (bfd_elf_final_link): When mmap is used, initialize + max_contents_size to _bfd_minimum_mmap_size and increase it + for compressed or linker created sections or sections whose + rawsize != size. + +2024-04-03 H.J. Lu + + elf: Always keep symbol table and relocation info for eh_frame + When --no-keep-memory is used, the symbol table and relocation info for + eh_frame are freed after they are retrieved for each text section in the + input object. If an input object has many text sections, the same data + is retrieved and freed many times which can take a very long time. + Update _bfd_elf_gc_mark to keep the symbol table and relocation info for + eh_frame to avoid it. Data to link the 3.5GB clang executable in LLVM + 17 debug build on Linux/x86-64 with 32GB RAM is: + + before after improvement + user 86.31 86.44 -0.2% + system 8.77 8.63 1.6% + total 95.58 96.81 -1.3% + maximum set(GB) 13.1 13.1 0% + page faults 3024752 3028699 -1.3% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.49 5.46 -0.5% + system 0.73 0.73 0% + total 6.26 6.25 0.3% + maximum set(MB) 964 964 0% + page faults 235173 235796 -0.3% + + The memory usage impact is minimum and the link time of the Rust binary + in + + https://sourceware.org/bugzilla/show_bug.cgi?id=31466 + + is reduced from 500+ seconds to 1.44 seconds, a 300x speedup. + + PR ld/31466 + * elflink.c (init_reloc_cookie): Add a bool argument, keep_memory, + for keeping memory. Always keep memory if keep_memory is true. + (init_reloc_cookie_rels): Likewise + (init_reloc_cookie_for_section): Add a bool argument for keeping + memory and pass it to init_reloc_cookie and + init_reloc_cookie_rels. + (_bfd_elf_gc_mark_reloc): Pass false to _bfd_elf_gc_mark. + (_bfd_elf_gc_mark): Pass true to init_reloc_cookie_for_section + for the eh_frame section. Pass false to + init_reloc_cookie_for_section for other sections. + (_bfd_elf_gc_mark_extra_sections): Add Add a bool argument for + keeping memory and pass it to _bfd_elf_gc_mark. + (bfd_elf_parse_eh_frame_entries): Pass false to init_reloc_cookie + and init_reloc_cookie_rels. + (bfd_elf_gc_sections): Pass false to init_reloc_cookie_for_section + and _bfd_elf_gc_mark. + (bfd_elf_discard_info): Pass false to + init_reloc_cookie_for_section and init_reloc_cookie. + +2024-04-03 H.J. Lu + + elf: Don't cache symbol nor relocation tables with mmap + During a "-j 8" LLVM 17 debug build on a machine with 32GB RAM and 16GB + swap, ld was killed by kernel because of out of memory: + + [79437.949336] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-9.scope,task=ld,pid=797431,uid=1000 + [79437.949349] Out of memory: Killed process 797431 (ld) total-vm:9219600kB, anon-rss:6558156kB, file-rss:1792kB, shmem-rss:0kB, UID:1000 pgtables:17552kB oom_score_adj:0 + + Don't cache symbol nor relocation tables if they are mapped in. Data to + link the 3.5GB clang executable in LLVM 17 debug build on Linux/x86-64 + with 32GB RAM is: + + stdio mmap improvement + user 86.73 87.02 -0.3% + system 9.55 9.21 3.6% + total 100.40 97.66 0.7% + maximum set(GB) 17.34 13.14 24% + page faults 4047667 3042877 25% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.41 5.44 -0.5% + system 0.80 0.76 5% + total 6.25 6.26 -0.2% + maximum set(MB) 1323 968 27% + page faults 323451 236371 27% + + These improve the overall system performance for parallel build by + reducing memory usage and page faults. + + Also rename _bfd_link_keep_memory to _bfd_elf_link_keep_memory. Since + the --no-keep-memory linker option causes: + + https://sourceware.org/bugzilla/show_bug.cgi?id=31458 + + this is opt-in by each backend. + + bfd/ + + * elf32-i386.c (elf_i386_scan_relocs): Remove + _bfd_link_keep_memory. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + * elflink.c (_bfd_elf_link_keep_memory): New. + (_bfd_elf_link_iterate_on_relocs): Replace _bfd_link_keep_memory + with _bfd_elf_link_keep_memory. + (elf_link_add_object_symbols): Likewise. + (init_reloc_cookie): Likewise. + (init_reloc_cookie_rels): Likewise. + * libbfd-in.h (_bfd_link_keep_memory): Removed. + * linker.c (_bfd_link_keep_memory): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in symbol and relocation tables + Add _bfd_mmap_read_temporary to mmap in symbol tables and relocations + whose sizes >= 4 * page size. For the final link, allocate an external + relocation buffer of 4 * page size to avoid using mmap and munmap on + smaller relocation sections. Since _bfd_mmap_read_temporary allocates + buffer as needed, its callers don't need to. + + When mmap is used to map in all ELF sections, data to link the 3.5GB + clang executable in LLVM 17 debug build on Linux/x86-64 with 32GB RAM + is: + + stdio mmap improvement + user 84.79 85.27 -0.5% + system 10.95 9.09 17% + total 97.91 94.90 3% + page faults 4837944 4033778 17% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build + is: + + user 5.31 5.33 -0.4% + system 0.86 0.76 12% + total 6.19 6.13 1% + page faults 361273 322491 11% + + * elf.c (bfd_elf_get_elf_syms): Don't allocate buffer for external + symbol table. Replace bfd_read with _bfd_mmap_read_temporary. + * elflink.c (elf_link_read_relocs_from_section): Add 2 arguments + to return mmap memory address and size. + (_bfd_elf_link_info_read_relocs): Don't allocate buffer for + external relocation information. Replace bfd_read with + _bfd_mmap_read_temporary. + (bfd_elf_final_link): Cache external relocations up to + _bfd_minimum_mmap_size bytes when mmap is used. + * libbfd.c (_bfd_mmap_read_temporary): New. + * libbfd-in.h (_bfd_mmap_read_temporary): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_m[un]map_section_contents + Add _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents. + A backend must opt-in to use mmap. It should replace + + bfd_malloc_and_get_section -> _bfd_elf_mmap_section_contents + free -> _bfd_elf_munmap_section_contents + + on section contents. + + * compress.c (bfd_get_full_section_contents): Don't allocate + buffer if mmapped_p is true. + * elf-bfd.h (elf_backend_data): Add use_mmap. + (bfd_elf_section_data): Add contents_addr and contents_size. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. + * elf.c (_bfd_elf_make_section_from_shdr): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_elf_print_private_bfd_data): Likewise. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf32-i386.c (elf_i386_scan_relocs): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + (elf_x86_64_get_synthetic_symtab): Likewise. + * elfcode.h (elf_checksum_contents): Likewise. + * elflink.c (elf_link_add_object_symbols): Likewise. + (bfd_elf_get_bfd_needed_list): Likewise. + * elfxx-target.h (elf_backend_use_mmap): New. + (elfNN_bed): Add elf_backend_use_mmap. + * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_x86_elf_get_synthetic_symtab): Replace free with + _bfd_elf_munmap_section_contents. + * elfxx-x86.h (elf_backend_use_mmap): New. + * libbfd.c: Include "elf-bfd.h". + (_bfd_generic_get_section_contents): Call bfd_mmap_local for + mmapped_p. + * opncls.c (_bfd_delete_bfd): Also munmap ELF section contents. + * section.c (asection): Add mmapped_p. + (BFD_FAKE_SECTION): Updated. + (bfd_malloc_and_get_section): Add a sanity check for not + mmapped_p. + * bfd-in2.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in read-only sections + There are many linker input files in LLVM debug build with huge string + sections. All these string sections can be treated as read-only. But + linker copies all of them into memory which consumes huge amount of + memory and slows down linker significantly. + + Add _bfd_mmap_readonly_persistent and _bfd_mmap_readonly_temporary to + mmap in reado-only sections with size >= 4 * page size. + + NB: All string sections in valid ELF inputs must be null terminated. + There is no need to terminate it again and string sections are mmapped + as read-only. + + * bfd.c (bfd_mmapped_entry): New. + (bfd_mmapped): Likewise. + (bfd): Add mmapped. + * bfdwin.c (bfd_get_file_window): Use _bfd_pagesize. + * cache.c (cache_bmmap): Remove pagesize_m1 and use pagesize_m1 + instead. + * elf.c (bfd_elf_get_str_section): Call + _bfd_mmap_readonly_persistent instead of _bfd_alloc_and_read. + Don't terminate the string section again. + (get_hash_table_data): Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_get_dynamic_symbols): Call _bfd_mmap_readonly_persistent + instead of _bfd_alloc_and_read. Don't terminate the string + section again. Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_slurp_version_tables): Call _bfd_mmap_readonly_temporary + and _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + * elflink.c (bfd_elf_link_record_dynamic_symbol): Use bfd_malloc + to get the unversioned symbol. + * libbfd-in.h (_bfd_pagesize): New. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + * libbfd.c + (bfd_allocate_mmapped_page): New. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_pagesize): Likewise. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Use _bfd_pagesize. + * opncls.c (_bfd_delete_bfd): Munmap tracked mmapped memories. + * sysdep.h (MAP_ANONYMOUS): New. Define if undefined. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-04-03 Lancelot SIX + + Revert "gdb/compile: Use std::filesystem::remove_all in cleanup" + This reverts commit 7bba0ad08576309763e3f41193eaa93025e10b8b. + + Tom de Vries reported that 7bba0ad0857 (gdb/compile: Use + std::filesystem::remove_all in cleanup) broke builds with gcc-7.5.0 + which mostly supports c++17, but not std::filesystem[1]. As this change + is not critical, revert it to maintain compatibility. + + [1] https://inbox.sourceware.org/gdb-patches/a06e6483-aa2e-4b8a-854f-e369a1e961ea@suse.de/ + + Change-Id: I58150bd27600c95052bdf1bbbd6b44718a5a0bbf + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Approved-By: Tom Tromey + +2024-04-03 Tankut Baris Aktemur + + doc: add the missing 'handle' attribute in xml + The XML response to the "qXfer:threads:read" packet may include + a "handle" attribute. The attribute is mentioned in the document + but not shown in the sample XML structure. Add it. + + Reviewed-By: Eli Zaretskii + +2024-04-03 Lancelot SIX + + gdb/compile: Use std::filesystem::remove_all in cleanup + In a previous review, I noticed that some code in gdb/compile/compile.c + could use c++17's `std::filesystem::remove_all` instead of using some + `system ("rm -rf ...");`. + + This patch implements this. + + Note that I use the noexcept overload of std::filesystem::remove_all and + explicitly check for an error code. This means that this code called + during the cleanup procedure cannot throw, and does not risk preventing + other cleanup functions to be called. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Change-Id: If5668bf3e15e66c020e5c3b4fa999f861690e4cf + Approved-By: Tom Tromey + +2024-04-03 Lancelot SIX + + gdb: ensure has dwarf info before reading DWZ file + I recent change (e9b738dfbdc "Avoid race when reading dwz file") moved + the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to + dwarf2_has_info. + + Before that patch, dwarf2_initialize_objfile was only called when + dwarf2_has_info returned true, and since that patch it is always called. + + When reading a file that has no debug info (.debug_info/.debug_abbrev + sections), but has a .gnu_debugaltlink section, GDB’s behavior is + different. I can observe this when loading + /lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging + any program dynamically loading this library). + + Before e9b738dfbdc, we had: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + while after we have: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + + warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3 + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + This patch restores the previous behavior of only trying to load the + DWZ file for objfiles when the main part of the debuginfo is present + (i.e. when dwarf2_has_info returns true). We still make sure that + dwarf2_read_dwz_file is called at most once per objfile. + + A consequence of this change is that the per_bfd->dwz_file optional + object can now remain empty (instead of containing a nullptr), so also + this patch also adjusts dwarf2_get_dwz_file to account for this + possibility. This effectively reverts the changes to + dwarf2_get_dwz_file done by e9b738dfbdc. + + Regression tested on x86_64-linux-gnu Ubuntu 22.04. + + Approved-By: Tom Tromey + +2024-04-03 Nick Clifton + + Fix null pointer dereference in process_debug_info() + + Extend objdump's --show-all-symbols option so that it also shows the extra symbols referenced by an instruction. + +2024-04-03 Jan Beulich + + Arm64: check tied operand specifier in aarch64-gen + Make sure that field actually matches the specified operands. Don't + follow existing F_PSEUDO checking in using assertions, though. Print + meaningful error messages, thus - while not having a line number + available - at least providing some indication of where things are + wrong. + + Fix SVE2.1's extq accordingly, but don't extend the testsuite there: + There are further issues with its operands (SVE_Zm_imm4 doesn't look to + be correct to use there, as that describes an indexed vector register, + while here a separate vector register and immediate operand are to be + specified). + +2024-04-03 Jan Beulich + + x86: add missing No_qSuf to non-64-bit PTWRITE + While largely benign, it still should have been put there when the + original single template was split (commit a04973848dc5). + + x86: drop stray Size64 from WRSSQ + Like for WRUSSQ it's not needed here. The legacy insn had gained it in + the course of zapping Rex64, but that attribute wasn't needed here + either. The APX insn then simply gained it by copy-and-paste, I suppose. + +2024-04-03 Cui, Lili + + x86/APX: Remove KEYLOCKER and SHA promotions from EVEX MAP4 + APX spec removed KEYLOCKER and SHA promotions from EVEX MAP4. + https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html + + gas/ChangeLog: + + * NEWS: Mention that remove KEYLOCKER and SHA promotions from EVEX + * MAP4. + * config/tc-i386.c (process_operands): Removed special handling of + * KEYLOCKER and SHA. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Removed KEYLOCKER + * and SHA instructions. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Removed KEYLOCKER and SHA instructions. + * i386-dis-evex.h: Ditto. + * i386-opc.tbl: Ditto. + * i386-dis.c (print_vector_reg): Removed special handling of KEYLOCKER + * and SHA. + +2024-04-03 GDB Administrator + + Automatic date update in version.in + +2024-04-02 Tom Tromey + + libiberty: Invoke D demangler when --format=auto + Investigating GDB PR d/31580 showed that the libiberty demangler + doesn't automatically demangle D mangled names. However, I think it + should -- like C++ and Rust (new-style), D mangled names are readily + distinguished by the leading "_D", and so the likelihood of confusion + is low. The other non-"auto" cases in this code are Ada (where the + encoded form could more easily be confused by ordinary programs) and + Java (which is long gone, but which also shared the C++ mangling and + thus was just an output style preference). + + This patch also fixed another GDB bug, though of course that part + won't apply to the GCC repository. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276 + + libiberty + * cplus-dem.c (cplus_demangle): Try the D demangler with + "auto" format. + * testsuite/d-demangle-expected: Add --format=auto test. + +2024-04-02 Tom Tromey + + Print type name when printing Rust slice + The recent change to how unsized Rust values are printed included a + small regression from past behavior. Previously, a slice's type would + be printed, like: + + (gdb) print slice + $80 = &[i32] [3] + + The patch changed this to just + + (gdb) print slice + $80 = [3] + + This patch restores the previous behavior. + + Reviewed-By: Simon Marchi + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517 + +2024-04-02 Tom Tromey + + Constify ada-lex.l:attributes + While examining the Ada parser globals with 'nm', I noticed that the + lexer's "attributes" array should be const. This change moves it into + read-only storage. + + Remove "numbuf" global + The lexer has a "numbuf" global that is only used for temporary + storage. This patch removes the global and redeclares it at the + points of use. + + Move "returned_complete" into ada_parse_state + This moves the "returned_complete" global into ada_parse_state. + + Move "paren_depth" into ada_parse_state + This moves the "paren_depth" global into ada_parse_state. + + Move "temp_parse_space" into ada_parse_state + This patch moves the "temp_parse_space" global into ada_parse_state. + It is also renamed to remove the redundant "parse". Finally, it is + changed to an auto_obstack to avoid the need for any manual + management. + + Move "iterated_associations" into ada_parse_state + This patch moves the "iterated_associations" global into + ada_parse_state. + + Move "assignments" global into ada_parse_state + This patch moves the "assignments" global into ada_parse_state. + + Move "components" and "associations" into ada_parse_state + This patch moves the "components" and "associations" globals into + ada_parse_state. + + Move "int_storage" global into ada_parse_state + This patch moves the "int_storage" global into ada_parse_state. + +2024-04-02 Tom Tromey + + Introduce ada_parse_state + This patch introduces the ada_parse_state class and the ada_parser + global. It also changes find_completion_bounds to be a method of this + new type. + + Note that find_completion_bounds never used its parameter; and because + it is generally fine to use the 'pstate' global throughout the parser, + this patch removes the parameter entirely. + +2024-04-02 Tom Tromey + + Implement Ada 2022 iterated assignment + Ada 2022 includes iterated assignment for array initialization. This + patch implements a subset of this for gdb. In particular, only arrays + with integer index types really work -- currently there's no decent + way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during + parsing. Fixing this probably requires the Ada parser to take a + somewhat more sophisticated approach to type resolution; and while + this would help fix another bug in this area, this patch is already + useful without it. + + Introduce and use aggregate_assigner type + This patch is a refactoring to add a new aggregate_assigner type. + This type is passed to Ada aggregate assignment operations in place of + passing a number of separate arguments. This new approach makes it + simpler to change some aspects of aggregate assignment behavior. + +2024-04-02 Tom Tromey + + Run isort + This patch is the result of running 'isort .' in the gdb directory. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Prepare gdb for isort + This patch prepares gdb for isort: it adds a couple of isort marker + comments where needed, and it adds an isort clause to setup.cfg. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Do not use bare "except" + flake8 warns about a bare "except". The docs point out that this will + also catch KeyboardInterrupt and SystemExit exceptions, which is + normally undesirable. Using "except Exception" catches everything + reasonable, so this patch makes this change. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress some "undefined" warnings from flake8 + flake8 warns about some identifiers in __init__.py, because it does + not realize these come from the star-imported _gdb module. This patch + suppresses these warnings. + +2024-04-02 Tom Tromey + + Specify ImportError in styling.py + styling.py has a long try/except surrounding most of the body. flake8 + warns about the final bare "except". However, this except is really + only there to catch the situation where the host doesn't have Pygments + installed. This patch changes this to only catch ImportError. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress star import errors + flake8 warns about the "from _gdb.disassembler import *" line in + disassembler.py, and a similar line from __init__.py. These line are + needed to re-export names from the corresponding C++ module, so this + patch applies the appropriate "noqa" flags. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove bare "except" from disassembler.py + flake8 complains about a bare "except" in disassembler.py. In this + case, the code purports to guard against some kind of user error + involving data structure corruption. I think it's better here to just + let the error occur -- py-disasm.c will show a stack trace in this + case. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove unused import from gdb/__init__.py + flake8 points out that the import of _gdb in gdb/__init__.py is + unused. Remove it. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Ignore unsed import in dap/__init__.py + flake8 warns about dap/__init__.py because it has a number of unused + imports. Most of these are intentional: the import is done to ensure + that the a DAP request is registered with the server object. + + This patch applies a "noqa" comment to these imports, and also removes + one import that is truly unnecessary. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Fix flake8 errors in dap/server.py + Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel") + introduced some errors into dap/server.py. A function is called but + not imported, and the wrong variable name is used. This patch + corrects both errors. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove .flake8 + I re-ran flake8 today and was puzzled to see W503 warnings. + Eventually I found out that the setup.cfg config overrides .flake8. + This patch merges the two and removes .flake8, to avoid future + confusion. + + Approved-By: Simon Marchi + +2024-04-02 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/ctf-ptype.c + On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get: + ... + gdb compile failed, ctf-ptype.c: In function 'main': + ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 242 | v_char_pointer = (char *) malloc (1); + | ^~~~~~ + ctf-ptype.c:1:1: note: include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This test program is part of GDB, the GNU debugger. + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + +2024-04-02 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit target + In an aarch32-linux chroot on an aarch64-linux system, I run into: + ... + (gdb) print x^M + $1 = 9223372036854775807^M + (gdb) FAIL: gdb.ada/verylong.exp: print x + ... + + A passing version on aarch64-linux looks like: + ... + (gdb) print x^M + $1 = 170141183460469231731687303715884105727^M + (gdb) PASS: gdb.ada/verylong.exp: print x + ... + + The difference is caused by the size of the type Long_Long_Long_Integer, which + is: + - a 128-bit signed on 64-bit targets, and + - a 64-bit signed on 32-bit target. + + Fix this by detecting the size of the Long_Long_Long_Integer type, and + handling it. + + Tested on aarch64-linux and aarch32-linux. + + Approved-By: Tom Tromey + + PR testsuite/31574 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574 + + [1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html + +2024-04-02 Nick Clifton + + Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections. Add a check for aligned sections not matching their VMAs. + +2024-04-02 Tom de Vries + + [gdb/tui] Fix centering and highlighting of current line + After starting TUI like this with a hello world a.out: + ... + $ gdb -q a.out -ex start -ex "tui enable" + ... + we get: + ... + ┌─hello.c──────────────────────────────┐ + │ 5 { │ + │ 6 printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + │ │ + └──────────────────────────────────────┘ + ... + + This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main + after resizing"), before which we had instead: + ... + ┌─hello.c──────────────────────────────┐ + │ 4 main (void) │ + │ 5 { │ + │ > 6  printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + └──────────────────────────────────────┘ + ... + + In other words, the problems are: + - the active line (source line 6) is no longer highlighted, and + - the active line is not vertically centered (screen line 2 out 6 instead of + screen line 3 out of 6). + + Fix these problems respectively by: + - in tui_enable, instead of "tui_show_frame_info (0)" using + 'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and + - in tui_source_window_base::rerender, adding centering functionality. + + Tested on aarch64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR tui/31522 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522 + +2024-04-02 H.J. Lu + + PR31458, FAIL: MIPS eh-frame 3 with --no-keep-memory + PR 31458 + bfd/ + * elf-bfd.h (_bfd_elf_link_read_relocs), + (_bfd_elf_link_info_read_relocs): Constify section. + * elflink.c: Likewise. + * elfxx-mips.c (_bfd_mips_elf_eh_frame_address_size): Read + relocs again in case --no-keep-memory. + ld/ + * testsuite/ld-mips-elf/mips-elf.exp: Run --no-keep-memory + version of eh-frame3 test. + +2024-04-02 Alan Modra + + PR 30569, delete _bfd_mips_elf_early_size_sections + PR30569 was triggered by a patch of mine 6540edd52cc0 moving the call + to always_size_sections in bfd_elf_size_dynamic_sections earlier, made + to support the x86 DT_RELR implementation. This broke mips16 code + handling stubs when --export-dynamic is passed to the linker, because + numerous symbols then became dynamic after always_size_sections. The + mips backend fiddles with symbols in its always_size_sections. Maciej + in 902e9fc76a0e had moved the call to always_size_sections to after + the export-dynamic code. Prior to that, Nathan in 04c3a75556c0 moved + it before the exec stack code, back to the start of + bfd_elf_size_dynamic_sections which was where Ian put it originally + in ff12f303355b. So the call has moved around a little. I'm leaving + it where it is, and instead calling mips_elf_check_symbols from + late_size_sections (the old size_dynamic_sections) which is now always + called. In fact, the whole of _bfd_mips_elf_early_size_sections can + be merged into _bfd_mips_elf_late_size_sections. + +2024-04-02 Alan Modra + + PR 30569, always call elf_backend_size_dynamic_sections + This largely mechanical patch is preparation for a followup patch. + + For quite some time I've thought that it would be useful to call + elf_backend_size_dynamic_sections even when no dynamic objects are + seen by the linker. That's what this patch does, with some renaming. + There are no functional changes to the linker, just a move of the + dynobj test in bfd_elf_size_dynamic_sections to target backend + functions, replacing the asserts/aborts already there. No doubt some + of the current always_size_sections functions could be moved to + size_dynamic_sections but I haven't made that change. + + Because both hooks are now always called, I have renamed + always_size_sections to early_size_sections and size_dynamic_sections + to late_size_sections. I condisdered calling late_size_sections plain + size_sections, since this is the usual target dynamic section sizing + hook, but decided that searching the sources for "size_sections" would + then hit early_size_sections and other functions. + +2024-04-02 Alan Modra + + objdump --disassemble=sym peculiarities + Given this testcase: + .text + mov $x1,%eax + f1: + mov $f1,%eax + .type f1,@function + .size f1,.-f1 + + mov $x2,%eax + f2: + mov $f2,%eax + .type f2,@function + .size f2,.-f2+0x1000 #bad size + + objdump --reloc --disassemble=f1 prints + 00000000 : + 0: b8 00 00 00 00 mov $0x0,%eax + + and objdump --reloc --disassemble=f2 prints + 0000000f : + f: b8 0f 00 00 00 mov $0xf,%eax + 10: R_386_32 .text + + It seems for f1 we get the insn before f1 and no reloc whereas, post + 159daa36fa, f2 is disassembled correctly. Some analysis says that + find_symbol_for_address may return a symbol past the current address, + and reloc skipping is broken. Fix both of these problems. + + * objdump.c (disassemble_jumps, disassemble_bytes): Replace + relppp with relpp, ie. don't update caller's rel_pp. Adjust + calls. + (disassemble_section): Skip over relocs inside loop rather + than before loop. Revert 7e538762c2c1. If given a symbol, + don't start disassembling until its address is reached. + Correct end of function calculation. + +2024-04-02 GDB Administrator + + Automatic date update in version.in + +2024-04-02 John David Anglin + + hppa: Implement PA 2.0 symbolic relocations for long displacements + The PA 2.0 architecture introduced several new load and store + instructions with long displacements. These include floating + point loads and stores for word mode, and integer and floating + point loads and stores for double words. Currently, ld does + not correctly support symbolic relocations for these instructions. + + If these are used, ld applies the standard R_PARISC_DPREL14R + relocation and corrupts the instruction. This change uses + bfd_hppa_insn2fmt to determine the correct relocation format. + + We need to check the computed displacement as the immediate + value used in these instruction must be a multiple of 4 or 8 + depending on whether the access is for a word or double word. + + A misaligned offset can potentially occur if the symbol is not + properly aligned or if $global$ (the global pointer) is not + double word aligned. $global$ is provided as a .data section + start symbol. The patch adjusts elf.sc and hppalinux.sh to + align .data to a 8-byte boundary in non-shared and non-pie + links. + + 2024-04-01 John David Anglin + + PR ld/31503 + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Output + + ld/ChangeLog: + + * emulparams/hppalinux.sh (DATA_SECTION_ALIGNMENT): Define. + * scripttempl/elf.sc: Align .data section to DATA_SECTION_ALIGNMENT + when relocating. + +2024-04-01 Alan Modra + + asan: heap-buffer-overflow objdump.c:3299 in disassemble_bytes + Fix yet another crash, this one with a fuzzed function symbol size. + The patch also corrects objdump behaviour when both --disassemble=sym + and --stop-address=value are given. Previously --disassemble=sym + overrode --stop-address, now we take the lower of the stop-address + value and the end of function. + + * objdump.c (disassemble_section): Sanity check ELF st_size. + +2024-04-01 Lulu Cai + + LoongArch: Fix the issue of excessive relocation generated by GD and IE + Currently, whether GD and IE generate dynamic relocation is + determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable. + This results in dynamic relocations still being generated in some + situations where dynamic relocations are not necessary (such as + the undefined weak symbol in static links). + + We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether + GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation, + set need_reloc to true and indx to be a dynamic index. + + At the same time, some test cases were modified to use regular + expression matching instead of complete disassembly matching. + +2024-04-01 mengqinggang + + LoongArch: gas: Ignore .align if it is at the start of a section + Ignore .align if it is at the start of a section and the alignment + can be divided by the section alignment, the section alignment + can ensure this .align has a correct alignment. + +2024-04-01 GDB Administrator + + Automatic date update in version.in + +2024-03-31 Andrew Burgess + + gdb: build dprintf commands just once in code_breakpoint constructor + I noticed in code_breakpoint::code_breakpoint that we are calling + update_dprintf_command_list once for each breakpoint location, when we + really only need to call this once per breakpoint -- the data updated + by this function, the breakpoint command list -- is per breakpoint, + not per breakpoint location. Calling update_dprintf_command_list + multiple times is just wasted effort, there's no per location error + checking, we don't even pass the current location to the function. + + This commit moves the update_dprintf_command_list call outside of the + per-location loop. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: the extra_string in a dprintf breakpoint is never nullptr + Given the changes in the previous couple of commits, this commit + cleans up some of the asserts and 'if' checks related to the + extra_string within a dprintf breakpoint. + + This commit: + + 1. Adds some asserts to update_dprintf_command_list about the + breakpoint type, and that the extra_string is not nullptr, + + 2. Given that we know extra_string is not nullptr (this is enforced + when the breakpoint is created), we can simplify + code_breakpoint::code_breakpoint -- it no longer needs to check for + the extra_string is nullptr case, + + 3. In dprintf_breakpoint::re_set we can remove the assert (this will + be checked within update_dprintf_command_list, we can also remove + the redundant 'if' check. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: change 'if' to gdb_assert in update_dprintf_command_list + I noticed in update_dprintf_command_list that we handle the case where + the bp_dprintf style breakpoint doesn't have a format and args string. + + However, I don't believe such a situation is possible. The obvious + approach certainly already catches this case: + + (gdb) dprintf main + Format string required + + If it is possible to create a dprintf breakpoint without a format and + args string then I think we should be catching this case and handling + it at creation time, rather than having GDB just ignore the situation + later on. + + And so, I propose that we change the 'if' that ignores the case where + the format/args string is empty, and instead assert that we do always + have a format/args string. The original code, that handled an empty + format/args string has existed since commit e7e0cddfb0d4, which is + when dprintf support was added to GDB. + + If I'm correct and this situation can't ever happen then there should + be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: asserts relating to extra_string/parse_extra + The goal of this commit is to better define the API for + create_breakpoint especially around the use of extra_string and + parse_extra. This will be useful in the next commit when I plan to + make some changes to create_breakpoint. + + This commit makes one possibly breaking change: until this commit it + was possible to create thread-specific dprintf breakpoint like this: + + (gdb) dprintf call_me, thread 1 "%s", "hello" + Dprintf 2 at 0x401152: file /tmp/hello.c, line 8. + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 dprintf keep y 0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1 + stop only in thread 1 + printf "%s", "hello" + (gdb) + + This feature of dprintf was not documented, was not tested, and is + slightly different in syntax to how we create thread specific + breakpoints and/or watchpoints -- the thread condition appears after + the first ','. + + I believe that this worked at all was simply by luck. We happen to + pass the parse_extra flag as true from dprintf_command to + create_breakpoint. + + So in this commit I made the choice to change this. We now pass + parse_extra as false from dprintf_command to create_breakpoint. With + this done it is assumed that the only thing in the extra_string is the + dprintf format and arguments. + + Beyond this change I've updated the comment on create_breakpoint in + breakpoint.h, and I've then added some asserts into + create_breakpoint as well as moving around some of the error + handling. + + - We now assert on the incoming argument values, + + - I've moved an error check to sit after the call to + find_condition_and_thread_for_sals, this ensures the extra_string + was parsed correctly, + + In dprintf_command: + + - We now throw an error if there is no format string after the + dprintf location. This error was already being thrown, but was + being caught later in the process. With this change we catch the + missing string earlier, + + - And, as mentioned earlier, we pass parse_extra as false when + calling create_breakpoint, + + In create_tracepoint_from_upload: + + - We now throw an error if the parsed location doesn't completely + consume the addr_str variable. This error has now effectively + moved out of create_breakpoint. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: add asserts and additional comments + This commit extends the asserts on create_breakpoint (in the header + file), and adds some additional assertions into the definition. + + The new assert confirms that when the thread and inferior information + is going to be parsed from the extra_string, then the thread and + inferior arguments should be -1. That is, the caller of + create_breakpoint should not try to create a thread/inferior specific + breakpoint by *both* specifying thread/inferior *and* asking to parse + the extra_string, it's one or the other. + + There should be no user visible changes after this commit. + +2024-03-31 mengqinggang + + BFD: Fix the bug of R_LARCH_AGLIN caused by discard section + To represent the first and third expression of .align, R_LARCH_ALIGN need to + associate with a symbol. We define a local symbol for R_LARCH_AGLIN. + But if the section of the local symbol is discarded, it may result in + a undefined symbol error. + + Instead, we use the section name symbols, and this does not need to + add extra symbols. + + During partial linking (ld -r), if the symbol associated with a relocation is + STT_SECTION type, the addend of relocation needs to add the section output + offset. We prevent it for R_LARCH_ALIGN. + + The elf_backend_data.rela_normal only can set all relocations of a target to + rela_normal. Add a new function is_rela_normal to elf_backend_data, it can + set part of relocations to rela_normal. + +2024-03-31 GDB Administrator + + Automatic date update in version.in + +2024-03-30 Tom Tromey + + Lower variable definitions in tui_redisplay_readline + I noticed a redundant assignment to 'prev_col' in + tui_redisplay_readline, and then went ahead and lowered most of the + variable definitions in that function to their initialization point. + +2024-03-30 GDB Administrator + + Automatic date update in version.in + +2024-03-29 Andrew Burgess + + gdb/testsuite: don't include port numbers in test names + The gdb.python/py-cmd-prompt.exp script includes a test that has a + gdbserver port number within a test name. As port numbers can change + from one test run to the next (depending on what else is running on + the machine at the time), this can make it hard to compare test + results between runs. + + Give the test a specific name to avoid including the port number. + + There is no change in what is tested after this commit. + +2024-03-29 Andrew Burgess + + gdb/testsuite: avoid $pc/$sp values in test names + Provide an explicit name for a test in gdb.base/pc-not-saved.exp to + avoid printing $pc and $sp values in the test name -- these values + might change between different test runs, which makes it harder to + compare test results. + + There is no change in what is actually being tested with this commit. + +2024-03-29 Tom de Vries + + [gdb/testsuite] Add missing includes in gdb.trace/collection.c + On fedora rawhide, with test-case gdb.trace/collection.exp, I get: + ... + gdb compile failed, collection.c: In function 'strings_test_func': + collection.c:227:13: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 227 | longloc = malloc(500); + | ^~~~~~ + collection.c:1:1: note: \ + include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + + collection.c:228:3: error: implicit declaration of function 'strcpy' \ + [-Wimplicit-function-declaration] + 228 | strcpy(longloc, ... ); + | ^~~~~~ + collection.c:1:1: note: include '' or provide a declaration of \ + 'strcpy' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + collection.c:230:8: error: implicit declaration of function 'strlen' \ + [-Wimplicit-function-declaration] + 230 | i += strlen (locstr); + | ^~~~~~ + collection.c:230:8: note: include '' or provide a declaration of \ + 'strlen' + ... + + Fix this by adding the missing includes. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 Tom de Vries + + [gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.c + On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I + get: + ... + gdb compile failed, break-asm-file.c:21:8: error: \ + return type defaults to 'int' [-Wimplicit-int] + 21 | static func() + | ^~~~ + ... + + Fix this by adding the missing return type. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 GDB Administrator + + Automatic date update in version.in + +2024-03-28 Tom Tromey + + Make pascal_language::print_type handle varstring==nullptr + PR gdb/31524 points out a crash when pascal_language::print_type is + called with varstring==nullptr. This crash is a regression arising + from the printf/pager rewrite -- that indirectly removed a NULL check + from gdb's "puts". + + This patch instead fixes the problem by adding a check to print_type. + Passing nullptr here seems to be expected in other places (e.g., there + is a call to type_print like this in expprint.c), and other + implementations of this method (or related helpers) explicitly check + for NULL. + + I didn't write a test case for this because it seemed like overkill + for a Pascal bug that only occurs with -i=mi. However, if you want + one, let me know and I will do it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 + Approved-By: John Baldwin + +2024-03-28 Indu Bhagat + + gas: gcfg: fix handling of non-local direct jmps in gcfg + The ginsn infrastructure in GAS includes the ability to create a GCFG + (ginsn CFG). A GCFG is currently used for SCFI passes. + + This patch fixes the following invalid assumptions / code blocks: + - The function ginsn_direct_local_jump_p () was erroneously _not_ + checking whether the symbol is locally defined (i.e., within the + scope of the code block for which GCFG is desired). Fix the code + to do so. + - Similarly, the GCFG creation code, in gcfg_build () itself had an + assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be + seen. The latter can indeed be seen, and in fact, needs to be treated + the same way as an exit from the function in terms of control-flow. + + gas/ + * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol + is local to the code block or function being assembled. + (add_bb_at_ginsn): Remove buggy assumption. + (frch_ginsn_data_append): Direct jmps do not disqualify a stream + of ginsns from GCFG creation. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cfg-3.d: New test. + * gas/scfi/x86_64/scfi-cfg-3.l: New test. + * gas/scfi/x86_64/scfi-cfg-3.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: move checking + It has always been looking a little odd to me that this was done deep + in cpu_flags_match(). Move it to match_template() itself - there's no + need to do anything complex when encountering such a template while it + cannot possibly be used. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: respect prefixes + 1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to + also do so with -msse2avx, converting to VEX.W. + + 2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2} + shouldn't either. + +2024-03-28 Jan Beulich + + gas: drop integer_constant()'s maxdig + Once properly set, it's only ever holding the same value as "radix". + Even if there was some plan with it, that plan hasn't made it anywhere + in over 20 years. + + gas: drop dead check for double quote + FB and dollar label definitions can't be enclosed in double quotes. In + fact at that point nul_char is the same as next_char, which we know is a + digit. + +2024-03-28 Jan Beulich + + gas: sanitize FB- and dollar-label uses + I don't view it as sensible to be more lax when it comes to references + to (uses of) such labels compared to their definition: The latter has + been limited to decimal numerics, while the former permitted any radix. + Beyond that leading zeroes on such labels aren't helpful either. Imo + labels and their use sites would better match literally, to avoid + confusion. + + As it turns out, one z80 testcase actually had such an odd use of labels + where definition and use don't match in spelling. That testcase is being + adjusted accordingly. + + While there also adjust a comment on a local variable in + integer_constant(). + +2024-03-28 Jan Beulich + + x86: templatize RAO-INT insns + It's only four of them, but still better to reduce redundancy. + + x86: templatize ADX insns + It's only two of them, but still better to reduce redundancy. + +2024-03-28 Jan Beulich + + x86: templatize shift-double insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the shift-double ones. + + While there also drop the APX form with ShiftCount omitted. Other shift + and rotate insns were deliberately left without this form as well. Note + that there's also no testsuite adjustment needed for this, indicating + that the form wasn't tested either. + +2024-03-28 Jan Beulich + + x86: templatize shift/rotate insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the "ordinary" shift and rotate ones. + + While there also drop the APX form of RCL/RCR with Imm1 omitted. Other + shift insns as well as ROR/ROL were deliberately left without this form + as well. Note that there's also no testsuite adjustment needed for this, + indicating that the form wasn't tested either. + + Furthermore since RCL/RCR already had non-NDD APX forms, those end up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize binary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a the more complex binary (two source) cases. + + Note how this adds a missing CheckOperandSize to one of the APX sub + forms. + + Furthermore since SBB already had a non-NDD APX form, one ends up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize unary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a few simple unary (single source) cases. + +2024-03-28 Jan Beulich + + x86: templatize INC/DEC + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Start with the simplest case, accompanied by a necessary adjustment to + i386-gen (such that template uses can also be at the start of a line). + + While there also drop a bogus (meaningless / unreachable) "break" as + well as a unused variable (which I'm surprised compilers didn't warn + about). + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux + On aarch64-linux, using the manjaro linux distro, I run into: + ... + (gdb) next^M + 32 }^M + (gdb) next^M + 0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M + (gdb) FAIL: gdb.base/ending-run.exp: step out of main + ... + + What happens here is described in detail in this clause: + ... + -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" { + # This case occurs on Powerpc when gdb steps out of main and the + # needed debug info files are not loaded on the system, preventing + # GDB to determine which function it reached (__libc_start_call_main). + # Ideally, the target system would have the necessary debugging + # information, but in its absence, GDB's behavior is as expected. + ... + } + ... + but the clause only matches for powerpc. + + Fix this by: + - making the regexp generic enough to also match /usr/lib/libc.so.6, and + - updating the comment to not mention powerpc. + + Tested on aarch64-linux. + + PR testsuite/31450 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux + When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using + the manjaro linux distro, I get: + ... + (gdb) thread apply all bt^M + ^M + Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M + #0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M + #2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M + #3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M + #4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M + #5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M + ^M + Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M + #0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M + #2 0x0000aaaade37086c in main () at attach-stopped.c:45^M + (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt + ... + + The problem is that the test-case expects to see start_thread: + ... + gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \ + "$threadtype: attach2 to stopped bt" + ... + but lack of symbols makes that impossible. + + Fix this by allowing " in ?? () from " as well. + + Tested on aarch64-linux. + + PR testsuite/31451 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/rtld-step.exp + On fedora rawhide, with test-case gdb.base/rtld-step.exp I get: + ... + static-pie-static-libc.c: In function '_start':^M + static-pie-static-libc.c:1:22: error: \ + implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M + 1 | void _start (void) { _exit (0); }^M + | ^~~~~^M + compiler exited with status 1 + ... + UNTESTED: gdb.base/rtld-step.exp: failed to compile \ + (-static-pie not supported or static libc missing) + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + +2024-03-28 Nelson Chu + + RISC-V: Removed privileged spec 1.9.1 support in assembler. + Removed since it's may have lots of conflicts with the newer extensions, but + still keep linker recognizes it in case of linking old objects. + + gas/ + * NEWS: Updated. + * config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as + an unknown version. + (md_show_usage): Removed privileged spec 1.9.1 information. + * testsuite/gas/riscv/attribute-05.s: Updated since privileged spec + 1.9.1 is unsupported. + * testsuite/gas/riscv/attribute-05.d: Likewise. + * testsuite/gas/riscv/attribute-12.d: Likewise. + * testsuite/gas/riscv/attribute-13.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. + * testsuite/gas/riscv/csr.s: Likewise. + * testsuite/gas/riscv/csr-version-1p10.d: Likewise. + * testsuite/gas/riscv/csr-version-1p10.l: Likewise. + * testsuite/gas/riscv/csr-version-1p11.d: Likewise. + * testsuite/gas/riscv/csr-version-1p11.l: Likewise. + * testsuite/gas/riscv/csr-version-1p12.d: Likewise. + * testsuite/gas/riscv/csr-version-1p12.l: Likewise. + * testsuite/gas/riscv/csr-version-1p9p1.d: Removed. + * testsuite/gas/riscv/csr-version-1p9p1.l: Removed. + include/ + * opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is + unsupported. + ld/ + * testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since + privileged spec 1.9.1 is unsupported. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise. + +2024-03-28 GDB Administrator + + Automatic date update in version.in + +2024-03-27 Tom Tromey + + Fix clang build + Simon pointed out that commit 818ef5f4 ("Capture warnings when writing + to the index cache") broke the build with clang. This patch fixes the + breakage. + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: remove includes of early headers + Now that defs.h, server.h and common-defs.h are included via the + `-include` option, it is no longer necessary for source files to include + them. Remove all the inclusions of these files I could find. Update + the generation scripts where relevant. + + Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: include early header files with `-include` + The motivation for this change is for analysis tools and IDEs to be + better at analyzing header files on their own. + + There are some definitions and includes we want to occur at the very + beginning of all translation units. The way we currently do that is by + requiring all source files (.c and .cc files) to include one of defs.h + (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and + shared source files). These special header files define and include + everything that needs to be included at the very beginning. Other + header files are written in a way that assume that these special + "prologue" header files have already been included. + + My problem with that is that my editor (clangd-based) provides a very + bad experience when editing header files. Since clangd doesn't know + that one of defs.h/server.h/common-defs.h was included already, a lot of + things are flagged as errors. For instance, CORE_ADDR is not known. + It's possible to edit the files in this state, but a lot of the power of + the editor is unavailable. + + My proposal to help with this is to include those things we always want + to be there using the compilers' `-include` option. Tom Tromey said + that the current approach might exist because not all compilers used to + have an option like this. But I believe that it's safe to assume they + do today. + + With this change, clangd picks up the -include option from the compile + command, and is able to analyze the header file correctly, as it sees + all that stuff included or defined by that -include option. That works + because when editing a header file, clangd tries to get the compilation + flags from a source file that includes said header file. + + This change is a bit self-serving, because it addresses one of my + frustrations when editing header files, but it might help others too. + I'd be curious to know if others encounter the same kinds of problems + when editing header files. Also, even if the change is not necessary by + any means, I think the solution of using -include for stuff we always + want to be there is more elegant than the current solution. + + Even with this -include flag, many header files currently don't include + what they use, but rather depend on files included before them. This + will still cause errors when editing them, but it should be easily + fixable by adding the appropriate include. There's no rush to do so, as + long as the code still compiles, it's just a convenience thing. + + The changes are: + + - Add the appropriate `-include` option to the various Makefiles. + + - There is one particularity for gdbserver's Makefile: we do not want + to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` + doesn't include it. So we can't simply put the `-include` in + `INTERNAL_CFLAGS`. Add the `-include server.h` option to the + `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule + to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. + + - Remove the `-include` option from the `check-headers` rule in + gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. + + Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + {gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables + Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their + contents in `INTERNAL_CFLAGS`. Not functional changes expected. + + Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line + Reformat some variables definitions. I think it makes them easier to + read, and it also makes diffs clearer. + + Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb: make gdbarch_types.py non-executable + I noticed that gdbarch_types.py is executable. It's not needed, since + it's only imported from gdbarch.py. + + Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e + +2024-03-27 GDB Administrator + + Automatic date update in version.in + +2024-03-26 Andrew Burgess + + Revert "gdbserver: convert have_ptrace_getregset to a tribool" + This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c. + + Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory" + This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354. + + Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description" + This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e. + + Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition" + This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54. + + Revert "gdb/gdbserver: share some code relating to target description creation" + This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd. + + Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32" + This reverts commit efba976d9713a92b4507ccfef2257e4589da2798. + + Revert "gdbserver: update target description creation for x86/linux" + This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a. + + Revert "gdb/gdbserver: share x86/linux tdesc caching" + This reverts commit 198ff6ff819c240545f9fc68b39636fd376d4ba9. + + Revert "gdbserver/Makefile.in: add missing `-x c++`" + This reverts commit c7c9820071f8b81a64221f5cfafb3cbfeafe7916. + + Revert "gdb: fix possible uninitialised variable use" + This reverts commit 24df37a10f8773ad5db07dc000f694d6405e3a36. + + Revert "gdb/gdbserver: fix some defined but unused function warnings" + This reverts commit f4c19f89ef43dbce8065532c808e1aeb05d08994. + +2024-03-26 Tom Tromey + + Remove redundant check from parse_number.exp + A user on irc pointed out that parse_number.exp has a redundant check. + This patch removes the duplicate. + +2024-03-26 Tom de Vries + + [gdb/testsuite] Fix valgrind tests on debian + On debian 12, I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + relaying data between gdb and process 618591^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + (No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M + 0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The problem is that we're expecting to match either of these regexps: + ... + set start_re1 " in \\.?_start " + set start_re2 "\\.?_start \\(\\) at " + ... + but there are no dwarf or elf symbols present. + + Fix this by also allowing: + ... + set start_re3 "$::hex in \\?\\? \\(\\) from " + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-26 Tom Tromey + + Capture warnings when writing to the index cache + PR symtab/30837 points out a race that can occur when writing to the + index cache: a call to ada_encode can cause a warning, which is + forbidden on a worker thread. + + This patch fixes the problem by arranging to capture any such + warnings. + + This is v2 of the patch. It is rebased on top of some other changes + in the same area. v1 was here: + + https://sourceware.org/pipermail/gdb-patches/2024-February/206595.html + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30837 + +2024-03-26 H.J. Lu + + Don't claim a fat IR object if no IR object should be claimed + When the linker sees an input object containing nothing but IR during + rescan, it should ignore it (LTO phase is over). But if the input object + is a fat IR object, which has non-IR code as well, it should be used to + resolve references as if it did not contain any IR at all. This patch + adds lto_type to bfd and linker avoids claiming a fat IR object if no IR + object should be claimed. + + bfd/ + + PR ld/23935 + * archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type + instead of lto_slim_object. + * elflink.c (elf_link_add_object_symbols): Likewise. + * bfd.c (bfd_lto_object_type): New. + (bfd): Remove lto_slim_object and add lto_type. + (bfd_get_lto_type): New function. + * elf.c (lto_section): Removed. + (_bfd_elf_make_section_from_shdr): Don't set lto_slim_object. + * format.c: (lto_section): New. + (bfd_set_lto_type): New function. + (bfd_check_format_matches): Call bfd_set_lto_type. + * bfd-in2.h: Regenerated. + + binutils/ + + PR ld/23935 + * nm.c (display_rel_file): Check bfd_get_lto_type instead of + lto_slim_object. + + ld/ + + PR ld/23935 + * ldmain.c (add_archive_element): Don't claim a fat IR object if + no IR object should be claimed. + * testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test. + Add PR ld/23935 test. + * testsuite/ld-plugin/pr23935a.c: New file. + * testsuite/ld-plugin/pr23935b.c: Likewise. + +2024-03-26 Andrew Burgess + + gdb/gdbserver: fix some defined but unused function warnings + This commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + added some functions which are always defined, but their use is + guarded within various #ifdef blocks. As a result we were seeing + errors about defined, but unused, functions. + + I've fixed this problem in this commit by wrapping the function + definitions within #ifdef blocks. + + I'm a little worried that there might be too many #ifdef blocks within + this file, however, I'm going to commit this fix for now as this will + fix the build, then I'll think about if there's a better way to split + this file so we might avoid some of these #ifdef blocks. + +2024-03-26 Andrew Burgess + + gdb: fix possible uninitialised variable use + After this commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + a possible use of an uninitialised variable was introduced, the + 'tdesc' variable in i386_linux_core_read_description might be read + without being written too if 'xcr0' was 0. + + This is fixed in this commit. I've updated the function to follow the + same pattern as amd64_linux_core_read_description, if xcr0 is 0 then + we select a default xcr0 value and use that to select a tdesc. + +2024-03-26 Simon Marchi + + gdbserver/Makefile.in: add missing `-x c++` + When building with Clang, I get: + + CXX nat/x86-linux-tdesc-ipa.o + clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated] + + Fix that by adding the missing `-x c++` in the rule building + `gdb/nat/*.c` files for the in-process agent. + + Change-Id: Ie53e4b9a8b57bef9669397fdfaf21617107c7180 + Approved-By: Tom Tromey + +2024-03-26 Simon Marchi + + gdb: mark addrmap classes `final` + When building GDB with clang, I see: + + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non + -abstract-non-virtual-dtor] + 95 | delete __ptr; + | ^ + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete::operator()' requested here + 396 | get_deleter()(std::move(__ptr)); + | ^ + /home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr::~unique_ptr' requested here + 422 | auto map = std::make_unique (); + | ^ + + Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too + while at it. + + Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526 + Approved-By: Tom Tromey + +2024-03-26 GDB Administrator + + Automatic date update in version.in + +2024-03-25 Vladimir Mezentsev + + gprofng: fix infinite recursion on calloc with multi-threaded applications + libcollector uses pthread_getspecific() and pthread_setspecific() to access + thread local memory. libcollector uses this memory to check that + interposed functions (like malloc, calloc or free) don't have recursion. + The first time we call calloc(), we call pthread_setspecific() to create + a thread-specific value. + On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept + such recursion. + gcc supports thread-local storage. For example, + static __thread int reentrance = 0; + I rewrote code using this instead of pthread_setspecific(). + + gprofng/ChangeLog + 2024-03-23 Vladimir Mezentsev + + PR gprofng/31460 + * libcollector/heaptrace.c: Use the __thread variable to check for + * reentry. Clean up code. + +2024-03-25 Pedro Alves + + gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode + Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all + test programs. When running the testsuite in parallel mode, on + Cygwin, I noticed errors like: + + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied + + (Absolute paths elided above.) + + The problem is that gdb_compile's unbuffered_mode_obj cache isn't + parallel safe. This is fixed in this commit. + + Reviewed-by: Kevin Buettner + Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2 + +2024-03-25 Pedro Alves + + Fix windows_nat_target::fake_create_process ptid + While working on Windows non-stop mode, I managed to introduce a bug + that led to fake_create_process being called. That then resulted in + GDB crashes later on, because fake_create_process added a thread with + an incorrect ptid for this target. It is putting dwThreadId in the + tid field of the ptid instead of on the lwp field. This is fixed by + this patch. + + Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215 + +2024-03-25 Andrew Burgess + + bfd: make _bfd_section_size_insane part of the public API + If a BFD user is making use of a function like + bfd_get_section_contents to read a section into a pre-allocated + buffer, then that BFD user might also want to make use of + _bfd_section_size_insane prior to allocating the buffer they intend to + use in order to validate that the buffer size that plan to allocate is + sane. + + This commit makes _bfd_section_size_insane public, by renaming it to + bfd_section_size_insane. + + I've updated the existing uses within bfd/, I don't believe this + function is used outside of bfd/ currently. + + One place that I plan to make use of this function is in + gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents. + This change isn't included in this commit, but will come later if/when + this has been merged into bfd. + + There should be no change in behaviour after this commit. + + bfd/ + + * bfd-in2.h (bfd_section_size_insane): Add declaration. + * compress.c (bfd_get_full_section_contents): Update for new name + of _bfd_section_size_insane. + (bfd_init_section_compress_status): Likewise. + * dwarf2.c (read_section): Likewise. + (_bfd_dwarf2_slurp_debug_info): Likewise. + * libbfd.h (_bfd_section_size_insane): Remove declaration. + * section.c (_bfd_section_size_insane): Rename to ... + (bfd_section_size_insane): ... this. + + binutils/ + + * readelf.c (uncompress_section_contents): Update comment to + account for new name of _bfd_section_size_insane. + +2024-03-25 Andrew Burgess + + gdb: move more completion setup into completer.c + Move more setup of the readline global state relating to tab + completion into completer.c out of top.c. + + Lots of the readline setup is done in init_main (top.c). This commit + moves those bits of initialisation that relate to completion, and + which are only set the one time, into completer.c. This does mean + that readline initialisation is now done in multiple locations, some + in init_main (top.c) and some in completer.c, but I think this is OK. + The work done in init_main is the general readline setup. + + I think making static what can be made static, and having it all in + one file, makes things easier to reason about. So I'm OK with having + this split initialisation. + + The only completion related thing which is still setup in top.c is + rl_completion_display_matches_hook. I've left this where it is for + now as rl_completion_display_matches_hook is also updated in the tui + code, and the display hook functions are not in completer.c anyway, so + moving this initialisation to completer.c would not allow anything + else to be made static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb/completion: make completion_find_completion_word static + I noticed that completion_find_completion_word is only used within + completer.c, so lets make it static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove special case completion word handling for filenames + This commit removes some code which is special casing the filename + completion logic. The code in question relates to finding the + beginning of the completion word and was first introduced, or modified + into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001). + + The code being removed moved the start of the completion word backward + until a character in gdb_completer_file_name_break_characters was + found, or until we reached the end of the actual command. + + However, I doubt that this is needed any more. The filename completer + has a corresponding filename_completer_handle_brkchars function which + provides gdb_completer_file_name_break_characters as the word break + characters to readline, and also sets rl_completer_quote_characters. + As such, I would expect readline to be able to correctly find the + start of the completion word. + + There is one change which I've needed to make as a consequence of + removing the above code, and I think this is a bug fix. + + In complete_line_internal_normal_command we initialised temporary + variable P to the CMD_ARGS; this is the complete text after the + command name. Meanwhile, complete_line_internal_normal_command also + accepts an argument WORD, which is the completion word that readline + found for us. + + In the code I removed P was updated, it was first set to WORD, and + then moved backwards to the "new" start of the completion word. + + But notice, the default for P is the complete command argument text, + and only if we are performing filename completion do we modify P to be + the completion word. + + We then passed P through to the actual commands completion function. + + If we are doing anything other than filename completion then the value + of P passed is the complete argument text. + + If we are doing filename completion then the value of P passed is the + completion word. + + In filename_completer we get two arguments TEXT and WORD, the TEXT + argument is the value of P which is the "new" completion word, while + WORD is the completion word that readline calculated. + + After simplifying complete_line_internal_normal_command, and the + temporary P is removed, we always pass the complete argument text into + TEXT, while WORD remains the completion word that readline found. + + Previously in filename_completer we actually tried to generate + completions based on TEXT, which worked fine as TEXT actually + contained the completion word that we found in + complete_line_internal_normal_command. But I believe that we should + be fine to use the completion word that readline found, so I have + updated filename_completer to generate completions based on WORD. + + If I'm correct, then I don't expect to see any user visible changes + after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove some dead code from completer.c + In completer.c there is some code that is surrounded with '#if 0', + this code: + + #if 0 + /* There is no way to do this just long enough to affect quote + inserting without also affecting the next completion. This + should be fixed in readline. FIXME. */ + /* Ensure that readline does the right thing + with respect to inserting quotes. */ + rl_completer_word_break_characters = ""; + #endif + + This code, in some form, and always defined out, has been around since + the original import of GDB. Though the comment hints at what the + problem might be, it's not really clear what the issue is. And + completion within GDB has moved on a long way since this code was + written ... but not used. + + I'm proposing that we just remove this code. + + If/when a problem comes up then we can look at how to solve it. Maybe + this code would be the answer ... but also, I suspect, given all the + changes ... maybe not. I'm not sure carrying around this code for + another 20+ years adds much value. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: allow double quotes for quoting filenames + Currently GDB only supports using single quotes for quoting things, + the reason for this, as explained in completer.c (next to the variable + gdb_completer_expression_quote_characters) is that double quoted + strings need to be treated differently by the C expression parser. + + But for filenames I don't believe this restriction holds. The file + names as passed to things like the 'file' command are not passing + through the C expression parser, so it seems like we should be fine to + allow double quotes for quoting in this case. + + And so, this commit extends GDB to allow double quotes for quoting + filenames. Maybe in future we might be able to allow double quote + quoting in additional places, but this seems enough for now. + + The testing has been extended to cover double quotes in addition to + the existing single quote testing. + + This change does a number of things: + + 1. Set rl_completer_quote_characters in filename_completer and + filename_completer_handle_brkchars, this overrides the default which + is set in complete_line_internal_1, + + 2. In advance_to_completion_word we now take a set of quote + characters as a parameter, the two callers + advance_to_expression_complete_word_point and + advance_to_filename_complete_word_point now pass in the required set + of quote characters, + + 3. In completion_find_completion_word we now use the currently active + set of quote characters, this means we'll use + gdb_completer_expression_quote_characters or + gdb_completer_file_name_quote_characters depending on what type of + things we are completing. + +2024-03-25 Andrew Burgess + + gdb: fix bug where quote characters would become nullptr + In gdb_completion_word_break_characters_throw, after calling + complete_line_internal, if the completion function chose to use a + custom word point then we set rl_completer_quote_characters to NULL. + + However, nowhere do we set rl_completer_quote_characters back to its + default value, which is setup in init_main (top.c). + + An example of something that uses a custom word point for its + completion is 'thread apply all ...'. + + An example of something that relies on rl_completer_quote_characters + would be completion of a quoted filename that contains white space. + + Consider this shell and GDB session. The markers indicate where + I've used tab to trigger completion: + + $ mkdir /tmp/aaa\ bbb + $ touch /tmp/aaa\ bbb/xx\ 11 + $ touch /tmp/aaa\ bbb/xx\ 22 + $ gdb -q + (gdb) file '/tmp/aaa bbb/xx + xx 11 xx 22 + (gdb) thread apply all hel + (gdb) thread apply all help + (gdb) file '/tmp/aaa bbb/xx + + First I create a directory structure which uses white space within + file and directory names. Then within GDB I use the 'file' command + and use a single quote to quote the filename. When I tab complete GDB + correctly offers the two files within the directory '/tmp/aaa bbb/'. + + This works because rl_completer_quote_characters contains the single + quote, and so readline knows that it is trying to complete the string + that starts after the single quote: /tmp/aaa bbb/xx + + Next I invoke the completer for the 'thread apply all' command, to do + this I type 'thread apply all hel' and hit tab, this expands to the + one completion 'thread apply all help'. We can run this command or + not, it doesn't matter (there are no threads, so we'll get no output). + + Now I repeat the original 'file' completion. This time though I don't + get offered any completions. + + The reason is that the 'thread apply all' completer set + rl_completer_quote_characters to nullptr. Now, when readline tries to + figure out the word to complete it doesn't see the single quote as the + start of a quoted word, so instead readline falls back to the word + break characters, and in this case spots the white space. As a result + readline tries to complete the string 'bbb/xx' which obviously doesn't + have any completions. + + By setting rl_completer_quote_characters each time completion is + invoked this problem is resolved and the second 'file' command + completes as expected. + + I've extended gdb.base/filename-completion.exp to also test with + quoted filenames, and added a 'thread apply all' completion at the + start to expose this bug. + + As setting of rl_completer_quote_characters is now all done in the + completer.c file the function get_gdb_completer_quote_characters() + could be made static. However, as this function is only used one time + to initialise rl_completer_quote_characters, I've instead just deleted + get_gdb_completer_quote_characters() and used + gdb_completer_quote_characters directly. + +2024-03-25 Andrew Burgess + + gdb: remove skip_quoted and skip_quoted_chars + The function skip_quoted_chars (completer.c) is only used by + skip_quoted (also completer.c), so could be made static. The function + skip_quoted just calls directly to skip_quoted_chars but fills in some + default arguments. + + The function skip_quoted is only used by the Pascal expression parser, + and is only used in one place. + + The skip_quoted_chars function skips a single string; it either looks + for a string between matching quotes, or for a string up to a word + break character. + + However, given how the Pascal expression parser calls this function, + we know that the first character will always be a single quote, in + which case skip_quoted_chars will looks for a string between matching + single quotes. + + The skip_quoted_chars doesn't do any escaped character handling, it + will just stop at the next single quote character. + + In this commit I propose to remove skip_quoted and skip_quoted_chars, + and replace these with a smaller function pascal_skip_string which + I've placed in p-exp.y. This new function only skips a string between + matching single quotes, which is exactly the use case that we need. + + The benefit of this change is to remove (some) code duplication. It + feels like skip_quoted is similar in some ways to + extract_string_maybe_quoted, however, there are some differences; + skip_quoted uses the quotes and word break characters from the + completion engine which extract_string_maybe_quoted does not. + + However, I'm currently working on improving filename completion, one + part of this is that I'm looking at allowing filenames to be quoted + with single or double quotes, while the default string quoting in + GDB (for expressions) can only use single quotes. If I do end up + allowing single and double quotes in some cases, but we retain the + single quotes only for expressions then skip_quoted starts to become a + problem, should it accept both quote types, or only one? + + But given how skip_quoted is used, I can avoid worrying about this by + simply removing skip_quoted. + + The Pascal tests do still pass. The code that called skip_quoted is + called at least once in the Pascal tests (adding an abort() call + causes gdb.pascal/types.exp to fail), but I doubt the testing is + extensive. Not sure how widely used GDB for Pascal actually is + though. + +2024-03-25 Andrew Burgess + + gdb: rename unwindonsignal to unwind-on-signal + We now have unwind-on-timeout and unwind-on-terminating-exception, and + then the odd one out unwindonsignal. + + I'm not a great fan of these squashed together command names, so in + this commit I propose renaming this to unwind-on-signal. + + Obviously I've added the hidden alias unwindonsignal so any existing + GDB scripts will keep working. + + There's one test that I've extended to test the alias works, but in + most of the other test scripts I've changed over to use the new name. + + The docs are updated to reference the new name. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: introduce unwind-on-timeout setting + Now that inferior function calls can timeout (see the recent + introduction of direct-call-timeout and indirect-call-timeout), this + commit adds a new setting unwind-on-timeout. + + This new setting is just like the existing unwindonsignal and + unwind-on-terminating-exception, but the new setting will cause GDB to + unwind the stack if an inferior function call times out. + + The existing inferior function call timeout tests have been updated to + cover the new setting. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: add timeouts for inferior function calls + In the previous commits I have been working on improving inferior + function call support. One thing that worries me about using inferior + function calls from a conditional breakpoint is: what happens if the + inferior function call fails? + + If the failure is obvious, e.g. the thread performing the call + crashes, or hits a breakpoint, then this case is already well handled, + and the error is reported to the user. + + But what if the thread performing the inferior call just deadlocks? + If the user made the call from a 'print' or 'call' command, then the + user might have some expectation of when the function call should + complete, and, when this time limit is exceeded, the user + will (hopefully) interrupt GDB and regain control of the debug + session. + + But, when the inferior function call is from a breakpoint condition it + is much harder to understand that GDB is deadlocked within an inferior + call. Maybe the breakpoint hasn't been hit yet? Or maybe the + condition was always false? Or maybe GDB is deadlocked in an inferior + call? The only way to know for sure is for the user to periodically + interrupt the inferior, check on the state of all the threads, and + then continue. + + Additionally, the focus of the previous commit was inferior function + calls, from a conditional breakpoint, in a multi-threaded inferior. + This opens up a whole new set of potential failure conditions. For + example, what if the function called relies on interaction with some + other thread, and the other thread crashes? Or hits a breakpoint? + Given how inferior function calls work (in a synchronous manner), a + stop event in some other thread is going to be ignored while the + inferior function call is being executed as part of a breakpoint + condition, and this means that GDB could get stuck waiting for the + original condition thread, which will now never complete. + + In this commit I propose a solution to this problem. A timeout. For + targets that support async-mode we can install an event-loop timer + before starting the inferior function call. When the timer expires we + will stop the thread performing the inferior function call. With this + mechanism in place a user can be sure that any inferior call they make + will either complete, or timeout eventually. + + Adding a timer like this is obviously a change in behaviour for the + more common 'call' and 'print' uses of inferior function calls, so, in + this patch, I propose having two different timers. One I call the + 'direct-call-timeout', which is used for 'call' and 'print' commands. + This timeout is by default set to unlimited, which, not surprisingly, + means there is no timeout in place. + + A second timer, which I've called 'indirect-call-timeout', is used for + inferior function calls from breakpoint conditions. This timeout has + a default value of 30 seconds. This is a reasonably long time to + wait, and hopefully should be enough in most cases to allow the + inferior call to complete. An inferior call that takes more than 30 + seconds, which is installed on a breakpoint condition is really going + to slow down the debug session, so hopefully this is not a common use + case. + + The user is, of course, free to reduce, or increase the timeout value, + and can always use Ctrl-c to interrupt an inferior function call, but + this timeout will ensure that GDB will stop at some point. + + The new commands added by this commit are: + + set direct-call-timeout SECONDS + show direct-call-timeout + set indirect-call-timeout SECONDS + show indirect-call-timeout + + These new timeouts do depend on async-mode, so, if async-mode is + disabled (maint set target-async off), or not supported (e.g. target + sim), then the timeout is treated as unlimited (that is, no timeout is + set). + + For targets that "fake" non-async mode, e.g. Linux native, where + non-async mode is really just async mode, but then we park the target + in a sissuspend, we could easily fix things so that the timeouts still + work, however, for targets that really are not async aware, like the + simulator, fixing things so that timeouts work correctly would be a + much bigger task - that effort would be better spent just making the + target async-aware. And so, I'm happy for now that this feature will + only work on async targets. + + The two new show commands will display slightly different text if the + current target is a non-async target, which should allow users to + understand what's going on. + + There's a somewhat random test adjustment needed in gdb.base/help.exp, + the test uses a regexp with the apropos command, and expects to find a + single result. Turns out the new settings I added also matched the + regexp, which broke the test. I've updated the regexp a little to + exclude my new settings. + + Reviewed-By: Tankut Baris Aktemur + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + Natalia Saiapova + Tankut Baris Aktemur + + gdb: fix b/p conditions with infcalls in multi-threaded inferiors + This commit fixes bug PR 28942, that is, creating a conditional + breakpoint in a multi-threaded inferior, where the breakpoint + condition includes an inferior function call. + + Currently, when a user tries to create such a breakpoint, then GDB + will fail with: + + (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ()) + Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2460150)] + [New Thread 0x7ffff745c700 (LWP 2460151)] + [New Thread 0x7ffff6c5b700 (LWP 2460152)] + [New Thread 0x7ffff645a700 (LWP 2460153)] + [New Thread 0x7ffff5c59700 (LWP 2460154)] + Error in testing breakpoint condition: + Couldn't get registers: No such process. + An error occurred while in a function called from GDB. + Evaluation of the expression containing the function + (return_true) will be abandoned. + When the function is done executing, GDB will silently stop. + Selected thread is running. + (gdb) + + Or, in some cases, like this: + + (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1)) + Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2461106)] + [New Thread 0x7ffff745c700 (LWP 2461107)] + ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + + The precise error depends on the exact thread state; so there's race + conditions depending on which threads have fully started, and which + have not. But the underlying problem is always the same; when GDB + tries to execute the inferior function call from within the breakpoint + condition, GDB will, incorrectly, try to resume threads that are + already running - GDB doesn't realise that some threads might already + be running. + + The solution proposed in this patch requires an additional member + variable thread_info::in_cond_eval. This flag is set to true (in + breakpoint.c) when GDB is evaluating a breakpoint condition. + + In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is + true, then GDB will only try to resume the current thread, that is, + the thread for which the breakpoint condition is being evaluated. + This solves the problem of GDB trying to resume threads that are + already running. + + The next problem is that inferior function calls are assumed to be + synchronous, that is, GDB doesn't expect to start an inferior function + call in thread #1, then receive a stop from thread #2 for some other, + unrelated reason. To prevent GDB responding to an event from another + thread, we update fetch_inferior_event and do_target_wait in infrun.c, + so that, when an inferior function call (on behalf of a breakpoint + condition) is in progress, we only wait for events from the current + thread (the one evaluating the condition). + + In do_target_wait I had to change the inferior_matches lambda + function, which is used to select which inferior to wait on. + Previously the logic was this: + + auto inferior_matches = [&wait_ptid] (inferior *inf) + { + return (inf->process_target () != nullptr + && ptid_t (inf->pid).matches (wait_ptid)); + }; + + This compares the pid of the inferior against the complete ptid we + want to wait on. Before this commit wait_ptid was only ever + minus_one_ptid (which is special, and means any process), and so every + inferior would match. + + After this commit though wait_ptid might represent a specific thread + in a specific inferior. If we compare the pid of the inferior to a + specific ptid then these will not match. The fix is to compare + against the pid extracted from the wait_ptid, not against the complete + wait_ptid itself. + + In fetch_inferior_event, after receiving the event, we only want to + stop all the other threads, and call inferior_event_handler with + INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint. + If we are, then all the other threads should be left doing whatever + they were before. The inferior_event_handler call will be performed + once the breakpoint condition has finished being evaluated, and GDB + decides to stop or not. + + The final problem that needs solving relates to GDB's commit-resume + mechanism, which allows GDB to collect resume requests into a single + packet in order to reduce traffic to a remote target. + + The problem is that the commit-resume mechanism will not send any + resume requests for an inferior if there are already events pending on + the GDB side. + + Imagine an inferior with two threads. Both threads hit a breakpoint, + maybe the same conditional breakpoint. At this point there are two + pending events, one for each thread. + + GDB selects one of the events and spots that this is a conditional + breakpoint, GDB evaluates the condition. + + The condition includes an inferior function call, so GDB sets up for + the call and resumes the one thread, the resume request is added to + the commit-resume queue. + + When the commit-resume queue is committed GDB sees that there is a + pending event from another thread, and so doesn't send any resume + requests to the actual target, GDB is assuming that when we wait we + will select the event from the other thread. + + However, as this is an inferior function call for a condition + evaluation, we will not select the event from the other thread, we + only care about events from the thread that is evaluating the + condition - and the resume for this thread was never sent to the + target. + + And so, GDB hangs, waiting for an event from a thread that was never + fully resumed. + + To fix this issue I have added the concept of "forcing" the + commit-resume queue. When enabling commit resume, if the force flag + is true, then any resumes will be committed to the target, even if + there are other threads with pending events. + + A note on authorship: this patch was based on some work done by + Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made + some changes to their work in this version. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942 + + [1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + Revert "gdb: remove unnecessary parameter wait_ptid from do_target_wait" + This reverts commit ac0d67ed1dcf470bad6a3bc4800c2ddc9bedecca. + + There was nothing wrong with the commit which I'm reverting here, but + it removed some functionality that will be needed for a later commit; + that is, the ability for GDB to ask for events from a specific ptid_t + via the do_target_wait function. + + In a follow up commit, this functionality will be used to implement + inferior function calls in multi-threaded inferiors. + + This is not a straight revert of the above commit. Reverting the + above commit replaces a 'nullptr' with 'NULL', I've gone in and + changed that, preserving the 'nullptr'. + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into + gdb/nat/x86-linux-tdesc.c and combine them so we have just a single + copy of each. Then both GDB and gdbserver will link against these + shared functions. + + It is worth reading the description of the previous commit to see why + this merging is not as simple as it seems: on the gdbserver side we + actually have two users of these functions, gdbserver itself, and the + in process agent (IPA). + + However, the previous commit streamlined the gdbserver code, and so + now it is simple to move the two functions along with all their + support functions from the gdbserver directory into the gdb/nat/ + directory, and then GDB is fine to call these functions. + + One small curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, that is some + additional configuration that is performed as each target description + is created to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + This does mean adding back some non-shared code when this whole series + has been about sharing code, but now the only non-shared bit is the + single line that is actually different between GDB and gdbserver, all + the rest, which is identical, is now shared. + + I did need to add a new rule to the gdbserver Makefile, this is to + allow the nat/x86-linux-tdesc.c file to be compiled for the IPA. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring, the previous commit actually started to share + some code, we added the shared x86_linux_tdesc_for_tid function into + nat/x86-linux-tdesc.c. However, this function still relies on + amd64_linux_read_description and i386_linux_read_description which are + implemented separately for both gdbserver and GDB. Given that at + their core, all these functions to is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + On the GDB side we create target descriptions using a different set of + cpu features than on the gdbserver side! This means that for the + exact same target, we might get a different target description when + using native GDB vs using gdbserver. This surely feels like a + mistake, I would expect to get the same target description on each. + + The table below shows the number of possible different target + descriptions that we can create on the GDB side vs on the gdbserver + side for each target type: + + | GDB | gdbserver + ------|-----|---------- + i386 | 64 | 7 + amd64 | 32 | 7 + x32 | 16 | 7 + + So in theory, all I want to do is move the GDB version + of *_read_description into the nat/ directory and have gdbserver use + that, then both GDB and gdbserver would be able to create any of the + possible target descriptions. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach made perfect sense. However + since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think passing the index is now more trouble than its worth. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use. However, the above commit + fixed an issue where we can't call malloc() within (certain parts of) + the IPA (apparently), so instead we now pre-compute _every_ possible + target description within the IPA. The index is now only used to + lookup which of the (many) pre-computed target descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of cpu features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + create the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they create target descriptions + using the same set of cpu features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series does. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit can merge the GDB and gdbserver + versions of these functions. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While trying to merge this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + With this patch series of mine: + + https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com + + I worried that there could be other paths that could result in an xcr0 + value that has X86_XSTATE_MPX set in x32 mode. As everyone eventually + calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this should uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things the GDB way, the only changes are to + allow for the sharing; we now have a callback function to call the + first time that the xcr0 state is read, this allows for GDB and + gdbserver to perform their own initialisation as needed, and + additionally, the new function takes a pointer for where to cache the + xcr0 value, this isn't needed for this commit, but will be useful in a + later commit where gdbserver will want to read this cached xcr0 + value. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/nat/x86-linux-tdesc.h, but the implementations are left as + separate. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit is part of a series that aims to share more of the x86 + target description creation code between GDB and gdbserver. The + I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target + description creation, and I noticed that this constant is defined + separately for GDB and gdbserver. + + This commit moves the definition into gdb/nat/x86-linux.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim of making the code + that, for x86, reads the target description for a native process + shared between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes. + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code could be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12 + With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc + 12, I get: + ... + (gdb) set debug symtab-create 1^M + (gdb) print *the_local_var^M + ... + $1 = (n => 2)^M + (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded + ... + + The problem is that this fails: + ... + -re -wrap ".* = \\\(n => $decimal\\\)" { + if {$found_pck + $found_pck2 == 1} { + pass $gdb_test_name + } else { + fail $gdb_test_name + } + ... + because $found_pck == 0 and $found_pck2 == 0. + + Indeed, with gcc 13 we have: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + pck2.adb + pck2.adb + pck2.ads + pck2.adb + pck2.ads + ... + and with gcc 12: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + ... + + Fix this by checking for "$found_pck + $found_pck2 <= 1" instead. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31514 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514 + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix tdlabel_re references + Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs + from info threads") introduces a new global variable tdlabel_re, but fails to + indicate it's global when used in procs in four test-cases. + + Fix this by adding "global tdlabel_re". + + Tested on aarch64-linux. + +2024-03-25 GDB Administrator + + Automatic date update in version.in + +2024-03-24 GDB Administrator + + Automatic date update in version.in + +2024-03-23 John Baldwin + + gdb tests: Allow for "LWP" or "process" in thread IDs from info threads + Several tests assume that the first word after a thread ID in 'info + threads' output is "Thread". However, several targets use "LWP" + instead such as the FreeBSD and NetBSD native targets. The Linux + native target also uses "LWP" if libthread_db is not being used. + Targets that do not support threads use "process" as the first word + via normal_pid_to_str. + + Add a tdlabel_re global variable as a regular-expression for a thread + label in `info threads' that matches either "process", "Thread", or + "LWP". + + Some other tests in the tree don't require a specific word, and + some targets may use other first words (e.g. OpenBSD uses "thread" + and Ravenscar threads use "Ravenscar Thread"). + +2024-03-23 GDB Administrator + + Automatic date update in version.in + +2024-03-22 Pedro Alves + + windows-nat: Use gdb_realpath + Use gdb_realpath instead of realpath in windows-nat.c:windows_make_so, + so that we don't have to manually call free. + + Approved-By: John Baldwin + Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff + +2024-03-22 Pedro Alves + + windows-nat: Remove SO_NAME_MAX_PATH_SIZE limit + There is no need to limit shared library path sizes to + SO_NAME_MAX_PATH_SIZE nowadays. windows_solib::name and + windows_solib::original_name are std::strings nowadays, and so are + solib::so_name and solib::so_original_name in the core solib code. + + This commit reworks the code to remove that limit. This also fixes a + leak where we were not releasing 'rname' in the realpath branch if the + 'rname' string was larger than SO_NAME_MAX_PATH_SIZE. + + Note: I tested the cygwin_conv_path with a manual hack to force that + path, and then stepping through the code. You only get to that path + if Windows doesn't report an absolute path for ntdll.dll, and on my + machine (running Windows 10), it always does. + + Approved-By: John Baldwin + Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5 + +2024-03-22 Pedro Alves + + Simplify windows-nat.c:windows_make_so #ifdefery + There are two separate #ifndef __CYGWIN__/#else/#endif sections in the + windows_make_so function with 3 lines of shared code separating them. + I find this makes the code harder to understand than necessary. + AFAICS, there is no reason those three shared lines need to be after + the first #ifdef block. There is no early return, nor are 'load_addr' + nor 'name' modified. + + This commit moves that shared code to the top of the function, and + then combines the two #ifndef sections. + + Approved-By: John Baldwin + Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc + +2024-03-22 Pedro Alves + + Remove SO_NAME_MAX_PATH_SIZE limit from core solib code + solib_map_sections errors out if the library file name is longer than + SO_NAME_MAX_PATH_SIZE. + + solib::so_name and solib::so_original_name used to be arrays of + SO_NAME_MAX_PATH_SIZE size, so that check made sense then. + + However, since commit 98107b0b17ac ("gdb: make + so_list::{so_original_name,so_name} std::strings") those fields are of + std::string type, so there's really no need for the limit. + + This commit simply removes the length limit check. + + Approved-By: John Baldwin + Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6 + +2024-03-22 Tom Tromey + + Use std::string for disassembler options + I noticed that the disassembler_options code uses manual memory + management. It seemed simpler to replace this with std::string. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Remove some unnecessary casts + I found a few unnecessary casts when calling + set_gdbarch_disassembler_options_implicit. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Constify get_disassembler_options + This changes get_disassembler_options to return a const char *. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Revert "Pass GUILE down to subdirectories" + This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. + + This patch caused problems for some users when building gdb, because + it would cause 'guild' to be invoked with the wrong versin of guile. + On the whole it seems simpler to just back this out. + + I'm checking this in to the binutils-gdb repository in the interest of + fixing the build for Andrew. No one has responded to the identical + patch sent to gcc-patches, but I will ping it there. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Remove GUILE. + (GUILE): Remove. + * Makefile.def (flags_to_pass): Remove GUILE. + +2024-03-22 Tiezhu Yang + + gdb: LoongArch: Clean up loongarch_iterate_over_regset_sections() + Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET + to replace the related code in the first cb(), and also make use of + tabs and spaces in indentation to force the proper alignment of code, + then remove the empty line at the end of the function. + +2024-03-22 Pedro Alves + + Teach GDB to generate sparse core files (PR corefiles/31494) + This commit teaches GDB's gcore command to generate sparse core files + (if supported by the filesystem). + + To create a sparse file, all you have to do is skip writing zeros to + the file, instead lseek'ing-ahead over them. + + The sparse logic is applied when writing the memory sections, as + that's where the bulk of the data and the zeros are. + + The commit also tweaks gdb.base/bigcore.exp to make it exercise + gdb-generated cores in addition to kernel-generated cores. We + couldn't do that before, because GDB's gcore on that test's program + would generate a multi-GB non-sparse core (16GB on my system). + + After this commit, gdb.base/bigcore.exp generates, when testing with + GDB's gcore, a much smaller core file, roughly in line with what the + kernel produces: + + real sizes: + + $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + apparent sizes: + + $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + Time to generate the core also goes down significantly. On my machine, I get: + + when writing to an SSD, from 21.0s, down to 8.0s + when writing to an HDD, from 31.0s, down to 8.5s + + The changes to gdb.base/bigcore.exp are smaller than they look at + first sight. It's basically mostly refactoring -- moving most of the + code to a new procedure which takes as argument who should dump the + core, and then calling the procedure twice. I purposely did not + modernize any of the refactored code in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494 + Reviewed-By: Lancelot Six + Reviewed-By: Eli Zaretskii + Reviewed-By: John Baldwin + Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1 + +2024-03-22 Jan Beulich + + x86: fix Solaris testsuite failures + For one 0afc614c9938 ("x86: Warn .insn instruction with length > 15 + bytes") introduced a .insn use involving a slash; such tests need to + have --divide passed to gas. + + And then 5bc71c2a6b8e ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke + BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by + adding respective code in a section guarded by + generate_relax_relocations (the case of that not being required there + was limited to 32-bit object files). Re-arrange that block of code to + check generate_relax_relocations later. + +2024-03-22 GDB Administrator + + Automatic date update in version.in + +2024-03-21 H.J. Lu + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits + on x32. + + PR server/31511 + * linux-x86-low.cc (x86_linux_read_description): Clear + X86_XSTATE_MPX bits in xcr0 on x32. + Reviewed-by: Felix Willgerodt + +2024-03-21 Tom Tromey + + Implement Ada 2022 delta aggregates + Ada 2022 includes a "delta aggregates" feature that can sometimes + simplify aggregate creation. This patch implements this feature for + GDB. + +2024-03-21 Tom Tromey + + Require trivial destructor in allocate_on_obstack + This patch makes allocate_on_obstack a little bit safer, by enforcing + the rule that objects allocated on an obstack must have a trivial + destructor. + + The static assert is done in a method -- doing it inside the class + itself won't work because the class is incomplete at that point. + +2024-03-21 Tom Tromey + + Don't use virtual destructor in addrmap + The addrmap polymorphism is sort of "phony" in that there isn't really + code in the tree that can be presented with either type. I haven't + tried to fix this (though perhaps I may); but meanwhile it's handy for + the next patch if addrmap_fixed has a trivial destructor. This patch + achieves this by making the addrmap destructor non-virtual, and also + making it protected so that objects of any of these types cannot be + destroyed when only the base class is known. + + Use addrmap_fixed in a few spots + There are a few spots in the tree that use 'addrmap' where only an + addrmap_fixed will ever really be seen. This patch changes this code + to use the more specific type. + +2024-03-21 Orgad Shaneh + + sim/erc32: Rename EVENT_MAX -> MAX_EVENTS + EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when + building on Windows, the value is overridden and compilation fails + because the array size of evbuf is too large. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476 + Approved-By: Tom Tromey + +2024-03-21 Tiezhu Yang + + gdb: syscalls: Add some tips for LoongArch xml files + In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in), + it needs special handling when generating xml file. This should at + least be mentioned in the file comment rather than git log to help + the next person who regenerates this file understand what needs to + be done, suggested by Pedro Alves, thank you. + + At the beginning, I only added the tips in loongarch-linux.xml.in, + after executing the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in, it generates the same tips in the file + loongarch-linux.xml automatically, so update loongarch-linux.xml.in + and loongarch-linux.xml together. + + Approved-by: Pedro Alves + +2024-03-21 Hui Li + + gdb: LoongArch: Silence warning about core file of lsx and lasx + In loongarch_iterate_over_regset_sections(), the second and third arguments + of the iterate_over_regset_sections_cb callback function should be the regset + size which is regsize * regnum. Otherwise when execute: + + make check-gdb TESTS="gdb.base/corefile.exp" + + there exists the following failed log: + + (gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core + [New LWP 531099] + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'. + Program terminated with signal SIGABRT, Aborted. + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + #0 0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6 + (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free + +2024-03-21 Nick Clifton + + New Romanian translation for gas sub-directory + +2024-03-21 GDB Administrator + + Automatic date update in version.in + +2024-03-20 Simon Marchi + + .pre-commit-config.yaml: bump black hook to 24.3.0 + Running `pre-commit autoupdate` showed that there is a new version of + the black hook for v24.3.0. Update it. + + ChangeLog: + + * .pre-commit-config.yaml: Bump black hook to 24.3.0 + + Change-Id: I5ec7d2edf99cd15f6525281a43aed9ff481ee9ee + +2024-03-20 Tom de Vries + + [gdb/testsuite] Fix gdb.server/server-connect.exp for missing ipv6 + On a system without ipv6 support enabled, when running test-case + gdb.server/server-connect.exp, it takes about 4 minutes, and I get: + ... + builtin_spawn gdbserver --once ::1:2347 server-connect^M + Can't open socket: Address family not supported by protocol.^M + Exiting^M + PASS: gdb.server/server-connect.exp: tcp6: start gdbserver + target remote tcp6:::1:2347^M + A program is being debugged already. Kill it? (y or n) y^M + could not connect: Address family not supported by protocol.^M + (gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1 + ... + + Fix this by: + - recognizing the error message in gdbserver_start, and returning an empty list + to signal unsupported, and + - handling the unsupported response in the test-case. + + This brings testing time down to 2 seconds, and gets me: + ... + UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31502 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502 + +2024-03-20 Tom de Vries + + [gdb/testsuite] Handle core without build-id in gdb.base/corefile-buildid.exp + On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get: + ... + expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163" + info files^M + Local core dump file:^M + `build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M + 0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M + ... + 0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M + (gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files + ... + + The problem is that the test-case expect the build-id to be available in the + core file, while it isn't. + + Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in + gdb.base/coredump-filter-build-id.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Tom de Vries + + [gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases + On aarch64-linux (debian 12), when running test-case + gdb.base/longjmp-until-in-main.exp, I run into: + ... + (gdb) until 33^M + warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M + Warning:^M + Cannot insert breakpoint 0.^M + Cannot access memory at address 0xfff727c678928489^M + ^M + 0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M + (gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main + ... + + This is PR gdb/26967: no longjmp probe is available: + ... + (gdb) info probes stap libc ^longjmp$^M + No probes matched.^M + ... + and glibc applies pointer mangling which makes it fairly difficult for gdb to + get the longjmp target. + + There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit + b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp"). + + Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in + this and one more test-case. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix casting in-memory values of primitive types to const reference + It's currently not possible to cast an in-memory value of a primitive + type to const reference: + ``` + (gdb) p Q.id + $1 = 42 + (gdb) p (int&)Q.id + $2 = (int &) @0x22fd0c: 42 + (gdb) p (const int&)Q.id + Attempt to take address of value not located in memory. + ``` + + And if in a function call an argument needs the same kind of casting, + it also doesn't work: + ``` + (gdb) l f3 + 39 int f3(const int &i) + 40 { + 41 return i; + 42 } + (gdb) p f3(Q.id) + Attempt to take address of value not located in memory. + ``` + + It's because when the constness of the type changes in a call to + value_cast, a new not_lval value is allocated, which doesn't exist + in the target memory. + + Fixed by ignoring const/volatile/restrict qualifications in + value_cast when comparing cast type to original type, so the new + value will point to the same location as the original value: + ``` + (gdb) p (int&)i + $2 = (int &) @0x39f72c: 1 + (gdb) p (const int&)i + $3 = (const int &) @0x39f72c: 1 + (gdb) p f3(Q.id) + $4 = 42 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423 + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix reinterpret_cast for classes with multiple inheritance + Currently a reinterpret_cast may change the pointer value if + multiple inheritance is involved: + ``` + (gdb) p r + $1 = (Right *) 0x22f75c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x22f758 + ``` + + It's because value_cast is called in this case, which automatically + does up- and downcasting. + + Fixed by simply using the target pointer type in a copy of the + original value: + ``` + (gdb) p r + $1 = (Right *) 0x3bf87c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x3bf87c + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861 + Approved-By: Tom Tromey + +2024-03-20 Simon Marchi + + Add .pre-commit-config.yaml + Add a pre-commit [1] config file, with a single hook to run black on the + gdb directory whenever a Python file is modified. We can always add + more hooks if we find some that are useful. + + Using pre-commit to run hooks is opt-in, as in it's not mandatory at all + for development, but it can be useful to run some checks that are easy + to forget (like running black). The hooks run locally on the + developer's machine when doing `git commit` (although they can also be + configured to run at other stages of the git workflow). + + Follow these instructions to install the hooks in your local development + git repository: + + - Install pre-commit the way you prefer. It can be using your OS + package manager if it has a recent enough version, or using `pip + install pre-commit`. + - Go to the binutils-gdb repository and run `pre-commit install`. + + This installs a git hook at `.git/hooks/pre-commit`. + + Now, whenever you modify and try to commit a Python file, pre-commit + will run black on it. For instance, if I try to insert something + misformatted, I get this when doing `git commit`: + + $ git commit + black....................................................................Failed + - hook id: black + - files were modified by this hook + + reformatted gdb/python/lib/gdb/dap/breakpoint.py + + All done! ✨ 🍰 ✨ + 1 file reformatted. + + At this point, black has already reformatted the files in place, so the + changes that fix the formatting are ready to add and commit. black is + only ran on files modified in the commit. + + The hook defines a black version, which is downloaded at `pre-commit + install` time. pre-commit manages its own env at + `$HOME/.cache/pre-commit/`, so it won't use the version of + black you have installed already. This may help ensure that + contributors use the right black version. + + The procedure when there is a new version of black (or a new version of + any hook we might be using in the future) is: + + - Modify .pre-commit-config.yaml to change the version number, push to + the upstream repo. + - Have contributors run `pre-commit autoupdate` to make their local + pre-commit installation update the hooks. + + It is possible to have pre-commit skip some hooks if needed [2]. + + I will add these instructions to the wiki if this patch gets merged, so + they are easy to find. We could perhaps think of having a + gdb/CONTRIBUTING document of some sort checked in the repo with that + kind of information. + + I have not used pre-commit in a real project before, but have heard good + things from it. If we want to give it a try before pushing it to the + repo, some volunteers can copy the .pre-commit-config.yaml file locally + and try it for some time. However, pushing the file upstream is not + going to impact anybody who doesn't care about it, so I'd say it's + relatively low-risk to push it right now. + + [1] https://pre-commit.com + [2] https://pre-commit.com/#temporarily-disabling-hooks + + Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099 + Acked-By: Tom Tromey + Acked-By: Guinevere Larsen + Acked-By: Andrew Burgess + +2024-03-20 Hannes Domani + + Fix comparison of array types + Currently it's not possible to call functions if an argument is a + pointer to an array: + ``` + (gdb) l f + 1 int f (int (*x)[2]) + 2 { + 3 return x[0][1]; + 4 } + 5 + 6 int main() + 7 { + 8 int a[2][2] = {{0, 1}, {2, 3}}; + 9 return f (a); + 10 } + (gdb) p f(a) + Cannot resolve function f to any overloaded instance + ``` + + This happens because types_equal doesn't handle array types, so the + function is never even considered as a possibility. + + With array type handling added, by comparing element types and array + bounds, the same works: + ``` + (gdb) p f(a) + $1 = 1 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398 + Co-Authored-By: Keith Seitz + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-03-20 Tiezhu Yang + + gdb: LoongArch: Set the correct XML syscall filename + Now, there exists syscalls/loongarch-linux.xml, let us set the correct + XML syscall filename for LoongArch, otherwise GDB won't be able to find + the correct XML file to open and get the syscalls definitions. + + It should install the package expat-devel (a library for XML parsing) + and configure --with-expat (done by default if libexpat is installed + and found at configure time) for compiling gdb in this case. + + Without this patch: + + (gdb) catch syscall + warning: There is no XML file to open. + warning: GDB will not be able to display syscall names nor to verify if + any provided syscall numbers are valid. + Catchpoint 1 (any syscall) + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch case in update-linux-from-src.sh + It shows that "Don't know how to generate loongarch-linux.xml.in" + when using the script update-linux-from-src.sh to regenerate the + syscall group info against Linux kernel, just add loongarch case. + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Generate loongarch-linux.xml + Make use of the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch-linux.xml.in + There is no syscall.tbl for LoongArch because it uses generic syscalls, + so it can not generate loongarch-linux.xml.in automatically through the + script update-linux-from-src.sh, make use of the script update-linux.sh + to generate loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ touch loongarch-linux.xml.in + $ ./update-linux.sh loongarch-linux.xml.in + + Note that the system header file /usr/include/asm-generic/unistd.h + may be different with the latest upstream Linux kernel uapi header + file include/uapi/asm-generic/unistd.h, it is better to copy the + upstream header file into the system header file when generating + loongarch-linux.xml.in. + + There exist some __NR3264_ prefixed syscall numbers, replace them + with digital numbers according to /usr/include/asm-generic/unistd.h + and sort them by syscall number manually, maybe we can modify the + script to do it automatically in the future. + + + + + + + + + + + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml files for some archs + Make use of the command "make" to regenerate .xml files from .xml.in files. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml.in files for some archs + Make use of the script update-linux-from-src.sh to regenerate the Linux + syscall group info against Linux git commit d206a76d7d27 which will be + released in v6.8. + + Like this: + + $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-from-src.sh ~/linux.git/ + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update linux-defaults.xml.in + Make use of the script update-linux-defaults.sh to regenerate the Linux + syscall group info against strace git commit 8c480270653d which will be + released in v6.8. + + Like this: + + $ git clone https://github.com/strace/strace.git strace.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-defaults.sh ~/strace.git/ + + Approved-By: John Baldwin + +2024-03-20 Tom de Vries + + [gdb/symtab] Workaround PR gas/31115 + On arm-linux, with gas 2.40, I run into: + ... + (gdb) x /i main+8^M + 0x4e1 : vrhadd.u16 d14, d14, d31^M + (gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) + ... + + This is a regression due to PR gas/31115, which makes gas produce a low_pc + with the thumb bit set (0x4d8 & 0x1): + ... + <1><24>: Abbrev Number: 2 (DW_TAG_subprogram) + <25> DW_AT_name : main + <29> DW_AT_external : 1 + <29> DW_AT_type : <0x2f> + <2a> DW_AT_low_pc : 0x4d9 + <2e> DW_AT_high_pc : 12 + ... + + The regression was introduced in 2.39, and is also present in 2.40 and 2.41, + and hasn't been fixed yet. + + Work around this in read_func_scope, by using gdbarch_addr_bits_remove on + low_pc and high_pc. + + Tested on arm-linux and x86_64-linux. + + PR tdep/31453 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453 + +2024-03-20 GDB Administrator + + Automatic date update in version.in + +2024-03-19 Tom Tromey + + Speed up lookup of "type_specific_data" + I noticed that "info locals" on a certain large Ada program was very + slow. I tracked this down to ada_get_tsd_type expanding nearly every + CU in the program. + + This patch fixes the problem by changing this code to use the more + efficient lookup_transparent_type which, unlike the Ada-specific + lookup functions, does not try to find all matching instances. + + Note that I first tried fixing this by changing ada_find_any_type, but + this did not work -- I may revisit this approach at some later date. + + Also note that the copyright dates on the test files are set that way + because I copied them from another test. + + New in v2: the new test failed on the Linaro regression tester. + Looking at the logs, it seems that gdb was picking up a 'value' from + libgnat: + + $1 = {} 0xf7e227a4 + + This version renames the local variable in an attempt to work around + this. + + v3: In v2, while trying to reproduce the problem locally, I + accidentally forgot to commit one of the changes. + +2024-03-19 Tom Tromey + + Fix two serious flake8 reports + flake8 points out that some code in frame_filters.py is referring to + undefined variables. + + In the first hunk, I've changed the code to match what other + 'complete' methods do in this file. + + In the second hunk, I've simply removed the try/except -- if + get_filter_priority fails, it will raise GdbError, which is already + handled properly by gdb. + +2024-03-19 Andrew Burgess + + gdb/python: test exception case for gdb.solib_name + The gdb.solib_name() and Progspace.solib_name() functions can throw an + exception if the address argument is not a valid address, but this is + not currently tested. + + This commit adds a couple of tests to check that exceptions are thrown + correctly. + + An early version of this commit updated the documentation, but it was + pointed out that lots of functions throw an exception if passed an + argument of the wrong type, and we don't document all of these, it's + kind-of assumed that passing an object of the incorrect type might + result in an exception, so this updated version leaves the docs alone, + but I do think adding the extra tests has value. + + There's no changes to GDB itself in this commit. + + Approved-By: Tom Tromey + +2024-03-19 Saurabh Jha + + gas, aarch64: Add faminmax extension + +2024-03-19 Nick Clifton + + Remove redunant test of ELF size in core note decoder. + PR 31469 + +2024-03-19 Andrew Burgess + + gdbsupport: rename include guard in gdb-checked-static-cast.h + I noticed in passing that the include guard in the file + gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word + DYNAMIC when STATIC would be better, fixed in this commit. + + There should be no user visible changes after this commit. + +2024-03-19 Andrew Burgess + + gdb: use static_cast in gdb::checked_static_cast + This commit: + + commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf + Date: Sat Feb 24 11:00:20 2024 +0100 + + [gdb/build] Fix static cast of virtual base + + addressed an issue where GDB would not compile in production mode due + to a use of gdb::checked_static_cast. The problem was that we were + asking GDB to cast from a virtual base class to a sub-class, this + works fine when using dynamic_cast, but does not work with + static_cast. + + The gdb::checked_static_cast actually uses dynamic_cast under the hood + in development mode in order to ensure that the cast is valid, while + in a production build we use static_cast as this is more efficient. + + What this meant however, was that when gdb::checked_static_cast was + used to cast from a virtual base class, the dynamic_cast of a + non-production build worked fine, while the production build's + static_cast caused a build failure. + + However, the gdb::checked_static_cast function already contains some + static_assert calls that are intended to catch any issues with invalid + type casting, the goal of these asserts was to prevent issues like + this: the build only failing in production mode. Clearly the current + asserts are not enough. + + I don't think there is a std::is_virtual_base type trait check, so + what I propose instead is that in non-production mode we also make use + of static_cast. This will ensure that any errors that crop up in + production mode should also be revealed in non-production mode, and + should catch issues like this in the future. + + There should be no user visible changes after this commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + + Co-Authored-By: Simon Marchi + +2024-03-19 Nick Clifton + + Fix seg-fault in the DWARF reader code when accessing an abbreviatuin table with a corrupt entry offset. + PR 31456 + +2024-03-19 H.J. Lu + + ld: Support LD_UNDER_TEST environment variable + Support LD_UNDER_TEST environment variable to test a different linker. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + + * testsuite/config/default.exp: If LD_UNDER_TEST environment + variable exists, set ld and LD to it and set up tmpdir/ld/ld. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + +2024-03-19 Nick Clifton + + Fix free of unallocated memory in the BFD library's compression code. + PR 31455 + + Fix typo in previous patch to ld.texi + +2024-03-19 Toby Lloyd Davies + + gdb/python: Fix segfault when iterating over empty linetable + symtab-> linetable () is set to null in + buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab + has no linetable. Attempting to iterate over this linetable using the + Python API caused GDB to segfault. + + Approved-By: Tom Tromey + +2024-03-19 Toby Lloyd Davies + + Add myself to gdb/MAINTAINERS + +2024-03-19 Tom de Vries + + [gdb] Further fix "value is not available" with debug frame + In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame") + I fixed a case in frame_unwind_register_value where using "set debug frame on" + caused an "info frame" command to abort, reporting a "value is not available" + error, due to the tpidruro register being unavailable. + + Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from + non-FreeBSD target descriptions") removed the unavailable register, which + caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp. + + While investigating the progression (see PR python/31437), I found that the + "debug frame" output of the test-case (when reverting commit bbb12eb9c84) + showed a smilar problem: + ... + Python Exception : value is not available^M + ... + that was absent without "debug frame". + + Fix this likewise in fetch_lazy_register, and update the test-case to check + for the exception. + + Furthermore, I realized that there's both value::entirely_available and + value::entirely_unavailable, and that commit 2aaba744467 handled the case + of !entirely_available by printing unavailable. + + Instead, print: + - "unavailable" for entirely_unavailable, and + - "partly unavailable" for !entirely_unavailable && !entirely_available. + + Tested on x86_64-linux and arm-linux. + +2024-03-19 mengqinggang + + LoongArch: Add relaxation for R_LARCH_CALL36 + This relaxation is effective for both macro instructions (call36, tail36) + and explicit relocation instructions (pcaddu18i + jirl). + + call36 f -> bl f + R_LARCH_CALL36 -> R_LARCH_B26 + + tail36 $t0, f -> b f + R_LARCH_CALL36 -> R_LARCH_B26 + +2024-03-19 GDB Administrator + + Automatic date update in version.in + +2024-03-18 Nick Clifton + + Regenerate AArch64 opcodes files + +2024-03-18 Yury Khrustalev + + aarch64: Add support for SVE ADDPT, SUBPT, MADPT, MLAPT instructions + The following instructions are added in this patch: + + - ADDPT (predicated): Add checked pointer vectors (predicated). + - ADDPT (unpredicated): Add checked pointer vectors (unpredicated). + - SUBPT (predicated): Subtract checked pointer vectors (predicated). + - SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated). + - MADPT: Multiply-add checked pointer vectors, writing multiplicand + - MLAPT: Multiply-add checked pointer vectors, writing addend + + These instructions are part of Checked Pointer Arithmetic extension + and are enabled when both CPA and SVE are enabled. To achieve this, + both flag "+sve" and "+cpa" should be active. + + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Yury Khrustalev + + aarch64: Add support for (M)ADDPT and (M)SUBPT instructions + The following instructions are added in this patch: + + - ADDPT and SUBPT - Add/Subtract checked pointer + - MADDPT and MSUBPT - Multiply Add/Subtract checked pointer + + These instructions are part of Checked Pointer Arithmetic extension. + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + A new flag "+cpa" added to documentation. This flag enables CPA extension. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Nick Clifton + + [PATCH] ld: Improve documentation of -rpath-link search paths + +2024-03-18 Tom Tromey + + Remove some unnecessary Ada expression code + ada_bitwise_operation differs from the "usual" bitwise operations only + in that it calls value_cast at the end. However, because gdb is + generally fairly lax about integer types, and because (perhaps oddly) + C-style binary promotion is done here anyway, it seems to me that this + code isn't needed. + +2024-03-18 Tom Tromey + + Fix Ada 'ptype' of access to array + ptype is a bit funny, in that it accepts both expressions and type + names. It also evaluates the resulting expression using + EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would + you expect ptype to possibly cause inferior execution?), but is also a + historical artifact of how expressions are implemented (there's no + EVAL_FOR_TYPE). + + In Ada, calling a function with an array will sometimes result in a + "thick pointer" array descriptor being made. This is essentially a + structure holding a pointer and bounds information. + + Currently, in such a callee, printing the type of the array will yield + funny results: + + (gdb) print str.all + $1 = "Hello World" + (gdb) ptype str + type = array (<>) of character + (gdb) ptype str.all + type = array (1 .. 0) of character + + That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch + trying to do "something" with an array descriptor, without doing too + much. + + I tried briefly to make this code really dereference the array + descriptor and get the correct runtime type. However, that proved to + be tricky; it certainly can't be done for all access types, because + that will cause dynamic type resolution and end up printing just the + runtime type -- which with variants may be pretty far from what the + user may expect. + + Instead, this patch arranges to just leave such types alone in this + situation. I don't think this should have an extra effects, because + things like array subscripting still work on thick pointers. + + This patch also touches arrayptr.exp, because in that case the access + type is a "thin pointer", and this ensures that the output does not + change in that scenario. + +2024-03-18 Tom Tromey + + Use string_view in quirk_rust_enum + quirk_rust_enum makes string copies to store in an unordered_map. + However, the original strings have an appropriate lifetime, and so no + copying is needed. With C++17, we can rely on string_view having a + std::hash specialization, so this patch changes this code to use + string_view rather than string. + +2024-03-18 Tom Tromey + + Set __file__ when source'ing a Python script + This patch arranges to set __file__ when source'ing a Python script. + This fixes a problem that was introduced by the "source" rewrite, and + then pointed out by Lancelot Six. + + Reviewed-by: Lancelot Six + Approved-By: Andrew Burgess + +2024-03-18 Tom Tromey + + Clear board_info entry after waiting for process + When certain DAP tests are run in a certain order, dejagnu will throw + an exception during shutdown. After adding many logging statements, I + tracked this down to kill_wait_spawned_process not clearing the + 'fileid' board_info entry, causing dejagnu to try to wait for the + process a second time -- and fail. + + Tom de Vries then pointed out a second instance of this, which I + tracked down to the same problem occurring when spawning gdbserver. + + This version of the patch fixes this by adding a new proc that can be + used to clean up board_info after waiting for a process to exit. I'm + not sure why this problem hasn't affected the test suite in the past. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435 + Approved-By: Andrew Burgess + +2024-03-18 Clément Chigot + + bfd: add missing include + bdfio.c is defining bfd_get_current_time which is returning a time_t. + This type is defined in time.h and thus, must be included in bfd main + header to avoid undefined type when include bfd.h. + + Note that most of the time, is pulled by already + included in bfd.h. That's why it went unnoticed. + +2024-03-18 Nick Clifton + + Fix compiling bfd/vms-lib.c for a 32-bit host. + +2024-03-18 Andrew Burgess + + gdb/testsuite: attach to i386 process stopped in vDSO + Fedora GDB has carried around a patch for a while which tested + attaching to an i386 process which is stopped within the vDSO library + region. Apparently, at some point in the distant past there was an + issue finding symbol information for this region in this situation. + + I'm struggling to track down the precise details of what the original + bug was, however, acquiring symbol information for the vDSO region is + different than for "normal" shared libraries -- the vDSO information + is synthesised within GDB during the attach / inferior creation + process -- so it's not unreasonable to imagine that there could be a + bug specifically in this area of GDB which wouldn't impact "normal" + shared libraries. + + I looked for references to vDSO in our testsuite and couldn't find + any tests that looked like they did the same sort of thing, so I'd + like to propose adding this test to our testsuite. + + It's a pretty simple test, and doesn't take long to run, so the cost + of adding this is not huge. + + Approved-By: Tom Tromey + +2024-03-18 Jan Beulich + + Arm64: check matching operands for predicated B16B16 insns + Except for bfml{a,s} their 1st and 3rd operands need to match - pass + the TIED macro argument accordingly. While doing that also slightly + re-arrange table entries, such that all predicated insns are close + together. + + At the same time change the existing test source to actually use non- + matching operands for the respective bfml{a,s} forms. + +2024-03-18 Jan Beulich + + Arm64: correct B16B16 indexed bf{mla,mls,mul} + Their index is in bits 19, 20, and 22. Bit 11 in particular is already + set in the base opcode. Note also how disassembler output didn't match + assembler input in the respective testcase. + +2024-03-18 Nelson Chu + + RISC-V: Tidy smstateen and ssstateen testcases. + gas/ + * testsuite/gas/riscv/march-imply-smstateen.d: Added. + * testsuite/gas/riscv/smstateen-csr-s.d: Removed. + * testsuite/gas/riscv/ssstateen-csr.d: Likewise. + * testsuite/gas/riscv/ssstateen-csr.s: Likewise. + +2024-03-18 GDB Administrator + + Automatic date update in version.in + +2024-03-17 Tom de Vries + + [gdb/testsuite] Fix gdb.base/list-no-debug.exp on debian + On debian 12, aarch64-linux I run into: + ... + (gdb) list .^M + No symbol table is loaded. Use the "file" command.^M + (gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .' + ... + + The test-case expects some debug info, but none for main. Instead, there's no + debug info at all. + + Fix this by adding another source file to the test-case, and compiling it with + debug info. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + PR testsuite/31290 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290 + +2024-03-17 GDB Administrator + + Automatic date update in version.in + +2024-03-16 GDB Administrator + + Automatic date update in version.in + +2024-03-15 Tom Tromey + + Use size_t in gdb_bfd_section_data + BFD recently changed bfd_mmap to use size_t, not bfd_size_type. This + patch updates gdb_bfd_section_data to follow. Without this patch, if + the two types ever differ, gdb would fail to build. + + Approved-By: Simon Marchi + +2024-03-15 Andrew Carlotti + + gas/NEWS: Remove mention of AArch64 B16B16 extension + This aligns the 2.42 NEWS with the update backported to the 2.42 release + branch. + +2024-03-15 Jan Beulich + + x86/APX: legacy promoted insns can't access %xmm16-%xmm31 + Irrespective of the encoding being EVEX, the usable SIMD register range + continues to be limited to %xmm0-%xmm15. Enforce this in gas (but + continue to generate code, as in principle we know how to encode + things) and recognize/flag the case in the disassembler. + + Oddly enough wrong forms were actually used in the testsuite (register- + only forms are then really meaningless to test here, and are hence + dropped instead of adjusted). + + Convert the POP2 test that needs touching anyway (due to a bad ModR/M + byte having been chosen) to .insn. + +2024-03-15 GDB Administrator + + Automatic date update in version.in + +2024-03-14 Tom de Vries + + [gdb/build] Fix build on postmarketos + I tried building gdbserver on postmarketos (which is based on alpine linux, + which uses musl libc), and ran into: + ... + gdbserver/linux-low.cc: In lambda function: + gdbserver/linux-low.cc:1907:41: error: \ + 'W_EXITCODE' was not declared in this scope + 1907 | mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true); + | ^~~~~~~~~~ + ... + + The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h. + + OTOH, WSETEXIT is defined there, but unused: + ... + /* These are not defined in POSIX, but are used by our programs. */ + + #ifndef WSETEXIT + # ifdef W_EXITCODE + #define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0)) + # else + #define WSETEXIT(w,status) ((w) = (0 | ((status) << 8))) + # endif + #endif + ... + + Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE. + + Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make + sure the definition is exercised. + + Approved-By: Tom Tromey + + PR build/31483 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483 + +2024-03-14 Simon Marchi + + gdbserver/linux: probe for libiconv in configure + Make gdbserver's build system locate libiconv when building for Linux. + + Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names") + make libiconv madantory for building gdbserver on Linux. + + While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a + toolchain generated with crosstool-ng), I got: + + /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory + 48 | #include + | ^~~~~~~~~ + + I downloaded GNU libiconv, built it for that host, and installed it in + an arbitrary directory. I had to modify the gdbserver build system to + locate libiconv and use it, the result is this patch. + + I eventually found that crosstool-ng has a config option to make uclibc + provide an implementation of iconv, which is of course much easier. But + given that this patch is now written, I think it would be worth merging + it, it could help some people who do not have iconv built-in their libc + in the future (and may not have the luxury of rebuilding their libc like + I do). + + Using AM_ICONV in configure.ac adds these options for configure (the + same we have for gdb): + + --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib + --without-libiconv-prefix don't search for libiconv in includedir and libdir + --with-libiconv-type=TYPE type of library to search for (auto/static/shared) + + It sets the `LIBICONV` variable with whatever is needed to link with + libiconv, and adds the necessary `-I` flag to `CPPFLAGS`. + + To avoid unnecessarily linking against libiconv on hosts that don't need + it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the + host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`. + + Since libiconv is a hard requirement for Linux hosts, error out if it is + not found. + + The bits in acinclude.m4 are similar to what we have in + gdb/acinclude.m4. + + Update the top-level build system to support building against an in-tree + libiconv (I did not test this part though). Something tells me that the + all-gdbserver dependency on all-libiconv is unnecessary, since there is + already a dependency of configure-gdbserver on all-libiconv (and + all-gdbserver surely depends on configure-gdbserver). I just copied + what's done for GDB though. + + ChangeLog: + + * Makefile.def: Add configure-gdbserver and all-gdbserver + dependencies on all-libiconv. + * Makefile.in: Re-generate. + + Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4 + Approved-By: Tom Tromey + +2024-03-14 Tom Tromey + + Pass alignment when using GCC_C_FE_VERSION_2 + When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can + use the new 'finish_record_with_alignment' method. This lets gdb pass + alignment information to the compiler, which in turn fixes the test + case included in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-03-14 Tom Tromey + + Remove 'if' from GDB_PY_HANDLE_EXCEPTION + This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and + GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with + the old gdb try/catch macros, but it no longer is: these should only + ever be called from a 'catch' block, where it's already known that an + exception was thrown. + + Simon pointed out, though, that in a few spots, these were in facts + called outside of 'catch' blocks. This patch cleans up these spots. + I also found one spot where a redundant 'return nullptr' could be + removed. + +2024-03-14 Tom de Vries + + [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into: + ... + (gdb) watch data.u.size8twice[1]^M + Hardware watchpoint 241: data.u.size8twice[1]^M + (gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1] + continue^M + Continuing.^M + FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) + FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write + ... + + This happens as follows. + + We start the exec and set an 8-byte hardware watchpoint on + data.u.size8twice[1] at address 0x440048: + ... + (gdb) p sizeof (data.u.size8twice[1]) + $1 = 8 + (gdb) p &data.u.size8twice[1] + $2 = (uint64_t *) 0x440048 + ... + + We continue execution, and a 16-byte write at address 0x440040 triggers the + hardware watchpoint: + ... + 4101c8: a9000801 stp x1, x2, [x0] + ... + + When checking whether a watchpoint has triggered in + aarch64_stopped_data_address, we check against address 0x440040 (passed in + parameter addr_trap). This behaviour is documented: + ... + /* ADDR_TRAP reports the first address of the memory range + accessed by the CPU, regardless of what was the memory + range watched. ... */ + ... + and consequently the matching logic compares against an addr_watch_aligned: + ... + && addr_trap >= addr_watch_aligned + && addr_trap < addr_watch + len) + ... + + However, the comparison fails: + ... + (gdb) p /x addr_watch_aligned + $3 = 0x440048 + (gdb) p addr_trap >= addr_watch_aligned + $4 = false + ... + + Consequently, aarch64_stopped_data_address returns false, and + stopped_by_watchpoint returns false, and watchpoints_triggered returns 0, + which make infrun think it's looking at a delayed hardware + breakpoint/watchpoint trap: + ... + [infrun] handle_signal_stop: stop_pc=0x4101c8 + [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring + ... + Infrun then ignores the trap and continues, but runs into the same situation + again and again, causing a hang which then causes the test timeout. + + Fix this by allowing a match 8 bytes below addr_watch_aligned. This + introduces the possibility for false positives, so we only do this for regular + "value changed" watchpoints. + + An earlier version of this patch worked by aligning addr_watch_aligned to 16 + instead of 8: + ... + - const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8); + + const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16); + ... + but while that fixed the test-case, it didn't fix the problem completely, so + extend the test-case to check more scenarios. + + Tested on aarch64-linux. + + Tested-By: Luis Machado + Approved-By: Luis Machado + + PR tdep/29423 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + +2024-03-14 GDB Administrator + + Automatic date update in version.in + +2024-03-13 Tom Tromey + + Remove extraneous word from manual + I noticed that the manual has an extra "either", which makes a + sentence ungrammatical. This patch removes it. + +2024-03-13 Christophe Lyon + + opcodes: Fix build verbosity + Add $(AM_V_xxx) in a few places where they were missing. + +2024-03-13 H.J. Lu + + bfd: Use size_t in the BFD mmap interface + Change the size type in the BFD mmap interface from bfd_size_type to + size_t to be consistent with the size type of the host mmap interface. + + * bfdio.c (bfd_iovec): Change the bmmap size type to size_t. + (bfd_mmap): Likewise. + (memory_bmmap): Likewise. + * cache.c (cache_bmmap): Change the bmmap size type to size_t. + * opncls.c (opncls_bmmap): Change the bmmap size type to size_t. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-03-13 H.J. Lu + + bfd: Use MAP_FAILED for mmap failure + Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use + ((void *) -1) only if MAP_FAILED is undefined. + + * bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * bfdwin.c: Don't include . + (MAP_FILE): Removed. + (bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * cache.c: Don't include . + (cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap + failure. + * opncls.c (opncls_bmmap): Likewise. + * sysdep.h: Include if HAVE_MMAP is define. + (MAP_FILE): New. Defined as 0 if undefined. + (MAP_FAILED): New. Defined as ((void *) -1) if undefined. + +2024-03-13 H.J. Lu + + bfd: Don't call bfd_write with 0 size + There is no need to call bfd_write with 0 size. + + * elf-strtab.c (_bfd_elf_strtab_emit): Don't call bfd_write with + 0 size. + +2024-03-13 Hau Hsu + + RISC-V: Add -march=help for gas + Use -march=help for gas to print all supported extensions and versions. + + Here is part of the output of `as -march=help`: + All available -march extensions for RISC-V: + e 1.9 + i 2.1, 2.0 + m 2.0 + a 2.1, 2.0 + f 2.2, 2.0 + d 2.2, 2.0 + q 2.2, 2.0 + c 2.0 + v 1.0 + h 1.0 + zicbom 1.0 + zicbop 1.0 + ... + + This patch assumes that the supported extensions with the same versions + are listed together. For example: + static struct riscv_supported_ext riscv_supported_std_ext[] = + { + ... + {"i", ISA_SPEC_CLASS_20191213, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_20190608, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_2P2, 2, 0, 0 }, + ... + }; + + For the "i" extension, 2.1.0 with different spec class are listed together. + This patch records the previous printed extension and version. If the + current extension and version are the same as the previous one, skip + printing. + + bfd/ + * elfxx-riscv.c (riscv_print_extensions): New function. Print + available extensions and versions. + * elfxx-riscv.h (riscv_print_extensions): New declaration. + gas/ + * gas/config/tc-riscv.c (md_parse_option): Parse 'help' keyword in + -march option to print available extensions and versions. + * testsuite/gas/riscv/march-help.l: New testcase for -march=help. + * testsuite/gas/riscv/riscv.exp: Updated. + +2024-03-13 GDB Administrator + + Automatic date update in version.in + +2024-03-12 Tom de Vries + + [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Hardware watchpoint 2: -location q.a^M + ^M + Old value = 1^M + New value = 0^M + main () at watch-bitfields.c:42^M + 42 q.h--;^M + (gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue + ... + + In a minimal form, if we step past line 37 which sets q.e, and we have a + watchpoint set on q.e, it triggers: + ... + $ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step + Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37. + + Breakpoint 1, main () at watch-bitfields.c:37 + 37 q.e = 5; + Hardware watchpoint 2: q.e + + Hardware watchpoint 2: q.e + + Old value = 0 + New value = 5 + main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38 + 38 q.f = 6; + ... + + However, if we set in addition a watchpoint on q.a, the watchpoint on q.e + doesn't trigger. + + How does this happen? + + Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1 + and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should + watch bytes 1 and 2. + + Using "maint set show-debug-regs on" (and some more detailed debug prints) we + get: + ... + WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1 + ctrl: enabled=1, offset=1, len=2 + WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1 + ctrl: enabled=1, offset=0, len=1 + ... + which matches that. + + When executing line 37, a hardware watchpoint trap triggers and we hit + aarch64_stopped_data_address with addr_trap == 0x440028: + ... + (gdb) p /x addr_trap + $1 = 0x440028 + .... + and since the loop in aarch64_stopped_data_address walks backward, we check + WP3 first, which matches, and consequently target_stopped_by_watchpoint + returns true in watchpoints_triggered. + + Likewise for target_stopped_data_address, which also returns addr == 0x440028. + Watchpoints_triggered matches watchpoint q.a to that address, and sets + watch_triggered_yes. + + However, subsequently the value of q.a is checked, and it's the same value as + before (becase the insn in line 37 didn't change q.a), so the watchpoint + hardware trap is not reported to the user. + + The problem originates from that fact that aarch64_stopped_data_address picked + WP3 instead of WP2. + + There's something we can do about this. In the example above, both + target_stopped_by_watchpoint and target_stopped_data_address returned true. + Instead we can return true in target_stopped_by_watchpoint but false in + target_stopped_data_address. This lets watchpoints_triggered known that a + watchpoint was triggered, but we don't know where, and both watchpoints + get set to watch_triggered_unknown. + + Subsequently, the values of both q.a and q.e are checked, and since q.e is not + the same value as before, the watchpoint hardware trap is reported to the user. + + Note that this works well for regular (write) watchpoints (watch command), but + not for read watchpoints (rwatch command), because for those no value is + checked. Likewise for access watchpoints (awatch command). + + So, fix this by: + - passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and + aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not + interested in the stop address, + - introducing a two-phase approach in aarch64_stopped_data_address, where: + - phase one handles access and read watchpoints, as before, and + - phase two handles write watchpoints, where multiple matches cause: + - return true if addr_p == null, and + - return false if addr_p != null. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + + PR tdep/31214 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214 + +2024-03-12 Sam James + + contrib: sync dg-extract-results.sh with GCC + This syncs dg-extract-results.sh with GCC. + + It contains two commits: r14-4333-g346f5991569fae and r14-9393-g64273a7e6bd8ba. + + contrib/ChangeLog: + * dg-extract-results.sh: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Sam James + + contrib: sync dg-extract-results.py with GCC + This syncs dg-extract-results.py with GCC. + + It contains only one commit: r14-7145-g8f67953d0198fe. + + contrib/ChangeLog: + * dg-extract-results.py: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Schimpe, Christina + + gdb: Deprecate MPX commands. + This patch deprecates the MPX commands "show/set mpx bound". + Intel listed Intel(R) Memory Protection Extensions (MPX) as removed + in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35, + deprecate MPX in GDB. + +2024-03-12 Lulu Cai + + LoongArch: Scan all illegal operand instructions without interruption + Currently, gas will exit immediately and report an error when + it sees illegal operands, and will not process the remaining + instructions. Replace as_fatal with as_bad to check for all + illegal operands. + + Add test cases for illegal operands of some instructions. + +2024-03-12 Lulu Cai + + LoongArch: Fix gas and ld test cases + * After adding the old LE relax, all old LE relocations will have + an R_LARCH_RELAX relocation. Fix the gas test case failure caused + by the implementation of the old LE relax. + + * loongarch64-elf does not support pie and -z norelro options, + removed in test files. + +2024-03-12 Simon Marchi + + gnulib: re-generate build files + I see some changes in the generated files when running update-gnulib.sh. + The changes appeared with commit 35b38b0182d0 ("Finalized intl-update + patches (trois)"). This is most likely due to how the autotools were + ran in that commit, possibly with some different -I arguments. + + Change-Id: Idaad8084b0e91e22d066f573775e21d0c7a039cb + +2024-03-12 GDB Administrator + + Automatic date update in version.in + +2024-03-11 Sam James + + Sync libbacktrace from gcc [PR31327] + Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which + landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC. + + This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk. + + Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b + which would've required an autoreconf, as it should be handled separately. + + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Remove tui-out.[ch] + The other day on irc, we were discussing the "m_line" hack in + tui-out.c, and I mentioned that it would be nice to replace this with + a new ui_out_flag. + + Later, I looked at ui_out_flag and found: + + ui_source_list = (1 << 0), + + ... and sure enough, this is tested already. + + This patch removes tui-out.[ch] and changes the TUI to use an ordinary + cli-out object without this flag set. + + As far as I can tell, this doesn't affect behavior at all -- the TUI + tests all pass, and interactively I tried switching stack frames, + "list", etc, and it all seems to work. + + New in v2: fixed the problem pointed out by Keith, and added a test + case for that scenario. + + Reviewed-By: Andrew Burgess + +2024-03-11 Simon Marchi + + gdb/Makefile.in: remove ACLOCAL_AMFLAGS + aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in + configure.ac, so there's no need to pass `-I ../config` here. + + Passing `-I ../config` is actually annoying, because it makes the output + different between when the update is triggered by the maintainer mode + and when aclocal or autoreconf is ran with no special flags. The + difference in the output is due to the order of include paths being + different. + + Change-Id: I2c963876516570842f20b4a6a470867e7a941006 + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Special case NULL pointers in dynamic type resolution + commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically") + caused a regression on a test case in the AdaCore internal test suite. + + The issue here is that gdb would try to resolve the type of a dynamic + pointer that happened to be NULL. In this case, the "Location address + is not set." error would end up being thrown from the DWARF expression + evaluator. + + I think it makes more sense to special-case NULL pointers and not try + to resolve their target type, as that type can't really be accessed + anyway. + + This patch implements this idea, and also adds the missing Ada test + case. + +2024-03-11 Andrew Burgess + + gdb/testsuite: reformat file with a more recent version of black + A Python file in my previous commit (5eb2254a1d1) was formatted with + an older version of black, which gives slightly different results. + + Reformat with a newer version of black. This should make our + post-commit testing happy again. + + No functional changes in this commit. + +2024-03-11 Nick Alcock + + libctf: fix uninitialized variables in testsuite + Just because a path is an error path doesn't mean the program terminates + there if you don't ask it to. And we don't want to -- but that means + we need to initialize the variables that are missed if an error happens to + *something*. Type ID 0 (unimplemented) will do: it'll induce further + ECTF_BADID errors, but that's no bad thing. + + libctf/ChangeLog: + + * testsuite/libctf-writable/libctf-errors.c: Initialize variables. + +2024-03-11 Simon Marchi + + gdb: re-generate aclocal.m4 + I get some changes when running `autoreconf -vf` in the gdb directory, + fix that. + + I did a bisect, it appears to have been introduced in this commit, not + sure why we haven't spotted that before. + + commit 862776f26a59516467c98091994c3dac90383159 + Author: Arsen Arsenovi? + AuthorDate: Wed Nov 15 12:53:04 2023 +0000 + Commit: Nick Clifton + CommitDate: Wed Nov 15 12:53:04 2023 +0000 + + Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9 + +2024-03-11 Markus Metzger + + gdb, btrace: fix error diagnostics + When we improved error messages in + + cd393cec3ab gdb, btrace: improve error messages + + we cleared the original errno. When the error reason can not be explained + in a more detailed error message, and we fall back to the default error + message, it now gives Success as error. + + Restore the original errno to fix that. + +2024-03-11 Andrew Burgess + + gdb/unwinders: better support for $pc not saved + This started with a Red Hat bug report which can be seen here: + + https://bugzilla.redhat.com/show_bug.cgi?id=1850710 + + The problem reported here was using GDB on GNU/Linux for S390, the + user stepped into JIT generated code. As they enter the JIT code GDB + would report 'PC not saved', and this same message would be reported + after each step/stepi. + + Additionally, the user had 'set disassemble-next-line on', and once + they entered the JIT code this output was not displayed, nor were any + 'display' directives displayed. + + The user is not making use of the JIT plugin API to provide debug + information. But that's OK, they aren't expecting any source level + debug here, they are happy to use 'stepi', but the missing 'display' + directives are a problem, as is the constant 'PC not saved' (error) + message. + + What is happening here is that as GDB is failing to find any debug + information for the JIT generated code, it is falling back on to the + S390 prologue unwinder to try and unwind frame #0. Unfortunately, + without being able to identify the function boundaries, the S390 + prologue scanner can't help much, in fact, it doesn't even suggest an + arbitrary previous $pc value (some targets that use a link-register + will, by default, assume the link-register contains the previous $pc), + instead the S390 will just say, "sorry, I have no previous $pc value". + + The result of this is that when GDB tries to find frame #1 we end + throwing an error from frame_unwind_pc (the 'PC not saved' error). + This error is not caught anywhere except at the top-level interpreter + loop, and so we end up skipping all the 'display' directive handling. + + While thinking about this, I wondered, could I trigger the same error + using the Python Unwinder API? What happens if a Python unwinder + claims a frame, but then fails to provide a previous $pc value? + + Turns out that exactly the same thing happens, which is great, as that + means we now have a way to reproduce this bug on any target. And so + the test included with this patch does just this. I have a Python + unwinder that claims a frame, but doesn't provide any previous + register values. + + I then do two tests, first I stop in the claimed frame (i.e. frame #0 + is the frame that can't be unwound), I perform a few steps, and check + the backtrace. And second, I stop in a child of the problem + frame (i.e. frame #1 is the frame that can't be unwound), and from + here I check the backtrace. + + While all this is going on I have a 'display' directive in place, and + each time GDB stops I check that the display directive triggers. + + Additionally, when checking the backtrace, I am checking that the + backtrace finishes with the message 'Backtrace stopped: frame did not + save the PC'. + + As for the fix I chose to add a call to frame_unwind_pc directly to + get_prev_frame_always_1. Calling frame_unwind_pc will cache the + unwound $pc value, so this doesn't add much additional work as + immediately after the new frame_unwind_pc call, we call + get_prev_frame_maybe_check_cycle, which actually generates the + previous frame, which will always (I think) require a call to + frame_unwind_pc anyway. + + The reason for adding the frame_unwind_pc call into + get_prev_frame_always_1, is that if the frame_unwind_pc call fails we + want to set the frames 'stop_reason', and get_prev_frame_always_1 + seems to be the place where this is done, so I wanted to keep the new + stop_reason setting code next to all the existing stop_reason setting + code. + + Additionally, once we enter get_prev_frame_maybe_check_cycle we + actually create the previous frame, then, if it turns out that the + previous frame can't be created we need to remove the frame .. this + seemed more complex than just making the check in + get_prev_frame_always_1. + + With this fix in place the original S390 bug is fixed, and also the + test added in this commit, that uses the Python API, is also fixed. + + Reviewed-By: Kevin Buettner + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Reduce gdb.threads/threadcrash.exp reliance on libc symbols + The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and + print the names of all functions. However, some of the functions are + from the libc library, and so the test implicitly demanded libc symbols + to be available, and would fail otherwise, as was raised in PR + gdb/31293. + + This commit changes it so we only explicitly check for functions that + are not provided by threadcrash.c if they are indeed available. + + Tested on arm-linux and x86_64-linux. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293 + +2024-03-11 Tom de Vries + + gdb/testsuite: Simplify gdb.threads/threadcrash.exp + I noticed in gdb.threads/threadcrash.exp that the usage of test_list is + somewhat convoluted. + + Simplify the test-case by storing a classification instead of a pattern in + test_list. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Use _inferior_thread_count in gdb.threads/threadcrash.exp + A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails + to cout the number of threads in the inferior: + ... + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7 + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list] + ... + + Fix this by getting the convenience variable _inferior_thread_count as opposed + to calculating it based on the output of "info threads". + + Tested on arm-linux and x86_64-linux. + + Reviewed-By: Lancelot Six + Approved-By: Tom de Vries + + [1] https://linaro.atlassian.net/browse/GNU-1120 + +2024-03-11 Tom de Vries + + gdb/testsuite: Fix gdb.threads/threadcrash.exp with check-readmore + With check-readmore, I run into: + ... + FAIL: gdb.threads/threadcrash.exp: test_corefile: \ + $thread_count == [llength $test_list] + ... + + The problem is that the clauses in the gdb_test_multiple for + "thread apply all backtrace" intent to match one line, but actually can + match more than one line, and consequently a match for one type of thread can + consume a line that was supposed to match another thread. + + For instance, there's this regexp: + ... + -re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" { + ... + + It's limited at the end by \[^\n\]*, meaning the match stops at the end of the + line. + + But it doesn't start with a ^, and consequently can match more than one line. + The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at + the start of each pattern, unless it's anchored using a ^. + + Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where: + - hs is: \[^\n\]* (horizontal space), and + - eol is (?=\r\n) (look-ahead end-of-line). + + It also turned out to be necessary to drop the -lbl switch, and introduce a + corresponding explicit clause. The -lbl clause is placed ALAP, and + consequently allowed the default fail clause to trigger. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Tom de Vries + + gdb/testsuite: Reduce indentation in gdb.threads/threadcrash.exp + In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented + gdb_test_multiple: + ... + gdb_test_multiple "thread apply all backtrace" \ + "Get thread information" -lbl { + -re "#\[0-9\]+\\\?\\\?\[^\n\]*" { + ... + + Fix this by moving the command into a variable, allowing the + "gdb_test_multiple ... {" to fit on a single 80 chars line. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Jan Beulich + + x86: KeyLocker insn interaction with -msse-check / .sse_check + Some of these have no explicit %xmm operand(s), yet they still act SSE- + like (in leaveing bits 128 and up untouched). Hence they want similarly + diagnosing, if that was asked for. + + x86/APX: permit wider than 4-bit immediates with V{EXTRACT,INSERT}{F,I}128 + These aren't useful, but can be encoded for their AVX forms and hence + should also be permitted for the APX surrogates. Extend the respective + conditional by a base opcode check, to restrict it to VROUND{P,S}{S,D}. + + x86: don't open-code REG_{SP,FP} + Since we have the #define-s, we should also use them. + +2024-03-11 Stephen Kitt + + tests: force non-deterministic mode in non-deterministic tests + Since ar can be built defaulting to deterministic mode, tests which + expect non-deterministic behaviour need to explicitly set the U flag. + + The non-deterministic member test expects SOURCE_DATE_EPOCH to not be + set; this documents that. Unconditionally unsetting the variable + causes issues in test infrastructure (which expects unsetenv to only + be called on variables which are already set). + +2024-03-11 GDB Administrator + + Automatic date update in version.in + +2024-03-10 GDB Administrator + + Automatic date update in version.in + +2024-03-09 Tom de Vries + + [gdb/python] Handle deprecation of PyErr_{Fetch,Restore} in 3.12 + Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated. + + Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for + python >= 3.12. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Normalize exceptions in gdbpy_err_fetch + With python 3.12, I run into: + ... + (gdb) PASS: gdb.python/py-block.exp: check variable access + python print (block['nonexistent'])^M + Python Exception : 'nonexistent'^M + Error occurred in Python: 'nonexistent'^M + (gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable + ... + + The problem is that that PyErr_Fetch returns a normalized exception, while the + test-case matches the output for an unnormalized exception. + + With python 3.6, PyErr_Fetch returns an unnormalized exception, and the + test passes. + + Fix this by: + - updating the test-case to match the output for a normalized exception, and + - lazily forcing normalized exceptions using PyErr_NormalizeException. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Use gdbpy_err_fetch::{type,value} as getters + Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use + both consistently to get gdbpy_err_fetch members m_error_value and + m_error_type. + + Tested on aarch64-linux. + +2024-03-09 Alan Modra + + Reinstate bfd_print_error as an extern function + * bfd.c (_bfd_print): Renamed from bfd_print_error. + (bfd_print_error): Reinstate previous code but using the above. + (error_handler_fprintf, error_handler_sprintf): Adjust. + * bfd-in2.h: Regenerate. + +2024-03-09 Alan Modra + + Re: Move bfd_init to bfd.c + Commit b1c95bc4dd73 cleared some bfd static variables, with bad + results since bfd_set_error_program_name is often called before + bfd_init. + + * bfd.c (bfd_init): Don't clear _bfd_error_program_name. + +2024-03-09 Alan Modra + + print cached error messages using _bfd_error_handler + * bfd.c (bfd_print_error): Make static. Don't print program name. + (error_handler_fprintf): Print program name here. + * format.c (print_warnmsg): Use _bfd_error_handler to print + cached messages. + * bfd-in2.h: Regenerate. + +2024-03-09 Tom Tromey + + Avoid race when writing to index cache + The background DWARF reader changes introduced a race when writing to + the index cache. The problem here is that constructing the + index_cache_store_context object should only happen on the main + thread, to ensure that the various value captures do not race. + + This patch adds an assert to the construct to that effect, and then + arranges for this object to be constructed by the cooked_index_worker + constructor -- which is only invoked on the main thread. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262 + +2024-03-09 Tom Tromey + + Move the 'store' method to index_cache_store_context + I think it is cleaner for 'store' to be a method on + index_cache_store_context rather than on the global index cache + itself. This patch makes this change. + + Capture the per-BFD object in index_cache_store_context + This changes index_cache_store_context to also capture the per-BFD + object when it is constructed. This is used when storing to the + cache, and this approach makes the code a little simpler. + + Capture directory in index_cache_store_context + I noticed that index_cache_store_context captures the 'enabled' + setting, but not the index cache directory. This patch makes this + change, which avoids a possible race -- with background reading, the + user could possibly change this directory at the exact moment the + writer examines the variable. + + Rename members of index_cache_store_context + This renames the private members of index_cache_store_context to start + with "m_". + +2024-03-09 GDB Administrator + + Automatic date update in version.in + +2024-03-08 Tom Tromey + + Add return value to DAP scope + A bug report in the DAP specification repository pointed out that it + is typical for DAP implementations to put a function's return value + into the outermost scope. + + This patch changes gdb to follow this convention. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341 + Reviewed-By: Kévin Le Gouguec + +2024-03-08 Tom Tromey + + Export "finish" return value to Python + This patch changes the Python "stop" event emission code to also add + the function return value, if it is known. This happens when the stop + comes from a "finish" command and when the value can be fetched. + + The test is in the next patch. + + Reviewed-By: Eli Zaretskii + +2024-03-08 H.J. Lu + + gas: Fix x86 build with GCC 6.4 + Add "()" to silence GCC 6.4: + + .../gas/config/tc-i386.c: In function ‘x86_ginsn_lea’: + .../gas/config/tc-i386.c:5738:19: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses] + if (!i.base_reg != (!i.index_reg || i.index_reg->reg_num == RegIZ)) + ^~ + cc1: all warnings being treated as errors + + PR gas/31464 + * config/tc-i386.c (x86_ginsn_lea): Add "()" to silence GCC 6.4. + +2024-03-08 Tom Tromey + + Avoid race when reading dwz file + PR gdb/31260 points out a race introduced by the background reading + changes. If a given objfile is re-opened when it is already being + read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again, + causing the 'dwz_file' to be reset. + + This patch fixes the problem by arranging to open the dwz just once: + when the dwarf2_per_bfd object is created. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31260 + +2024-03-08 H.J. Lu + + bfd: Change the --with-mmap default to true + Change the configure default to using mmap. + + * configure.ac: Change the --with-mmap default to true. + * configure: Regenerated. + +2024-03-08 H.J. Lu + + bfd: Don't hard-code BFD_JUMP_TABLE_COPY + In BFD_JUMP_TABLE_COPY, replace _bfd_generic_init_private_section_data + with NAME##_init_private_section_data so that ELF targets can properly + replace it with _bfd_elf_init_private_section_data. + + * aout-target.h (MY_init_private_section_data): New. + * coff-rs6000.c (_bfd_xcoff_init_private_section_data): New. + * coffcode.h (coff_init_private_section_data): New. + * elfxx-target.h (bfd_elfNN_init_private_section_data): New. + * libecoff.h (_bfd_ecoff_init_private_section_data): New. + * mach-o-target.c (bfd_mach_o_init_private_section_data): New. + * mmo.c (mmo_init_private_section_data): New. + * plugin.c (bfd_plugin_init_private_section_data): New. + * ppcboot.c (ppcboot_init_private_section_data): New. + * som.c (som_init_private_section_data): New. + * targets.c (BFD_JUMP_TABLE_COPY): Replace + _bfd_generic_init_private_section_data with + NAME##_init_private_section_data. + * vms-alpha.c (vms_init_private_section_data): New. + * elf-bfd.h (_bfd_generic_init_private_section_data): Removed. + * bfd-in2.h: Regenerated. + +2024-03-08 Jiawei + + RISC-V: Support Zabha extension. + The Zabha extension[1] supports for byte and halfword + atomic memory operations. This patch add all instructions + include in Zabha. Further work is waiting Zacas[2] merge. + + [1] https://github.com/riscv/riscv-zabha/tags + [2] https://sourceware.org/pipermail/binutils/2023-May/127700.html + + Version log: + Add new imply relation that Zabha extension implies A extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): New imply. + (riscv_multi_subset_supports): New extension. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New test. + * testsuite/gas/riscv/zabha.d: New test. + * testsuite/gas/riscv/zabha.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOADD_B): New opcodes. + (MASK_AMOADD_B): Ditto. + (MATCH_AMOXOR_B): Ditto. + (MASK_AMOXOR_B): Ditto. + (MATCH_AMOOR_B): Ditto. + (MASK_AMOOR_B): Ditto. + (MATCH_AMOAND_B): Ditto. + (MASK_AMOAND_B): Ditto. + (MATCH_AMOMIN_B): Ditto. + (MASK_AMOMIN_B): Ditto. + (MATCH_AMOMAX_B): Ditto. + (MASK_AMOMAX_B): Ditto. + (MATCH_AMOMINU_B): Ditto. + (MASK_AMOMINU_B): Ditto. + (MATCH_AMOMAXU_B): Ditto. + (MASK_AMOMAXU_B): Ditto. + (MATCH_AMOSWAP_B): Ditto. + (MASK_AMOSWAP_B): Ditto. + (MATCH_AMOADD_H): Ditto. + (MASK_AMOADD_H): Ditto. + (MATCH_AMOXOR_H): Ditto. + (MASK_AMOXOR_H): Ditto. + (MATCH_AMOOR_H): Ditto. + (MASK_AMOOR_H): Ditto. + (MATCH_AMOAND_H): Ditto. + (MASK_AMOAND_H): Ditto. + (MATCH_AMOMIN_H): Ditto. + (MASK_AMOMIN_H): Ditto. + (MATCH_AMOMAX_H): Ditto. + (MASK_AMOMAX_H): Ditto. + (MATCH_AMOMINU_H): Ditto. + (MASK_AMOMINU_H): Ditto. + (MATCH_AMOMAXU_H): Ditto. + (MASK_AMOMAXU_H): Ditto. + (MATCH_AMOSWAP_H): Ditto. + (MASK_AMOSWAP_H): Ditto. + (DECLARE_INSN): New declare. + * opcode/riscv.h (enum riscv_insn_class): New class. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-03-08 GDB Administrator + + Automatic date update in version.in + +2024-03-07 GDB Administrator + + Automatic date update in version.in + +2024-03-06 Nick Clifton + + Add "-j1" to make command lines in the create-a-release README. + +2024-03-06 Lulu Cai + + LoongArch: Fix some test cases for TLS transition and relax + + LoongArch: Add dtpoff calculation function + When tls_sec is NULL, we should not access the virtual address + of tls_sec. + +2024-03-06 Lulu Cai + + LoongArch: Delete extra instructions when TLS type transition + This modification mainly changes the timing of type transition, + adds relaxation to the old LE instruction sequence, and fixes + bugs in extreme code models. + + We strictly distinguish between type transition and relaxation. + Type transition is from one type to another, while relaxation + is the removal of instructions under the same TLS type. Detailed + instructions are as follows: + + 1. For type transition, only the normal code model of DESC/IE + does type transition, and each relocation is accompanied by a + RELAX relocation. Neither abs nor extreme will do type transition, + and no RELAX relocation will be generated. + The extra instructions when DESC transitions to other TLS types + will be deleted during the type transition. + + 2. Implemented relaxation for the old LE instruction sequence. + The first two instructions of LE's 32-bit and 64-bit models + use the same relocations and cannot be distinguished based on + relocations. Therefore, for LE's instruction sequence, any code + model will try to relax. + + 3. Some function names have been adjusted to facilitate understanding, + parameters have been adjusted, and unused macros have been deleted. + +2024-03-06 Alan Modra + + Don't use bfd_error_handler in bfd_abort + We don't want to lose an abort message when bfd_set_error_handler has + been called to ignore or cache errors. + + PR ld/31444 + * bfd.c (_bfd_abort): Don't use _bfd_error_handler. + +2024-03-06 GDB Administrator + + Automatic date update in version.in + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.trace/circ.exp + This fixes some duplicate test names in gdb.trace/circ.exp when using + native-gdbserver and native-extended-gdbserver boards. + + In this test we set the trace buffer size twice. The same test name + was used each time the size was adjusted. + + I've fixed this issue by: + + 1. Creating a new proc, set_trace_buffer_size, which factors out the + code to change the buffer size, and uses test names based on the + size we're setting the buffer too, + + 2. Calling the new proc each time we want to adjust the buffer size. + + After this the duplicate test names are resolved. There should be no + change in what is tested after this commit. + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix some more duplicate test names in gdb.trace/ + This commit fixes some duplicate test names in the gdb.trace/ + directory when run with the native-gdbserver and + native-extended-gdbserver boards. In this case the duplicates relate + to the calls to gdb_compile_pthreads which emits a fixed PASS message, + as there are two calls to gdb_compile_pthreads we get a duplicate PASS + message. + + In both cases the problem is fixed by adding a with_test_prefix around + one of the compilations, however, I've made additional changes to + clean up the tests a little while I was working on them: + + 1. Switch to use prepare_for_testing instead of + gdb_compile_pthreads. By passing the 'pthreads' option this does + call gdb_compile_pthreads under the hood, but using the standard + compile function is cleaner, + + 2. Using prepare_for_testing removes the need to call clean_restart + immediately afterwards, so those calls are removed, + + 3. I removed the unneeded $executable and $expfile globals, where + the $executable global was used I've replaced this with $binfile, + + 4. When we compile two executables I've now given these different + names so that both exist at the end of the test run, + + 5. Removed a gdb_reinitialize_dir call, this is covered by + clean_restart, + + 6. Use gdb_test_no_output where it makes sense. + + I now see no duplicate test names when running these test scripts. + There should be no change in what is being tested after this commit. + +2024-03-05 Lulu Cai + + LoongArch: Add gas testsuit for LA32 relocations + Test the relocation of the LA32 instruction set. + + LoongArch: Add gas testsuit for LA64 relocations + Test the relocation of the LA64 instruction set. + + LoongArch: Add gas testsuit for LA32 int/float instructions + Test the int/float instructions of LA32. + + LoongArch: Add gas testsuit for LA64 int/float instructions + Test the int/float instructions of LA64. + + LoongArch: Add gas testsuit for lsx/lasx instructions + Test the LSX/LASX instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for lbt/lvz instructions + Test the LBT/LVZ instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for alias instructions + Test the alias instructions. + +2024-03-05 GDB Administrator + + Automatic date update in version.in + +2024-03-04 GDB Administrator + + Automatic date update in version.in + +2024-03-03 GDB Administrator + + Automatic date update in version.in + +2024-03-02 Hui Li + + gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35 + There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())" + in find_register_by_number() when gdb connects to gdbserver, this + is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains + 10 reserved regs) is different with the number of regs (35, which not + contains 10 reserved regs) in file gdb/features/loongarch/base64.xml. + Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to + keep consistent with the gdb/features/loongarch/base64.xml, and then + define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that + all the reg numbers in regcache are consistent with tdesc reg numbers. + + without this patch: + + Execute on the target machine: + + $ gdbserver 192.168.1.123:5678 ./test + + Execute on the host machine: + + $ gdb ./test + (gdb) target remote 192.168.1.123:5678 + + Output on the target machine: + + Process ./test created; pid = 67683 + Listening on port 5678 + Remote debugging from host 192.168.1.136, port 6789 + gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected. + find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed. + + Output on the host machine: + + Remote debugging using 192.168.1.123:5678 + Remote connection closed + + Approved-By: John Baldwin + +2024-03-02 Tom Tromey + + Fix TUI text centering + In a couple of spots, the TUI tries to center some text in the window. + Andrew noticed that the calculation is done strangely and the text + ends up somewhat to the left of center. + + This patch fixes the problem. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31355 + +2024-03-02 GDB Administrator + + Automatic date update in version.in + +2024-03-01 Will Hawkins + + gdb/jit: Fix missing word in comment + ChangeLog: + + * gdb/jit.c: Fix missing word in code comment. + +2024-03-01 Jens Remus + + s390: Be more verbose about missing operand type + Provide expected operand type in s390-specific assembler operand parsing + error message: + + "error: operand : missing operand" + + With being one of: + - base register + - displacement + - [vector] index register + - length + - access register + - control register + - floating-point register + - general-purpose register + - vector register + - [un]signed number + + gas/ + * config/tc-s390.c: Provide missing operand type in error + message. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + result validation patterns to operand number in operand syntax + error messages. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Provide operand number in assembler warning and error messages + Prepend the operand number "operand %d:" to the s390-specific assembler + operand parsing warning and error messages. + + While at it reword the custom operand out of range error message text to + be closer to the one used by as_bad_value_out_of_range(). Additionally + reword the invalid FPR pair warning message to make it nicer. + + gas/ + * config/tc-s390.c: Print operand number in error messages. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + verification patterns to accept syntax error messages now + containing the operand number. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + * testsuite/gas/s390/zarch-z900-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Allow to explicitly omit base register operand in assembly + The base register operand B may be omitted in D(B) by coding D and in + D(L,B) by coding D(L). The index register operand X may be omitted in + D(X,B) by coding D(B) or explicitly omitted by coding D(,B). In both + cases the omitted base register operand value defaults to zero. + + Allow to explicitly omit the base register operand B in D(X,B) and + D(L,B) by coding D(X,) and D(L,). Default the omitted base register + operand value to zero. + + gas/ + * config/tc-s390.c: Allow to explicitly omit the base register + operand in assembly. + * NEWS: Mention that the base register now may be omitted on + s390. + * gas/testsuite/gas/s390/zarch-base-index-0.s: Update test cases + for change to allow to explicitly omit the base register + operand in assembly. + * gas/testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.s: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.l: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.s: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.l: + Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Print base register 0 as "0" in disassembly + Base and index register 0 have no effect in address computation: + + "A value of zero in the B [base] or X [index] field specifies that no + base or index is to be applied, and, thus, general register 0 cannot be + designated as containing a base address or index." + IBM z/Architecture Principles of Operation [1], chapter "Organization", + section "General Registers". + + Index register 0 is omitted in the s390 disassembly. Base register 0 is + omitted in D(B), D(L,B) and D(X,B) - the latter only if the index + register is zero. + + To make it more apparent print base register 0 as "0" instead of "%r0", + whenever it would still be printed in the disassembly. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + opcodes/ + * s390-dis.c: Print base register 0 as "0" in disassembly. + + binutils/ + * NEWS: Mention base register 0 now being printed as "0" in s390 + disassembly. + + gas/ + * testsuite/gas/s390/zarch-base-index-0.d: Update test case + output verification patterns to accept "0" as base base + register due to disassembler output format change. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Warn when register name type does not match operand + Print a warning message when the register type of a specified register + name does not match with the operand's register type: + + operand {#}: expected {access|control|floating-point|general|vector} + register name [as {base|index} register] + + Introduce a s390-specific assembler option "warn-regtype-mismatch" + with the values "strict", "relaxed", and "no" as well as an option + "no-warn-regtype-mismatch" which control whether the assembler + performs register name type checks and generates above warning messages. + + warn-regtype-mismatch=strict: + Perform strict register name type checks. + + warn-regtype-mismatch=relaxed: + Perform relaxed register name type checks, which allow floating-point + register (FPR) names %f0 to %f15 to be specified as argument to vector + register (VR) operands and vector register (VR) names %v0 to %v15 to + be specified as argument to floating-point register (FPR) operands. + This is acceptable as the FPRs are embedded into the lower halves of + the VRs. Make "relaxed" the default, as GCC generates assembler code + using FPR and VR interchangeably, which would cause assembler warnings + to be generated with "strict". + + warn-regtype-mismatch=no: + no-warn-regtype-mismatch: + Disable any register name type checks. + + Tag .insn pseudo mnemonics as such, to skip register name type checks + on those. They need to be skipped, as there do not exist .insn pseudo + mnemonics for every possible operand register type combination. Keep + track of the currently parsed operand number to provide it as reference + in warning messages. + + To verify that the introduction of this change does not unnecessarily + affect the compilation of existing code the GNU Binutils, GNU C Library, + and Linux Kernel have been build with the new assembler, verifying that + the assembler did not generate any of the new warning messages. + + gas/ + * config/tc-s390.c: Handle new assembler options + "[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate + parsed register expressions with register type. Keep track of + operand number being parsed. Print warning message in case of + register type mismatch between instruction operand and parsed + register expression. + * doc/as.texi: Document new s390-specific assembler options + "[no-]warn-regtype-mismatch[=strict|relaxed|no]". + * NEWS: Mention new s390-specific register name type checks and + related assembler option "warn-regtype-mismatch=strict| + relaxed|no". + * testsuite/gas/s390/s390.exp: Add test cases for new assembler + option "warn-regtype-mismatch={strict|relaxed}". + * testsuite/gas/s390/esa-g5.s: Fix register types in tests for + didbr, diebr, tbdr, and tbedr. + * testsuite/gas/s390/zarch-z13.s: Fix register types in tests + for vgef, vgeg, vscef, and vsceg. + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s: + Tests for assembler option "warn-regtype-mismatch=strict". + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l: + Likewise. + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s: + Tests for assembler option "warn-regtype-mismatch=relaxed". + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update + test cases for assembler option "warn-regtype-mismatch" + defaulting to "relaxed". + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + include/ + * opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add + instruction flag to tag .insn pseudo-mnemonics. + + opcodes/ + * s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as + such. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Revise s390-specific assembler option descriptions + Reorder, reword, and complete the s390-specific option descriptions. + Align the formatting of s390-specific assembler options to that of the + general assembler options in "as --help". + + While at it change a warning message to use the term "z/Architecture" + instead of the deprecated "esame" (ESA Modal Extensions or ESAME) one. + + gas/ + * config/tc-s390.c: Revise s390-specific assembler option + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test case for disassembler option warn-areg-zero + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for s390-specific + assembler option "warn-areg-zero". + * testsuite/gas/s390/zarch-warn-areg-zero.s: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test cases for base/index register 0 + While at it add comments to logic to omit base and/or index register 0 + in s390 disassembly. + + opcodes/ + * s390-dis.c: Add comments related to omitting base and/or index + register 0 in disassembly. + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for base and/or + index register 0. + * testsuite/gas/s390/zarch-base-index-0.s: Add test cases for + base and/or index register 0. + * testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * testsuite/gas/s390/zarch-base-index-0-err.s: Add error test + cases for base and/or index register 0. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add comments to assembler operand parsing logic + gas/ + * config/tc-s390.c: Add comments to assembler operand parsing + logic. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Assemble processor specific test cases for their processor + Assemble the esa-g5 test case with -march=g5. + Assemble the zarch-z900 test case with -march=z900. + + gas/ + * testsuite/gas/s390/s390.exp: Assemble processor specific test + cases for their respective processor (-march=). + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Correct setting of highgprs flag in ELF output + The combination of an architecture size of 32 bits and z/Architecture + mode requires the highgprs flag to be set in the ELF output. It causes + the high-halves of the general purpose registers (GPRs) to be preserved + at run-time, so that the code can use 64-bit GPRs. + + The architecture size of 32 bits can either be the default in case of + a default architecture name of "s390" or due to specification of the + option -m31 (to generate the 31-bit file format). + The z/Architecture mode can either be the default or due to + specification of the option -mzarch (to assemble for z/Architecture + mode). It can also be selected using the pseudo commands + ".machinemode zarch" and ".machinemode zarch_nohighgprs". The latter + not causing the highgprs flag to be set. + + The highgprs flag was only set when the following s390-specific + assembler options were given in the following specific order: + "-m31 -mzarch". + + The highgprs flag was erroneously not set when: + - the order of above options was inverse (i.e. "-mzarch -m31"), + - the architecture mode defaulted to z/Architecture mode and + option "-m31" was specified, + - the architecture size defaulted to 32 bits due to a default + architecture name of "s390" and option -mzarch was specified, + - the architecture size defaulted to 32 bits and the architecture + mode defaulted to z/Architecture due to the specified processor + (e.g. "-march=z900" or follow-on processor). + + Determine whether to set the highgprs flag in init_default_arch() after + having processed all assembler options in md_parse_option(). This + ensures the flag is set in all of the above cases it was erroneously not + set. Add test cases for highgprs flag, including ones that use + .machinemode to switch the architecture mode. + + gas/ + * config/tc-s390.c: Correct setting of highgprs flag in ELF + output. + * testsuite/gas/s390/s390.exp: Add test cases for highgprs + flag. + * testsuite/gas/s390/blank.s: Empty assembler source used in + test cases for "highgprs" flag. + * testsuite/gas/s390/esa-highgprs-0.d: Add test case for + highgprs flag. + * testsuite/gas/s390/zarch-highgprs-0.d: Likewise. + * testsuite/gas/s390/zarch-highgprs-1.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-0.s: Add test case + for highgprs flag when using .machinemode to switch + architecture mode. + * testsuite/gas/s390/esa-highgprs-machinemode-0.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.s: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Do not erroneously use base operand value for length operand + The base register operand B may optionally be omitted in D(B) by coding + D and in D(L,B) by coding D(L). The index register operand X may + optionally be omitted in D(X,B) by coding D(,B) or D(B). Both base and + index register operands may optionally be omitted in D(X,B) by coding D. + In any case the omitted base and/or index register operand value + defaults to zero. + + When parsing an erroneously omitted length L operand in D(L,B) by coding + D(,B) the base register operand B was erroneously consumed as length + operand. When using a register name for the base register operand this + was detected and reported as error. But when not using a register name + the base register operand value was erroneously used as length operand + value. + + Correct the parsing of an omitted optional base or index register to not + erroneously use the base register operand value as length, when + erroneously omitting the length operand. + + While at it rename the variable used to remember whether the base or + index register operand was omitted to enhance code readability. + Additionally add test cases for the optional omission of base and/or + index register operands. + + Example assembler source: + mvc 16(1,%r1),32(%r2) + mvc 16(1),32(%r2) + mvc 16(,1),32(%r2) # undetected syntax error + + Disassembly of bad assembly without commit shows the base register + operand value was erroneously used as length operand value: + 0: d2 00 10 10 20 20 mvc 16(1,%r1),32(%r2) + 6: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + c: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + + Assembler messages with commit: + 3: Error: operand 1: missing operand + + gas/ + * config/tc-s390.c: Correct parsing of omitted base register. + * testsuite/gas/s390/s390.exp: Add test cases for omitted base + and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index.s: Test cases for + omitted optional base or index register. + * testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * testsuite/gas/s390/zarch-omitted-base-index-err.s: Test cases + for omitted base and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Enhance handling of syntax errors in assembler + Do not consume any unexpected character including newline ('\n') when + detecting a syntax error when parsing an operand block with parenthesis. + This resolves the unfavorable assembler messages from the example below, + including consuming the newline at the end of the current statement and + reporting the next statement as junk. + + While at it change the only pre-increment of the current instruction + string pointer into a post-increment to align with the other instances. + + Example assembler source: + mvi 16(),32 # syntax error + a %r1,16(%r2 # syntax error + a %r1,16(%r2) + mvc 16(1,),32(%r2) # syntax error + mvc 16(1,%r1,32(%r2 # syntax error + + Assembler messages without commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 1: Error: syntax error; expected ',' + 1: Error: junk at end of line: `32' + 2: Error: syntax error; missing ')' after base register + 2: Error: junk at end of line: `a %r1,16(%r2)' + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 4: Error: syntax error; expected ',' + 4: Error: operand out of range (32 is not between 0 and 15) + 4: Error: syntax error; missing ')' after base register + 4: Error: junk at end of line: `%r2)' + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; expected ',' + 5: Error: operand out of range (32 is not between 0 and 15) + 5: Error: syntax error; missing ')' after base register + 5: Error: junk at end of line: `%r2' + + Assembler messages with commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 2: Error: syntax error; missing ')' after base register + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + + gas/ + * config/tc-s390.c: Do not erroneously consume newline when + parsing an addressing operand with parentheses. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Lower severity of assembler syntax errors from fatal to error + Report s390 assembler syntax errors as error instead of fatal error. + This allows the assembler to continue and potentially report further + syntax errors in the source. This should not cause syntax errors to + be erroneously accepted, as both error and fatal error cause the + assembler to return with a non-zero return code. + + The following syntax errors are changed from fatal to error: + - invalid length field specified + - odd numbered general purpose register specified as register pair + - invalid floating point register pair. Valid fp register pair operands + are 0, 1, 4, 5, 8, 9, 12 or 13. + + gas/ + * config/tc-s390.c: Lower severity of assembler syntax errors + from fatal to error. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Use proper string lengths when parsing opcode table flags + opcodes/ + * s390-mkopc.c: Use proper string lengths when parsing opcode + table flags. + + Fixes: c5306fed7d4 ("s390: Support for jump visualization in disassembly") + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Whitespace fixes in conditional branch flavor descriptions + opcodes/ + * s390-mkopc.c: Whitespace fixes in conditional branch flavor + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jan Beulich + + x86: adjust which Dwarf2 register numbers to use + Consumers can't know which execution mode is in effect for a certain + piece of code; they can only go from object file properties. Hence which + register numbers to encode ought to depend solely on object file type. + + In tc_x86_frame_initial_instructions() do away with parsing a register + name: We have a symbolic constant already for the 64-bit case, and the + 32-bit number isn't going to change either. Said constant's definition + needs moving, though, to be available also for non-ELF. While moving + also adjust the comment to clarify that it's applicable to 64-bit mode + only. + +2024-03-01 Jan Beulich + + gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 + ... plus the SME part of B16B16. As per + + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + SVE2.1 support is both incomplete and buggy. SME2.1 "support" goes as + far as a single instruction (a subset of movaz forms) only. The SME part + of B16B16 is entirely missing. + +2024-03-01 Jan Beulich + + x86/APX: honor -mevexwig= for byte-size insns + These uniformly ignore EVEX.W, and hence what we emit ought to be + controllable by the command line option. + + x86/APX: optimize certain XOR and SUB forms + While most logic in optimize_encoding() is already covering APX by way + of the earlier NDD->REX2 conversion, there's a remaining set of cases + which wants handling separately. + + x86/APX: correct .insn opcode space determination when REX2 is needed + In this case spaces 0f38 and 0f3a may not be put in place. To achieve + the intended effect, operand parsing (but not operand processing) needs + pulling ahead, so we know whether eGRP-s are in use. + +2024-03-01 Jan Beulich + + x86/APX: respect {vex}/{vex3} + Even when an EVEX encoding is available, use of such a prefix ought to + be respected (resulting in an error) rather than ignored. As requested + during review already, introduce a new encoding enumerator to record use + of eGPR-s, and update state transitions accordingly. + + The optimize_encoding() change also addresses an internal assembler + error that was previously raised when respective memory operands used + eGPR-s for addressing. + + While this results in a change of diagnostic issued for VEX-encoded + insns, the new one is at least no worse than the prior one. + +2024-03-01 Tom Tromey + + Use DW_FORM_ref_addr for DIE offset in .debug_names + Today I realized that while the .debug_names writer uses DW_FORM_udata + for the DIE offset, DW_FORM_ref_addr would be more appropriate here. + This patch makes this change. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31361 + +2024-03-01 GDB Administrator + + Automatic date update in version.in + +2024-02-29 Alan Modra + + PR19871, description of --pie + Say why we even mention shared libraries here (ET_DYN), and clarify + symbol resolution. There are of course many other ways that PIEs + resemble PDEs more closely than shared libraries. + + PR 19871 + * ld.texi (-pie): Clarify. + +2024-02-29 Tom Tromey + + Synchronize GCC compile plugin headers + This patch copies some changes to the compile headers from GCC's + include/ directory. It is the gdb equivalent of the GCC commit + bc0e18a9 -- however, while that commit also necessarily touched + libcc1, this one of course does not. + + Tested by rebuilding and also running the gdb.compile tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-02-29 Srinath Parvathaneni + + aarch64: Fix the 2nd operand in gcsstr and gcssttr instructions. + The assembler wrongly expects plain register name instead of + memory-form 2nd operand for gcsstr and gcssttr instructions. + This patch fixes the issue. + +2024-02-29 Tom de Vries + + [gdb/dap] Fix stray KeyboardInterrupt after cancel + When running test-case gdb.dap/pause.exp 100 times in a loop, it passes + 100/100. + + But if we remove the two "sleep 0.2" from the test-case, we run into + (copied from dap.log and edited for readability): + ... + Traceback (most recent call last): + File "startup.py", line 251, in message + def message(): + + KeyboardInterrupt + Quit + ... + + This happens as follows. + + CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight. + + The idea is that this interrupt triggers while in fn here in message (a nested + function of send_gdb_with_response): + ... + def message(): + try: + val = fn() + result_q.put(val) + except (Exception, KeyboardInterrupt) as e: + result_q.put(e) + ... + but instead it triggers outside the try/except. + + Fix this by: + - in CancellationHandler, renaming variable in_flight to in_flight_dap_thread, + and adding a variable in_flight_gdb_thread to be able to distinguish when + a request is in flight in the dap thread or the gdb thread. + - adding a wrapper Cancellable to to deal with cancelling the wrapped + event + - using Cancellable in send_gdb and send_gdb_with_response to wrap the posted + event + - in CancellationHandler.cancel, only call gdb.interrupt if + req == self.in_flight_gdb_thread. + + This makes the test-case pass 100/100, also when adding the extra stressor of + "taskset -c 0", which makes the fail more likely without the patch. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31275 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275 + +2024-02-29 Tom de Vries + + [gdb/dap] Move send_gdb and send_gdb_with_response to server module + Move functions send_gdb and send_gdb_with_response, as well as class Invoker + to server module. + + Separated out to make the following patch easier to read. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-29 Thiago Jung Bauermann + + gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions + Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro + register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which + adds the tpidruro register, and unconditionally enabled it in + aarch32_create_target_description. + + In Linux, the tpidruro register isn't available via ptrace in the 32-bit + kernel but it is available for an aarch32 program running under an arm64 + kernel via the ptrace compat interface. This isn't currently implemented + however, which causes GDB on arm-linux with 64-bit kernel to list the + register but show it as unavailable, as reported by Tom de Vries: + + $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' + Temporary breakpoint 1 at 0x512 + + Temporary breakpoint 1, 0xaaaaa512 in main () + $1 = + + Simon Marchi then clarified: + + > The only time we should be seeing some "unavailable" registers or memory + > is in the context of tracepoints, for things that are not collected. + > Seeing an unavailable register here is a sign that something is not + > right. + + Therefore, disable the TLS feature in aarch32 target descriptions for Linux + and NetBSD targets (the latter also doesn't seem to support accessing + tpidruro either, based on a quick look at arm-netbsd-nat.c). + + This patch fixes the following tests: + + Running gdb.base/inline-frame-cycle-unwind.exp ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 + + Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native, + native-gdbserver and native-extended-gdbserver targets with no regressions. + + PR tdep/31418 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418 + + Approved-By: John Baldwin + +2024-02-29 H.J. Lu + + bfd: Add ATTRIBUTE_HIDDEN to x86 internal functions + * elfxx-x86.h: Add ATTRIBUTE_HIDDEN to internal functions. + * libbfd-in.h (_bfd_get_link_info): Add ATTRIBUTE_HIDDEN. + * libbfd.h: Regenerated. + +2024-02-29 Alan Modra + + PR21739, Inconsistent diagnostics + PR 21739 + cpu/ + * mep.opc (parse_lo16, parse_unsigned7): Mark %function + message as no-c-format. + opcodes/ + * mep-asm.c: Regenerate. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Initial ld.bfd support for TLSDESC. + Only relocation handling for now; relaxation is not implemented yet. + + bfd/ + * elfnn-riscv.c (riscv_elf_check_relocs): Record GOT reference and + paired relocation for TLSDESC_HI20. + (riscv_elf_adjust_dynamic_symbol): Allocate GOT and reloc slots for + TLSDESC symbols. + (riscv_elf_size_dynamic_sections): Likewise but for local symbols. + (tlsdescoff): New helper to determine static addend for R_TLSDESC. + (riscv_elf_relocate_section): Ignore TLSDESC_CALL reloc for now (it is + relaxation only). + Handle TLSDESC_{LOAD,ADD}_LO12 as paired pcrel relocs. + For TLS GOT slot generation, generalize the logic to handle any + combination of (GD, IE, TLSDESC). + Add TLSDESC Rela generation. + * ld/testsuite/ld-riscv-elf/tls*: Add TLSDESC instruction sequences + next to the existing GD and IE sequences. Update expectations. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Define and use GOT entry size constants for TLS. + As the size calculation is split by global and local symbols, using a + shared constant definition for its size improves clarity. + + bfd/ + * elfnn-riscv.c: Add macros for sizes of a normal GOT entry, TLS GD and + TLS IE entry. + (allocate_dynrelocs): Replace GOT size expressions with the new + constants. + (riscv_elf_size_dynamic_sections): Likewise. + (riscv_elf_relocate_section): Likewise. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Add assembly support for TLSDESC. + gas/ + * tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi, + %tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype + renamed to percent_op_relax_only as this matcher is extended to handle + jalr as well which is not R-type. + (riscv_ip): Apply the percent_op_relax_only rename and update comment. + (md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to + TLS relocation check list. + * testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation + generation. + opcodes/ + * riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with + %tlsdesc_call annotations. + + RISC-V: Add TLSDESC reloc definitions. + bfd/ + * elfxx-riscv.c: Add 5 TLSDESC reloc descriptions. + * reloc.c: Likewise. + * libbfd.h: Regenerate. + * bfd-in2.h: Regenerate. + include/ + * elf/riscv.h: Add 5 TLSDESC reloc descriptions. + +2024-02-29 Ruud van der Pas + + gprofng: change use of bignum to use of bigint + Change the statement "use bignum" to "use bigint". This is sufficient + for gp-display-html to work and removes the dependency on bignum. + + gprofng/ChangeLog + 2024-02-27 Ruud van der Pas + + PR 31390 + * gprofng/gp-display-html: One line change to "use bigint". + +2024-02-29 John Baldwin + + aarch64: Use aarch64_debug_printf in a few more places + No functional change + + Approved-By: Simon Marchi + +2024-02-29 GDB Administrator + + Automatic date update in version.in + +2024-02-28 Alan Modra + + PR23877, bad value (n32r5900) for default CPU + Catching this at configure time would be nicer, but we'd need to exactly + match mips_parse_cpu in configure.ac and keep it all in sync. + + PR 23877 + * config/tc-mips.c (mips_after_parse_args): Don't assert that + mips_parse_cpu returns non-NULL, call as_fatal with an informative + message instead. + +2024-02-28 Vladislav Belov + + Fix implementation of SUBALIGN. + +2024-02-28 Tom Tromey + + Fix gdb.interrupt race + gdb.interrupt was introduced to implement DAP request cancellation. + However, because it can be run from another thread, and because I + didn't look deeply enough at the implementation, it turns out to be + racy. + + The fix here is to lock accesses to certain globals in extension.c. + + Note that this won't work in the case where configure detects that the + C++ compiler doesn't provide thread support. This version of the + patch disables DAP entirely in this situation. + + Regression tested on x86-64 Fedora 38. I also ran gdb.dap/pause.exp + in a thread-sanitizer build tree to make sure the reported race is + gone. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31263 + +2024-02-28 Alan Modra + + PR23881, pdp11 binutils fails if too much debug data + The PR testcase overflows one of the exec header fields, e_syms (the + size of the symbol table), leading to the string table offset being + wrong. Things go downhill from there. Fixed by checking for + overflow. This happens to trigger in the ld testsuite, so xfail that + test. + + PR 23881 + bfd/ + * libaout.h (swap_exec_header_out): Return a bool. + * aoutx.h (swap_exec_header_out): Check for overflow in exec + header. + * pdp11.c (swap_exec_header_out): Likewise. + * i386lynx.c (WRITE_HEADERS): Adjust. + ld/ + * testsuite/ld-scripts/map-address.exp: xfail pdp11. + +2024-02-28 GDB Administrator + + Automatic date update in version.in + +2024-02-27 Tom Tromey + + Two minor addrmap cleanups + While working on a different patch, I found a couple of simple addrmap + cleanups. + + In one case, a forward declaration is no longer needed, as the header + now includes addrmap.h. + + In the other, an include of addrmap.h is no longer needed. + + Tested by rebuilding. + +2024-02-27 Tom Tromey + + Explicitly quit gdb from DAP server thread + This changes the DAP code to explicitly request that gdb exit. + Previously this could cause crashes, but with the previous cleanups, + this should no longer happen. + + This also adds a tests that ensures that gdb exits with status 0. + +2024-02-27 Tom Tromey + + Add final cleanup for runnables + This changes run-on-main-thread.c to clear 'runnables' in a final + cleanup. This avoids an issue where a pending runnable could require + Python, but be run after the Python interpreter was finalized. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31172 + +2024-02-27 Tom Tromey + + Change finalize_values into a final cleanup + This removes finalize_values in favor of adding a new final cleanup. + This is safe now that extension languages are explicitly shut down. + + Add extension_language_ops::shutdown + Right now, Python is shut down via a final cleanup. However, it seems + to me that it is better for extension languages to be shut down + explicitly, after all the ordinary final cleanups are run. The main + reason for this is that a subsequent patch adds another case like + finalize_values; and rather than add a series of workarounds for + Python shutdown, it seemed better to let these be done via final + cleanups, and then have Python shutdown itself be the special case. + + Rewrite final cleanups + This patch rewrites final cleanups to use std::function and otherwise + be more C++-ish. + +2024-02-27 Tom Tromey + + Use the .py file in gdb.dap/pause.exp + Tom de Vries pointed out that the gdb.dap/pause.exp test writes a + Python file but then does not use it. This patch corrects the + oversight. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Rewrite "python" command exception handling + The "python" command (and the Python implementation of the gdb + "source" command) does not handle Python exceptions in the same way as + other gdb-facing Python code. In particular, exceptions are turned + into a generic error rather than being routed through + gdbpy_handle_exception, which takes care of converting to 'quit' as + appropriate. + + I think this was done this way because PyRun_SimpleFile and friends do + not propagate the Python exception -- they simply indicate that one + occurred. + + This patch reimplements these functions to respect the general gdb + convention here. As a bonus, some Windows-specific code can be + removed, as can the _execute_file function. + + The bulk of this change is tweaking the test suite to match the new + way that exceptions are displayed. These changes are largely + uninteresting. However, it's worth pointing out the py-error.exp + change. Here, the failure changes because the test changes the host + charset to something that isn't supported by Python. This then + results in a weird error in the new setup. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Acked-By: Tom de Vries + Reviewed-By: Eli Zaretskii + +2024-02-27 Tom Tromey + + Fix formatting buglet in python.c + python.c has a split string that is missing a space. There's also a + stray backslash in this code. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Introduce read_remainder_of_file + This patch adds a new function, read_remainder_of_file. This is like + read_text_file_to_string, but reads from an existing 'FILE *'. This + will be used in a subsequent patch. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom de Vries + + [gdb/testsuite] Reset errcnt and warncnt in default_gdb_init + Say we do: + ... + $ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp" + ... + and add a perror at the end of pause.exp: + ... + dap_shutdown + + + +perror "foo" + ... + + We run into: + ... + UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb + ... + + This happens because the perror increases the errcnt, which is not reset at + the end of the test-case, and consequently the first pass in the following + test-case is changed into an unresolved. + + Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the + end of the test-case, which does reset the errcnt, but this is with version + 1.6.1. + + Furthermore, we reset the errcnt in clean_restart, but the pass is produced + before, so that doesn't help either. + + Fix this by resetting errcnt and warncnt in default_gdb_init. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31351 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Remove KFAIL for PR ada/30908 + PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by + commit d56fdf1b976 ("Refine Ada overload matching"). + + Remove the KFAILs for PR ada/30908. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp + With test-case gdb.python/py-finish-breakpoint.exp, we run into: + ... + (gdb) python print (finishbp_default.hit_count) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Breakpoint 3 is invalid. + Error while executing Python code. + (gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \ + check finishBP on default frame has been hit + ... + + The test producing the pass is: + ... + gdb_test "python print (finishbp_default.hit_count)" "1.*" \ + "check finishBP on default frame has been hit" + ... + so the pass is produced because the 1 in "line 1" matches "1.*". + + Temporary breakpoints are removed when hit, and consequently accessing the + hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is + not possible, and as per spec we get a RuntimeError. + + So the RuntimeError is correct, and not specific to finish breakpoints. + + The test presumably attempts to match: + ... + (gdb) python print (finishbp_default.hit_count) + 1 + ... + but most likely this output was never produced by any gdb version. + + Fix this by checking whether the finishbp_default breakpoint has hit by + checking that finishbp_default.is_valid() is False. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31391 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391 + +2024-02-27 Pedro Alves + + Cygwin: Fix putting inferior in foreground (fix input) + gdb.base/interrupt.exp reveals that inferior input is + broken on Cygwin: + + (gdb) continue + Continuing. + talk to me baby + Input/output error <<< BAD + PASS: gdb.base/interrupt.exp: process is alive + a + [Thread 10688.0x2590 exited with code 1] + [Thread 10688.0x248c exited with code 1] + [Thread 10688.0x930 exited with code 1] + [Thread 10688.0x2c98 exited with code 1] + + Program terminated with signal SIGHUP, Hangup. + The program no longer exists. + (gdb) FAIL: gdb.base/interrupt.exp: child process ate our char + a + Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior... + (gdb) ERROR: "" is not a unique command name. + + The problem is that inflow.c:child_terminal_inferior is failing to put + the inferior in the foreground, because we're passing down the + inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp. + + That is fixed by this commit. Afterwards we will get: + + (gdb) continue + Continuing. + talk to me baby + PASS: gdb.base/interrupt.exp: process is alive + a + a <<< GOOD + PASS: gdb.base/interrupt.exp: child process ate our char + [New Thread 7236.0x1c58] + + Thread 6 received signal SIGINT, Interrupt. <<< new thread spawned for SIGINT + [Switching to Thread 7236.0x1c58] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C + + We still have the FAIL seen above because this change has another + consequence. By failing to put the inferior in the foreground + correctly, Ctrl-C was always reaching GDB first. Now that the + inferior is put in the foreground properly, Ctrl-C reaches the + inferior first, which results in a Windows Ctrl-C event, which results + in Windows injecting a new thread in the inferior to report the Ctrl-C + exception => SIGINT. That is, running the test manually: + + Before patch: + + (gdb) c + Continuing. + [New Thread 2352.0x1f5c] + [New Thread 2352.0x1988] + [New Thread 2352.0x18cc] + <<< Ctrl-C pressed. + Thread 7 received signal SIGTRAP, Trace/breakpoint trap. + [Switching to Thread 2352.0x18cc] + 0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll + (gdb) + + Above, GDB got the SIGINT, and it manually passes it down the + inferior, which reaches windows_nat_target::interrupt(), which + interrupts the inferior with DebugBreakProcess (which injects a new + thread in the inferior that executes an int3 instruction). + + After this patch, we have (with "set debugexceptions on" so + DBG_CONTROL_C is visible): + + (gdb) c + Continuing. + [New Thread 9940.0x1168] + [New Thread 9940.0x5f8] + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + [New Thread 9940.0x3d8] + gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b <<< Ctrl-C + + Thread 7 received signal SIGINT, Interrupt. <<< new injected thread + [Switching to Thread 9940.0x3d8] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) + + This new behavior is exactly the same as what you see with a MinGW GDB + build. Also, SIGINT reaching inferior first is what you get on Linux + as well currently. + + I wrote an initial fix for this before I discovered that Cygwin + downstream had a similar change, so I then combined the patches. I am + adding a Co-Authored-By for that reason. + + Co-Authored-By: Takashi Yano + Approved-By: Tom Tromey + Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f + +2024-02-27 Andreas Krebbel + + s390: Add r_offset check to the weak undef change + Since we are accessing up to 2 bytes before the relocation target we + should better make sure there are actually 2 bytes before it. + + ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Make sure + rel->r_offset is large enough. + +2024-02-27 Yuriy Kolerov + + arc: Don't build arc-analyze-prologue.S with -g + arc-analyze-prologue.S test does not contain debug information thus + it must be compiled without -g option. Otherwise GDB will try to + unwind frames using debug information (which does not exist for .S + code!) instead of analyzing frames manually. + + Approved-By: Shahab Vahedi + +2024-02-27 Andreas Krebbel + + s390: Avoid reloc overflows on undefined weak symbols + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0, a + NOP, or a trapping insn. + + This prevents the PC32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative addressing + to avoid relocation overflows. + + ld/ChangeLog: + * ld/testsuite/ld-s390/s390.exp: + * ld/testsuite/ld-s390/8GB.ld: New test. + * ld/testsuite/ld-s390/weakundef-1.dd: New test. + * ld/testsuite/ld-s390/weakundef-1.s: New test. + +2024-02-27 Matthieu Longo + + aarch64: rename internals related to PAuth feature to use pauth in their naming for coherency + Hi, + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion. + + Regression tested on aarch64-none-elf, and no regression found. + + Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf. + + Regards, + Matthieu. + From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001 + From: Matthieu Longo + Date: Fri, 23 Feb 2024 11:30:40 +0000 + Subject: [PATCH] aarch64: rename internals related to PAuth feature to use + pauth in their naming for coherency + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature + with internal names that don't match the actual feature name pauth. The new + feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature + of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" + would create confusion. + +2024-02-27 mengqinggang + + LoongArch: Run overflow testcases only on LoongArch target + +2024-02-27 ticat_fp + + LoongArch: Modify inconsistent behavior of ld with --unresolved-symbols=ignore-all + Remove duplicated check when producing executable files that reference external symbols + defined in other files. RELOC_FOR_GLOBAL_SYMBOL will check it. + + Testcase is: + resolv.c: + int main(int argc, char *argv[]) { + return argc; + } + + t.c: + + extern const struct my_struct ms1; + static const struct my_struct *ms = &ms1; + + t.h: + typedef struct my_struct { + char *str; + int i; + } my_struct; + + Compiling and linking command with: + gcc t.c -c ; gcc resolv.c -c + gcc resolv.o t.o -o resolv -Wl,--unresolved-symbols=ignore-all + + Got error as: + ~/install/usr/bin/ld: t.o:(.data.rel+0x0): undefined reference to `ms1' + collect2: error: ld returned 1 exit status + +2024-02-27 Jinyang He + + Avoid unused space in .rela.dyn if sec was discarded + The relsec size is still increased although sec is discarded, which + cause a lot of unused space allocated. Avoid size increased if sec + was discarded. + + bfd/ChangeLog: + + * bfd/elfnn-loongarch.c: (allocate_dynrelocs): Do not increase + sreloc size when discarded_section. + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test. + * ld/testsuite/ld-loongarch-elf/pie_discard.d: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.s: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.t: New test. + +2024-02-27 Jinyang He + + LoongArch: ld: Fix other pop relocs overflow check and add tests + Add reloc_unsign_bits() to fix others sop_pop relocs overflow check. + Then add over/underflow tests for relocs B*, SOP_POP* and PCREL20_S2. + + bfd/ChangeLog: + + * bfd/elfxx-loongarch.c: Add reloc_unsign_bits(). + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add tests. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.dd: New test. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi1_sops.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_overflows.s: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_5_20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_5_20.d: New test. + +2024-02-27 mengqinggang + + LoongArch: bfd: Fix some bugs of howto table + R_LARCH_IRELATIVE: For dynamic relocation that does not distinguish between + 32/64 bits, size and bitsize set to 8 and 64. + R_LARCH_TLS_DESC64: Change size to 8. + R_LARCH_SOP_POP_32_S_0_5_10_16_S2: Change src_mask to 0, dst_mask to + 0x03fffc1f. + +2024-02-27 GDB Administrator + + Automatic date update in version.in + +2024-02-26 Simon Marchi + + gdb/amd-dbgapi: fix indentation + Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0 + +2024-02-26 Tom Tromey + + Remove two unnecessary casts + I noticed a spot in ada-lang.c where the return value of + value_as_address was cast to CORE_ADDR -- a no-op cast. I searched + and found another. This patch fixes both. + +2024-02-26 Pedro Alves + + [gdb] Fix heap-use-after-free in select_event_lwp + PR gdb/31259 reveals one scenario where we run into a + heap-use-after-free reported by thread sanitizer, while running + gdb.base/vfork-follow-parent.exp. + + The heap-use-after-free happens during the following scenario: + + - linux_nat_wait_1 is about to return an event for T2. It stops all + other threads, and while doing so, stop_wait_callback -> wait_lwp + sees T1 exit, and decides to leave the exit event pending. It + should have set the lp->stopped flag too, but does not -- this is + the bug. + + - The event for T2 is reported, is processed by infrun, and we're + back at linux_nat_wait_1. + + - linux_nat_wait_1 selects LWP T1 with the pending exit status to + report. + + - it sets variable lp to point to the corresponding lwp_info. + + - it calls stop_callback and stop_wait_callback for all threads + (because !target_is_non_stop_p ()). + + - it calls select_event_lwp to maybe pick another thread than T1, to + prevent starvation. + + The problem is the following: + + - while calling stop_wait_callback for all threads, it also does this + for T1. While doing so, the corresponding lwp_info is deleted + (callstack stop_wait_callback -> wait_lwp -> exit_lwp -> + delete_lwp), leaving variable lp as a dangling pointer. + + - variable lp is passed to select_event_lwp, which derefences it, + which causes the heap-use-after-free. + + Note that the comment here mentions "all other LWP's": + ... + /* Now stop all other LWP's ... */ + iterate_over_lwps (minus_one_ptid, stop_callback); + /* ... and wait until all of them have reported back that + they're no longer running. */ + iterate_over_lwps (minus_one_ptid, stop_wait_callback); + ... + + The reason the comments say "all other LWP's", and doesn't bother + filtering out LP is that lp->stopped should be true at this point, and + the callbacks (both stop_callback and stop_wait_callback) check that + flag, and do nothing if set. I.e., they skip already-stopped threads, + so they should skip LP. + + In this particular scenario, though, we missed setting the stopped + flag right in the first step described above, so LP was iterated over + incorrectly. + + The fix is to make wait_lwp set the lp->stopped flag when it decides + to leave the exit event pending. However, going a bit further, + gdbserver has a mark_lwp_dead function to centralize setting up + various lwp flags such that the rest of the code doesn't mishandle + them, and it seems like a good idea to do a similar thing in gdb as + well. That is what this patch does. + + PR gdb/31259 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31259 + Co-Authored-By: Tom de Vries + Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9 + +2024-02-26 Tom de Vries + + [gdb/testsuite] Dump dap.log.$n to gdb.log when exceptions found + For a patch I submitted, the Linaro CI reported a failure: + ... + FAIL: gdb.dap/attach.exp: exceptions in log file + ... + + I ran the test-case locally, and observed the same FAIL in the gdb.sum file. + + I then wanted to confirm that I reproduced the exact same problem, but + realized that I couldn't because there's no way for me to know what exception + occurred, and where, because that information is logged in the dap.log.$n + file, and the Linaro CI only saves the gdb.sum and gdb.log files. + + This issue is even worse if only the CI can reproduce a FAIL. + + Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when + exceptions are found. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-26 Tom de Vries + + [gdb/testsuite] Further handle long filenames in gdb.base/startup-with-shell.exp + In commit 52498004a34 ("gdb/testsuite: handle long filenames in + gdb.base/startup-with-shell.exp") we fixed a FAIL reported by the Linaro CI: + ... + (gdb) print argv[1] + $1 = 0xfffed978 "/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; \ + run_args = *.unique-extension: first argument expanded + ... + + PR testsuite/31410 reports a similar failure: + ... + (gdb) print argv[1] + $1 = 0xfffeda96 "/startup-with-shell/*.unique-extens"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = off; \ + run_args = *.unique-extension: first argument not expanded + ... + + Fix this in the same way, using "set print characters unlimited". + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410 + +2024-02-26 Tom de Vries + + [gdb] Fix "value is not available" with debug frame + On arm-linux, with a started hello world, running "info frame" works fine, but + when I set debug frame to on, I run into: + ... + (gdb) info frame + ... + [frame] frame_unwind_register_value: exit + value is not available + (gdb) + ... + + The problem is here in frame_unwind_register_value: + ... + if (value->lazy ()) + gdb_printf (&debug_file, " lazy"); + else + { + int i; + gdb::array_view buf = value->contents (); + ... + where we call value->contents () while !value->entirely_available (). + + Fix this by checking value->entirely_available () and printing: + ... + [frame] frame_unwind_register_value: -> register=91 unavailable + ... + + Tested on arm-linux. + + PR gdb/31369 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31369 + +2024-02-26 Tiezhu Yang + + gdb: Modify the output of "info breakpoints" and "delete breakpoints" + The output of "info breakpoints" includes breakpoint, watchpoint, + tracepoint, and catchpoint if they are created, so it should show + all the four types are deleted in the output of "info breakpoints" + to report empty list after "delete breakpoints". + + It should also change the output of "delete breakpoints" to make it + clear that watchpoints, tracepoints, and catchpoints are also being + deleted. This is suggested by Guinevere Larsen, thank you. + + $ make check-gdb TESTS="gdb.base/access-mem-running.exp" + $ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running + [...] + (gdb) break main + Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32. + (gdb) watch global_counter + Hardware watchpoint 2: global_counter + (gdb) trace maybe_stop_here + Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27. + (gdb) catch fork + Catchpoint 4 (fork) + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32 + 2 hw watchpoint keep y global_counter + 3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27 + not installed on target + 4 catchpoint keep y fork + + Without this patch: + + (gdb) delete breakpoints + Delete all breakpoints? (y or n) y + (gdb) info breakpoints + No breakpoints or watchpoints. + (gdb) info breakpoints 3 + No breakpoint or watchpoint matching '3'. + + With this patch: + + (gdb) delete breakpoints + Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y + (gdb) info breakpoints + No breakpoints, watchpoints, tracepoints, or catchpoints. + (gdb) info breakpoints 3 + No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'. + + Approved-by: Kevin Buettner + Reviewed-By: Eli Zaretskii + +2024-02-26 Andreas Arnez + + gdb: s390: Add arch14 record/replay support + Enable recording of the new "arch14" instructions on z/Architecture + targets, except for the specialized-function-assist instruction NNPA. + +2024-02-26 Vladimir Mezentsev + + gprofng: Add hardware counter profiling for the Ampere system + gprofng should recognize Ampere and other ARM systems. + + gprofng/ChangeLog + 2024-02-22 Vladimir Mezentsev + + * common/hwc_cpus.h: Declare the enum values ARM_CPU_IMP_*. + * common/core_pcbe.c (core_pcbe_init): Accept new systems ARM_CPU_IMP_*. + +2024-02-26 Jinyang He + + LoongArch: bfd: Correct the name of R_LARCH_SOP_POP_32_U in howto_table + +2024-02-26 GDB Administrator + + Automatic date update in version.in + +2024-02-25 GDB Administrator + + Automatic date update in version.in + +2024-02-24 Tom de Vries + + [gdb/build] Fix static cast of virtual base + With this change in bfd/development.sh: + ... + -development=true + +development=false + ... + we run into: + ... + In file included from tui-data.h:28:0, + from tui-command.c:24: + gdb-checked-static-cast.h: In instantiation of \ + ‘T gdb::checked_static_cast(V*) [with T = tui_cmd_window*; V = tui_win_info]’: + tui-command.c:65:15: required from here + gdb-checked-static-cast.h:63:14: error: cannot convert from pointer to base \ + class ‘tui_win_info’ to pointer to derived class ‘tui_cmd_window’ because \ + the base is virtual + T result = static_cast (v); + ^~~~~~~~~~~~~~~~~~ + ... + + Fix this by using dynamic_cast instead of gdb::checked_static_cast in + TUI_CMD_WIN and TUI_STATUS_WIN. + + Tested on x86_64-linux, with development set to false. + + Reported-By: Robert Xiao + Reported-By: Simon Marchi + Approved-By: Tom Tromey + + PR build/31399 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + +2024-02-24 Alan Modra + + PR25333, GAS is slow processing -fdebug-types-sections + gas needs to build lists of sections for each group. This arranges to + build the lists earlier, so they can be used when looking for sections + that belong to a group. Using the section hash table to find sections + by name, then by group isn't efficient when there are numerous groups + with the same section names. Using a hash table to quickly find a + group, then searching by section name on a list for the group results + in a 100-fold speed improvement assembling the testcase in this PR. + + To reduce the number of times we traverse the section list, the patch + also moves some processing done in elf_adjust_symtab for linked-to + section, to elf_frob_file. This requires a testsuite change because + processing will stop before elf_frob_file if there is a parse error in + section21.s, ie. you'll only get the "junk at end of line" error, not + the "undefined linked-to symbol" errors. + + PR 25333 + * config/obj-elf.c (struct group_list, groups): Move earlier. + (match_section): New function, extracted from.. + (get_section_by_match): ..here. + (free_section_idx): Move earlier. + (group_section_find, group_section_insert): New functions. + (change_section): Use the above. + (elf_set_group_name): New function. + (obj_elf_attach_to_group): Use elf_set_group_name. + (set_additional_section_info): Handle linked_to_symbol_name and + stabs code, extracted from.. + (adjust_stab_sections): ..here,.. + (build_additional_section_info): ..and here. + (elf_adjust_symtab): Don't call build_additional_section_info. + (elf_frob_file): Adjust. + * config/obj-elf.h (elf_set_group_name): Declare. + * config/tc-xtensa.c (cache_literal_section): Use elf_set_group_name. + (xtensa_make_property_section): Likewise. + * testsuite/gas/elf/attach-1.d: Stricter group section matching, + and changed group section ordering. + * testsuite/gas/elf/attach-2.d: Stricter group section matching. + * testsuite/gas/elf/attach-2.s: Provide section bar type. + * testsuite/gas/elf/elf.exp: Run attach-2. + * testsuite/gas/elf/section21.l: Update. + * testsuite/gas/elf/section21.s: Don't check for a parse error. + +2024-02-24 Alan Modra + + xtensa: move xtensa_make_property_section from bfd to gas + This function is only used by gas, so move it there. Necessary for + gas to keep track of group sections as they are created. + + PR 25333 + bfd/ + * elf32-xtensa.c (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Make public. + include/ + * elf/xtensa.h (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Declare + gas/ + * config/tc-xtensa.c (xtensa_make_property_section): New, + moved from elf32-xtensa.c. + +2024-02-24 Alan Modra + + Make is_relocatable_executable only affect dynamic section syms + I believe the only elflink.c specialties for is_relocatable_executable + needed by tic6x are those directly related to dynamic section symbols. + I might be wrong, the code in record_dynamic_symbol and + record_link_assignment predated the tic6x port, but I think these were + symbian specific hacks. + + The shlib-app-1* testsuite changes aren't needed for this patch. I + started making them when trying to remove is_relocatable_executable + completely, but figure it is worth keeping the more permissive address + matching for some future generic linker change. The static-app-1* + changes also adjust to the fact that an unneeded "c" no longer appears + in the dynamic symbol table. + + bfd/ + * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't do anything + special for is_relocatable_executable. + (bfd_elf_record_link_assignment): Likewise. + ld/ + * testsuite/ld-tic6x/shlib-app-1.rd: Make some address matching + more permissive. + * testsuite/ld-tic6x/shlib-app-1b.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1r.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise. + * testsuite/ld-tic6x/static-app-1.rd: Likewise, and adjust expected + dynamic symbol table. + * testsuite/ld-tic6x/static-app-1b.rd: Likewise. + * testsuite/ld-tic6x/static-app-1r.rd: Likewise. + * testsuite/ld-tic6x/static-app-1rb.rd: Likewise. + +2024-02-24 Alan Modra + + sim: no rule to make sim/ppc/Makefile.in + Seen with --enable-maintainer-mode. + make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed + by 'ppc/stamp-pk'. Stop. + + * sim/ppc/local.mk (stamp-pk): Depend on local.mk not + Makefile.in. + * Makefile.in: Regenerate. + + Approved-By: Tom Tromey + +2024-02-24 GDB Administrator + + Automatic date update in version.in + +2024-02-23 Simon Marchi + + gdb: disable formatting-related flake8 warnings + Tom Tromey pointed out that flake8 gives some warnings related to + formatting, such as: + + python/lib/gdb/prompt.py:149:43: E203 whitespace before ':' + + We don't care about those, since all our formatting is handled + automatically by black, so ignore these warnings. + + The list of warnings I put comes from: + + https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8 + + Note that since the setup.cfg file is under the gdb directory, it will + be picked up if you run flake8 from the gdb directory like this: + + binutils-gdb/gdb $ flake8 python + + but not if you do: + + binutils-gdb $ flake8 gdb/python + + Change-Id: I1e42aefd388b9c3b6c9d52b4f635ac881db4bbc1 + Approved-By: Tom Tromey + +2024-02-23 Tom Tromey + + Remove unused import + flake8 points out that dap/io.py does not use send_gdb. This patch + removes the unused import. + +2024-02-23 Pedro Alves + + Fix throw_winerror_with_name build error on x86-64 Cygwin + The GDB build currently fails on x86-64 Cygwin, with: + + src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’: + src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=] + 152 | error (_("%s (error %d): %s"), string, err, strwinerror (err)); + | ^ + + Fix this by adding a cast. While at it, the error codes are really a + DWORD that results from a GetLastError() call, so I think unsigned is + more appropriate. That is also what strwinerror already does: + + sprintf (buf, "unknown win32 error (%u)", (unsigned) error); + + The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned + long long, but for some reason, I don't get a warning there. + + Approved-By: Tom Tromey + Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17 + +2024-02-23 Pedro Alves + + gdb/linux-nat.c: Add "Accessing inferior memory" section + This commit adds a new "Accessing inferior memory" comment section to + gdb/linux-nat.c that explains why we prefer /proc/pid/mem over + alternatives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30453 + + Change-Id: I575b21ed697a85f3ff4c0ec58c04812db5005b76 + +2024-02-23 Jon Turney + + Drop special way of getting inferior context after a Cygwin signal + Simplify Cygwin signal handling by dropping the special way of getting + inferior context after a Cygwin signal. + + I think the reason this existed was because previously we were not + able to unwind through the alternate stack used by _sigfe frames, so + without the hint of the "user" code IP, the backtrace from a signal + was unusable. + + Now we can unwind through _sigfe frames, drop all this complexity. + + (Restoring this specially obtained context to the inferior (as the + code currently does) skips over the actual signal delivery and + handling. Cygwin has carried for a long time a patch which clears the + ContextFlags in the signal context, so we never attempt to restore it + to the inferior, but that interfers with gdb's ability to modify that + context e.g. if it decides it wants to turn on FLAG_TRACE_BIT.) + + Change-Id: I214edd5a99fd17c1a31ad18138d4a6cc420225e3 + +2024-02-23 Jon Turney + + Teach gdb how to unwind cygwin _sigbe and sigdelayed frames + The majority of functions in the cygwin DLL are wrapped by routines + which use an an alternate stack to return via a signal handler if a + signal occured while inside the function. (See [1],[2]) + + At present, these frames cannot be correctly unwound by gdb. There + doesn't seem to currently be a way to correctly describe these frames + using DWARF CFI. + + So instead, write a custom unwinder for _sigbe and sigdelayed frames, + which gets the return address from the alternate stack. + + The offset of tls::stackptr from TIB.stacktop is determined by analyzing + the code in _sigbe or sigdelayed. + + This can backtrace from _sigbe and from a sighandler through sigdelayed. + + Implemented for amd64 and i386 + + Issues: + + 1. We should detect if we are in the wrapper after the return address + has been popped off the alternate stack, and if so, fetch the return + address from the register it's been popped into. + + 2. If there are multiple _sigbe or sigdelayed stack frames to be + unwound, this only unwinds the first one correctly, because we don't + unwind the value of the alternate stack pointer itself. + + This is no worse than currently, when we can't even unwind one of + these frame correctly, but isn't quite correct. + + I guess this could be handled by defining a pseudo-register to track + its value as we unwind the stack. + + [1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/gendef + [2] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/how-signals-work.txt + + Co-Authored-By: Pedro Alves + Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc + +2024-02-23 Jan Beulich + + x86: rename vec_encoding and vex_encoding_* + Even with just VEX these weren't limited to vector insns. With APX the + set of non-vector ones covered has greatly increased. Drop the vec_ + prefix. Also drop the vex_ ones off of the enumerators, as they weren't + appropriate anyway: Should have been vec_ then, too. + + x86: document -moperand-check= + PR gas/31388 + Like other command line options this should be mentioned in + documentation as well, not just in "as --help" output. + +2024-02-23 Jan Beulich + + x86: also permit YMM/ZMM use in CFI directives + Next to code using %ymm or %zmm it is more natural to have .cfi_* + directives also reference those, not the corresponding %xmm. Accept + their names as kind of aliases, i.e. resolving to the same numbers. + + While extending the respective 64-bit testcase, also add %bnd there + (should have happened right with 633789901c83 ["x86-64: Dwarf2 register + numbers for %bnd"], sorry), requiring binutils/dwarf.c to be adjusted + accordingly as well. + +2024-02-23 Jan Beulich + + x86/APX: INV{EPT,PCID,VPID} are WIG + While various other entries in version 003 of the spec aren't quite as + explicit (due to simply leaving the respective field blank), all three + have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0 + by default (and respect -mevexwig=). + +2024-02-23 mengqinggang + + LoongArch: gas: Try to avoid R_LARCH_ALIGN associate with a symbol + The R_LARCH_ALIGN need to associated with a symbol if .align has the first + and third expressions. If R_LARCH_ALIGN associate with a symbol, the addend can + represent the first and third expression of .align. + + For '.align 3', the addend of R_LARCH_ALIGN only need to represent the alignment + and R_LARCH_ALIGN not need to associate with a symbol. + + For '.align x, , y', R_LARCH_ALIGN need to associate with a symbol if 0 < y < + 2^x - 4. + +2024-02-23 H.J. Lu + + gdb: Add XMM16-XMM31 and K0-K1 DWARF register number mapping + Add XMM16-XMM31 and K0-K1 DWARF register number mapping to + amd64_dwarf_regmap. + + Reviewed-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-02-23 GDB Administrator + + Automatic date update in version.in + +2024-02-22 Tom Tromey + + Use bool in dynamic type code + This changes some of the dynamic-type-related code to use bool rather + than int. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-02-22 Tom de Vries + + [gdb/testsuite] Fix license text in gdb.reverse/map-to-same-line.{c,exp} + I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are + using some kind of indirection via urldefense.proofpoint.com. + + Fix this by removing this indirection. + + Tested on x86_64-linux. + + PR testsuite/31358 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap exit and gdb exit + When DAP shuts down due to an EOF event, there's a race between: + - gdb's main thread handling a SIGHUP, and + - the DAP main thread exiting. + + Fix this by waiting for DAP's main thread exit during the gdb_exiting event. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap startup and dap log file + In dap_gdb_start we do: + ... + append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap" + ... + + While the dap log file setting comes before the dap interpreter setting, + the order is the other way around: + - first, the dap interpreter is started + - second, the -iex commands are executed and the log file is initialized. + + Consequently, there's a race between dap interpreter startup and dap log file + initialization. + + This cannot be fixed by using -eiex instead. Before the interpreter is + started, the "set debug dap-log-file" command is not yet registered. + + Fix this by postponing the start of the DAP server until GDB has processed all + command files. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31386 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386 + +2024-02-22 Tom de Vries + + [gdb/dap] Factor out thread_log + In thread_wrapper I used a style where a message is prefixed with the thread + name. + + Factor this out into a new function thread_log. + + Also treat the GDB main thread special, because it's usual name is MainThread: + ... + MainThread: + ... + which is the default name assigned by python, so instead use the more + explicit: + ... + GDB main: + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-22 GDB Administrator + + Automatic date update in version.in + +2024-02-21 Tom Tromey + + Don't allow multiple request registrations in DAP + This changes the DAP code to check that a given request or capability + is only registered a single time. This is just a precaution against + accidentally introducing a second definition of a request somewhere. + +2024-02-21 Alan Modra + + Leak in i386_elf_section_change_hook + notes_alloc is perfect for assorted memory you can't free easily + and/or would rather leave freeing until just before exit. + + * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc. + +2024-02-21 Simon Marchi + + gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable} + This code was there to support g++ 4, which didn't support + std::is_trivially_constructible and std::is_trivially_copyable. Since + we now require g++ >= 9, I think it's fair to assume that GDB will + always be compiled with a compiler that supports those. + + Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1 + +2024-02-21 Simon Marchi + + gdb: remove some GCC version checks + Since we now require C++17, and therefore gcc >= 9, it's no longer + useful to have gcc version checks for older gcc version. + + Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 + Reviewed-by: Kevin Buettner + Approved-By: Pedro Alves + +2024-02-21 Tom de Vries + + [gdb/testsuite] Fix error handling in _dap_read_json + In _dap_read_json we have a gdb_expect with clauses that generate errors: + ... + timeout { + error "timeout reading json header" + } + eof { + error "eof reading json header" + } + ... + + Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar + semantics related to errors: + ... + # remote_expect works basically the same as standard expect, but it + # also takes care of getting the file descriptor from the specified + # host and also calling the timeout/eof/default section if there is an + # error on the expect call. + ..... + + When a timeout triggers, it generates a timeout error, which is reported by + gdb_expect, after which it runs the timeout/eof/default clauses, which + generates an eof error, which is reported by runtest. + + I think the intention here is to generate just a one error, a timeout error. + + Fix this by postponing generating the error until after gdb_expect. + + Tested on x86_64-linux, by: + - running all the DAP test-cases and observing no regressions, and + - modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and + observing only a timeout error. + + PR testsuite/31382 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382 + +2024-02-21 Yuriy Kolerov + + arc: Determine a branch target of DBNZ correctly + DBNZ instruction was moved from BRANCH class to a separate one - DBNZ. + Thus, it must be processed separately in arc_insn_get_branch_target + to correctly determine an offset for a possible branch. + + The testsuite for DBNZ instruction verifies these cases: + + 1. Check that dbnz does not branch and falls through if its source + register is 0 after decrementing. GDB must successfully break + on the following instruction after stepping over. + 2. Check that dbnz branches to the target correctly if its source register + is not 0 after decrementing - GDB must successfully break on the target + instruction if a forward branch is performed after stepping over. + 3. The same as point 2 but for a backward branching case. + +2024-02-21 Alan Modra + + Re: PR29785, memory bloat after b43771b045fb + Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift + exponent 64 is too large". This is on the bucket_high_pc calculation + which was moved to the top of insert_arange_in_trie where previously + it was later, at a point where the overflow could not occur. Move it + back and arrange for a duplicate calculation of bucket_high_pc which + is also protected from overflow. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Split bucket_high_pc. + Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help. + +2024-02-21 Alan Modra + + Remove is_relocatable_executable from backend code + With the removal of symbian support, most targets no longer or never + did set is_relocatable_executable. Remove the backend support that is + no longer relevant. + + * elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub), + (elf32_arm_final_link_relocate, elf32_arm_check_relocs), + (elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol), + (elf32_arm_output_arch_local_syms): Remove is_relocatable_executable + code and comments. + * elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise. + * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise. + * elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise. + * elfxx-mips.c (count_section_dynsyms): Likewise. + +2024-02-21 Matthieu Longo + + aarch64: testsuite: move sysreg tests into sysreg sub-directory + This patch moves the existing sysreg tests for AArch64 into a subdirectory + (sysreg). The number of test files related to system registers grew + relatively big with time and makes the browsing of those files difficult. + Moreover, the difference of naming for the failure, working, and + feature-specific scenarios causes the tests not to appear next to one + another in the exploration tree when it is ordered alphabetically. + +2024-02-21 Tom de Vries + + [gdb/dap] Join JSON writer thread with DAP thread + The DAP interpreter runs in its own thread, and starts a few threads: + - the JSON reader thread, + - the JSON writer thread, and + - the inferior output reader thread. + + As part of the DAP shutdown, both the JSON reader thread and the JSON writer + thread, as well as the DAP main thread run to exit, but these exits are not + ordered in any way. + + Wait in the main DAP thread for the exit of the JSON writer thread. + + This makes sure that the responses are flushed to the DAP client before DAP + shutdown. + + An earlier version of this patch used Queue.task_done() to accomplish the + same, but that didn't guarantee writing the ": terminating" + log entry from thread_wrapper before DAP shutdown. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-21 Tom de Vries + + [gdb/dap] Make dap log printing thread-safe + I read that printing from different python threads is thread-unsafe, and I + noticed that the dap log printing is used from different threads, but doesn't + take care to make the printing thread-safe. + + Fix this by using a lock to access LoggingParam.log_file. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/dap] Flush after printing in log_stack + I noticed that function log flushes the dap log file after printing, but + that function log_stack doesn't. + + Fix this by also flushing the dap log file in log_stack. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp + While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP + patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap + log file. + + This is normally set up by dap_gdb_start, but the test-case doesn't use it. + + Fix this by doing "set debug dap-log-file $logfile" in the test-case. + + To make it easy to do so, I've factored out a new proc new_dap_log_file, and + while at likewise a new proc current_dap_log_file. + + Note that the log file is currently empty. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Felix Willgerodt + + gdb: Document C++17 build requirement. + We require C++17 to build for a while now: + https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1 + + Reviewed-By: Lancelot Six + +2024-02-21 Tatsuyuki Ishi + + RISC-V: Fix local GOT and reloc size calculation for TLS. + The previous code did not account correctly for two cases: + * A TLS symbol can be referenced with multiple TLS types (although rare), + in which case it only allocated the maximum slot size among the types, + instead of the sum. + * TLS relocations are only needed for DLLs, unlike normal symbols which + requires relocations for all PIE code. + + Modify the logic to account for the two cases, so this fixes the redundant + dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + bfd/ + * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation + sizing for TLS and non-TLS symbols differently, with the former + requiring relocs on DLL while the latter requiring on PIE. + Allocate GOT slots and relocation slots for each TLS type separately, + accounting for the possibility of a TLS variable getting referenced by + multiple symbols. + ld/ + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with + symbols referred by both types and global and local symbols. + +2024-02-21 Nelson Chu + + RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax. + Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c. Theoretically, + assembler don't need to generate the pc-relative relocation and the refered + local .L symbol when relaxation is disabled. The above commit improved the + pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump + relocations. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + gas/ + * config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all + branch and jump relocations when -mno-relax. + +2024-02-21 GDB Administrator + + Automatic date update in version.in + +2024-02-20 Tom Tromey + + Rewrite Rust slice type handling + This patch rewrites the handling of slice types in Rust. + + More recent versions of the Rust compiler changed how unsized types + were emitted, letting gdb inspect them more nicely. However, gdb did + not do this, and in fact treated all such types as if they were slices + of arrays, which is incorrect. + + This patch rewrites this handling and removes the restriction that + unsized types must be array slices. I've added a comment explaining + how unsized types are represented to rust-lang.c as well. + + I looked into a different approach, namely changing the DWARF reader + to fix up slice types to have a dynamic type. However, the approach + taken here turned out to be simpler. + + Tested on x86-64 Fedora 38 with a variety of Rust compiler versions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + +2024-02-20 Tom Tromey + + Add obj_section::contains method + I noticed a number of spots checking whether an address is in an + obj_section. This patch introduces a new method for this and changes + some code to use it. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Andrew Burgess + +2024-02-20 Simon Marchi + + gdb: pass frames as `const frame_info_ptr &` + We currently pass frames to function by value, as `frame_info_ptr`. + This is somewhat expensive: + + - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass + by value + - the constructors and destructor link/unlink the object in the global + `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so + it's not so bad: it's just assigning a few points, there's no memory + allocation as if it was `std::list`, but still it's useless to do + that over and over. + + As suggested by Tom Tromey, change many function signatures to accept + `const frame_info_ptr &` instead of `frame_info_ptr`. + + Some functions reassign their `frame_info_ptr` parameter, like: + + void + the_func (frame_info_ptr frame) + { + for (; frame != nullptr; frame = get_prev_frame (frame)) + { + ... + } + } + + I wondered what to do about them, do I leave them as-is or change them + (and need to introduce a separate local variable that can be + re-assigned). I opted for the later for consistency. It might not be + clear why some functions take `const frame_info_ptr &` while others take + `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because + it did re-assign its parameter, I doubt that we would think to change it + to `const frame_info_ptr &` should the implementation change such that + it doesn't need to take `frame_info_ptr` anymore. It seems better to + have a simple rule and apply it everywhere. + + Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 + Approved-By: Andrew Burgess + +2024-02-20 Tom de Vries + + [gdb] Don't init history in batch mode + I noticed in captured_main_1 that init_history is called just before bailing + out if batch_flag is true. + + The history is used only in an interactive session, so there's no need to + initialize it in batch mode. + + Fix this by moving init_history to after the batch mode check. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-02-20 Paul Iannetta + + kvx: gas: missing aliases for $r14r15 in assembler. + Most registers from a register-pair suffixed by .lo and .hi suffixes. + This was not the case of $r14 and $r15 since they are defined by the + ABI: $r14 is the frame pointer, and $r15 is used to return aggregates + from functions. We do not add aliases for $r12 (the stack pointer) and + $r13 (the tls register). + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: enable magic immediates for integer multiply-accumulate and CMOVE* + Affected instructions: + - alu unit: + cmovewp cmovehq + - mau unit: + maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp + msbfsuwdp mms mulwdp muluwdp mulsuwdp mm + + opcodes/ChangeLog: + + * kvx-opc.c (struct kvxopc): Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: rename: or -> ior, xor -> eor + TCA instructions start with an X, this introduces ambiguities when it + comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this + reason, we rename OR to IOR and XOR to EOR. + + OR and XOR variants are still valid on KV3-1 and KV3-2. However, they + have been completely removed from KV4-1. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: move the splat modifier to the immediate + The position of the splat modifier is now after the operand it + modifies and not attached directly to the opcode. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: fix leak + gas/ChangeLog: + + * config/tc-kvx.c (md_apply_fix): Free memory at this end. + +2024-02-20 Paul Iannetta + + kvx: Improve lexing & parsing + Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates, + however this candidate can be directly extracted from the array (in + kvx-parse.h) registering all the immediates. + + During lexing, we ignored trailing characters after a number, this is + not good enough since now number can be followed by a modifier. The + function READ_TOKEN and GET_TOKEN_CLASS have been update to take this + into account. + + gas/ChangeLog: + + * config/kvx-parse.c (promote_token): Do not rely on + env.promote_immediate anymore. + (get_token_class): Do not ignore trailing characters after a + number. + (read_token): Likewise. + (print_token_list): THIS SHOULD NOT BE HERE. + +2024-02-20 Paul Iannetta + + kvx: gas: fix the detection of negative powers of 2 + The detection of negative powers of 2 was wrong and could lead to + well-formed bundles ending up taking more syllables than necessary. + + gas/ChangeLog: + + * config/kvx-parse.c (get_token_class): Use the signed value. + * testsuite/gas/kvx/np2-detection.d: New test. + * testsuite/gas/kvx/np2-detection.s: New test. + +2024-02-20 Jose E. Marchesi + + bpf: gas: add missing indcall-badoperand.* test files + This adds teh following files that were missing in the previous + commit ecd16ae4e47118f66447641d93a6aa1334e550d4 + + testsuite/gas/bpf/indcall-badoperand.d + testsuite/gas/bpf/indcall-badoperand.l + testsuite/gas/bpf/indcall-badoperand.s + +2024-02-20 GDB Administrator + + Automatic date update in version.in + +2024-02-19 Will Hawkins + + bpf: fix bpf expression parsing regression in GAS + As a result of a switch instead of an if, as would issue non-specific + error messages when it encountered an operand it could not parse in bpf. + This patch fixes that regression and adds a test to prevent it from + reoccurring. + + Tested for bpf-unknown-none on x86_64-redhat-linux. + + gas/ChangeLog: + + * config/tc-bpf.c (parse_expression): Change switch to if so that error + * condition is handled. + * testsuite/gas/bpf/bpf.exp: Invoke new test. + * testsuite/gas/bpf/indcall-badoperand.d: New test. + * testsuite/gas/bpf/indcall-badoperand.l: New test. + * testsuite/gas/bpf/indcall-badoperand.s: New test. + +2024-02-19 Jose E. Marchesi + + bpf: gas: avoid UB in pointer subtraction + The PARSE_ERROR macro in md_assemble performs pointer subtraction. If + parse_expression returns NULL then the later will be part of the + subtraction and therefore UB will be incurred. + + This patch changes md_assemble to: + 1. Accommodate all invocations to parse_expression to the fact it will + return NULL when a parse error occurs. + 2. Avoid UB in PARSE_ERROR. + + Tested in bpf-unknown-none target / x86_64-linux-gnu host. + + gas/ChangeLog: + + * config/tc-bpf.c (md_assemble): Fix to take into account that + parse_expression can return NULL. + (PARSE_ERROR): Avoid passing invalid length to parse_error. + +2024-02-19 Claudio Bantaloukas + + arm: Add support for Armv9.5-A + +2024-02-19 Yury Khrustalev + + aarch64: Add support for the id_aa64isar3_el1 system register + Hi, + + [PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + + Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf? + + Thanks, + Yury Khrustalev + + From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001 + From: Yury Khrustalev + Date: Tue, 6 Feb 2024 11:05:39 +0000 + Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the + id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + +2024-02-19 Tankut Baris Aktemur + + testsuite, python: reformat python files using black + In the recent patch titled "gdb, python: selectively omit enabling + stdin in gdb.execute", the black tool found formatting issues. Fix + them. + +2024-02-19 Zac Walker + + aarch64: Add new relocations and limit COFF AArch64 relocation offsets + The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation + type. This is needed for 32-bit relative address. + + It also adds a check for relocation offsets over 21 bits. Offsets + inside coff files are stored in instruction code. In the case of ADRP + the actual value is stored, not a downshifted page offset. This means + values over 21 bits would otherwise be truncated. + + Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped. + + ChangeLog: + + * bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add + BFD_RELOC_AARCH64_ADR_GOT_PAGE, + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32 + relocations. + (coff_pe_aarch64_relocate_section): Likewise. + * gas/write.c (adjust_reloc_syms): COFF AArch64 relocation + offsets need to be limited to 21bits + (defined): Likewise. + +2024-02-19 Tankut Baris Aktemur + + gdb, python: selectively omit enabling stdin in gdb.execute + From the Python API, we can execute GDB commands via gdb.execute. If + the command gives an exception, however, we need to recover the GDB + prompt and enable stdin, because the exception does not reach + top-level GDB or normal_stop. This was done in commit + + commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a + Author: Andrew Burgess + Date: Tue Nov 19 11:17:20 2019 +0000 + + gdb: Enable stdin on exception in execute_gdb_command + + with the following code: + + catch (const gdb_exception &except) + { + /* If an exception occurred then we won't hit normal_stop (), or have + an exception reach the top level of the event loop, which are the + two usual places in which stdin would be re-enabled. So, before we + convert the exception and continue back in Python, we should + re-enable stdin here. */ + async_enable_stdin (); + GDB_PY_HANDLE_EXCEPTION (except); + } + + In this patch, we explain what happens when we run a GDB command in + the context of a synchronous command, e.g. via Python observer + notifications. + + As an example, suppose we have the following objfile event listener, + specified in a file named file.py: + + ~~~ + import gdb + + class MyListener: + def __init__(self): + gdb.events.new_objfile.connect(self.handle_new_objfile_event) + self.processed_objfile = False + + def handle_new_objfile_event(self, event): + if self.processed_objfile: + return + + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('add-inferior -no-connection') + gdb.execute('inferior 2') + gdb.execute('target remote | gdbserver - /tmp/a.out') + gdb.execute('inferior 1') + + the_listener = MyListener() + ~~~ + + Using this Python file, we see the behavior below: + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3075406 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3075400] (/tmp/a.out)] + [Switching to thread 1.1 (process 3075400)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + (gdb) [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3075400) exited normally] + + Note how the GDB prompt comes in-between the debugger output. We have this + obscure behavior, because the executed command, "target remote", triggers + an invocation of `normal_stop` that enables stdin. After that, however, + the Python notification context completes and GDB continues with its normal + flow of executing the 'run' command. This can be seen in the call stack + below: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801 + #3 0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225 + #4 0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316 + #5 0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175 + #6 0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338 + #7 0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280) at src/gdb/target.c:824 + #8 0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735 + #9 0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575 + #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529 + #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701 + #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411 + #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700 + #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52 + #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195 + #24 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #25 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #26 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290 + #27 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590 + #28 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166 + #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416 + #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The use of the "target remote" command here is just an example. In + principle, we would reproduce the problem with any command that + triggers an invocation of `normal_stop`. + + To omit enabling the stdin in `normal_stop`, we would have to check the + context we are in. Since we cannot do that, we add a new field to + `struct ui` to track whether the prompt was already blocked, and set + the tracker flag in the Python context before executing a GDB command. + + After applying this patch, the output becomes + + ... + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3032261 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3032255] (/tmp/a.out)] + [Switching to thread 1.1 (process 3032255)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3032255) exited normally] + (gdb) + + Let's now consider a secondary scenario, where the command executed from + the Python raises an error. As an example, suppose we have the Python + file below: + + def handle_new_objfile_event(self, event): + ... + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('print a') + + The executed command, "print a", gives an error because "a" is not + defined. Without this patch, we see the behavior below, where the + prompt is again placed incorrectly: + + ... + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + (gdb) [Inferior 1 (process 3980401) exited normally] + + This time, `async_enable_stdin` is called from the 'catch' block in + `execute_gdb_command`: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713 + #2 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #3 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #4 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #5 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #6 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #7 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #8 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #9 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52 + #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195 + #12 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #13 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #14 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290 + #15 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590 + #16 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166 + #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416 + #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + Again, after we enable stdin, GDB continues with its normal flow + of the 'run' command and receives the inferior's exit event, where + it would have enabled stdin, if we had not done it prematurely. + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700 + #3 0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42 + #4 0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316 + #5 0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573 + #6 0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694 + #7 0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217 + #8 0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407 + #9 0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471 + #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324 + #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The solution implemented by this patch addresses the problem. After + applying the patch, the output becomes + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + [Inferior 1 (process 3984511) exited normally] + (gdb) + + Regression-tested on X86_64 Linux using the default board file (i.e. unix). + + Co-Authored-By: Oguzhan Karakaya + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-02-19 Tom de Vries + + [gdb/exp] Fix printing of out of bounds struct members + When building gdb with -O0 -fsanitize=address, and running test-case + gdb.ada/uninitialized_vars.exp, I run into: + ... + (gdb) info locals + a = 0 + z = (a => 1, b => false, c => 2.0) + ================================================================= + ==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80 + READ of size 4 at 0x602000097f58 thread T0 + #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18) + #1 0xbcab24 in unsigned char* std::__copy_move_backward::__copy_move_b(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748 + #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769 + #3 0xbc898c in unsigned char* std::__copy_move_backward_a1(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778 + #4 0xbc715c in unsigned char* std::__copy_move_backward_a(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807 + #5 0xbc4e6c in unsigned char* std::copy_backward(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867 + #6 0xbc2934 in void gdb::copy(gdb::array_view, gdb::array_view) gdb/../gdbsupport/array-view.h:223 + #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239 + #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078 + #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095 + #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658 + #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857 + #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042 + #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04) + #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092 + #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184 + #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #18 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #19 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #20 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #29 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694 + #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264 + #39 0x1768080 in start_event_loop gdb/main.c:408 + #40 0x17684c4 in captured_command_loop gdb/main.c:472 + #41 0x176cfc8 in captured_main gdb/main.c:1342 + #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361 + #43 0xb73edc in main gdb/gdb.c:39 + #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8) + #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac) + #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c) + + 0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58) + allocated by thread T0 here: + #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218) + #1 0xcbc278 in xcalloc gdb/alloc.c:97 + #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29 + #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937 + #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033 + #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector > const&) gdb/value.c:229 + #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560 + #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133 + #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182 + #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #11 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #12 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #13 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #22 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + + SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove + ... + + The error happens when trying to print either variable y or y2: + ... + type Variable_Record (A : Boolean := True) is record + case A is + when True => + B : Integer; + when False => + C : Float; + D : Integer; + end case; + end record; + Y : Variable_Record := (A => True, B => 1); + Y2 : Variable_Record := (A => False, C => 1.0, D => 2); + ... + when the variables are uninitialized. + + The error happens only when printing the entire variable: + ... + (gdb) p y.a + $2 = 216 + (gdb) p y.b + There is no member named b. + (gdb) p y.c + $3 = 9.18340949e-41 + (gdb) p y.d + $4 = 1 + (gdb) p y + + ... + + The error happens as follows: + - field a functions as discriminant, choosing either the b, or c+d variant. + - when y.a happens to be set to 216, as above, gdb interprets this as the + variable having the c+d variant (which is why trying to print y.b fails). + - when printing y, gdb allocates a value, copies the bytes into it from the + target, and then prints the value. + - gdb allocates the value using the type size, which is 8. It's 8 because + that's what the DW_AT_byte_size indicates. Note that for valid values of a, + it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1 + (b variant), size is 8. + - gdb tries to print field d, which is at an 8 byte offset, and that results + in a out-of-bounds access for the allocated 8-byte value. + + Fix this by handling this case in value::contents_copy_raw, such that we have: + ... + (gdb) p y + $1 = (a => 24, c => 9.18340949e-41, + d => ) + ... + + An alternative (additional) fix could be this: in compute_variant_fields_inner + gdb reads the discriminant y.a to decide which variant is active. It would be + nice to detect that the value (y.a == 24) is not a valid Boolean, and give up + on choosing a variant altoghether. However, the situation regarding the + internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not + possible to reliably decide what valid values are. + + The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is + a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the + copyright years. + + Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc + versions. [ So, it would be nice to rewrite it into a dwarf assembly + test-case. ] + + The test-case loops over all languages. This is inherited from an earlier + attempt to fix this, which had language-specific fixes (in print_field_values, + cp_print_value_fields, pascal_object_print_value_fields and + f_language::value_print_inner). I've left this in, but I suppose it's not + strictly necessary anymore. + + Tested on x86_64-linux. + + PR exp/31258 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258 + +2024-02-19 GDB Administrator + + Automatic date update in version.in + +2024-02-18 GDB Administrator + + Automatic date update in version.in + +2024-02-17 GDB Administrator + + Automatic date update in version.in + +2024-02-16 H.J. Lu + + ld: Add -plugin-save-temps + Add -plugin-save-temps to store plugin intermediate files permanently. + It can be used to exam the final input object files generated from IR + inputs. + + * NEWS: Mention -plugin-save-temps. + * ld.h (ld_config_type): Add plugin_save_temps. + * ld.texi: Document -plugin-save-temps. + * ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS. + * lexsup.c (ld_options): Add -plugin-save-temps. + (parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS. + * plugin.c (plugin_call_cleanup): Don't call plugin + cleanup_handler for -plugin-save-temps. + +2024-02-16 Alan Modra + + PR27597, nios: assertion fail in nios2_elf32_install_imm16 + The assertion in nios2_elf32_install_imm16 triggers when the PLT is + twice the maximum allowable size for a branch from PLTn to reach + .PLTresolve, and on no other call to nios2_elf32_install_imm16. That + makes the assertion completely useless. We can handle a PIC PLT + exceeding 0x8000 in size by bouncing branches that won't reach through + previous branches. + + PR 27597 + * elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT. + (nios2_build_one_stub): Don't bother masking value passed to + nios2_elf32_install_imm16. + (nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow + of PLTn branch to .PLTresolve by bouncing through prior branches. + +2024-02-16 Nick Clifton + + Update how-to-make-a-release document to reference new git repository for the documentation + +2024-02-16 Jan Beulich + + x86/APX: drop stray IgnoreSize + While necessary on the legacy encodings, the EVEX ones don't need it. + Even more so when they're available for 64-bit mode only, when the + legacy encodings have the attribute only for correctly handling things + in 16-bit mode. + + x86: don't use VexWIG in SSE2AVX templates + Several years ago it was decided that SSE2AVX templates should not be + sensitive to -mvexwig= (upon my suggestion to consistently make all + sensitive as long as they don't require a specific setting of VEX.W). + Adjust the four that still are, switching to use of Vex128 at the same + time. + + x86: drop redundant Xmmword + While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from + insn templates") did so for Byte/Word/Dword/Qword, the same kind of + redundancy was left in place for a few 128-bit SIMD operands. + + SCFI: correct test names + Having multiple tests with the same name is confusing. + +2024-02-16 GDB Administrator + + Automatic date update in version.in + +2024-02-15 H.J. Lu + + x86: Display -msse-check= default as none + Display -msse-check= default as none for "as --help" since its default + is none, not warning. + + PR gas/31389 + * config/tc-i386.c (md_show_usage): Change -msse-check= default + to none. + +2024-02-15 Alan Modra + + S/390: 32-bit PIE undef weak failures + Like 10e7c0457cb7 but for elf32-s390.c + + * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use + UNDEFWEAK_NO_DYNAMIC_RELOC. + (allocate_dynrelocs): Likewise. + (elf_s390_relocate_section): Check resolved_to_zero. + (elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if + UNDEFWEAK_NO_DYNAMIC_RELOC. + +2024-02-15 Tom Tromey + + Move lookup_name_info creation into basic_lookup_transparent_type + I noticed that basic_lookup_transparent_type calls two different + functions that both proceed to create a lookup_name_info. It's more + efficient to create this object in the outermost layer possible. + Making this change required a few related changes, resulting in this + patch. + + There are still more changes of this sort that could be made. + + Regression tested on x86-64 Fedora 38. + +2024-02-15 Will Hawkins + + objdump, as: add callx support for BPF CPU v1 + Albeit not being a currently valid BPF instruction, callx is generated + by both clang and GCC when BPF programs are compiled unoptimized. + Until now, GCC would emit it only whe using the experimental + compiler-testing cpu version xbpf, whereas clang would emit it from + v1. This patch makes GAS to accept callx also starting with cpu v1. + + opcodes/ChangeLog + + * bpf-opc.c: Move callx into the v1 BPF CPU variant. + + gas/ChangeLog + + * testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu + version. + * testsuite/gas/bpf/indcall-1.d: Likewise. + +2024-02-15 Alan Modra + + Make various gas symbol predicates and accessors take const args + * symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK), + (S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED), + (S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD), + (symbol_previous, symbol_next, symbol_X_add_number), + (symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p), + (symbol_mri_common_p, symbol_written_p, symbol_removed_p), + (symbol_resolved_p, symbol_resolving_p, symbol_section_p), + (symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p), + (symbol_shadow_p, symbol_same_p): Constify sym args. + * symbols.h: Update prototypes. + + Re: elf_backend_finish_dynamic_symbol returning false + Making a bfd_final_link failure noisy requires testsuite changes. + + PR28448, Memory leak in function add_symbols(plugin.c) + PR 28448 + * plugin.c (add_symbols): bfd_alloc memory for symptrs. Check + bfd_make_empty_symbol return. + + Re: elf_backend_finish_dynamic_symbol returning false + I didn't examine ld testsuite logs properly after cf95b909e2c2. + Replacing one of the "return false" with BFD_ASSERT in + finish_dynamic_symbol was wrong as it causes segmentation faults on + testcases expected to fail. Revert those changes and instead make + a bfd_final_link failure noisy. + +2024-02-15 Samuel Tardieu (tiny change) + + gdb/doc: Fix several typos in GDB documentation + Approved-by: Eli Zaretskii + +2024-02-15 Steinar H. Gunderson + + PR29785, memory bloat after b43771b045fb + Pathological cases of dwarf info with overlapping duplicate memory + ranges can cause splitting of trie leaf nodes, which in the worst case + will cause memory to increase without bounds. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Don't split leaf nodes + unless that reduces number of elements in at least one node. + +2024-02-15 Alan Modra + + PR30308, infinite recursion in i386_intel_simplify + This patch exposes the symbol "resolving" flag for use in + i386_intel_simplify, not only preventing infinite recursion on the + testcase in the PR but also more complicated cases like: + + .intel_syntax + b = a + a = b + mov eax, [a] + + PR 30308 + * symbols.c (symbol_mark_resolving, symbol_clear_resolving), + (symbol_resolving_p): New functions. + * symbols.h: Declare them. + * config/tc-i386-intel.c (i386_intel_simplify): Delete forward + declaration. Formatting. + (i386_intel_simplify_symbol): Use resolving flag to prevent + infinite recursion. + +2024-02-15 Alan Modra + + elf_backend_finish_dynamic_symbol returning false + Returning false from elf_backend_finish_dynamic_symbol will not result + in an error being printed unless bfd_error is set but will result in + the linker exiting with a non-zero status. If just bfd_error is set + then a generic "final link failed" will result, which doesn't help a + user much. So elf_backend_finish_dynamic_symbol should print its own + error message whenever returning false, or use BFD_ASSERT or abort to + print assertion failures for conditions that shouldn't occur. + + This patch does that, and removes unnecessary "htab != NULL" tests in + elf_backend_finish_dynamic_symbol. Such tests aren't needed in a + function only called via elf_backend_data. + +2024-02-15 GDB Administrator + + Automatic date update in version.in + +2024-02-14 Tom de Vries + + [gdb/dap] Fix exit race + When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to + a segfault in new_threadstate. + + At the point of the core dump, the gdb main thread looks like: + ... + (gdb) bt + #0 0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0 + #6 0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0 + #7 0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738) + at gdb/python/python-internal.h:787 + #8 0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0, + __in_chrg=) at gdb/python/python.c:1051 + #9 0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy + (__victim=...) at /usr/include/c++/13/bits/std_function.h:175 + #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager + (__dest=..., __source=..., __op=std::__destroy_functor) + at /usr/include/c++/13/bits/std_function.h:203 + #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...) + at /usr/include/c++/13/bits/std_function.h:282 + #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:244 + #13 0x000000000042e654 in std::function::~function() (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:334 + #14 0x0000000000b68e60 in std::_Destroy >(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:151 + #15 0x0000000000b68cd0 in std::_Destroy_aux::__destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:163 + #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:196 + #17 0x0000000000b68414 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/alloc_traits.h:948 + #18 std::vector<...>::~vector() (this=0x2a183c8 ) + at /usr/include/c++/13/bits/stl_vector.h:732 + #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6 + #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6 + #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0) + at gdb/top.c:1822 + #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0) + at gdb/cli/cli-cmds.c:508 + #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300 + #24 0x00000000007b09d4 in async_disconnect (arg=0x0) + at gdb/event-top.c:1230 + #25 0x0000000000548acc in invoke_async_signal_handlers () + at gdb/async-event.c:234 + #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:199 + #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #29 0x000000000094567c in captured_main (data=0xffffcb279d08) + at gdb/main.c:1335 + #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08) + at gdb/main.c:1354 + #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98) + at gdb/gdb.c:39 + ... + + The direct cause of the segfault is calling PyGILState_Ensure after + calling Py_Finalize. + + AFAICT the problem is a race between the gdb main thread and DAP's JSON writer + thread. + + On one side, we have the following events: + - DAP's JSON reader thread reads an EOF, and lets DAP's main thread known + by writing None into read_queue + - DAP's main thread lets DAP's JSON writer thread known by writing None into + write_queue + - DAP's JSON writer thread sees the None in its queue, and calls + send_gdb("quit") + - a corresponding gdbpy_event is deposited in the runnables vector, to be + run by the gdb main thread + + On the other side, we have the following events: + - the gdb main thread receives a SIGHUP + - the corresponding handler calls quit_force, which calls do_final_cleanups + - one of the final cleanups is finalize_python, which calls Py_Finalize + - quit_force calls exit, which triggers the exit handlers + - one of the exit handlers is the destructor of the runnables vector + - destruction of the vector triggers destruction of the remaining element + - the remaining element is a gdbpy_event, and the destructor (indirectly) + calls PyGILState_Ensure + + It's good to note that both events (EOF and SIGHUP) are caused by this line in + the test-case: + ... + catch "close -i $gdb_spawn_id" + ... + where "expect close" closes the stdin and stdout file descriptors, which + causes the SIGHUP to be send. + + So, for the system I'm running this on, the send_gdb("quit") is actually not + needed. + + I'm not sure if we support any systems where it's actually needed. + + Fix this by removing the send_gdb("quit"). + + Tested on aarch64-linux. + + PR dap/31306 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306 + +2024-02-14 H.J. Lu + + gdb: Reformat amd64_dwarf_reg_to_regnum + Reformat amd64_dwarf_reg_to_regnum: + + @@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg) + if (reg >= 0 && reg < amd64_dwarf_regmap_len) + regnum = amd64_dwarf_regmap[reg]; + + - if (ymm0_regnum >= 0 + - && i386_xmm_regnum_p (gdbarch, regnum)) + + if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum)) + regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep); + + to remove the misaligned line. + +2024-02-14 Tom Tromey + + Use typedef in definition of warning_hook + This changes the global 'warning_hook' to use the warning_hook_handler + typedef in its definition. This makes it a little easier to change + the type, should that be needed. + +2024-02-14 Yuriy Kolerov + + arc: Put DBNZ instruction to a separate class + DBNZ instruction decrements its source register operand, and if + the result is non-zero it branches to the location defined by a signed + half-word displacement operand. + + DBNZ instruction is in BRANCH class as other branch instrucitons + like B, Bcc, etc. However, DBNZ is the only branch instruction + that stores a branch offset in the second operand. Thus it must + be placed in a distinct class and treated differently. + + For example, current logic of arc_insn_get_branch_target in GDB + assumes that a branch offset is always stored in the first operand + for BRANCH class and it's wrong for DBNZ. + + include/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * opcode/arc.h (enum insn_class_t): Add DBNZ class. + + opcodes/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * arc-tbl.h (dbnz): Use "DBNZ" class. + * arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class. + + gas/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ". + +2024-02-14 Tom de Vries + + [gdb/testsuite] Fix another fail and tcl error in gdb.dap/sources.exp + With gdb.dap/sources.exp on aarch64-linux, I'm running into: + ... + {"request_seq": 3, "type": "response", "command": "loadedSources", \ + "success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M + ^M + {"type": "event", "event": "thread", \ + "body": {"reason": "started", "threadId": 1}, \ + "seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: tcl error code TCL LOOKUP DICT body + ERROR: key "body" not known in dictionary + while executing + "dict get [lindex $obj 0] body sources" + ... + + These are the same type of tcl error and FAIL I just fixed for a later + request in the same test-case. + + Fix this by: + - moving the wait-for-stop to before the loadedSources request to fix the + FAIL, and + - checking for $obj == "" to fix the tcl error. + + Also make the code a bit less indented and more readable by wrapping the tests + in a proc, allowing the use of return to bail out, while still running + dap_shutdown afterwards. + + Approved-By: Tom Tromey + + Tested on aarch64-linux. + +2024-02-14 GDB Administrator + + Automatic date update in version.in + +2024-02-13 Yuriy Kolerov + + arc: Don't use multiline in arc-disassembler-options.exp test + Breaking a TCL string to several lines leads to adding of extra + symbols to the resulting expect string. In turn, this leads to + failing of all test cases in gdb.arch/arc-disassembler-options.exp + testsuite. It's necessary to use multi_line function in such + cases. + + Approved-By: Tom Tromey + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix fail in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ... + + The fail happens because the request races with the stopping at main as + requested by: + ... + if {[dap_launch $testfile stop_at_main 1] == ""} { + ... + + Fix this by waiting for the stop, in the same way that is done in other + test-cases that use stop_at_main. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31374 + https://sourceware.org/bugzilla/show_bug.cgi?id=31374 + +2024-02-13 Jaydeep Patil + + sim: riscv: Add support for compressed integer instructions + Added support for simulation of compressed integer instruction set ("c"). + Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions. + The compressed instructions are available for models implementing C extension. + Such as RV32IC, RV64IC, RV32GC, RV64GC etc. + + Approved-By: Andrew Burgess + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix tcl error in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: key "body" not known in dictionary + ... + + The FAIL has been filed as PR dap/31374. + + The ERROR happens because after the FAIL, dap_check_request_and_response + returns "", and the test-case doesn't check for that. + + Fix this by checking for $obj != "" in the test-case. + + Tested on x86_64-linux. + +2024-02-13 Tom de Vries + + [gdb/tdep] Fix reverse execution of LDR(immediate) T4 + When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with + target board unix/-mthumb, we run into: + ... + (gdb) reverse-step + func2 () at func-map-to-same-line.c:26 + 26 { + (gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \ + column_info_flag=column-info: step-test: reverse-step into func2 + ... + + The FAIL is caused by incorrect recording of this insn: + ... + 4f6: f85d 7b04 ldr.w r7, [sp], #4 + ... + + The insn updates the sp, but we don't record this: + ... + $ gdb -q -batch func-map-to-same-line \ + -ex "b *func2+8" \ + -ex run \ + -ex record \ + -ex "set debug record 2" \ + -ex stepi + Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27. + + Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27 + 27 } /* END FUNC2 */ + Process record: arm_process_record addr = 0xaaaaa4f6 + Process record: add register num = 15 to record list. + Process record: record_full_arch_list_add 0xabc6c460. + Process record: add register num = 7 to record list. + Process record: record_full_arch_list_add 0xabc3b868. + Process record: add register num = 25 to record list. + ... + [ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ] + + The problem is that the specific insn, an LDR(immediate) T4, is not handled in + thumb2_record_ld_word. + + Fix this by detecting the insn in thumb2_record_ld_word, and recording the + updated base register. + + Tested on arm-linux. + + Reported-By: Thiago Jung Bauermann + Approved-By: Luis Machado + + PR tdep/31278 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278 + +2024-02-13 GDB Administrator + + Automatic date update in version.in + +2024-02-12 Tom Tromey + + Introduce bfd_print_error function + gdb likes to control its own output; for example, this is important + for gdb's pager, and for logging. While BFD provides a way to + intercept error output, via bfd_set_error_handler, it turns out to be + difficult for this function to truly generate the desired output in a + gdb-friendly way -- the error handler is expected to implement some + BFD printf format extensions. + + This patch introduces a new function that an error handler can use to + format the text. This way, gdb can set the error handler and arrange + for the output to be displayed as it likes. + + * bfd.c (bfd_print_callback): Rename from print_func. Move into + comment. + (_bfd_doprnt): Update. + (bfd_print_error): New function. + (error_handler_fprintf, error_handler_sprintf): Use + bfd_print_error. + * bfd-in2.h: Rebuild. + +2024-02-12 Tom Tromey + + Do not call fputc from _bfd_doprnt + I noticed that _bfd_doprnt can unconditionally call fputc. However, + when called from error_handler_sprintf, this will likely result in a + crash, as the stream argument does not actually point to a FILE. + + * bfd.c (_bfd_doprnt): Do not call fputc. + +2024-02-12 Tom de Vries + + [gdb] Re-format dap/startup.py with black + Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made + some changes to gdb/python/lib/gdb/dap/startup.py. + + Re-format it with black. + +2024-02-12 Tom de Vries + + [gdb/dap] Catch and log exceptions in dap threads + When running test-case gdb.dap/eof.exp, it occasionally coredumps. + + The thread triggering the coredump is: + ... + #0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232 + #6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s") at gdb/ui-out.c:584 + #7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=..., + format=0x16f93ea "", args=...) at gdb/ui-out.c:621 + #8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...) + at gdb/ui-file.c:74 + #9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s", + args=...) at gdb/utils.c:1898 + #10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s") + at gdb/utils.c:1913 + #11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0) + at gdb/python/python.c:1464 + #12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0 + #17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0 + #18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0 + #19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0 + #20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O () + from /lib64/libpython3.12.so.1.0 + #21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0 + #22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0 + #25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0 + #26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6 + #27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6 + ... + + The direct cause for the coredump seems to be that cli_ui_out::do_message + is trying to write to a stream variable which does not look sound: + ... + (gdb) p *stream + $8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, { + m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}}, + m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377', + m_green = 255 '\377', m_blue = 0 '\000'}}}, + m_intensity = (unknown: 0x438fe710), m_reverse = 255}} + ... + + The string that is being printed is: + ... + (gdb) p str + $9 = "Exception in thread " + ... + so AFAICT this is a DAP thread running into an exception and trying to print + it. + + If we look at the state of gdb's main thread, we have: + ... + #0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6 + #1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 () + from /lib64/libc.so.6 + #2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0 + #3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread () + from /lib64/libpython3.12.so.1.0 + #4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads ( + this=0xfffffbea1cf8, __in_chrg=) + at gdb/python/python-internal.h:769 + #5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60, + kw=0x34553d20) at gdb/python/python.c:681 + #6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 () + from /lib64/libpython3.12.so.1.0 + #10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900) + at gdb/python/python.c:1061 + #11 0x0000000000ab93e8 in std::__invoke_impl (__f=...) + at /usr/include/c++/13/bits/invoke.h:61 + #12 0x0000000000ab9204 in std::__invoke_r (__fn=...) + at /usr/include/c++/13/bits/invoke.h:111 + #13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...) + at /usr/include/c++/13/bits/std_function.h:290 + #14 0x000000000062e0d0 in std::function::operator()() const ( + this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591 + #15 0x0000000000b67f14 in run_events (error=0, client_data=0x0) + at gdb/run-on-main-thread.c:76 + #16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1) + at gdbsupport/event-loop.cc:573 + #17 0x000000000157e760 in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:694 + #18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:264 + #19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #21 0x000000000094567c in captured_main (data=0xfffffbea23e8) + at gdb/main.c:1335 + #22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8) + at gdb/main.c:1354 + #23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578) + at gdb/gdb.c:39 + ... + + AFAIU, there's a race between the two threads on gdb_stderr: + - the DAP thread samples the gdb_stderr value, and uses it a bit later to + print to + - the gdb main thread changes the gdb_stderr value forth and back, + using a temporary value for string capture purposes + + The non-sound stream value is caused by gdb_stderr being sampled while + pointing to a str_file object, and used once the str_file object is already + destroyed. + + The error here is that the DAP thread attempts to print to gdb_stderr. + + Fix this by adding a thread_wrapper that: + - catches all exceptions and logs them to dap.log, and + - while we're at it, logs when exiting + and using the thread_wrapper for each DAP thread. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-12 Tom Tromey + + Fix DAP launch and configurationDone requests + Co-workers at AdaCore pointed out that gdb incorrectly implements the + DAP launch and configurationDone requests. It's somewhat strange to + me, but the spec does in fact say that configuration requests should + occur before the executable is known to gdb. This was clarified in + this bug report against the spec: + + https://github.com/microsoft/debug-adapter-protocol/issues/452 + + Fixing 'launch' to start the inferior was straightforward, but this + then required some changes to how breakpoints are handled. In + particular, now gdb will emit the "pending" reason on a breakpoint, + and will suppress breakpoint events during breakpoint setting. + +2024-02-12 Tom Tromey + + Clean up suppress_new_breakpoint_event + Kévin pointed out that suppress_new_breakpoint_event would do the + wrong thing if it happened to be used reentrantly. While I don't + think this can happen, it's also easy and clearly better to make it + robust. + + Export dap_initialize + This changes the test suite to export dap_initialize. + +2024-02-12 Simon Marchi + + gdb: re-format Python files with black 24.1.1 + New year, new black version. + + Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d + +2024-02-12 Frederic Cambus + + Add support to readelf for the PT_OPENBSD_SYSCALLS segment type. + binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type. + include * elf/common.h (PT_OPENBSD_SYSCALLS): Define. + +2024-02-12 Carl Love + + rs6000, unwind-on-each-instruction fix. + The function rs6000_epilogue_frame_cache assumes the LR and gprs have been + restored. In fact register r31 and the link register, lr, may not have + been restored yet. This patch adds support to store the lr and gpr + register unrolling rules in the cache. The LR and GPR values can now be + unrolled correctly. + + Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp. + +2024-02-12 Alexandra Hájková + + remote.c: Make packet_check_result return a structure + packet_check_result currently returns an packet_result enum. + If GDB will recieve an error in a format E.errtext, which + is possible for some q packets, such errtext is lost if + treated by packet_check_result. + Introduce a new structure which bundles enum packet_result + with possible error message or error code returned by + the GDBserver. + I plan to make more GDBserver response checking functions to use + packet_check_result to make remote.c code more consistent. + This will also allow to use E.errtext more in the future. + + Beside adding the unit test, I tested this by modifying + store_registers_using_G function to get an error message: + + [remote] Sending packet: $GG00000000 ... + + gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793) + gdbserver: Invalid hex digit 71 + Killing process(es): 1104002 + [remote] Packet received: E01 + Could not write registers; remote failure reply '01' + + Reviewed-by: Thiago Jung Bauermann + +2024-02-12 GDB Administrator + + Automatic date update in version.in + +2024-02-11 Hannes Domani + + Fix crash when calling Frame.static_link + If you try to call Frame.static_link for a frame without debug info, + gdb crashes: + ``` + Temporary breakpoint 1, 0x000000013f821650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + The problem was a missing check if get_frame_block returns nullptr + inside frame_follow_static_link. + + With this, it works: + ``` + Temporary breakpoint 1, 0x000000013f941650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + None + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366 + Approved-By: Tom Tromey + +2024-02-11 GDB Administrator + + Automatic date update in version.in + +2024-02-10 Andrew Burgess + + gdb/python: fix 'set python ignore-environment' white space + I noticed that the help text for set/show python ignore-environment + was messed up, some lines had unwanted leading white space, like this: + + (gdb) help set python ignore-environment + Set whether the Python interpreter should ignore environment variables. + When enabled GDB's Python interpreter will ignore any Python related + flags in the environment. This is equivalent to passing `-E' to a + python executable. + (gdb) + + This has been present since the ignore-environment setting was added + in commit: + + commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9 + Date: Thu Aug 27 16:53:13 2020 +0100 + + gdb: startup commands to control Python extension language + + Fixed in this commit. + +2024-02-10 GDB Administrator + + Automatic date update in version.in + +2024-02-09 Hannes Domani + + Allow value repeat operator on references + Currently it's not possible to use the value repeat operator on references: + ``` + print ((int &) v_int_array_init[0])@2 + Only values in memory can be extended with '@'. + ``` + + This seems like an unnecessary restriction, since it also prevents + its use on iterators (which was the original reported problem): + ``` + (gdb) p *it@2 + Only values in memory can be extended with '@'. + ``` + + So this converts any references to the referenced value in value_repeat, + making this possible: + ``` + print ((int &) v_int_array_init[0])@2 + $1 = {10, 20} + (gdb) p *it@2 + $2 = {1, 2} + ``` + + Approved-by: Kevin Buettner + +2024-02-09 Peter Bergner + + PowerPC: Add support for Power11 options + binutils/ + * doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11. + + gas/ + * config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11. + * doc/c-ppc.texi: Likewise. + + opcodes/ + * ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries. + (powerpc_init_dialect): Default to "power11". + +2024-02-09 Simon Marchi + + gdb: remove unnecessary nullptr check in remove_user_added_objfile + Since commit 74daa597e74 ("gdb: add all_objfiles_removed observer"), the + objfile passed to the free_objfile observable can't be nullptr. + + Change-Id: If215aa051ab43c068b11746938022c7efca09caa + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to clear_solib + Make the current_program_space reference bubble up one level. + + Remove one unnecessary declaration of clear_solib. + + Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to disable_breakpoints_in_shlibs + Make the current_program_space reference bubble up one level. + + Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add inferior parameter to breakpoint_init_inferior + By inspection, I believe that breakpoint_init_inferior doesn't call + anything that relies on the current program space or inferior. So, + add an inferior parameter, to make the current inferior / program space + references bubble up one level. + + Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7 + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to mark_breakpoints_out + Make the current_program_space reference bubble up one level. + + Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29 + Approved-By: Andrew Burgess + +2024-02-09 Pedro Alves + + Fix crash in aarch64-linux gdbserver + Since commit 393a6b5947d0 ("Thread options & clone events (Linux + GDBserver)"), aarch64-linux gdbserver crashes when the inferior + vforks. This happens in aarch64_get_debug_reg_state: + + struct process_info *proc = find_process_pid (pid); + + return &proc->priv->arch_private->debug_reg_state; + + Here, find_process_pid returns nullptr -- the new inferior hasn't yet + been created in linux_process_target::handle_extended_wait. + + This patch fixes the problem by having + linux_process_target::handle_extended_wait create the child process + earlier, before the child LWP is created. This is what the function + did before it was reorganized by the commit referred above. + + Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50 + Co-Authored-By: Tom Tromey + +2024-02-09 Jan Beulich + + x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3 + Don't wander into three_byte_table[] when REX2 is present. + + While there also eliminate related confusion when accessing + dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping + the odd variable gets things better in sync with 1-byte handling as + well. + +2024-02-09 Jan Beulich + + x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed + Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't + even present in the x86-64-apx-egpr-inval testcase, hence why I + overlooked that these can actually be encoded, (again) using suitable + AVX512 counterparts. + + While there also "modernize" the adjacent AVX/AVX2 entries. + +2024-02-09 Jan Beulich + + x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} + In eea4357967b6 ("x86/APX: VROUND{P,S}{S,D} can generally be encoded") I + failed to add the AVX512* ISA dependency of the two new entries. + + x86: change type of Dwarf2 register numbers in register table + Already the %bnd registers used numbers beyond 127, and eGPR ones are + all out of reach for "signed char", at least when CHAR_BITS=8. Switch to + "unsigned char", covering appropriately in places where the value + returned for "none" actually matters (in tc_x86_parse_to_dw2regnum() + this is actually achieved by altering how X_op is set). + +2024-02-09 Indu Bhagat + + gas: scfi: fix failing test on Solaris2 + It has been observed that the run of scfi-unsupported-1 test with --x32 + arg on a Solaris2 x86_64 system fails: + + Executing on host: sh -c {../as-new --x32 --scfi=experimental \ + <...>/scfi-unsupported-1.s 2>&1} /dev/null dump.out (timeout = 300) + Assembler messages: + Fatal error: no compiled in support for 32bit x86_64 + regexp_diff match failure + regexp "^Fatal error: SCFI is not supported for this ABI$" + line "Fatal error: no compiled in support for 32bit x86_64" + FAIL: x86_64 scfi-unsupported-1 + + Fix the above by adding a check for --x32 support before running the + test. While at it, also include a similar check for --32 support. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and + gas_32_check. Conditionalize the execution of affected + testcases. + +2024-02-09 Alan Modra + + PR 14962 testcase xcoff failure + Like https://sourceware.org/pipermail/binutils/2002-August/021279.html + but for symbols defined in an xcoff object but then made absolute by a + linker script. + + * xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly + for symbols made absolute by a linker script. + +2024-02-09 GDB Administrator + + Automatic date update in version.in + +2024-02-08 Thiago Jung Bauermann + + gdb/testsuite: Fix testing of "info copying" + gdb.base/default.exp has an incomplete test for the "info copying" command, + as poetically pointed out by the FIXME removed by this patch. + + The test omits the pattern argument to gdb_test, which causes it to just + check for a GDB prompt at the end of the command output. + + The problem is that the command output is the whole GPLv3 license, which + due to its size causes the test to fail sometimes, making the testcase to + be out of sync with GDB's output and failing the tests that follow + it. E.g., + + FAIL: gdb.base/default.exp: info copying (timeout) + FAIL: gdb.base/default.exp: info display + FAIL: gdb.base/default.exp: info frame "f" abbreviation + PASS: gdb.base/default.exp: info frame + FAIL: gdb.base/default.exp: info files + FAIL: gdb.base/default.exp: info float + FAIL: gdb.base/default.exp: info functions + FAIL: gdb.base/default.exp: info locals + FAIL: gdb.base/default.exp: info program + FAIL: gdb.base/default.exp: info registers + FAIL: gdb.base/default.exp: info stack "s" abbreviation + + Fix by by checking for a few excerpts at the beginning, middle and end of + the license text. This makes the test consume the command's output in + smallish chunks. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-02-08 Alan Modra + + PR31208, strip can break ELF alignment requirements + In https://sourceware.org/pipermail/binutils/2007-August/053261.html + (git commit 3dea8fca8b86) I disabled a then new linker feature that + removed empty PT_LOAD headers in cases where a user specified program + headers, and for objcopy. This can be a problem for objcopy/strip and + since objcopy operates on sections, any part of a PT_LOAD loading file + contents not covered by a section will be omitted anyway. + + PR 31208 + * elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load + as true to elf_modify_segment_map for objcopy/strip. + +2024-02-08 Tom Tromey + + Update TUI register window when the inferior exits + When the inferior exits, the TUI register window should clear. + + Fixing this was mostly a matter of sticking an assignment into + tui_inferior_exit. However, some changes to the register window + itself were also needed. + + While working on this, I realized that the TUI register window would + not work correctly when moving between frames of different + architectures. This patch attempts to fix this as well, though I have + no way to test it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600 + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename show_registers -> set_register_group + This renames a method on the TUI register window to reflect its real + purpose. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Return void from tui_show_frame_info + Nothing uses the tui_show_frame_info result any more, so change it to + return void. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove redundant check from tui_refresh_frame_and_register_information + tui_refresh_frame_and_register_information checks 'from_stack' in a + block that's already guarded by a 'from_stack' check. This patch + removes the redundant check. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove tui_refreshing_registers + The comment by tui_refreshing_registers mentions a hook that no longer + exists. However, maybe the comment is wrong. + + The code paths touching tui_refreshing_registers can only be called in two places: + + 1. From the before_prompt observer. This is only called when a prompt + is about to be displayed. + + 2. From the register_changed observer. This is only called when + value_assign changes a register value. + + From this it seems clear that the recursion case here cannot in fact + occur. This patch removes the variable. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_win::erase_data_content + There's only a single call to tui_data_win::erase_data_content now, so + remove the parameter and make it just render the "empty window" text. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove the TUI register window rerender overload + After these restructurings, it should be clear that the rerender + overload can be removed from the TUI register window. This is done by + moving a bit more logic from show_registers into update_register_data. + After this, update_register_data simply updates the internal state, + and rerender will write to the screen. All the actual rendering work + is done, ultimately, by display_registers_from. This split between + updating the model and rendering makes it clear that the recursive + case can't happen any longer. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify update_register_data + This changes update_register_data to always update the register data. + The idea here is that this is really only called when either the + desired register group changes, or when gdb transitions from not + having a frame to having a frame. + + show_registers is also simplified slightly to account for this. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Move scrollok call in register window + The register window calls scrollok each time a register is written to + the window. However, we only need to call this once, at the start of + display. (We could actually call it just once when the window is + made, but that would involve making another method virtual or adding a + new member -- both which I think are worse than this approach.) + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Change tui_register_info::visible to a method + tui_register_info::visible is redundant with the fact that y==0 means + that the register is not visible. This patch changes this member in + favor of having a single indication of the register's visibility -- a + method with the same name. This change makes it clear that + delete_data_content_windows is not needed, so this is removed as well. + + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename tui_data_item_window -> tui_register_info + tui_data_item_window used to hold a curses window, but we removed that + ages ago. Now it just holds information about a single register. + This patch renames the class to make it more clearly reflect its + meaning. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_window::show_register_group + This simplifies tui_data_window::show_register_group, renaming it as + well. The old method had two loops to iterate over all the registers + for the arch, but in the new scheme, the vector is set up when + switching groups, and then updates simply iterate over the vector. + + tui_data_item_window is made self-updating, which also clarifies the + code somewhat. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Minor C++ cleanups in tui-regs.c + This changes a couple of spots to use nullptr rather than 0, and + changes an int to a bool. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Use pop_back in tui_register_format + tui_register_format can use string::pop_back now. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Hannes Domani + + Allow calling of C++ methods from python + Currently it's not possible to call C++ methods from python. + Using this example: + ``` + class B + { + static int static_func (); + int arg0_func (); + int arg1_func (int arg1); + int arg2_func (int arg1, int arg2); + }; + + B *b_obj = new B; + ``` + + Trying to call B::static_func gives this error: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC). + Error while executing Python code. + ``` + + TYPE_CODE_METHOD was simply missing as a possible type in + valpy_call, now the same is possible: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + 1111 + ``` + + Note that it's necessary to explicitely add the this pointer + as the first argument in a call of non-static methods: + ``` + (gdb) py print(b_obj['arg0_func']()) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Too few arguments in function call. + Error while executing Python code. + (gdb) py print(b_obj['arg0_func'](b_obj)) + 198 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-02-08 Jens Remus + + gdb: Fix building with clang + This resolves the following clang++ error message: + + ../../gdb/symtab.c:4892:33: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses] + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ../../gdb/symtab.c:4892:33: note: add parentheses after the '!' to evaluate the comparison first + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + ../../gdb/symtab.c:4892:33: note: add parentheses around left hand side expression to silence this warning + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + + Bug: https://sourceware.org/PR31328 + +2024-02-08 H.J. Lu + + x86-64: Add R_X86_64_CODE_6_GOTTPOFF + For + + add %reg1, name@gottpoff(%rip), %reg2 + + and + + add name@gottpoff(%rip), %reg1, %reg2 + + add + + #define R_X86_64_CODE_6_GOTTPOFF 50 + + if the instruction starts at 6 bytes before the relocation offset. + They are similar to R_X86_64_GOTTPOFF. Linker can covert GOTTPOFF to + + add $name@tpoff, %reg1, %reg2 + + Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate + R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX, + R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and + R_X86_64_CODE_6_GOTTPOFF. + + NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in + md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this + stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF + or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix. + + 5 relocations: + + #define R_X86_64_CODE_5_GOTPCRELX 46 + #define R_X86_64_CODE_5_GOTTPOFF 47 + #define R_X86_64_CODE_5_GOTPC32_TLSDESC 48 + #define R_X86_64_CODE_6_GOTPCRELX 49 + #define R_X86_64_CODE_6_GOTPC32_TLSDESC 51 + + are added for completeness and they are unused. + + bfd/ + + * elf64-x86-64.c (x86_64_elf_howto_table): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (R_X86_64_standard): Updated. + (x86_64_reloc_map): Add R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and + R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_check_tls_transition): Handle + R_X86_64_CODE_6_GOTTPOFF. + (elf_x86_64_tls_transition): Likewise. + (elf_x86_64_scan_relocs): Handle R_X86_64_CODE_6_GOTTPOFF. + Issue an error for R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_relocate_section): Handle R_X86_64_CODE_6_GOTTPOFF. + * reloc.c (bfd_reloc_code_real): Add + BFD_RELOC_X86_64_CODE_5_GOTPCRELX, + BFD_RELOC_X86_64_CODE_5_GOTTPOFF, + BFD_RELOC_X86_64_CODE_5_GOTPC32_TLSDESC, + BFD_RELOC_X86_64_CODE_6_GOTPCRELX, + BFD_RELOC_X86_64_CODE_6_GOTTPOFF and + BFD_RELOC_X86_64_CODE_6_GOTPC32_TLSDESC. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + + elfcpp/ + + * x86_64.h (R_X86_64_CODE_5_GOTPCRELX): New. + (R_X86_64_CODE_5_GOTTPOFF): Likewise. + (R_X86_64_CODE_5_GOTPC32_TLSDESC): Likewise. + (R_X86_64_CODE_6_GOTPCRELX): Likewise. + (R_X86_64_CODE_6_GOTTPOFF): Likewise. + (R_X86_64_CODE_6_GOTPC32_TLSDESC): Likewise. + + gas/ + + * config/tc-i386.c (tc_i386_fix_adjustable): Handle + BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (md_assemble): Don't check BFD_RELOC_X86_64_CODE_4_GOTTPOFF. + Allow "add %reg1, foo@gottpoff(%rip), %reg2". + (output_disp): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. Rewrite + setting fx_tcbitX bits for BFD_RELOC_X86_64_GOTTPOFF, + BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL. + (md_apply_fix): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (i386_validate_fix): Rewrite fx_tcbitX bit checking for + BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and + BFD_RELOC_32_PCREL. + (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle + R_X86_64_CODE_6_GOTTPOFF. + (Target_x86_64::Scan::get_reference_flags): Likewise. + (Target_x86_64::Scan::local): Likewise. + (Target_x86_64::Scan::global): Likewise. + (Target_x86_64::Relocate::relocate): Likewise. + (Target_x86_64::Relocate::relocate_tls): Likewise. + (Target_x86_64::Relocate::tls_ie_to_le): Handle. + R_X86_64_CODE_6_GOTTPOFF. + * testsuite/x86_64_ie_to_le.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + include/ + + * elf/x86-64.h (elf_x86_64_reloc_type): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-02-08 Richard W.M. Jones + + PR 31283 windmc: Parse input correctly on big endian hosts + On big endian hosts (eg. s390x) the windmc tool fails to parse even + trivial files: + + $ cat test.mc + ; + $ ./binutils/windmc ./test.mc + In test.mc at line 1: parser: syntax error. + In test.mc at line 1: fatal: syntax error. + + The tool starts by reading the input as Windows CP1252 and then + converting it internally into an array of UTF-16LE, which it then + processes as an array of unsigned short (typedef unichar). + + There are lots of ways this is wrong, but in the specific case of big + endian machines the little endian pairs of bytes are byte-swapped. + + For example, the ';' character in the input above is first converted + to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to + unsigned short. On a big endian machine the first unichar appears to + be 0x3b00. The lexer is unable to recognize this as the comment + character ((unichar)';') and so parsing fails. + + The simple fix is to convert the input to UTF-16BE on big endian + machines (and do the reverse conversion when writing the output). + + Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283 + +2024-02-08 GDB Administrator + + Automatic date update in version.in + +2024-02-07 Hannes Domani + + Raise exception if ambiguous name is used in gdb.parameter + Currently gdb.parameter doesn't raise an exception if an + ambiguous name is used, it instead returns the value of the + last partly matching parameter: + ``` + (gdb) show print sym + Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading. + (gdb) show print symbol-loading + Printing of symbol loading messages is "full". + (gdb) py print(gdb.parameter("print sym")) + full + ``` + + It's because lookup_cmd_composition_1 tries to detect + ambigous names by checking the return value of find_cmd + for CMD_LIST_AMBIGUOUS, which never happens, since only + lookup_cmd_1 returns CMD_LIST_AMBIGUOUS. + Instead the nfound argument contains the number of found + matches. + + By using it instead, and by setting *CMD to the special value + CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show + the appropriate error message: + ``` + (gdb) py print(gdb.parameter("print sym")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print sym' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol")) + True + (gdb) py print(gdb.parameter("print symbol-")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print symbol-' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol-load")) + full + ``` + + Since the document command also uses lookup_cmd_composition, it needed + to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an + "Ambiguous command" error message in this case. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639 + Approved-By: Tom Tromey + +2024-02-07 Hannes Domani + + Fix raw-frame-arguments in combination with frame-filters + Currently, if frame-filters are active, raw-values is used instead of + raw-frame-arguments to decide if a pretty-printer should be invoked for + frame arguments in a backtrace. + + In this example, "super struct" is the output of the pretty-printer: + + (gdb) disable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + If no frame-filter is active, then the raw-values print option does not + affect the backtrace output: + + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + + Instead, the raw-frame-arguments option disables the pretty-printer in the + backtrace: + + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + But if a frame-filter is active, the same rules don't apply. + The option raw-frame-arguments is ignored, but raw-values decides if the + pretty-printer is used: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which + is then used in the frame-filter to override the raw flag in enumerate_args. + + Then the output is the same if a frame-filter is active, the pretty-printer + for backtraces is only disabled with the raw-frame-arguments option: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + Co-Authored-By: Andrew Burgess + Approved-By: Tom Tromey + +2024-02-07 Ciaran Woodward + + Remove use of scoped_restore_tmpl from scoped_restore_warning_hook + The warning_hook_handler function pointer takes va_list as + an argument, which on some platforms (mingw64) includes some + attributes. Attributes get ignored in template arguments. + This led to the compiler warning: + + error: ignoring attributes on template argument 'warning_hook_handler' {aka 'void (*)(const char*, char*)'} [-Werror=ignored-attributes] + 387 | scoped_restore_tmpl m_save; + | ^ + + By manually implementing the save/restore behaviour, rather + than using the helper template, this warning is fixed. + + Approved-By: Tom Tromey + +2024-02-07 Alan Modra + + asan: NULL dereference in _bfd_mips_final_write_processing + Fuzzed object files can easily have unexpected section names. We + don't want to segfault on objcopy of any file accepted by the mips + object_p functions. For objcopy, an assertion that "sec" is non-NULL + followed by deferencing "sec" is wrong. So too is asserting that the + section name string starts with a particular prefix, and then blithely + accessing past the assumed prefix. + + * elfxx-mips.c (_bfd_mips_final_write_processing): Replace + assertions with conditionals. Don't bother testing for name + non-NULL. + +2024-02-07 Alan Modra + + memory leak in objdump disassemble_section + * objdump.c (disassemble_section): Free rel_ppstart on error path. + +2024-02-07 Indu Bhagat + + gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly + PR gas/31326 + SCFI must handle non QWORD ALU with imm and MOV ops correctly + + As per the x86 ISA manual: + - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit + result in the destination general-purpose register. + - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The + upper 56 bits or 48 bits (respectively) of the destination + general-purpose register are not modified by the operation. + + Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have + implications on SCFI. SCFI/ginsn machinery does not track operation size + in the ginsn representation. But given that these sub-QWORD ops update + only a portion of a 64-bit destination register, for SCFI purposes, this + needs to be deemed as an untraceable update (when the destination is + REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected + for stack management, but the SCFI machinery must behave correctly, when + such ops are indeed present. + + As mentioned earlier, ginsn representation does not carry operation size + information. To resolve the issue raised in PR gas/31326, an option is + to force the generation of GINSN_TYPE_OTHER for all cases when there is + a 8/16/32 bit op. But this may dilute the utility of ginsn for other + use-cases, when they pop up in future. + + The current approach is less disruptive than above in that it generates + GINSN_TYPE_OTHER for all cases only when: + - there is a 8/16/32 bit op, and + - the 64-bit op is otherwise traceable. + + In other words this means: + - For add/sub ops where dest is reg and src is reg/mem: these always + make dest reg untraceable; So, the current handling is unchanged. We + simply skip detecting 8/16/32-bit ops. + - An x86 pop instruction is translated to a load ginsn followed by a stack + increment add op. A load op always makes dest reg untraceable. + Hence, if the pop instruction is sub-QWORD, we continue to (skip + detecting 8/16/32-bit op, and) generate the load instruction as usual. + This means that if input asm does have save and restore of unequal sized + registers, gas/SCFI will not detect nor warn. + - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated + when a 8/16/32-bit op is seen. + + gas/ + PR gas/31326 + * config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code + comment. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early. + (x86_ginsn_move): Likewise. + (x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in + opcode_space SPACE_BASE) about skipped handling. + + gas/testsuite/: + PR gas/31326 + * gas/scfi/x86_64/ginsn-add-1.l: Update. + * gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of + add to invoke and test the ginsn_dw2_regnum code path. + +2024-02-07 GDB Administrator + + Automatic date update in version.in + +2024-02-06 Simon Marchi + + gdb: remove core_bfd macro + The core_bfd macro hides a use of current_program_space. Remove it, so + that we have the opportunity to get the program space from the context, + if possible. I guess that the macro was introduced at some point to + replace a global variable of the same name without changing all the + uses. + + Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 + Approved-By: Tom Tromey + +2024-02-06 H.J. Lu + + x86: Warn .insn instruction with length > 15 bytes + Change .insn instruction with length > 15 bytes from error to warning. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue a warning when .insn + instruction length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized64.s: Add a test for .insn + * testsuite/gas/i386/oversized64.l: Updated. + +2024-02-06 Tiezhu Yang + + gdb: LoongArch: Implement the get_syscall_number gdbarch method + In the current code, the feature 'catch syscall' is not supported + on LoongArch, implement the "get_syscall_number" gdbarch method to + get the system call number from the register a7. + + Without this patch: + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architecture yet. + +2024-02-06 Feiyang Chen + + gdb: LoongArch: Add LBT extension support + Loongson Binary Translation (LBT) is used to accelerate binary + translation, which contains 4 scratch registers (scr0 to scr3), + x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This + patch support gdb to fetch/store these registers. + + Signed-off-by: Feiyang Chen # Framework + Signed-off-by: Binbin Zhou # Detail Optimizes + Signed-off-by: Hui Li # Error Fixes + +2024-02-06 Hui Li + + gdb: LoongArch: Add vector extensions support + Add LoongArch's vector extensions support, which including + 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX + (i.e., Loongson Advanced SIMD eXtension). This patch support + gdb to fetch/store vector registers. + +2024-02-06 Alan Modra + + Link x86-64 mark-plt-1.so with --no-as-needed + Fixes + FAIL: Build mark-plt-1.so + where gcc is built with default --as-needed. + + * testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass + --no-as-needed. + +2024-02-06 GDB Administrator + + Automatic date update in version.in + +2024-02-05 Simon Marchi + + gdb: rename target_so_ops to solib_ops + I don't like the name `target_so_ops`, because: + + - The name `target` is so overloaded, and in this case it's not even + related to target_ops or anything else called "target". + - We do have an implementation that actually fetches solibs from the + target (solib_target_so_op in solib-target.c), so it's confusing for + the "base class" to be called target_something as well. + + Rename to solib_ops. + + Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f + Approved-By: Tom Tromey + +2024-02-05 Simon Marchi + + gdb: rename struct shobj -> struct solib + `struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f + ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would + have been a better name. We have solib.c, the implementations in + solib-*.c, many functions with solib in their name, the solib_loaded / + solib_unloaded observables, etc. + + Rename shobj to solib. + + Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d + Approved-By: Tom Tromey + +2024-02-05 Tom Tromey + + Remove remnants of partial DIEs from DWARF reader + When rewriting the DWARF scanner, I forgot to remove + dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies. This patch + corrects the oversight and fixes up a couple other spots that mention + partial DIEs, which no longer exist. + + Approved-By: Tom de Vries + +2024-02-05 Tom Tromey + + Avoid an allocation in attr_to_dynamic_prop + I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no + allocation is required. This patch stack-allocates the object + instead. + + Reviewed-By: Tom de Vries + +2024-02-05 Thiago Jung Bauermann + + Fix disabling of year 2038 support on 32-bit hosts by default + Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by + default") fixed a mismatch between 64-bit time_t in GDB and system headers + and 32-bit time_t in BFD. + + However, since commit 862776f26a59 ("Finalized intl-update patches") + gnulib's year 2038 support has been accidentally re-enabled — causing + problems for 32-bit hosts again. The commit split baseargs into + {h,b}baseargs, but this hasn't been done for the code that handles + --disable-year2038. + + This patch restores the intended behaviour. With this change, the number + of unexpected core files goes from 18 to 4. + + Tested on armv8l-linux-gnueabihf. + + Approved-By: Luis Machado + +2024-02-05 Tom Tromey + + Handling of arrays with optimized-out bounds + In Ada, sometimes the compiler must emit array bounds by referencing + an artificial variable that's created for this purpose. However, with + optimization enabled, these variables can be optimized away. + + Currently this can result in displays like: + + (gdb) print mumble + $1 = (warning: unable to get bounds of array, assuming null array + ) + + This patch changes this to report that the array is optimized-out, + instead, which is closer to the truth, and more generally useful. For + example, Python pretty-printers can now recognize this situation. + + In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT + enumerator and changed one place to use it. Reusing the "unknown" + state wouldn't work properly, because in C it is normal for array + bounds to be unknown. + +2024-02-05 Tom de Vries + + [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache + On arm-linux the linaro CI occasionally reports: + ... + (gdb) up 10 + #4 0x0001b864 in pthread_join () + (gdb) FAIL: gdb.threads/staticthreads.exp: up 10 + ... + while this is expected: + ... + (gdb) up 10 + #3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76 + 76 pthread_join (thread, NULL); + (gdb) PASS: gdb.threads/staticthreads.exp: up 10 + ... + + Thiago investigated the problem, and using valgrind found an invalid read in + arm_exidx_fill_cache. + + The problem happens as follows: + - an objfile and corresponding per_bfd are allocated + - some memory is allocated in arm_exidx_new_objfile using + objfile->objfile_obstack, for the "exception table entry cache". + - a symbol reread is triggered, and the objfile, including the + objfile_obstack, is destroyed + - a new objfile is allocated, using the same per_bfd + - again arm_exidx_new_objfile is called, but since the same per_bfd is used, + it doesn't allocate any new memory for the "exception table entry cache". + - the "exception table entry cache" is accessed by arm_exidx_fill_cache, + and we have a use-after-free. + + This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling + information per-bfd instead of per-objfile"), which changed the "exception + table entry cache" from per-objfile to per-bfd, but failed to update the + obstack_alloc. + + Fix this by using objfile->per_bfd->storage_obstack instead of + objfile->objfile_obstack. + + I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch + fixes it. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR tdep/31254 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254 + +2024-02-05 GDB Administrator + + Automatic date update in version.in + +2024-02-04 Tom Tromey + + Use reference result of emplace_back + Starting with C++17, emplace_back returns a reference to the new + object. This patch changes code that uses emplace_back followed by a + call to back() to simply use this reference instead. + + Approved-By: Simon Marchi + +2024-02-04 Xi Ruoyao + + LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab + When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a + TLS symbol and we should set its type to TLS in the symtab. Otherwise + when building Perl with gcc-14 -flto, we get: + + /usr/bin/ld: PL_current_context: TLS definition in + ./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference + in ./miniperl.ltrans1.ltrans.o + + A minimal reproducer: + + $ cat t1.s + .section .tbss + .globl x + x: .word 0 + $ cat t2.s + f: + lu12i.w $a0, %le_hi20_r(x) + add.d $a0, $a0, $tp, %le_add_r(x) + li.w $a1, 1 + st.w $a1, $a0, %le_lo12_r(x) + $ gas/as-new t1.s -o t1.o + $ gas/as-new t2.s -o t2.o + $ ld/ld-new t1.o t2.o + ld/ld-new: x: TLS definition in t1.o section .tbss mismatches + non-TLS reference in t2.o + + Unfortunately this was undetected before Binutils-2.42 release because + GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a + TLS LE definition and its reference in two different translation units. + So this fix should be backported to Binutils-2.42 branch too. + +2024-02-04 GDB Administrator + + Automatic date update in version.in + +2024-02-03 GDB Administrator + + Automatic date update in version.in + +2024-02-02 Andrew Burgess + + gdb: attach to a process when the executable has been deleted + Bug PR gdb/28313 describes attaching to a process when the executable + has been deleted. The bug is for S390 and describes how a user sees a + message 'PC not saved'. + + On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but + instead I see this: + + (gdb) attach 901877 + Attaching to process 901877 + No executable file now. + warning: Could not load vsyscall page because no executable was specified + 0x00007fa9d9c121e7 in ?? () + (gdb) bt + #0 0x00007fa9d9c121e7 in ?? () + #1 0x00007fa9d9c1211e in ?? () + #2 0x0000000000000007 in ?? () + #3 0x000000002dc8b18d in ?? () + #4 0x0000000000000000 in ?? () + (gdb) + + Notice that the addresses in the backtrace don't seem right, quickly + heading to 0x7 and finally ending at 0x0. + + What's going on, in both the s390 case and the x86-64 case is that the + architecture's prologue scanner is going wrong and causing the stack + unwinding to fail. + + The prologue scanner goes wrong because GDB has no unwind information. + + And GDB has no unwind information because, of course, the executable + has been deleted. + + Notice in the example session above we get this line in the output: + + No executable file now. + + which indicates that GDB failed to find an executable to debug. + + For GNU/Linux when GDB tries to find an executable for a given pid we + end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c. + Within this function we call `readlink` on /proc/PID/exe to find the + path of the actual executable. + + If the `readlink` call fails then we already fallback on using + /proc/PID/exe as the path to the executable to debug. + + However, when the executable has been deleted the `readlink` call + doesn't fail, but the path that is returned points to a non-existent + file. + + I propose that we add an `access` call to linux_proc_pid_to_exec_file + to check that the target file exists and can be read. If the target + can't be read then we should fall back to /proc/PID/exe (assuming that + /proc/PID/exe can be read). + + Now on x86-64 the output looks like this: + + (gdb) attach 901877 + Attaching to process 901877 + Reading symbols from /proc/901877/exe... + Reading symbols from /lib64/libc.so.6... + (No debugging symbols found in /lib64/libc.so.6) + Reading symbols from /lib64/ld-linux-x86-64.so.2... + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) + 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + (gdb) bt + #0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + #1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6 + #2 0x000000000040117e in spin_forever () at attach-test.c:17 + #3 0x0000000000401198 in main () at attach-test.c:24 + (gdb) + + which is much better. + + I've also tagged the bug PR gdb/29782 which concerns the test + gdb.server/connect-with-no-symbol-file.exp. After making this change, + when running gdb.server/connect-with-no-symbol-file.exp GDB would now + pick up the /proc/PID/exe file as the executable in some cases. + + As GDB is not restarted for the multiple iterations of this test + GDB (or rather BFD) would given a warning/error like: + + (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect + set sysroot target: + BFD: reopening /proc/3283001/exe: No such file or directory + (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot + + What's happening is that an executable found for an earlier iteration + of the test is still registered for the inferior when we are setting + up for a second iteration of the test. When the sysroot changes, if + there's an executable registered GDB tries to reopen it, but in this + case the file has disappeared (the previous inferior has exited by + this point). + + I did think about maybe, when the executable is /proc/PID/exe, we + should auto-delete the file from the inferior. But in the end I + thought this was a bad idea. Not only would this require a lot of + special code in GDB just to support this edge case: we'd need to track + if the exe file name came from /proc and should be auto-deleted, or + we'd need target specific code to check if a path should be + auto-deleted..... + + ... in addition, we'd still want to warn the user when we auto-deleted + the file from the inferior, otherwise they might be surprised to find + their inferior suddenly has no executable attached, so we wouldn't + actually reduce the number of warnings the user sees. + + So in the end I figured that the best solution is to just update the + test to avoid the warning. This is easily done by manually removing + the executable from the inferior once each iteration of the test has + completed. + + Now, in bug PR gdb/29782 GDB is clearly managing to pick up an + executable from the NFS cache somehow. I guess what's happening is + that when the original file is deleted /proc/PID/exe is actually + pointing to a file in the NFS cache which is only deleted at some + later point, and so when GDB starts up we do manage to associate a + file with the inferior, this results in the same message being emitted + from BFD as I was seeing. The fix included in this commit should also + fix that bug. + + One final note: On x86-64 GNU/Linux, the + gdb.server/connect-with-no-symbol-file.exp test will produce 2 core + files. This is due to a bug in gdbserver that is nothing to do with + this test. These core files are created before and after this + commit. I am working on a fix for the gdbserver issue, but will post + that separately. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782 + + Approved-By: Tom Tromey + +2024-02-02 H.J. Lu + + x86: Disallow instructions with length > 15 bytes + It is a hard error when an instruction length exceeds the limit of 15 + bytes: + + [hjl@gnu-cfl-3 tmp]$ cat x.s + .text + xacquire lock addq $0x11223344, %fs:(,%eax) + [hjl@gnu-cfl-3 tmp]$ gcc -c x.s + x.s: Assembler messages: + x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw x.o + + x.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 xacquire lock (bad) + f: 11 .byte 0x11 + [hjl@gnu-cfl-3 tmp]$ + + and + + [hjl@gnu-cfl-3 tmp]$ cat z.s + addq $0xe0, %fs:0, %rdx + [hjl@gnu-cfl-3 tmp]$ as -o z.o z.s + z.s: Assembler messages: + z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw z.o + + z.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 (bad) + ... + [hjl@gnu-cfl-3 pr31323]$ + + Instructions with length > 15 bytes are always invalid. It is quite easy + to generate invalid instructions with AVX now. We should issue an error + when instruction length exceeds the limit of 15 bytes. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue an error when instruction + length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized16.l: Updated. + * testsuite/gas/i386/oversized64.l: Likewise. + * testsuite/gas/i386/x86-64-apx-inval.l: New file. + * testsuite/gas/i386/x86-64-apx-inval.s: Likewise. + +2024-02-02 Nils-Christian Kempke + + gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers + For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like + + <2><17d>: Abbrev Number: 22 (DW_TAG_variable) + <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr + <184> DW_AT_type : <0x214> + ... + <1><219>: Abbrev Number: 27 (DW_TAG_array_type) + <21a> DW_AT_type : <0x10e> + <216> DW_AT_associated : ... + + The 'pointer property' in Fortran is implicitly modeled by adding a + DW_AT_associated to the type of the variable (see also the + DW_AT_associated description in DWARF 5). A Fortran pointer is more + than an address and thus different from a C pointer. It is a + self contained type having additional fields such as, e.g., the rank of + its underlying array. This motivates the intended DWARF modeling of + Fortran pointers via the DW_AT_associated attribute. + + This patch adds support for the sizeof intrinsic by simply dereferencing + pointer types when encountered during a sizeof evaluation. + + The patch also adds a test for the sizeof intrinsic which was not tested + before. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Bernhard Heckel + + gdb, types: Resolve pointer types dynamically + This commit allows pointers to be dynamic types (on the outmost + level). Similar to references, a pointer is considered a dynamic type + if its target type is a dynamic type and it is on the outmost level. + Also this commit removes the redundant code inside function + "value_check_printable" for handling of DW_AT_associated type. + + The pointer resolution follows the one of references. + + This change generally makes the GDB output more verbose. We are able to + print more details about a pointer's target like the dimension of an array. + + In Fortran, if we have a pointer to a dynamic type + + type buffer + real, dimension(:), pointer :: ptr + end type buffer + type(buffer), pointer :: buffer_ptr + allocate (buffer_ptr) + allocate (buffer_ptr%ptr (5)) + + which then gets allocated, we now resolve the dynamic type before + printing the pointer's type: + + Before: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(:) + End Type buffer ) + + After: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(5) + End Type buffer ) + + Similarly in C++ we can dynamically resolve e.g. pointers to arrays: + + int len = 3; + int arr[len]; + int (*ptr)[len]; + int ptr = &arr; + + Once the pointer is assigned one gets: + + Before: + + (gdb) p ptr + $1 = (int (*)[variable length]) 0x123456 + (gdb) ptype ptr + type = int (*)[variable length] + + After: + + (gdb) p ptr + $1 = (int (*)[3]) 0x123456 + (gdb) ptype ptr + type = int (*)[3] + + For more examples see the modified/added test cases. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Ijaz, Abdul B + + gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp + Improve indentation in the test file by replacing 10 spaces at second level + with 4 spaces. This helps to update the test using the right indentation + in future. + + Approved-By: Tom Tromey + +2024-02-02 Jan Beulich + + x86: move Q-suffix-to-REX.W translation logic + By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a + part of another conditional there. While moving, also drop a pointless + check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily + have both been 64-bit ones. + +2024-02-02 Jan Beulich + + x86: actually implement .noopt + For quite some time we've had support for -O command line options. With + that ignoring at least .noopt isn't really a good idea. + + Re-purpose the optimize-3 test for testing this directive's effect as + well. + + As to the doc addition - this uses the same text as is there for the + {nooptimize} pseudo-prefix, despite me not being convinced of the "size" + part being fully accurate there (and hence also here). + +2024-02-02 Sandra Loosemore + + MAINTAINERS: Update my e-mail address. + +2024-02-02 GDB Administrator + + Automatic date update in version.in + +2024-02-01 Indu Bhagat + + gas: x86: ginsn: adjust ginsns for certain lea ops + A review comment on the SCFI V4 series was to handle ginsn creation for + certain lea opcodes more precisely. + + Specifically, we should preferably handle the following two cases of lea + opcodes similarly: + - #1 lea with "index register and scale factor of 1, but no base + register", + - #2 lea with "no index register, but base register present". + + Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the + case of #1 above. For #2, however, the lea insn is translated to either + a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate + for displacement is non-zero or not respectively. + + Change the handling in x86_ginsn_lea so that both of the above lea + manifestations are handled similarly. + + While at it, remove the code paths creating GINSN_TYPE_OTHER altogether + from the function. It makes sense to piggy back on the + x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the + destination register is interesting. This was also suggested in one of + the previous review rounds; the other functions already follow that + model, so this keeps functions symmetrical looking. + + gas/ + * gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with + no base register similar to the case of no index register. Remove + creation of GINSN_TYPE_OTHER from the function. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-lea-1.l: New test. + * gas/scfi/x86_64/ginsn-lea-1.s: Likewise. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-02-01 Vladimir Mezentsev + + gprofng: Remove unused macros + gprofng/ChangeLog + 2024-02-01 Vladimir Mezentsev + + * common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION. + * common/hwctable.c: Remove DBG_LT* macros. + * libcollector/envmgmt.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/iolib.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/memmgr.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/tsd.c: Likewise. + * libcollector/unwind.c: Likewise. + +2024-02-01 Tom Tromey + + Fix "objstack" typo + I noticed some comments that mentions "objstack". The type is + actually "obstack". This patch fixes the typos. + +2024-02-01 Tom Tromey + + Rename SEARCH_ALL + The constant SEARCH_ALL conflicts with a define in a Windows header. + This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the + conflict. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307 + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix some duplicate test names in gdb.trace/ + This commit fixes some of the easier duplicate test names in the + gdb.trace/ directory. + + All of these duplicates are resolved by either given tests a name, or + by extended the existing name to make it more descriptive. + + There should be no change in what is tested after this commit. + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp + Fix some duplicate test names in gdb.base/cond-eval-mode.exp when + running with native-gdbserver or native-extended-gdbserver board + files. + + I've just added some 'with_test_prefix' blocks to make the test names + unique, there should be no change in what is tested after this commit. + +2024-02-01 Aditya Vidyadhar Kamath + + Fix AIX build break. + A recent commit broke AIX build. The thread_local type defined functions + were being considered a weak symbol and hence while creating the binary these + symbols were not visible. + + This patch is a fix for the same. + +2024-02-01 GDB Administrator + + Automatic date update in version.in + +2024-01-31 Simon Marchi + + gdb: remove some unnecessary frame_info_ptr resets + This code was probably needed before we had reinflatable + frame_info_ptrs, it's not necessary anymore. + + Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5 + Approved-By: Tom Tromey + +2024-01-31 Nick Clifton + + Mention support for AMD/znver5 in GAS + +2024-01-31 Georg-Johann Lay + + PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. + Supply these symbols as computed by the linker scripts, even when there are weak definitions. + PR 31124 + * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE. + +2024-01-31 GDB Administrator + + Automatic date update in version.in + +2024-01-30 Tom Tromey + + Really fix Windows gdbserver segment registers + My earlier attempt to mask the segment registers in gdbserver for + Windows introduced some bugs. That patch is here: + + https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html + + The problem turned out to be that these fields in the Windows + 'CONTEXT' type are just 16 bits, so while masking the values on read + is fine, writing the truncated values back then causes zeros to be + written to some subsequent field. + + This patch cleans this up by arranging never to write too much data to + a field. + + I also noticed that two register numbers here were never updated for + the 64-bit port. This patch fixes this as well, and renames the "FCS" + register to follow gdb. + + Finally, this patch applies the same treatment to windows-nat.c. + + Reviewed-by: John Baldwin + +2024-01-30 GDB Administrator + + Automatic date update in version.in + +2024-01-29 Alan Modra + + PR31314, chew crashing on use of uninitialized value + The "drop" call in wrap_comment already increments pc. Defining DOCDD + in proto.str is a warning fix. + + PR 31314 + * chew.c (wrap_comment): Don't increment pc. + * proto.str (DOCDD): Define. + +2024-01-29 Jose E. Marchesi + + sim: bpf: remove support for ldinddw and ldabsdw instructions + This patch removes support for the two instructions above from the GNU + simulator, including the corresponding tests. These instructions do + not really exist in BPF and are not recognized as such by the kernel + verifier. This has now been pointed out during the standardization of + the BPF ISA. + +2024-01-29 Lancelot SIX + + gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.def + Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the + sym-domains.def file has been introduced, and requires the user to + define the DOMAIN(x) macro. + + On older systems (centos-7 with glibc-2.17 for example), this DOMAIN + macro conflicts with another macro defined in /usr/include/math.h. + + Fix this conflict by changing sym-domains.def to use a macro named + SYM_DOMAIN instead of DOMAIN. + + Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3 + Approved-By: Tom Tromey + +2024-01-29 Jose E. Marchesi + + bfd: restore Threading menu entry in bfd.texi + I mistakenly vandalized bfd.texi in the commit + 0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the + manual menu. This commit reverts that thunk. + +2024-01-29 Jose E. Marchesi + + bpf: there is no ldinddw nor ldabsdw instructions + There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW. + For some reason we were (incorrectly) supporting these. This patch + updates the opcodes so the instructions get removed and modifies the + GAS manual and testsuite accordingly. + + See discussion at + https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev + + Tested in bpf-uknonwn-none target, x86-64-linux-gnu host. + + include/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + opcodes/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + gas/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit + load instruction. + (BPF Instructions): There is no absolute 64-bit load instruction. + * testsuite/gas/bpf/mem.s: Update test accordingly. + * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-be.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.s: Likewise. + * testsuite/gas/bpf/mem.d: Likewise. + * testsuite/gas/bpf/mem.s: Likewise. + +2024-01-29 Nick Clifton + + Update release making documentation after 2.42 release + + Remove support for the beos file format + +2024-01-29 Hannes Domani + + Fix backtrace limit stopping on inline frame + If you have set up a backtrace limit, and the backtrace stops + because of this in an inline frame with arguments, you get an + assertion failure: + ``` + (gdb) bt + (gdb) set backtrace limit 2 + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed. + ``` + + And if this one is fixed, there is another one as well: + ``` + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed. + ``` + + The reason for both of them is this kind of loop: + ``` + while (get_frame_type (frame) == INLINE_FRAME) + frame = get_prev_frame (frame); + ``` + Since get_prev_frame respects the backtrace limit, it will return + NULL, and from there on you can't continue. + This changes these loops to use get_prev_frame_always instead, so + you always get a non-inline frame in the end. + + With this backtrace works: + ``` + (gdb) bt + (gdb) + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865 + Approved-By: Andrew Burgess + +2024-01-29 Nick Clifton + + Updated French translations for GOLD and LD + +2024-01-29 GDB Administrator + + Automatic date update in version.in + +2024-01-28 Tom Tromey + + Document new Python and Guile constants + This documents the new Python and Guile constants introduced earlier + in this series. + + Approved-By: Eli Zaretskii + +2024-01-28 Tom Tromey + + Refine search in cp_search_static_and_baseclasses + This changes cp_search_static_and_baseclasses to only search for + types, functions, and modules. The latter two cases were discovered + by regression testing. I found it somewhat surprising the Fortran + name lookup ends up in this code, but did not attempt to change this. + + Only search for functions in rust_structop::evaluate_funcall + This changes rust_structop::evaluate_funcall to only search for + functions. + +2024-01-28 Tom Tromey + + Only search types in lookup_typename + This changes lookup_typename to only look for types. The check for + LOC_TYPEDEF can now also be removed, because only types will appear in + TYPE_DOMAIN. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24870 + +2024-01-28 Tom Tromey + + Only search types in cp_lookup_rtti_type + This changes cp_lookup_rtti_type to only search for types -- not + functions or variables. Due to the symbol-matching hack, this could + just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also + I hold on to some hope that perhaps the hack can someday be removed. + + Use a function-domain search in inside_main_func + This changes inside_main_func to search only for functions. + + Only look for functions in expand_symtabs_for_function + This changes expand_symtabs_for_function to only look in the function + domain. + + Only search for "main" as a function + This changes find_main_name to restrict its search to the function + domain. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in linespec.c + This simplifies some symbol searches in linespec.c. In particular, + two separate searches here can now be combined into one, due to the + new use of flags. + + Arguably the STRUCT_DOMAIN searches should perhaps not even be done. + Only C really has these, and C doesn't have member functions. + However, it seems relatively harmless -- and clearly compatible -- to + leave this in. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in Ada code + This changes some of the Ada code to simplify symbol searches. For + example, if a function is being looked for, the search is narrowed to + use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a + search of the "struct" domain is removed, because Ada does not have a + tag domain. + +2024-01-28 Tom Tromey + + Use the new symbol domains + This patch changes the DWARF reader to use the new symbol domains. It + also adjusts many bits of associated code to adapt to this change. + + The non-DWARF readers are updated on a best-effort basis. This is + somewhat simpler since most of them only support C and C++. I have no + way to test a few of these. + + I went back and forth a few times on how to handle the "tag" + situation. The basic problem is that C has a special namespace for + tags, which is separate from the type namespace. Other languages + don't do this. So, the question is, should a DW_TAG_structure_type + end up in the tag domain, or the type domain, or should it be + language-dependent? + + I settled on making it language-dependent using a thought experiment. + Suppose there was a Rust compiler that only emitted nameless + DW_TAG_structure_type objects, and specified all structure type names + using DW_TAG_typedef. This DWARF would be correct, in that it + faithfully represents the source language -- but would not work with a + purely struct-domain implementation in gdb. Therefore gdb would be + wrong. + + Now, this approach is a little tricky for C++, which uses tags but + also enters a typedef for them. I notice that some other readers -- + like stabsread -- actually emit a typedef symbol as well. And, I + think this is a reasonable approach. It uses more memory, but it + makes the internals simpler. However, DWARF never did this for + whatever reason, and so in the interest of keeping the series slightly + shorter, I've left some C++-specific hacks in place here. + + Note that this patch includes language_minimal as a language that uses + tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, + which doesn't specify the language for a type unit. Arguably this + test case is wrong. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164 + +2024-01-28 Tom Tromey + + Remove old symbol_matches_domain + Nothing calls the variant of symbol_matches_domain that accepts a + domain_enum for searching, so this patch removes it and the + corresponding symbol::matches. + + Remove some obsolete Python constants + The Python code has exported some constants, but they are no longer + documented, and were never useful. This patch removes them. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_symbol et al + This changes lookup_symbol and associated APIs to accept + domain_search_flags rather than a domain_enum. + + Note that this introduces some new constants to Python and Guile. I + chose to break out the documentation patch for this, because the + internals here do not change until a later patch, and it seemed + simpler to patch the docs just once, rather than twice. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_global_symbol_language + This changes quick_symbol_functions::lookup_global_symbol_language to + accept domain_search_flags rather than just a domain_enum, and fixes + up the fallout. + + To avoid introducing any regressions, any code passing VAR_DOMAIN now + uses SEARCH_VFT. + + That is, no visible changes should result from this patch. However, + it sets the stage to refine some searches later on. + +2024-01-28 Tom Tromey + + Introduce "scripting" domains + The Python and Guile code exposed the internal domain constants both + as attributes of symbols and as values to pass to lookup functions. + + Now, perfect backward compatibility here can't be achieved: some + symbols are going to have domain changes by the end of this series. + However, it seemed to me that we can preserve lookups using the basic + domain values. + + This patch implements this by exporting the "or"-able search constants + with an extra bit set. Then it introduces some functions to convert + such constants to domain_search_flags. This will be used by the + Python and Guile code, so that both old- and new-style lookups will + work properly; and while preserving the idea that the domain constants + can be compared to a symbol's domain. + +2024-01-28 Tom Tromey + + Remove a check of VAR_DOMAIN + completion_list_add_symbol checks that the returned symbol has + VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The + domain check is redundant -- only functions can possibly be LOC_BLOCK + -- and leaving this in place will cause a regression when combined + with a later patch in this series. This patch preemptively removes + the redundant check. + + Replace search_domain with domain_search_flags + This patch changes gdb to replace search_domain with + domain_search_flags everywhere. search_domain is removed. + + Add domain_search_flags + This adds a new flag enum type, domain_search_flags, which is the flag + version of domain_enum. Nothing uses this yet, but the goal here is + to have all symbol searches and lookups use these flags. The new + names are chosen to exactly parallel domain_enum. + +2024-01-28 Tom Tromey + + Add two new symbol domains + This adds two new symbol domain constants, TYPE_DOMAIN and + FUNCTION_DOMAIN. + + Historically, gdb was a C debugger, and the symbol tables continue to + reflect this. In particular, symbol domains match the C language, + with VAR_DOMAIN including variables, functions, and types. + + However, other languages have other approaches to namespacing. And, + in any case, it is often useful for other parts of gdb to be able to + distinguish between some domains at lookup time, without resorting to + examining a symbol's location -- in some situations, this sort of + filtering happens too late. + + Nothing uses these new domains yet, but the idea behind the patch is + to separate symbols into more domains and then let the + language-specific parts of gdb implement their semantics in terms of + these categories. + +2024-01-28 Tom Tromey + + Use a .def file for domain_enum + Future patches will change and reuse the names from domain_enum. This + patch makes this less error-prone by having a single point to define + these names, using the typical gdb ".def" file. + + Split up a big 'if' in symtab.c + global_symbol_searcher::add_matching_symbols in symtab.c has a + gigantic 'if' statement -- 33 lines of conditional expression. This + patch splits it up into a series of separate 'if's. + + Simplify symbol_to_info_string + Thi simplifies symbol_to_info_string, removing the 'kind' parameter + and instead having it use the symbol's domain. + +2024-01-28 Tom Tromey + + Remove NR_DOMAINS + NR_DOMAINS is only used for a static assert, but we no longer need it + now. If we add too many constants to this enum, GCC will warn about + the bitfield overflow: + + error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’ + +2024-01-28 Tom Tromey + + Give names to unspecified types + A patch later in this series will change check_typedef to also look in + the type domain. This change by itself caused a regression, but one + that revealed some peculiar behavior. + + The regression is in nullptr_t.exp, where examining a std::nullptr_t + will change from the correct: + + typedef decltype(nullptr) std::nullptr_t; + + to + + typedef void std::nullptr_t; + + Right now, the DWARF reader marks all unspecified types as stub types. + However, this interacts weirdly with check_typedef, which currently + does not try to resolve types -- only struct-domain objects. + + My first attempt here was to fix this by changing void types not to be + stub types, as I didn't see what value that provided. However, this + caused another regression, because call_function_by_hand_dummy checks + for stub-ness: + + if (values_type == NULL || values_type->is_stub ()) + values_type = default_return_type; + + I'm not really sure why it does this rather than check for + TYPE_CODE_VOID. + + While looking into this, I found another oddity: the DWARF reader + correctly creates a type named 'decltype(nullptr)' when it seems a + DW_TAG_unspecified_type -- but it creates a symbol named "void" + instead. + + This patch changes the DWARF reader to give the symbol the correct + name. This avoids the regression. + +2024-01-28 Tom Tromey + + Fix latent bug in mdebugread.c + mdebugread.c makes a label symbol but puts it into VAR_DOMAIN. I + think LABEL_DOMAIN is more appropriate. + + I don't have a way to test this. + +2024-01-28 Tom Tromey + + Make nsalias.exp more reliable + nsalias.exp tries to detect a complaint that is issued when expanding + a CU. However, the test is a bit funny in that, while gdb does + currently expand the CU and issue the complaint, it also emits this + error: + + No symbol "N100" in current context. + + This series will change gdb such that this CU is not expanded -- which + makes sense, the symbol in question doesn't actually match the lookups + that are done. + + So, to make the test more robust, a direct request to expand symtabs + is done instead. + +2024-01-28 Tom Tromey + + Fix latent bug in DW_TAG_entry_point handling + A DW_TAG_entry_point symbol inherits its extern/static property from + the enclosing subroutine. This is encoded in new_symbol -- but the + cooked indexer does not agree. + +2024-01-28 Tom Tromey + + Small cleanup in DWARF reader + I noticed a couple of spots in dwarf/read.c:new_symbol that call + add_symbol_to_list. However, this function is generally written to + set list_to_add, and then have a single call to add_symbol_to_list at + the end. This patch cleans up this discrepancy. + + Note that new_symbol is overlong and should probably be split up. + +2024-01-28 Tom Tromey + + Fix bug in cooked index scanner + Testing this entire series pointed out that the cooked index scanner + disagrees with new_symbol about certain symbols. In particular, + new_symbol has this comment: + + Ada and Fortran subprograms, whether marked external or + not, are always stored as a global symbol, because we want + + This patch updates the scanner to match. + + I don't know why the current code does not cause failures. + + It's maybe worth noting that incremental CU expansion -- creating + symtabs directly from the index -- would eliminate this sort of bug. + +2024-01-28 GDB Administrator + + Automatic date update in version.in + +2024-01-27 GDB Administrator + + Automatic date update in version.in + +2024-01-26 Indu Bhagat + + gas: scfi: untraceable control flow should be a hard error + PR gas/31284 + + Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be + created, and the SCFI machinery bails out with a warning: + "Warning: Untraceable control flow for func 'foo'; Skipping SCFI" + + It is, however, better suited if this is a hard error. Change it to a + hard error. Also change the message to skip mentioning "SCFI", because + the error itself may also useful when ginsns are used for other passes + (distinct from SCFI) involving GCFG, like a pass to detect if there is + unreachable code. Hence, simply say: + "Error: untraceable control flow for func 'foo'" + + gas/ + PR gas/31284 + * ginsn.c (ginsn_data_end): Use as_bad instead of as_warn. + + gas/testsuite/ + PR gas/31284 + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output + in case of errors. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning. + +2024-01-26 Indu Bhagat + + x86: testsuite: scfi: adjust COFI testcase + The testcase for change of flow instructions in its current shape is not + doing much: it checks that SCFI issues an appropriate warning. The same + warning is covered by another testcase (scfi-unsupported-cfg-1); It is + better to test the ginsn translation instead, for these 'change of flow + instructions'. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cofi-1.s: Moved to... + * gas/scfi/x86_64/ginsn-cofi-1.s: ...here. + * gas/scfi/x86_64/scfi-x86-64.exp: Adjust tests. + * gas/scfi/x86_64/scfi-cofi-1.d: Removed. + * gas/scfi/x86_64/scfi-cofi-1.l: Removed. + * gas/scfi/x86_64/ginsn-cofi-1.l: New test. + +2024-01-26 H.J. Lu + + elf: Rename is_standard_elf to uses_elf_em + Rename is_standard_elf to uses_elf_em for targets which use elf.em. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): Renamed + to ... + (uses_elf_em): This. + + ld/ + + PR ld/31289 + * testsuite/ld-elf/fatal-warnings-2a.d: Replace is_standard_elf + with uses_elf_em. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-26 Andrew Carlotti + + aarch64: move SHA512 instructions to +sha3 + SHA512 instructions were added to the architecture at the same time as SHA3 + instructions, but later than the SHA1 and SHA256 instructions. Furthermore, + implementations must support either both or neither of the SHA512 and SHA3 + instruction sets. However, SHA512 instructions were originally (and + incorrectly) added to Binutils under the +sha2 flag. + + This patch moves SHA512 instructions under the +sha3 flag, which matches the + architecture constraints and existing GCC and LLVM behaviour. + +2024-01-26 Nick Clifton + + Fix: Stripping Rust static libraries fails because of overly zealous illegal path check + PR 31250 + * objcopy.c (copy_archive): Improve the handling of archives that contain elements with invalid pathnames. + + Remove -pie from command line of fatal-warnings 1a and 1b tests. + +2024-01-26 Jan Beulich + + x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings + Re-using the entire VEX decode hierarchy for the respective major opcode + has led to those two also being decoded as-if valid. Follow the earlier + USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening. + + x86/APX: no need to have decode go through x86_64_table[] + As suggested during review already, all such entries have their first + slot as Bad_Opcode, so by adding two more enumerators we can avoid doing + that decode step altogether. + + x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix" + Adjustments made for the directive (by set_intel_syntax()) need also + making for the command line option. Break out respective code into a new + helper function, to also be invoked during command line processing. + Further also set register_prefix when processing -mnaked-reg. + + x86/APX: optimize MOVBE + With identical source and destination it can be covered by the NDD-to- + legacy conversion logic as well, even if in this case the original insn + doesn't use an NDD encoding. The size savings are even better here, for + the replacement (BSWAP) not having a ModR/M byte. + +2024-01-26 mengqinggang + + LoongArch: Fix a bug of getting relocation type + The old code works because R_LARCH_RELAX has no symbol index. It causes + '(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1. + +2024-01-26 mengqinggang + + LoongArch: gas: Add support for s9 register + In LoongArch ABI, r22 register can be used as frame pointer or + static register(s9). + + Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers + +2024-01-26 mengqinggang + + LoongArch: ld: Add support for TLS LE symbol with addend + Add support for TLS LE symbol with addend, such as: + lu12i.w $t0, %le_hi20(a + 0x8) + ori $t0, $t0, %le_lo12(a + 0x8) + +2024-01-26 Alan Modra + + Assertion failure dumping .eh_frame_hdr + dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated + sections, due to get_encoded_eh_value wrongly returning a full count + for truncated words. + + * dwarf.c (get_encoded_eh_value): Return zero for truncated words. + +2024-01-26 GDB Administrator + + Automatic date update in version.in + +2024-01-25 Simon Marchi + + gdb: remove get_gdb_program_name + Nothing uses it. + + Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7 + +2024-01-25 H.J. Lu + + elf: Add is_standard_elf + PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf, + mn10200-elf, ms1-elf and msp430-elf targets: + + FAIL: ld-elf/fatal-warnings-2a + FAIL: ld-elf/fatal-warnings-2b + FAIL: ld-elf/fatal-warnings-3a + FAIL: ld-elf/fatal-warnings-3b + FAIL: ld-elf/fatal-warnings-4a + FAIL: ld-elf/fatal-warnings-4b + + even though PR ld/31289 targets xfail for [is_generic] targets. These + targets not only don't use the generic_link_hash_table linker, but also + don't use the standard ELF emulation. Add is_standard_elf for ELF + targets which use the standard ELF emulation and replace [is_generic] + with ![is_standard_elf] in PR ld/31289 tests. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): New. + + ld/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_generic): Return 1 for + fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*, + moxie-*-moxiebox*, msp430-*-* and mt-*-*. + * testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic] + with ![is_standard_elf]. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 H.J. Lu + + ld: Always call output_unknown_cmdline_warning + Call output_unknown_cmdline_warning if there are no input files so that + + $ ld -z bad-option + + reports + + ld: warning: -z bad-option ignored + ld: no input files + + instead of + + ld: no input files + + PR ld/31289 + * ldmain.c (main): Call output_unknown_cmdline_warning if there + are no input files. + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix regexp in vgdb_start + On Fedora 39 aarch64 I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + relaying data between gdb and process 2114437^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + _start () at ../sysdeps/aarch64/dl-start.S:22^M + warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + For contrast, on openSUSE Leap 15.4 x86_64 I have: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + relaying data between gdb and process 18797^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib64/ld-linux-x86-64.so.2...^M + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M + 0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M + (gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The fail happens in vgdb_start because the regexp only matches the + "in _start ()" variant, not the "_start () at": + ... + gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb" + ... + Which variant you get is determined by presence of debug info. + + Fix this by also matching the "_start () at" variant. + + Tested aarch64-linux and x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-25 Andrew Carlotti + + gas: Update NEWS + Groups entries by architecture, and update AArch64 content. + +2024-01-25 Tom de Vries + + [gdb/build] Workaround gcc PR113599 + Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding + [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as + reported in PR build/31281. + + Work around this by flipping inherit order: + ... + -class thread_info : public refcounted_object, + - public intrusive_list_node + +class thread_info : public intrusive_list_node, + + public refcounted_object + ... + + An argument could be made that this isn't necessary, because this occurred in + an unreleased gcc version. + + However, I think it could be useful when bisecting gcc for other problems in + building gdb. Having this workaround means the bisect won't reintroduce the + problem. Furthermore, the workaround is harmless. + + Tested on Fedora rawhide x86_64. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281 + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599 + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix gdb.base/eh_return.exp + On Fedora rawhide aarch64, I run into: + ... + (gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address + run ^M + Starting program: eh_return ^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + [Inferior 1 (process 1113051) exited normally]^M + (gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited) + ... + + This happens as follows: the test-case sets a breakpoint on the last + instruction of function eh2: + ... + (gdb) break *0x00000000004103ec^M + ... + and expects to hit the breakpoint, but instead the "br x6" is taken: + ... + 0x00000000004103e0 <+176>: cbz x4, 0x4103ec ^M + 0x00000000004103e4 <+180>: add sp, sp, x5^M + 0x00000000004103e8 <+184>: br x6^M + 0x00000000004103ec <+188>: ret^M + ... + + In contrast, with fedora f39 we have: + ... + 0x00000000004103bc <+156>: ldp x2, x3, [sp, #48]^M + 0x00000000004103c0 <+160>: ldp x29, x30, [sp, #16]^M + 0x00000000004103c4 <+164>: add sp, sp, #0x50^M + 0x00000000004103c8 <+168>: add sp, sp, x4^M + 0x00000000004103cc <+172>: ret^M + + ... + and the breakpoint is reached. + + Fix this by detecting that the breakpoint is not hit, and declaring the test + unsupported. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31291 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291 + +2024-01-25 Aditya Vidyadhar Kamath + + Fix attach-twice.c testcase for AIX. + Currently, in AIX attach-twice.exp testcase is untested due to the below error. + gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace' + + This is because in AIX ptrace has five arguments. This patch is a fix for the same such that + this test case runs in AIX and other targets as well. + +2024-01-25 H.J. Lu + + ld: Improve --fatal-warnings for unknown command-line options + There are 2 problems with --fatal-warnings for unknown command-line + options: + + 1. --fatal-warnings doesn't trigger an error for an unknown command-line + option when --fatal-warnings is the last command-line option. + 2. When --fatal-warnings triggers an error for an unknown command-line + option, the message says that the unknown command-line option is ignored. + + This patch queues unknown command-line option warnings and outputs queued + command-line option warnings after all command-line options have been + processed so that --fatal-warnings can work for unknown command-line + options regardless of the order of --fatal-warnings. + + When --fatal-warnings is used, the linker message is changed from + + ld: warning: -z bad-option ignored + + to + + ld: error: unsupported option: -z bad-option + + The above also applies to "-z dynamic-undefined-weak" when the known + "-z dynamic-undefined-weak" option is ignored. + + PR ld/31289 + * ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning + to warn the ignored -z dynamic-undefined-weak option. + * ldmain.c (main): Call output_unknown_cmdline_warnings after + calling ldemul_after_parse. + * ldmisc.c (CMDLINE_WARNING_SIZE): New. + (cmdline_warning_list): Likewise. + (cmdline_warning_head): Likewise. + (cmdline_warning_tail): Likewise. + (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * ldmisc.h (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use + queue_unknown_cmdline_warning to warn unknown -z option. + * testsuite/ld-elf/fatal-warnings-1a.d: New file. + * testsuite/ld-elf/fatal-warnings-1b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 GDB Administrator + + Automatic date update in version.in + +2024-01-24 Alan Modra + + riscv64-pei uninitialised data writing relocs + Without this patch the r_offset field of struct external_reloc is + uninitialised when using objcopy. + + * coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define. + (SWAP_OUT_RELOC_OFFSET): Define. + +2024-01-24 Tom Tromey + + Emit stopped event for DAP attach request + In an earlier patch, I wrote: + + ... It also adds some machinery so that attach stops can be + suppressed, which I think is the right thing to do. + + However, after some discussions here at AdaCore, I now believe this to + be incorrect -- while DAP says that expected "continue" events should + be suppressed, there is no corresponding language for expected "stop" + events, and indeed "stop" events explicitly mention cases like "step". + + This patch arranges for the stop event to be emitted again. + +2024-01-24 Tom Tromey + + Handle DW_AT_endianity on enumeration types + A user found that gdb would not correctly print a field from an Ada + record using the scalar storage order feature. We tracked this down + to a combination of problems. + + First, GCC did not emit DW_AT_endianity on the enumeration type. + DWARF does not specify this, but it is an obvious and harmless + extension. This was fixed in GCC recently: + + https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html + https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd + + Second, GDB did not handle this attribute on enumeration types. This + patch makes this change and adds a test case that will pass with the + patched GCC. + + So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes + in, the test case in this patch can be updated to reflect that. + + Reviewed-By: Keith Seitz + +2024-01-24 Thiago Jung Bauermann + + gdb/arm: Fix epilogue frame id + arm_epilogue_frame_this_id has a comment saying that it fall backs to using + the current PC if the function start address can't be identified, but it + actually uses only the PC to make the frame id. + + This patch makes the code match the comment. Another hint that it's what + is intended is that arm_prologue_this_id, a function almost identical to + it, does that. + + The problem was found by code inspection. It fixes the following testsuite + failures: + + FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches + FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two + + Tested on arm-linux-gnueabi-hf. + +2024-01-24 Guinevere Larsen + + gdb/testsuite: add test for backtracing for threaded inferiors from a corefile + This patch is based on an out-of-tree patch that fedora has been + carrying for a while. It tests if GDB is able to properly unwind a + threaded program in the following situations: + * regular threads + * in a signal handler + * in a signal handler executing on an alternate stack + + And the final frame can either be in a syscall or in an infinite loop. + + The test works by running the inferior until a crash to generate a + corefile, or until right before the crash. Then applies a backtrace to + all threads to see if any frame can't be identified, and the order of + the threads in GDB. Finally, it goes thread by thread and tries to + collect a large part of the backtrace, to confirm that everything is + being unwound correctly. + + Co-Authored-By: Andrew Burgess + Reviewed-By: Luis Machado + Approved-By: Luis Machado + +2024-01-24 Andrew Carlotti + + aarch64: Eliminate unused variable warnings with -DNDEBUG + +2024-01-24 mengqinggang + + LoongArch: gas: Start a new frag after instructions that can be relaxed + For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20} + relocations, start a new frag to get correct eh_frame Call Frame Information + FDE DW_CFA_advance_loc info. + +2024-01-24 mengqinggang + + LoongArch: gas: Don't define LoongArch .align + Gcc may generate "\t.align\t%d,54525952,4\n" before commit + b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object + file, we call s_align_ptwo (-4). It result in alignment padding must be a + multiple of 4 if .align has second parameter. + + Use default s_align_ptwo for .align. + +2024-01-24 Paul Iannetta + + Add myself as the KVX port maintainer + binutils/ChangeLog: + + * MAINTAINERS: Add myself as the KVX port maintainer. + +2024-01-24 GDB Administrator + + Automatic date update in version.in + +2024-01-23 Andrew Carlotti + + aarch64: Update Architecture Extensions documentation + Restructure the architecture extensions table, add a new table for architecture + version dependencies, add missing architecture extensions, and improve some + extension descriptions. + + aarch64: Include +predres2 in -march=armv8.9-a + This matches the dependencies in the architecture, in LLVM, and even in the + original Binutils commit message that mistakenly included it only in armv9.4-a. + +2024-01-23 Xi Ruoyao + + [PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42 + +2024-01-23 Guinevere Larsen + + gdb: fix "list ." related crash + When a user attempts to use the "list ." command with an inferior that + doesn't have debug symbols, GDB would crash. This was reported as PR + gdb/31256. + + The crash would happen when attempting to get the current symtab_and_line + for the stop location, because the symtab would return a null pointer + and we'd attempt to dereference it to print the line. + + This commit fixes that by checking for an empty symtab and erroring out + of the function if it happens. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256 + Approved-By: Tom Tromey + +2024-01-23 Mike Frysinger + + sim: sh: fix nested braces in struct init + The op struct includes an array of strings, but doesn't use braces + around that array when initializing. This causes a ton of warnings + when using -Wmissing-braces. Add them to fix. + + The code this tool generates is the same before & after. + +2024-01-23 Jaydeep Patil + + sim: riscv: Fix crash during instruction decoding + The match_never() function has been removed and thus step_once() crashes + during instruction decoding. Fixed it by checking for null pointer before + invoking function attached to match_func member of riscv_opcode structure + +2024-01-23 Mike Frysinger + + sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752] + Some compilers warn in the frv code: + sem.c:24343:41: error: incompatible function pointer types passing + 'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)') + to parameter of type + 'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types] + + This is due to frvbf_h_acc40U_set using UDI for setting the new value, + but using the common sim_queue_fn_di_write API which uses DI. The same + size, but different sign. We could change frvbf_h_acc40U_set to take a + DI without changing behavior in practice: the UDI is already passed via + the queue function which accepts a DI, and frvbf_h_acc40U_set already + casts the input to UDI before running any operations on it. However, + these files are all generated, so manual changes here would be reverted. + + Seems like we can only change the register type for all APIs in the cpu + definition. This builds cleanly, and passes sim unittests. Not sure if + it's 100% the answer, but seems to be the best we have currently. + + Bug: https://sourceware.org/PR29752 + +2024-01-23 GDB Administrator + + Automatic date update in version.in + +2024-01-22 Simon Marchi + + gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp (and more) + Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test + name. This happens because have_index calls get_index_type with the + default test name. Refactor the test to avoid this, while cleaning a + few other things, the most important being: + + - factor out the relocated and unrelocated parts in their own procs + - give different names to generated binaries in different variations, + such that all binaries are left in the test output directory (this + makes it easier to debug a specific variation) + + Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94 + +2024-01-22 Vladimir Mezentsev + + Fix 31252 gprofng causes testsuite parallel jobs fail + Before running our tests, we made a fake installation into ./tmpdir. + This installation changes libopcodes.la in the build area. + Gas testing may fail if gas and gprofng tests are run in parallel. + + I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH, + GPROFNG_SYSCONFDIR are set. + putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create + directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used + to set up LD_PRELOAD). + + gprofng/ChangeLog + 2024-01-19 Vladimir Mezentsev + + PR gprofng/31252 + PR gprofng/30808 + * src/envsets.cc (putenv_libcollector_ld_misc): Use + $GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH. + * testsuite/config/default.exp: Create a script to run gprofng. + * testsuite/lib/display-lib.exp: Fix typo. + +2024-01-22 Nick Clifton + + Updated Serbian translations for th bfd, gold and opcodes directories + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in srconv.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils/srconv.c: In function ‘nints’: + binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 598 | return (int *) (xcalloc (sizeof (int), x)); + | ^~~ + binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * srconv.c (nints): Swap xcalloc arguments. + (wr_du): Likewise. + (wr_dus): Likewise. + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in coffgrok.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’: + binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section), + | ^~~~~~ + binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * coffgrok.c (empty_scope): Swap xcalloc arguments. + (empty_symbol): Likewise. + (do_lines): Likewise. + (doit): Likewise. + (coff_grok): Likewise. + +2024-01-22 Mark Wielaard + + libsframe: Fix calloc argument order in dump_sframe_header + GCC14 warns about the order of the arguments to calloc + + libsframe/sframe-dump.c: In function ‘dump_sframe_header’: + libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] + 70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN); + | ^~~~ + libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element + + Fix this by swapping the size and count arguments. + + libsframe/ + + * sframe-dump.c (dump_sframe_header): Swap arguments to calloc + +2024-01-22 Mark Wielaard + + opcodes: tic4x_disassemble swap xcalloc arguments + GCC 14 will detect when the size and count arguments of calloc are + swapped. + + binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’: + binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE)); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element + binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element + + opcodes/ChangeLog: + + * /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc + arguments. + +2024-01-22 Tom Tromey + + Handle EOF more gracefully in DAP + A user pointed out that gdb will print a Python exception when it gets + an EOF in DAP mode. And, it turns out that an EOF like this also + causes gdb not to exit. This is due to the refactoring that moved the + JSON reader to its own thread -- previously this caused an exception + to propagate and cause an exit, but now it just leaves the reader + hung. + + This patch fixes these problems by arranging to handle EOF more + gracefully. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217 + +2024-01-22 Tom Tromey + + Fix handling of DW_OP_GNU_push_tls_address + In one spot, DW_OP_GNU_push_tls_address is handled differently from + DW_OP_form_tls_address. However, I think they should always be + treated identically. + + Approved-by: Kevin Buettner + +2024-01-22 Mark Wielaard + + sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write} + m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit + + sim/m32c/gdb-if.c: In function ‘sim_read’: + sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local] + 162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length) + | ~~~~~~~~~^~~ + In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38: + sim/m32c/cpu.h:83:3: note: shadowed declaration is here + 83 | mem, + | ^~~ + + Fix this by renaming mem to addr in all sim_read and sim_write functions. + Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this + also meant renaming the local addr variable to vma. + +2024-01-22 Mark Wielaard + + sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.c + With GCC 14 -Werror=shadow=compatible-local flags the reuse of single + capital letters used in aarch64/cpustate.h enums + + 88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N) + | ~~~~~~~~~^ + In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27, + from ../../binutils-gdb/sim/aarch64/simulator.c:33: + 217 | N = 1 << N_IDX + | ^ + + sim/aarch64/simulator.c: In function ‘expand_logical_immediate’: + sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local] + sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here + +2024-01-22 Mark Wielaard + + sim: Fix cc -Werror=shadow=local in cr16/simops.c + include/opcode/cr16.h defines cc as an enum value, which causes GCC 14 + to warn + + sim/cr16/simops.c: In function ‘cond_stat’: + sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local] + 138 | static int cond_stat(int cc) + | ~~~~^~ + In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26, + from ../../binutils-gdb/sim/cr16/simops.c:39: + sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here + 149 | cc, + | ^~ + + Fix this by renaming cc in cr16/simops.c to cond. + +2024-01-22 Guinevere Larsen + + gdb/testsuite: relax filename restriction in some gdb.btrace tests + The test gdb.btrace/tailcall.exp has multiple tests that include the + filename in the output. When testing with gcc, only a relative path is + printed, but when using clang, the full file path is printed instead. + This makes most of those tests fail, with the exception of "record goto + 4" which allows for more characters before the file name. The test + gdb.btrace/recod_goto.exp suffers with the same issue + + This commit allows for text before the filename. However, instead of how + the aforementioned "record goto 4", it uses a regexp that doesn't allow + for newlines, just in case some off output happens. + + Approved-By: Tom Tromey + +2024-01-22 Guinevere Larsen + + gdb/testsuite: modernize gdb.dwarf2/dw2-noloc.exp + The test gdb.dwarf2/dw2-noloc.exp predates the dwarf assembler, and uses + some unreliable assumptions about where global labels get put. + Specifically, when using clang to compile the test, both labels it uses + to gauge the adresses of the main function get reshuffled to be side-by-side, + and the debug information ends up making it look like main's high pc is equal + to low pc, meaning we never enter the main function's scope, and that leads to + 22 failures because the "main_*" variables are technically never in scope. + + This patch modernizes the aforementioned test to use the dwarf + assembler, which removes all failures when using clang. It also renames + the .c file to be more inline with current standard. + + Approved-By: Tom Tromey + +2024-01-22 Xi Ruoyao + + LoongArch: Fix some test failures about TLS desc and TLS relaxation + There are two issues causing 11 test failures: + + 1. The TLS desc tests are matching the entire disassemble of a linked + executable. But if ld is configured --enable-default-hash-style=gnu + (note that most modern distros use this option), the layout of the + linked executables will be different and the immediate operands in + the linked executables will also be different. So we add + "--hash-style=both" for these tests to cancel the effect of + --enable-default-hash-style=gnu, like [x86_64 mark-plt tests]. + 2. By default objdump disassemble uses [pseudo-instructions] so "addi.w" + is outputed as "li.w", causing mismatches in TLS relaxation tests. + We can turn off the pseudo-instruction usage in objdump using "-M + no-aliases" to fix them. + + [x86_64 mark-plt tests]: 16666ccc91295d1568c5c2cb0e7600694840dfd9 + [pseudo-instructions]: 17f9439038257b1de0c130a416a9a7645c653cb0 + +2024-01-22 Tatsuyuki Ishi + + LoongArch: Do not add DF_STATIC_TLS for TLS LE + TLS LE is exclusively for executables, while DF_STATIC_TLS is for DLLs. + DF_STATIC_TLS should only be set for TLS IE (and when it's DLL), not LE. + + LoongArch: Use tab to indent assembly in TLSDESC test suite + The usual convention is to use tabs. Not all test are following this, + but at least when using tabs, let's use it consistently throughout the + file. + +2024-01-22 Jan Beulich + + x86/APX: also amend the PUSH2/POP2 testcase + Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be + encoded") took care of only half of the remaining issue. Add #pass here + as well. + +2024-01-22 GDB Administrator + + Automatic date update in version.in + +2024-01-21 Lancelot SIX + + gdb/infrun: lazily load curr_frame_id in process_event_stop_test + A recent(ish) change in gdb/infrun.c made process_event_stop_test load + debug information where it would not have done so previously. The + change is: + + commit bf2813aff8f2988ad3d53e819a0415abf295c91f + AuthorDate: Fri Sep 1 13:47:32 2023 +0200 + CommitDate: Mon Nov 20 10:54:03 2023 +0100 + + gdb/record: print frame information when exiting a recursive call + + Currently, when GDB is reverse stepping out of a function into the same + function due to a recursive call, it doesn't print frame information, as + reported by PR record/29178. This happens because when the inferior + leaves the current frame, GDB decides to refresh the step information, + clobbering the original step_frame_id, making it impossible to figure + out later on that the frame has been changed. + + This commit changes GDB so that, if we notice we're in this exact + situation, we won't refresh the step information. + + Because of implementation details, this change can cause some debug + information to be read when it normally wouldn't before, which showed up + as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that + isn't a problem, the test was changed to allow for the new output. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 + + Although there is nothing wrong with this change in principle, it + happens to break most of the tests in gdb/testsuite/gdb.rocm/*.exp. + This is because those tests do rely on GDB not loading debug + information. This is necessary because the debug information produced + for AMDGPU code is using DWARF extensions which are not supported by GDB + at this point. + + In this patch, I propose to use a lazy loading mechanism so the frame_id + for the current frame is only computed when required instead of when + entering process_event_stop_test. The lazy_loader class is currently + defined locally in infrun.c, but if it turns out to be useful elsewhere, + it could go somewhere under gdbsupport. + + This patch should restore the behavior GDB had before + bf2813aff8f2988ad3d53e819a0415abf295c91f when it comes to load debug + info. + + Another approach could have been to revert + fb84fbf8a51f5be2e78765508ebd9753af96b492 (gdb/infrun: simplify + process_event_stop_test) and adjust the implementation of + bf2813aff8f2988ad3d53e819a0415abf295c91f (gdb/record: print frame + information when exiting a recursive call). However, I think that the + lazy loading works well with the simplification done recently, so I went + down that route. + + Regression tested on x86_64-linux (Ubuntu 22.04) with AMDGPU support. + + Change-Id: Ib63a162128130d1786a77c98623e9e3dcbc363b7 + Approved-by: Kevin Buettner + +2024-01-21 mengqinggang + + LoongArch: Do not emit R_LARCH_RELAX for two register macros + For two register macros (e.g. la.local $t0, $t1, symbol) used in extreme code + model, do not emit R_LARCH_RELAX relocations. + +2024-01-21 GDB Administrator + + Automatic date update in version.in + +2024-01-20 Simon Marchi + + gdb: remove SYMBOL_*_OPS macros + Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in + favor of methods on struct symbol. More changes could be done here to + improve the design and make things safer, but I just wanted to do a + straightforward change to remove the macros for now. + + Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21 + Reviewed-by: Kevin Buettner + +2024-01-20 Tom Tromey + + Simplify DWARF symtab inclusion handling + In the past, dwarf2_per_cu_data was allocated using malloc, so special + handling was needed for the vector used for symtab handling. We + changed this to use 'new' a while back, so this code can now be + greatly simplified. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + +2024-01-20 GDB Administrator + + Automatic date update in version.in + +2024-01-19 Andrew Burgess + + gdb: remove deprecated_exec_file_display_hook and associated code + This commit removes deprecated_exec_file_display_hook and the + associated specify_exec_file_hook. + + The specify_exec_file_hook is used to add a new hook function to + deprecated_exec_file_display_hook, but is only used from the insight + debugger. + + I posted a patch to remove the use of specify_exec_file_hook from + insight, and instead use gdb::observers::executable_changed, this + patch can be found here (it has now been merged): + + https://inbox.sourceware.org/insight/6abeb45e97d9004ec331e94cf2089af00553de76.1702379379.git.aburgess@redhat.com/T/#u + + With this merged we can now cleanup the GDB side as this code is now + unused. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-01-19 Сергей Чернов + + Fix remote serial read + After closing "Bug 30770 - serial.c does not preserve errno correctly" + https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The + documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is + permissible to use recv in the case of a non-socket. + + condition: + os: Distributor ID: Ubuntu + Description: Ubuntu 23.10 + Release: 23.10 + Codename: mantic + + libc: + ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38 + kernel: + Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux + gdb: build from trank at 15.0.50.20231226-git + + GDB output: + $ arm-kgp-eabi-gdb + GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>) + 15.0.50.20231226-git + .... + (gdb) tar ext /dev/ttyACM1 + Remote debugging using /dev/ttyACM1 + Remote communication error. Target disconnected: error while reading: Socket operation on non-socket. + (gdb) + + after fix gdb work fine + + $ arm-kgp-eabi-gdb -q + (gdb) tar ext /dev/ttyACM0 + Remote debugging using /dev/ttyACM0 + (gdb) mon swd + Target voltage: 0.0V + Available Targets: + No. Att Driver + STM32F40x M4 + (gdb) att 1 + Attaching to Remote target + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x08020c80 in ?? () + (gdb) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + +2024-01-19 Aaron Merey + + gdb/ui-out.h: Fix exception handling in do_with_buffered_output + Replace throw with throw_exeception in do_with_buffered_output. + + This patch fixes regressions in gdb.dwarf2/dw2-dir-file-name.exp + caused by commit 519d63439. + + do_with_buffered_output needs to use throw_exception instead of + throw to ensure that exceptions of the correct type are thrown. + If using throw, gdb_exception_error may be wrongly converted into + gdb_exception during print_frame_info. This prevents the exception + from being caught in print_stack_frame. + +2024-01-19 Tom de Vries + + [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp + With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into: + ... + (gdb) attach 7773^M + Attaching to program: attach-many-short-lived-threads, process 7773^M + Cannot attach to lwp 7776: Operation not permitted (1)^M + (gdb) PASS: $exp: iter 1: attach + info threads^M + No threads.^M + (gdb) PASS: $exp: iter 1: no new threads + set breakpoint always-inserted on^M + (gdb) PASS: $exp: iter 1: set breakpoint always-inserted on + break break_fn^M + Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M + (gdb) PASS: $exp: iter 1: break break_fn + continue^M + The program is not being run.^M + (gdb) FAIL: $exp: iter 1: break at break_fn: 1 \ + (the program is no longer running) + ... + + There's some code in the test-case dealing with a similar warning: + ... + -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { + ... + + But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be + traced"), the warning has been changed into an error. + + Fix the FAIL by updating the test-case to expect an error instead of a + warning. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-19 Simon Marchi + + gdb: remove unnecessary NULL checks for return value of value_from_register + value_from_register can't return nullptr, remove some NULL checks. + + Change-Id: Ia6b32b8f86e593c535e3678a89dffe5544eb7ab0 + Approved-By: Tom Tromey + +2024-01-19 H.J. Lu + + ld: Remove scripttempl/elf_chaos.sc + scripttempl/elf_chaos.sc is unused. Remove it. + + * scripttempl/elf_chaos.sc: Removed. + +2024-01-19 H.J. Lu + + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc which are unused + after + + commit 3596d8ceb2cdc35b4fd702ee9daace5a2d880174 + Author: Alan Modra + Date: Wed Apr 18 15:39:34 2018 +0930 + + Remove mips aout, coff, and pe support + + bfd/ + + * hosts/mipsbsd.h: Removed. + + ld/ + + * scripttempl/mipsbsd.sc: Removed. + +2024-01-19 Oleg Tolmatcev + + ld: fix 32-bit mingw DLL symbol export bug + I think there's a bug in ld on 32-bit Windows. Here is a tiny project for reproducing the problem: + https://github.com/oltolm/ld-mingw32-bug + + A 32-bit DLL exports two stdcall functions "myfunc" and "myfunc64". The functions would normally get + exported as "myfunc@0" and "myfunc64@0". The "DEF" file exports them as "myfunc" and "myfunc64" + without the decorations. When you run the executable it shows an error message saying that it cannot + find "myfunc64". + + I think it happens because the sorting in ld is wrong. I think it should use the exported names + "myfunc" and "myfunc64", but instead it uses the decorated names "myfunc@0" or "myfunc65@0". The + ordering of functions in the DLL is different depending on which names you use. + + My patch changes ld to use undecorated exported names for sorting and it seems to fix the problem. + When I execute ctest in my project, it runs successfully. + +2024-01-19 H.J. Lu + + Update x86/APX: VROUND{P,S}{S,D} can generally be encoded + Append "#pass" to APX tests for targets which pad text sections with NOPs. + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Append + "#pass". + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. + +2024-01-19 Nick Clifton + + Update readelf's and objdump's debug frame displaying feature to include the contents of the .eh_frame_hdr section, if present. + +2024-01-19 H.J. Lu + + ld: Put all emulation options in ldlex.h + For each command line option, parse_args() calls ldemul_parse_args() + to check if the command line option is an emulation option. But when + there is a conflict between the emulation option value and the default + option value, the default command line option will be processed as if + the emulation option is used. Remove PARSE_AND_LIST_PROLOGUE and move + all emulation options to ldlex.h to avoid conflicts. + + PR ld/31247 + * ldlex.h (option_values): Add all emulation options. + * emulparams/elf32mcore.sh (PARSE_AND_LIST_PROLOGUE): Removed. + * emulparams/plt_unwind.sh (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aarch64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/alphaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/armelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/avrelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/bfin.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/cskyelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/hppaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ia64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68hc1xelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68kelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/metagelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/mipself.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nds32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nto.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/riscvelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/rxelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/s390.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/scoreelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/spuelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/tic6xdsbt.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/vxworks.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aix.em: Include "ldlex.h". + (OPTION_XXX): Removed. + (gld${EMULATION_NAME}_read_file): Replace lineno with linenumber. + * emultempl/beos.em (OPTION_XXX): Removed. + * emultempl/elf.em: Include "ldlex.h". + Don't check PARSE_AND_LIST_PROLOGUE. + (OPTION_XXX): Removed. + * emultempl/msp430.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/pe.em (OPTION_XXX): Removed. + * emultempl/pep.em (OPTION_XXX): Likewise. + * emultempl/ticoff.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/vms.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/xtensaelf.em (elf32xtensa_size_opt, + elf32xtensa_no_literal_movement, elf32xtensa_abi): Moved out of + PARSE_AND_LIST_PROLOGUE. + (PARSE_AND_LIST_PROLOGUE): Removed. + +2024-01-19 Nick Clifton + + Add multilib.am to the list of top level files included in any release created by the src-release.sh script + +2024-01-19 Jan Beulich + + x86-64: Dwarf2 register numbers for %bnd + I don't see why we shouldn't record them when they have been allocated, + even if they're (bogusly) named as reserved in the ABI right now. + + x86/APX: VROUND{P,S}{S,D} can generally be encoded + VRNDSCALE{P,S}{S,D} is the AVX512 generalization of these AVX insns. As + long as the immediate has the top 4 bits clear, they are equivalent to + the earlier VEX-encoded insns, and hence can be used to permit use of + eGPR-s in the memory operand. Since this is the normal way of using + these insns, also alter the resulting diagnostic to complain about the + immediate, not the eGPR use. + + x86/APX: be consistent with insn suffixes + When there's a suitably disambiguating register operand, suffixes are + generally omitted (unless in suffix-always mode). All NDD insns have a + suitable register operand, so they shouldn't have suffixes by default. + + x86: drop redundant EVex128 from PUSH2/POP2 + EVexMap4 already covers that. + + x86: support APX forms of U{RD,WR}MSR + This was missed in 6177c84d5edc ("Support APX GPR32 with extend evex + prefix"). + +2024-01-19 Aaron Merey + + gdb: Buffer output streams during events that might download debuginfo + Introduce new ui_file buffering_file to temporarily collect output + written to gdb_std* output streams during print_thread, print_frame_info + and print_stop_event. + + This ensures that output during these functions is not interrupted + by debuginfod progress messages. + + With the addition of deferred debuginfo downloading it is possible + for download progress messages to print during these events. + Without any intervention we can end up with poorly formatted output: + + (gdb) backtrace + [...] + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0 + function_cache=0x561221b224d0, state=... + + To fix this we buffer writes to gdb_std* output streams while allowing + debuginfod progress messages to skip the buffers and print to the + underlying output streams immediately. Buffered output is then written + to the output streams. This ensures that progress messages print first, + followed by uninterrupted frame/thread/stop info: + + (gdb) backtrace + [...] + Downloading separate debug info for /lib64/libpython3.11.so.1.0 + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=... + + Co-Authored-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-01-19 GDB Administrator + + Automatic date update in version.in + +2024-01-18 Tom Tromey + + Rewrite .debug_names writer + This rewrites GDB's .debug_names writer. It is now closer to the form + imagined in the DWARF spec. In particular, names are emitted exactly + as they appear in the original DWARF. + + In order to make the reader work nicely, some extensions were needed. + These were all documented in an earlier patch. Note that in + particular this writer solves the "main name" problem by putting a + flag into the table. + + GDB does not use the .debug_names hash table, so it also does not + write one. I consider this hash table to be essentially useless in + general, due to the name canonicalization problem -- while DWARF says + that writers should use the system demangling style, (1) this style + varies across systems, so it can't truly be relied on; and (2) at + least GCC and one other compiler don't actually follow this part of + the spec anyway. + + It's important to note, though, that even if the hash was somehow + useful, GDB probably still would not use it -- a sorted list of names + is needed for completion and performs reasonably well for other + lookups, so a hash table is just overhead, IMO. + + String emission is also simplified. There's no need in this writer to + ingest the contents of .debug_str. + + A couple of tests are updated to reflect the fact that they now "fail" + because the tests don't include .debug_aranges in the .S file. + Arguably the .debug_names writer should also create this section; but + I did not implement that in this series, and there is a separate bug + about it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 + +2024-01-18 Tom Tromey + + Export dwarf5_augmentation + I don't know why gdb had the .debug_names augmentation string in two + separate places; this patch exports it in one spot, to be used in + another. + +2024-01-18 Tom Tromey + + Rewrite .debug_names reader + This rewrites the .debug_names reader to follow the spec. + + Since it was first written, gdb's .debug_names writer has been + incorrect -- while the form of the section has been ok, the contents + have been very gdb-specific. + + This patch fixes the reader side of this equation, rewriting the + reader to create a cooked index internally -- an important detail + because it allows for the deletion of a lot of code, and it means the + various readers will agree more often. + + This reader checks for a new augmentation string. For the time being, + all other producers are ignored -- the old GDB ones because they are + wrong, and clang because it does not emit DW_IDX_parent. (If there + are any other producers, I'm unaware of them.) + + While the new reader mostly runs in a worker thread, it does not try + to distribute its work. This could be done by partitioning the name + table. The parent computations could also be done in parallel after + all names have been read. I haven't attempted this. + + Note that this patch temporarily regresses gdb.base/gdb-index-err.exp. + This test writes an index using gdb -- but at this particular stage, + gdb cannot read the indexes it creates. Rather than merge the patches + into a mega-patch, I've chosen to just accept this temporary + regression. + + In v1 of this patch, I made the new reader more strict about requiring + .debug_aranges. In v2, I've backed this out and kept the previous + logic. This solved a few test failures, though it's arguably not the + right approach. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Allow other results in DW_TAG_entry_point test + DW_TAG_entry_point is implemented by adding a new LOC_BLOCK symbol -- + that is, another function symbol. However, the test case assumes that + "bt" will never pick this symbol. + + This assumption seems unwarranted to me, and in fact this test will + regress with the debug-names target board after the .debug_names + rewrite. + + This patch changes the test to allow either answer in the backtrace. + If only the main entry point is desired, then it seems that more work + must be done to handle DW_TAG_entry_point properly, as nothing + currently guarantees this property. + +2024-01-18 Tom Tromey + + Remove some .debug_names tests + These .debug_names tests were hand-written to mimic clang. However, + they are difficult to update, and in any case the new reader won't + accept clang-generated indices. Therefore this patch removes these + tests. + +2024-01-18 Tom Tromey + + Explicitly expand CUs in dw2-inline-with-lexical-scope.exp + dw2-inline-with-lexical-scope.exp relies on the main CU being + expanded. However, it doesn't guarantee that this actually happens, + and with the new .debug_names reader, it won't, because the "main" + program will be found in the index without requiring CU expansion. + + This patch fixes the problem by explicitly expanding the CU in + question. + + Note that this is an artificial bug -- it occurs because the generated + .debug_aranges isn't correct. + +2024-01-18 Tom Tromey + + Fix dw2-zero-range.exp when an index is in use + dw2-zero-range.exp looks for a certain complaint, but this won't be + issued when an index is in use. This patch changes the test to not + fail in this case. + +2024-01-18 Tom Tromey + + Empty hash table fix in .debug_names reader + The handling of an empty hash table in the .debug_names reader is + slightly wrong. + + Currently the code assumes there is always an array of hashes. + However, section 6.1.1.4.5 Hash Lookup Table says: + + The optional hash lookup table immediately follows the list of + type signatures. + + and then: + + The hash lookup table is actually two separate arrays: an array of + buckets, followed immediately by an array of hashes. + + My reading of this is that the hash table as a whole is optional, and + so the hashes will not exist in this case. (This also makes sense + because the hashes are not useful without the buckets anyway.) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Remove cooked_index_worker::start_reading + I noticed that cooked_index_worker::start_reading isn't really needed. + This patch removes it, and also removes the SCOPED_EXIT, in favor of a + direct call. + +2024-01-18 Tom Tromey + + Change cooked_index_worker to abstract base class + This changes cooked_index_worker to be an abstract base class. The + base class implementation is moved to cooked-index.c, and a concrete + subclass is added to read.c. + + This change is preparation for the new .debug_names reader, which will + supply its own concrete implementation of the worker. + +2024-01-18 Tom Tromey + + Do not write the index cache from an index + The new .debug_names reader will work by creating a cooked index from + .debug_names. This patch updates cooked_index::maybe_write_index to + avoid writing the index in this case. + + However, in order to do this in a clean way, the readers are changed + so that a nullptr result from index_for_writing means "cannot be + done", and then the error message is moved into write_dwarf_index + (where it historically lived). + +2024-01-18 Tom Tromey + + Move cooked_index_functions to cooked-index.h + This moves the declaration of cooked_index_functions to + cooked-index.h. This makes it visible for use by the rewritten + .debug_names reader, and it also lets us move the implementation of + make_quick_functions into cooked-index.c, where it really belongs. + +2024-01-18 Tom Tromey + + Add language to cooked_index_entry + This adds a new 'lang' member to cooked_index_entry. This holds the + language of the symbol. This is primarily useful for the new + .debug_names reader, which will not scan the CUs for languages up + front. + + This also changes cooked_index_shard::add to return a non-const + pointer. This doesn't impact the current code, but is needed for the + new reader. + +2024-01-18 Tom Tromey + + Document GDB extensions to DWARF .debug_names + GDB's new .debug_names implementation uses some extensions. This + patch adds some documentation on this to the manual. + + Reviewed-By: Eli Zaretskii + +2024-01-18 Tom Tromey + + Remove IS_ENUM_CLASS from cooked_index_flag + I noticed that cooked_index_flag::IS_ENUM_CLASS is not needed. This + patch removes it. + +2024-01-18 Tom Tromey + + Refactor quick-function installation in DWARF reader + While working on the previous patch, I saw that the handling of + quick-function installation could be unified + dwarf2_initialize_objfile. In particular, at the end of the function, + if there is an index table, then it can be used to create the quick + function object. + + This cleanup will be useful when rewriting the .debug_names reader. + +2024-01-18 Tom Tromey + + Refactor 'maint set dwarf synchronous' handling + The new .debug_names reader will reuse the background reading + infrastructure of the cooked index code. In order to share the + handling of 'maint set dwarf synchronous' -- and to avoid having to + export this global -- this patch refactors this to be handled directly + in dwarf2_initialize_objfile. + +2024-01-18 Nick Clifton + + Add note to translators not to translate z/Architecture + + Updated translations for various sub-directories + +2024-01-18 Tom de Vries + + [gdb/testsuite] Call ldd --version in gdb.testsuite/dump-system-info.exp + Once in a while I'm looking at the gdb.log of an entire testsuite run, and I'm + trying to establish what glibc version is used. Sometimes this is possible, + sometimes not. + + Make this easy by calling ldd --version in test-case + gdb.testsuite/dump-system-info.exp, which for instance on openSUSE Leap 15.4 + gives: + ... + $ ldd --version + ldd (GNU libc) 2.31 + ... + $ + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-18 Mike Frysinger + + sim: ppc: implement 128-bit register read/writes with sim-endian APIs + We have APIs in sim-endian for working with 128-bit values like this code + is already doing for 8/16/32/64-bit values. Switch over to that to make + it a bit simpler, and drop the WITH_ALTIVEC check. The code probably is + only used when altivec is enabled, but it doesn't add much to always + compile it in, and avoids #ifdef rot by not actually compiling it. + +2024-01-18 Mike Frysinger + + sim: ppc: switch register read/writes to union to avoid aliasing issues + This code creates a small buffer on the stack w/alloca, then proceeds to + write to it with a cast to a pointer type based on the register type, then + reads from it with a cast to a pointer type based on the register size. + gcc will flags only one of these lines as "maybe used uninitialized", but + it seems to track back to this memory abuse. + + Create a large union with all the possible types that this code will read + or write as, and then use those. It's a bit ugly, but is probably better + than using raw memcpy's everywhere. + +2024-01-18 GDB Administrator + + Automatic date update in version.in + +2024-01-17 Alan Modra + + PR30824 internal error with -z pack-relative-relocs + This corrects a counting problem, where prior to relocate_section relr + encoded relative relocs were allowed when it was known they were on + even boundaries, but relocate_section can only put relative relocs + (non-relr) on eight byte boundaries. + + PR 30824 + * elf64-ppc.c (RELR_ALIGN): Define, use throughout. + (maybe_relr): New function, use throughout. + +2024-01-17 H.J. Lu + + Update x86-64: Add -z mark-plt and -z nomark-plt + Pass --hash-style=both to ld for -z mark-plt tests to support linker + configured with --enable-default-hash-style=gnu. + + * testsuite/ld-x86-64/mark-plt-1b-x32.d: Pass --hash-style=both + to ld. + * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. + +2024-01-17 Andrew Burgess + + gdb/testsuite: handle long filenames in gdb.base/startup-with-shell.exp + I got a report of a failure from Linaro's CI testing for the test + gdb.base/startup-with-shell.exp. + + Looking at the log I see this: + + (gdb) PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: inferior started + print argv[1] + $1 = 0xfffed978 "/home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gdb-gdb.git~master/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: first argument expanded + + Notice that the value of $1 was truncated (indicated by the trailing + ellipses), and as a result it isn't going to match the expected output + pattern. + + Avoid this by adding a call to 'set print characters unlimited' which + allows GDB to print strings of any length. + + Approved-By: Tom de Vries + +2024-01-17 Tom Tromey + + Fix crash in struct-with-sig-2.exp with debug-names target board + When I run the struct-with-sig-2.exp test with the .debug_names-using + target board, I see a gdb crash. This happens because the reader + throws an exception without calling finalize_all_units. This causes + an assertion failure later because the number of CUs and TUs doesn't + match. + + The fix is to clear 'all_units' on failure. + + Approved-By: Tom de Vries + +2024-01-17 Nick Clifton + + Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling. + +2024-01-17 Xi Ruoyao + + LoongArch: Adapt R_LARCH_{PCALA,GOT,TLS_IE,TLS_DESC}64_* handling per psABI v2.30 + In LoongArch psABI v2.30, an offset (-8 for LO20 and -12 for HI12) + should be applied on PC for these reloc types to avoid wrong relocation + when the instruction sequence crosses a page boundary. + + The lld linker has already adapted the change. Make it for the bfd + linker too. + + Link: https://github.com/loongson/la-abi-specs/releases/v2.30 + Link: https://github.com/loongson-community/discussions/issues/17 + Link: https://github.com/llvm/llvm-project/pull/73387 + +2024-01-17 GDB Administrator + + Automatic date update in version.in + +2024-01-16 GDB Administrator + + Automatic date update in version.in + +2024-01-15 Simon Marchi + + gdb/testsuite: remove spurious $ in save_vars + I noticed that running the whole testsuite in serial mode (which means + all the .exp files are ran in the same TCL environment, one after the + other) with the native-extended-gdbserver board caused some weird + failures, for instance a lot of internal errors in the reverse tests, + like: + + continue^M + Continuing.^M + /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/native-extended-gdbserver/src/binutils-gdb/gdb/remot e.c:6922: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.reverse/break-precsave.exp: run to end of main (GDB internal error) + + This only happens after running gdb.multi/attach-while-running.exp. + That test does not restore GDBFLAGS properly when it's done, it leaves + `-ex \"maint set target-non-stop on\""` in there, which breaks some + subsequent tests. The problem is that this line: + + save_vars { $::GDBFLAGS } { + + should not use a `$` before the variable name. Passes the content of + `::GDBFLAGS` to save_vars, which is not what we want. We want to pass + the `::GDBFLAGS` string. Fix that. + + Change-Id: I5ad32c527795fd10d0d94020e4fd15cebaca3a77 + +2024-01-15 Tom Tromey + + Remove addrmap_fixed::set_entry + It occurred to me that there is no reason for addrmap_fixed::set_entry + to exist. This patch removes it and removes the abstract virtual + function from the base class. This then required a few minor changes + in the DWARF reader. I consider this a type-safety improvement. + + Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-01-15 Simon Marchi + + gdb: remove unnecessary braces + Change-Id: I5e96c0f38aa788462ab19a9becfe22030e913c2a + +2024-01-15 H.J. Lu + + x86-64: Skip SCFI tests for x32 targets + Since SCFI isn't supported on x32: + + Fatal error: SCFI is not supported for this ABI + + skip SCFI tests for x32 targets. + + PR gas/31245 + * testsuite/gas/scfi/x86_64/scfi-x86-64.exp: Skip for x32 + targets. + +2024-01-15 Nick Clifton + + Update HOWTO document after creating the 2.42 branch + + Change version to 2.42.50 and regenerate files + +2024-01-15 Mark Wielaard + + Regenerate two Makefile.in files to update Copyright headers + commit 1d506c26d9772bcd84e1a7b3a8c8c5bc602dbf61 + Update copyright year range in header of all files managed by GDB + updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in + also sim/Makefile.in was updated, but the Copyright hunks/years + were off. The first hunk comes from automake 1.15.1 header-vars.am + and so should have 2017 as last year, the second hunk does come from + sim/Makefile.am and so should have 2024 as last year. + + * gnulib/Makefile.in: Regenerate. + * sim/Makefile.in: Likewise. + +2024-01-15 Nick Clifton + + Add markers for 2.42 branch + + Update branch/release creation documentation + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Regenerate aarch64-*-2.c files + +2024-01-15 Victor Do Nascimento + Srinath Parvathaneni + + aarch64: rcpc3: Add FP load/store insns + Along with the relevant unit-tests, this adds the following rcpc3 + instructions: + + STL1 { .D }[], [] + LDAP1 { .D }[], [] + + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR
, [{, #}] + LDAPUR , [{, #}] + + STLUR , [{, #}] + STLUR , [{, #}] + STLUR , [{, #}] + STLUR
, [{, #}] + STLUR , [{, #}] + + with `#' taking on a signed 8-bit integer value in the range + [-256,255] and `index' the values 0 or 1. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add integer load/store insns + Along with the relevant unit tests and updates to the existing + regression tests, this adds support for the following novel rcpc3 + insns: + + LDIAPP , , [] + LDIAPP , , [], #8 + LDIAPP , , [] + LDIAPP , , [], #16 + + STILP , , [] + STILP , , [, #-8]! + STILP , , [] + STILP , , [, #-16]! + + LDAPR , [], #4 + LDAPR , [], #8 + + STLR , [, #-4]! + STLR , [, #-8]! + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define RCPC3_INSN macro + This patch adds the necessary macro for encoding FEAT_RCPC3-dependent + instructions in Binutils. + + aarch64: rcpc3: add support in general_constraint_met_p + Given the introduction of the new address operand types for rcpc3 + instructions, this patch adds the necessary logic to teach + `general_constraint_met_p` how to proper handle these. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: New RCPC3_ADDR operand types + The particular choices of address indexing, along with their encoding + for RCPC3 instructions lead to the requirement of a new set of operand + descriptions, along with the relevant inserter/extractor set. + + That is, for the integer load/stores, there is only a single valid + indexing offset quantity and offset mode is allowed - The value is + always equivalent to the amount of data read/stored by the + operation and the offset is post-indexed for Load-Acquire RCpc, and + pre-indexed with writeback for Store-Release insns. + + This indexing quantity/mode pair is selected by the setting of a + single bit in the instruction. To represent these insns, we add the + following operand types: + + - AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND + - AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB + + In the case of loads and stores involving SIMD/FP registers, the + optional offset is encoded as an 8-bit signed immediate, but neither + post-indexing or pre-indexing with writeback is available. This + created the need for an operand type similar to + AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should + not be checked. + + We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a + variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define address operand fields and inserter/extractors + Beyond the need to encode any registers involved in data transfer and + the address base register for load/stores, it is necessary to specify + the data register addressing mode and whether the address register is + to be pre/post-indexed, whereby loads may be post-indexed and stores + pre-indexed with write-back. + + The use of a single bit to specify both the indexing mode and indexing + value requires a novel function be written to accommodate this for + address operand insertion in assembly and another for extraction in + disassembly, along with the definition of two insn fields for use with + these instructions. + + This therefore defines the following functions: + + - aarch64_ins_rcpc3_addr_opt_offset + - aarch64_ins_rcpc3_addr_offset + - aarch64_ext_rcpc3_addr_opt_offset + - aarch64_ext_rcpc3_addr_offset + + It extends the `do_special_{encoding|decoding}' functions and defines + two rcpc3 instruction fields: + + - FLD_opc2 + - FLD_rcpc3_size + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Create implicit load/store size calc function + The allowed immediate offsets in integer rcpc3 load store instructions + are not encoded explicitly in the instruction itself, being rather + implicitly equivalent to the amount of data loaded/stored by the + instruction. + + This leads to the requirement that this quantity be calculated based on + the number of registers involved in the transfer, either as data + source or destination registers and their respective qualifiers. + + This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)' + implemented here, using a cumulative sum of qualifier sizes preceding + the address operand in the OPNDS operand list argument. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add +rcpc3 architectural feature support flag + Indicating the presence of the Armv8.2-a feature adding further + support for the Release Consistency Model, the `+rcpc3' architectural + extension flag is added to the list of possible `-march' options in + Binutils, together with the necessary macro for encoding rcpc3 + instructions. + +2024-01-15 Mark Wielaard + + bfd: riscv_maybe_function_sym check _bfd_elf_is_local_label_name + This fixes the ld "Handle no DWARF information" testcase. Which + currently fails on riscv because a local label name is assumed + to be the current function name. + + bfd/ChangeLog: + + * elfnn-riscv.c (riscv_maybe_function_sym): Also check + _bfd_elf_is_local_label_name. + +2024-01-15 Andrew Carlotti + + aarch64: Fix tlbi and tlbip instructions + There are some tlbi operations that don't have a corresponding tlbip operation, + but we were incorrectly using the same list for both. Add the missing tlbi + *nxs operations, and use the F_REG_128 flag to filter tlbi operations that + don't have a tlbip analogue. For increased clarity, I have also used a macro + to reduce duplication between the 'nxs' and non-'nxs' variants, and added a + test to verify that no invalid combinations are accepted. + + Additionally, fix two missing checks for AARCH64_OPND_SYSREG_TLBIP that were + preventing disassembly of tlbip instructions. + +2024-01-15 Andrew Carlotti + + aarch64: Refactor aarch64_sys_ins_reg_supported_p + Add an aarch64_feature_set field to aarch64_sys_ins_reg, and use this for + feature checks instead of testing against a list of operand codes. + +2024-01-15 Nick Clifton + + nm: Replace --with-symbol-versions with --without-symbol-versions in --help output + PR 31243 + nm: Fix --help output + +2024-01-15 Andrew Carlotti + + aarch64: Remove unused BTI feature bit + OK for master? + +2024-01-15 Nick Clifton + + Add generated source files and fix thinko in aarch64-asm.c + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 Contiguous load/store instructions. + Hi, + + This patch add support for SVE2.1 instructions ld1q, + ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + PATCH 5/6][Binutils] aarch64: Add SVE2.1 fmin and fmax instructions. + Hi, + + This patch add support for SVE2.1 instruction faddqv, + fmaxnmqv, fmaxqv, fminnmqv and fminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 dupq, eorqv and extq instructions. + Hi, + + This patch add support for SVE2.1 instruction dupq, eorqv and extq. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE2p1. + Hi, + + This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature + along with +sve2p1 optional flag to enabe this feature. + + Also support for following SVE2p1 instructions is added + addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME2p1 instructions. + Hi, + + This patch add support for FEAT_SME2p1 and "movaz" instructions + along with the optional flag +sme2p1. + + Following "movaz" instructions are add: + Move and zero two ZA tile slices to vector registers. + Move and zero four ZA tile slices to vector registers. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_B16B16 instructions. + Hi, + + This patch add support for SVE2.1 and SME2.1 non-widening BFloat16 + (FEAT_B16B16) instructions. + + Following instructions predicated, unpredicated and indexed + variants are added in this patch. + + bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm, + bfmla,bfmls,bfmul and bfsub. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Indu Bhagat + + gas/NEWS: announce the new SCFI command line option + +2024-01-15 Indu Bhagat + + gas: testsuite: add an x86 testsuite for SCFI + The testsuite for SCFI contains target-specific tests. + + When a test is executed with --scfi=experimental command line option, + the CFI annotations in the test .s files are skipped altogether by the + GAS for processing. The CFI directives in the input assembly files are, + however, validated by running the assembler one more time without + --scfi=experimental. + + Some testcases are used to highlight those asm constructs that the SCFI + machinery in GAS currently does not support: + + - Only System V AMD64 ABI is supported for now. Using either --32 or + --x32 with SCFI results in hard error. + See scfi-unsupported-1.s. + + - Untraceable stack-pointer manipulation in function epilougue and prologue. + See scfi-unsupported-2.s. + + - Using Dynamically Realigned Arguement Pointer (DRAP) register to + realign the stack. For SCFI, the CFA must be only REG_SP or REG_FP + based. See scfi-unsupported-drap-1.s + + Some testcases are used to highlight some diagnostics that the SCFI + machinery in GAS currently issues, with an intent to help user correct + inadvertent errors in their hand-written asm. An error is issued when + GAS finds that input asm is not amenable to correct CFI synthesis. + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + + In case of (#2) and (#3), SCFI generation is skipped for the respective + function. Above is a subset of the warnings/errors implemented in the + code. + + gas/testsuite/: + * gas/scfi/README: New test. + * gas/scfi/x86_64/ginsn-add-1.l: New test. + * gas/scfi/x86_64/ginsn-add-1.s: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: New test. + * gas/scfi/x86_64/ginsn-pop-1.l: New test. + * gas/scfi/x86_64/ginsn-pop-1.s: New test. + * gas/scfi/x86_64/ginsn-push-1.l: New test. + * gas/scfi/x86_64/ginsn-push-1.s: New test. + * gas/scfi/x86_64/scfi-add-1.d: New test. + * gas/scfi/x86_64/scfi-add-1.l: New test. + * gas/scfi/x86_64/scfi-add-1.s: New test. + * gas/scfi/x86_64/scfi-add-2.d: New test. + * gas/scfi/x86_64/scfi-add-2.l: New test. + * gas/scfi/x86_64/scfi-add-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.s: New test. + * gas/scfi/x86_64/scfi-cfg-1.d: New test. + * gas/scfi/x86_64/scfi-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-cfg-2.d: New test. + * gas/scfi/x86_64/scfi-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.s: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.s: New test. + * gas/scfi/x86_64/scfi-cofi-1.d: New test. + * gas/scfi/x86_64/scfi-cofi-1.l: New test. + * gas/scfi/x86_64/scfi-cofi-1.s: New test. + * gas/scfi/x86_64/scfi-diag-1.l: New test. + * gas/scfi/x86_64/scfi-diag-1.s: New test. + * gas/scfi/x86_64/scfi-diag-2.l: New test. + * gas/scfi/x86_64/scfi-diag-2.s: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.l: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.s: New test. + * gas/scfi/x86_64/scfi-enter-1.d: New test. + * gas/scfi/x86_64/scfi-enter-1.l: New test. + * gas/scfi/x86_64/scfi-enter-1.s: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.l: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-5.s: New test. + * gas/scfi/x86_64/scfi-lea-1.d: New test. + * gas/scfi/x86_64/scfi-lea-1.l: New test. + * gas/scfi/x86_64/scfi-lea-1.s: New test. + * gas/scfi/x86_64/scfi-leave-1.d: New test. + * gas/scfi/x86_64/scfi-leave-1.l: New test. + * gas/scfi/x86_64/scfi-leave-1.s: New test. + * gas/scfi/x86_64/scfi-pushq-1.d: New test. + * gas/scfi/x86_64/scfi-pushq-1.l: New test. + * gas/scfi/x86_64/scfi-pushq-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-1.d: New test. + * gas/scfi/x86_64/scfi-pushsection-1.l: New test. + * gas/scfi/x86_64/scfi-pushsection-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-2.d: New test. + * gas/scfi/x86_64/scfi-pushsection-2.l: New test. + * gas/scfi/x86_64/scfi-pushsection-2.s: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.d: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.l: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.s: New test. + * gas/scfi/x86_64/scfi-simple-1.d: New test. + * gas/scfi/x86_64/scfi-simple-1.l: New test. + * gas/scfi/x86_64/scfi-simple-1.s: New test. + * gas/scfi/x86_64/scfi-simple-2.d: New test. + * gas/scfi/x86_64/scfi-simple-2.l: New test. + * gas/scfi/x86_64/scfi-simple-2.s: New test. + * gas/scfi/x86_64/scfi-sub-1.d: New test. + * gas/scfi/x86_64/scfi-sub-1.l: New test. + * gas/scfi/x86_64/scfi-sub-1.s: New test. + * gas/scfi/x86_64/scfi-sub-2.d: New test. + * gas/scfi/x86_64/scfi-sub-2.l: New test. + * gas/scfi/x86_64/scfi-sub-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-3.l: New test. + * gas/scfi/x86_64/scfi-unsupported-3.s: New test. + * gas/scfi/x86_64/scfi-unsupported-4.l: New test. + * gas/scfi/x86_64/scfi-unsupported-4.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: New file. + +2024-01-15 Indu Bhagat + + opcodes: i386-reg.tbl: Add a comment to reflect dependency on ordering + The ginsn representation keeps the DWARF register number of the + operands. The API ginsn_dw2_regnum relies on the the relative ordering + of these register entries in the table. Add a comment to make it clear. + + opcodes/ + * i386-reg.tbl: Add a comment. + +2024-01-15 Indu Bhagat + + gas: doc: update documentation for the new listing option + Add a new listing option, -i, to emit ginsn in the listing output. We + may also emit other SCFI information if necessary in the future. + + ginsn are most useful when seen alongside the assembly instructions. + Hence, they are emitted when the user includes the assembly instructions + in the listing output, i.e., "-ali=FILE". + + gas/doc/: + * as.texi: Add documentation for the new listing option, -i. + +2024-01-15 Indu Bhagat + + gas: x86: synthesize CFI for hand-written asm + This patch adds support in GAS to create generic GAS instructions + (a.k.a., the ginsn) for the x86 backend (AMD64 ABI only at this time). + Using this ginsn infrastructure, GAS can then synthesize CFI for + hand-written asm for x86_64. + + A ginsn is a target-independent representation of the machine + instructions. One machine instruction may need one or more ginsn. + + This patch also adds skeleton support for printing ginsn in the listing + output for debugging purposes. + + Since the current use-case of ginsn is to synthesize CFI, the x86 target + needs to generate ginsns necessary for the following machine + instructions only: + + - All change of flow instructions, including all conditional and + unconditional branches, call and return from functions. + - All register saves and unsaves to the stack. + - All instructions affecting the two registers that could potentially + be used as the base register for CFA tracking. For SCFI, the base + register for CFA tracking is limited to REG_SP and REG_FP only for + now. + + The representation of ginsn is kept simple: + + - GAS instruction has GINSN_NUM_SRC_OPNDS (defined to be 2 at this time) + number of source operands and one destination operand at this time. + - GAS instruction uses DWARF register numbers in its representation and + does not track register size. + - GAS instructions carry location information (file name and line + number). + - GAS instructions are ID's with a natural number in order of their + addtion to the list. This can be used as a proxy for the static + program order of the corresponding machine instructions. + + Note that, GAS instruction (ginsn) format does not support + GINSN_TYPE_PUSH and GINSN_TYPE_POP. Some architectures, like aarch64, + do not have push and pop instructions, but rather STP/LDP/STR/LDR etc. + instructions. Further these instructions have a variety of addressing + modes, like offset, pre-indexing and post-indexing etc. Among other + things, one of differences in these addressing modes is _when_ the addr + register is updated with the result of the address calculation: before + or after the memory operation. To best support such needs, the generic + instructions like GINSN_TYPE_LOAD, GINSN_TYPE_STORE together with + GINSN_TYPE_ADD, and GINSN_TYPE_SUB may be used. + + The functionality provided in ginsn.c and scfi.c is compiled in when a + target defines TARGET_USE_SCFI and TARGET_USE_GINSN. This can be + revisited later when there are other use-cases of creating ginsn's in + GAS, apart from the current use-case of synthesizing CFI for + hand-written asm. + + Support is added only for System V AMD64 ABI for ELF at this time. If + the user enables SCFI with --32, GAS issues an error: + + "Fatal error: SCFI is not supported for this ABI" + + For synthesizing (DWARF) CFI, the SCFI machinery requires the programmer + to adhere to some pre-requisites for their asm: + - Hand-written asm block must begin with a .type foo, @function + It is highly recommended to, additionally, also ensure that: + - Hand-written asm block ends with a .size foo, .-foo + + The SCFI machinery encodes some rules which align with the standard + calling convention specified by the ABI. Apart from the rules, the SCFI + machinery employs some heuristics. For example: + - The base register for CFA tracking may be either REG_SP or REG_FP. + - If the base register for CFA tracking is REG_SP, the precise amount of + stack usage (and hence, the value of REG_SP) must be known at all times. + - If using dynamic stack allocation, the function must switch to + FP-based CFA. This means using instructions like the following (in + AMD64) in prologue: + pushq %rbp + movq %rsp, %rbp + and analogous instructions in epilogue. + - Save and Restore of callee-saved registers must be symmetrical. + However, the SCFI machinery at this time only warns if any such + asymmetry is seen. + + These heuristics/rules are architecture-independent and are meant to + employed for all architectures/ABIs using SCFI in the future. + + gas/ + * Makefile.am: Add new files. + * Makefile.in: Regenerated. + * as.c (defined): Handle documentation and listing option for + ginsns and SCFI. + * config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end. + (obj_elf_type): Invoke ginsn_data_begin. + * config/tc-i386.c (x86_scfi_callee_saved_p): New function. + (ginsn_prefix_66H_p): Likewise. + (ginsn_dw2_regnum): Likewise. + (x86_ginsn_addsub_reg_mem): Likewise. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Likewise. + (x86_ginsn_move): Likewise. + (x86_ginsn_lea): Likewise. + (x86_ginsn_jump): Likewise. + (x86_ginsn_jump_cond): Likewise. + (x86_ginsn_enter): Likewise. + (x86_ginsn_safe_to_skip): Likewise. + (x86_ginsn_unhandled): Likewise. + (x86_ginsn_new): New functionality to generate ginsns. + (md_assemble): Invoke x86_ginsn_new. + (s_insn): Likewise. + (i386_target_format): Add hard error for usage of SCFI with non AMD64 ABIs. + * config/tc-i386.h (TARGET_USE_GINSN): New definition. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): Likewise. + (REG_FP): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (x86_scfi_callee_saved_p): Likewise. + * gas/listing.h (LISTING_GINSN_SCFI): New define for ginsn and + SCFI. + * gas/read.c (read_a_source_file): Close SCFI processing at end + of file read. + * gas/scfidw2gen.c (scfi_process_cfi_label): Add implementation. + (scfi_process_cfi_signal_frame): Likewise. + * subsegs.h (struct frch_ginsn_data): New forward declaration. + (struct frchain): New member for ginsn data. + * gas/subsegs.c (subseg_set_rest): Initialize the new member. + * symbols.c (colon): Invoke ginsn_frob_label to convey + user-defined labels to ginsn infrastructure. + * ginsn.c: New file. + * ginsn.h: New file. + * scfi.c: New file. + * scfi.h: New file. + +2024-01-15 Indu Bhagat + + opcodes: x86: new marker for insns that implicitly update stack pointer + Some x86 instructions affect the stack pointer implicitly. Add a new + operand constraint to reflect this. This will be useful for SCFI + implmentation to ensure its correctness. + + Mark all push, pop, call, ret, enter, leave, INT, iret instructions. + + opcodes/ + * i386-gen.c: Update opcode_modifiers. + * i386-opc.h: Add a new constraint. + * i386-opc.tbl: Update the affected instructions. + * i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + opcodes: gas: x86: define and use Rex2 as attribute not constraint + Rex2 is currently an operand constraint. For the upcoming SCFI + implementation in GAS, we need to identify operations which implicitly + update the stack pointer. An operand constraint enumerator for implicit + stack op seems more appropriate than an attribute. However, two opcodes + currently necessitate both Rex2 and an implicit stack op marker; this + prompts revisiting the current representations a bit. + + Make Rex2 a standalone attribute, so that later a new operand constraint + may be added for IMPLICIT_STACK_OP. + + ChangeLog: + * gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check. + * opcodes/i386-gen.c: Add a new BITFIELD for Rex2. + * opcodes/i386-opc.h (REX2_REQUIRED): Remove. + * opcodes/i386-opc.tbl: Remove Rex2 operand constraint. + * opcodes/i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + gas: scfidw2gen: new functionality to prepare for SCFI + Define a new set of handlers for CFI directives for the purpose of SCFI. + The SCFI machinery ignores many of the user-specified CFI direcives when + SCFI is in effect. A warning ("Warning: SCFI ignores most + user-specified CFI directives") is issued once per file. The following + CFI directives, however, are not ignored: + - .cfi_sections + - .cfi_label + - .cfi_signal_frame + + gas/ + * Makefile.am: Add new files to GAS_CFILES and HFILES. + * Makefile.in: Likewise. + * gas/read.c (scfi_pop_insert): New define. + (pobegin): Use the SCFI handlers. + * scfidw2gen.c: New file. + * scfidw2gen.h: New file. + +2024-01-15 Indu Bhagat + + gas: add new command line option --scfi=experimental + When the command line option --scfi=experimenta is passed to the GNU + assembler, it will synthesize DWARF call frame information (CFI) for the + input assembly. + + The option --scfi=experimental will also ignore most of the existing + .cfi_* directives, if already contained in the provided input file. + Only the following CFI directives will not be ignored: + - .cfi_sections, + - .cfi_label, + - .cfi_signal_frame + + To use SCFI, a target will need to: + - define TARGET_USE_SCFI and TARGET_USE_GINSN, and other necessary + definitions, + - provide means to help GAS understand the target specific instruction + semantics by creating ginsns. + + The upcoming support for SCFI is inteded to be experimental, hence the + option --scfi=experimental. The --scfi= may see more options like + --scfi=[all,none] added in future, once the SCFI support in GAS is + mature and robust. The offering may also see for example, an + --scfi=inline option for dealing with inline asm may be added in the + future. In --scfi=inline option, the GNU assembler may consume (and not + ignore) the compiler generated CFI for the code surrounding the inline + asm. + + Also document the option. + + gas/ + * as.c (show_usage): Add support for --scfi=experimental. + (parse_args): Likewise. + * as.h (enum synth_cfi_type): Define new type. + * doc/as.texi: Document the new option. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: externalize the all_cfi_sections + gas/ + * dw2gencfi.h: Declare all_cfi_sections as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen + scfidw2gen will use this for processing the .cfi_sections directive. + + gas/ + * dw2gencfi.c (dot_cfi_sections): Not static anymore. + * dw2gencfi.h (dot_cfi_sections): Mark as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: move some tc_* defines to the header file + Move the following three defines to the header file, so the SCFI + machinery can use them: + - tc_cfi_frame_initial_instructions + - tc_cfi_startproc + - tc_cfi_endproc + + gas/ + * dw2gencfi.c: Move from ... + * dw2gencfi.h: ... to here. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose a new cfi_set_last_fde API + gas/ + * dw2gencfi.c (cfi_set_last_fde): New definition. + (dot_cfi_endproc): Use it. + (dot_cfi_fde_data): Likewise. + (dot_cfi_inline_lsda): Likewise. + * dw2gencfi.h (struct fde_entry): New declaration. + (cfi_set_last_fde): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: use all_cfi_sections instead of cfi_sections + The code in dw2gencfi.c was checking variable cfi_sections and + all_cfi_sections seemingly randomly. Accessing all_cfi_sections seems + to the correct variable to access. + + The data in cfi_sections has already been propagated to all_cfi_sections + once cfi_dot_startproc () has been called. + + gas/ + * dw2gencfi.c (dot_cfi_startproc): Use all_cfi_sections + instead. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections + cfi_sections_set is best set to true in cfi_dot_startproc (). Setting + it to true again in other APIs (dot_cfi_endproc, dot_cfi_fde_data, and + cfi_finish) is unnecessary. Also, move setting the global var + all_cfi_sections into cfi_set_sections (). + + gas/ + * dw2gencfi.c (cfi_set_sections): Set cfi_sections_set and + cfi_sections here. + (dot_cfi_startproc): Remove unnecessarily setting + cfi_set_sections to true. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + (cfi_finish): Likewise. + +2024-01-15 GDB Administrator + + Automatic date update in version.in + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.mi/mi-dprintf.exp with read1 + When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into: + ... + (gdb) ^M + PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop + -data-evaluate-expression stderr^M + ^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M + (gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check + ... + + The problem is in proc mi_gdb_is_stderr_available: + ... + proc mi_gdb_is_stderr_available {} { + set has_stderr_symbol false + gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" { + -re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" { + } + -re "$::mi_gdb_prompt$" { + set has_stderr_symbol true + } + } + ... + which uses a gdb_test_multiple that is supposed to use the mi prompt, but + doesn't use -prompt to indicate this. Consequently, the default patterns use + the regular gdb prompt, which trigger earlier than the two custom patterns + which use "$::mi_gdb_prompt$". + + Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments. + + While we're at it, make the gdb_test_multiple call a bit more readable by + using variables, and by using -wrap. + + Tested on x86_64-linux, with: + - gcc and clang (to trigger both the has_stderr_symbol true and false cases) + - make check and make check-read1. + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/namespace.exp with read1 + With check-read1 we run into: + ... + (gdb) break DNE>::DNE^M + Function "DNE>::DNE" not defined.^M + Make breakpoint pending on future shared library load? (y or [n]) y^M + Breakpoint 9 (DNE>::DNE) pending.^M + n^M + (gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt) + n^M + ... + + The question is supposed to be handled by the question and response arguments + to this gdb_test call: + ... + gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \ + "Make breakpoint pending on future shared library load?.*" "y" + ... + but both this and the builtin handling in gdb_test_multiple triggers. + + The cause of this is that the question argument regexp is incomplete. + + Fix this by making sure that the entire question is matched in the regexp: + ... + set yn_re [string_to_regexp {(y or [n])}] + ... + "Make breakpoint pending on future shared library load\\? $yn_re " "Y" + ... + + Tested on x86_64-linux. + +2024-01-14 GDB Administrator + + Automatic date update in version.in + +2024-01-13 Yang Liu + + gdb: RISC-V: Refine lr/sc sequence support + Per RISC-V spec, the lr/sc sequence can consist of up to 16 instructions, and we + cannot insert breakpoints in the middle of this sequence. Before this, we only + detected a specific pattern (the most common one). This patch improves this part + and now supports more complex pattern detection. + + Approved-By: Andrew Burgess + Reviewed-by: Palmer Dabbelt + +2024-01-13 Yang Liu + + Add myself to gdb/MAINTAINERS + +2024-01-13 Vladimir Mezentsev + + gprofng: 30889 can't compile without large file support + gprofng/ChangeLog + 2024-01-12 Vladimir Mezentsev + + PR 30889 + * src/util.h (O_LARGEFILE): Define to 0, if not defined. + +2024-01-13 GDB Administrator + + Automatic date update in version.in + +2024-01-12 Vladimir Mezentsev + + gprofng: fix 3 bugzillas against gp-display-html + Fix two cases where gp-display-html terminates prematurely because the + input format is not recognized. This problem occurs in the function + overview and caller-callee parts of the code. + The fix consists of new regular expressions and a different approach + in handling the input from gp-display-text. + Also fix a performance problem in the caller-callee part that has a + noticeable impact on the performance for large applications. + + gprofng/ChangeLog + 2024-01-10 Ruud van der Pas + + PR gprofng/30438 + PR gprofng/30439 + PR gprofng/30942 + * gp-display-html/gp-display-html.in: fixes the issues. + +2024-01-12 Dimitar Dimitrov + + sim: Fix compile errors + The following change broke simulator testsuite with host GCC 13: + commit 435ad222b3de93fa647fba7221eece36b1b395eb + sim: warnings: compile build tools with -Werror too + + Host GCC13 complains about missing function prototypes: + + binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes] + 26 | gen_struct (void) + | ^~~~~~~~~~ + + Fix by making the functions static, which instructs the compiler that + there is no need for a prototype. + +2024-01-12 David Faust + + bpf: fix relocation addend incorrect symbol value + Relocations installed by the BPF ELF backend were sometimes incorrectly + adding the symbol value to the relocation entry addend, when the correct + relocation value was already stored in the addend. This could lead to a + relocation effectively adding the symbol value twice. + + Fix that by making bpf_elf_generic_reloc () more similar to the flow of + bfd_install_relocation in the case where howto->install_addend is set, + which is how it ought to behave. + + bfd/ + * bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64) + (R_BPF_64_NODYLD32): Set partial_inplace to true. + * elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value + of the symbol when installing relocation. Copy some additional + logic from bfd_elf_generic_reloc. + + gas/ + * testsuite/gas/bpf/bpf.exp: Run new test. + * testsuite/gas/bpf/elf-relo-1.d: New. + * testsuite/gas/bpf/elf-relo-1.s: New. + +2024-01-12 Andrew Burgess + + gdb/testsuite: fix failure in gdb.python/py-inferior.exp + After this commit: + + commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72 + Date: Thu Jan 4 10:01:24 2024 +0000 + + gdb/python: add gdb.InferiorThread.__repr__() method + + failures were reported for gdb.python/py-inferior.exp. + + The test grabs a gdb.InferiorThread object representing an inferior + thread, and then, later in the test, expects this Python object to + become invalid when the inferior thread has exited. + + The gdb.InferiorThread object was obtained from the list returned by + calling gdb.Inferior.threads(). + + The mistake I made in the original commit was to assume that the order + of the threads returned from gdb.Inferior.threads() somehow reflected + the thread creation order. Specifically, I was expecting the main + thread to be first in the list, and "other" threads to appear ... not + first. + + However, the gdb.Inferior.threads() function creates a list and + populates it from a map. The order of the threads in the returned + list has no obvious relationship to the thread creation order, and can + vary from host to host. + + On my machine the ordering was as I expected, so the test passed for + me. For others the ordering was not as expected, and it just happened + that we ended up recording the gdb.InferiorThread for the main thread. + + As the main thread doesn't exit (until the test is over), the + gdb.InferiorThread object never became invalid, and the test failed. + + Fixed in this commit by taking more care to correctly find a non-main + thread. I do this by recording the main thread early on (when there + is only one inferior thread), and then finding any thread that is not + this main thread. + + Then, once all of the secondary threads have exited, I know that the + second InferiorThread object I found should now be invalid. + + The test still passes for me, and I believe this should fix the issue + for everyone else too. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238 + +2024-01-12 Andrew Burgess + + Update copyright year range in header of all files managed by GDB + This commit is the result of the following actions: + + - Running gdb/copyright.py to update all of the copyright headers to + include 2024, + + - Manually updating a few files the copyright.py script told me to + update, these files had copyright headers embedded within the + file, + + - Regenerating gdbsupport/Makefile.in to refresh it's copyright + date, + + - Using grep to find other files that still mentioned 2023. If + these files were updated last year from 2022 to 2023 then I've + updated them this year to 2024. + + I'm sure I've probably missed some dates. Feel free to fix them up as + you spot them. + +2024-01-12 Andrew Carlotti + + aarch64: Remove unused code + Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was + already dead when it was first added. + + aarch64: Make FEAT_ASMv8p2 instruction aliases always available + There's no reason to disallow the aliases when the aliased instructions are + always available. The new behaviour matches existing LLVM behaviour. + + aarch64: Add +xs flag for existing instructions + Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of + "+d128". This is an incremental improvement; there are still some FEAT_XS tlbi + variants that are gated incorrectly or missing entirely. + + aarch64: Add +wfxt flag for existing instructions + + aarch64: Add +rcpc2 flag for existing instructions + + aarch64: Add +flagm2 flag for existing instructions + + aarch64: Add +frintts flag for existing instructions + + aarch64: Add +jscvt flag for existing fjcvtzs instruction + + aarch64: Fix option parsing to disallow prefixes of valid options + Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility + with Clang. + + aarch64: Add +fcma alias for +compnum + + aarch64: Fix +lse feature flag dependency + +2024-01-12 Andrew Burgess + + gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs + This commit updates the Python example code in the gdb.Progspace and + gdb.Objfile sections of the docs. Changes made: + + 1. Use @value{GDBP} for the GDB prompt rather than + hard-coding (gdB), + + 2. Use @group...@end group to split the example code into + unbreakable chunks, and + + 3. Add parenthesis to the Python print() calls in the examples. In + Python 2 it was OK to drop the parenthesis, but now GDB is Python 3 + only, example code should include the parenthesis. + + Approved-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/doc: add some notes on selecting suitable attribute names + In previous commits I've added Object.__dict__ support to gdb.Inferior + and gdb.InferiorThread, this is similar to the existing support for + gdb.Objfile and gdb.Progspace. + + This commit extends the documentation to offer the user some guidance + on selecting good names for their custom attributes so they + can (hopefully) avoid conflicting with any future attributes that GDB + might add. + + The rules I've proposed are: + + 1. Don't start user attributes with a lower case letter, all the + current GDB attributes start with a lower case letter, and I suspect + all future attributes would also start with a lower case letter, and + + 2. Don't start user attributes with a double underscore, this risks + conflicting with Python built in attributes (e.g. __dict__) - though + clearly the user would need to start and end with a double + underscore, but it seemed easier just to say no double underscores. + + I'm doing this as a separate commit as I've updated the docs for the + existing gdb.Objfile and gdb.Progspace so they all reference a single + paragraph on selecting attribute names. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.InferiorThread.__dict__ attribute + The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python + types already have a __dict__ attribute, which allows users to create + user defined attributes within the objects. This is useful if the + user wants to cache information within an object. + + This commit adds the same functionality to the gdb.InferiorThread + type. + + After this commit there is a new gdb.InferiorThread.__dict__ + attribute, which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> t = gdb.selected_thread() + >>> t._user_attribute = 123 + >>> t._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.Inferior.__dict__ attribute + The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have + a __dict__ attribute, which allows users to create user defined + attributes within the objects. This is useful if the user wants to + cache information within an object. + + This commit adds the same functionality to the gdb.Inferior type. + + After this commit there is a new gdb.Inferior.__dict__ attribute, + which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> i = gdb.selected_inferior() + >>> i._user_attribute = 123 + >>> i._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: remove users ability to create gdb.Progspace objects + I noticed that it is possible for the user to create a new + gdb.Progspace object, like this: + + (gdb) pi + >>> p = gdb.Progspace() + >>> p + + >>> p.is_valid() + False + + As the new gdb.Progspace object is not associated with an actual C++ + program_space object within GDB core, then the new gdb.Progspace is + created invalid, and there is no way in which the new object can ever + become valid. + + Nor do I believe there's anywhere in the Python API where it makes + sense to consume an invalid gdb.Progspace created in this way, for + example, the gdb.Progspace could be passed as the locus to + register_type_printer, but all that would happen is that the + registered printer would never be used. + + In this commit I propose to remove the ability to create new + gdb.Progspace objects. Attempting to do so now gives an error, like + this: + + (gdb) pi + >>> gdb.Progspace() + Traceback (most recent call last): + File "", line 1, in + TypeError: cannot create 'gdb.Progspace' instances + + Of course, there is a small risk here that some existing user code + might break ... but if that happens I don't believe the user code can + have been doing anything useful, so I see this as a small risk. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.Frame.__repr__() method + Add a gdb.Frame.__repr__() method. Before this patch we would see + output like this: + + (gdb) pi + >>> gdb.selected_frame() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_frame() + + + More verbose, but, I hope, more useful. + + If the gdb.Frame becomes invalid, then we will see: + + (gdb) pi + >>> invalid_frame_variable + + + which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.InferiorThread.__repr__() method + Add a gdb.InferiorThread.__repr__() method. Before this patch we + would see output like this: + + (gdb) pi + >>> gdb.selected_thread() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_thread() + + + More verbose, but, I hope, more useful. + + If the gdb.InferiorThread becomes invalid, then we will see: + + (gdb) pi + >>> invalid_thread_variable + + + Which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: hoist common invalid object repr code into py-utils.c + Many object types now have a __repr__() function implementation. A + common pattern is that, if an object is invalid, we print its + representation as: . + + I thought it might be a good idea to move the formatting of this + specific representation into a utility function, and then update all + of our existing code to call the new function. + + The only place where I haven't made use of the new function is in + unwind_infopy_repr, where we currently return a different string. + This case is a little different as the UnwindInfo is invalid because + it references a frame, and it is the frame itself which is invalid. + That said, I think it would be fine to switch to using the standard + format; if the UnwindInfo references an invalid frame, then the + UnwindInfo is itself invalid. But changing this would be an actual + change in behaviour, while all the other changes in this commit are + just refactoring. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb: add trailing '/' when using 'complete' with directory names + This patch contains work pulled from this previously proposed patch: + + https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/ + + But has been modified by me. Credit for the original idea and + implementation goes to Lancelot, any bugs in this new iteration belong + to me. + + Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is + empty other than the `foo' sub-directory, then currently within GDB, + if I type: + + (gdb) file /tmp/f + + and then hit TAB, GDB completes this to: + + (gdb) file /tmp/foo/ + + notice that not only did GDB fill in the whole of `foo', but GDB also + added a trailing '/' character. This is done within readline when the + path that was just completed is a directory. However, if I instead + do: + + (gdb) complete file /tmp/f + file /tmp/foo + + I now see the completed directory name, but the trailing '/' is + missing. The reason is that, in this case, the completions are not + offered via readline, but are handled entirely within GDB, and so + readline never gets the chance to add the trailing '/' character. + + The above patch added filename option support to GDB, which included + completion of the filename options. This initially suffered from the + same problem that I've outlined above, but the above patch proposed a + solution to this problem, but this solution only applied to filename + options (which have still not been added to GDB), and was mixed in + with the complete filename options support. + + This patch pulls out just the fix for the trailing "/" problem, and + applies it to GDB's general filename completion. This patch does not + add filename options to GDB, that can always be done later, but I + think this small part is itself a useful fix. + + One of the biggest changes I made in this version is that I got rid of + the set_from_readline member function, instead, I now pass the value + of m_from_readline into the completion_tracker constructor. + + I then moved the addition of the trailing '/' into filename_completer + so that it is applied in the general filename completion case. I also + added a call to gdb_tilde_expand which was missing from the original + patch, I haven't tested, but I suspect that this meant that the + original patch would not add the trailing '/' if the user entered a + path starting with a tilde character. + + When writing the test for this patch I ran into two problems. + + The first was that the procedures in lib/completion-support.exp relied + on the command being completed for the test name. This is fine for + many commands, but not when completing a filename, if we use the + command in this case the test name will (potentially) include the name + of the directory in which the test is being run, which means we can't + compare results between two runs of GDB from different directories. + + So in this commit I've gone through completion-support.exp and added a + new (optional) testname argument to many of the procedures, this + allows me to give a unique test name, that doesn't include the path + for my new tests. + + The second issue was in the procedure make_tab_completion_list_re, + this builds the completion list which is displayed after a double tab + when there are multiple possible completions. + + The procedure added the regexp ' +' after each completion, and then + added another ' +' at the very end of the expected output. So, if we + expected to match the name of two functions 'f1' and 'f2' the + generated regexp would be: 'f1 +f2 + +'. This would match just fine, + the actual output would be: 'f1 f2 ', notice that we get two spaces + after each function name. + + However, if we complete two directory names 'd1' and 'd2' then the + output will be 'd1/ d2/ '. Notice that now we only have a single + space between each match, however, we do get the '/' added instead. + + What happens is that when presenting the matches, readline always adds + the appropriate trailing character; if we performed tab completion of + 'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with + a trailing space added. However, if we complete 'file d1' then we get + 'file d1/'. Then readline is adding a single space after each + possible match, including the last one, which accounts for the + trailing space character. + + To resolve this I've simply remove the addition o the second ' +' + within make_tab_completion_list_re, for the function completion + example I gave above the expected pattern is now 'f1 +f2 +', which for + the directory case we expect 'd1/ +d2/ +', both of which work just + fine. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265 + Co-Authored-By: Lancelot SIX + Approved-By: Tom Tromey + Reviewed-By: John Baldwin + +2024-01-12 Andrew Burgess + + gdb/python: New InferiorThread.ptid_string attribute + This commit adds a new InferiorThread.ptid_string attribute. This + read-only attribute contains the string returned by target_pid_to_str, + which actually converts a ptid (not pid) to a string. + + This is the string that appears (at least in part) in the output of + 'info threads' in the 'Target Id' column, but also in the thread + exited message that GDB prints. + + Having access to this string from Python is useful for allowing + extensions identify threads in a similar way to how GDB core would + identify the thread. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Tom de Vries + + [gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp + In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is + missing here after the unsupported: + ... + if { ![is_x86_64_m64_target] } { + unsupported "unsupported architecture" + } + ... + and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3 + FAILs. + + Fix this by simply using require: + ... + require is_x86_64_m64_target + ... + + Tested on x86_64-linux and aarch64-linux. + +2024-01-12 Indu Bhagat + + gas: sframe: warn when skipping SFrame FDE generation + Fix PR gas/31213. + + gas/ + PR gas/31213 + * gen-sframe.c (sframe_do_cfi_insn): Add new warning. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Test the new warning as well. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-01-12 mengqinggang + + LoongArch: Fix relaxation overflow caused by section alignment + When deleting NOP instructions addend by .align at second pass, this may cause + the PC decrease but the symbol address to remain unchanged due to section + alignment. + + To solve this question, we subtract a maximux alignment of all sections like + RISC-V. + +2024-01-12 Cui, Lili + + x86: Fix indentation and use true/false instead of 1/0 + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Fix indentation. + (check_EgprOperands): Use true/false instead of 1/0. + +2024-01-12 GDB Administrator + + Automatic date update in version.in + +2024-01-11 Simon Marchi + + gdb: fix frame passed to gdbarch_value_to_register in value_assign + Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum") + introduced an unexpected change in value_assign. It replaced + `get_prev_frame_always (next_frame)` with `next_frame`in the call to + gdbarch_value_to_register. + + This is the result of a merge error, since I previously had a patch to + change gdbarch_value_to_register to take the next frame, and later + decided to drop it. Revert that change. + + Add a test based on the DWARF assembler to expose the problem and test + the fix. I also tested on ppc64le to make sure the problem reported in + PR 31231 was fixed. + + Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le + On ppc64le-linux, I run into: + ... + (gdb) bt^M + #0 0x00000000100006dc in foobar (J=2)^M + #1 0x000000001000070c in prog ()^M + (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo + ... + + The test-case attemps to emulate additional entry points of a function, with + function bar having entry points foo and foobar: + ... + (gdb) p bar + $1 = {void (int, int)} 0x1000064c + (gdb) p foo + $2 = {void (int, int)} 0x10000698 + (gdb) p foobar + $3 = {void (int)} 0x100006d0 + ... + + However, when setting a breakpoint on the entry point foo: + ... + (gdb) b foo + Breakpoint 1 at 0x100006dc + ... + it ends up in foobar instead of in foo, due to prologue skipping, and + consequently the backtrace show foobar instead foo. + + The problem is that the test-case does not emulate an actual prologue at each + entry point. + + Fix this by disabling the prologue skipping when setting a breakpoint, using + "break *foo". + + Tested on ppc64le-linux and x86_64-linux. + + Tested-By: Guinevere Larsen + Approved-By: Ulrich Weigand + + PR testsuite/31232 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Extend gdb.base/kill-during-detach.exp + I ran into the following FAIL: + ... + (gdb) python kill_and_detach()^M + Traceback (most recent call last):^M + File "", line 1, in ^M + File "", line 7, in kill_and_detach^M + gdb.error: Selected thread is running.^M + Error while executing Python code.^M + (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \ + python kill_and_detach() + ... + + The FAIL happens as follows: + - gdb is debugging a process A + - a checkpoint is created, in other words, fork is called in the inferior, + after which we have: + - checkpoint 0 (the fork parent, process A), and + - checkpoint 1 (the fork child, process B). + - during checkpoint creation, lseek is called in the inferior (process A) for + all file descriptors, and it returns != -1 for at least one file descriptor. + - the process A continues in the background + - gdb detaches, from process A + - gdb switches to process B, in other words, it restarts checkpoint 1 + - while restarting checkpoint 1, gdb tries to call lseek in the inferior + (process B), but this fails because gdb incorrectly thinks that inferior B + is running. + + This happens because linux_nat_switch_fork patches the pid of process B into + the current inferior and current thread which where originally representing + process A. So, because process A was running in the background, the + thread_info fields executing and resumed are set accordingly, but they are not + correct for process B. + + There's a line in fork_load_infrun_state that fixes up the thread_info field + stop_pc, so fix this by adding similar fixups for the executing and resumed + fields alongside. + + The FAIL did not always reproduce, so extend the test-case to reliably + trigger this scenario. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31203 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203 + +2024-01-11 changjiachen + + LoongArch: ld: Adjusted some code order in relax.exp. + ld/testsuite/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test. + +2024-01-11 Lulu Cai + + LoongArch: Discard extra spaces in objdump output + Due to the formatted output of objdump, some instructions + that do not require output operands (such as nop/ret) will + have extra spaces added after them. + + Determine whether to output operands through the format + of opcodes. When opc->format is an empty string, no extra + spaces are output. + +2024-01-11 Mike Frysinger + + sim: ppc: return register error when unhandled + We don't want to fallthru and use cooked_buf when we haven't initialized + it to anything. Returning 0 indicates the register wasn't recognized. + + sim: m32r: enable warnings in traps.c + File should be clean now! + +2024-01-11 Mike Frysinger + + sim: m32r: fixup some of the int<->pointer casts + The m32r trap code was written for a 32-bit Linux host (and really, one + whose Linux ABI matched pretty exactly). This has lead to conversions + between integers and pointers which breaks down hard on 64-bit hosts. + + Clean up some of the functions where possible to avoid unnecessary + conversions, use uintptr_t to cast 32-bit target pointers to host + pointers in some places, and just stub out a few functions that can't + easily be salvaged currently when sizeof(void*) is not 32-bits. This + is a bit ugly, but lets us enable warnings for the whole file. + +2024-01-11 Mike Frysinger + + sim: m32r: fix missing break statement + The ftime syscall should not fallthrough to the sync syscall. + Clearly the code was missing a break statement. + +2024-01-11 Mike Frysinger + + sim: m32r: migrate ftime() to clock_gettime() + The ftime() function has been deprecated since POSIX-1-2004, and + removed in POSIX.1-2008. It's also been deprecated/removed in glibc + since 2.33. POSIX has always said the function is not portable, and + its return value, timezone, and dstflag fields are unspecified. Even + if Linux/glibc & m32r had defined behavior, those aren't the host for + the sim runtime. + + So let's stop using the function and switch to clock_gettime. gnulib + already has detection support for it, and it's been around since at + least POSIX-1-2004. + +2024-01-11 Mike Frysinger + + sim: m32r: cleanup unused variables + We've been building this file with -Wno-error, so clean up unused + variable warnings. + + sim: igen: add printf attributes to the prototypes too + While gcc propagates the printf attribute via the typedef, clang + doesn't seem to, so add it to the prototypes themselves too. We + still keep it on the prototype for cases where it's used as a + variable. + +2024-01-11 Mike Frysinger + + gdbsupport: tighten up libiberty code a bit with dnl + No functional change here, just touch up generated output slightly. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + sim: build: switch to gdbsupport/libiberty.m4 + Leverage this common logic to find all the libiberty settings rather + than duplicate it ourselves. + + sim: ppc: rework defines.h to handle HAVE symbols defined to 0 + The HAVE_DECL_xxx defines are always defined to 0 or 1. The current + defines.h logic assumes every HAVE_xxx symbol is only defined iff it's + defined to 1 which causes this to break. Tweak the sed logic to only + match defines of 1. + +2024-01-11 Mike Frysinger + + gdb: libiberty: switch to AC_CHECK_DECLS_ONCE + Only check these decls once in case other m4 macros also look for them. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + gdb: move libiberty.m4 to gdbsupport + This is used by gdb, gdbsupport, and gdbserver. We want to use it + in the sim tree too. Move it to gdbsupport which is meant as the + common sharing space for these projects. + + Approved-By: Tom Tromey + +2024-01-11 GDB Administrator + + Automatic date update in version.in + +2024-01-10 Vladimir Mezentsev + + gprofng: add an examples directory + This directory contains example programs for the user to experiment with. + Initially there is one application written in C. The plan is to include + more examples, also in other langauges, over time. + In addition to the sources and a make file, a sample script how to make + a profile is included. There is also a README.md file. + + gprofng/ChangeLog + 2024-01-08 Ruud van der Pas + + * examples: Top level directory. + * examples/mxv-pthreads: Example program written in C. + +2024-01-10 Vladimir Mezentsev + + gprofng: 31123 improvements to hardware event implementation + Our hardware counter profiling is based on perf_event_open(). + Our HWC tables are absent for new machines. + I have added HWC tables for the following events: PERF_TYPE_HARDWARE, + PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. + + Did a little cleaning: marked the symbols as static, used Stringbuilder, + created a function to read /proc/cpuinfo. + + gprofng/ChangeLog + 2024-01-08 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. + * common/hwc_cpus.h: Declare a new function read_cpuinfo. + * common/hwcdrv.c: Add a new parameter in init_perf_event(). + * common/hwcentry.h: Add use_perf_event_type in Hwcentry. + * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, + type, config. + * common/hwctable.c: Add a new HWC table generic_list[]. + * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. + * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). + Add a new function read_cpuinfo. + +2024-01-10 Aditya Vidyadhar Kamath + + Fix AIX catchpoint warning during fork () event + In AIX we were missing some hooks needed to catch a fork () event + in rs6000-aix-nat.c. Due to their absence we were returning 1 while we + insert the breakpoint/catchpoint location. This patch is a fix to the same. + +2024-01-10 Nick Clifton + + Sync top level configure and makefiles + This update brings in the following commits from the gcc mainline: + + commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f + Author: Tom Tromey + Date: Tue Jan 9 06:25:26 2024 -0700 + + Pass GUILE down to subdirectories + + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb + Author: Pierre-Emmanuel Patry + Date: Wed Oct 25 13:06:48 2023 +0200 + + build: Add libgrust as compilation modules + + Define the libgrust directory as a host compilation module as well as + for targets. Disable target libgrust if we're not building target + libstdc++. + + commit 56ca59a03150cf44cea340f58967c990ed6bf43c + Author: Lewis Hyatt + Date: Thu Nov 16 11:18:37 2023 -0500 + + Makefile.tpl: Avoid race condition in generating site.exp from the top level + + A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of + a fresh build directory does not work reliably. That will spawn two + independent make processes inside the "gcc" directory, and each of those + will attempt to create site.exp if it doesn't exist and will interfere with + each other, producing often a corrupted or empty site.exp. Resolve that by + making these targets depend on a new phony target which makes sure site.exp + is created first before starting the recursive makes. + + commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1 + Author: Iain Sandoe + Date: Sun Mar 28 14:48:17 2021 +0100 + + Config,Darwin: Allow for configuring Darwin to use embedded runpath. + + Recent Darwin versions place contraints on the use of run paths + specified in environment variables. This breaks some assumptions + in the GCC build. + + This change allows the user to configure a Darwin build to use + '@rpath/libraryname.dylib' in library names and then to add an + embedded runpath to executables (and libraries with dependents). + + The embedded runpath is added by default unless the user adds + '-nodefaultrpaths' to the link line. + + For an installed compiler, it means that any executable built with + that compiler will reference the runtimes installed with the + compiler (equivalent to hard-coding the library path into the name + of the library). + + During build-time configurations any "-B" entries will be added to + the runpath thus the newly-built libraries will be found by exes. + + Since the install name is set in libtool, that decision needs to be + available here (but might also cause dependent ones in Makefiles, + so we need to export a conditional). + + This facility is not available for Darwin 8 or earlier, however the + existing environment variable runpath does work there. + + We default this on for systems where the external DYLD_LIBRARY_PATH + does not work and off for Darwin 8 or earlier. For systems that can + use either method, if the value is unset, we use the default (which + is currently DYLD_LIBRARY_PATH). + + commit 2551e10038a70901f30b2168e6e3af4536748f3c + Author: Sergei Trofimovich + Date: Mon Oct 2 12:08:17 2023 +0100 + + Makefile.tpl: disable -Werror for feedback stage [PR111663] + + Without the change profiled bootstrap fails for various warnings on + master branch as: + + $ ../gcc/configure + $ make profiledbootstrap + ... + gcc/genmodes.cc: In function ‘int main(int, char**)’: + gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] + ... + gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: + gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] + + The change removes -Werror just like autofeedback does today. + + commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a + Author: Thomas Schwinge + Date: Thu Jun 1 23:07:37 2023 +0200 + + Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] + + ..., where we need to use it (separate commits) for build-tree testing, similar + to 'gcc/Makefile.in:site.exp': + + # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation. + # They are passed first to allow individual tests to override them. + @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp + + PR testsuite/109951 + * Makefile.tpl (BASE_TARGET_EXPORTS): Add + 'SYSROOT_CFLAGS_FOR_TARGET'. + * Makefile.in: Regenerate. + +2024-01-10 Saurabh Jha + + gas: aarch64: Add system registers for Debug and PMU extensions + This patch adds support for the new AArch64 system registers that are part of the following extensions: + * FEAT_DEBUGv8p9 + * FEAT_PMUv3p9 + * FEAT_PMUv3_SS + * FEAT_PMUv3_ICNTR + * FEAT_SEBEP + +2024-01-10 Tom de Vries + + [gdb] Fix assertion failure for checkpoint delete 0 + When doing "checkpoint delete 0" we run into an assertion failure: + ... + +delete checkpoint 0 + inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed. + ... + + Fix this by handling the "pptid == null_ptid" case in + delete_checkpoint_command. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31209 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209 + +2024-01-10 Tom de Vries + + [gdb] Fix info checkpoints + Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info + checkpoints command: + ... + (gdb) info checkpoints^M + * 0 process 30570 (main process) at 0x0^M + 1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M + 2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M + 3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M + 4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M + 5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M + 6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M + 7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M + 8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M + 9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M + 10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M + ... + + According to the docs, each of these (0-10) is a checkpoint. + + But the pc address (as well as the file name and line number) is missing for + checkpoint 0. + + Fix this by sampling the pc value for the current process in + info_checkpoints_command, such that we have instead: + ... + * 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M + ... + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31211 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211 + +2024-01-10 Tom de Vries + + [gdb] Make variable printed bool in info_checkpoints_command + While reading info_checkpoints_command, I noticed variable printed: + ... + const fork_info *printed = NULL; + ... + for (const fork_info &fi : fork_list) + { + if (requested > 0 && fi.num != requested) + continue; + + printed = &fi; + ... + } + if (printed == NULL) + ... + has pointer type, but is just used as bool. + + Make this explicit by changing the variable type to bool. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + +2024-01-10 Tom de Vries + + gdb/symtab: Eliminate deferred_entry + Currently cooked_index entry creation is either: + - done immediately if the parent_entry is known, or + - deferred if the parent_entry is not yet known, and done later while + resolving the deferred entries. + + Instead, create all cooked_index entries immediately, and keep track of which + entries have a parent_entry that needs resolving later using the new + IS_PARENT_DEFERRED flag. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Make cooked_index_entry::parent_entry private + Make cooked_index_entry::parent_entry private, and add member functions to + access it. + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Allow changing of added cooked_index entries + Make cooked_index_storage::add and cooked_index_entry::add return a + "cooked_index_entry *" instead of a "const cooked_index_entry *". + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom Tromey + + Fix ASAN failure in DWO code + Simon pointed out that my recent change to the DWO code caused a + failure in ASAN testing. + + The bug here was I updated the code to use a different search type in + the hash table; but then did not change the search code to use + htab_find_slot_with_hash. + + Note that this bug would not be possible with my type-safe hash table + series, hint, hint. + + Approved-By: Simon Marchi + +2024-01-10 GDB Administrator + + Automatic date update in version.in + +2024-01-09 Tom Tromey + + Fix thread-less build + A user pointed out that the recent background DWARF reader series + broke the build when --disable-threading is in use. This patch fixes + the problem. I am checking it in. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223 + +2024-01-09 Tom Tromey + + Pass GUILE down to subdirectories + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Add GUILE. + (GUILE): New variable. + * Makefile.def (flags_to_pass): Add GUILE. + +2024-01-09 H.J. Lu + + ld: Add --enable-mark-plt configure option + Add --enable-mark-plt linker configure option to mark PLT entries with + DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by + default. + + * NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt. + * config.in: Regenerated. + * configure: Likewise. + * configure.ac: Add --enable-mark-plt. + (DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED. + * emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT): + Support DEFAULT_LD_Z_MARK_PLT. + * emultempl/elf-x86.em (elf_x86_64_before_parse): New function. + (LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for + x86-64 targets. + +2024-01-09 H.J. Lu + + elf: Add elf_backend_add_glibc_version_dependency + When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and + DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation + stores the offset of the indirect branch instruction. However, glibc + versions which don't have this commit in glibc 2.36: + + commit f8587a61892cbafd98ce599131bf4f103466f084 + Author: H.J. Lu + Date: Fri May 20 19:21:48 2022 -0700 + + x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT + + According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT + and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we + can ignore their r_addends. + + Reviewed-by: Fangrui Song + + won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. + Although this commit has been backported to glibc 2.33/2.34/2.35 release + branches, it is safer to require glibc 2.36 for such binaries. + + Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to + also add GLIBC_2.36 version dependency for -z mark-plt on the shared C + library if it provides a GLIBC_2.XX symbol version. + + * elflink.c (elf_find_verdep_info): Moved to ... + * elf-bfd.h (elf_find_verdep_info): Here. + (elf_backend_data): Add elf_backend_add_glibc_version_dependency. + (_bfd_elf_link_add_glibc_version_dependency): New function. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): + Likewise. + (elf_backend_add_glibc_version_dependency): New. + * elflink.c (elf_link_add_dt_relr_dependency): Renamed to ... + (elf_link_add_glibc_verneed): This. Modified to support other + glibc dependencies. + (_bfd_elf_link_add_glibc_version_dependency): Likewise. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + (bfd_elf_size_dynamic_sections): Call + elf_backend_add_glibc_version_dependency instead of + elf_link_add_dt_relr_dependency. + * elfxx-target.h (elf_backend_add_glibc_version_dependency): New. + (elfNN_bed): Add elf_backend_add_glibc_version_dependency. + + ld/ + + * testsuite/ld-x86-64/mark-plt-1a.rd: New file. + * testsuite/ld-x86-64/mark-plt-1b.rd: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for + GLIBC_2.36 dependency. + +2024-01-09 H.J. Lu + + x86: Don't check R_386_NONE nor R_X86_64_NONE + Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning + relocations. + + bfd/ + + * PR ld/31047 + * elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check + R_X86_64_NONE. + + ld/ + + * PR ld/31047 + * testsuite/ld-i386/i386.exp: Run PR ld/31047 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/pr31047.d: New file. + * testsuite/ld-x86-64/pr31047-x32.d: Likewise. + * testsuite/ld-x86-64/pr31047.d: Likewise. + * testsuite/ld-x86-64/pr31047a.s: Likewise. + * testsuite/ld-x86-64/pr31047b.s: Likewise. + +2024-01-09 Tom Tromey + + Fix two bugs in gdbserver thread name handling + Simon pointed out that my earlier patch to gdbserver's thread name + code: + + commit 07b3255c3bae7126a0d679f957788560351eb236 + Author: Tom Tromey + Date: Thu Jul 13 17:28:48 2023 -0600 + + Filter invalid encodings from Linux thread names + + ... introduced a regression. This bug was that the iconv output was + not \0-terminated. + + Looking at it, I found another bug as well -- replace_non_ascii would + not \0-terminate, and also would return the wrong pointer + + This patch fixes both of them. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153 + +2024-01-09 Tom Tromey + + Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu + dwarf2_base_index_functions::find_per_cu is documented as using an + unrelocated address. This patch changes the interface to use the + unrelocated_addr type, just to be a bit more type-safe. + + Regression tested on x86-64 Fedora 38. + +2024-01-09 Jan Beulich + + x86: add missing APX logic to cpu_flags_match() + As already indicated during review, we can't get away without certain + adjustments here: Without these, respective {evex}-prefixed insns are + assembled to APX encodings even when APX_F is turned off. + + While there also extend the respective comment in the opcode table, to + explain why this construct is used. + +2024-01-09 Jan Beulich + + x86: FMA insns aren't eligible to VEX2 encoding + PR gas/31178 + + In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked + that C aliases StaticRounding, and hence build_vex_prefix() now needs to + be aware of that aliasing. Disambiguation is easy, as StaticRounding is + only ever used together with SAE (hence why the overlaying works in the + first place). + +2024-01-09 Jan Beulich + + PPC64/ELF: adjust comment wrt ABI versions + While having been moved a couple of times since its introduction in + f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"), + the wording has always remained the same. In particular ELFv1 and ELFv2 + have always been the wrong way round. + +2024-01-09 Nick Clifton + + Synchronize sourceware version of the libiberty sources with the master gcc versions. + This brings in the following commits: + + commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a + Author: Jakub Jelinek + Date: Tue Dec 5 23:32:19 2023 +0100 + + libiberty: Fix build with GCC < 7 + + Tobias reported on IRC that the linker fails to build with GCC 4.8.5. + In configure I've tried to use everything actually used in the sha1.c + x86 hw implementation, but unfortunately I forgot about implicit function + declarations. GCC before 7 did have header and bit_SHA define + and __get_cpuid function defined inline, but it didn't define + __get_cpuid_count, which compiled fine (and the configure test is + intentionally compile time only) due to implicit function declaration, + but then failed to link when linking the linker, because + __get_cpuid_count wasn't defined anywhere. + + The following patch fixes that by using what autoconf uses in AC_CHECK_DECL + to make sure the functions are declared. + + commit 691858d279335eeeeed3afafdf872b1c5f8f4201 + Author: Rainer Orth + Date: Tue Dec 5 11:04:06 2023 +0100 + + libiberty: Fix pex_unix_wait return type + + The recent warning patches broke Solaris bootstrap: + + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] + 326 | pex_unix_wait, + | ^~~~~~~~~~~~~ + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') + + While pex_funcs.wait expects a function returning pid_t, pex_unix_wait + currently returns int. However, on Solaris pid_t is long for 32-bit, + but int for 64-bit. + + This patches fixes this by having pex_unix_wait return pid_t as + expected, and like every other variant already does. + + Bootstrapped without regressions on i386-pc-solaris2.11, + sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and + x86_64-apple-darwin23.1.0. + + commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 + Author: Jason Merrill + Date: Mon Sep 25 10:15:02 2023 +0100 + + c++: mangle function template constraints + + Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and + https://github.com/itanium-cxx-abi/cxx-abi/pull/166 + + We need to mangle constraints to be able to distinguish between function + templates that only differ in constraints. From the latter link, we want to + use the template parameter mangling previously specified for lambdas to also + make explicit the form of a template parameter where the argument is not a + "natural" fit for it, such as when the parameter is constrained or deduced. + + I'm concerned about how the latter link changes the mangling for some C++98 + and C++11 patterns, so I've limited template_parm_natural_p to avoid two + cases found by running the testsuite with -Wabi forced on: + + template T f() { return V; } + int main() { return f(); } + + template int max() { return i; } + template int max() + { + int sub = max(); + return i > sub ? i : sub; + } + int main() { return max<1,2,3>(); } + + A third C++11 pattern is changed by this patch: + + template