Alice Carlotti [Thu, 9 Apr 2026 01:17:48 +0000 (02:17 +0100)]
aarch64: Remove constraints on sysp operands
The CRn and CRm operands of sysp were unnecessarily constrained to the
ranges C8-C9 and C0-C7. This constraint has been removed from the
architecture spec, and was never implemented in LLVM, so remove it here
as well.
Additionally, add some more tests to cover the full range of valid sysp
operands, including omitting the pair of optional operands.
Alice Carlotti [Thu, 9 Apr 2026 00:16:12 +0000 (01:16 +0100)]
aarch64: Disallow movprfx before revd
An architectural relaxation in 2024 (listed in the "Known issues in
Issue K.a" of the Arm ARM) removed support for revd to be prefixed by a
movprfx instruction.
Remove two movprfx/revd tests from sme-9.s, and replace the
unnecessarily strict address checks with more permissive regexes
Muhammad Kamran [Wed, 18 Mar 2026 13:49:57 +0000 (13:49 +0000)]
aarch64: Reject no-Xt SYS aliases when Rt != 31 in disassembly
For SYS-encoding aliases that do not take Xt (for example TLBI ALLE1,
PLBI ALLE1), disassembly should not print the alias form when Rt != 31.
In that case, disassemble as the generic sys form instead.
Add a focused gas test that checks:
- Rt=31 still disassembles to aliases for no-Xt forms.
- Rt!=31 disassembles to sys ... , xN for those no-Xt forms.
- A valid Xt alias (TLBI VALE1) continues to disassemble as the alias.
opcodes/ChangeLog:
* aarch64-dis.c (aarch64_ext_regrt_sysins): Mark present as
whether Rt is non-default or the SYS op accepts Xt, so aliases
that do not take Xt are rejected when Rt != 31.
gas/ChangeLog:
* testsuite/gas/aarch64/sys-rt-alias.s: New test.
* testsuite/gas/aarch64/sys-rt-alias.d: New test.
aarch64: Add support for %dtprel(var) and R_AARCH64_TLS_DTPREL64
This patch allows R_AARCH64_TLS_DTPREL64 relocations in non-allocated
sections, which is required for DWARF debug information when using
Thread Local Storage. This matches the behavior in LLD.
Also a new syntax to parse dtprel operator use to describe tls
location in debug information. Please see the reference 3 below.
References:
- https://github.com/llvm/llvm-project/pull/146572
[AArch64] Support TLS variables in debug info
- https://github.com/llvm/llvm-project/pull/183962
[LLD][AArch64] Handle R_AARCH64_TLS_DTPREL64 in non-alloc sections
- https://github.com/ARM-software/abi-aa/pull/330
[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically.
Alan Modra [Wed, 8 Apr 2026 23:36:27 +0000 (09:06 +0930)]
PR 34053 buffer overflow in xcoff_link_add_symbols
This patch adds two sanity checks with error reporting in
xcoff_link_add_symbols before reading symbol aux entries, add extends
assertions in later functions. A whole lot of unnecessary casts are
also tidied.
PR 34053
* xcofflink.c: Remove unnecessary casts throughout.
(xcoff_link_add_symbols): Sanity check aux entries are within
symbol buffer.
(bfd_xcoff_build_dynamic_sections): Assert the above is true.
(xcoff_link_input_bfd): Likewise.
Remove static variables do_ctf and do_sframe that are set but never
read, causing build failures with LLVM's extended
-Wunused-but-set-variable warning.
These variables are dead code:
- Declared at lines 244-245 as static booleans
- Set to true when --ctf or --sframe options are parsed
- Never actually used or read anywhere in the code
- The actual dump functionality is triggered by request_dump() calls
Build error with -Werror enabled:
binutils/readelf.c:244:13: error: variable 'do_ctf' set but not used
[-Werror,-Wunused-but-set-variable]
binutils/readelf.c:245:13: error: variable 'do_sframe' set but not used
[-Werror,-Wunused-but-set-variable]
Jan Beulich [Thu, 9 Apr 2026 06:39:10 +0000 (08:39 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_PCREL*
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do, as long as the
resulting reloc's properties fit such a generic use (in the assembler it
could, after all, also result from ordinary expressions or uses with the
.reloc directive). Arm64, C-Sky, and KVX - sadly - are once again
exceptions.
For cris it's a PLT reloc which is being replaced.
For msp430 also drop BFD_RELOC_MSP430_16_BYTE, which has already been
merely an alias of BFD_RELOC_16 (resolving to R_MSP430_16_BYTE).
Jan Beulich [Thu, 9 Apr 2026 06:38:33 +0000 (08:38 +0200)]
bfd/Sparc: drop 64-bit BFD_RELOC_* aliases
For other relocations (e.g. BFD_RELOC_{8,16,32}{,_PCREL} or
BFD_RELOC_32_PCREL_S2) the generic enumerator is used. Plus use of such
aliases obfuscates where the generic types are actually in use.
Jan Beulich [Thu, 9 Apr 2026 06:37:51 +0000 (08:37 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_GOTPC*
For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. C-Sky - sadly -
continues to be an exception.
Jan Beulich [Thu, 9 Apr 2026 06:36:55 +0000 (08:36 +0200)]
bfd/s390+sh: don't abuse BFD_RELOC_32_GOT_PCREL
Neither R_390_GOT32 nor R_SH_GOT32 are PC-relative relocations, so don't
use a generic PC-relative enumerator for them. Doing so gets in the way
of properly using that enumerator.
Jan Beulich [Thu, 9 Apr 2026 06:36:19 +0000 (08:36 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_GOTOFF*
For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. Arm64, C-Sky, and
KVX - sadly - continue to be exceptions.
Tom Tromey [Sat, 28 Mar 2026 23:44:54 +0000 (17:44 -0600)]
Add command styling to error messages
This changes a number of error messages in gdb to use command_style.
In some places I've added double quotes around the command name for
consistency with other messages.
Alan Modra [Tue, 7 Apr 2026 23:27:39 +0000 (08:57 +0930)]
Don't write uninitialised data in .note.gnu.property
Seen when running the binutils x86-64 pr23494 tests.
_bfd_elf_convert_gnu_properties doesn't initialise its "contents"
buffer, and elf_write_gnu_properties doesn't write to padding.
Fix this by initialising the padding and then dispense with zeroing
contents in _bfd_elf_link_setup_gnu_properties.
Matthieu Longo [Wed, 28 Jan 2026 13:09:51 +0000 (13:09 +0000)]
gdb: add new helpers for retrieving a type's fully qualified name
Py_TYPE (self)->tp_name is the traditional idiomatic way to get a Python
type's fully qualified name. However, in the context of the Python
limited API, PyTypeObject is opaque, so the 'tp_name' attribute is no
longer accessible. Additionally, retrieving the type of a Python object
requires Py_TYPE, which is only available as part of the stable API
starting with Python 3.14.
This patch increases minimal Python limited API version from 3.11 to 3.14.
It also introduces two new helpers to retrieve a type's fully qualified
name: gdb_py_tp_name() and gdbpy_py_obj_tp_name(), which extract the fully
qualified name from a PyTypeObject and a PyObject, respectively. Ifdefery
allows these wrappers to select the appropriate API depending on the Python
version and whether the Python limited API is enabled. For any Python
version less than 3.13, gdb_py_tp_name() fallbacks using __qualname__
instead. However, the result may differ slightly in some cases, e.g. the
module name may be missing.
Finally, this patch adapts the existing code to use these wrappers, and
adjusts some test expectations to use the fully qualified name (or
__qualname__ for versions <= 3.13) where it was not previously used.
Note that the corner case where the module name would be missing does not
appear in the testsuite.
Matthieu Longo [Fri, 6 Mar 2026 17:50:45 +0000 (17:50 +0000)]
gdb: fail configure if Python version is too old for limited API
GDB can be built against the Python limited API using the configure
flag '--enable-py-limited-api=yes'. This flag is currently experimental,
and the build is not yet fully successful. Today, the minimum required
Python version for this option is 3.11. This requirement is not final
and will be raised to a later version as the migration progresses.
However, the configure script does not currently report an error if an
older version of Python is used. Instead, the build fails later with
numerous errors that are difficult to relate to Python limited API
compatiblity.
This patch adds a version check when '--enable-py-limited-api=yes' is
specified, ensuring that the provided Python version meets the minimum
requirements for the limited API support. If it does not, configure will
now fail with a clear error message.
Tom Tromey [Sun, 30 Mar 2025 15:50:18 +0000 (09:50 -0600)]
Update .debug_names documentation
This updates the .debug_names documentation to explain some DWARF
issues that we've handled in gdb.
This list still isn't exhaustive. I think there are some situations
where gdb may examine a declaration (which DWARF says not to do), but
I didn't document this as I don't recall the details.
Approved-By: Eli Zaretskii <eliz@gnu.org> Acked-By: Tom de Vries <tdevries@suse.de>
Tom Tromey [Tue, 22 Oct 2024 22:29:46 +0000 (16:29 -0600)]
Handle inline functions with dwz
Currently, gdb does not properly handle inline functions when dwz is
used. This can be seen by running gdb.cp/breakpoint-locs.exp with the
cc-with-dwz target board.
The problem here is that inline functions need special handling in the
dwz case.
First, recall that a DWARF partial unit cannot, in general, be read in
isolation, as it may not have a language. To handle this, gdb defers
scanning partial units directly, and instead scans them in the context
of some including CU.
Entries coming from the PU are attributed to this reading CU. If
multiple CUs import a PU, gdb has the reader threads race to see which
one does the actual reading.
However, if an inline function is moved into a partial unit, then that
means it has potentially been inlined somewhere in every including CU.
Thus, when linespec searches for this function, each such including CU
should be expanded. But because gdb only attributed the function's
index entry to one CU, only that particular one is expanded.
This patch fixes this bug. All inclusions of a PU are recorded.
Entries coming from a PU are attributed to that PU. For most entries
coming from the PU, a single "canonical" outer CU is chosen to expand.
However, when an inline function is found, all such CUs are expanded.
A change was also needed to the index writer to handle this case.
There, entries coming from a PU should note the correct including CU.
This must be done because, with .debug_names or .gdb_index, gdb does
not have information about unit imports. Handling inline functions
here means writing out a separate entry for each outermost CU that
includes the function's PU.
I did consider changing the cooked indexer to create an internal table
more similar to what would be created by the .debug_names (e.g.)
reader: that is, multiple entries for each inline function. However,
this seemed more expensive at read time, and a main goal of the cooked
indexer is to be fast.
This version updates an assert in the .debug_names writer, and adds a
regression test for that.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30728 Acked-By: Tom de Vries <tdevries@suse.de>
Tom Tromey [Sat, 24 Jan 2026 21:56:10 +0000 (14:56 -0700)]
Have iterate_over_one_compunit_symtab search included symtabs
A latent bug in the search-via-psyms series was that it neglected to
update iterate_over_one_compunit_symtab to search included symtabs.
I think lookups that needed this search used to work by accident -- an
included CU would be expanded but not searched, but a search of all
compunits() would then find it.
This patch corrects the oversight. I'm not sure if this bug is
readily visible without the next patch.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sat, 24 Jan 2026 21:56:16 +0000 (14:56 -0700)]
Remove C++ special case from process_imported_unit_die
process_imported_unit_die has a special case for C++, added as a
performance improvement.
While I somewhat agree with the general idea of this snippet --
importing a compilation unit seems like a strange thing to do, given
that partial units exist -- I think there are two issues with it.
First, it is specific to C++. I don't see any real reason that this
should be the case.
Second, it does not have a corresponding bit of code in the indexer.
This means that the cooked index's view of the DWARF differs from the
full reader's view here. This causes regressions in this series,
because the indexer assumes that reading a CU will cause all the
imported CUs to be read as a side effect -- but that does not happen
here.
I think fixing this in the indexer is not trivial. The reason for
this is that the indexer works in parallel, and once a reader has
acquired the "scan" bit for a CU, it is obligated to read it.
However, in this case this would require making a new cooked indexer.
Instead, because (1) this is weird and rare DWARF anyway, and (2) this
is just a performance optimization, I propose removing this.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Fri, 21 Nov 2025 16:43:11 +0000 (09:43 -0700)]
Combine two cases in cooked_index_functions::search
This combines a couple of 'if' statements in
cooked_index_functions::search. This simplifies the code a little and
also makes a subsequent patch a bit simpler as well.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sun, 30 Mar 2025 19:52:57 +0000 (13:52 -0600)]
Don't consider DW_TAG_inlined_subroutine as interesting
tag_interesting_for_index returns true for DW_TAG_inlined_subroutine
-- but this tag only appears where the function is actually inlined,
which is not interesting for the index.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sun, 30 Mar 2025 13:52:34 +0000 (07:52 -0600)]
Skip partial units in process_psymtab_comp_unit
process_psymtab_comp_unit passes 'false' for the 'skip_partial'
argument to the cutu_reader constructor, but then proceeds to skip
partial units. This patch simplifies the code by passing 'true'
instead.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Some gdb.dwarf2 tests match the output of commands like frame and
expect to see locations printed as fission-base.c:LINE (no directory
prefix). When the test programs are built with clang as CC_FOR_TARGET,
GDB can print an absolute source path instead, causing FAILs.
For example, with clang:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at /path/to/gdb/testsuite/fission-base.c:27
27 return func (-1);
(gdb) FAIL: gdb.dwarf2/fission-base.exp: frame in main
With gcc:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at fission-base.c:27
27 return func (-1);
(gdb) PASS: gdb.dwarf2/fission-base.exp: frame in main
The difference comes from the DWARF line table contents. With clang,
the .debug_line directory table can contain an absolute directory that
the file table entries reference:
The Directory Table:
0 /path/to/gdb/testsuite
The File Name Table:
0 Dir=0 Name=fission-base.c
1 Dir=0 Name=fission-base.c
Whereas with gcc the directory table is empty and only the bare filename
is present:
The Directory Table is empty.
The File Name Table:
1 Name=fission-base.c
This difference reflects toolchain/assembler behavior in how .file/.loc
are translated into .debug_line and is orthogonal to what these tests
aim to validate.
Force set filename-display basename in the affected tests so the
output is stable across toolchains.
Alan Modra [Tue, 7 Apr 2026 04:25:36 +0000 (13:55 +0930)]
various xcoff rs6000 linker issues
This patch started out as an exercise in sanity checking r_symndx
before indexing symbol hashes, but grew as I noticed other issues.
Merges xcoff_ppc_relocate_section and xcoff64_ppc_relocate_section.
All of the xcoff_reloc_function now return a status, with the idea
that error reporting can be done in one place.
* libxcoff.h (xcoff_reloc_function): Return bfd_reloc_status_type
rather than bool.
(_bfd_xcoff_relocate_section): Declare.
* coff-rs6000.c (xcoff_reloc_type_noop, xcoff_reloc_type_fail),
(xcoff_reloc_type_pos, xcoff_reloc_type_neg, xcoff_reloc_type_rel),
(xcoff_reloc_type_toc, xcoff_reloc_type_ba, xcoff_reloc_type_br),
(xcoff_reloc_type_crel, xcoff_reloc_type_tls): Return
bfd_reloc_status_type rather than bool. Don't emit standard
error message and don't set bfd error. Replace r_symndx
non-negative check with check against obj_raw_syment_count.
(_bfd_xcoff_relocate_section): Extracted from
xcoff_ppc_relocate_section and xcoff64_ppc_relocate_section.
Move error reporting to end of loop. Report error for
r_symndx out of range. Adjust for reloc howto special
function change. Properly check that reloc offset is in range.
Prevent possible segfault in _bfd_coff_internal_syment_name.
* coff64-rs6000.c: Similarly.
Alan Modra [Mon, 6 Apr 2026 13:28:22 +0000 (22:58 +0930)]
PR 34049 buffer overflow in xcoff_link_add_symbols
The fact that coffcode.h:coff_set_alignment_hook for rs6000 removes
sections can result in target_index > section_count. Thus any array
indexed by target_index must not be sized by section_count.
PR ld/34049
* xcofflink.c (xcoff_link_add_symbols): Size reloc_info array
using max target_index.
Pedro Alves [Tue, 2 May 2023 19:42:35 +0000 (20:42 +0100)]
Windows gdb: Eliminate global current_process.dr[8] global
current_process.dr needs to be per-thread for non-stop. Actually, it
doesn't even need to exist at all. We have x86_debug_reg_state
recording intent, and then the
cygwin_get_dr/cygwin_get_dr6/cygwin_get_dr7 functions are registered
as x86_dr_low_type vector functions, so they should return the current
value in the inferior's registers. See this comment in x86-dregs.c:
~~~
/* In non-stop/async, threads can be running while we change the
global dr_mirror (and friends). Say, we set a watchpoint, and
let threads resume. Now, say you delete the watchpoint, or
add/remove watchpoints such that dr_mirror changes while threads
are running. On targets that support non-stop,
inserting/deleting watchpoints updates the global dr_mirror only.
It does not update the real thread's debug registers; that's only
done prior to resume. Instead, if threads are running when the
mirror changes, a temporary and transparent stop on all threads
is forced so they can get their copy of the debug registers
updated on re-resume. Now, say, a thread hit a watchpoint before
having been updated with the new dr_mirror contents, and we
haven't yet handled the corresponding SIGTRAP. If we trusted
dr_mirror below, we'd mistake the real trapped address (from the
last time we had updated debug registers in the thread) with
whatever was currently in dr_mirror. So to fix this, dr_mirror
always represents intention, what we _want_ threads to have in
debug registers. To get at the address and cause of the trap, we
need to read the state the thread still has in its debug
registers.
In sum, always get the current debug register values the current
thread has, instead of trusting the global mirror. If the thread
was running when we last changed watchpoints, the mirror no
longer represents what was set in this thread's debug
registers. */
~~~
This patch makes the Windows native target follow that model as well.
Tromey pointed out that gdb/2388 mentioned in the code being removed
was moved to https://sourceware.org/bugzilla/show_bug.cgi?id=9493 in
the bugzilla migration. I tried the reproducer mentioned there, and
it still works correctly.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Id762d0faa7d5e788402f2ff5adad5352447a7526
commit-id:8a975ed0
Pedro Alves [Tue, 2 May 2023 19:42:35 +0000 (20:42 +0100)]
Windows gdb: Dead code in windows_nat_target::do_initial_windows_stuff
In windows_nat_target::do_initial_windows_stuff, there's no point in
setting windows_process.current_event.dwProcessId. It's a nop, given
the following memset.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I2fe460341b598ad293ea60d5f702b10cefc30711
While working on Windows non-stop support, I ran into a
very-hard-to-track-down bug.
The problem turned out to be that
infrun.c:proceed_resume_thread_checked resumed an already-executing
thread because the thread was marked as "executing=true,
resumed=false", and that function only skips resuming threads that are
marked resumed=true. The consequence was that GDB corrupted the
registers of the Windows DLL loader threads, eventually leading to a
GDB+inferior deadlock.
Originally, the "resumed" flag was only ever set when infrun decided
is was ready to process a thread's pending wait status. infrun has
since evolved to set the resumed flag when we set a thread's executing
flag too. We are not always consistent throughout in guaranteeing
that a thread is marked resumed=true whenever it is marked
executing=true, though. For instance, no target code that supports
non-stop mode (linux-nat, remote, and windows-nat with this series) is
making sure that new threads are marked resumed=true when they are
added to the thread list. They are only marked as {state=running,
executing=true}, the "resumed" flag is not touched.
Making proceed_resume_thread_checked check thr->executing() in
addition to thr->resumed(), feels like papering over a combination of
states that shouldn't happen nowadays.
OTOH, having to have the target backends mark new threads as
resumed=true just feels like too many different states (three) to set:
We really have too many "state tracking" flags in a thread.
Basically:
- whether a thread is "running/stopped/exited" (from the user's
perspective). This is the thread_info::state field.
- whether a thread is "executing" (infrun asked the target to set the
thread executing). This is thread_info::executing().
- whether a thread is "resumed" (infrun wants the thread to be
resumed, but maybe can't yet because the thread has a pending wait
status). This is thread_info::resumed()
"running", "executing", and "resumed" are almost synonyms, so this can
be highly confusing English-wise too.
For "running" vs "executing", in comments, we tipically need to
explain that "running/stopped/exited" is for the user/frontend
perspective, while "executing true/false" is for gdb's internal run
control.
(Also, "executing or not" can also mean something else in GDB's
codebase -- "target has execution" does not mean that threads are
actually running right now -- it's a test for whether we have a live
process vs a core dump!)
One simplification we can do that avoids this running vs executing
ambiguity is to replace the "executing" field with an "internal_state"
field, similar to the thread_info::state field, and make that new
internal_state field reuse the same enum thread_state type that is
used by thread_info::state. Like:
struct thread_info
{
...
/* Frontend/public/external/user view of the thread state. */
enum thread_state m_state = THREAD_STOPPED;
/* The thread's internal state. When the thread is stopped
internally while handling an internal event, like a software
single-step breakpoint, the internal state will be
THREAD_STOPPED, but the external state will still be
THREAD_RUNNING. */
enum thread_state m_internal_state = THREAD_STOPPED;
};
(Assume we'd add state() and internal_state() getters.)
With that, every check for thr->executing() is replaced with a
'thr->internal_state() == THREAD_RUNNING' check, and the code is
clearer by design. There is no confusion between "running" vs
"executing" any more, because they now mean the exact same thing.
Instead, we say e.g., 'thread has (user) state "running", and internal
state "stopped"'. Or simpler, 'thread is running (from the user's
perspective), but internally stopped'. That is after all what we
would way in comments today already.
That still leaves the 'resumed' flag, though. That's the least
obvious one. Turns out we can get rid of it, and make it a new state
tracked by thread_info::internal_state. That is, we make
internal_state have its own enumeration type (decoupled from
thread_info::state's type), and convert the resumed true/false flag to
a new enumerator of this new enumeration. Like so:
The patch adds getters/setters for both (user) state and
internal_state, and adds assertions around state transitions, ensuring
that internal_state doesn't get out of sync with
thread::have_pending_wait_status().
The code that adds/removes threads from the proc_target's
resumed_with_pending_wait_status list is all centralized within
thread_info::set_internal_state, when we switch to/from the
resumed-pending-status state. With the assertions in place, it should
be impossible to end up with a THREAD_INT_RUNNING thread with a
pending status.
The thread.c:set_running, thread.c:set_executing, thread.c:set_resumed
global functions are all gone, replaced with new thread.c:set_state
and thread.c:set_internal_state functions.
Pedro Alves [Wed, 19 Feb 2025 14:37:39 +0000 (14:37 +0000)]
init_wait_for_inferior doesn't imply proceed
The next patch adds an assertion to clear_proceed_status_thread,
making sure that we don't try to proceed a thread that is already
running. Turns out that catches attach_command calling
init_wait_for_inferior too late, after attaching has already created
already-running threads. This patch fixes.
However, that alone changes MI output when attaching (as caught by
e.g. gdb.rocm/mi-attach.exp). We'd go from:
That change would happen because init_wait_for_inferior calls
clear_proceed_status, which calls notify_about_to_proceed, where we
end up in mi_interp::on_about_to_proceed(), setting the mi_proceeded
flag. If that happens before linux_nat_target::attach is called, then
the set_running calls inside linux_nat_target::attach result in
emiting ^running in MI instead of ^done due to the back-compatibility
hack in mi_on_resume_1.
Now, init_wait_inferior really does not imply we're about to call
proceed. So restore the MI output by adding a new parameter to
clear_proceed_status that lets init_wait_inferior tell
clear_proceed_status to skip notifying the about_to_proceed observers.
I audited all init_wait_inferior calls, and this made sense in all of
them. The places do call proceed after init_wait_inferior, already
explicitly clear_proceed_status after init_wait_inferior. E.g.,
run_command_1.
Tom Tromey [Wed, 4 Mar 2026 15:13:41 +0000 (08:13 -0700)]
Handle inherited discriminants in Ada
In Ada, a discriminant might be inherited. Consider this code:
type Root_T (Root_Disc : Boolean) is tagged record
null;
end record;
type Child_T (Child_Disc : Boolean) is new Root_T (Root_Disc => Child_Disc) with record
case Child_Disc is
when True =>
Child_Flag : Boolean;
when others => null;
end case;
end record;
Here, Child_Disc does not really exist -- it just an alias of
Root_Disc.
Now, DWARF doesn't recognize this possibility, so compilers have come
up with two different approaches to handle this.
gnat-llvm will emit an artificial copy of Root_Disc as a member of
Child_T. See commit 48b5669c, where this was handled in gdb.
It wasn't convenient to follow this same approach in GCC (the two
compilers have very different DWARF generation approaches), and so GCC
emits the possibly-more-intuitive approach of simply having the
DW_AT_discr refer to the field DIE in Root_T.
This patch implements support for this approach in gdb. The idea here
is that, rather than try to figure out how to handle cross-type
references, gdb will implement the "LLVM" approach internally; that
is, make an artificial duplicate field.
For gnat-llvm, though, it was more convenient to always emit a bit
stride. Using an expression for this is a DWARF extension, but it's a
fairly obvious one, and something similar is already used in gdb.
This patch adds support for dynamic bit strides on an array to gdb. A
new test case, derived from gdb.dwarf2/arr-stride.exp (the derivation
explains the copyright dates) is included.
Alan Modra [Mon, 6 Apr 2026 00:54:07 +0000 (10:24 +0930)]
libsframe testsuite format mismatches on 32-bit host
libsframe.find/findfre-1.c:177:41: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int64_t’ {aka ‘long long int’} [-Wformat=]
* testsuite/sframe-test.h: Include inttypes.h.
* testsuite/libsframe.find/findfre-1.c (main): Use PRIx64 to print
int64_t vars.
* testsuite/libsframe.find/findfre-flex-1.c (main): Likewise.
* testsuite/libsframe.find/findfunc-1.c (main): Likewise.
* testsuite/libsframe.find/plt-findfre-1.c (main): Likewise.
* testsuite/libsframe.find/plt-findfre-2.c (main): Likewise.
Alan Modra [Mon, 6 Apr 2026 00:02:06 +0000 (09:32 +0930)]
gprofng format mismatch on 32-bit host
On a 32-bit host without --enable-64-bit-bfd
gp-gmon.cc:531:42: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘bfd_size_type’ {aka ‘unsigned int’} [-Wformat=]
On a 32-bit-host with --enable-64-bit-bfd the underlying type will be
unsigned long long.
* src/gp-gmon.cc (gen_gmon_map): Use %llu to print msize, and cast.
Instead of hard coding the path to milli.a, add the input file
as a lang_input_file_is_search_file_enum. This allows adding
a dummy archive in the testsuite.
2026-04-04 John David Anglin <danglin@gcc.gnu.org>
ld/ChangeLog:
* emultempl/hppa64elf.em (hppa64elf_after_parse): Search
for milli.a. Add "/lib/pa20_64" and "/usr/lib/pa20_64"
library search paths.
gdb: implement Tcl platform detection and improve private headers scan
This is needed for recent TEA support.
Autoconf macro CY_AC_TCL_PRIVATE_HEADERS checks more file locations and
determines TCL_PLATFORM according to the private header files found.
A C macro TCL_PLATFORM_DEFINE is computed accordingly and defined from
command line.
The same applies to Tk.
As in-tree Tcl/Tk sources have been removed, this case is left out.
Alan Modra [Fri, 3 Apr 2026 22:13:06 +0000 (08:43 +1030)]
score howto special_function final linking output bfd access
Like commit 804439b4d7a8, avoid segfaults when the hack to access
the output bfd won't work, eg. when the sym is absolute.
* elf32-score.c (score_elf_gprel15_reloc): Return bfd_reloc_undefined
when output_bfd cannot be determined from the symbol.
(score_elf_gprel32_reloc): Likewise.
* elf32-score7.c (score_elf_gprel32_reloc): Likewise.
Alan Modra [Fri, 3 Apr 2026 22:07:59 +0000 (08:37 +1030)]
bfd_perform_relocation and howto special_function bfd params
Describe the output_bfd parameter of bfd_perform_relocation, in
pariticular that it is NULL when final linking.
* reloc.c (bfd_perform_relocation): Comment on abfd and
output_bfd parameters in the function description.
(reloc_howto_struct <special_function>): Refer to above.
Tom de Vries [Fri, 3 Apr 2026 13:19:26 +0000 (15:19 +0200)]
[gdb] Enable ptype /o for some dynamic types
Printing the offsets of a struct containing a flexible array member using
"ptype /o" currently fails:
...
$ cat test.c
struct s {
int a;
int b[];
};
struct s foo;
$ gcc -g test.c -c
$ gdb -q -batch test.o -ex "ptype /o struct s"
warning: ptype/o does not work with dynamic types; disabling '/o'
type = struct s {
int a;
int b[];
}
...
This has been the case since gdb 14, containing commit 0c1aa2a0953 ("Disable
ptype/o for dynamic types").
If we revert the commit, we get instead:
...
$ gdb -q -batch test.o -ex "ptype /o struct s"
/* offset | size */ type = struct s {
/* 0 | 4 */ int a;
/* 4 | 0 */ int b[];
/* total size (bytes): 4 */
}
...
which is similar to what pahole prints:
...
struct s {
int a; /* 0 4 */
int b[]; /* 4 0 */
The problem is that the commit uses is_dynamic_type:
...
if (flags.print_offsets && is_dynamic_type (type))
{
warning (_("ptype/o does not work with dynamic types; disabling '/o'"));
flags.print_offsets = 0;
}
...
which is too restrictive.
Fix this by using a new function cannot_print_offsets instead.
Tom de Vries [Fri, 3 Apr 2026 13:19:26 +0000 (15:19 +0200)]
[gdb] Factor out is_dynamic_type_internal_1
Simplify is_dynamic_type_internal by factoring out is_dynamic_type_internal_1,
leaving only the handling of the top_level parameter in
is_dynamic_type_internal.
H.J. Lu [Wed, 18 Mar 2026 20:58:35 +0000 (13:58 -0700)]
ld: Pass --no-rosegment to ld in some linker tests
For elf/x86, --rosegment places code after read-only data, instead of
before read-only data. Pass --no-rosegment to ld in some linker tests
to avoid extra linker test failures when binutils is configured with
--enable-rosegment for elf/x86.
binutils/
PR ld/34003
* testsuite/lib/binutils-common.exp (check_rosegment_support): New.
(run_dump_test): Make NO_ROSEGMENT_LDFLAGS global.
The ada-valprint-error.exp test links a nodebug .o file with a separate
DWARF .o file generated by lib/dwarf.exp. This requires the linker to
apply relocations for initialized pointers in the .data section.
Some clang + linker combinations fail to apply these relocations,
leaving fd__global as NULL instead of pointing to buffer. This causes
the test to print null instead of the expected error message.
Binary evidence from .comment section confirms which compiler and
linker were used. Testing shows:
- GCC 13 + GNU ld 2.42: PASS
- clang 20 + GNU ld 2.42: FAIL
- clang 22 + ld.lld 22: FAIL
- clang 17/19 + GNU ld 2.45.0: PASS
The failure is a linker limitation when handling this specific
relocation pattern, not a GDB bug. Document this in the test file
to help users understand why the test may fail with certain toolchains.
Joel Holdsworth [Thu, 2 Apr 2026 17:23:14 +0000 (10:23 -0700)]
PR 34038 null pointer dereference in elf_link_output_extsym
When linking an ELF object file containing an STT_GNU_IFUNC symbol,
elf_link_output_extsym() unconditionally calls the backend's
elf_backend_finish_dynamic_symbol callback. On targets that do not
support dynamic linking (and therefore do not define this callback),
the function pointer is NULL, causing a segmentation fault.
Add a NULL check for bed->elf_backend_finish_dynamic_symbol before
the indirect call. This is consistent with the definition in
elfxx-target.h which defaults this callback to 0 (NULL) for targets
that do not override it.
Found by AFL++ fuzzing of the ELF linker with mutated object files.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
Tom de Vries [Thu, 2 Apr 2026 21:09:09 +0000 (23:09 +0200)]
[gdb/tui] Make tui_setup_io more robust
The following sequence of events may happen when enabling TUI:
- tui_enable () is called,
- a SIGFPE happens, before tui_setup_io (1) is called,
- the SIGFPE triggers handle_fatal_signal, which calls tui_disable (),
- during tui_disable (), tui_setup_io (0) is called, and
- tui_setup_io (0) tries to restore things that were saved during a previous
tui_setup_io (1) call, but tui_setup_io (1) was never called so the saving
never happened.
This can cause current_ui.m_ui_stderr to be nullptr, which then can cause a
crash in sig_write (PR33918).
Fix this by:
- adding a variable tui_io_mode, and
- using the variable to bail out of tui_setup_io in case the current mode
doesn't change.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33918
Patrick Monnerat [Tue, 31 Mar 2026 14:44:44 +0000 (16:44 +0200)]
Support MinGW & 64-bit libraries/paths in Tcl autoconf scripts
Debian implements directories /usr/lib32 and /usr/lib64, but installs
tclConfig.sh and tkConfig.sh in /usr/lib. Therefore always search in
/usr/lib when the others fail.
Most of these changes were originally submitted by Keith Seitz for
Insight support.
This commit also strips trailing spaces and normalizes tab/space
indenting in config/tcl.m4.
In the setting of GAS and LD ABI flags the `*-*-linux*' target is used
twice in a different legs of a multi-part conditional, with the second
instance never having a chance to match due to the earlier one. Remove
the unused expression then.
The gdb.base/watchpoint.exp on Windows with non-stop support added
(later in the series) exposed an issue with the currently_stepping
logic when tested with software watchpoints.
The issue only happens when:
- You have multiple threads. gdb.base/watchpoint.exp exposed it on
Windows because there the OS always spawns a few extra threads.
- Displaced stepping is not available. The Windows non-stop work
does not implement displaced stepping yet. That is left as an
optimization for later.
- The target backend is working in non-stop mode.
I've written a new test that exposes the issue on GNU/Linux as well
(on hardware single-step targets, like x86-64). There, we see:
continue
Continuing.
../../src/gdb/infrun.c:2918: internal-error: resume_1: Assertion `!(thread_has_single_step_breakpoints_set (tp) && step)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp: target-non-stop=on: displaced-stepping=off: continue until exit (GDB internal error)
Currently, software watchpoints are implemented by forcing
single-stepping. That is done by currently_stepping returning true
when we have a software watchpoint. proceed calls resume, which calls
resume_1, which then ends up always requesting a single-step resume,
even if the higher layers wanted a continue.
Now, if you set a software watchpoint, and then continue the program,
and there's a breakpoint at the current PC, GDB needs to step over
that breakpoint first. If displaced stepping is not available, then
GDB temporarily pauses all threads, removes the breakpoint,
single-steps the thread that needs to move past the breakpoint, and
then finally, reinserts the breakpoint, and restarts all threads
again. That last restarting step happens in the restart_threads
infrun function.
restart_threads iterates over all threads trying to restart them one
by one. There, we have:
if (currently_stepping (tp))
{
infrun_debug_printf ("restart threads: [%s] was stepping",
tp->ptid.to_string ().c_str ());
but, what if TP is actually a new thread that hasn't yet ever set
stepping? currently_stepping still returns true, due to the software
watchpoint, and we end up in keep_going_stepped_thread, here:
if (tp->stop_pc () != tp->prev_pc)
{
ptid_t resume_ptid;
... because prev_pc was stale at that point (we had no reason to
update it earlier). E.g. on Windows we see something like:
[infrun] restart_threads: start: event_thread=1867996.1867996.0, inf=-1
[infrun] restart_threads: restart threads: [1867996.1867996.0] is event thread
[infrun] restart_threads: restart threads: [1867996.1868003.0] was stepping
[infrun] keep_going_stepped_thread: resuming previously stepped thread
[infrun] keep_going_stepped_thread: expected thread advanced also (0 -> 0x7ffff7ce57f8)
[infrun] clear_step_over_info: clearing step over info
[infrun] do_target_resume: resume_ptid=1867996.1868003.0, step=0, sig=GDB_SIGNAL_0
On GNU/Linux, we may see:
[infrun] keep_going_stepped_thread: expected thread advanced also (0x7ffff7d2683d -> 0x7ffff7ce57f8)
there prev_pc might have been updated on an earlier proceed call,
which makes the issue harder to see, but it is stale too here.
That means we insert a single-step breakpoint at the current PC, and
continue the thread, with target_resume directly, asking for a normal
continue.
Eventually, something causes a user-visible stop. For example, the
software watchpoint triggers. That makes GDB stop all threads.
Now, if the user re-resumes the program, say, with "continue", we fail
this assertion in resume_1 coming from proceed:
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(thread_has_single_step_breakpoints_set (tp) && step));
"step" is true because currently_stepping returns true since we have a
software watchpoint. And the thread has a single-step breakpoint
installed from earlier, because of that code mentioned above, in
keep_going_stepped_thread reached from restart_threads.
This patch fixes the root cause -- the currently_stepping call in
restart_threads returned true for a thread that has never set stepping
in the first place. This is because currently_stepping really serves
two purposes currently:
#1 - for a thread that we are about to resume, should we set it
stepping?
#2 - for a thread that just stopped, was it stepping before?
The fix is thus to decouple those two aspects:
- for #1, we simply rename currently_stepping to should_step.
- for #2, we record whether the thread was stepping before in a new
currently_stepping flag in thread_info.
As mentioned, there's a new testcase included. I tested this on
x86-64 GNU/Linux, native and gdbserver, and on Windows x64 with the
non-stop series. The assertion triggers on all of those with the fix,
and is fixed by this patch on all of those, too.
There's one unnecessary check for currently_stepping in
handle_signal_stop that can be removed. It is unnecessary because
currently_stepping is only ever called if
ecs->event_thread->control.trap_expected is true, and then if it is
true, then currently_stepping always returns true too.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I7b07bc62e8570333d2e4856d2e55ae6e58f8260c
commit-id:0125e966
Paul Eggert [Sun, 22 Mar 2026 21:08:47 +0000 (14:08 -0700)]
gdbserver: fix unlikely getpkt buffer overflow
This problem was reported by Manish Sharma.
Within gdbserver, in getpkt, there is no bounds checking as we parse
the incoming packet. An unexpectedly large packet can therefore
overflow the allocated buffer. Fixed by adding bounds checking.
If a packet is too long then in ACK mode we send out the NAK, but then
immediately return -1 as the result from getpkt. Currently the only
thing that GDB can do when it sees a '-' (NAK) is resend the packet.
If the original packet was too long then the resent packet will also
be too long. gdbserver would then be stuck re-reading the incoming
too long packet. Now GDB does give up after 3 retries, but this means
gdbserver is relying on GDB to give up sending, when in reality,
gdbserver knows it's not going to be able to recover. So I propose
that gdbserver should just give up once it sees a packet that is too
long.
While looking at the error handling in this case I noticed that in the
noack_mode case, if we get a packet with a bad checksum, or a packet
that is too long, getpkt will return success and gdbserver will try to
interpret whatever it has. This seems like a bad idea. So I've
updated this code path to also return an error.
Then there are a couple of places where we had a comment like this:
/* FIXME: Eventually add buffer overflow checking (to getpkt?) */
Now that getpkt does have buffer overflow checking, I've removed these
comments.
Pedro Alves [Wed, 11 Jun 2025 21:05:23 +0000 (22:05 +0100)]
Improve attach on Windows
Unlike most targets, on Windows, when you attach, GDB doesn't print
the current stack frame. Vis:
On GNU/Linux:
attach 3340347
Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19
19 while (! should_exit)
(gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
On Linux, GDB prints the frame because after the target_attach, GDB
goes back to the event loop, to wait for an initial stop event. The
stop event arrives, and we process it, which sets the stop_print_frame
global, and then we get to normal_stop, which prints the frame iff
stop_print_frame is set, which it is.
Windows OTOH, is a target_attach_no_wait target, so after
target_attach, there is no going back to event loop. In
infcmd.c:attach_command, we go straight to attach_post_wait which
takes us to normal_stop. But this time, nothing set stop_print_frame
to true, so no frame is printed. Actually, if the global happened to
be true due to an earlier event from debugging a previous inferior,
then we will print the frame.
This patch makes GDB's behavior consistent, by making sure the globals
normal_stop looks at are in a good state in the target_attach_no_wait
path.
With that alone, GDB now prints the frame:
(gdb) attach 2915
Attaching to program: /usr/bin/sleep.exe, process 2832
[New Thread 2832.0x2a68]
[New Thread 2832.0xb1c]
[New Thread 2832.0x8ac]
[Switching to Thread 2832.0x8ac]
0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
This is still not ideal, IMHO, as the current thread is the thread
that Windows injects to attach:
(gdb) info threads
Id Target Id Frame
1 Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll
2 Thread 2832.0x2a68 "sig" 0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll
3 Thread 2832.0xb1c 0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll
* 4 Thread 2832.0x8ac 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
Automatically switching to the main thread is IMHO more useful. That
results in very similar output than what we see on Linux:
attach 5164
Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
[New Thread 5164.0x87c]
[New Thread 5164.0x28f0]
[New Thread 5164.0x376c]
[New Thread 5164.0x2db4]
[New Thread 5164.0xce4]
main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
19 while (! should_exit)
(gdb)
If we do this, then we can simplify gdb.base/attach.exp a bit by
removing a couple Cygwin special cases.
The patch does all that, which results in the following
gdb.base/attach.exp progressions:
-FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
-FAIL: gdb.base/attach.exp: do_attach_tests: attach2, with no file
-FAIL: gdb.base/attach.exp: do_attach_tests: load file manually, after attach2 (re-read) (got interactive prompt)
-FAIL: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach
+PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
+PASS: gdb.base/attach.exp: do_attach_tests: attach2, with no file
+PASS: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
+PASS: gdb.base/attach.exp: do_attach_failure_tests: first attach
Andrew Burgess [Wed, 25 Mar 2026 16:41:46 +0000 (16:41 +0000)]
gdb: move call to clear_symtab_users out from finish_new_objfile
Move the call to clear_symtab_users from within finish_new_objfile to
instead reside within symbol_file_add_with_addrs. This resolves an
issue where clear_symtab_users can be called multiple times during the
loading of the main executable, which causes important information to
be discarded.
To understand the problem we must understand two things. First, how
does clear_symtab_users discard critical information? This is the
easy part of the problem, clear_symtab_users notifies the
all_objfiles_removed observer, in auto-load.c there is a listener for
this observer, clear_section_scripts, which discards information about
any auto-loaded scripts. If we call clear_symtab_users after
auto-loading a script within a program space, then information about
that script having been loaded will be discarded.
The second thing we must consider is the order in which functions are
called when loading a main executable with separate debug
information. I'm only listing some of the most important functions in
the process here, the ones relevant to the issue being fixed. In the
following text I'll use "main objfile" to refer to the actual
executable, and "debug info objfile" to refer to the split debug info
corresponding to the "main objfile".
1. Call symbol_file_add_with_addrs for the main objfile.
2. Call syms_from_objfile passing in the main objfile.
3. Call objfile::find_and_add_separate_symbol_file on the main
objfile.
4. Call symbol_file_add_separate for the debug info objfile.
5. Call symbol_file_add_with_addrs for the debug info objfile.
6. Call syms_from_objfile for the debug info objfile. The debug
symbols are contained in this objfile so they are read and added
to GDB.
7. Call finish_new_objfile for the debug info objfile, followed by
triggering the new objfile observer for the debug info objfile.
8. We are now done in symbol_file_add_with_addrs for the debug info
objfile. We now unwind the stack back to (1).
9. Back in symbol_file_add_with_addrs for the main objfile, the
debug symbols have now been added (from the separate debug info
objfile), so we can now call finish_new_objfile for the main
objfile, followed by triggering the new objfile observer for the
main objfile.
10. Success! The main objfile, and the associated debug info objfile
have now been added to GDB.
Notice that we end up with a recursive call back into
symbol_file_add_with_addrs, which results in two calls to
finish_new_objfile, the debug info objfile is processed first, and the
main objfile is processed second.
The main objfile will have SYMFILE_MAINLINE in its symfile_add_flags,
and this will end up being passed to symbol_file_add_separate.
This means that in finish_new_objfile we currently call
clear_symtab_users after finishing both the debug info objfile, and
after the main objfile, in that order.
Auto-loaded scripts are loaded by load_auto_scripts_for_objfile (in
auto-load.c) which is called by the new_objfile observer. If the
debug info objfile contains any scripts within the .debug_gdb_scripts
section, then these will be loaded (7) in the above list, after the
debug info objfile has been added, but before the main objfile is
added.
Now, this shouldn't be a problem, except that currently, when
finishing the main objfile, we call clear_symtab_users, which triggers
the all_objfiles_removed observer, which calls
clear_section_scripts (in auto-load.c), which discards all records of
auto-loaded scripts.
This issue is exposed by the test extension added in this commit. An
executable is compiled with debug information, the executable includes
a .debug_gdb_scripts section. We then use objcopy to split the debug
information into a separate objfile. This takes the
.debug_gdb_scripts section with it. We then ask GDB to load the
executable, which triggers loading of the separate debug information
file. Loading the separate debug information file loads the
.debug_gdb_scripts section, then GDB finishes loading the main
executable and discards the record of loading the .debug_gdb_scripts.
This is exposed by using 'info auto-load'.
The solution I propose is to move the call to clear_symtab_users
earlier within symbol_file_add_with_addrs, and to guard the call so
that it is only called for the main objfile, and not for the debug
info objfile. The new location for the clear_symtab_users call is
before the syms_from_objfile call. This means that it will be called
for the main objfile before GDB starts loading the debug info objfile.
There are two additional, related changes in this commit. The new
location for the clear_symtab_users call is before
program_space::symfile_object_file is removed by unlinking the
referenced objfile, so we don't want the breakpoint_re_set call in
clear_symtab_users to resolve breakpoints against the old objfiles.
To avoid this, at the new call to clear_symtab_users, we force the
SYMFILE_DEFER_BP_RESET. Then we restructure finish_new_objfile so
that breakpoint_re_set can always be called if appropriate. This
replaces the old breakpoint_re_set call which was reached via the old
call to clear_symtab_users.
Additionally, in finish_new_objfile, we only set
program_space::symfile_object_file for the main objfile. Previously
we would set this field first to the debug info objfile, and then
reset this field to the main objfile. This set then overwrite
sequence was harmless, but also pointless. I think by restricting
this code so we only set it to the main objfile better reflects the
state we want GDB to be in.
Andrew Burgess [Wed, 25 Mar 2026 16:28:05 +0000 (16:28 +0000)]
gdb/testsuite: modernise the gdb.python/py-section-script.exp test
I want to add more test cases to gdb.python/py-section-script.exp, so
this commit is an initial cleanup of the test script.
The primary change here is that we no longer overwrite the test
executable. The test has a loop, previously we'd overwrite the test
executable on each iteration, now we create a new test executable on
each iteration.
Additionally, at the end of the loop we strip the debug from the
executable and run some additional tests, I now create a copy of the
executable and strip the debug from that instead, this leaves the
unstripped executable around if we need to rerun tests outside of the
testsuite.
Then I've made some other small clean ups, making use of
$gdb_test_name, and the -wrap flag within gdb_test_multiple.
I've made use of require is_elf_target.
And I've factored out some code to set the auto-load safe path as in
some places we were switching the path separator, but in others we
just assumed ":". The helper proc always uses ";" for mingw.
I also added a full 'info auto-load python-scripts' check after
loading the stripped binary. Previously we only actually checked one
of the scripts had been loaded correctly.
Andrew Burgess [Wed, 4 Feb 2026 20:31:31 +0000 (20:31 +0000)]
gdb: introduce '**' for skip globs
There are cases when a user might wish to skip every file of a
particular type within a directory, and all its sub-directories.
Currently, you'll need to account for each sub-directory in your skip
patterns, so given:
Revert "skip -gfile: call fnmatch without FNM_FILE_NAME"
Due to bug PR gdb/33872. The initial commit also changed GDB in a
non-backward compatible way, that is 'skip -gfile /include/*.h' would
now match all .h files in every sub-directory of /include/, which
might not be what the user wants. The approach taken in this commit
avoids changing this behaviour and allows the user to better select
what they want to match.
This worked by splitting both the filename and the glob on every '/'
and then using a recursive algorithm to match each part of the file
name. This initial approach only split on '/' which means there would
have been some regressions on DOS based file systems where '\' can be
used as a directory separator, though this would probably have been
easy enough to fix.
However, it was pointed out that the splitting and matching was rather
inefficient, and it might be better to convert the glob into a regexp
and use that for matching. I figured; how hard can that be, which is
how this version of the patch came to be.
Turns out it's not that simple. I'm not going to go though all the
details here, but the basic idea is that, when the user creates a glob
skip GDB calls glob_to_regexp to convert the glob to a regexp, which
is then compiled and stored in the skiplist_entry. The regexp can
then be used as you'd expect to check for matches.
The matching is now done in a global function do_skip_gfile_p, which
makes it easier to write unit tests. The
skiplist_entry::do_skip_gfile_p just calls the global function.
I've retained the initial file basename check, which still uses
fnmatch, as this is likely quicker than performing the regexp match,
at least, I hope so, I've not tried to benchmark anything.
Converting a glob to a regexp is mostly straight forward, except for
bracket expressions, we dont want these to match against directory
separators, so we need to filter the directory separators out, this
retains compatibility with the fnmatch FNM_PATHNAME flag. It is this
filtering that is the cause of most of the pain. The details for all
of this can be found in glob_bracket_expr::parse.
We also need to take care to handle case insensitive file systems.
This is mostly just adding REG_ICASE to the regexp flags, however,
there are some issues with, you guessed it, bracket expressions. If
we have a character range that spans out of the upper case letter set,
for example [W-_], then, at least for glibc, when REG_ICASE is set
this ends up being treated like [w-_]. This is unfortunate because
'w' is after '_' so the range is now invalid. To resolve this we end
up splitting the range into two giving: [W-Z[-_], now when glibc
adjusts to lower case, we end up matching with [w-z[-_].
For DOS like file systems, the created regexp adds a pattern that
matches both '/' and '\' whenever either of these is seen in the glob.
But there's also some additional work needed for, you guessed it,
bracket expressions; we need to ensure '\' is removed from any ranges.
One final issue with, you guessed it, bracket expressions, is
character classes, e.g. [:alpha:]. Many classes are fine, but some,
like [:punct:] include '/' and '\'. For now I just raise an error if
the user tries to use a class that includes a directory separator.
This is a change in behaviour, but hopefully isn't going to impact too
many people. The only fix I can currently see for this would be to
expand the problematic character classes into their component
characters, and then remove the directory separators. But I haven't
tried to do that just yet.
There are documentation updates and tests for the new feature. All
existing behaviour should remain unchanged. On the testing side I've
added both some full DejaGNU tests and some self tests. The self
tests are focused on just the core glob matching function, but the
full DejaGNU tests ensure that the whole mechanism, from skip
creation to its final usage, is also tested.
Andrew Burgess [Tue, 10 Feb 2026 11:10:38 +0000 (11:10 +0000)]
gdb: move debug logging around in some skip related functions
Move the debug printing code out from skiplist_entry::do_skip_gfile_p
and skiplist_entry::do_skip_file_p. This will make the next commit
easier as we can switch to an early exit style function layout.
There should be no user visible changes, even when 'set debug skip on'
is in use, after this commit.
Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Keith Seitz <keiths@redhat.com>
Patrick Monnerat [Sat, 14 Mar 2026 15:23:26 +0000 (16:23 +0100)]
Support MinGW & 64-bit libraries/paths in Tcl autoconf scripts
Debian implements directories /usr/lib32 and /usr/lib64, but installs
tclConfig.sh and tkConfig.sh in /usr/lib. Therefore always search in
/usr/lib when the others fail.
Most of these changes were originally submitted by Keith Seitz for
Insight support.
After several years of dedicated service, Alan Hayward has decided to step down
from his role as maintainer. Alan has been instrumental in keeping the Arm
ports robust and modern. Most notably, he championed the complex task of
implementing support for the Scalable Vector Extension (SVE), which required
significant changes to how GDB handles variable register sizes, something that
is used for SME to this day. Beyond SVE, he also enabled Pointer Authentication
support for AArch64. And his work on XML target descriptions and general
infrastructure refactoring have left the codebase in a much stronger position.
We thank Alan for his leadership and his many contributions to the project over
the years.
At the same time, I am pleased to announce that Thiago Bauermann has agreed to
step up as a new co-maintainer for AArch64 and Arm. Thiago is already a familiar
face in the community, having contributed extensively to GDB on PowerPC and,
more recently, AArch64. His recent work on MOPS, GCS and SME features have been
vital for keeping GDB aligned with the latest developments on AArch64.
Thiago has also contributed significant time reviewing patches from others,
something that is highly appreciated in the community.
Please join me in thanking Alan for his hard work and welcoming Thiago to
his new role. I have updated the gdb/MAINTAINERS file accordingly.
Add --rosegment option to BFD linker to stop the '-z separate-code' from gen erating two read-only segments.
added --rosegment option to generate one read-only segment with
-z separate-code. But it puts the read-only data, which contains ELF
headers and .note.gnu.build-id section, in the executable segment:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x00185 0x00185 R E 0x1000
LOAD 0x001000 0x00001000 0x00001000 0x000d0 0x000d0 R 0x1000
LOAD 0x001f78 0x00002f78 0x00002f78 0x0008c 0x0008c RW 0x1000
DYNAMIC 0x001f78 0x00002f78 0x00002f78 0x00070 0x00070 RW 0x4
NOTE 0x000154 0x00000154 0x00000154 0x00024 0x00024 R 0x4
NOTE 0x00109c 0x0000109c 0x0000109c 0x00034 0x00034 R 0x4
GNU_PROPERTY 0x00109c 0x0000109c 0x0000109c 0x00034 0x00034 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x001f78 0x00002f78 0x00002f78 0x00088 0x00088 R 0x1
Eric Botcazou [Mon, 30 Mar 2026 17:10:26 +0000 (19:10 +0200)]
PE-COFF: Fix link failure of C++ code with debug info after partial linking
If you apply the following recipe to the attached C/C++ files with a PE-COFF
toolchain, you get the specified output:
1. g++ -c clib.cpp cpplib.cpp test.c -g
2. g++ -o pl.o clib.o cpplib.o -nostdlib -Wl,-r
3. objcopy pl.o
objcopy.exe: pl.o: warning: COMDAT symbol
'.debug_frame$_ZNSt12_Vector_baseIiSaIiEE12_Vector_implD1Ev' does not match
section name '.debug_frame'
4. g++ -o test test.o pl.o
ld.exe: pl.o: warning: COMDAT symbol
'.debug_frame$_ZNSt12_Vector_baseIiSaIiEE12_Vector_implD1Ev' does not match
section name '.debug_frame'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE13_M_deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv'
pl.o:clib.cpp:(.pdata$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt12_Vector_baseIiSaIiEE19_M_get_Tp_allocatorEv'
pl.o:clib.cpp:(.pdata$_ZNSt15__new_allocatorIiE10deallocateEPiy+0x0):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt15__new_allocatorIiE10deallocateEPiy'
pl.o:clib.cpp:(.pdata$_ZNSt15__new_allocatorIiE10deallocateEPiy+0x4):
relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against
`.text$_ZNSt15__new_allocatorIiE10deallocateEPiy'
collect2.exe: error: ld returned 1 exit status
The problem pertains to section symbols generated for COMDAT sections: they
are marked as local symbols as per Microsoft's PE-COFF specification, but
partial linking discards the duplicate COMDAT sections without being able
to either merge them, or remove them when they are used in a relocation.
So they end up as undefined local symbols after the partial link, which in
turn may cause the final link to fail (in practice you need e.g. a call to
objcopy in between, because it moves them to the end of the symbol list).
This change instructs the linker to "relocate" them instead, that is to say
to attach them to the one COMDAT section that is output among the multiple
COMDAT sections that are duplicate. It also prevents partial linking from
prematurely globing the .[z]debug_frame* sections together, as already done
for the .eh_frame* sections.
bfd/
* cofflink.c (_bfd_coff_link_input_bfd): For a relocatable output,
relocate section symbols for input sections that are not going to
be emitted because they are duplicate of another one in the link.
ld/
* scripttempl/pe.sc (.debug_frame): Do not glob all .debug_frame*
sections together when not relocating.
(.zdebug_frame): Likewise for .zdebug_frame* sections.
* scripttempl/pep.sc (.debug_frame): Likewise.
(.zdebug_frame): Likewise.
Alan Modra [Mon, 30 Mar 2026 10:57:10 +0000 (21:27 +1030)]
obj_coff_sym_hashes sanity checks
Various places in cofflink.c and coffgen.c assume the r_symndx
indexing sym_hashes is sane. Add some checks.
* cofflink.c (_bfd_coff_link_input_bfd): Sanity check r_symndx
against obj_raw_syment_count before using it to index sym_hashes,
rather than just checking for the special -1 value.
(_bfd_coff_generic_relocate_section): Delete unnecessary check.
Sanity check weak symndx2 against obj_raw_syment_count.
* coffgen.c (_bfd_coff_gc_mark_hook): Sanity check weak symndx2
against obj_raw_syment_count.
(_bfd_coff_gc_mark_rsec): Sanity check r_symndx.
Alan Modra [Sat, 28 Mar 2026 08:11:02 +0000 (18:41 +1030)]
buffer overflow in loongarch_elf_add_sub_reloc_uleb128
oss-fuzz managed to trigger a buffer overflow processing a bogus
leb128. Well, the leb128 encoding can be arbitrarily long so this
isn't surprising at all. If we want to guard against user input
triggering buffer overflows then we'd need to ensure input is
terminated somehow, or do as this patch does.
Remove _bfd_read_unsigned_leb128 and _bfd_read_signed_leb128,
replacing all uses of these functions with _bfd_safe_read_leb128.
Jens Remus [Fri, 27 Mar 2026 16:42:08 +0000 (17:42 +0100)]
s390: Only use canonical PLT for non-PIC code taking address in PDE
Fix incorrect use of canonical PLT in position-dependent executables
(PDE) that violated pointer equality. The linker must distinguish
between non-PIC code linked as PDE (which requires canonical PLT for
pointer equality) and PIC code linked as PDE (which must not use
canonical PLT). This is determined by examining relocations, not just
the executable type (PIE vs. PDE).
Canonical PLT entries are needed only when non-PIC code takes function
addresses. Non-PIC code uses absolute addresses and assumes all
addresses are known at link time. When such code both calls and takes
the address of a shared library function, the linker creates a canonical
PLT entry (setting the symbol's value to the PLT stub address) to ensure
all references use the same address, maintaining pointer equality.
However, PIC code uses GOT-indirect addressing for function pointers.
When PIC code takes a function's address, it loads from the GOT, which
the dynamic linker resolves to the actual function address in the shared
library. Using canonical PLT in this case is wrong, as it forces all
GOT entries to point to the PLT stub, breaking pointer equality when the
shared library compares function addresses internally.
Require pointer equality in PDE for symbols with non-PLT PC-relative
relocations, that are likely in address taken context, and direct
relocations, that are likely in function reference context. Do so
for IFUNC symbols defined in a non-shared object. Clear value of PLT
undefined symbols if pointer equality is not needed and do not hash them
in '.gnu.hash' section.
As workaround for GCC 12-14 treat PC32DBL relocation for address taking
instruction "larl rX,<sym>@PLT" as if it was without @PLT suffix and
require pointer equality. This ensures correct behavior even when the
compiler incorrectly marks address-taking instructions with @PLT.
GCC 12-14, since GCC commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for
local functions in 64-bit mode") [1], unconditionally suffix non-local
symbols with @PLT, regardless of whether they are used in function call
instructions (i.e. brasl) or address taking instructions (i.e. larl).
The assembler therefore generates a PLT32DBL instead of a PC32DBL
relocation for larl. The linker therefore cannot distinguish between
function call and address taking instructions solely from the relocation
type. The latter requiring pointer equality.
This complements GCC commit a2e0a30c52fa ("IBM zSystems: Do not use
@PLT with larl") [2], which makes GCC stop suffixing @PLT to address
taking larl instructions, so that the correct behavior with regards to
pointer equality is also achieved with affected GCC 12-14.
Note that this workaround can be reverted once GCC 12-14 emitting
address taking larl instructions with @PLT suffix have become
irrelevant.
Note that without the workaround for GCC 12-14 suffixing @PLT to larl
the following linker tests would fail:
Based on x86-64, especially Jakub Jelinek's x86 commits 47a9f7b34f7a
(clearing value of PLT undefined symbols if pointer equality not needed)
and fdc90cb46b0f (omitting PLT undefined symbols from '.gnu.hash').
Note that on x86-64 PC32 (and PC64) relocations are excluded as
indication for address taken context requiring function pointer
equality. This is because x86-64 used a PC32 relocation in function
calls from non-PIC code, which has been resolved with commit bd7ab16b4537 ("x86-64: Generate branch with PLT32 relocation").
[1] GCC commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for local
functions in 64-bit mode"),
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0990d93dd8a4
[2] GCC commit a2e0a30c52fa ("IBM zSystems: Do not use @PLT with larl"),
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a2e0a30c52fa
bfd/
PR ld/29655
* elf64-s390.c (elf_s390_check_relocs): Require pointer equality
for direct and non-PLT PC-relative relocations indicating
address taking instructions and for PLT32DBL relocations, when
used with address taking larl instruction.
(elf_s390_finish_dynamic_symbol): Do not use canonical PLT for
non-local undefined symbols if pointer equality is not needed.
Abort if pointer equality needed flag not set although required.
(elf_s390_copy_indirect_symbol): Copy pointer equality needed
flag.
(elf_s390_hash_symbol): New function. Based on x86-64.
(elf_backend_hash_symbol): Wire up elf_s390_hash_symbol.
ld/testsuite/
PR ld/29655
* ld-elf/shared.exp: Add new pr29655 test.
* ld-elf/pr29655a.c: New file. Based on Rui's sample in PR.
* ld-elf/pr29655b.c: Likewise.
* ld-elf/pr29655.rd: Expect zero fun_public symbol value.
* ld-s390/plt_64-1.wf: Adjust expected test output to change in
.gnu.hash due to omitted PLT undefined symbols that do not need
pointer equality.
* ld-s390/plt_64-1_eh.wf: Likewise.
Bug: https://sourceware.org/PR29655 Co-authored-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jan Beulich [Fri, 27 Mar 2026 09:42:21 +0000 (10:42 +0100)]
bfd: fold aarch64* entries
There are three groups with identical selections each. Make them have
three entries rather than five (plain little-endian ELF entries were
already folded when the Phoenix target was added).
projects / thirdparty / binutils-gdb.git / log
