[binutils-gdb/binutils-2_46-branch] This is the 2.46 release
Nick Clifton
nickc@sourceware.org
Sun Feb 8 10:41:09 GMT 2026
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=49d4d3fafa4ec4ff5a3460d91d5b1ed5286487db
commit 49d4d3fafa4ec4ff5a3460d91d5b1ed5286487db
Author: Nick Clifton <nickc@redhat.com>
Date: Sun Feb 8 10:40:43 2026 +0000
This is the 2.46 release
Diff:
---
ChangeLog.git | 321663 ++++++++++++++++++++++++++++++++++++++
bfd/configure | 20 +-
bfd/development.sh | 4 +-
bfd/po/bfd.pot | 296 +-
bfd/version.m4 | 2 +-
binutils/configure | 20 +-
binutils/po/binutils.pot | 108 +-
gas/configure | 20 +-
gas/po/gas.pot | 48 +-
gdb/aclocal.m4 | 16 +-
gprof/configure | 20 +-
gprofng/configure | 20 +-
gprofng/doc/version.texi | 4 +-
gprofng/libcollector/configure | 20 +-
ld/configure | 20 +-
ld/po/ld.pot | 1203 +-
libdecnumber/aclocal.m4 | 4 +-
libiberty/functions.texi | 59 +-
opcodes/configure | 20 +-
src-release.sh | 2 +-
20 files changed, 322645 insertions(+), 924 deletions(-)
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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-07 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-06 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <nickc@redhat.com>
+
+ Updated/new translation files for the 2.46 release
+
+2026-02-06 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-05 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-04 Alan Modra <amodra@gmail.com>
+
+ 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 <matz@suse.de>
+ (cherry picked from commit 2dfd38f93ce3b05d25c7bd14cbcff0fa3614c056)
+
+2026-02-04 Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
+ Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <claudiu.zissulescu-ianculescu@oracle.com>
+ Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <jremus@linux.ibm.com>
+ (cherry-picked from commit 4b5ff658b4993fae1f347793bddd5c14b76167cd)
+
+2026-02-04 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-03 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-02 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-02-01 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-31 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-30 GDB Administrator <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-29 Jan Beulich <jbeulich@suse.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-28 Alan Modra <amodra@gmail.com>
+
+ 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 <R_390_TLS_LE64>): Correct
+ size and bitsize.
+
+ (cherry picked from commit 0e245c72b774658c48a14b05d78a4e0943a8a9b1)
+
+2026-01-28 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-27 Alan Modra <amodra@gmail.com>
+
+ regen pot files
+
+2026-01-27 Alan Modra <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ PR 33840 typo in elfnn-loongarch.c
+ s/marching/matching/
+
+ (cherry picked from commit 5c9b48f2eda429b3ef09a8239a472f6a72541a53)
+
+2026-01-27 Alan Modra <amodra@gmail.com>
+
+ 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 <schwab@linux-m68k.org>
+
+ (cherry picked from commit 1c8cfb3d217aee87562c4f4c4dbc1e4d60e8eadb)
+
+2026-01-27 Than McIntosh <thanm@golang.org>
+
+ 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 <DW_FORM_string>): Skip terminating NUL too.
+
+ (cherry picked from commit a72b83ab3792532b66cc5c472a20476a8a2fd969)
+
+2026-01-27 Alan Modra <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-26 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <nickc@redhat.com>
+
+ Update version to 2.45.90
+
+ Add 2.46 release markers to NEWS files. Update BRANCHES. Update README.
+
+2026-01-25 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <jremus@linux.ibm.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-24 John David Anglin <danglin@gcc.gnu.org>
+
+ 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 <danglin@gcc.gnu.org>
+
+ bfd/ChangeLog:
+
+ * elf64-hppa.c (elf64_hppa_relocate_section): Remove asserts.
+
+2026-01-24 Alice Carlotti <alice.carlotti@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ 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 <srinath.parvathaneni@arm.com>
+
+ aarch64: TLBI Domains changes for PLBI instruction
+ For the PLBI instruction with optional register argument
+ <Rt> == 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 <type> of ALLE1*, ALLE2* and
+ VMALL* and a <shareability> 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 <srinath.parvathaneni@arm.com>
+
+ aarch64: Add support for FEAT_TLBID feature
+ TLBI Domains feature changes TLBI and TLBIP system instructions.
+ For the TLBI instruction with optional register argument
+ <Rt> == 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 <type> of ALLE1*, ALLE2*,
+ VMALL*, VMALLS12* or VMALLWS2* and a <shareability> of IS or OS.
+
+ This patch add support for FEAT_TLBID feature, which is enabled
+ by new +tlbid option.
+
+2026-01-24 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ ld:
+ PR ld/33350
+ * testsuite/ld-i386/libgot-1.rd: Allow for different
+ R_386_JUMP_SLOT addends.
+
+2026-01-24 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <symbol>@<version> (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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <hp@axis.com>
+
+ 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) <case 'l' - two cases>: Make separate
+ compound statements where case-labels were part of a declaration.
+
+2026-01-24 H.J. Lu <hjl.tools@gmail.com>
+
+ 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 <a1ba.omarov@gmail.com>
+
+ 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=<foo>' -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=<foo>' -o test.o -i test.rc
+ ./i686-w64-mingw32-windres: no resources
+
+2026-01-24 Michal Sobon <msobon@hex-rays.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <amodra@gmail.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-23 Indu Bhagat <indu.bhagat@oracle.com>
+
+ sframe: doc: minor typos and cosmetic fixes
+ libsframe/
+ * doc/sframe-spec.texi: Minor edits.
+
+2026-01-23 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ 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 <indu.bhagat@oracle.com>
+
+ sframe: doc: terminology change from offset to data word
+ ChangeLog:
+ * libsframe/doc/sframe-spec.texi
+
+2026-01-23 Tom Tromey <tom@tromey.com>
+
+ 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 <keiths@redhat.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <eliz@gnu.org>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ Move setting size of long to windows-tdep
+ It's 32bit for all (non-cygwin) Windows ABIs.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ Move auto_wide_charset gdbarch method to windows-tdep
+ It's UTF-16 for all Windows ABIs.
+
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ Move software breakpoint recognition code into x86-windows-nat.c
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
+
+ Move x86 selector code into x86-windows-nat.c
+ Approved-By: Tom Tromey <tom@tromey.com>
+ Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
+
+ Move x86 register code into x86-windows-nat.c
+ Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+ Move x86 debug registers and related code into x86-windows-nat.c
+ Approved-By: Tom Tromey <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+ Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
+
+2026-01-23 Hannes Domani <ssbssa@yahoo.de>
+
+ 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 <tom@tromey.com>
+
+2026-01-23 Tom Tromey <tom@tromey.com>
+
+ 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 <tromey@adacore.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2026-01-23 Matthieu Longo <matthieu.longo@arm.com>
+
+ aarch64 test: fix clashing test name
+
+ fix build failures due to incorrect format specifier for uint64_t
+
+2026-01-23 Nick Clifton <nickc@redhat.com>
+
+ Reword the section of the AI Acceptance Policy that refers to labelling submissions.
+
+2026-01-23 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2026-01-23 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ binutils:
+ * testsuite/lib/binutils-common.exp (is_elf_format): Fix
+ indentation.
+
+2026-01-23 Eli Zaretskii <eliz@gnu.org>
+
+ 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 <hjl.tools@gmail.com>
+
+ 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 <tdevries@suse.de>
+
+ [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 <keiths@redhat.com>
+
+ 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 <gdbadmin@sourceware.org>
+
+ Automatic date update in version.in
+
+2026-01-22 John David Anglin <danglin@gcc.gnu.org>
+
+ 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 <danglin@gcc.gnu.org>
+
+ 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 <tromey@adacore.com>
+
+ Fix typo in fetch-exec-and-args.exp
+ pre-commit points out a typo in this file.
+
+2026-01-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ ld:
+ * testsuite/ld-sparc/sparc.exp: Run sparctests, sparc64tests on
+ Solaris.
+
+2026-01-22 Indu Bhagat <indu.bhagat@oracle.com>
+
+ 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 <tom@tromey.com>
+
+ Constify gdbserver "monitor" commands
+ I noticed that the gdbserver "monitor" commands should take a const
+ parameter.
+
+ Approved-By: Simon Marchi <simon.marchi@efficios.com>
+
+2026-01-22 Andrew Burgess <aburgess@redhat.com>
+
+ 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 <simon.marchi@efficios.com>
+
+2026-01-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <ro@CeBiTec.Uni-Bielefeld.DE>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <http://gnu.org/licenses/gpl.html>
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
+ ┃ Find the GDB manual online at: ┃
+ ┃ http://www.gnu.org/software/gdb/documentation/. ┃
+ ┃ For help, type "help". ┃
+ ┃ Type "apropos <word>" to search for commands related to <word>. ┃
+ --Type <RET> 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 <http://gnu.org/licenses/gpl.html>
+ 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:
+ <https://www.gnu.org/software/gdb/bugs/>.
+
+ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
+ ┃ Find the GDB manual online at: ┃
+ ┃ http://www.gnu.org/software/gdb/documentation/. ┃
+ ┃ For help, type "help". ┃
+ ┃ Type "apropos <word>" to search for commands related to <word>. ┃
+ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
+ --Type <RET> 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 <tom@tromey.com>
+
+2026-01-22 Tom de Vries <tdevries@suse.de>
+
+ [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 <matthieu.longo@arm.com>
+
+ bfd: use correct format specifier for uint64_t
+
+2026-01-22 Thiago C Silva <opsrcodev@gmail.com>
+
+ 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 <opsrcodev@gmail.com>
+
+ 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 <eliz@gnu.org>
+
+ 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 <eliz@gnu.org>
+
+ 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 <amodra@gmail.com>
+
+ 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 <aburgess@redhat.com>
+
+ 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 <tom@tromey.com>
+
+2026-01-22 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ gnu directives: bfd: generic tests for objcopy of gnu attributes v2
+
+2026-01-22 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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_<XXXXXX>_MERGE_<POLICY>
+ with:
+ - <XXXXXX>: an arbitrary name for your testing subsection.
+ - <POLICY>: 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+ 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:
+ <format-version: uint8>
+ [ <subsection-length: uint32>
+ <subsection-name: NTBS>
+ <optionality: uint8>
+ <encoding: uint8>
+ <attribute>*
+ ]*
+
+ 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 <richard.ball@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+2026-01-22 Richard Ball <richard.ball@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+2026-01-22 Richard Ball <richard.ball@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+2026-01-22 Matthieu Longo <matthieu.longo@arm.com>
+
+ 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 <richard.ball@arm.com>
+
+ 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 <matthieu.longo@arm.com>
+
+2026-01-22 Richard Ball <richard.ball@arm.com>
+
+ 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 at[...]
[diff truncated at 100000 bytes]
More information about the Binutils-cvs
mailing list