Matthieu Longo [Tue, 6 Jan 2026 13:12:38 +0000 (13:12 +0000)]
Python limited API: migrate Py_CompileStringExFlags and PyRun_SimpleString
This patch replaces Py_CompileStringExFlags () with its limited C API
equivalent, Py_CompileString (). The eval_python_command () helper is
now exposed through the private GDB Python API as a utility function.
PyRun_SimpleString () is replaced with eval_python_command () to avoid
code duplication.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
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.
Rainer Orth [Tue, 27 Jan 2026 17:26:59 +0000 (18:26 +0100)]
ld: testsuite: Simplify emulation check in libgot tests
The x86 libgot-1 tests are the only ones in all testsuites that use a
new ld -V -m<emul under test> idiom to check whether to run the tests.
Rather than open-coding the check everywhere while relying on that
idiom, this patch introduces a new proc to directly check the ld -V
output for the emulation in question.
Tested on {x86_64,i686}-pc-linux-gnu and {amd64,i386}-pc-solaris2.11.
Tom de Vries [Tue, 27 Jan 2026 09:40:06 +0000 (10:40 +0100)]
[bfd] Fix data race in bfd_check_format_matches
At the start of bfd_check_format_matches, we have this read of_bfd_section_id:
...
unsigned int initial_section_id = _bfd_section_id;
...
In order to access the variable, it is required to hold the global BFD lock.
The function already contains code acquiring the lock:
...
/* Locking is required here in order to manage _bfd_section_id. */
if (!bfd_lock ())
{
bfd_cache_set_uncloseable (abfd, old_in_format_matches, NULL);
free (matching_vector);
return false;
}
...
so fix this by moving the read after it.
Simon Marchi [Thu, 8 Jan 2026 19:51:54 +0000 (14:51 -0500)]
gdb/testsuite: remove guile "test byte at sp, before flush" test
When I run:
$ while make check TESTS="gdb.guile/scm-ports.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"; do done
I eventually get:
FAIL: gdb.guile/scm-ports.exp: buffered=1: test byte at sp, before flush
I don't know why I only see this (or see this more often) with the
native-extended-gdbserver board, I guess because it changes the timing
of things. Also, this is with a debug/ASan/UBSan build of GDB, if that
matters. This is with guile 3.0.
This is what the test attempts to do:
1. create a rw memory port that is supposed to be buffered
2. write the byte at $sp with a new value, expecting that byte to only
be in the port's buffer
3. read the memory at $sp (using parse-and-eval, bypassing the rw
memory port), expecting to see the old byte value
4. flush the memory port, expecting that to write to new byte value at
$sp
5. read the memory at $sp (using parse-and-eval again), expecting to
see the new value
It is step 3 that fails. My hypothesis is that even if the memory port
we write to is buffered, the write to the underlying memory can happen
before the "before flush" test happens. The Guile Buffering doc [1]
says this:
If you write data to a buffered port, it probably doesn’t go out to
the mutable store directly. (This “probably” introduces some
indeterminism in your program: what goes to the store, and when,
depends on how full the buffer is. It is something that the user
needs to explicitly be aware of.) The data is written to the store
later – when the buffer fills up due to another write, or when
force-output is called, or when close-port is called, or when the
program exits, or even when the garbage collector runs.
Because of the mention of the garbage collector, I tried putting some
calls to gc-disable and gc-enable around that area, but it doesn't fix
it.
Given that the flushing behavior of the buffered port seems
non-deterministic, I think that the buffering behavior can't easily be
tested. I propose to get rid of that specific aspect of the test.
As suggested by Tom de Vries, replace the "test byte at sp, before
flush" test with a "test byte at sp, before write" one. I think this is
useful as a sanity check to help prove that the memory write did in fact
change the state of the program.
Tom Tromey [Mon, 26 Jan 2026 17:54:08 +0000 (10:54 -0700)]
Minor cleanups in expanded-symbol.[ch]
I found a typo in expanded-symbol.h, then noticed some formatting
mistakes and some other incorrect comments. This patch fixes all
these and removes some 'struct' keywords as well.
This is not dap-specific, also with the CLI I see:
...
$ gdb -q -batch prog -ex "break prog.adb:22" -ex run -ex "info locals"
...
<W03a0> = 3
...
vs.:
...
<W03a0> = 3
<W03a6> = 7
...
Matthieu Longo [Thu, 23 Oct 2025 16:20:50 +0000 (17:20 +0100)]
gdb: add noexcept to relevant methods of class ref_ptr
This patch aims at improving code readability and maintainability
by adding the 'noexcept' attribute to some constructors and
methods of class 'ref_ptr' to make clear that no exception is
supposed to be raised from them.
As an additional benefit, the compiler doesn't need to generate
the stack unwinding code for those constructors and methods.
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.
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
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
....
projects / thirdparty / binutils-gdb.git / log
