While working on Windows non-stop support, I ran into a
very-hard-to-track-down bug.
The problem turned out to be that
infrun.c:proceed_resume_thread_checked resumed an already-executing
thread because the thread was marked as "executing=true,
resumed=false", and that function only skips resuming threads that are
marked resumed=true. The consequence was that GDB corrupted the
registers of the Windows DLL loader threads, eventually leading to a
GDB+inferior deadlock.
Originally, the "resumed" flag was only ever set when infrun decided
is was ready to process a thread's pending wait status. infrun has
since evolved to set the resumed flag when we set a thread's executing
flag too. We are not always consistent throughout in guaranteeing
that a thread is marked resumed=true whenever it is marked
executing=true, though. For instance, no target code that supports
non-stop mode (linux-nat, remote, and windows-nat with this series) is
making sure that new threads are marked resumed=true when they are
added to the thread list. They are only marked as {state=running,
executing=true}, the "resumed" flag is not touched.
Making proceed_resume_thread_checked check thr->executing() in
addition to thr->resumed(), feels like papering over a combination of
states that shouldn't happen nowadays.
OTOH, having to have the target backends mark new threads as
resumed=true just feels like too many different states (three) to set:
We really have too many "state tracking" flags in a thread.
Basically:
- whether a thread is "running/stopped/exited" (from the user's
perspective). This is the thread_info::state field.
- whether a thread is "executing" (infrun asked the target to set the
thread executing). This is thread_info::executing().
- whether a thread is "resumed" (infrun wants the thread to be
resumed, but maybe can't yet because the thread has a pending wait
status). This is thread_info::resumed()
"running", "executing", and "resumed" are almost synonyms, so this can
be highly confusing English-wise too.
For "running" vs "executing", in comments, we tipically need to
explain that "running/stopped/exited" is for the user/frontend
perspective, while "executing true/false" is for gdb's internal run
control.
(Also, "executing or not" can also mean something else in GDB's
codebase -- "target has execution" does not mean that threads are
actually running right now -- it's a test for whether we have a live
process vs a core dump!)
One simplification we can do that avoids this running vs executing
ambiguity is to replace the "executing" field with an "internal_state"
field, similar to the thread_info::state field, and make that new
internal_state field reuse the same enum thread_state type that is
used by thread_info::state. Like:
struct thread_info
{
...
/* Frontend/public/external/user view of the thread state. */
enum thread_state m_state = THREAD_STOPPED;
/* The thread's internal state. When the thread is stopped
internally while handling an internal event, like a software
single-step breakpoint, the internal state will be
THREAD_STOPPED, but the external state will still be
THREAD_RUNNING. */
enum thread_state m_internal_state = THREAD_STOPPED;
};
(Assume we'd add state() and internal_state() getters.)
With that, every check for thr->executing() is replaced with a
'thr->internal_state() == THREAD_RUNNING' check, and the code is
clearer by design. There is no confusion between "running" vs
"executing" any more, because they now mean the exact same thing.
Instead, we say e.g., 'thread has (user) state "running", and internal
state "stopped"'. Or simpler, 'thread is running (from the user's
perspective), but internally stopped'. That is after all what we
would way in comments today already.
That still leaves the 'resumed' flag, though. That's the least
obvious one. Turns out we can get rid of it, and make it a new state
tracked by thread_info::internal_state. That is, we make
internal_state have its own enumeration type (decoupled from
thread_info::state's type), and convert the resumed true/false flag to
a new enumerator of this new enumeration. Like so:
The patch adds getters/setters for both (user) state and
internal_state, and adds assertions around state transitions, ensuring
that internal_state doesn't get out of sync with
thread::have_pending_wait_status().
The code that adds/removes threads from the proc_target's
resumed_with_pending_wait_status list is all centralized within
thread_info::set_internal_state, when we switch to/from the
resumed-pending-status state. With the assertions in place, it should
be impossible to end up with a THREAD_INT_RUNNING thread with a
pending status.
The thread.c:set_running, thread.c:set_executing, thread.c:set_resumed
global functions are all gone, replaced with new thread.c:set_state
and thread.c:set_internal_state functions.
Pedro Alves [Wed, 19 Feb 2025 14:37:39 +0000 (14:37 +0000)]
init_wait_for_inferior doesn't imply proceed
The next patch adds an assertion to clear_proceed_status_thread,
making sure that we don't try to proceed a thread that is already
running. Turns out that catches attach_command calling
init_wait_for_inferior too late, after attaching has already created
already-running threads. This patch fixes.
However, that alone changes MI output when attaching (as caught by
e.g. gdb.rocm/mi-attach.exp). We'd go from:
That change would happen because init_wait_for_inferior calls
clear_proceed_status, which calls notify_about_to_proceed, where we
end up in mi_interp::on_about_to_proceed(), setting the mi_proceeded
flag. If that happens before linux_nat_target::attach is called, then
the set_running calls inside linux_nat_target::attach result in
emiting ^running in MI instead of ^done due to the back-compatibility
hack in mi_on_resume_1.
Now, init_wait_inferior really does not imply we're about to call
proceed. So restore the MI output by adding a new parameter to
clear_proceed_status that lets init_wait_inferior tell
clear_proceed_status to skip notifying the about_to_proceed observers.
I audited all init_wait_inferior calls, and this made sense in all of
them. The places do call proceed after init_wait_inferior, already
explicitly clear_proceed_status after init_wait_inferior. E.g.,
run_command_1.
Tom Tromey [Wed, 4 Mar 2026 15:13:41 +0000 (08:13 -0700)]
Handle inherited discriminants in Ada
In Ada, a discriminant might be inherited. Consider this code:
type Root_T (Root_Disc : Boolean) is tagged record
null;
end record;
type Child_T (Child_Disc : Boolean) is new Root_T (Root_Disc => Child_Disc) with record
case Child_Disc is
when True =>
Child_Flag : Boolean;
when others => null;
end case;
end record;
Here, Child_Disc does not really exist -- it just an alias of
Root_Disc.
Now, DWARF doesn't recognize this possibility, so compilers have come
up with two different approaches to handle this.
gnat-llvm will emit an artificial copy of Root_Disc as a member of
Child_T. See commit 48b5669c, where this was handled in gdb.
It wasn't convenient to follow this same approach in GCC (the two
compilers have very different DWARF generation approaches), and so GCC
emits the possibly-more-intuitive approach of simply having the
DW_AT_discr refer to the field DIE in Root_T.
This patch implements support for this approach in gdb. The idea here
is that, rather than try to figure out how to handle cross-type
references, gdb will implement the "LLVM" approach internally; that
is, make an artificial duplicate field.
For gnat-llvm, though, it was more convenient to always emit a bit
stride. Using an expression for this is a DWARF extension, but it's a
fairly obvious one, and something similar is already used in gdb.
This patch adds support for dynamic bit strides on an array to gdb. A
new test case, derived from gdb.dwarf2/arr-stride.exp (the derivation
explains the copyright dates) is included.
Alan Modra [Mon, 6 Apr 2026 00:54:07 +0000 (10:24 +0930)]
libsframe testsuite format mismatches on 32-bit host
libsframe.find/findfre-1.c:177:41: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int64_t’ {aka ‘long long int’} [-Wformat=]
* testsuite/sframe-test.h: Include inttypes.h.
* testsuite/libsframe.find/findfre-1.c (main): Use PRIx64 to print
int64_t vars.
* testsuite/libsframe.find/findfre-flex-1.c (main): Likewise.
* testsuite/libsframe.find/findfunc-1.c (main): Likewise.
* testsuite/libsframe.find/plt-findfre-1.c (main): Likewise.
* testsuite/libsframe.find/plt-findfre-2.c (main): Likewise.
Alan Modra [Mon, 6 Apr 2026 00:02:06 +0000 (09:32 +0930)]
gprofng format mismatch on 32-bit host
On a 32-bit host without --enable-64-bit-bfd
gp-gmon.cc:531:42: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘bfd_size_type’ {aka ‘unsigned int’} [-Wformat=]
On a 32-bit-host with --enable-64-bit-bfd the underlying type will be
unsigned long long.
* src/gp-gmon.cc (gen_gmon_map): Use %llu to print msize, and cast.
Instead of hard coding the path to milli.a, add the input file
as a lang_input_file_is_search_file_enum. This allows adding
a dummy archive in the testsuite.
2026-04-04 John David Anglin <danglin@gcc.gnu.org>
ld/ChangeLog:
* emultempl/hppa64elf.em (hppa64elf_after_parse): Search
for milli.a. Add "/lib/pa20_64" and "/usr/lib/pa20_64"
library search paths.
gdb: implement Tcl platform detection and improve private headers scan
This is needed for recent TEA support.
Autoconf macro CY_AC_TCL_PRIVATE_HEADERS checks more file locations and
determines TCL_PLATFORM according to the private header files found.
A C macro TCL_PLATFORM_DEFINE is computed accordingly and defined from
command line.
The same applies to Tk.
As in-tree Tcl/Tk sources have been removed, this case is left out.
Alan Modra [Fri, 3 Apr 2026 22:13:06 +0000 (08:43 +1030)]
score howto special_function final linking output bfd access
Like commit 804439b4d7a8, avoid segfaults when the hack to access
the output bfd won't work, eg. when the sym is absolute.
* elf32-score.c (score_elf_gprel15_reloc): Return bfd_reloc_undefined
when output_bfd cannot be determined from the symbol.
(score_elf_gprel32_reloc): Likewise.
* elf32-score7.c (score_elf_gprel32_reloc): Likewise.
Alan Modra [Fri, 3 Apr 2026 22:07:59 +0000 (08:37 +1030)]
bfd_perform_relocation and howto special_function bfd params
Describe the output_bfd parameter of bfd_perform_relocation, in
pariticular that it is NULL when final linking.
* reloc.c (bfd_perform_relocation): Comment on abfd and
output_bfd parameters in the function description.
(reloc_howto_struct <special_function>): Refer to above.
Tom de Vries [Fri, 3 Apr 2026 13:19:26 +0000 (15:19 +0200)]
[gdb] Enable ptype /o for some dynamic types
Printing the offsets of a struct containing a flexible array member using
"ptype /o" currently fails:
...
$ cat test.c
struct s {
int a;
int b[];
};
struct s foo;
$ gcc -g test.c -c
$ gdb -q -batch test.o -ex "ptype /o struct s"
warning: ptype/o does not work with dynamic types; disabling '/o'
type = struct s {
int a;
int b[];
}
...
This has been the case since gdb 14, containing commit 0c1aa2a0953 ("Disable
ptype/o for dynamic types").
If we revert the commit, we get instead:
...
$ gdb -q -batch test.o -ex "ptype /o struct s"
/* offset | size */ type = struct s {
/* 0 | 4 */ int a;
/* 4 | 0 */ int b[];
/* total size (bytes): 4 */
}
...
which is similar to what pahole prints:
...
struct s {
int a; /* 0 4 */
int b[]; /* 4 0 */
The problem is that the commit uses is_dynamic_type:
...
if (flags.print_offsets && is_dynamic_type (type))
{
warning (_("ptype/o does not work with dynamic types; disabling '/o'"));
flags.print_offsets = 0;
}
...
which is too restrictive.
Fix this by using a new function cannot_print_offsets instead.
Tom de Vries [Fri, 3 Apr 2026 13:19:26 +0000 (15:19 +0200)]
[gdb] Factor out is_dynamic_type_internal_1
Simplify is_dynamic_type_internal by factoring out is_dynamic_type_internal_1,
leaving only the handling of the top_level parameter in
is_dynamic_type_internal.
H.J. Lu [Wed, 18 Mar 2026 20:58:35 +0000 (13:58 -0700)]
ld: Pass --no-rosegment to ld in some linker tests
For elf/x86, --rosegment places code after read-only data, instead of
before read-only data. Pass --no-rosegment to ld in some linker tests
to avoid extra linker test failures when binutils is configured with
--enable-rosegment for elf/x86.
binutils/
PR ld/34003
* testsuite/lib/binutils-common.exp (check_rosegment_support): New.
(run_dump_test): Make NO_ROSEGMENT_LDFLAGS global.
The ada-valprint-error.exp test links a nodebug .o file with a separate
DWARF .o file generated by lib/dwarf.exp. This requires the linker to
apply relocations for initialized pointers in the .data section.
Some clang + linker combinations fail to apply these relocations,
leaving fd__global as NULL instead of pointing to buffer. This causes
the test to print null instead of the expected error message.
Binary evidence from .comment section confirms which compiler and
linker were used. Testing shows:
- GCC 13 + GNU ld 2.42: PASS
- clang 20 + GNU ld 2.42: FAIL
- clang 22 + ld.lld 22: FAIL
- clang 17/19 + GNU ld 2.45.0: PASS
The failure is a linker limitation when handling this specific
relocation pattern, not a GDB bug. Document this in the test file
to help users understand why the test may fail with certain toolchains.
Joel Holdsworth [Thu, 2 Apr 2026 17:23:14 +0000 (10:23 -0700)]
PR 34038 null pointer dereference in elf_link_output_extsym
When linking an ELF object file containing an STT_GNU_IFUNC symbol,
elf_link_output_extsym() unconditionally calls the backend's
elf_backend_finish_dynamic_symbol callback. On targets that do not
support dynamic linking (and therefore do not define this callback),
the function pointer is NULL, causing a segmentation fault.
Add a NULL check for bed->elf_backend_finish_dynamic_symbol before
the indirect call. This is consistent with the definition in
elfxx-target.h which defaults this callback to 0 (NULL) for targets
that do not override it.
Found by AFL++ fuzzing of the ELF linker with mutated object files.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
Tom de Vries [Thu, 2 Apr 2026 21:09:09 +0000 (23:09 +0200)]
[gdb/tui] Make tui_setup_io more robust
The following sequence of events may happen when enabling TUI:
- tui_enable () is called,
- a SIGFPE happens, before tui_setup_io (1) is called,
- the SIGFPE triggers handle_fatal_signal, which calls tui_disable (),
- during tui_disable (), tui_setup_io (0) is called, and
- tui_setup_io (0) tries to restore things that were saved during a previous
tui_setup_io (1) call, but tui_setup_io (1) was never called so the saving
never happened.
This can cause current_ui.m_ui_stderr to be nullptr, which then can cause a
crash in sig_write (PR33918).
Fix this by:
- adding a variable tui_io_mode, and
- using the variable to bail out of tui_setup_io in case the current mode
doesn't change.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33918
Patrick Monnerat [Tue, 31 Mar 2026 14:44:44 +0000 (16:44 +0200)]
Support MinGW & 64-bit libraries/paths in Tcl autoconf scripts
Debian implements directories /usr/lib32 and /usr/lib64, but installs
tclConfig.sh and tkConfig.sh in /usr/lib. Therefore always search in
/usr/lib when the others fail.
Most of these changes were originally submitted by Keith Seitz for
Insight support.
This commit also strips trailing spaces and normalizes tab/space
indenting in config/tcl.m4.
In the setting of GAS and LD ABI flags the `*-*-linux*' target is used
twice in a different legs of a multi-part conditional, with the second
instance never having a chance to match due to the earlier one. Remove
the unused expression then.
The gdb.base/watchpoint.exp on Windows with non-stop support added
(later in the series) exposed an issue with the currently_stepping
logic when tested with software watchpoints.
The issue only happens when:
- You have multiple threads. gdb.base/watchpoint.exp exposed it on
Windows because there the OS always spawns a few extra threads.
- Displaced stepping is not available. The Windows non-stop work
does not implement displaced stepping yet. That is left as an
optimization for later.
- The target backend is working in non-stop mode.
I've written a new test that exposes the issue on GNU/Linux as well
(on hardware single-step targets, like x86-64). There, we see:
continue
Continuing.
../../src/gdb/infrun.c:2918: internal-error: resume_1: Assertion `!(thread_has_single_step_breakpoints_set (tp) && step)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp: target-non-stop=on: displaced-stepping=off: continue until exit (GDB internal error)
Currently, software watchpoints are implemented by forcing
single-stepping. That is done by currently_stepping returning true
when we have a software watchpoint. proceed calls resume, which calls
resume_1, which then ends up always requesting a single-step resume,
even if the higher layers wanted a continue.
Now, if you set a software watchpoint, and then continue the program,
and there's a breakpoint at the current PC, GDB needs to step over
that breakpoint first. If displaced stepping is not available, then
GDB temporarily pauses all threads, removes the breakpoint,
single-steps the thread that needs to move past the breakpoint, and
then finally, reinserts the breakpoint, and restarts all threads
again. That last restarting step happens in the restart_threads
infrun function.
restart_threads iterates over all threads trying to restart them one
by one. There, we have:
if (currently_stepping (tp))
{
infrun_debug_printf ("restart threads: [%s] was stepping",
tp->ptid.to_string ().c_str ());
but, what if TP is actually a new thread that hasn't yet ever set
stepping? currently_stepping still returns true, due to the software
watchpoint, and we end up in keep_going_stepped_thread, here:
if (tp->stop_pc () != tp->prev_pc)
{
ptid_t resume_ptid;
... because prev_pc was stale at that point (we had no reason to
update it earlier). E.g. on Windows we see something like:
[infrun] restart_threads: start: event_thread=1867996.1867996.0, inf=-1
[infrun] restart_threads: restart threads: [1867996.1867996.0] is event thread
[infrun] restart_threads: restart threads: [1867996.1868003.0] was stepping
[infrun] keep_going_stepped_thread: resuming previously stepped thread
[infrun] keep_going_stepped_thread: expected thread advanced also (0 -> 0x7ffff7ce57f8)
[infrun] clear_step_over_info: clearing step over info
[infrun] do_target_resume: resume_ptid=1867996.1868003.0, step=0, sig=GDB_SIGNAL_0
On GNU/Linux, we may see:
[infrun] keep_going_stepped_thread: expected thread advanced also (0x7ffff7d2683d -> 0x7ffff7ce57f8)
there prev_pc might have been updated on an earlier proceed call,
which makes the issue harder to see, but it is stale too here.
That means we insert a single-step breakpoint at the current PC, and
continue the thread, with target_resume directly, asking for a normal
continue.
Eventually, something causes a user-visible stop. For example, the
software watchpoint triggers. That makes GDB stop all threads.
Now, if the user re-resumes the program, say, with "continue", we fail
this assertion in resume_1 coming from proceed:
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(thread_has_single_step_breakpoints_set (tp) && step));
"step" is true because currently_stepping returns true since we have a
software watchpoint. And the thread has a single-step breakpoint
installed from earlier, because of that code mentioned above, in
keep_going_stepped_thread reached from restart_threads.
This patch fixes the root cause -- the currently_stepping call in
restart_threads returned true for a thread that has never set stepping
in the first place. This is because currently_stepping really serves
two purposes currently:
#1 - for a thread that we are about to resume, should we set it
stepping?
#2 - for a thread that just stopped, was it stepping before?
The fix is thus to decouple those two aspects:
- for #1, we simply rename currently_stepping to should_step.
- for #2, we record whether the thread was stepping before in a new
currently_stepping flag in thread_info.
As mentioned, there's a new testcase included. I tested this on
x86-64 GNU/Linux, native and gdbserver, and on Windows x64 with the
non-stop series. The assertion triggers on all of those with the fix,
and is fixed by this patch on all of those, too.
There's one unnecessary check for currently_stepping in
handle_signal_stop that can be removed. It is unnecessary because
currently_stepping is only ever called if
ecs->event_thread->control.trap_expected is true, and then if it is
true, then currently_stepping always returns true too.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I7b07bc62e8570333d2e4856d2e55ae6e58f8260c
commit-id:0125e966
Paul Eggert [Sun, 22 Mar 2026 21:08:47 +0000 (14:08 -0700)]
gdbserver: fix unlikely getpkt buffer overflow
This problem was reported by Manish Sharma.
Within gdbserver, in getpkt, there is no bounds checking as we parse
the incoming packet. An unexpectedly large packet can therefore
overflow the allocated buffer. Fixed by adding bounds checking.
If a packet is too long then in ACK mode we send out the NAK, but then
immediately return -1 as the result from getpkt. Currently the only
thing that GDB can do when it sees a '-' (NAK) is resend the packet.
If the original packet was too long then the resent packet will also
be too long. gdbserver would then be stuck re-reading the incoming
too long packet. Now GDB does give up after 3 retries, but this means
gdbserver is relying on GDB to give up sending, when in reality,
gdbserver knows it's not going to be able to recover. So I propose
that gdbserver should just give up once it sees a packet that is too
long.
While looking at the error handling in this case I noticed that in the
noack_mode case, if we get a packet with a bad checksum, or a packet
that is too long, getpkt will return success and gdbserver will try to
interpret whatever it has. This seems like a bad idea. So I've
updated this code path to also return an error.
Then there are a couple of places where we had a comment like this:
/* FIXME: Eventually add buffer overflow checking (to getpkt?) */
Now that getpkt does have buffer overflow checking, I've removed these
comments.
Pedro Alves [Wed, 11 Jun 2025 21:05:23 +0000 (22:05 +0100)]
Improve attach on Windows
Unlike most targets, on Windows, when you attach, GDB doesn't print
the current stack frame. Vis:
On GNU/Linux:
attach 3340347
Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19
19 while (! should_exit)
(gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
On Linux, GDB prints the frame because after the target_attach, GDB
goes back to the event loop, to wait for an initial stop event. The
stop event arrives, and we process it, which sets the stop_print_frame
global, and then we get to normal_stop, which prints the frame iff
stop_print_frame is set, which it is.
Windows OTOH, is a target_attach_no_wait target, so after
target_attach, there is no going back to event loop. In
infcmd.c:attach_command, we go straight to attach_post_wait which
takes us to normal_stop. But this time, nothing set stop_print_frame
to true, so no frame is printed. Actually, if the global happened to
be true due to an earlier event from debugging a previous inferior,
then we will print the frame.
This patch makes GDB's behavior consistent, by making sure the globals
normal_stop looks at are in a good state in the target_attach_no_wait
path.
With that alone, GDB now prints the frame:
(gdb) attach 2915
Attaching to program: /usr/bin/sleep.exe, process 2832
[New Thread 2832.0x2a68]
[New Thread 2832.0xb1c]
[New Thread 2832.0x8ac]
[Switching to Thread 2832.0x8ac]
0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
This is still not ideal, IMHO, as the current thread is the thread
that Windows injects to attach:
(gdb) info threads
Id Target Id Frame
1 Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll
2 Thread 2832.0x2a68 "sig" 0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll
3 Thread 2832.0xb1c 0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll
* 4 Thread 2832.0x8ac 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
Automatically switching to the main thread is IMHO more useful. That
results in very similar output than what we see on Linux:
attach 5164
Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
[New Thread 5164.0x87c]
[New Thread 5164.0x28f0]
[New Thread 5164.0x376c]
[New Thread 5164.0x2db4]
[New Thread 5164.0xce4]
main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
19 while (! should_exit)
(gdb)
If we do this, then we can simplify gdb.base/attach.exp a bit by
removing a couple Cygwin special cases.
The patch does all that, which results in the following
gdb.base/attach.exp progressions:
-FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
-FAIL: gdb.base/attach.exp: do_attach_tests: attach2, with no file
-FAIL: gdb.base/attach.exp: do_attach_tests: load file manually, after attach2 (re-read) (got interactive prompt)
-FAIL: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach
+PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
+PASS: gdb.base/attach.exp: do_attach_tests: attach2, with no file
+PASS: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
+PASS: gdb.base/attach.exp: do_attach_failure_tests: first attach
Andrew Burgess [Wed, 25 Mar 2026 16:41:46 +0000 (16:41 +0000)]
gdb: move call to clear_symtab_users out from finish_new_objfile
Move the call to clear_symtab_users from within finish_new_objfile to
instead reside within symbol_file_add_with_addrs. This resolves an
issue where clear_symtab_users can be called multiple times during the
loading of the main executable, which causes important information to
be discarded.
To understand the problem we must understand two things. First, how
does clear_symtab_users discard critical information? This is the
easy part of the problem, clear_symtab_users notifies the
all_objfiles_removed observer, in auto-load.c there is a listener for
this observer, clear_section_scripts, which discards information about
any auto-loaded scripts. If we call clear_symtab_users after
auto-loading a script within a program space, then information about
that script having been loaded will be discarded.
The second thing we must consider is the order in which functions are
called when loading a main executable with separate debug
information. I'm only listing some of the most important functions in
the process here, the ones relevant to the issue being fixed. In the
following text I'll use "main objfile" to refer to the actual
executable, and "debug info objfile" to refer to the split debug info
corresponding to the "main objfile".
1. Call symbol_file_add_with_addrs for the main objfile.
2. Call syms_from_objfile passing in the main objfile.
3. Call objfile::find_and_add_separate_symbol_file on the main
objfile.
4. Call symbol_file_add_separate for the debug info objfile.
5. Call symbol_file_add_with_addrs for the debug info objfile.
6. Call syms_from_objfile for the debug info objfile. The debug
symbols are contained in this objfile so they are read and added
to GDB.
7. Call finish_new_objfile for the debug info objfile, followed by
triggering the new objfile observer for the debug info objfile.
8. We are now done in symbol_file_add_with_addrs for the debug info
objfile. We now unwind the stack back to (1).
9. Back in symbol_file_add_with_addrs for the main objfile, the
debug symbols have now been added (from the separate debug info
objfile), so we can now call finish_new_objfile for the main
objfile, followed by triggering the new objfile observer for the
main objfile.
10. Success! The main objfile, and the associated debug info objfile
have now been added to GDB.
Notice that we end up with a recursive call back into
symbol_file_add_with_addrs, which results in two calls to
finish_new_objfile, the debug info objfile is processed first, and the
main objfile is processed second.
The main objfile will have SYMFILE_MAINLINE in its symfile_add_flags,
and this will end up being passed to symbol_file_add_separate.
This means that in finish_new_objfile we currently call
clear_symtab_users after finishing both the debug info objfile, and
after the main objfile, in that order.
Auto-loaded scripts are loaded by load_auto_scripts_for_objfile (in
auto-load.c) which is called by the new_objfile observer. If the
debug info objfile contains any scripts within the .debug_gdb_scripts
section, then these will be loaded (7) in the above list, after the
debug info objfile has been added, but before the main objfile is
added.
Now, this shouldn't be a problem, except that currently, when
finishing the main objfile, we call clear_symtab_users, which triggers
the all_objfiles_removed observer, which calls
clear_section_scripts (in auto-load.c), which discards all records of
auto-loaded scripts.
This issue is exposed by the test extension added in this commit. An
executable is compiled with debug information, the executable includes
a .debug_gdb_scripts section. We then use objcopy to split the debug
information into a separate objfile. This takes the
.debug_gdb_scripts section with it. We then ask GDB to load the
executable, which triggers loading of the separate debug information
file. Loading the separate debug information file loads the
.debug_gdb_scripts section, then GDB finishes loading the main
executable and discards the record of loading the .debug_gdb_scripts.
This is exposed by using 'info auto-load'.
The solution I propose is to move the call to clear_symtab_users
earlier within symbol_file_add_with_addrs, and to guard the call so
that it is only called for the main objfile, and not for the debug
info objfile. The new location for the clear_symtab_users call is
before the syms_from_objfile call. This means that it will be called
for the main objfile before GDB starts loading the debug info objfile.
There are two additional, related changes in this commit. The new
location for the clear_symtab_users call is before
program_space::symfile_object_file is removed by unlinking the
referenced objfile, so we don't want the breakpoint_re_set call in
clear_symtab_users to resolve breakpoints against the old objfiles.
To avoid this, at the new call to clear_symtab_users, we force the
SYMFILE_DEFER_BP_RESET. Then we restructure finish_new_objfile so
that breakpoint_re_set can always be called if appropriate. This
replaces the old breakpoint_re_set call which was reached via the old
call to clear_symtab_users.
Additionally, in finish_new_objfile, we only set
program_space::symfile_object_file for the main objfile. Previously
we would set this field first to the debug info objfile, and then
reset this field to the main objfile. This set then overwrite
sequence was harmless, but also pointless. I think by restricting
this code so we only set it to the main objfile better reflects the
state we want GDB to be in.
Andrew Burgess [Wed, 25 Mar 2026 16:28:05 +0000 (16:28 +0000)]
gdb/testsuite: modernise the gdb.python/py-section-script.exp test
I want to add more test cases to gdb.python/py-section-script.exp, so
this commit is an initial cleanup of the test script.
The primary change here is that we no longer overwrite the test
executable. The test has a loop, previously we'd overwrite the test
executable on each iteration, now we create a new test executable on
each iteration.
Additionally, at the end of the loop we strip the debug from the
executable and run some additional tests, I now create a copy of the
executable and strip the debug from that instead, this leaves the
unstripped executable around if we need to rerun tests outside of the
testsuite.
Then I've made some other small clean ups, making use of
$gdb_test_name, and the -wrap flag within gdb_test_multiple.
I've made use of require is_elf_target.
And I've factored out some code to set the auto-load safe path as in
some places we were switching the path separator, but in others we
just assumed ":". The helper proc always uses ";" for mingw.
I also added a full 'info auto-load python-scripts' check after
loading the stripped binary. Previously we only actually checked one
of the scripts had been loaded correctly.
Andrew Burgess [Wed, 4 Feb 2026 20:31:31 +0000 (20:31 +0000)]
gdb: introduce '**' for skip globs
There are cases when a user might wish to skip every file of a
particular type within a directory, and all its sub-directories.
Currently, you'll need to account for each sub-directory in your skip
patterns, so given:
Revert "skip -gfile: call fnmatch without FNM_FILE_NAME"
Due to bug PR gdb/33872. The initial commit also changed GDB in a
non-backward compatible way, that is 'skip -gfile /include/*.h' would
now match all .h files in every sub-directory of /include/, which
might not be what the user wants. The approach taken in this commit
avoids changing this behaviour and allows the user to better select
what they want to match.
This worked by splitting both the filename and the glob on every '/'
and then using a recursive algorithm to match each part of the file
name. This initial approach only split on '/' which means there would
have been some regressions on DOS based file systems where '\' can be
used as a directory separator, though this would probably have been
easy enough to fix.
However, it was pointed out that the splitting and matching was rather
inefficient, and it might be better to convert the glob into a regexp
and use that for matching. I figured; how hard can that be, which is
how this version of the patch came to be.
Turns out it's not that simple. I'm not going to go though all the
details here, but the basic idea is that, when the user creates a glob
skip GDB calls glob_to_regexp to convert the glob to a regexp, which
is then compiled and stored in the skiplist_entry. The regexp can
then be used as you'd expect to check for matches.
The matching is now done in a global function do_skip_gfile_p, which
makes it easier to write unit tests. The
skiplist_entry::do_skip_gfile_p just calls the global function.
I've retained the initial file basename check, which still uses
fnmatch, as this is likely quicker than performing the regexp match,
at least, I hope so, I've not tried to benchmark anything.
Converting a glob to a regexp is mostly straight forward, except for
bracket expressions, we dont want these to match against directory
separators, so we need to filter the directory separators out, this
retains compatibility with the fnmatch FNM_PATHNAME flag. It is this
filtering that is the cause of most of the pain. The details for all
of this can be found in glob_bracket_expr::parse.
We also need to take care to handle case insensitive file systems.
This is mostly just adding REG_ICASE to the regexp flags, however,
there are some issues with, you guessed it, bracket expressions. If
we have a character range that spans out of the upper case letter set,
for example [W-_], then, at least for glibc, when REG_ICASE is set
this ends up being treated like [w-_]. This is unfortunate because
'w' is after '_' so the range is now invalid. To resolve this we end
up splitting the range into two giving: [W-Z[-_], now when glibc
adjusts to lower case, we end up matching with [w-z[-_].
For DOS like file systems, the created regexp adds a pattern that
matches both '/' and '\' whenever either of these is seen in the glob.
But there's also some additional work needed for, you guessed it,
bracket expressions; we need to ensure '\' is removed from any ranges.
One final issue with, you guessed it, bracket expressions, is
character classes, e.g. [:alpha:]. Many classes are fine, but some,
like [:punct:] include '/' and '\'. For now I just raise an error if
the user tries to use a class that includes a directory separator.
This is a change in behaviour, but hopefully isn't going to impact too
many people. The only fix I can currently see for this would be to
expand the problematic character classes into their component
characters, and then remove the directory separators. But I haven't
tried to do that just yet.
There are documentation updates and tests for the new feature. All
existing behaviour should remain unchanged. On the testing side I've
added both some full DejaGNU tests and some self tests. The self
tests are focused on just the core glob matching function, but the
full DejaGNU tests ensure that the whole mechanism, from skip
creation to its final usage, is also tested.
Andrew Burgess [Tue, 10 Feb 2026 11:10:38 +0000 (11:10 +0000)]
gdb: move debug logging around in some skip related functions
Move the debug printing code out from skiplist_entry::do_skip_gfile_p
and skiplist_entry::do_skip_file_p. This will make the next commit
easier as we can switch to an early exit style function layout.
There should be no user visible changes, even when 'set debug skip on'
is in use, after this commit.
Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Keith Seitz <keiths@redhat.com>
Patrick Monnerat [Sat, 14 Mar 2026 15:23:26 +0000 (16:23 +0100)]
Support MinGW & 64-bit libraries/paths in Tcl autoconf scripts
Debian implements directories /usr/lib32 and /usr/lib64, but installs
tclConfig.sh and tkConfig.sh in /usr/lib. Therefore always search in
/usr/lib when the others fail.
Most of these changes were originally submitted by Keith Seitz for
Insight support.
After several years of dedicated service, Alan Hayward has decided to step down
from his role as maintainer. Alan has been instrumental in keeping the Arm
ports robust and modern. Most notably, he championed the complex task of
implementing support for the Scalable Vector Extension (SVE), which required
significant changes to how GDB handles variable register sizes, something that
is used for SME to this day. Beyond SVE, he also enabled Pointer Authentication
support for AArch64. And his work on XML target descriptions and general
infrastructure refactoring have left the codebase in a much stronger position.
We thank Alan for his leadership and his many contributions to the project over
the years.
At the same time, I am pleased to announce that Thiago Bauermann has agreed to
step up as a new co-maintainer for AArch64 and Arm. Thiago is already a familiar
face in the community, having contributed extensively to GDB on PowerPC and,
more recently, AArch64. His recent work on MOPS, GCS and SME features have been
vital for keeping GDB aligned with the latest developments on AArch64.
Thiago has also contributed significant time reviewing patches from others,
something that is highly appreciated in the community.
Please join me in thanking Alan for his hard work and welcoming Thiago to
his new role. I have updated the gdb/MAINTAINERS file accordingly.
Add --rosegment option to BFD linker to stop the '-z separate-code' from gen erating two read-only segments.
added --rosegment option to generate one read-only segment with
-z separate-code. But it puts the read-only data, which contains ELF
headers and .note.gnu.build-id section, in the executable segment:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x00185 0x00185 R E 0x1000
LOAD 0x001000 0x00001000 0x00001000 0x000d0 0x000d0 R 0x1000
LOAD 0x001f78 0x00002f78 0x00002f78 0x0008c 0x0008c RW 0x1000
DYNAMIC 0x001f78 0x00002f78 0x00002f78 0x00070 0x00070 RW 0x4
NOTE 0x000154 0x00000154 0x00000154 0x00024 0x00024 R 0x4
NOTE 0x00109c 0x0000109c 0x0000109c 0x00034 0x00034 R 0x4
GNU_PROPERTY 0x00109c 0x0000109c 0x0000109c 0x00034 0x00034 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x001f78 0x00002f78 0x00002f78 0x00088 0x00088 R 0x1
Eric Botcazou [Mon, 30 Mar 2026 17:10:26 +0000 (19:10 +0200)]
PE-COFF: Fix link failure of C++ code with debug info after partial linking
If you apply the following recipe to the attached C/C++ files with a PE-COFF
toolchain, you get the specified output:
1. g++ -c clib.cpp cpplib.cpp test.c -g
2. g++ -o pl.o clib.o cpplib.o -nostdlib -Wl,-r
3. objcopy pl.o
objcopy.exe: pl.o: warning: COMDAT symbol
'.debug_frame$_ZNSt12_Vector_baseIiSaIiEE12_Vector_implD1Ev' does not match
section name '.debug_frame'
4. g++ -o test test.o pl.o
ld.exe: pl.o: warning: COMDAT symbol
'.debug_frame$_ZNSt12_Vector_baseIiSaIiEE12_Vector_implD1Ev' does not match
section name '.debug_frame'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv'
pl.o:clib.cpp:(.pdata$_ZNSt15__new_allocatorIiE10deallocateEPiy+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt15__new_allocatorIiE10deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt15__new_allocatorIiE10deallocateEPiy+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt15__new_allocatorIiE10deallocateEPiy'
collect2.exe: error: ld returned 1 exit status
The problem pertains to section symbols generated for COMDAT sections: they
are marked as local symbols as per Microsoft's PE-COFF specification, but
partial linking discards the duplicate COMDAT sections without being able
to either merge them, or remove them when they are used in a relocation.
So they end up as undefined local symbols after the partial link, which in
turn may cause the final link to fail (in practice you need e.g. a call to
objcopy in between, because it moves them to the end of the symbol list).
This change instructs the linker to "relocate" them instead, that is to say
to attach them to the one COMDAT section that is output among the multiple
COMDAT sections that are duplicate. It also prevents partial linking from
prematurely globing the .[z]debug_frame* sections together, as already done
for the .eh_frame* sections.
bfd/
* cofflink.c (_bfd_coff_link_input_bfd): For a relocatable output,
relocate section symbols for input sections that are not going to
be emitted because they are duplicate of another one in the link.
ld/
* scripttempl/pe.sc (.debug_frame): Do not glob all .debug_frame*
sections together when not relocating.
(.zdebug_frame): Likewise for .zdebug_frame* sections.
* scripttempl/pep.sc (.debug_frame): Likewise.
(.zdebug_frame): Likewise.
Alan Modra [Mon, 30 Mar 2026 10:57:10 +0000 (21:27 +1030)]
obj_coff_sym_hashes sanity checks
Various places in cofflink.c and coffgen.c assume the r_symndx
indexing sym_hashes is sane. Add some checks.
* cofflink.c (_bfd_coff_link_input_bfd): Sanity check r_symndx
against obj_raw_syment_count before using it to index sym_hashes,
rather than just checking for the special -1 value.
(_bfd_coff_generic_relocate_section): Delete unnecessary check.
Sanity check weak symndx2 against obj_raw_syment_count.
* coffgen.c (_bfd_coff_gc_mark_hook): Sanity check weak symndx2
against obj_raw_syment_count.
(_bfd_coff_gc_mark_rsec): Sanity check r_symndx.
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.
projects / thirdparty / binutils-gdb.git / log
