Unlike PyTuple_SET_ITEM(), PyTuple_SetItem() returns an integer: 0 on
success and -1 on error (e.g. IndexError). The existing code must therefore
be updated to handle this new behaviour.
Since processing now stops when PyTuple_SetItem() returns an error, some
resources (such as newly allocated tuples) must be properly deallocated in
error paths. To address this, this patch replaces the use of raw 'PyObject *'
pointers with gdbpy_ref<>, a reference-counted wrapper around 'PyObject *',
which automatically decrements the reference count on early exit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Kevin Buettner [Tue, 3 Mar 2026 02:25:23 +0000 (19:25 -0700)]
gdb/testsuite: Skip gdb.base/watchpoint-adjacent.exp on s390x
The watchpoint-adjacent.exp test requires both read and write hardware
watchpoints. s390x only supports write watchpoints, causing 108 test
failures when rwatch commands fail with "Target does not support this
type of hardware watchpoint."
Add a require for allow_hw_watchpoint_access_tests to skip this test on
architectures without read watchpoint support.
Kevin Buettner [Sun, 2 Nov 2025 04:29:26 +0000 (21:29 -0700)]
[gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x
This commit fixes six failures for s390x due to a fundamental
difference in unwinding behavior between s390x and other
architectures:
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 5:
backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 3:
backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 1:
backtrace when the unwind is broken at frame 1
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 5:
backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 3:
backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 1:
backtrace when the unwind is broken at frame 1
The core issue is that on s390x, the Canonical Frame Address (CFA) for
a function points *into the caller's stack frame*, whereas on x86_64
or aarch64 the CFA points *within the current function's frame*. This
architectural difference causes cycle detection to occur later on
s390x.
The patch resolves this by:
- Making expected backtrace output architecture-specific.
- For non-s390x targets: expecting the full set of frames up to the
specified level.
- For s390x: expecting fewer frames before detecting the cycle
(e.g., level 5 shows 3 frames instead of 5).
- Skipping the cycle at level 1 test entirely on s390x since it cannot
be detected at that frame.
Tested using recent Fedora releases on s390x, x86_64, and aarch64.
Abhay Kandpal [Tue, 3 Mar 2026 15:25:09 +0000 (10:25 -0500)]
gdb/testsuite: fix printf regexp for ppc64le with glibc ieee128 fix
On ppc64le, when the compiler selects IEEE-128 long double ABI
(-mabi=ieeelongdouble), calls to printf are redirected to
___ieee128_printf. This causes 'break printf' in GDB to never stop
at printf:
...
(gdb) break printf
Breakpoint 3 at 0x7ffff7a6b880
(gdb) continue
Continuing.
value is 7
glibc fixed this by adding local symbol aliases in the ieee128
compatibility files so that the original symbol names are present in
the symbol table again (glibc commit f05ab7c4a99b). After the glibc
fix, GDB stops at printf but the breakpoint is reported as
'Breakpoint 3.2, ___ieee128_printf' since printf now resolves to two
locations. The current GDB test regexps do not match this output.
Breakpoint 3.2, ___ieee128_printf (format=0x10000970 \"value is %d\n\")
at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:28
(gdb) FAIL: gdb.base/annota1.exp: continue to printf
...
This causes failures in gdb.base/annota1.exp and gdb.base/annota3.exp
because the pattern 'Breakpoint 3, ' does not match 'Breakpoint 3.2, '.
Fix this by changing 'Breakpoint 3, ' to 'Breakpoint 3.*, '.
In gdb.server/sysroot.exp the pattern '(__)?printf' does not match
'___ieee128_printf'.
Fix this by changing '(__)?printf' to '.*printf' to match any printf
variant including printf, __printf, and ___ieee128_printf,
following the same approach as previous fixes for __printf on x86_64
(commit f870f78fb2d) and printf@@GLIBC_2.17 on ppc64le (commit 29004660c94).
Tom de Vries [Tue, 3 Mar 2026 08:19:43 +0000 (09:19 +0100)]
[gdb/record] Fix syscall recording some more
I ran into the same gdb.reverse/sigall-reverse.exp failure on ppc64le-linux,
as fixed in commits:
- commit 3686645cec9 ("[gdb/record] Fix return value for svc in
aarch64_record_branch_except_sys"), and
- commit 4ef576bdb7f ("[gdb/record] Fix return value for syscall in
loongarch_record_syscall_insn").
The difference with those commits is that the problem is not due to confusion
about a port-local enums (aarch64_record_result, loongarch_record_result).
Instead, the port just treats return values 1 and -1 the same:
...
if (tdep->ppc_syscall_record (regcache) != 0)
return -1;
...
Fix this by passing through the return value 1 instead.
Matthieu Longo [Mon, 9 Feb 2026 17:49:09 +0000 (17:49 +0000)]
aarch64 gas: use bool return type for sub-option parsing
The signature of the functions used to decode sub-options mirrors that
of md_parse_option(). They currently return an integer, but the return
value is always set to 0 on failure and 1 on success, which exactly
matches boolean semantics.
These functions likely predate C99 as the minimum supported C standard
in binutils. Today, there is no good reason to keep this legacy interface
instead of using a proper boolean type.
This patch updates the sub-option parsing functions to return a boolean
and adjusts the corresponding code accordingly.
gdb/infrun: do not restart a stepped thread if not running
Suppose we have two inferiors on an all-stop target with schedule-multi
set on:
$ gdb -q
(gdb) target extended-remote | gdbserver --multi -
Remote debugging using | gdbserver --multi -
Remote debugging using stdio
(gdb) file /temp/test
Reading symbols from /temp/test...
(gdb) set remote exec-file /temp/test
(gdb) start
Temporary breakpoint 1 at 0x115c: file test.c, line 8.
Starting program: /temp/test
stdin/stdout redirected
Process /temp/test created; pid = 864027
...
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd218) at test.c:8
8 foo();
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote | gdbserver --multi -)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file /temp/test
Reading symbols from /temp/test...
(gdb) set remote exec-file /temp/test
(gdb) tbreak 2
Temporary breakpoint 2 at 0x555555555131: /temp/test.c:2. (2 locations)
(gdb) run
Starting program: /temp/test
stdin/stdout redirected
Process /temp/test created; pid = 864430
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) set schedule-multi on
(gdb)
At this point, detaching the first inferior works fine:
(gdb) detach inferiors 1
Detaching from program: /temp/test, process 858904
Detaching from process 858904
[Inferior 1 (process 858904) detached]
(gdb) info inferiors
Num Description Connection Executable
1 <null> 1 (extended-remote | gdbserver --multi -) /temp/test
* 2 process 858925 1 (extended-remote | gdbserver --multi -) /temp/test
(gdb)
Let us now repeat exactly the same scenario, but before detaching, we
make the current thread single-step an instruction:
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) stepi
3 int b = 43;
(gdb) detach inferiors 1
Detaching from program: /temp/test, process 876580
Detaching from process 876580
gdbserver: Couldn't reap LWP 876580 while detaching: No child processes
[Inferior 1 (process 876580) detached]
(gdb) [Switching to Thread 877351.877351]
3 int b = 43;
There is a mysterious line info output. Running the scenario with
infrun debug logs reveals more information.
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) stepi
3 int b = 43;
(gdb) set debug infrun on
(gdb) detach inferiors 1
[infrun] scoped_disable_commit_resumed: reason=detaching
[infrun] scoped_disable_commit_resumed: reason=detaching
Detaching from program: /temp/test, process 3537498
Detaching from process 3537498
gdbserver: Couldn't reap LWP 3537498 while detaching: No child processes
[Inferior 1 (process 3537498) detached]
[infrun] reset: reason=detaching
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] restart_stepped_thread: switching back to stepped thread (stepping)
[infrun] keep_going_stepped_thread: resuming previously stepped thread
[infrun] keep_going_stepped_thread: expected thread advanced also (0x555555555131 -> 0x555555555138)
[infrun] clear_step_over_info: clearing step over info
[infrun] do_target_resume: resume_ptid=-1.0.0, step=0, sig=GDB_SIGNAL_0
[infrun] infrun_async: enable=1
[infrun] reset: reason=detaching
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
(gdb) [infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #0
[infrun] random_pending_event_thread: None found.
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 3537875.3537875.0 [Thread 3537875.3537875],
[infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] context_switch: Switching context from 0.0.0 to 3537875.3537875.0
[infrun] handle_signal_stop: stop_pc=0x555555555138
[infrun] handle_signal_stop: [3537875.3537875.0] hit its single-step breakpoint
[infrun] handle_signal_stop: delayed software breakpoint trap, ignoring
[infrun] process_event_stop_test: stepi/nexti
[infrun] stop_waiting: stop_waiting
[Switching to Thread 3537875.3537875]
3 }
[infrun] infrun_async: enable=0
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target extended-remote, no resumed threads
[infrun] fetch_inferior_event: exit
GDB attempted to do a step-over for the current thread. This takes us
to the commit that introduced restarting step-overs:
A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process, while threads are running. If we have more than one inferior
running, and we detach from just one of the inferiors, we expect that
the remaining inferior continues running. However, in all-stop, if
GDB needs to pause the target for the detach, nothing is re-resuming
the other inferiors after the detach. "info threads" shows the
threads as running, but they really aren't. This fixes it.
However, the thread that was resumed for step-over in our scenario did
not have an interrupted step-over; it had completed its stepi already.
More debugging reveals that the thread is resumed because of the
following two conditions in `restart_stepped_thread`:
if (tp->control.trap_expected)
{
infrun_debug_printf ("switching back to stepped thread (step-over)");
if (keep_going_stepped_thread (tp))
return true;
}
and
if (tp->control.step_range_end)
{
infrun_debug_printf ("switching back to stepped thread (stepping)");
if (keep_going_stepped_thread (tp))
return true;
}
The root cause of the problem is, `restart_stepped_thread` checks for
the thread state as
if (tp->state == THREAD_EXITED)
continue;
but the thread's state is THREAD_STOPPED. To fix, we change the state
check to
if (tp->state != THREAD_RUNNING)
Additionally, the 'trap_expected' and the 'step_range_end' fields of
the thread's control remain set even after the "stepi" command
completes, creating a half-baked internal state that can be misleading
when debugging. We address this problem by clearing the control
fields when stepping completes. We also add a regression test.
Regression-tested on X86_64 Linux using the default, native-gdbserver,
and native-extended-gdbserver board files.
Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Mon, 2 Mar 2026 03:26:06 +0000 (22:26 -0500)]
gdb/linux-tdep: pass string by reference
Sonarqube in me IDE pointed out this "const string" parameter that
should be a reference. I then looked at the callers, and saw that one
would pass `.c_str()`, causing an unnecessary copy, and the other using
std::move unnecessarily.
Tom Tromey [Wed, 25 Feb 2026 20:50:14 +0000 (13:50 -0700)]
Use enum types for remote fileio flags
This changes gdbsupport/fileio.h to use enums with underlying types
for the various constants -- open flags, modes, and lseek flags.
These types replace #defines that were previously used.
Then, this fixes all the users of these flags. This found a few bugs.
Some of these were pedantic (using the constant 0700 where perhaps
FILEIO_S_IRWXU would be more precise), but sparc64-tdep.c confused
host and remote flags.
Also, I believe solib-rocm.c had a couple of arguments in the wrong
order.
I also found that gdb/remote-fileio.c had essentially duplicated some
code from gdbsupport. This patch removes the duplicates.
New in v2:
- The lseek enum is anonymous, the type itself isn't used, just
the constants
Approved-By: Simon Marchi <simon.marchi@efficios.com>
AMD clang is going to start using DW_LANG_HIP instead of
DW_LANG_C_plus_plus_14 (see PR at
https://github.com/llvm/llvm-project/pull/181738). Rather than
falling back to the minimal language, this commit ensures that
GDB will still treat it like a C++ app. The commit also adds
a test to an existing one.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Idc7f18d154036ffceaa0a28032eabb19f110bb11
Tom Tromey [Tue, 24 Feb 2026 19:39:22 +0000 (12:39 -0700)]
Use the "O!" format more in the Python code
I noticed a few spots in the Python code that were decoding method
arguments and then immediately type-checking an argument. This can be
done more concisely using the "O!" format.
Tom Tromey [Fri, 27 Feb 2026 14:31:42 +0000 (07:31 -0700)]
Compute register name once in default_print_one_register_info
PR gdb/9884 points out that default_print_one_register_info could call
gdbarch_register_name a single time. The current code seems harmless
but OTOH the proposed change is also harmless and perhaps slightly
faster, so why not.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9884 Approved-By: Tom de Vries <tdevries@suse.de>
Bruce McCulloch [Thu, 5 Feb 2026 20:50:28 +0000 (12:50 -0800)]
libctf: remove CTF_F_ARRNELEMS flag
This patch removes the constraint that a CTF_F_ARRNELEMS flag has to be
present in order to reverse the elements of an array when dumping. The
flag was never added to GCC, and having this requirement causes more
problems than it solves. A quick recap of the issue:
Given an array int foo[1][2][3], the expected graph is:
int foo[1][2][3] -> int foo[2][3] -> int foo[3] -> int foo
Prior to GCC PR114186, the emitted graph would be:
int foo[1][2][3] -> int foo[1][2] -> int foo[1] -> int foo
Following GCC PR114186, before the libctf fix, the output was:
int foo[3][2][1] -> int foo[3][2] -> int foo[3] -> int foo
So the underlying type graph was correct, but the ordering of elements
was incorrect.
With this fix, we emit correct ordering of the type graph, with no
requirements for the compiler to signal that it has GCC PR114186.
libctf/
* ctf-decl.c (ctf_decl_push): Act as if CTF_F_ARRNELEMS is
always set.
* ctf-dump.c (ctf_dump_header): No longer dump its value.
* testsuite/libctf-lookup/multidim-array.c: No longer detect
compilers not emitting this flag (none do).
Nick Alcock [Mon, 3 Nov 2025 17:15:32 +0000 (17:15 +0000)]
libctf: allow ctf_arc_bufpreamble to fail
The recent libctf fix for ctf_arc_bufpreamble missed a case:
what if the input is exactly sizeof (ctf_archive_t) in size (which can
happen if the archive has no members at all, so returning the preamble
from one of the members is in any case impossible?). In this case
it'll return an off-the-end pointer, and its caller will overrun.
(This can also happen with fuzzed input which has a valid magic
number.)
Allow it to fail in this case, returning NULL, and adjust its sole
caller. The caller's conclusions in this case will be wrong (it will
conclude that the archive is connected to .symtab), but the incorrect
conclusions are harmless because the lack of archive members will
immediately cause a failure in ctf_arc_bufopen(), and an error return.
Thanks to Alan Modra for the original fix this soups up.
libctf/
PR libctf/33548
* ctf-archive.c (ctf_arc_bufpreamble): Fail if the archive is
too short (or empty, with no dicts to contain preambles),
returning NULL.
* ctf-open-bfd.c (ctf_bfdopen_ctfsect): Handle a NULL return.
Alan Modra [Fri, 27 Feb 2026 07:44:36 +0000 (18:14 +1030)]
PR 33743 readelf abort during RELR relocation handling
Rather than aborting, use "unknown relative" as the reloc type should
display_elf_relocation_at want to print a relocation. Also fix
another case where readelf doesn't understand the relocation and sets
all_relocations[i].r_name to NULL.
PR 33743
* readelf.c (dump_relr_relocations): Don't abort on unknown
e_machine.
(dump_relocations): Don't assume we can pass NULL to a %s
format.
Jan Beulich [Fri, 27 Feb 2026 07:00:05 +0000 (08:00 +0100)]
PPC: improve handling of improper "kind-of-register" operands
A unary % is expected to be followed by a register. While this is being
diagnosed as "bad expression", a 2nd error then follows ("syntax error;
found ..."). Consume the % in md_operand() (thus preventing it to be
treated as modulus with missing [i.e. implicitly 0] leading operand) and
mark the expression O_illegal (thus avoiding the "bad expression") when
the "register" is unrecognized.
Reviewed-by: Peter Bergner <bergner@tenstorrent.com>
Tom de Vries [Thu, 26 Feb 2026 09:46:02 +0000 (10:46 +0100)]
[gdb/record] Fix return value for syscall in loongarch_record_syscall_insn
This is the loongarch version of commit 3686645cec9 ("[gdb/record] Fix return
value for svc in aarch64_record_branch_except_sys").
Approved-By: Tiezhu Yang <yangtiezhu@loongson.cn> Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33924
Alan Modra [Thu, 26 Feb 2026 00:03:10 +0000 (10:33 +1030)]
Work around gcc-4.9 bug
Commit 893eb49c9b12 exposed a gcc-4.9 build error, with gcc-4.9
erroneously complaining that F_MIN_SUBSECTION_DATA_LEN has a
non-constant initialisation.
* readelf.c (F_MIN_SUBSECTION_DATA_LEN): Use #define to work
around gcc-4.9 bug.
(F_SUBSECTION_LEN, F_SUBSECTION_COMPREHENSION),
(F_SUBSECTION_ENCODING): Use #define here too.
(elf_parse_attrs_subsection_v2): Adjust format string.
Alan Modra [Wed, 25 Feb 2026 23:51:37 +0000 (10:21 +1030)]
same-inode.h: don't depend on _GL_WINDOWS_STAT_INODES
It looks like assuming _GL_WINDOWS_STAT_INODES is 1 is likely our best
option. See gnulib/m4/windows-stat-inodes.m4. Note that this doesn't
really make SAME_INODE usable on windows hosts as a number of the
likely filesystems (FAT, HPFS, or NTFS) don't support st_ino.
* same-inode.h (SAME_INODE <_WIN32>): Remove _GL_WINDOWS_STAT_INODES
test. Assume it is true.
gdb: limit updating the address spaces to the current target
For the `update_address_spaces` function, there is this comment:
It is assumed that there are no bound inferiors yet, otherwise,
they'd be left with stale referenced to released aspaces.
The function indeed iterates over all inferiors and resets their
address spaces. The function has only one caller:
remote_target::start_remote_1. This means, if we already have an
inferior and then start a remote target in a second inferior, we may
alter the address space of the first inferior. It seems the current
code is a left-over from pre-multi-target days. To prevent bad things
from happening, update the address spaces for a given target only.
A scenario where unwanted behavior occurs is as follows: Start a
multi-threaded program in non-stop mode. Hit a breakpoint with a
thread. Create a second inferior on a remote target. Switch back to
inferior 1. Continuing repeatedly hits the breakpoint. See below.
$ gdb /tmp/multi-thread
Reading symbols from /tmp/multi-thread...
(gdb) set non-stop on
(gdb) break 30
Breakpoint 1 at 0x151e: file multi-thread.cpp, line 30.
(gdb) run
Starting program: /tmp/multi-thread
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7a4f640 (LWP 3413070)]
[New Thread 0x7ffff724e640 (LWP 3413071)]
[New Thread 0x7ffff6a4d640 (LWP 3413072)]
[New Thread 0x7ffff624c640 (LWP 3413073)]
Thread 1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
30 int x = 42;
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote | gdbserver --multi -
Remote debugging using | gdbserver --multi -
Remote debugging using stdio
(gdb) inferior 1
[Switching to inferior 1 [process 3413067] (/tmp/multi-thread)]
[Switching to thread 1.1 (Thread 0x7ffff7a50740 (LWP 3413067))]
#0 main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
30 int x = 42;
(gdb) continue
Continuing.
Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
30 int x = 42;
(gdb) continue
Continuing.
Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
30 int x = 42;
(gdb) continue
Continuing.
Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
30 int x = 42;
(gdb)
...
It was not possible to simplify the bug reproducer. For some reason,
simplifications make observable problems go away. Adding the case
above as a testcase.
Regression-tested in Linux x86-64 with the default, native-gdbserver,
and native-extended-gdbserver board files.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Keith Seitz [Wed, 25 Feb 2026 14:24:53 +0000 (06:24 -0800)]
Fix even more -Wdiscarded-qualifers issues
Fedora Rawhide is failing to build due to new glibc header changes
enforcing const-correctness in functions like strchr and memchr.
For example:
../../opcodes/aarch64-dis.c: In function ‘remove_dot_suffix’:
../../opcodes/aarch64-dis.c:4027:7: error: assignment discards ‘const’ qualifier from po
inter target type [-Werror=discarded-qualifiers]
4027 | ptr = strchr (inst->opcode->name, '.');
| ^
cc1: all warnings being treated as errors
This patch addresses all the discovered issues with --enable-targets=all
and regenerates a few cgen files along the way.
Andrew Burgess [Wed, 11 Feb 2026 13:02:11 +0000 (13:02 +0000)]
gdb: more styling for skip command output
Add function and file styling to output of the 'skip', 'skip file',
and 'skip function' commands.
I did worry a little about this case:
(gdb) skip -gfile *.c
File(s) *.c will be skipped when stepping.
After this change the '*.c' will be given file_name_style, even though
it's not an actual filename, but a filename glob.
However, if you do this:
(gdb) info skip
Num Enb Glob File RE Function
1 y y *.c n <none>
Then the '*.c' is already (even before this patch) given
file_name_style, so if nothing else, my change makes things
consistent. And personally, I think it's OK to style the '*.c'.
There's a similar issue with 'skip -rfunction PATTERN' where the
PATTERN will be styled in the output with function_name_style even
though it's not an actual function name. As with the filename case
PATTERN is already styled in the 'info skip' table, so I think the
change in this commit is consistent if nothing else.
There should be no functional change after this commit; just improved
styling.
Andrew Burgess [Tue, 10 Feb 2026 20:01:20 +0000 (20:01 +0000)]
gdb: option completion for the 'skip' command
This commit adds proper option completion for the 'skip' command, the
skip_command function (skip.c) has been rewritten as a consequence.
All the existing functionality should have been retained, though some
of the error messages have changed as we now get the errors generated
by the option parsing code rather than the ones from skip_command.
I've added more skip tests to cover error cases that were not
previously tested. And I've added a test for 'skip FUNCTION_NAME'
which was previously untested.
Consider the -gfile option for the skip command. Previously the skip
command was hard coded to accept -gfile or -gfi, these were aliases.
But you couldn't pass -gfil. Now we've switched to the general option
handling routine the only option is -gfile, but our option handling
code will accept any partial option name that uniquely identifies an
option, so -g, -gf, -gfi, -gfil, and -gfile are all valid, and all
aliases of each other. The same is true for all the options that skip
accepts.
Because of this I've gone through and removed all references to the
short form option names that I can find. Now that tab-completion
works, there's no need to advertise specific short form names, and as
discussed above, all unique short forms are still valid.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 10 Feb 2026 15:14:09 +0000 (15:14 +0000)]
gdb: aliases for some skip related commands
Skips are created using 'skip', 'skip file', or 'skip function', then
managed with 'skip enable', 'skip disable', and 'skip delete'.
This is slightly different to other things, for example breakpoint,
where we have a command to create the thing, e.g. 'break', but then we
have 'enable breakpoints', 'disable breakpoints', and 'delete
breakpoints' to manage the thing.
If you tab-complete on any of the 'enable', 'disable', or 'delete'
prefix commands you'll find these are used to manage a whole bunch of
different types of thing.
When I started playing with skips, my instinct, given the existing
patterns in GDB, was to try 'enable skip', 'disable skip', and 'delete
skip', and it surprised me that these didn't work.
But notice we do have 'info skip' rather than 'skip info'. So the
"normal" pattern does apply in some cases.
In this commit I propose that we create aliases 'enable skip',
'disable skip', and 'delete skip' which just alias back to the
existing commands. We cannot delete the existing commands for fear of
breaking existing user scripts.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Add a new "environ" subcommand to "info proc" to print the initial
environment variables of a given process. The environment variables
are printed line-by-line and are indented by two spaces, so that they
can be distinguished from the rest of the output in "info proc all".
Note that the information printed by this new command is not
necessarily the same as `show environment`, which lists the
environment variables that will be given to the program next time it
is started under GDB. The two information may differ in particular
when GDB attached to a running program that was started in an
environment different than GDB's.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
gdb: remove 'num' field from 'struct address_space'
The getter method `num ()` in `struct address_space` is never used.
Remove it. This leads to two more simplifications: (1) the
address_space constructor can be defaulted in the header, (2)
`highest_address_space_num` global counter is no longer needed and can
be removed.
Tested by re-building.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Tue, 24 Feb 2026 21:22:15 +0000 (07:52 +1030)]
Re: gas: macros nested too deep error
In commit fc2fcd4f5be3 I changed as as_fatal to as_bad, thinking that
was sufficient. Revert that change because
.macro r;r;r;.endm;r
with two recursive invocations in the body results in 2 to the power
max_macro_nest lines of gas output complaining about macro nesting.
* input-scrub.c (input_scrub_include_sb): Revert last change.
Tom Tromey [Mon, 9 Feb 2026 14:13:33 +0000 (07:13 -0700)]
Sort and uniquify Ada standard exceptions
With libgnat debuginfo installed, I noticed some test failures.
This patch fixes gdb.ada/info_exc.exp and gdb.ada/mi_exc_info.exp,
both of which had failures caused by not unique-ifying the list of
standard exceptions.
Tom Tromey [Sun, 8 Feb 2026 21:39:50 +0000 (14:39 -0700)]
Fix Ada failure with gdb-index
The gdb index reader rewrite (commit 486bc5ac) broke a couple of Ada
test cases. I didn't notice these at the time because they require
libgnat debuginfo to be installed.
This patch fixes the problem. The issue here is that the Ada code
sometimes requires types to have "linkage name" entries. This is
required because these lookups are done using the verbatim ("<...>")
notation, which won't match the split names in the index.
Removing the need for this is on my wish-list, see PR ada/32142; but I
have not gotten around to figuring this one out yet.
In the meantime, having the gdb-index reader create synthetic linkage
name entries for types fixes the bug.
Jan Vrany [Tue, 24 Feb 2026 15:24:31 +0000 (15:24 +0000)]
gdb/testsuite: fix test build-id-no-debug-warning.exp with -readnow
Test build-id-no-debug-warning.exp fails when using -readnow. This is
because in that case GDB outputs "Expanding full symbols from..." after
"Reading symbols from ...".
Jan Vrany [Tue, 24 Feb 2026 15:24:31 +0000 (15:24 +0000)]
gdb/testsuite: fix test crc_mismatch.exp with -readnow
Test crc_mismatch.exp fails when using -readnow. This is because in that
case GDB outputs "Expanding full symbols..." after "Reading symbols from
...".
Tom de Vries [Tue, 24 Feb 2026 13:35:40 +0000 (14:35 +0100)]
[gdb/record] Fix return value for svc in aarch64_record_branch_except_sys
The Linaro CI reported the following regression in test-case
gdb.reverse/sigall-reverse.exp on aarch64-linux:
...
(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 0xd4000001 at address $hex.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
__GI__exit (status=status@entry=0) at ../sysdeps/unix/sysv/linux/_exit.c:30^M
30 INLINE_SYSCALL (exit_group, 1, status);^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit
...
due to commit 0cb5fde010a ("[gdb/testsuite] Fix some incorrect uses of
decimal").
[ Note that 0xd4000001 is "svc #0", the syscall instruction. ]
The test fails because it expects "Process record: inferior program stopped":
...
gdb_test "continue" "Process record: inferior program stopped.*" \
"continue to signal exit" \
"The next instruction is syscall exit_group.* program...y. or n. " \
"yes"
...
instead of "Process record: failed to record execution log".
The problem is caused by the fact that there are two result value domains:
- one for generic record (res < 0, res == 0, and res > 0) and
- one for aarch64 record (AARCH64_RECORD_SUCCESS = 0, AARCH64_RECORD_UNSUPPORTED = 1
and AARCH64_RECORD_UNKNOWN = 2, and an unnamed -1).
When returning here from aarch64_record_branch_except_sys:
...
return tdep->aarch64_syscall_record (aarch64_insn_r->regcache,
svc_number);
...
we transfer from the generic record domain to the aarch64 record domain, converting:
- a value 1, meaning "Process record: inferior program stopped", into
- a value AARCH64_RECORD_UNSUPPORTED, meaning
"Process record does not support instruction $hex at address $hex.
Process record: failed to record execution log.".
[ Then again, the transfer of domains might be in aarch64_linux_syscall_record.
It's kind of hard to say, given that typing is not used to distinguish between
the two domains. ]
Fix this by:
- introducing a conversion function to_aarch64_record_result, and
- using it in aarch64_record_branch_except_sys.
Likewise, add a from_aarch64_record_result and use it in
aarch64_process_record.
Also add some documentation to enum aarch64_record_result, and add the missing
-1 value.
AFAICT, the loongarch port needs the same fix, but I can't test that so I
think it's better to only deal with aarch64 in this patch.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33913
Alan Modra [Tue, 24 Feb 2026 11:18:14 +0000 (21:48 +1030)]
readelf: endless loop on attrv2
Given a short attributes section, elf_parse_attrs_subsection_v2 prints
an error message but does not return an error status or consume any
input. That results in endless printing of "Object attributes section
ends prematurely". The length checks also ignored a single excess
byte at the end of the section.
* readelf.c (elf_parse_attrs_subsection_v2): Move various
constants out of function. Don't check for min length here..
(process_attributes_v2): ..do so here instead.
Alan Modra [Sun, 22 Feb 2026 04:52:43 +0000 (15:22 +1030)]
readelf .debug_aranges header display
Print "Address size" rather than "Pointer Size" and "Segment size"
rather than "Segment Size", using the same names and capitalisation
as is used when printing other headers with these fields.
Alan Modra [Mon, 23 Feb 2026 00:57:15 +0000 (11:27 +1030)]
binutils: rename ar_pointer_size
The field is named "address size" in all versions of the DWARF spec
that have and name the field. Reflect that by renaming
ar_pointer_size to ar_address_size.
Alan Modra [Mon, 23 Feb 2026 00:48:17 +0000 (11:18 +1030)]
PR 33914 abort parsing fuzzed .debug_line
The abort is due to an unexpected DW_FORM_addrx3 entry in the
testcase, which requires pointer_size to be known.
* dwarf.c (address_size_ok): New function.
(read_debug_line_header): Use address_size_ok.
(display_formatted_table): Pass li_address_size as
pointer_size to read_and_display_attr_value.
(display_debug_lines_decoded): Likewise.
(display_debug_macro, display_debug_names): Similarly pass
offset_size.
(display_loclists_unit_header): Use address_size_ok.
(display_debug_loc, display_debug_addr): Likewise.
(display_debug_aranges): Likewise. Remove power of two check
on address_size. Calculate and pad to tuple_size.
Since commit 120072c7cdc ("gdb/testsuite: update C++ tests for volatile
changes in C++20") I see regressions in two test-cases:
...
$ ./sum.sh
4300 gdb.base/infcall-nested-structs-c++.exp:
2500 gdb.base/infcall-nested-structs-c.exp:
...
In more detail, in test-case gdb.base/infcall-nested-structs-c++.exp:
...
(gdb) tbreak 421^M
No compiled code for line 421 in the current file.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: $exp: types-tc: gdb_breakpoint: set breakpoint at 421
...
Fix this by reverting the change done by the commit, and applying the same fix
as the commit applied elsewhere:
...
- v++;
+ v = v + 1;
...
Tested on x86_64-linux, with target boards unix and unix/-std=c++20.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33915
Kevin Buettner [Wed, 18 Feb 2026 01:09:08 +0000 (18:09 -0700)]
gcore: Query auxv for AT_PAGESZ in gcore_copy_callback
This is a followup patch to commit c1da013915e, titled "gcore: Handle
unreadable pages within readable memory regions".
In his review of that earlier patch, Tom de Vries recommended using
target_auxv_search with AT_PAGESZ to find the page size if it's
available; this patch implements that suggestion. As before, a 4k
fallback size is used should the search for an AT_PAGESZ value not
succeed.
Alan Modra [Sat, 21 Feb 2026 00:26:57 +0000 (10:56 +1030)]
PR 33917 Internal error in S_SET_SEGMENT
Commit d4d05d13eba6 attempted to fix a similar error to that uncovered
by the testcase in pr33917, but did so in a way that was wrong.
Modifying an undefined_section symbol that is an equate breaks prior
use of that symbol, as shown in the rewrite of the
section-symbol-redef test.
Another oddity found when poking at pr33917 is that gas allows
x=0
.sect x
x=u
while
.sect x
x=u
fails with "Error: symbol `x' is already defined".
Fix all of this by rewriting section_symbol to properly check for the
only case where we want to redefine an existing symbol, a truly
undefined symbol, and always use section_symbol in obj-elf rather than
trying to handle undefined symbols there too.
PR 33917
* config/obj-elf.c (change_section): Always call section_symbol
to set up sym.
* subsegs.c (section_symbol): Rewrite.
* testsuite/gas/elf/section-symbol-redef.d
* testsuite/gas/elf/section-symbol-redef.s: Rewrite.
* testsuite/gas/elf/section-symbol-redef-2.d,
* testsuite/gas/elf/section-symbol-redef-2.s: New test.
* testsuite/gas/elf/elf.exp: Run new test.
Alan Modra [Sat, 21 Feb 2026 00:26:49 +0000 (10:56 +1030)]
Make Solaris global ABI syms STT_OBJECT and STV_PROTECTED
PR 33177
* emultempl/solaris2.em (elf_solaris_before_allocation): Make
globals defined here STV_PROTECTED and STT_OBJECT. Use
elf_backend_hide_symbol rather that just setting forced_local
for local ABI syms.
Alan Modra [Sat, 21 Feb 2026 00:26:43 +0000 (10:56 +1030)]
PR 12320 ld --as-needed links libgcc_s.so.1 unnecessarily on Solaris
The Solaris 2 ABI requires some global symbols to be present as
dynamic symbols. These unfortunately interact with ld --as-needed.
See the comment above elf-solaris.c:elf_solaris2_add_symbol_hook,
a new function added by this patch to ignore those symbol in shared
libraries.
PR 12320
PR 33177
bfd/
* elf-solaris2.c: New file.
* elf-solaris2.h: New file.
* elf32-i386.c (elf_backend_add_symbol_hook): Define for Solaris.
* elf32-sparc.c (elf_backend_add_symbol_hook): Likewise.
* elf64-sparc.c (elf64_sparc_solaris2_add_symbol_hook): New.
(elf_backend_add_symbol_hook): Define for Solaris.
* elf64-x86-64.c (elf_x86_64_solaris2_add_symbol_hook): New.
(elf_backend_add_symbol_hook): Define for Solaris.
* Makefile.am (BFD32_BACKENDS): Add elf-solaris2.lo.
(BFD32_BACKENDS_CFILES): Add elf-solaris2.c.
* configure.ac (elfxx_x86): Add elf-solaris2.lo.
(elfxx_sparc): Define and use in all sparc_elf*_vec.
* po/SRC-POTFILES.in: Regenerate.
* Makefile.in: Regenerate.
* configure: Regenerate.
ld/
* emultempl/solaris2.em (elf_solaris2_after_open): New function.
(LDEMUL_AFTER_OPEN): Define.
(elf_solaris_before_allocation): Delete global_syms, instead
use elf_solaris2_global_syms. Ignore globals that are still
bfd_link_hash_new, ie. have not been defined by a script.
Alan Modra [Sat, 21 Feb 2026 00:26:33 +0000 (10:56 +1030)]
Solaris emulation check
elf_solaris2_before_allocation can be called when ld output is non-ELF,
but also when ld output is ELF but not Solaris. Split out from the
pr12320 fix due to the indentation change.
PR 12320
PR 33177
* emultempl/solaris2.em (elf_solaris_before_allocation): Wrap
everything done here in a more rigorous output hash table check.
I tracked this down to a race condition in the test program, causing it
not to generate the expected SIGTRAP. This can be reproduced by adding
a sleep(1) just after the pthread_create.
The expected behavior is:
- The main thread starts a second thread
- The main thread blocks on pthread_cond_wait, waiting to be notified
by the second thread (to make sure the second thread had time to
start)
- The second thread notifies the main thread using pthread_cond_signal
- The main thread sends a SIGTRAP to the second thread
However, this can happen:
- The main thread starts a second thread
- The second thread calls pthread_cond_signal, while no one is waiting
to the condvar
- The main thread blocks on pthread_cond_wait forever
Fix it by introducing a separate boolean predicate protected by the
shared mutex, and looping until it is true. This is the way
pthread_cond_wait is meant to be used. From pthread_cond_wait(3):
When using condition variables there is always a boolean predicate
involving shared variables associated with each condition wait that
is true if the thread should proceed. Spurious wakeups from the
pthread_cond_wait() or pthread_cond_timedwait() functions may occur.
Since the return from pthread_cond_wait() or
pthread_cond_timedwait() does not imply anything about the value of
this predicate, the predicate should be re-evaluated upon such
return.
Finally, make things static, just out of principle, and fix minor
formatting issues.
Change-Id: I62ba2085a2d506dc3d91e32cd5de48c43a3ff55e Approved-By: Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
