Tom de Vries [Mon, 1 Jun 2026 12:53:36 +0000 (14:53 +0200)]
[gdb/contrib] Add missing copyright notices
I found a few files in gdb/contrib that were missing a copyright notice.
In codespell-ignore-words.txt, it was trivial to add, but I found a
codespell issue stating that it's not explicitly support, so I added a note
about that.
In codespell-dictionary.txt, I had to resort to a hack, using an "empty word"
rewrite rule:
...
-># Comment here.
...
Also, I found that empty lines are not allowed in codespell-dictionary.txt. I
filed an issue about these two problems [1].
Since these two files were added in 2025, I've used 2025-2026 as copyright
years.
Tom de Vries [Mon, 1 Jun 2026 12:33:48 +0000 (14:33 +0200)]
[pre-commit] Move gdb/contrib/setup.cfg to gdb/pyproject.toml
The codespell settings are currently in gdb/contrib/setup.cfg.
There's a goal to move settings of Python tools used for gdb to
gdb/pyproject.toml.
Do so, and update the args entries in .pre-commit-config.yaml:
...
- args: [--config, gdb/contrib/setup.cfg]
+ args: [--toml, gdb/pyproject.toml]
...
It's necessary to point codespell as used in pre-commit to the pyproject.toml
file, because:
- pre-commit uses codespell with the repository root as working directory
- codespell currently only supports discovery of configuration files in the
working directory. There's an issue open to support hierarchical
pyproject.toml files [1].
Likewise, it's necessary to point codespell on the CLI to the pyproject.toml
file:
...
$ codespell --toml gdb/pyproject.toml
...
Now that the codespell settings are in gdb/pyproject.toml, codespell will
automatically discover it when running codespell in the gdb directory.
However, that's not useful, because the paths in gdb/pyproject.toml are
relative to the repository root. Hopefully, that will be fixed once codespell
supports hierarchical toml files.
In the mean time, we could fix this by moving the settings to a pyproject.toml
file in the repository root. But we have been avoiding this sofar (to keep
project-related things out of the repository root as much as possible), so we
continue having this pre-existing issue.
Tom de Vries [Mon, 1 Jun 2026 12:33:48 +0000 (14:33 +0200)]
[pre-commit] Make codespell:ignore-begin/end non-greedy
The current definition of codespell:ignore-begin/end is greedy and
consequently in this example:
...
/* codespell:ignore-begin */
/* Ignore this: usuable. */
/* codespell:ignore-end */
/* Don't ignore this: usuable. */
/* codespell:ignore-begin */
/* Ignore that: usuable. */
/* codespell:ignore-end */
...
the "Don't ignore this" line will be ignored.
Alan Modra [Mon, 1 Jun 2026 08:58:11 +0000 (18:28 +0930)]
macho section symbol handling
The macho gas support starts a new frag at non-local labels,
identifying the frag with the label symbol as a "subsection". Relocs
are needed when referencing labels in a different subsection, to
support relaxation. There is a problem when reloc symbols are reduced
to a section symbol plus offset (see write.c:adjust_reloc_syms), as
this loses the subsection. Not reducing symbols like this is not a
good option as it results in a large number of symbols, some with
weird internal gas names. So instead this patch finds the original
frag for any fx_addsy reduced to a section symbol.
The reason ".org test 1" fails is the -gdwarf2 .debug_aranges
generates two temp symbols and uses them for the start and size of
each range, the size being calculated by "end" - "beg" (see
out_debug_aranges). For the test, "beg" is before any source symbol
is emitted so has subsection NULL. "end" has a subsection but lost
that when the fixup was converted to a section symbol plus offset.
So prior to this change obj_mach_o_in_different_subsection returned
false. Now that the lost subsection is recovered for "end" it returns
true, and results in "Error: can't resolve .text - L0^A$".
* config/obj-macho.c (obj_mach_o_in_different_subsection):
Add parameters. Get frag containing section sym plus offset.
(obj_mach_o_force_reloc_sub_same): Adjust to suit
obj_mach_o_in_different_subsection change.
(obj_mach_o_force_reloc_sub_local): Likewise.
(obj_mach_o_force_reloc): Likewise.
* testsuite/gas/i386/insn-32.d: Don't xfail darwin.
* write.c (get_frag_for_address): New function, extracted from..
(get_frag_for_reloc): ..here.
* write.h (get_frag_for_address): Declare.
Reduced testcase:
.intel_syntax noprefix
mov eax, [offset x] - [1]
This triggers an obj_mach_o_check_before_writing error, because x
is indeed undefined. However, the error is nonsense because fx_subsy
is the absolute value 1, and that should just result in a relocation
against x with an addend of -1.
What's more, obj_mach_o_check_before_writing runs before symbols
are resolved. At that point undefined symbols may be wrapped in an
expression symbol. Expression symbols are S_IS_DEFINED, which is
why the error did not trigger until commit cc28c46227cd simplified
away the expression symbol wrapper. So obj_mach_o_check_before_writing
is ineffective in some cases and overly restrictive in others. If
something like it is necessary the correct place to do so is after
fixups have been simplified. In fact there is a sufficient check in
write.c:fixup_segment but the macho support disables it by defining
TC_VALIDATE_FIX_SUB to 1.
This patch reverts commit 16a87420985f (see
https://sourceware.org/pipermail/binutils/2012-February/075591.html),
and removes the define of TC_VALIDATE_FIX_SUB for macho. I'm sure it
is wrong to whitewash fixups by using TC_VALIDATE_FIX_SUB in this way.
Any fx_subsy that is left at that point will be ignored by the x86
md_apply_fix and tc_gen_reloc functions, except for a few special
cases. That will result in incorrect relocations.
The patch also corrects obj_mach_o_force_reloc_sub_local. Since this
is a predicate testing whether fx_subsy can be eliminated (and the
fixup made pc-relative) it ought to be testing for fx_subsy in the
same subsection as the fixup frag. This cures "FAIL: i386 sub".
Tom de Vries [Sat, 30 May 2026 12:46:22 +0000 (14:46 +0200)]
[gdb/testsuite] Use Wno-non-c-typedef-for-linkage for gcc 16
With gcc 16 and test-case gdb.cp/classes.exp I run into:
...
classes.cc:440:15: warning: anonymous non-C-compatible type given name for linkage purposes by 'typedef' declaration [-Wnon-c-typedef-for-linkage]^M
440 | typedef class {^M
| ^^M
| DynamicBase2^M
classes.cc:443:15: note: type is not C-compatible because it contains 'virtual int DynamicBase2::get_x()' declaration^M
443 | virtual int get_x () { return x; }^M
| ^~~~~^M
...
Fix this by applying Wno-non-c-typedef-for-linkage, which is already done for
clang.
Likewise for gdb.cp/class2.exp.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34187
Tom de Vries [Sat, 30 May 2026 12:46:22 +0000 (14:46 +0200)]
[gdb/testsuite] Fix ambiguous operator warning
With gcc 16, defaulting to c++20, and test-case gdb.cp/cmpd-minsyms.exp I run
into:
...
cmpd-minsyms.cc: In function 'int main(int, char**)':^M
cmpd-minsyms.cc:39:13: warning: C++20 says that these are ambiguous, even \
though the second is reversed:^M
39 | if (a == b)^M
| ^^M
cmpd-minsyms.cc:26:8: note: candidate 1: 'int GDB<T>::operator==(const GDB<T>&) [with T = int]'^M
26 | int operator == (GDB const& other)^M
| ^~~~~~~~^M
cmpd-minsyms.cc:26:8: note: candidate 2: 'int GDB<T>::operator==(const GDB<T>&) [with T = int]' (reversed)^M
cmpd-minsyms.cc:26:8: note: try making the operator a 'const' member function^M
...
Fix this by following the advice:
...
- int operator == (GDB const& other)
+ int operator == (GDB const& other) const
{ return 1; }
...
Likewise in gdb.cp/many-args.exp.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34187
Kevin Buettner [Thu, 14 May 2026 02:28:39 +0000 (19:28 -0700)]
contrib: Make dg-extract-results.py tolerant of unparseable files
This commit is for the benefit of GDB, but as the binutils-gdb
repository shares the contrib/ directory with GCC, this commit
must first be applied to GCC and then copied back to binutils-gdb.
When running GDB tests in parallel (make check -j$(nproc)), the
consolidated gdb.sum and gdb.log files are produced by
contrib/dg-extract-results.py, which merges per-test output files.
If any single per-test output file is malformed (e.g., due to a
DejaGnu EILSEQ crash, which is how I encountered this problem), the
script aborts via self.fatal(). Because this script is invoked via a
Makefile command using shell redirection, this causes the top-level
output files to be left as empty, zero-byte files, discarding valid
results from all other tests.
Fix by making the script tolerant of unparseable input files. Wrap
each file's parsing in a try/except block. When a file cannot be
parsed, emit a warning to stderr and continue processing remaining
files. This ensures that crashing tests do not destroy the
consolidated output for the entire parallel build.
Tested on Fedora 44 using the GCC testsuite (make check-gcc
-j$(nproc)). The consolidated results are produced correctly with
no regressions.
Running ...gdb/testsuite/gdb.base/utf8-identifiers.exp ...
ERROR: tcl error sourcing .../gdb/testsuite/gdb.base/utf8-identifiers.exp.
ERROR: tcl error code POSIX EILSEQ {invalid or incomplete multibyte or wide character}
error writing "file6": invalid or incomplete multibyte or wide character
...
(I've shortened some of the pathnames for brevity.)
These Fedora systems are using Tcl 9 and also an updated version of
dejagnu with this change applied:
* Thu Apr 16 2026 Jakub Jelinek <jakub@redhat.com> - 1:1.6.3-17
- Apply full set of Tcl 9 compatibility fixes from upstream PR80674 branch
(#2448542)
That runtest change is responsible for the POSIX EILSEQ errors on
machines with that change. The change to runtest causing the change
in behavior for GDB is the addition of these lines near the top of
the runtest script:
# Ensure that DejaGnu will be run in the POSIX locale
LC_ALL=C
export LC_ALL
Tcl 8 used a permissive encoding strategy: bytes that could not be
represented in the current encoding were silently mangled or
substituted. Tcl 9 changed this default to a strict profile, which
means that any attempt to write a character that cannot be expressed
in the channel's encoding raises a POSIX EILSEQ error ("invalid or
incomplete multibyte or wide character").
So, together, this Tcl 9 behavior combined with the dejagnu change
to runtest causes the EILSEQ error for the tests mentioned earlier.
Fix it by using "fconfigure $handle -encoding utf-8 -profile replace"
in proc spawn_capture_tty_name, and proc gdb_stdin_log_init. Also,
the open_logs wrapper has been changed to invoke fconfigure using only
"-encoding utf-8". Testing showed that "-profile replace" wasn't
necessary there.
With regard to the Bug noted below, I haven't been able to reproduce
the failures in gdb.ada/lazy-string.exp, but I've been informed that
this commit fixes it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34146 Reviewed-By: Tom de Vries <tdevries@suse.de>
Tom Tromey [Thu, 21 May 2026 17:41:53 +0000 (11:41 -0600)]
Use gdb::Requires in gdb::ref_ptr
Andrew pointed out that the use of is_convertible in gdb::ref_ptr is
incorrect, and that it should instead check the value. This can
easily be done using gdb::Requires.
Tom Tromey [Fri, 29 May 2026 17:08:50 +0000 (11:08 -0600)]
Remove ada-lang.c:eval_ternop_in_range
ada-lang.c:eval_ternop_in_range is only used in a single spot. This
patch merges it into its sole caller. Helper functions like this are
still sometimes left over from the big expression rewrite.
Tom de Vries [Fri, 29 May 2026 15:58:12 +0000 (17:58 +0200)]
[gdb/symtab] Add assert in free_cached_comp_units constructor
I wrote a patch containing:
...
dw2_instantiate_symtab (cu->per_cu, ...);
...
and ran into a use-after-free at a following use of cu.
The problem is that dw2_instantiate_symtab contains:
...
free_cached_comp_units freer (per_objfile);
...
and that the destructor does:
...
~free_cached_comp_units ()
{
m_per_objfile->remove_all_cus ();
}
...
which also frees the cu we used in the cu->per_cu argument to
dw2_instantiate_symtab.
Detect this situation using an assert in the free_cached_comp_units
constructor.
Tom de Vries [Thu, 28 May 2026 20:16:46 +0000 (22:16 +0200)]
[gdb/symtab] Fix data race in try_open_dwop_file
The call to bfd_check_format in try_open_dwop_file:
...
/* The operations below are not thread-safe, use a lock to synchronize
concurrent accesses. */
static gdb::mutex mutex;
gdb::lock_guard<gdb::mutex> lock (mutex);
if (!bfd_check_format (sym_bfd.get (), bfd_object))
return NULL;
...
accesses the sym_bfd.get () BFD, so it should be guarded by the global BFD
lock.
Fix this by:
- using the global BFD lock in gdb_bfd_check_format, and
- removing the local lock.
Likewise, use the global BFD lock in gdb_bfd_check_format_matches.
The local lock also guarded a call to gdb_bfd_record_inclusion, which doesn't
do any locking, so likewise use the global BFD lock in
gdb_bfd_record_inclusion.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33809
Tom de Vries [Thu, 28 May 2026 20:16:46 +0000 (22:16 +0200)]
[gdb] Add gdb_bfd_check_format and gdb_bfd_check_format_matches
Add new bfd wrappers:
- gdb_bfd_check_format for bfd_check_format, and
- gdb_bfd_check_format_matches for bfd_check_format_matches.
and run this command to use them:
...
$ sed -i 's/bfd_check_format/gdb_bfd_check_format/' \
$(find gdb* -type f | egrep -v "/testsuite/|ChangeLog")
...
Sivan Shani [Tue, 26 May 2026 11:48:25 +0000 (11:48 +0000)]
gas, bfd, gold: Rename Arm v8/v9 architecture tags
Rename the Arm AEABI CPU architecture tag constants and macro definitions to include the
profile suffix for A-profile architectures. This makes the naming
consistent with existing v8-R and v8-M tag names, while preserving the
existing numeric tag values.
Update BFD, GAS and Gold usage accordingly, including attribute combination
tables, architecture checks, and mach selection.
Ezra Sitorus [Wed, 27 May 2026 16:59:16 +0000 (17:59 +0100)]
gdb/aarch64: Test record/replay support for CSSC
GDB can handle AArch64's CSSC instructions but there were no tests
ensuring that and ensuring no regressions would creep in. This commit
adds some tests for these instructions. This was tested on
aarch64-none-linux-gnu on QEMU with CSSC support.
Alan Modra [Wed, 27 May 2026 12:07:31 +0000 (21:37 +0930)]
Re: alpha: Properly handle local weak undefined symbols
asan complains "runtime error: member access within null pointer"
for &h->root with NULL h, which is annoying since &h->root is the
same address as h, causing
alpha-linux-gnu +FAIL: TLS -fpic -shared
alpha-linux-gnu +FAIL: TLS -fpic and -fno-pic exec
alpha-linux-gnu +FAIL: TLS -fpic and -fno-pic exec -relax
* elf64-alpha.c (elf64_alpha_relocate_section): Fix asan
complaint.
Lancelot Six [Wed, 20 May 2026 17:22:56 +0000 (18:22 +0100)]
gdb/solib-rocm: add support for file URI on Windows
For processes using the ROCm runtime, GPU code objects are reported to
the debugger in the form of a URI (those are available to GDB using the
amd_dbgapi_process_code_object_list function and query the
AMD_DBGAPI_CODE_OBJECT_INFO_URI_NAME property). Each URI can be of 2
forms:
- "memory://$PID/mem#offset=$ADDR&size=$SIZE"
- "file://$PATH#offset=$OFFSET&size=$SIZE"
On the Windows platform, only the "memory" URI form is used at the
moment, but future runtime changes might make it report code objects
using the "file" form. When using the "file" form, when the runtime
reports an absolute path, the URI will look something like this:
The decoding scheme currently implemented in
gdb/solib-rocm:rocm_bfd_iovec_open would extract the file path as
"/C:/foo/bar/file.exe", and will eventually hand this path to
solib_open.
Surprisingly enough, solib_open still manages to locate the file
properly. This is due to the following of code which effectively drops
the leading "/" turning the path into a valid absolute path which can
eventually be opened.
/* If the search in gdb_sysroot failed, and the path name is
absolute at this point, make it relative. (openp will try and open the
file according to its absolute path otherwise, which is not what we want.)
Affects subsequent searches for this solib. */
if (found_file < 0 && IS_TARGET_ABSOLUTE_PATH (fskind, in_pathname))
{
/* First, get rid of any drive letters etc. */
while (!IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
in_pathname++;
/* Next, get rid of all leading dir separators. */
while (IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
in_pathname++;
}
This patch proposes to fix rocm_solib so we properly decode the file
path and give a valid path to solib_open to properly support this
scheme.
Note that this patch only looks for forward slashes "/" in the pattern
matching and not the traditional backslashes (as IS_TARGET_DIR_SEPARATOR
would) as URIs use forward slashes, not backslashes.
Current GDB does not really AMDGPU debugging on Windows (there are still
a couple of missing necessary pieces), but this patch can still be
applied upstream and will eventually be needed. I have tested this
patch on top of the downstream ROCgdb windows branch[1]. I have also
tested this patch on Linux + gfx1031 on top of master to ensure this
causes no regression.
Pedro Alves [Mon, 18 May 2026 13:20:00 +0000 (14:20 +0100)]
Sync thread state after infcalls with "set unwind-on-* on" (PR gdb/34148)
Commit 519774805a1 ("Don't pretend infcalls don't set the inferior
running (PR gdb/34082)") removed the special case in proceed that
skipped set_state(THREAD_RUNNING) for infcalls. That fixed
gdb.threads/hand-call-new-thread.exp, but introduced a regression in
gdb.compile/compile.exp:
...
set unwind-on-signal on
(gdb) PASS: gdb.compile/compile.exp: set unwind-on-signal on
compile code *(volatile int *) 0 = 0;
The program being debugged received signal SIGSEGV, Segmentation fault
while in a function called from GDB. GDB has restored the context
to what it was before the call. To change this behavior use
"set unwind-on-signal off". Evaluation of the expression containing
the function (_gdb_expr) will be abandoned.
(gdb) PASS: gdb.compile/compile.exp: compile code segfault second
break 132
Breakpoint 2 at 0x555555555262: file .../compile.c, line 132.
(gdb) continue
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.compile/compile.exp: continue to breakpoint: break-here
The "compile code" command before the FAIL is an infcall under the
hood. That hits SIGSEGV with "set unwind-on-signal on" in effect, so
GDB unwinds and abandons the call. After that, "continue" is rejected
because the thread is still marked THREAD_RUNNING from the proceed
that started the infcall.
When an infcall is unwound due to a signal, timeout, or terminating
exception, call_thread_fsm::should_notify_stop returns false, and so
normal_stop is not called from fetch_inferior_event. normal_stop is
what would normally call finish_thread_state to sync the public thread
state back to THREAD_STOPPED. run_inferior_call has a fallback
finish_thread_state call for that purpose, but it is gated on
stop_stack_dummy == STOP_STACK_DUMMY, which is only true for
successful calls.
Before the commit mentioned above, proceed never marked an infcall's
thread as THREAD_RUNNING, so the missing RUNNING => STOPPED transition
was harmless. The old comment in infcall.c about the
finish_thread_state call claimed "If the infcall does NOT succeed,
normal_stop will have already finished the thread states", but that
was already incorrect for the unwind paths. It just happened to not
matter.
Fix this by dropping the STOP_STACK_DUMMY guard and updating the
comment to describe the actual rule: sync regardless of how the call
ended. The !was_running check is kept since it is there to exclude
the in-cond-eval case, where the thread is meant to stay marked
running. finish_thread_state is idempotent, so the call is harmless
on paths where normal_stop also ran.
Extend gdb.base/unwindonsignal.exp to exercise the "set
unwind-on-signal on" path without having to rely on the "compile code"
feature. Without the fix, the test fails like so:
info threads
Id Target Id Frame
* 1 Thread 0x7ffff7f8f740 (LWP 239019) "unwindonsignal" (running)
(gdb) FAIL: gdb.base/unwindonsignal.exp: thread is stopped
continue
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.base/unwindonsignal.exp: continue until exit at after unwound infcall
Similarly, extend gdb.cp/gdb2495.exp for "set
unwind-on-terminating-exception on", and gdb.base/infcall-timeout.exp
for "set unwind-on-timeout on". Both would fail without the code fix,
too.
With the fix, gdb.compile/compile.exp now passes cleanly.
Tested on x86_64-unknown-linux-gnu.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34148
Change-Id: Idef0dcd4dd751b501869c58b752f77d4dadb6c72
Alan Modra [Tue, 26 May 2026 07:40:34 +0000 (17:10 +0930)]
aarch64 core: use of uninitialised value
Commit d0ff5ca959df adding PT_AARCH64_MEMTAG_MTE support, creates
a section that stores "p_memsz" from the program header in "rawsize"
and "p_filesz" in "size". p_memsz is the memory range, usually 32
times p_filesz. This can be a problem when bfd reads the section, for
example to display it with objdump -s, as the usual (linker) meaning
for input section "rawsize" is the original size on disk. Memory is
allocated to read the larger of "size" and "rawsize". So 32 times the
memory is allocated than what is really needed.
With fuzzed input "rawsize" can be smaller than "size" since the
header values are not sanity checked. This results in section
contents with only the first "rawsize" bytes read from disk, the rest
being uninitialised. Of course fuzzed input can also have very large
"rawsize" which might result in OOM.
One way of fixing this is to move the p_memsz value somewhere else
(output_offset would work, I think). Another might be to qualify use
of rawsize by is_linker_input, but I haven't checked over all the bfd
code using rawsize. And then there is this approach:
Pedro Alves [Thu, 21 May 2026 14:33:16 +0000 (15:33 +0100)]
Adjust gdb.base/exitsignal.exp for Cygwin
Cygwin has this feature where if the program is about to die with a
signal, and there's a debugger attached, it raises a SIGTRAP via
DebugBreak. So if you try to pass a terminating signal to the
inferior, you see that SIGTRAP first, before the process exits with
the signal. E.g.:
Thread 1 "segfault" received signal SIGSEGV, Segmentation fault.
0x0000000100401092 in main () at segfault.cc:5
5 *(volatile int *)0;
(gdb) c
Continuing.
Thread 1 "segfault" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffe99d35a13 in KERNELBASE!DebugBreak () from C:/WINDOWS/System32/KERNELBASE.dll
(gdb) bt
#0 0x00007ffe99d35a13 in KERNELBASE!DebugBreak () from C:/WINDOWS/System32/KERNELBASE.dll
#1 0x00007ffe896163b7 in break_here () at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/dcrt0.cc:473
#2 0x00007ffe8962fe13 in try_to_debug () at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/exceptions.cc:599
#3 exception::handle (e=0x7ffffc9b0, frame=<optimized out>, in=0x7ffffc4c0, dispatch=<optimized out>) at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/exceptions.cc:812
#4 0x00007ffe9c5e63df in ntdll!.chkstk () from C:/WINDOWS/SYSTEM32/ntdll.dll
#5 0x00007ffe9c499497 in ntdll!RtlLocateExtendedFeature () from C:/WINDOWS/SYSTEM32/ntdll.dll
#6 0x00007ffe9c5e5d1e in ntdll!KiUserExceptionDispatcher () from C:/WINDOWS/SYSTEM32/ntdll.dll
#7 0x0000000100401092 in main () at segfault.cc:5
(gdb) c
Continuing.
...
[Inferior 1 (process 8032) exited with code 05400]
(gdb)
gdb.base/exitsignal.exp fails on Cygwin partly because it doesn't take
that into account. This commit fixes it.
In addition, the typical adjustement for the fact that all programs
are multi-threaded on Windows is also necessary.
gdb.base/exitsignal.exp still won't pass cleanly on Cygwin yet.
That'll be finally fixed in a following patch.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I2d18e2604afe3a4f80987848e2c1cd307ed43401
commit-id: 013964ce
Pedro Alves [Wed, 20 May 2026 13:48:03 +0000 (14:48 +0100)]
Fix "set cwd ..." on Cygwin, part 2
Even after the previous patch, on both native and gdbserver Cygwin, we
get:
(gdb) set cwd /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal
(gdb) start
Temporary breakpoint 3 at 0x100401094: file /home/alves/rocm/gdb/src/gdb/testsuite/gdb.base/segv.c, line 26.
Starting program: /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal.exe
❌️ Error creating process /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal.exe (error 6): The handle is invalid.
(gdb)
On the native side, this is because in
windows_nat_target::create_inferior, we unconditionally convert
forward slashes to backward slashes:
and then cygwin_conv_path(CCP_POSIX_TO_WIN_W) does nothing on such
path, as the backward slashes make the path not look like a Unix-style
path.
CreateProcess then fails to CD into that directory, as that's not a
real Windows native path.
The fix is to not do the slashes replacement on Cygwin.
On the GDBserver side, we're just completely missing the
cygwin_conv_path logic. This commit adds it. The code isn't shared
with GDB because GDB uses wide chars, and GDBserver uses narrow char.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I004f2a562757a566423f6acb9aecfcc1a7f2f746
commit-id: 85aa8c22
Pedro Alves [Wed, 20 May 2026 12:14:07 +0000 (13:14 +0100)]
Fix "set cwd ..." on Cygwin, part 1
When running gdb.base/exitsignal.exp on Cygwin, we see:
(gdb) set cwd /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal
(gdb) run
Starting program: /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal
Error converting inferior cwd: 28
(gdb) FAIL: gdb.base/exitsignal.exp: runto: run to main
28 is ENOSPC. But this isn't really literally no space left, though.
cygwin_conv_path documentation mentions that error code.
According to the Cygwin API documentation for cygwin_conv_path, the
function fails with ENOSPC ("No space left on device") when the size
of the destination buffer is smaller than what is required for the
conversion. See:
If we look closely at how the buffer size argument is being passed, we
see we have two problems here:
1) Incorrectly passing down the input buffer size instead of the
output size.
The code passes strlen(inferior_cwd) as the size of the destination
buffer (infcwd). However, the target Windows path format
(e.g. "D:\cygwin-gdb\..." in my case) could be longer or shorter than
the POSIX source path ("/cygdrive/d/..."). In my specific case, the
source string is 64 characters, while the target Windows string is 61
(wide) characters (and twice as many bytes).
2) Incorrectly passing character count instead of byte count
The conversion target token is CCP_POSIX_TO_WIN_W. The _W means that
the destination buffer infcwd takes wide characters (wchar_t). The
documentation states that the size argument is in bytes, not
characters.
This commit fixes it, by passing the byte size of the destination
buffer.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I70af6ef394f48da35ccc2e04ef764915e09e59de
commit-id: 66c930c2
H.J. Lu [Fri, 22 May 2026 21:12:10 +0000 (05:12 +0800)]
alpha: Properly handle local weak undefined symbols
Since the local undefined TLS symbol address isn't mapped to any TLS
storage, it isn't usable. Set its value to 0 to avoid relocation overflow.
When processing TLS relocations, elf_hash_table (info)->tls_sec can be
NULL if all TLS symbols are weak, hidden and undefined. Don't assert
elf_hash_table (info)->tls_sec != NULL. Always set dtp_base and tp_base
to 0 if elf_hash_table (info)->tls_sec == NULL.
bfd/
PR ld/34165
* * elf-bfd.h (elf_link_local_undefweak_p): New function.
* elf64-alpha.c (elf64_alpha_relax_got_load): Set dtp_base and
tp_base to 0 if elf_hash_table (info)->tls_sec == NULL.
(elf64_alpha_relocate_section): Set the local undefined TLS
symbol value to 0. Don't assert elf_hash_table (info)->tls_sec
!= NULL.
hppa*64*-*-hpux*: Create dummy milli.a archive for binutils and ld tests
On cross builds, this fixes numerous test fails due to the milli.a
archive not being found. On hppa*64*-*-hpux*, this fixes four fails
due to undefined symbols in the HP milli.a archive.
The change to objcopy.exp causes the "objcopy executable (pr25662)"
test to fail. Previously, it didn't run because milli.a wasn't
found.
2026-05-24 John David Anglin <danglin@gcc.gnu.org>
binutils/ChangeLog:
* testsuite/binutils-all/objcopy.exp: Append LDFLAGS to
ldflags for milli.a archive.
* testsuite/config/default.exp: Create dummy milli.a archive
in tmpdir/hppa. Append " -Ltmpdir/hppa" to LDFLAGS.
Alan Modra [Sun, 24 May 2026 04:55:10 +0000 (14:25 +0930)]
"eqv involving dot" gas test and pdp11
This changes the eqv-dot test to make 'x' non-zero, so targets
(eg. i386-darwin) that silently ignore the value of fx_subsy in fixups
will fail the test.
When updating the test I noticed seriously odd expected output for
pdp11. Why should .long write in different byte order when needing
fixups (".long z")? That appears to be a bug in the pdp11
md_apply_fix, which reads section contents using pdp-endian but writes
them little-endian. Fix that too.
gas/
* config/tc-pdp11.c (md_apply_fix): Use md_mumber_to_chars.
* testsuite/gas/all/eqv-dot.s: Move x to second .long.
* testsuite/gas/all/eqv-dot.d: Update expected result.
* testsuite/gas/all/eqv-dot-pdp11.d: Likewise, and use
source directive.
* testsuite/gas/all/eqv-dot-pdp11.s: Delete.
* testsuite/gas/all/gas.exp (do_930509a): Support pdp11.
* testsuite/gas/all/simple-forward.d: Likewise.
Alan Modra [Sun, 24 May 2026 04:54:36 +0000 (14:24 +0930)]
mips: section .note.gnu.build-id can't be allocated in segment
After modifying test_build_id_debuglink, mips-linux fails
objcopy --only-keep-debug tmpdir/testprog tmpdir/testprog.debug
with the above error. This is due to .MIPS.abiflags and .reginfo
being made SHT_NOBITS but the .note.gnu.build-id which follows is
SHT_PROGBITS. That tickles a bug in file offset tracking.
* elf.c (assign_file_positions_for_load_sections): When
resetting "off_adjust" for sections with contents following
sections without contents, put back "off" too.
Alan Modra [Sun, 24 May 2026 04:53:03 +0000 (14:23 +0930)]
binutils test_build_id_debuglink
I saw build-id-debuglink test failures on a number of targets due to
deleting the glibc source I'd used when building the cross toolchains.
The tests failed with timeouts.
$ objdump -Sl tmpdir/testprog.strip
tmpdir/testprog.strip: file format elf64-ia64-little
I don't know where debuginfod was looking to try to find that crti.S
source, but wherever it was took too long, and we aren't trying to
test debuginfod here. So remove the extraneous source dependencies
by building with -shared -nostdlib. When making this change I also
removed the code passing extra options to target_compile via
CFLAGS_FOR_TARGET. Instead, pass extra options with additional_flags.
* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
Don't use CFLAGS_FOR_TARGET to pass extra options to
target_compile. Instead use additional_flags. Build test
with -fPIC -shared -nostdlib.
Hannes Domani [Thu, 7 May 2026 18:54:54 +0000 (20:54 +0200)]
Implement native TLS support on Windows
GCC 16 introduced native TLS variables on Windows, so this adds
debugger support for them.
The fetch_tls_load_module_address gdbarch method is used to get the
address of _tls_index of the OBJFILE, which is then forwarded as LM_ADDR
to windows_get_thread_local_address.
The TLS slot for a module can be found in
TIB->thread_local_storage[_tls_index].
Tom de Vries [Sat, 23 May 2026 08:16:57 +0000 (10:16 +0200)]
[gdb/testsuite] Improve dwarf assembly for implicit const in .debug_names
In the assembly generated for the dwarf assembly for test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, there's this bit:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_flag_present */
.sleb128 0x0002 /* DW_LANG_C */
...
As it happens, 0x21 is not DW_FORM_flag_present, but DW_FORM_implicit_const,
and the following entry is the value of the attribute.
Fix the comment, and make the relation between the two entries more clear by
printing:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_implicit_const */
.sleb128 0x0002 /* DW_FORM_implicit_const value: DW_LANG_C */
...
Tom de Vries [Sat, 23 May 2026 08:16:57 +0000 (10:16 +0200)]
[gdb/testsuite] Add missing type_offset in gdb.dwarf/debug-names-tu.exp
With llvm-dwarfdump we run into this warning:
...
$ llvm-dwarfdump -a -v debug-names-tu > /dev/null
warning: DWARF type unit at offset 0x00000028 has its relocated type_offset \
0x00000028 pointing inside the header
...
Fix this by adding the missing type_offset.
Likewise in gdb.dwarf2/debug-names-bad-cu-index.exp.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157
Tom de Vries [Fri, 22 May 2026 13:11:56 +0000 (15:11 +0200)]
[binutils] Handle implicit const in .debug_names
I tried to use readelf to read the debug info for gdb test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, and ran into some trouble reading the
.debug_names section:
...
$ readelf -w debug-names-tu-dwarf5
...
Symbol table:
[ 1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 2] #53a2ae86 struct_with_int_member:readelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
<0x3><2> DW_TAG_structure_type DW_IDX_type_unit=0 DW_IDX_GNU_language=0 DW_IDX_type_unitreadelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
...
The .debug_names abbreviation table contains a DW_FORM_implicit_const entry:
...
.uleb128 0x2003 /* DW_IDX_GNU_language */
.uleb128 0x21 /* DW_FORM_implicit_const */
.sleb128 0x0002 /* DW_FORM_implicit_const value: DW_LANG_C */
...
and readelf doesn't support this.
Add support for DW_FORM_implicit_const in display_debug_names, such that we
get the expected:
...
Symbol table:
[ 1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 2] #53a2ae86 struct_with_int_member: <0x3><2> DW_TAG_structure_type \
DW_IDX_type_unit=0 DW_IDX_GNU_language=2
...
Jan Beulich [Fri, 22 May 2026 06:49:12 +0000 (08:49 +0200)]
x86/disasm: rework comment handling
Model this after operand handling, such that comments can be emitted in
the same order as operands. %rip-relative address comments remain
separate for now. While there correct style for the symbols associated
with immediates: These aren't "comment starts", but symbol names.
The thread_local g_complaint_interceptor pointer is unnecessary. The
complaint_interceptor constructor registers itself as the warning hook
via m_saved_warning_hook (this), so when complaint_internal dispatches
through the warning hook, it lands in complaint_interceptor::warn with
'this' already pointing at the registered interceptor. Inside warn,
g_complaint_interceptor and 'this' always refer to the same object.
Replace g_complaint_interceptor->m_complaints with m_complaints in
complaint_interceptor::warn and remove g_complaint_interceptor.
Change-Id: I75565a5f2c0e51363f36be0e3544210c10bb5491 Approved-By: Tom Tromey <tom@tromey.com>
Location is heap block of size 32 at 0x7208000004c0 allocated by main thread:
...
#11 __static_initialization_and_destruction_0 /home/simark/src/binutils-gdb/gdb/complaints.c:31 (gdb+0xf0df04) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
...
This points to clear_complaints touching the global counters map in the
main thread without holding a lock, while a background thread touched
the map in a worker thread while holding the lock complaint_mutex.
Fix this by holding the complaint_mutex lock in clear_complaints.
Change-Id: Id2fe442486bcdf57156aacdc9253055702c07600 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 20 May 2026 18:19:29 +0000 (14:19 -0400)]
gdb/dwarf: track whether the all_units vector is sorted
dwarf2_find_unit performs a binary search over dwarf2_per_bfd::all_units
using std::lower_bound. Before calling std::lower_bound, we want to
make sure that all_units is properly sorted.
Track the state of whether all_units is considered sorted with a new
dwarf2_per_bfd::all_units_sorted flag, and assert it in
dwarf2_find_unit. This will help catch bugs where we call
dwarf2_find_unit on a non sorted vector, for instance what was fixed by
commit fbaef7de7701 ("gdb/dwarf: fix order of operations when reading
.debug_names").
The flag is set:
- At initialization time, because an empty vector is sorted.
- Whenever the vector is cleared, for the same reason (added a helper
method for that).
- After sorting in dwarf2_per_bfd::sort_all_unit.
It is cleared:
- Whenever a unit is appended to all_units. To keep this centralized,
add a new dwarf2_per_bfd::add_unit helper that appends the unit and
clears the flag.
- Whenever a unit's sort key (section / sect_off) is modified. That is
done in dwarf2_per_cu::set_section and dwarf2_per_cu::set_sect_off.
Note that the flag is cleared when appending a unit even if the vector
would by chance already be sorted. This is good, because it will catch
mistakes even on machines where a problem with std::lower_bound would
not manifest.
I checked that this patch would have caught the problem before commit fbaef7de7701:
Simon Marchi [Wed, 20 May 2026 18:19:28 +0000 (14:19 -0400)]
gdb/dwarf: change signatured_type_up to include deleter type
We currently have:
using dwarf2_per_cu_up = std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>;
using signatured_type_up = std::unique_ptr<signatured_type>;
Meaning that it's not possible to pass a signatured_type_up as a
dwarf2_per_cu_up, even though the target types are related (it is
possible to pass a `signatured_type *` as a `dwarf2_per_cu *`).
If we give signatured_type_up the same deleter as dwarf2_per_cu_up, then
it becomes possible to pass a signatured_type_up as a dwarf2_per_cu_up.
This lets us avoid releasing a signatured_type_up only to create a
dwarf2dwarf2_per_cu_up immediately after in some spots. The only
downside is that we can't use make_unique anymore, but it's already the
case for dwarf2_per_cu_up.
Swap the order of things in add_type_unit so that we don't need a
special holder variable.
Change-Id: Iee34e5d1711d601297f109e58cbaeccb5a0c6cde Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 8 May 2026 16:44:59 +0000 (10:44 -0600)]
Add test for Ada abs operator
There were no tests in the tree for the Ada abs operator, meaning that
ada_abs was never invoked during a test. This patch adds a new basic
test for this.
Note that operator overloading of 'abs' does seem to be tested.
Tom Tromey [Fri, 8 May 2026 16:36:26 +0000 (10:36 -0600)]
Test attributes with array types
While looking at code coverage, I noticed that gdb was not testing the
case where certain attributes were applied to an Ada array type. This
patch adds some new tests, improving the coverage.
gdb/amd-dbgapi-target: suppress a repeated stop request
Sending a second stop request to an AMD GPU thread before fetching the
event caused by the first request leads to an error:
wave_stop for wave_1 failed (The wave has an outstanding stop request)
Prevent sending a new stop request if there already is an outstanding
one. The fix is in amd_dbgapi_target::stop.
A regression test is included. The test uses non-stop mode and
executes the "interrupt" command twice, because in non-stop mode this
command uses the 'stop' target op, where the fix is applied.
To be able to execute two interrupt commands repeatedly, we define a
user command.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Abdul Basit Ijaz [Tue, 21 Apr 2026 12:05:08 +0000 (14:05 +0200)]
gdb: Handle TYPE_CODE_COMPLEX in valprint_check_validity.
When printing complex variables with partial optimization (e.g., real
part available but imaginary part optimized out), GDB incorrectly
reported the entire variable as <optimized out> instead of showing
available components.
The issue occurred because valprint_check_validity () only exempted
TYPE_CODE_UNION, TYPE_CODE_STRUCT, and TYPE_CODE_ARRAY from the
optimized-out check, but not TYPE_CODE_COMPLEX. Complex types, like
structures, can have components with different availability.
A new test gdb.dwarf2/complex-partial-optimized.exp is added to verify
that available components are printed.
Simon Marchi [Tue, 19 May 2026 20:09:10 +0000 (16:09 -0400)]
gdb/dwarf: fix order of operations when reading .debug_names
PR 34149 shows a hard to reproduce bug. The problem sometimes shows up
when reading in `.debug_names` indexes, manifesting like this:
warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.
This is shown even if the CU table in the `.debug_names` index
accurately describes the CUs in `.debug_info`.
The bug was introduced by commit b301725d35c1 ("gdb/dwarf: read foreign
type units").
Before b301725d35c1, the steps when reading a `.debug_names` index were:
- call to create_all_units(), which filled the all_units vector by
walking `.debug_info` and `.debug_types` and then sorted it.
- calls to the build_and_check_* functions, which do some lookups in
the all_units vector, requiring it to be sorted.
- call to create_all_units(), which still fills the all_units vector by
walking `.debug_info` and `.debug_types`, but does not sort it
anymore.
- calls to the build_and_check_* functions, which do some lookups in
the all_units vector, requiring it to be sorted (oops)
- call to create_foreign_type_units_from_debug_names(), which may add
more items to the all_units vector.
- call to finalize_all_units(), to sort the all_units vector.
The sorting of all_units was taken out of create_all_units() on purpose.
Because create_foreign_type_units_from_debug_names() may add more units,
we don't want to sort the vector in create_all_units() and then sort it
again after create_foreign_type_units_from_debug_names().
The build_and_check_* functions do some lookups in the all_units vector
with dwarf2_find_unit(), which uses std::lower_bound() internally. This
happens while the all_units vector is not sorted according to the
sorting key, all_units_less_than(), which makes the search is bogus.
dwarf2_find_unit() might return "no such unit", when in fact, the given
unit exists. This leads build_and_check_cu_list_from_debug_names() to
believe that the list of CUs in the `.debug_names` index does not match
what was built from reading `.debug_info`, we get the warning shown
above, and the index gets wrongfully rejected.
For this bug to show up, it is necessary to have type units in a
`.debug_types`. The sorting key for units in the all_units vector is:
section pointer (`dwarf2_section_info *`), then the unit offset into the
section. If all units come from the same section (`.debug_info`), then
this bug does not show up because the all_units vector happens to be
sorted after create_all_units() runs. This happens for example in test
gdb.dwarf2/debug-names-bad-cu-index.exp, where we create some DWARF 4
units and then a `.debug_names` index out of them.
It must also happen for the `dwarf2_section_info *` for `.debug_types`
to be "less than" the `dwarf2_section_info *` for `.debug_info`,
otherwise the all_units also happens to be sorted after
create_all_units() runs. This entirely depends on the whims of the
memory allocator.
I was not able to reproduce it in my normal GDB dev build, but I was
able in a "thread sanitizer" build, for some reason. Not because there
is an actual threading issue, but I think because it shuffled the memory
allocations in just the right way to make the bug happen. And then, it
only happened when doing "make check", I could not get it to reproduce
when running interactively. Using -D_GLIBCXX_DEBUG was immensely
useful, because it pointed out that the "range must be sorted"
precondition for std::lower_bound() was not met, which made the problem
immediately obvious:
Error: elements in iterator range [first, last) are not partitioned by the
predicate __comp and value __val.
Knowing all this, is it easy to artificially reproduce the problem by
making create_all_units() reverse the all_units vector, like so:
// Reverse the all_units vector
std::reverse (per_objfile->per_bfd->all_units.begin (),
per_objfile->per_bfd->all_units.end ());
The fix is to reorder the operations in this way
- call create_all_units(), to fill the all_units vector by walking
`.debug_info` and `.debug_types`
- call create_foreign_type_units_from_debug_names(), which may add more
items to the all_units vector.
- call finalize_all_units(), to sort the all_units vector.
- call the build_and_check_* functions, which is fine now that
all_units is sorted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34149
Change-Id: I315f391605af549b55341a167683d2dc6203bcea Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Tue, 12 May 2026 00:27:16 +0000 (09:57 +0930)]
PR 30308 again
Commit 22f8905d9f38 reintroduced pr30308. This fix resolves equates
safely in the presence of symbol loops by using symbol_equated_to.
Symbols aren't prematurely modified, by copying their value
expressions before i386_intel_simplify does its work. I figure that
it is safer to do this for all symbols rather than just the particular
case of equates, so the in_equate parameter can disappear.
Tom de Vries [Wed, 20 May 2026 06:31:12 +0000 (08:31 +0200)]
[gdb/tui] Allow second tui enable if first fails
Commit fb23d7ba4a2 ("[gdb/tui] Handle error in tui_enable") handles a
particular error during tui_enable, but doesn't allow trying to enable TUI
again.
I tried to get this to work, but didn't manage because I didn't understand the
interaction between endwin and the "tui_batch_rendering defer" destructor:
- first endwin restores the shell terminal mode
- then the defer destructor calls doupdate, restoring program terminal mode.
Fix this by checking for tui_active in ~tui_batch_rendering.
Tom de Vries [Wed, 20 May 2026 06:31:12 +0000 (08:31 +0200)]
[gdb/tui] Factor out require_tui_terminal
I noticed this bit of code in tui_enable:
...
/* Check required terminal capabilities. The MinGW port of
ncurses does have them, but doesn't expose them through "cup". */
cap = tigetstr ((char *) "cup");
if (cap == NULL || cap == (char *) -1 || *cap == '\0')
{
endwin ();
delscreen (s);
error (_("Cannot enable the TUI: "
"terminal doesn't support cursor addressing [TERM=%s]"),
gdb_getenv_term ());
}
...
At this point in tui_enable, we need endwin and delscreen to clean up after
newterm, but the check can be done before newterm.
Fix this by factoring out a new function require_tui_terminal, and moving the
code there.
Andrew Burgess [Thu, 14 May 2026 16:47:01 +0000 (17:47 +0100)]
gdb/testsuite: add a test to check for Python traits static_assert
The previous two commits added a new type trait which can be used
within a static_assert to check the properties of a struct used by GDB
to implement Python objects.
The previous commit fixed a bug in GDB which this trait check exposed.
This commit adds a new test gdb.gdb/python-traits-check.exp which
checks that every struct in the Python/ directory that inherits from
PyObject, has a suitable static_assert in place.
Adding this test should mean that if someone adds a new Python object
type to GDB, and they forget to add the static_assert, then this test
should give a failure, which should remind them to add the required
static_assert. The static_assert will then check that their new
struct is compliant.
Andrew Burgess [Thu, 14 May 2026 09:42:59 +0000 (10:42 +0100)]
gdb/python: fix use of frame_info_ptr within pending_frame_object
The previous commit added a type trait which identifies types that
should not be used within Python objects, that is, types that are not
trivially default constructible. As a result of this, it was
discovered that pending_frame_object includes a frame_info_ptr field.
The problem with frame_info_ptr is that its constructor registers the
new frame_info_ptr with the global frame_list. It is by this
registration that invalidation of frame_info_ptr objects is performed.
As Python is written in C, C++ constructors are not called, so when a
pending_frame_object is created the constructor for the nested
frame_info_ptr field is never run, and the frame_info_ptr is never
registered with the global frame_list. As a result the frame_info_ptr
will never be invalidated if the frame cache is flushed, this can then
lead to problems where we make use of the 'frame_info *' within the
frame_info_ptr, even though it is no longer valid.
In this commit I change the frame_info_ptr within pending_frame_object
to a 'frame_info_ptr *' and allocate the frame_info_ptr object on the
heap, releasing the object, and resetting the point to NULL, when we
are done with it. As the pending_frame_object only needs to remain
valid for the duration of frame_unwind_python::sniff, the 'new' and
'delete' both performed within the function.
We can now check that a pending_frame_object is valid by checking if
the 'frame_info_ptr *' is NULL or not. As the frame_info_ptr is
created in a valid state, and the point is set back to NULL when we
are done with it, we no longer need to compare the frame_info_ptr
object itself against NULL.
The remaining changes in this patch are to dereference the
'frame_info_ptr *' in places where we need the actual object. In some
cases I need to move the dereference later within a function, after a
validity check, in order to avoid dereferencing a NULL pointer.
Finally, I can add the static_assert that guarantees that
pending_frame_object is now safe for allocation by Python.
I discovered this bug while looking at PR gdb/32120. That bug is
about a user's custom frame unwinder that triggers a flush of the
frame cache during the sniffer phase (the
RemoteTargetConnection.send_packet call switches thread, which
triggers the frame cache flush). While looking at that bug I noticed
that the frame_info_ptr within the pending_frame_object wasn't being
reset when the frame cache was flushed. Fixing this does not resolve
the user's issue, but I thought it was still worth tagging this commit
with the bug link.
Andrew Burgess [Thu, 14 May 2026 08:39:57 +0000 (09:39 +0100)]
gdb/python: add type traits check for all PyObject sub-classes
All of our custom Python types are created as structs, like this:
struct some_new_type : public PyObject
{
... various fields ...
};
Then instances of this struct are created by calling PyObject_New,
either directly within GDB's C++ code, or within Python when a user's
Python script creates an instance of that class.
The problem is that Python is written in C, and PyObject_New doesn't
call any constructors for `some_new_type`, nor for any of the fields
within `some_new_type`.
If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to
be more C++ specific, if `some_new_type` is trivially default
constructable, then we're fine.
But if a field within `some_new_type` has a non-trivial constructor,
then we're in trouble as that constructor will never be run.
An example of a problematic field type is frame_info_ptr. The
constructor for this type registers the new object with a central
management object, recording the `this` pointer, using this type within
`some_new_type` will not work as expected; frame invalidation will not
show up within the frame_info_ptr as you might expect.
And so, this type trait exists. Whenever a struct is created to define
a new Python type we should add a line like:
This will fail if any field of `some_new_type` are unsuitable for this
use.
We don't actually check is_trivially_default_constructible here. Some
types, e.g. ui_file_style::color, have non-trivial (or no default)
constructors, but are still safe to use within `some_new_type` because
their constructors just initialise data fields; there's nothing
"special" that the constructor does that cannot be achieved by
assigning the fields after creation with PyObject_New.
What actually matters is that the type is trivially destructible
(Python won't call C++ destructors, so destructors with side effects,
like deregistering from a list, would be skipped) and trivially
copyable (Python may copy objects with memcpy). Types like
frame_info_ptr, whose constructors and destructors have side effects
such as registering with a central management object, will be caught
because they are neither trivially destructible nor trivially copyable.
Simple POD types like ui_file_style are trivially destructible and
copyable, so pass this trait.
This commit adds the new type trait, and makes use of it in all cases
but one, pending_frame_object in python/py-unwind.c, has a field of
type frame_info_ptr, which is currently broken. This will be fixed,
and the static_assert added, in the next commit.
Alan Modra [Sat, 16 May 2026 00:57:26 +0000 (10:27 +0930)]
Re: binutils/configure: look for msgpack-c.pc (in addition to msgpack.pc)
Commit 520c7eefed7f results in the following if both msgpack-c and
msgpack are missing.
checking for msgpack-c... no
checking for msgpack... no
configure: error: Package requirements (msgpack) were not met:
Package 'msgpack', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables MSGPACK_CFLAGS
and MSGPACK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make[2]: *** [Makefile:920: config.status] Error 1
make[2]: Leaving directory '/build/gas/all/binutils'
make[1]: *** [Makefile:4123: all-binutils] Error 2
binutils/
* configure.ac <msgpack>: Tell PKG_CHECK_MODULES that errors
will be handled by its caller.
* configure: Regenerate.
bfd/
* bfd-in2.h: Regenerate.
projects / thirdparty / binutils-gdb.git / log
