Simon Marchi [Sat, 28 Feb 2026 03:51:56 +0000 (22:51 -0500)]
gdb: remove psymtab.{c,h}
The last user of psymtabs has been changed not to use them, remove them.
Update the tests minimally to avoid introducing failures (mostly due to
tests using the removed maintenance commands). There are still a lot of
references to partial symtabs in the comments or test names. There are
probably some tests that are just not relevant anymore. It would be quite
difficult to do this job all at once, we can clean this up little by
little.
Update the docs to remove references to partial symbols/symtabs.
Mention the removal of the maintenance commands in NEWS.
Change-Id: I58ae48c30e0303bcaa48298146d69fb8f059cb32 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 28 Feb 2026 03:51:55 +0000 (22:51 -0500)]
gdb/ctf: don't use psymtabs, create symtabs directly
The CTF debug info reader is the last user of partial symtabs. Being a
fairly limited debug info format, CTF only uses a fraction of the
psymtab features. So I see 3 ways forward:
- keep psymtabs but trim them down, removing everything not useful for
CTF
- make the CTF reader implement its own index-like structure that
implements the quick_symbol_functions interface (which would
presumably be a small subset of partial symtabs)
- make the CTF reader skip partial symtabs, create full symtabs
directly
My hypothesis is that CTF debug info is typically small enough and fast
enough to process that it's not worth it to bother with an intermediate
step before full symbols. But I will need help to see if this is true,
I'm not sure what representatively big C project I can build with CTF
debug info. I tried to build the Linux kernel with -gctf, but I got
plenty of warnings like:
ld: warning: orphan section `.ctf' from `vmlinux.o' being placed in section `.ctf'
GDB is still able to load the resulting ELF, and there are about 150k
calls to ctf_add_type_cb. Before this patch, elfctf_build_psymtabs
takes anywhere between 300-350 ms. With this patch, it's around 400 ms.
Implementation
--------------
This patch gets rid of the ctf_psymtab step, creating full symtabs from
the start.
The entry point elfctf_build_psymtabs gets renamed to
elfctf_build_symtabs.
Everything related to ctf_psymtab or partial symtabs is removed.
The build_ctf_archive_member function nows contains the code to build a
full symtab out of one CTF dict. This code is not new for the most
part, it has been moved from other functions that used to be called when
expanding one symtab.
Change-Id: I728c1ef35785218c178fb467b80db71d59269a6d Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 28 Feb 2026 03:51:54 +0000 (22:51 -0500)]
gdb: make expanded_symbols_functions hold compunit symtabs
Change the expanded_symbols_functions quick functions type to hold and
use a list of compunit symtab to search.
Currently, an expanded_symbols_functions instance will search all the
compunits in the objfile. This is not efficient if an
expanded_symbols_functions instance exists alongside another quick
functions object in an objfile, as the compunits belonging to that other
object will be unnecessarily searched.
And at worst, I think it could be a source of subtle bugs. For
instance, if the order of quick functions determine the order in which
we want the search to happen (the comment in elf_symfile_read suggests
this is the case), then having expanded_symbols_functions search the
compunits from other quick functions objects would not respect that
ordering.
Update the expanded_symbols_functions constructor to accept a vector of
compunits and store this vector in a field. Update
expanded_symbols_functions methods to use that vector instead of the
objfile's compunits.
Right now the sole user of expanded_symbols_functions is JIT. Update it
to keep a vector of compunits as they are finalized, and pass this
vector to the expanded_symbols_functions object.
Change-Id: Idf8de18b25fd3f71766166d6f420184af3c26b7e Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 28 Feb 2026 03:51:53 +0000 (22:51 -0500)]
gdb/ctf: add scoped_time_it in elfctf_build_psymtabs
This will be useful to determine the impact on the startup time getting
rid of partial symtabs has.
I use it like so:
$ ./gdb -q -nx --data-directory=data-directory -iex "maint set per-command time on" /home/simark/src/linux/vmlinux.unstripped -batch
...
Time for "elfctf_build_psymtabs": wall 0.381, user 0.357, sys 0.015, user+sys 0.372, 97.6 % CPU
Change-Id: I021319212f27eee0bf0f6c230f4e7cdd9c3602c1 Approved-By: Tom Tromey <tom@tromey.com>
This is because ctf_type_align returns -1 for some types, which is an
indication of an error. Update the code to check the return value of
ctf_type_align for errors, and emit complaints if it happens.
With this patch, if I enable the complaints, I see a bunch of messages
like this:
During symbol reading: ctf_type_align read_structure_type failed - Type is not a complete type.
Change-Id: Ibed23e7f1490d9163b8dde1318b9e45dec2906d6 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 28 Feb 2026 03:51:51 +0000 (22:51 -0500)]
gdb/ctf: use ctf_per_objfile in ctf_archive_iter_psymtab_data and ctf_context
This patch slightly reorganizes the data structures in ctfread.c to be a
bit more like in the DWARF reader. That is, instead of duplicating the
information (for instance, the objfile pointer), keep the information
once in the most general object where in make sense (in the
ctf_per_objfile in this case) and have the more specific objects (like
ctf_context, ctf_archive_iter_psymtab_data) have a link to the more
general object.
Concretely, that means removing the archive and parent_dict fields from
ctf_archive_iter_psymtab_data and ctf_context (those are per-objfile
information), adding backlink to the ctf_per_objfile and using the
parent_dict and archive fields there. Similarly, remove the objfile
fields from these and add a new objfile field in ctf_per_objfile.
Remove the objfile and dict parameters from the ctf_psymtab_add_stt_*
functions, since they can be obtained from the other parameters.
No functional changes expected.
Change-Id: I837264eece869f2bb962842998dede8cd7806bfe Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 28 Feb 2026 03:51:50 +0000 (22:51 -0500)]
gdb/ctf: editorial renames
Rename a few things to fit a bit more with how we typically name things,
or make the names more accurate. I think this makes the code easier to
follow for anyone familiar with the GDB codebase (or at least, familiar
with the DWARF reader). It's not super important, but it did help me
understand better the flow of the reader.
Simon Marchi [Sat, 28 Feb 2026 03:51:48 +0000 (22:51 -0500)]
gdb/ctf: add debug logging in ctfread.c
Add some debug statements, to be able to visualize what is happening
when loading CTF debug info. Add a new "set debug ctf" command, with
the usual logging macros.
Here's an example of the result, when reading the binary from test
gdb.ctf/cruss-tu-cyclic:
[ctf] elfctf_build_psymtabs: start: building psymtabs for /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic
[ctf] scan_partial_symbols: start: fname='.ctf'
[ctf] scan_partial_symbols: is parent, using fname='/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic'
[ctf] ctf_psymtab_type_cb: adding type tid=0x1 kind=INTEGER name='int'
[ctf] ctf_psymtab_type_cb: adding type tid=0x2 kind=INTEGER name='long int'
[ctf] ctf_psymtab_type_cb: adding type tid=0x3 kind=FORWARD name='B'
[ctf] ctf_psymtab_type_cb: adding type tid=0x5 kind=FORWARD name='A'
[ctf] ctf_psymtab_type_cb: adding type tid=0x8 kind=STRUCT name='C'
[ctf] ctf_psymtab_add_stt_entries: adding function psym 'main' tid=0x7 kind=FUNCTION
[ctf] scan_partial_symbols: end: fname='.ctf'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-1.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='B'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000002 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-1.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-2.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-2.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-3.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-3.c'
[ctf] scan_partial_symbols: start: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-4.c'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000001 kind=STRUCT name='A'
[ctf] ctf_psymtab_type_cb: adding type tid=0x80000002 kind=STRUCT name='B'
[ctf] scan_partial_symbols: end: fname='/home/simark/src/binutils-gdb/gdb/testsuite/gdb.ctf/cross-tu-cyclic-4.c'
[ctf] elfctf_build_psymtabs: end: building psymtabs for /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic
Change-Id: If3800d14dd965ccefa67a24ef5c4481aef70ffa4 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 2 Mar 2026 03:23:05 +0000 (22:23 -0500)]
gdb/corelow: mark bytes unavailable when reading from unavailable mapping
The main motivation for this change is to nicely support "lightweight"
core files on ROCm (more on this below), but I think that the change
also makes sense for regular core files.
When handling a file mappings from a core file, the core target
attempts to open the referenced file. If successful, the mappings from
this file end up in the m_core_file_mappings vector. Otherwise, they
end up in the m_core_unavailable_mappings vector.
When trying to read from an address within an unavailable mapping,
unless the executable target beneath is able to fulfill the request, the
core target returns an error (TARGET_XFER_E_IO). This is from
gdb.base/corefile.exp before the patch:
(gdb) PASS: gdb.base/corefile.exp: accessing mmapped data in core file with coremmap.data removed
x/8bd buf2ro
0x7f095a517000: Cannot access memory at address 0x7f095a517000
I think that this would be a good use case for the "unavailable" status.
We know the memory was there at runtime, it's just not available during
post-mortem debugging. That is the definition of "unavailable". After
changing core_target::xfer_partial to report the bytes as unavailable,
which this patch does, the same test now shows:
(gdb) PASS: gdb.base/corefile.exp: accessing mmapped data in core file with coremmap.data removed
x/8bd buf2ro
0x7f0250f52000: <unavailable> <unavailable> <unavailable> <unavailable> <unavailable> <unavailable> <unavailable> <unavailable>
I would say that the output of the x command isn't great, but that is
just a presentation issue.
The original motivation for me to do this change is that we are working
on lightweight GPU core dump support in ROCm. By default, the ROC
runtime will dump all the memory allocated in the context of the
crashing wave. This can result in absurdly big core dumps. With
lightweight core dumps, the runtime only dumps a certain subset of the
information that is considered essential. When trying to read a value
from a segment of memory that was not dumped, I believe that it is
natural to use the "unavailable" status. That is handled by this patch.
In the following example, `d` is a kernel parameter of type `int *`.
Its value was collected in the core dump, but the memory it points to,
allocated with hipMalloc, was not. Before:
(gdb) p data
$1 = (int *) 0x78bf26e00000
(gdb) p data[5]
❌️ Cannot access memory at address 0x78bf26e00014
After:
(gdb) p data
$1 = (int *) 0x78bf26e00000
(gdb) p data[5]
$2 = <unavailable>
Note that the same concept exists on Linux with the minicoredumper
project [1]. We could adjust the core target to act the same way when
dealing with minicoredumps.
[1] https://www.linutronix.de/minicoredumper/
Change-Id: I4df82ba4116e87545691facec0cb662c4b2b7797 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 27 Feb 2026 20:05:28 +0000 (15:05 -0500)]
gdb: better gdbarch init values
Change the initial values of the gdbarch structure fields to be
nullptr, false or 0, depending on their types (instead of just 0).
Define an `init_value()` method in the Value and Function classes to
provide the appropriate initial value for the component. Use it at a
few places in gdbarch.py.
Change-Id: I700ca49b08a062e4d745531620c4913a733ca3e8 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 27 Feb 2026 20:05:13 +0000 (15:05 -0500)]
gdb: change *_find_memory_regions to return bool
Change target_ops::find_memory_region, gdbarch_find_memory_regions and
associated helpers to return bool instead of int. This is a bit
confusing, because the logic is swapped. Previously, 0 meant "success,
carry on" and non-zero meant "failure, stop". Now, true means "success,
carry on" and false means "failure, stop".
The gcore_memory_sections already used that logic, so for that one it's
a simple int to bool conversion.
I build-tested this on Solaris, for the procfs.c changes, and on
FreeBSD, for the fbsd-nat.c changes. I haven't build-tested the other
native files.
Change-Id: I27ba892bb0dc949cdb4363275c8aded73ce338bc Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 27 Feb 2026 20:05:11 +0000 (15:05 -0500)]
gdb: change gdbarch_have_nonsteppable_watchpoint to bool
There is one unnecessary call to
set_gdbarch_have_nonsteppable_watchpoint that passes false (which is the
default), in arc-tdep.c, but I left it there because there is an
insightful comment and I didn't feel like deleting it.
Change-Id: Iccb9851c1cf28f48a075649b1dbc7c9388383df3 Approved-By: Tom Tromey <tom@tromey.com>
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.
projects / thirdparty / binutils-gdb.git / log
