Tom de Vries [Wed, 10 Jun 2026 07:54:22 +0000 (09:54 +0200)]
[gdb/contrib] Fix KeyError in dwarf-to-dwarf-assembler.py
Executable outputs/gdb.threads/stepi-over-clone/stepi-over-clone contains the
following DWARF (using readelf -w):
...
<31c5> DW_AT_const_value : 8 byte block: ff ff ff ff ff ff ff ff
...
or more explicit using llvm-dwarfdump -v:
...
DW_AT_const_value [DW_FORM_block1] \
(<0x08> ff ff ff ff ff ff ff ff )
...
Before commit 18ad8c1a54d ("Emit DWARF expressions from
dwarf-to-dwarf-assembler.py"), the dwarf-to-dwarf-assembler.py script
generated:
...
DW_AT_const_value { MANUAL: Fill expr list } SPECIAL_expr
...
for this.
But since the commit, we run into a KeyError.
The problem is that we're trying to interpret some random data as a DWARF
expression.
Fix this by special-casing DW_AT_const_value, and generating instead:
...
DW_AT_const_value "\xff\xff\xff\xff\xff\xff\xff\xff" DW_FORM_block1
...
which mimics the style I found in gdb.dwarf2/info-locals-optimized-out.exp:
...
DW_TAG_variable {
DW_AT_name const_bytes
DW_AT_type :$int_type_label
DW_AT_const_value "\x01\x01\x01\x01" DW_FORM_block1
}
...
Likewise for DW_AT_discr_list.
Another case for which the KeyError triggers, is DWARF from
outputs/gdb.ada/array_of_variant/p-minimal:
...
<2><14a4>: Abbrev Number: 20 (DW_TAG_structure_type)
<14a5> DW_AT_name : p__payload_t
<14a9> DW_AT_byte_size : 18 byte block: \
fd 63 14 0 0 97 94 1 99 45 0 0 0 23 7 9 fc 1a \
(DW_OP_GNU_variable_value: <0x1463>; \
DW_OP_push_object_address; \
DW_OP_deref_size: 1; \
DW_OP_call4: <0x1421>; \
DW_OP_plus_uconst: 7; \
DW_OP_const1s: -4; DW_OP_and)
...
because the pyelftools version that I'm using doesn't support
DW_OP_GNU_variable_value yet (supported starting v0.33).
Fix this by catching the KeyError, and falling back to the string case:
...
DW_AT_byte_size \
"\xfd\x63\x14\x00\x00\x97\x94\x01\x99\x45\x00\x00\x00\x23\x07\x09\xfc\x1a" \
DW_FORM_exprloc # Failed to print op as DWARF expression: 0xfd
...
Alan Modra [Wed, 10 Jun 2026 02:10:59 +0000 (11:40 +0930)]
PR 34204 dlltool SEGVs with --exclude-symbols
This fixes a segfault introduced by commit 45a7f5a29de7 which didn't
take into account that there was a use of leading_underscore in option
processing.
PR 34204
* dlltool.c (struct string_list): Make string a flexible array
member.
(add_excludes): Adjust to suit. Extract code adding underscore
and informing..
(underscore_excludes): ..to here. New function.
(main): Call underscore_excludes.
Markus Metzger [Thu, 20 Nov 2025 11:21:41 +0000 (11:21 +0000)]
gdb, btrace: support libipt v2.2 events
Add support for printing new events added in libipt v2.2 originating from
Event Tracing in combination with Flexible Return and Event Delivery
(FRED) and from Trigger Tracing.
Reviewed-By: Keith Seitz <keiths@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Tue, 9 Jun 2026 13:36:37 +0000 (07:36 -0600)]
Make two Ada tests more robust
tasks.exp and task_watch.exp were failing when run with gnat-llvm.
Investigating these showed the same problem (which makes sense because
the tests use the same program). In this code:
for J in Task_List'Range loop -- STOP_HERE
Task_List (J).Call_Break_Me;
end loop;
... with GCC, the breakpoint set on the 'for' line is only hit a
single time. However, with gnat-llvm, the breakpoint is hit on every
iteration of the loop. IMO this is a GCC bug.
Similarly, at the end of the function:
null; -- STOP_HERE_2
... with gnat-llvm, a breakpoint set here was not being hit. It seems
perhaps somewhat strange to set a breakpoint on a null statement at
the end of a function; and while this might possibly be a gnat-llvm
bug, this isn't really the point of this test.
This patch makes these tests more robust by arranging for the
breakpoints to be set before the loop and on a call, respectively.
Because this is Ada-specific, was reviewed internally, and is just a
minor test case adjustment, I am checking it in.
Alan Modra [Sun, 7 Jun 2026 23:43:51 +0000 (09:13 +0930)]
Re: RISC-V: riscv_parse_subset_t's isa_spec is only parser input
check_compiler_available fails with a ld segfault linking
int main (void) { return 0; }
Program received signal SIGSEGV, Segmentation fault.
0x0000000000466a64 in riscv_parse_add_subset (rps=rps@entry=0x7fffffffd450, subset=subset@entry=0x962ca0 "zaamo", major=-1, minor=-1, implicit=implicit@entry=true) at /home/alan/src/binutils-gdb/bfd/elfxx-riscv.c:1947
1947 riscv_get_default_ext_version (*rps->isa_spec, subset,
(gdb) p rps->isa_spec
$1 = (const enum riscv_spec_class *) 0x0
This was triggered when calling riscv_merge_attributes for crti.o
which had
(gdb) p ibfd->tdata.elf_obj_data->known_obj_attributes[OBJ_ATTR_PROC][Tag_RISCV_arch]
$5 = {type = 2, i = 0, s = 0x97e4c0 "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0"}
Fix the segfault by reinstating a NULL check removed with commit 413cf36d8e81
Alan Modra [Sat, 6 Jun 2026 01:38:11 +0000 (11:08 +0930)]
filter_implib_symbols
This tidies filter_implib_symbols implementations, which I noticed
returned unsigned int but took long symbol counts. While unsigned int
is very likely sufficient, size_t is better.
_bfd_elf_filter_global_symbols is a linker-only function so really
should be moved to elflink.c, but I left it in elf.c as it calls
sym_is_global, a static function in elf.c.
* elf-bfd.h (struct elf_backend_data): Take size_t symcount
and return a size_t from elf_backend_filter_implib_symbols.
(_bfd_elf_filter_implib_symbols): Likewise. Rename from
_bfd_elf_filter_global_symbols.
* elf.c (_bfd_elf_filter_implib_symbols): Likewise. Use
size_t vars too, and avoid unnecessary casts.
* elf32-arm.c (elf32_arm_filter_cmse_symbols): Likewise.
(elf32_arm_filter_implib_symbols): Likewise.
* elflink.c (elf_output_implib): Avoid unneccesary casts.
Call elf_backend_filter_implib_symbols uncontitionally.
* elfxx-target.h (elf_backend_filter_implib_symbols): Define
fallback as _bfd_elf_filter_implib_symbols.
Alan Modra [Sat, 6 Jun 2026 01:36:40 +0000 (11:06 +0930)]
Drop output bfd param from many elf linker functions
Functions that are always passed a non-NULL bfd_link_info* and are not
called by BFD_SEND using the output bfd, need not pass the output bfd
as a parameter. It can be accessed via info->output_bfd. Removing
the excess parameters result in a small code size reduction on
x86_64-linux --enable-targets=all ld built with a static libbfd, from 9896133 to 9893805 bytes.
Alan Modra [Sat, 6 Jun 2026 01:35:45 +0000 (11:05 +0930)]
gas s_comm_internal uninitialised access
After elf_common_parse calls ignore_rest_of_line on some errors,
s_comm_internal calls demand_empty_rest_of_line. These functions
cannot be both called, as they consume the end_of_stmt char in the
input buffer and the second call then consumes the next line of input,
which may not even be in the input buffer.
Tom Tromey [Fri, 22 May 2026 17:17:17 +0000 (11:17 -0600)]
Emit DWARF expressions from dwarf-to-dwarf-assembler.py
This changes dwarf-to-dwarf-assembler.py to attempt to emit DWARF
expressions. It is not close to perfect, since it relies on the
elftools formatting to some extent, but it does at least eliminate the
need to do a separate "readelf" step to try to work on the expression
by hand.
Tom Tromey [Wed, 22 Apr 2026 18:31:57 +0000 (12:31 -0600)]
Use double quotes in some gdb output
I looked for spots where gdb was using `...' or ``...'' quoting, and
changed these to use double quotes instead.
I think it might be good to regularize output quoting in gdb. My
proposal is to use double quotes, though single quotes would also be
fine. Using `...', though, is a kind of older style and has fallen
out of favor in GNU; the relevant node is here:
Tom de Vries [Fri, 5 Jun 2026 21:06:48 +0000 (23:06 +0200)]
[gdb] Drop nullptr in "get_selected_frame (nullptr)"
I came across "get_selected_frame (nullptr)", and realized nullptr is the
default argument, so this can be simplified to "get_selected_frame ()".
Do so using the following script:
...
$ find gdb* -type f -name "*.[ch]" -o -name "*.cc" \
| xargs sed -i 's/get_selected_frame (nullptr)/get_selected_frame ()/'
...
and likewise for "get_selected_frame (NULL)".
Tom de Vries [Fri, 5 Jun 2026 21:03:42 +0000 (23:03 +0200)]
[gdb/build] Fix Wnon-pod-varargs in bppy_repr
I build gdb with clang and ran into a build breaker:
...
gdb/python/py-breakpoint.c:1074:52: error: cannot pass object of non-trivial \
type 'const std::string' (aka 'const basic_string<char>') through variadic \
function; call will abort at runtime [-Wnon-pod-varargs]
1074 | return PyUnicode_FromFormat ("<%s (invalid)>", tp_name);
| ^
...
This looks like fallout from commit dafd73bcda6 ("gdb/python: fix memory leak
in gdb_py_tp_name"), which changed the return type of gdbpy_py_obj_tp_name
from const char * to std::string.
We could fix this using tp_name.c_str (), but instead fix this by simplifying
the code using gdb_py_invalid_object_repr.
Tom Tromey [Wed, 3 Jun 2026 19:03:31 +0000 (13:03 -0600)]
Add two new warnings to warning.m4
I recently learned that GCC has improved -Wdangling-reference and
added -Wunterminated-string-initialization. Both of these seem
sensible to me, so this patch adds them to warning.m4.
gdb rebuilds cleanly with this in place on x86-64 Fedora 43.
Tom de Vries [Fri, 5 Jun 2026 12:18:59 +0000 (14:18 +0200)]
[gdb/testsuite] Add missing copyright notice in tclint-plugin.py
I ran:
...
$ ./gdb/contrib/license-check-new-files.sh -s gdb-17-branchpoint HEAD
Scanning directories gdb*/...
gdb/features/aarch64-fpmr.c: None
gdb/features/aarch64-fpmr.xml: FSFAP-no-warranty-disclaimer
gdb/syscalls/riscv-linux.xml: FSFAP
gdb/syscalls/riscv-linux.xml.in: FSFAP-no-warranty-disclaimer
gdb/testsuite/tclint-plugin.py: None
gdbsupport/unordered_dense/stl.h: MIT
...
and found out that I forgot to add a copyright notice to
gdb/testsuite/tclint-plugin.py.
The sole size dependent parameter used there is ARCH_SIZE. For just this
there's no good reason to build all of the involved code twice. Make the
value a function parameter instead.
Jan Beulich [Fri, 5 Jun 2026 09:11:40 +0000 (11:11 +0200)]
RISC-V: drop dead code from subset parsing
In riscv_update_subset1(), when explicit_subset is NULL, errmsg_internal
is the empty string. There's no need then to pass this as an extra
argument to the error handler.
riscv_parsing_subset_version() can't return NULL. Dropping the respective
checks clarifies that there is no issue with a missing error message (gas
would rely on one being emitted when parsing fails).
Jan Beulich [Fri, 5 Jun 2026 09:10:28 +0000 (11:10 +0200)]
RISC-V: error handling for subset parsing
The parsing of both the argument of -march= and the operand(s) of
".option arch, ..." can fail. In such a case for .option (and equally
for .attribute) prior state should continue to be used, while for -march=
defaults should be put in place. In particular, extensions conflicting
with previously enabled extensions should not suddenly become available.
While re-indenting riscv_set_rvc() invocations, leverage that C implies
Zca (and hence a check for the latter suffices). Mirror that change to
riscv_set_arch() for consistency.
Jan Beulich [Fri, 5 Jun 2026 09:10:12 +0000 (11:10 +0200)]
RISC-V: riscv_parse_subset_t's isa_spec is only parser input
Make the field pointer-to-const and drop indirection from
riscv_get_default_ext_version(). This way it's more clear that parsing
won't alter the field.
Jan Beulich [Fri, 5 Jun 2026 09:09:55 +0000 (11:09 +0200)]
RISC-V: riscv_set_arch() can fail
In that case neither riscv_rps_as.subset_list nor file_arch_str would be
set, yet the NULL pointers would be happily passed into functions not
expecting such.
Jan Beulich [Fri, 5 Jun 2026 09:09:38 +0000 (11:09 +0200)]
RISC-V: match_*() improvements
Match functions referenced by macro insns should not
unconditionally invoke match_opcode(): The macro enumeration can change
(grow), making the function potentially yield false negatives.
In match_rs1_nonzero(), used solely by macro insns, add an assertion to
that effect.
While there also drop the pointless attribute from
match_rs1_nonzero_rs2_even()'s first parameter.
Jan Beulich [Fri, 5 Jun 2026 09:09:18 +0000 (11:09 +0200)]
RISC-V: fold redundant code in riscv_ip()
The parsing of 'F' and 'O' .insn operands is pretty redundant. Have only a
single instance each of common code, with the inner switch()es merely
handling the actual value insertion. This in particular simplifies the
addition of new sub-forms.
Jan Beulich [Fri, 5 Jun 2026 09:08:48 +0000 (11:08 +0200)]
RISC-V: rename operand descriptor O4
It's describing a 7-bit field, so O7 is the more consistent (with other
O<n> and F<n>) name. This way a subsequent change will also be a little
easier.
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.
projects / thirdparty / binutils-gdb.git / log
