Alan Modra [Wed, 28 Jan 2026 21:49:44 +0000 (08:19 +1030)]
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.
Alan Modra [Wed, 28 Jan 2026 07:38:09 +0000 (18:08 +1030)]
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.
Than McIntosh [Sun, 25 Jan 2026 14:19:10 +0000 (14:19 +0000)]
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
Matthieu Longo [Thu, 22 Jan 2026 18:53:34 +0000 (18:53 +0000)]
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.
Indu Bhagat [Thu, 22 Jan 2026 08:00:36 +0000 (10:00 +0200)]
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.
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).
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.
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.
Rainer Orth [Sat, 24 Jan 2026 07:02:14 +0000 (08:02 +0100)]
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.
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.
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.
H.J. Lu [Thu, 15 Jan 2026 01:11:50 +0000 (09:11 +0800)]
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.
Michal Sobon [Fri, 23 Jan 2026 13:38:28 +0000 (14:38 +0100)]
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.
Indu Bhagat [Fri, 23 Jan 2026 22:21:56 +0000 (14:21 -0800)]
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.
Indu Bhagat [Fri, 23 Jan 2026 22:21:15 +0000 (14:21 -0800)]
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.
Indu Bhagat [Fri, 23 Jan 2026 22:20:54 +0000 (14:20 -0800)]
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.
Tom Tromey [Sun, 23 Apr 2023 15:58:14 +0000 (09:58 -0600)]
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.
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
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>
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
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.
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
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).
Hannes Domani [Fri, 23 Jan 2026 19:07:04 +0000 (20:07 +0100)]
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.
Tom Tromey [Sat, 22 Nov 2025 18:03:57 +0000 (11:03 -0700)]
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.
Andrew Burgess [Thu, 22 Jan 2026 14:09:37 +0000 (14:09 +0000)]
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.
Matthieu Longo [Thu, 22 Jan 2026 17:34:39 +0000 (17:34 +0000)]
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.
H.J. Lu [Sun, 18 Jan 2026 01:24:48 +0000 (09:24 +0800)]
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.
Tom de Vries [Fri, 23 Jan 2026 06:54:32 +0000 (07:54 +0100)]
[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.
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.
Indu Bhagat [Wed, 21 Jan 2026 20:00:22 +0000 (12:00 -0800)]
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.
Andrew Burgess [Wed, 14 Jan 2026 19:31:24 +0000 (19:31 +0000)]
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.
Rainer Orth [Thu, 22 Jan 2026 15:21:00 +0000 (16:21 +0100)]
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.
Andrew Burgess [Mon, 12 Jan 2026 16:36:36 +0000 (16:36 +0000)]
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:
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.
Tom de Vries [Thu, 22 Jan 2026 13:12:15 +0000 (14:12 +0100)]
[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
....
Thiago C Silva [Thu, 22 Jan 2026 11:05:07 +0000 (12:05 +0100)]
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.
Thiago C Silva [Thu, 22 Jan 2026 11:03:43 +0000 (12:03 +0100)]
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.
Eli Zaretskii [Thu, 22 Jan 2026 11:03:13 +0000 (13:03 +0200)]
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.
Eli Zaretskii [Thu, 22 Jan 2026 10:43:38 +0000 (12:43 +0200)]
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.
Alan Modra [Thu, 22 Jan 2026 02:37:51 +0000 (13:07 +1030)]
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 0020020c00000307 R_386_JUMP_SLOT 00000000 bar
while the corresponding got-contents dump shows "bar + 156".
3: 0020020c R_386_JUMP_SLOT bar + 156
Andrew Burgess [Mon, 12 Jan 2026 10:44:35 +0000 (10:44 +0000)]
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.
Matthieu Longo [Thu, 10 Apr 2025 15:11:02 +0000 (16:11 +0100)]
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.
Matthieu Longo [Thu, 10 Apr 2025 14:16:31 +0000 (15:16 +0100)]
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.
Matthieu Longo [Thu, 17 Apr 2025 17:02:38 +0000 (18:02 +0100)]
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).
Matthieu Longo [Tue, 25 Feb 2025 17:28:03 +0000 (17:28 +0000)]
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.
Matthieu Longo [Thu, 17 Apr 2025 09:23:08 +0000 (10:23 +0100)]
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).
Matthieu Longo [Tue, 25 Feb 2025 17:26:57 +0000 (17:26 +0000)]
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.
Matthieu Longo [Wed, 12 Nov 2025 16:05:07 +0000 (16:05 +0000)]
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.
Matthieu Longo [Fri, 14 Nov 2025 10:31:29 +0000 (10:31 +0000)]
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.
Matthieu Longo [Fri, 14 Nov 2025 12:04:32 +0000 (12:04 +0000)]
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.
projects / thirdparty / binutils-gdb.git / log
