Simon Marchi [Mon, 17 Nov 2025 21:48:25 +0000 (16:48 -0500)]
gdb, gdbserver: propagate use of target_desc unique pointers
Propagate the use of target_desc unique pointers further. Basically,
avoid releasing target_desc objects, except in some spots in gdbserver
(e.g. netbsd) where we don't currently have a persistent container for
created target descriptions (and the target desc just leaks). Introduce
const_target_desc_up to change some `const target_desc *` to a unique
pointer without loss of constness.
Architectures that use the old regformats/regdat.sh don't need to be
changed, because their target_desc objects are statically allocated in
the generated files.
I was able to built-test these native configs:
- Linux AArch64
- Linux ARC
- Linux AMD64
- Linux ARM
- Linux LoongArch
- Linux M68K
- Linux Microblaze
- Linux MIPS (32 and 64)
- Linux or1k
- Linux PPC (32 and 64)
- Linux RISC-V
- Linux s390x
- Linux SH4
- Linux Sparc (32 and 64)
- Linux Xtensa
- FreeBSD AMD64
- NetBSD AMD64
- Windows i686
- Windows AMD64
For the rest, I did my best by staring at the code long enough. I
probably missed or messed some spots, but that shouldn't be difficult to
fix.
Simon Marchi [Mon, 1 Dec 2025 21:19:07 +0000 (16:19 -0500)]
gdbserver: remove leftovers from tic6x target_desc selftests
Commit 9a5d3e6c4a50 ("gdb: remove tic6x .dat files") removed the .dat
files that were used solely for selftests in linux-tic6x-low.cc.
However, I forgot to remove the things that depended on that in
linux-tic6x-low.cc (or rather, I put them in the wrong patch). As-is,
linux-tic6x-low.cc will certainly no build, because function
selftests::tdesc::tic6x_tdesc_test is not defined anywere. Remove those
remaining bits.
Tom Tromey [Fri, 14 Nov 2025 20:44:22 +0000 (13:44 -0700)]
Rename some locals in objc_msgcall_operation::evaluate
This renames a couple of local variables in
objc_msgcall_operation::evaluate, in preparation for the next patch.
This is done separately because the next patch is pretty messy and
this makes it a little simpler.
Tom Tromey [Fri, 14 Nov 2025 20:42:11 +0000 (13:42 -0700)]
Use a vector in objc_msgcall_operation::evaluate
This changes objc_msgcall_operation::evaluate to use a std::vector
rather than XALLOCAVEC. alloca is bad and should generally be
avoided; and anyway there's no justification for it here.
Tom Tromey [Fri, 14 Nov 2025 20:40:22 +0000 (13:40 -0700)]
Fix crash from eval_op_objc_msgcall
Trying to evaluate an Objective-C message call will cause gdb to
crash. This happens because this code was not correctly updated when
call_function_by_hand was changed to accept an array_view, and the
trailing NULL pointer was no longer required.
GNAT recently added support for asynchronous aborts of tasks blocked in
calls to Ada.Synchronous_Task_Control.Suspend_Until_True. That GNAT
change added a new value to the Task_States enumerated type. This patch
adds the corresponding value to task_states.
Simon Marchi [Fri, 21 Nov 2025 20:14:05 +0000 (15:14 -0500)]
gdb/dwarf: clarify meaning dwarf2_per_cu::{m_section,m_sect_off,m_length} in presence of DWO file
The comments above these fields are almost accurate. If a unit in a DWO
file has a corresponding skeleton in the main file, these fields
describe the skeleton in the main file. However, it's missing the
detail that if the unit in the DWO file does not have a corresponding
skeleton in the main file, then the fields describe the unit in the DWO
file. Update the comments to reflect that.
Change-Id: I0681bc0d884f7e373b227416cbdef307d462ae71 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 21 Nov 2025 20:14:03 +0000 (15:14 -0500)]
gdb/dwarf: store addr/offset/ref_addr sizes in dwarf2_per_cu
New in v2:
- make the test try with indexes by default
- using uint8_t instead of unsigned char
In some specific circumstances, it is possible for GDB to read a type
unit from a .dwo file without ever reading in the section of the stub in
the main file. In that case, calling any of these methods:
will cause a crash, because they will try to read the unit header from
the not-read-in section buffer. See the previous patch for more
details.
The remaining calls to these methods are in the loc.c and expr.c
files. That is, in the location and expression machinery. It is
possible to set things up to cause them to trigger a crash, as shown by
the new test, when running it with the cc-with-gdb-index board:
$ make check TESTS="gdb.dwarf2/fission-type-unit-locexpr.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-type-unit-locexpr.exp ...
ERROR: GDB process no longer exists
The backtrace at the moment of the crash is:
#0 0x0000555566968b1f in bfd_getl32 (p=0x78) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846
#1 0x00005555642e51b7 in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x78 <error: Cannot access memory at address 0x78>, bytes_read=0x7bfff09daca0, handle_nonstd=true)
at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92
#2 0x00005555647ca584 in read_unit_head (header=0x7d0ff1e06c70, info_ptr=0x78 <error: Cannot access memory at address 0x78>, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE)
at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44
#3 0x000055556452df18 in dwarf2_per_cu::get_header (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531
#4 0x000055556452e10e in dwarf2_per_cu::addr_size (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544
#5 0x0000555564314ac3 in dwarf2_locexpr_baton_eval (dlbaton=0x7bfff0c9a508, frame=..., addr_stack=0x7bfff0b59150, valp=0x7bfff0c9a430, push_values=..., is_reference=0x7bfff0d33030)
at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1593
#6 0x0000555564315bd2 in dwarf2_evaluate_property (prop=0x7bfff0c9a450, initial_frame=..., addr_stack=0x7bfff0b59150, value=0x7bfff0c9a430, push_values=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1668
#7 0x0000555564a14ee1 in resolve_dynamic_field (field=..., addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2758
#8 0x0000555564a15e24 in resolve_dynamic_struct (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2839
#9 0x0000555564a17061 in resolve_dynamic_type_internal (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=..., top_level=true) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2972
#10 0x0000555564a17899 in resolve_dynamic_type (type=0x7e0ff1f02550, valaddr=..., addr=0x4010, in_frame=0x7bfff0d32e60) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:3019
#11 0x000055556675fb34 in value_from_contents_and_address (type=0x7e0ff1f02550, valaddr=0x0, address=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/value.c:3674
#12 0x00005555666ce911 in get_value_at (type=0x7e0ff1f02550, addr=0x4010, frame=..., lazy=1) at /home/simark/src/binutils-gdb/gdb/valops.c:992
#13 0x00005555666ceb89 in value_at_lazy (type=0x7e0ff1f02550, addr=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/valops.c:1039
#14 0x000055556491909f in language_defn::read_var_value (this=0x5555725fce40 <minimal_language_defn>, var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame_param=...)
at /home/simark/src/binutils-gdb/gdb/findvar.c:504
#15 0x000055556491961b in read_var_value (var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame=...) at /home/simark/src/binutils-gdb/gdb/findvar.c:518
#16 0x00005555666d1861 in value_of_variable (var=0x7e0ff1f02500, b=0x7e0ff1f025d0) at /home/simark/src/binutils-gdb/gdb/valops.c:1384
#17 0x00005555647f7099 in evaluate_var_value (noside=EVAL_NORMAL, blk=0x7e0ff1f025d0, var=0x7e0ff1f02500) at /home/simark/src/binutils-gdb/gdb/eval.c:533
#18 0x00005555647f740c in expr::var_value_operation::evaluate (this=0x7c2ff1e3b690, expect_type=0x0, exp=0x7c2ff1e3aa00, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:559
#19 0x00005555647f3347 in expression::evaluate (this=0x7c2ff1e3aa00, expect_type=0x0, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:109
#20 0x000055556543ac2f in process_print_command_args (args=0x7fffffffe728 "global_var", print_opts=0x7bfff0be4a30, voidprint=true) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1328
#21 0x000055556543ae65 in print_command_1 (args=0x7fffffffe728 "global_var", voidprint=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1341
#22 0x000055556543b707 in print_command (exp=0x7fffffffe728 "global_var", from_tty=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1408
The problem to solve is: in order to evaluate a location expression, we
need to know some information (the various sizes) found in the unit
header. In that context, it's not possible to get it from
dwarf2_cu::header, like the previous patch did: at the time the
expression is evaluated, the corresponding dwarf2_cu might have been
freed. We don't want to re-build a dwarf2_cu just for that, it would be
very inefficient. We could force reading in the dwarf2_per_cu::section
section (in the main file), but we never needed to read that section
before, so it would be better to avoid reading it unnecessarily.
My initial attempt was to store this information in baton objects
(dwarf2_locexpr_baton & co), so that it can be retrieved when the time
comes to evaluate the expressions. However, it quickly became obvious
that storing it there would be redundant and wasteful.
I instead opted to store this information directly inside dwarf2_per_cu,
making it easily available when evaluating expressions. These fields
initially have the value 0, and are set by cutu_reader whenever the
unit is parsed. The various getters (dwarf2_per_cu::addr_size & al) now
just return these fields.
Doing so allows removing anything related to reading the header from
dwarf2_per_cu, which I think is a nice simplification. This means that
nothing ever needs to read the header from just a dwarf2_per_cu.
It also happens to shrink the dwarf2_per_cu object size a bit, going
from:
(top-gdb) p sizeof(dwarf2_per_cu)
$1 = 176
to
(top-gdb) p sizeof(dwarf2_per_cu)
$1 = 120
I placed the new fields at this strange location in dwarf2_per_cu
because there happened to be a nice 3 bytes hole there (on Linux amd64
at least).
The new test set things up as described previously. Note that the crash
only occurs if using the cc-with-gdb-index board.
Change-Id: I50807a1bbb605f0f92606a9e61c026e3376a4fcf Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Fri, 21 Nov 2025 20:14:02 +0000 (15:14 -0500)]
gdb/dwarf: when in dwarf2_cu, read addr_size from dwarf2_cu::header
New in v2: make the test try with indexes by default
This patch fixes a crash caused by GDB trying to read from a section not
read in. The bug happens in those specific circumstances:
- reading a type unit from .dwo
- that type unit has a stub in the main file
- there is a GDB index (.gdb_index) present
This crash is the cause of the following test failure, with the
cc-with-gdb-index target board:
$ make check TESTS="gdb.dwarf2/fission-reread.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index"
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-reread.exp ...
ERROR: GDB process no longer exists
For this last one, you need to interrupt the test (e.g. add a return)
before the test deletes the .dwo file.
The backtrace at the moment of the crash is:
#0 0x0000555566968f7f in bfd_getl32 (p=0x0) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846
#1 0x00005555642e561d in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x0, bytes_read=0x7bfff0962fa0, handle_nonstd=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92
#2 0x00005555647ca9ea in read_unit_head (header=0x7d0ff1e068b0, info_ptr=0x0, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE) at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44
#3 0x000055556452e37e in dwarf2_per_cu::get_header (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531
#4 0x000055556452e574 in dwarf2_per_cu::addr_size (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544
#5 0x000055556406af91 in dwarf2_cu::addr_type (this=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/cu.c:124
#6 0x0000555564534e48 in set_die_type (die=0x7e0ff1f23dd0, type=0x7e0ff1f027f0, cu=0x7d7ff1e20880, skip_data_location=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19020
#7 0x00005555644dcc7b in read_structure_type (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11239
#8 0x000055556451c834 in read_type_die_1 (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16878
#9 0x000055556451c5e0 in read_type_die (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16861
#10 0x0000555564526f3a in get_signatured_type (die=0x7e0ff1f0ffb0, signature=10386129560629316377, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:17998
#11 0x000055556451c23b in lookup_die_type (die=0x7e0ff1f0ffb0, attr=0x7e0ff1f10008, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16808
#12 0x000055556451b2e9 in die_type (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16684
#13 0x000055556451457f in new_symbol (die=0x7e0ff1f0ffb0, type=0x0, cu=0x7d7ff1e0f480, space=0x0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16089
#14 0x00005555644c52a4 in read_variable (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9119
#15 0x0000555564494072 in process_die (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5197
#16 0x000055556449c88e in read_file_scope (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6125
#17 0x0000555564493671 in process_die (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5098
#18 0x00005555644912f5 in process_full_comp_unit (cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4851
#19 0x0000555564485e18 in process_queue (per_objfile=0x7d6ff1e71100) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4161
#20 0x000055556446391d in dw2_do_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1650
#21 0x0000555564463b3c in dw2_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1671
#22 0x00005555644687fd in dwarf2_base_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1990
#23 0x0000555564381050 in cooked_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index.h:237
#24 0x0000555565df5b0d in objfile::expand_all_symtabs (this=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/symfile-debug.c:372
#25 0x0000555565eafc4a in maintenance_expand_symtabs (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/symmisc.c:914
The main file contains a stub (skeleton) for a compilation unit and a
stub for a type unit. The .dwo file contains a compilation unit and a
type unit matching those stubs. When doing the initial scan of the main
file, the DWARF reader parses the CU/TU list from the GDB index
(.gdb_index), and thus creates a signatured_type object based on that.
The section field of this signatured_type points to the .debug_types
section in the main file, the one containing the stub. And because GDB
trusts the GDB index, it never needs to look at that .debug_types
section in the main file. That section remains not read in.
When expanding the compilation unit, GDB encounters a type unit
reference (by signature) corresponding to the type in the type unit. We
get in lookup_dwo_signatured_type, trying to see if there is a type unit
matching that signature in the current .dwo file. We proceed to read
and expand that type unit, until we eventually get to a
dwarf2_cu::addr_type() call, which does:
int addr_size = this->per_cu->addr_size ();
dwarf2_per_cu::addr_size() tries to read the header from the section
pointed to by dwarf2_per_cu::section which, if you recall, is the
.debug_types section in the main file that was never read in. That
causes the segfault.
All this was working fine before these patches of mine, that tried to do
some cleanups:
a47e2297fc28 ("gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor") c44ab627b021 ("gdb/dwarf: pass section to dwarf2_per_cu_data constructor") 39ee8c928551 ("gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor")
Before these patches, the fill_in_sig_entry_from_dwo_entry function
(called from lookup_dwo_signatured_type, among others) would overwrite
some dwarf2_per_cu fields (including the section) to point to the .dwo,
rather than represent what's in the main file. Therefore, the header
would have been read from the unit in the .dwo file, and things would
have been fine.
When doing these changes, I mistakenly assumed that the section written
by fill_in_sig_entry_from_dwo_entry was the same as the section already
there, which is why I removed the statements overwriting the section
field (and the two others). To my defense, here's the comment on
dwarf2_per_cu::section:
/* The section this CU/TU lives in.
If the DIE refers to a DWO file, this is always the original die,
not the DWO file. */
struct dwarf2_section_info *section = nullptr;
I would prefer to not reintroduce the behavior of overwriting the
section info in dwarf2_per_cu, because:
1. I find it confusing, I like the invariant of dwarf2_per_cu::section
points to the stub, and dwarf2_cu::section points to where we
actually read the debug info from.
2. The dwarf2_per_bfd::all_units vector is nowadays sorted by (section,
section offset). If we change the section and section offset of a
dwarf2_per_cu, then we can no longer do binary searches in it, we
would have to re-sort the vector (not a big deal, but still adds to
the confusion).
One possible fix would be to make sure that the section is read in when
reading the header, probably in dwarf2_per_cu::get_header. An approach
like that was proposed by Andrew initially, here:
It would work, but there is a more straightforward fix for this
particular problem, I believe. In dwarf2_cu, we have access to the
header read from the unit we're actually reading the DWARF from. In the
DWO case, that is the header read from the .dwo file. We can get the
address size from there instead of going through the dwarf2_per_cu
object. This is what this patch does.
However, there are other case where we get the address (or offset) size
from the dwarf2_per_cu in the DWARF expression evaluator (expr.c,
loc.c), that could cause a similar crash. The next patch handles these
cases.
Modify the gdb.dwarf2/fission-reread.exp test so that it tries running
with an index even with the standard board (that part was originally
written by Andrew).
Finally, just to put things in context, having a stub in the main file
for a type unit is obsolete. It happened in the gcc 4.x days, until
this commit:
Simon Marchi [Fri, 21 Nov 2025 20:14:01 +0000 (15:14 -0500)]
gdb/testsuite/dwarf: emit type unit sections as COMDAT
In an effort to generate ELF files and DWARF info as close as possible
as an actual compiler would generate, change how we emit type unit
sections to emit each type unit in its own section, in COMDAT section
groups.
We currently emit all type units in a single, standard section (either
.debug_info or .debug_types, depending on the DWARF version). Compilers
emit each type unit in its own .debug_types section. Each section is
placed in a COMDAT section group with a signature based on the type
unit's signature. This lets the linker deduplicate identical type units
by discarding section groups with identical signatures (keeping only one
group with a given signature).
Looking at a .s file generated by gcc, we can see that this is how it
specifies the section for a type unit:
The "G" flag tells the assembler to place the section in a section
group with signature "wi.006fd2152a3054a6". That string was generated
from the type unit, signature. Finally, the comdat linkage field
indicates that the section group should have the COMDAT flag.
Update the tu proc to emit a section with these properties. In this
case, it's mandatory to specify the type of the section (progbits).
Update the _section proc to accept the new options "group_signature" and
"linkage".
As a result, if you look at the .debug_types section in a .o file from
gcc:
COMDAT group section [ 2] `.group' [sig.0x0000000000000002] contains 2 sections:
[Index] Name
[ 12] .debug_types
[ 13] .rela.debug_types
In both cases, in the fully linked files, there is a single .debug_types section
containing the two type units, as expected.
Before this patch, when I run gdb.dwarf2/fission-with-type-unit.exp, the
resulting .dwo file has a single .debug_info.dwo. After this patch it
has two: one with the type unit and one with the compile unit (the test
uses DWARF 5). Based on what I see gcc generate when using "-gdwarf-5
-gsplit-dwarf -fdebug-types-section", this is what we expect.
Change-Id: Ie1954dc697fe100b5dbe664d148c71fa02888d96 Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Fri, 21 Nov 2025 20:13:59 +0000 (15:13 -0500)]
gdb/testsuite/dwarf: use single abbrev table in .dwo files
When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use
build_executable_and_dwo_files, because it wouldn't work to have
multiple units in the .dwo file, each referring to their own abbrev
table using labels. build_executable_and_dwo_files extracts the .dwo
file content from the .o using objcopy (just like gcc does, I learned),
meaning that the .dwo file never runs through a linker. Anything
needing relocation (like labels pointing to abbrev tables) doesn't work.
I instead opted to use gdb_compile_shlib to build the .dwo file on its
own, so that those labels would get resolved. That causes problems now
that I'm trying to write a test with multiple type units in a .dwo file,
where each type unit should be in its own .debug_types section. Running
the .dwo file through the linker causes all the .debug_types section to
be collapsed into one. And generally, I think it was a bad idea to
generate a .dwo file using the linker, since the idea behind .dwo files
is that they do not need to be linked (therefore improving link
times). We want to produce files as close to what an actual compiler
would produce.
This patch fixes this by doing what compilers do in the same situation:
use a single abbrev table shared by all units in the .dwo file. This
requires the following changes in lib/dwarf.exp:
- Declare a new variable _dwo_abbrev_num, which holds the next
abbrev number to use in the .dwo file's abbrev section
(.debug_abbrev.dwo). Initialize this variable to 1.
- When producing a CU or TU in a .dwo file, use 0 as the abbrev table
offset.
- When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num,
depending on whether the current CU is in a .dwo file.
- After producing a CU or TU in a .dwo file, don't append the
terminator byte.
- After finishing producing the CUs and TUs, append the terminator byte
in .debug_abbrev.dwo if we did output anything there.
Update gdb.dwarf2/fission-with-type-unit.exp to use
build_executable_and_dwo_files, as it should. Remove the
gdb_remote_download call from gdb.dwarf/fission-with-type-unit.exp,
because build_executable_and_dwo_files does not support remote hosts
anyway.
With this change, running with the cc-with-gdb-index board, I see:
(gdb) maint expand-symtabs
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)
This is actually an improvement, as the test case didn't run properly
before. The compilation failed with:
gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit]
The reason was that the old code would try to generate the GDB index
during this step:
# Build main file.
if { [build_executable "${testfile}.exp" $binfile \
[list ${srcfile} ${main_asm_file}] {nodebug}] } {
return
}
... which is before the DWO file is even generated. With this patch
things are done in the correct order:
- The -dw.S file is generated
- The -dw.o file is compiled from the -dw.S
- The .dwo sections are extracted to the .dwo file, and stripped from
the -dw.o file
- The executable is linked from the .o and -dw.o
- gdb-add-index is ran on the executable
When gdb-add-index runs, the .dwo file exists, so GDB is able to produce
an index. That index is bogus though, because the .gdb_index format is
unable to describe skeletonless type units. And then GDB gets confused
trying to use that index, leading to the internal error.
Change-Id: Iabbcf00db97faf2a4fa5fc71652ad273081189f9 Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Fri, 21 Nov 2025 20:13:58 +0000 (15:13 -0500)]
gdb/testsuite/dwarf: ensure build_executable_and_dwo_files calls untested in all failure paths
There are some paths of build_executable_and_dwo_files that return -1
without calling "untested". As a result, tests such as
gdb.dwarf2/fission-absolute-dwo.exp would exit without leaving a trace.
Add some untested calls to fix that.
Change-Id: I2e632b5b44b11b4beb39791316f1203f9a12bf4f Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Tue, 25 Nov 2025 04:04:30 +0000 (23:04 -0500)]
gdb/dwarf: remove nullptr prop check in dwarf2_evaluate_property
This nullptr is pointless most of the time: almost all callers either
check that the prop is not nullptr or they pass the address of a local
variable, which is necessarily not nullptr. I propose to remove it. I
found only one call site where I needed to add a check.
Change-Id: Iada84d529b8edc6b20486f3539c675dad6b364f5 Approved-By: Tom Tromey <tom@tromey.com>
[gdb/testsuite] Error out on clean_restart <absolute filename>
These commits added a lot of calls to gdb_load which can be removed in
many cases by passing $testfile to clean_restart, or by switching to
use prepare_for_testing to compile the test executable.
In this commit I've gone through the gdb.base/ directory and removed
as many of the gdb_load calls as possible. I was only looking for
places where the gdb_load call immediately follows the call to
clean_restart. And I did skip a few where it was not as simple as
just passing $testfile.
Where possible I've updated tests to use calls to prepare_for_testing,
and simply removed the clean_restart call altogether (this is done as
part of prepare_for_testing). This is, I think, the best solution.
In other cases I've removed the gdb_load call, and passed $testfile to
clean_restart. I've preferred $::testfile to adding a 'global'
declaration, and in some cases switching to testfile has allowed me to
remove the 'global binfile' as an additional cleanup.
I ran the complete set of tests that I touched and I didn't see any
regressions, so I don't believe I broke anything.
I know that there are probably gdb_load calls that can be cleaned up
in other testsuite sub-directories, if/when this patch is merged I'll
take a look at those too.
[gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64
The problem with AArch64 hardware watchpoints is that they (as I
understand it) are restricted to a minimum of 8 bytes.
The problem is that current AArch64 hardware has imprecise hardware
watchpoint events due to unaligned accesses. The address reported for
the watchpoint event will depend on the access size. As a result, it
is possible that multiple watchpoints could potentially account for a
single watchpoint event, which is the case in the RH test. GDB can
then miss-identify which watchpoint actually triggered.
Prior to the above commit the RH test was passing. However, the test
was relying on, in the case of ambiguity, GDB selecting the first
created watchpoint. That behaviour changed with the above commit.
Now GDB favours reporting non write breakpoints, and will only report
a write breakpoint if no non-write breakpoint exists in the same
region.
I originally posted a patch to try and tweak the existing logic to
restore enough of the original behaviour that the RH test would pass,
this can be found here (2 iterations):
Neither of these really resolved the problem, they fixed some cases,
but broke others.
Ultimately, the problem on AArch64 is that for a single watchpoint
trap, there could be multiple watchpoints that are potentially
responsible. The existing API defined by the target_ops methods
stopped_by_watchpoint() and stopped_data_address() only allow for two
possible options:
1. If stopped_by_watchpoint() is true then stopped_data_address()
can return true and a single address which identifies all
watchpoints at that single address, or
2. If stopped_by_watchpoint() is true then stopped_data_address()
can return false, in which case GDB will check all write
watchpoints to see if any have changed, if they have, then GDB
tells the user that that was the triggering watchpoint.
If we are in a situation where we have to choose between multiple
write and read watchpoints then the current API doesn't allow the
architecture specific code to tell GDB core about this case.
In this commit I propose that we change the target_ops API,
specifically, the method:
The architecture specific code can now return a set of watchpoint
addresses, allowing GDB to identify a set of watchpoints that might
have triggered. GDB core can then select the most likely watchpoint,
and present that to the user.
As with the old API, target_ops::stopped_data_addresses should only be
called when target_ops::stopped_by_watchpoint is true, in which case
it's return values can be interpreted like this:
a. An empty vector; this replaces the old case where false was
returned. GDB should check all the write watchpoints and select
the one that changed as the responsible watchpoint.
b. A single entry vector; all targets except AArch64 currently
return at most a single entry vector. The single address
indicates the watchpoint(s) that triggered.
c. A multi-entry vector; currently AArch64 only. These addresses
indicate the set of watchpoints that might have triggered. GDB
will check the write watchpoints to see which (if any) changed,
and if no write watchpoints changed, GDB will present the first
access watchpoint.
In the future, we might want to improve the handling of (c) so that
GDB tells the user that multiple access watchpoints might have
triggered, and then list all of them. This might clear up some
confusion. But I think that can be done in the future (I don't have
an immediate plan to work on this). I think this change is already a
good improvement.
The changes for this are pretty extensive, but here's a basic summary:
* Within gdb/ changing the API name from stopped_data_address to
stopped_data_addresses throughout. Comments are updated too where
needed.
* For targets other than AArch64, the existing code is retained with
as few changes as possible, we only allow for a single address to
be returned, the address is now wrapped in a vector. Where we
used to return false, we now return the empty vector.
* For AArch64, the return a vector logic is pushed through to
gdb/nat/aarch64-hw-point.{c,h}, and aarch64_stopped_data_address
changes to aarch64_stopped_data_addresses, and is updated to
return a vector of addresses.
* In infrun.c there's some updates to some debug output.
* In breakpoint.c the interesting changes are in
watchpoints_triggered. The existing code has three cases to
handle:
(i) target_stopped_by_watchpoint returns false. This case is
unchanged.
(ii) target_stopped_data_address returns false. This case is now
calling target_stopped_data_addresses, and checks for the
empty vector, but otherwise is unchanged.
(iii) target_stopped_data_address returns true, and a single
address. This code calls target_stopped_data_addresses, and
now handles the possibility of a vector containing multiple
entries. We need to first loop over every watchpoint
setting its triggered status to 'no', then we check every
address in the vector setting matching watchpoint's
triggered status to 'yes'. But the actual logic for if a
watchpoint matches an address or not is unchanged.
The important thing to notice here is that in case (iii), before
this patch, GDB could already set _multiple_ watchpoints to
triggered. For example, setting a read and write watchpoint on
the same address would result in multiple watchpoints being marked
as triggered. This patch just extends this so that multiple
watchpoints, at multiple addresses, can now be marked as
triggered.
* In remote.c there is an interesting change. We need to allow
gdbserver to pass the multiple addresses back to GDB. To achieve
this, I now allow multiple 'watch', 'rwatch', and 'awatch' tokens
in a 'T' stop reply packet. There's a new feature multi-wp-addr
which is passed in the qSupported packet to determine if the
remote is allowed to pass back multiple watchpoint stop reasons.
If the remote passed multiple watchpoint addresses then these are
collected and returned from the target_ops::stopped_data_addresses
call.
If a new GDB connects to an old gdbserver that doesn't understand
the multi-wp-addr feature, then gdbserver will continue to return
a single watchpoint address in the 'T' packet, which is what
happens before this patch.
* In gdbserver/ the changes are pretty similar. The API is renamed
from ::stopped_data_address to ::stopped_data_addresses, and
::low_stopped_data_address to ::low_stopped_data_addresses.
There's also code added to detect the new multi-wp-addr feature.
If this feature is not advertised from GDB then only a single
watchpoint address will be returned in the 'T' stop reply packet.
* In GDB and gdbserver, for all targets except AArch64, the existing
code to figure out a watchpoint address is retained, we just wrap
the single address into a vector.
* For AArch64, we call aarch64_stopped_data_addresses, which returns
the required vector.
For testing, I've built GDB on GNU/Linux for i386, x86-64, PPC64le,
ARM, and AArch64. That still leaves a lot of targets possibly
impacted by this change as untested. Which is a risk. I certainly
wouldn't want to push this patch until after GDB 17 branches so we
have time to find and fix any regressions that are introduced.
I've run a full regression test on AArch64 and x86-64 (both GNU/Linux)
with no regressions. As I said above, for other targets nothing
should really have changed, all non-AArch64 targets just return a
single watchpoint address from target_ops::stopped_data_addresses(),
so, as long as the target builds, it should run unchanged.
I also sent the branch through the sourceware CI, and everything
passed.
H.J. Lu [Sun, 30 Nov 2025 08:02:07 +0000 (16:02 +0800)]
lto: Compile PR ld/23818 test with -fPIC
Compile PR ld/23818 test with -fPIC to fix
testsuite/ld-plugin/pr23818b.c:6:(.text+0x34): relocation R_MIPS_26 against `a local symbol' cannot be used when making a shared object; recompile with -fPIC
FAIL: Build libpr23818.so
for mips.
PR ld/23818
* testsuite/ld-plugin/lto.exp: Compile PR ld/23818 test with
-fPIC.
H.J. Lu [Fri, 28 Nov 2025 00:05:18 +0000 (08:05 +0800)]
elf: Properly place base symbols in DT_GNU_HASH and DT_HASH
The base symbol, a symbol with the empty version string, created by
asm (".symver foo_base, foo@");
is used to provide a compatibility symbol in a versioned shared library
for binaries linked against the previous unversioned shared library.
The dynamic linker will pick the first match to resolve the unversioned
symbol reference. If the newest version, VERS_1,
asm (".symver foo_v1, foo@@VERS_1");
is picked before the base symbol in DT_GNU_HASH and DT_HASH, foo@@VERS_1,
instead of foo@, will be used to resolve the unversioned reference.
Properly place base symbols in DT_GNU_HASH and DT_HASH so that they will
be picked first.
Also check defined function symbol, foo, and undefined function symbol,
bar, separately to support different dynamic symbol orders.
bfd/
PR ld/33577
PR ld/33673
* elf-bfd.h (elf_link_hash_entry): Add base_symbol.
(elf_link_hash_table): Add has_base_symbols.
* elflink.c (_bfd_elf_merge_symbol): Set base_symbol and
has_base_symbols if the version string is empty.
(collect_gnu_hash_codes): Add base_symbol.
(elf_gnu_hash_process_symidx): Skip if base symbol doesn't match.
(bfd_elf_size_dynsym_hash_dynstr): If there are base symbols,
output base symbols first in DT_GNU_HASH.
(elf_outext_info): Add base_symbol.
(elf_link_output_extsym): Skip if base symbol doesn't match.
(_bfd_elf_final_link): If there are base symbols, output base
symbols last in DT_HASH.
H.J. Lu [Fri, 28 Nov 2025 08:07:57 +0000 (16:07 +0800)]
elf: Renumber local dynamic symbols only if needed
Only hppa, ia64 and sparc ELF targets use local dynamic symbols. But
elf_link_renumber_local_hash_table_dynsyms is always called to renumber
local dynamic symbols even if there is none. Add has_local_dynsyms to
elf_link_hash_table and set it to true only if there are local dynamic
symbols. Renumber local dynamic symbols only if there are local dynamic
symbols.
* elf-bfd.h (elf_link_hash_table): Add has_local_dynsyms.
* elflink.c (_bfd_elf_link_renumber_dynsyms): Renumber local
dynamic symbols only if there are local dynamic symbols.
(_bfd_elf_adjust_dynamic_symbol): Set has_local_dynsyms if
there are local dynamic symbols.
Alan Modra [Sun, 30 Nov 2025 03:44:18 +0000 (14:14 +1030)]
ELF symbol version output cleanup
* elflink.c (elf_link_output_extsym): Localise code setting
VERSYM_HIDDEN to previous branch of "if" where def_regular
might be true. Delete noversion. Set vs_vers to zero instead.
Alan Modra [Sun, 30 Nov 2025 02:21:54 +0000 (12:51 +1030)]
PR 33637, abort in byte_get
When DWARF5 support was added to binutils in commit 77145576fadc,
the loop over CUs in process_debug_info set do_types when finding a
DW_UT_type unit, in order to process the signature and type offset
entries. Unfortunately that broke debug_information/debug_info_p
handling, which previously was allocated and initialised for each unit
in .debug_info. debug_info_p was NULL when processing a DWARF4
.debug_types section. After the 77145576fadc change it was possible
for debug_infp_p to be non-NULL but point to zeroed data, in
particular a zeroed offset_size. A zero for offset_size led to the
byte_get_little_endian abort triggered by the fuzzer testcase.
I haven't investigated whether there is any need for a valid
offset_size when processing a non-fuzzed DWARF4 .debug_types section.
Presumably we'd have found that out in the last 6 years if that was
the case. We don't want to change debug_information[] for
.debug_types!
PR 33637
* dwarf.c (process_debug_info): Don't change DO_TYPES flag bit
depending on cu_unit_type. Instead test cu_unit_type along
with DO_TYPES to handle signature and type_offset for a type
unit. Move find_cu_tu_set_v2 call a little later.
Alan Modra [Sun, 30 Nov 2025 02:21:30 +0000 (12:51 +1030)]
Re: bfd/Dwarf: Add suitable defines to use at call and use sites
Commit 1f7e70ddd2c4 made changes to process_debug_info parameters
without adjusting the function comment to suit. Fix that, and tidy
do_printing flag use.
* dwarf.c (process_debug_info): Edit function comment.
Make do_printing a bool. Fold DO_LOC test into do_printing.
Roman Kapl [Sat, 29 Nov 2025 11:45:27 +0000 (12:45 +0100)]
bfd: fix potential missing seek
If a file was closed by cache and then bfd_open_file was called followed
by e.g. bfd_seek to the original position, the seek would be optimized out
while the real file position was still zero (as fopened). I added
`bfd_io_force` to force the seek at next IO occasion.
This could lead e.g. to appearence of a corrupted object in ld:
symbol number 0 uses unsupported binding of 6
or invalid string offset #X >= #Y for section
Andreas Schwab [Sat, 22 Nov 2025 10:29:43 +0000 (11:29 +0100)]
gprofng: protect against standard library macros
The CALL_UTIL macro can expand to an unparsable expression of the argument
is a macro, like with the new const-preserving standard library macros in
C23.
* gprofng/src/collector_module.h (CALL_UTIL): Add parens to not
expand its argument if it is a function-like macro.
Jan Vrany [Fri, 28 Nov 2025 13:47:02 +0000 (13:47 +0000)]
gdb: update is_addr_in_objfile to support "dynamic" objfiles
While working with objfiles in Python I noticed that
gdb.Progspace.objfile_for_address () does not return "dynamic" objfiles
created by (for example) GDB's JIT reader API.
This is because is_addr_in_objfile() checks if a given address falls into
any (mappped) section of that objfile. However objfiles created by JIT
reader API do not have sections.
To solve this issue, this commit updates is_addr_in_objfile() to also
check if the address fall into any compunit in that objfile. It does so
only if the objfile has no sections.
Jan Vrany [Fri, 28 Nov 2025 13:47:02 +0000 (13:47 +0000)]
gdb: change blockvector::contains() to handle blockvectors with "holes"
This commit slightly changes the logic in blockvector::contains()
to handle a case where the blockvector contains blocks with disjoint
regions (see the comment in blockvector::contains for details).
This change may potentially change GDB's behavior. It is not clear to me
if there was a reason for blockvector_contains_pc() behaving differently
depending whether or not given blockvector contain a map. With this
change, blockvector::contains() return the same value regardless. The
reason for it is to make it work as expected also for "dynamic" code
created by JIT reader (and perhaps by Python in the future).
Note that for CUs created from DWARF, blockvectors have always a map set
so this change in behavior should not affect them. Running testsuite
on Linux x86_64 shown no regressions.
Finally, I was considering of making this change up in lookup method
but in the end decided to be bit more conservative because comment in
original find_block_in_blockvector() suggested that returning a static
block from there is an expected situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Vrany [Fri, 28 Nov 2025 13:47:02 +0000 (13:47 +0000)]
gdb: update blockvector::lookup
This commit changes blockvector::lookup() to improve style and
readability. It also adds quick range check to see if given address
falls into global block.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Fri, 28 Nov 2025 08:48:54 +0000 (09:48 +0100)]
x86: drop a few excess AVX512VL from opcode table
In commit 24187fb9c0d0 ("x86/APX: extend SSE2AVX coverage") I apparently
went a little to far with AVX512VL uses:
- PEXTRQ and PINSRQ are AVX512DQ alone, despite using 128-bit (XMM)
registers,
- SSE41DQ is used for only PEXTRD and PINSRD, falling in the same
category.
With the SSE41DQ observation above, also simplify Disp8MemShift handling
there: No need to override it in the insn template, as long as the
manufacturing template specifies it correctly.
Note that the AVX512DW form of PINSRQ also had a stray "AVX" CPU specifier
on it. Make this disappear by templatizing via a new SSE41DQ64
manufacturing template (covering PEXTRQ and PINSRQ, paralleling SSE41DQ).
Jan Beulich [Fri, 28 Nov 2025 08:48:18 +0000 (09:48 +0100)]
ld: support most modifiers for printf() like vfinfo() format specifiers
Not doing so is pretty error prone: One needs to distinguish e.g.
->einfo() and alike invocations out of libbfd from _bfd_error_handler()
ones. Omit support for * though for now, as that would be more intrusive
to implement.
Use this then to disambiguate x86'es ISA level diagnostic of unknown bits,
where decimal vs hex isn't immediately clear.
bfd/Dwarf: Add suitable defines to use at call and use sites
use do_loc and do_types arguments into a signle unsigned int do_flags for
better code readability.
binutils/
* dwarf.c (DO_LOC, DO_TYPES): Define.
(process_debug_info): Change arguments do_loc and do_types
to a single unsigned int do_flags.
(find_cu_tu_set_v2): Change parameter do_types from int to bool.
Simon Marchi [Thu, 27 Nov 2025 17:15:43 +0000 (12:15 -0500)]
gdb/MAINTAINERS: add Christina Schimpe as x86-64 and i386 maintainer
Christina Schimpe has kindly agreed to take on the role of maintainer
for the x86-64 and i386 targets (thank you!). Update the MAINTAINERS
file to reflect that.
Currently, on startup, GDB prints a lot of licensing information and
then a few hints for new users. While there is an attempt to separate
the hints from the rest of the text, my user testing showed that it is
not good enough, and most unfamiliar users will just skip the
information. Especially considering that the documentation link happens
before the separation.
This commit attempts to make the startup message more friendly to new
users by visually separating the most important commands from the
copyright. If there is enough space available, a box is printed
containing the hints (either using unicode box drawing characters, if
emojis are allowed, or using ascii). If there isn't space for a box,
a simple line separator is printed. The code deems "enough space
available" when there is enough space to print the documentation URL
inside the box, since the other hints will be broken into multiple
lines if necessary.
Here are examples of the 2 possible startups, with enough space:
+-----------------------------------------------------------------+
| Find the GDB manual online at: |
| http://www.gnu.org/software/gdb/documentation/ |
| For help, type "help". |
| Type "apropos <word>" to search for commands related to "word". |
+-----------------------------------------------------------------+
And with limited space:
---------------------------------------------
Find the GDB manual documentation resources o
nline at:
<http://www.gnu.org/software/gdb/document
ation/>.
For help, type "help".
Type "apropos word" to search for commands re
lated to "word".
Tom de Vries [Thu, 27 Nov 2025 11:52:03 +0000 (12:52 +0100)]
[gdb/tdep] Simplify i386_thiscall_push_dummy_call
I came across this code in i386_thiscall_push_dummy_call:
...
int args_space = 0;
...
for (write_pass = 0; write_pass < 2; write_pass++)
{
int args_space_used = 0;
...
if (write_pass)
{
store_unsigned_integer (buf, 4, byte_order, struct_addr);
write_memory (sp, buf, 4);
args_space_used += 4;
}
else
args_space += 4;
...
and wondered about the difference between arg_space and arg_space_used.
AFAICT, there is none:
- args_space is available after the loop, but unused after the loop
- in the loop body:
- if write_pass == 0: args_space is used
- if write_pass == 1: arg_space_used
- the code modifying args_space and args_space_used is identical
Simplify the loop body by using just one variable: args_space.
Tested on x86_64-linux with target board unix/-m32.
Alan Modra [Wed, 26 Nov 2025 22:31:31 +0000 (09:01 +1030)]
PR 33453 backend_finish_dynamic_sections final link buffer
This adds a pointer parameter to backend_finish_dynamic_sections, to
give the function access to the final link section contents buffer.
The patch is entirely mechanical changes in preparation for the next
patch. No use is made of the buffer here.
Alan Modra [Wed, 26 Nov 2025 22:30:26 +0000 (09:00 +1030)]
PR 33453 allow extra for .eh_frame in final link buffer
The PR33453 testcase overflows a buffer allocated for the .eh_frame
section. This happens with a silly large alignment for .eh_frame,
creating a large gap between two .eh_frame sections. When the last
FDE of the first section is stretched to cover the gap, we get a
buffer overflow. This patch makes the final link buffer large enough
to cover such gaps. It doesn't fix the testcase yet, because there
the first .eh_frame section in question is the x86 plt_eh_frame
section which uses a different buffer. However, similar testcases
could be constructed using object file .eh_frame sections.
PR 33453
* elflink.c (bfd_elf_final_link): Round up max_contents_size
for .eh_frame alignment.
Alan Modra [Wed, 26 Nov 2025 22:24:43 +0000 (08:54 +1030)]
Tidy .eh_frame rawsize manipulation
bfd_elf_discard_info is only called once. Well, it was until commit 9b854f169df9 introduced cmdline_emit_object_only_section, but I think
and hope that function does enough reinitialisation to not cause a
problem. There would be a problem if bfd_elf_discard_info was called
iteratively, shrinking an eh_frame section on the first pass, then
further shrinking on another pass. That's because
_bfd_elf_discard_section_eh_frame uses rawsize to store the last
section size, which is against the general rules for input sections.
rawsize needs to be kept as the initial size to be able to read
section contents again (or you'd need to cache the edited contents).
Other eh_frame functions would break too.
So this tidy makes it obvious when looking at
_bfd_elf_discard_section_eh_frame alone that rawsize is only set once,
to the initial size. There are no functional changes here.
* elf-bfd.h (_bfd_elf_discard_section_eh_frame): Update decl.
* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Return
an int status. Don't set rawsize unless it is zero.
* elflink.c (bfd_elf_discard_info): Use new return status
from _bfd_elf_discard_section_eh_frame rather than comparing
section size with rawsize.
Indu Bhagat [Wed, 26 Nov 2025 06:31:17 +0000 (22:31 -0800)]
libsframe: testsuite: remove usage of ##__VA_ARGS__
'##__VA_ARGS' is a GNU extension, the usage of which in the testsuite of
libsframe may cause failure to build on platforms where the compiler may
not support the GNU extension.
This GNU extension swallows the preceding comma if the variable
arguments list is empty. In libsframe testsuite though, an empty list
is never used. Usages will remain of the following type:
- TEST (cond, "string", vars);
or
- TEST (cond, "string");
Mailing list discussion:
https://sourceware.org/pipermail/binutils/2025-November/145825.html
PR libsframe/33437
libsframe/testsuite/
PR libsframe/33437
* sframe-test.h: Replace ##__VA_ARGS__ with __VA_ARGS__.
Abhay Kandpal [Wed, 26 Nov 2025 06:33:25 +0000 (01:33 -0500)]
PowerPC: Skip base type RTTI tests before inferior start
On PowerPC targets, RTTI typeinfo objects for simple base types such as
`int`, `char*`, and `const char*` may not be emitted until the inferior
has been started. As a result, the `gdb.cp/typeid.exp` test fails when
checking typeid results before program execution begins.
This patch extends the existing Clang-specific logic that skips base type
RTTI checks before the inferior starts, to also apply on PowerPC. This
ensures consistent test behavior across compilers and targets.
gdb/testsuite/
* gdb.cp/typeid.exp (do_typeid_tests): Skip base type RTTI tests
before inferior start on PowerPC.
Indu Bhagat [Wed, 26 Nov 2025 04:46:08 +0000 (20:46 -0800)]
libsframe: bugfix in flip_sframe
A previous commit bdb0d62281a to make flip_fde version aware added a new
argument for passing the remaning buffer size to the involved functions.
Fix the passed value to the intended.
libsframe/
* sframe.c (flip_sframe): Correct the passed value of buf size.
lijian1 [Mon, 24 Nov 2025 07:53:50 +0000 (15:53 +0800)]
LoongArch: set PRSTATUS_SIZE=0x1e0 to match kernel's struct elf_prstatus size
As PRSTATUS_SIZE is now with the value 0x1d8, which causes inconsistency with the kernel
definition and then can not lead to the correct branch for loongarch64 backend.
With the correct value 0x1e0 for the master branch, the loongarch64 banckend will work well.
hppa64: Fix R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocation support
The elf_hppa_final_link_relocate function didn't handle
R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocations
for local symbols.
DLT and OPD output relocation support for local symbols is
consolidated in elf_hppa_dlt_dynrel_reloc() and
elf_hppa_opd_dynrel_relocs().
2025-11-24 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf_hppa_dlt_dynrel_reloc): New.
(elf_hppa_opd_dynrel_relocs): New.
(elf_hppa_final_link_relocate): Use elf_hppa_dlt_dynrel_reloc()
and elf_hppa_opd_dynrel_relocs(). Fix relocation support for
R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64.
Alan Modra [Mon, 24 Nov 2025 08:16:35 +0000 (18:46 +1030)]
PR 33473 SEGV in _bfd_elf_gc_mark_debug_special_section_group
The code that faulted made the assumption that a group section always
had at least one valid member. Fix that assumption. Also fail if all
entries in a SHT_GROUP section are invalid. (An empty group will not
result in a call to process_sht_group_entries.)
PR 33473
* elflink.x (_bfd_elf_gc_mark_debug_special_section_group): Don't
segfault on empty group.
* elf.c (process_sht_group_entries): Return false if all
entries are invalid.
Alan Modra [Mon, 24 Nov 2025 01:01:18 +0000 (11:31 +1030)]
bogus FAILs from mmix ld testsuite
Get rid of [^c][^h][^i][^l][^d] from error regex. It won't match
/home/... and other legitimate paths printed for the program name of
the ld under test.
Michael Matz [Wed, 19 Nov 2025 15:32:51 +0000 (16:32 +0100)]
Use version index 1 for defined symbols
It's reasonable to use version index 0 for undefined
symbols, so let's continue doing that. For defined (global)
symbols that aren't otherwise versioned continue using
VER_NDX_GLOBAL (partly reverting behaviour introduced in
commit f685e395).
bfd/
PR ld/33577
* elflink.c (elf_link_output_extsym): Don't set noversion
for defined syms.
ld/
PR ld/33577
* ld-elfvers/vers16.dsym: Add back the "Base" version for
defined syms.
Michael Matz [Thu, 20 Nov 2025 14:30:50 +0000 (15:30 +0100)]
Make readelf not print 'foo@@' for normal symbols
when a symbol 'foo' is exported and non-hidden and hence is
available for resolving from other objects it's unreasonable
for readelf to print it as 'foo@@'. If it's not available
for unversioned resolving because its version is hidden
(but without name), then continue printing it as 'foo@' to
indicate that something special goes on.
Matthieu Longo [Wed, 19 Nov 2025 17:01:56 +0000 (17:01 +0000)]
aarch64: constify BTI and GCS report functions
This patch consitifies the arguments of the functions used to report BTI
and GCS errors, and also renames the argument "ebfd" to "abfd" as this
naming is confusing and inconsistent with others places.
Matthieu Longo [Mon, 14 Jul 2025 14:19:05 +0000 (15:19 +0100)]
gas: move code for object attribute parsing into obj-elf-attr.c
Gas, contrarilly to others binutils tools, is compiled for a specific
target. Some targets don't support Object Attributes (OAs). For those
cases, today the OA directive ".gnu_attribute" is still enabled but the
processing would probably fail in most of cases because the named tag
would be unknown. Most of the parsing code on such a target can be
considered as dead code.
This patch aims at removing this dead code from Gas when the target does
not support the OAs by:
- moving the code of OA parsing into a separate file under gas/config
which is only included for the relevant targets supporting OAs.
- disabling the code related to OAs on non-OA target via a TC_OBJ_ATTR
macro.
Adding/removing the OA feature from Gas for a specific target can easilly
be done from tc-<arch>.h by changing the values of TC_OBJ_ATTR: 1 enabled,
0 disabled. You might also want to guard the enablement of OAs only for
ELF targets with OBJ_ELF (see example below).
Matthieu Longo [Thu, 17 Apr 2025 10:05:16 +0000 (11:05 +0100)]
bfd: rename parsing methods of object attribute v1 API
This patch is a preparation for the introduction of object attributes
v2. It aims at:
- making clear what methods are used to parse OAv1
- adding more constaints on parameters type by using enums instead of
defines.
- hiding the attribute tag type behind a typedef.
- preparing the move of object attributes's parsing code to another
file.
Note: the name obj_attr_v1_process_attribute is exposed in the API.
Ideally, the version should not be part of the name, and be hidden
behind a macro. However, a later patch will unify the parsing of
OAv1 and OAv2, and will make the use of such a macro obsolete.
Matthieu Longo [Tue, 11 Nov 2025 10:50:23 +0000 (10:50 +0000)]
bfd: rename old references to build attributes
A previous refactoring patch [1] introduced "build_attributes" in the
functions naming. However this naming is specific to the AArch64 Build
Attributes specification, and should be replaced by "object_attributes"
going forward.
Simon Marchi [Tue, 18 Nov 2025 03:38:25 +0000 (22:38 -0500)]
gdb: resolve dynamic type in one value_cast case
This particular path for value_cast does not attempt to resolve a
dynamic target type before assigning it to the new value. Having a
value with a dynamic type that hasn't been resolved causes an assert
later, when printing the value. For instance, running the added test
without the fix yields:
This code path is taken when the value being cast has the same size as
the target type, and no earlier more specific rule matched. Fix it by
adding a call to resolve_dynamic_type before assigning the target type
to the value.
The test exercises this by defining a char array
(`g_outer_as_char_array`) with the same size as `outer_type` in the
DWARF info, then casting it to `outer_type`. Without the fix, this
triggers the assertion when printing the result.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33575
Change-Id: I547da32bbd24462b779e76bceb6e0a87859188d1 Approved-By: Tom Tromey <tom@tromey.com>
The test added by this patch mimics a problem that was reported when
debugging a Fortran program. The situation is:
- The DWARF defines a Fortran-style array type, with a
DW_AT_data_location attribute.
- It then defines a structure type (outer_type) with a field
(outer_type::assoc) of that array type.
- Trying to cast a minimal symbol (g_outer_var) to that structure type
leads to the internal error shown above.
The use case for this is: for some reason, a variable of type S isn't
described in the debug info, but GDB still knows about type S. The user
is trying to say: I know that the variable at this address is an S, show
it to me.
A Fortran-style array doesn't hold the data directly. It's a structure
(a descriptor) that contains a pointer to the data and possible other
properties, like the length of the array. The DW_AT_data_location
attribute contains a DWARF expression that yields the location the
actual data, given the location of the descriptor. In GDB's type
system, this translates to a dynamic property of kind
DYN_PROP_DATA_LOCATION pointing to the DWARF expression. Before
instantiating a value with such a dynamic type, the dynamic type must
first be resolved, which is done by function resolve_dynamic_type. That
is, for each dynamic property, compute a concrete value for the specific
instance we're dealing with here. The result of resolve_dynamic_type is
a type that is just like the input type, but where all dynamic
properties now have concrete, constant values.
Here's the timeline of what happens when doing "p (outer_type)
g_outer_var":
1. We start in var_msym_value_operation::evaluate_for_cast.
... where to_type is the "outer_type" structure and arg2 is the
minsym. This effectively builds a value pretending that there
exists an instance of outer_type at the address of the minsym, which
is what we want. The resulting value is "lval_memory".
3. Somewhere inside value_at_lazy, there is a call to
resolve_dynamic_type:
#0 resolve_dynamic_type (type=0x7e0ff1cfd560, valaddr=..., addr=0x4340, in_frame=0x7bfff0b3f100) at /home/smarchi/src/binutils-gdb/gdb/gdbtypes.c:3011
#1 0x000055556687dcba in value_from_contents_and_address (type=0x7e0ff1cfd560, valaddr=0x0, address=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/value.c:3669
#2 0x00005555667ec527 in get_value_at (type=0x7e0ff1cfd560, addr=0x4340, frame=..., lazy=1) at /home/smarchi/src/binutils-gdb/gdb/valops.c:992
#3 0x00005555667ec79f in value_at_lazy (type=0x7e0ff1cfd560, addr=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/valops.c:1039
#4 0x00005555667e902b in value_cast (type=0x7e0ff1cfd560, arg2=0x7d0ff1c35540) at /home/smarchi/src/binutils-gdb/gdb/valops.c:645
This is good, it returns a structure type where the type of field
"assoc" has a constant DYN_PROP_DATA_LOCATION property that holds
the memory address where the data for this array resides.
4. Back in var_msym_value_operation::evaluate_for_cast, we do:
val = value_cast (to_type, val);
/* Don't allow e.g. '&(int)var_with_no_debug_info'. */
if (val->lval () == lval_memory)
{
if (val->lazy ())
val->fetch_lazy ();
val->set_lval (not_lval);
}
This is meant to make GDB behave more or less like C, where the
result of a cast is not an lvalue, of which you can't take the
address, for instance. I am not an expert in this area, but Pedro
explained that this lval thing in GDB actually conflates two things:
- where is the value (memory, register, only in GDB's mind, etc)
- is this an lvalue (is it assignable, can you take its address,
etc)
Here, we would ideally want to say that the value is not an lvalue,
but still say that it lives at a given address in memory. But since
the two concepts are conflated, we set it to "not_lval", which means
"not an lval and does not exist on target".
If there was a way to say "non-lvalue" and "in memory", I think that
the bug that follows would be hidden.
5. When printing the value, the value-printing code attempts to fetch
the "assoc" field of the struct using value::primitive_field, which
then goes into value::set_component_location. In
set_component_location there is this code, which is where we find
the assert that fails:
/* If the COMPONENT has a dynamic location, and is an
lval_internalvar_component, then we change it to a lval_memory.
Usually a component of an internalvar is created non-lazy, and has
its content immediately copied from the parent internalvar.
However, for components with a dynamic location, the content of
the component is not contained within the parent, but is instead
accessed indirectly. Further, the component will be created as a
lazy value.
By changing the type of the component to lval_memory we ensure
that value_fetch_lazy can successfully load the component.
This solution isn't ideal, but a real fix would require values to
carry around both the parent value contents, and the contents of
any dynamic fields within the parent. This is a substantial
change to how values work in GDB. */
if (this->lval () == lval_internalvar_component)
{
gdb_assert (lazy ());
m_lval = lval_memory;
}
else
gdb_assert (this->lval () == lval_memory);
I think that what this comment is really trying to say is: if a
structure is an internalvar, and a field of that structure has a
dynamic data location, then the actual data is not contained in the
internalvar, it is in memory.
The message for the commit that introduced that code (3c8c6de21da
"gdb: user variables with components of dynamic type")) confirms it,
I think. The message also goes on to explain that we could imagine
a world where the internalvar outer struct value would also capture
the (indirect) contents of the array field. The internalvar value
would then be completely self-contained. I imagine this could be
useful in some cases, but we don't have that today.
The comment makes it sound like it's a hack, but I actually think it
makes sense. This is what is really happening.
This all assumes that the result of the DW_AT_data_location is a
location in memory. I guess this is true for all practical purposes
today, but it would be possible for DW_AT_data_location to yield a
register, a composite, or even "undefined" (meaning optimized out)
as a location (which would be even easier to implement with the
upcoming DWARF 6 "Location descriptions on the DWARF stack" feature
[1]). In that case, the location that we set for the array
component should reflect whatever the DWARF expression returned.
But that is future work, for now, we assume that the data location
can only be in memory.
So, the fix is basically to always set the location of a value
sub-component to "memory", because we assume (for now) that the result
of all DW_AT_data_location expressions will be memory locations.
Now, referring back to point 4 above: if the code in
var_msym_value_operation::evaluate_for_cast could in fact set the value
to "non-lvalue in memory", then we wouldn't hit the assert in
value::set_component_location, because the subcomponent would have
inherited lval_memory from the parent structure. However, I still think
that the fix in this patch is valid on its own. Imagine that the DWARF
says that the outer struct (and thus the array descriptor) is in a
register. Once we evaluate the DW_AT_data_location of the array field,
the value describing the actual data is still in memory.
The takeaway is that regardless of the location of the descriptor, the
DW_AT_data_location expression always returns a memory location (for
now), so we should always set the location of that value to memory. In
other words, we apply the same logic as commit 3c8c6de21da regardless of
the location of the outer value".
Finally, a note about the test: I made the array content very long (100
elements), because I did spot some issues where GDB would conflate the
size of the array data with the size of the array field, within the
outer structure. The test does not expose these issues and I didn't try
to fix them here (one thing at a time), but making the array size very
large might help spot these issues in the future.
[1] https://dwarfstd.org/issues/230524.1.html
Change-Id: Ib10a77b62cd168fc7c08702e0f6dd47b5ac0f097
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33575 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 19 Nov 2025 09:42:34 +0000 (02:42 -0700)]
Remove a call to blockvector::map
block_starting_point_at checks blockvector::map before doing a lookup.
This patch removes this call, a step toward making the blockvector API
a bit more opaque. It arranges to find the necessary blockvector just
once, in gather_inline_frames, and then uses the 'lookup' method to
find the desired block.
Note that this is a slight change of semantics, in that the old code
looked only in the map while the new code looks in the blockvector,
regardless of whether a map was made. However, I don't think this
should matter, and furthermore this seems like an abstraction
violation, with the inline-frame code knowing details of how buildsym
decided to create the blockvector.
in the longer run, I think only the 'lookup' method should be provided
by blockvector -- that is, separately checking the map should be
impossible. The idea here is that eventually, for lazy CU expansion,
we will want to be able to expand the blockvector. This may be easier
with a different underlying data structure, so perhaps the map will go
away entirely. After this patch, one such use remains.
Tom de Vries [Sat, 22 Nov 2025 15:44:48 +0000 (16:44 +0100)]
[gdb/testsuite] Rewrite strings in gdb.ada/unchecked_union.exp
In test-case gdb.ada/unchecked_union.exp, git --check reports some whitespace
issues:
...
$ git diff-tree --check $(git hash-object -t tree /dev/null) HEAD \
-- gdb/testsuite/gdb.ada/unchecked_union.exp \
| grep -c "indent with spaces"
12
...
The problem is that this style of string is used containing space-indented
text:
...
set inner_string { case ? is
when 0 =>
small: range 0 .. 255;
second: range 0 .. 255;
when ? =>
bval: range 0 .. 255;
when others =>
large: range 255 .. 510;
more: range 255 .. 510;
end case;
}
...
Fix this by changing the string into a list of strings:
...
set inner_string \
[list \
" case ? is" \
" when 0 =>" \
" small: range 0 .. 255;" \
" second: range 0 .. 255;" \
" when ? =>" \
" bval: range 0 .. 255;" \
" when others =>" \
" large: range 255 .. 510;" \
" more: range 255 .. 510;" \
" end case;"]
...
which also fixes the odd position of the first line in the original version.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/33616
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616
Alan Modra [Fri, 21 Nov 2025 23:22:18 +0000 (09:52 +1030)]
PR 33639 .debug_loclists output
The fuzzed testcase in this PR prints an almost endless table of
offsets, due to a bogus offset count. Limit that count, and the total
length too.
PR 33639
* dwarf.c (display_loclists_unit_header): Return error on
length too small to read header. Limit length to section
size. Limit offset count similarly.
Alan Modra [Fri, 21 Nov 2025 22:52:10 +0000 (09:22 +1030)]
PR 33638, debug_rnglists output
The fuzzed testcase in this PR continuously outputs an error about
the debug_rnglists header. Fixed by taking notice of the error and
stopping output. The patch also limits the length in all cases, not
just when a relocation is present, and limits the offset entry count
read from the header. I removed the warning and the test for relocs
because the code can't work reliably with unresolved relocs in the
length field.
PR 33638
* dwarf.c (display_debug_rnglists_list): Return bool. Rename
"inital_length" to plain "length". Verify length is large
enough to read header. Limit length to rest of section.
Similarly limit offset_entry_count.
(display_debug_ranges): Check display_debug_rnglists_unit_header
return status. Stop output on error.
Alan Modra [Fri, 21 Nov 2025 22:45:00 +0000 (09:15 +1030)]
som foreign syms
The makes use of the copy_private_symbol_data change in order to
prevent bogus writes seen when running objcopy with binary input and
som output. It doesn't fix "FAIL: binary symbol", because the som
backend also doesn't copy binary sections to the output, a fact that I
didn't notice until I'd gone quite some way into fixing symbols..
* som.c (som_bfd_copy_private_symbol_data): Make som symbols
for non-som input.
Alan Modra [Fri, 21 Nov 2025 22:43:26 +0000 (09:13 +1030)]
bfd_copy_private_symbol_data
Allow copy_private_symbol_data to replace osym if a target desires.
Change isym similarly for symmetry. The idea is to make it possible
to give the asymbol an output target specific extension. Some
targets, eg. som, use such an extension when outputting symbols,
behaving badly if the input object is not som. There are no
functional changes in this patch; It just changes the signatures.
Alan Modra [Fri, 21 Nov 2025 22:39:12 +0000 (09:09 +1030)]
copy_private and merge_private functions
These are all called via BFD_SEND on the output bfd xvec. Thus there
is no need to verify the output bfd flavour. There *is* a need to
verify the input bfd flavour. Also of course target specific data
shouldn't be accessed until the input target is verified. Tidy these
issues in many places.
bfd_copy_private_section_data, bfd_copy_private_symbol_data, and
bfd_merge_private_bfd_data are macros. Delete prototypes created via
synopsis entry in comments.
timurgol007 [Fri, 21 Nov 2025 11:06:02 +0000 (14:06 +0300)]
RISC-V: Fixed opcodes for some bitmanip instructions
Currently some of the instructions in bitmanip extensions can not be obtained
using DECLARE_INSN macros. I generated them using riscv-opcodes and added to
other opcodes.
The problem happens as follows. In core_target_open, we do:
...
if (thread == NULL)
thread = add_thread_silent (target, ptid_t (CORELOW_PID));
...
and then in add_thread_silent:
...
struct thread_info *
add_thread_silent (process_stratum_target *targ, ptid_t ptid)
{
gdb_assert (targ != nullptr);
inferior *inf = find_inferior_ptid (targ, ptid);
...
find_inferior_ptid returns nullptr, which eventually causes the segfault.
So, why can't we find an inferior with CORELOW_PID?
A bit earlier in core_target_open, we do:
...
/* Find (or fake) the pid for the process in this core file, and
initialise the current inferior with that pid. */
bool fake_pid_p = false;
int pid = bfd_core_file_pid (target->core_bfd ());
if (pid == 0)
{
fake_pid_p = true;
pid = CORELOW_PID;
}
The warning is emitted because the pseudo-section .reg is missing, because
elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but
instead we have:
...
$ eu-readelf -n core | grep -i prstatus
CORE 156 PRSTATUS
CORE 156 PRSTATUS
CORE 156 PRSTATUS
CORE 156 PRSTATUS
...
I'm assuming this is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed
by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of
elf_prstatus out").
The core was generated using a kernel with CONFIG_BINFMT_ELF_FDPIC=y and
v5.3.18.
We can try to work around this bug in elf32_arm_nabi_grok_prstatus, but
that's out of scope for this commit, which focuses on fixing the segfault.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR corefiles/33560
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560
gdb: include NT_I386_TLS note in generated core files
includes a pointer value in the test name. The value changes from run
to run making it harder to compare test results. Fix this by giving
the test an actual name.
There's no change to what is being tested with the commit.
Jan Beulich [Fri, 21 Nov 2025 08:05:36 +0000 (09:05 +0100)]
bfd/COFF: mark a function exposed to ld as non-private
As a non-private function, _bfd_coff_read_internal_relocs() shouldn't have
a "_bfd_" prefix, but merely a "bfd_" one. Tidy arguments passed whle at
it.
Jan Beulich [Fri, 21 Nov 2025 08:05:18 +0000 (09:05 +0100)]
bfd/PEI: mark internal functions hidden
This reduces the dynamic symbol table a bit (over a hundred symbols when
building all targets) and allows the compiler to be more aggressive about
inlining (as it sees fit, of course).
Jan Beulich [Fri, 21 Nov 2025 08:05:02 +0000 (09:05 +0100)]
bfd/XCOFF: mark internal data hidden
This reduces the dynamic symbol table a bit (about a dozen symbols) and
allows the compiler to be more aggressive about inlining (as it sees fit,
of course).
projects / thirdparty / binutils-gdb.git / log
