Alan Modra [Sat, 28 Mar 2026 08:11:02 +0000 (18:41 +1030)]
buffer overflow in loongarch_elf_add_sub_reloc_uleb128
oss-fuzz managed to trigger a buffer overflow processing a bogus
leb128. Well, the leb128 encoding can be arbitrarily long so this
isn't surprising at all. If we want to guard against user input
triggering buffer overflows then we'd need to ensure input is
terminated somehow, or do as this patch does.
Remove _bfd_read_unsigned_leb128 and _bfd_read_signed_leb128,
replacing all uses of these functions with _bfd_safe_read_leb128.
Jens Remus [Fri, 27 Mar 2026 16:42:08 +0000 (17:42 +0100)]
s390: Only use canonical PLT for non-PIC code taking address in PDE
Fix incorrect use of canonical PLT in position-dependent executables
(PDE) that violated pointer equality. The linker must distinguish
between non-PIC code linked as PDE (which requires canonical PLT for
pointer equality) and PIC code linked as PDE (which must not use
canonical PLT). This is determined by examining relocations, not just
the executable type (PIE vs. PDE).
Canonical PLT entries are needed only when non-PIC code takes function
addresses. Non-PIC code uses absolute addresses and assumes all
addresses are known at link time. When such code both calls and takes
the address of a shared library function, the linker creates a canonical
PLT entry (setting the symbol's value to the PLT stub address) to ensure
all references use the same address, maintaining pointer equality.
However, PIC code uses GOT-indirect addressing for function pointers.
When PIC code takes a function's address, it loads from the GOT, which
the dynamic linker resolves to the actual function address in the shared
library. Using canonical PLT in this case is wrong, as it forces all
GOT entries to point to the PLT stub, breaking pointer equality when the
shared library compares function addresses internally.
Require pointer equality in PDE for symbols with non-PLT PC-relative
relocations, that are likely in address taken context, and direct
relocations, that are likely in function reference context. Do so
for IFUNC symbols defined in a non-shared object. Clear value of PLT
undefined symbols if pointer equality is not needed and do not hash them
in '.gnu.hash' section.
As workaround for GCC 12-14 treat PC32DBL relocation for address taking
instruction "larl rX,<sym>@PLT" as if it was without @PLT suffix and
require pointer equality. This ensures correct behavior even when the
compiler incorrectly marks address-taking instructions with @PLT.
GCC 12-14, since GCC commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for
local functions in 64-bit mode") [1], unconditionally suffix non-local
symbols with @PLT, regardless of whether they are used in function call
instructions (i.e. brasl) or address taking instructions (i.e. larl).
The assembler therefore generates a PLT32DBL instead of a PC32DBL
relocation for larl. The linker therefore cannot distinguish between
function call and address taking instructions solely from the relocation
type. The latter requiring pointer equality.
This complements GCC commit a2e0a30c52fa ("IBM zSystems: Do not use
@PLT with larl") [2], which makes GCC stop suffixing @PLT to address
taking larl instructions, so that the correct behavior with regards to
pointer equality is also achieved with affected GCC 12-14.
Note that this workaround can be reverted once GCC 12-14 emitting
address taking larl instructions with @PLT suffix have become
irrelevant.
Note that without the workaround for GCC 12-14 suffixing @PLT to larl
the following linker tests would fail:
Based on x86-64, especially Jakub Jelinek's x86 commits 47a9f7b34f7a
(clearing value of PLT undefined symbols if pointer equality not needed)
and fdc90cb46b0f (omitting PLT undefined symbols from '.gnu.hash').
Note that on x86-64 PC32 (and PC64) relocations are excluded as
indication for address taken context requiring function pointer
equality. This is because x86-64 used a PC32 relocation in function
calls from non-PIC code, which has been resolved with commit bd7ab16b4537 ("x86-64: Generate branch with PLT32 relocation").
[1] GCC commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for local
functions in 64-bit mode"),
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0990d93dd8a4
[2] GCC commit a2e0a30c52fa ("IBM zSystems: Do not use @PLT with larl"),
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a2e0a30c52fa
bfd/
PR ld/29655
* elf64-s390.c (elf_s390_check_relocs): Require pointer equality
for direct and non-PLT PC-relative relocations indicating
address taking instructions and for PLT32DBL relocations, when
used with address taking larl instruction.
(elf_s390_finish_dynamic_symbol): Do not use canonical PLT for
non-local undefined symbols if pointer equality is not needed.
Abort if pointer equality needed flag not set although required.
(elf_s390_copy_indirect_symbol): Copy pointer equality needed
flag.
(elf_s390_hash_symbol): New function. Based on x86-64.
(elf_backend_hash_symbol): Wire up elf_s390_hash_symbol.
ld/testsuite/
PR ld/29655
* ld-elf/shared.exp: Add new pr29655 test.
* ld-elf/pr29655a.c: New file. Based on Rui's sample in PR.
* ld-elf/pr29655b.c: Likewise.
* ld-elf/pr29655.rd: Expect zero fun_public symbol value.
* ld-s390/plt_64-1.wf: Adjust expected test output to change in
.gnu.hash due to omitted PLT undefined symbols that do not need
pointer equality.
* ld-s390/plt_64-1_eh.wf: Likewise.
Bug: https://sourceware.org/PR29655 Co-authored-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jan Beulich [Fri, 27 Mar 2026 09:42:21 +0000 (10:42 +0100)]
bfd: fold aarch64* entries
There are three groups with identical selections each. Make them have
three entries rather than five (plain little-endian ELF entries were
already folded when the Phoenix target was added).
Jan Beulich [Fri, 27 Mar 2026 09:35:24 +0000 (10:35 +0100)]
bfd/mcore: drop BFD_RELOC_MCORE_{PCREL_32,RVA}
They're unused. Really there was a bogus use in the assembler: If the
type isn't used anywhere else, the case label was stale (in one of two
ways; assume it was missed during some earlier conversion, with the
alternative being that it should be dropped altogether).
Fix asertion failure while analysing core files in AIX with terminated threads.
If we analyse core files today in AIX ( few of them ) we get,
regcache.c:432: internal-error: get_thread_regcache:
Assertion `thread->state != THREAD_EXITED' failed.
The reason being the aix-thread.c file where root cause is the sync_threadlists()
function. When reading an AIX core file, threads are reported by
libpthread library as being in PST_TERM (terminated) state, which
is correct since process crashed. However, sync_threadlists() was
calling delete_thread() for these terminated threads, marking them
as THREAD_EXITED in GDBs internal state.
Later, when GDB tried to fetchregisters or access frame information
for these threads during core file analysis, it would hit an
assertion in get_thread_regcache() that prevents accessing exited threads.
In AIX we see this in 7.3 from any python3 core file dumps.
The fix is to call sync_threadlists () only for a program in execution and
not for core files.
Consequently, the current code using CTRL_CHAR also explicitly handles RUBOUT
(which is readline's way of representing ^?).
Use c_iscntrl/c_ctrl/c_unctrl instead of CTRL_CHAR/CTRL/UNCTRL, removing
redundant RUBOUT handling code.
Tested on x86_64-linux.
A v1 was submitted here [2].
Changes in v2:
- change $subject to use gdb instead of gdbsupport since we're adding the
new functions in gdb/utils.c
- change parameter and result type of c_unctrl to unsigned char
- avoid using readline macros in c_unctrl implementation
- rewrite c_unctrl to be compatible with c_iscntrl, making sure to handle
^?.
- add c_ctrl
- use c_ctrl/c_iscntrl instead of CTRL/CTRL_CHAR.
Suggested-By: Tom Tromey <tom@tromey.com> [1] Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226136.html
[2] https://sourceware.org/pipermail/gdb-patches/2026-March/226171.html
Alan Modra [Thu, 26 Mar 2026 02:17:05 +0000 (12:47 +1030)]
aout, ecoff and som free_cached_info
By inspection the aout, som and ecoff object targets either do not
support _bfd_check_format[bfd_core], or they use different tdata to
the bfd_object support, eg. i386lynx.c and lynx-core.c. Some use
entirely separate bfd_target vecs for bfd_object vs. bfd_core. In any
of these cases we either should not or do not need to support bfd_core
in their free_cached_info functions.
This patch removes the bfd_core test from free_cached_info for these
targets.
Alan Modra [Wed, 25 Mar 2026 22:18:17 +0000 (08:48 +1030)]
xcoff free_cached_info
Most coff/pe formats allow reading of core files as objects, and so
use struct coff_tdata (or an extension of that struct) in the bfd
tdata field for core files. The xcoff backend uses an entirely
different tdata struct for core files, and therefore can't use
_bfd_coff_free_cached_info.
* coff-rs6000.c (_bfd_xcoff_bfd_free_cached_info): New function.
(_bfd_xcoff_bfd_free_cached_info): Don't define.
* coff64-rs6000.c (rs6000_xcoff64_vec): Use the above.
(rs6000_xcoff64_aix_vec): Likewise.
* libxcoff.h (_bfd_xcoff_bfd_free_cached_info): Declare.
Tom Tromey [Tue, 24 Mar 2026 14:59:31 +0000 (08:59 -0600)]
Hold the GIL while clearing gdbpy_reggroup_object_map
Tom de Vries pointed out that a certain Python test left a core file.
Looking into this, I think the problem is that the GIL is not held
when gdbpy_reggroup_object_map is destroyed.
This patch changes the code to explicitly clear the global while
holding the GIL. This fixed the crash for me.
This also adds a comment to gdbpy_initialize_file to explicitly
mention that the GIL is held while the finalizers are run.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34013 Reviewed-By: Tom de Vries <tdevries@suse.de>
Jan Vrany [Wed, 25 Mar 2026 15:06:23 +0000 (15:06 +0000)]
gdb/python: add property ranges to gdb.Block object
This commit adds a new property - ranges - to gdb.Block object. It holds
a tuple of ranges for that block. Each range is a tuple of (start, end)
address. For contiguous blocks it contains only one range.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Wed, 25 Mar 2026 13:12:11 +0000 (14:12 +0100)]
[gdb/record] Fix syscall exit recording for riscv
[ Submitted earlier [1] with $subject: "[gdb/record] Fix syscall recording for
riscv". ]
On riscv64-linux, I run into:
...
(gdb) continue^M
Continuing.^M
The next instruction is syscall exit_group. It will make the program exit. \
Do you want to stop the program?([y] or n) yes^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
__GI__exit (status=status@entry=0) at _exit.c:30^M
warning: 30 _exit.c: No such file or directory^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit
...
The problem is here in record_insn_len4:
...
/* We are in linux mode. */
return (read_reg (RISCV_A7_REGNUM, reg_val)
&& m_gdbarch->riscv_syscall_record (m_regcache, reg_val) == 0);
...
where return values 1 and -1 are handled the same.
Fix this in the usual way, by passing through the 1 value all the way to
riscv_process_record. That requires changing a few functions from type bool
to int. That's also the case for record_insn_len4, where I factored out
record_insn_len4_1 to keep changes to a minimum.
Also introduce a common enum record_result, and use it instead of hardcoded
1/0/-1.
Tom de Vries [Wed, 25 Mar 2026 13:08:17 +0000 (14:08 +0100)]
[gdb/record] Fix syscall exit recording for arm
[ Submitted earlier [1] with $subject: "[PATCH] [gdb/record] Fix syscall
recording for arm". ]
On arm-linux, I run into:
...
(gdb) continue^M
Continuing.^M
The next instruction is syscall exit_group. It will make the program exit. \
Do you want to stop the program?([y] or n) yes^M
Process record does not support instruction 0xdf00 at address 0xf7e8f984.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
__libc_do_syscall () at libc-do-syscall.S:46^M
warning: 46 libc-do-syscall.S: No such file or directory^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit
...
The problem is this bit of code here in decode_insn:
...
ret = thumb2_record_decode_insn_handler (arm_record);
if (ret != ARM_RECORD_SUCCESS)
{
arm_record_unsupported_insn (arm_record);
ret = -1;
}
...
where ret == 1 is mapped to -1.
The 1 is returned by arm_linux_syscall_record and is meant to be interpreted
using this categorization:
- res < 0: Process record: failed to record execution log.
- res == 0: No failure.
- res > 0: Process record: inferior program stopped.
But the port interprets 1 as ARM_RECORD_FAILURE:
...
enum arm_record_result
{
ARM_RECORD_SUCCESS = 0,
ARM_RECORD_FAILURE = 1
};
...
We could fix this confusion this by:
- adding an ARM_RECORD_UNKNOWN = 2, and
- applying translations at the appropriate points, translating:
- ARM_RECORD_UNKNOWN into 1 and vice versa,
- ARM_RECORD_FAILURE into -1 and vice versa,
similar to what we did for aarch64 and loongarch.
But it seems easier to adopt a go-with-the-flow approach, defining
ARM_RECORD_FAILURE as -1, freeing up the 1 for ARM_RECORD_UNKNOWN = 1.
Then the aforementioned FAIL is fixed by simply doing:
...
if (ret == ARM_RECORD_FAILURE)
arm_record_unsupported_insn (arm_record);
...
Some of the "visibility" linker tests that use a non-PIC shared library
with load offset (first load segment has a non-zero virtual address)
XPASS on s390 64-bit (s390x):
This is due to Alan Modra's commit 125c64931b97 from 2006, which moved
overriddenvar, shlib_overriddencall2, and shared_data from sh1.c to
sh2.c, if the shared library is build non-PIC. This prevents GCC from
treating them as local symbols, preventing the executable from
overriding them, causing the tests to fail because interposition did
not work.
This actually only became visible due to H.J. Lu's commit fd7728c8a4aa
("ld: Update function prototypes for compilers defaulting to -std=gnu23")
from 2025, that fixed the visibility test's function prototypes.
Previously all of the "visibility" tests would appear as UNSUPPORTED, as
the prerequisite compile of main.c would fail due to the function
prototypes not matching with their definitions.
In general creating shared libraries from non-PIC compiled code is not
supported on s390 64-bit (s390x). This is because shared libraries are
inherently position independent. The Glibc dynamic loader common code
passes the virtual address from the first load segment as hint to
mmap(). As a result a shared library with "load offset" may be loaded
at the virtual address used at link-time, but this is not guaranteed.
The following visibility tests using a non-PIC shared library with
load offset XPASS, if the non-PIC shared library is loaded at its link-
time "load offset". This causes the tests to PASS by chance.
This is because visibility_var is local in sh1.c, preventing the
executable from overriding it, causing the tests to fail because
interposition does not work.
Note that all of the visibility tests using a non-PIC shared library
without load offset XFAIL, as they are loaded at a random address, which
is incompatible with non-PIC code.
Skip all non-PIC shared library "visibility" linker tests on s390 64-bit
(s390x) as unsupported. In contrast to PowerPC and MIPS do not skip
all of the "visibility" linker tests.
Tom de Vries [Wed, 25 Mar 2026 07:03:01 +0000 (08:03 +0100)]
[gdb/remote] Use sevenbit_strings == true in escape_buffer
With Fedora RH, using Tcl 9.0.2, I run into:
...
(gdb) break -q main^M
[remote] Sending packet: $qXfer:auxv:read::0,1000#6b^M
[remote] Packet received: l!\000\000\000\000\000\000\000\000 ERROR: \
i_read(spawn_id fd=9): invalid or incomplete multibyte or wide character
...
UNRESOLVED: gdb.server/bkpt-other-inferior.exp: inf 2: set breakpoint
...
For reference, on openSUSE Leap 16.0, with Tcl 8.6.15 the initial part of the
problematic string looks like:
...
[remote] Packet received: l!\000\000\000\000\000\000\000\000`ü÷ÿ\177\000...
...
With Tcl 9.0, something (dejagnu/expect/gdb testsuite infrastructure)
has problems with gdb IO containing non-utf-8 chars.
Having said that, I don't think having chars like 'ü' in the debug output is
particularly helpful.
Fix this by forcing sevenbit_strings to true in escape_buffer, getting us
instead:
...
[remote] Packet received: \
l!\000\000\000\000\000\000\000\000`\374\367\377\177\000...
...
This also fixes test-case gdb.python/py-send-packet.exp, where we run into a
similar problem with the "Sending packet:" line.
Tested on x86_64-linux, with Tcl 9.0.2 and 8.6.15.
A v1 submitted was submitted here [2].
Changes in v2 [3]:
- use c_isprint instead of std::isprint
- use string_appendf instead of std::ostringstream
Changes in v3:
- Rather than re-implementing escape_buffer, change it to use
sevenbit_strings == true.
- update $subject to indicate new approach
The 'x' command takes an arbitrary expression as its argument,
evaluates it to a value, and treats the value as the address to read
from. How many bytes to read from that address is decided based on
the specified format, from which a type is derived. One can see this
in the `$_` convenience variable that holds the last address read
from.
For example, suppose we have an integer variable and we want to
examine the memory where the variable is located.
(gdb) list
36 int main(int argc, char *argv[]) {
37 int a = 42;
38
39 return 0;
40 }
(gdb) print &a
$1 = (int *) 0x7fffffffdddc
(gdb)
Note that `&a` gives us an `int *`. Let's now examine the memory at
`&a`.
Note the type of `$_`: `int16_t *`, not `int *`, although the argument
was a `int *`.
This happens because the 'x' command is a low-level command and GDB
does not care much about the type of the argument; it is rather
interested in using the evaluated value as an address. GDB simply
discards the type of the argument. The format 'h' (half word)
determines the type `int16_t`, with which GDB creates a lazy value.
It is this lazy value with the `int16_t` type that fetches the data
from the target.
The problem with this is that if the argument type contains address
class information, the information would be ignored. Let's use GDB's
builtin `@data` modifier:
The `@data` modifier was dropped as can be seen in the type of `$_`.
On an architecture where data and code pointers have to be
distinguished, or where architecture-specific address classes are
available, the 'x' command would not work.
Address the problem by propagating the type instance flags of the
argument to the type constructed from the format.
Side note:
The 'x' command remembers the next address and can be
re-used without an argument:
(gdb) x
0x7fffffffddde: 0
(gdb) x
0x7fffffffdde0: 1
(gdb) x
0x7fffffffdde2: 0
(gdb) x
0x7fffffffdde4: 0
(gdb) print $_
$5 = (@data int16_t *) 0x7fffffffdde4
(gdb)
With this patch, it also becomes possible to use the "next address"
feature of the 'x' command.
End side note.
A final remark: There exists a `pointer_to_address` gdbarch method.
One can wonder whether it not already solves the problem. The thing
is, that gdbarch method would change the bits of the address and this
may not be possible/meaningful on some architectures.
gdb: track type instead of gdbarch for `next_address`
The `next_address` global that is used for tracking the next address
to show in the 'x' command is declared as plain CORE_ADDR. In
addition to this CORE_ADDR, a gdbarch is also being tracked, so that
the right type can be determined based on the format specified by the
user.
In GDB, a pointer may be pointing to a particular address class. This
is indicated in the type instance flags of the pointer's target type.
In case an address class other than the default one is being pointed
at, the data needs to be fetched from the target accordingly. Hence,
in addition to the CORE_ADDR and gdbarch, we also need to track the
address class of the next address.
Rather than adding one more variable to the global state, we can track
the type instead of gdbarch. The architecture can be obtained from
the type anyway.
This patch does the refactoring to replace the `next_gdbarch` global
with the `next_type` global. No observable change in the behavior of
GDB is expected.
The type instance flags that may carry address class information
mentioned above are still lost, though. The next patch handles this
problem, while this patch focuses on the refactoring only.
`do_examine` takes a `gdbarch` argument and a `CORE_ADDR` argument,
and assigns them to the `next_gdbarch` and `next_address` globals.
The function then interchangeably uses the `gdbarch` parameter and the
`next_gdbarch` global. It may also update the `next_address` global.
Because of these, the function contract is blurred. Since the
function already depends on the global state and updates it, remove
the parameters and use the global state more cleanly. The callers
must set the global state properly before calling this function.
Rename the function to `do_examine_next_address` to make the intent
clearer.
In this patch, we still assign the global variable to a local variable
and use that local var. The reason is twofold: (1) lines become
shorter; (2) the refactorings in the subsequent patches become
cleaner. In particular, in a future patch, 'next_gdbarch' global var
is completely removed but a gdbarch is still needed. Using a local
var helps keep that patch cleaner.
Tom de Vries [Tue, 24 Mar 2026 15:38:32 +0000 (16:38 +0100)]
[gdb/tui] Remove local CTRL_CHAR definition
In gdb/tui/tui-io.c we have a local definition of CTRL_CHAR:
...
/* Use definition from readline 4.3. */
#undef CTRL_CHAR
#define CTRL_CHAR(c) \
((c) < control_character_threshold && (((c) & 0x80) == 0))
...
We require readline >= 7.0, so we can expect the definition to be available.
Tom de Vries [Tue, 24 Mar 2026 13:58:11 +0000 (14:58 +0100)]
[gdb/ada] Use c_isupper in ada_decode
Commit cfe3a766e64 ("Change ada_decode to preserve upper-case in some
situations") changed a use of c_isupper into isupper:
...
$ git show cfe3a766e646| grep isupper
+ else if (isupper (encoded[i]) || encoded[i] == ' ')
- if (c_isupper (decoded[i]) || decoded[i] == ' ')
...
Apparently this was an oversight [1].
Fix this by using c_isupper.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226136.html
Add support for recording minimal symbols in AIX for non DWARF compiled library function record.
Commit 1dfd89c739 (gdb: Remove stabs support from XCOFF inferiors) removed STABS handling from xcoffread.c.
While removing full symtab and compunit_symtab construction is appropriate when DWARF is available,
the change also removed recording of minimal symbols, which still provide value for XCOFF binaries that lack DWARF.
On AIX, system libraries such as libc and libpthread are built with STABS debug information up to AIX 7.3 TL4.
As a result, current GDB master is unable to record even minimal symbols for these libraries, leading to missing function names (e.g. printf) in common debugging scenarios.
When we compile this in GDB in AIX today in master branch we get,
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) r
Starting program: /gdb_tests/main
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call printf()
No symbol "printf" in current context.
(gdb)
The issue is Without minimal symbols:
- Functions from system libraries are not visible in backtraces.
- Calls such as call printf() fail with no symbol in current context.
- This affects not only stepping, but also basic usability of backtraces on AIX systems without DWARF-enabled system libraries.
- Even when full debug information is unavailable, minimal symbols are still sufficient to:
- Identify function entry/exit points.
- Display meaningful backtraces involving system libraries.
This patch restores recording of minimal symbols in xcoffread.c, while keeping the removal of:
- STABS-based symtabs
- compunit_symtabs
The below function (read_xcoff_minimal_symbols) ensures that:
- record_minimal_symbol() is still invoked where appropriate.
- No attempt is made to rebuild full debug information from STABS.
- DWARF remains the sole source for full debugging information when available.
This keeps the original intent of the STABS removal intact, while restoring essential functionality for non-DWARF XCOFF binaries.
After applying the patch we get,
GNU gdb (GDB) 18.0.50.20260316-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 "powerpc64-ibm-aix7.2.0.0".
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". |
+------------------------------------------------------------------------------+
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) n
The program is not being run.
(gdb) r
Starting program: /gdb_tests/main
Tom Tromey [Sun, 11 Jan 2026 21:28:12 +0000 (14:28 -0700)]
Apply styling to error messages
This patch changes gdb to apply styling to error messages. The
approach taken is that styling is always applied when forming an
exception's string value; and then if styling is not desired, the
styling is stripped before printing.
Tom Tromey [Wed, 14 Jan 2026 13:34:56 +0000 (06:34 -0700)]
Change two ui_file subclasses to templates
This patch changes escape_buffering_file and no_terminal_escape_file
to be template classes. Currently these both derive from stdio_file,
but in a coming patch that won't be desirable. This change makes it
easy to instantiate these classes in a couple of different ways.
The implementation is hidden and so explicit instantiations are done
in ui-file.c. This seems fine since in practice there aren't going to
be many of these.
Tom Tromey [Wed, 14 Jan 2026 17:51:44 +0000 (10:51 -0700)]
Add wrapped_file::write
This adds an implementation of wrapped_file::write. With this change,
a wrapped_file can be used as-is, without requiring a subclass. This
is convenient for a subsequent patch.
An existing subclass is simplified due to this change.
Andrew Burgess [Fri, 20 Mar 2026 15:05:16 +0000 (15:05 +0000)]
gdb/python: allow Architecture.disassemble to give styled output
Extend the Architecture.disassemble API to allow the user to request
styled disassembler output via a new styling argument. A user can now
write:
insn = arch.disassemble(address, styling = True)
The instruction strings returned within INSN will contain ANSI escape
sequences so long as 'set style enabled on' is in effect. This means
that the user's personal settings (disabling styling) will override a
GDB extension that requests styled disassembler output. I think this
makes sense.
The default for the styling argument is False, this maintains the
current unstyled output as default.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Sun, 22 Mar 2026 16:08:31 +0000 (17:08 +0100)]
[gdb/tdep] Eliminate ostringstream use from arc_check_tdesc_feature
We generally avoid C++ streams in GDB sources [1].
Remove an instance of std::ostringstream in arc_check_tdesc_feature.
While we're at it, fix an array index bug:
...
- reg_names << " or '" << reg.names[0] << "'";
+ string_appendf (reg_names, " or '%s'", reg.names[i]);
...
Tested on x86_64-linux, using a trigger patch:
...
- if (!found && reg.required_p)
+ if (true || (!found && reg.required_p))
...
and doing "maint selftest" and observing the output:
...
Running selftest unpack_field_as_long::ARC600.
Error: Cannot find required register(s) 'r0' in feature 'org.gnu.gdb.arc.core'.
Error: Cannot find required register(s) 'pc' in feature 'org.gnu.gdb.arc.aux'.
...
Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226117.html
Tom Tromey [Thu, 12 Mar 2026 20:00:44 +0000 (14:00 -0600)]
Add lock_guard to thread_pool::thread_count
I think there's a possible race when calling thread_pool::thread_count
from a worker thread, if the main thread changes the number of threads
at the same time.
When this code was initially written, we didn't worry about this,
because this was only accessed from the main thread. This is no
longer the case, though.
This patch fixes any potential problem by adding a lock_guard to the
method. This doesn't seem too harmful because this is not called very
much and because I doubt this lock is highly contended.
While doing this I noticed that thread_pool::do_post_task could access
m_sized_at_least_once and m_thread_count without holding the lock.
This patch changes this method as well.
What this tells us is that lookup_selected_frame MUST ensure that
selected_frame is not NULL before it returns. I ran into a case where
this guarantee is broken, lookup_selected_frame can leave selected_frame
as NULL, and the assertion in get_selected_frame triggers.
I started looking at this code while reviewing the debuginfod patches that
can be found here:
[ NOTE: The patch isn't exactly like that, but that's basically the idea,
I've just simplified things here as the details are not important. ]
The problem that was encountered with the debuginfod patches is that, with
the changes in that series, it becomes more likely that
lookup_selected_frame can fail to set selected_frame, but, due to details
specific to that patch, the failure can only happen the first time
lookup_selected_frame is called.
It occurred to me during review, that, if I could find a way to replicate
that problem outside the specifics of debuginfod, then I could submit that
part of the patch separately, and this would reduce the size of the
debuginfod patch set, and make that patch easier to review.
So I looked for other ways that I could cause lookup_selected_frame to
fail.
In the end I wasn't able to truly reproduce the same issue that the
debuginfod patch has, which means I cannot post the above fix here. But I
did find some bugs that I then fixed, and I though it would be worth
posting them anyway.
I'm aware that I'm really getting into some nasty edge cases here, doing
things that most users will never do, so these fixes are unlikely to ever
be of real value, but they aren't huge, and I figure it doesn't hurt to
cover these edge cases.
So, with that all said, what's the problem? The selected frame is stored
as a frame level and frame-id. The job of lookup_selected_frame is to
lookup the actual frame_info_ptr and call select_frame to set the global
selected_frame variable.
If the frame described by the level and frame-id cannot be found then
lookup_selected_frame should (if level > 0) give a warning and select the
innermost frame. We don't give a warning if the frame we're trying to
select is #0 as the default action, selecting frame #0 is close enough,
even if it's a different frame #0 than the one we're expecting.
This fall back case, and the associated warning is not currently tested,
so this patch adds a test that triggers this case. To do this we setup a
call stack, select a frame other than #0, then within a 'thread apply',
pop frames from the stack using 'return'. When the 'thread apply'
completes GDB tries to restore the previously selected frame, but that
frame has now been popped from the stack and no longer exists. GDB will
print the warning and select frame #0 instead.
This tests the warning, but still isn't enough to trigger the assertion.
To do that we have to go a little further. The fall back code in
lookup_selected_frame looks like this (I've simplified this a little):
/* Select the innermost stack frame. */
select_frame (get_current_frame ());
/* Warn the user. */
if (frame_level > 0)
{
warning (_("Couldn't restore frame #%d in "
"current thread. Bottom (innermost) frame selected:"),
frame_level);
It is the select_frame call which sets the selected_frame global. If we
can find a way to set the back to NULL after the select_frame call then we
will trigger the assertion.
We already have a mechanism for setting selected_frame to NULL from Python
code, the gdb.invalidate_cached_frames function. So the only remaining
question is, can we invoke a Python callback after the select_frame call?
And yes, we can. Printing a frame will trigger the pretty printers. Now,
in real code there's no reason at all that a pretty printer should ever
need to call gdb.invalidate_cached_frames, or call anything that needs to
then call gdb.invalidate_cached_frames, which is why I started off by
saying that this really is an edge case. But, for a moment, lets just run
with it.
So we setup a pretty printer which invalidates the frame cache, setting
selected_frame back to NULL. We ensure this is run when GDB prints the
fall back frame, and now we leave lookup_selected_frame with
selected_frame set to NULL, and the assertion triggers.
The fix is really easy. Move the select_frame call after the
print_stack_frame call (outside the 'if' block). The print_stack_frame
call needs to be updated to print the current frame rather than the
selected frame, as the current frame is no longer selected at the point we
are printing the frame now.
With this done the assertion is fixed. There is just one theoretical bug
that I haven't tried to fix; if the pretty printer changed the machine
state then it is possible that the current frame that's selected is not
the current frame that was printed. This could be confusing, but not I
think fatal. Trying to fix this felt like taking things too far, so I've
left this for now.
While I was here I changed the wording of the warning message. The old
warning included the words "Bottom (innermost) frame selected", but our
manual doesn't really use the word "bottom" to describe the innermost
frame, we just say innermost. So I updated the text to say "Innermost
frame selected". Given we then print the stack frame, which includes the
"#0" tag, I think this is all perfectly clear, and lines up with the
wording in our documentation.
Having written all of the above I realised I could extend the test to
cover an additional, but related case. Using the same setup, I run
the inferior to a point where the stack has 5 frames in it. I select
frame #2 just as before, but now, instead of popping all frames
including frame #2, I just pop frames #0 and #1. The logic in
lookup_selected_frame first tries to find the frame at the expected
level, in this case #2. But after popping the frames, the frame at
level 2 will not be the expected frame. But lookup_selected_frame
already handles this, and if the find frame by level logic fails, we
instead search for the frame by frame-id. And this is what allows
this additional test to pass, the previous frame #2 has now become
frame #0, and this frame is selected as expected.
Evgeny Karpov [Fri, 20 Mar 2026 13:09:33 +0000 (14:09 +0100)]
Adjust pdata function table entries sorting for AArch64
The .pdata section contains an array of function table entries that
are used for exception handling. The entries should be sorted by
begin address, which is usually the first 4 bytes RVA in the entry.
Entry sizes are different for x64 and AArch64.
This difference is addressed in this patch.
This is the first patch in the patch series implementing
Structured Exception Handling (SEH) for aarch64-w64-mingw32.
Jan Beulich [Fri, 20 Mar 2026 13:08:12 +0000 (14:08 +0100)]
x86: drop iamcu as default secondary target
It's not clear why this would have been forced onto about everyone
x86-ish. People wanting this as secondary target can specify it via the
--enable-targets= configure option.
Obviously a few tests cannot be run then anymore by default, but only when
IAMCU is actually the/a configured target.
While there also consolidate bfd/config.bfd entries doing identical
selections.
Andrew Burgess [Mon, 23 Feb 2026 13:27:56 +0000 (13:27 +0000)]
gdb/riscv: use register number for 'info reg' output format choice
On RISC-V the 'info register' format for floating point registers
includes the raw register value printed as hex. While reviewing an
upstream patch[1] I realised that this raw hex output was no longer
working, but no tests had started to fail.
It's the '(raw 0x0000000000000000)' part that was missing once I had
applied series[1].
This commit does a few things. First, I've extended an existing test
to check that the raw register value is printed. I've updated the
same test to use to '-wrap' option to gdb_test_multiple. And in
addition, in the case where the register type is a union (as in the
above example), I've relaxed the test so we no longer assume that the
field named 'float' is the first field of the union, a similar change
was part of the upstream series I was reviewing[2], so I figured I
might as well throw this in here.
The reason that patch series[1] broke the raw output, is that in
riscv_print_one_register_info, in order to identify a floating point
register, we currently inspect the register's type. If the register
is of type float, or is a 2 or 3 element union, where each element is
a float, then we consider the register a floating point register, and
print it with the additional raw format.
In this commit I've switched to just checking the register number. If
we're in the FP register range then we handle this as a floating point
register.
The code being changed here was introduced in commit:
The commit message seems to indicate that this code was only ever
intended to identify the standard floating point registers, and I'm
not aware of any other RISC-V registers that would need printing with
the additional raw format, so I think the register number check should
be fine.
As such, there should be no user visible changes after this commit.
With Tcl 9.0 and test-cases gdb.ada/non-ascii-latin-{1,3}.exp we run into
similar problems as reported in the previous patch.
Work around this by avoiding non-UTF-8 chars in:
- gdb input by using a command file, and
- gdb output by not printing a source line containing such chars
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
When running test-case gdb.python/py-source-styling.exp with Tcl 9.0, I get:
...
python gdb.execute('list 26')^M
<SNIP>/* The following line contains a character that is non-utf-8. This is a
<SNIP> critical part of the test as Python 3 can't convert this into a string
<SNIIP> using its default mechanism. */
<SNIP>FAIL: $exp: test_source_cache_style_tracking: \
python gdb.execute('list 26') (timeout)
ERROR: i_read(spawn_id fd=9): invalid or incomplete multibyte or wide character
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" POSIX EILSEQ {invalid or incomplete multibyte or wide \
character} i_read(spawn_id fd=9)
: invalid or incomplete multibyte or wide character
Couldn't send python gdb.execute('list 26', to_string=False, styling=True) to GDB.
...
I have tried a fix similar to the previous commit in default_gdb_spawn:
...
+ if {[tcl_version_at_least 9 0 0]} {
+ set fd [exp_open -leaveopen -i $res]
+ fconfigure $fd -encoding utf-8 -profile replace
+ }
+
...
but that doesn't seem to work.
Work around this by skipping the part that runs into this problem.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix error: invalid or incomplete multibyte or wide character
With Tcl 9.0 and test-case gdb.python/py-source-styling.exp, I run into:
...
ERROR: tcl error sourcing gdb.python/py-source-styling.exp.
ERROR: tcl error code POSIX EILSEQ {invalid or incomplete multibyte or wide character}
ERROR: error reading "file8": invalid or incomplete multibyte or wide character
while executing
"read $fh"
(procedure "auto_lappend_include_files_1" line 14)
...
Fix this by using "fconfigure $fh -encoding utf-8 -profile replace" [1] in
auto_lappend_include_files_1. Likewise in gdb_get_line_number.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix uninitialized string in gdb.fortran/function-calls.f90
With Tcl 9.0 and test-case gdb.fortran/function-calls.f90 I run into:
...
(gdb) run ^M
Starting program: function-calls ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
(2.09999990,3.29999995)^M
4 5^M
23^M
(2.09999990,3.29999995)^M
3.40000010 ^M
6^M
^K^@^@^@^@^@^@^@ERROR: i_read(spawn_id fd=9): invalid or incomplete multibyte or wide character
...
The problem seems to be the printing of an uninitialized string.
Fix this by initializing the string.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix clipping by format %x
With test-case gdb.fortran/logical.exp and Tcl 9.0, I ran into:
...
(gdb) set *((character *) 0x7fffffffd8ec) = 0xff^M
(gdb) PASS: $exp: var=l: byte 0: set contents of byte at offset 0
p l^M
$8 = .TRUE.^M
(gdb) PASS: gdb.fortran/logical.exp: var=l: byte 0: p l
set *((character *) 0xffffd8ed) = 0xff^M
Cannot access memory at address 0xffffd8ed^M
(gdb) FAIL: $exp: var=l: byte 1: set contents of byte at offset 1
...
So there are two writes:
- for the first write at offset 0, we use address: 0x7fffffffd8ec
- for the second write at offset 1, we use address: 0xffffd8ed.
The address got clipped by using %x with command format:
...
incr addr
set addr [format "0x%x" $addr]
...
Fix this by using "%lx" instead.
Likewise in two other test-cases.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix error: invalid character in array index
With test-case gdb.cp/inherit.exp and Tcl 9.0, I run into:
...
ERROR: tcl error sourcing gdb.cp/inherit.exp.
ERROR: tcl error code NONE
ERROR: invalid character in array index
while executing
"set in_class_table $cp_class_table_history("
invoked from within
"if {$in_class_table == "ibid"} {
if {![info exists cp_class_table_history("$in_key,$in_tag")]} {
...
Fix this by dropping the double quotes in
'cp_class_table_history("$in_key,$in_tag")'.
Likewise in gdb.cp/ovldbreak.exp.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix Tcl version check
With Tcl 9.0, we get:
...
ERROR: tcl error sourcing tool init file lib/gdb.exp.
version conflict for package "Tcl": have 9.0.2, need 8.6.2
version conflict for package "Tcl": have 9.0.2, need 8.6.2
while executing
"package require Tcl 8.6.2"
(file "lib/gdb.exp" line 20)
...
Fix this by using tcl_version_at_least.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite, Tcl 9.0] Fix use of deprecated trace variable subcommand
With Tcl 9.0, we get:
...
bad option "variable": must be add, info, or remove
while executing
"trace variable "boards_dir" w append_gdb_boards_dir"
(file "lib/append_gdb_boards_dir.exp" line 48)
...
The trace subcommand "trace variable <name> <ops> <command>" [1]:
- is equivalent to "trace add variable <name> <ops> <command>"
- is for backwards compatibility,
- uses "an older syntax in which array, read, write, unset are replaced by a,
r, w and u respectively",
- has an ops argument which is "not a list, but simply a string concatenation
of the operations", and
- is "deprecated and will likely be removed in a future version of Tcl".
Fix this by using "trace add variable":
...
-trace variable "boards_dir" w append_gdb_boards_dir
+trace add variable "boards_dir" {write} append_gdb_boards_dir
...
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948
Tom de Vries [Fri, 20 Mar 2026 09:13:27 +0000 (10:13 +0100)]
[gdb/testsuite] Clean up globals saving in gdb.tui/tuiterm.exp
In test-case gdb.tui/tuiterm.exp, I came across this proc:
...
proc setup_terminal { cols rows } {
setenv TERM ansi
Term::_setup $rows $cols
}
...
and I wondered why we're not using save_vars ::env(TERM) in here.
Then I found out that this happens via run_one_test_small, which calls
setup_small, which calls setup_terminal:
...
proc setup_small {} {
setup_terminal 8 4
...
}
...
proc run_one_test_small { test_proc_name } {
save_vars { env(TERM) stty_init } {
setup_small
$test_proc_name
}
}
...
There are a couple of problems here:
- the proc test_attrs calls setup_terminal, but doesn't do any
saving/restoring
- the saving/restoring in run_one_test_small doesn't work, because the
variable names don't have global scope
- both env(TERM) and stty_init aren't actually used in the test.
Fix this by:
- dropping the setting of env(TERM)
- moving the saving/restoring of stty_init to setup_terminal
Tom de Vries [Thu, 19 Mar 2026 22:33:06 +0000 (23:33 +0100)]
[gdb/tdep] Fix unrelocated pc in i386_displaced_step_fixup
With test-case gdb.threads/next-fork-other-thread.exp and target board
unix/-m32 I run into:
...
(gdb) next
[Switching to Thread 0xf643ab40 (LWP 3267939)]
Thread 5 "next-fork-other" hit Breakpoint 1, main () at \
next-fork-other-thread.c:73
73 alarm (60);
(gdb) FAIL: $exp: fork_func=fork: target-non-stop=off: non-stop=off: \
displaced-stepping=on: i=$n: next to break here
...
Before we go into how this happens, let's first look at the inferior.
In main, 4 threads are started with the same thread function, leaving all 5
threads in a loop:
- the main thread is stuck in a loop calling sleep, and gdb steps through this
loop using next
- the other, non-main threads are stuck in a loop where each thread:
- forks off a child process that exits immediately
- waits for the child process to exit
- calls sleep
The FAIL happens as follows (following snippets from this gdb.log [1]).
One of the non-main threads enters __syscall_cancel_arch to do a sycall (
either to sleep, or to wait).
Then the non-main thread stops:
...
[infrun] handle_signal_stop: [2937316.2937324.0] hit another thread's \
single-step breakpoint
[infrun] handle_signal_stop: delayed software breakpoint trap, ignoring
[infrun] switch_back_to_stepped_thread: need to step [2937316.2937324.0] \
over single-step breakpoint
...
because we "hit another thread's single-step breakpoint".
AFAIU, this is because of the main thread stepping through
__syscall_cancel_arch.
To handle this, we're going to try displaced stepping.
The syscall instruction is copied:
...
[displaced] displaced_step_prepare_throw: original insn 0xf7cdce69: \
cd 80 int $0x80
[displaced] prepare: selected buffer at 0x80490d2
...
to a buffer at _start+2:
... 080490d0 <_start>: 80490d0: 31 ed xor %ebp,%ebp 80490d2: 5e pop %esi
...
and we're going to resume execution there.
However, right after resuming we get a GDB_SIGNAL_CHLD for the same thread.
Part of handling that is finalizing the displaced stepping:
...
[displaced] finish: restored 2937316.2937324.0 0x80490d2
[displaced] i386_displaced_step_fixup: fixup (0xf7cdce69, 0x80490d2), \
insn = 0xcd 0x80 ...
[displaced] i386_displaced_step_fixup: syscall changed %eip; not relocating
[infrun] handle_signal_stop: stop_pc=0x80490d2
...
The stop pc is 0x80490d2, the address of the copied instruction. In other
words, we've stopped without making progress.
The problem is that the address is in the displaced stepping buffer, and needs
relocating, but instead we have "syscall changed %eip; not relocating".
The code in i386_displaced_step_fixup doesn't recognize this situation:
...
if (i386_syscall_p (insn, &insn_len)
&& pc != to + (insn - insn_start) + insn_len
/* GDB can get control back after the insn after the syscall.
Presumably this is a kernel bug.
i386_displaced_step_copy_insn ensures it's a nop,
we add one to the length for it. */
&& pc != to + (insn - insn_start) + insn_len + 1)
displaced_debug_printf ("syscall changed %%eip; not relocating");
...
It only handles the cases where the stop pc is:
- the address after the syscall insn, or
- the address after the nop after the syscall insn
So, instead of relocating the stop pc back to the original 0xf7cdce69, it
stays 0x80490d2. After resuming at that address, the thread:
- executes the syscall,
- executes the rest of _start,
- enters main, and
- runs into the breakpoint at the start of main.
Since commit cf141dd8ccd ("gdb: fix reg corruption from displaced stepping on
amd64"), we do handle the "pc == to" case in amd64_displaced_step_fixup:
...
if (amd64_syscall_p (insn_details, &insn_len)
/* GDB can get control back after the insn after the syscall.
Presumably this is a kernel bug. Fixup ensures its a nop, we
add one to the length for it. */
&& (pc < to || pc > (to + insn_len + 1)))
displaced_debug_printf ("syscall changed %%rip; not relocating");
...
Fix this in the same way.
Tested on x86_64-linux, with target board unix/-m32.
On openSUSE Tumbleweed (kernel version 6.19.7), this patch fixes the test-case.
On openSUSE Leap 16.0 (kernel version 6.12.0), we still run into PR29040.
Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33997
Andrew Burgess [Tue, 17 Mar 2026 14:53:48 +0000 (14:53 +0000)]
gdb: change new_objfile observer to take an objfile reference
I was looking at the new_objfile observer and noticed a comment in
reread_symbols (symfile.c) that seemed out of date, it talked about
calling the new objfile observer with a NULL objfile argument.
A little digging indicates that the comment is indeed out of date, and
that we never call the new_objfile observer with a NULL argument any
more.
So in this commit I have:
1. Updated the out of date comment in reread_symbols.
2. Changed the argument type for the new_objfile observer from
'objfile *' to 'objfile &'. Passing a NULL pointer is no longer
an option.
3. Updated the existing new_objfile observers to take 'objfile &'
and updated their implementations as needed.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Sat, 14 Mar 2026 19:06:01 +0000 (15:06 -0400)]
gdb: make find_memory_region_ftype a function_view
Make it a function_view and remove the `void *` parameter. Convert the
callers (in gcore.c) to use lambda functions that capture `obfd`.
The target_debug_print_find_memory_region_ftype debug printer isn't
terribly useful, but I don't see a good way to print a function_view
with what we have right now.
Since find_memory_region_ftype needs to be seen by both gdbarch.h and
target.h, I chose to move the typedef to a new file
(find-memory-region.h), that is included by both.
Change-Id: I9d24d31da31e5fe0439124cec1a9757ad226b222 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Thu, 19 Mar 2026 10:11:32 +0000 (11:11 +0100)]
[gdb/testsuite] Handle too many watchpoints in gdb.base/watchpoint-adjacent.exp
On i686-linux, with test-case gdb.base/watchpoint-adjacent.exp I run into:
...
(gdb) watch obj.b^M
Hardware watchpoint 5: obj.b^M
Warning:^M
Could not insert hardware watchpoint 5.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: $exp: var_type=type_ll: test= a {a b} : rwatch_first=true: \
watch obj.b
...
The CPU supports 4 hardware watchpoints of 4 bytes, and the test-case attempts
to set 3 hardware watchpoints of 8 bytes.
Tom de Vries [Thu, 19 Mar 2026 09:55:46 +0000 (10:55 +0100)]
[gdb/tui] Add tui_try_activate
In tui/tui.c, there this type of pattern related to activating TUI:
...
static int
tui_rl_delete_other_windows (int notused1, int notused2)
{
if (!tui_active)
tui_rl_switch_mode ();
if (tui_active)
tui_remove_some_windows ();
return 0;
}
...
Add a new function tui_try_activate that allows us to write the shorter:
...
static int
tui_rl_delete_other_windows (int notused1, int notused2)
{
if (tui_try_activate ())
tui_remove_some_windows ();
Tom de Vries [Thu, 19 Mar 2026 09:55:46 +0000 (10:55 +0100)]
[gdb/tui] Remove unnecessary nullptr check in tui_rl_other_window
In tui_rl_other_window, we check for win_info != nullptr:
...
win_info = tui_next_win (tui_win_with_focus ());
if (win_info)
tui_set_win_focus_to (win_info);
...
but that's also done in tui_set_win_focus_to, so drop it here.
Alan Modra [Thu, 19 Mar 2026 09:08:58 +0000 (19:38 +1030)]
mips64*-linux-gnuabi64 ld tests
I noticed recently that my mips64-linux-gnuabi64 binutils build was
not doing compiled ld tests due to check_compiler_available returning
false, despite having a cross-compiler installed. My compiler fails
to build the test executable when both -mabi=n32 and -L options with
the lib64 dir first are passed, complaining
ld-new: .../lib64/libgcc_s.so.1: error adding symbols: file in wrong format
The -mabi=n32 comes from config/default.exp, the -L options from
genscripts.sh via libpath.exp. The -mabi=n32 is wrong because
contrary to the comment in default.exp, the abi64 compiler does not
default to N32. And the -L options interfere with the correct -L
passed by the compiler for -mabi=n32.
* testsuite/config/default.exp (mips64*-*-linux*): Do not
supply -mabi=n32 for abi64 configuration.
Eric Botcazou [Wed, 18 Mar 2026 11:49:23 +0000 (12:49 +0100)]
ld/ELF: Fix small issue with orphan sections and NOLOAD output section
What happens is that the effect of the command:
.foo (NOLOAD) : {}
is not equivalent to that of:
.foo (NOLOAD) : { *(.foo) }
when there is more than 1 object file containing a .foo section: the former
will output two .foo sections, the first with PROGBITS and the second with
NOBITS, where the latter will output only one with NOBITS.
Given that the commands are essentially equivalent, the linker ought to
yield the same outcome, namely the single output section with NOBITS.
Keith Seitz [Thu, 16 Oct 2025 15:29:05 +0000 (08:29 -0700)]
infcall: Add support for integer literals as reference function parameters
This patch attempts to mitigate the shortcomings of passing literals
to inferior function calls requiring references. The specific use case here
is std::map's operator[]:
std::map int_map<int, int>;
int_map[1] = 10;
(gdb) print int_map[1]
Attempt to take address of value not located in memory.
This is occurring because while value_coerce_to_target understands
that some values need to be allocated and copied to the inferior's
memory, it only considers the actual parsed type of the argument value,
ignoring the actual type of the function parameter. That is,
in this specific case, the value's parsed type is TYPE_CODE_INT, but
the function requires TYPE_CODE_REF. We need to account for the
reference.
In value_arg_coerce, we have special handling for references, but it
has not specifically dealt with this case. It now checks if the
reference is in memory, and if it isn't, it copies it, if the type
is trivially copyable.
As a result of this patch, the last remaining failure in c++/15372 is now
fixed, and that bug can be closed.
With this patch, we can now print map entries with integer keys:
Oleg Endo [Wed, 11 Mar 2026 02:55:20 +0000 (11:55 +0900)]
sim/sh: check PFSCR.PR setting for fldi0 and fldi1 insns
On SH variants with double-precision FPU the insns fli0 and flid1 are only
defined when FPSCR.PR = 0. The hardware does not necessarily trap but might
quietly load undefined values. However, qemu traps in that case, so do the
same.
GDB: aarch64-linux: Fix build failure on musl systems
When building against musl (e.g. on Alpine Linux), the following error
happens:
CXX linux-aarch64-low.o
In file included from /home/bauermann/src/binutils-gdb/gdbserver/linux-aarch64-low.cc:48:
/home/bauermann/src/binutils-gdb/gdbserver/../gdb/nat/aarch64-gcs-linux.h:36:8: error: redefinition of 'struct user_gcs'
36 | struct user_gcs
| ^~~~~~~~
In file included from /home/bauermann/src/binutils-gdb/gdbserver/linux-aarch64-low.cc:36:
/usr/include/asm/ptrace.h:329:8: note: previous definition of 'struct user_gcs'
329 | struct user_gcs {
| ^~~~~~~~
make[2]: *** [Makefile:565: linux-aarch64-low.o] Error 1
aarch64-linux-tdep.c fails to build in the same way. This happens because
aarch64-gcs-linux-ptrace.h uses GCS_MAGIC to see whether the system headers
have GCS-related definitions. The problem is that GCS_MAGIC is defined in
<asm/sigcontext.h> while struct gcs_user is defined in <asm/ptrace.h>.
It's fine on glibc systems because in the set of system headers that
linux-aarch64-low.cc and aarch64-linux-tdep.c include, <asm/sigcontext.h>
ends up being included implicitly as well. This doesn't happen when using
musl's headers though.
There isn't a macro in <asm/ptrace.h> whose presence is correlated with
the presence of the struct user_gcs definition, so a configure check is
needed to detect it and conditionally define the struct.
Note that there's another build issue with musl, described in
PR gdb/33747 affecting compilation of gdb/ser-unix.c. In order to be
able to test this patch, I applied the patch in comment 11 there.
Tested with a native build on an Alpine Linux aarch64 system, and also
verified that all gdb.arch/aarch64-gcs*.exp tests pass on it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33926 Co-authored-by: Chris Packham <judge.packham@gmail.com> Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Only native code should use struct user_gcs, so its definition should be
in a native-specific file and not in a file under gdb/arch/.
To fix this problem, create gdb/nat/aarch64-gcs-linux.h and move the
struct user_gcs definition to it, as suggested by Luis.
To fix the use of struct user_gcs in gdb/aarch64-linuxt-dep.c, define a
macro with the size of the GCS regset in gdb/arch/aarch64-gcs-linux.h
and use it in aarch64-linux-tdep.c, as is done for other regsets and
following a suggestion from Simon Marchi.
Also, move the HWCAP_GCS definition to gdb/nat/aarch64-gcs-linux.h and
create an AARCH64_HWCAP_GCS definition in gdb/arch/aarch64-gcs-linux.h
for use by target-dependent code.
Similarly, move the SEGV_CPERR and PR_SHADOW_STACK_{ENABLE,WRITE,PUSH}
definitions, which were added by the GCS patches and are only used by
aarch64-linux target-dependent code, to gdb/arch/aarch64-gcs-linux.h
with an AARCH64_ prefix and adjust users.
Finally, I noticed that gdb/aarch64-linux-nat.c and
gdbserver/linux-aarch64-low.cc don't need anything from the
arch/aarch64-gcs-linux.h header, so make them not include it.
Suggested-by: Luis <luis.machado.foss@gmail.com> Suggested-by: Simon Marchi <simark@simark.ca> Approved-By: Luis Machado <luis.machado.foss@gmail.com>
The HWCAP2_SME, HWCAP2_SME2 and HWCAP2_SME2P1 definitions should be in a
file under gdb/nat/, so move them to aarch64-scalable-linux-ptrace.h.
Also, I noticed that gdb/aarch64-linux-nat.c and
gdbserver/linux-aarch64-low.cc don't need anything from the
arch/aarch64-scalable-linux.h header, so make them not include it.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
projects / thirdparty / binutils-gdb.git / log
