Parse display gmon options only once so invalid arguments are not
reported twice and exit status is set to failure for invalid usage.
Also add tests in gp-gmon.exp to verify unknown options and missing
-o argument fail as expected and produce a single diagnostic.
gprofng/
* src/gp-gmon.cc (usage_and_exit): New function.
(check_mods): Change number of parameters.
(checkflagterm): Fix error text, update to use new functions.
* testsuite/gprofng.display/gp-gmon.exp: Add new test.
Kevin Buettner [Wed, 11 Mar 2026 00:14:10 +0000 (17:14 -0700)]
gdb/testsuite: Skip rwatch in watchpoint-unaligned.exp on s390x
The watchpoint-unaligned.exp test requires both read and write
hardware watchpoints. s390x only supports write watchpoints, causing
one test failure when the rwatch command fails with "Target does not
support this type of hardware watchpoint."
This commit causes the test using the rwatch command in this file to
be skipped when allow_hw_watchpoint_access_tests is false.
Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom de Vries <tdevries@suse.de>
Tom de Vries [Tue, 10 Mar 2026 20:44:01 +0000 (21:44 +0100)]
[gdb] Minor refactoring of is_dynamic_type_internal
Simplify is_dynamic_type_internal by:
- factoring out type->field (i) for the TYPE_CODE_STRUCT/UNION case.
- merging a loop iteration variable declaration into a for statement
Tom Tromey [Tue, 10 Mar 2026 18:00:43 +0000 (12:00 -0600)]
Remove note about C++ demangler from Rust documentation
A note about the C++ demangler in the Rust documentation hasn't been
accurate for a while. Also, it probably isn't clear to users how this
related to the next bit of text in the same bullet point. This patch
removes the obsolete comment.
Simon Marchi [Sat, 21 Feb 2026 20:07:34 +0000 (15:07 -0500)]
gdb/dwarf: use gdb::unordered_map for line headers
Change htab_t for gdb::unordered_map, more specifically the
unordered_section_and_offset_map specialization.
It is no longer necessary to keep the section and offset inside the
line_header structure itself, because it's just used for the map key, so
remove that.
I tried my best to preserve the logic in decode_line_header_for_cu, but
I don't fully understand it.
Change-Id: I512652e6da8b25db77ac9974135f9a06ce3d831e Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:33 +0000 (15:07 -0500)]
gdb/dwarf: use (section, offset-in-section) as key for line_header hash
Similar to the previous patch, use the (section, offset-in-section)
tuple as the key to uniquely identify a line table header. Currently,
line_header objects are hashed based on the (offset-in-section, is-dwz)
tuple.
This removes the last instances of "offset_in_dwz" parameters, which I
never really liked, as they were oddly specific. Specifying the section
does the same job in a more generic way.
Change-Id: Ia4666f68111ce2210dc58f716eff37cf913eeeb9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:32 +0000 (15:07 -0500)]
gdb/dwarf: use (section, offset) as stmt_list key
It occurred to me that we could use (section, offset-in-section) tuples
as the key for a line table, replacing stmt_list_hash, just like we use
(section, offset-in-section) as the sort key in the
dwarf2_per_bfd::all_units vector. This is functionally the same, the
goal is to uniquely identify a line table, but I think it's clearer this
way. The tuple (section, offset-in-section) precisely and unambiguously
specifies a spot in an object file.
This allows deleting some specialized code, and eventually share code
with other places that would want to use section_and_offset as a key.
Change-Id: I1b45c7f653d71656b964c3f3789d8bb459774340 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:31 +0000 (15:07 -0500)]
gdb/dwarf: store dwarf2_cus in expansion queue
The CU expansion queue currently holds dwarf2_per_cu items (see
dwarf2_queue_item). But there is this invariant that if a per_cu is
queued for expansion, then its DIEs are loaded in memory and a matching
dwarf2_cu object exists in dwarf2_per_objfile.
When a caller calls maybe_queue_comp_unit, a return value of `true`
indicates "the per_cu was enqueued, but its DIEs are not currently
loaded (a dwarf2_cu does not exist for it yet), so you must do it". The
caller is then responsible for calling some function to make it happen
and ensure the invariant is respected.
This feels backwards to me, I think it would be simpler if it was the
other way around. The queue should hold dwarf2_cu objects directly. To
enqueue a CU for expansion, a caller would therefore have to make sure
that a dwarf2_cu exists in the first place (i.e. that the unit's DIEs
are loaded), to pass it to queue_comp_unit. Often, the caller wants to
use the dwarf2_cu anyway, so it's not lost.
- Change dwarf2_queue_item to hold dwarf2_cu pointers. No need to have
a dwarf2_per_objfile anymore, since a dwarf2_cu provides it.
- Change queue_comp_unit and maybe_queue_comp_unit to take a dwarf2_cu.
- Change the order of operation in the spots that call
maybe_queue_comp_unit. Make sure the target unit is loaded first, by
calling one of the new ensure_loaded_* functions. Then, if the
return value is not nullptr (which happens if the unit is dummy),
then call maybe_queue_comp_unit.
- process_queue does not need to deal with possible dummy units, since
that is now filtered earlier. It is not possible to have a dwarf2_cu
for a dummy unit.
- Move the queued flag from dwarf2_per_cu to dwarf2_cu.
- Remove this assert from fill_in_sig_entry_from_dwo_entry, since the
queued flag is not longer in dwarf2_per_cu:
gdb_assert (! sig_entry->queued);
I think that the assert just below does the same job:
Simon Marchi [Sat, 21 Feb 2026 20:07:30 +0000 (15:07 -0500)]
gdb/dwarf: inline queue_and_load_dwo_tu
I noticed that queue_and_load_dwo_tu unnecessarily returned an integer
value, so I started by removing that. Then, I thought that it didn't
really need to be a separate function anymore, it would be clear enough
if the code was inlined into queue_and_load_all_dwo_tus.
Change-Id: Ibc5a83e87a10e6c0bf67ca955fcabbc90d9ac2ef Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:29 +0000 (15:07 -0500)]
gdb/dwarf: return dwarf2_cu from load_full_{comp,type}_unit
Make load_full_{comp,type}_unit return a non-owning reference to the
created dwarf2_cu. The functions still install the dwarf2_cu in
dwarf2_per_objfile::m_dwarf2_cus with dwarf2_per_objfile::set_cu.
Make dwarf2_per_objfile::set_cu return a non-owning reference as well,
for convenience. This makes things easier to follow, and reduces the
number of calls of unnecessary dwarf2_per_objfile::get_cu calls (i.e.
map lookups).
Change-Id: I51ed32585521cad0b89a4ca398915d7e0c1141e1 Approved-By: Tom Tromey <tom@tromey.com>
The first one is unnecessary, since the same assert is in
read_signatured_type.
The second one might be wrong, since read_signatured_type could in
theory not set the cu, if it is dummy.
Remove the existing load_full_type_unit and rename read_signatured_type
to load_full_type_unit. I prefer the latter name, for the parallel with
load_full_comp_unit, but also because I think it's clearer.
read_signatured_type makes it sound like it will read the type and build
the symbols, which is not the case. It only loads the DIEs in memory.
Change-Id: Ia411ccdaeae091298986b18e26d5583b896b2aa5 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:27 +0000 (15:07 -0500)]
gdb/dwarf: remove unnecessary compunit_symtab_set_p check in process_queue
We know that enqueued per_cu objects never have a matching
compunit_symtab object set.
The two places where per_cus are enqueued are:
- maybe_queue_comp_unit, which has its own compunit_symtab_set_p check
- dw2_do_instantiate_symtab, which is only called if per_cu does not
have a compunit_symtab yet
process_queue therefore does not need to consider the possibility of
the compunit_symtab being set already.
Change-Id: Id8565d7f659813047ee15603598f9abd39993adc Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:26 +0000 (15:07 -0500)]
gdb/dwarf: remove unnecessary compunit_symtab_set_p check in dw2_do_instantiate_symtab
dw2_do_instantiate_symtab is called by dw2_instantiate_symtab, only if
per_cu does not have a matching compunit_symtab yet.
dw2_do_instantiate_symtab therefore does not need this
compunit_symtab_set_p itself.
Change-Id: Ie665980bb65016b56206c4aac36f4c2fc13c61de Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:25 +0000 (15:07 -0500)]
gdb/dwarf: remove just_read_cus from dwarf2_per_bfd
It is not necessary to keep the just_read_cus vector inside
dwarf2_per_bfd. This vector is only needed shortly, while we process
the CU expansion queue.
Instead of appending expanded comp units in process_full_comp_unit,
instantiate a local vector in process_queue, populate it with the
expanded comp units, and call process_cu_includes from there.
Remove the `if (!iter->is_debug_types ())` check in process_cu_includes:
we know that we only append comp units to this vector, no type units.
In compute_compunit_symtab_includes, remove the `if (cust == NULL)`
check: in process_queue, we only append the per_cus for which a
compunit_symtab was indeed created, no need to check it again here.
Change-Id: Ia50b703f379ae9dc90c9abc1d5269d4932f16e2d Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:24 +0000 (15:07 -0500)]
gdb/dwarf: make process_full_{comp,type}_unit return a compunit_symtab
This change makes it so that there is a single point in the code where
compunit symtabs are set (where dwarf2_per_objfile::set_compunit_symtab
is called), which I think helps understand how things work.
Change-Id: Ie84aa5141ebe1e2c7a990f59a62d95401a4b3e4a Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 21 Feb 2026 20:07:23 +0000 (15:07 -0500)]
gdb/dwarf: make dw2_search_one a method of dwarf2_base_index_functions
This function is used as a helper for readnow_functions::search and
cooked_index_functions::search. Just to better organize things, make it
a protected static method in the base class,
dwarf2_base_index_functions.
Change-Id: I0273c92379bf2337df16d28e21586125716e7de6 Approved-By: Tom Tromey <tom@tromey.com>
Python extension objects that support __dict__ must inherit from
gdbpy_dict_wrapper, a wrapper class that stores the PyObject
corresponding to the __dict__ attribute.
Currently, management of this dictionary is not centralized, and
each Python extension object implements its own logic to create,
access, and destroy it.
This patch focuses on the allocation of the dictionary, introduces
a new method, gdbpy_dict_wrapper::allocate_dict(), and
adapts the existing code to use this method.
Matthieu Longo [Thu, 26 Feb 2026 16:08:27 +0000 (16:08 +0000)]
gdb/python: flatten functions calling PyObject_New and use gdbpy_ref
This patch aims at systematically using gdbpy_ref<> at all call sites
of PyObject_New(). This prepares for future patches that expect
gdbby_ref<> parameters and affect return handling.
As part of this change, flattening the affected functions so that the
return logic becomes clearer and more flexible to adjust.
Matthieu Longo [Thu, 26 Feb 2026 17:20:20 +0000 (17:20 +0000)]
gdb/python: allow ref_ptr<T, Policy>::new_reference to accept subclasses of T
When ref_ptr<T,Policy>::new_reference() is specialized for 'PyObject'
(i.e. gdbpy_ref<>), it currently requires the argument type to be exactly
'PyObject *'. As a result, pointers to subclasses of 'PyObject' must be
explicitly cast before being passed, making call sites unnecessarily
verbose.
This patch makes ref_ptr<T,Policy>::new_reference() a template method
that accepts both T and subclasses of T, performing the cast to 'T *'
internally when needed. This removes redundant casts at call sites
without changing behavior.
Matthieu Longo [Fri, 20 Feb 2026 10:45:27 +0000 (10:45 +0000)]
gdb: introduce rgb_color type to simplify existing code
This patch replaces the raw uint8[3] buffer used to represent RGB values
with a more convenient wrapper, rgb_color, around std::array<uint8_t, 3>.
It also changes the return type of ui_file_style::color::get_rgb to
rgb_color instead of filling a caller-provided buffer, and updates all
callers accordingly.
This expected benefit of this change consists in:
- removing the manual size handling.
- proving accessors without using hard-coded indexes.
- making the API safer.
- simplifying call sites.
This refactoring does not introduce any functional change.
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:
projects / thirdparty / binutils-gdb.git / log
