Simon Marchi [Thu, 6 Nov 2025 21:13:07 +0000 (16:13 -0500)]
gdb/testsuite: adjust add-inferior test for native-extended-gdbserver board
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: per-inferior parameters: add-inferior
The add-inferior command produces more output than expected when using
the native-extended-gdbserver board, because it is already connected to
a remote target:
Rainer Orth [Thu, 6 Nov 2025 16:18:16 +0000 (17:18 +0100)]
gas: Default to -mrelax-relocations=no on Solaris/x86 [PR19520]
I recently noticed a complex case statement in gas/configure.ac controlling
the setting of ac_default_x86_relax_relocations on Solaris/x86. Since it
included all versions of Solaris, it could be massively simplified.
Looking closer however, I found that it was introduced in
based on PR gas/19520. This PR reported that the new R_386_GOT32X
etc. relocations weren't supported on older versions of Solaris,
breaking gcc bootstrap. In response, they were disabled on all Solaris
versions except Solaris 12, where they had been implemented in the
native toolchain based on my findings.
However, Solaris 12 has been rechristened to 11.4 before release,
effectively disabling DEFAULT_GENERATE_X86_RELAX_RELOCATIONS on all
versions of Solaris/x86.
Since Solaris 11.4 cannot be distinguished from earlier versions in
cross configurations, this patch fixes this by removing
--enable-x86-relax-relocations completely, instead disabling
DEFAULT_GENERATE_X86_RELAX_RELOCATIONS in tc-i386.c on Solaris. It also
adds testcases to verify the -mrelax-relocations default.
Tested on {i386,amd64}-pc-solaris2.11 and {i686,x86_64}-pc-linux-gnu.
Tom Tromey [Thu, 6 Nov 2025 15:33:08 +0000 (08:33 -0700)]
Fix build after command_classes change
Commit 7028626eff3 (gdb: make command classes be bitmaps) broke the
build, causing the compiler to issue an error message about the global
scm-cmd.c:command_classes being redefined as a different type.
Renaming the global fix the problem.
Andrew Burgess [Tue, 4 Nov 2025 09:59:09 +0000 (09:59 +0000)]
gdb/python: fix gdb.Block repr output
I noticed that when printing a gdb.Block object in Python, I would
occasionally get corrupted, nonsensical output, like this:
<gdb.Block <anonymous> {intintyinty_1inty_3inty_5... (-5 more symbols)}>
The symbol list is missing commas, it should be:
int, inty, inty_1, inty_3, inty_5, ...
And the '-5 more symbols' is clearly not right.
The problem is in python/py-block.c, we use this line to calculate the
number of symbols in a block:
const int len = mdict_size (block->multidict ());
Then we loop over the symbols in the block like this:
for (struct symbol *symbol : block_iterator_range (block))
...
The problem here is that 'block_iterator_range (block)' can loop over
more symbols than just those within 'block'. For global and static
blocks, block_iterator_range() takes into account included CUs; and so
can step through multiple global or static blocks. See
block_iterator_step and find_iterator_compunit_symtab in block.c for
more details.
In contrast, 'mdict_size (block->multidict ())' only counts the
symbols contained within 'block' itself.
I could fix this by either fixing LEN, or by only iterating over the
symbols within 'block'.
I assume that printing a gdb.Block object is used mostly for debug
purposes; the output isn't really user friendly, so I cannot imagine a
user script that is relying on printing a gdb.Block as a way to inform
the user about blocks in their program. As such, I think it makes
more sense if the symbols listed are restricted to those strictly held
within the block.
And so, instead of block_iterator_range, I've switched to iterating
over the multidict symbols. Now the calculated LEN will match the
number of symbols being printed, which fixes the output seen above.
However, as we're now only printing symbols that are within the block
being examined, the output above becomes:
<gdb.Block <anonymous> {}>
All the symbols that GDB previously tried to print, are coming from an
included CU.
For testing, I've made use of an existing DWARF test that tests
DW_AT_import. In the wild I saw this in an inferior that used
multiple shared libraries that has their debug information stored in a
separate debug file, and then parts of that debug information was
combined into a third separate file using the DWZ tool. I made a few
attempts to craft a simpler reproducer, but failed. In the end it was
easier to just use a DWARF assembler test to reproduce the issue.
I have added some more typedef symbols into the DWARF test, I don't
believe that this will impact the existing test, but makes the
corrupted output more obvious.
Tom de Vries [Thu, 6 Nov 2025 09:39:33 +0000 (10:39 +0100)]
[gdb/testsuite] Fix DUPLICATE in callfuncs.exp
With test-case gdb.base/callfuncs.exp I get:
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
DUPLICATE: gdb.base/callfuncs.exp: failed to prepare
...
Fix this by moving a with_test_prefix up one level.
RISC-V: Fix missing instruction classes in error messages
Add 6 missing instruction class cases to riscv_multi_subset_supports_ext()
to provide proper extension names in error messages instead of producing
"internal: unreachable INSN_CLASS_*" errors.
These instruction classes exist in riscv_multi_subset_supports() but were
missing from riscv_multi_subset_supports_ext(), causing the assembler to
produce internal errors when instructions are used without the required
-march specification.
Currently, there is no way for a new user to have an idea of common
useful commands and behaviors from the GDB interface itself, without
checking the example session in the documentation. This command class
aims to close that gap by providing a set of quickstart commands that
allows for any simple debug session to happen without anything too
egregious missing.
The set of commands was chosen somewhat arbitrarily, based on what I
used or missed the most. The one overarching important thing, however,
is that the list is kept short, so as to not overwhelm new users. This
is confirmed by the newly introduced selftest, essential_command_count,
which ensures there are 20 or fewer essential commands.
Here's the reasoning for some of the choices:
* The command "start" was picked over "run" because combining it with
"continue" achieves the same effect, and I prefer it over needing to set
a breakpoint on main to stop at the start of the inferior.
* The command "ptype" is chosen because I believe it is important to
provide a way for the user to check a variable's type from inside GDB,
and ptype is a more complete command than the alternative, "whatis".
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
This commit makes it so GDB's command classes can be represented with a
single bit, allowing for a command to have multiple classes. This is
primarily done as preparation for the next patch, but it can provide
value on its own as some commands could be described as belonging to
multiple classes, such as "record" being obscure and related to running
the inferior.
BFD: Remove unused file position member of `struct orl'
The `pos' member of `struct orl' has never been used. Remove it along
with the enclosing union so as not to propagate clutter with a later
change, which adds that union as a distinct type. No functional change.
Tom de Vries [Wed, 5 Nov 2025 15:16:01 +0000 (16:16 +0100)]
[gdb/testsuite] Yet another attempt to fix gdb.threads/thread-specific-bp.exp
When running test-case gdb.threads/thread-specific-bp.exp using taskset to
select an Efficient-core in a loop, it fails 19 out of 100 runs.
For example, like this:
...
(gdb) continue -a^M
Continuing.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: $exp: non_stop=on: continue to end
[Thread 0x7ffff7cbe6c0 (LWP 2348848) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The way we're trying to match this gdb output is:
...
gdb_test_multiple "$cmd" "continue to end" {
-re "$\r\n${gdb_prompt} .*${msg_re}\r\n" {
pass $gdb_test_name
}
-re "\r\n${msg_re}\r\n.*$gdb_prompt " {
pass $gdb_test_name
}
}
...
The problem is that the two -re clauses above do not match the output ending
in a prompt, so the default fail in gdb_test_multiple triggers.
Fix this by splitting this up in two gdb_test_multiple calls:
- the first matches a prompt (with or without preceding $msg_re), making sure
that the default fail doesn't trigger, and
- the second matches $msg_re, if that was not already matched by the first call.
Using this approach, the test-case passes 100 out of 100 runs.
Tested on x86_64-linux, also with make-check-all.sh.
Tom de Vries [Wed, 5 Nov 2025 15:07:54 +0000 (16:07 +0100)]
[gdb/testsuite] Remove gdb.dwarf2/dw2-ranges.exp
On openSUSE Leap 15.6 x86_64 with test-case gdb.dwarf2/dw2-ranges.exp I ran
into:
...
(gdb) file dw2-ranges^M
Reading symbols from dw2-ranges...^M
warning: stabs debug information is not supported.^M
(gdb)
...
The test-case checks a combination of dwarf and stabs.
Now that stabs is no longer supported, checking the combination is no longer possible.
Indu Bhagat [Wed, 5 Nov 2025 06:59:11 +0000 (22:59 -0800)]
gas: sframe: fix PR gas/33277
In SFrame stack trace format, the representation of stack offsets allows
for either 1-byte, 2-byte or 4-byte integers.
Add new internal function sframe_fre_stack_offset_bound_p () which
checks if the given offset is within bounds (at most as a 4-byte
integer). Use this to check if CFA offset is within bounds, if not skip
emitting the FDE, and warn the user.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
PR gas/33277
* gen-sframe.c (sframe_fre_stack_offset_bound_p): New
definition.
(sframe_xlate_do_def_cfa): Check bounds of offset.
(sframe_xlate_do_def_cfa_offset): Likewise.
hppa64: Fix some issues handling dynamic relocaltions
This change fixes the allocation logic in allocate_dynrel_entries and
elf64_hppa_finalize_dynreloc. It also fixes addend calculation for
segment based relocations.
Some applications now link successfully on HP-UX but there are still
issues with external weak symbols. This breaks linking with libgcc.
It looks like we need support for .rela.data.rel.ro, ...
2025-11-04 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (allocate_dynrel_entries): Correct hh->want_opd
if condition.
(elf64_hppa_finalize_dynreloc): Likewise. Use symbol address
instead of OPD address. Include sec->output_offset in value2
calculation.
(elf64_hppa_finalize_opd): Likewise.
(elf64_hppa_finalize_dlt): Likewise.
(elf_hppa_final_link_relocate): Fix symbol address calculation.
Jens Remus [Tue, 4 Nov 2025 10:51:07 +0000 (11:51 +0100)]
s390: Emit relocation for 32-bit immediate operand
IBM Z instruction format RIL-a has a 32-bit immediate operand in
instruction bits 16 to 47. Enable the assembler to emit a 32-bit
direct or PC-relative relocation when processing a fixup, similar
as it is already done for 16-bit immediate operands in bits 16-31.
H.J. Lu [Wed, 29 Oct 2025 01:49:57 +0000 (09:49 +0800)]
elf: Don't set its DT_VERSYM entry for unversioned symbol
1. Referenced symbol without '@' has no version.
2. Defined symbol without the .symver directive has no version if there
is no linker version script.
Symbol without version shouldn't have the base version in its DT_VERSYM
entry. Instead, its DT_VERSYM entry should be all zero to indicate that
the symbol doesn't have a version.
NB: Symbol with the base version has a '@' suffix, like "foo@", defined
with
.symver hide_original_foo, foo@
bfd/
PR ld/33577
* elflink.c (elf_link_output_extsym): Don't set its DT_VERSYM
entry for the symbol without version.
ld/
PR ld/33577
* ld-elfvers/vers16.dsym: Remove the "Base" version on symbols
without version.
Markus Metzger [Fri, 25 Oct 2024 14:15:59 +0000 (14:15 +0000)]
btrace: stopped_by_*() consider the selected thread
In stopped_by_sw_breakpoint() and stopped_by_hw_breakpoint(), we check
whether any thread is replaying. This is unnecessary as it only matters
if inferior_ptid is replaying.
Markus Metzger [Fri, 25 Oct 2024 14:07:51 +0000 (14:07 +0000)]
btrace: remove update_thread_list() and thread_alive()
The record btrace target does not create or destroy threads. There is no
reason to override the update_thread_list() and thread_alive() target
methods.
Markus Metzger [Fri, 25 Oct 2024 13:53:04 +0000 (13:53 +0000)]
btrace, infrun: replay scheduler locking only depends on to-be-resumed thread
Similar to the parent commit, simplify schedlock_applies() by only
checking the argument thread.
When resuming that thread, GDB will automatically stop replaying its
inferior. The replay state of other inferiors is not considered by
user_visible_resume_ptid(), so let's not consider them in
schedlock_applies(), either.
Markus Metzger [Fri, 25 Oct 2024 07:17:05 +0000 (07:17 +0000)]
btrace, infrun: simplify scheduler-locking replay
When scheduler-locking is set to replay and we're resuming a thread at the
end of its execution history, we check whether anything is replaying in
user_visible_resume_ptid() only to check again in clear_proceed_status()
before we stop replaying the current process.
What really matters is whether the selected thread is replaying or will
start replaying.
Simplify this by removing redundant checks.
Also avoid a redundant pass over all threads to check whether anything is
replaying before stopping replaying. Make record_stop_replaying() handle
the case when we're not replaying gracefully.
Markus Metzger [Mon, 24 Jun 2024 08:21:17 +0000 (08:21 +0000)]
gdb, remote: adjust debug printing
remote::wait () may get called rather frequently, polluting the logging
output with tons of
[remote] wait: enter
[remote] wait: exit
messages.
Similarly, remote_target::remote_notif_remove_queued_reply () will print
the debug message even if nothing was actually removed. Change that to
only print a debug message if a stop reply was removed.
Markus Metzger [Wed, 21 Feb 2024 17:06:41 +0000 (17:06 +0000)]
gdb, btrace: set wait status to ignore if nothing is moving
When record_btrace::wait() is called and no threads are moving, we set the
wait status to no_resumed. Change that to ignore.
This helps with enabling per-inferior run-control for the record btrace
target as it avoids breaking out of do_target_wait() too early with
no_resumed when there would have been an event on another thread.
We don't really need three inferiors to test multi-inferior recording.
We don't really need to check info record before starting recording.
If we were recording, there would be output, causing a fail.
This just complicates the test when there is something to debug.
Markus Metzger [Tue, 12 Aug 2025 12:33:48 +0000 (12:33 +0000)]
btrace: clear thread stopped state when stopping replaying
When we stop replaying a thread, it moves to the end of its execution
history. It retains its state from when it was replaying, though, so a
subsequent 'info program' command would show wrong information.
Clear all execution state used by the 'info program' command.
Markus Metzger [Wed, 13 Aug 2025 14:25:27 +0000 (14:25 +0000)]
btrace: do not stop replaying or recording while a thread is running
With asynchronous stepping commands, one may start replaying a thread in
the background and then stop recording its inferior in the foreground.
This causes the execution history to be cleared and the record target to
be unpushed while the thread is using said execution history.
I fail to see a use-case for this, so rather than trying to make this
work, I prevent such a scenario by not allowing replaying or recording to
be stopped while a thread is running.
We could do this only when a thread is running in replay mode and preserve
the existing behavior of being able to stop recording while threads are
running in recording mode. It seems more consistent to not allow this for
both replaying and recording threads, though.
In record_btrace_stop_replaying_at_end, we know that we are at the end of
the execution history, so PC must match the current PC if we're not
replaying.
We're not changing any other registers during btrace replay, so we should
be fine leaving the regcache.
But we need to reinit the frame cache, since current frames used the
btrace unwinder.
The main motivation for this, however, is that future patches extend stop
replaying in ways that is not relevant to stop replaying at the end.
Markus Metzger [Tue, 20 Feb 2024 11:45:39 +0000 (11:45 +0000)]
gdb, btrace: fix pr19340
GDB fails with an assertion when stopping recording on a replaying thread
and then resuming that thread. Stopping recording left the thread
replaying but the record target is gone.
Stop replaying all threads in the selected inferior before stopping recording.
I had to change the stepping test slightly to account for different
compilers generating slightly different debug information, so when
stepping the 'return 0' after 'record stop' I would end up in a different
location depending on which compiler I used. The test still covers all
stepping commands.
Alan Modra [Mon, 3 Nov 2025 02:31:42 +0000 (13:01 +1030)]
ctf-archive sanity checks
Existing code checks that the first uint64_t ctfa_magic field is
available before reading but neglects to check that the last uint64_t
ctfa_ctfs is available before reading it in ctf_arc_bufpreamble.
ctf_arc_bufopen sets up a pointer to the struct ctf_archive in
ctf_new_archive_internal. Extend the check to cover the entire struct.
PR 33548
PR 33549
* ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Check
that buffer contains at least an entire struct ctf_archive
when accessing such a struct.
Alan Modra [Mon, 3 Nov 2025 00:29:50 +0000 (10:59 +1030)]
tidy m4 plugin config support
In CLANG_PLUGIN_FILE it is possible for plugin_file to be non-NULL
when LLVMgold.so does not exist.
configure output is messy, with results not printed against their
"checking.." line, eg.
checking for clang... (cached) yes
checking for clang plugin file... checking for x86_64-pc-linux-gnu-ar... (cached) ar --plugin /usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so
/usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so
This patch fixes those problems, and a similar interposition of other
configure output between AC_MSG_CHECKING and AC_MSG_RESULT in
gcc-plugin.m4. It also tidies some of the message text, and makes
similar code in gcc-plugin.m4 and clang-plugin.m4 a little more
consistent.
hppa64: Implement segment based relocations for local symbols
There is progress in implementing 64-bit shared library support.
Fixes link error compiling vdso64.so. HP-UX dynamic linker no longer
complains that libgcc_s.4 linked with GNU ld is an invalid shared library.
Relocations are now generated for all slots in .rela.data, .rela.dlt
and .rela.opd. Relocation counts for libgcc_s.4 linked using GNU and
HP ld are the same except .rela.plt. That may be okay as GNU ld directs
pc-relative calls to stubs.
Glibc's ld.so.new appears to link okay. However, libgcc_s.4 linked with
GNU ld is still broken on HP-UX.
There are six unexpected fails in the testsuite and three unexpected
passes. There's at least one fail due to name munging in the .dynsym
table.
2025-11-02 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (struct elf64_hppa_link_hash_entry): Remove
sym_ind and owner fields. Rename hash entries for __text_seg
and __data_seg. Adjust all users.
(global_sym_index): Remove.
(hppa64_elf_local_refcounts): Assert size is not 0.
(elf64_hppa_check_relocs): Drop NEED_PLT from R_PARISC_FPTR64
relocation. Don't stash abfd and r_symndx in hh->owner and
hh->sym_indx. Add global symbols with hh->eh.dynindx equal
-1 to dynamic table. Don't record section symbols to the
local dynamic symbol table.
(allocate_global_data_dlt): Don't add symbol to local dynamic
symbol table.
(allocate_global_data_opd): Likewise.
(elf64_hppa_late_size_sections): Rework code to add __text_seg
and __data_seg symbols to the dynamic table.
(elf64_hppa_finalize_dlt): Revise to use __text_seg and
__data_seg symbols.
(elf64_hppa_finalize_dynreloc): Likewise.
(elf_hppa_final_link_relocate): When generating a shared
library, ignore relocs in debugging sections. Revise
relocations needing DLT and OPD dynamic relocations to output
dynamic relocatios for local symbols. Move code to initialize
segment base values back to SEGREL case.
Andrew Burgess [Fri, 31 Oct 2025 10:19:41 +0000 (10:19 +0000)]
gdb: add a constructor for symtab
Convert symtab to use obstack_new, and have a real constructor. The
filename, filename_for_id and m_compunit, members should really not
change once the symtab has been created, so make these members private
(m_compunit was already private) and set them just once from the
constructor. The set_compunit function has been deleted, and new
getter functions for filename and filename_for_id have been added.
The language is also set at construction time, but can be updated
later, so set the language in the constructor, but retain
symtab::set_language for when the language needs to be updated.
Prior to this patch the symtab was allocated with OBSTACK_ZALLOC which
would zero out the symtab object. With the call to objstack_new
fields in the symtab would no longer be initialised, so I've added
default member initialisation for everything not set in the
constructor.
The interesting changes are in symtab.h, and symfile.c. Everything
else is just updating to handle symfile::filename and
symfile::filename_for_id becoming methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Indu Bhagat [Sat, 1 Nov 2025 08:46:42 +0000 (01:46 -0700)]
libsframe: use sf_fde_tbl data structure internally for the decoder
Instead of the current sframe_func_desc_entry (on-disk format
representation) data structure.
The decoder context in libsframe, so far, has been internally directly
tied to the sframe_func_desc_entry (on-disk format representation) data
structure. While this allows libsframe to avoid some operations, this
is not desirable anymore as the format evolves: we will need to support
reading in of older version(s) of SFrame FDE, as well as a newer on-disk
representations for SFrame FDE.
Use sf_fde_tbl internally in the decoder context. Note that libsframe
already does _not_ use sframe_func_desc_entry in any external-facing,
user-visible APIs.
Note that this commit is simply preparatory in nature. At the moment,
the 'sf_fde_tbl' internally uses the sframe_func_desc_entry (on-disk
format representation). When need arises (as SFrame FDE evolves), we
may change sf_fde_tbl to use an alternative (but still libsframe
internal) definition of SFrame FDE.
lisbframe/
* sframe-impl.h (sf_fde_tbl, sf_fre_tbl): Move definition before use.
Use sf_fde_tbl instead of sframe_func_desc_entry in struct
sframe_decoder_ctx.
* sframe.c (sframe_fde_tbl_alloc): New internal definition.
(sframe_fde_tbl_init): Likewise.
(sframe_decoder_get_funcdesc_at_index): Adjust for sf_fde_tbl
usage.
(sframe_decoder_get_secrel_func_start_addr): Likewise.
(sframe_fre_check_range_p): Likewise.
(sframe_decode): Likewise.
(sframe_get_funcdesc_with_addr_internal): Likewise.
Indu Bhagat [Sat, 1 Nov 2025 08:42:02 +0000 (01:42 -0700)]
libsframe: make flip_header version aware
Future versions of the format may have alternative representation of an
FDE. As the format evolves, endian flipping of the SFrame header may
need to be version aware.
flip_header () now takes the SFrame version as argument and also returns
SFRAME_ERR in case of error. Currently the SFrame version as argument
remains unused.
SFrame encoder, at the momemnt, writes the SFrame data in the most recent
format version by default.
libsframe/
* sframe.c (flip_header): Make version aware.
(sframe_decode): Adjust usage of flip_header.
(sframe_encoder_write): Likewise.
Indu Bhagat [Sat, 1 Nov 2025 08:35:34 +0000 (01:35 -0700)]
libsframe: make flip_fde version aware
Future versions of the format may have a different representation of an
SFrame FDE. As the format evolves, endian flipping will need to be version
aware.
Refactor flip_fde a bit by carving out an internal sframe_decode_fde API
which can read information from an on-disk SFrame FDE.
libsframe/
* sframe.c (flip_fde): Make version aware.
(sframe_decode_fde): New internal definition.
(flip_sframe): Use the new definitions.
added the LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook for offload
support. Since the V2 linker plugin hook doesn't claim the offload IR if
known_used is unset, set input plugin_format to bfd_plugin_no only if
known_used is set or the V2 linker plugin hook is unused.
PR ld/33584
* plugin.c (plugin_object_p): Set plugin_format to bfd_plugin_no
only if known_used is set or the V2 linker plugin hook is unused.
Alan Modra [Thu, 30 Oct 2025 22:57:46 +0000 (09:27 +1030)]
Pass -B to objcopy binary symbol test
objcopy -I binary -O some_coff_target does not currently work without
choosing a valid arch with -B. This used to be the case for ELF
targets too, until commit 6765ee1825d9.
* testsuite/binutils-all/objcopy.exp (binary_symbol): Pass
-B arch to objcopy. Choose different output object files for
the two tests.
Simon Marchi [Mon, 27 Oct 2025 19:25:51 +0000 (15:25 -0400)]
gdbsupport: bump unordered_dense to 4.8.0
We don't need anything in this release, but I think it doesn't hurt to
just stay up to date. The new version has a new include file, stl.h.
To keep things clean and separated, move the imported files to a new
sub-directory. This requires a small change in
gdb/check-include-guards.py, to be able to ignore the whole new
directory.
Change-Id: Ic8c5d0dd5ea8b6691c99975d6ca78f637175ef42 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 29 Oct 2025 17:49:21 +0000 (13:49 -0400)]
gdb/testsuite: remove unused but set variables in Python files
Fix flake8 errors like this one:
gdb/testsuite/gdb.python/py-unwind-inline.py:61:17: F841 local variable 'v' is assigned to but never used
For this one, there is a slight possibility that removing a variable
changes some behavior, and perhaps renders some test uneffective (where
the test would no longer exercises what it meant to). Removing a
variable means that the object it pointed to likely gets de-allocated
earlier (its tp_dealloc method gets called). So if the intent of the
variable was to ensure the variable outlives the statements that come
after, then this change would be wrong. But I didn't see any evidence
of that being the intent in all the occurences.
Change-Id: Ic57bc68ad225a43ae6771c47b7f443956e8029a6 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 29 Oct 2025 17:49:14 +0000 (13:49 -0400)]
gdb/{testsuite,system-gdbinit}: import gdb module in Python scripts
Fix flake8 warnings like:
gdb/system-gdbinit/wrs-linux.py:21:5: F821 undefined name 'gdb'
These scripts get executed in a context where the gdb module is already
loaded, so this is not strictly necessary. However, adding these
imports removes a lot of red lines when editing these files in an IDE.
Without them, the code uses this `gdb` thing that appears to be
undefined. Pylance is able to pull the module definition from typeshed
[1] and provide a good experience with typings.
Luis Machado [Wed, 29 Oct 2025 10:07:08 +0000 (10:07 +0000)]
Fix device index in gdb.rocm/addr-bp-gpu-no-deb-info.exp
On a system with a single GPU, I spotted this test failing. The environment
variable ROCR_VISIBLE_DEVICES can be a bit misleading, as it actually expects
a list of device id's as opposed to a literal number of devices to make
visible.
This test sets it to 1, which is the second GPU on the system. As a result,
systems with a single GPU will have no visible GPU's and the test will FAIL.
Set ROCR_VISIBLE_DEVICES to 0 to make use of the first GPU on the system.
Approved-By: Lancelot Six <lancelot.six@amd.com> (AMDGPU)
MIPS/GAS: Add HI16/LO16 pairing for REL TLS relocs
Complementing commit 7ea90d9316d3 ("MIPS: Fix linker for REL TLS
HI16/LO16 relocs") also add pairing for HI16/LO16 REL TLS relocations
in GAS, which is where it needs to be done in the first place and
which is required for later linker operation on the objects produced.
Pairing also corrects in-place addend installation for the high-part
relocations, which used not to happen in the absence of this fix for
ones not already followed by the corresponding low-part relocation.
Add test cases to verify relocation ordering and addend installation.
Fix `micromips_reloc_p' wrongly classifying microMIPS TLS relocations
as non microMIPS relocations.
Owing to where the function is called this issue does not trigger in
reality, but with an upcoming change it would, where suitable tests
will be included.
MIPS: Add o32 RELA relocations for VxWorks targets
MIPS/VxWorks targets have an unusual arrangement in that they use RELA
relocations with the o32 ABI, unlike any other MIPS target. Due to an
inconsistency in BFD however "hybrid" relocations are produced by GAS,
where despite the relocations being of the RELA type the field to be
relocated also holds an in-place addend to be applied at link time.
For example:
$ cat vxworks-rela.s
.text
foo:
la $2, bar + 0x12345678
$ mips-vxworks-as -o vxworks-rela.o vxworks-rela.s
$ mips-vxworks-objdump -dr vxworks-rela.o
This arrangement nevertheless happens to produce correct ELF executables
owing to the ELF linker avoiding the use of howtos and doing relocation
calculations using its own knowledge of relocation semantics embedded
directly in `mips_elf_calculate_relocation' code.
Beyond producing questionable link object files it however breaks badly
with the generic linker, such as when output is srec.
Fix the problem by providing a set of o32 RELA howtos and making VxWorks
targets use it. Complement it with a set of test cases for GAS and LD;
we expect link object files to be essentially the same as n32 ones for
other MIPS targets sans the ABI2 ELF file header flag, and machine code
produced to be the same between SREC and ELF executables.
MIPS/LD/testsuite: Run HI16/LO16 tests for VxWorks too
Run ELF linker tests for HI16/LO16 relocations with MIPS/VxWorks targets
as well. Despite issues only fixed in the next change they produce the
same results as with other MIPS targets, so just use the existing tests
verbatim, however refrain from adding other tests until said issues have
been fixed.
Hui Li [Thu, 30 Oct 2025 02:51:56 +0000 (10:51 +0800)]
gdb: LoongArch: Change default char data type to signed
According to "Procedure Call Standard for the LoongArch Architecture" [1],
for all base ABI types of LoongArch, the char data type in C is signed by
default, so change the char data type to signed in gdb/loongarch-tdep.c.
Before this patch:
make check-gdb TESTS="gdb.base/sizeof.exp"
=== gdb Summary ===
# of expected passes 75
# of unexpected failures 1
make check-gdb TESTS="gdb.base/charset.exp"
=== gdb Summary ===
# of expected passes 277
# of unexpected failures 6
# of unsupported tests 1
Jens Remus [Thu, 30 Oct 2025 13:39:59 +0000 (14:39 +0100)]
s390: Do not generate incomplete opcode table
The s390 opcode table s390-opc.tbl is generated from s390-opc.txt
using the s390-mkopc utility using output redirection. If s390-mkopc
fails with a non-zero return code, e.g. due to a warning or error, an
incomplete opcode table may be generated in the build directory. A
subsequent invocation of make then assumes that incomplete opcode
table to be up to date. Depending on the s390-mkopc issue the build
may then proceed without any follow-on warnings or errors, causing
the preceding error or warning to go unnoticed.
Generate the s390 opcode table into an intermediate temporary file
s390-opc.tbl.tmp in the build directory and only move it to the final
target s390-opc.tbl if the generation was successful.
Tested by appending an unsupported inline comment "# TEST" to one of
the instructions defined in s390-opc.txt.
opcodes/
* Makefile.am (s390-opc.tab): Use an intermediate temporary file
to prevent updating of the target on error/warning.
* Makefile.in: Regenerated.
Alan Modra [Thu, 30 Oct 2025 05:56:57 +0000 (16:26 +1030)]
Sanity check elf_sym_hashes indexing
I'm a little surprised we haven't already had fuzzing reports of
indexing off the end of sym_hashes. The idea here is to preempt such
bugs. One wrinkle is that ppc64 can't leave a zero symtab_hdr when
setting up sym_hashes for the fake stub bfd.
* elf-bfd.h (struct elf_reloc_cookie): Add "num_sym".
(_bfd_elf_get_link_hash_entry): Update declaration.
* elf-eh-frame.c (find_merged_cie): Sanity check reloc symbol
index.
* elf64-ppc.c (use_global_in_relocs): Fake up symtab_hdr for
stub bfd.
* elflink.c (_bfd_elf_get_link_hash_entry): Add "num_sym"
param. Check symndx against it. Update all calls.
(set_symbol_value): Add "num_sym" param and update all calls.
(elf_link_input_bfd): Add "num_syms" var and use for above.
(init_reloc_cookie): Set "cookie->num_syms".
* elf64-x86-64.c (elf_x86_64_scan_relocs): Pass symtab number
of entries to _bfd_elf_get_link_hash_entry.
* elfxx-x86.c (_bfd_x86_elf_check_relocs): Likewise.
(_bfd_x86_elf_link_relax_section): Likewise.
Alan Modra [Thu, 30 Oct 2025 05:56:50 +0000 (16:26 +1030)]
Don't read and cache local syms for gc-sections
Most places just need the local sym section, so reading and sometimes
caching the symbols is excessive. A symbol shndx can be stored in 4
bytes, an elf symbol internal form requires 32 bytes. When caching
the local symbols we went slightly crazy trying to avoid memory usage,
resulting in the symbols being freed then immediately read again for
the testcase in the PR33530.
To avoid this problem, this patch caches the local symbol section
indices in the bfd rather than in the reloc cookie. They are not
initialised until there is a need for them, so unlike elf_sym_hashes
for global syms you cannot rely on them being present.
One place that does need local syms is adjust_eh_frame_local_symbols,
but that is called once via bfd_discard_info so there is no problem
simply reading them. The other place that needs local syms is
ppc64_elf_gc_mark_hook for the old ELFv1 ABI when handling .opd.
bfd_sym_from_r_symndx should be sufficient for function pointer
references to static functions, which is how this code is triggered.
PR 33530
* elf-bfd.h (struct elf_reloc_cookie): Delete "locsyms",
"sym_hashes", "bad_symtab". Make "locsymcount" and
"extsymoff" unsigned int.
(struct elf_obj_tdata): Add loc_shndx.
(elf_loc_shndx): Define.
(_bfd_get_local_sym_section): Declare.
* elf-eh-frame.c (find_merged_cie): Use
_bfd_get_local_sym_section for local syms.
(adjust_eh_frame_local_symbols): Read local syms if any match
.eh_frame section. Return them if changed.
(_bfd_elf_discard_section_eh_frame): Adjust.
* elf64-ppc.c (ppc64_elf_gc_mark_hook): Use
_bfd_get_local_sym_section. Use bfd_sym_from_r_symndx when
reading opd local symbol.
* elflink.c (_bfd_get_local_sym_section): New function.
(_bfd_elf_section_for_symbol): Use it.
(elf_link_add_object_symbols): Remove unnecessary cast on
bfd_zalloc return.
(init_reloc_cookie): Remove "info" and "keep_memory" params.
Adjust all callers. Don't stash elf_sym_hashes and
elf_bad_symtab to cookie. Don't read local syms to cookie.
(fini_reloc_cookie): Do nothing.
(_bfd_elf_gc_mark_hook): Use _bfd_get_local_sym_section.
(elf_gc_mark_debug_section): Likewise.
(bfd_elf_reloc_symbol_deleted_p): Likewise. Update cookie use.
Alan Modra [Thu, 30 Oct 2025 05:56:44 +0000 (16:26 +1030)]
_bfd_elf_get_link_hash_entry tidy
Replace the "Elf_Internal_Shdr *symtab_hdr" parameter with
"unsigned int ext_sym_start", making it a duplicate of the existing
get_link_hash_entry function.
Also remove unnecessary checks from get_ext_sym_hash_from_cookie and
find_merged_cie. The sym_hashes and symbol index checks in
get_ext_sym_hash_from_cookie are duplicates of those done in
_bfd_elf_get_link_hash_entry, and there is no need to check for a
global symbol before calling _bfd_elf_get_link_hash_entry. When
bad_symtab, local symbols will have a NULL sym_hashes entry. Removing
these unnecessary checks gets rid of some cookie->locsyms references.
PR 33530
* elf-bfd.h (_bfd_elf_get_link_hash_entry): Update declaration.
* elflink.c (_bfd_elf_get_link_hash_entry): Rename from
get_link_hash_entry, adjusting all calls and deleting original
function.
(get_ext_sym_hash_from_cookie): Make "symndx" unsigned int.
Remove unnecessary check on sym_hashes, symbol index and
symbol binding.
* elf-eh-frame.c (find_merged_cie): Remove similar unnecessary
checks.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Adjust.
* elfxx-x86.c (_bfd_x86_elf_check_relocs): Adjust.
(_bfd_x86_elf_link_relax_section): Adjust.
Alan Modra [Thu, 30 Oct 2025 05:56:27 +0000 (16:26 +1030)]
Pass cookie and symndx to gc_mark_hook
Replace the "sym" param with "cookie" and "symndx". This is in
preparation for the next patch. Also remove "rel" param since this is
available via "cookie", and is always set from cookie->rel.
Alon Bar-Lev [Wed, 29 Oct 2025 10:54:40 +0000 (12:54 +0200)]
objcopy: add option to specify custom prefix for symbol of binary input
When using --input-target=binary, objcopy currently derives symbol names
from a mangled version of the input file name. This approach can lead to
unpredictable results, as the generated symbols depend on the file path and
working directory.
This patch introduces a new option:
--binary-symbol-prefix <prefix> Use <prefix> as the base symbol name for
the input file (default: derived from
file name)
It allows specifying an explicit symbol prefix, while preserving the existing
behavior as a fallback.
Andrew Burgess [Fri, 24 Oct 2025 21:14:56 +0000 (22:14 +0100)]
gdb/testsuite: fix git repository check in gdb.src/pre-commit.exp
In the recently added gdb.src/pre-commit.exp test, we check if the
source directory is a git repository like this:
if {![file isdirectory $repodir/.git]} {
unsupported "Not in a git repository"
return
}
I make extensive use of git worktrees for development. In a worktree
.git is a file containing the location of the actual .git directory,
it is not itself a directory. As such, the above check fails,
claiming my source tree is not a git repository, when in fact, it is.
Fix this by relaxing the check to 'file exists $repodir/.git', which
will cover the directory and file case.
Haochen Jiang [Fri, 24 Oct 2025 05:49:20 +0000 (13:49 +0800)]
x86: Disable AMX-TRANSPOSE by default
In Binutils, we choose to keep the AMX-TRANSPOSE support for
now in case there are vendors want to utilize the instructions
although the feature itself is de-published. AMX-TRANSPOSE will
not show up on any Intel/AMD hardware. Also in foreseeable future,
no hardware will support AMX-TRANSPOSE, we will disable it by
default.
The patch (the removal) was done on the wrong assumption that
it was only the APX-promoted forms which would be dropped
because the APX spec was updated ahead of ISE and there was no
info that AMX-TRANSPOSE would be de-published at that time.
Given the current situation, since we will choose to disable
AMX-TRANSPOSE but not to remove the support in Binutils, we will
also not remove the APX support.
Simon Marchi [Mon, 27 Oct 2025 19:41:51 +0000 (15:41 -0400)]
gdb/solib-rocm: avoid expensive gdbarch_from_bfd call in rocm_solib_relocate_section_addresses
Loading a library containing a lot (> 100k) sections proved very slow
with whenever the support for ROCm was built into gdb. The culprit is
the gdbarch_from_bfd call in rocm_solib_relocate_section_addresses:
if (!is_amdgpu_arch (gdbarch_from_bfd (so.abfd.get ())))
This function gets called for every section, and gdbarch_from_bfd is
somewhat slow. It turns out that we can skip the gdbarch_from_bfd call,
since all is_amdgpu_arch needs is the bfd_architecture value, which we
can directly extract from the `bfd *`, without going through the
gdbarch.
Add an overload of is_amdgpu_arch that takes a `bfd *`, and use it in
rocm_solib_relocate_section_addresses.
Update a call site in rocm_solib_bfd_open to use the new overload as
well. That call site is not as much in a hot path, but there is no
point in paying the extra cost of looking up the gdbarch there. I
removed the other assert that checked that gdbarch_from_bfd returned a
non-nullptr value. If that was the case, something would be very wrong
with ROCgdb, and the problem would manifest very soon after anyway.
Change-Id: I55e9e68af59903b1b9727ff57388f9469d0e0002 Approved-by: Lancelot Six <lancelot.six@amd.com> (AMDGPU)
projects / thirdparty / binutils-gdb.git / log
