While working on commit 391c4026573 ("[gdb] Simplify debuginfod_is_enabled") I
noticed this Wstringop-overread workaround:
...
url_view = url_view.substr (off);
/* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
hppa seem convinced url_view might be of SIZE_MAX length.
And so complains because the length of an array can only
be PTRDIFF_MAX. */
DIAGNOSTIC_PUSH
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
off = url_view.find_first_of (' ');
DIAGNOSTIC_POP
...
I had difficulty understanding how the warning got triggered, and why it was
ok to ignore it, so I investigated this and ended up filing a gcc PR [1].
While doing so, I realized that this:
...
- url_view = url_view.substr (off);
+ url_view = url_view.substr (off, PTRDIFF_MAX);
...
is a simpler workaround, that:
- is not specific to the warning and also
- states explicitly what the assumption is we're making.
I ended up using this instead to make the workaround part more minimal:
...
url_view = url_view.substr (off);
+ url_view = url_view.substr (0, PTRDIFF_MAX);
off = url_view.find_first_of (' ');
...
The gcc PR got closed because it's supposed to be fixed in 12.1, so the
workaround is enabled only for g++ < 12.1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124879
Following Simon Marchi's fix for dw2-empty-inline-ranges.exp [1], this
test exhibits the same failure pattern when running in an environment
where GDB can't disable address space randomization (such as in a
container where that capability is removed) with a toolchain generating
position-independent executables.
The test does a first run to grab addresses of labels and function
boundaries (foo_middle, foo_start, foo_end, and range labels). It then
crafts DWARF using these addresses across multiple test iterations.
When the executable is PIE and ASLR is active, the addresses in each
subsequent run don't match the addresses from the initial run.
The failure manifests in the 'maint info blocks' output comparisons,
where the expected addresses (from the first run) don't match the
actual addresses in the test runs.
The simplest fix, following Simon's approach, is to use "nopie" when
building the binaries. This doesn't affect the effectiveness of the
test, which is exercising different ways DW_AT_entry_pc can be
expressed in DWARF.
Also, with a non-PIE executable, it is no longer necessary to run the
inferior before grabbing the addresses in the initial run, as they are
stable. So remove that runto_main call.
Tom de Vries [Tue, 14 Apr 2026 20:45:23 +0000 (22:45 +0200)]
[gdb/symtab] Add find_symbol_for_pc_maybe_inline
We have function find_symbol_for_pc:
...
find_symbol_for_pc (CORE_ADDR pc)
{
return find_symbol_for_pc_sect (pc, find_pc_mapped_section (pc));
}
...
which uses some standard way of getting the section for the given pc.
Add a similar function find_symbol_for_pc_maybe_inline that calls
find_symbol_for_pc_sect_maybe_inline, and use it in jump_command.
Andrew Burgess [Tue, 14 Apr 2026 20:36:09 +0000 (22:36 +0200)]
gdb: use get_current_frame consistently in print_stop_location
In print_stop_location, in the PRINT_UNKNOWN case we currently use a
strange mix of get_current_frame and get_selected_frame. This works
fine because at the point print_stop_location is called the selected
frame will always be the current frame, but calling these two
different functions is confusing, at least for me.
Since bpstat_print selects the frame to print (which usually is the current
frame, but not always), the correct frame to use is the selected frame after
the bpstat_print call.
Assign the selected frame to a variable print_frame, and use it throughout the
function.
There should be no user visible changes after this commit.
Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Andrew Burgess <aburgess@redhat.com>
we change the 36/0x401165 entry into a 37/0x401165 entry:
...
File name Line number Starting address View Stmt
dw2-extend-inline-block.c 34 0x401116 x
dw2-extend-inline-block.c 35 0x401129 x
dw2-extend-inline-block.c 26 0x401138 x
dw2-extend-inline-block.c 27 0x401147 x
dw2-extend-inline-block.c 28 0x401156 x
dw2-extend-inline-block.c 36 0x401156
-dw2-extend-inline-block.c 36 0x401165
+dw2-extend-inline-block.c 37 0x401165
dw2-extend-inline-block.c 37 0x401174 x
dw2-extend-inline-block.c 38 0x401183 x
dw2-extend-inline-block.c 39 0x401192 x
dw2-extend-inline-block.c 40 0x4011a1 x
dw2-extend-inline-block.c - 0x4011b7
...
As it happens, the fix to extend truncated inlined function blocks
doesn't work in this case. This is PR gdb/33930.
We can work around this by making sure that the inlined function block
isn't truncated in the first place:
What happens is that the slightly different line program triggers a
different stepping path, which includes a case of "stepped to a
different frame, but it's not the start of a statement", which
refreshes the stepping info and consequently updates
tp->control.step_frame_id to the frame id of main.
So by the time we're stopped at line 37, and are trying to figure out
what to print in print_stop_location, this condition evaluates to
true:
...
/* Finished step in same frame and same file, just print source
line. */
source_flag = SRC_LINE;
...
It's good to realize here that because foo is inlined into main,
tp->control.step_start_function is not foo but main, so consequently
the step_start_function check (which checks if we are still in the
same function) also passes, even though we actually stepped from foo
into main.
The problem is the use of find_symbol_for_pc, this function
deliberately skips over inline frames and returns the symbol for the
innermost non-inline frame.
It might be tempting to think that we should switch to use
find_symbol_for_pc_sect_maybe_inline, which will return the symbol for
an inline frame, but this also has problems, specifically, attempting
this caused a regression in gdb.opt/inline-cmds.exp. The previous
version of this patch, which showed the regression can be found here:
At a given $pc the inferior might be reported as being within an
inline frame, or it might be reported as being in the containing
non-inline frame. When the user performs a 'step' the
step_start_function needs to be set based on the function symbol of
the frame the inferior is actually reported in. And we have a
function that gives us this information, get_frame_function. So
instead of looking up the step_start_function based on the $pc value,
set it based on the frame.
Test gdb.dwarf2/dw2-extend-inline-block.exp is extended with the
additional test case described above.
Tested on x86_64-linux.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33981
Andrew Burgess [Tue, 14 Apr 2026 20:36:09 +0000 (22:36 +0200)]
[gdb/testsuite] Extend gdb.opt/inline-cmds.exp
When using this tentative patch [1], GDB regresses like this in test-case
gdb.opt/inline-cmds.exp:
...
Temporary breakpoint 1, main () at inline-cmds.c:64
64 y = 8; /* set mi break here */
(gdb) s
+main () at inline-cmds.c:66
66 result = func1 ();
(gdb) s
func1 () at inline-cmds.c:35
35 bar ();
(gdb)
...
but the regression doesn't produce a FAIL.
The regression does produce a FAIL during the part of the test that runs in MI
mode.
Extend the test so the regression also produces a FAIL in CLI mode.
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226272.html
Simon Marchi [Wed, 18 Mar 2026 20:27:23 +0000 (16:27 -0400)]
gdb/dwarf: fix internal error when FDEs do not describe the CFA
New in v2: change how undefined_retaddr is set, to avoid regressions on
AArch64 (among possibly others).
This patch fixes an internal error problem that happens when a frame
description entry does not define the Canonical Frame Address (CFA).
This problem was initially reported downstream as a ROCgdb issue (see
Bug trailer below), but I wrote a reproducer that uses the .debug_frame
functionality added to the DWARF assembler in the previous patch.
The error is:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1046: internal-error: Unknown CFA rule.
The original bug was encountered while debugging a GPU kernel written
with Triton [1]. From what I understand, the generated kernel does not
really use a stack, so the .debug_frame contents generated is quite
bare:
$ readelf --debug-dump=frames k
Contents of the .debug_frame section:
For those who don't speak fluent .debug_frame, what we see here is a
Frame Description Entry (FDE) that doesn't define any register rule,
referring to a Common Information Entry (CIE) that also doesn't define
any initial register rule. This is equivalent to having no unwind
information at all. One question is: why generate these at all? I
suppose that this is an edge case, that the compiler is written in a way
that that presumes there will always be some unwind info. That there is
no "if unwind info is empty, skip emitting the FDE" check. Anyway, the
important thing for us is that these can be found in the wild, so GDB
shouldn't crash.
The fix consists of handling CFA_UNSET in the dwarf2_frame_cache switch.
CFA_UNSET is the initial state when we start interpreting a CFA program,
meaning that we don't know yet how the CFA is defined. In our case, it
remains unset after interpreting the CFA program.
With just the fix above, we get:
(gdb) bt
#0 0x000055555555511d in main ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Which is good (better than crashing), but it would be good to avoid the
error. To do so, set the undefined_retaddr flag to true. This has
two effects:
- dwarf2_frame_this_id won't try to build a frame id from the CFA
(which is good, we don't have a CFA)
- dwarf2_frame_unwind_stop_reason will return UNWIND_OUTERMOST, which
is the most accurate thing we can return here (there is no outer
frame)
Simon Marchi [Wed, 18 Mar 2026 20:27:22 +0000 (16:27 -0400)]
gdb/testsuite: add .debug_frame support in DWARF assembler
Add support to the DWARF assembler for generating .debug_frame sections.
My initial use case is to reproduce a crash happening when encountering
an empty FDE, but I suppose that other use cases will pop up in the
future.
- Generate procs for the `DW_CFA_*` constants, similar to how the
DW_OP_* constants are handled. These `DW_CFA_*` procs are expected
to be used in the CIE and FDE bodies, described below.
- Add handlers for `DW_CFA_*` operations that take arguments. I tried
to cover everything that is in DWARF 5.
- Add the `frame` proc, used to generate one .debug_frame section.
- Add the `_frame_CIE` proc (available as `CIE` in the context of the
frame proc), used to generate one Common Information Entry.
- Add the `_frame_FDE` proc (available as `FDE` in the context of the
frame proc), used to generate one Frame Description Entry.
Due to the nature of the .debug_frame contents (it describes how
specific machine registers get saved), I expect that most of
the tests written using this will be arch-specific. But I think it
will still be useful, as it will let us craft .debug_frame sections to
look exactly how we want.
I included a test (gdb.dwarf2/debug-frame.exp), which is more like a
proof that we can build something useful using this, and can serve as an
example for whoever wants to write a test case using this in the future.
Change-Id: I048568ded53883abf52d70139e5cd3e7b4ac3841 Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 10 Apr 2026 06:43:22 +0000 (08:43 +0200)]
x86/AT&T: make GOT-relative expressions work
The expressions used in intel-got{32,64}.s should equally work (or not) in
AT&T mode. Changing the Intel syntax parser such that O_symbol wouldn't
happen to be wrapped around such expressions breaks it there, too. It
really isn't correct to limit this to just O_symbol. Permitting O_add and
O_subtract as well requires taking care of the other operand as well then.
(Strictly speaking non-zero offsets aren't very useful here, but then at
least with an equate of 0 this ought to work. The non-zero offset in the
testcase helps demonstrate that this offset isn't lost.)
Jan Beulich [Fri, 10 Apr 2026 06:42:10 +0000 (08:42 +0200)]
gas: distinguish local symbol flavors when printing symbols
Ordinary symbols fulfilling S_IS_LOCAL() criteria aren't the same as local
symbols. Make sure one can tell them apart in print_symbol_value()'s (and
print_expr()'s) output.
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.
projects / thirdparty / binutils-gdb.git / log
