Matthieu Longo [Tue, 26 May 2026 10:46:29 +0000 (11:46 +0100)]
gdb/python: fix memory leak in gdb_py_tp_name
The current implementation of gdb_py_tp_name() leaks a reference to the
object returned by PyType_GetFullyQualifiedName() for Python >= 3.13, and
PyType_GetQualName() for Python >= 3.11.
Managing the strong reference on the returned PyObject* with a gdbpy_ref<>
fixes the reference count, but also causes the temporary object to be
deallocated on function exit. As a consequence, the 'const char *' returned
by PyUnicode_AsUTF8AndSize() becomes dangling and can no longer safely be
returned.
The proposed approach consists in changing gdb_py_tp_name() to return a
std::string, and forcing a copy of the 'const char *' value, statically
or dynamically allocated, stored in a temporary or non-temporary PyObject,
depending on the version of Python it was compiled with.
An unfortunate side effect of this fix is that every call sites where the
tp_name is printed, must now use `.c_str()' because PyErr_Format()
and its siblings cannot handle std::string.
Jon Turney [Fri, 22 May 2026 12:43:15 +0000 (13:43 +0100)]
ld: Drop pep-dll-{aarch64,x86_64}.c
When configuring with
'--enable-targets=x86_64-w64-mingw32,aarch64-w64-mingw32', many
duplicate symbol errors are produced:
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_id_target':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:493: multiple definition of `pep_dll_id_target'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:493: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_add_excludes':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:586: multiple definition of `pep_dll_add_excludes'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:586: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_find_data_imports':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1444: multiple definition of `pep_find_data_imports'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1444: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_dll_generate_def_file':
> /wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1877: multiple definition of `pep_dll_generate_def_file'; pep-dll.o:/wip/binutils-gdb/build/ld/../../ld/pe-dll.c:1877: first defined here
> /usr/lib/gcc/x86_64-pc-cygwin/16/../../../../x86_64-pc-cygwin/bin/ld: pep-dll-aarch64.o: in function `pep_create_import_fixup':
> etc.
On investigation, this is unsurprising, since we're compiling the same code twice. In
fact, configure.tgt has:
... so we're potentially including pep-dll.c compiled under three
different names!
I can't see anything in pe{,p}-dll.c which depends on the
COFF_WITH_peAArch64 or COFF_WITH_pex64 defines, so just remove all this.
(Neither pep-dll-aarch64.o or pep-dll-x86_64.o are listed in
ALL_EMUL_EXTRA_OFILES, so this multiple definition problem doesn't show
up when configured --enable-targets=all', but this seems like another
source of subtle bugs if those defines did do anything here...)
Cc'ed Evgeny (Hi!), because I think this crosses with not-yet-submitted
patches of his which do add some code conditional on COFF_WITH_peAArch64.
I imagine it's possible in code which *does* need to depend on the
output target to replace build time checks of COFF_WITH_pe{AArch64,x64}
with a runtime check of the output architecture (via
pe_details->pe_arch?).
Cc: Evgeny Karpov <evgeny.karpov@arm.com> Fixes: c60b3806799a ("aarch64-pe support for LD, GAS and BFD") Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2026-05-29 Jon Turney <jon.turney@dronecode.org.uk>
Andrew Burgess [Tue, 19 May 2026 15:21:58 +0000 (16:21 +0100)]
gdb/frame: add FRAME_SCOPED_DEBUG_START_END
Add the FRAME_SCOPED_DEBUG_START_END macro, and make use of it in a
couple of places.
I find the frame debug output a little noisy, and it could be easier
to match up the entry/exit lines, by making use of
FRAME_SCOPED_DEBUG_START_END to print the frame level.
While I was adding the FRAME_SCOPED_DEBUG_START_END calls, there were
a couple of places where I also moved a variable declaration from the
top the a function into the function body. And in another couple of
places there was some debug output that could be removed, where the
existing debug just printed the frame level (this is now handled by
the START/END macro).
There should be no user visible changes after this commit unless 'set
debug frame on' is used of course.
zhaozhou [Mon, 25 May 2026 08:32:49 +0000 (16:32 +0800)]
LoongArch: Remove local hidden symbols testscase
Remove the local symbol ldh definitions with hidden visibility from the
relax-call36-*.s tests. The hidden visibility is meaningless for local
defined symbols and makes the test cases error.
Alan Modra [Wed, 3 Jun 2026 22:23:47 +0000 (07:53 +0930)]
elf_merge_st_other
This fixes a potential problem with merging non-visibility bits in
st_other. Non-visibilty bits in st_other have an architecture
dependent meaning, so they cannot just be copied from a foreign ELF
object file. I think the safest thing to do in this situation is
ignore non-visibility st_other bits. That's what this patch does.
PR 34062
* elflink.c (elf_merge_st_other): Replace abfd param with
obfd and ibfd parameters. Do not call
elf_backend_merge_symbol_attribute when input xvec differs
from output xvec.
(_bfd_elf_merge_symbol, _bfd_elf_add_default_symbol),
(elf_link_add_object_symbols),
(_bfd_elf_copy_link_hash_symbol_type): Pass both output bfd
and input bfd to elf_merge_st_other.
Alan Modra [Wed, 3 Jun 2026 22:22:44 +0000 (07:52 +0930)]
elflink.c: rename abfd and bed
This renames "abfd" function parameters to "obfd" when that parameter
is always the output bfd, and to "dynobj" when it is always the input
object used to attach dynamic sections. "bed" variables which are set
to the output bfd or dynobj backend data are renamed to "obed". (The
dynobj xvec must be the same as the output xvec, or bad things
happen.) The idea is to make the use of bfd* parameter a little more
obvious when reading the source.
Alan Modra [Tue, 2 Jun 2026 10:36:15 +0000 (20:06 +0930)]
spu: .note.spu_name
This fixes a bug with the .note.spu_name section flags, which were
made SEC_LOAD without SEC_ALLOC. That combination doesn't really make
sense and led to odd layout behaviour. In addition .note.spu_name
now uses the normal note alignment, with some tweaks to keep its file
offset 16 byte aligned. This tends to work better in the testsuite
when the standard scripts are not used and the note is merged with
other notes.
bfd/
* elf32-spu.c (spu_elf_create_sections): Remove SEC_LOAD from
.note.spu_name, and align to 4 bytes.
(spu_elf_fake_sections): Tweak .note.spu_name output section
alignment for layout.
(spu_elf_final_write_processing): New function.
(elf_backend_final_write_processing): Define.
binutils/
* testsuite/binutils-all/objcopy.exp (pr25662): Don't xfail spu.
ld/
* testsuite/ld-elf/orphan-region.d: Don't xfail spu.
* testsuite/ld-elf/pr23658-1e.d: Likewise.
* testsuite/ld-scripts/provide-8.d: Likewise.
* testsuite/ld-spu/ovl.d: Remove commented out old matches.
Adjust expected overlay file offset.
* testsuite/ld-spu/ovl2.d: Likewise.
The problem here is that gdb::remote_args::split expects a std::string,
and so ends up creating a std::string from ARGS. However, ARGS can be
NULL, e.g. if a user does this:
(gdb) maint test-remote-args
This ends up creating a std::string from a NULL pointer, which is
undefined behaviour.
Fix this by adding a check to test_remote_args_command, and throwing
an error if ARGS is NULL. Add a new test to verify this case.
Additionally, fix a typo in the header comment for
test_remote_args_command.
Ezra Sitorus [Mon, 1 Jun 2026 22:36:46 +0000 (23:36 +0100)]
gdb/aarch64: record/replay support for LRCPC3
FEAT_LRCPC3 introduces various load/store instructions with release
consistency for cases where ordering is required. This patch teaches GDB
to decode these instructions for recording and reversing.
The gdb.reverse/aarch64-lrcpc3.exp testcase verifies that the
instructions are recorded and correctly reversed. In particular, there
are some interesting cases to note:
* ldapur/stlur are SIMD instructions, but are not decoded in the simd
function.
* There are writeback cases to cover too. These were taken from the
binutils testcases: gas/testsuite/gas/aarch64/rcpc3.s.
The full testsuite was done on aarch64-none-linux-gnu without LRCPC3.
The gdb.arch and gdb.reverse tests were run on Shrinkwrap with LRCPC3
support.
Please note:
1) There is no support for LRCPC and LRCPC2 instructions
2) LRCPC3 is gated with +rcpc3 in GCC/binutils and LLVM.
Tom de Vries [Mon, 1 Jun 2026 18:14:37 +0000 (20:14 +0200)]
[gdb] Remove '/* *' multi-line comment marker
Doxygen supports a multi-line comment marker '/**'. In GDB we're using
something slightly similar: '/* *' [1].
Drop this and just use '/*'.
Result of:
...
$ find gdb* -type f -name "*.[ch]" -o -name "*.def" \
| egrep -v /testsuite/ \
| xargs sed -i 's%/\* \* %/* %'
...
and manually reverting the change in the comment for BINOP_MUL in
gdb/std-operator.def.
Tom de Vries [Mon, 1 Jun 2026 18:14:37 +0000 (20:14 +0200)]
[gdb/doc] Remove doxygen support
We have some form of doxygen support, allowing to run "make doxy" in
build/gdb/doc, but in the result I didn't find any references to gdbsupport
(moved to top-level in 2019), so I'm assuming this is unmaintained for a long
time now.
Remove it.
Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34186
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.
projects / thirdparty / binutils-gdb.git / log
