Simon Marchi [Fri, 27 Feb 2026 20:05:01 +0000 (15:05 -0500)]
gdb: change gdbarch_ax_pseudo_register_collect to return void
I initially changed it to return bool instead of int, but then realized
that none of the implementations actually ever returned an error, so
change the return type to void.
Use gdb_assert_not_reached instead of internal_error, and remove the use
of the gettext macro, because these messages are typically not
translated, if we look at other call sites of gdb_assert_not_reached.
Change-Id: Iab9804f090805ded5a50336dbab8d1a0c099ce33 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Mon, 9 Mar 2026 15:13:02 +0000 (16:13 +0100)]
[gdb/contrib] Avoid NotImplementedError in dwarf-to-dwarf-assembler.py
The previous commit mentions:
...
File "dwarf-to-dwarf-assembler.py", line 173, in _format_value
raise NotImplementedError(f"Unknown data type: {type(self.value)}")
NotImplementedError: Unknown data type: <class 'elftools.construct.lib.container.ListContainer'>
...
While the NotImplementedError makes its point clear, it's unhelpful in two ways:
- it's hard to find out what part of the input causes the error, and
- it may be that the user is not interested at all in the bit triggering the
error, but some part after it, and the error prevents the user from seeing it
Fix this by returning an error string instead of raising an error, resulting in this output:
...
DW_AT_upper_bound Unknown data type: <class 'elftools.construct.lib.container.ListContainer'>: \
[255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255] DW_FORM_data16
...
Tom de Vries [Mon, 9 Mar 2026 15:13:02 +0000 (16:13 +0100)]
[gdb/contrib] Handle DW_FORM_data16 in dwarf-to-dwarf-assembler.py
I ran gdb/contrib/dwarf-to-dwarf-assembler.py on testsuite executable
gdb.ada/task_bp/foo, and ran into:
...
Traceback (most recent call last):
File "dwarf-to-dwarf-assembler.py", line 660, in <module>
main(sys.argv)
~~~~^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 656, in main
generator.generate()
~~~~~~~~~~~~~~~~~~^^
File "dwarf-to-dwarf-assembler.py", line 628, in generate
self.generate_die(die, indent_count)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 607, in generate_die
die_lines = die.format(self.dwarf_parser.offset_to_die, indent_count)
File "dwarf-to-dwarf-assembler.py", line 297, in format
return "\n".join(self.format_lines(offset_die_lookup, indent_count))
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 394, in format_lines
inner_lines = super().format_lines(offset_die_lookup, indent_count + 1)
File "dwarf-to-dwarf-assembler.py", line 285, in format_lines
child_lines = child.format_lines(
offset_die_lookup, indent_count=indent_count + 1
)
File "dwarf-to-dwarf-assembler.py", line 269, in format_lines
attr_line = attr.format(
offset_die_lookup, indent_count=indent_count + 1
)
File "dwarf-to-dwarf-assembler.py", line 219, in format
s += self._format_value(offset_die_lookup)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 173, in _format_value
raise NotImplementedError(f"Unknown data type: {type(self.value)}")
NotImplementedError: Unknown data type: <class 'elftools.construct.lib.container.ListContainer'>
...
when trying to print the DW_FORM_data16 constant for this upper bound:
...
<1><3af88>: Abbrev Number: 47 (DW_TAG_subrange_type)
<3af89> DW_AT_lower_bound : 0
<3af89> DW_AT_upper_bound : 0xffffffffffffffffffffffffffffffff
<3af99> DW_AT_name : system__put_images__lll_integer_images__unsigned_typeXn
...
Fix this by handling elftools.construct.lib.container.ListContainer.
Tom de Vries [Mon, 9 Mar 2026 15:13:02 +0000 (16:13 +0100)]
[gdb/contrib] Handle DW_LANG_Mips_Assembler in dwarf-to-dwarf-assembler.py
I ran gdb/contrib/dwarf-to-dwarf-assembler.py on a hello world executable, and
ran into:
...
Traceback (most recent call last):
File "dwarf-to-dwarf-assembler.py", line 654, in <module>
main(sys.argv)
~~~~^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 650, in main
generator.generate()
~~~~~~~~~~~~~~~~~~^^
File "dwarf-to-dwarf-assembler.py", line 622, in generate
self.generate_die(die, indent_count)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 601, in generate_die
die_lines = die.format(self.dwarf_parser.offset_to_die, indent_count)
File "dwarf-to-dwarf-assembler.py", line 291, in format
return "\n".join(self.format_lines(offset_die_lookup, indent_count))
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "dwarf-to-dwarf-assembler.py", line 388, in format_lines
inner_lines = super().format_lines(offset_die_lookup, indent_count + 1)
File "dwarf-to-dwarf-assembler.py", line 263, in format_lines
attr_line = attr.format(
offset_die_lookup, indent_count=indent_count + 1
)
File "dwarf-to-dwarf-assembler.py", line 209, in format
s += "@" + LANG_NAME[self.value]
~~~~~~~~~^^^^^^^^^^^^
KeyError: 32769
...
The problem is that the language 0x8001 (DW_LANG_lo_user + 1) is not listed in
elftools.dwarf.enums.ENUM_DW_LANG.
This is MIPS vendor extension DW_LANG_MIPS_assembler, commonly used for
any assembly in DWARF versions that don't define a value for it (starting v6,
there's DW_LANG_Assembly).
Fix the generic case by emitting:
...
DW_AT_language 32769 DW_FORM_sdata
...
and this specific case by emitting:
...
DW_AT_language @DW_LANG_Mips_Assembler
...
Matthieu Longo [Fri, 27 Feb 2026 10:28:34 +0000 (10:28 +0000)]
gdb/python: accept gdbpy_ref in init helpers and return bool
Passing 'gdbpy_ref<> &' instead of raw 'PyObject *' to init helpers
makes ownership of PyObject clearer at call sites, and removes
unnecessary '.get()' calls.
Changing the return type from 'int' to 'bool' improves readability
and better expresses the success/failure semantics.
Jakub Jelinek [Thu, 5 Mar 2026 12:11:39 +0000 (13:11 +0100)]
libiberty: Copy over .ARM.attributes section into *.debug.temp.o files [PR124365]
If gcc is configured on aarch64-linux against new binutils, such as
2.46, it doesn't emit into assembly markings like
.section .note.gnu.property,"a"
.align 3
.word 4
.word 16
.word 5
.string "GNU"
.word 0xc0000000
.word 4
.word 0x7
.align 3
but instead emits
.aeabi_subsection aeabi_feature_and_bits, optional, ULEB128
.aeabi_attribute Tag_Feature_BTI, 1
.aeabi_attribute Tag_Feature_PAC, 1
.aeabi_attribute Tag_Feature_GCS, 1
The former goes into .note.gnu.propery section, the latter goes into
.ARM.attributes section.
Now, when linking without LTO or with LTO but without -g, all behaves
for the linked binaries the same, say for test.c
int main () {}
$ gcc -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC, GCS
$ gcc -flto -g -mbranch-protection=standard test.c -o test; readelf -j .note.gnu.property test
readelf: Warning: Section '.note.gnu.property' was not dumped because it does not exist
The problem is that the *.debug.temp.o object files created by lto-wrapper
don't have these markings. The function copies over .note.GNU-stack section
(so that it doesn't similarly on most arches break PT_GNU_STACK segment
flags), and .note.gnu.property (which used to hold this stuff e.g. on
aarch64 or x86, added in PR93966). But it doesn't copy the new
.ARM.attributes section.
The following patch fixes it by copying that section too. The function
unfortunately only works on names, doesn't know if it is copying ELF or some
other format (PE, Mach-O) or if it is copying ELF, whether it is EM_AARCH64
or some other arch. The following patch just copies the section always,
I think it is very unlikely people would use .ARM.attributes section for
some random unrelated stuff. If we'd want to limit it to just EM_AARCH64,
guess it would need to be done in
libiberty/simple-object-elf.c (simple_object_elf_copy_lto_debug_sections)
instead as an exception for the (*pfn) callback results (and there it could
e.g. verify SHT_AARCH64_ATTRIBUTES type but even there dunno if it has
access to the Ehdr stuff).
No testcase from me, dunno if e.g. the linker can flag the lack of those
during linking with some option rather than using readelf after link and
what kind of effective targets we'd need for such a test.
2026-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/124365
* simple-object.c (handle_lto_debug_sections): Also copy over
.ARM.attributes section.
Ruslan Valiyev [Thu, 26 Feb 2026 19:15:06 +0000 (19:15 +0000)]
libiberty: fix resource exhaustion in rust demangler (PR demangler/106641)
demangle_binder() parses the bound_lifetimes count as a base-62
integer with no upper bound. A crafted symbol can encode a huge
lifetime count in very few bytes, causing OOM or CPU hang.
Cap bound_lifetimes at 1024 and check rdm->errored in the loop
so it bails out early on errors during iteration.
libiberty/ChangeLog:
PR demangler/106641
* rust-demangle.c (demangle_binder): Reject bound_lifetimes
above 1024 to prevent resource exhaustion from crafted symbols.
Add rdm->errored check in the loop condition.
* testsuite/rust-demangle-expected: Add regression test.
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
Iain Sandoe [Tue, 24 Feb 2026 11:44:27 +0000 (11:44 +0000)]
libiberty, Darwin: Fix handling of file offsets.
In the case where a Mach-O object is embedded inside some container
(e.g. an archive) we must account the offset from the start of that
container when reading. In most cases, this has been done correctly.
However, we were missing the case for reading segment data. This
only showed up once we tried using archives (since regular Mach-O
objects start at the begining of the file).
Fixed thus.
libiberty/ChangeLog:
* simple-object-mach-o.c
(simple_object_mach_o_segment): Account for the offset of
this Mach-O object from the start of any container.
LIU Hao [Mon, 9 Feb 2026 13:44:07 +0000 (21:44 +0800)]
libiberty: Preserve `errno` across calls to `libiberty_vprintf_buffer_size()`
The MSVCRT `strtoul()` function resets `errno` to zero upon success. On such
a system, `libiberty_vprintf_buffer_size()` could clobber `errno` like this:
Alan Modra [Thu, 5 Mar 2026 22:26:43 +0000 (08:56 +1030)]
Remove bfd_boolean from gdb
Replace a few vestiges of bfd_boolean in gdb with bool. I haven't
tried to replace FALSE/TRUE in gdb except when the type was clearly
bool. There may well be other occurrences of FALSE or TRUE that ought
to be tidied. Source that uses BOOL or a typedef enum boolean in
particular isn't changed.
Fangrui Song [Sun, 8 Feb 2026 21:18:28 +0000 (13:18 -0800)]
gas/doc: clarify internal symbol vs local symbol terminology
In ELF, "local symbols" refer to symbols of STB_LOCAL binding. The
doc is inconsistent: while it uses "local symbol" in places like .local,
"local symbols" are also used for .L-prefixed symbols (as determined by
bfd_is_local_label).
Rename "Local Symbol Names" to "Internal Symbol Names" for .L-prefixed
symbols, and rename "Local Labels" to "Numeric Local Labels" for
N:/Nb/Nf numeric labels. This avoids confusion with ELF STB_LOCAL
"local symbols".
The term "internal symbol" is chosen over alternatives like "temporary
symbol" because it describes the purpose of these symbols: they are for
internal use by compilers and assemblers, not meant to be visible
externally (albeit they can become visible in certain situations).
While ELF defines STV_INTERNAL as a symbol visibility, it is rarely used
in practice and unlikely to cause confusion (only used by SGI for their
link-time interprocedural optimization; useless on other OSes).
Tom Tromey [Wed, 28 Jan 2026 18:12:24 +0000 (11:12 -0700)]
Fix debug_names function visibility
A few test cases that emit custom DWARF with debug_names had a
discrepancy between the debug info and the debug names. In particular
a function would be marked private in the info:
Dimitar Dimitrov [Fri, 20 Feb 2026 20:43:20 +0000 (22:43 +0200)]
gas: pru: Add TSEN and MVI instructions
Add support for TSEN and MVI instructions to GAS and libopcodes.
TSEN is available in newer PRU core revisions, and can be used to
implement multitasking. MVI allows indirectly addressing CPU registers
using a pointer in R1 register.
Matthieu Longo [Fri, 12 Sep 2025 16:26:38 +0000 (17:26 +0100)]
ld: clarify comments on /DISCARD/ output section behavior
The previous comments made it difficult to understand how the /DISCARD/
output section interacts with non-contiguous regions.
In summary, the general rule is that the first (top-most) clause takes
precedence over subsequent ones:
- If /DISCARD/ appears first, the section is dropped. There is no need
to warn about potential behavior changes with non-contiguous regions
when the section is already discarded.
- If /DISCARD/ follows clauses that assign the input section to an output
section, /DISCARD/ is ignored. If the input section can't be assigned
to the output section for a later reason, an error will be raised.
Otherwise the input section will be assigned as intended to an output
section specified by one of the matching clauses previous to /DISCARD/.
Matthieu Longo [Tue, 9 Sep 2025 13:23:01 +0000 (14:23 +0100)]
aarch64: add tests for non-contiguous memory regions
This patch adds AArch64 test cases for all non-contiguous memory scenarios.
Those tests were copy-pasted from AArch32, and adapted for AArch64.
It also adds a new test case inspired from a real case where several sections
containing interrupt vector tables, declared in different compilation units,
and all aligned on 2KB, are supposed to be merged into one output section
fitting on 2KB memory.
Matthieu Longo [Tue, 9 Sep 2025 10:32:41 +0000 (11:32 +0100)]
ld: fix segfault on discarded input sections not fitting in memory regions
In the case of non-contiguous memory regions, if an input section did not
fit in any of the designated memory regions, the linker marked it as
discarded, and warn_non_contiguous_discards() would only issue warning on
it, relying on later unresolved symbol errors to terminate the process
before a crash occur. This approach was insufficient, and crashes did occur
on AArch64.
This patch renames warn_non_contiguous_discards () to a name that does not
contain "discard" as it created some confusion with the /DISCARD/ output
section. It also promotes the warnings to errors, and ensures that the
link process terminates cleanly if any input section is not allocated to
an output section.
It also updates an AArch32 test's expectations to match the corrected
behavior. Tests for the crash cases are added in a subsequent patch.
Finally, it adds some patterns to /DISCARD/ in ld-elf/non-contiguous.ld.
Before this patch, a section which was not assigned to an output section
because no pattern matched, did not raise any error.
Approved-By: Jan Beulich <jbeulich@suse.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31412
Matthieu Longo [Tue, 9 Sep 2025 10:10:43 +0000 (11:10 +0100)]
explicitly state code assumptions on output section in AArch64 ld handlers
When support for non-contiguous memory was added, some corner cases when
sections were removed from the output object, did not emit fatal error and
reached code paths that correctly assumed every input section had a valid
output section, and this led to crashes due to segfault.
This patch adds BFD_ASSERTs in the previously segfaulting code, to
explicitly state code assumptions.
Matthieu Longo [Tue, 9 Sep 2025 09:12:55 +0000 (10:12 +0100)]
ld: fix segfault caused by untagged stub sections
In the case of non-contiguous memory regions, a far-call stub section
must be assigned to the memory of the section it was originally emitted
for. If the stub section does not fit, the section is marked as dropped,
and removed later. To emit a useful message to the user, however, a stub
section needs to be discernible from sections originating from input
objects.
Previously [1], this distinction was made using the SEC_LINKER_CREATED
flag only in the AArch32 backend handler <arch>_add_stub_section. Other
backends that didn't set this flag on their stub sections skipped required
checks in ld/ldlang.c:size_input_section(). On AArch64, this caused the
linker to proceed into code paths that assumed output sections were set,
instead of reporting fatal errors, and ultimately led to a segmentation
fault.
However, the SEC_LINKER_CREATED flag does not solely indicate that a
section was created by the linker. Its original meaning also meant that
the section should not be handled by the generic relocation code. Reusing
this flag to identify stub sections, while it appeared to fix the issue,
introduced unintended side effects. On PowerPC, for instance, it skipped
relocations present in the stubs and interpreted them as absolute
addresses.
This patch proposes a new attribute 'veneer', indicating that a section
contains branch veneers. The attribute is set on AArch32, AArch64 and
PowerPC immediately after the creation of the stub section. Others
architectures are left unchanged, as they do not appear to support
non-contiguous memory regions (no tests were found to verify the fix).
Additionally, the diagnostic message was improved when a stub cannot be
placed in the same memory region as its referencing code.
Approved-By: Jan Beulich <jbeulich@suse.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31412
[1]: abf874a, Add support for non-contiguous memory regions.
Tom de Vries [Thu, 5 Mar 2026 21:10:09 +0000 (22:10 +0100)]
[gdb/symtab] Replace per-BFD lock with global BFD lock
Our current BFD locking scheme is as follows [1]:
...
There is one global mutex, gdb_bfd_mutex, which BFD can lock and unlock via
the callbacks we pass it. This appears to lock the internal global data
structures of BFD (like its global cache or some global counter), but not data
in individual `bfd *`instances. If the user of BFD wishes to call functions
on a given `bfd *` from multiple threads, it must provide the synchronization
itself. For this, we have gdb_bfd_data::per_bfd_mutex.
...
PR33811 reports the following data race:
...
Read of size 1 at 0x72440010c608 by thread T5 (mutexes: write M0):
#0 bfd_get_section_limit_octets bfd.h:2433
#1 bfd_get_section_contents bfd/section.c:1612
#2 bfd_is_section_compressed_info bfd/compress.c:901
#3 bfd_is_section_compressed bfd/compress.c:959
#4 gdb_bfd_map_section(bfd_section*, unsigned long*) gdb/gdb_bfd.c:779
...
vs:
...
Previous write of size 4 at 0x72440010c608 by main thread (mutexes: write M1):
#0 bfd_cache_delete bfd/cache.c:180
#1 _bfd_cache_close_unlocked bfd/cache.c:607
#2 bfd_cache_close_all bfd/cache.c:664
#3 notify_before_prompt gdb/event-top.c:524
...
In more detail, this read in bfd_get_section_limit_octets in bfd/bfd-in2.h:
...
if (abfd->direction != write_direction && sec->rawsize != 0)
...
vs. this write in bfd_cache_delete in bfd/cache.c:
...
abfd->last_io = bfd_io_force;
...
There is already locking used for both the read and write.
In gdb_bfd_map_section, we use the per-BFD lock:
...
gdb_bfd_data *gdata = (gdb_bfd_data *) bfd_usrdata (abfd);
gdb::lock_guard<gdb::mutex> guard (gdata->per_bfd_mutex);
...
And in bfd_cache_close_all, we use the global BFD lock:
...
bool
bfd_cache_close_all (void)
{
...
if (!bfd_lock ())
return false;
...
if (!bfd_unlock ())
return false;
return ret;
}
...
The problem is that the locking is not sufficient. Since bfd_cache_close_all
accesses individual BFDs, it needs to lock the corresponding per-BFD locks as
well.
A naive way to implement this using the existing scheme of wrappers, would be to
add a gdb_bfd_cache_close_all that locks all per-BFD locks, calls
bfd_cache_close_all, and unlocks all per-BFD locks, like this:
...
bool
gdb_bfd_cache_close_all ()
{
bool res;
for (auto abfd : all_bfds)
{
auto gdata = static_cast<gdb_bfd_data *> (bfd_usrdata (abfd));
gdata->per_bfd_mutex.lock ();
}
res = bfd_cache_close_all ();
for (auto abfd : all_bfds)
{
auto gdata = static_cast<gdb_bfd_data *> (bfd_usrdata (abfd));
gdata->per_bfd_mutex.unlock ();
}
return res;
}
...
Apart from the fact that trying to hold all those locks at the same time
increases the changes of deadlock, it also accesses all_bfds without locking
the required global BFD lock (reported by TSAN).
It's easy enough to fix that by adding:
...
gdb_bfd_cache_close_all ()
{
+ gdb::lock_guard<gdb::recursive_mutex> guard (gdb_bfd_mutex);
...
but that brings us to the problem of lock-order-inversion (also reported by
TSAN), and indeed timeouts do occur.
I came up with a complicated scheme [2] that:
- doesn't try to lock all the per-BFD locks at the same time, and
- addresses the lock-order-inversion problem by releasing the global BFD lock
before acquiring the per-BFD lock and then re-acquiring the global BFD lock
However, this approach was seen as too convoluted.
So instead, revert to a simple locking scheme with only the global BFD lock,
dropping the per-BFD lock.
This changes the per-BFD locking in gdb_bfd_map_section to global BFD locking,
which means that the read in bfd_get_section_limit_octets is now guarded by
the global BFD lock, which is the same lock guarding the write in
bfd_cache_delete. So, the race is fixed.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33811
Tom de Vries [Thu, 5 Mar 2026 20:59:28 +0000 (21:59 +0100)]
[gdb/testsuite] Fix gdb.opt/inline-entry.exp with clang
I ran test-case gdb.opt/inline-entry.exp with clang, more specifically:
...
get_compiler_info: clang-17-0-6
...
and ran into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2.1, bar (val=<optimized out>) at inline-entry.c:29^M
29 if (global == val)^M
(gdb) PASS: gdb.opt/inline-entry.exp: continue to bar
continue^M
Continuing.^M
^M
Breakpoint 2.3, bar (val=2) at inline-entry.c:29^M
29 if (global == val)^M
(gdb) FAIL: gdb.opt/inline-entry.exp: continue to foo
continue^M
Continuing.^M
^M
Breakpoint 3, foo (arg=arg@entry=1) at inline-entry.c:23^M
23 global += arg;^M
(gdb) FAIL: gdb.opt/inline-entry.exp: continue until exit
...
The problem is that the test-case expects two breakpoint locations for
function bar, and to hit one of them, but there are three and it hits two of
them.
This is due to the debug info, which for function bar:
...
<1><25d>: Abbrev Number: 7 (DW_TAG_subprogram)
<25e> DW_AT_name : bar
<25f> DW_AT_decl_file : 1
<260> DW_AT_decl_line : 27
<261> DW_AT_prototyped : 1
<261> DW_AT_type : <0x243>
<265> DW_AT_external : 1
<265> DW_AT_inline : 1 (inlined)
<2><265>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<266> DW_AT_name : val
<267> DW_AT_decl_file : 1
<268> DW_AT_decl_line : 27
<269> DW_AT_type : <0x243>
...
has three corresponding DW_TAG_inlined_subroutine DIEs:
...
<2><27d>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
<27e> DW_AT_abstract_origin: <0x25d>
<282> DW_AT_ranges : 0x31
<283> DW_AT_call_file : 1
<284> DW_AT_call_line : 38
<2><285>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
<286> DW_AT_abstract_origin: <0x25d>
<28a> DW_AT_low_pc : 0x114f
<28b> DW_AT_high_pc : 0x5
<28f> DW_AT_call_file : 1
<290> DW_AT_call_line : 38
<291> DW_AT_call_column : 18
<3><292>: Abbrev Number: 12 (DW_TAG_formal_parameter)
<293> DW_AT_const_value : 1
<294> DW_AT_abstract_origin: <0x265>
<2><299>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
<29a> DW_AT_abstract_origin: <0x25d>
<29e> DW_AT_low_pc : 0x1166
<29f> DW_AT_high_pc : 0x7
<2a3> DW_AT_call_file : 1
<2a4> DW_AT_call_line : 38
<2a5> DW_AT_call_column : 30
<3><2a6>: Abbrev Number: 12 (DW_TAG_formal_parameter)
<2a7> DW_AT_const_value : 2
<2a8> DW_AT_abstract_origin: <0x265>
...
while the source contains just two calls:
...
35 int
36 main (void)
37 {
38 if ((global && bar (1)) || bar (2))
39 return 0;
40 return 1;
41 }
...
This is a bug in the debug info.
I don't see a way to work around this in gdb, so work around this in the
test-case by bailing out if there are more or less than two breakpoint
locations for function bar.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33953
Andrew Burgess [Fri, 23 Jan 2026 16:34:01 +0000 (16:34 +0000)]
gdb/python: fix gdb.FinishBreakpoint returning to a tail call frame
I noticed that gdb.FinishBreakpoint doesn't work if the parent
function is a tail call function. In bpfinishpy_init we use
get_frame_pc to find the address at which the finish breakpoint should
be placed within the previous frame.
However, if the previous frame is a tail call frame, then get_frame_pc
will return an address outside of the tail call function, an address
which will not be reached on the return path.
Unlike other recent tail call fixes I've made, we cannot switch to
using something like get_frame_address_in_block here as in the tail
call case this will return an address within the function, but not an
address that will be executed when we return.
What we need to do in the tail call case is create the finish
breakpoint in the frame that called the tail call function. Or if
that frame is itself a tail call, then we should walk back up the call
stack until we find a non-tail call function.
This can be achieved by adding a call to skip_tailcall_frames into
bpfinishpy_init after our existing call to get_prev_frame.
I've extended the existing test case to cover this additional
situation.
Andrew Burgess [Fri, 23 Jan 2026 15:12:17 +0000 (15:12 +0000)]
gdb/python: don't allow FinishBreakpoints for inline frames
Creating a Python gdb.FinishBreakpoint for an inline frame doesn't
work.
If we look at the 'finish' command, in the finish_command
function (infcmd.c) then we see that GDB handles inline frames very
different to non-inline frames.
For non-inline frames GDB creates a temporary breakpoint and then
resumes the inferior until the breakpoint is hit.
But for inline frames, GDB steps forward until we have left the inline
frame.
When it comes to gdb.FinishBreakpoint we only have the "create a
temporary breakpoint" mechanism; that is, after all, what the
FinishBreakpoint is, it's a temporary breakpoint placed at the
return address in the caller.
Currently, when a FinishBreakpoint is created within an inline frame,
GDB ends up creating the breakpoint at the current $pc. As a result
the breakpoint will not be hit before the current function
exits (unless there's a loop going on, but that's not the point).
We could imagine what a solution to this problem would look like, GDB
would need to figure out the set of addresses for all possible exit
points from the inline function, and place a breakpoint at each of
these locations. I don't propose doing that in this commit.
Instead, I plan to update the docs to note that creating a
FinishBreakpoint within an inline frame is not allowed, and I will
catch this case within bpfinishpy_init (python/py-finishbreakpoint.c)
and throw an error.
Though the error is new, all I'm doing is raising an error for a case
that never worked.
Andrew Burgess [Fri, 23 Jan 2026 09:57:24 +0000 (09:57 +0000)]
gdb/python: fix FinishBreakpoint.return_value for tail call functions
The FinishBreakpoint.return_value attribute will not be populated
correctly for tail call functions.
In bpfinishpy_init (python/py-finishbreakpoint.c) we use the function
get_frame_pc_if_available to return an address, and then use this
address to lookup a function symbol.
The problem is that, for tail call functions, the address returned by
get_frame_pc_if_available can be outside the bounds of the function,
as a result GDB might find no function symbol at all, or might find
the wrong function symbol, if the tail call function is immediately
adjacent to the next function.
Fix this by using get_frame_address_in_block_if_available instead.
For tail call functions this will return an address within the bounds
of the function, which means that GDB should find the correct function
symbol, and from this the correct return type.
I've extended the existing FinishBreakpoint with tail call test case
to include printing the return value, this test fails without this
patch, but now works.
Are, I believe, currently all broken with respect to inline and tail
call functions.
The Python FinishBreakpoint type creates a breakpoint in the caller
function which, when triggered, indicates that the FinishBreakpoint
has gone out of scope.
I was writing a test for the FinishBreakpoint type which included a
tail call function, and the FinishBreakpoint was being created for the
tail call function frame. What I observed is that the out of scope
breakpoint was never being hit.
The call stack in my new test looked like this:
main -> tailcall_function -> normal_function
I would stop in normal_function, and then create a FinishBreakpoint
for the parent (tailcall_function) frame. The FinishBreakpoint's out
of scope breakpoint was being correctly placed in the 'main' function,
but would never trigger.
The problem is that the breakpoint placed in 'main' holds a frame-id.
This frame-id is the frame in which the breakpoint should trigger.
This frame-id exists to prevent premature stops due to recursion. But
in this case, when the breakpoint in 'main' was hit, despite no
recursion having occurred, the frame-id didn't match, and so the
breakpoint was ignored.
The problem is that in bpfinishpy_init we call frame_unwind_caller_id
to compute the frame-id of the frame in which we should stop, and
frame_unwind_caller_id was returning the wrong frame-id. As far as I
can tell frame_unwind_caller_id has been broken since it was updated
for inline functions in commit edb3359dff90ef8a.
The frame_unwind_caller_id function, and all the
frame_unwind_caller_WHAT functions, are intended to return the
previous frame, but should skip over any inline, or tail call frames.
Let's look at an example call stack:
#0 A // A normal function.
#1 B // An inline function.
#2 C // An inline function.
#3 D // A normal function.
#4 E // A normal function.
Starting from #0, a normal function, frame_unwind_caller_id, should
return the frame-id for #3, and this is what happens.
But if we start in #1 and call frame_unwind_caller_id, then we should
still return the frame-id for #3, but this is not what happens.
Instead we return the frame-id for #4, skipping a frame.
The problem is that frame_unwind_caller_id starts by calling
skip_artificial_frames, which calls get_prev_frame_always until we
reach a non-inline (or non-tail call) frame, this moves us from #1 to
Then, back in frame_unwind_caller_id we call get_prev_frame_always,
which moves us to #4.
Then frame_unwind_caller_id finishes with a call to
skip_artificial_frames, this could potentially result in additional
frames being skipped, but in my example above this isn't the case.
The problem here is that if skip_artificial_frames skips anything,
then we have already unwound to the caller frame, and the
get_prev_frame_always call in frame_unwind_caller_id is unnecessary.
I propose to add a new helper function frame_unwind_caller_frame,
which should do the correct thing; it unwinds one frame and then calls
skip_artificial_frames. This should do exactly what is needed.
Then all the frame_unwind_caller_WHAT functions will be updated to use
this helper function, and just extract the required property from the
resulting frame.
With this fix in place I could then write the FinishBreakpoint test,
which now works.
I took a look for other places where frame_unwind_caller_id is used
and spotted that the 'until' command does much the same thing, placing
a breakpoint in the caller frame. As predicted, the 'until' command
is also broken when used within a tail call frame. This patch fixes
that issue too. There's also a test for the until command.
The bug PR gdb/28683 seems to describe this exact problem with a
specific AArch64 case given. I haven't actually setup the environment
needed to test this bug, but I'm reasonably sure that this patch will
fix the bug. Even if it doesn't then it's certainly related and worth
linking into the bug report.
Tom de Vries [Thu, 5 Mar 2026 15:45:48 +0000 (16:45 +0100)]
[gdb/testsuite] Fix flake8 error in gdb.python/py-selected-context.py
We currently are running into a flake8 error:
...
$ pre-commit run --all-files flake8
flake8..................................................................Failed
- hook id: flake8
- exit code: 1
gdb/testsuite/gdb.python/py-selected-context.py:24:5: \
F824 `global event_throws_error` is unused: name is never assigned in scope
...
Fix this by dropping the unnecessary "global event_throws_error".
The 'x' command with the 'i' format specifier is for displaying
instructions. The "last address examined" convenience var, that is
'$_', is set to a single byte pointer by "x/i":
gdb: use builtin_func_ptr for `$_` set by "info breakpoints" and "info line"
The `$_` convenience var, as set by the "info breakpoints" and
"info line" commands, has the type builtin_data_ptr (i.e. `void *`).
However, both of the aforementioned commands deal with code addresses.
Hence, it makes more sense to use builtin_func_ptr (i.e.
`void (*)()`).
With this change:
(gdb) b main
Breakpoint 2 at 0x402547: file test.cpp, line 20.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000402547 in main(int, char**) at test.cpp:20
(gdb) p $_
$2 = (void (*)(void)) 0x402547 <main(int, char**)+39>
(gdb) ptype $_
type = void (*)(void)
(gdb) ptype &main
type = int (*)(int, char **)
(gdb) info line 22
Line 22 of "test.cpp" starts at address 0x40256d <main(int, char**)+77> and ends at 0x4025bd <main(int, char**)+157>.
(gdb) p $_
$3 = (void (*)(void)) 0x40256d <main(int, char**)+77>
(gdb) ptype $_
type = void (*)(void)
(gdb)
This also matches the type of PC:
(gdb) ptype $pc
type = void (*)(void)
Also add test cases to check that "info breakpoints" and "info line"
set the `$_` var.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
gdb: update doc for the $_ variable and search commands
I noticed that forward-search and reverse-search commands set the $_
convenience variable. This is mentioned in the help menu (see below)
but is not stated in the documentation. Add related text to the doc.
(gdb) help search
forward-search, fo, search
Search for regular expression (see regex(3)) from last line listed.
The matching line number is also stored as the value of "$_".
(gdb) help rev
reverse-search, rev
Search backward for regular expression (see regex(3)) from last line listed.
The matching line number is also stored as the value of "$_".
(gdb)
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
gdbserver: require_running_or_break for the 'z' and 'vCont' packets
Similar to several other packages that access/modify process state,
the 'z'/'Z' and 'vCont' packets need to access the process. Hence,
add a `require_running_or_break` as a pre-check.
Also add a test to check that gdbserver does not crash when certain
packets are received while there does not exist a process.
This commit adds a new method gdb.Symtab.source_lines. This method
can be used to read the lines from a symtab's source file. This is
similar to GDB's internal source_cache::get_source_lines function.
Currently using the Python API, if a user wants to display source
lines then they need to use Symtab.fullname() to get the source file
name, then open this file and parse out the lines themselves.
This isn't too much effort, but the problem is that these lines will
not be styled. The user could style the source content themselves,
but will this be styled exactly as GDB would style it?
The new Symtab.source_lines() method returns source lines with styling
included (as ANSI terminal escape sequences), assuming of course, that
styling is currently enabled.
Of course, in some cases, a user of the Python API might want source
code without styling. That's supported too, the new method has an
'unstyled' argument. If this is True then the output is forced to be
unstyled. The argument is named 'unstyled' rather than 'styled'
because the API call cannot force styling on. If 'set style enabled
off' is in effect then making the API call will never return styled
source lines.
The new API call allows for a range of lines to be requested if
desired.
As part of this commit I've updated the host_string_to_python_string
utility function to take a std::string_view.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Mon, 23 Feb 2026 10:22:55 +0000 (10:22 +0000)]
gdb: return optional from last_symtab_line, and use this more
I noticed that last_symtab_line is defined as returning an int, but if
the file associated with the symtab cannot be read then the function
returns false!
This commit updates last_symtab_line to return std::optional<int> and
replaces 'return false' with 'return {}'.
I then realised that last_symtab_line isn't actually used very often,
but we do use source_cache::get_line_charpos to perform the same job.
So I went through all uses of ::get_line_charpos and replaced them
with last_symtab_line where appropriate. I think this makes it
clearer what we're actually trying to do.
There should be no user visible changes after this commit.
Andrew Burgess [Sun, 22 Feb 2026 11:16:15 +0000 (11:16 +0000)]
gdb/python: new selected_context event
This commit introduces a new Python event, selected_context. This
event is attached to the user_selected_context_changed observer, which
triggers when the user changes the currently selected inferior,
thread, or frame.
Adding this event allows a Python extension to update in response to
user driven changes without having to poll the state from a
before_prompt hook, which is what I currently do to achieve the same
results.
I did consider splitting the user_selected_context_changed observer
into 3 separate Python events, inferior_changed, thread_changed, and
frame_changed, but I couldn't see any significant advantage to doing
this, so in the end I went with just a single event, and the event
object contains the inferior, thread, and frame.
Additionally, the user isn't informed about which aspect of the
context changed. That is, every event carries the inferior, thread,
and frame, so an event triggered when switching frames will looks
identical to an event triggered when switching inferiors. If the user
wants to know what changed then they will have to track the current
state themselves, and then compare the event state to the stored
current state. In many cases though I suspect that just being told
something changed, and then updating everything will be sufficient,
which is why I've not bothered trying to inform the user what changed.
Abhay Kandpal [Thu, 5 Mar 2026 04:07:53 +0000 (23:07 -0500)]
PowerPC: Fix dmxxshake128pad test case for big-endian targets
The encoding pattern for dmxxshake128pad in future.d was incorrect for
big-endian targets, causing the gas testsuite to fail with a regexp_diff
mismatch. The expected byte order did not match the objdump output on
big-endian systems.
Update the expected encoding to match the correct byte order.
Alan Modra [Wed, 4 Mar 2026 22:45:17 +0000 (09:15 +1030)]
Don't lose actual error in _bfd_generic_read_minisymbols
Setting bfd_error_no_symbols in the error return loses the underlying
reason why the function failed. Also fix a few places where functions
called by _bfd_generic_read_minisymbols didn't set bfd_error on failure.
Alan Modra [Wed, 4 Mar 2026 22:45:04 +0000 (09:15 +1030)]
gas: only free on exit when --enable-leak-check
Adds a new --enable-leak-check option, controlling whether memory is
freed before exit in order to find memory leaks. The default is to
free memory if BFD_ASAN is non-zero.
* configure.ac: Add new --enable-leak-check..
(ENABLE_LEAK_CHECK): ..defining this.
* as.c (gas_early_init): free_notes on exit only if ENABLE_LEAK_CHECK.
* expr.c (expr_end): Nothing to do when !ENABLE_LEAK_CHECK.
* macro.c (macro_end): Likewise.
* output-file.c (output_file_close): Don't stash frchain obstacks
when !ENABLE_LEAK_CHECK.
* read.c (read_end): Nothing to do when !ENABLE_LEAK_CHECK.
(poend): Likewise.
* stabs.c (stabs_end): Likewise.
* subsegs.c (subsegs_end): Likewise.
* symbols.c (symbol_end): Likewise.
* config/obj-elf-attr.c (oav1_attr_info_exit): Likewise.
* config/obj-elf.c (elf_end): Likewise.
* config/tc-arc.c (arc_md_end): Likewise.
* config/tc-i386.c (i386_md_end): Likewise.
* config/tc-loongarch.c (loongarch_md_end): Likewise.
* config/tc-ppc.c (ppc_md_end): Likewise.
* config/tc-pru.c (pru_md_end): Likewise.
* config/tc-riscv.c (riscv_md_end): Likewise.
* config/tc-tic54x.c (tic54x_md_end): Likewise.
* configure: Regenerate.
* config.in: Regenerate.
Unlike PyTuple_SET_ITEM(), PyTuple_SetItem() returns an integer: 0 on
success and -1 on error (e.g. IndexError). The existing code must therefore
be updated to handle this new behaviour.
Since processing now stops when PyTuple_SetItem() returns an error, some
resources (such as newly allocated tuples) must be properly deallocated in
error paths. To address this, this patch replaces the use of raw 'PyObject *'
pointers with gdbpy_ref<>, a reference-counted wrapper around 'PyObject *',
which automatically decrements the reference count on early exit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Kevin Buettner [Tue, 3 Mar 2026 02:25:23 +0000 (19:25 -0700)]
gdb/testsuite: Skip gdb.base/watchpoint-adjacent.exp on s390x
The watchpoint-adjacent.exp test requires both read and write hardware
watchpoints. s390x only supports write watchpoints, causing 108 test
failures when rwatch commands fail with "Target does not support this
type of hardware watchpoint."
Add a require for allow_hw_watchpoint_access_tests to skip this test on
architectures without read watchpoint support.
Kevin Buettner [Sun, 2 Nov 2025 04:29:26 +0000 (21:29 -0700)]
[gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x
This commit fixes six failures for s390x due to a fundamental
difference in unwinding behavior between s390x and other
architectures:
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 5:
backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 3:
backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 1:
backtrace when the unwind is broken at frame 1
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 5:
backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 3:
backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 1:
backtrace when the unwind is broken at frame 1
The core issue is that on s390x, the Canonical Frame Address (CFA) for
a function points *into the caller's stack frame*, whereas on x86_64
or aarch64 the CFA points *within the current function's frame*. This
architectural difference causes cycle detection to occur later on
s390x.
The patch resolves this by:
- Making expected backtrace output architecture-specific.
- For non-s390x targets: expecting the full set of frames up to the
specified level.
- For s390x: expecting fewer frames before detecting the cycle
(e.g., level 5 shows 3 frames instead of 5).
- Skipping the cycle at level 1 test entirely on s390x since it cannot
be detected at that frame.
Tested using recent Fedora releases on s390x, x86_64, and aarch64.
Abhay Kandpal [Tue, 3 Mar 2026 15:25:09 +0000 (10:25 -0500)]
gdb/testsuite: fix printf regexp for ppc64le with glibc ieee128 fix
On ppc64le, when the compiler selects IEEE-128 long double ABI
(-mabi=ieeelongdouble), calls to printf are redirected to
___ieee128_printf. This causes 'break printf' in GDB to never stop
at printf:
...
(gdb) break printf
Breakpoint 3 at 0x7ffff7a6b880
(gdb) continue
Continuing.
value is 7
glibc fixed this by adding local symbol aliases in the ieee128
compatibility files so that the original symbol names are present in
the symbol table again (glibc commit f05ab7c4a99b). After the glibc
fix, GDB stops at printf but the breakpoint is reported as
'Breakpoint 3.2, ___ieee128_printf' since printf now resolves to two
locations. The current GDB test regexps do not match this output.
Breakpoint 3.2, ___ieee128_printf (format=0x10000970 \"value is %d\n\")
at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:28
(gdb) FAIL: gdb.base/annota1.exp: continue to printf
...
This causes failures in gdb.base/annota1.exp and gdb.base/annota3.exp
because the pattern 'Breakpoint 3, ' does not match 'Breakpoint 3.2, '.
Fix this by changing 'Breakpoint 3, ' to 'Breakpoint 3.*, '.
In gdb.server/sysroot.exp the pattern '(__)?printf' does not match
'___ieee128_printf'.
Fix this by changing '(__)?printf' to '.*printf' to match any printf
variant including printf, __printf, and ___ieee128_printf,
following the same approach as previous fixes for __printf on x86_64
(commit f870f78fb2d) and printf@@GLIBC_2.17 on ppc64le (commit 29004660c94).
Tom de Vries [Tue, 3 Mar 2026 08:19:43 +0000 (09:19 +0100)]
[gdb/record] Fix syscall recording some more
I ran into the same gdb.reverse/sigall-reverse.exp failure on ppc64le-linux,
as fixed in commits:
- commit 3686645cec9 ("[gdb/record] Fix return value for svc in
aarch64_record_branch_except_sys"), and
- commit 4ef576bdb7f ("[gdb/record] Fix return value for syscall in
loongarch_record_syscall_insn").
The difference with those commits is that the problem is not due to confusion
about a port-local enums (aarch64_record_result, loongarch_record_result).
Instead, the port just treats return values 1 and -1 the same:
...
if (tdep->ppc_syscall_record (regcache) != 0)
return -1;
...
Fix this by passing through the return value 1 instead.
Matthieu Longo [Mon, 9 Feb 2026 17:49:09 +0000 (17:49 +0000)]
aarch64 gas: use bool return type for sub-option parsing
The signature of the functions used to decode sub-options mirrors that
of md_parse_option(). They currently return an integer, but the return
value is always set to 0 on failure and 1 on success, which exactly
matches boolean semantics.
These functions likely predate C99 as the minimum supported C standard
in binutils. Today, there is no good reason to keep this legacy interface
instead of using a proper boolean type.
This patch updates the sub-option parsing functions to return a boolean
and adjusts the corresponding code accordingly.
gdb/infrun: do not restart a stepped thread if not running
Suppose we have two inferiors on an all-stop target with schedule-multi
set on:
$ gdb -q
(gdb) target extended-remote | gdbserver --multi -
Remote debugging using | gdbserver --multi -
Remote debugging using stdio
(gdb) file /temp/test
Reading symbols from /temp/test...
(gdb) set remote exec-file /temp/test
(gdb) start
Temporary breakpoint 1 at 0x115c: file test.c, line 8.
Starting program: /temp/test
stdin/stdout redirected
Process /temp/test created; pid = 864027
...
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd218) at test.c:8
8 foo();
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote | gdbserver --multi -)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file /temp/test
Reading symbols from /temp/test...
(gdb) set remote exec-file /temp/test
(gdb) tbreak 2
Temporary breakpoint 2 at 0x555555555131: /temp/test.c:2. (2 locations)
(gdb) run
Starting program: /temp/test
stdin/stdout redirected
Process /temp/test created; pid = 864430
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) set schedule-multi on
(gdb)
At this point, detaching the first inferior works fine:
(gdb) detach inferiors 1
Detaching from program: /temp/test, process 858904
Detaching from process 858904
[Inferior 1 (process 858904) detached]
(gdb) info inferiors
Num Description Connection Executable
1 <null> 1 (extended-remote | gdbserver --multi -) /temp/test
* 2 process 858925 1 (extended-remote | gdbserver --multi -) /temp/test
(gdb)
Let us now repeat exactly the same scenario, but before detaching, we
make the current thread single-step an instruction:
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) stepi
3 int b = 43;
(gdb) detach inferiors 1
Detaching from program: /temp/test, process 876580
Detaching from process 876580
gdbserver: Couldn't reap LWP 876580 while detaching: No child processes
[Inferior 1 (process 876580) detached]
(gdb) [Switching to Thread 877351.877351]
3 int b = 43;
There is a mysterious line info output. Running the scenario with
infrun debug logs reveals more information.
...
Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
2 int a = 42;
(gdb) stepi
3 int b = 43;
(gdb) set debug infrun on
(gdb) detach inferiors 1
[infrun] scoped_disable_commit_resumed: reason=detaching
[infrun] scoped_disable_commit_resumed: reason=detaching
Detaching from program: /temp/test, process 3537498
Detaching from process 3537498
gdbserver: Couldn't reap LWP 3537498 while detaching: No child processes
[Inferior 1 (process 3537498) detached]
[infrun] reset: reason=detaching
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] restart_stepped_thread: switching back to stepped thread (stepping)
[infrun] keep_going_stepped_thread: resuming previously stepped thread
[infrun] keep_going_stepped_thread: expected thread advanced also (0x555555555131 -> 0x555555555138)
[infrun] clear_step_over_info: clearing step over info
[infrun] do_target_resume: resume_ptid=-1.0.0, step=0, sig=GDB_SIGNAL_0
[infrun] infrun_async: enable=1
[infrun] reset: reason=detaching
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
(gdb) [infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #0
[infrun] random_pending_event_thread: None found.
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 3537875.3537875.0 [Thread 3537875.3537875],
[infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] context_switch: Switching context from 0.0.0 to 3537875.3537875.0
[infrun] handle_signal_stop: stop_pc=0x555555555138
[infrun] handle_signal_stop: [3537875.3537875.0] hit its single-step breakpoint
[infrun] handle_signal_stop: delayed software breakpoint trap, ignoring
[infrun] process_event_stop_test: stepi/nexti
[infrun] stop_waiting: stop_waiting
[Switching to Thread 3537875.3537875]
3 }
[infrun] infrun_async: enable=0
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target extended-remote, no resumed threads
[infrun] fetch_inferior_event: exit
GDB attempted to do a step-over for the current thread. This takes us
to the commit that introduced restarting step-overs:
A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process, while threads are running. If we have more than one inferior
running, and we detach from just one of the inferiors, we expect that
the remaining inferior continues running. However, in all-stop, if
GDB needs to pause the target for the detach, nothing is re-resuming
the other inferiors after the detach. "info threads" shows the
threads as running, but they really aren't. This fixes it.
However, the thread that was resumed for step-over in our scenario did
not have an interrupted step-over; it had completed its stepi already.
More debugging reveals that the thread is resumed because of the
following two conditions in `restart_stepped_thread`:
if (tp->control.trap_expected)
{
infrun_debug_printf ("switching back to stepped thread (step-over)");
if (keep_going_stepped_thread (tp))
return true;
}
and
if (tp->control.step_range_end)
{
infrun_debug_printf ("switching back to stepped thread (stepping)");
if (keep_going_stepped_thread (tp))
return true;
}
The root cause of the problem is, `restart_stepped_thread` checks for
the thread state as
if (tp->state == THREAD_EXITED)
continue;
but the thread's state is THREAD_STOPPED. To fix, we change the state
check to
if (tp->state != THREAD_RUNNING)
Additionally, the 'trap_expected' and the 'step_range_end' fields of
the thread's control remain set even after the "stepi" command
completes, creating a half-baked internal state that can be misleading
when debugging. We address this problem by clearing the control
fields when stepping completes. We also add a regression test.
Regression-tested on X86_64 Linux using the default, native-gdbserver,
and native-extended-gdbserver board files.
Tested-By: Guinevere Larsen <guinevere@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Mon, 2 Mar 2026 03:26:06 +0000 (22:26 -0500)]
gdb/linux-tdep: pass string by reference
Sonarqube in me IDE pointed out this "const string" parameter that
should be a reference. I then looked at the callers, and saw that one
would pass `.c_str()`, causing an unnecessary copy, and the other using
std::move unnecessarily.
Tom Tromey [Wed, 25 Feb 2026 20:50:14 +0000 (13:50 -0700)]
Use enum types for remote fileio flags
This changes gdbsupport/fileio.h to use enums with underlying types
for the various constants -- open flags, modes, and lseek flags.
These types replace #defines that were previously used.
Then, this fixes all the users of these flags. This found a few bugs.
Some of these were pedantic (using the constant 0700 where perhaps
FILEIO_S_IRWXU would be more precise), but sparc64-tdep.c confused
host and remote flags.
Also, I believe solib-rocm.c had a couple of arguments in the wrong
order.
I also found that gdb/remote-fileio.c had essentially duplicated some
code from gdbsupport. This patch removes the duplicates.
New in v2:
- The lseek enum is anonymous, the type itself isn't used, just
the constants
Approved-By: Simon Marchi <simon.marchi@efficios.com>
AMD clang is going to start using DW_LANG_HIP instead of
DW_LANG_C_plus_plus_14 (see PR at
https://github.com/llvm/llvm-project/pull/181738). Rather than
falling back to the minimal language, this commit ensures that
GDB will still treat it like a C++ app. The commit also adds
a test to an existing one.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Idc7f18d154036ffceaa0a28032eabb19f110bb11
Tom Tromey [Tue, 24 Feb 2026 19:39:22 +0000 (12:39 -0700)]
Use the "O!" format more in the Python code
I noticed a few spots in the Python code that were decoding method
arguments and then immediately type-checking an argument. This can be
done more concisely using the "O!" format.
Tom Tromey [Fri, 27 Feb 2026 14:31:42 +0000 (07:31 -0700)]
Compute register name once in default_print_one_register_info
PR gdb/9884 points out that default_print_one_register_info could call
gdbarch_register_name a single time. The current code seems harmless
but OTOH the proposed change is also harmless and perhaps slightly
faster, so why not.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9884 Approved-By: Tom de Vries <tdevries@suse.de>
Bruce McCulloch [Thu, 5 Feb 2026 20:50:28 +0000 (12:50 -0800)]
libctf: remove CTF_F_ARRNELEMS flag
This patch removes the constraint that a CTF_F_ARRNELEMS flag has to be
present in order to reverse the elements of an array when dumping. The
flag was never added to GCC, and having this requirement causes more
problems than it solves. A quick recap of the issue:
Given an array int foo[1][2][3], the expected graph is:
int foo[1][2][3] -> int foo[2][3] -> int foo[3] -> int foo
Prior to GCC PR114186, the emitted graph would be:
int foo[1][2][3] -> int foo[1][2] -> int foo[1] -> int foo
Following GCC PR114186, before the libctf fix, the output was:
int foo[3][2][1] -> int foo[3][2] -> int foo[3] -> int foo
So the underlying type graph was correct, but the ordering of elements
was incorrect.
With this fix, we emit correct ordering of the type graph, with no
requirements for the compiler to signal that it has GCC PR114186.
libctf/
* ctf-decl.c (ctf_decl_push): Act as if CTF_F_ARRNELEMS is
always set.
* ctf-dump.c (ctf_dump_header): No longer dump its value.
* testsuite/libctf-lookup/multidim-array.c: No longer detect
compilers not emitting this flag (none do).
Nick Alcock [Mon, 3 Nov 2025 17:15:32 +0000 (17:15 +0000)]
libctf: allow ctf_arc_bufpreamble to fail
The recent libctf fix for ctf_arc_bufpreamble missed a case:
what if the input is exactly sizeof (ctf_archive_t) in size (which can
happen if the archive has no members at all, so returning the preamble
from one of the members is in any case impossible?). In this case
it'll return an off-the-end pointer, and its caller will overrun.
(This can also happen with fuzzed input which has a valid magic
number.)
Allow it to fail in this case, returning NULL, and adjust its sole
caller. The caller's conclusions in this case will be wrong (it will
conclude that the archive is connected to .symtab), but the incorrect
conclusions are harmless because the lack of archive members will
immediately cause a failure in ctf_arc_bufopen(), and an error return.
Thanks to Alan Modra for the original fix this soups up.
libctf/
PR libctf/33548
* ctf-archive.c (ctf_arc_bufpreamble): Fail if the archive is
too short (or empty, with no dicts to contain preambles),
returning NULL.
* ctf-open-bfd.c (ctf_bfdopen_ctfsect): Handle a NULL return.
projects / thirdparty / binutils-gdb.git / log
